Troubles with MPLS a sign of hidden complexity

Rogue networks can result if the technology ins't used carefully, says Jon Espenschield

Multi-site 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 ISPs 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 organisation 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.

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.

By labelling traffic at a lower network level, less processing has to happen at each waypoint between source and destination. It’s analogous to colour-coding cars on the highway and allowing only blue cars to enter at the Los Angeles on-ramp and exit at San Francisco and vice versa. Yellow cars might share the same road from San Diego to Santa Barbara, but they would enter or exit only on ramps flagged for yellow cars.

The transit speed is unchanged — MPLS doesn’t make a 10Mbit/s link go to 11Mbit/s — but the entry, routing and exit decisions can be made much more simply and quickly. To send someone to San Francisco, you could give them a blue car, and the network (the road) would get him there without needing to get on and off the highway to ask for directions.

The devil’s in the detail. The RFC 3031 standard defines MPLS, but it takes a subsequent half-dozen requests for comments to cover the more drowsy topics of label distribution, handling, application and interfaces with other networks. MPLS configuration is, to quote Cisco strategist and customer liaison executive Azhar Sayeed, expensive and tedious, which is why the technology has been the domain of carriers for the better part of a decade.

It’s misleading, then, when uninformed LAN administrators think an MPLS connection “just works”. Simply plugging two network endpoints into a carrier’s MPLS cloud may allow those networks to communicate, but without some attention, anyone else connected to the cloud may also be visible.

It’s not that organisations shouldn’t play with big kids’ toys, but they need to be aware of their complexity.

Anyone in the market ought to consider at least these three simple precautions when MPLS is in play:

Firstly, ensure that responsibility for network traffic labeling is assigned. This means more than watching as the carrier’s sales rep nods and says it’s handled. Just as access control lists between internal VLANs are necessary for meaningful segmentation, someone needs to define label assignment and distribution rules before data is forked over to the MPLS cloud.

Second, the contract or service-level agreement should include a description of suitability, not just performance metrics for the connection. This means the usual contractual disclaimer “We’re not responsible for how you use this connection” ought to be extended or replaced with a bounding statement such as “suitable for the requirements specified in Exhibit A.” That exhibit defines whether the endpoints are connected to VPN routers or a pile of unsegmented network spaghetti.

Finally, know what the options are for MPLS traffic engineering. Your situation may call for a dedicated MPLS cloud, heterogeneous options or another service altogether. Knowing your choices is the first step toward making a good one.

Join the newsletter!

Error: Please check your email address.

Tags mplsNetworking & Telecomms IDcomplexity

Show Comments