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

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

OSPF VPN

Definition

As an extension of OSPF, OSPF VPN 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 use OSPF 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 OSPF Between PEs and CEs

In BGP/MPLS VPN, Multi-Protocol BGP (MP-BGP) is used to transmit routing information between PEs, whereas OSPF is used to learn and advertise routes between PEs and CEs.

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 number of the protocol types that CEs must support.

  • Similarly, running OSPF 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 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.

In Figure 6-11, CE1, CE3, and CE4 belong to VPN 1, and the numbers following OSPF refer to the process IDs of the multiple OSPF instances running on PEs.

Figure 6-11 Networking with OSPF running between PEs and CEs

The routes that PE1 receives from CE1 are advertised to CE3 and CE4 as follows:

  1. PE1 imports OSPF routes of CE1 into BGP and converts them to BGP VPNv4 routes.

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

  3. PE2 imports the 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 non-backbone or backbone areas (Area 0). PEs can function only as ABRs.

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 deployed between the PEs and the backbone area. Figure 6-12 shows the networking for configuring OSPF areas between PEs and CEs.

Figure 6-12 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. The backbone area in Site 1 is separated from the VPN backbone area. To ensure that the backbone areas are contiguous, a virtual link is configured between PE1 and CE1.

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

  • Each OSPF 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 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 based on 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 6-12 Domain ID relationships and corresponding generated routes

Relationship Between Local and Remote Domain IDs

Comparison Between Local and Remote Domain IDs

Type of the Generated Routes

Both the local and remote domain IDs are null.

Equal

Inter-area routes

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

Equal

Inter-area routes

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

Not equal

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 OSPF and BGP learn routes from each other.

Figure 6-13 Networking for OSPF VPN routing loops

In Figure 6-13, on PE1, OSPF imports a BGP route destined for 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 10.1.1.1/32 as the destination address and PE1 as the next hop and advertises the route to PE2. Therefore, PE2 learns an OSPF route with 10.1.1.1/32 as the destination address and CE1 as the next hop.

Similarly, CE1 also learns an OSPF route with 10.1.1.1/32 as the destination address and PE2 as the next hop. PE1 learns an OSPF route with 10.1.1.1/32 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 hop of the routes from PE1 and PE2 to 10.1.1.1/32 is CE1, which leads to a routing loop.

In addition, the priority 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 with the OSPF route, and the OSPF route with 10.1.1.1/32 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 OSPF is deleted, which causes the OSPF route to be withdrawn. As a result, no OSPF route exists in the routing table, and the BGP route becomes active again. This cycle causes route flapping.

OSPF VPN provides a few solutions to routing loops, as described in Table 6-13.

Table 6-13 Routing loop prevention measures

Feature

Definition

Function

DN-bit

It is a flag bit used by OSPF multi-instance processes to prevent routing loops.

After OSPF multi-instance is configured on the ME device (a PE or an MCE), the ME device sets the DN-bit of generated Type 3, Type 5, or Type 7 LSAs to 1 and retains the DN-bit (0) of other LSAs.

When calculating routes, the OSPF multi-instance process on the ME device ignores LSAs with DN-bit 1, which prevents the ME device from receiving the LSAs that are advertised by itself. In Figure 6-13, PE1 generates Type 3, Type 5, or Type 7 LSAs, sets their DN-bit to 1, and advertises these LSAs to CE1. After receiving these LSAs, CE1 forwards them to PE2. Upon reception of these LSAs, PE2 ignores them and does not forward them back to PE1, which prevents a routing loop.

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 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 the local route tag, the PE ignores the LSA, which prevents routing loops.

Default route

It is a route whose destination IP address and mask are both 0.

Default routes are used to forward traffic from CEs or sites where CEs reside to the VPN backbone network.

Disabling Routing Loop Prevention

Exercise caution when disabling routing loop prevention because it may cause 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 runs between ASBRs to transmit VPN routes, the remote ASBR may fail to learn the OSPF routes sent by the local ASBR due to the routing loop prevention mechanism.

In Figure 6-14, inter-AS VPN Option A is deployed with OSPF running between PE1 and CE1. CE1 sends VPN routes to CE2.

Figure 6-14 Networking for inter-AS VPN Option A

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

  2. After receiving 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 carrying DN bit 1.

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

The routing loop prevention mechanism prevents ASBR2 from learning the OSPF routes sent from ASBR1. As a result, CE1 cannot communicate with CE3.

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

  • Disable the device from setting the DN bit to 1 in the LSAs when importing BGP routes into OSPF. For example, if ASBR1 does not set the DN bit to 1 when importing MP-BGP routes into OSPF. After ASBR2 receives these routes and finds that the DN bit in the LSAs carrying these routes is 0, ASBR2 will add the routes to its routing table.

  • Disable the device from checking the DN bit after receiving 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 receiving these LSAs.

The preceding methods can be used based on specific types of 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 6-15, the four ASBRs are fully meshed and run OSPF. ASBR2 may receive the Type 3, Type 5, or Type 7 LSAs generated on ASBR4. ASBR2 denies 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. If ASBR2 is disabled from checking the DN bit in the LSAs, ASBR2 accepts the Type 3 LSAs, and routing loops may occur.

To address the routing loop problem caused by Type 3 LSAs, ASBR2 can be disabled from checking the DN bit in the Type 3 LSAs generated by devices with router ID 1.1.1.1 and router ID 3.3.3.3. After the configuration is complete, if ASBR2 receives Type 3 LSAs sent by ASBR4 with router ID 4.4.4.4, ASBR2 checks the DN bit and denies these Type 3 LSAs because the DN bit is set to 1.

Figure 6-15 Networking for fully meshed ASBRs in the inter-AS VPN Option A scenario

Sham Link

OSPF sham links are unnumbered P2P links between two PEs over an MPLS VPN backbone network.

Generally, BGP extended community attributes carry routing information over the MPLS VPN backbone between BGP peers. OSPF running on the other PE can use the routing information to generate inter-area routes from PEs to CEs.

Figure 6-16 OSPF Sham link

In Figure 6-16, if an intra-area OSPF link exists between the network segments of local and remote CEs. Routes that pass through the intra-area route link and have higher priorities than inter-area routes that pass through the MPLS VPN backbone network. As a result, VPN traffic is always forwarded through the intra-area route instead of the backbone network. To prevent such a problem, an OSPF sham link can be established between PEs so that the routes that pass through the MPLS VPN backbone network also become OSPF intra-area routes and take precedence.

  • A sham link is a link between two VPN instances. Each VPN instance contains the address of an end-point of a sham link. The address is a loopback address with the 32-bit mask in the VPN address space on the PE.

  • After a sham link is established between two PEs, the PEs become neighbors on the sham link and exchange routing information.

  • A sham link functions as a P2P link within an area. Users can select a route from the sham link and intra-area route link by adjusting the metric.

Multi-VPN-Instance CE

OSPF multi-instance generally runs on PEs. Devices that run OSPF multi-instance within user LANs are called Multi-VPN-Instance CEs (MCEs).

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

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

  • MCEs establish one OSPF instance for each service. Different virtual CEs transmit different services, which ensures LAN security at a low cost.

  • MCEs implement different OSPF 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.

Translation
Download
Updated: 2019-01-04

Document ID: EDOC1100059473

Views: 14776

Downloads: 10

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