MPLS L3VPN is a L3VPN technology used to interconnect geographically dispersed VPN sites. MPLS L3VPN uses BGP to advertise VPN routes and uses MPLS to forward VPN packets over a service provider backbone. MPLS L3VPN provides flexible networking modes, excellent scalability, and convenient support for MPLS QoS and MPLS TE.

Basic MPLS L3VPN architecture

As shown in Figure 1, a basic MPLS L3VPN architecture has the following types of devices:

· Customer edge device—A CE device resides on a customer network and has one or more interfaces directly connected to a service provider network. It does not support MPLS.

· Provider edge device—A PE device resides at the edge of a service provider network and is connected to one or more CEs. All MPLS VPN services are processed on PEs.

· Provider device—A P device is a core device on a service provider network. It is not directly connected to any CEs. A P device has only basic MPLS forwarding capability and does not handle VPN routing information.

Figure 1 Basic MPLS L3VPN architecture

‌

MPLS L3VPN concepts

Site

A site has the following features:

· A site is a group of IP systems with IP connectivity that does not rely on any service provider networks.

· The classification of a site depends on the topology relationship of the devices, rather than the geographical positions. However, the devices at a site are, in most cases, adjacent to each other geographically.

· The devices at a site can belong to multiple VPNs, which means that a site can belong to multiple VPNs.

· A site is connected to a provider network through one or more CEs. A site can contain multiple CEs, but a CE can belong to only one site.

Sites connected to the same provider network can be classified into different sets by policies. Only the sites in the same set can access each other through the provider network. Such a set is called a VPN.

VPN instance

VPN instances implement route isolation, data independence, and data security for VPNs.

A VPN instance has the following components:

· A separate Label Forwarding Information Base (LFIB).

· An IP routing table.

· Interfaces bound to the VPN instance.

· VPN instance administration information, including route distinguishers (RDs), route targets (RTs), and route filtering policies.

To associate a site with a VPN instance, bind the VPN instance to the PE's interface connected to the site. A site can be associated with only one VPN instance, and different sites can be associated with the same VPN instance. A VPN instance contains the VPN membership and routing rules of associated sites.

VPN-IPv4 address

Each VPN independently manages its address space. The address spaces of VPNs might overlap. For example, if both VPN 1 and VPN 2 use the addresses on subnet 10.110.10.0/24, address space overlapping occurs.

BGP cannot process overlapping VPN address spaces. For example, if both VPN 1 and VPN 2 use the subnet 10.110.10.0/24 and each advertise a route destined for the subnet, BGP selects only one of them. This results in the loss of the other route.

Multiprotocol BGP (MP-BGP) can solve this problem by advertising VPN-IPv4 addresses (also called VPNv4 addresses).

Figure 2 VPN-IPv4 address structure

‌

As shown in Figure 2, a VPN-IPv4 address consists of 12 bytes. The first eight bytes represent the RD, followed by a four-byte IPv4 prefix. The RD and the IPv4 prefix form a unique VPN-IPv4 prefix.

An RD can be in one of the following formats:

· When the Type field is 0, the Administrator subfield occupies two bytes, the Assigned number subfield occupies four bytes, and the RD format is 16-bit AS number:32-bit user-defined number. For example, 100:1.

· When the Type field is 1, the Administrator subfield occupies four bytes, the Assigned number subfield occupies two bytes, and the RD format is 32-bit IPv4 address:16-bit user-defined number. For example, 172.1.1.1:1.

· When the Type field is 2, the Administrator subfield occupies four bytes, the Assigned number subfield occupies two bytes, and the RD format is 32-bit AS number:16-bit user-defined number, where the minimum value of the AS number is 65536. For example, 65536:1.

NOTE:

When you configure an RD at the CLI, you can specify an AS number in integer format or dotted decimal notation. For example, 65536:1 and 1.0:1 specify the same RD.

To guarantee global uniqueness for a VPN-IPv4 address, do not set the Administrator subfield to any private AS number or private IP address.

Route target attribute

MPLS L3VPN uses route target (also called VPN target) community attributes to control the advertisement of VPN routing information. A VPN instance on a PE supports the following types of route target attributes:

· Export target attribute—A PE sets the export target attribute for VPN-IPv4 routes learned from directly connected sites before advertising them to other PEs.

· Import target attribute—A PE checks the export target attribute of VPN-IPv4 routes received from other PEs. If the export target attribute matches the import target attribute of a VPN instance, the PE adds the routes to the routing table of the VPN instance.

Route target attributes define which sites can receive VPN-IPv4 routes, and from which sites a PE can receive routes.

Like RDs, route target attributes can be one of the following formats:

· 16-bit integer-format AS number:32-bit user-defined number, for example, 101:3.

· 16-bit dotted-format AS number:32-bit user-defined number, for example, 0.1:1. The value range for the AS number is 0.1 to 0.65535.

· 32-bit IP address:16-bit user-defined number, for example, 192.168.122.15:1.

· 32-bit integer-format AS number:16-bit user-defined number, for example, 65536:1. The minimum value of the AS number is 65536.

· 32-bit dotted-format AS number:16-bit user-defined number, for example, 10.1:1. The minimum value of the AS number is 1.0.

MP-BGP

MP-BGP supports multiple address families, including IPv4 multicast address family and VPN-IPv4 address family.

In MPLS L3VPN, MP-BGP advertises VPN-IPv4 routes for VPN sites between PEs.

MPLS L3VPN route advertisement

In a basic MPLS L3VPN, CEs and PEs are responsible for advertising VPN routing information. P routers maintain only the routes within the backbone. A PE maintains only routing information for directly connected VPNs, rather than for all VPNs.

VPN routing information is advertised through the path local CE—ingress PE—egress PE—remote CE.

Route advertisement from the local CE to the ingress PE

The CE advertises standard IPv4 routing information to the ingress PE over a static route, RIP route, OSPF route, IS-IS route, EBGP route, or IBGP route.

Route advertisement from the ingress PE to the egress PE

The ingress PE performs the following operations:

1. Adds RDs and route target attributes to these standard IPv4 routes to create VPN-IPv4 routes.

2. Saves the VPN-IPv4 routes to the routing table of the VPN instance created for the CE.

3. Advertises the VPN-IPv4 routes to the egress PE through MP-BGP.

PEs can also exchange labels through BGP EVPN routes. For more information, see EVPN Configuration Guide.

Route advertisement from the egress PE to the remote CE

After receiving the VPN-IPv4 routes, the egress PE performs the following operations:

1. Compares the routes' export target attributes with the local import target attributes.

2. Adds the routes to the routing table of the VPN instance if the export and local import target attributes match each other.

3. Restores the VPN-IPv4 routes to the original IPv4 routes.

4. Advertises those routes to the connected CE over a static route, RIP route, OSPF route, IS-IS route, EBGP route, or IBGP route.

MPLS L3VPN packet forwarding

In a basic MPLS L3VPN (within a single AS), a PE adds the following information into VPN packets:

· Outer tag—Identifies the public tunnel from the local PE to the remote PE. The public tunnel can be an LSP, an MPLS TE tunnel, or a GRE tunnel. Based on the outer tag, a VPN packet can be forwarded along the public tunnel to the remote PE. For a GRE public tunnel, the outer tag is the GRE encapsulation. For an LSP or MPLS TE tunnel, the outer tag is an MPLS label.

NOTE:

In the current software version, the device does not support using GRE/IPv6 tunnels as public tunnels for MPLS L3VPN.

‌

· Inner label—Identifies the remote VPN site. The remote PE uses the inner label to forward packets to the target VPN site. MP-BGP advertises inner labels for VPN-IPv4 routes among PEs.

Figure 3 VPN packet forwarding

‌

As shown in Figure 3, a VPN packet is forwarded from Site 1 to Site 2 by using the following process:

2. Site 1 sends an IP packet with the destination address 1.1.1.2. CE 1 transmits the packet to PE 1.

3. PE 1 performs the following operations:

a. Finds the matching VPN route based on the inbound interface and destination address of the packet.

b. Labels the packet with both the inner label and the outer tag.

c. Forwards the packet to the public tunnel.

4. P devices forward the packet to PE 2 by the outer tag.

¡ If the outer tag is an MPLS label, the label is removed from the packet at the penultimate hop.

¡ If the outer tag is GRE encapsulation, PE 2 removes the GRE encapsulation.

5. PE 2 performs the following operations:

a. Uses the inner label to find the matching VPN instance to which the destination address of the packet belongs.

b. Looks up the routing table of the VPN instance for the output interface.

c. Removes the inner label and forwards the packet out of the interface to CE 2.

6. CE 2 transmits the packet to the destination through IP forwarding.

When two sites of a VPN are connected to the same PE, the PE directly forwards packets between the two sites through the VPN routing table without adding any tag or label.

MPLS L3VPN networking schemes

In MPLS L3VPNs, route target attributes are used to control the advertisement and reception of VPN routes between sites. They work independently and can be configured with multiple values to support flexible VPN access control and implement multiple types of VPN networking schemes.

Basic VPN networking scheme

In the simplest case, all users in a VPN form a closed user group. They can forward traffic to each other but cannot communicate with any user outside the VPN.

For the basic VPN networking scheme, you must assign a route target to each VPN for identifying the export target attribute and import target attribute of the VPN. Moreover, this route target cannot be used by any other VPNs.

Figure 4 Network diagram for basic VPN networking scheme

‌

As shown in Figure 4, the route target for VPN 1 is 100:1, while that for VPN 2 is 200:1. The two VPN 1 sites can communicate with each other, and the two VPN 2 sites can communicate with each other. However, the VPN 1 sites cannot communicate with the VPN 2 sites.

Hub and spoke networking scheme

The hub and spoke networking scheme is suitable for a VPN where all users must communicate with each other through an access control device.

In a hub and spoke network as shown in Figure 5, configure route targets as follows:

· On spoke PEs (PEs connected to spoke sites), set the export target to Spoke and the import target to Hub.

· On the hub PE (PE connected to the hub site), use two interfaces that each belong to a different VPN instance to connect the hub CE. One VPN instance receives routes from spoke PEs and has the import target set to Spoke. The other VPN instance advertises routes to spoke PEs and has the export target set to Hub.

These route targets rules produce the following results:

· The hub PE can receive all VPN-IPv4 routes from spoke PEs.

· All spoke PEs can receive VPN-IPv4 routes advertised by the hub PE.

· The hub PE advertises the routes learned from a spoke PE to the other spoke PEs so the spoke sites can communicate with each other through the hub site.

· The import target attribute of a spoke PE is different from the export target attribute of any other spoke PE. Any two spoke PEs do not directly advertise VPN-IPv4 routes to each other. Therefore, they cannot directly access each other.

Figure 5 Network diagram for hub and spoke network

‌

A route in Site 1 is advertised to Site 2 by using the following process:

2. Spoke-CE 1 advertises a route in Site 1 to Spoke-PE 1.

3. Spoke-PE 1 changes the route to a VPN-IPv4 route and advertises the VPN-IPv4 route to Hub-PE through MP-BGP.

4. Hub-PE adds the VPN-IPv4 route into the routing table of VPN 1-in, changes it to the original IPv4 route, and advertises the IPv4 route to Hub-CE.

5. Hub-CE advertises the IPv4 route back to Hub-PE.

6. Hub-PE adds the IPv4 route to the routing table of VPN 1-out, changes it to a VPN-IPv4 route, and advertises the VPN-IPv4 route to Spoke-PE 2 through MP-BGP.

7. Spoke-PE 2 changes the VPN-IPv4 route to the original IPv4 route, and advertises the IPv4 route to Site 2.

After spoke sites exchange routes through the hub site, they can communicate with each other through the hub site.

Extranet networking scheme

The extranet networking scheme allows specific resources in a VPN to be accessed by users not in the VPN.

In this networking scheme, if a VPN instance needs to access a shared site, the export target attribute and the import target attribute of the VPN instance must be contained in the import target attribute and the export target attribute of the VPN instance of the shared site, respectively.

Figure 6 Network diagram for extranet networking scheme

‌

As shown in Figure 6, route targets configured on PEs produce the following results:

· PE 3 can receive VPN-IPv4 routes from PE 1 and PE 2.

· PE 1 and PE 2 can receive VPN-IPv4 routes advertised by PE 3.

· Site 1 and Site 3 of VPN 1 can communicate with each other, and Site 2 of VPN 2 and Site 3 of VPN 1 can communicate with each other.

· PE 3 advertises neither the VPN-IPv4 routes received from PE 1 to PE 2 nor the VPN-IPv4 routes received from PE 2 to PE 1 (routes learned from an IBGP neighbor are not advertised to any other IBGP neighbor). Therefore, Site 1 of VPN 1 and Site 2 of VPN 2 cannot communicate with each other.

Inter-AS VPN

In an inter-AS VPN networking scenario, multiple sites of a VPN are connected to multiple ISPs in different ASs, or to multiple ASs of an ISP.

Inter AS-VPN provides the following solutions:

· VRF-to-VRF connections between ASBRs—This solution is also called inter-AS option A.

· EBGP redistribution of labeled VPN-IPv4 routes between ASBRs—ASBRs advertise VPN-IPv4 routes to each other through MP-EBGP. This solution is also called inter-AS option B.

· Multihop EBGP redistribution of labeled VPN-IPv4 routes between PE routers—PEs advertise VPN-IPv4 routes to each other through MP-EBGP. This solution is also called inter-AS option C.

Inter-AS option A

In this solution, PEs of two ASs are directly connected, and each PE is also the ASBR of its AS. Each PE treats the other as a CE and advertises unlabeled IPv4 unicast routes through EBGP. The PEs associate a VPN instance with a minimum of one interface.

Figure 7 Network diagram for inter-AS option A

‌

As shown in Figure 7, in VPN 1, routes are advertised from CE 1 to CE 3 by using the following process:

2. PE 1 advertises the VPN routes learned from CE 1 to ASBR 1 through MP-IBGP.

3. ASBR 1 performs the following operations:

a. Adds the routes to the routing table of the VPN instance whose import target attribute matches the export target attribute of the routes.

b. Advertises the routes as IPv4 unicast routes to its CE (ASBR 2) through EBGP.

4. ASBR 2 adds the IPv4 unicast routes to the routing table of the VPN instance that is bound to the receiving interface, and advertises the routes to PE 3 through MP-IBGP.

5. PE 3 advertises the received routes to CE 3.

Packets forwarded within an AS are VPN packets that carry two labels. Packets forwarded between ASBRs are common IP packets.

Inter-AS option A is easy to carry out because no special configuration is required on the PEs acting as the ASBRs.

However, it has limited scalability because the PEs acting as the ASBRs must manage all the VPN routes and create VPN instances on a per-VPN basis. This leads to excessive VPN-IPv4 routes on the PEs. Associating a separate interface with each VPN also requires additional system resources.

Inter-AS option B

In this solution, two ASBRs use MP-EBGP to exchange VPN-IPv4 routes that they obtain from the PEs in their respective ASs.

Figure 8 Network diagram for inter-AS option B

‌

As shown in Figure 8, in VPN 1, routes are advertised from CE 1 to CE 3 by using the following process:

2. PE 1 advertises the VPN routes learned from CE 1 to ASBR 1 through MP-IBGP.

Assume that the inner label assigned by PE 1 for the routes is L1.

3. ASBR 1 advertises the VPN-IPv4 routes to ASBR 2 through MP-EBGP.

Before advertising the routes, ASBR 1 modifies the next hop as its own address, assigns a new inner label (L2) to the routes, and associates L1 with L2.

4. ASBR 2 advertises the VPN-IPv4 routes to PE 3 through MP-IBGP.

Before advertising the routes, ASBR 2 modifies the next hop as its own address, assigns a new inner label (L3) to the routes, and associates L2 with L3.

5. PE 3 advertises the received routes to CE 3.

A packet is forwarded from CE 3 to CE 1 by using the following process:

6. PE 3 encapsulates the received packet with two labels, and forwards the encapsulated packet to ASBR 2.

One of the labels is L3, and the other is the outer tag for the public tunnel from PE 3 to ASBR 2.

7. ASBR 2 removes the outer tag, replaces L3 with L2, and forwards the packet to ASBR 1.

Packets between ASBR 1 and ASBR 2 carry only one inner label.

8. ASBR 1 replaces L2 with L1, adds the outer tag of the public tunnel from ASBR 1 to PE 1, and forwards the packet to PE 1.

9. PE 1 removes the inner label and outer tag and forwards the packet to CE 1.

In this solution, ASBRs must receive all inter-AS VPN routes. Therefore, ASBRs cannot filter incoming VPN-IPv4 routes by route targets.

Inter-AS option B has better scalability than option A. However, it requires that ASBRs maintain and advertise VPN routes.

Inter-AS option C

The Inter-AS option A and option B solutions require that the ASBRs maintain and advertise VPN-IPv4 routes. When every AS needs to exchange a great amount of VPN routes, the ASBRs might become bottlenecks, which hinders network extension. Inter-AS option C has better scalability because it makes PEs directly exchange VPN-IPv4 routes.

In this solution, PEs exchange VPN-IPv4 routes over a multihop MP-EBGP session. Each PE must have a route to the peer PE and a label for the route so that the inter-AS public tunnel between the PEs can be set up. Inter-AS option C sets up a public tunnel by using the following methods:

· Method 1:

a. The PE and the ASBR within an AS establish a public tunnel by using a label distribution protocol such as LDP.

b. The local and remote ASBRs advertise labeled IPv4 unicast routes through BGP to establish an inter-AS public tunnel.

Labeled IPv4 unicast route advertisement refers to the process of assigning MPLS labels to IPv4 unicast routes and advertising IPv4 unicast routes and their labels.

