OSPFv3 VPN
Definition
As an extension to OSPFv3, OSPFv3 VPN multi-instance enables Provider Edges (PEs) and Customer Edges (CEs) in VPN networks to run OSPFv3 for interworking and use OSPFv3 to learn and advertise routes.
Purpose
As a widely used IGP, in most cases, OSPFv3 runs in VPNs. If OSPFv3 runs between PEs and CEs, and PEs use OSPFv3 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 OSPFv3 Between PEs and CEs
In BGP/MPLS VPN, Multi-Protocol BGP (MP-BGP) is used to transmit routing information between PEs, whereas OSPFv3 is used to learn and advertise routes between PEs and CEs.
Running OSPFv3 between PEs and CEs features the following benefits:
OSPFv3 is used in a site to learn routes. Running OSPFv3 between PEs and CEs can reduce the number of protocol types supported by CEs.
Similarly, running OSPFv3 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 the network, which originally uses OSPFv3 but not VPN on the backbone network begins to use BGP/MPLS VPN, running OSPFv3 between PEs and CEs facilitates the transition.
In Figure 1, CE1, CE3, and CE4 belong to VPN 1, and the numbers following OSPFv3 indicate the process IDs of the multiple OSPFv3 instances running on PEs.
CE1 advertises routes to CE3 and CE4 as follows:
PE1 imports OSPFv3 routes of CE1 into BGP and forms BGP VPNv6 routes.
PE1 uses MP-BGP to advertise the BGP VPNv6 routes to PE2.
PE2 imports the BGP VPNv4 routes into OSPFv3 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.
OSPFv3 Domain ID
If inter-area routes are advertised between local and remote OSPFv3 areas, these areas are considered to be in the same OSPFv3 domain.
Domain IDs identify domains.
Each OSPFv3 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 OSPFv3 instance does not have specific domain IDs, its ID is considered as null.
Before advertising the remote routes sent by BGP to CEs, PEs need to determine the type of OSPFv3 routes (Type 3 or Type 5) to be advertised to CEs based on the domain IDs, as described in Table 1.
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 routes.
Relationship Between Local and Remote Domain IDs |
Type of the Generated Routes |
|---|---|
Both are null. |
Inter-area routes |
The remote domain ID equals the local primary domain ID or one of the local secondary domain IDs. |
Inter-area routes |
The remote domain ID is different from the local primary domain ID or any of 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 when OSPFv3 and BGP learn routes from each other.
In Figure 2, on PE1, OSPFv3 imports a BGP route destined for 2001:db8:1::1/64 and then generates and advertises a Type 5 or Type 7 LSA to CE1. Then, CE1 learns an OSPFv3 route with 2001:db8:1::1/64 as the destination address and PE1 as the next hop and advertises the route to PE2. Therefore, PE2 learns an OSPFv3 route with 2001:db8:1::1/64 as the destination address and CE1 as the next hop.
Similarly, CE1 also learns an OSPFv3 route with 2001:db8:1::1/64 as the destination address and PE2 as the next hop. PE1 learns an OSPF route with 2001:db8:1::1/64 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 hops of the routes from PE1 and PE2 to 2001:db8:1::1/64 are CE1, which leads to a routing loop.
In addition, the priority of an OSPFv3 route is higher than that of a BGP route. Therefore, on PE1 and PE2, BGP routes to 2001:db8:1::1/64 are replaced with the OSPFv3 route, and the OSPFv3 route with 2001:db8:1::1/64 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 OSPFv3 is deleted, which causes the OSPFv3 route to be withdrawn. As a result, no OSPFv3 route exists in the routing table, and the BGP route becomes active again. This cycle causes route flapping.
OSPFv3 VPN provides a few solutions to routing loops, as described in Table 2.
Feature |
Definition |
Function |
|---|---|---|
DN-bit |
It is a flag bit used by OSPFv3 multi-instance processes to prevent routing loops. |
When advertising the generated Type 3, Type 5, or Type 7 LSAs to CEs, PEs set the DN-bit of these LSAs to 1. PEs retain the DN-bit (0) of other LSAs. When calculating routes, the OSPFv3 multi-instance process of a PE ignores LSAs with DN-bit 1, which prevents the PE from receiving the LSAs that are advertised by itself. |
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 the PEs that receive BGP routes and generate OSPFv3 LSAs. |
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, which prevents routing loops. |
Default route |
It is a route whose destination IP address and mask are both 0. |
PEs do not calculate default routes. Default routes are used to forward the traffic from CEs or the sites where CEs reside to the VPN backbone network. |
Multi-VPN-Instance CE
OSPFv3 multi-instance generally runs on PEs. Devices that run OSPFv3 multi-instance within user LANs are called Multi-VPN-Instance CEs (MCEs).
Compared with OSPFv3 multi-instance running on PEs, MCEs have the following characteristics:
MCEs do not need to support OSPFv3-BGP association.
MCEs establish one OSPFv3 instance for each service. Different virtual CEs transmit different services, which ensures LAN security at a low cost.
MCEs implement different OSPFv3 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.