Basic PE to CE Link Configuration

To provide a VPN service, the PE-router needs to be configured so that any routing information learned from a VPN customer interface can be associated with a particular VRF. You can do this through the standard routing protocol process, which is known as the routing context. Each VRF uses a separate routing context. Chapter 8 discusses this concept fully.

Any routes learned across an interface that is associated with the particular routing protocol context are installed into the associated VRF. Any routes learned from interfaces that are not part of any VRF routing context are placed in the global routing table. This allows for the separation of routing information into different contexts even though the information is learned by the same routing protocol process. It effectively creates VPN-aware routing protocols.

Several connectivity options allow a VPN customer to attach to the MPLS/VPN backbone. The sample case study uses only RIP Version 2 and static routing, and this section reviews both of these options.

Note

For a full discussion on other connectivity options, such as OSPF and BGP, see Chapter 10.

PE to CE Link Configuration?Static Routing

The first option is to run static routing between the PE- and CE-routers. This static routing information is redistributed into BGP for advertisement across the MP-iBGP sessions that connect PE-routers. This is a good choice for deployment when the site is a stub site, that is it has only one entry point into the service provider's network because there is little to be gained by dynamically learning the customer routes via the PE-CE link.

A static route for every network (or aggregate route) beyond the CE-router must be configured into the VRF on the PE-router that connects the site (assuming other members of the VPN can reach the network). This is the same type of configuration as with normal IP routing.

Note

One exception to this is when the rest of the VPN uses the site for central services, such as Internet connectivity. In this case, a default route pointing to the site can be deployed and advertised to other members of the VPN using a specific route target. See the discussion on Internet connectivity in Chapter 12, "Advanced MPLS/VPN Topics," for further details.

To allow this static routing information to be advertised between PE-routers, it must be redistributed into BGP. You can achieve this by using the redistribute command within the BGP Address Family configuration, which is discussed in more detail in the section on MP-BGP, later in this chapter. You can use the same command to redistribute any connected VRF interface addresses into BGP.

In the case study example, the SuperCom Paris PE-router needs to be configured for static routing to both VPN customers. Each customer CE-router points by default to the PE-router, so you do not need to consider the configuration of the CE-router. The first step in this process is to configure all the relevant static routes, and to place these static routes in the correct VRF, rather than the global routing table. To acheive this objective, use the ip route command (with extensions for MPLS/VPN). Example 9-10 shows the relevant configuration for the SuperCom Paris router to support the EuroBank Paris and FastFoods Lyon customer sites.

Example 9-10 ip route Command Extensions for MPLS/VPN


Paris(config)# ip route vrf FastFoods 10.2.1.0 255.255.255.0 serial0

Paris(config)# ip route vrf EuroBank 196.7.25.0 255.255.255.0 serial1

The second step is to advertise these static routes to other PE-routers by using MP-iBGP. As previously stated, you use the redistribute command within the address-family configuration of the VRF to do this. Example 9-11 shows the configuration of the SuperCom Paris PE-router, which allows the previously defined static routes to be advertised to other PE-routers within the SuperCom MPLS/VPN backbone:

Example 9-11 Redistribution of Static Routing Information into MP-iBGP


hostname Paris

!

router bgp 1

!

address-family ipv4 vrf EuroBank

 redistribute static

exit address-family

!

address-family ipv4 vrf FastFoods

 redistribute static

exit address-family

If multiple static routes exist for a particular VPN customer and only some of these routes should be reachable by other members of the VPN, you can use a route-map command to control which static routes are placed into MP-iBGP during redistribution.

PE to CE Link Configuration?RIP Version 2

This connectivity option provides the facility to run RIP version 2 between the PE- and CE-routers. The information received via RIP from any VPN customer CE-router is placed into the connected VRF for the receiving interface, and then is advertised across the MPLS/VPN backbone between PE-routers.

When RIP version 2 is chosen as the routing protocol, the RIP process needs to be told which RIP routes to advertise out of which interfaces. To achieve this, use the network command. The network command tells the RIP process which interfaces are RIP-enabled and which interfaces to send RIP updates out of. In a normal RIP version 2 deployment, these RIP updates contain every RIP route within the routing table plus any directly connected interfaces that are RIP-enabled.

It obviously is not desirable, in the context of MPLS/VPN, for the RIP process to advertise all routes out of any interfaces that belong to the address range specified by the network command. To overcome this, use the address-family sub-mode within the main RIP process configuration. The router interprets any commands you enter in this sub-mode as belonging to the specified VRF. Because of this, any network commands you enter in the sub-mode are associated with the VRF that is configured for that address-family. Routes belonging to the VRF then are advertised by RIP but only out of the interfaces associated with the address-family. Any RIP routes that belong to the global routing table, or any other VRF, are not advertised even though the RIP process is aware of the routes.

The SuperCom San Jose PE-router in the case study runs RIP version 2 with the EuroBank San Francisco site and the FastFoods San Jose site. Example 9-12 illustrates the relevant RIP configuration.

Example 9-12 PE to CE RIP Version 2 Configuration Example


hostname San Jose

!

interface serial0

 description ** interface to Eurobank San Francisco**

 ip address 10.2.1.5 255.255.255.252

!

interface serial1

 description ** interface to FastFoods San Jose**

 ip address 195.12.2.5 255.255.255.252

!

router rip

 version 2

 !

address-family ipv4 vrf EuroBank

 version 2

 redistribute bgp 1 metric 1

 network 10.0.0.0

 no auto-summary

exit-address-family

!

address-family ipv4 vrf FastFoods

 version 2

 redistribute bgp 1 metric 1

 network 195.12.2.0

 no auto-summary

exit-address-family

!

Example 9-13 shows that a routing context is defined for each VRF that receives routes from the RIP process. Any routes received via RIP across interfaces associated with the VRF are placed into the VRF and are not placed into the global routing table. However, this configuration only gets the RIP-derived information into the relevant VRFs; it does not cause the routes to be advertised via MP-iBGP to other PE-routers. If this is desired, then you must configure the address-family for this specific VRF within the BGP process as in the previous static route example, and the RIP routes must be redistributed into BGP. This causes the routes to be advertised across any MP-iBGP sessions that are configured to carry VPN-IPv4 address prefixes.

Note

In Example 9-12, notice the statement redistribute bgp 1 metric 1 in the RIP address-family configuration. This command is necessary so that any VPN routes learned from across MP-iBGP sessions are advertised toward the CE-router by the RIP process. Notice also that these routes are iBGP routes that normally are not redistributed when running standard BGP-4, but are successfully redistributed if the interface is associated with a VRF.

Note

Although RIP version 1 also works in this scenario, it is not recommended due to its lack of VLSM support and the fact that Cisco does not support its use within this environment.

Note

When using RIP as the PE-CE configuration, it is necessary (as in normal redistribution) to specify the BGP metric as the default metric, which is unreachable. In later releases of IOS, however, it is possible to carry RIP metrics transparently across the MPLS/VPN backbone through the use of the command redistribute bgp metric transparent. This command causes RIP to use the routing table metric for redistributed routes as the RIP metric, with the original metric being carried across the MPLS/VPN backbone in the BGP MED value.