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

Reminder

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

upgrade

CLI-based Configuration Guide - IP Unicast Routing

AR100, AR120, AR150, AR160, AR200, AR1200, AR2200, AR3200, and AR3600 V200R009

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).
OSPF VPN

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, and PEs advertise VPN routes to CEs using OSPF, CEs do not need to support other routing protocols for interworking with PEs. This simplifies 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 in a site to learn routes. Running OSPF between PEs and CEs can reduce the protocol types that CEs must support, reducing the requirements for CEs.

  • Similarly, running OSPF both in a site and between PEs and CEs simplifies the workload of network administrators. In this manner, network administrators do not have to be familiar with multiple protocols.

  • 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 process IDs of multiple OSPF instances running on PEs.

Figure 5-9 Running OSPF between PEs and CEs

The process of advertising routes of CE1 to CE3 and CE4 is as follows:

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

  2. PE1 advertises BGP VPNv4 routes to PE2 using MP-BGP.

  3. 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 as 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 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 used to implement logical connection between the PEs and the backbone area, as shown in Figure 5-10.

Figure 5-10 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. As a result, the backbone area in Site 1 is separated from the VPN backbone area. Therefore, a virtual link is configured between PE1 and CE1 to ensure that the backbone area is 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 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, 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 according to domain IDs.

  • If local domain IDs are the same as or compatible with remote domain IDs in BGP routes, PEs advertise Type 3 routes.

  • Otherwise, PEs advertise Type 5 or Type 7 routes.

Table 5-12 Domain ID

Comparison Between Local and Remote Domain IDs

Local and Remote Domain IDs the Same Or Not

Route Type

Both the local and remote domain IDs are null.

The same

Inter-area route

The remote domain ID is the same as the local primary domain ID or one of the local secondary domain IDs.

The same

Inter-area route

The remote domain ID is different from the local primary domain ID or any of the local secondary domain IDs.

Not the same

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

Between PEs and CEs, routing loops may occur when OSPF and BGP learn routes from each other.

Figure 5-11 OSPF VPN routing loops

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 and advertises a Type 5 or Type 7 LSA to CE1. Then, CE1 learns an OSPF route with the destination address and next hop being 10.1.1.1/32 and PE1 respectively, and 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. Thus, 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 the OSPF route. That is, the OSPF route with the destination address and next hop being 10.1.1.1/32 and CE1 respectively is active in the routing tables of PE1 and PE2.

The BGP route then becomes inactive, and thus the LSA generated when this route is imported by OSPF is deleted. This causes the OSPF route to be withdrawn. As a result, there is no OSPF route in the routing table, and the BGP route becomes active again. This cycle causes route flapping.

OSPF VPN provides a solution to this problem, as shown in Table 5-13.

Table 5-13 Routing loop prevention

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 advertising the generated Type 3, Type 5, or Type 7 LSAs to CEs, PEs set the DN-bit of these LSAs to 1 and the DN-bit of other LSAs to 0.

When calculating routes, the OSPF multi-instance process of a PE ignores the LSAs with the DN-bit being 1. This avoids routing loops that occur when PEs learn the self-originated LSAs from CEs.

VPN Route Tag

The VPN route tag is carried in Type 5 or Type 7 LSAs generated by PEs according to the received BGP private route.

Not transmitted in BGP extended community attributes, the VPN route tag is valid only on the 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 that in the local LSA, the PE ignores this LSA. Consequently, routing loops are avoided.

Default Route

A route with the destination address and mask being all 0s is a default route.

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.

Disabling Routing Loop Prevention

Disabling routing loop prevention may cause routing loops. Exercise caution when performing this operation.

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 remote ASBR may be unable to learn the OSPF routes sent by the local ASBR due to the routing loop prevention mechanism.

As shown in Figure 5-12, inter-AS VPN Option A is deployed. OSPF is running between PE1 and CE1. CE1 sends VPN routes to CE2.

Figure 5-12 Networking diagram for inter-AS VPN Option A

  1. PE1 learns routes to CE1 using the OSPF process in a VPN instance, and imports these routes into MP-BGP, and sends the MP-BGP routes to ASBR1.

  2. After having received 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 in which the DN bit is set to 1.

  3. ASBR2 learns these LSAs using OSPF and checks the DN bit of each LSA. After learning that the DN bit in each LSA is set to 1, ASBR2 does not add the routing information carried in these LSAs to its routing table.

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.

To address the preceding problem, use either of the following methods:

  • A device does not set the DN bit to 1 in the LSAs when importing BGP routes into OSPF. For example, ASBR1 does not set the DN bit to 1 when importing MP-BGP routes into OSPF. After ASBR2 receives these routes and checks that the DN bit in the LSAs carrying these routes is 0, ASBR2 adds the routes to its routing table.

  • A device does not check the DN bit after having received 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 having received these LSAs.

The preceding 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 Type 3 LSAs.

In the inter-AS VPN Option A scenario shown in Figure 5-13, the four 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, 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, configure ASBR2 not to check the DN bit in the Type 3 LSAs that are generated by devices with the router ID 10.1.1.1 and the router ID 10.3.3.3. After the configuration is complete, 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.

Figure 5-13 Networking diagram for full-mesh ASBRs in the inter-AS VPN Option A scenario

Multi-VPN-Instance CE

OSPF multi-instance generally runs on PEs. The devices that run OSPF multi-instance within the LANs of users are called Multi-VPN-Instance CEs (MCEs), that is, multi-instance CEs.

Compared with OSPF multi-instance running on PEs, MCEs have the following characteristics:

  • MCEs do not need to support OSPF-BGP synchronization.

  • MCEs establish different OSPF instances for different services. Different virtual CEs transmit different services. This solves the security issue of the LAN at a low cost.

  • MCEs implement different OSPF multi-instances on a CE. The key to implementing MCEs is to disable loop detection and calculate routes directly. That is, MCEs also use the received LSAs with the DN-bit set to 1 for route calculation.

Translation
Download
Updated: 2019-05-17

Document ID: EDOC1000174069

Views: 140267

Downloads: 280

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