RIPv2 PE-CE Routing Overview, Configuration, and Verification

Static PE-CE routing can create administrative overheads for the service provider. Service providers, therefore, prefer to run dynamic PE-CE routing protocols for the following reasons:

To avoid maintaining multiple static routes.

Customer prefers to run a dynamic routing protocol.

Customer has a dual-homed connection to the service provider.

In an RIPv2 PE-CE routing environment, an IPv4 routing context is configured for each VRF running RIP on the PE router. The RIP parameters are specified in the VRF routing context. Global RIP parameters, if entered in the RIP router configuration, are inherited by the RIP VRF routing context. These parameters can, however, be overwritten in the routing context.

Figure 4-3 shows a typical MPLS VPN network, where PE1-AS1 uses RIPv2 as the PE-CE routing protocol with CE1-A, and PE2-AS1 can run either RIPv2, OSPF, EIGRP, BGP, or static PE-CE routing protocol with CE2-A. PE1-AS1 receives RIPv2 routes from the CE1-A router. The received RIP routes are redistributed into MP-iBGP at the PE1-AS1 router and are transported across the backbone as VPNv4 routes to the PE2-AS1 router. These VPNv4 routes are redistributed back into RIPv2, OSPF, EIGRP, and BGP routes at the PE2-AS1 router and then propagated to the CE2-A router.

The network topology in Figure 4-5 depicts an ATM-based MPLS VPN provider network providing MPLS VPN services to Customer A sites, Site 1 and Site 2. The MPLS provider network comprises PE1-AS1 and PE2-AS1 as PE routers. P1-AS1 and P2-AS1 are LS1010 switches and function as provider routers. The MPLS VPN provider network is running OSPF as the IGP routing protocol on PE1-AS1, P1-AS1, P2-AS1, and PE2-AS1. PE routers PE1-AS1 and PE2-AS1 are configured for MP-iBGP connectivity between them.

Figure 4-5. MPLS VPN Provider Implementing RIPv2 PE-CE Routing

Customer A requires connectivity between the Site 1 network (172.16.10.0/24) and Site 2 network (172.16.20.0/24). Site 1 and Site 2 belong to the same VPN, VPN-A. Site 1 and Site 2 comprise CE routers CE1-A and CE2-A, respectively. CE1-A and CE2-A are connected to PE1-AS1 and PE2-AS1, respectively. CE1-A and CE2-A are already running RIPv2 routing protocol. RIPv2 PE-CE routing protocol on PE routers PE1-AS1 and PE2-AS1 is implemented as follows.

Prior to the configuration shown in Example 4-10, ensure that the provider network is provisioned to deliver MPLS VPN services to Customer A sites. Ensure that IP addresses are preconfigured and VRFs defined on PE router. Example 4-10 provides the configuration related to defining VRF and its attributes on PE routers for RIPv2 PE-CE routing.

The steps to configure RIPv2 PE-CE routing on PE routers are as follows:

Step 1.

Configure per VRF RIP routing context and RIP parameters on PE routers – Configure per VRF RIP routing context for VRF RIP under the RIP routing process on PE1-AS1 and PE2-AS1. Configure the per VRF RIP parameters under the address family. Example 4-11 shows this configuration step for PE1-AS1. Repeat the same steps for PE2-AS1.

Redistribute the per VRF RIP routes in BGP – Example 4-12 shows the step to redistribute the per VRF RIP routes into BGP on PE routers PE1-AS1 and PE2-AS1. This configuration step is shown in Example 4-12.

Redistribute MP-iBGP VPNv4 prefixes into RIP – Redistribute the MP-iBGP VPNv4 prefixes from remote PE1-AS1 into RIP per VRF routing context on PE2-AS1 router. In RIP PE-CE routing, the RIP metric is copied into the BGP multi-exit discriminator (MED) attribute. This metric can be preserved across the CE network by configuring the metric transparent option during redistribution from BGP into RIPv2, and, by doing so, it is copied back from the BGP MED attribute into the RIP version 2 metric. The configuration step is shown in Example 4-13.

Verify BGP VPNv4 routing table on PE1-AS1 and PE2-AS1 – Check the BGP VPNv4 routing table to see if routes are received properly. Example 4-16 shows that PE1-AS1 receives 172.16.20.0/24. Repeat the same step on PE2-AS1.

