OSPF VPN
Definition
As an extension of OSPF, OSPF VPN multi-instance 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, PEs can advertise VPN routes to CEs using OSPF, CEs do not need to support other routing protocols for interworking with PEs, 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 routes are 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 CEs.
Similarly, running OSPF both in a site and between PEs and frees network administrators from getting familiarity with multiple protocols, simplifying the workload of them.
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.
As shown in Figure 5-9, CE1, CE3, and CE4 belong to VPN 1, and 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 similar to the preceding process.
Configuring OSPF Areas Between PEs and CEs
OSPF areas between PEs and CEs can be either non-backbone areas 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 5-10.
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 backbone areas are contiguous.
OSPF Domain ID
If inter-area routes are advertised between local and remote OSPF areas, these areas are considered to be in the same OSPF domain.
Domain IDs identify and differentiate 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 specified 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 |
Identical Local and Remote Domain IDs |
Type of Routes to Be Advertised |
|---|---|---|
Both the local and remote domain IDs are NULL. |
Yes |
Inter-area route |
The remote domain ID is the same as the local primary domain ID or one of the local secondary domain IDs. |
Yes |
Inter-area route |
The remote domain ID is different from the local primary domain ID and all local secondary domain IDs. |
No |
If the local area is not an 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.
As shown in Figure 5-11, on PE1, OSPF imports a BGP route whose destination address is 10.1.1.1/32, and then generates a Type 5 or Type 7 LSA and advertises it to CE1. Then, CE1 learns an OSPF route with the destination address and next hop being 10.1.1.1/32 and PE1 respectively. CE1 advertises the route to PE2. In this manner, PE2 learns an OSPF route with the destination address and next hop being 10.1.1.1/32 and CE1 respectively.
Similarly, CE1 also learns an OSPF route with the destination address and next hop being 10.1.1.1/32 and PE2 respectively. PE1 learns an OSPF route with the destination address and next hop being 10.1.1.1/32 and CE1 respectively.
As a result, CE1 has two equal-cost routes with next hops being PE1 and PE2 respectively, and the next hops of the routes from PE1 and PE2 to 10.1.1.1/32 are CE1. A routing loop occurs.
In addition, the preference 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 by OSPF routes. That is, the OSPF routes with the destination address and next hop being 10.1.1.1/32 and CE1 respectively are active in the routing tables of PE1 and PE2.
The BGP routes then become inactive, and therefore the LSAs generated when OSPF imports the routes are deleted. 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 shown in Table 5-14.
Feature |
Definition |
Function |
|---|---|---|
DN-bit |
To prevent routing loops, an OSPF multi-instance process uses one bit as a flag bit, which is called the DN-bit. |
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 incoming 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. |
PEs do not calculate default routes. Default routes are used to forward traffic from CEs or from sites where CEs reside to the VPN backbone network. |
Disabling Routing Loop Prevention
Exercise caution when disabling routing loop prevention as it increases the likelihood of 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 is running between ASBRs to transmit VPN routes, the routing loop prevention mechanism disables the remote ASBR from learning the OSPF routes sent by the local ASBR.
Figure 5-12 illustrates an inter-AS VPN in Option A mode. OSPF runs between PE1 and CE1. Assume that CE1 sends VPN routes to CE2.
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.
After receiving the MP-BGP routes, ASBR1 imports them into the OSPF process in a VPN instance and 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.
Due to the routing loop prevention mechanism, ASBR2 cannot learn the OSPF routes sent from ASBR1, causing CE1 to be unable to communicate with CE3.
The following methods are provided to resolve 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-13, 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, as described in Figure 5-13. 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, 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. The devices that run OSPF multi-instance within LANs of users are called multi-VPN-instance CEs (MCEs).
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.