Ethernet Switching
Ethernet Switching

layer2-protocol-tunneling lacp Decapsulation does not work on EX4500

‎01-18-2020 06:40 PM

Hi

 

I have an issue where LACP traffic is being punted to the route processor on EX4500 even though layer2-protocol-tunneling has been enabled on the relevant VLAN. I have tried this with the trunk port having only the tunneled VLAN, a combination of tunneled and untunneled VLANs or all tunneled VLANS. The issue is the same:

 

Model: ex4500-40f

Junos: 14.1X53-D49.1

 

I have the following configuration which enables dot1q tunneling.

 

vl267 {

    vlan-id 267;                        

}

vl400 {

    vlan-id 400;

    dot1q-tunneling {

        layer2-protocol-tunneling {

            all;

         }

    }

}

 

I have the following configuration facing the carrier PE/NNI:

 

show interfaces xe-0/0/37 

mtu 1552;

unit 0 {

    family ethernet-switching {

        port-mode trunk;

        vlan {

            members [ vl400 vl267 ]

        }

    }

}

 

> monitor traffice interface xe-0/0/37 no-resolve layer2-headers

Listening on xe-0/0/37, capture size 96 bytes

21:26:43.176559  In 20:x:x:x:x:x > 01:80:c2:00:00:02, ethertype 802.1Q (0x8100), length 74: vlan 400, p 0, ethertype Slow Protocols, LACPv1, length 56

 

As you can see, the LACP packet is being punted to the route processor because otherwise it would not be seen in monitor traffic output. I do not see any LACP packets turn up on access or trunk interfaces on the same VLAN which means it is being consumed by the control plane and not forwarded. I have also confirmed this with an analyzer port.

 

> show ethernet-switching layer2-protocol-tunneling statistics vlan 400

...

vl400 xe-0/0/37.0 lacp      Decapsulation   0          0          0        

 

Clearly there LACP packets being received above. If I add another UNI/CE access port to the vlan stanza configuration and I configure the CE device to generate LACP traffic, I can see it encapsulating the LACP ports:

vl400 ge-0/0/10.0 lacp      Encapsulation   5217       0          0   

 

Clearly, the VLAN is configured correctly. The issue is the ingress (Decapsulation) traffic.

 

Have I missed something configuration wise?

 

Thanks

 

 

 

6 REPLIES 6
Ethernet Switching

Re: layer2-protocol-tunneling lacp Decapsulation does not work on EX4500

‎01-18-2020 08:06 PM

Hello

 

Are you using the following in your configuration

 

root# show ethernet-switching-options

dot1q-tunneling {

    ether-type 0x8100;

}

 

You may refer the below article for any configuration that might have been missed

 

https://kb-im.juniper.net/InfoManager/WebObjects/InfoManager.woa/wo/1.2.1.30.3.1

 

 

Ethernet Switching

Re: layer2-protocol-tunneling lacp Decapsulation does not work on EX4500

[ Edited ]
‎01-18-2020 10:38 PM

Yes, I am. The configuration will not apply otherwise.

 

> show configuration ethernet-switching-options 

dot1q-tunneling {

    ether-type 0x8100;

}

storm-control {

    interface all;

}

 

I have already looked through that link before posting. I'm confident my configuraiton is as per the documentation. The issue is pretty simple, the EX4500 punts the LACP to the route processor/control plane for no apparent reason. I have also tried Junos: 15.1R7-S5.1 and the problem still exists.

 

 

 

Ethernet Switching

Re: layer2-protocol-tunneling lacp Decapsulation does not work on EX4500

a month ago

If the configuration is correct on both PE switches then i would suggest to try the following:

1. Try to change the ether type to 0x9100

2. Try to configure the native-vlan-id on the trunk interface and check if that helps

Ethernet Switching

Re: layer2-protocol-tunneling lacp Decapsulation does not work on EX4500

a month ago

Firstly, the ethertype of the incoming packet is 0x8100, I cannot change it. Further, I can't mix different ethertypes on one trunk interface. Secondly, it's coming on a trunk and there are several such VLANs. Accordingly, the native-vlan-id is of no assistance to me.

 

 

 

Ethernet Switching

Re: layer2-protocol-tunneling lacp Decapsulation does not work on EX4500

a month ago

When you say this is not working on EX4500 (old product BTW), are there other Juniper platforms you have tried same thing with and these work as desired? is there some other vendor product that provides this support.

 

For this VLAN, this is a single tagged frame, that has LACP packets inside it?  As far as I know, LACP is point-to-point, and therefore should not pass through intermediate switches.  In past life at Nortel, we developed proprietary function that was called VLACP, that allowed LACP to pass through intermediate switches and be end-to-end, vs point-to-point.  I am not sure is any other vendors ever implemented such a solution, and I am fairly certain Juniper has not.

 

I would not expect this to work with any Juniper product.

 

My 2 cents worth.

Ethernet Switching

Re: layer2-protocol-tunneling lacp Decapsulation does not work on EX4500

4 weeks ago

It doesn't work on the QFX5100, SRX345 or the EX4500. It does however work on the EX4200. While LACP inside an Ethernet frame might seem strange to you, it's actually a valid MEF (Metro Ethernet Forum) use case where you deliver an eLine from one point to another and you encapsulate the Ethernet frames and deliver it over a trunk. This might explain why, when I checked, the EX4200 and EX4550 has some MEF certification but the EX4500 does not.  This use case also works with the Juniper MX line. I believe all of the Cisco ASR platform as well as the old ME platform support this type of encapsulation.

 

However, the issue is that the Juniper online documentation is misleading and deceptive. The EX4500 simply does not support dot1q-tunneling of LACP.  You can enter the command, it doesn't complain, but it doesn't work. The LACP packets get punted to the control plane.