Working with EoMPLS Part 2

Peter Welcher
Architect, Operations Technical Advisor

A previous article took a look at Port-Based EoMPLS on a 6500. In particular, the MTU and LDP (MPLS label protocol) setup is discussed there. It is not repeated with the configlets below.

In that blog, we discovered that setting up port-based EoMPLS is darn easy. So easy that the danger is creating mounds of L2 spaghetti on top of your robust L3 routed network. (Yes I’ve had dinner, there’s no food craving at work here!)

This blog is a quick follow-up to that blog. It posts tested configlets for VLAN-based EoMPLS. I recently did some VLAN-based EoMPLS in the lab using dot1q subinterfaces on a 7200 router using GNS3 / Dynamips. The configuration is nearly identical.

Sidetrack note: I’ve been looking at CEF and GLBP based load balancing routing configurations for a situation where a company may have dual L3 or L2 MPLS VPN carriers. I had a little fun while doing that with GNS3 and Dynamips, by putting in a small EoMPLS or L3 MPLS VPN for each of the two carriers. The carriers had to be rather minimal ones: two PE routers and one P router for each carrier. That’s because running 10 routers doing MPLS and MBGP stresses  my 3 year old laptop to the limit. (Yes, it’s coming up on time for a new one — waiting to see if Apple announces a tablet, and if so what its capabilities are.)

(Tip: using GNS3, it is easy to stop half the routers, and configure and test each provider side at a time, before testing how it all works together.)

VLAN-Based EoMPLS on a 6500

Update, 1/5/2010: It’s been suggested that I provide a picture. Indeed, I’d have liked to, but time has been a bit tight.

The picture is darn simple: swA, links/cloud, swC.

I’ve also been asked for the configs for what’s in between. However, that would just obscure the simplicity — the links in between need IP routing and “mpls ip” enabled on them (and preferably on alternate paths as well). And the interface MTU cranked up / jumbos, I’ve been using the biggest number allowed.

Here are representative configurations for two 6500’s running EoMPLS using OSPF routing and LDP on the paths between the endpoint switches. Really, only routes between the loopback addresses ( and below) are needed.

Switch swA config:
interface GigabitEthernet4/1
 switchport access vlan 108
 switchport trunk encapsulation dot1q
 switchport mode trunk
 mtu 9216
 spanning-tree portfast trunk
interface GigabitEthernet4/1.200
 encapsulation dot1Q 200
 xconnect 200 encapsulation mpls
Switch swC config:
interface GigabitEthernet2/2
 switchport access vlan 108
 switchport trunk encapsulation dot1q
 switchport mode trunk
 mtu 9216
 spanning-tree portfast trunk
interface GigabitEthernet2/2.200
 encapsulation dot1Q 200
 xconnect 200 encapsulation mpls

Once the overall port MTU was correct, the VLAN-based xconnect came up. (That’s why I show it in the above configlets.)

Note that this does NOT locally switch VLAN 200 into the xconnect when configured on a switch. It takes incoming frames tagged with VLAN 200 dot1q tagging and forwards them to the port at the other end, with relevant VLAN tagging. Connecting the physical port back to the switch, with trunking and appropriate VLAN tagging, is required to obtain local switching. This is similar to what was observed for port-based xconnect, but requires more configuration.

Not tried

I haven’t tried port-based EoMPLS on a 7200 router. Or rather, I tried hastily in GNS3, didn’t see the command options I expected, and shifted to VLAN-based since that worked for what I needed to do. I did a quick Google search for configuration for port-based EoMPLS in router IOS, and I’m not seeing anything obvious as an example, so I’m kind of curious to see if it can be done. Of course, one can use QinQ on a switch to feed tagged frames into a VLAN-based EoMPLS pseudo-wire, but that’s not a very direct way to get the job done.

Update, 1/5/2010: Per CNC’s Luan Nguyen (and his CCIE SP prep), port-based EoMPLS on 7200 is easy: just put the xconnect on the main interface. I had tried that, but it was apparently not supported in the images I tried. (“xconnect … encaps mpls” was not an option). I tried again with a 15.0 image for the 7200 and it worked. I still claim that this is not documented, or at least I sure didn’t find it explicitly shown in the IOS docs, nor in the examples Google found for me. (Or I was having prolonged blindness to what was in front of me?) So that’s darn easy, and thanks to Luan.

I also haven’t lab-tested doing port-based EoMPLS with different VLAN-based pseudo-wires going to different destinations. On the other hand, it’s clear how to configure that, and I have no reason to expect it to not work.


When in doubt, consider using port-based xconnect, it requires less configuration on the endpoints.

Use VLAN-based EoMPLS if you want the VLANs to act sort of like Frame Relay DLCI’s, with different VLANs going to different other endpoints.

7 responses to “Working with EoMPLS Part 2

  1. Good passage. I have a question, what’s the relation between l2 martini vpn and EoMpls,and vpls? I did quick google search using martini as key word, but only to get few results.

  2. Draft-Martini refers to the pseudo-wire encapsulation. See for instance [url][/url]. For VPLS and Kompella, see [url][/url]. There’s an article at [url][/url] that might also shed more light on this. (I happen to like the author’s writing :)). There are two signaling approaches that can be used to set up one (or many) pseudo-wire or EoMPLS connections.

  3. Could it be possible to do a dot1q tunnel in the 6500 and send it through an EoMPLS pseudowire?

  4. EoMPLS is pretty much transparent, with a lot of high-level similarity to QinQ. That is, a frame goes in a port on the switch configured for tunneling, it gets encapsulated and tunneled to the other end. OK, QinQ does get switched just like ordinary frames, rather than encapsulated and send via a LDP path, that’s different. Similarly, native VLAN handling and so-on differ some.

    So if you do QinQ before EoMPLS, it goes over EoMPLS with the double dot1q encapsulation as is. Of course, you might use up ports on one or more switches doing that (one for QinQ, then out another via cabling to feed it back into the EoMPLS port…). Do that one per QinQ "customer" and I suspect you’d find the hardware for VPLS more attractive in terms of cabling ugliness and cost.

  5. If your loopback ports are doing BPDUguard, they’ll probably errdisable on you, taking EoMPLS down. You need "switchport bpduguard disable" — the global default may be to enable bpduguard, in which case "no switchport bpduguard enable" doesn’t do the job.

    Second item: as with MPLS VPN, you cannot be summarizing the address blocks your loopback addresses come from, for the loopbacks you’re doing EoMPLS with. For an OSPF design, we usually pick loopbacks that will summarize with buildings or areas. For an MPLS design, the PE loopbacks usually come from a separate prefix block, chosen so as to be easily NOT summarized. The symptom is obscure: your EoMPLS will come up, but you won’t be able to ping something via the EoMPLS link.

  6. I configured some EoMPLS pseudowires about 5 years back, and none of the above was true. Did they push the encapsulation to the ingress DFC? It required that I use the Ethernet WAN card on the uplink to get the Ethernet frame into the MPLS frame. On the other side we used the ME3750, which does support MPLS and EoMPLS specifically. Sorry to rehash an old post, but I had heard of people doing EoMPLS on the 6500 platform, and it really didn’t mesh with my past experience on this box, and it would be good to get some confirmation that it actually works now.

  7. I’ve done it. You want a Sup 720 PFC 3B and DFC3B or better cards for hardware MPLS (and software MPLS is not supported by Cisco).

    I recently ran across a site doing N7K-based VPC port-channel using paired 6500’s for two EoMPLS links between sites. (Subject of future blog.) Cisco Advanced Services built it that way at a time when the OTV code was not there. (And it’s still a bit early days for OTV in terms of maturity.)

Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.