Cisco Subnet An independent Cisco community View more

It's Time to Start Loving Tunnels

Cisco is Using Tunnels More and More to Solve Routing and Switching Design Problems

I wrote a blog two years ago about how I could fix anything with a tunnel. Yes, it was a tad tongue in cheek, but it also had some truth to it. Tunnels are a weapon to use when faced with a difficult network design issue. However, as with any weapon, there can be collateral damage. Tunnels have proven to sometimes cost more than they are worth when they introduce sub-optimal routing, MTU issues, and hardware/software scalability issues. Given these problems, most network engineers shied away from tunnels. They were to be used if necessary, but very carefully. Sort of like cruise missiles - very effective when used right, but be very careful to hit the right target. Things are changing though. Just as "smart bombs" can use GPS to hit within 10 meters of a target, tunnels are getting smarter too. Cisco is using them more and more to solve networking problems, even if you don't realize it.

Some of you may argue with me that a couple of the examples I use below are not "tunnels" they are "encapsulation" protocols. Ok, yes, it doesn't create a "Tunnel0" interface on the router, but it's still a tunnel. Works the same way as GRE would.

Many of you might have heard the hype growing about LISP. It got a lot of attention and sessions at Cisco Live. I have my own thoughts on LISP (which I'll share in a future blog), but it's a big user of tunnels. Picture your Internet packets being encased in a LISP packet, routed to a remote LISP end-point across the Internet, then decapsulated and routed to the destination. It's a tunnel. Cisco's Overlay Transport Virtualization (OTV) is another technology using tunnels. It uses intelligence in the Nexus 7000s to properly extend L2 domains between remote data centers over any L3 backbone. Some idea. Take a L2 data center frame, encap it, ship it over the WAN, decap and deliver. It's a tunnel. Some very large enterprises are already building and running their own MPLS backbones today. Financial services, multinational corporations, and governments are buying bandwidth from carriers, but then using it to build their own MPLS backbones. IP VPNs, VPLS, AToM can then be designed, deployed, and used by the organizations themselves, not relying on a service provider. However, most enterprises do not build and run their own MPLS backbones today, they buy IP VPNs from MPLS service providers, like Verizon. But, things are changing. As more complex R&S solutions are needed by normal size enterprises, Cisco is creating ways for these organizations to build their own MPLS backbones. The newest way, which I learned about at Cisco Live, is MPLS over mGRE tunnels. Hell, that's tunnels over a tunnel! There's also a good whitepaper on Deploying MPLS VPNs in Tunnel Environments (non mGRE). You can use any L3 transport - including IP VPNs from carrier-based MPLS providers (like Verizon and AT&T) - and build your own MPLS network on top of it using the tunnels. No LDP needed with the carriers. It all runs over the GRE tunnels. The moral of the story here is to start seeing tunnels in a different way. They will become more and more a part of your networks in the near future (even if you don't know it like with OTV). Tunnels are just a tool that have gotten much smarter in the recent years - just like smart bombs.

More >From the Field blog entries:

Special Cisco Live Contest - Hottest Booth Girl

Best Sign at Cisco Live

Our Cisco Live Certification Gift

CCDE Recertified!

Cisco Live 2010 Wireless Performance

I'm at Cisco Networkers 2010

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

Join the discussion
Be the first to comment on this article. Our Commenting Policies