We Love Tunnels Too - EoMPLS to Connect Two Data Centers

EoMPLS Proves to Be an Effective Way to Connect Two Data Centers

I wrote a blog a couple months back about my changing perception of tunnels, aptly titled "It's Time to Start Loving Tunnels". While I midly joked about tunnels in the past, it was becoming clear that tunnels are becoming a much more common - and proper - network design tool. Following my own advice, we actually used Ethernet-Over-MPLS (EoMPLS) recently to connect two data centers. Our problem was extending Internet access to the second data center from the first data center. The first data center has very large Internet circuits, but the new DMZ was going in the second data center. Enter EoMPLS to connect the two DCs together via 10 Gig WAN links which already connect the two DCs at Layer-3. Now Internet traffic enters the first DC and is tunneled to the other DC where the DMZ lives. As far as the firewalls in the DMZ are concerned, it's just a layer-2 hop away to the Internet routers even though it's hundreds of miles away. The configuration is rather simple. MPLS switching is enabled on the 10 Gig WAN links and an xconnect statement is applied to the interface which connects to the Internet switches.

interface TenGigabitEthernetX/X description 10 GIG WAN LINK mtu 9216 ip address [IP ADDRESS] load-interval 30 mpls label protocol ldp tag-switching ip end interface GigabitEthernetX/X description TO INTERNET ROUTERS mtu 9216 no ip address xconnect [IP Address] 100 encapsulation mpls end

Because of some code issues - we're running some "older" code on these 6500s - we ended up using static routes to advertise the xconnect addresses. This means a single EoMPLS tunnel won't fail over to the redundant 10 Gig should one of the 10 Gig WAN links fail. In this case, the EoMPLS tunnel goes down and RSTP moves traffic to the other EoMPLS tunnel on the redundant 10 Gig WAN link. Not perfect - particularly spanning-tree extension between two DCs - but the failover is quick and we have configured proper spanning-tree controls to protect ourselves. We'll move to dynamic routing protocols when we upgrade our 6500 code in the future. This has turned out to be a nice, innovative design that saved money and properly uses tunnels. Expect more of this. I already have plans for connecting the other data center.

BTW, I must give credit for this design to my lead engineer, Kamal. As the manager now, I can only take credit for the initial idea to use some kind of tunnel to solve this business problem of extending Internet access. He did the engineering work, lab testing, and deployment. He did a great job.

More >From the Field blog entries:

Positive ROI is What Made WAN Transformation Possible

Cisco's Dividend Announcement and a Little Corporate Finance Shows How Cisco is Changing

WAN Transformation is a Huge Project

WAN Transformation is a Go!

Cisco Unified Computing System is 75% Networking - Who Knew?

Congress Needs to Step In for Net Neutrality...Really? Seriously?

  Go to Cisco Subnet for more Cisco news, blogs, discussion forums, security alerts, book giveaways, and more.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2010 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)