Propagation of OSPF Routes Across the MPLS/VPN Backbone

As with all other MPLS/VPN deployment options, after the VPN customer routes have been placed into the receiving VRF, they must be advertised to other PE-routers through use of MP-iBGP. Again, this behavior is not automatic, so redistribution between OSPF and BGP is required.

Note

It is important to note that the MPLS/VPN backbone is not a real OSPF area 0 backbone. No adjacencies are formed between PE-routers?only between PE- and CE-routers. MP-iBGP is used between PE-routers, and all OSPF routes are translated into VPN-IPv4 routes. This means that the redistribution of routes into BGP does not cause these routes to become external OSPF routes when advertised to other member sites of the same VPN.

The redistribution of VRF OSPF routes into MP-iBGP is achieved through use of the address family within the BGP configuration. Depending on which IOS revision is used, the redistribute command may need several options added so that all relevant routes are redistributed into BGP. The configuration for the SuperCom San Jose PE-router can be seen in Example 10-6, which shows the command with all relevant route types added.

Example 10-6 Redistribution of VRF OSPF Routes into MP-iBGP


hostname San Jose

!

router bgp 1

 no bgp default ipv4-unicast 

 neighbor 194.22.15.1 remote-as 1

 neighbor 194.22.15.1 update-source loopback0

 !

 address-family ipv4 vrf EuroBank

 redistribute ospf 200 match internal external 1 external 2

 no auto-summary

 no synchronization

 exit-address-family

 !

 address-family ipv4 vrf FastFoods

 redistribute ospf 100 match internal external 1 external 2

 no auto-summary

 no synchronization

 exit-address-family

The final configuration step is to redistribute any routes that are contained within a particular VRF and that have been learned via MP-iBGP to other members of the VPN. This is achieved through the redistribution of routes from BGP into the relevant OSPF process, as shown in Example 10-7.

Example 10-7 Redistribution of BGP into VRF OSPF Process


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

! 

router ospf 200 vrf EuroBank

 redistribute bgp 1 subnets metric 20

 network 10.2.1.4 0.0.0.3 area 0

!

router ospf 100 vrf FastFoods

 redistribute bgp 1 subnets metric 20

 network 195.12.2.4 0.0.0.3 area 1

When this redistribution has been configured, the PE-router becomes an area border router (ABR) and an autonomous system boundary router (ASBR) for the VPN customer site. Example 10-8 provides confirmation of this, and also shows that the EuroBank San Francisco CE-router generates a type-4 LSA (Link State Advertisement) into its attached area 1 for this ASBR.

Example 10-8 PE-router as Autonomous System Boundary Router (ASBR)


San Jose# show ip ospf



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 and autonomous system boundary router

 Redistributing External Routes from,

    bgp 1, includes subnets in redistribution



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 and autonomous system boundary router

 Redistributing External Routes from,

    bgp 1, includes subnets in redistribution    



San Francisco# show ip ospf database asbr-summary



OSPF Router with ID (10.3.1.7) (Process ID 100)





                Summary ASB Link States (Area 1)



  LS age: 1339

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(AS Boundary Router)

  Link State ID: 10.2.1.5 (AS Boundary Router address)

  Advertising Router: 10.3.1.7

  LS Seq Number: 80000002

  Checksum: 0x80B

  Length: 28

  Network Mask: /0

        TOS: 0  Metric: 1

BGP Extended Community Attribute for OSPF Routes

Whenever a PE-router receives an MP-iBGP update that contains a prefix learned via OSPF by the originating PE-router, it must be capable of identifying what type of OSPF route is contained within the update. This is necessary to allow the PE-router to generate an appropriate link state advertisement (LSA) toward the VPN customer CE-router based on the OSPF route type received across the MPLS/VPN backbone. OSPF has several route types:

Inter-area
Intra-area
NSSA
External type 1
External type 2

To support this requirement, when the PE-router propagates OSPF routes into MP-iBGP through redistribution, the BGP extended community attribute is used to preserve and convey the OSPF attributes of the route. (This attribute was discussed in detail in Chapter 9.) The format of the attribute used for the propagation of OSPF information is as follows, and we will see the operation of this attribute in later sections:

Extended Community 0x8000
- 4 bytes: OSPF area number
- 1 byte: OSPF route type (1 through 7)
- 1 Byte: Option (used for external metric type)

As we already know, when a PE-router receives an MP-iBGP update, it must execute the BGP decision process to decide the best path to the prefix contained within the update. When this decision process is complete, the best route is passed onto the OSPF selection process for import into any relevant VRFs. Because multiple updates for the same prefix might be received, and because OSPF has its own selection process for differing route types, the BGP decision process has been enhanced to prefer intra-area OSPF routes over inter-area routes over external type 1 over external type 2 routes. This decision process is based on the OSPF route type that is conveyed within the BGP extended community attribute that accompanies the VPN-IPv4 route.