MPLS in the Enterprise

I knew it. I have been talking about it from the past 2 years.
It’s coming. I knew it, and it’s coming.

When people talk about MPLS, they always associate it with Service Provider. By adding label to the packet between layer 2 and layer 3, MPLS can provide so many services such as Layer 3 VPN, Layer 2 VPN, Traffic Engineering and so on.

Why Enterprise customers need MPLS?
MPLS was invented originally to optimize and increase the switching performance by not doing Layer 3 lookup, but MPLS label lookup instead. Nowadays switching performance in network device has been increased and it is equal for either Layer 3 lookup or layer 2 lookup. So increasing the performance is not the answer we are looking for.

Okay, it’s really good to consolidate ATM backbone and Frame-Relay backbone into single IP infrastructure with Layer 2 VPN. But which Enterprise customer maintains the physical layer for its backbone? And forget about Traffic Engineering for time being.

The most applicable MPLS service for Enterprise is: Layer 3 VPN. But wait, why in single Enterprise network you need to run MPLS L3 VPN?

Well, the answer is obvious if you have any third party vendors or consultants working in several places in your network. You want them to use your network transparently: they can connect to each other but they can’t see your infrastructure. MPLS L3 VPN is the answer.

Now I want to push it even further. I have one project to build big campus network, with core, distribution, and access switches topology. And the users are divided into several departments. The policy from my customer: within one department, regardless of the physical location, users should be able to connect to each other. But they should not be able to connect to any other departments. And all of them share the same data center, and share the same Internet connection.

I have two options for this: put Access Control List (ACL) in any distribution switches or the gateways. This is the most common option that any Network Engineers would choose. The second option is to have VPN within each department so they will not be able to communicate to each other. VPN can be provided with normal GRE tunnel, IPSec, and.. MPLS.
Compare to the other two, MPLS configuration is easier and more fit to address the above requirement.

The MPLS cloud will start from distribution switches. So at minimum, distribution should run hardware that can support MPLS. From Cisco this can be Catalyst 6500 series with Supervisor 720-3B. We can terminate each VPN into the firewall, one VRF for one VLAN connected to the firewall. With this way, we can have all the MPLS VPN connected to firewall as DMZ. Later on, if it’s required to provide specific access between VPN, all the connection can be inspected and filtered through the firewall.

Things get interesting if you want to extend MPLS to the access switches. Cisco encourages to have Routing terminated into the access nowadays, to eliminate the requirement of Spanning-Tree Protocol and HSRP. If we can run routing in access switches, the gateway for all users will be the access switch itself. No STP and HSRP required. And to extend MPLS to the access, we need to have VRF-Lite feature to bind each user VLAN to dedicated uplink to Distribution switches. In distribution switches, each uplink from access switch will be placed into designated VRF.

So it’s coming, everyone. MPLS is already here, and it’s inevitable.
All Enterprise customers hear me now: MPLS time has come.