MPLS – EoM (Ethernet over MPLS) deeper review, attempted configuration, never worked with it before but lets give it a go!

I’ve added a couple of Routers to my current MPLS Lab, as the concept to my understanding is that with minor configuration on the PE / CE devices, it should just use the MPLS Network for Transport and that will be that!

I have no training material or instructor led training on this, so this will be completely freestyle, and if this ends up not working or running into weird quirks the lab might end up with an unfortunate “Well that didn’t work.” Not ideal, but worth a try!

Ethernet over MPLS Review

Being a variation of AToM, EoM is the process of encapsulating an Ethernet Frame in an MPLS Packet to be Label Switched across the MPLS Network, arriving at the other end as an Ethernet frame by one of two methods:

• VLAN Mode – Uses dot1q tagging to define the SRC and DST VLAN on both sides
• Port mode – Uses a common Port shared between Endpoints to use a single VC

I will only be attempting a configuration of VLAN Mode EoM on this lab, as any working configuration of EoM is a win for me, and the whole Virtual Circuit (VC) terminology / technology rabbit hole runs deep with info that could consume me for days.

Lets give configuration of EoM a try!

I am actually using a Cisco white paper for a Catalyst 6500 for EoMPLS found here which I am going to try to apply to a 7200 sub-interface, because Layer 2 images are lacking for Emulators at this time.

EoM1

EoM1(config)#int fa0/0.100
EoM1(config-subif)#encap dot1q 100
EoM1(config-subif)#ip add 10.10.100.1 255.255.255.0
EoM1(config-subif)#no shut
EoM1(config-subif)#int fa0/0
EoM1(config-if)#no shut
EoM1(config-if)#
*Dec 13 04:45:13.559: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Dec 13 04:45:14.559: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
EoM1(config-if)#

I assume this is correct, as the “xconnect …” configuration seems like it should only be on the PE and defining the CE’s IP / VLAN #, while the CE should be configured as normal.

R1-PE (Connected to EoM1)

R1-PE(config)#int fa3/0.100
R1-PE(config-subif)#encap dot1q 100
R1-PE(config-subif)#xconnect 10.10.100.1 100 encap mpls
R1-PE(config-subif-xconn)#
*Dec 13 04:38:30.663: %LINEPROTO-5-UPDOWN: Line protocol on Interface pseudowire0, changed state to up
R1-PE(config-subif-xconn)#no shut
R1-PE(config-subif)#

Sooooo, now we have two “Psuedowire0” Interfaces that have come up on the left hand side of the MPLS network, apparently you apply the exact same thing on the remote side and everything lights up?

Lets find out!

EoM2

EoM2(config-line)#int fa0/0.100
EoM2(config-subif)#encap dot1q 100
EoM2(config-subif)#ip add 10.10.100.2 255.255.255.0
EoM2(config-subif)#no shut
EoM2(config-subif)#int fa0/0
EoM2(config-if)#no shut
EoM2(config-if)#
*Dec 13 04:47:30.203: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Dec 13 04:47:31.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
EoM2(config-if)#

R5-PE (Connecting to EoM2)

R5-PE(config)#int fa3/0.100
R5-PE(config-subif)#encap dot1q 100
R5-PE(config-subif)#xconnect 10.10.100.2 100 encap mpls
R5-PE(config-subif-xconn)#
*Dec 13 04:43:14.839: %LINEPROTO-5-UPDOWN: Line protocol on Interface pseudowire0, changed state to up
R5-PE(config-subif-xconn)#no shut
R5-PE(config-subif)#

With everything in place, I dare say we try a ping test, and see if we have succeeded:

EoM1(config-if)#do ping 10.10.100.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.100.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
EoM1(config-if)#

And we did not, and I am thinking the issue is that the xconnect statement should be pointing at the remote / peer router, and not the local:

R1-PE(config-subif)#no xconnect 10.10.100.1 100 encap mpls
R1-PE(config-subif)#xconnect 10.10.100.2 100 encap mpls
R1-PE(config-subif-xconn)#exit
R1-PE(config-subif)#

R5-PE(config-subif)#no xconnect 10.10.100.2 100 encap mpls
R5-PE(config-subif)#xconnect 10.10.100.1 100 encap mpls
R5-PE(config-subif-xconn)#exit
R5-PE(config-subif)#

Trying to perform some verification on this connection

It apparently should show up in the MPLS LFIB:

R1-PE(config-subif)#do sh mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
100 Pop Label 2.2.2.2/32 0 Fa0/0 10.12.0.2
101 Pop Label 10.23.0.0/24 0 Fa0/0 10.12.0.2
102 201 5.5.5.5/32 0 Fa0/0 10.12.0.2
103 202 4.4.4.4/32 0 Fa0/0 10.12.0.2
104 203 3.3.3.3/32 0 Fa0/0 10.12.0.2
105 204 10.45.0.0/24 0 Fa0/0 10.12.0.2
106 205 10.34.0.0/24 0 Fa0/0 10.12.0.2
107 No Label 172.16.101.0/30[V] \
0 aggregate/101:Looped
108 No Label 172.16.101.0/30[V] \
0 aggregate/102:Back
109 No Label 172.16.222.2/32[V] \
0 Fa2/0 172.16.101.2
R1-PE(config-subif)#

Which there is no 10.10.100.0/24 entry in the LFIB, and the final nail in the coffin of me believing this might be yet another Layer 2 limitation of Emulators:

R5-PE#sh vlan ?
% Unrecognized command
R5-PE#

So I am unable to even verify that VLAN 100 is active on this PE device, and am unable to manually add the VLAN from Global Configuration:

R5-PE(config)#vlan ?
accounting VLAN accounting configuration

R5-PE(config)#

So that kind of stops me dead in my tracks as far as labbing this goes, which is a shame as I felt I was on the correct path there, but of course Layer 2 and Emulators just stinks.

That will conclude my look at Layer 2 EoM for MPLS

I wanted to explore this topic to the limitations of my lab which are unfortunately quite immediate at Layer 2, however I think the concepts covered here give a fairly good overview of the technology and configuration, so I am happy with it 🙂

Until next time!