The MPLS VPN architecture extends OSPF by introducing another backbone above OSPF area 0 (superbackbone). The OSPF super-backbone is implemented with MultiProtocol BGP (MP-BGP) between the PE-routers and is completely transparent to the OSPF routers. The architecture even allows disjointed OSPF backbone areas (area 0) at MPLS VPN customer sites.
The OSPF hierarchical model now has three levels:
- The superbackbone is always on top.
- Area 0 (backbone) connects directly to the superbackbone
- Ordinary areas (non-backbone) connect to area 0
However, when the superbackbone is present, the old backbone (area 0) is not required. As a design option, ordinary areas are allowed to connect directly to the superbackbone.
In the figure, area 3 is connected to area 0 which is connected to the superbackbone. There is also another site where area 0 is used. This discontinuous area 0 is not a problem because the superbackbone connects them together. Without the concept of the superbackbone, a discontinuous area 0 would in fact turn a traditional OSPF network into two separate OSPF networks.
The OSPF information propagated between different OSPF sites is encoded into BGP. This is totally transparent to the customer routers is only visible to the PE routers. OSPF super-backbone is transparent to the CE-routers (in pink) that run standard OSPF software.
The PE-routers that connect regular OSPF areas to the super-backbone appear as ABR in the OSPF
areas to which they are attached. They also appear as ASBR in non-stub areas.
The CE router views the PE router as an ABR. If the CE router is in area 0 (backbone), the CE router will believe that there is an ordinary area on the other side of the PE router. If the CE router is in a non-backbone area, the CE router will believe that the backbone is on the other side of the PE router.
The PE inserts the OSPF LSA type 1 (Router) or LSA type 2 (network) into the superbackbone by redistributing the OSPF route into MP-BGP. The MP-BGP route is propagated to other PE-routers and injected as a LSA 3 (inter-area route / Summary) route.
LSA type 4 MUST NOT be redistributed to BGP.
LSA type 5 route are redistribued into MP-BGP. This LSA is re-originated in the remote area with the PE-router acting as the ASBR.
LSA type 7 NSSA external routes are similarly redistributed. The route is announced to the other
OSPF sites as LSA type-5 external route.
OSPF to BGP Attribute Mapping
OSPF Routes from one site are converted to BGP, distributed across the VPN backbone, and possibly converted back to OSPF routes before being distributed into another site. The OSPF route “attributes” like LSA type, Cost are attached to the BGP route using Extended Communities attributes. With these attributes, BGP carries enough information about the route to enable the route to be converted back into OSPF “transparently”, just as if BGP had not been involved.
This OSPF information is carried in extended community attributes and MED as given below.
- OSPF Domain Identifier Route Type Extended Communities Attribute
- OSPF Route Type Extended Communities Attribute: Contains three fields:
- Area Number (4 bytes)
- Route Type (1 byte)
- 1 or 2 for intra-area routes (depending on whether the route came from a type 1 or a type 2 LSA)
- 3 for inter-area routes
- 5 for external routes (area number must be 0)
- 7 for NSSA routes
- Options (1 byte)
- Currently, this is only used if the route type is 5 or 7. Setting the least significant bit in the field indicates that the route carries a type 2 metric
- OSPF Router ID Extended Communities Attribute
- By default, this SHOULD be set to the value of the OSPF distance associated with the route, plus 1
Issue with Redistribution
There are a number of issues with distributing these OPSF routes back into a remote OSPF area and this document covers them well.
Both the OSPF down bit and domain tag are modifications in OSPF which are used as loop prevention mechanisms. Type 5 LSAs do not contain the options field in the header as a result they use domain tags. In LSA type 5 an external route tag is used to identify routes which have been redistributed from BGP into OSPF.
PE routers do not import OSPF routes which have either the down bit or tag set as they know this was originated by the a PE somewhere else in the OSPF domain.
A OPSF Sham link is used to affect the path selection within an area. If a MPLS VPN has multiple OSPF enabled sites and two or more of these sites are in the same area and are tied by a separate link then OSPF will prefer the intraarea paths to interarea paths.
A sham-link is setup between PE routers. A cost is configured with each sham-link and is used to decide whether traffic will be sent over the backdoor path or the sham-link path. Because the sham-link is seen as an intra-area link between PE routers, an OSPF adjacency is created and database exchange (for the particular OSPF process) occurs across the link. The PE router can then flood LSAs between sites from across the MPLS VPN backbone. As a result, the desired intra-area connectivity is created.
You can setup a sham link using the command below. The area-id is the area you are bridging together (unlike the ospf virtual links where the specified area-id is the area you are transiting)
PE(config-if)# area area-id sham-link source-address destination-address cost number
Only LSAs travel over this link, traffic is be routed across the MPLS/VPN backbone.