OSPF VPN
Definition
As an extension of OSPF, OSPF VPN enables Provider Edges (PEs) and Customer Edges (CEs) in VPNs to run OSPF for interworking and use OSPF to learn and advertise routes.
Purpose
As a widely used IGP, in most cases, OSPF runs in VPNs. If OSPF runs between PEs and CEs, and PEs use OSPF to advertise VPN routes to CEs, no other routing protocols need to be configured on CEs for interworking with PEs, which simplifies management and configuration of CEs.
Running OSPF Between PEs and CEs
In BGP/MPLS VPN, Multi-Protocol BGP (MP-BGP) is used to transmit routing information between PEs, whereas OSPF is used to learn and advertise routes between PEs and CEs.
Running OSPF between PEs and CEs has the following benefits:
OSPF is used in a site to learn routes. Running OSPF between PEs and CEs can reduce the number of the protocol types that CEs must support.
Similarly, running OSPF both in a site and between PEs and CEs simplifies the work of network administrators and reduces the number of protocols that network administrators must be familiar with.
When a network using OSPF but not VPN on the backbone network begins to use BGP/MPLS VPN, running OSPF between PEs and CEs facilitates the transition.
In Figure 1, CE1, CE3, and CE4 belong to VPN 1, and the numbers following OSPF refer to the process IDs of the multiple OSPF instances running on PEs.
CE1 advertises routes to CE3 and CE4 as follows:
PE1 imports OSPF routes of CE1 into BGP and converts them to BGP VPNv4 routes.
PE1 uses MP-BGP to advertise the BGP VPNv4 routes to PE2.
PE2 imports the BGP VPNv4 routes into OSPF and then advertises these routes to CE3 and CE4.
The process of advertising routes of CE4 or CE3 to CE1 is the same as the preceding process.
Configuring OSPF Areas Between PEs and CEs
OSPF areas between PEs and CEs can be non-backbone or backbone areas (Area 0). PEs can function only as ABRs.
In the extended application of OSPF VPN, the MPLS VPN backbone network serves as Area 0. OSPF requires that Area 0 be contiguous. Therefore, Area 0 of all VPN sites must be connected to the MPLS VPN backbone network. If a VPN site has OSPF Area 0, the PEs that CEs access must be connected to the backbone area of this VPN site through Area 0. If no physical link is available to directly connect PEs to the backbone area, a virtual link can be deployed between the PEs and the backbone area. Figure 2 shows the networking for configuring OSPF areas between PEs and CEs.
A non-backbone area (Area 1) is configured between PE1 and CE1, and a backbone area (Area 0) is configured in Site 1. The backbone area in Site 1 is separated from the VPN backbone area. To ensure that the backbone areas are contiguous, a virtual link is configured between PE1 and CE1.
OSPF Domain ID
If inter-area routes are advertised between local OSPF area and the VPN remote OSPF area, these areas are considered to be in the same OSPF domain.
Domain IDs identify domains.
Each OSPF domain has one or more domain IDs. If more than one domain ID is available, one of the domain IDs is a primary ID, and the others are secondary IDs.
If an OSPF instance does not have a specific domain ID, its ID is considered as null.
Before advertising the remote routes sent by BGP to CEs, PEs need to determine the type of OSPF routes (Type 3, Type 5, or Type 7) to be advertised to CEs based on domain IDs.
If local domain IDs are the same as or compatible with remote domain IDs in BGP routes, PEs advertise Type 3 routes.
If local domain IDs are different from or incompatible with remote domain IDs in BGP routes, PEs advertise Type 5 or Type 7 routes.
Relationship Between Local and Remote Domain IDs |
Comparison Between Local and Remote Domain IDs |
Type of the Generated Routes |
|---|---|---|
Both the local and remote domain IDs are null. |
Equal |
Inter-area routes |
The remote domain ID is the same as the local primary domain ID or one of the local secondary domain IDs. |
Equal |
Inter-area routes |
The remote domain ID is different from the local primary domain ID or any of the local secondary domain IDs. |
Not equal |
If the local area is a non-NSSA, external routes are generated. If the local area is an NSSA, NSSA routes are generated. |
Routing Loop Prevention
Routing loops may occur between PEs and CEs when OSPF and BGP learn routes from each other.
In Figure 3, on PE1, OSPF imports a BGP route destined for 10.1.1.1/32 and then generates and advertises a Type 5 or Type 7 LSA to CE1. Then, CE1 learns an OSPF route with 10.1.1.1/32 as the destination address and PE1 as the next hop and advertises the route to PE2. Therefore, PE2 learns an OSPF route with 10.1.1.1/32 as the destination address and CE1 as the next hop.
Similarly, CE1 also learns an OSPF route with 10.1.1.1/32 as the destination address and PE2 as the next hop. PE1 learns an OSPF route with 10.1.1.1/32 as the destination address and CE1 as the next hop.
As a result, CE1 has two equal-cost routes with PE1 and PE2 as next hops respectively, and the next hop of the routes from PE1 and PE2 to 10.1.1.1/32 is CE1, which leads to a routing loop.
In addition, the priority of an OSPF route is higher than that of a BGP route. Therefore, on PE1 and PE2, BGP routes to 10.1.1.1/32 are replaced with the OSPF route, and the OSPF route with 10.1.1.1/32 as the destination address and CE1 as the next hop is active in the routing tables of PE1 and PE2.
The BGP route is inactive, and therefore, the LSA generated when this route is imported by OSPF is deleted, which causes the OSPF route to be withdrawn. As a result, no OSPF route exists in the routing table, and the BGP route becomes active again. This cycle causes route flapping.
OSPF VPN provides a few solutions to routing loops, as described in Table 2.
Feature |
Definition |
Function |
|---|---|---|
DN-bit |
The DN bit is a flag bit used by OSPF multi-instance processes to prevent routing loops. |
After OSPF multi-instance is configured on the router (a PE or an MCE), the router sets the DN bit (to 1) of generated Type 3, Type 5, or Type 7 LSAs and does not set the DN bit (0) of other LSAs. When calculating routes, the OSPF multi-instance process on the router ignores the LSAs in which the DN bit is set. This prevents routing loops that occur when LSAs sent by a PE (or MCE) are sent back to the PE (or MCE) through a CE. On the network shown in Figure 3, PE1 sets the DN bit in the generated Type 3, Type 5, or Type 7 LSAs to 1 and advertises these LSAs to CEs. Then, the CEs send the LSAs to PE2. Upon reception of these LSAs, PE2 checks the DN bit of the LSAs and finds that the DN bit is 1. Therefore, PE2 ignores the LSAs, which prevents routing loops. |
VPN Route Tag |
The VPN route tag is carried in Type 5 or Type 7 LSAs generated by PEs based on the received BGP VPN route. It is not carried in BGP extended community attributes. The VPN route tag is valid only on PEs that receive BGP routes and generate OSPF LSAs. |
When a PE detects that the VPN route tag in the incoming LSA is the same as the local route tag, the PE ignores the LSA, which prevents routing loops. |
Default route |
It is a route whose destination IP address and mask are both 0. |
Default routes are used to forward traffic from CEs or sites where CEs reside to the VPN backbone network. |
Disabling Routing Loop Prevention
Exercise caution when disabling routing loop prevention because it may cause routing loops.
During BGP or OSPF route exchanges, routing loop prevention prevents OSPF routing loops in VPN sites.
In the inter-AS VPN Option A scenario, if OSPF runs between ASBRs to transmit VPN routes, the remote ASBR may fail to learn the OSPF routes sent by the local ASBR due to the routing loop prevention mechanism.
In Figure 4, inter-AS VPN Option A is used. In this example, CE1 sends VPN routes to CE3, and OSPF runs between PE1 and CE1.
PE1 learns routes to CE1 using the OSPF process in a VPN instance, imports these routes into MP-BGP, and sends the MP-BGP routes to ASBR1.
After receiving the MP-BGP routes, ASBR1 imports the routes into the OSPF process in a VPN instance and generates Type 3, Type 5, or Type 7 LSAs carrying DN bit 1.
ASBR2 uses OSPF to learn these LSAs and checks the DN bit of each LSA. After learning that the DN bit in each LSA is 1, ASBR2 does not add the routes carried in these LSAs to its routing table.
In conclusion, because of the routing loop prevention mechanism, the ASBR cannot learn the OSPF routes from the peer ASBR. As a result, CE1 and CE3 cannot communicate with each other.
To address the preceding problem, use either of the following methods:
Disable the device from setting the DN bit to 1 in the LSAs when importing BGP routes into OSPF. For example, if ASBR1 does not set the DN bit to 1 when importing MP-BGP routes into OSPF. After ASBR2 receives these routes and finds that the DN bit in the LSAs carrying these routes is 0, ASBR2 will add the routes to its routing table.
Disable the device from checking the DN bit after receiving LSAs. For example, ASBR1 sets the DN bit to 1 in LSAs when importing MP-BGP routes into OSPF. ASBR2, however, does not check the DN bit after receiving these LSAs.
The preceding methods can be used based on specific types of LSAs. You can configure a sender to determine whether to set the DN bit to 1 or configure a receiver to determine whether to check the DN bit in the Type 3 LSAs based on the router ID of the device that generates the Type 3 LSAs.
In the inter-AS VPN Option A scenario shown in Figure 5, the ASBRs are fully meshed and run OSPF. ASBR2 may receive the Type 3, Type 5, or Type 7 LSAs generated on ASBR4. If ASBR2 is not configured to check the DN bit in the LSAs, ASBR2 will accept the Type 3 LSAs, which may cause routing loops, as described in Routing Loop Prevention. ASBR2 will deny the Type 5 or Type 7 LSAs, because the VPN route tags carried in the LSAs are the same as the default VPN route tag of the OSPF process on ASBR2.
To address the routing loop problem caused by Type 3 LSAs, ASBR2 can be disabled from checking the DN bit in the Type 3 LSAs generated by devices with OSPF router ID 1.1.1.1 and router ID 3.3.3.3. After the configuration is complete, if ASBR2 receives Type 3 LSAs sent by ASBR4 with router ID 4.4.4.4, ASBR2 checks the DN bit and denies these Type 3 LSAs because the DN bit is set to 1.
Sham Link
OSPF sham links are unnumbered P2P links between two PEs over an MPLS VPN backbone network.
Generally, BGP extended community attributes carry routing information over the MPLS VPN backbone between BGP peers. OSPF running on the other PE can use the routing information to generate inter-area routes from PEs to CEs.
In Figure 6, if an intra-area OSPF link exists between the network segments of local and remote CEs, the route over the intra-area OSPF link is an intra-area route and takes precedence over the inter-area route over the MPLS VPN backbone network. As a result, VPN traffic is always forwarded through the intra-area route rather than through the backbone network. To prevent such a problem, an OSPF sham link can be established between PEs so that the routes that pass through the MPLS VPN backbone network also become OSPF intra-area routes and take precedence.
A sham link is a link between two VPN instances. Each VPN instance contains the address of an end-point of a sham link. The address is a loopback address with the 32-bit mask in the VPN address space on the PE.
After a sham link is established between two PEs, the PEs become neighbors on the sham link and exchange routing information.
A sham link functions as a P2P link within an area. Users can select a route from the sham link and intra-area route link by adjusting the metric.
Multi-VPN-Instance CE
OSPF multi-instance generally runs on PEs. Devices that run OSPF multi-instance within user LANs are called Multi-VPN-Instance CEs (MCEs).
Compared with OSPF multi-instance running on PEs:
MCEs do not need to support OSPF-BGP association.
MCEs establish one OSPF instance for each service. Different virtual CEs transmit different services, which ensures LAN security at a low cost.
MCEs implement different OSPF instances on a CE. The key to implementing MCEs is to disable loop detection and calculate routes directly. MCEs also use the received LSAs with the DN-bit 1 for route calculation.