MPLS VPNs for Enterprise Networks
Multi-protocol label switching (MPLS) technologies are becoming more prevalent in enterprise networks, replacing the traditional frame-Relay and asynchronous transfer mode (ATM) networks. There are primarily four reasons corporations look toward this solution. They are reduced cost, greater bandwidth efficiencies, reduced configuration complexity and having the ability to provide “any-to-any” communications because the MPLS protocol is media independent.
Service providers are able to reduce the cost of a typical enterprise wide area network (WAN) because there are no end-to-end permanent virtual circuits (PVCs) that are required. In addition to these benefits, some service providers are offering different types of managed services (i.e. Internet, VPN, etc.) to further reduce the customers’ in-house operation support requirements. These services are meant to reduce operating costs and increase availability and stability.
The Enterprise MPLS VPN Architecture
The architecture of a typical enterprise MPLS VPN is very simple. Enterprise network administrators should look at their MPLS VPN WAN as private-IP network. With that mindset, the backbone consists of provider (P) routers, which are the core of the MPLS network that connect all of the provider edge (PE) routers together. The P routers should be viewed as transparent because typically they are not perceived as part of the network. However, the PE routers directly interface with the customer network. Each PE router handles a number of customer MPLS VPNs.
At each of the customer’s remote sites there is a customer rdge (CE) router that connects to the PE router using some Layer 2 protocol such as frame relay, PPP (Point-to-Point Protocol) or ATM. Frame relay and PPP are preferred because of the minor protocol overhead required to function.
The service provider creates a network-wide MPLS VPN ID for a customer and then configures a port for the PE router to connect to the CE router. This MPLS VPN ID is unique to the network, so there is no Layer 3 visibility from one customer’s MPLS VPN to another.
The biggest misconception about a MPLS VPN is that the CE router must support MPLS. This CE router is treated like any other enterprise WAN router. Traditionally, the WAN interface on the router is configured with a frame relay or ATM PVC, and the remote IP address for that interface is on the head-end router. In this case, the remote IP address for that interface is the egress interface on the PE router. This is how the “any-to-any” communications take place.
Routing in a MPLS VPN WAN
MPLS is a Layer 3 technology, so all communications from site-to-site use some form of routing. Service providers typically give the customer three options: border gateway protocol (BGP), open shortest path first (OSPF) or static routing. It is important to note that some providers are starting to support enhanced interior gateway routing protocol (EIGRP), but the greater customer base will select a standards-based routing protocol for their network.
A typical enterprise network consists of a head-end hub site, usually the headquarters and any number of remote WAN sites. The head-end site would exist where the company services reside to include connectivity to the Internet, e-mail and other services provided to the remote sites.
For example, a head-end site will use the IP address range of 10.1.0.0/21, where the remote sites each have a /23 IP address range in the 10.2.0.0/16 network. Each of the WAN circuits between CE and PE routers have a /30 network, which are assigned by the service provider. In a MPLS VPN, the portion of the network where PE routers communicate with each other is transparent to the customer. The only routes that are distributed throughout the VPN are the IP networks for the WAN circuits and the IP networks at each of the customer sites. Those IP networks at each of the customer sites are only seen in the WAN if they are advertised to the PE routers.
BGP is a routing protocol that can be intimidating. However, once the syntax is understood, it can be fairly simple to configure if organized properly. Usually the service provider will give the customer the option of how they want to configure their BGP autonomous system numbers (ASNs). The most common configurations are to have each of the sites configured with the same ASN or to assign a different ASN to each site. The latter is recommended, not for any technical reason, but for troubleshooting and management reasons.
If the CE router at each site is the only router at that location, then there is no need for an internal routing protocol (i.e. OSPF, EIGRP, etc.) at that site. If the site has more than one router, an internal routing protocol should be used. In this case, BGP can be redistributed into the internal routing protocol dynamically with the redistribute command, but should not be done the other way around. The reason for this is to summarize the site’s IP address network manually, assuming it has been broken up into larger bit networks at that site. Summarizing can be done with a static route to Null0 using an administrative distance of 220. The administrative distance value is not typically necessary but only used to ensure the summary route is always in the routing table.
In a configuration that has the BGP process of 65001, which is the ASN of that site, the first two sub-commands prevent the auto summarization of routes and prevent dynamic synchronization of BGP with the internal routing protocol. The network statement defines the local IP address space for this site and adds this route into the BGP routing table. This route will only go in the IP routing table if it seen by the internal routing protocol or locally connected. This is where the manual summarization of the IP address space is used. The neighbor statements are used to define the remote IP address and the rules for advertising to that neighbor. The remote-as number is 65000, which is the ASN for the MPLS VPN. The description is only cosmetic and typically has more details about the neighbor. Specifying the BGP version should be identified from the service provider, though version 4 is most commonly used. The default-originate command should only be used at the head-end site where the default route should be coming from. This default route is then dynamically advertised to the remote WAN sites. The soft-reconfiguration inbound command is used to store the inbound routing table updates. This command is useful when BGP changes are made to the router then a soft reset with the neighbor can be executed without a hard reset of the neighbor adjacency. Finally, the in and out prefix lists are used to control the routes received and advertised into the MPLS VPN manually. Though these are not required, they are useful in preventing any mistakes made by the service provider. In large enterprise networks where network administration is distributed throughout the environment, it provides more control to the routing in the WAN and ensure its integrity.
The remote site configuration is similar to the head-end site, except the remote site only needs to receive the default route from its adjacent PE router. Once the traffic leaves that remote site, the routing table on the PE router has the routes from the other remote sites in the MPLS VPN for that customer.
The major differences are the exclusion of the default-originate command, the addition of a default route and the prefix list only allowing the default route to be received from the neighbor. The default route with an administrative distance of 220 is added at the remote sites in the event of the head-end site going down. When the default route sent from BGP, with an administrative distance of 20, disappears from the routing table, the static route will take over. This allows the remote sites to at least communication with each other.
This is a ba