No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


ME60 V800R010C10SPC500 Feature Description - WAN Access 01

This is ME60 V800R010C10SPC500 Feature Description - WAN Access
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).



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.


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 7-6, 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.

Figure 7-6 Running OSPFv3 between PEs and CEs

CE1 advertises routes to CE3 and CE4 as follows:

  1. PE1 imports OSPF routes of CE1 into BGP and forms BGP VPNv4 routes.

  2. PE1 uses MP-BGP to advertise the BGP VPNv4 routes to PE2.

  3. PE2 imports the BGP VPNv6 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.

  • 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.

Table 7-7 Domain ID relationships and corresponding generated 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.

Figure 7-7 OSPFv3 VPN routing loops

In Figure 7-7, 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 Table 7-8.

Table 7-8 Routing loop prevention measures





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.

Updated: 2019-01-04

Document ID: EDOC1100059473

Views: 14729

Downloads: 10

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Previous Next