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:

This is a sample configuration to enable label switching for the Labeled Switched Path (LSP) between PE1 and PE2 (refer to Figure 3-4).

What follows is a sample configuration to establish connections between the two Provider Edge routers PE1 and PE2.

Label switching protocols are used to set up a Label-Switched Path (LSP) between PE routers. OcNOS supports LDP and RSVP-TE protocols for label switching. Enable either LDP or RSVP-TE.

This is a sample configuration to enable LDP on the whole path between PE1 and PE2 (see Figure 3-4).

This is a sample configuration to enable RSVP-TE along the entire path between PE1 and PE2 (see Figure 3-4).

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 xe48 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. Configure a VRF in both PEs with a unique RD value:

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.

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.