2

In my lab network I have a Juniper MX 80 configured as MPLS router. On one site there is a customer connected (simulated by a single PC) and on the other side is an MPLS network.

I use tcpreplay to generate traffic load. The PCAP file I use has been prepared as follows:

  • Source IP is the IP of the "customer" PC
  • Source MAC is the MAC address of the interface of the customer PC
  • Destination IPs are spread among the test network, but all are existing and there are valid routes
  • Destination MAC is the MAC address of the "customer" interface of the MX80

The packets do actually arrive at the router. I am sending ~140Mbit/s traffic stream, and SMTP counters show the following (read using SNMP):

1.3.6.1.4.1.2636.3.3.1.1.1.517: 0 Mb/s
1.3.6.1.4.1.2636.3.3.1.1.5.517: 17 Mb/s
----
1.3.6.1.4.1.2636.3.3.1.1.1.527: 138 Mb/s
1.3.6.1.4.1.2636.3.3.1.1.5.527: 0 Mb/s

The first two rows are in/out of the network facing interface, and the third + fourth row is the customer facing interface. There are no other interfaces and all traffic is supposed to the router via the first interface. Correct routes are in place, OSPF and LDP is up.

Unfortunately I am a "Cisco guy", I do not now too much on Juniper devices. However, as far as I can tell, the router should be forwarding all the traffic.

I have one suspicions, though: Roughly 19,278% of the packets in the PCAP file is UDP, while the rest is TCP, making up roughly 10,979% of the total traffic volume. This translates to roughly 15,15Mbps being UDP traffic, which nearly matches the not-dropped packet volume.

As the traffic is recorded and later replayed, the packets do not make up correct TCP sessions. Does the router perform some kind of TCP SYN checking? If this is the case, this also would break asynchronous communication.

I have found this article, but my device does not understand the "set security flow *" commands.

Further I have found and tried the steps from this article, but traffic is still dropped.

Here is the configuration of the device. So why is the traffic dropped?

version 14.2R2.8;
groups {
    ffm {
        system {
            host-name F-Rtr;
            root-authentication {
                encrypted-password "******";
            }
        }
    }
}
apply-groups ffm;
system {
    services {
        ssh;
    }
    syslog {
        user * {
            any emergency;
        }
        file messages {
            any notice;                 
            authorization info;
        }
        file interactive-commands {
            interactive-commands any;
        }
    }
    ddos-protection {
        global {
            disable-routing-engine;
            disable-fpc;
            disable-logging;
        }
        protocols {
            tcp-flags {
                initial {
                    disable-routing-engine;
                    disable-fpc;
                }
            }
        }
    }
}
interfaces {                            
    ge-1/0/0 {
        unit 0 {
            description "Link to F-Core";
            family inet {
                address 10.0.1.30/30;
            }
            family mpls;
        }
    }
    ge-1/1/0 {
        unit 0 {
            family inet {
                address 10.0.0.57/29;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 10.0.4.117/32;
            }
        }
    }
}
routing-options {
    router-id 10.0.4.117;
}
protocols {
    mpls {
        interface ge-1/0/0.0;
    }
    ospf {
        area 0.0.0.0 {
            interface ge-1/0/0.0 {
                interface-type p2p;
            }
            interface lo0.0 {
                passive;
            }
            interface ge-1/1/0.0 {
                passive;
            }
        }
    }                                   
    ldp {
        transport-address router-id;
        interface ge-1/0/0.0;
    }
}
2
  • In your pcap file, is ALL the tcp traffic destined for remote routes? Most TCP will be bi-directional, in which case, the return traffic from the original capture would be sourced from the server end of the connection. The MX won't perform TCP Sequence checking on your flows (and "set security flow" is a command from the SRX firewall series), but clearly ALL packets in the capture you are sending will need to be destined for valid routes. Commented Aug 24, 2015 at 21:57
  • Yes, all the traffic has been rewritten to be destined for remote routers. It is actually breaking TCP connections, but this does not matter, as no device should make any checks beyond the IP layer. However I have a similar problem using an Cisco ASR1002-fixed, a Cisco 2901 router, and some virtual routers, so it seems to be a traffic-related problem..
    – Daniel
    Commented Sep 12, 2015 at 20:32

1 Answer 1

0

Finally I found the issue, which was quite a stupid moment... The problem was the MTU of the link combined with many 1514byte packets in the PCAP with the DF bit set.

The PCAP file was recorded at a normal Ethernet connection. In this particular time frame, there were several large packets with 1514 bytes each and the Do Not Fragment (DF) bit set. During the troubleshooting process, I replaced the MX80 with a Cisco ASR10002-f router, and used show ip cef switching statistics which in turn shows a high counter for RP LES Fragmentation failed, DF.

After knowing this I modified the PCAP and truncated the packet in sizes below 1500, and the problem was gone.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.