Verify end-to-end connectivity using ping – Verify end-to-end connectivity between the CE1-A and CE2-A by issuing a ping from CE1-A to network 172.16.20.0/24 on CE2-A and vice versa. Example 4-18 shows that the ping has been successful.

Figure 4-6 shows that PE1-AS1 accepts and transforms the IPv4 route, 172.16.10.0/24, to a VPNv4 route by assigning an RD 1:100, SoO, and RT 1:100 based on the VRF RIP configuration on PE1-AS1. It then allocates a VPNv4 label 24 to 172.16.10.0/24 update and rewrites the next-hop attribute to the PE1-AS1 loopback0 IP address 10.10.10.101.

Now PE1-AS1, 10.10.10.101, is reachable via IGP (OSPF) and LDP. The following control plane operation shows the IGP label propagation for prefix 10.10.10.101/32 from PE1-AS1 to PE2-AS1 inside the provider network. This propagation takes place as soon as the MPLS VPN provider network is established and is always in place prior to any VPNv4 prefix being propagated across the MPLS VPN provider network. The following steps are performed in the label propagation process for prefix 10.10.10.101/32. This operation is shown for clarity:

Step 2A In Figure 4-6, Edge ATM LSR PE2-AS1 requests a label for the 10.10.10.101/32 prefix using the LDP label mapping request from its downstream neighbor, ATM LSR P2-AS1. P2-AS1 requests a label for the 10.10.10.101/32 prefix using the LDP label mapping request from its downstream neighbor, ATM LSR P1-AS1. P1-AS1, in turn, requests a label for the 10.10.10.101/32 prefix using the LDP label mapping request from its downstream neighbor, Edge ATM LSR PE1-AS1. Edge ATM LSR PE1-AS1 allocates a label to 10.10.10.101/32, which corresponds to its inbound VPI/VCI value 1/33, modifies the entry in the LFIB corresponding to 10.10.10.101/32, and sends it to P1-AS1 using an LDP reply. Example 4-19 shows the output of show mpls atm-ldp bindings on PE1-AS1.

Step 2B P1-AS1 uses the VPI/VCI, 1/33, received from PE1-AS1 as its outbound VPI/VCI label value, allocates a free VC that is mapped to the local inbound VPI/VCI 1/44, and modifies the LFIB entry for 10.10.10.101/32. P1-AS1 then sends VPI/VCI value 1/44 to P2-AS1 via an LDP reply, as shown in Figure 4-6. Example 4-20 shows the output of show mpls atm-ldp bindings on P1-AS1.

Step 2C P2-AS1 uses the VPI/VCI, 1/44, received from P1-AS1 as its outbound VPI/VCI value, allocates a free VC that is mapped to the local inbound VPI/VCI 1/39, and modifies the LFIB entry for 10.10.10.101/32. P2-AS1 then sends VPI/VCI value 1/39 to PE2-AS1 via an LDP reply. Example 4-21 shows the output of show mpls atm-ldp bindings on P2-AS1.

PE1-AS1 has VRF RIP configured to accept routes with RT 1:100 and, therefore, translates the VPNv4 update to IPv4 and inserts the route in VRF RIP. It then propagates this route to the CE2-A.

Data Forwarding Operation

The data forwarding path originates from 172.16.20.1, which is the source address with the traffic destined to 172.16.10.1. Figure 4-6 traces the path of the data packet from the source to the destination:

Step 1.

CE2-RIP originates a data packet with the source address of 172.16.20.1 and destination of 172.16.10.1.

Step 2.

PE2-AS1 receives the data packet and appends the VPN label 24 and LDP label 1/39 and forwards the packet to P2-AS1. See Example 4-23.

P1-AS1 receives the data packet destined to 172.16.10.1 and swaps LDP label 1/44 with 1/33. Example 4-25 shows the output of show mpls atm-ldp bindings destination-prefix mask-length. Penultimate hop popping is not supported on ATM LSRs because the label is part of the ATM cell payload and cannot be removed by ATM switching hardware. Therefore, P1-AS1, which is an ATM device, does not perform any penultimate hop popping function.