4

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 !

Improve this question
1
  • Did any answer help you? if so, you should accept the answer so that the question does not keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin ♦
    Dec 23, 2021 at 15:30

2 Answers 2

Reset to default
6

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.

Improve this answer
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
    Dec 9, 2020 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
    Dec 9, 2020 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, 2020 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, 2020 at 13:02
  • 1
    You are absolutely right about ICMP ECHO_REQUEST.
    – Nabeel
    Dec 9, 2020 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.

Improve this answer
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
    Dec 9, 2020 at 11:51
  • You can't see the physical link states??
    – Zac67 ♦
    Dec 9, 2020 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
    Dec 12, 2020 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 LAG after timeout. I think you should closely monitor each port's frame counters (FCS error and such).
    – Zac67 ♦
    Dec 12, 2020 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
    Dec 12, 2020 at 12:23

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.

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