Ethernet over MPLS query about connecting cusomers

[Asemmoqbel]

Dear Beloved engineers,

direct to my question without longer intro, I'm trying to establish a l2vpn between customer sites via Etherent over mpls. we want to connect the customer A site with vlan tagged and customer B site with untagged vlan.

We tried to configure one side with vc type 4 using vlan mode and other side with type 5 etherent type but VC never comes up. I did a research on cisco threads and i found this note qutoed as below

(

• For a particular EoMPLS connection, both the ingress EoMPLS interface on the ingress PE and the egress EoMPLS interface on the egress PE have to be subinterfaces with dot1Q encapsulation or neither is a subinterface.)

is that means we can't mix connection VC between type 4 and type 5. if no, can you please provide other alternatives to meet our needs.

Thanks in advanced.

[Francesco Molino]

Hi.

Thanks for your rating.
from the xconnect where dot1q is tagged, you will see that in the mpls packet the frame is always tagged and when received by the other end on the mpls packet it is still tagged. When the packet is released the interface and it's an ethernet type, the tagged is removed.
Same thing the other way around except that this time the packet arrives untagged and then when it flows through the subinterfaces, the packet is tagged with the right vlan id.

Don't know if I explained it correctly.

Attached some wireshark captures, filter them on icmp. 192.168.10.10 is on CE1 and 192.168.10.20 is on CE2. Rename the file from txt to zip because I can't upload zip files

Here another explanation that I found very good and comprehensive: (it was made on this forum by a Cisco employee rsimoni):

VC Type 4 : The original 802.1Q tag is inserted in the EoMPLS payload (along with the MPLS label) before forwarding it to the MPLS core. At the ingress of the remote end or receiving PE the 802.1Q tag is stripped off before its transmission to the internal bus. If a packet is received from the MPLS core without a tag (ether type of the packet is other than 0x8100) the packet is dropped.

VC Type 5 : In EoMPLS VLAN mode configuration, only the MPLS label is added to the packet transmitted to the MPLS core. On the ingress of the remote end or receiving PE the MPLS label stack is popped out before the transmission on the internal bus. If Port mode is configured instead, the 802.1Q tag is also carried along with the MPLS label

The actions taken by the PE interfaces facing the CE are solely determined by the specific interface configuration. If such configuration requires 802.1Q tagging, the egress frame is tagged; otherwise the egress frame is sent untagged. EoMPLS VC type 5 is the default configuration mode on the platforms supporting it. Meaning that the PEs will try to first negotiate and use VC 5, if one of them (or both) does not support it they will reverse to VC 4. EoMPLS type VLAN offers backward compatibility in case the remote peer does not support VC type Ethernet.

[Asemmoqbel]

I wanted to confirm the functionality of our design and configured between CE1 and CE2 vlan with same subnet range or routed interface with same subnet range. both of that didn't work and didn't provide reachbility between CE1 and CE2 even though the vc is up and L2 vpn tunnel from provider side is working all good.

This proves that our design is not proper for real productive network and it's only for testing and playing. Also this confirm the notes given by cisco that states both of vc endpoint must be subinterface or neither is subinterface.

** For a particular EoMPLS connection, both the ingress EoMPLS interface on the ingress PE and the egress EoMPLS interface on the egress PE have to be subinterfaces with dot1Q encapsulation or neither is a subinterface **

[Francesco Molino]

Hi

For sure this isn't the best. If you can have the same design on both sides it would be better.
However, in production, sometimes you need to adapt and this kind of design is something you can do. I've done it several times.

Now, why your hosts aren't reachable, it maybe due to spanning-tree not managed correctly because you should have inconsistency issue due to 1 site in trunk and the other in access. You can handle that by disabling spanning-tree for this vlan it enable bpdufilter.... After that your port won't be anymore in blocked state and reachability between hosts will be fine.