3

We need to capture LACP PDUs on a member link of an aggregated bundle link on Juniper MX connected with other router via DWDM link and save the output in .pcap format using write-file knob.

Can someone help us to show how to use 'monitor traffic interface' command and capture only the LACP packets? We have tried but failed. The .pcap file size doesn't increase which shows packets are not captured but no error displayed by 'monitor interface traffic' command itself.

Is it possible to run the 'monitor traffic interface' on ae link as well as xe- link (member link)? 

Or we can only run the command on ae link only? 

We solely want to do this for troubleshooting purposes by knowing in which state LACP protocol machine got stuck when there is an issue in underlying DWDM network.

We are also using mirco BFD over LAG. The configurations of LAG as well as loopback interface are shared below.

user@RIK-RIK-Edg-MX24-1-re0> show configuration interfaces ae24 
apply-groups [ xge-if-parameters-core ubfd-ae ];
aggregated-ether-options {
    bfd-liveness-detection {
        neighbor 10.135.19.45;
        local-address 192.168.1.40;
    }
    lacp {
        periodic fast;
    }
}
unit 3 {
    apply-groups core-ifl-parameters;
    vlan-id 3;
    family inet {
        address 10.176.141.90/30;
    }
}

{master}
user@GKN-GKN-Edg-MX24-1-re0> show bfd session 
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
10.135.19.45            Up        xe-2/0/1       0.900     0.300        3   
10.135.19.45            Up        xe-1/1/0       0.900     0.300        3   

user@RIK-RIK-Edg-MX24-1-re0> show configuration interfaces lo0 
unit 0 {
    family inet {
        filter {
            input protect-re;
        }
        address 192.168.1.40/32;
    }
    family iso {
        address 49.0000.1921.6800.1040.00;
    }
}

Many Thanks !

1
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer. – Ron Maupin Dec 31 '20 at 5:21
5

show lacp interfaces <aeX> displays detailed state information for each member-link in a LAG. For example:

user@router> show lacp interfaces ae0 extensive
LACP state:       Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  Activity
      ge-0/0/1       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/1     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/2       Actor    No    No   Yes  Yes  Yes   Yes     Fast    Active
      ge-0/0/2     Partner    No    No   Yes  Yes  Yes   Yes     Fast    Active
    LACP protocol:        Receive State  Transmit State          Mux State 
      ge-0/0/1                  Current   Fast periodic Collecting distributing
      ge-0/0/2                  Current   Fast periodic Collecting distributing
    LACP info:        Role     System             System       Port     Port    Port 
                             priority         identifier   priority   number     key 
      ge-0/0/1       Actor        127  00:05:86:4e:b6:c0        127        1       1
      ge-0/0/1     Partner        127  00:05:86:7e:d3:c0        127        1       1
      ge-0/0/2       Actor        127  00:05:86:4e:b6:c0        127        2       1
      ge-0/0/2     Partner        127  00:05:86:7e:d3:c0        127        2       1

It sounds like you think your active DWDM system is interacting with your LACP-speaking devices. If that's true, you might see a difference in System Identifier among the two sides; or a perceived difference in member state.

I hope you'll post updates as you find more information about your problem; sounds interesting.

12
  • The active DWDM system is NOT interacting with our LACP speaking devices. We do see remote end 'system ID' when we run the command 'show lacp interface <> extensive'. But sometimes it is necessary to make DWDM team believe that problem lies at their end by virtue of packets in wire shark. Because output of commands can be manipulated but not packets itself. – NABEEL NASIR Dec 9 '20 at 12:56
  • 1
    Last Night I was seeing my own LACP System ID when I ran traceoptions at the lacp protocol level while DWDM team was saying no issue at their end. The output of 'show lacp interface <>' shows interface in detached state. As per the LACP protocol states , this condition is called 'LAG Looped'. We encounter LACP protocol states issues (Detached , LACP_TIME_OUT) on daily basis. Hence it is more beneficial to take captures to see the situation in more detail. – NABEEL NASIR Dec 9 '20 at 13:01
  • Are the remote sysIDs displayed by each end the ones you expect, e.g. device A sees remote sysID of device Z and vice-versa? If you don't think the DWDM system is involved in LACP then that should be enough to tell if the waves are configured incorrectly (like misrouted to the wrong device.) – Jeff Wheeler Dec 9 '20 at 13:01
  • If you see a loop you could reconfigure the member-link to be separate from the LAG, give it a temporary IP address, and send some pings, while capturing traffic on that interface. The pings will come back through the loop and appear in the capture file. – Jeff Wheeler Dec 9 '20 at 13:02
  • 1
    You are absolutely right about ICMP ECHO_REQUEST. – NABEEL NASIR Dec 9 '20 at 13:40
2

You need to filter for Ethertype 0x8809 frames (for Slow Protocols) with subtype 0x01 (for LACP).

You need to run the capture on the physical interfaces, ie. xe. The aggregated, logical ae link doesn't carry those LACPDUs any more - they are consumed by the aggregation layer. See IEEE 802.1AX Clause 6.2.1: enter image description here

Note that problems with the DWDM scheme should show up on the physical link level.

6
  • We know that Ether-type for LACP is 0x8809 (slow protocol). We did try using this as filter in monitor traffic interface command but no success. We have no access to DWDM managment system. We can only see the protocol states at LACP level using cli. – NABEEL NASIR Dec 9 '20 at 11:51
  • You can't see the physical link states?? – Zac67 Dec 9 '20 at 15:11
  • The problem is not about physical states. Of course in case the link is physically down , we can see easily this at our side. What happens if LACP PDUs are not passing end to end making LAG non operational yet physical link is Up at both ends? How can we show to DWDM team that problem lies at their end? By sharing packet captures we can tell them that we are sending LACP PDUs but but receiving them so problem needs to be checked at DWDM side. – NABEEL NASIR Dec 12 '20 at 8:58
  • LACPDUs don't pass end-to-end. They pass between physical links. You need to use monitoring (SNMP, ....) to see the actual LAG trunk states. If LACPDUs are not received as expected the respective link falls out of the trunk after timeout. I think you should closely monitor each port's frame counters (FCS error and such). – Zac67 Dec 12 '20 at 9:22
  • If LACP PDU dont pass end to end , then how are we able to see same remote system-ID over each member link in a LAG when we run the command 'show lac interface ae0 extensive'? I didn't get your point. – NABEEL NASIR Dec 12 '20 at 12:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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