Juniper MX80 drops generated (TCP?) packets

juniperjuniper-junosjuniper-mx

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;
    }
}

Best Answer

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.