2

I am facing problem with regard to 1 x 10G link (which is actually configured as an aggregated Ethernet (ae) i.e ae link contains only single 10G link.

This ae link is connected between 2 x Juniper MX960 routers. When I ping the P2P IP interface IP (ae) of other end MX960 router , I get packet loss. The behavior is random . Some times I get lost (like 1 or 2 or 3 packets out of 2000) sometimes I dont get even a single drop. The behavior is random.This happens in both directions i.e from R1 --> R2 and vice versa.

While checking the physical interface I verified that there are interface errors of any kind. Further there is no firewall policer applied on the interface or routing engine against the ping that we are sending ping.

Below are the ICMP snapshots and Interface errors at R1 side.

Can we know why IMCP packets are dropped? Why sometime they get dropped while sometimes they dont. 

R1> ping 10.0.2.81 rapid count 2000 size 1400    
PING 10.0.2.81 (10.0.2.81): 1400 data bytes

--- 10.0.2.81 ping statistics ---
2000 packets transmitted, 1999 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.106/1.427/21.957/0.900 ms

R1> ping 10.0.2.81 rapid count 2000 size 1400    
PING 10.0.2.81 (10.0.2.81): 1400 data bytes

--- 10.0.2.81 ping statistics ---
2000 packets transmitted, 2000 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.088/1.416/19.726/0.905 ms

R1> ping 10.0.2.81 rapid count 2000 size 1400    
PING 10.0.2.81 (10.0.2.81): 1400 data bytes

--- 10.0.2.81 ping statistics ---
2000 packets transmitted, 1999 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.099/1.425/19.372/0.753 ms

nabeel.nasir@ISB-I010-EDG-MX96-1-re0> ping 10.0.2.81 rapid count 2000 size 1400    
PING 10.0.2.81 (10.0.2.81): 1400 data bytes

--- 10.0.2.81 ping statistics ---
2000 packets transmitted, 2000 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.108/1.447/13.389/0.818 ms

R1> show configuration interfaces ae30 
apply-groups [ xge-if-parameters ubfd-ae-core ];
aggregated-ether-options {
    bfd-liveness-detection {
        neighbor 192.168.0.1;
        local-address 192.168.0.15;
    }
    lacp {
        active;
        periodic fast;
    }
}
unit 3 {
    apply-groups core-ifl-parameters;
    vlan-id 3;
    family inet {
        address 10.0.2.82/30;
    }
}

R1> show interfaces ae30 extensive | match Error    Link-level type: Flexible-Ethernet, MTU: 9192, Speed: 10Gbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,   Input errors:
    Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0, Policed discards: 0, Resource errors: 0   Output errors:
    Carrier transitions: 0, Errors: 0, Drops: 0, MTU errors: 0, Resource errors: 0

R1> show interfaces ae30 extensive | match Error    Link-level type: Flexible-Ethernet, MTU: 9192, Speed: 10Gbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,   Input errors:
    Errors: 0, Drops: 0, Framing errors: 0, Runts: 0, Giants: 0, Policed discards: 0, Resource errors: 0   Output errors:
    Carrier transitions: 0, Errors: 0, Drops: 0, MTU errors: 0, Resource errors: 0

Thanks

Improve this question
9
  • 3
    Are you seeing any other performance degradation? You might consider that ping traffic is simply considered less important than other control plane traffic so either side could be limiting responses. Just in case, can you post "show configuration interfaces ae30 | display inheritance no-comments"
    – Jordan Head
    Mar 7, 2019 at 13:17
  • Thanks Jordan .Yes. I forgot to mention there is no service effecting. You are right that ping is less important than control plane traffic. But is it possible we could verify via some commands to be sure and (share it with managment) that pings are dropped by RE as they are considered less important. Is there any some counter (which exists by default) that shows dropped packets?
    – Nabeel
    Mar 7, 2019 at 13:42
  • 1
    "Is there any some counter (which exists by default) that shows dropped packets?" It's not that ICMP gets dropped, it is that by the time the target gets around to responding, it has timed out on the source, so the target does respond, but too late for the source application.
    – Ron Maupin ♦
    Mar 7, 2019 at 16:00
  • @ Ron. Can we use some kind of firewall filter at the interface level (not at the RE level) to count the number of ICMP replied packets from R2 to R1 (i.e on R2 in outbound direction towards R1) to check if number of ICMP replied packets are the same as ICMP echo packets.
    – Nabeel
    Mar 8, 2019 at 6:17
  • 1
    @NABEELNASIR What you mentioned about the firewall filter is a good idea, you can set one on the ingress interface(s) to count ICMP. You could also add a term to your lo0.0 interface to count ICMP as well, this represents traffic that hits the control plane (routing engine) and you can correlate the counters. I would recommend setting a match condition on the source address so other ICMP traffic doesn't skew your counters.
    – Jordan Head
    Mar 8, 2019 at 14:12

0

Reset to default

Your Answer

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

Browse other questions tagged or ask your own question.