Separation of VPN Customer Routing Information

Whichever of the two connectivity options are chosen (we will look at each in detail in the sections that follow), a mechanism is needed so that the PE-router can distinguish which routes belong to which VRF. This is accomplished through association of a particular customer interface to a specific VRF (per the standard MPLS/VPN model that we have already described) and to a particular OSPF process.

A separate OSPF process is necessary for each VRF that will receive VPN routes via OSPF. This is different than the procedures used when either RIP Version 2 or BGP are deployed across the PE-to-CE link because these protocols can run different routing contexts within the same process. Due to the complexity of OSPF and the associated topology database, this option is not currently available, so a different OSPF process (with a different process-ID) is required per VRF. To support this requirement, an extension to the router ospf command has been provided, as shown in Example 10-3.

Example 10-3 Extension to router ospf Command

San Jose(config)# router ospf ospf-Process-ID VRF vrf-name

Using the example topology shown in Figure 10-4, we can see in Example 10-4 the use of the router ospf command to set up the relevant OSPF processes for the EuroBank and FastFoods VPN customers on the San Jose PE-router.

Example 10-4 Configuration of OSPF Processes for VPN Customers

hostname San Jose

!

ip vrf EuroBank

 rd 1:27

 route-target export 100:27

 route-target import 100:27

!

ip vrf FastFoods

 rd 1:26

 route-target export 100:26

 route-target export 100:26

!

interface serial 1/0

 description ** interface to EuroBank San Francisco**

 ip vrf forwarding EuroBank

 ip address 10.2.1.5 255.255.255.252

!

interface serial 1/1

 description ** interface to FastFoods San Jose**

 ip vrf forwarding FastFoods

 ip address 195.12.2.5 255.255.255.252

!

router ospf 200 vrf EuroBank

 network 10.2.1.4 0.0.0.3 area 0

!

router ospf 100 vrf FastFoods

 network 195.12.2.4 0.0.0.3 area 1

Given the configuration in Example 10-4, we can see in Example 10-5 both OSPF processes and the number of interfaces in each process through use of the show ip ospf command.

Example 10-5 show ip ospf Confirmation of Multiple OSPF Processes

San Jose# show ip ospf



Routing Process "ospf 100" with ID 195.12.2.5

 Supports only single TOS(TOS0) routes

 Supports opaque LSA

 Connected to MPLS VPN Superbackbone

 It is an area border router

 SPF schedule delay 5 secs, Hold time between two SPFs 10 secs

 Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs

 Number of external LSA 0. Checksum Sum 0x0

 Number of opaque AS LSA 0. Checksum Sum 0x0

 Number of DCbitless external and opaque AS LSA 0

 Number of DoNotAge external and opaque AS LSA 0

 Number of areas in this router is 1. 1 normal 0 stub 0 nssa

 External flood list length 0

    Area 1

        Number of interfaces in this area is 1

        Area has no authentication

        SPF algorithm executed 2 times

        Area ranges are

        Number of LSA 1. Checksum Sum 0xC4E7

        Number of opaque link LSA 0. Checksum Sum 0x0

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0



Routing Process "ospf 200" with ID 10.2.1.5

 Supports only single TOS(TOS0) routes

 Supports opaque LSA

 Connected to MPLS VPN Superbackbone

 It is an area border router

 SPF schedule delay 5 secs, Hold time between two SPFs 10 secs

 Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs

 Number of external LSA 1. Checksum Sum 0xCAE8

 Number of opaque AS LSA 0. Checksum Sum 0x0

 Number of DCbitless external and opaque AS LSA 0

 Number of DoNotAge external and opaque AS LSA 0

 Number of areas in this router is 1. 1 normal 0 stub 0 nssa

 External flood list length 0

    Area BACKBONE(0)

        Number of interfaces in this area is 1

        Area has no authentication

        SPF algorithm executed 6 times

        Area ranges are

        Number of LSA 7. Checksum Sum 0x4A01D

        Number of opaque link LSA 0. Checksum Sum 0x0

        Number of DCbitless LSA 0

        Number of indication LSA 0

        Number of DoNotAge LSA 0

        Flood list length 0

When the relevant OSPF processes have been configured on the PE-router, it is now possible to learn routes from the CE-router using OSPF. These routes are placed into the relevant OSPF database, and the VPN customer VRF is populated.