OSPF VPN
Definition
OSPF VPN enables Provider Edges (PEs) and Customer Edges (CEs) within VPNs to run OSPF. This is useful for interworking and allows OSPF to learn and advertise VPN routes.
Purpose
As a widely used IGP, in most cases, OSPF runs in VPNs. When OSPF runs between PEs and CEs and PEs are advertising VPN routes using OSPF, CEs do not need to support other routing protocols for interworking, simplifying the management and configuration of CEs.
Running OSPF Between PEs and CEs
In BGP/MPLS VPN, routing information is transmitted between PEs using Multi-Protocol BGP (MP-BGP), whereas routing information is learned and advertised between PEs and CEs using OSPF.
Running OSPF between PEs and CEs has the following benefits:
OSPF is used within a site to learn routes. Running OSPF between PEs and CEs can reduce the protocol types that CEs must support, lowering the requirements on the CEs.
Running OSPF both within a site and between PEs and CEs frees network administrators from getting familiarity with multiple protocols, simplifying the workload of them.
Running OSPF between PEs and CEs facilitates the transition from a non-VPN backbone network to a BGP/MPLS VPN network.
As shown in Figure 1, CE1, CE3, and CE4 belong to VPN 1. The numbers following OSPF refer to the IDs of OSPF multi-instance processes running on PEs.
To advertise routes of CE1 to CE3 and CE4:
PE1 imports OSPF routes of CE1 into BGP and generates BGP VPNv4 routes.
PE1 advertises BGP VPNv4 routes to PE2 using MP-BGP.
PE2 imports 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.
Configuring OSPF Areas Between PEs and CEs
OSPF areas between PEs and CEs can be either non-backbones or backbone areas (Area 0). A PE can only be an area border router (ABR).
In the extended application of OSPF VPN, the MPLS VPN backbone network serves as Area 0. OSPF requires that backbone areas (Area 0) be contiguous. Therefore, Area 0 in 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 the MPLS VPN backbone network. If no physical link is available to directly connect PEs to Area 0 in the VPN site, a virtual link can be used to implement logical connection between them, as shown in Figure 2.
In Figure 2, a non-backbone area (Area 1) is configured between PE1 and CE1, and a backbone area (Area 0) is configured in Site 1. As a result, the backbone area in Site 1 is isolated from the VPN backbone area. Therefore, a virtual link is configured between PE1 and CE1 to ensure that the backbone areas are continuous.
OSPF Domain ID
If inter-area routes are advertised between local and remote OSPF areas, these areas are considered in the same OSPF domain.
Important characteristics of OSPF domain IDs include:
Domain IDs identify and differentiate different domains.
Each OSPF domain has one or more domain IDs, one of which is a primary ID with the others being secondary IDs.
If an OSPF instance does not have a specific domain ID, NULL is used as its domain ID.
Before a PE advertises the BGP routes learned from remote PEs to CEs, the PE checks the domain IDs carried in the BGP routes to determine the type of OSPF routes (Type 3, Type 5, or Type 7) to be advertised.
If local domain IDs are the same as or compatible with the remote domain IDs carried in the BGP routes, the PE advertises Type 3 routes. Otherwise, the PE advertises Type 5 or Type 7 routes.
Comparison Between Local and Remote Domain IDs |
Advertised Route Type |
|---|---|
Both the local and remote domain IDs are null. |
Inter-area route |
The remote domain ID is the same as the local primary domain ID or one of the local secondary domain IDs. |
Inter-area route |
The remote domain ID is different from the local primary domain ID and all the local secondary domain IDs. |
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 if OSPF and BGP learn routes from each other.
- PE1 uses OSPF to import a BGP route whose destination address is 10.1.1.1/32.
- OSPF then generates a Type 5 or Type 7 LSA and advertises it to CE1.
- CE1 learns an OSPF route with the destination address of 10.1.1.1/32 and the next hop of PE1 and advertises the route to PE2.
- PE2 learns an OSPF route with the destination address and next hop being 10.1.1.1/32 and CE1 respectively.
- Likewise, CE1 learns an OSPF route with the destination address of 10.1.1.1/32 and the next hop of PE2, and PE1 learns an OSPF route with the destination address of 10.1.1.1/32 and the next hop of CE1.
- In this way, CE1 has learned two equal-cost routes, with the next hop of one being PE1 and the other being PE2. The next hops of the routes from PE1 and PE2 to 10.1.1.1/32 are both CE1. That is, a routing loop occurs.
The preference of an OSPF route is higher than that of a BGP route. Therefore, BGP routes on PE1 and PE2 to 10.1.1.1/32 are replaced by the OSPF routes. The OSPF routes with the destination address of 10.1.1.1/32 and the next hop of CE1 are active in the routing tables of PE1 and PE2.
The BGP routes then become inactive, causing the deletion of the LSAs generated when OSPF imports the routes. As a result, the active OSPF routes are withdrawn, and the BGP route becomes active again. The above process occurs repeatedly, leading to route flapping.
OSPF VPN provides a solution to this problem, as described in the following table.
Feature |
Definition |
Function |
|---|---|---|
DN bit |
The DN bit is a 1-bit flag used by an OSPF multi-instance process to prevent routing loops. |
When a PE advertises generated Type 3, Type 5, or Type 7 LSAs to CEs, it sets the DN bit of these LSAs to 1 and retains the default value 0 for the DN bit of other LSAs. When calculating routes, the OSPF multi-instance process of the PE ignores LSAs with the DN bit set to 1. This prevents the PE from learning the self-originated LSAs from CEs, thereby avoiding routing loops. |
VPN route tag |
The VPN route tag is carried in Type 5 or Type 7 LSAs generated by PEs according to received BGP private routes. The VPN route tag is valid only on the PEs that receive BGP routes and generate OSPF LSAs. It is not transmitted in BGP extended community attributes. |
When a PE detects that the VPN route tag in the received LSA is the same as that in the local LSA, the PE ignores this LSA. This prevents routing loops. |
Default route |
A default route is a route with an all-0 destination address and an all-0 subnet mask. |
Default routes are used to forward traffic from CEs or from the sites where CEs reside to the VPN backbone network. PEs do not calculate default routes. |
Disabling Routing Loop Prevention
Exercise caution when disabling routing loop prevention as it increases the likelihood of routing loops.
After routing loop prevention is enabled, OSPF routing loops will not occur in VPN sites during BGP/OSPF route exchanges.
In an inter-AS VPN Option A scenario, if OSPF runs between ASBRs to transmit VPN routes, the remote ASBR will be unable to learn the OSPF routes sent by the local ASBR due to the routing loop prevention mechanism.
Figure 4 illustrates an inter-AS VPN in Option A mode. OSPF runs between PE1 and CE1. Assume that CE1 sends VPN routes to CE2.
In Figure 4:
PE1 learns routes to CE1 through the OSPF process within a VPN instance, imports these routes into MP-BGP, and then sends the MP-BGP routes to ASBR1.
ASBR1 receives the MP-BGP routes, imports the routes into the OSPF process within a VPN instance, and then generates Type 3, Type 5, or Type 7 LSAs with the DN bit set to 1.
When learning these LSAs using OSPF, ASBR2 checks the DN-bit in the LSAs. When detecting that the DN-bit in the LSAs is 1, ASBR2 ignores these LSAs.
Because ASBR2 cannot learn OSPF routes sent from ASBR1, CE1 cannot communicate with CE3.
The following methods are provided to solve this problem:
Method 1: Disable devices from setting the DN bit to 1 when importing BGP routes into OSPF. For example, ASBR1 is disabled from setting the DN-bit to 1 when importing BGP routes into OSPF. When ASBR2 receives these routes and detects that the DN-bit in the LSAs carrying these routes is 0, ASBR2 uses these LSAs to calculate routes.
Method 2: Disable devices from checking the DN-bit in received LSAs. For example, ASBR2 is disabled from checking the DN-bit in received LSAs. ASBR1 sets the DN-bit to 1 in LSAs when importing MP-BGP routes into OSPF. ASBR2, however, does not check the DN-bit when receiving these LSAs and uses these LSAs to calculate routes.
The two methods can be used more flexibly based on specific types of LSAs. For Type 3 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 LSAs.
In an inter-AS VPN Option A scenario as shown in Figure 5, four ASBRs are fully meshed and run OSPF. ASBR2 may receive Type 3, Type 5, or Type 7 LSAs generated on ASBR4. If ASBR2 is disabled from checking the DN-bit in the LSAs, ASBR2 will accept the Type 3 LSAs, and routing loops will occur. 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 loops caused by Type 3 LSAs, you can disable the check of the DN-bit only for the Type 3 LSAs that are generated by devices with the router ID 10.1.1.1 or 10.3.3.3. With the check disabled in such a way, if ASBR2 receives Type 3 LSAs sent by ASBR4 with the router ID 10.4.4.4, ASBR2 will check the DN-bit and deny these Type 3 LSAs because the DN-bit is set to 1.
Multi-VPN-Instance CE
OSPF multi-instance generally runs on PEs. Multi-VPN-Instance CEs (MCEs) are devices that run OSPF multi-instance within user LANs.
Compared with OSPF multi-instance running on PEs, MCEs have the following characteristics:
Support of OSPF-BGP synchronization is not required.
A separate OSPF instance is created for each service. That is, different virtual CEs transmit traffic for different services. This is a low-cost solution for LAN security issues.
Different OSPF multi-instances are implemented on a CE. To implement OSPF multi-instances, routing loop detection needs to be disabled and route calculation is performed directly. That is, MCEs also use the received LSAs with the DN bit set to 1 for route calculations.