L2VPN - port encapsulations - Null, 802.1q, Q-in-Q help

Post Reply
cloughy1
Member
Posts: 9
Joined: 12 Nov 2013 19:45

L2VPN - port encapsulations - Null, 802.1q, Q-in-Q help

Post by cloughy1 » 08 Oct 2017 14:14

In my job we have to troubleshoot L2VPN connection issues. One of the issues starts with 'wrong / incorrect' port encapsulation set up on the PE devices, at one end or the other or both ends. Im not sure why this would cause an issue and need it clear in my head - The port encapsulations that are available are: Null, dot1q or q-in-q. in simple english, which service does each provide and how do they work, why would they not work? Do certain combinations work each end or do they both have to be the same encaps both ends?

Do they work differently depending on what the customer is sending? i.e. no specific vlans, 1 vlan, many vlans

Sometimes frames dont reach the far end because of incorrect encpasulation on the PE port (s). I just need to know why this might be?

Any help appreciated

mivens
Member
Posts: 200
Joined: 28 Sep 2012 06:34

Re: L2VPN - port encapsulations - Null, 802.1q, Q-in-Q help

Post by mivens » 11 Oct 2017 15:47

On the subject of VLLs, here's a quote from the Layer 2 Services and EVPN Guide which may help you:
The spoke-SDP can be configured to process zero, one, or two VLAN tags as traffic is transmitted and received. In the transmit direction, VLAN tags are added to the frame being sent. In the received direction, VLAN tags are removed from the frame being received. This is analogous to the SAP operations on a null, dot1q, and QinQ SAP.

The system expects a symmetrical configuration with its peer; specifically, it expects to remove the same number of VLAN tags from received traffic as it adds to transmitted traffic. When removing VLAN tags from a spoke-SDP, the system attempts to remove the configured number of VLAN tags. If fewer tags are found, the system removes the VLAN tags found and forwards the resulting packet. Because some of the related configuration parameters are local and not communicated in the signaling plane, an asymmetrical behavior cannot always be detected and so cannot be blocked. With an asymmetrical behavior, a protocol extraction will not necessarily function as it would with a symmetrical configuration, resulting in an unexpected operation.

Post Reply

Return to “7750 SR”