The trouble with MPLS

12.03.2007
Multisite and outsourced IT operations are making good use of Multiprotocol Label Switching (MPLS), but strange trouble is turning up more and more. Often in discussion with local network staffers, we come to the point when I ask about backhaul lines or internet service providers over which they presumably run a site-to-site virtual private network (VPN). They happily reply, "Oh, we have MPLS" and provide a network diagram consisting of a suitably inscrutable cloud.

Life is not so simple. Increasingly, those IT infrastructures appear functional, but a simple scan turns up many times the number of hosts that ought to be visible. Finding rogue devices on a network is cause for a bit of alarm, but unknown subnets?

What's going on? MPLS is supposed to simplify wide-area networking with carrier-grade service, not increase the risks of exposing sensitive data. Finding one's network cross-connected with another organization is not something that can be dealt with tomorrow, and a serious address-space collision can put networks completely out of commission.

IT managers and technologists looking for a simple way to connect distant LANs turn to MPLS as a solution that has more currency and expandability than older offerings. The trouble is many of them make the decision to adopt MPLS without enough information.

Blue car, yellow car

As its name implies, MPLS embeds network switching or routing information into lower network layers. Like frame relay, it allows low-latency transit of network traffic between two distant points but leaves error handling up to the endpoints. Like asynchronous transfer mode, it embeds transit information into lower network layers, but the variable-length packets of MPLS are more suited for encapsulating IP traffic than ATM's fixed-length cells.