· Method 2:

In method 2, the PE and ASBR within an AS do not need to establish an IBGP peer relationship.

c. The local ASBR redistributes IGP routes to the BGP routing table, assigns labels to the routes, and advertises the labeled routes to the remote ASBR.

d. The remote ASBR redistributes BGP routes to the IGP routing table.

e. The local and remote PEs then can learn the route s to reach each other. After the PEs learn the routes to each other, they establish a public tunnel by using a label distribution protocol such as LDP.

The following is an example of configuring inter-AS option C by using method 1.

Figure 9 Network diagram for inter-AS option C (method 1)

‌

As shown in Figure 9, in VPN 1, routes are advertised from CE 1 to CE 3 by using the following process:

2. PE 1 advertises the VPN routes learned from CE 1 as VPN-IPv4 routes to PE 3 through multihop MP-EBGP.

Assume that the inner label assigned by PE 1 for the routes is Lx.

3. PE 3 advertises the received routes to CE 3.

Setting up an inter-AS public tunnel is difficult in this solution. A public tunnel, for example, the one from PE 3 to PE 1, is set up by using the following process:

4. Within AS 100, the public tunnel from ASBR 1 to PE 1 is set up by using a label distribution protocol, for example, LDP.

Assume that the outgoing label for the public tunnel on ASBR 1 is L1.

5. ASBR 1 advertises labeled IPv4 unicast routes to ASBR 2 through EBGP.

The route destined for PE 1 and the label (L2) assigned by ASBR 1 for the route are advertised from ASBR 1 to ASBR 2. The next hop of the route is ASBR 1. The public tunnel from ASBR 2 to ASBR 1 is set up. The incoming label for the public tunnel on ASBR 1 is L2.

6. ASBR 2 advertises labeled IPv4 unicast routes to PE 3 through IBGP.

The route destined for PE 1 and the label (L3) assigned by ASBR 2 for the route are advertised from ASBR 2 to PE 3. The next hop for the route is ASBR 2. The public tunnel from PE 3 to ASBR 2 is set up. The incoming label for the public tunnel on ASBR 2 is L3, and the outgoing label is L2.

7. MPLS packets cannot be forwarded directly from PE 3 to ASBR 2. Within AS 200, the public tunnel from PE 3 to ASBR 2 is required to be set up hop by hop through a label distribution protocol, for example, LDP.

Assume that the outgoing label for the public tunnel on PE 3 is Lv.

After route advertisement and public tunnel setup, a packet is forwarded from CE 3 to CE 1 by using the following process:

8. PE 3 performs the following routing table lookups for the packet:

a. Finds a matching route with next hop PE 1 and inner label Lx, and encapsulates the packet with label Lx.

b. Finds the route to PE 1 with next hop ASBR 2 and label L3, and encapsulates the packet with label L3 as the outer label.

c. Finds the route to ASBR 2 with outgoing label Lv, and encapsulates the packet with label Lv as the outmost label.

9. AS 200 transmits the packet to ASBR 2 by the outmost label.

10. ASBR 2 removes the outmost label, replaces L3 with L2, and forwards the packet to ASBR 1.

11. ASBR 1 replaces L2 with L1, and forwards the packet.

12. AS 100 transmits the packet to PE 1 by the outer label.

13. PE 1 removes the outer label, and forwards the packet to CE 1 according to the inner label Lx.

As shown in Figure 10, to improve scalability, you can specify a route reflector (RR) in each AS to exchange VPN-IPv4 routes with PEs in the same AS. The RR in each AS maintains all VPN-IPv4 routes. The RRs in two ASs establish a multihop MP-EBGP session to advertise VPN-IPv4 routes.

Figure 10 Network diagram for inter-AS option C using RRs

‌

Carrier's carrier

If a customer of an MPLS L3VPN service provider is also a service provider:

· The MPLS L3VPN service provider is called the provider carrier or the Level 1 carrier.

· The customer is called the customer carrier or the Level 2 carrier.

This networking model is referred to as carrier's carrier.

The PEs of the Level 2 carrier directly exchange customer networks over a BGP session. The Level 1 carrier only learns the backbone networks of the Level 2 carrier, without learning customer networks.

For packets between customer networks to travel through the Level 1 carrier, the PE of the Level 1 carrier and the CE of the Level 2 carrier must assign labels to the backbone networks of the Level 2 carrier. The CE of the Level 2 carrier is a PE within the Level 2 carrier network.

Follow these guidelines to assign labels:

· If the PE and the CE are in the same AS, you must configure IGP and LDP between them. If they are in different ASs, you must configure MP-EBGP to assign labels to IPv4 unicast routes exchanged between them.

· You must enable MPLS on the CE of the Level 2 carrier regardless of whether the PE and CE are in the same AS.

A Level 2 carrier can be an ordinary ISP or an MPLS L3VPN service provider.

As shown in Figure 11, when the customer carrier is an ordinary ISP, its PEs and CEs run IGP to communicate with each other. The PEs do not need to run MPLS. PE 3 and PE 4 exchange customer network routes (IPv4 unicast routes) through an IBGP session.

Figure 11 Scenario where the Level 2 carrier is an ISP

‌

As shown in Figure 12, when the customer carrier is an MPLS L3VPN service provider, its PEs and CEs must run IGP and LDP to communicate with each other. PE 3 and PE 4 exchange customer network routes (VPN-IPv4 routes) through an MP-IBGP session.

Figure 12 Scenario where the Level 2 carrier is an MPLS L3VPN service provider

‌

NOTE:

As a best practice, establish equal cost LSPs between the Level 1 carrier and the Level 2 carrier if equal cost routes exist between them.

‌

Nested VPN

The nested VPN technology exchanges VPNv4 routes between PEs and CEs of the ISP MPLS L3VPN and allows a customer to manage its own internal VPNs. Figure 13 shows a nested VPN network. On the service provider's MPLS VPN network, there is a customer VPN named VPN A. The customer VPN contains two sub-VPNs, VPN A-1 and VPN A-2.

The service provider PEs consider the customer's network as a common VPN user and do not join any sub-VPNs. The service provider CE devices (CE 1 and CE 2) exchange VPNv4 routes including sub-VPN routing information with the service provider PEs, which implements the propagation of the sub-VPN routing information throughout the customer network.

The nested VPN technology supports both symmetric networking and asymmetric networking. Sites of the same VPN can have the same number or different numbers of internal VPNs. Nested VPN also supports multiple-level nesting of internal VPNs.

Figure 13 Network diagram for nested VPN

‌

In a nested VPN network, routing information is propagated by using the following process:

2. After receiving VPN routes from customer CEs, a customer PE advertises VPN-IPv4 routes to the provider CEs through MP-BGP.

3. The provider CEs advertise the VPN-IPv4 routes to a provider PE through MP-BGP.

4. After receiving a VPN-IPv4 route, the provider PE keeps the customer's internal VPN information, and appends the customer's MPLS VPN attributes on the service provider network. It replaces the RD of the VPN-IPv4 route with the RD of the customer's MPLS VPN on the service provider network. It also adds the export route-target (ERT) attribute of the customer's MPLS VPN on the service provider network to the extended community attribute list of the route. The internal VPN information for the customer is maintained on the provider PE.

5. The provider PE advertises VPN-IPv4 routes carrying the comprehensive VPN information to the other PEs of the service provider.

6. After another provider PE receives the VPN-IPv4 routes, it matches the VPN-IPv4 routes to the import targets of its local VPNs. Each local VPN accepts routes of its own and advertises them to provider CEs. If a provider CE (such as CE 7 and CE 8 in Figure 13) is connected to a provider PE through an IPv4 connection, the PE advertises IPv4 routes to the CE. If it is a VPN-IPv4 connection (a customer MPLS VPN network), the PE advertises VPN-IPv4 routes to the CE.

7. After receiving VPN-IPv4 routes from the provider CE, a customer PE matches those routes to local import targets. Each customer VPN accepts only its own routes and advertises them to connected customer CEs (such as CE 3, CE 4, CE 5, and CE 6 in Figure 13).

Multirole host

Typically, hosts in the same VPN can communicate with each other, and those in different VPNs cannot. However, a host or server in a site might need to access VPNs in addition to the VPN to which the host or server belongs. To simplify configuration, you can use the multirole host feature.

The multirole host feature enables a PE to use PBR to provide multiple VPN access for a host or server. The host or server is called a multirole host.

Figure 14 Network diagram

‌

As shown in Figure 14, the multirole host in site 1 needs to access both VPN 1 and VPN 2. Other hosts in site 1 only need to access VPN 1. To configure the multirole host feature, configure PE 1 as follows:

· Create VPN instances vpn1 and vpn2 for VPN 1 and VPN 2, respectively.

· Associate VPN instance vpn1 with the interface connected to CE 1.

· Configure PBR to route packets from CE 1 first by the routing table of the associated VPN instance (vpn1). Then, if no matching route is found, route the packets according to the routing table of VPN instance vpn2. This configuration ensures that packets from Site 1 can be forwarded in both VPN 1 and VPN 2.

· Configure a static route for VPN instance vpn2 to reach the multirole host. Specify the next hop of the route as the IP address of CE 1 and specify the VPN instance to which the next hop belongs as VPN 1. This configuration ensures that packets from VPN 2 can be routed to the multirole host.

Configure static routes for all VPN instances that the multirole host needs to access, except the associated VPN instance.

IMPORTANT:

IP addresses in all VPNs that the multirole host can access must not overlap.

‌

HoVPN

Hierarchy of VPN (HoVPN), also called Hierarchy of PE (HoPE), prevents PEs from being bottlenecks and is applicable to large-scale VPN deployment.

HoVPN divides PEs into underlayer PEs (UPEs) or user-end PEs, and superstratum PEs (SPEs) or service provider-end PEs. UPEs and SPEs have different functions and comprise a hierarchical PE. The HoPE and common PEs can coexist in an MPLS network.

Figure 15 Basic architecture of HoVPN

‌

As shown in Figure 15, UPEs and SPEs play the following different roles:

· A UPE is directly connected to CEs. It provides user access. It maintains the routes of directly connected VPN sites. It does not maintain the routes of the remote sites in the VPN, or it only maintains their summary routes. A UPE assigns inner labels to the routes of its directly connected sites, and advertises the labels along with VPN routes to the SPE through MP-BGP. A UPE features high access capability, small routing table capacity, and low forwarding performance.

· An SPE is connected to UPEs and resides inside the service provider network. It manages and advertises VPN routes. It maintains all the routes of the VPNs connected through UPEs, including the routes of both the local and remote sites. An SPE advertises routes along with labels to UPEs, including the default routes of VPN instances or summary routes and the routes permitted by the routing policy. By using routing policies, you can control which sites in a VPN can communicate with each other. An SPE features large routing table capacity, high forwarding performance, and fewer interface resources.

Either MP-IBGP or MP-EBGP can run between SPE and UPE. When MP-IBGP runs between SPE and UPEs, the SPE acts as the RR of multiple UPEs and reflects routes between UPEs.

HoVPN supports HoPE recursion:

· An HoPE can act as a UPE to form a new HoPE with an SPE.

· An HoPE can act as an SPE to form a new HoPE with multiple UPEs.

HoVPN supports multilevel recursion. In HoPE recursion, the concepts of SPE and UPE are relative. A PE might be the SPE of its underlayer PEs and a UPE of its SPE at the same time.

Figure 16 Recursion of HoPEs

‌

Figure 16 shows a three-level HoPE. The PE in the middle is called the middle-level PE (MPE). MP-BGP runs between SPE and MPE, and between MPE and UPE.

MP-BGP advertises the following routes:

· All the VPN routes of UPEs to the SPEs.

· The default routes of the VPN instance of the SPEs or the VPN routes permitted by the routing policies to the UPEs.

The SPE maintains the VPN routes of all sites in the HoVPN. Each UPE maintains only VPN routes of its directly connected sites. An MPE has fewer routes than the SPE but has more routes than a UPE.

OSPF VPN extension

This section describes the OSPF VPN extension. For more information about OSPF, see Layer 3—IP Routing Configuration Guide.

OSPF for VPNs on a PE

If OSPF runs between a CE and a PE to exchange VPN routes, the PE must support multiple OSPF instances to create independent routing tables for VPN instances. Each OSPF process is bound to a VPN instance. Routes learned by an OSPF process are added into the routing table of the bound VPN instance.

OSPF area configuration between a PE and a CE

The OSPF area between a PE and a CE can be either a non-backbone area or a backbone area.

In the OSPF VPN extension application, the MPLS VPN backbone is considered the backbone area (area 0). The area 0 of each site must be connected to the MPLS VPN backbone (physically connected or logically connected through a virtual link) because OSPF requires that the backbone area be contiguous.

BGP/OSPF interaction

If OSPF runs between PEs and CEs, each PE redistributes BGP routes to OSPF and advertises the routes to CEs through OSPF. OSPF considers the routes redistributed from BGP as external routes but the OSPF routes actually belong to the same OSPF domain. This problem can be resolved by configuring the same domain ID for sites in an OSPF domain.

Figure 17 Network diagram for BGP/OSPF interaction

‌

As shown in Figure 17, CE 11, CE 21, and CE 22 belong to the same VPN and the same OSPF domain.

Before domain ID configuration, VPN 1 routes are advertised from CE 11 to CE 21 and CE 22 by using the following process:

2. PE 1 redistributes OSPF routes from CE 11 into BGP, and advertises the VPN routes to PE 2 through BGP.

3. PE 2 redistributes the BGP routes to OSPF, and advertises them to CE 21 and CE 22 in AS External LSAs (Type 5) or NSSA External LSAs (Type 7).

After domain ID configuration, VPN 1 routes are advertised from CE 11 to CE 21 and CE 22 by using the following process:

4. PE 1 redistributes OSPF routes into BGP, adds the domain ID to the redistributed BGP VPNv4 routes as a BGP extended community attribute, and advertises the routes to PE 2.

5. PE 2 compares the domain ID in the received routes with the locally configured domain ID. If they are the same and the received routes are intra-area or inter-area routes, OSPF advertises these routes in Network Summary LSAs (Type 3). Otherwise, OSPF advertises these routes in AS External LSAs (Type 5) or NSSA External LSAs (Type 7).

Routing loop avoidance

As shown in Figure 18, Site 1 is connected to two PEs. When a PE advertises VPN routes learned from MP-BGP to Site 1 through OSPF, the routes might be received by the other PE. This results in a routing loop.

Figure 18 Network diagram for routing loop avoidance

‌

OSPF VPN extension uses the following tags to avoid routing loops:

· Down bit, or DN bit. An OSPF process for a VPN instance uses the DN bit to avoid routing loops as follows:

When a PE redistributes BGP routes into OSPF and creates Type 3 LSAs, Type 5 LSAs, or Type 7 LSAs, it sets the DN bit for the LSAs. When receiving the LSAs advertised by CE 11, the other PE ignores the LSAs whose DN bit is set to avoid routing loops.

· VPN route tag, the external route tag in redistributed routes of a VPN instance. An OSPF process for a VPN instance uses the route tag to avoid routing loops as follows:

The two PEs connected to the same site use the same route tag. When a PE redistributes BGP routes into OSPF and creates Type 5 or 7 LSAs, it adds the route tag to the LSAs. When receiving the Type 5 or 7 LSAs advertised by CE 11, the other PE compares the route tag in the LSAs against the local route tag. If they are the same, the PE ignores the LSAs to avoid routing loops.

OSPF sham link

As shown in Figure 19, two routes exist between Site 1 and Site 2 of VPN 1:

· A route over MPLS backbone—It is an inter-area route if PE 1 and PE 2 have the same domain ID, or is an external route if PE 1 and PE 2 are configured with no domain ID or with different domain IDs.

· A direct route between CEs—It is an intra-area route that is called a backdoor link.

VPN traffic is always forwarded through the backdoor link because it has a higher priority than the inter-area route. To forward VPN traffic over the inter-area route, you can establish a sham link between the two PEs to change the inter-area route to an intra-area route.

Figure 19 Network diagram for sham link

‌

A sham link is considered a virtual point-to-point link within a VPN and is advertised in a Type 1 LSA. It is identified by the source IP address and destination IP address that are the local PE address and the remote PE address in the VPN address space. Typically, the source and destination addresses are loopback interface addresses with a 32-bit mask.

To add a route to the destination IP address of a sham link to a VPN instance, the remote PE must advertise the source IP address of the sham link as a VPN-IPv4 address through MP-BGP. To avoid routing loops, a PE does not advertise the sham link's destination address.

BGP AS number substitution and SoO attribute

BGP detects routing loops by examining AS numbers. If EBGP runs between PE and CE, you must assign different AS numbers to geographically different sites or configure the BGP AS number substitution feature to ensure correct transmission of routing information.

The BGP AS number substitution feature allows geographically different CEs to use the same AS number. If the AS_PATH of a route contains the AS number of a CE, the PE replaces the AS number with its own AS number before advertising the route to that CE.

After you enable the BGP AS number substitution feature, the PE performs BGP AS number substitution for all routes and re-advertises them to connected CEs in the peer group.

Figure 20 Application of BGP AS number substitution and SoO attribute

‌

As shown in Figure 20, both Site 1 and Site 2 use the AS number 800. AS number substitution is enabled on PE 2 for CE 2. Before advertising updates received from CE 1 to CE 2, PE 2 substitutes its own AS number 100 for the AS number 800. In this way, CE 2 can correctly receive the routing information from CE 1.

However, the AS number substitution feature also introduces a routing loop in Site 2 because route updates originated from CE 3 can be advertised back to Site 2 through PE 2 and CE 2. To remove the routing loop, you can configure the same SoO attribute on PE 2 for CE 2 and CE 3. PE 2 adds the SoO attribute to route updates received from CE 2 or CE 3, and checks the SoO attribute of route updates to be advertised to CE 2 or CE 3. The SoO attribute of the route updates from CE 3 is the same as the SoO attribute for CE 2, and PE 2 does not advertise route updates to CE 2.

For more information about the SoO attribute, see Layer 3—IP Routing Configuration Guide.

MPLS L3VPN FRR

MPLS L3VPN Fast Reroute (FRR) is applicable to a dual-homed scenario, as shown in Figure 21. By using BFD to detect the primary link, FRR enables a PE to use the backup link when the primary link fails. The PE then selects a new optimal route, and uses the new optimal route to forward traffic.

MPLS L3VPN FRR supports the following types of backup:

· VPNv4 route backup for a VPNv4 route.

· VPNv4 route backup for an IPv4 route.

· IPv4 route backup for a VPNv4 route.

VPNv4 route backup for a VPNv4 route

Figure 21 Network diagram

As shown in Figure 21, configure FRR on the ingress node PE 1, and specify the backup next hop for VPN 1 as PE 3. When PE 1 receives a VPNv4 route to CE 2 from both PE 2 and PE 3, it uses the route from PE 2 as the primary link, and the route from PE 3 as the backup link.

Configure BFD for LSPs or MPLS TE tunnels on PE 1 to detect the connectivity of the public tunnel from PE 1 to PE 2. When the tunnel PE 1—PE 2 operates correctly, traffic from CE 1 to CE 2 goes through the path CE 1—PE 1—PE 2—CE 2. When the tunnel fails, the traffic goes through the path CE 1—PE 1—PE 3—CE 2.

In this scenario, PE 1 is responsible for primary link detection and traffic switchover.

For more information about BFD for LSPs or MPLS TE tunnels, see "Configuring MPLS OAM."

VPNv4 route backup for an IPv4 route

Figure 22 Network diagram

As shown in Figure 22, configure FRR on the egress node PE 2, and specify the backup next hop for VPN 1 as PE 3. When PE 2 receives an IPv4 route from CE 2 and a VPNv4 route from PE 3 (both routes are destined for VPN 1 connected to CE 2), PE 2 uses the IPv4 route as the primary link, and the VPNv4 route as the backup link.

PE 2 uses ARP or echo-mode BFD to detect the connectivity of the link from PE 2 to CE 2. When the link operates correctly, traffic from CE 1 to CE 2 goes through the path CE 1—PE 1—PE 2—CE 2. When the link fails, PE 2 switches traffic to the link PE 2—PE 3—CE 2, and traffic from CE 1 to CE 2 goes through the path CE 1—PE 1—PE 2—PE 3—CE 2. This avoids traffic interruption before route convergence completes (switching to the link CE 1—PE 1—PE 3—CE 2).

In this scenario, PE 2 is responsible for primary link detection and traffic switchover.

IPv4 route backup for a VPNv4 route

Figure 23 Network diagram

‌

As shown in Figure 23, configure FRR on PE 1, and specify the backup next hop for VPN 1 as CE 2. When PE 1 receives an IPv4 route from CE 2 and a VPNv4 route from PE 2 (both routes are destined for VPN 1 connected to CE 2), PE 1 uses the VPNv4 route as the primary link, and the IPv4 route as the backup link.

Configure BFD for LSPs or MPLS TE tunnels on PE 1 to detect the connectivity of the public tunnel from PE 1 to PE 2. When the tunnel operates correctly, traffic from CE 1 to CE 2 goes through the path CE 1—PE 1—PE 2—CE 2. When the tunnel fails, the traffic goes through the path CE 1—PE 1—CE 2.

In this scenario, PE 1 is responsible for primary link detection and traffic switchover.

Protocols and standards

· RFC 3107, Carrying Label Information in BGP-4

· RFC 4360, BGP Extended Communities Attribute

· RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs)

· RFC 4577, OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

MPLS L3VPN tasks at a glance

Unless otherwise indicated, configure MPLS L3VPN on PEs.

To configure MPLS L3VPN, perform the following tasks:

1. Configuring MPLS L3VPN basics

a. Configuring VPN instances

b. Configuring routing between a PE and a CE

c. Configuring routing between PEs

d. (Optional.) Configuring BGP VPNv4 route control

e. (Optional.) Enabling MPLS IP packet fragmentation

2. Configuring advanced MPLS L3VPN networks

Choose the following tasks as needed:

¡ Configuring inter-AS VPN

Perform this task when sites of a VPN are connected to different ASs of an ISP.

¡ Configuring nested VPN

Deploy the nest VPN when a large number of VPNs exist and you want to hide from the outside of the customer internal VPNs.

¡ Configuring multirole host

Multirole host allows a host or server in a site to access multiple VPNs by configuring PBR on the PE.

¡ Configuring HoVPN

HoVPN prevents PEs from being bottlenecks and is applicable to large-scale VPN deployment.

3. (Optional.) Specifying the VPN label processing mode on the egress PE

4. (Optional.) Configuring MPLS L3VPN FRR

5. (Optional.) Configuring a TTL processing mode for tunnels associated with a VPN instance

6. (Optional.) Controlling route advertisement and reception in an MPLS L3VPN network

¡ Configuring an OSPF sham link

¡ Configuring BGP AS number substitution and SoO attribute

¡ Configuring the AIGP attribute

¡ Configuring BGP RT filtering

Perform this task to reduce the number of routes advertised in an MPLS L3VPN.

¡ Configuring the BGP additional path feature

Perform this task to enable BGP to advertise multiple routes with the same prefix and different next hops to a peer or peer group to shorten the traffic interruption time.

¡ Configuring the rule for adding BGP routes to the IP routing table and the route advertisement rule for VPN instances

¡ Enabling the VPN Prefix ORF feature

¡ Configuring route replication

¡ Enabling redistribution of multiple same-prefix routes with the same RD

¡ Enabling prioritized withdrawal of specific routes

Perform this task to configure BGP to send the withdrawal messages of specific routes prior to other routes to achieve fast switchover of traffic and reduce the traffic interruption time.

7. (Optional.) Maintaining MPLS L3VPN networks

¡ Enabling SNMP notifications for MPLS L3VPN

¡ Enabling logging for BGP route flapping

Prerequisites for MPLS L3VPN

Before you configure basic MPLS L3VPN, perform the following tasks:

1. Configure an IGP on the PEs and P devices to ensure IP connectivity within the MPLS backbone.

2. Configure basic MPLS for the MPLS backbone.

3. Configure MPLS LDP on the PEs and P devices to establish LDP LSPs.

Configuring VPN instances

All VPN instance configurations are performed on PEs.

Creating a VPN instance

About this task

A VPN instance is a collection of the VPN membership and routing rules of its associated site. A VPN instance might correspond to more than one VPN.

Restrictions and guidelines

You can configure an RD in VPN instance view and each address family view of the VPN instance. The RD configured in address family view takes precedence over the RD configured in VPN instance view. An address family uses the RD configured in VPN instance view only when no RD is configured in the address family view.

Editing an RD will delete some configuration related to the VPN instance from the BGP process. Please be cautious.

Follow these restrictions and guidelines when deleting RDs:

· When you delete the RD configured in VPN instance view, settings configured in an address family view of the BGP-VPN instance will be deleted if no RD is configured in the address family view. For example, when you delete the RD of VPN instance vpna, settings configured in BGP-VPN IPv4 unicast address family view of VPN instance vpna will be deleted if no RD is configured in VPN instance IPv4 address family view.

· When you delete an RD configured in an address family view of the VPN instance, settings configured in the address family view of the BGP-VPN instance will be deleted if the RD configured in the address family view is different from the RD configured in VPN instance view.

· If you configure an RD for an address family that inherits the RD of the VPN instance and the two RDs are different, settings configured in the address family view of the BGP-VPN instance will be deleted.

Procedure

1. Enter system view.

system-view

2. Set an MPLS label range for all VPN instances.

mpls per-vrf-label range minimum maximum

By default, no MPLS label range is configured for VPN instances.

3. Create a VPN instance and enter VPN instance view.

ip vpn-instance vpn-instance-name

4. Configure an RD for the VPN instance.

route-distinguisher route-distinguisher

By default, no RD is configured for a VPN instance.

5. (Optional.) Configure a description for the VPN instance.

description text

By default, no description is configured for a VPN instance.

6. (Optional.) Configure a VPN ID for the VPN instance.

vpn-id vpn-id

By default, no VPN ID is configured for a VPN instance.

7. (Optional.) Configure an SNMP context for the VPN instance.

snmp context-name context-name

By default, no SNMP context is configured.

8. Enter VPN instance IPv4 address family view.

address-family ipv4

9. Configure an RD.

route-distinguisher route-distinguisher

By default, no RD is configured.

10. Specify a label allocation mode.

apply-label { per-instance [ static static-label-value ] | per-route }

By default, BGP allocates a label to each next hop.

CAUTION:

Executing this command will re-advertise all routes in the VPN instance, which will cause temporary interruption of running services in the VPN instance. Please be cautious.

‌

Associating a VPN instance with a Layer 3 interface

Restrictions and guidelines

If an interface is associated with a VSI or cross-connect, the interface (including its subinterfaces) cannot associate with a VPN instance.

If a subinterface is associated with a VSI or cross-connect, the subinterface cannot associate with a VPN instance.

Procedure

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Associate a VPN instance with the interface.

ip binding vpn-instance vpn-instance-name

By default, an interface belongs to the public network and does not associate with a VPN instance.

CAUTION:

Associating an interface with a VPN instance or disassociating an interface from a VPN instance will clear the IP address and routing protocol settings on the interface.

‌

The ip binding vpn-instance command deletes the IP address of the current interface. You must reconfigure an IP address for the interface after configuring the command.

Configuring route related attributes for a VPN instance

Restrictions and guidelines

Configurations made in VPN instance view apply to both IPv4 VPN and IPv6 VPN.

IPv4 VPN prefers the configurations in VPN instance IPv4 address family view over the configurations in VPN instance view.

Prerequisites

Before you perform this task, create the routing policies to be used by this task. For information about routing policies, see Layer 3—IP Routing Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter VPN instance view or VPN instance IPv4 address family view.

¡ Enter VPN instance view.

ip vpn-instance vpn-instance-name

¡ Execute the following commands in sequence to enter VPN instance IPv4 address family view:

ip vpn-instance vpn-instance-name

address-family ipv4

3. Configure route targets.

vpn-target vpn-target&<1-8> [ both | export-extcommunity | import-extcommunity ]

By default, no route targets are configured.

4. Set the maximum number of active routes.

routing-table limit number { warn-threshold | simply-alert }

By default, the number of active routes in a VPN instance is not limited.

Setting the maximum number of active routes for a VPN instance can prevent the device from learning too many routes.

5. Apply an import routing policy.

import route-policy route-policy

By default, all routes matching the import target attribute are accepted.

6. Apply an export routing policy.

export route-policy route-policy

By default, routes to be advertised are not filtered.

7. Bind a tunnel policy to the VPN instance.

tnl-policy tunnel-policy-name

By default, no tunnel policy is bound to a VPN instance.

If no tunnel policy is bound to a VPN instance or the bound tunnel policy is not configured, the VPN instance uses the default load sharing policy for tunnel selection. For more information about tunnel policies and the default load sharing policy, see "Configuring tunnel policies."

Configuring routing between a PE and a CE

Configuring static routing between a PE and a CE

About this task

Perform this configuration on the PE. On the CE, configure a common static route.

For more information about static routing, see Layer 3—IP Routing Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Configure a static route for a VPN instance.

ip route-static vpn-instance s-vpn-instance-name dest-address { mask-length | mask } { interface-type interface-number [ next-hop-address ] | next-hop-address [ public ] [ track track-entry-number ] | vpn-instance d-vpn-instance-name next-hop-address [ track track-entry-number ] } [ permanent ] [ preference preference ] [ tag tag-value ] [ description text ]

Configuring RIP between a PE and a CE

About this task

Perform this configuration on the PE. On the CE, create a common RIP process.

For more information about RIP, see Layer 3—IP Routing Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Create a RIP process for a VPN instance and enter RIP view.

rip [ process-id ] vpn-instance vpn-instance-name

A RIP process can belong to only one VPN instance.

3. Redistribute BGP routes.

import-route bgp [ as-number ] [ allow-ibgp ] [ cost cost-value | route-policy route-policy-name | tag tag ] *

By default, RIP does not redistribute routes from other routing protocols.

4. Enable RIP on the interface attached to the specified network.

network network-address [ wildcard-mask ]

By default, RIP is disabled on an interface.

Configuring OSPF between a PE and a CE

About this task

Perform this configuration on the PE. On the CE, create a common OSPF process.

For more information about OSPF, see Layer 3—IP Routing Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Create an OSPF process for a VPN instance and enter the OSPF view.

ospf [ process-id | router-id router-id ] * vpn-instance vpn-instance-name

Parameter

Usage guidelines

router-id router-id

An OSPF process bound to a VPN instance does not use the public network router ID configured in system view. Therefore, you must specify a router ID when creating a process or configure an IP address for a minimum of one interface in the bound VPN instance.

vpn-instance vpn-instance-name

An OSPF process can belong to only one VPN instance.

If you delete a VPN instance, all OSPF processes of the VPN instance are also deleted.

‌

3. Redistribute BGP routes.

import-route bgp [ as-number ] [ allow-ibgp ] [ cost cost-value | nssa-only | route-policy route-policy-name | tag tag | type type ] *

By default, OSPF does not redistribute routes from other routing protocols.

If the vpn-instance-capability simple command is not configured for the OSPF process, the allow-ibgp keyword is optional to redistribute VPNv4 routes learned from MP-IBGP peers. In any other cases, if you do not specify the allow-ibgp keyword, the OSPF process does not redistribute VPNv4 routes learned from MP-IBGP peers.

4. (Optional.) Set an OSPF domain ID.

domain-id { domain-id [ secondary ] | null }

The default domain ID is 0.

Description

Restrictions and guidelines

The domain ID is carried in the routes of the OSPF process. When redistributing routes from the OSPF process, BGP adds the domain ID as an extended community attribute into BGP route.

An OSPF process can be configured with only one primary domain ID. Domain IDs of different OSPF processes can be the same.

All OSPF processes of a VPN must be configured with the same domain ID.

‌

5. (Optional.) Configure the type codes of OSPF extended community attributes.

ext-community-type { domain-id type-code1 | router-id type-code2 | route-type type-code3 }

The defaults are as follows:

¡ 0x0005 for Domain ID.

¡ 0x0107 for Router ID.

¡ 0x0306 for Route Type.

6. Set the DN bit in OSPF LSAs.

dn-bit-set { ase | nssa | summary }

By default, when a PE redistributes BGP routes into OSPF and creates OSPF LSAs, it sets the DN bit for the Network Summary LSA (Type 3 LSA).

7. Configure OSPF to check the DN bit in OSPF LSAs.

dn-bit-check { ase | nssa | summary }

By default, OSPF on a PE checks the DN bit of Network Summary LSA (Type 3 LSA).

8. Enable external route check for OSPF LSAs.

route-tag-check enable

By default, the external route check feature is enabled for OSPF LSAs.

9. Create an OSPF area and enter area view.

area area-id

10. Enable OSPF on the interface attached to the specified network in the area.

network ip-address wildcard-mask

By default, an interface neither belongs to any area nor runs OSPF.

Configuring IS-IS between a PE and a CE

About this task

Perform this configuration on the PE. On the CE, configure common IS-IS.

For more information about IS-IS, see Layer 3—IP Routing Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Create an IS-IS process for a VPN instance and enter IS-IS view.

isis [ process-id ] vpn-instance vpn-instance-name

An IS-IS process can belong to only one VPN instance.

3. Configure a network entity title for the IS-IS process.

network-entity net

By default, no NET is configured.

4. Enter IS-IS IPv4 unicast address family view.

address-family ipv4

5. Redistribute BGP routes.

import-route bgp [ as-number ] [ allow-ibgp ] [ cost cost-value | cost-type { external | internal } | [ level-1 | level-1-2 | level-2 ] | route-policy route-policy-name | tag tag ] *

import-route bgp [ as-number ] [ allow-ibgp ] inherit-cost [ [ level-1 | level-1-2 | level-2 ] | route-policy route-policy-name | tag tag ] *

By default, IS-IS does not redistribute routes from other routing protocols.

6. Return to system view.

quit

7. Enter interface view.

interface interface-type interface-number

8. Enable the IS-IS process on the interface.

isis enable [ process-id ]

By default, no IS-IS process is enabled on the interface.

Configuring EBGP between a PE and a CE

Restrictions and guidelines for configuring EBGP between a PE and a CE

After you edit or delete the RD in VPN instance view or VPN instance IPv4 address family view, the device automatically deletes the BGP-VPN IPv4 unicast address family view and all its configuration. To avoid route flapping, do not edit or delete the RD if you have configured EBGP between a PE and a CE.

Configuring the PE

1. Enter system view.

system-view

2. Enable a BGP instance and enter BGP instance view.

bgp as-number [ instance instance-name ]

By default, BGP is not enabled.

3. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

Configuration commands in BGP-VPN instance view are the same as those in BGP instance view. For more information, see BGP in Layer 3—IP Routing Configuration Guide.

4. Configure the CE as the VPN EBGP peer.

peer { group-name | ip-address [ mask-length ] } as-number as-number

For more information about this command, see BGP in Layer 3—IP Routing Configuration Guide.

5. Create the BGP-VPN IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

6. Enable IPv4 unicast route exchange with the specified peer.

peer { group-name | ip-address [ mask-length ] } enable

By default, BGP does not exchange IPv4 unicast routes with a peer.

7. Redistribute the routes of the local CE.

import-route protocol [ { process-id | all-processes } [ allow-direct | med med-value | route-policy route-policy-name ] * ]

A PE must redistribute the routes of the local CE into its VPN routing table so it can advertise them to the peer PE.

8. Allow the local AS number to appear in the AS_PATH attribute of a received route, and set the maximum number of repetitions.

peer { group-name | ip-address [ mask-length ] } allow-as-loop [ number ]

By default, BGP discards incoming route updates that contain the local AS number.

Execute this command in a hub-spoke network where EBGP is running between a PE and a CE to enable the PE to receive the route updates from the CE.

Configuring the CE

1. Enter system view.

system-view

2. Enable a BGP instance and enter BGP instance view.

bgp as-number [ instance instance-name ]

By default, BGP is not enabled.

3. Configure the PE as a BGP peer.

peer { group-name | ip-address [ mask-length ] } as-number as-number

4. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

5. Enable IPv4 unicast route exchange with the specified peer or peer group.

peer { group-name | ip-address [ mask-length ] } enable

By default, BGP does not exchange IPv4 unicast routes with any peer.

6. Configure route redistribution.

import-route protocol [ { process-id | all-processes } [ allow-direct | med med-value | route-policy route-policy-name ] * ]

A CE must redistribute its routes to the PE so the PE can advertise them to the peer CE.

Configuring IBGP between a PE and a CE

Restrictions and guidelines for configuring IBGP between a PE and a CE

Use IBGP between PE and CE only in a basic MPLS L3VPN network. In networks such as Hub&Spoke, Extranet, inter-AS VPN, carrier's carrier, nested VPN, and HoVPN, you cannot use IBGP between PE and CE.

Configuring the PE

1. Enter system view.

system-view

2. Enable a BGP instance and enter BGP instance view.

bgp as-number [ instance instance-name ]

By default, BGP is not enabled.

3. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

Configuration commands in BGP-VPN instance view are the same as those in BGP instance view. For more information, see Layer 3—IP Routing Configuration Guide.

4. Configure the CE as the VPN IBGP peer.

peer { group-name | ip-address [ mask-length ] } as-number as-number

5. Create the BGP-VPN IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

6. Enable IPv4 unicast route exchange with the specified peer.

peer { group-name | ip-address [ mask-length ] } enable

By default, BGP does not exchange IPv4 unicast routes with any peer.

7. Configure the CE as a client of the RR to enable the PE to advertise routes learned from the IBGP peer CE to other IBGP peers.

peer { group-name | ip-address [ mask-length ] } reflect-client

By default, no RR or RR client is configured.

Configuring an RR does not change the next hop of a route. To change the next hop of a route, configure an inbound policy on the receiving side.

8. (Optional.) Enable route reflection between clients.

reflect between-clients

By default, route reflection between clients is enabled.

9. (Optional.) Configure the cluster ID for the RR.

reflector cluster-id { cluster-id | ip-address }

By default, the RR uses its own router ID as the cluster ID.

If multiple RRs exist in a cluster, use this command to configure the same cluster ID for all RRs in the cluster to avoid routing loops.

Configuring the CE

1. Enter system view.

system-view

2. Enable a BGP instance and enter BGP instance view.

bgp as-number [ instance instance-name ]

By default, BGP is not enabled.

3. Configure the PE as an IBGP peer.

peer { group-name | ip-address [ mask-length ] } as-number as-number

4. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

5. Enable IPv4 unicast route exchange with the specified peer.

peer { group-name | ip-address [ mask-length ] } enable

By default, BGP does not exchange IPv4 unicast routes with a peer.

6. Configure route redistribution.

import-route protocol [ { process-id | all-processes } [ allow-direct | med med-value | route-policy route-policy-name ] * ]

A CE must redistribute its routes to the PE so the PE can advertise them to the peer CE.

Configuring routing between PEs

1. Enter system view.

system-view

2. Enable a BGP instance and enter BGP instance view.

bgp as-number [ instance instance-name ]

By default, BGP is not enabled.

3. Configure the remote PE as a BGP peer.

peer { group-name | ip-address [ mask-length ] } as-number as-number

4. (Optional.) Specify the source interface for TCP connections.

peer { group-name | ip-address [ mask-length ] } connect-interface interface-type interface-number

By default, BGP uses the output interface of the optimal route destined for the peer as the source interface.

5. Create the BGP VPNv4 address family and enter its view.

address-family vpnv4

6. Enable BGP VPNv4 route exchange with the specified peer.

peer { group-name | ip-address [ mask-length ] } enable

By default, BGP does not exchange BGP VPNv4 routes with a peer.

Configuring BGP VPNv4 route control

About BGP VPNv4 route control

BGP VPNv4 route control is configured similarly with BGP route control, except that it is configured in BGP VPNv4 address family view. For more information about BGP route control, see Layer 3—IP Routing Configuration Guide.

Controlling BGP VPNv4 route advertisement, reception, and saving

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Advertise a default VPN route to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } default-route-advertise vpn-instance vpn-instance-name

By default, no default VPN route is advertised to a peer or peer group.

5. Set the maximum number of routes BGP can receive from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } route-limit prefix-number [ { alert-only | discard | reconnect reconnect-time } | percentage-value ] *

By default, the number of routes that BGP can receive from a peer or peer group is not limited.

6. Save all route updates from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } keep-all-routes

By default, BGP does not save route updates from a peer.

Setting a preferred value for received routes

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Set a preferred value for routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } preferred-value value

By default, the preferred value for routes received from a peer or peer group is 0.

Configuring BGP VPNv4 route reflection

About this task

To ensure the connectivity of IBGP peers, you must establish full-mesh IBGP connections, which costs massive network and CPU resources.

To reduce IBGP connections in the network, you can configure a router as a route reflector (RR) and configure other routers as its clients. You only need to establish IBGP connections between the RR and its clients to enable the RR to forward routes to the clients.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Configure the device as a route reflector and specify a peer or peer group as its client.

peer { group-name | ipv4-address [ mask-length ] } reflect-client

By default, no route reflector or client is configured.

5. (Optional.) Enable route reflection between clients.

reflect between-clients

By default, route reflection between clients is enabled.

6. (Optional.) Configure a cluster ID for the RR.

reflector cluster-id { cluster-id | ip-address }

By default, the RR uses its own router ID as the cluster ID.

7. (Optional.) Configure a filtering policy for reflected routes.

rr-filter { ext-comm-list-number | ext-comm-list-name }

By default, the RR does not filter reflected routes.

8. (Optional.) Allow the RR to change the attributes of routes to be reflected.

reflect change-path-attribute

By default, RR cannot change the attributes of routes to be reflected.

9. (Optional.) Specify a peer or peer group as a client of the nearby cluster.

peer { group-name | ipv4-address [ mask-length ] } reflect-nearby-group

By default, the nearby cluster does not have any clients.

The RR does not change the next hop of routes reflected to clients in the nearby cluster.

Configuring BGP VPNv4 route attributes

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Configure the NEXT_HOP attribute. Choose one of the following tasks:

¡ Set the device as the next hop for routes sent to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } next-hop-local

¡ Configure the device to not change the next hop of routes advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } next-hop-invariable

By default, the device uses its address as the next hop for routes advertised to peers.

On an RR in an inter-AS option C scenario, you must configure this command to not change the next hop of VPNv4 routes advertised to BGP peers and RR clients.

5. Configure the AS_PATH attribute.

¡ Allow the local AS number to appear in the AS_PATH attribute of a received route and set the maximum number of repetitions.

peer { group-name | ipv4-address [ mask-length ] } allow-as-loop [ number ]

By default, BGP discards incoming routes that contain the local AS number.

¡ Remove private AS numbers in BGP updates sent to an EBGP peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } public-as-only [ { force | limited } [ replace ] [ include-peer-as ] ]

By default, BGP updates sent to an EBGP peer or peer group can carry both public and private AS numbers.

For more information about this command, see BGP commands in Layer 3—IP Routing Command Reference.

6. Advertise the COMMUNITY attribute to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } advertise-community

By default, BGP does not advertise the COMMUNITY attribute to a peer or peer group.

7. Advertise the Large community attribute to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } advertise-large-community

By default, BGP does not advertise the Large community attribute to a peer or peer group.

8. Configure the SoO attribute for a peer for peer group.

peer { group-name | ipv4-address [ mask-length ] } soo site-of-origin

By default, the SoO attribute is not configured.

9. Configure BGP to add the link bandwidth attribute to routes received from an EBGP peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } bandwidth

By default, BGP does not add the link bandwidth attribute to routes received from an EBGP peer or peer group.

10. Configure BGP to carry the user group ID in BGP routes sent to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } advertise user-group-id

By default, BGP does not carry the user group ID in BGP routes sent to a peer or peer group.

Configuring BGP VPNv4 route filtering

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Filter advertised routes.

filter-policy { ipv4-acl-number | name ipv4-acl-name | prefix-list prefix-list-name } export [ protocol process-id ]

By default, BGP does not filter advertised routes.

5. Filter received routes.

filter-policy { ipv4-acl-number | name ipv4-acl-name | prefix-list prefix-list-name } import

By default, BGP does not filter received routes.

6. Configure AS_PATH list-based route filtering for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } as-path-acl as-path-acl-number { export | import }

By default, AS_PATH list-based route filtering is not configured.

7. Configure ACL-based route filtering for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } filter-policy { ipv4-acl-number | name ipv4-acl-name } { export | import }

By default, ACL-based route filtering is not configured.

8. Configure IP prefix list-based route filtering for a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } prefix-list prefix-list-name { export | import }

By default, no IP prefix list-based route filtering is configured.

9. Apply a routing policy to routes advertised to or received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } route-policy route-policy-name { export | import }

By default, no routing policy is applied for a peer.

10. Enable route target filtering for received BGP VPNv4 routes.

policy vpn-target

By default, route target filtering is enabled for received VPNv4 routes. Only VPNv4 routes whose export route target attribute matches the local import route target attribute are added to the routing table.

Configuring BGP VPNv4 route dampening

About this task

This feature enables BGP to not select unstable routes as optimal routes.

Restrictions and guidelines

If a BGP peer goes down after you configure this feature, VPNv4 routes coming from the peer are dampened but not deleted.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Configure BGP VPNv4 route dampening.

¡ Configure EBGP route dampening.

dampening [ half-life-reachable half-life-unreachable reuse suppress ceiling | route-policy route-policy-name ] *

For more information about this command, see BGP commands in Layer 3—IP Routing Command Reference.

¡ Configure IBGP route dampening.

dampening ibgp[ half-life-reachable half-life-unreachable reuse suppress ceiling | route-policy route-policy-name ] *

By default, BGP VPNv4 route dampening is not configured.

Configuring BGP VPNv4 optimal route selection delay

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Set the BGP VPNv4 optimal route selection delay timer.

route-select delay delay-value

By default, the BGP VPNv4 optimal route selection delay timer is 0 seconds, which means optimal route selection is not delayed.

Setting the delay time for responding to BGP VPNv4 recursive next hop changes

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Set the delay time for responding to recursive next hop changes.

nexthop recursive-lookup [ non-critical-event ] delay [ delay-value ]

By default, BGP responds to recursive next hop changes immediately.

For more information about this command, see BGP commands in Layer 3—IP Routing Command Reference.

Configuring BGP VPNv4 routes to use private network next hops

About this task

By default, the device does not change the next hop attribute of a received BGP VPNv4 route. The next hop address of a BGP VPNv4 route is a public address. This feature changes the next hop of a BGP VPNv4 route received from a peer or peer group to an IP address in the VPN instance. The outgoing label of the VPNv4 route is also changed to an invalid value. For example, the device received a VPNv4 route and its next hop address is 10.1.1.1, which is a public address by default. After this feature is configured, the next hop address changes to private address 10.1.1.1.

Restrictions and guidelines

After you configure this feature, the following applies:

· The device re-establishes the BGP sessions to the specified peer or to all peers in the specified peer group.

· The device receives a BGP VPNv4 route only when its RD is the same as a local RD.

· When advertising a BGP VPNv4 route received from the specified peer or peer group, the device does not change the route target attribute of the route.

· If you delete a VPN instance or its RD, BGP VPNv4 routes received from the specified peer or peer group and in the VPN instance will be deleted.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Change the next hop of a BGP VPNv4 route received from a peer or peer group to a VPN instance address.

peer { group-name | ipv4-address [ mask-length ] } next-hop-vpn

By default, the device does not change the next hop attribute of a received BGP VPNv4 route, and the next hop belongs to the public network.

Changing the BGP VPNv4 route selection rules

About this task

For the priority of the settings configured by this feature in BGP route selection, see BGP overview in Layer 3—IP Routing Configuration Guide.

Preferring routes learned from a peer or peer group during optimal route selection

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Prefer routes learned from the specified peer or peer group during optimal route selection.

peer { group-name | ipv4-address [ mask-length ] } high-priority [ preferred ]

By default, routes learned from a peer or peer group do not take precedence over routes learned from other peers or peer groups.

This command takes effect only on BGP routes that are learned in the current address family, and it does not take effect on BGP routes that are added to other BGP routing tables.

Preferring routes with the specified type of next hop addresses during optimal route selection

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Prefer routes with the specified type of next hop addresses during optimal route selection.

bestroute nexthop-priority { ipv4 | ipv6 } [ preferred ]

By default, BGP prefers routes with IPv4 next hop addresses.

If you execute this command multiple times, the most recent configuration takes effect.

Advertising BGP RPKI validation state to a peer or peer group

Restrictions and guidelines

BGP advertises the BGP RPKI validation state to a peer or peer group through the extended community attribute. For more information about BGP RPKI, see BGP configuration in Layer 3—IP Routing Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Advertise the BGP RPKI validation state to the specified peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } advertise origin-as-validation

By default, BGP does not advertise the BGP RPKI validation state.

Enabling MPLS IP packet fragmentation

About this task

In a carrier's carrier network as shown in "Carrier's carrier," a PE does not fragment MPLS L3VPN IP packets by default. To avoid data loss caused by oversized packets from a CE to a PE, enable MPLS IP packet fragmentation and set an MPLS MTU on the PE. To set an MPLS MTU, use the mpls mtu command. For more information about the mpls mtu command, see basic MPLS commands in MPLS Command Reference.

Restrictions and guidelines

You must enable this feature if the device (as a P device for example) receives MPLS-labeled packets from the incoming interface and performs label switching on the outgoing interface.

Procedure

1. Enter system view.

system-view

2. Enable MPLS IP packet fragmentation.

mpls l3vpn fragment enable

By default, MPLS IP packet fragmentation is disabled.

Configuring inter-AS VPN

Configuring inter-AS option A

Inter-AS option A applies to scenarios with a few VPNs.

To configure inter-AS option A, create VPN instances on PEs and ASBRs. The VPN instances on PEs are used to allow CEs to access the network. The VPN instances on ASBRs are used to access the peer ASBRs. An ASBR considers the peer ASBR as a CE.

The route targets configured on the PEs must match those configured on the ASBRs in the same AS to make sure VPN routes sent by the PEs (or ASBRs) can be received by the ASBRs (or PEs). Route targets configured on the PEs in different ASs do not have such requirements.

Configuring inter-AS option B

Restrictions and guidelines

An ASBR always sets itself as the next hop of VPNv4 routes advertised to an MP-IBGP peer regardless of the peer next-hop-local command.

Configuring a PE

Configure basic MPLS L3VPN, and specify the ASBR in the same AS as an MP-IBGP peer. The route targets for the VPN instances on the PEs in different ASs must match for the same VPN.

Configuring an ASBR

1. Enter system view.

system-view

2. Enable MPLS and LDP on the interface connected to an internal router of the AS:

a. Configure an LSR ID for the local LSR.

mpls lsr-id lsr-id

By default, no LSR ID is configured.

b. Enable LDP on the local LSR and enter LDP view.

mpls ldp

By default, LDP is disabled.

c. Return to system view.

quit

d. Enter interface view of the interface connected to an internal router of the AS.

interface interface-type interface-number

e. Enable MPLS on the interface.

mpls enable

By default, MPLS is disabled on the interface.

f. Enable MPLS LDP on the interface.

mpls ldp enable

By default, MPLS LDP is disabled on the interface.

g. Return to system view.

quit

3. Enable MPLS on the interface connected to the remote ASBR:

a. Enter interface view of the interface connected to the remote ASBR.

interface interface-type interface-number

b. Enable MPLS on the interface.

mpls enable

By default, MPLS is disabled on the interface.

c. Return to system view.

quit

4. Enter BGP instance view.

bgp as-number [ instance instance-name ]

5. Configure PE in the same AS as an IBGP peer and the ASBR in another AS as an EBGP peer.

peer { group-name | ipv4-address [ mask-length ] } as-number as-number

6. Enter BGP VPNv4 address family view.

address-family vpnv4

7. Enable BGP to exchange VPNv4 routes with the PE in the same AS and the ASBR in another AS.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, BGP cannot exchange VPNv4 routes with a peer.

8. Disable route target filtering of received VPNv4 routes.

undo policy vpn-target

By default, route target filtering is enabled for received VPNv4 routes.

Configuring inter-AS option C (method 1)

Restrictions and guidelines

PEs are not directly connected. For the PEs to establish neighbor relationships, execute the peer ebgp-max-hop command to enable the local router to establish an EBGP session to an indirectly-connected peer.

You can perform either of the following tasks to enable BGP IPv4 labeled unicast route advertisement between PE and ASBR and between ASBRs:

· Enable BGP to exchange IPv4 labeled routes with a peer or peer group in BGP IPv4 unicast address family view.

· Enable BGP to exchange BGP IPv4 labeled unicast routes with a peer or peer group in BGP IPv4 labeled unicast address family view.

BGP routes received in BGP IPv4 labeled unicast address family cannot be added to the routing table of the public network or a VPN instance, so the PE cannot learn public network routes in another AS. As a result, the PE cannot establish an MP-EBGP session over multiple hops with a PE in another AS. To resolve this issue, redistribute the BGP routes in BGP IPv4 labeled unicast address family to the BGP routing table of the BGP IPv4 unicast address family, and add the routes received from another AS to the routing table of the public network.

Prerequisites

Before you configure inter-AS option C (method 1), perform the following tasks:

· Configure BGP on the PE or ASBR to advertise the route to the PE. For more information, see BGP configuration in Layer 3—IP Routing Configuration Guide.

· Configure VPN instances on PEs.

· Configure routing between PE and CE.

Configuring a PE (exchanging labeled routes in BGP IPv4 unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the ASBR in the same AS as an IBGP peer and configure the PE in another AS as an EBGP peer.

peer { group-name | ipv4-address [ mask-length ] } as-number as-number

4. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

5. Enable BGP to exchange IPv4 unicast routes with the ASBR in the same AS.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, BGP does not exchange IPv4 unicast routes with any peer.

6. Enable BGP to exchange labeled IPv4 routes with the ASBR in the same AS.

peer { group-name | ipv4-address [ mask-length ] } label-route-capability

By default, BGP cannot exchange labeled routes with any IPv4 peer or peer group.

7. Return to BGP instance view.

quit

8. Enter BGP VPNv4 address family view.

address-family vpnv4

9. Enable BGP to exchange VPNv4 routes with the PE in another AS.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, BGP cannot exchange VPNv4 routes with any peer.

10. (Optional.) Configure the PE to not change the next hop of routes advertised to the peer.

peer { group-name | ipv4-address [ mask-length ] } next-hop-invariable

By default, the device uses its address as the next hop of routes advertised to peers.

Configure this command on the RR so the RR does not change the next hop of advertised VPNv4 routes.

Configuring a PE (exchanging labeled routes in BGP IPv4 labeled unicast address family)

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the ASBR in the same AS as an IBGP peer and configure the PE in another AS as an EBGP peer.

peer { group-name | ipv4-address [ mask-length ] } as-number as-number

4. Create the BGP IPv4 labeled unicast address family and enter its view.

address-family ipv4 labeled-unicast

5. Enable BGP to exchange IPv4 labeled unicast routes with the ASBR in the same AS.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, BGP does not exchange IPv4 labeled unicast routes with any peer.

6. Return to BGP instance view.

quit

7. Create the BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

8. Redistribute BGP IPv4 labeled unicast routes to the BGP IPv4 unicast routing table.

import-rib { public | vpn-instance vpn-instance-name } labeled-unicast [ valid-route ] [ route-policy route-policy-name | filter-policy { ipv4-acl-number | name ipv4-acl-name | prefix-list ipv4-prefix-list-name } ]

By default, BGP IPv4 labeled unicast routes cannot be redistributed to the BGP IPv4 unicast routing table.

9. Return to BGP instance view.

quit

10. Enter BGP VPNv4 address family view.

address-family vpnv4

11. Enable BGP to exchange VPNv4 routes with the PE in another AS.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, BGP cannot exchange VPNv4 routes with any peer.

12. (Optional.) Configure the PE to not change the next hop of routes advertised to the peer.

peer { group-name | ipv4-address [ mask-length ] } next-hop-invariable

By default, the device uses its address as the next hop of routes advertised to peers.

Configure this command on the RR so the RR does not change the next hop of advertised VPNv4 routes.

Configuring an ASBR (exchanging labeled routes in BGP IPv4 unicast address family)

1. Enter system view.

system-view

2. Configure a routing policy:

a. Create a routing policy, and enter routing policy view.

route-policy route-policy-name { deny | permit } node node-number

b. Match IPv4 routes carrying labels.

if-match mpls-label

By default, no MPLS label match criterion is configured.

You can configure if-match clauses in the routing policy to filter routes. Routes surviving the filtering are assigned labels, and all others are advertised as common IPv4 routes.

c. Set labels for IPv4 routes.

apply mpls-label

By default, no MPLS label is set for IPv4 routes.

d. Return to system view.

quit

3. Enable MPLS and LDP on the interface connected to an internal router of the AS:

a. Configure an LSR ID for the local LSR.

mpls lsr-id lsr-id

By default, no LSR ID is configured.

b. Enable LDP on the local LSR and enter LDP view.

mpls ldp

By default, LDP is disabled.

c. Return to system view.

quit

d. Enter interface view of the interface connected to an internal router of the AS.

interface interface-type interface-number

e. Enable MPLS on the interface.

mpls enable

By default, MPLS is disabled on the interface.

f. Enable MPLS LDP on the interface.

mpls ldp enable

By default, MPLS LDP is disabled on the interface.

g. Return to system view.

quit

4. Enable MPLS on the interface connected to the remote ASBR.

a. Enter interface view of the interface connected to the remote ASBR.

interface interface-type interface-number

b. Enable MPLS on the interface.

mpls enable

By default, MPLS is disabled on the interface.

c. Return to system view.

quit

5. Enter BGP instance view.

bgp as-number [ instance instance-name ]

6. Configure the PE in the same AS as an IBGP peer and the ASBR in another AS as an EBGP peer.

peer { group-name | ipv4-address [ mask-length ] } as-number as-number

7. Create BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

8. Enable BGP to exchange IPv4 unicast routes with the PE in the same AS and the ASBR in another AS.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, BGP cannot exchange IPv4 unicast routes with a peer.

9. Enable BGP to exchange labeled IPv4 routes with the PE in the same AS and the ASBR in another AS.

peer { group-name | ipv4-address [ mask-length ] } label-route-capability

By default, BGP cannot exchange labeled IPv4 routes with a peer.

10. Specify the device as the next hop of routes sent to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } next-hop-local

By default, the device does not set itself as the next hop for routes sent to a peer or peer group.

11. Apply a routing policy to routes advertised to or received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } route-policy route-policy-name { export | import }

By default, no routing policy is applied.

Configuring an ASBR (exchanging labeled routes in BGP IPv4 labeled unicast address family)

1. Enter system view.

system-view

2. Enable MPLS and LDP on the interface connected to an internal router of the AS:

a. Configure an LSR ID for the local LSR.

mpls lsr-id lsr-id

By default, no LSR ID is configured.

b. Enable LDP on the local LSR and enter LDP view.

mpls ldp

By default, LDP is disabled.

c. Return to system view.

quit

d. Enter interface view of the interface connected to an internal router of the AS.

interface interface-type interface-number

e. Enable MPLS on the interface.

mpls enable

By default, MPLS is disabled on the interface.

f. Enable MPLS LDP on the interface.

mpls ldp enable

By default, MPLS LDP is disabled on the interface.

g. Return to system view.

quit

3. Enable MPLS on the interface connected to the remote ASBR.

a. Enter interface view of the interface connected to the remote ASBR.

interface interface-type interface-number

b. Enable MPLS on the interface.

mpls enable

By default, MPLS is disabled on the interface.

c. Return to system view.

quit

4. Enter BGP instance view.

bgp as-number [ instance instance-name ]

5. Configure the PE in the same AS as an IBGP peer and the ASBR in another AS as an EBGP peer.

peer { group-name | ipv4-address [ mask-length ] } as-number as-number

6. Create BGP IPv4 labeled unicast address family and enter its view.

address-family ipv4 labeled-unicast

7. Enable BGP to exchange IPv4 labeled unicast routes with the PE in the same AS and the ASBR in another AS.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, BGP cannot exchange IPv4 labeled unicast routes with a peer.

8. (Optional.) Apply a routing policy to routes advertised to or received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } route-policy route-policy-name { export | import }

By default, no routing policy is applied.

Configuring inter-AS option C (method 2)

Restrictions and guidelines

You can perform either of the following tasks to enable BGP IPv4 labeled unicast route advertisement between ASBRs:

· Enable BGP to exchange IPv4 labeled routes with a peer or peer group in BGP IPv4 unicast address family view.

· Enable BGP to exchange BGP IPv4 labeled unicast routes with a peer or peer group in BGP IPv4 labeled unicast address family view.

Prerequisites

Before you configure inter-AS option C (method 2), perform the following tasks:

· Configure BGP on the PE or ASBR to advertise the route to the PE. For more information, see BGP configuration in Layer 3—IP Routing Configuration Guide.

· Configure VPN instances on PEs.

· Configure routing between PE and CE.

Configuring a PE

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the PE in another AS as an EBGP peer.

peer { group-name | ipv4-address [ mask-length ] } as-number as-number

4. Enter BGP VPNv4 address family view.

address-family vpnv4

5. Enable BGP to exchange VPNv4 routes with the PE in another AS.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, BGP cannot exchange VPNv4 routes with any peer.

6. (Optional.) Configure the PE to not change the next hop of routes advertised to the peer.

peer { group-name | ipv4-address [ mask-length ] } next-hop-invariable

By default, the device uses its address as the next hop of routes advertised to peers.

Configure this command on the RR so the RR does not change the next hop of advertised VPNv4 routes.

Configuring an ASBR (exchanging labeled routes in BGP IPv4 unicast address family)

1. Enter system view.

system-view

2. Configure a routing policy:

a. Create a routing policy, and enter routing policy view.

route-policy route-policy-name { deny | permit } node node-number

b. Match IPv4 routes carrying labels.

if-match mpls-label

By default, no MPLS label match criterion is configured.

You can configure if-match clauses in the routing policy to filter routes. Routes surviving the filtering are assigned labels, and all others are advertised as common IPv4 routes.

c. Set labels for IPv4 routes.

apply mpls-label

By default, no MPLS label is set for IPv4 routes.

d. Return to system view.

quit

3. Enable MPLS and LDP on the interface connected to an internal router of the AS:

a. Configure an LSR ID for the local LSR.

mpls lsr-id lsr-id

By default, no LSR ID is configured.

b. Enable LDP on the local LSR and enter LDP view.

mpls ldp

By default, LDP is disabled.

c. Return to system view.

quit

d. Enter interface view of the interface connected to an internal router of the AS.

interface interface-type interface-number

e. Enable MPLS on the interface.

mpls enable

By default, MPLS is disabled on the interface.

f. Enable MPLS LDP on the interface.

mpls ldp enable

By default, MPLS LDP is disabled on the interface.

g. Return to system view.

quit

4. Enable MPLS on the interface connected to the remote ASBR.

a. Enter interface view of the interface connected to the remote ASBR.

interface interface-type interface-number

b. Enable MPLS on the interface.

mpls enable

By default, MPLS is disabled on the interface.

c. Return to system view.

quit

5. Enter BGP instance view.

bgp as-number [ instance instance-name ]

6. Configure the ASBR in another AS as an EBGP peer.

peer { group-name | ipv4-address [ mask-length ] } as-number as-number

7. Create BGP IPv4 unicast address family and enter its view.

address-family ipv4 [ unicast ]

8. Enable BGP to exchange IPv4 unicast routes with the ASBR in another AS.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, BGP cannot exchange IPv4 unicast routes with a peer.

9. Enable BGP to exchange labeled IPv4 routes with the ASBR in another AS.

peer { group-name | ipv4-address [ mask-length ] } label-route-capability

By default, BGP cannot exchange labeled IPv4 routes with a peer.

10. Specify the device as the next hop of routes sent to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } next-hop-local

By default, the device does not set itself as the next hop for routes sent to an IBGP peer or peer group.

11. Apply a routing policy to routes advertised to or received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } route-policy route-policy-name { export | import }

By default, no routing policy is applied.

Configuring an ASBR (exchanging labeled routes in BGP IPv4 labeled unicast address family)

1. Enter system view.

system-view

2. Enable MPLS and LDP on the interface connected to an internal router of the AS:

a. Configure an LSR ID for the local LSR.

mpls lsr-id lsr-id

By default, no LSR ID is configured.

b. Enable LDP on the local LSR and enter LDP view.

mpls ldp

By default, LDP is disabled.

c. Return to system view.

quit

d. Enter interface view of the interface connected to an internal router of the AS.

interface interface-type interface-number

e. Enable MPLS on the interface.

mpls enable

By default, MPLS is disabled on the interface.

f. Enable MPLS LDP on the interface.

mpls ldp enable

By default, MPLS LDP is disabled on the interface.

g. Return to system view.

quit

3. Enable MPLS on the interface connected to the remote ASBR.

a. Enter interface view of the interface connected to the remote ASBR.

interface interface-type interface-number

b. Enable MPLS on the interface.

mpls enable

By default, MPLS is disabled on the interface.

c. Return to system view.

quit

4. Enter BGP instance view.

bgp as-number [ instance instance-name ]

5. Configure the ASBR in another AS as an EBGP peer.

peer { group-name | ipv4-address [ mask-length ] } as-number as-number

6. Create BGP IPv4 labeled unicast address family and enter its view.

address-family ipv4 labeled-unicast

7. Enable BGP to exchange IPv4 labeled unicast routes with the ASBR in another AS.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, BGP cannot exchange IPv4 labeled unicast routes with a peer.

8. (Optional.) Apply a routing policy to routes advertised to or received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } route-policy route-policy-name { export | import }

By default, no routing policy is applied.

9. Return to BGP instance view.

quit

10. Create the BGP IPv4 unicast address family view and enter its view.

address-family ipv4 [ unicast ]

11. Redistribute BGP IPv4 labeled unicast routes to the BGP IPv4 unicast routing table.

By default, BGP IPv4 labeled unicast routes cannot be redistributed to the BGP IPv4 unicast routing table.

Configuring nested VPN

Restrictions and guidelines

When you configure nested VPN, follow these guidelines:

· The address spaces of sub-VPNs of a VPN cannot overlap.

· Do not assign nested VPN peers addresses that public network peers use.

· Nested VPN does not support multihop EBGP. A provider PE and a provider CE must use the addresses of the directly connected interfaces to establish a neighbor relationship.

Procedure

1. Connect the customer CE to the customer PE:

a. Configure VPN instances on the customer PE.

See "Configuring VPN instances."

b. Configure route exchange between customer PE and customer CE.

See "Configuring routing between a PE and a CE."

2. Configure the customer PE to exchange sub-VPN routing information with the provider CE:

a. Configure BGP VPNv4 route exchange between customer PE and provider CE.

See "Configuring routing between PEs."

b. Execute the following commands in sequence to configure the provider CE to receive all VPNv4 routes (not filter VPNv4 routes by route targets).

system-view

bgp as-number [ instance instance-name ]

address-family vpnv4

undo policy vpn-target

This step is not required in a nested VPN network when no provider CE is deployed and the customer PE is connected directly to the provider PE.

3. Connect the provider CE to the provider PE:

a. Configure VPN instances on the provider PE.

See "Configuring VPN instances."

b. Configure route exchange between the provider CE and provider PE.

See "Configuring routing between a PE and a CE."

4. Configure BGP VPNv4 route exchange between the provider PE and provider CE:

This step contains only configurations on the provider PE. For information about configuring the provider CE, see "Configuring routing between PEs." If the customer PE is directly connected to the provider PE, you must configure provider CE settings on the customer PE because the PE also functions as a provider CE.

a. Execute the following commands in sequence to enter BGP VPNv4 address family view:

system-view

bgp as-number [ instance instance-name ]

address-family vpnv4

b. Enable nested VPN.

nesting-vpn

By default, nested VPN is disabled.

c. Return to BGP instance view.

quit

d. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

e. Configure the provider CE as a BGP peer.

peer { group-name | ipv4-address [ mask-length ] } as-number as-number

f. Create BGP-VPN VPNv4 address family and enter BGP-VPN VPNv4 address family view.

address-family vpnv4

g. Enable BGP VPNv4 route exchange with the peer CE or the peer group of the peer CE.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, BGP does not exchange VPNv4 routes with any peer.

h. (Optional.) Configure the SoO attribute for the BGP peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } soo site-of-origin

By default, the SoO attribute is not configured.

i. (Optional.) Prefer routes learned from the specified peer or peer group during optimal route selection.

peer { group-name | ipv4-address [ mask-length ] } high-priority [ preferred ]

By default, routes learned from a peer or peer group do not take precedence over routes learned from other peers or peer groups.

This command takes effect only on BGP routes that are learned in the current address family, and it does not take effect on BGP routes that are added to other BGP routing tables.

5. Configure BGP VPNv4 route exchange between provider PEs.

See "Configuring routing between PEs."

Configuring multirole host

About configuring multirole host

To configure the multirole host feature, perform the following tasks on the PE connected to the CE in the site where the multirole host resides:

· Configure and apply PBR.

· Configure static routes.

Configuring and applying PBR

1. Enter system view.

system-view

2. Create a policy node and enter policy node view.

policy-based-route policy-name { deny | permit } node node-number

3. Configure match criteria for the node.

See Layer 3—IP Routing Configuration Guide.

By default, no match criterion is configured. All packets match the criteria for the node.

This step matches packets from the multirole host.

4. Specify the VPN instances for forwarding the matching packets.

apply access-vpn vpn-instance vpn-instance-name&

By default, no VPN instance is specified.

You must specify multiple VPN instances for the node. The first one is the VPN instance to which the multirole host belongs, and others are the VPN instances to be accessed. A matching packet is forwarded according to the routing table of the first VPN instance that has a matching route for that packet.

5. Return to system view.

quit

6. Enter the view of the interface connected to the CE.

interface interface-type interface-number

7. Apply the policy to the interface.

ip policy-based-route policy-name

By default, no policy is applied to the interface.

Configuring a static route

1. Enter system view.

system-view

2. Configure a static route for a VPN instance to reach the multirole host.

ip route-static vpn-instance s-vpn-instance-name dest-address { mask-length | mask } vpn-instance d-vpn-instance-name next-hop-address [ track track-entry-number ] [ permanent ] [ preference preference ] [ tag tag-value ] [ description text ]

The d-vpn-instance-name argument represents the VPN instance to which the multirole host belongs. The next-hop-address argument represents the IP address of the CE in the site where the multirole host resides.

Configuring HoVPN

Configuring the UPE

Configure basic MPLS L3VPN settings on the UPE.

Configuring the SPE

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify a BGP peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } as-number as-number

4. Enter BGP VPNv4 address family view.

address-family vpnv4

5. Enable BGP VPNv4 route exchange with the peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } enable

By default, BGP does not exchange VPNv4 routes with any peer.

6. Specify the BGP peer or peer group as a UPE.

peer { group-name | ipv4-address [ mask-length ] } upe

By default, no peer is a UPE.

7. Advertise routes to the UPE.

¡ Advertise a default VPN route to the UPE.

peer { group-name | ipv4-address [ mask-length ] } default-route-advertise vpn-instance vpn-instance-name

After you configure this command, the device advertises a default route to the UPE, regardless of whether the default route exists in the local routing table. The default route uses the local address as the next hop.

¡ Advertise routes permitted by a routing policy to the UPE.

peer { group-name | ipv4-address [ mask-length ] } upe route-policy route-policy-name export

By default, no route is advertised to the UPE.

Do not configure both commands.

8. Return to BGP instance view.

quit

9. Create a BGP-VPN instance and enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

You do not need to associate the VPN instance to an interface on the SPE.

This step adds the learned VPNv4 routes to the BGP routing table of the VPN instance.

Configuring route re-origination

About this task

In an HoVPN network, different UPEs communicate with each other through MPEs and SPEs. You can configure route re-origination on MPEs to reduce the number of private network labels that a UPE receives for VPNv4 routes.

As shown in Figure 24, if a network contains many UPEs that use the per-VPN-instance label allocation mode, and the MPEs in the network use the per-next-hop label allocation mode, the SPE will receive a large number of labels, which might cause traffic forwarding errors.

To resolve this issue, you can configure route re-origination on MPEs. The MPEs then can redistribute the BGP routes received from UPEs into local VPN instances and reoriginate these routes. The MPEs can modify the information of the reoriginated routes. After setting the per-VPN instance label allocation mode, the MPEs only need to allocate the number of VPN labels equal to the number of local VPN instances, regardless of the number of UPEs. The SPE only needs to receive the VPN labels allocated by the MPEs, significantly reducing the resource load on the SPE.

Figure 24 Route re-origination

‌

Restrictions and guidelines

This feature can reoriginate the BGP routes that are imported into a local VPN instance and have a different RD from that of the local VPN instance. It cannot reoriginate the BGP routes that are received from remote peers and have the same RD as that of the local VPN instance.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

4. Enter BGP-VPN IPv4 unicast address family view.

address-family ipv4 [ unicast ]

5. Configure the device to re-originate the optimal routes in the VPN instance and advertise the re-originated routes to VPNv4 peers.

advertise route-reoriginate [ route-policy route-policy-name ] [ replace-rt ]

By default, the device does not re-originate the optimal routes in a VPN instance, and it sends the original VPNv4 routes to VPNv4 peers.

Specifying the VPN label processing mode on the egress PE

About this task

An egress PE can process VPN labels in either POPGO or POP mode:

· POPGO forwarding—Pops the label and forwards the packet out of the output interface corresponding to the label.

· POP forwarding—Pops the label and forwards the packet through the FIB table.

Restrictions and guidelines

The POPGO forwarding mode (vpn popgo) and per-VPN instance label allocation mode (label-allocation-mode per-vrf) are mutually exclusive. Do not configure both modes in a BGP instance. For more information about the label-allocation-mode command, see BGP commands in Layer 3—IP Routing Command Reference.

The POPGO forwarding mode (vpn popgo) cannot be used in per-VPN instance label allocation mode (apply-label per-instance). After the apply-label per-instance command is executed for a VPN instance, the device can only forward packets by looking up the FIB according to labels, and the vpn popgo command does not take effect in the VPN instance.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify the VPN label processing mode as POPGO forwarding.

vpn popgo

The default is POP forwarding.

Configuring MPLS L3VPN FRR

About MPLS L3VPN FRR

You can use the following methods to configure MPLS L3VPN FRR:

· Method 1—Execute the pic command in BGP-VPN IPv4 unicast address family view or BGP VPNv4 address family view. The device calculates a backup next hop for each BGP route in the VPN instance if there are two or more unequal-cost routes to reach the destination.

· Method 2—Execute the fast-reroute route-policy command in BGP-VPN IPv4 unicast address family view to use a routing policy. In the routing policy, specify a backup next hop by using the apply fast-reroute backup-nexthop command. The backup next hop calculated by the device must be the same as the specified backup next hop. Otherwise, the device does not generate a backup next hop for the primary route. You can also configure if-match clauses in the routing policy to identify the routes protected by FRR.

If both methods are configured, Method 2 takes precedence over Method 1.

Restrictions and guidelines

Executing the pic command in BGP-VPN IPv4 unicast address family view or BGP VPNv4 address family view might cause routing loops. Use it with caution.

To configure inter-protocol FRR, execute the inter-protocol fast-reroute command. For more information about the inter-protocol fast-reroute command, see IP routing basics commands in Layer 3—IP Routing Command Reference.

Configuring FRR by using a routing policy

1. Enter system view.

system-view

2. Configure BFD.

¡ Enable MPLS BFD.

mpls bfd enable

By default, MPLS BFD is disabled.

The mpls bfd enable command applies to VPNv4 route backup for a VPNv4 route and IPv4 route backup for a VPNv4 route.

For more information about this command, see MPLS Command Reference.

¡ Configure the source IP address for BFD echo packets.

bfd echo-source-ip ip-address

By default, the source IP address for BFD echo packets is not configured.

This command is required when echo-mode BFD is used to detect primary route connectivity in VPNv4 route backup for an IPv4 route. For more information about this command, see High Availability Command Reference.

3. Use BFD to test the connectivity of an LSP or MPLS TE tunnel.

¡ Configure BFD to test the connectivity of the LSP for the specified FEC.

¡ Execute the following commands in sequence to configure BFD to test the connectivity of the MPLS TE tunnel for the tunnel interface.

interface tunnel number mode mpls-te

mpls tunnel-bfd [ discriminator local local-id remote remote-id | echo | reverse-lsp binding-sid label label-value ] [ template template-name ]

quit

By default, BFD is not configured to test the connectivity of the LSP or MPLS TE tunnel.

This step is required for VPNv4 route backup for a VPNv4 route and IPv4 route backup for a VPNv4 route.

For more information about the commands in this step, see MPLS Command Reference.

4. Configure a routing policy:

a. Create a routing policy and enter routing policy view.

route-policy route-policy-name permit node node-number

b. Set the backup next hop for FRR.

apply fast-reroute backup-nexthop ip-address

By default, no backup next hop address is set for FRR.

c. Return to system view.

quit

For more information about the commands, see Layer 3—IP Routing Command Reference.

5. Enter BGP instance view.

bgp as-number [ instance instance-name ]

6. (Optional.) Use echo-mode BFD to detect the connectivity to the next hop of the primary route.

primary-path-detect bfd echo

By default, ARP is used to detect the connectivity to the next hop.

Use this command if necessary in VPNv4 route backup an IPv4 route.

For more information about this command, see Layer 3—IP Routing Command Reference.

7. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

8. Enter BGP-VPN IPv4 unicast address family view.

address-family ipv4 [ unicast ]

9. Apply a routing policy to FRR.

fast-reroute route-policy route-policy-name

By default, no routing policy is applied to FRR.

The apply fast-reroute backup-nexthop command can take effect in the routing policy that is being used. Other apply commands do not take effect.

For more information about the command, see BGP commands in Layer 3—IP Routing Command Reference.

Enabling MPLS L3VPN FRR for BGP-VPN IPv4 unicast address family or BGP VPNv4 address family view

1. Enter system view.

system-view

2. Configure BFD.

¡ Enable MPLS BFD.

mpls bfd enable

By default, MPLS BFD is disabled.

This command applies to VPNv4 route backup for a VPNv4 route and IPv4 route backup for a VPNv4 route. For more information about this command, see MPLS OAM commands in MPLS Command Reference.

¡ Configure the source IP address for BFD echo packets.

bfd echo-source-ip ip-address

By default, the source IP address for BFD echo packets is not configured.

This command is required when echo-mode BFD is used to detect primary route connectivity in VPNv4 route backup for an IPv4 route. For more information about this command, see BFD commands in High Availability Command Reference.

3. Use BFD to test the connectivity of an LSP or MPLS TE tunnel.

¡ Use BFD to test the connectivity of the LSP for the specified FEC.

¡ Execute the following commands in sequence to use BFD to test the connectivity of the MPLS TE tunnel for the tunnel interface:

interface tunnel number mode mpls-te

mpls tunnel-bfd [ discriminator local local-id remote remote-id | echo | reverse-lsp binding-sid label label-value ] [ template template-name ]

quit

By default, BFD is not used to test the connectivity of the LSP or MPLS TE tunnel.

This command applies to VPNv4 route backup for a VPNv4 route and IPv4 route backup for a VPNv4 route.

For more information about the commands, see MPLS OAM commands in MPLS Command Reference.

4. Enter BGP instance view.

bgp as-number [ instance instance-name ]

5. (Optional.) Use echo-mode BFD to detect the connectivity to the next hop of the primary route.

primary-path-detect bfd echo

By default, ARP is used to detect the connectivity to the next hop.

Use this command if necessary in VPNv4 route backup an IPv4 route.

For more information about this command, see BGP commands in Layer 3—IP Routing Command Reference.

6. Enter BGP-VPN IPv4 unicast address family view or BGP VPNv4 address family view.

¡ Enter BGP-VPN IPv4 unicast address family view.

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

¡ Enter BGP VPNv4 address family view.

address-family vpnv4

7. Enable MPLS L3VPN FRR for the address family.

pic

By default, MPLS L3VPN FRR is disabled.

For more information about this command, see BGP commands in Layer 3—IP Routing Command Reference.

Configuring a TTL processing mode for tunnels associated with a VPN instance

About this task

A tunnel associated with a VPN instance supports the following TTL processing modes:

· Pipe—When an IP or IPv6 packet enters the tunnel of the VPN instance, the ingress node adds a new header to the packet. The ingress node sets the TTL value or hop limit in the new header to 255 or the value specified by the encapsulation source-address ip-ttl command in SRv6 view. When the packet leaves the tunnel of the VPN instance, the egress node does not change the TTL value or the hop limit according to the remaining TTL value in the new header. Therefore, the public network nodes are invisible to user networks, and the tracert facility cannot show the real path in the public network.

· Uniform—When an IP or IPv6 packet enters the tunnel of the VPN instance, the ingress node adds a new header to the packet. The ingress node copies the TTL value or the hop limit of the original packet to the TTL or hop limit field of the new header. When the packet leaves the tunnel of the VPN instance, the egress node copies the remaining TTL value or hop limit back to the original packet. The TTL value or hop limit can reflect how many hops the packet has traversed in the public network. The tracert facility can show the real path along which the packet has traveled.

Restrictions and guidelines

In the current software version, you can configure a TTL processing mode for only SRv6 tunnels associated with VPN instances. For more information about associating VPN instances with SRv6 tunnels, see MPLS L3VPN over SRv6 configuration in Segment Routing Configuration Guide.

This feature takes effect after you restart the IGP/BGP process.

Procedure

1. Enter system view.

system-view

2. Enter VPN instance mode.

ip vpn-instance vpn-instance-name

3. Configure a TTL processing mode for the tunnel associated with a VPN instance.

ttl-mode { pipe | uniform }

By default, the TTL processing mode for the tunnel associated with a VPN instance is pipe.

Configuring an OSPF sham link

About OSPF sham links

When a backdoor link exists between the two sites of a VPN, you can create a sham link between PEs to forward VPN traffic through the sham link on the backbone rather than the backdoor link. A sham link is considered an OSPF intra-area route.

The source and destination addresses of the sham link must be loopback interface addresses with 32-bit masks. The loopback interfaces must be bound to VPN instances, and their addresses are advertised through BGP.

Prerequisites

Before you configure an OSPF sham link, perform the following tasks:

· Configure basic MPLS L3VPN (OSPF is used between PE and CE).

· Configure OSPF in the LAN where customer CEs reside.

Redistributing the loopback interface address

1. Enter system view.

system-view

2. Create a loopback interface and enter loopback interface view.

interface loopback interface-number

3. Associate the loopback interface with a VPN instance.

ip binding vpn-instance vpn-instance-name

By default, an interface belongs to the public network and does not associate with a VPN instance.

4. Configure an IP address for the loopback interface.

ip address ip-address { mask-length | mask }

By default, no IP address is configured for the loopback interface.

5. Return to system view.

quit

6. Enter BGP instance view.

bgp as-number [ instance instance-name ]

7. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

8. Enter BGP-VPN IPv4 unicast address family view.

address-family ipv4 [ unicast ]

9. Redistribute direct routes into BGP (including the loopback interface route).

import-route direct

By default, no direct routes are redistributed into BGP.

Creating a sham link

1. Enter system view.

system-view

2. Enter OSPF view.

ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *

As a best practice, specify a router ID.

3. Set the external route tag for imported VPN routes.

route-tag tag-value

By default, if BGP runs within an MPLS backbone, and the BGP AS number is not greater than 65535, the first two octets of the external route tag are 0xD000 and the last two octets are the local BGP AS number. If the AS number is greater than 65535, the external route tag is 0.

4. Enter OSPF area view.

area area-id

5. Configure a sham link.

sham-link source-ip-address destination-ip-address [ cost cost-value | dead dead-interval | hello hello-interval | { { hmac-md5 | hmac-sha-256 | md5 } key-id { cipher | plain } string | keychain keychain-name | simple { cipher | plain } string } | retransmit retrans-interval | trans-delay delay | ttl-security hops hop-count ] *

Configuring BGP AS number substitution and SoO attribute

About this task

When CEs at different sites have the same AS number, configure the BGP AS number substitution feature to avoid route loss.

When a PE uses different interfaces to connect different CEs in a site, the BGP AS number substitution feature introduces a routing loop. To remove the routing loop, configure the SoO attribute on the PE.

For more information about the BGP AS number substitution feature and the SoO attribute, see "BGP AS number substitution and SoO attribute."

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

4. Enable the BGP AS number substitution feature.

peer { ipv4-address [ mask-length ] | group-name } substitute-as

By default, BGP AS number substitution is disabled.

5. Enter BGP-VPN IPv4 unicast address family view.

address-family ipv4 [ unicast ]

6. (Optional.) Configure the SoO attribute for a BGP peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } soo site-of-origin

By default, the SoO attribute is not configured.

Configuring the AIGP attribute

About this task

An Accumulated Interior Gateway Protocol (AIGP) administrative domain is a collection of multiple ASs that run the same IGP under one administrative control. Within the domain, BGP accumulates the IGP metrics all along the forwarding path for a route. Then, it uses the accumulated value as the AIGP attribute for the route to implement metric-based route selection.

By default, BGP does not advertise the AIGP attribute to its peers or peer groups. When BGP receives a route carrying the AIGP attribute, it ignores and removes the attribute before advertising the route to other peers or peer groups. Perform this task to enable BGP to advertise the AIGP attribute to its peers or peer groups.

With this feature enabled, a router processes the AIGP attribute in a received route as follows:

· If the router sets itself as the next hop for the route, it adds to the AIGP attribute value the IGP metric from itself to the original next hop and advertises the new AIGP attribute value.

· If the router does not set itself as the next hop for the route, it does not change the AIGP attribute value.

BGP uses the AIGP attribute to select the optimal route as follows:

· A route carrying the AIGP attribute takes precedence over a route not carrying the AIGP attribute.

· A route that has a smaller computed AIGP attribute value has a higher priority.

When the AIGP attribute of a route changes, BGP sends update messages for the route.

Restrictions and guidelines

As a best practice, do not configure the peer aigp command on border routers of an AIGP administrative domain.

When a router receives a route not carrying the AIGP attribute, it does not advertise the AIGP attribute to a peer or peer group if you configure only the peer aigp command. To enable the router to advertise the AIGP attribute, you must configure both the peer aigp and apply aigp commands. For information about the apply aigp command, see the routing policy configuration in Layer 3—IP Routing Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Configure BGP to advertise the AIGP attribute to the specified peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } aigp

By default, BGP does not advertise the AIGP attribute to a peer or peer group and ignores the AIGP attribute in routes received from the peer or peer group.

5. (Optional.) Replace the MED value with AIGP value in routes advertised to the specified peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } aigp send med

By default, BGP does not replace the MED value with AIGP value in routes advertised to a peer or peer group.

Use this command to send the AIGP attribute to a peer or peer group that does not support AIGP.

Configuring BGP RT filtering

About this task

The BGP RT filtering feature reduces the number of routes advertised in an MPLS L3VPN.

After RT filtering is configured, a PE advertises its import target attribute to the peer PEs in the RT filter address family. The peer PEs use the received import target attribute to filter routes and advertise only the routes that match the attribute to the PE.

When a large number of IBGP peers exist, the BGP RT filtering and the route reflection features are used together as a best practice. Route reflection reduces the number of IBGP connections. BGP RT filtering reduces the number of routes advertised in the network.

For more information about the BGP RT filtering commands, see Layer 3—IP Routing Command Reference.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 RT filter address family view.

address-family ipv4 rtfilter

4. Enable the device to exchange routing information with a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } enable

By default, the device cannot exchange routing information with a peer or peer group.

5. (Optional.) Advertise a default route to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } default-route-advertise [ route-policy route-policy-name ]

By default, no default route is advertised.

6. (Optional.) Set the maximum number of routes that can be received from the specified peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } route-limit prefix-number [ { alert-only | discard | reconnect reconnect-time } | percentage-value ] *

By default, no limit is set for the number of routes that can be received from a peer or peer group.

7. (Optional.) Set a preferred value for routes received from a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } preferred-value value

By default, the preferred value for routes received from a peer or peer group is 0.

8. (Optional.) Prefer routes learned from the specified peer or peer group during optimal route selection.

peer { group-name | ipv4-address [ mask-length ] } high-priority [ preferred ]

By default, routes learned from a peer or peer group do not take precedence over routes learned from other peers or peer groups.

9. (Optional.) Configure the device as a route reflector and specify a peer or peer group as its client.

peer { group-name | ipv4-address [ mask-length ] | ipv6-address [ prefix-length ] } reflect-client

By default, no route reflector or client is configured.

10. (Optional.) Enable route reflection between clients.

reflect between-clients

By default, route reflection between clients is enabled.

11. (Optional.) Configure the cluster ID of the route reflector.

reflector cluster-id { cluster-id | ipv4-address }

By default, a route reflector uses its own router ID as the cluster ID.

Configuring the BGP additional path feature

About this task

By default, BGP advertises only one optimal route. When the optimal route fails, traffic forwarding will be interrupted until route convergence completes.

The BGP additional path (Add-Path) feature enables BGP to advertise multiple routes with the same prefix and different next hops to a peer or peer group. When the optimal route fails, the suboptimal route becomes the optimal route, which shortens the traffic interruption time.

You can enable the BGP additional path sending, receiving, or both sending and receiving capabilities on a BGP router. For two BGP peers to successfully negotiate the additional path capabilities, make sure one end has the sending capability and the other end has the receiving capability.

Procedure

1. Enter system view.

system-view

2. Enter BGP VPNv4 address family view or BGP-VPN VPNv4 address family view.

¡ Execute the following commands in sequence to enter BGP VPNv4 address family view:

bgp as-number [ instance instance-name ]

address-family vpnv4

¡ Execute the following commands in sequence to enter BGP-VPN VPNv4 address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family vpnv4

3. Configure the BGP additional path capabilities.

peer { group-name | ipv4-address [ mask-length ] } additional-paths { receive | send } *

By default, no BGP additional path capabilities are configured.

4. Set the maximum number of Add-Path optimal routes that can be advertised to a peer or peer group.

peer { group-name | ipv4-address [ mask-length ] } advertise additional-paths best number [ route-policy route-policy-name ]

By default, the maximum number of Add-Path optimal routes that can be advertised to a peer or peer group is 1.

5. Set the maximum total number of Add-Path optimal routes that can be advertised to all peers.

additional-paths select-best best-number [ route-policy route-policy-name ]

By default, the maximum total number of Add-Path optimal routes that can be advertised to all peers is 1.

This command is not supported in BGP-VPN VPNv4 address family view.

6. (Optional.) Set the optimal route selection delay timer.

route-select delay delay-value

By default, the optimal route selection delay timer is 0 seconds, which means optimal route selection is not delayed.

Configuring the rule for adding BGP routes to the IP routing table and the route advertisement rule for VPN instances

About this task

Perform this task to configure the following features:

· Route adding rule—For multiple BGP routes to the same destination, BGP adds the optimal route with matching route targets of a VPN instance to the IP routing table of the VPN instance.

After the undo policy vpn-target command is executed, VPNv4 routes without matching route targets of the local VPN instance can be received. If the VPNv4 routes have the same RD as the local VPN instance, these routes can be selected in the BGP VPNv4 routing table as optimal routes. However, routes without matching route targets are invisible and unavailable in the BGP-VPN instance routing table and cannot be added to the routing table of the VPN instance. The BGP-VPN instance routing table uses the same optimal route selection result as the BGP VPNv4 routing table. Therefore, if a route without matching route targets is selected as the only optimal route in the BGP VPNv4 routing table, no optimal route can be added to the BGP-VPN instance routing table. Only the optimal route in the BGP-VPN instance routing table can be added to the VPN instance IP routing table. Therefore, the BGP route without matching route targets cannot be added to the VPN instance IP routing table, so packets destined for the destination address of that route cannot be forwarded.

You can configure this feature to resolve this issue. With this feature configured, for BGP routes to the same destination address, BGP adds the optimal route with the same route targets as a VPN instance to the IP routing table of the VPN instance.

For example, the import target of VPN instance vpna is 10:1. The BGP routing table of VPN instance vpna contains two routes to destination address 1.1.1.1, which are 1.1.1.1 <RT: 10:1> and 1.1.1.1 <RT: 20:1>, and 1.1.1.1 <RT: 20:1> is the optimal route. After you configure this feature, BGP will add 1.1.1.1 <RT: 10:1> to the IP routing table of VPN instance vpna, because this route has the same import target as the VPN instance.

· Route advertisement rule—When the optimal route to a destination address cannot be advertised to peers, the device advertises the suboptimal route to the destination address from the routes that can be advertised. The device does not advertise any route for a destination address only if no routes to the destination address can be advertised.

The BGP routing table of a VPN instance contains the routes in the IP routing table of the VPN instance, so the routing table of a BGP address family might contain routes that are not learned from that address family. For example, an IP prefix advertisement route learned from the BGP EVPN address family is added to the IP routing table of a VPN instance, and the route also exists in the BGP routing tables of the BGP-VPN IPv4 unicast address family and BGP VPNv4 address family in the VPN instance. BGP cannot advertise the optimal route to peers in an address family if the optimal route is not learned from that address family, making the destination address of the route unreachable.

After you configure this feature, if the optimal route to a destination address cannot be advertised to peers, the device advertises the suboptimal route, and so forth until a route to the destination address is advertised successfully. The device does not advertise any route for a destination address only if no routes to the destination address can be advertised.

For example, the device learns the route with IP prefix 3.3.3.3/32 from both the BGP VPNv4 address family and BGP EVPN address family. Therefore, there will be two routes to destination address 3.3.3.3 in the BGP routing table of the BGP VPNv4 address family, and the one learned from the BGP EVPN address family is the optimal route. However, this optimal route cannot be advertised to BGP VPNv4 peers, because it was learned from the BGP EVPN address family. As a result, network nodes deployed with only BGP VPNv4 cannot obtain the route with IP prefix 3.3.3.3/32. After you configure this feature, the device will advertise the route with IP prefix 3.3.3.3/32 learned from the BGP VPNv4 address family to BGP VPNv4 peers, although this route is not the optimal route.

Restrictions and guidelines

The bestroute same-rd command takes effect on BGP routes of all VPN instances. Use caution when you execute this command.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure BGP to add the optimal routes with the same route targets as a VPN instance to the IP routing table of the VPN instance, and allow BGP to advertise non-optimal routes to its peers.

bestroute same-rd

By default, BGP adds the optimal routes in the BGP routing table to the IP routing table of a VPN instance and advertises only the optimal routes to its peers.

Enabling the VPN Prefix ORF feature

About VPN Prefix ORF

VPN Prefix ORF introduction

By default, in large-scale networks with route reflectors, the BGP VPNv4 routes reflected by the RR usually include the VPN routes from all BGP-VPN instances on the route originator. The current route limit measures can take effect only on address families. When the number of routes for RR reflection reaches the limit, unwanted BGP-VPN instance routes might occupy most of the receiving end's received routes, resulting in the receiving end not being able to receive the necessary BGP-VPN instance routes.

To resolve this issue, it is required to allow the RR to filter routes based on the BGP-VPN instances of the routes on the originator, implementing router filtering at the granularity of BGP-VPN instances in the BGP VPNv4 address families. Enabling the VPN Prefix Outbound Route Filtering (ORF) feature can resolve the above issue. This feature uses route-refresh messages to send VPN Prefix ORF entries (which contain information for route matching) to peers. Peers will withdraw all previously advertised routes that match the VPN Prefix ORF entries and when sending new routes to the local device, they must filter the routes using both the routing policy on the peer device and the received VPN Prefix ORF entries. Only routes that pass both filters will be sent to the local device. VPN Prefix ORF realizes the advertisement and reception of route control at the BGP-VPN instance granularity. It limits the number of routes at the source of route sending to reduce route exchanges between BGP peers and save network resources.

VPN Prefix ORF operating mechanism

After configuring this feature, the BGP session between the local device and the specified peer/peer group will be disconnected and reestablished for VPN Prefix ORF capability negotiation via Open messages. Negotiation can be successful only if the peer capability-advertise orf vpn-prefix command is configured on both ends of the BGP session. After successful negotiation, the device will be able to parse the route-refresh messages carrying VPN Prefix ORF entries sent by the remote end. A VPN Prefix ORF entry contains a <RD value, source device address> tuple.

NOTE:

If the devices in the BGP session do not support the exchange of route-refresh messages, the VPN Prefix ORF entries will not be successfully sent. Configure the peer capability-advertise route-refresh command on both ends of the BGP session to enable the capability of exchanging route-refresh messages.

For more information the peer capability-advertise route-refresh command, see BGP commands in Layer 3—IP Routing Command Reference.

The VPN Prefix ORF feature uses the following conditions to determine whether to trigger sending VPN Prefix ORF entries:

· The <RD, source device address> tuple used to match VPN routes and the alarm threshold for the matching VPN routes, which is used to match VPN routes.

· The maximum number of routes supported by a BGP-VPN instance, which is set by using the route-limit command.

After these conditions are set on the device, when the number of IPv4 or IPv6 unicast routes in a BGP-VPN instance exceeds the route limit, and the percentage of the routes that match the tuple in the BGP-VPN instance exceeds the alarm threshold:

1. The device checks if there are other BGP-VPN instances configured with the same tuple.

¡ If yes, go to step 2.

¡ If not, go to step 3.

2. The device checks if the number of routes in these BGP-VPN instances has exceeded the route limit and if the number of routes matching the tuple has exceeded the alarm threshold.

¡ If yes, go to step 3.

¡ If not, the BGP-VPN instance that contains routes exceeding the route limit will continue to receive routes and repeat step 2.

3. The device sends a route-refresh message with a VPN Prefix ORF entry to the peer/peer group specified by the peer capability-advertise orf vpn-prefix command.

TIP:

Among the BGP-VPN instances configured with the same tuple, if the number of routes matching the tuple in some BGP-VPN instances has exceeded the alarm threshold, while some BGP-VPN instances have not received any routes matching the tuple, it indicates that these instances cannot receive routes matching the tuple. The device will not consider these BGP-VPN instances when determining whether to trigger sending VPN Prefix ORF entries.

A VPN Prefix ORF entry contains a <RD value, source device address> tuple. The values of RD and source device address are those specified by using the vpn-prefix-quota command.

After receiving a route-refresh message carrying a VPN Prefix ORF entry from the local device, the specified peer/peer group operates as follows:

· Withdraws all BGP VPNv4 routes that match both the RD and source device address in the VPN Prefix ORF entry. (The route information matching the source device address in the VPN Prefix ORF entry is the next hop attribute of the route.)

· No longer sends BGP VPNv4 routes that match the VPN Prefix ORF entry to the local device.

If the device has previously advertised VPN Prefix ORF entries, the entries will remain effective on the peer to filter route advertisement. You can execute the clear bgp vpn-prefix-orf command to withdraw the previously advertised VPN Prefix ORF entries, so that the peer can re-advertise routes that were withdrawn or filtered due to the VPN Prefix ORF entries.

VPN Prefix ORF application network diagram

As shown in Figure 25, VPN instances are configured on each PE. The RR reflects routes from PE 1, PE 2, and PE 3 within the same AS. Both PE 1 and PE 2 have successfully negotiated the VPN Prefix ORF capabilities with the RR. PE 1 specifies the tuple as <RD31, PE3> and the alarm threshold as 70% in the BGP-VPN instances corresponding to VPN1 and VPN2 by using the vpn-prefix-quota command. PE 2 specifies the tuple as <RD31, PE3> and the alarm threshold as 70% in the BGP-VPN instance corresponding to VPN1 by using the vpn-prefix-quota command.

Figure 25 VPN Prefix ORF application network diagram

PE 3 advertises routes of VPN1 through BGP VPNv4. When the advertised routes cause BGP-VPN instances on PE 1 and PE 2 to exceed the route limit, VPN Prefix ORF will function on PE 1 and PE 2 as follows:

· On PE 1

The number of routes in the BGP-VPN instance for VPN1 exceeded the limit, and the number of routes matching <RD31, PE3> exceeded 70% of the total routes. However, PE 1 would not send route-refresh messages carrying VPN Prefix ORF entries because the BGP-VPN instances for VPN2 and VPN1 have the same tuple <RD31, PE3>, and PE 1 could still receive VPN1 routes carrying RT 1 and RT 2 from PE 3 for the BGP-VPN instance corresponding to VPN2. PE 1 will send a route-refresh message carrying a VPN Prefix ORF entry to the RR only when both the BGP-VPN instances for VPN1 and VPN2 have exceeded the route limit and the VPN routes matching the <RD31, PE3> tuple have also exceeded the alarm threshold. The advertised VPN Prefix ORF entry contains the following information: <RD31, min (maximum route count supported by BGP-VPN instance for VPN1, maximum route count supported by BGP-VPN instance for VPN2), PE3 address>.

After receiving the route-refresh message with the VPN Prefix ORF entry, the RR will withdraw the advertised routes that meet the following conditions from PE 1 and will no longer advertise the routes that meet the following conditions to PE 1:

¡ The RD carried by the routes is RD31.

¡ The next hop address of the routes is the address of PE 3.

Figure 26 VPN Prefix ORF taking effect

· On PE 2

When the number of routes in the BGP-VPN instance for VPN1 exceeds the limit, PE 2 will immediately send a route-refresh message carrying a VPN Prefix ORF entry to the RR because no other BGP-VPN instances have specified the same tuple. The advertised VPN Prefix ORF entry contains the following information: <RD31, maximum route count supported by BGP-VPN instance for VPN1, PE3 address>.

After receiving the route-refresh message carrying the VPN Prefix ORF entry, the RR will withdraw the advertised routes that meet the following conditions from PE 2 and will no longer advertise routes that meet the following conditions to PE 2:

¡ The RD carried by the routes is RD31.

¡ The next hop address of the routes is the address of PE 3.

Restrictions and guidelines

In the current software version, only VPN Prefix ORF within the same AS is supported. VPN Prefix ORF across ASs is not supported.

You must configure the route-limit, vpn-prefix-quota route-distinguisher, and peer capability-advertise orf vpn-prefix commands at the same time for VPN Prefix ORF to operate properly.

Procedure

Configuring a VPN instance

1. Enter system view.

system-view

2. Create a VPN instance and enter its view.

ip vpn-instance vpn-instance-name

3. Configure an RD for the VPN instance.

route-distinguisher route-distinguisher

By default, no RD is configured for a VPN instance.

4. Configure route targets for the VPN instance.

vpn-target vpn-target&<1-8> [ both | export-extcommunity | import-extcommunity ]

By default, no route targets are configured for a VPN instance.

Configuring the conditions that trigger the VPN Prefix ORF mechanism

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

For more information about this command, see BGP commands in Layer 3—IP Routing Command Reference.

3. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

For more information about this command, see BGP commands in Layer 3—IP Routing Command Reference.

4. Enter BGP-VPN IPv4 unicast address family view.

address-family ipv4 [ unicast ]

For more information about this command, see BGP commands in Layer 3—IP Routing Command Reference.

5. Set the maximum number of routes supported by the BGP-VPN instance.

route-limit limit

By default, no limit is set to the number of routes supported by a BGP-VPN instance.

6. Set the tuple for routing matching and set the alarm threshold for routes matching the tuple.

vpn-prefix-quota route-distinguisher route-distinguisher source-address { ipv4-address | ipv6-address } quota threshold

By default, no tuple or alarm threshold is set, and no alarm information will be triggered for tuple-matching routes.

Configuring the VPN Prefix ORF feature

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Enable negotiating VPN Prefix ORF capabilities with the specified BGP peer or peer group.

peer { group-name | ipv4-address [ mask-length ] |ipv6-address [ prefix-length ] } capability-advertise orf vpn-prefix { both | send | receive }

By default, the local end does not negotiate VPN Prefix ORF capabilities with BGP peer/peer group.

5. (Optional.) Withdraw the advertised VPN Prefix ORF entries.

a. Execute the following commands in sequence to return to user view:

quit

b. Withdraw the advertised VPN Prefix ORF entries.

clear bgp [ instance instance-name ] vpn-prefix-orf [ vpn-instance vpn-instance-name | route-distinguisher route-distinguisher source-address { ipv4-address | ipv6-address } ]

Configuring route replication

Configuring the public instance

About this task

Configure the public instance to enable the mutual access between public network and private network users.

Restrictions and guidelines

In an MPLS L3VPN network, for the public network and the VPN network to communicate with each other through route target matching, perform the following tasks:

· Configure matching route targets for the public instance and VPN instance.

· Use the route-replicate enable command in BGP instance view to enable mutual BGP route replication between the public and VPN instances.

Procedure

1. Enter system view.

system-view

2. Enter public instance view.

ip public-instance

3. Configure an RD for the public instance.

route-distinguisher route-distinguisher

By default, no RD is configured for the public instance.

4. Configure a route target for the public instance.

vpn-target vpn-target&<1-8> [ both | export-extcommunity | import-extcommunity ]

By default, no route target is configured for the public instance.

5. Enter public instance IPv4 address family view.

address-family ipv4

6. Configure a route target for the IPv4 address family of the public instance.

vpn-target vpn-target&<1-8> [ both | export-extcommunity | import-extcommunity ]

By default, no route target is configured for the IPv4 address family of the public instance.

7. Apply an import routing policy to the public instance.

import route-policy route-policy

By default, all routes matching the import target attribute are accepted.

8. Apply an export routing policy to the public instance.

export route-policy route-policy

By default, routes to be advertised are not filtered.

9. (Optional.) Set the maximum number of active route prefixes supported by the public instance. Choose one or more of the following tasks:

¡ Execute the following commands in sequence to set the maximum number of active route prefixes supported by the public instance:

quit

routing-table limit number { warn-threshold | simply-alert }

¡ Set the maximum number of IPv4 route prefixes supported by the public instance.

routing-table limit number { warn-threshold | simply-alert }

By default, no limit is set for the number of active route prefixes supported by the public instance.

The configuration in public instance IPv4 address family view takes precedence over the configuration in public instance view.

Configuring route replication for public and VPN instances

About this task

In a BGP/MPLS L3VPN network, only VPN instances that have matching route targets can communicate with each other.

The route replication feature provides the following functions:

· Enables a VPN instance to communicate with the public network or other VPN instances by replicating routes from the public instance or other VPN instances.

· Enables the public network to communicate with a VPN instance by replicating routes from the VPN instance.

In an intelligent traffic control network, traffic of different tenants is assigned to different VPNs. To enable the tenants to communicate with the public network, configure this feature to replicate routes from the public instance to the VPN instances.

VLINK direct routes are generated based on ARP entries learned by interfaces. The route-replicate from vpn-instance protocol direct or route-replicate from public protocol direct command replicates VLINK direct routes, but the VLINK direct routes cannot be added to the FIB, causing traffic forwarding failures. To address this issue, you can specify the vlink-direct keyword to replicate VLINK direct routes and add the routes to the FIB.

Configuring a VPN instance to replicate routes from the public instance or another VPN instance

1. Enter system view.

system-view

2. Enter VPN instance view.

ip vpn-instance vpn-instance-name

3. Enter VPN instance IPv4 address family view.

address-family ipv4

4. Replicate routes from the public instance or other VPN instances.

route-replicate from { public | vpn-instance vpn-instance-name } protocol eigrp eigrp-as [ advertise ] [ route-policy route-policy-name ]

route-replicate from { public | vpn-instance vpn-instance-name } protocol { bgp as-number | direct | static | unr | vlink-direct | { isis | ospf | rip } process-id } [ advertise ] [ route-policy route-policy-name ]

By default, a VPN instance cannot replicate routes from the public instance or other VPN instances.

Replicating routes from a VPN instance to the public instance

1. Enter system view.

system-view

2. Enter public instance view.

ip public-instance

3. Enter public instance IPv4 address family view.

address-family ipv4

4. Replicate routes from a VPN instance to the public instance.

route-replicate from vpn-instance vpn-instance-name protocol { bgp as-number | direct | static | unr | vlink-direct | { isis | ospf | rip } process-id } [ advertise ] [ route-policy route-policy-name ]

By default, the public instance cannot replicate routes from VPN instances.

Configuring BGP route replication between public and VPN instances

About this task

In traffic cleaning scenarios, traffic between the public and private networks are filtered by firewalls and traffic of different tenants is assigned to different VPNs. To enable the tenants to communicate with the public network under the protection of firewalls, BGP route replication between public and VPN instances is required.

By default, only VPN instances that have matching route targets can redistribute BGP routes from each other, while the public instance and VPN instances cannot. After you configure this feature, the public instance and VPN instances that have matching route targets can replicate BGP routes from each other, enabling communication between the public network and VPN users.

This feature also replicates the BGP route attributes, so that the device can select proper forwarding paths according to the route attributes.

Restrictions and guidelines

After this feature is enabled, the public network and VPNs cannot be isolated. Configure this feature only in specific scenarios, for example, the traffic cleaning scenario.

To use this feature to implement IPv4 route replication between the public instance and a VPN instance, make sure the VPN instance and the BGP IPv4 unicast address family have been created.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enable BGP route replication between public and VPN instances.

route-replicate enable

By default, BGP route replication between public and VPN instances is disabled.

Enabling redistribution of multiple same-prefix routes with the same RD

About this task

Typically, if multiple same-prefix BGP routes have the same RD as a local BGP VPN instance or the BGP public instance, BGP redistributes only the best one of them into the routing table of that BGP VPN instance or the BGP public instance.

To redistribute multiple same-prefix routes with the same RD into a BGP routing table, perform this task.

This feature enables redistribution of multiple active same-prefix BGP routes that have the same RD, as follows:

· If these routes are in the routing table of a BGP VPN instance or the BGP public instance, BGP redistributes them into the BGP VPNv4, VPNv6, or EVPN routing table, regardless of their route priorities.

· If these routes are in the BGP VPNv4, VPNv6, or EVPN routing table, BGP redistributes them into the BGP VPN instance or the BGP public instance, regardless of their route priorities when the following conditions are met:

¡ The routes have the same RD as the VPN or public instance.

¡ The routes match the import RTs of the VPN or public instance.

Restrictions and guidelines

When enabled in BGP instance view, this feature applies to redistribution of routes from a BGP VPN instance or the BGP public instance into the BGP VPNv4, VPNv6, or EVPN routing table, and vice versa.

When enabled in the view of an address family, this feature takes effect only on redistribution of routes into the BGP routing table for that address family.

Procedure

1. Enter system view.

system-view

2. Enter a BGP address family view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP VPNv4 address family view:

bgp as-number [ instance instance-name ]

address-family vpnv4

3. Enable redistribution of multiple same-prefix routes with the same RD.

vpn-route cross multipath

By default, redistribution of multiple same-prefix routes with the same RD is disabled.

Enabling prioritized withdrawal of specific routes

About this task

This feature enables BGP to send the withdrawal messages of specific routes prior to other routes. This can achieve fast switchover of traffic on the specified routes to available routes to reduce the traffic interruption time.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

4. Enable prioritized withdrawal of the routes that match the specified routing policy.

update-first route-policy route-policy-name

By default, BGP does not send the withdrawal messages of specific routes prior to other routes.

Enabling SNMP notifications for MPLS L3VPN

About this task

To report critical MPLS L3VPN events to an NMS, enable SNMP notifications for MPLS L3VPN. For MPLS L3VPN event notifications to be sent correctly, you must also configure SNMP on the device. For more information about SNMP configuration, see Network Management and Monitoring Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enable SNMP notifications for MPLS L3VPN.

snmp-agent trap enable l3vpn [ vrf-down | vrf-ipv6-down | vrf-ipv6-up | vrf-up ] *

By default, SNMP notifications for MPLS L3VPN are enabled.

Enabling logging for BGP route flapping

About this task

This feature enables BGP to generate logs for BGP route flappings that trigger log generation. The generated logs are sent to the information center. For the logs to be output correctly, you must also configure information center on the device. For more information about the information center, see Network Management and Monitoring Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter BGP VPNv4 address family view or BGP-VPN VPNv4 address family view.

¡ Execute the following commands in sequence to enter BGP VPNv4 address family view:

bgp as-number [ instance instance-name ]

address-family vpnv4

¡ Execute the following commands in sequence to enter BGP-VPN VPNv4 address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family vpnv4

3. Enable logging for BGP route flapping.

log-route-flap monitor-time monitor-count [ log-count-limit | route-policy route-policy-name ] *

By default, logging for BGP route flapping is disabled.

Display and maintenance commands for MPLS L3VPN

Resetting BGP connections

You can soft-reset or reset BGP sessions to apply new BGP configurations. A soft reset operation updates BGP routing information without tearing down BGP connections. A reset operation updates BGP routing information by tearing down, and then re-establishing BGP connections. Soft reset requires that BGP peers have route refresh capability.

Execute the following commands in user view to soft reset or reset BGP connections:

Task	Command
Soft-reset BGP sessions for the VPNv4 address family.	refresh bgp [ instance instance-name ] { ipv4-address [ mask-length ] \| all \| external \| group group-name \| internal } { export \| import } vpnv4 [ vpn-instance vpn-instance-name ]
Soft-reset BGP sessions for the BGP IPv4 RT filter family.	refresh bgp [ instance instance-name ] { ipv4-address [ mask-length ] \| all \| external \| group group-name \| internal } { export \| import } ipv4 rtfilter
Reset BGP sessions for the VPNv4 address family.	reset bgp [ instance instance-name ] { as-number \| ipv4-address [ mask-length ] \| all \| external \| internal \| group group-name } vpnv4 [ vpn-instance vpn-instance-name ]
Reset BGP sessions for the BGP IPv4 RT filter family.	reset bgp [ instance instance-name ] { as-number \| ipv4-address [ mask-length ] \| all \| external \| internal \| group group-name } ipv4 rtfilter

‌

For more information about the refresh bgp vpnv4 and reset bgp vpnv4 commands, see Layer 3—IP Routing Command Reference.

Displaying and maintaining MPLS L3VPN information

Execute the following display commands in any view and reset commands in user view to display and maintain MPLS L3VPN information:

Task	Command
Display BGP VPNv4 route dampening parameters.	display bgp [ instance instance-name ] dampening parameter vpnv4
Display BGP RT filter peer group information.	display bgp [ instance instance-name ] group ipv4 rtfilter [ group-name group-name ]
Display BGP VPNv4 peer group information.	display bgp [ instance instance-name ] group vpnv4 [ vpn-instance vpn-instance-name ] [ group-name group-name ]
Display BGP RT filter information.	display bgp [ instance instance-name ] ipv4 rtfilter [ peer ipv4-address [ statistics ] \| statistics ]
Display BGP RT filter peer information.	display bgp [ instance instance-name ] peer ipv4 rtfilter [ ipv4-address mask-length \| { ipv4-address \| group-name group-name } log-info \| [ ipv4-address ] verbose ]
Display BGP VPNv4 peer information.	display bgp [ instance instance-name ] peer vpnv4 [ vpn-instance vpn-instance-name ] [ ipv4-address mask-length \| { ipv4-address \| group-name group-name } log-info \| [ ipv4-address ] verbose ]
Display information about dampened BGP VPNv4 routes.	display bgp [ instance instance-name ] routing-table dampened vpnv4
Display BGP VPNv4 route flapping information.	display bgp [ instance instance-name ] routing-table flap-info vpnv4 [ ipv4-address [ { mask \| mask-length } [ longest-match ] ] \| as-path-acl as-path-acl-number ]
Display incoming labels for BGP IPv4 unicast routes.	display bgp [ instance instance-name ] routing-table ipv4 [ unicast ] [ vpn-instance vpn-instance-name ] inlabel
Display outgoing labels for BGP IPv4 unicast routes.	display bgp [ instance instance-name ] routing-table ipv4 [ unicast ] [ vpn-instance vpn-instance-name ] outlabel
Display BGP IPv4 RT filter routing information.	display bgp [ instance instance-name ] routing-table ipv4 rtfilter [ default-rt [ advertise-info ] \| [ origin-as as-number ] [ route-target [ advertise-info ] ] \| as-path-acl { as-path-acl-number \| as-path-acl-name } \| as-path-regular-expression regular-expression \| peer ipv4-address { advertised-routes \| received-routes } [ default-rt \| [ origin-as as-number ] [ route-target ] \| statistics ] \| statistics ] display bgp [ instance instance-name ] routing-table ipv4 rtfilter time-range min-time max-time
Display BGP VPNv4 routes.	display bgp [ instance instance-name ] routing-table vpnv4 [ [ route-distinguisher route-distinguisher ] [ ipv4-address [ { mask-length \| mask } [ longest-match ] ] \| ipv4-address [ mask-length \| mask ] advertise-info \| as-path-acl as-path-acl-number \| as-path-regular-expression regular-expression \| [ statistics ] { community [ community-number&<1-32> \| aa:nn&<1-32> ] [ internet \| no-advertise \| no-export \| no-export-subconfed ] [ whole-match ] \| community-list { { basic-community-list-number \| comm-list-name } [ whole-match ] \| adv-community-list-number } ] \| [ vpn-instance vpn-instance-name ] peer ipv4-address { advertised-routes \| received-routes } [ ipv4-address [ mask-length \| mask ] [ verbose ] \| statistics ] \| peer ipv6-address { advertised-routes \| received-routes } [ ipv4-address [ mask-length \| mask ] [ verbose ] \| statistics ] \| statistics ] display bgp [ instance instance-name ] routing-table vpnv4 [ route-distinguisher route-distinguisher ] [ ipv4-address [ mask-length \| mask ] ] [ statistics ] { large-community [ aa:bb:cc&<1-32> ] \| large-community-list { basic-large-community-list-number \| adv-large-community-list-number \| large-comm-list-name } } [ whole-match ] display bgp [ instance instance-name ] routing-table vpnv4 [ route-distinguisher route-distinguisher ] [ ipv4-address [ mask-length \| mask ] ] statistics source { evpn-remote-import \| local \| local-import \| remote-import } display bgp [ instance instance-name ] routing-table vpnv4 [ same-rd-selected ] display bgp [ instance instance-name ] routing-table vpnv4 { [ vpn-instance vpn-instance-name ] peer ipv4-address \| peer ipv6-address } { accepted-routes \| not-accepted-routes } display bgp [ instance instance-name ] routing-table vpnv4 [ route-distinguisher route-distinguisher \| vpn-instance vpn-instance-name peer ipv4-address ] time-range min-time max-time
Display BGP VPNv4 route source information.	display bgp [ instance instance-name ] routing-table vpnv4 source-type
Display incoming labels for BGP VPNv4 routes.	display bgp [ instance instance-name ] routing-table vpnv4 inlabel
Display outgoing labels for BGP VPNv4 routes.	display bgp [ instance instance-name ] routing-table vpnv4 outlabel
Display BGP IPv4 RT filter address family update group information.	display bgp [ instance instance-name ] update-group ipv4 rtfilter [ ipv4-address ]
Display BGP VPNv4 address family update group information.	display bgp [ instance instance-name ] update-group vpnv4 [ vpn-instance vpn-instance-name ] [ ipv4-address ]
Display BGP peer and routing summary information.	display bgp [ instance instance-name ] vpnv4 summary
Display route targets sourcing from a VPN instance.	display bgp [ instance instance-name ] route-target l3vpn [ ipv4 ] [ vpn-instance vpn-instance-name ]
Display received and advertised VPN Prefix ORF entries.	display bgp [ instance instance-name ] vpn-prefix-orf [ route-distinguisher route-distinguisher source-address { ipv4-address \| ipv6-address } ]
Display the FIB of a VPN instance.	display fib vpn-instance vpn-instance-name
Display FIB entries that match the specified destination IP address in the specified VPN instance.	display fib vpn-instance vpn-instance-name ip-address [ mask-length \| mask ]
Display the routing table for a VPN instance.	display ip routing-table vpn-instance vpn-instance-name [ statistics \| verbose ]
Display information about a specific or all VPN instances.	display ip vpn-instance [ instance-name vpn-instance-name \| count ]
Display OSPF sham link information.	display ospf [ process-id ] sham-link [ area area-id ]
Clear BGP VPNv4 route dampening information and release dampened routes.	reset bgp [ instance instance-name ] dampening vpnv4 [ ipv4-address [ mask \| mask-length ] ]
Clear BGP VPNv4 route flapping statistics.	reset bgp [ instance instance-name ] flap-info vpnv4 [ ipv4-address [ mask \| mask-length ] \| as-path-acl as-path-acl-number \| peer ipv4-address [ mask-length ] ]

‌

For more information about the following commands, see BGP commands in Layer 3—IP Routing Command Reference:

· display ip routing-table

· display bgp group vpnv4

· display bgp peer vpnv4

· display bgp update-group vpnv4

09-MPLS Configuration Guide

About MPLS L3VPN

MPLS L3VPN concepts

MP-BGP

MPLS L3VPN route advertisement

Inter-AS VPN

Carrier's carrier

Multirole host

OSPF VPN extension

BGP AS number substitution and SoO attribute

Protocols and standards

Prerequisites for MPLS L3VPN

Configuring VPN instances

About this task

Restrictions and guidelines

Procedure

Restrictions and guidelines

Procedure

Restrictions and guidelines

Prerequisites

Procedure

Configuring routing between a PE and a CE

Configuring static routing between a PE and a CE

About this task

Procedure

Configuring RIP between a PE and a CE

About this task

Procedure

Configuring OSPF between a PE and a CE

About this task

Procedure

About this task

Procedure

Configuring routing between PEs

Configuring BGP VPNv4 route reflection

About this task

Procedure

Configuring BGP VPNv4 route attributes

Configuring BGP VPNv4 route filtering

Configuring BGP VPNv4 route dampening

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Changing the BGP VPNv4 route selection rules

About this task

Preferring routes learned from a peer or peer group during optimal route selection

Preferring routes with the specified type of next hop addresses during optimal route selection

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Configuring inter-AS option A

Configuring inter-AS option C (method 1)

Configuring an ASBR (exchanging labeled routes in BGP IPv4 unicast address family)

Configuring inter-AS option C (method 2)

Restrictions and guidelines

Procedure

Configuring multirole host

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines