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.
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.
hostname San Jose ! router bgp 1 no bgp default ipv4-unicast neighbor 18.104.22.168 remote-as 1 neighbor 22.214.171.124 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.
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 126.96.36.199 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.
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 188.8.131.52 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
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:
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.