When should companies consider building MPLS networks into their WANs?

Learn when corporations should consider building Multiprotocol Label Switching (MPLS) networks into their enterprise wide area networks (WANs) in this tip.

Many IT network architects are afraid to use unknown and notoriously complex technologies like Multiprotocol Label

Switching (MPLS) -- and with good reason. Ask an enterprise network designer about building an MPLS network for their enterprise WAN and they’ll probably reply, “Isn’t that a service provider technology? Why should I use MPLS in my enterprise network?” They would be  right to question this. This is because MPLS VPNs were developed to help service providers offer scalable IP-based VPN networks. However, as enterprise IT evolves from traditional cost-center departments into service-driven private cloud organizations, IT departments are becoming de facto service providers by offering multi-tenant services to their clients -- whether those clients are from external organizations or various departments in their own company.

In order to isolate users within a campus or servers within a data center, it's quite common to create Layer2 virtual LANs (VLANs). Data center designers also use virtual routing and forwarding tables (VRFs) -- one of the MPLS VPN cornerstone technologies -- to insert firewalls and load balancers between servers and the outside world. Maybe it’s time to consider going all the way and deploying isolated Layer3 domains across your entire network.

When should enterprises consider building MPLS networks?

Whenever you have to split your users into various security-based groups and keep their traffic isolated as it crosses the enterprise WAN infrastructure, you’re a potential candidate for an enterprise-wide MPLS VPN deployment. The following scenarios are quite common and will benefited from an MPLS network:

High-security departments. Some organizations have departments that have to be kept separate from the rest of the enterprise. Other organizations would like to keep traditional corporate functions -- i.e., marketing, finance, production, R&D -- well, separate. In both cases, you have to keep the groups of users isolated, even when their traffic crosses the WAN. Keeping their traffic separated in a campus network is easilyaccomplished using VLANs.

Some designers have tried to solve this problem with traffic filters (i.e., access lists) limiting inter-group connectivity, but access lists are hard to maintain in an ever-evolving, fast-changing enterprise network.

Ministries and other governmental institutions. This is a special case of high-security departments. Some governments have even tighter security requirements than most enterprises, and even more so if mission-critical ministries, like Finance, Interior or Defense, share the WAN backbone with others.

Guest Internet access. Many organizations connect to the Internet through a central firewall. A lot of them have to provide guest Internet access -- i.e., with a guest Wi-Fi VLAN -- at multiple locations. Needless to say, the guest Internet traffic has to be kept strictly separate from the internal enterprise traffic.

Outsourced services infrastructure. Most businesses are trying to reduce their costs by outsourcing non-core services. Sometimes the organizations providing the outsourced services need IP-based access to numerous locations within your organization, and it’s most efficient to provide them with isolated transit across your IP backbone.

Examples of outsourced service infrastructures/technologies that include WANs:

  • Video surveillance with web cameras.
  • IP-based ATM machines (cash dispensers) operated by a third party.

NAC separation. Some security-conscious organizations use Network Access Control (NAC) to assign LAN or WiFi users to individual VLANs based on the security posture assessment. In some cases, these users have to be kept separate as their traffic traverses the enterprise WAN.

Continue reading part two of this tip on how to integrate MPLS VPNs into your WAN, or continue on to part three: Troubleshooting MPLS WAN services: VPLS, pseudowires, and Layer-3 VPNs.

About the author:
Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks. He is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and Web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. Check out his IOS Hints blog.

This was first published in November 2010

Dig deeper on WAN protocols

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchNetworking

SearchUnifiedCommunications

SearchTelecom

SearchSDN

Close