Hey folks, as we discussed in our previous post regarding Basic Configuration on Cisco IOS , here we will continue with advance feature which is establishment of VPN on top of MPLS. Basically there were two Models of VPN which exist:

1. Overlay VPN

Overlay VPNs were initially implemented by the SP by providing either Layer 1 (physical layer) connectivity or a Layer 2 transport circuit between customer sites. In the Layer 1 implementation, the SP would provide physical layer connectivity between customer sites, and the customer was responsible for all other layers. In the Layer 2 implementation, the SP was responsible for transportation of Layer 2 frames (or cells) between customer sites, which was traditionally implemented using either Frame Relay or ATM switches as PE devices. Therefore, the service provider was not aware of customer routing or routes. Later, overlay VPNs were also implemented using VPN services over IP (Layer 3) with tunneling protocols like L2TP, GRE, and IPSec to interconnect customer sites. In all cases, the SP network was transparent to the customer, and the routing protocols were run directly between customer routers.

1. Peer-to-Peer VPN

The peer-to-peer model was developed to overcome the drawbacks of the Overlay model and provide customers with optimal data transport via the SP backbone. Hence, the service provider would actively participate in customer routing. In the peer-to-peer model, routing information is exchanged between the customer routers and the service provider routers, and customer data is transported across the service provider’s core, optimally. Customer routing information is carried between routers in the provider network (P and PE routers) and customer network (CE routers). The peer-to-peer model, consequently, does not require the creation of virtual circuits.The CE routers exchange routes with the connected PE routers in the SP domain. Customer routing information is propagated across the SP backbone between PE and P routers and identifies the optimal path from one customer site to another.

In this lab we outline the generic configurations required on the routers in the service provider domain to implement MPLS VPN. The configurations of the PE and P routers will be covered in this lab. The Configuration on the CE routers are only default routes which we discussed on our previous post.

We will use the following topology for this lab and proceed with it’s configuration step by step:

The scenario is to implement Intranet VPN between the Customer A Site 1 and Customer A Site 2, the customer network consists of the two routers which are CEA-1 and CEA-2, rest there are two other loopbacks on PE1-AS1 and PE2-AS1 as part of the VRF Customer A and be redistributed into the MP-BGP routing contexts.

Configuring MPLS forwarding is the first step to provision the service provider’s MPLS VPN backbone. This step ensures the service provider’s readiness to provide MPLS-related services to prospective customers. At a minimum, the steps to configure MPLS forwarding on PE routers are:

• Enable CEF (Cisco Express Forwarding)
• Configuring IGP Routing Protocol on the PE routers
• Configure MPLS or label forwarding on the PE interfaces connected to the P ( Provider )

The above steps are already discussed on previous post and will not be covered here, in this section we will configure VRFs (Virtual Routing and Forwarding Table) on the PE routers, and below are the configuration steps to configure VRF Definitions:

• Configure VRF on PE router

Configure the VRF CustomerA on PE1-AS1 and PE2-AS1 router. This results in the creation of a VRF routing table and a Cisco Express Forwarding (CEF) table for CustomerA. Below we see that CustomerA VRF being configured on PE1-AS1 router. ( Note the VRF name is case sensitive.)

NOTE: While removing the VRF From the router, the all existing IP Addresses which are associated with CustomerA VRF will be removed as shown above.

• Configure the RD

The RD creates routing and forwarding tables. The RD is added to the beginning of the customer’s IPv4 prefixes to convert them into globally unique VPNv4 prefixes. Next we see the configuration for defining the RD under the VRF.

The RD can be used in either of these formats:

1. 16-bit AS number: Your 32-bit number (for example, 1:100)
2. 32-bit IP address: Your 16-bit number (for example, 10.10.10.101:1)

• Configure the import and export policy

Configure the import and export policy for the MP-BGP extended communities. The policy is used for filtering routes for that particular RT. below it shows the relevant configuration for defining import and export policy.

NOTE: You can simply write use the same value for both (import and export) and we can verify that in our running-configuration we see that the values are same for both Export and Import.

• Associate VRF with the interface

Associate virtual routing/forwarding instance (VRF) with an interface or subinterface in this CustomerA. ( Associating the VRF to an interface results in removal of the IP address from that interface. This is only if VRF was associated to an interface that had the IP address already configured. This means that the IP address will have to be reconfigured after the VRF is associated with that interface. )

Be Noted that the above steps are also followed in PE2-AS1, as they both require same configurations.

You also require to add Interface Loopback 1 under VRF CustomerA.

You can verify the above configuration with the Below Commands:

• Show IP VRF
• Show IP VRF Interfaces

Next we will move to the Configuration of BGP PE-PE Routing on PE Routers as below:

Configuring BGP PE-PE routing between the PE routers is the next step in an MPLS VPN deployment. The purpose of this step is to ensure that VPNv4 routes can be transported across the service provider backbone using MP-iBGP. The P router is transparent to this entire process and, therefore, does not carry any customer routes. We will follow below steps:

• Configure BGP routing on PE routers

Enable BGP routing and identify the AS on the PE1-AS1 and PE2-AS1 routers as below:

• Configure the MP-iBGP neighbors

Configure the remote MP-iBGP neighbor and use the loopback interface as the source of BGP messages and updates. Note that you have to use the update-source command only when the neighbor is peering to your loopback address. This is irrespective of whether it is an iBGP or eBGP neighbor.

You can see above that after issuing the command on PE2-AS1 router the connection between the PE1 and PE2 are established and the BGP Session is UP.

• Configure the VPNv4 address family

Configure the address family for VPNv4 under the BGP configuration process. This step allows you to enter the VPNv4 address family to activate the VPNv4 neighbors. Activate the iBGP neighbor, which is essential for transporting VPNv4 prefixes across the service provider backbone. Using next-hop-self is optional and is primarily used when the service provider has an eBGP PE-CE routing with the customers, because internal BGP (iBGP) sessions preserve the next-hop attribute learned from eBGP peers, which is why it is important to have an internal route to the next hop. Otherwise, the BGP route is unreachable. To make sure you can reach the eBGP next hop, include the network that the next hop belongs to in the IGP or use the next-hop-self neighbor command to force the router to advertise itself, rather than the external peer, as the next hop.

In addition, configure the propagation of the extended communities with BGP routes so as to enable RT propagation, which identifies the VPNs that the routes have to be imported into. ( Note that on some versions of IOS, adding the neighbor for VPNv4 route exchange using the neighbor ip-address activate command also automatically adds the neighbor ip-address send-community extended command. If the neighbor needs to be configured for both standard and extended community exchange, you will explicitly have to configure the neighbor ip-address send-community both command under the VPNv4 address family.)

• Configure the IPv4 address family

Configure the peer VRF IPv4 address family under the BGP configuration process. This step allows you to enter the IPv4 networks that will be converted to VPNv4 routes in MP-BGP updates. For simplicity, redistribution of all connected networks is configured into the MP-BGP process.

After configuring BGP PE-PE routing between the PE routers, you can verify that the MP-iBGP neighbors are operational by issuing any of the following commands:

• show ip bgp vpnv4 * summary
• show IP bgp vpnv4 all
• show ip bgp summary
• show ip bgp neighbor ip-address

No special configurations need to be performed on the P routers P1-AS1 and P1-AS2 for MPLS VPN support. Because the P routers only participate in MPLS labeled packet forwarding, the only requirements are those of an LSR in an MPLS network, namely, IGP for NLRI exchange and LDP for label assignment and distribution. As always, CEF needs to be enabled on all interfaces configured for MPLS forwarding.

You can configure a default route on Customer Site pointing to it’s respective PE Routers and initiate a Ping to see the result.

Cheers,