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 (1.1.1.1 and 2.2.2.2 below) are needed.
| Switch swA config: |
| interface GigabitEthernet4/1 switchport 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 1.1.1.1 200 encapsulation mpls end |
| Switch swC config: |
| interface GigabitEthernet2/2 switchport 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 2.2.2.2 200 encapsulation mpls end |
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.
Recommendations
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.
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.
Draft-Martini refers to the pseudo-wire encapsulation. See for instance [url]http://en.wikipedia.org/wiki/Martini_draft[/url]. For VPLS and Kompella, see [url]http://www.cisco.com/application/pdf/en/us/guest/tech/tk891/c1482/ccmigration_09186a00801ed507.pdf[/url]. There’s an article at [url]http://www.netcraftsmen.net/resources/archived-articles/437.html[/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.
Could it be possible to do a dot1q tunnel in the 6500 and send it through an EoMPLS pseudowire?
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.
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.
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.
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.)