This chapter contains configurations for MPLS Layer-3 Virtual Private Networks (VPNs).

The MPLS Layer-3 VPN solution provides address space and routing separation via the use of per-VPN Routing and Forwarding tables (VRFs), and MPLS switching in the core and at the edge of the network. VPN customer routing data is imported into the VRFs utilizing the Route Target BGP extended community. This routing data is identified by a Route Distinguisher (RD) and is distributed among Provider Edge (PE) routers using Multi-Protocol BGP extensions.

The following illustrates a Virtual Private Network in a CConnect Service Provider Network. This illustration corresponds to the terms defined in this subsection.

The organization that owns the infrastructure that provides leased lines to customers, offering them a Virtual Private Network Service. In the above illustration, CConnect is the service provider providing services to clients ComA and ComB.

A router at a customer’s site that connects to the Service Provider via one or more Provider Edge routers. In the above illustration, CE1, CE2, CE3 and CE4 are all CE routers connected directly to the CConnect network.

A provider’s router connected to a CE router through a leased line or dial-up connection. In the above illustration, PE1 and PE2 are the PE routers, because they link the CConnect service provider to its clients.

The devices in the core of the service provider network, which are generally not Provider Edge routers. In the above illustration, the P router is the Provider device, not connected to any customer, and is the core of the CConnect network.

A contiguous part of the customer network. A site connects to the provider network through transmission lines, using a CE and PE router. In the above illustration, R1, R2 and CE3 comprise a Customer network, and are seen as a single site by the CConnect network.

In the illustration above, R1 and R2 are the Customer routers, and are not directly connected to the CConnect network.

The OcNOS MPLS-VPN Routing process follows these steps:

The MPLS Layer-3 VPN configuration process can be divided into the following tasks

In this example, the CConnect MPLS-VPN backbone has two customers — ComA and ComB. Both customers have sites in California and Arizona. The following topology shows BGP4 address assignment between PE and CE routers. The steps that follow provision a customer VPN service across the MPLS-VPN backbone.

To establish this connection involves three steps:

BGP is the preferred protocol to transport VPN routes because of its multiprotocol capability and its scalability. Its ability to exchange information between indirectly connected routers supports keeping VPN routing information out of the Provider (P) routers. The P routers carry information as an optional BGP attribute. Additional attributes are transparently forwarded by any P router. The MPLS-VPN forwarding model does not require the P routers to make routing decisions based on VPN addresses: They forward packets based on the label value attached to the packet. The P routers do not require a VPN configuration in order to carry this information.

 

 

 

 

 

 

Each PE router in the MPLS-VPN backbone is attached to a site that receives routes from a specific VPN, so the PE router must have the relevant Virtual Routing and Forwarding (VRF) configuration for that VPN.

This command creates a VRF RIB (Routing Information Base), assigns a VRF-ID, and switches the command mode to vrf mode. The following example creates a VRF named ComB.

After the VRFs are defined on the PE router, the PE router needs to recognize which interfaces belong to which VRF. The VRF is populated with routes from connected sites. More than one interface can belong to the same VRF.

In the following example, interface eth1 is associated with the VRF named ComB.

After the VRF is created, configure Router Distinguishers and the Route Targets.

Route Distinguishers (RDs) make all customer routes unique. The routes must be unique, so that Multi-Protocol BGP treats the same prefix from two different VPNs as non-comparable routes. To configure RDs, a sequence of 64 bits is prepended to the IPv4 address in the Multi-Protocol BGP update. BGP considers two IPv4 addresses with different RDs as non-comparable, even if they have the same address and mask.

Assign a particular value to the RD for each VRF on the PE router. To display the routing table for a VRF, use the show ip route vrf command.

The following example shows adding an RD:

Any routes learned from customers are advertised across the network through Multi-Protocol BGP, and any routes learned through Multi-Protocol BGP are added into the appropriate VRFs. The route target helps PE routers identify which VRFs should receive the routes.

The route-target command creates lists of import and export route-target extended communities for the VRF. It specifies a target VPN extended community. Execute the command once for each community. All routes with the specific route-target extended community are imported into all VRFs with the same extended community as an import route-target.

The following example demonstrates the route-target configuration for ComB.

To provide a VPN service, the PE-router must be configured so that any routing information learned from a VPN customer interface can be associated with a particular VRF. This is achieved using any standard routing protocol process (OSPF, BGP or static routes etc). Use any one of the following configurations (BGP, or OSPF) to configure the CE neighbor.

The BGP sessions between PE and CE routers can carry different types of routes (VPN-IPv4, IPv4 routes). Address families are used to control the type of BGP session. Configure a BGP address family for each VRF on the PE-router, and a separate address family to carry VPN-IPv4 routes between PE routers. All non-VPN BGP neighbors are defined using the IPv4 address mode. Each VPN BGP neighbor is defined under its associated address family mode.

A separate address family entry is used for every VRF, and each address family entry can have multiple CE routers within the VRF.

The PE and CE routers must be directly connected for BGP4 sessions; BGP multihop is not supported between PE and CE routers.

The following example places the router in address family mode, and specifies company names, ComA and ComB, as the names of the VRF instance to associate with subsequent IPv4 address family configuration mode commands. This configuration is used when BGP is used for PE and CE.

Unlike BGP, OSPF does not run different routing contexts within one process. Thus, for running OSPF between the PE and CE routers, configure a separate OSPF process for each VRF that receives VPN routes through OSPF. The PE router distinguishes routers belonging to a specific VRF, by associating a particular customer interface to a specific VRF and to a particular OSPF process.

To redistribute VRF OSPF routes into BGP, redistribute OSPF under the BGP VRF address family submode.

Use the show ip bgp neighbor command to validate the neighbor session between the CE and the PE routers. Use the show ip bgp vpnv4 all command to display all the VRFs and the routes associated with them. The following is sample output for the above commands for the PE1, CE1 and PE2 routers (based on the topology in Figure 4-5).

Use the ping mpls l3vpn command for the below requirements: