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.

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 attributes

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.

Similar to RDs, route target attributes use one of the following formats:

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

· 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 IPv4 address:16-bit user-defined number, for example, 172.1.1.1: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, 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, 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 or MPLS TE tunnel. Based on the outer tag, a VPN packet can be forwarded along the public tunnel to the remote PE. For an LSP or MPLS TE tunnel, the outer tag is an MPLS label.

· 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:

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

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

3. P devices forward the packet to PE 2 by the outer tag. The outer tag (MPLS label) is removed from the packet at the penultimate hop.

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

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

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 5 Basic architecture of HoVPN

‌

As shown in Figure 5, 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 6 Recursion of HoPEs

‌

Figure 6 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 7 Network diagram for BGP/OSPF interaction

‌

As shown in Figure 7, 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:

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

2. 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:

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

2. 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 8, 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 8 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.

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 9 Application of BGP AS number substitution and SoO attribute

‌

As shown in Figure 9, 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 10. 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 10 Network diagram

As shown in Figure 10, 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 11 Network diagram

As shown in Figure 11, 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 12 Network diagram

‌

As shown in Figure 12, 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.

ECMP VPN route redistribution

This feature enables a VPN instance to redistribute all routes that have the same prefix and RD into its routing table. Based on the ECMP routes, the device can perform load sharing (as configured by the balance command) or MPLS L3VPN FRR. For more information about the balance command, see BGP in Layer 3—IP Routing Command Reference.

Figure 13 Network diagram

‌

As shown in Figure 13, CE 1 accesses the backbone network through VPN instance VPN1 created on PE 1. The RD of VPN instance VPN1 is 1:1. CE 2 accesses the backbone network through VPN instances created on PE 2 and PE 3. The VPN instances created on PE 2 and PE 3 have the same name VPN2 and the same RD 1:2. VPN instances VPN1 and VPN2 can communicate with each other.

Both PE 2 and PE 3 can advertise routes from CE 2 to PE 1, and the advertised routes have the same RD 1:2. By default, BGP redistributes only the optimal route into the routing table of VPN instance VPN1. After you enable this feature on VPN instance VPN1, BGP redistributes routes from both PE 2 and PE 3 to the routing table of VPN instance VPN1.

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

2. Configuring advanced MPLS L3VPN networks

Choose the following tasks as needed:

¡ Configuring HoVPN

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

3. (Optional.) Configuring MPLS L3VPN FRR

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

5. (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.

¡ Enabling independent routing tables for BGP VPNv4 routes and BGP-VPN instance routes

¡ 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 ECMP VPN route redistribution

Perform this task to enable a VPN instance to redistribute all routes that have the same prefix and RD into its routing table to perform load sharing or MPLS L3VPN FRR.

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

6. (Optional.) Maintaining MPLS L3VPN networks

¡ Enabling SNMP notifications for MPLS L3VPN

¡ Enabling logging for BGP route flapping

¡ Enabling MPLS label forwarding statistics for a VPN instance

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

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 is not associated with a VPN instance and belongs to the public network.

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. Apply a tunnel policy to the VPN instance.

tnl-policy tunnel-policy-name

By default, only one tunnel is selected (no load balancing) in this order: LSP tunnel, CRLSP tunnel, and SRLSP tunnel.

If the specified tunnel policy does not exist, the default tunnel policy is used.

For information about tunnel policies, 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 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.

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

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.

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.

mpls bfd dest-addr mask-length [ nexthop nexthop-address [ discriminator local local-id remote remote-id ] ] [ template template-name ]

¡ Configure BFD to test the connectivity of the MPLS TE tunnel for the tunnel interface.

interface tunnel number mode mpls-te

mpls bfd [ discriminator local local-id remote remote-id ] [ 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.

mpls bfd dest-addr mask-length [ nexthop nexthop-address [ discriminator local local-id remote remote-id ] ] [ template template-name ]

¡ Use BFD to test the connectivity of the MPLS TE tunnel for the tunnel interface.

interface tunnel number mode mpls-te

mpls bfd [ discriminator local local-id remote remote-id ] [ 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.

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, the interface is not associated with any VPN instances and belongs to the public network.

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 | 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 ] } 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 ] } 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

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

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.

Enabling independent routing tables for BGP VPNv4 routes and BGP-VPN instance routes

About this task

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 (the routing-table independent enable command) to resolve this issue. After this feature is enabled, only BGP VPNv4 optimal routes with matching route targets of a VPN instance can be added to the corresponding BGP-VPN instance routing table. These routes can participate in optimal route selection together with other routes in the BGP-VPN instance routing table and the selection result is independent of that in the BGP VPNv4 routing table. This mechanism allows the BGP-VPN instance routing table to contain only the BGP routes with matching route targets of the corresponding VPN instance. So the optimal routes selected in the BGP-VPN instance routing table can always be added to the VPN instance IP routing table.

For example, a PE has learned two routes with the same prefix (10.10.10.10/32) and different next hops through BGP VPNv4 sessions.

<Sysname> display bgp routing-table vpnv4

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external,

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Total number of VPN routes: 3

Total number of routes from all PEs: 2

Route distinguisher: 10:1(vpn1)

Total number of routes: 2

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 10.10.10.10/32 1.1.1.1 0 100 0 i

* i 3.3.3.3 0 100 0 i

Route distinguisher: 20:1

Total number of routes: 1

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 10.10.10.10/32 3.3.3.3 0 100 0 i

NOTE:

In the BGP VPNv4 routing table, route entries are listed by RD. In the previous output, the BGP VPNv4 routing table contains two route lists, one for RD 10:1 and the other for RD 20:1.

The route with next hop address 3.3.3.3 has matching route target values of VPN instance vpn1, while the route with next hop address 1.1.1.1 does not. The route with next hop 3.3.3.3 is added to the BGP-VPN instance routing table of vpn1. The BGP VPNv4 of RD 10:1 and the BGP-VPN instance share the same route entries, so the BGP VPNv4 routing table for RD 10:1 also contains the route with next hop 3.3.3.3. In the BGP VPNv4 routing table for RD 10:1, the route with next hop 3.3.3.3 and the route with next hop 1.1.1.1 participate in optimal route selection and the route with next hop 1.1.1.1 is selected as the optimal route. However, the route target attribute of the route with next hop 1.1.1.1 does not match that of vpn1, so this route is not available in the BGP-VPN instance routing table of vpn1. As a result, there is no optimal route destined for 10.10.10.10/32 in the BGP-VPN instance routing table of vpn1.

<Sysname> display bgp routing-table ipv4 vpn-instance vpn1

Total number of routes: 1

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external,

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* i 10.10.10.10/32 3.3.3.3 0 100 0 i

After this feature is configured, the BGP VPNv4 routing table and the BGP-VPN instance routing table no longer share route entries. The BGP VPNv4 routing table is as follows:

<Sysname> display bgp routing-table vpnv4

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external,

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Total number of VPN routes: 3

Total number of routes from all PEs: 2

Route distinguisher: 10:1

Total number of routes: 1

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 10.10.10.10/32 1.1.1.1 0 100 0 i

Route distinguisher: 10:1(vpn1)

Total number of routes: 1

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 10.10.10.10/32 3.3.3.3 0 100 0 i

Route distinguisher: 20:1

Total number of routes: 1

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 10.10.10.10/32 3.3.3.3 0 100 0 i

The route with next hop 1.1.1.1 is selected as the optimal route for RD 10:1. However, the route target attribute of the route with next hop 1.1.1.1 does not match that of vpn1, so this route cannot be added to the BGP-VPN instance routing table of vpn1.

The route with next hop 3.3.3.3 is selected as the optimal route for RD 20:1, and the route target attribute of the route matches that of vpn1. So this route can be added to the BGP-VPN instance routing table of vpn1 and selected as an optimal route and thus added to the IP routing table of vpn1.

<Sysname> display bgp routing-table ipv4 vpn-instance vpn1

Total number of routes: 1

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external,

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >i 10.10.10.10/32 3.3.3.3 0 100 0 i

IP prefix routes can be added to a BGP-VPN instance routing table. When the optimal route for an IP prefix in the VPNv4 address family does not match the route targets of the local VPN instance, this feature also can add the route with the same IP prefix learned from the BGP EVPN address family to the BGP-VPN instance routing table. The IP prefix advertisement route added to the BGP-VPN instance routing table can be selected as an optimal route and added to the IP routing table of the VPN instance.

This feature also provides the following function:

· Before this feature is enabled, the peer re-originated command cannot modify the route information for received BGP VPNv4 routes that have the same RD as the local VPN instance.

· After this feature is enabled, the peer re-originated command can modify the route information for all received BGP VPNv4 routes.

Restrictions and guidelines

The bestroute same-rd command and the routing-table independent enable command can implement similar functions. The differences include the following:

· The bestroute same-rd command ignores the routes that do not have matching route targets of the local VPN instance, and enables BGP to add other routes that have the same IP prefix and matching route targets (if any in the BGP VPNv4 routing table) to the IP routing table of the VPN instance.

· The routing-table independent enable command uses the routes learned from other BGP routing tables to implement the function of adding BGP routes to the IP routing table of the VPN instance. In the BGP VPNv4 routing table for an RD, the route without matching route targets still cannot be added to the IP routing table of the VPN instance. This feature applies to the following scenarios:

¡ There are optimal routes with the same IP prefix in the BGP VPNv4 route entries for different RDs.

¡ An IP prefix advertisement route in the BGP EVPN routing table and a VPNv4 route in the BGP VPNv4 routing table have the same IP prefix.

¡ The peer re-originated command is configured to modify the route information for received BGP VPNv4 routes that have the same RD as the local VPN instance.

After the routing-table independent enable command is executed, the bestroute same-rd command no longer takes effect.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enabling independent routing tables for BGP VPNv4 routes and BGP-VPN instance routes.

routing-table independent enable

By default, BGP VPNv4 routes and BGP-VPN routes share the same route entries. The BGP routes in BGP-VPN instance routing table can also be displayed in the BGP VPNv4 routing table. For the same VPN instance, it has the same optimal route selection result in BGP VPNv4 routing table and in the BGP-VPN instance routing table.

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.

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.

After the routing-table independent enable command is executed, the bestroute same-rd command no longer takes effect. For more information about the differences of the two commands, see "Enabling independent routing tables for BGP VPNv4 routes and BGP-VPN instance routes."

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 15, 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 15 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 16 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 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 { bgp as-number | direct | static | unr | vlink-direct | { isis | ospf } 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 } 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 ECMP VPN route redistribution

About this task

For multiple routes that have the same prefix and RD, a VPN instance redistributes only the optimal route into its routing table by default. This feature enables a VPN instance to redistribute all routes that have the same prefix and RD into its routing table to perform load sharing or MPLS L3VPN FRR.

Restrictions and guidelines

· The configuration in BGP instance view takes effect on all address families.

· The configuration in BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view takes effect only on the address family.

· The configuration in BGP IPv4 unicast address family view or BGP-VPN IPv4 unicast address family view takes precedence over that in BGP instance view.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view, BGP IPv4 unicast address family view, or BGP-VPN IPv4 unicast 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 ECMP VPN route redistribution.

vpn-route cross multipath

By default, ECMP VPN route redistribution is disabled. If multiple routes have the same prefix and RD, a VPN instance redistributes only the optimal route into its routing table.

In BGP IPv4 unicast address family view, this command redistributes ECMP routes to the routing table of the public instance. For more information about the public instance, see EVPN Configuration Guide.

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.

Enabling MPLS label forwarding statistics for a VPN instance

About this task

MPLS label forwarding statistics for a VPN instance include inbound and outbound statistics.

· Inbound statistics provide information about the labeled packets that the local PE receives from the remote PE. The local PE forwards these packets to the CE of the VPN instance according to the incoming label of the packets.

· Outbound statistics provide information about the labeled packets that the local PE sends to the remote PE. After the local PE receives packets from the CE of the VPN instance, it labels the packets and then forwards the labeled packets to the remote PE.

Perform this task to enable MPLS label forwarding statistics for a VPN instance. Then, you can use the display ip vpn-instance mpls statistics command to view MPLS label forwarding statistics

Restrictions and guidelines

Perform this task on PEs.

Procedure

1. Enter system view.

system-view

2. Set the MPLS label forwarding statistics collection interval.

mpls statistics interval interval

By default, MPLS label forwarding statistics interval is 30 seconds.

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

3. Enter VPN instance view.

ip vpn-instance vpn-instance-name

4. Enable MPLS label forwarding statistics for the VPN instance.

mpls statistics enable

By default, MPLS label forwarding statistics is disabled for all VPN instances.

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

Displaying and maintaining VPN instance statistics

Execute the following display commands in any view and reset commands in user view to display and maintain VPN instance statistics:

Task	Command
Display MPLS label forwarding statistics for VPN instances.	display ip vpn-instance mpls statistics [ instance-name vpn-instance-name ]
Clear MPLS label forwarding statistics for VPN instances.	reset ip vpn-instance mpls statistics [ instance-name vpn-instance-name ]

‌

MPLS L3VPN configuration examples

Example: Configuring basic MPLS L3VPN

Network configuration

CE 1 and CE 3 belong to VPN 1. CE 2 and CE 4 belong to VPN 2.

VPN 1 uses route target attribute 111:1. VPN 2 uses route target attribute 222:2. Users of different VPNs cannot access each other.

A PE and its connected CE use EBGP to exchange VPN routing information.

PEs use OSPF to communicate with each other and use MP-IBGP to exchange VPN routing information.

Figure 17 Network diagram

‌

Table 1 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
CE 1	XGE2/0/0	10.1.1.1/24	P	Loop0	2.2.2.9/32
PE 1	Loop0	1.1.1.9/32		XGE2/0/3	172.1.1.2/24
	XGE2/0/0	10.1.1.2/24		XGE2/0/4	172.2.1.1/24
	XGE2/0/1	10.2.1.2/24	PE 2	Loop0	3.3.3.9/32
	XGE2/0/3	172.1.1.1/24		XGE2/0/0	10.3.1.2/24
CE 2	XGE2/0/0	10.2.1.1/24		XGE2/0/1	10.4.1.2/24
CE 3	XGE2/0/0	10.3.1.1/24		XGE2/0/3	172.2.1.2/24
CE 4	XGE2/0/0	10.4.1.1/24

‌

Procedure

1. Configure OSPF on the MPLS backbone to ensure IP connectivity within the backbone:

# Configure PE 1.

<PE1> system-view

[PE1] interface loopback 0

[PE1-LoopBack0] ip address 1.1.1.9 32

[PE1-LoopBack0] quit

[PE1] interface ten-gigabitethernet 2/0/3

[PE1-Ten-GigabitEthernet2/0/3] ip address 172.1.1.1 24

[PE1-Ten-GigabitEthernet2/0/3] quit

[PE1] ospf

[PE1-ospf-1] area 0

[PE1-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255

[PE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0

[PE1-ospf-1-area-0.0.0.0] quit

[PE1-ospf-1] quit

# Configure the P device.

<P> system-view

[P] interface loopback 0

[P-LoopBack0] ip address 2.2.2.9 32

[P-LoopBack0] quit

[P] interface ten-gigabitethernet 2/0/3

[P-Ten-GigabitEthernet2/0/3] ip address 172.1.1.2 24

[P-Ten-GigabitEthernet2/0/3] quit

[P] interface ten-gigabitethernet 2/0/4

[P-Ten-GigabitEthernet2/0/4] ip address 172.2.1.1 24

[P-Ten-GigabitEthernet2/0/4] quit

[P] ospf

[P-ospf-1] area 0

[P-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255

[P-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255

[P-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0

[P-ospf-1-area-0.0.0.0] quit

[P-ospf-1] quit

# Configure PE 2.

<PE2> system-view

[PE2] interface loopback 0

[PE2-LoopBack0] ip address 3.3.3.9 32

[PE2-LoopBack0] quit

[PE2] interface ten-gigabitethernet 2/0/3

[PE2-Ten-GigabitEthernet2/0/3] ip address 172.2.1.2 24

[PE2-Ten-GigabitEthernet2/0/3] quit

[PE2] ospf

[PE2-ospf-1] area 0

[PE2-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255

[PE2-ospf-1-area-0.0.0.0] network 3.3.3.9 0.0.0.0

[PE2-ospf-1-area-0.0.0.0] quit

[PE2-ospf-1] quit

# Execute the display ospf peer command to verify that OSPF adjacencies in Full state have been established between PE 1, P, and PE 2. Execute the display ip routing-table command to verify that the PEs have learned the routes to the loopback interfaces of each other. (Details not shown.)

2. Configure basic MPLS and MPLS LDP on the MPLS backbone to establish LDP LSPs:

# Configure PE 1.

[PE1] mpls lsr-id 1.1.1.9

[PE1] mpls ldp

[PE1-ldp] quit

[PE1] interface ten-gigabitethernet 2/0/3

[PE1-Ten-GigabitEthernet2/0/3] mpls enable

[PE1-Ten-GigabitEthernet2/0/3] mpls ldp enable

[PE1-Ten-GigabitEthernet2/0/3] quit

# Configure the P device.

[P] mpls lsr-id 2.2.2.9

[P] mpls ldp

[P-ldp] quit

[P] interface ten-gigabitethernet 2/0/3

[P-Ten-GigabitEthernet2/0/3] mpls enable

[P-Ten-GigabitEthernet2/0/3] mpls ldp enable

[P-Ten-GigabitEthernet2/0/3] quit

[P] interface ten-gigabitethernet 2/0/4

[P-Ten-GigabitEthernet2/0/4] mpls enable

[P-Ten-GigabitEthernet2/0/4] mpls ldp enable

[P-Ten-GigabitEthernet2/0/4] quit

# Configure PE 2.

[PE2] mpls lsr-id 3.3.3.9

[PE2] mpls ldp

[PE2-ldp] quit

[PE2] interface ten-gigabitethernet 2/0/3

[PE2-Ten-GigabitEthernet2/0/3] mpls enable

[PE2-Ten-GigabitEthernet2/0/3] mpls ldp enable

[PE2-Ten-GigabitEthernet2/0/3] quit

# Execute the display mpls ldp peer command to verify that LDP sessions in Operational state have been established between PE 1, P, and PE 2. Execute the display mpls ldp lsp command to verify that the LSPs have been established by LDP. (Details not shown.)

3. Configure VPN instances on PEs to allow CE access:

# Configure PE 1.

[PE1] ip vpn-instance vpn1

[PE1-vpn-instance-vpn1] route-distinguisher 100:1

[PE1-vpn-instance-vpn1] vpn-target 111:1

[PE1-vpn-instance-vpn1] quit

[PE1] ip vpn-instance vpn2

[PE1-vpn-instance-vpn2] route-distinguisher 100:2

[PE1-vpn-instance-vpn2] vpn-target 222:2

[PE1-vpn-instance-vpn2] quit

[PE1] interface ten-gigabitethernet 2/0/0

[PE1-Ten-GigabitEthernet2/0/0] ip binding vpn-instance vpn1

[PE1-Ten-GigabitEthernet2/0/0] ip address 10.1.1.2 24

[PE1-Ten-GigabitEthernet2/0/0] quit

[PE1] interface ten-gigabitethernet 2/0/1

[PE1-Ten-GigabitEthernet2/0/1] ip binding vpn-instance vpn2

[PE1-Ten-GigabitEthernet2/0/1] ip address 10.2.1.2 24

[PE1-Ten-GigabitEthernet2/0/1] quit

# Configure PE 2.

[PE2] ip vpn-instance vpn1

[PE2-vpn-instance-vpn1] route-distinguisher 200:1

[PE2-vpn-instance-vpn1] vpn-target 111:1

[PE2-vpn-instance-vpn1] quit

[PE2] ip vpn-instance vpn2

[PE2-vpn-instance-vpn2] route-distinguisher 200:2

[PE2-vpn-instance-vpn2] vpn-target 222:2

[PE2-vpn-instance-vpn2] quit

[PE2] interface ten-gigabitethernet 2/0/0

[PE2-Ten-GigabitEthernet2/0/0] ip binding vpn-instance vpn1

[PE2-Ten-GigabitEthernet2/0/0] ip address 10.3.1.2 24

[PE2-Ten-GigabitEthernet2/0/0] quit

[PE2] interface ten-gigabitethernet 2/0/1

[PE2-Ten-GigabitEthernet2/0/1] ip binding vpn-instance vpn2

[PE2-Ten-GigabitEthernet2/0/1] ip address 10.4.1.2 24

[PE2-Ten-GigabitEthernet2/0/1] quit

# Configure IP addresses for the CEs according to Figure 17. (Details not shown.)

# Execute the display ip vpn-instance command on the PEs to display the configuration of the VPN instance. Use the ping command on the PEs to verify that the PEs can ping their attached CEs. (Details not shown.)

4. Establish EBGP peer relationships between PEs and CEs, and redistribute VPN routes into BGP:

# Configure CE 1.

<CE1> system-view

[CE1] bgp 65410

[CE1-bgp-default] peer 10.1.1.2 as-number 100

[CE1-bgp-default] address-family ipv4 unicast

[CE1-bgp-default-ipv4] peer 10.1.1.2 enable

[CE1-bgp-default-ipv4] import-route direct

[CE1-bgp-default-ipv4] quit

[CE1-bgp-default] quit

# Configure the other three CEs in the same way that CE 1 is configured. (Details not shown.)

# Configure PE 1.

[PE1] bgp 100

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] peer 10.1.1.1 as-number 65410

[PE1-bgp-default-vpn1] address-family ipv4 unicast

[PE1-bgp-default-ipv4-vpn1] peer 10.1.1.1 enable

[PE1-bgp-default-ipv4-vpn1] quit

[PE1-bgp-default-vpn1] quit

[PE1-bgp-default] ip vpn-instance vpn2

[PE1-bgp-default-vpn2] peer 10.2.1.1 as-number 65420

[PE1-bgp-default-vpn2] address-family ipv4 unicast

[PE1-bgp-default-ipv4-vpn2] peer 10.2.1.1 enable

[PE1-bgp-default-ipv4-vpn2] quit

[PE1-bgp-default-vpn2] quit

[PE1-bgp-default] quit

# Configure PE 2 in the same way that PE 1 is configured. (Details not shown.)

# Execute the display bgp peer ipv4 vpn-instance command on the PEs to verify that a BGP peer relationship in Established state has been established between a PE and a CE. (Details not shown.)

5. Create an MP-IBGP peer relationship between PEs:

# Configure PE 1.

[PE1] bgp 100

[PE1-bgp-default] peer 3.3.3.9 as-number 100

[PE1-bgp-default] peer 3.3.3.9 connect-interface loopback 0

[PE1-bgp-default] address-family vpnv4

[PE1-bgp-default-vpnv4] peer 3.3.3.9 enable

[PE1-bgp-default-vpnv4] quit

[PE1-bgp-default] quit

# Configure PE 2.

[PE2] bgp 100

[PE2-bgp-default] peer 1.1.1.9 as-number 100

[PE2-bgp-default] peer 1.1.1.9 connect-interface loopback 0

[PE2-bgp-default] address-family vpnv4

[PE2-bgp-default-vpnv4] peer 1.1.1.9 enable

[PE2-bgp-default-vpnv4] quit

[PE2-bgp-default] quit

# Execute the display bgp peer vpnv4 command on the PEs to verify that a BGP peer relationship in Established state has been established between the PEs. (Details not shown.)

Verifying the configuration

# Execute the display ip routing-table vpn-instance command on the PEs.

[PE1] display ip routing-table vpn-instance vpn1

Destinations : 11 Routes : 11

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

10.1.1.0/24 Direct 0 0 10.1.1.2 XGE2/0/0

10.1.1.0/32 Direct 0 0 10.1.1.2 XGE2/0/0

10.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

10.1.1.255/32 Direct 0 0 10.1.1.2 XGE2/0/0

10.3.1.0/24 BGP 255 0 3.3.3.9 XGE2/0/3

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

The output shows that PE 1 has a route to the remote CE. Output on PE 2 is similar.

# Verify that CEs of the same VPN can ping each other, whereas those of different VPNs cannot. For example, CE 1 can ping CE 3 (10.3.1.1), but it cannot ping CE 4 (10.4.1.1). (Details not shown.)

Example: Configuring MPLS L3VPN inter-AS option C (method 1) (exchanging labeled routes in BGP IPv4 labeled unicast address family

Network configuration

Site 1 and Site 2 belong to the same VPN. Site 1 accesses the network through PE 1 in AS 100, and Site 2 accesses the network through PE 2 in AS 600. PEs in the same AS run IS-IS.

PE 1 and ASBR-PE 1 establish a session in BGP IPv4 labeled unicast address family to exchange IPv4 labeled routes.

PE 2 and ASBR-PE 2 establish a session in BGP IPv4 labeled unicast address family to exchange IPv4 labeled routes.

PE 1 and PE 2 establish an MP-EBGP session to exchange VPNv4 routes.

ASBR-PE 1 and ASBR-PE 2 establish a session in BGP IPv4 labeled unicast address family to exchange IPv4 labeled routes.

Figure 18 Network diagram

‌

Table 2 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
PE 1	Loop0	2.2.2.9/32	PE 2	Loop0	5.5.5.9/32
	XGE2/0/0	30.0.0.1/24		XGE2/0/0	20.0.0.1/24
	XGE2/0/4	1.1.1.2/8		XGE2/0/4	9.1.1.2/8
ASBR-PE 1	Loop0	3.3.3.9/32	ASBR-PE 2	Loop0	4.4.4.9/32
	XGE2/0/4	1.1.1.1/8		XGE2/0/4	9.1.1.1/8
	XGE2/0/3	11.0.0.2/8		XGE2/0/3	11.0.0.1/8
CE 1	XGE2/0/0	30.0.0.2/24	CE 2	XGE2/0/0	20.0.0.2/24

‌

Procedure

1. Configure CE 1:

# Configure an IP address for Ten-GigabitEthernet2/0/0.

<CE1> system-view

[CE1] interface ten-gigabitethernet 2/0/0

[CE1-Ten-GigabitEthernet2/0/0] ip address 30.0.0.2 24

[CE1-Ten-GigabitEthernet2/0/0] quit

# Establish an EBGP peer relationship with PE 1, and redistribute VPN routes.

[CE1] bgp 65001

[CE1-bgp-default] peer 30.0.0.1 as-number 100

[CE1-bgp-default] address-family ipv4 unicast

[CE1-bgp-default-ipv4] peer 30.0.0.1 enable

[CE1-bgp-default-ipv4] import-route direct

[CE1-bgp-default-ipv4] quit

[CE1-bgp-default] quit

2. Configure PE 1:

# Configure IS-IS on PE 1.

<PE1> system-view

[PE1] isis 1

[PE1-isis-1] network-entity 10.0000.0000.0000.0001.00

[PE1-isis-1] quit

# Configure LSR ID, and enable MPLS and LDP.

[PE1] mpls lsr-id 2.2.2.9

[PE1] mpls ldp

[PE1-ldp] quit

# Configure Ten-GigabitEthernet 2/0/4, and enable IS-IS, MPLS, and LDP on the interface.

[PE1] interface ten-gigabitethernet 2/0/4

[PE1-Ten-GigabitEthernet2/0/4] ip address 1.1.1.2 255.0.0.0

[PE1-Ten-GigabitEthernet2/0/4] isis enable 1

[PE1-Ten-GigabitEthernet2/0/4] mpls enable

[PE1-Ten-GigabitEthernet2/0/4] mpls ldp enable

[PE1-Ten-GigabitEthernet2/0/4] quit

# Configure Loopback 0, and enable IS-IS on it.

[PE1] interface loopback 0

[PE1-LoopBack0] ip address 2.2.2.9 32

[PE1-LoopBack0] isis enable 1

[PE1-LoopBack0] quit

# Create VPN instance vpn1, and configure the RD and route target attributes.

[PE1] ip vpn-instance vpn1

[PE1-vpn-instance-vpn1] route-distinguisher 11:11

[PE1-vpn-instance-vpn1] vpn-target 1:1 2:2 3:3 import-extcommunity

[PE1-vpn-instance-vpn1] vpn-target 3:3 export-extcommunity

[PE1-vpn-instance-vpn1] quit

# Associate interface Ten-GigabitEthernet 2/0/0 with VPN instance vpn1, and specify the IP address for the interface.

[PE1] interface ten-gigabitethernet 2/0/0

[PE1-Ten-GigabitEthernet2/0/0] ip binding vpn-instance vpn1

[PE1-Ten-GigabitEthernet2/0/0] ip address 30.0.0.1 24

[PE1-Ten-GigabitEthernet2/0/0] quit

# Enable BGP on PE 1.

[PE1] bgp 100

# Configure IBGP peer 3.3.3.9 as a BGP IPv4 labeled unicast peer.

[PE1-bgp-default] peer 3.3.3.9 as-number 100

[PE1-bgp-default] peer 3.3.3.9 connect-interface loopback 0

[PE1-bgp-default] address-family ipv4 labeled-unicast

[PE1-bgp-default-labeled-ipv4] peer 3.3.3.9 enable

[PE1-bgp-default-labeled-ipv4] quit

# Redistribute BGP routes in BGP IPv4 labeled unicast address family to the BGP routing table of BGP IPv4 unicast address family, and add the redistributed BGP routes to the public network routing table.

[PE1-bgp-default] address-family ipv4 unicast

[PE1-bgp-default-ipv4] import-rib public labeled-unicast

[PE1-bgp-default-ipv4] quit

# Configure the maximum hop count from PE 1 to EBGP peer 5.5.5.9 as 10.

[PE1-bgp-default] peer 5.5.5.9 as-number 600

[PE1-bgp-default] peer 5.5.5.9 connect-interface loopback 0

[PE1-bgp-default] peer 5.5.5.9 ebgp-max-hop 10

# Configure peer 5.5.5.9 as a VPNv4 peer.

[PE1-bgp-default] address-family vpnv4

[PE1-bgp-default-vpnv4] peer 5.5.5.9 enable

[PE1-bgp-default-vpnv4] quit

# Establish an EBGP peer relationship with CE 1, and add the learned BGP routes to the routing table of VPN instance vpn1.

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] peer 30.0.0.2 as-number 65001

[PE1-bgp-default-vpn1] address-family ipv4 unicast

[PE1-bgp-default-ipv4-vpn1] peer 30.0.0.2 enable

[PE1-bgp-default-ipv4-vpn1] quit

[PE1-bgp-default-vpn1] quit

[PE1-bgp-default] quit

3. Configure ASBR-PE 1:

# Enable IS-IS on ASBR-PE 1.

<ASBR-PE1> system-view

[ASBR-PE1] isis 1

[ASBR-PE1-isis-1] network-entity 10.0000.0000.0000.0002.00

[ASBR-PE1-isis-1] quit

# Configure the LSR ID, and enable MPLS and LDP.

[ASBR-PE1] mpls lsr-id 3.3.3.9

[ASBR-PE1] mpls ldp

[ASBR-PE1-ldp] quit

# Configure Ten-GigabitEthernet 2/0/4, and enable IS-IS, MPLS, and LDP on the interface.

[ASBR-PE1] interface ten-gigabitethernet 2/0/4

[ASBR-PE1-Ten-GigabitEthernet2/0/4] ip address 1.1.1.1 255.0.0.0

[ASBR-PE1-Ten-GigabitEthernet2/0/4] isis enable 1

[ASBR-PE1-Ten-GigabitEthernet2/0/4] mpls enable

[ASBR-PE1-Ten-GigabitEthernet2/0/4] mpls ldp enable

[ASBR-PE1-Ten-GigabitEthernet2/0/4] quit

# Configure Ten-GigabitEthernet 2/0/3, and enable MPLS on it.

[ASBR-PE1] interface ten-gigabitethernet 2/0/3

[ASBR-PE1-Ten-GigabitEthernet2/0/3] ip address 11.0.0.2 255.0.0.0

[ASBR-PE1-Ten-GigabitEthernet2/0/3] mpls enable

[ASBR-PE1-Ten-GigabitEthernet2/0/3] quit

# Configure Loopback 0, and enable IS-IS on it.

[ASBR-PE1] interface loopback 0

[ASBR-PE1-LoopBack0] ip address 3.3.3.9 32

[ASBR-PE1-LoopBack0] isis enable 1

[ASBR-PE1-LoopBack0] quit

# Enable BGP on ASBR-PE 1, and configure peers 2.2.2.9 and 11.0.0.1 as BGP IPv4 labeled unicast peers.

[ASBR-PE1] bgp 100

[ASBR-PE1-bgp-default] peer 2.2.2.9 as-number 100

[ASBR-PE1-bgp-default] peer 2.2.2.9 connect-interface loopback 0

[ASBR-PE1-bgp-default] peer 11.0.0.1 as-number 600

[ASBR-PE1-bgp-default] address-family ipv4 labeled-unicast

[ASBR-PE1-bgp-default-labeled-ipv4] peer 2.2.2.9 enable

[ASBR-PE1-bgp-default-labeled-ipv4] peer 11.0.0.1 enable

# Redistribute routes from IS-IS process 1 to BGP.

[ASBR-PE1-bgp-default-labeled-ipv4] import-route isis 1

[ASBR-PE1-bgp-default-labeled-ipv4] quit

[ASBR-PE1-bgp-default] quit

4. Configure ASBR-PE 2:

# Enable IS-IS on ASBR-PE 2.

<ASBR-PE2> system-view

[ASBR-PE2] isis 1

[ASBR-PE2-isis-1] network-entity 10.0000.0000.0000.0003.00

[ASBR-PE2-isis-1] quit

# Configure the LSR ID, and enable MPLS and LDP.

[ASBR-PE2] mpls lsr-id 4.4.4.9

[ASBR-PE2] mpls ldp

[ASBR-PE2-ldp] quit

# Configure Ten-GigabitEthernet 2/0/4, and enable IS-IS, MPLS, and LDP on the interface.

[ASBR-PE2] interface ten-gigabitethernet 2/0/4

[ASBR-PE2-Ten-GigabitEthernet2/0/4] ip address 9.1.1.1 255.0.0.0

[ASBR-PE2-Ten-GigabitEthernet2/0/4] isis enable 1

[ASBR-PE2-Ten-GigabitEthernet2/0/4] mpls enable

[ASBR-PE2-Ten-GigabitEthernet2/0/4] mpls ldp enable

[ASBR-PE2-Ten-GigabitEthernet2/0/4] quit

# Configure Loopback 0, and enable IS-IS on it.

[ASBR-PE2] interface loopback 0

[ASBR-PE2-LoopBack0] ip address 4.4.4.9 32

[ASBR-PE2-LoopBack0] isis enable 1

[ASBR-PE2-LoopBack0] quit

# Configure Ten-GigabitEthernet 2/0/3, and enable MPLS on the interface.

[ASBR-PE2] interface ten-gigabitethernet 2/0/3

[ASBR-PE2-Ten-GigabitEthernet2/0/3] ip address 11.0.0.1 255.0.0.0

[ASBR-PE2-Ten-GigabitEthernet2/0/3] mpls enable

[ASBR-PE2-Ten-GigabitEthernet2/0/3] quit

# Enable BGP on ASBR-PE 2, and configure peers 5.5.5.9 and 11.0.0.2 as BGP IPv4 labeled unicast peers.

[ASBR-PE2] bgp 600

[ASBR-PE2-bgp-default] peer 5.5.5.9 as-number 600

[ASBR-PE2-bgp-default] peer 5.5.5.9 connect-interface loopback 0

[ASBR-PE2-bgp-default] peer 11.0.0.2 as-number 100

[ASBR-PE2-bgp-default] address-family ipv4 labeled-unicast

[ASBR-PE2-bgp-default-labeled-ipv4] peer 5.5.5.9 enable

[ASBR-PE2-bgp-default-labeled-ipv4] peer 11.0.0.2 enable

# Redistribute routes from IS-IS process 1.

[ASBR-PE2-bgp-default-labeled-ipv4] import-route isis 1

[ASBR-PE2-bgp-default-labeled-ipv4] quit

[ASBR-PE2-bgp-default] quit

5. Configure PE 2:

# Enable IS-IS on PE 2.

<PE2> system-view

[PE2] isis 1

[PE2-isis-1] network-entity 10.0000.0000.0000.0004.00

[PE2-isis-1] quit

# Configure the LSR ID, and enable MPLS and LDP.

[PE2] mpls lsr-id 5.5.5.9

[PE2] mpls ldp

[PE2-ldp] quit

# Configure Ten-GigabitEthernet 2/0/4, and enable IS-IS, MPLS, and LDP on the interface.

[PE2] interface ten-gigabitethernet 2/0/4

[PE2-Ten-GigabitEthernet2/0/4] ip address 9.1.1.2 255.0.0.0

[PE2-Ten-GigabitEthernet2/0/4] isis enable 1

[PE2-Ten-GigabitEthernet2/0/4] mpls enable

[PE2-Ten-GigabitEthernet2/0/4] mpls ldp enable

[PE2-Ten-GigabitEthernet2/0/4] quit

# Configure Loopback 0, and enable IS-IS on it.

[PE2] interface loopback 0

[PE2-LoopBack0] ip address 5.5.5.9 32

[PE2-LoopBack0] isis enable 1

[PE2-LoopBack0] quit

# Create VPN instance vpn1, and configure the RD and route target attributes.

[PE2] ip vpn-instance vpn1

[PE2-vpn-instance-vpn1] route-distinguisher 11:11

[PE2-vpn-instance-vpn1] vpn-target 1:1 2:2 3:3 import-extcommunity

[PE2-vpn-instance-vpn1] vpn-target 3:3 export-extcommunity

[PE2-vpn-instance-vpn1] quit

# Associate Ten-GigabitEthernet 2/0/0 with VPN instance vpn1, and specify the IP address for the interface.

[PE2] interface ten-gigabitethernet 2/0/0

[PE2-Ten-GigabitEthernet2/0/0] ip binding vpn-instance vpn1

[PE2-Ten-GigabitEthernet2/0/0] ip address 20.0.0.1 24

[PE2-Ten-GigabitEthernet2/0/0] quit

# Enable BGP on PE 2.

[PE2] bgp 600

# Configure IBGP peer 4.4.4.9 as BGP IPv4 labeled unicast peer.

[PE2-bgp-default] peer 4.4.4.9 as-number 600

[PE2-bgp-default] peer 4.4.4.9 connect-interface loopback 0

[PE2-bgp-default] address-family ipv4 labeled-unicast

[PE2-bgp-default-labeled-ipv4] peer 4.4.4.9 enable

[PE2-bgp-default-labeled-ipv4] quit

[PE2-bgp-default] address-family ipv4 unicast

[PE2-bgp-default-ipv4] import-rib public labeled-unicast

[PE2-bgp-default-ipv4] quit

# Configure the maximum hop count from PE 2 to EBGP peer 2.2.2.9 as 10.

[PE2-bgp-default] peer 2.2.2.9 as-number 100

[PE2-bgp-default] peer 2.2.2.9 connect-interface loopback 0

[PE2-bgp-default] peer 2.2.2.9 ebgp-max-hop 10

# Configure peer 2.2.2.9 as a VPNv4 peer.

[PE2-bgp-default] address-family vpnv4

[PE2-bgp-default-vpnv4] peer 2.2.2.9 enable

[PE2-bgp-default-vpnv4] quit

# Establish an EBGP peer relationship with CE 2, and add the learned BGP routes to the routing table of VPN instance vpn1.

[PE2-bgp-default] ip vpn-instance vpn1

[PE2-bgp-default-vpn1] peer 20.0.0.2 as-number 65002

[PE2-bgp-default-vpn1] address-family ipv4 unicast

[PE2-bgp-default-ipv4-vpn1] peer 20.0.0.2 enable

[PE2-bgp-default-ipv4-vpn1] quit

[PE2-bgp-default-vpn1] quit

[PE2-bgp-default] quit

6. Configure CE 2:

# Configure an IP address for Ten-GigabitEthernet 2/0/0.

<CE2> system-view

[CE2] interface ten-gigabitethernet 2/0/0

[CE2-Ten-GigabitEthernet2/0/0] ip address 20.0.0.2 24

[CE2-Ten-GigabitEthernet2/0/0] quit

# Establish an EBGP peer relationship with PE 2, and redistribute VPN routes.

[CE2] bgp 65002

[CE2-bgp-default] peer 20.0.0.1 as-number 600

[CE2-bgp-default] address-family ipv4 unicast

[CE2-bgp-default-ipv4] peer 20.0.0.1 enable

[CE2-bgp-default-ipv4] import-route direct

[CE2-bgp-default-ipv4] quit

[CE2-bgp-default] quit

Verifying the configuration

# Execute the display ip routing table command on CE 1 and CE 2 to verify that CE 1 and CE 2 have a route to each other. Verify that CE 1 and CE 2 can ping each other. (Details not shown.)

Example: Configuring MPLS L3VPN inter-AS option C (method 2) (exchanging labeled routes in BGP IPv4 labeled unicast address family)

Network configuration

Site 1 and Site 2 belong to the same VPN. Site 1 accesses the network through PE 1 in AS 100, and Site 2 accesses the network through PE 2 in AS 600. PEs in the same AS run IS-IS.

PE 1 and PE 2 are MP-EBGP peers and exchange VPNv4 routes.

ASBR-PE 1 and ASBR-PE 2 exchange labeled IPv4 routes through a session in the BGP IPv4 labeled unicast address family, and redistribute IGP and BGP routes from each other.

Figure 19 Network diagram

‌

Table 3 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
PE 1	Loop0	2.2.2.9/32	PE 2	Loop0	5.5.5.9/32
	XGE2/0/0	30.0.0.1/24		XGE2/0/0	20.0.0.1/24
	XGE2/0/4	1.1.1.2/8		XGE2/0/4	9.1.1.2/8
ASBR-PE 1	Loop0	3.3.3.9/32	ASBR-PE 2	Loop0	4.4.4.9/32
	XGE2/0/4	1.1.1.1/8		XGE2/0/4	9.1.1.1/8
	XGE2/0/3	11.0.0.2/8		XGE2/0/3	11.0.0.1/8
CE 1	XGE2/0/0	30.0.0.2/24	CE 2	XGE2/0/0	20.0.0.2/24

‌

Procedure

1. Configure CE 1:

# Configure an IP address for Ten-GigabitEthernet 2/0/0.

<CE1> system-view

[CE1] interface ten-gigabitethernet 2/0/0

[CE1-Ten-GigabitEthernet2/0/0] ip address 30.0.0.2 24

[CE1-Ten-GigabitEthernet2/0/0] quit

# Establish an EBGP peer relationship with PE 1, and redistribute VPN routes.

[CE1] bgp 65001

[CE1-bgp-default] peer 30.0.0.1 as-number 100

[CE1-bgp-default] address-family ipv4 unicast

[CE1-bgp-default-ipv4] peer 30.0.0.1 enable

[CE1-bgp-default-ipv4] import-route direct

[CE1-bgp-default-ipv4] quit

[CE1-bgp-default] quit

2. Configure PE 1:

# Configure IS-IS on PE 1.

<PE1> system-view

[PE1] isis 1

[PE1-isis-1] network-entity 10.0000.0000.0000.0001.00

[PE1-isis-1] quit

# Configure an LSR ID, and enable MPLS and LDP.

[PE1] mpls lsr-id 2.2.2.9

[PE1] mpls ldp

[PE1-ldp] quit

# Enable IS-IS, MPLS, and LDP on interface Ten-GigabitEthernet 2/0/4.

[PE1] interface ten-gigabitethernet 2/0/4

[PE1-Ten-GigabitEthernet2/0/4] ip address 1.1.1.2 255.0.0.0

[PE1-Ten-GigabitEthernet2/0/4] isis enable 1

[PE1-Ten-GigabitEthernet2/0/4] mpls enable

[PE1-Ten-GigabitEthernet2/0/4] mpls ldp enable

[PE1-Ten-GigabitEthernet2/0/4] quit

# Enable IS-IS on interface Loopback 0.

[PE1] interface loopback 0

[PE1-LoopBack0] ip address 2.2.2.9 32

[PE1-LoopBack0] isis enable 1

[PE1-LoopBack0] quit

# Create VPN instance vpn1, and configure the RD and route target attributes.

[PE1] ip vpn-instance vpn1

[PE1-vpn-instance-vpn1] route-distinguisher 11:11

[PE1-vpn-instance-vpn1] vpn-target 1:1 2:2 3:3 import-extcommunity

[PE1-vpn-instance-vpn1] vpn-target 3:3 export-extcommunity

[PE1-vpn-instance-vpn1] quit

# Associate interface Ten-GigabitEthernet 2/0/0 with VPN instance vpn1, and specify an IP address for the interface.

[PE1] interface ten-gigabitethernet 2/0/0

[PE1-Ten-GigabitEthernet2/0/0] ip binding vpn-instance vpn1

[PE1-Ten-GigabitEthernet2/0/0] ip address 30.0.0.1 24

[PE1-Ten-GigabitEthernet2/0/0] quit

# Enable BGP on PE 1.

[PE1] bgp 100

# Configure the maximum hop count from PE 1 to EBGP peer 5.5.5.9 as 10.

[PE1-bgp-default] peer 5.5.5.9 as-number 600

[PE1-bgp-default] peer 5.5.5.9 connect-interface loopback 0

[PE1-bgp-default] peer 5.5.5.9 ebgp-max-hop 10

# Configure peer 5.5.5.9 as a VPNv4 peer.

[PE1-bgp-default] address-family vpnv4

[PE1-bgp-default-vpnv4] peer 5.5.5.9 enable

[PE1-bgp-default-vpnv4] quit

# Establish an EBGP peer relationship with CE 1, and add the learned BGP routes to the routing table of VPN instance vpn1.

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] peer 30.0.0.2 as-number 65001

[PE1-bgp-default-vpn1] address-family ipv4 unicast

[PE1-bgp-default-ipv4-vpn1] peer 30.0.0.2 enable

[PE1-bgp-default-ipv4-vpn1] quit

[PE1-bgp-default-vpn1] quit

[PE1-bgp-default] quit

3. Configure ASBR-PE1:

# Enable IS-IS on ASBR-PE 1.

<ASBR-PE1> system-view

[ASBR-PE1] isis 1

[ASBR-PE1-isis-1] network-entity 10.0000.0000.0000.0002.00

# Redistribute BGP routes.

[ASBR-PE1-isis-1] address-family ipv4 unicast

[ASBR-PE1-isis-1-ipv4] import-route bgp

[ASBR-PE1-isis-1-ipv4] quit

[ASBR-PE1-isis-1] quit

# Configure an LSR ID, and enable MPLS and LDP.

[ASBR-PE1] mpls lsr-id 3.3.3.9

[ASBR-PE1] mpls ldp

[ASBR-PE1-ldp] quit

# Configure interface Ten-GigabitEthernet 2/0/4, and enable IS-IS, MPLS, and LDP on the interface.

[ASBR-PE1] interface ten-gigabitethernet 2/0/4

[ASBR-PE1-Ten-GigabitEthernet2/0/4] ip address 1.1.1.1 255.0.0.0

[ASBR-PE1-Ten-GigabitEthernet2/0/4] isis enable 1

[ASBR-PE1-Ten-GigabitEthernet2/0/4] mpls enable

[ASBR-PE1-Ten-GigabitEthernet2/0/4] mpls ldp enable

[ASBR-PE1-Ten-GigabitEthernet2/0/4] quit

# Configure Ten-GigabitEthernet 2/0/3, and enable MPLS on it.

[ASBR-PE1] interface ten-gigabitethernet 2/0/3

[ASBR-PE1-Ten-GigabitEthernet2/0/3] ip address 11.0.0.2 255.0.0.0

[ASBR-PE1-Ten-GigabitEthernet2/0/3] mpls enable

[ASBR-PE1-Ten-GigabitEthernet2/0/3] quit

# Configure interface Loopback 0, and enable IS-IS on it.

[ASBR-PE1] interface loopback 0

[ASBR-PE1-LoopBack0] ip address 3.3.3.9 32

[ASBR-PE1-LoopBack0] isis enable 1

[ASBR-PE1-LoopBack0] quit

# Enable BGP on ASBR-PE 1, and configure EBGP peer 11.0.0.1 as a BGP IPv4 labeled unicast peer.

[ASBR-PE1] bgp 100

[ASBR-PE1-bgp-default] peer 11.0.0.1 as-number 600

[ASBR-PE1-bgp-default] address-family ipv4 labeled-unicast

[ASBR-PE1-bgp-default-labeled-ipv4] peer 11.0.0.1 enable

# Redistribute routes from IS-IS process 1 to BGP.

[ASBR-PE1-bgp-default-labeled-ipv4] import-route isis 1

[ASBR-PE1-bgp-default-labeled-ipv4] quit

# Redistributes BGP IPv4 labeled unicast routes in the public network instance to the BGP routing table of the BGP IPv4 unicast address family.

[ASBR-PE1-bgp-default] address-family ipv4 unicast

[ASBR-PE1-bgp-default-ipv4] import-rib public labeled-unicast

[ASBR-PE1-bgp-default-ipv4] quit

[ASBR-PE1-bgp-default] quit

4. Configure ASBR-PE 2:

# Enable IS-IS on ASBR-PE 2.

<ASBR-PE2> system-view

[ASBR-PE2] isis 1

[ASBR-PE2-isis-1] network-entity 10.0000.0000.0000.0003.00

# Redistribute BGP routes.

[ASBR-PE2-isis-1] address-family ipv4 unicast

[ASBR-PE2-isis-1-ipv4] import-route bgp

[ASBR-PE2-isis-1-ipv4] quit

[ASBR-PE2-isis-1] quit

# Configure an LSR ID, and enable MPLS and LDP.

[ASBR-PE2] mpls lsr-id 4.4.4.9

[ASBR-PE2] mpls ldp

[ASBR-PE2-ldp] quit

# Configure Ten-GigabitEthernet 2/0/4, and enable IS-IS, MPLS, and LDP on the interface.

[ASBR-PE2] interface ten-gigabitethernet 2/0/4

[ASBR-PE2-Ten-GigabitEthernet2/0/4] ip address 9.1.1.1 255.0.0.0

[ASBR-PE2-Ten-GigabitEthernet2/0/4] isis enable 1

[ASBR-PE2-Ten-GigabitEthernet2/0/4] mpls enable

[ASBR-PE2-Ten-GigabitEthernet2/0/4] mpls ldp enable

[ASBR-PE2-Ten-GigabitEthernet2/0/4] quit

# Configure Loopback 0, and enable IS-IS on it.

[ASBR-PE2] interface loopback 0

[ASBR-PE2-LoopBack0] ip address 4.4.4.9 32

[ASBR-PE2-LoopBack0] isis enable 1

[ASBR-PE2-LoopBack0] quit

# Configure Ten-GigabitEthernet 2/0/3, and enable MPLS on the interface.

[ASBR-PE2] interface ten-gigabitethernet 2/0/3

[ASBR-PE2-Ten-GigabitEthernet2/0/3] ip address 11.0.0.1 255.0.0.0

[ASBR-PE2-Ten-GigabitEthernet2/0/3] mpls enable

[ASBR-PE2-Ten-GigabitEthernet2/0/3] quit

# Enable BGP on ASBR-PE 2, and configure EBGP peer 11.0.0.2 as a BGP IPv4 labeled unicast peer.

[ASBR-PE2] bgp 600

[ASBR-PE2-bgp-default] peer 11.0.0.2 as-number 100

[ASBR-PE2-bgp-default] address-family ipv4 labeled-unicast

[ASBR-PE2-bgp-default-labeled-ipv4] peer 11.0.0.2 enable

# Redistribute routes from IS-IS process 1 to BGP.

[ASBR-PE2-bgp-default-labeled-ipv4] import-route isis 1

[ASBR-PE2-bgp-default-labeled-ipv4] quit

# Redistributes BGP IPv4 labeled unicast routes in the public network instance to the BGP routing table of the BGP IPv4 unicast address family.

[ASBR-PE2-bgp-default] address-family ipv4 unicast

[ASBR-PE2-bgp-default-ipv4] import-rib public labeled-unicast

[ASBR-PE2-bgp-default-ipv4] quit

[ASBR-PE2-bgp-default] quit

5. Configure PE 2:

# Enable IS-IS on PE 2.

<PE2> system-view

[PE2] isis 1

[PE2-isis-1] network-entity 10.0000.0000.0000.0004.00

[PE2-isis-1] quit

# Configure an LSR ID, and enable MPLS and LDP.

[PE2] mpls lsr-id 5.5.5.9

[PE2] mpls ldp

[PE2-ldp] quit

# Configure interface Ten-GigabitEthernet 2/0/4, and enable IS-IS, MPLS, and LDP on the interface.

[PE2] interface ten-gigabitethernet 2/0/4

[PE2-Ten-GigabitEthernet2/0/4] ip address 9.1.1.2 255.0.0.0

[PE2-Ten-GigabitEthernet2/0/4] isis enable 1

[PE2-Ten-GigabitEthernet2/0/4] mpls enable

[PE2-Ten-GigabitEthernet2/0/4] mpls ldp enable

[PE2-Ten-GigabitEthernet2/0/4] quit

# Configure interface Loopback 0, and enable IS-IS on it.

[PE2] interface loopback 0

[PE2-LoopBack0] ip address 5.5.5.9 32

[PE2-LoopBack0] isis enable 1

[PE2-LoopBack0] quit

# Create VPN instance vpn1, and configure the RD and route target attributes.

[PE2] ip vpn-instance vpn1

[PE2-vpn-instance-vpn1] route-distinguisher 11:11

[PE2-vpn-instance-vpn1] vpn-target 1:1 2:2 3:3 import-extcommunity

[PE2-vpn-instance-vpn1] vpn-target 3:3 export-extcommunity

[PE2-vpn-instance-vpn1] quit

# Associate interface Ten-GigabitEthernet 2/0/0 with VPN instance vpn1, and specify an IP address for the interface.

[PE2] interface ten-gigabitethernet 2/0/0

[PE2-Ten-GigabitEthernet2/0/0] ip binding vpn-instance vpn1

[PE2-Ten-GigabitEthernet2/0/0] ip address 20.0.0.1 24

[PE2-Ten-GigabitEthernet2/0/0] quit

# Enable BGP on PE 2.

[PE2] bgp 600

# Configure the maximum hop count from PE 2 to EBGP peer 2.2.2.9 as 10.

[PE2-bgp-default] peer 2.2.2.9 as-number 100

[PE2-bgp-default] peer 2.2.2.9 connect-interface loopback 0

[PE2-bgp-default] peer 2.2.2.9 ebgp-max-hop 10

# Configure peer 2.2.2.9 as a VPNv4 peer.

[PE2-bgp-default] address-family vpnv4

[PE2-bgp-default-vpnv4] peer 2.2.2.9 enable

[PE2-bgp-default-vpnv4] quit

# Establish an EBGP peer relationship with CE 2, and add the learned BGP routes to the routing table of VPN instance vpn1.

[PE2-bgp-default] ip vpn-instance vpn1

[PE2-bgp-default-vpn1] peer 20.0.0.2 as-number 65002

[PE2-bgp-default-vpn1] address-family ipv4 unicast

[PE2-bgp-default-ipv4-vpn1] peer 20.0.0.2 enable

[PE2-bgp-default-ipv4-vpn1] quit

[PE2-bgp-default-vpn1] quit

[PE2-bgp-default] quit

6. Configure CE 2:

# Configure an IP address for interface Ten-GigabitEthernet 2/0/0.

<CE2> system-view

[CE2] interface ten-gigabitethernet 2/0/0

[CE2-Ten-GigabitEthernet2/0/0] ip address 20.0.0.2 24

[CE2-Ten-GigabitEthernet2/0/0] quit

# Establish an EBGP peer relationship with PE 2, and redistribute VPN routes.

[CE2] bgp 65002

[CE2-bgp-default] peer 20.0.0.1 as-number 600

[CE2-bgp-default] address-family ipv4 unicast

[CE2-bgp-default-ipv4] peer 20.0.0.1 enable

[CE2-bgp-default-ipv4] import-route direct

[CE2-bgp-default-ipv4] quit

[CE2-bgp-default] quit

Verifying the configuration

# Execute the display ip routing-table command on CE 1 and CE 2 to verify that CE 1 and CE 2 have a route to each other. Verify that CE 1 and CE 2 can ping each other. (Details not shown.)

Example: Configuring MPLS L3VPN carrier's carrier in different ASs (exchanging labeled routes in BGP IPv4 labeled unicast address family)

Network configuration

Configure carrier's carrier for the scenario shown in Figure 20. In this scenario:

· PE 1 and PE 2 are the provider carrier's PE routers. They provide VPN services for the customer carrier.

· CE 1 and CE 2 are the customer carrier's routers. They are connected to the provider carrier's backbone as CE routers.

· PE 3 and PE 4 are the customer carrier's PE routers. They provide MPLS L3VPN services for the end customers.

· CE 3 and CE 4 are customers of the customer carrier.

· The customer carrier and the provider carrier reside in different ASs.

The key to carrier's carrier deployment is to configure exchange of two kinds of routes:

· Exchange of the customer carrier's internal routes on the provider carrier's backbone.

· Exchange of the end customers' VPN routes between PE 3 and PE 4, the PEs of the customer carrier. In this process, an MP-EBGP peer relationship must be established between PE 3 and PE 4.

Figure 20 Network diagram

‌

Table 4 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
CE 3	XGE2/0/0	100.1.1.1/24	CE 4	XGE2/0/0	120.1.1.1/24
PE 3	Loop0	1.1.1.9/32	PE 4	Loop0	6.6.6.9/32
	XGE2/0/0	100.1.1.2/24		XGE2/0/0	120.1.1.2/24
	XGE2/0/4	10.1.1.1/24		XGE2/0/4	20.1.1.2/24
CE 1	Loop0	2.2.2.9/32	CE 2	Loop0	5.5.5.9/32
	XGE2/0/3	10.1.1.2/24		XGE2/0/3	21.1.1.2/24
	XGE2/0/4	11.1.1.1/24		XGE2/0/4	20.1.1.1/24
PE 1	Loop0	3.3.3.9/32	PE 2	Loop0	4.4.4.9/32
	XGE2/0/3	11.1.1.2/24		XGE2/0/3	30.1.1.2/24
	XGE2/0/4	30.1.1.1/24		XGE2/0/4	21.1.1.1/24

‌

Procedure

1. Configure MPLS L3VPN on the provider carrier backbone. Enable IS-IS as the IGP, enable LDP between PE 1 and PE 2, and establish an MP-IBGP peer relationship between the PEs:

# Configure PE 1.

<PE1> system-view

[PE1] interface loopback 0

[PE1-LoopBack0] ip address 3.3.3.9 32

[PE1-LoopBack0] quit

[PE1] mpls lsr-id 3.3.3.9

[PE1] mpls ldp

[PE1-ldp] quit

[PE1] isis 1

[PE1-isis-1] network-entity 10.0000.0000.0000.0004.00

[PE1-isis-1] quit

[PE1] interface loopback 0

[PE1-LoopBack0] isis enable 1

[PE1-LoopBack0] quit

[PE1] interface ten-gigabitethernet 2/0/4

[PE1-Ten-GigabitEthernet2/0/4] ip address 30.1.1.1 24

[PE1-Ten-GigabitEthernet2/0/4] isis enable 1

[PE1-Ten-GigabitEthernet2/0/4] mpls enable

[PE1-Ten-GigabitEthernet2/0/4] mpls ldp enable

[PE1-Ten-GigabitEthernet2/0/4] mpls ldp transport-address interface

[PE1-Ten-GigabitEthernet2/0/4] quit

[PE1] bgp 200

[PE1-bgp-default] peer 4.4.4.9 as-number 200

[PE1-bgp-default] peer 4.4.4.9 connect-interface loopback 0

[PE1-bgp-default] address-family vpnv4

[PE1-bgp-default-vpnv4] peer 4.4.4.9 enable

[PE1-bgp-default-vpnv4] quit

[PE1-bgp-default] quit

# Configure PE 2 in the same way that PE 1 is configured. (Details not shown.)

# On PE 1 or PE 2, execute the following commands:

¡ Execute the display mpls ldp peer command to verify that an LDP session in Operational state has been established between PE 1 and PE 2. (Details not shown.)

¡ Execute the display bgp peer vpnv4 command to verify that a BGP peer relationship in Established state has been established between PE 1 and PE 2. (Details not shown.)

¡ Execute the display isis peer command to verify that the IS-IS neighbor relationship has been established between PE 1 and PE 2. (Details not shown.)

2. Configure the customer carrier network. Enable IS-IS as the IGP, and enable LDP between PE 3 and CE 1, and between PE 4 and CE 2:

# Configure PE 3.

<PE3> system-view

[PE3] interface loopback 0

[PE3-LoopBack0] ip address 1.1.1.9 32

[PE3-LoopBack0] quit

[PE3] mpls lsr-id 1.1.1.9

[PE3] mpls ldp

[PE3-ldp] quit

[PE3] isis 2

[PE3-isis-2] network-entity 10.0000.0000.0000.0001.00

[PE3-isis-2] quit

[PE3] interface loopback 0

[PE3-LoopBack0] isis enable 2

[PE3-LoopBack0] quit

[PE3] interface ten-gigabitethernet 2/0/4

[PE3-Ten-GigabitEthernet2/0/4] ip address 10.1.1.1 24

[PE3-Ten-GigabitEthernet2/0/4] isis enable 2

[PE3-Ten-GigabitEthernet2/0/4] mpls enable

[PE3-Ten-GigabitEthernet2/0/4] mpls ldp enable

[PE3-Ten-GigabitEthernet2/0/4] mpls ldp transport-address interface

[PE3-Ten-GigabitEthernet2/0/4] quit

# Configure CE 1.

<CE1> system-view

[CE1] interface loopback 0

[CE1-LoopBack0] ip address 2.2.2.9 32

[CE1-LoopBack0] quit

[CE1] mpls lsr-id 2.2.2.9

[CE1] mpls ldp

[CE1-ldp] import bgp

[CE1-ldp] quit

[CE1] isis 2

[CE1-isis-2] network-entity 10.0000.0000.0000.0002.00

[CE1-isis-2] address-family ipv4

[CE1-isis-2-ipv4] import-route bgp

[CE1-isis-2-ipv4] quit

[CE1-isis-2] quit

[CE1] interface loopback 0

[CE1-LoopBack0] isis enable 2

[CE1-LoopBack0] quit

[CE1] interface ten-gigabitethernet 2/0/3

[CE1-Ten-GigabitEthernet2/0/3] ip address 10.1.1.2 24

[CE1-Ten-GigabitEthernet2/0/3] isis enable 2

[CE1-Ten-GigabitEthernet2/0/3] mpls enable

[CE1-Ten-GigabitEthernet2/0/3] mpls ldp enable

[CE1-Ten-GigabitEthernet2/0/3] mpls ldp transport-address interface

[CE1-Ten-GigabitEthernet2/0/3] quit

PE 3 and CE 1 can establish an LDP session and IS-IS neighbor relationship.

# Configure PE 4 and CE 2 in the same way that PE 3 and CE 1 are configured. (Details not shown.)

3. Allow CEs of the customer carrier to access PEs of the provider carrier:

# Configure PE 1.

[PE1] ip vpn-instance vpn1

[PE1-vpn-instance-vpn1] route-distinguisher 200:1

[PE1-vpn-instance-vpn1] vpn-target 1:1

[PE1-vpn-instance-vpn1] quit

[PE1] interface ten-gigabitethernet 2/0/3

[PE1-Ten-GigabitEthernet2/0/3] ip binding vpn-instance vpn1

[PE1-Ten-GigabitEthernet2/0/3] ip address 11.1.1.2 24

[PE1-Ten-GigabitEthernet2/0/3] mpls enable

[PE1-Ten-GigabitEthernet2/0/3] quit

[PE1] bgp 200

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] peer 11.1.1.1 as-number 100

[PE1-bgp-default-vpn1] address-family ipv4 labeled-unicast

[PE1-bgp-default-labeled-ipv4-vpn1] peer 11.1.1.1 enable

[PE1-bgp-default-labeled-ipv4-vpn1] quit

[PE1-bgp-default-vpn1] address-family ipv4 unicast

[PE1-bgp-default-ipv4-vpn1] import-rib vpn-instance vpn1 labeled-unicast

[PE1-bgp-default-ipv4-vpn1] quit

[PE1-bgp-default-vpn1] address-family ipv4 labeled-unicast

[PE1-bgp-default-labeled-ipv4-vpn1] import-rib vpn-instance vpn1

[PE1-bgp-default-labeled-ipv4-vpn1] quit

[PE1-bgp-default-vpn1] quit

[PE1-bgp-default] quit

# Configure CE 1.

[CE1] interface ten-gigabitethernet 2/0/4

[CE1-Ten-GigabitEthernet2/0/4] ip address 11.1.1.1 24

[CE1-Ten-GigabitEthernet2/0/4] mpls enable

[CE1-Ten-GigabitEthernet2/0/4] quit

[CE1] bgp 100

[CE1-bgp-default] peer 11.1.1.2 as-number 200

[CE1-bgp-default] address-family ipv4 labeled-unicast

[CE1-bgp-default-labeled-ipv4] peer 11.1.1.2 enable

[CE1-bgp-default-labeled-ipv4] import-route isis 2

[CE1-bgp-default-labeled-ipv4] quit

[CE1-bgp-default] address-family ipv4 unicast

[CE1-bgp-default-ipv4] import-rib public labeled-unicast

[CE1-bgp-default-ipv4] quit

[CE1-bgp-default] quit

PE 1 and CE 1 can establish a BGP session and exchange IPv4 labeled unicast routes through BGP.

# Configure PE 2 and CE 2 in the same way that PE 1 and CE 1 are configured. (Details not shown.)

4. Connect CEs of the end customers and the PEs of the customer carrier:

# Configure CE 3.

<CE3> system-view

[CE3] interface ten-gigabitethernet 2/0/0

[CE3-Ten-GigabitEthernet2/0/0] ip address 100.1.1.1 24

[CE3-Ten-GigabitEthernet2/0/0] quit

[CE3] bgp 65410

[CE3-bgp-default] peer 100.1.1.2 as-number 100

[CE3-bgp-default] address-family ipv4 unicast

[CE3-bgp-default-ipv4] peer 100.1.1.2 enable

[CE3-bgp-default-ipv4] import-route direct

[CE3-bgp-default-ipv4] quit

[CE3-bgp-default] quit

# Configure PE 3.

[PE3] ip vpn-instance vpn1

[PE3-vpn-instance-vpn1] route-distinguisher 100:1

[PE3-vpn-instance-vpn1] vpn-target 1:1

[PE3-vpn-instance-vpn1] quit

[PE3] interface ten-gigabitethernet 2/0/0

[PE3-Ten-GigabitEthernet2/0/0] ip binding vpn-instance vpn1

[PE3-Ten-GigabitEthernet2/0/0] ip address 100.1.1.2 24

[PE3-Ten-GigabitEthernet2/0/0] quit

[PE3] bgp 100

[PE3-bgp-default] ip vpn-instance vpn1

[PE3-bgp-default-vpn1] peer 100.1.1.1 as-number 65410

[PE3-bgp-default-vpn1] address-family ipv4 unicast

[PE3-bgp-default-ipv4-vpn1] peer 100.1.1.1 enable

[PE3-bgp-default-ipv4-vpn1] quit

[PE3-bgp-default-vpn1] quit

[PE3-bgp-default] quit

# Configure PE 4 and CE 4 in the same way that PE 3 and CE 3 are configured. (Details not shown.)

5. Configure an MP-EBGP peer relationship between the PEs of the customer carrier to exchange the VPN routes of the end customers:

# Configure PE 3.

[PE3] bgp 100

[PE3-bgp-default] peer 6.6.6.9 as-number 300

[PE3-bgp-default] peer 6.6.6.9 connect-interface loopback 0

[PE3-bgp-default] peer 6.6.6.9 ebgp-max-hop 10

[PE3-bgp-default] address-family vpnv4

[PE3-bgp-default-vpnv4] peer 6.6.6.9 enable

[PE3-bgp-default-vpnv4] quit

[PE3-bgp-default] quit

# Configure PE 4 in the same way that PE 3 is configured. (Details not shown.)

Verifying the configuration

1. Display the public network routing table and VPN routing table on the provider carrier PEs, for example, on PE 1:

# Verify that the public network routing table contains only routes of the provider carrier network.

[PE1] display ip routing-table

Destinations : 12 Routes : 12

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

3.3.3.9/32 Direct 0 0 127.0.0.1 InLoop0

4.4.4.9/32 IS_L1 15 10 30.1.1.2 XGE2/0/4

30.1.1.0/24 Direct 0 0 30.1.1.1 XGE2/0/4

30.1.1.0/32 Direct 0 0 30.1.1.1 XGE2/0/4

30.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

30.1.1.255/32 Direct 0 0 30.1.1.1 XGE2/0/4

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

# Verify that the VPN routing table contains the internal routes of the customer carrier, but it does not contain the VPN routes that the customer carrier maintains.

[PE1] display ip routing-table vpn-instance vpn1

Destinations : 12 Routes : 12

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

1.1.1.9/32 BGP 255 10 11.1.1.1 XGE2/0/3

6.6.6.9/32 BGP 255 10 4.4.4.9 XGE2/0/4

11.1.1.0/24 Direct 0 0 11.1.1.2 XGE2/0/3

11.1.1.0/32 Direct 0 0 11.1.1.2 XGE2/0/3

11.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

11.1.1.255/32 Direct 0 0 11.1.1.2 XGE2/0/3

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

2. Display the routing table on the customer carrier CEs, for example, on CE 1.

# Verify that the routing table contains the internal routes of the customer carrier network, but it does not contain the VPN routes that the customer carrier maintains.

[CE1] display ip routing-table

Destinations : 17 Routes : 17

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

1.1.1.9/32 IS_L1 15 10 10.1.1.1 XGE2/0/3

2.2.2.9/32 Direct 0 0 127.0.0.1 InLoop0

6.6.6.9/32 BGP 255 0 11.1.1.2 XGE2/0/4

10.1.1.0/24 Direct 0 0 10.1.1.2 XGE2/0/3

10.1.1.0/32 Direct 0 0 10.1.1.2 XGE2/0/3

10.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

10.1.1.255/32 Direct 0 0 10.1.1.2 XGE2/0/3

11.1.1.0/24 Direct 0 0 11.1.1.1 XGE2/0/4

11.1.1.0/32 Direct 0 0 11.1.1.1 XGE2/0/4

11.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

11.1.1.255/32 Direct 0 0 11.1.1.1 XGE2/0/4

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

3. Display the public network routing table and VPN routing table on the customer carrier PEs, for example, on PE 3:

# Verify that the public network routing table contains the internal routes of the customer carrier network.

[PE3] display ip routing-table

Destinations : 13 Routes : 13

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

1.1.1.9/32 Direct 0 0 127.0.0.1 InLoop0

2.2.2.9/32 IS_L1 15 10 10.1.1.2 XGE2/0/4

6.6.6.9/32 IS_L2 15 74 10.1.1.2 XGE2/0/4

10.1.1.0/24 Direct 0 0 10.1.1.1 XGE2/0/4

10.1.1.0/32 Direct 0 0 10.1.1.1 XGE2/0/4

10.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

10.1.1.255/32 Direct 0 0 10.1.1.1 XGE2/0/4

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

# Verify that the VPN routing table contains the route to the remote VPN customer.

[PE3] display ip routing-table vpn-instance vpn1

Destinations : 11 Routes : 11

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

100.1.1.0/24 Direct 0 0 100.1.1.2 XGE2/0/0

100.1.1.0/32 Direct 0 0 100.1.1.2 XGE2/0/0

100.1.1.2/32 Direct 0 0 127.0.0.1 InLoop0

100.1.1.255/32 Direct 0 0 100.1.1.2 XGE2/0/0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

120.1.1.0/24 BGP 255 0 6.6.6.9 XGE2/0/4

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

4. Verify that PE 3 and PE 4 can ping each other. (Details not shown.)

5. Verify that CE 3 and CE 4 can ping each other. (Details not shown.)

Example: Configuring HoVPN

Network configuration

As shown in Figure 21, there are two levels of networks: the backbone and the MPLS VPN networks.

· SPEs act as PEs to allow MPLS VPNs to access the backbone.

· UPEs act as PEs of the MPLS VPNs to allow end users to access the VPNs.

· Performance requirements for the UPEs are lower than those for the SPEs.

· SPEs advertise routes permitted by routing policies to UPEs, permitting CE 1 and CE 3 in VPN 1 to communicate with each other and forbidding CE 2 and CE 4 in VPN 2 from communicating with each other.

Figure 21 Network diagram

‌

Table 5 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
CE 1	XGE2/0/0	10.2.1.1/24	CE 3	XGE2/0/0	10.1.1.1/24
CE 2	XGE2/0/0	10.4.1.1/24	CE 4	XGE2/0/0	10.3.1.1/24
UPE 1	Loop0	1.1.1.9/32	UPE 2	Loop0	4.4.4.9/32
	XGE2/0/0	10.2.1.2/24		XGE2/0/0	172.2.1.1/24
	XGE2/0/1	10.4.1.2/24		XGE2/0/1	10.1.1.2/24
	XGE2/0/2	172.1.1.1/24		XGE2/0/2	10.3.1.2/24
SPE 1	Loop0	2.2.2.9/32	SPE 2	Loop0	3.3.3.9/32
	XGE2/0/0	172.1.1.2/24		XGE2/0/0	180.1.1.2/24
	XGE2/0/1	180.1.1.1/24		XGE2/0/1	172.2.1.2/24

‌

Procedure

1. Configure UPE 1:

# Configure basic MPLS and MPLS LDP to establish LDP LSPs.

<UPE1> system-view

[UPE1] interface loopback 0

[UPE1-LoopBack0] ip address 1.1.1.9 32

[UPE1-LoopBack0] quit

[UPE1] mpls lsr-id 1.1.1.9

[UPE1] mpls ldp

[UPE1-ldp] quit

[UPE1] interface ten-gigabitethernet 2/0/2

[UPE1-Ten-GigabitEthernet2/0/2] ip address 172.1.1.1 24

[UPE1-Ten-GigabitEthernet2/0/2] mpls enable

[UPE1-Ten-GigabitEthernet2/0/2] mpls ldp enable

[UPE1-Ten-GigabitEthernet2/0/2] quit

# Configure the IGP protocol (OSPF, in this example).

[UPE1] ospf

[UPE1-ospf-1] area 0

[UPE1-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255

[UPE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0

[UPE1-ospf-1-area-0.0.0.0] quit

[UPE1-ospf-1] quit

# Configure VPN instances vpn1 and vpn2, allowing CE 1 and CE 2 to access UPE 1.

[UPE1] ip vpn-instance vpn1

[UPE1-vpn-instance-vpn1] route-distinguisher 100:1

[UPE1-vpn-instance-vpn1] vpn-target 100:1 both

[UPE1-vpn-instance-vpn1] quit

[UPE1] ip vpn-instance vpn2

[UPE1-vpn-instance-vpn2] route-distinguisher 100:2

[UPE1-vpn-instance-vpn2] vpn-target 100:2 both

[UPE1-vpn-instance-vpn2] quit

[UPE1] interface ten-gigabitethernet 2/0/0

[UPE1-Ten-GigabitEthernet2/0/0] ip binding vpn-instance vpn1

[UPE1-Ten-GigabitEthernet2/0/0] ip address 10.2.1.2 24

[UPE1-Ten-GigabitEthernet2/0/0] quit

[UPE1] interface ten-gigabitethernet 2/0/1

[UPE1-Ten-GigabitEthernet2/0/1] ip binding vpn-instance vpn2

[UPE1-Ten-GigabitEthernet2/0/1] ip address 10.4.1.2 24

[UPE1-Ten-GigabitEthernet2/0/1] quit

# Establish an MP-IBGP peer relationship with SPE 1.

[UPE1] bgp 100

[UPE1-bgp-default] peer 2.2.2.9 as-number 100

[UPE1-bgp-default] peer 2.2.2.9 connect-interface loopback 0

[UPE1-bgp-default] address-family vpnv4

[UPE1-bgp-default-vpnv4] peer 2.2.2.9 enable

[UPE1-bgp-default-vpnv4] quit

# Establish an EBGP peer relationship with CE 1.

[UPE1-bgp-default] ip vpn-instance vpn1

[UPE1-bgp-default-vpn1] peer 10.2.1.1 as-number 65410

[UPE1-bgp-default-vpn1] address-family ipv4 unicast

[UPE1-bgp-default-ipv4-vpn1] peer 10.2.1.1 enable

[UPE1-bgp-default-ipv4-vpn1] quit

[UPE1-bgp-default-vpn1] quit

# Establish an EBGP peer relationship with CE 2.

[UPE1-bgp-default] ip vpn-instance vpn2

[UPE1-bgp-default-vpn2] peer 10.4.1.1 as-number 65420

[UPE1-bgp-default-vpn2] address-family ipv4 unicast

[UPE1-bgp-default-ipv4-vpn2] peer 10.4.1.1 enable

[UPE1-bgp-default-ipv4-vpn2] quit

[UPE1-bgp-default-vpn2] quit

[UPE1-bgp-default] quit

2. Configure CE 1.

<CE1> system-view

[CE1] interface ten-gigabitethernet 2/0/0

[CE1-Ten-GigabitEthernet2/0/0] ip address 10.2.1.1 255.255.255.0

[CE1-Ten-GigabitEthernet2/0/0] quit

[CE1] bgp 65410

[CE1-bgp-default] peer 10.2.1.2 as-number 100

[CE1-bgp-default] address-family ipv4 unicast

[CE1-bgp-default-ipv4] peer 10.2.1.2 enable

[CE1-bgp-default-ipv4] import-route direct

[CE1-bgp-default-ipv4] quit

[CE1-bgp-default] quit

3. Configure CE 2.

<CE2> system-view

[CE2] interface ten-gigabitethernet 2/0/0

[CE2-Ten-GigabitEthernet2/0/0] ip address 10.4.1.1 255.255.255.0

[CE2-Ten-GigabitEthernet2/0/0] quit

[CE2] bgp 65420

[CE2-bgp-default] peer 10.4.1.2 as-number 100

[CE2-bgp-default] address-family ipv4 unicast

[CE2-bgp-default-ipv4] peer 10.4.1.2 enable

[CE2-bgp-default-ipv4] import-route direct

[CE2-bgp-default-ipv4] quit

[CE2-bgp-default] quit

4. Configure UPE 2:

# Configure basic MPLS and MPLS LDP to establish LDP LSPs.

<UPE2> system-view

[UPE2] interface loopback 0

[UPE2-LoopBack0] ip address 4.4.4.9 32

[UPE2-LoopBack0] quit

[UPE2] mpls lsr-id 4.4.4.9

[UPE2] mpls ldp

[UPE2-ldp] quit

[UPE2] interface ten-gigabitethernet 2/0/0

[UPE2-Ten-GigabitEthernet2/0/0] ip address 172.2.1.1 24

[UPE2-Ten-GigabitEthernet2/0/0] mpls enable

[UPE2-Ten-GigabitEthernet2/0/0] mpls ldp enable

[UPE2-Ten-GigabitEthernet2/0/0] quit

# Configure the IGP protocol (OSPF, in this example).

[UPE2] ospf

[UPE2-ospf-1] area 0

[UPE2-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255

[UPE2-ospf-1-area-0.0.0.0] network 4.4.4.9 0.0.0.0

[UPE2-ospf-1-area-0.0.0.0] quit

[UPE2-ospf-1] quit

# Configure VPN instances vpn1 and vpn2, allowing CE 3 and CE 4 to access UPE 2.

[UPE2] ip vpn-instance vpn1

[UPE2-vpn-instance-vpn1] route-distinguisher 300:1

[UPE2-vpn-instance-vpn1] vpn-target 100:1 both

[UPE2-vpn-instance-vpn1] quit

[UPE2] ip vpn-instance vpn2

[UPE2-vpn-instance-vpn2] route-distinguisher 400:2

[UPE2-vpn-instance-vpn2] vpn-target 100:2 both

[UPE2-vpn-instance-vpn2] quit

[UPE2] interface ten-gigabitethernet 2/0/1

[UPE2-Ten-GigabitEthernet2/0/1] ip binding vpn-instance vpn1

[UPE2-Ten-GigabitEthernet2/0/1] ip address 10.1.1.2 24

[UPE2-Ten-GigabitEthernet2/0/1] quit

[UPE2] interface ten-gigabitethernet 2/0/2

[UPE2-Ten-GigabitEthernet2/0/2] ip binding vpn-instance vpn2

[UPE2-Ten-GigabitEthernet2/0/2] ip address 10.3.1.2 24

[UPE2-Ten-GigabitEthernet2/0/2] quit

# Establish an MP-IBGP peer relationship with SPE 2.

[UPE2] bgp 100

[UPE2-bgp-default] peer 3.3.3.9 as-number 100

[UPE2-bgp-default] peer 3.3.3.9 connect-interface loopback 0

[UPE2-bgp-default] address-family vpnv4

[UPE2-bgp-default-vpnv4] peer 3.3.3.9 enable

[UPE2-bgp-default-vpnv4] quit

# Establish an EBGP peer relationship with CE 3.

[UPE2-bgp-default] ip vpn-instance vpn1

[UPE2-bgp-default-vpn1] peer 10.1.1.1 as-number 65430

[UPE2-bgp-default-vpn1] address-family ipv4 unicast

[UPE2-bgp-default-ipv4-vpn1] peer 10.1.1.1 enable

[UPE2-bgp-default-ipv4-vpn1] quit

[UPE2-bgp-default-vpn1] quit

# Establish an EBGP peer relationship with CE 4.

[UPE2-bgp-default] ip vpn-instance vpn2

[UPE2-bgp-default-vpn2] peer 10.3.1.1 as-number 65440

[UPE2-bgp-default-vpn2] address-family ipv4 unicast

[UPE2-bgp-default-ipv4-vpn2] peer 10.3.1.1 enable

[UPE2-bgp-default-ipv4-vpn2] quit

[UPE2-bgp-default-vpn2] quit

[UPE2-bgp-default] quit

5. Configure CE 3.

<CE3> system-view

[CE3] interface ten-gigabitethernet 2/0/0

[CE3-Ten-GigabitEthernet2/0/0] ip address 10.1.1.1 255.255.255.0

[CE3-Ten-GigabitEthernet2/0/0] quit

[CE3] bgp 65430

[CE3-bgp-default] peer 10.1.1.2 as-number 100

[CE3-bgp-default] address-family ipv4 unicast

[CE3-bgp-default-ipv4] peer 10.1.1.2 enable

[CE3-bgp-default-ipv4] import-route direct

[CE3-bgp-default-ipv4] quit

[CE3-bgp-default] quit

6. Configure CE 4.

<CE4> system-view

[CE4] interface ten-gigabitethernet 2/0/0

[CE4-Ten-GigabitEthernet2/0/0] ip address 10.3.1.1 255.255.255.0

[CE4-Ten-GigabitEthernet2/0/0] quit

[CE4] bgp 65440

[CE4-bgp-default] peer 10.3.1.2 as-number 100

[CE4-bgp-default] address-family ipv4 unicast

[CE4-bgp-default-ipv4] peer 10.3.1.2 enable

[CE4-bgp-default-ipv4] import-route direct

[CE4-bgp-default-ipv4] quit

[CE4-bgp-default] quit

7. Configure SPE 1:

# Configure basic MPLS and MPLS LDP to establish LDP LSPs.

<SPE1> system-view

[SPE1] interface loopback 0

[SPE1-LoopBack0] ip address 2.2.2.9 32

[SPE1-LoopBack0] quit

[SPE1] mpls lsr-id 2.2.2.9

[SPE1] mpls ldp

[SPE1-ldp] quit

[SPE1] interface ten-gigabitethernet 2/0/0

[SPE1-Ten-GigabitEthernet2/0/0] ip address 172.1.1.2 24

[SPE1-Ten-GigabitEthernet2/0/0] mpls enable

[SPE1-Ten-GigabitEthernet2/0/0] mpls ldp enable

[SPE1-Ten-GigabitEthernet2/0/0] quit

[SPE1] interface ten-gigabitethernet 2/0/1

[SPE1-Ten-GigabitEthernet2/0/1] ip address 180.1.1.1 24

[SPE1-Ten-GigabitEthernet2/0/1] mpls enable

[SPE1-Ten-GigabitEthernet2/0/1] mpls ldp enable

[SPE1-Ten-GigabitEthernet2/0/1] quit

# Configure the IGP protocol, OSPF, in this example.

[SPE1] ospf

[SPE1-ospf-1] area 0

[SPE1-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0

[SPE1-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255

[SPE1-ospf-1-area-0.0.0.0] network 180.1.1.0 0.0.0.255

[SPE1-ospf-1-area-0.0.0.0] quit

[SPE1-ospf-1] quit

# Configure VPN instances vpn1 and vpn2.

[SPE1] ip vpn-instance vpn1

[SPE1-vpn-instance-vpn1] route-distinguisher 500:1

[SPE1-vpn-instance-vpn1] vpn-target 100:1 both

[SPE1-vpn-instance-vpn1] quit

[SPE1] ip vpn-instance vpn2

[SPE1-vpn-instance-vpn2] route-distinguisher 700:1

[SPE1-vpn-instance-vpn2] vpn-target 100:2 both

[SPE1-vpn-instance-vpn2] quit

# Establish MP-IBGP peer relationships with SPE 2 and UPE 1, and specify UPE 1 as a UPE.

[SPE1] bgp 100

[SPE1-bgp-default] peer 1.1.1.9 as-number 100

[SPE1-bgp-default] peer 1.1.1.9 connect-interface loopback 0

[SPE1-bgp-default] peer 3.3.3.9 as-number 100

[SPE1-bgp-default] peer 3.3.3.9 connect-interface loopback 0

[SPE1-bgp-default] address-family vpnv4

[SPE1-bgp-default-vpnv4] peer 3.3.3.9 enable

[SPE1-bgp-default-vpnv4] peer 1.1.1.9 enable

[SPE1-bgp-default-vpnv4] peer 1.1.1.9 upe

[SPE1-bgp-default-vpnv4] peer 1.1.1.9 next-hop-local

[SPE1-bgp-default-vpnv4] quit

# Create BGP-VPN instances for VPN instances vpn1 and vpn2, so the VPNv4 routes learned according to the RT attributes can be added into the BGP routing tables of the corresponding VPN instances.

[SPE1-bgp-default] ip vpn-instance vpn1

[SPE1-bgp-default-vpn1] quit

[SPE1-bgp-default] ip vpn-instance vpn2

[SPE1-bgp-default-vpn2] quit

[SPE1-bgp-default] quit

# Advertise to UPE 1 the routes permitted by a routing policy (the routes of CE 3).

[SPE1] ip prefix-list hope index 10 permit 10.1.1.1 24

[SPE1] route-policy hope permit node 0

[SPE1-route-policy-hope-0] if-match ip address prefix-list hope

[SPE1-route-policy-hope-0] quit

[SPE1] bgp 100

[SPE1-bgp-default] address-family vpnv4

[SPE1-bgp-default-vpnv4] peer 1.1.1.9 upe route-policy hope export

8. Configure SPE 2:

# Configure basic MPLS and MPLS LDP to establish LDP LSPs.

<SPE2> system-view

[SPE2] interface loopback 0

[SPE2-LoopBack0] ip address 3.3.3.9 32

[SPE2-LoopBack0] quit

[SPE2] mpls lsr-id 3.3.3.9

[SPE2] mpls ldp

[SPE2-ldp] quit

[SPE2] interface ten-gigabitethernet 2/0/0

[SPE2-Ten-GigabitEthernet2/0/0] ip address 180.1.1.2 24

[SPE2-Ten-GigabitEthernet2/0/0] mpls enable

[SPE2-Ten-GigabitEthernet2/0/0] mpls ldp enable

[SPE2-Ten-GigabitEthernet2/0/0] quit

[SPE2] interface ten-gigabitethernet 2/0/1

[SPE2-Ten-GigabitEthernet2/0/1] ip address 172.2.1.2 24

[SPE2-Ten-GigabitEthernet2/0/1] mpls enable

[SPE2-Ten-GigabitEthernet2/0/1] mpls ldp enable

[SPE2-Ten-GigabitEthernet2/0/1] quit

# Configure the IGP protocol, OSPF, in this example.

[SPE2] ospf

[SPE2-ospf-1] area 0

[SPE2-ospf-1-area-0.0.0.0] network 3.3.3.9 0.0.0.0

[SPE2-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255

[SPE2-ospf-1-area-0.0.0.0] network 180.1.1.0 0.0.0.255

[SPE2-ospf-1-area-0.0.0.0] quit

[SPE2-ospf-1] quit

# Configure VPN instances vpn1 and vpn2.

[SPE2] ip vpn-instance vpn1

[SPE2-vpn-instance-vpn1] route-distinguisher 600:1

[SPE2-vpn-instance-vpn1] vpn-target 100:1 both

[SPE2-vpn-instance-vpn1] quit

[SPE2] ip vpn-instance vpn2

[SPE2-vpn-instance-vpn2] route-distinguisher 800:1

[SPE2-vpn-instance-vpn2] vpn-target 100:2 both

[SPE2-vpn-instance-vpn2] quit

# Establish MP-IBGP peer relationships with SPE 1 and UPE 2, and specify UPE 2 as a UPE.

[SPE2] bgp 100

[SPE2-bgp-default] peer 4.4.4.9 as-number 100

[SPE2-bgp-default] peer 4.4.4.9 connect-interface loopback 0

[SPE2-bgp-default] peer 2.2.2.9 as-number 100

[SPE2-bgp-default] peer 2.2.2.9 connect-interface loopback 0

[SPE2-bgp-default] address-family vpnv4

[SPE2-bgp-default-vpnv4] peer 2.2.2.9 enable

[SPE2-bgp-default-vpnv4] peer 4.4.4.9 enable

[SPE2-bgp-default-vpnv4] peer 4.4.4.9 upe

[SPE2-bgp-default-vpnv4] peer 4.4.4.9 next-hop-local

[SPE2-bgp-default-vpnv4] quit

# Create BGP-VPN instances for VPN instances vpn1 and vpn2, so the VPNv4 routes learned according to the RT attributes can be added into the BGP routing tables of the corresponding VPN instances.

[SPE2-bgp-default] ip vpn-instance vpn1

[SPE2-bgp-default-vpn1] quit

[SPE2-bgp-default] ip vpn-instance vpn2

[SPE2-bgp-default-vpn2] quit

[SPE2-bgp-default] quit

# Advertise to UPE 2 the routes permitted by a routing policy (the routes of CE 1).

[SPE2] ip prefix-list hope index 10 permit 10.2.1.1 24

[SPE2] route-policy hope permit node 0

[SPE2-route-policy-hope-0] if-match ip address prefix-list hope

[SPE2-route-policy-hope-0] quit

[SPE2] bgp 100

[SPE2-bgp-default] address-family vpnv4

[SPE2-bgp-default-vpnv4] peer 4.4.4.9 upe route-policy hope export

Verifying the configuration

# Verify that CE 1 and CE3 can learn each other's interface routes and can ping each other. CE 2 and CE 4 cannot learn each other's interface routes and cannot ping each other. (Details not shown.)

Example: Configuring BGP AS number substitution

Network configuration

As shown in Figure 22, CE 1 and CE 2 belong to VPN 1 and are connected to PE 1 and PE 2, respectively. The two CEs have the same AS number, 600.

Configure BGP AS number substitution on the PEs to enable the CEs to communicate with each other.

Figure 22 Network diagram

‌

Table 6 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
CE 1	XGE2/0/0	10.1.1.1/24	P	Loop0	2.2.2.9/32
	XGE2/0/1	100.1.1.1/24		XGE2/0/0	20.1.1.2/24
PE 1	Loop0	1.1.1.9/32		XGE2/0/1	30.1.1.1/24
	XGE2/0/0	10.1.1.2/24	PE 2	Loop0	3.3.3.9/32
	XGE2/0/1	20.1.1.1/24		XGE2/0/0	10.2.1.2/24
CE 2	XGE2/0/0	10.2.1.1/24		XGE2/0/1	30.1.1.2/24
	XGE2/0/1	200.1.1.1/24

‌

Procedure

1. Configure basic MPLS L3VPN:

¡ Configure OSPF on the MPLS backbone to allow the PEs and P device to learn the routes of the loopback interfaces from each other.

¡ Configure basic MPLS and MPLS LDP on the MPLS backbone to establish LDP LSPs.

¡ Establish MP-IBGP peer relationship between the PEs to advertise VPN IPv4 routes.

¡ Configure the VPN instance of VPN 1 on PE 2 to allow CE 2 to access the network.

¡ Configure the VPN instance of VPN 1 on PE 1 to allow CE 1 to access the network.

¡ Configure BGP as the PE-CE routing protocol, and redistribute routes of CEs into PEs.

For more information about basic MPLS L3VPN configurations, see "Example: Configuring basic MPLS L3VPN."

# Execute the display ip routing-table command on CE 2. The output shows that CE 2 has learned the route to network 10.1.1.0/24, where the interface used by CE 1 to access PE 1 resides. However, it has not learned the route to the VPN (100.1.1.0/24) behind CE 1.

<CE2> display ip routing-table

Destinations : 15 Routes : 15

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

10.1.1.0/24 BGP 255 0 10.2.1.2 XGE2/0/0

10.2.1.0/24 Direct 0 0 10.2.1.1 XGE2/0/0

10.2.1.0/32 Direct 0 0 10.2.1.1 XGE2/0/0

10.2.1.1/32 Direct 0 0 127.0.0.1 InLoop0

10.2.1.255/32 Direct 0 0 10.2.1.1 XGE2/0/0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

200.1.1.0/24 Direct 0 0 200.1.1.1 XGE2/0/1

200.1.1.0/32 Direct 0 0 200.1.1.1 XGE2/0/1

200.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

200.1.1.255/24 Direct 0 0 200.1.1.1 XGE2/0/1

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

# Execute the display ip routing-table command on CE 1 to verify that CE 1 has not learned the route to the VPN behind CE 2. (Details not shown.)

# Execute the display ip routing-table vpn-instance command on the PEs. The output shows the route to the VPN behind the peer CE. This example uses PE 2.

<PE2> display ip routing-table vpn-instance vpn1

Destinations : 13 Routes : 13

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

10.1.1.0/24 BGP 255 0 1.1.1.9 XGE2/0/1

10.2.1.0/24 Direct 0 0 10.2.1.2 XGE2/0/0

10.2.1.0/32 Direct 0 0 10.2.1.2 XGE2/0/0

10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0

10.2.1.255/32 Direct 0 0 10.2.1.2 XGE2/0/0

100.1.1.0/24 BGP 255 0 1.1.1.9 XGE2/0/1

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

200.1.1.0/24 BGP 255 0 10.2.1.1 XGE2/0/0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

# Enable BGP update packet debugging on PE 2. The output shows that PE 2 advertises the route to 100.1.1.0/24, and the AS_PATH is 100 600.

<PE2> terminal monitor

<PE2> terminal logging level 7

<PE2> debugging bgp update vpn-instance vpn1 10.2.1.1 ipv4

<PE2> refresh bgp all export ipv4 vpn-instance vpn1

*Jun 13 16:12:52:096 2012 PE2 BGP/7/DEBUG:

BGP.vpn1: Send UPDATE to peer 10.2.1.1 for following destinations:

Origin : Incomplete

AS Path : 100 600

Next Hop : 10.2.1.2

100.1.1.0/24,

# Execute the display bgp routing-table ipv4 peer received-routes command on CE 2 to verify that CE 2 has not received the route to 100.1.1.0/24.

<CE2> display bgp routing-table ipv4 peer 10.2.1.2 received-routes

Total number of routes: 2

BGP local router ID is 200.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >e 10.1.1.0/24 10.2.1.2 0 100?

* e 10.2.1.0/24 10.2.1.2 0 0 100?

2. Configure BGP AS number substitution on PE 2.

<PE2> system-view

[PE2] bgp 100

[PE2-bgp-default] ip vpn-instance vpn1

[PE2-bgp-default-vpn1] peer 10.2.1.1 substitute-as

[PE2-bgp-default-vpn1] address-family ipv4 unicast

[PE2-bgp-default-ipv4-vpn1] peer 10.2.1.1 enable

[PE2-bgp-default-ipv4-vpn1] quit

[PE2-bgp-default-vpn1] quit

[PE2-bgp-default] quit

Verifying the configuration

# The output shows that among the routes advertised by PE 2 to CE 2, the AS_PATH of 100.1.1.0/24 has changed from 100 600 to 100 100.

*Jun 13 16:15:59:456 2012 PE2 BGP/7/DEBUG:

BGP.vpn1: Send UPDATE to peer 10.2.1.1 for following destinations:

Origin : Incomplete

AS Path : 100 100

Next Hop : 10.2.1.2

100.1.1.0/24,

# Display again the routing information that CE 2 has received, and the routing table.

<CE2> display bgp routing-table ipv4 peer 10.2.1.2 received-routes

Total number of routes: 3

BGP local router ID is 200.1.1.1

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >e 10.1.1.0/24 10.2.1.2 0 100?

* e 10.2.1.0/24 10.2.1.2 0 0 100?

* >e 100.1.1.0/24 10.2.1.2 0 100 100?

<CE2> display ip routing-table

Destinations : 16 Routes : 16

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

10.1.1.0/24 BGP 255 0 10.2.1.2 XGE2/0/0

10.2.1.0/24 Direct 0 0 10.2.1.1 XGE2/0/0

10.2.1.0/32 Direct 0 0 10.2.1.1 XGE2/0/0

10.2.1.1/32 Direct 0 0 127.0.0.1 InLoop0

10.2.1.255/32 Direct 0 0 10.2.1.1 XGE2/0/0

100.1.1.0/24 BGP 255 0 10.2.1.2 XGE2/0/0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

200.1.1.0/24 Direct 0 0 200.1.1.1 XGE2/0/1

200.1.1.0/32 Direct 0 0 200.1.1.1 XGE2/0/1

200.1.1.1/32 Direct 0 0 127.0.0.1 InLoop0

200.1.1.255/32 Direct 0 0 200.1.1.1 XGE2/0/1

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

# After you also configure BGP AS substitution on PE 1, verify that the interfaces of CE 1 and CE 2 can ping each other. (Details not shown.)

Example: Configuring BGP AS number substitution and SoO attribute

Network configuration

CE 1, CE 2, and CE 3 belong to VPN 1, and are connected to PE1, PE 2, and PE 3, respectively.

CE 1 and CE 2 reside in the same site. CE1, CE2, and CE 3 all use AS number 600.

· To avoid route loss, configure BGP AS number substitution on PEs.

· To avoid routing loops, configure the same SoO attribute on PE 1 and PE 2 for CE 1 and CE 2.

Figure 23 Network diagram

‌

Table 7 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
CE 1	Loop0	100.1.1.1/32	CE 3	Loop0	200.1.1.1 /32
	XGE2/0/0	10.1.1.1/24		XGE2/0/0	10.3.1.1/24
CE 2	XGE2/0/0	10.2.1.1/24	PE 2	Loop0	2.2.2.9/32
PE 1	Loop0	1.1.1.9/32		XGE2/0/0	10.2.1.2/24
	XGE2/0/0	10.1.1.2/24		XGE2/0/1	40.1.1.1/24
	XGE2/0/1	20.1.1.1/24		XGE2/0/2	20.1.1.2/24
	XGE2/0/2	30.1.1.1/24	P	Loop0	3.3.3.9/32
PE 3	Loop0	4.4.4.9/32		XGE2/0/0	30.1.1.2/24
	XGE2/0/0	10.3.1.2/24		XGE2/0/1	40.1.1.2/24
	XGE2/0/1	50.1.1.2/24		XGE2/0/2	50.1.1.1/24

‌

Procedure

1. Configure basic MPLS L3VPN:

¡ Configure OSPF on the MPLS backbone to allow the PEs and P device to learn the routes of the loopback interfaces from each other.

¡ Configure basic MPLS and MPLS LDP on the MPLS backbone to establish LDP LSPs.

¡ Establish MP-IBGP peer relationship between the PEs to advertise VPN IPv4 routes.

¡ Configure the VPN instance of VPN 1 on PE 1 to allow CE 1 to access the network.

¡ Configure the VPN instance of VPN 1 on PE 2 to allow CE 2 to access the network.

¡ Configure the VPN instance of VPN 1 on PE 3 to allow CE 3 to access the network.

¡ Configure BGP as the PE-CE routing protocol, and redistribute routes of CEs into PEs.

For more information about basic MPLS L3VPN configurations, see "Example: Configuring basic MPLS L3VPN."

2. Configure BGP AS number substitution:

# Configure BGP AS number substitution on PE 1, PE 2, and PE 3. For more information about the configuration, see "Example: Configuring BGP AS number substitution."

# Display routing information on CE 2. The output shows that CE 2 has learned the route for 100.1.1.1/32 from CE 1. A routing loop has occurred because CE 1 and CE 2 reside in the same site.

<CE2> display bgp routing-table ipv4 peer 10.2.1.2 received-routes

Total number of routes: 6

BGP local router ID is 1.1.1.9

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Network NextHop MED LocPrf PrefVal Path/Ogn

* >e 10.1.1.0/24 10.2.1.2 0 100?

* 10.2.1.0/24 10.2.1.2 0 0 100?

* 10.2.1.1/32 10.2.1.2 0 0 100?

* >e 10.3.1.0/24 10.2.1.2 0 100?

* >e 100.1.1.1/32 10.2.1.2 0 100 100?

* >e 200.1.1.1/32 10.2.1.2 0 100 100?

3. Configure BGP SoO attribute:

# On PE 1, configure the SoO attribute as 1:100 for CE 1.

<PE1> system-view

[PE1] bgp 100

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] address-family ipv4

[PE1-bgp-default-ipv4-vpn1] peer 10.1.1.1 soo 1:100

# On PE 2, configure the SoO attribute as 1:100 for CE 2.

<PE2> system-view

[PE2] bgp 100

[PE2-bgp-default] ip vpn-instance vpn1

[PE2-bgp-default-vpn1] address-family ipv4

[PE2-bgp-default-ipv4-vpn1] peer 10.2.1.1 soo 1:100

Verifying the configuration

# PE 2 does not advertise routes received from CE 1 to CE 2 because the same SoO attribute has been configured for the CEs. Display the routing table of CE 2. The output shows that the route 100.1.1.1/32 has been removed.

<CE2> display ip routing-table

Destinations : 12 Routes : 12

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

10.2.1.0/24 Direct 0 0 10.2.1.1 XGE2/0/0

10.2.1.0/32 Direct 0 0 10.2.1.1 XGE2/0/0

10.2.1.1/32 Direct 0 0 127.0.0.1 Inloop0

10.2.1.255/32 Direct 0 0 10.2.1.1 XGE2/0/0

10.3.1.0/24 BGP 255 0 10.2.1.2 XGE2/0/0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

200.1.1.1/32 BGP 255 0 10.2.1.2 XGE2/0/0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

Example: Configuring MPLS L3VPN FRR through VPNv4 route backup for a VPNv4 route

Network configuration

CE 1 and CE 2 belong to VPN 1.

Configure EBGP between CEs and PEs to exchange VPN routes.

Configure OSPF to ensure connectivity between PEs, and configure MP-IBGP to exchange VPNv4 routing information between PEs.

Configure MPLS L3VPN FRR on PE 1 to achieve the following purposes:

· When the link 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 BFD detects that the LSP between PE 1 and PE 2 fails, traffic from CE 1 to CE 2 goes through the path CE 1—PE 1—PE 3—CE 2.

Figure 24 Network diagram

‌

Table 8 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
CE 1	Loop0	5.5.5.5/32	PE 1	Loop0	1.1.1.1/32
	XGE2/0/0	10.2.1.1/24		XGE2/0/0	10.2.1.2/24
PE 2	Loop0	2.2.2.2/32		XGE2/0/1	172.1.1.1/24
	XGE2/0/0	172.1.1.2/24		XGE2/0/2	172.2.1.1/24
	XGE2/0/1	10.1.1.2/24	CE 2	Loop0	4.4.4.4/32
PE 3	Loop0	3.3.3.3/32		XGE2/0/0	10.1.1.1/24
	XGE2/0/0	172.2.1.3/24		XGE2/0/1	10.3.1.1/24
	XGE2/0/1	10.3.1.2/24

‌

Procedure

1. Configure IP addresses and masks for interfaces as shown in Table 8, and configure BGP and MPLS L3VPN. (Details not shown.)

For more information about configuring basic MPLS L3VPN, see "Example: Configuring basic MPLS L3VPN."

2. Configure MPLS L3VPN FRR on PE 1:

# Configure BFD to test the connectivity of the LSP to 2.2.2.2/32.

<PE1> system-view

[PE1] mpls bfd enable

[PE1] mpls bfd 2.2.2.2 32

# Create routing policy frr, and specify the backup next hop as 3.3.3.3 for the route to 4.4.4.4/32.

[PE1] ip prefix-list abc index 10 permit 4.4.4.4 32

[PE1] route-policy frr permit node 10

[PE1-route-policy-frr-10] if-match ip address prefix-list abc

[PE1-route-policy-frr-10] apply fast-reroute backup-nexthop 3.3.3.3

[PE1-route-policy-frr-10] quit

# Configure FRR for VPN instance vpn1 to use routing policy frr.

[PE1] bgp 100

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] address-family ipv4 unicast

[PE1-bgp-default-ipv4-vpn1] fast-reroute route-policy frr

[PE1-bgp-default-ipv4-vpn1] quit

[PE1-bgp-default-vpn1] quit

# Specify the preferred value as 100 for routes received from PE 2. This value is greater than the preferred value (0) for routes from PE 3, so PE 1 prefers the routes from PE 2.

[PE1-bgp-default] address-family vpnv4

[PE1-bgp-default-vpnv4] peer 2.2.2.2 preferred-value 100

[PE1-bgp-default-vpnv4] quit

[PE1-bgp-default] quit

3. Enable MPLS BFD on PE 2.

<PE2> system-view

[PE2] mpls bfd enable

Verifying the configuration

# Display detailed information about the route to 4.4.4.4/32 on PE 1. The output shows the backup next hop for the route.

[PE1] display ip routing-table vpn-instance vpn1 4.4.4.4 32 verbose

Summary Count : 1

Destination: 4.4.4.4/32

Protocol: BGP

Process ID: 0

SubProtID: 0x1 Age: 00h00m03s

FlushedAge: 15h28m49s

Cost: 0 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x102 OrigAs: 300

NibID: 0x15000002 LastAs: 300

AttrID: 0x2

BkAttrID: 0xffffffff Neighbor: 2.2.2.2

Flags: 0x110060 OrigNextHop: 2.2.2.2

Label: 1146 RealNextHop: 172.1.1.2

BkLabel: 1275 BkNextHop: 172.2.1.3

SRLabel: NULL Interface: N/A

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: 0x401 IPInterface: XGE2/0/1

BkTunnel ID: 0x409 BkIPInterface: XGE2/0/2

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BkColorInterface: NULL

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BkTunnelInterface: N/A

Connector: N/A PathID: 0x0

UserID: 0x0 SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

SID: N/A

BkSID: N/A

CommBlockLen: 0 Priority: Critical

MemberPort: N/A ExtFlags: 0x0

Example: Configuring MPLS L3VPN FRR through VPNv4 route backup for an IPv4 route

Network configuration

CE 1 and CE 2 belong to VPN 1.

Configure EBGP between CEs and PEs to exchange VPN routes.

Configure OSPF to ensure connectivity between PEs, and configure MP-IBGP to exchange VPNv4 routing information between PEs.

Configure MPLS L3VPN FRR on PE 2 to achieve the following purposes:

· When the link PE 2—CE 2 operates correctly, traffic from CE 1 to CE 2 goes through the path CE 1—PE 1—PE 2—CE 2.

· When BFD detects that the link between PE 2 and CE 2 fails, traffic from CE 1 to CE 2 goes through the path CE 1—PE 1—PE 2—PE 3—CE 2.

Figure 25 Network diagram

‌

Table 9 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
CE 1	Loop0	5.5.5.5/32	PE 2	Loop0	2.2.2.2/32
	XGE2/0/0	10.2.1.1/24		XGE2/0/0	172.1.1.2/24
PE 1	Loop0	1.1.1.1/32		XGE2/0/1	10.1.1.2/24
	XGE2/0/0	10.2.1.2/24		XGE2/0/2	172.3.1.2/24
	XGE2/0/1	172.1.1.1/24	PE 3	Loop0	3.3.3.3/32
	XGE2/0/2	172.2.1.1/24		XGE2/0/0	172.2.1.3/24
CE 2	Loop0	4.4.4.4/32		XGE2/0/1	10.3.1.2/24
	XGE2/0/0	10.1.1.1/24		XGE2/0/2	172.3.1.3/24
	XGE2/0/1	10.3.1.1/24

‌

Procedure

1. Configure IP addresses and masks for interfaces as shown in Table 9, and configure BGP and MPLS L3VPN. (Details not shown.)

For more information about configuring basic MPLS L3VPN, see "Example: Configuring basic MPLS L3VPN."

2. Configure MPLS L3VPN FRR on PE 2:

# Configure the source IP address of BFD echo packets as 12.1.1.1.

<PE2> system-view

[PE2] bfd echo-source-ip 12.1.1.1

# Create routing policy frr, and specify the backup next hop as 3.3.3.3 for the route to 4.4.4.4/32.

[PE2] ip prefix-list abc index 10 permit 4.4.4.4 32

[PE2] route-policy frr permit node 10

[PE2-route-policy-frr-10] if-match ip address prefix-list abc

[PE2-route-policy-frr-10] apply fast-reroute backup-nexthop 3.3.3.3

[PE2-route-policy-frr-10] quit

# Use echo-mode BFD to detect the primary route connectivity.

[PE2] bgp 100

[PE2-bgp-default] primary-path-detect bfd echo

# Configure FRR for VPN instance vpn1 to use routing policy frr.

[PE2-bgp-default] ip vpn-instance vpn1

[PE2-bgp-default-vpn1] address-family ipv4 unicast

[PE2-bgp-default-ipv4-vpn1] fast-reroute route-policy frr

# Specify the preferred value as 200 for BGP routes received from CE 2. This value is greater than the preferred value (0) for routes from PE 3, so PE 2 prefers the routes from CE 2.

[PE2-bgp-default-ipv4-vpn1] peer 10.1.1.1 preferred-value 200

[PE2-bgp-default-vpn1] quit

[PE2-bgp-default] quit

Verifying the configuration

# Display detailed information about the route to 4.4.4.4/32 on PE 2. The output shows the backup next hop for the route.

[PE2] display ip routing-table vpn-instance vpn1 4.4.4.4 32 verbose

Summary Count : 1

Destination: 4.4.4.4/32

Protocol: BGP

Process ID: 0

SubProtID: 0x2 Age: 01h54m24s

FlushedAge: 15h28m49s

Cost: 0 Preference: 10

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: vpn1

TableID: 0x102 OrigAs: 300

NibID: 0x15000002 LastAs: 300

AttrID: 0x0

BkAttrID: 0xffffffff Neighbor: 10.1.1.1

Flags: 0x10060 OrigNextHop: 10.1.1.1

Label: NULL RealNextHop: 10.1.1.1

BkLabel: 1275 BkNextHop: 172.3.1.3

SRLabel: NULL Interface: N/A

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: Invalid IPInterface: XGE2/0/1

BkTunnel ID: 0x409 BkIPInterface: XGE2/0/2

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BkColorInterface: NULL

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BkTunnelInterface: N/A

Connector: N/A PathID: 0x0

UserID: 0x0 SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

SID: N/A

BkSID: N/A

CommBlockLen: 0 Priority: Critical

MemberPort: N/A ExtFlags: 0x0

Example: Configuring MPLS L3VPN FRR through IPv4 route backup for a VPNv4 route

Network configuration

CE 1 and CE 2 belong to VPN 1.

Configure EBGP between CEs and PEs to exchange VPN routes.

Configure OSPF to ensure connectivity between PEs, and configure MP-IBGP to exchange VPNv4 routing information between PEs.

Configure MPLS L3VPN FRR on PE 1 to achieve the following purposes:

· When the link 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 BFD detects that the link between PE 1 and PE 2 fails, traffic from CE 1 to CE 2 goes through the path CE 1—PE 1—CE 2.

Figure 26 Network diagram

‌

Table 10 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
CE 1	Loop0	5.5.5.5/32	CE 2	Loop0	4.4.4.4/32
	XGE2/0/0	10.2.1.1/24		XGE2/0/0	10.1.1.1/24
PE 1	Loop0	1.1.1.1/32		XGE2/0/1	10.3.1.1/24
	XGE2/0/0	10.2.1.2/24	PE 2	Loop0	2.2.2.2/32
	XGE2/0/1	10.1.1.2/24		XGE2/0/1	10.3.1.2/24
	XGE2/0/2	172.2.1.1/24		XGE2/0/2	172.2.1.2/24

‌

Procedure

1. Configure IP addresses and masks for interfaces as shown in Table 10, and configure BGP and MPLS L3VPN. (Details not shown.)

For more information about configuring basic MPLS L3VPN, see "Example: Configuring basic MPLS L3VPN."

2. Configure MPLS L3VPN FRR on PE 1:

# Configure BFD to test the connectivity of the LSP to 2.2.2.2/32.

<PE1> system-view

[PE1] mpls bfd enable

[PE1] mpls bfd 2.2.2.2 32

# Create routing policy frr, and specify the backup next hop as 10.1.1.1 for the route to 4.4.4.4/32.

[PE1] ip prefix-list abc index 10 permit 4.4.4.4 32

[PE1] route-policy frr permit node 10

[PE1-route-policy-frr-10] if-match ip address prefix-list abc

[PE1-route-policy-frr-10] apply fast-reroute backup-nexthop 10.1.1.1

[PE1-route-policy-frr-10] quit

# Configure FRR for VPN instance vpn1 to use routing policy frr.

[PE1] bgp 100

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] address-family ipv4 unicast

[PE1-bgp-default-ipv4-vpn1] fast-reroute route-policy frr

[PE1-bgp-default-ipv4-vpn1] quit

[PE1-bgp-default-vpn1] quit

# Specify the preferred value as 200 for BGP VPNv4 routes received from PE 2. This value is greater than the preferred value (0) for IPv4 unicast routes from CE 2, so PE 1 prefers the routes from PE 2.

[PE1-bgp-default] address-family vpnv4

[PE1-bgp-default-vpnv4] peer 2.2.2.2 preferred-value 200

[PE1-bgp-default-vpnv4] quit

[PE1-bgp-default] quit

3. Enable MPLS BFD on PE 2.

<PE2> system-view

[PE2] mpls bfd enable

Verifying the configuration

# Display detailed information about the route to 4.4.4.4/32 on PE 1. The output shows the backup next hop for the route.

[PE1] display ip routing-table vpn-instance vpn1 4.4.4.4 32 verbose

Summary Count : 1

Destination: 4.4.4.4/32

Protocol: BGP

Process ID: 0

SubProtID: 0x1 Age: 00h00m03s

FlushedAge: 15h28m49s

Cost: 0 Preference: 255

IpPre: N/A QosLocalID: N/A

Tag: 0 State: Active Adv

OrigTblID: 0x0 OrigVrf: default-vrf

TableID: 0x102 OrigAs: 300

NibID: 0x15000004 LastAs: 300

AttrID: 0x1

BkAttrID: 0xffffffff Neighbor: 2.2.2.2

Flags: 0x110060 OrigNextHop: 2.2.2.2

Label: 1275 RealNextHop: 172.1.1.2

BkLabel: NULL BkNextHop: 10.1.1.1

SRLabel: NULL Interface: N/A

BkSRLabel: NULL BkInterface: N/A

Tunnel ID: 0x401 IPInterface: XGE2/0/2

BkTunnel ID: 0x409 BkIPInterface: XGE2/0/1

InLabel: NULL ColorInterface: N/A

SIDIndex: NULL BkColorInterface: NULL

FtnIndex: 0x0 TunnelInterface: N/A

TrafficIndex: N/A BkTunnelInterface: N/A

Connector: N/A PathID: 0x0

UserID: 0x0 SRTunnelID: Invalid

SID Type: N/A NID: Invalid

FlushNID: Invalid BkNID: Invalid

BkFlushNID: Invalid StatFlags: 0x0

SID: N/A

BkSID: N/A

CommBlockLen: 0 Priority: Critical

MemberPort: N/A ExtFlags: 0x0

Configuring IPv6 MPLS L3VPN

About IPv6 MPLS L3VPN

IPv6 MPLS L3VPN, also known as IPv6 VPN Provider Edge (6VPE), uses BGP to advertise IPv6 VPN routes and uses MPLS to forward IPv6 VPN packets on the service provider backbone.

IPv6 MPLS L3VPN network diagram

Figure 27 shows a typical IPv6 MPLS L3VPN model. The service provider backbone in the IPv6 MPLS L3VPN model is an IPv4 network. IPv6 runs inside the VPNs and between CE and PE. Therefore, PEs must support both IPv4 and IPv6. The PE-CE interfaces of a PE run IPv6, and the PE-P interface of a PE runs IPv4.

Figure 27 Network diagram for the IPv6 MPLS L3VPN model

‌

IPv6 MPLS L3VPN packet forwarding

As shown in Figure 28, the IPv6 MPLS L3VPN packet forwarding procedure is as follows:

1. The PC at Site 1 sends an IPv6 packet destined for 2001:2::1, the PC at Site 2. CE 1 transmits the packet to PE 1.

2. Based on the inbound interface and destination address of the packet, PE 1 finds a matching entry from the routing table of the VPN instance, labels the packet with both a private network label (inner label) and a public network label (outer label), and forwards the packet out.

3. The MPLS backbone transmits the packet to PE 2 by outer label. The outer label is removed from the packet at the penultimate hop.

4. According to the inner label and destination address of the packet, PE 2 searches the routing table of the VPN instance to determine the outbound interface, and then forwards the packet out of the interface to CE 2.

5. CE 2 forwards the packet to the destination by IPv6 forwarding.

Figure 28 IPv6 MPLS L3VPN packet forwarding diagram

‌

IPv6 MPLS L3VPN routing information advertisement

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

Routing information advertisement from the local CE to the ingress PE.

The local CE advertises standard IPv6 routing information to the ingress PE over an IPv6 static route, OSPFv3 route, IPv6 IS-IS route, IBGP route, or EBGP route.

Routing information advertisement from the ingress PE to the egress PE.

After receiving the standard IPv6 routes from the CE, the ingress PE performs the following operations:

1. Adds RDs and route targets to create VPN-IPv6 routes.

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

3. Assigns VPN labels for the routes.

4. Advertises the VPN-IPv6 routes to the egress PE through MP-BGP.

The egress PE performs the following operations:

1. Compares the export target attributes of the VPN-IPv6 routes with the import target attributes that it maintains for the VPN instance.

2. Adds the routes to the routing table of the VPN instance if the export and import target attributes are the same.

The PEs use an IGP to ensure the connectivity between them.

Routing information advertisement from the egress PE to the remote peer CE.

The egress PE restores the original IPv6 routes and advertises them to the remote CE over an IPv6 static route, OSPFv3 route, IPv6 IS-IS route, EBGP, or IBGP route.

IPv6 MPLS L3VPN network schemes and features

IPv6 MPLS L3VPN supports the following network schemes and features:

· Basic VPN.

· Inter-AS VPN option A.

· Inter-AS VPN option B.

· Inter-AS VPN option C.

· Carrier's carrier.

· HoVPN.

· OSPFv3 VPN extension. (OSPFv3 Type 3, Type 5, and Type 7 LSAs support the DN bit. By default, OSPFv3 VPN extension uses the DN bit to avoid routing loops.)

· BGP AS number substitution and SoO.

· IPv6 MPLS L3VPN FRR.

Protocols and standards

· RFC 4659, BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN

· RFC 6565, OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol

IPv6 MPLS L3VPN tasks at a glance

Unless otherwise indicated, configure IPv6 MPLS L3VPN on PEs.

To configure IPv6 MPLS L3VPN, perform the following tasks:

1. Configuring IPv6 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 VPNv6 route control

2. Configuring advanced IPv6 MPLS L3VPN networks

Choose the following tasks as needed:

3. (Optional.) Configuring IPv6 MPLS L3VPN FRR

4. (Optional.) Controlling MPLS L3VPN route advertisement and reception

¡ Configuring an OSPFv3 sham link

¡ Configuring BGP AS number substitution and SoO attribute

¡ Configuring the AIGP attribute

¡ Configuring the BGP additional path feature

¡ Enabling independent routing tables for BGP VPNv6 routes and BGP-VPN instance routes

¡ 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 ECMP VPN route redistribution

Perform this task to enable a VPN instance to redistribute all routes that have the same prefix and RD into its routing table to perform load sharing or IPv6 MPLS L3VPN FRR.

¡ Enabling prioritized withdrawal of specific routes

5. (Optional.) Enabling logging for BGP route flapping

Restrictions and guidelines: IPv6 MPLS L3VPN configuration

The public tunnels for IPv6 MPLS L3VPN can be LSP and MPLS TE tunnels.

Prerequisites for IPv6 MPLS L3VPN

Before configuring IPv6 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 PEs and P devices to establish LDP LSPs.

Configuring VPN instances

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

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 IPv6 unicast address family view of VPN instance vpna will be deleted if no RD is configured in VPN instance IPv6 address family view.

Procedure

1. Enter system view.

system-view

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

mpls per-vrf-label range minimum maximum

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.) Set an ID for the VPN instance.

vpn-id vpn-id

By default, no 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 IPv6 address family view.

address-family ipv6

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 is not associated with a VPN instance and belongs to the public network.

CAUTION:

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

‌

The ip binding vpn-instance command clears the IPv6 address of the interface. Therefore, reconfigure an IPv6 address for the interface after configuring this 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.

IPv6 VPN prefers the configurations in VPN instance IPv6 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 IPv6 address family view.

¡ Enter VPN instance view.

ip vpn-instance vpn-instance-name

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

ip vpn-instance vpn-instance-name

address-family ipv6

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 PE from storing 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. Apply a tunnel policy to the VPN instance.

tnl-policy tunnel-policy-name

By default, only one tunnel is selected (no load balancing) in this order: LSP tunnel, CRLSP tunnel, and SRLSP tunnel.

If the specified tunnel policy does not exist, the default tunnel policy is used.

For information about tunnel policies, see "Configuring tunnel policies."

Configuring routing between a PE and a CE

Configuring IPv6 static routing between a PE and a CE

About this task

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

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

Procedure

1. Enter system view.

system-view

2. Configure an IPv6 static route for a VPN instance.

ipv6 route-static vpn-instance s-vpn-instance-name ipv6-address prefix-length { interface-type interface-number [ next-hop-address ] | nexthop-address [ public ] | vpn-instance d-vpn-instance-name nexthop-address } [ permanent ] [ preference preference ] [ tag tag-value ] [ description text ]

Configuring OSPFv3 between a PE and a CE

About this task

Perform this configuration on the PE. On the CE, configure a common OSPFv3 process.

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

Procedure

1. Enter system view.

system-view

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

ospfv3 [ process-id | vpn-instance vpn-instance-name ] *

An OSPFv3 process can belong to only one VPN instance.

Deleting a VPN instance also deletes all related OSPFv3 processes.

3. Set the router ID.

router-id router-id

4. Redistribute BGP routes.

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

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

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

5. (Optional.) Configure OSPFv3 route attributes:

a. Set an OSPFv3 domain ID.

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

The default domain ID is 0.

Description

Restrictions and guidelines

When you redistribute OSPFv3 routes into BGP, BGP adds the primary domain ID to the redistributed BGP routes as a BGP extended community attribute.

You can configure the same domain ID for different OSPFv3 processes.

You must configure the same domain ID for all OSPFv3 processes of the same VPN to ensure correct route advertisement.

‌

b. Configure the type code of an OSPFv3 extended community attribute.

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

By default, the type codes for domain ID, route type, and router ID are 0x0005, 0x0306, 0x0107, respectively.

c. Configure an external route tag for redistributed 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. The last two octets are the local BGP AS number. If the AS number is greater than 65535, the external route tag is 0.

d. Disable setting the DN bit in OSPFv3 LSAs.

disable-dn-bit-set

By default, when a PE redistributes BGP routes into OSPFv3 and creates OSPFv3 LSAs, it sets the DN bit for the LSAs.

This command might cause routing loops. Use it with caution.

e. Ignore the DN bit in OSPFv3 LSAs.

disable-dn-bit-check

By default, the PE checks the DN bit in OSPFv3 LSAs.

This command might cause routing loops. Use it with caution.

f. Enable the external route check feature for OSPFv3 LSAs.

route-tag-check enable

By default, the PE does not check the external route tag but checks the DN bit in OSPFv3 LSAs to avoid routing loops.

This command is only for backward compatibility with the old protocol (RFC 4577).

g. Return to system view.

quit

6. Enter interface view.

interface interface-type interface-number

7. Enable OSPFv3 on the interface.

ospfv3 process-id area area-id [ instance instance-id ]

By default, OSPFv3 is disabled on an interface.

For the command to be executed successfully, make sure the VPN instance to which the OSPFv3 process belongs is the VPN instance bound to the interface.

Configuring IPv6 IS-IS between a PE and a CE

About this task

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

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

Procedure

1. Enter system view.

system-view

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

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

An IPv6 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. Create the IS-IS IPv6 unicast address family and enter its view.

address-family ipv6 [ unicast ]

5. Redistribute BGP routes.

By default, IPv6 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 IPv6 for the IS-IS process on the interface.

isis ipv6 enable [ process-id ]

By default, IPv6 is disabled for the IS-IS process 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 IPv6 address family view, the device automatically deletes the BGP-VPN IPv6 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

4. Configure the CE as the VPN EBGP peer.

peer { group-name | ipv6-address [ prefix-length ] } as-number as-number

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

address-family ipv6 [ unicast ]

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

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

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

By default, BGP does not exchange IPv6 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 that it can advertise them to the peer PE.

8. (Optional.) 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 | ipv6-address [ prefix-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. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the PE as an EBGP peer.

peer { group-name | ipv6-address [ prefix-length ] } as-number as-number

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

address-family ipv6 [ unicast ]

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

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

By default, BGP does not exchange IPv6 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 advertise its VPN routes to the connected PE so that 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 IPv6 MPLS L3VPN network. In networks such as inter-AS VPN and carrier's carrier, you cannot configure IBGP between PE and CE.

Configuring the PE

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

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 | ipv6-address [ prefix-length ] } as-number as-number

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

address-family ipv6 [ unicast ]

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

peer { group-name | ipv6-address [ prefix-length ] } enable

By default, BGP does not exchange IPv6 unicast routes with a 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 | ipv6-address [ prefix-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. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the PE as an IBGP peer.

peer { group-name | ipv6-address [ prefix-length ] } as-number as-number

4. Create the BGP IPv6 unicast family and enter its view.

address-family ipv6 [ unicast ]

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

peer { group-name | ipv6-address [ prefix-length ] } enable

By default, BGP does not exchange IPv6 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. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the remote PE as the peer.

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

4. Specify the source interface for TCP connections.

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

By default, BGP uses the outbound interface of the best route to the BGP peer as the source interface.

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

address-family vpnv6

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

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

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

Configuring BGP VPNv6 route control

About BGP VPNv6 route control

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

Controlling BGP VPNv6 route saving

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

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

Specifying a preferred value for BGP VPNv6 routes

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

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

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

The default preferred value is 0.

Setting the maximum number of received routes

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

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

Configuring BGP VPNv6 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.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

4. Configure the local PE as the RR and specify the peer as the client.

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

By default, no RR 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, an 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.

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

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

By default, an RR does not filter reflected routes.

Only IBGP routes whose extended community attribute matches the specified community list are reflected.

By configuring different filtering policies on RRs, you can implement load balancing among the RRs.

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 VPNv6 route attributes

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

4. Configure the NEXT_HOP attribute.

¡ 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 of 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 VPNv6 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 routes received from a peer or peer group and set the maximum number of repetitions.

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

By default, BGP discards route updates 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 any peers or peer groups.

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 any peers or peer groups.

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 VPNv6 route filtering

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

4. Filter advertised routes.

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

By default, BGP does not filter advertised routes.

5. Filter received routes.

filter-policy { ipv6-acl-number | name ipv6-acl-name | prefix-list ipv6-prefix-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 { ipv6-acl-number | name ipv6-acl-name } { export | import }

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

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

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

By default, IPv6 prefix list-based route filtering is not 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.

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

policy vpn-target

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

Configuring BGP VPNv6 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, VPNv6 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 VPNv6 address family view.

address-family vpnv6

4. Configure BGP VPNv6 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 VPNv6 route dampening is not configured.

Configuring BGP VPNv6 optimal route selection delay

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

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

route-select delay delay-value

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

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

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

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 VPNv6 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 VPNv6 route. The next hop address of a BGP VPNv6 route is a public address. This feature changes the next hop of a BGP VPNv6 route received from a peer or peer group to an IP address in the VPN instance. The outgoing label of the VPNv6 route is also changed to an invalid value. For example, the device received a VPNv6 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 VPNv6 route only when its RD is the same as a local RD.

· When advertising a BGP VPNv6 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 VPNv6 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 VPNv6 address family view.

address-family vpnv6

4. Change the next hop of a BGP VPNv6 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 VPNv6 route, and the next hop belongs to the public network.

Changing the BGP VPNv6 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 VPNv6 address family view.

address-family vpnv6

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 VPNv6 address family view.

address-family vpnv6

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

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

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.

Configuring IPv6 MPLS L3VPN FRR

About IPv6 MPLS L3VPN FRR

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

· Method 1—Execute the pic command in BGP-VPN IPv6 unicast address family view or BGP VPNv6 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 IPv6 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 IPv6 unicast address family view or BGP VPNv6 address family view might cause routing loops. Use it with caution.

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 VPNv6 route backup for a VPNv6 route and IPv6 route backup for a VPNv6 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 VPNv6 route backup for an IPv6 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.

mpls bfd dest-addr mask-length [ nexthop nexthop-address [ discriminator local local-id remote remote-id ] ] [ template template-name ]

¡ Configure BFD to test the connectivity of the MPLS TE tunnel for the tunnel interface.

interface tunnel number mode mpls-te

mpls bfd [ discriminator local local-id remote remote-id ] [ 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 VPNv6 route backup for a VPNv6 route and IPv6 route backup for a VPNv6 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 ipv6 fast-reroute backup-nexthop ipv6-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 VPNv6 route backup an IPv6 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 IPv6 unicast address family view.

address-family ipv6 [ 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 ipv6 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 IPv6 unicast address family or BGP VPNv6 address family

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 VPNv6 route backup for a VPNv6 route and IPv6 route backup for a VPNv6 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 VPNv6 route backup for an IPv6 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.

mpls bfd dest-addr mask-length [ nexthop nexthop-address [ discriminator local local-id remote remote-id ] ] [ template template-name ]

¡ Use BFD to test the connectivity of the MPLS TE tunnel for the tunnel interface.

interface tunnel number mode mpls-te

mpls bfd [ discriminator local local-id remote remote-id ] [ 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 VPNv6 route backup for a VPNv6 route and IPv6 route backup for a VPNv6 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 VPNv6 route backup an IPv6 route.

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

6. Enter BGP-VPN IPv6 unicast address family view or BGP VPNv6 address family view.

¡ Enter BGP-VPN IPv6 unicast address family view.

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

¡ Enter BGP VPNv6 address family view.

address-family vpnv6

7. Enable FRR for the address family.

pic

By default, FRR is disabled.

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

Configuring an OSPFv3 sham link

Prerequisites

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

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

· Configure OSPFv3 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, the interface is not associated with any VPN instances and belongs to the public network.

4. Configure an IPv6 address for the loopback interface.

See Layer 3—IP Services Configuration Guide.

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

5. Enter BGP instance view.

bgp as-number [ instance instance-name ]

6. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

7. Enter BGP-VPN IPv6 unicast address family view.

address-family ipv6 [ unicast ]

8. Redistribute direct routes into BGP (including the loopback interface address).

import-route direct

By default, no direct routes are redistributed into BGP.

Creating a sham link

1. Enter system view.

system-view

2. Enter OSPFv3 view.

ospfv3 [ process-id | vpn-instance vpn-instance-name ] *

3. Enter OSPFv3 area view.

area area-id

4. Configure an OSPFv3 sham link.

sham-link source-ipv6-address destination-ipv6-address [ cost cost-value | dead dead-interval | hello hello-interval | instance instance-id | { hmac-sha-256 | hmac-sm3 } key-id { cipher | plain } string | retransmit retrans-interval | trans-delay delay ] *

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.

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 { group-name | ipv6-address [ prefix-length ] } substitute-as

By default, BGP AS number substitution is disabled.

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

address-family ipv6 [ unicast ]

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

peer { group-name | ipv6-address [ prefix-length ] } soo site-of-origin

By default, the SoO attribute is not configured.

Configuring the AIGP attribute

About this task

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 execute only the peer aigp command. To enable the router to advertise the AIGP attribute, you must execute 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 VPNv6 address family view.

address-family vpnv6

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

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

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

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

By default, the maximum number of Add-Path optimal routes that can be advertised to a peer or peer group is 1.

6. Set the maximum total number of Add-Path optimal routes that can be advertised to all peers.

additional-paths select-best best-number

By default, the maximum total number of Add-Path optimal routes that can be advertised to all peers is 1.

Enabling independent routing tables for BGP VPNv6 routes and BGP-VPN instance routes

About this task

After the undo policy vpn-target command is executed, VPNv6 routes without matching route targets of the local VPN instance can be received. If the VPNv6 routes have the same RD as the local VPN instance, these routes can be selected in the BGP VPNv6 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 VPNv6 routing table. Therefore, if a route without matching route targets is selected as the only optimal route in the BGP VPNv6 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 (the routing-table independent enable command) to resolve this issue. After this feature is enabled, only BGP VPNv6 optimal routes with matching route targets of a VPN instance can be added to the corresponding BGP-VPN instance routing table. These routes can participate in optimal route selection together with other routes in the BGP-VPN instance routing table and the selection result is independent of that in the BGP VPNv6 routing table. This mechanism allows the BGP-VPN instance routing table to contain only the BGP routes with matching route targets of the corresponding VPN instance. So the optimal routes selected in the BGP-VPN instance routing table can always be added to the VPN instance IP routing table.

For example, a PE has learned two routes with the same prefix (2001::1/64) and different next hops through BGP VPNv6 sessions.

<Sysname> display bgp routing-table vpnv6

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external,

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Total number of VPN routes: 3

Total number of routes from all PEs: 2

Route distinguisher: 10:1(vpn1)

Total number of routes: 2

* >i Network : 2001:: PrefixLen : 64

NextHop : 1::1 LocPrf : 100

PrefVal : 0 OutLabel : 24127

MED : 0

Path/Ogn: i

* i Network : 2001:: PrefixLen : 64

NextHop : 3::3 LocPrf : 100

PrefVal : 0 OutLabel : 24255

MED : 0

Path/Ogn: i

Route distinguisher: 20:1

Total number of routes: 1

* >i Network : 2001:: PrefixLen : 64

NextHop : 3::3 LocPrf : 100

PrefVal : 0 OutLabel : 24255

MED : 0

Path/Ogn: i

NOTE:

In the BGP VPNv6 routing table, route entries are listed by RD. In the previous output, the BGP VPNv6 routing table contains two route lists, one for RD 10:1 and the other for RD 20:1.

The route with next hop address 3::3 has matching route target values of VPN instance vpn1, while the route with next hop address 1::1 does not. The route with next hop 3::3 is added to the BGP-VPN instance routing table of vpn1. The BGP VPNv6 of RD 10:1 and the BGP-VPN instance share the same route entries, so the BGP VPNv6 routing table for RD 10:1 also contains the route with next hop 3::3. In the BGP VPNv6 routing table for RD 10:1, the route with next hop 3::3 and the route with next hop 1::1 participate in optimal route selection and the route with next hop 1::1 is selected as the optimal route. However, the route target attribute of the route with next hop 1::1 does not match that of vpn1, so this route is not available in the BGP-VPN instance routing table of vpn1. As a result, there is no optimal route destined for 2001::1/64 in the BGP-VPN instance routing table of vpn1.

<Sysname> display bgp routing-table ipv6 vpn-instance vpn1

Total number of routes: 1

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external,

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

* i Network : 2001:: PrefixLen : 64

NextHop : 3::3 LocPrf : 100

PrefVal : 0 OutLabel : 24255

MED : 0

Path/Ogn: i

After this feature is configured, the BGP VPNv6 routing table and the BGP-VPN instance routing table no longer share route entries. The BGP VPNv6 routing table is as follows:

<Sysname> display bgp routing-table vpnv6

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external,

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

Total number of VPN routes: 3

Total number of routes from all PEs: 2

Route distinguisher: 10:1

Total number of routes: 1

* >i Network : 2001:: PrefixLen : 64

NextHop : 1::1 LocPrf : 100

PrefVal : 0 OutLabel : 24127

MED : 0

Path/Ogn: i

Route distinguisher: 10:1(vpn1)

Total number of routes: 1

* >i Network : 2001:: PrefixLen : 64

NextHop : 3::3 LocPrf : 100

PrefVal : 0 OutLabel : 24127

MED : 0

Path/Ogn: i

Route distinguisher: 20:1

Total number of routes: 1

* >i Network : 2001:: PrefixLen : 64

NextHop : 3::3 LocPrf : 100

PrefVal : 0 OutLabel : 24255

MED : 0

Path/Ogn: i

The route with next hop 1::1 is selected as the optimal route for RD 10:1. However, the route target attribute of the route with next hop 1::1 does not match that of vpn1, so this route cannot be added to the BGP-VPN instance routing table of vpn1.

The route with next hop 3::3 is selected as the optimal route for RD 20:1, and the route target attribute of the route matches that of vpn1. So this route can be added to the BGP-VPN instance routing table of vpn1 and selected as an optimal route and thus added to the IP routing table of vpn1.

<Sysname> display bgp routing-table ipv6 vpn-instance vpn1

Total number of routes: 1

BGP local router ID is 2.2.2.2

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external,

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

* >i Network : 2001:: PrefixLen : 64

NextHop : 3::3 LocPrf : 100

PrefVal : 0 OutLabel : 24255

MED : 0

Path/Ogn: i

IP prefix routes can be added to a BGP-VPN instance routing table. When the optimal route for an IP prefix in the VPNv6 address family does not match the route targets of the local VPN instance, this feature also can add the route with the same IP prefix learned from the BGP EVPN address family to the BGP-VPN instance routing table. The IP prefix advertisement route added to the BGP-VPN instance routing table can be selected as an optimal route and added to the IP routing table of the VPN instance.

This feature also provides the following function:

· Before this feature is enabled, the peer re-originated command cannot modify the route information for received BGP VPNv6 routes that have the same RD as the local VPN instance.

· After this feature is enabled, the peer re-originated command can modify the route information for all received BGP VPNv6 routes.

Restrictions and guidelines

The bestroute same-rd command and the routing-table independent enable command can implement similar functions. The differences include the following:

· The bestroute same-rd command ignores the routes that do not have matching route targets of the local VPN instance, and enables BGP to add other routes that have the same IP prefix and matching route targets (if any in the BGP VPNv6 routing table) to the IP routing table of the VPN instance.

· The routing-table independent enable command uses the routes learned from other BGP routing tables to implement the function of adding BGP routes to the IP routing table of the VPN instance. In the BGP VPNv6 routing table for an RD, the route without matching route targets still cannot be added to the IP routing table of the VPN instance. This feature applies to the following scenarios:

¡ There are optimal routes with the same IP prefix in the BGP VPNv6 route entries for different RDs.

¡ An IP prefix advertisement route in the BGP EVPN routing table and a VPNv6 route in the BGP VPNv6 routing table have the same IP prefix.

¡ The peer re-originated command is configured to modify the route information for received BGP VPNv6 routes that have the same RD as the local VPN instance.

After the routing-table independent enable command is executed, the bestroute same-rd command no longer takes effect.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enabling independent routing tables for BGP VPNv6 routes and BGP-VPN instance routes.

routing-table independent enable

By default, BGP VPNv6 routes and BGP-VPN routes share the same route entries. The BGP routes in BGP-VPN instance routing table can also be displayed in the BGP VPNv6 routing table. For the same VPN instance, it has the same optimal route selection result in BGP VPNv6 routing table and in the BGP-VPN instance routing table.

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.

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 3::3, which are 3::3 <RT: 10:1> and 3::3 <RT: 20:1>, and 3::3 <RT: 20:1>is the optimal route. After you configure this feature, BGP will add 3::3 <RT: 10:1> to the IP routing table of VPN instance vpna, because this route has the same import target as the VPN instance.

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 IPv6 unicast address family and BGP VPNv6 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.

For example, the device learns the route with IP prefix 3::3/128 from both the BGP VPNv6 address family and BGP EVPN address family. Therefore, there will be two routes to destination address 3::3/128 in the BGP routing table of the BGP VPNv6 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 VPNv6 peers, because it was learned from the BGP EVPN address family. As a result, network nodes deployed with only BGP VPNv6 cannot obtain the route with IP prefix 3::3/128. After you configure this feature, the device will advertise the route with IP prefix 3::3/128 learned from the BGP VPNv6 address family to BGP VPNv6 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 VPNv6 routes reflected by the RR usually include the VPN routes from all BGP-VPN instances on the route originating device. 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 VPNv6 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

NOTE:

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 are set by using the vpn-prefix-quota command.

· The maximum number of routes supported by a BGP-VPN instance, which is set by using the route-limit command.

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 VPN Prefix ORF entries to the peer/peer group specified by the peer capability-advertise orf vpn-prefix command.

TIP:

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 VPNv6 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 VPNv6 routes that match the VPN Prefix ORF entry to the local device.

VPN Prefix ORF networking example

As shown in Figure 29, 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 29 VPN Prefix ORF application network diagram

PE 3 advertises routes of VPN1 through BGP VPNv6. 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 the 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 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:

¡ The RD carried by the routes is RD31.

¡ The next hop address of the routes is the address of PE 3.

Figure 30 VPN Prefix ORF taking effect

· On 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.

Configure 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 IPv6 unicast address family view.

address-family ipv6 [ 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 the 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.

Enabling 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 VPNv6 address family view.

address-family vpnv6

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 IPv6 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 IPv6 address family view.

address-family ipv6

6. Configure a route target for the IPv6 address family view of the public instance.

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

By default, no route target is configured for the IPv6 address family view 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 IPv6 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 network instance.

The configuration in public instance IPv6 address family view takes precedence over the configuration in public instance view.

Configuring route replication for public and VPN instances

About this task

In an IPv6 BGP/IPv6 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 network or other VPN instances.

· Enables the public network to communicate with a VPN instance by replicating routes from the VPN instance.

VLINK direct routes are generated based on ND 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 IPv6 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 IPv6 FIB.

Configuring a VPN instance to replicate routes from the public network 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 IPv6 address family view.

address-family ipv6

4. Replicate routes from the public network or other VPN instances.

route-replicate from { public | vpn-instance vpn-instance-name } protocol { bgp4+ as-number | direct | static | unr | vlink-direct | { isisv6 | ospfv3 } process-id } [ advertise ] [ route-policy route-policy-name ]

By default, a VPN instance cannot replicate routes from the public network or other VPN instances.

Replicating routes from a VPN instance to the public network

1. Enter system view.

system-view

2. Enter public instance view.

ip public-instance

3. Enter public instance IPv6 address family view.

address-family ipv6

4. Replicate routes from a VPN instance to the public network.

route-replicate from vpn-instance vpn-instance-name protocol { bgp4+ as-number | direct | static | unr | vlink-direct | { isisv6 | ospfv3 } process-id } [ advertise ] [ route-policy route-policy-name ]

By default, the public network cannot replicate routes from VPN instances.

Configuring BGP route replication between public and VPN instances

About this task

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 IPv6 route replication between the public instance and a VPN instance, make sure the VPN instance and the BGP IPv6 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 ECMP VPN route redistribution

About this task

Restrictions and guidelines

· The configuration in BGP instance view takes effect on all address families.

· The configuration in BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view takes effect only on the address family.

· The configuration in BGP IPv6 unicast address family view or BGP-VPN IPv6 unicast address family view takes precedence over that in BGP instance view.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view, BGP IPv6 unicast address family view, or BGP-VPN IPv6 unicast address family view.

¡ Enter BGP instance view.

bgp as-number [ instance instance-name ]

¡ Execute the following commands in sequence to enter BGP IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-VPN IPv6 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv6 [ unicast ]

¡ Execute the following commands in sequence to enter BGP VPNv6 address family view:

bgp as-number [ instance instance-name ]

address-family vpnv6

3. Enable ECMP VPN route redistribution.

vpn-route cross multipath

By default, ECMP VPN route redistribution is disabled. If multiple routes have the same prefix and RD, a VPN instance redistributes only the optimal route into its routing table.

In BGP IPv6 unicast address family view, this command redistributes ECMP routes to the routing table of the public instance. For more information about the public instance, see EVPN Configuration Guide.

Enabling prioritized withdrawal of specific routes

About this task

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

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 logging for BGP route flapping

About this task

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

4. 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 IPv6 MPLS L3VPN

Resetting BGP connections

Execute the following commands in user view to soft reset or reset BGP connections:

Task	Command
Manually soft reset BGP sessions for VPNv6 address family.	refresh bgp [ instance instance-name ] { ipv4-address [ mask-length ] \| all \| external \| group group-name \| internal } { export \| import } vpnv6
Reset BGP sessions for VPNv6 address family.	reset bgp [ instance instance-name ] { as-number \| ipv4-address [ mask-length ] \| all \| external \| internal \| group group-name } vpnv6

‌

For more information about the refresh bgp vpnv6 and reset bgp vpnv6 commands, see Layer 3—IP Routing Command Reference.

Displaying and maintaining IPv6 MPLS L3VPN information

Execute the display commands in any view and reset commands in user view to display and maintain IPv6 MPLS L3VPN:

Task	Command
Display BGP VPNv6 peer group information.	display bgp [ instance instance-name ] group vpnv6 [ group-name group-name ]
Display BGP VPNv6 peer information.	display bgp [ instance instance-name ] peer vpnv6 [ ipv4-address mask-length \| { ipv4-address \| group-name group-name } log-info \| [ ipv4-address ] verbose ]
Display BGP VPNv6 routes.	display bgp [ instance instance-name ] routing-table vpnv6 [ [ route-distinguisher route-distinguisher ] [ ipv6-address prefix-length [ 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 } ] \| peer { ipv4-address \| ipv6-address } { advertised-routes \| received-routes } [ ipv6-address prefix-length [ verbose ] \| statistics ] \| statistics ] display bgp [ instance instance-name ] routing-table vpnv6 [ route-distinguisher route-distinguisher ] [ ipv6-address prefix-length ] [ statistics ] { large-community [ aa:bb:cc&<1-32> ] \| large-community-list { basic-large-comm-list-number \| adv-large-comm-list-number \| large-comm-list-name } } [ whole-match ] display bgp [ instance instance-name ] routing-table vpnv6 [ route-distinguisher route-distinguisher ] [ ipv6-address prefix-length ] statistics source { evpn-remote-import \| local \| local-import \| remote-import } display bgp [ instance instance-name ] routing-table vpnv6 [ same-rd-selected ] display bgp [ instance instance-name ] routing-table vpnv6 peer { ipv4-address \| ipv6-address } { accepted-routes \| not-accepted-routes } display bgp [ instance instance-name ] routing-table vpnv6 [ route-distinguisher route-distinguisher ] time-range min-time max-time
Display BGP VPNv6 route dampening parameters.	display bgp [ instance instance-name ] dampening parameter vpnv6
Display information about dampened BGP VPNv6 routes.	display bgp [ instance instance-name ] routing-table dampened vpnv6
Display BGP VPNv6 route flapping information.	display bgp [ instance instance-name ] routing-table flap-info vpnv6 [ ipv6-address prefix-length \| as-path-acl { as-path-acl-number \| as-path-acl-name } ]
Display BGP VPNv6 route source information.	display bgp [ instance instance-name ] routing-table vpnv6 source-type
Display incoming labels for all BGP VPNv6 routes.	display bgp [ instance instance-name ] routing-table vpnv6 inlabel
Display outgoing labels for all BGP VPNv6 routes.	display bgp [ instance instance-name ] routing-table vpnv6 outlabel
Display BGP VPNv6 address family update group information.	display bgp [ instance instance-name ] update-group vpnv6 [ ipv4-address ]
Display BGP peer and routing summary information.	display bgp [ instance instance-name ] vpnv6 summary
Display route targets sourcing from a VPN instance.	display bgp [ instance instance-name ] route-target l3vpn [ ipv6 ] [ 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 } ] evpn
Display information about a specified VPN instance or all VPN instances.	display ip vpn-instance [ instance-name vpn-instance-name \| count ]
Display IPv6 FIB information for a VPN instance.	display ipv6 fib vpn-instance vpn-instance-name [ ipv6-address [ prefix-length ] ]
Display the IPv6 routing table for a VPN instance.	display ipv6 routing-table vpn-instance vpn-instance-name [ verbose ]
Display OSPFv3 sham link information.	display ospfv3 [ process-id ] [ area area-id ] sham-link [ verbose ]
Clear BGP VPNv6 route dampening information and release dampened routes.	reset bgp [ instance instance-name ] dampening vpnv6 [ ipv6-address prefix-length ]
Clear BGP VPNv6 route flapping statistics.	reset bgp [ instance instance-name ] flap-info vpnv6 [ ipv6-address prefix-length \| as-path-acl { as-path-acl-number \| as-path-acl-name } \| peer [ ipv4-address [ mask-length ] \| peer ipv6-address [ prefix-length ] ] ]

‌

For more information about the display ipv6 routing-table, display bgp group vpnv6, display bgp peer vpnv6, and display bgp update-group vpnv6 commands, see Layer 3—IP Routing Command Reference.

IPv6 MPLS L3VPN configuration examples

Example: Configuring IPv6 MPLS L3VPNs

Network configuration

CE 1 and CE 3 belong to VPN 1. CE 2 and CE 4 belong to VPN 2.

VPN 1 uses route target attributes 111:1. VPN 2 uses route target attributes 222:2. Users of different VPNs cannot access each other.

Run EBGP between CEs and PEs to exchange VPN routing information.

PEs use OSPF to communicate with each other and use MP-IBGP to exchange VPN routing information.

Figure 31 Network diagram

‌

Table 11 Interface and IP address assignment

Device	Interface			IP address	Device		Interface	IP address
CE 1		XGE2/0/0	2001:1::1/96			P	Loop0	2.2.2.9/32
PE 1		Loop0	1.1.1.9/32				XGE2/0/3	172.1.1.2/24
		XGE2/0/0	2001:1::2/96				XGE2/0/4	172.2.1.1/24
		XGE2/0/1	2001:2::2/96			PE 2	Loop0	3.3.3.9/32
		XGE2/0/3	172.1.1.1/24				XGE2/0/0	2001:3::2/96
CE 2		XGE2/0/0	2001:2::1/96				XGE2/0/1	2001:4::2/96
CE 3		XGE2/0/0	2001:3::1/96				XGE2/0/3	172.2.1.2/24
CE 4		XGE2/0/0	2001:4::1/96

‌

Procedure

1. Configure OSPF on the MPLS backbone to ensure IP connectivity among the PEs and the P router:

# Configure PE 1.

<PE1> system-view

[PE1] interface loopback 0

[PE1-LoopBack0] ip address 1.1.1.9 32

[PE1-LoopBack0] quit

[PE1] interface ten-gigabitethernet 2/0/3

[PE1-Ten-GigabitEthernet2/0/3] ip address 172.1.1.1 24

[PE1-Ten-GigabitEthernet2/0/3] quit

[PE1] ospf

[PE1-ospf-1] area 0

[PE1-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255

[PE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0

[PE1-ospf-1-area-0.0.0.0] quit

[PE1-ospf-1] quit

# Configure the P router.

<P> system-view

[P] interface loopback 0

[P-LoopBack0] ip address 2.2.2.9 32

[P-LoopBack0] quit

[P] interface ten-gigabitethernet 2/0/3

[P-Ten-GigabitEthernet2/0/3] ip address 172.1.1.2 24

[P-Ten-GigabitEthernet2/0/3] quit

[P] interface ten-gigabitethernet 2/0/4

[P-Ten-GigabitEthernet2/0/4] ip address 172.2.1.1 24

[P-Ten-GigabitEthernet2/0/4] quit

[P] ospf

[P-ospf-1] area 0

[P-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255

[P-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255

[P-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0

[P-ospf-1-area-0.0.0.0] quit

[P-ospf-1] quit

# Configure PE 2.

<PE2> system-view

[PE2] interface loopback 0

[PE2-LoopBack0] ip address 3.3.3.9 32

[PE2-LoopBack0] quit

[PE2] interface ten-gigabitethernet 2/0/3

[PE2-Ten-GigabitEthernet2/0/3] ip address 172.2.1.2 24

[PE2-Ten-GigabitEthernet2/0/3] quit

[PE2] ospf

[PE2-ospf-1] area 0

[PE2-ospf-1-area-0.0.0.0] network 172.2.1.0 0.0.0.255

[PE2-ospf-1-area-0.0.0.0] network 3.3.3.9 0.0.0.0

[PE2-ospf-1-area-0.0.0.0] quit

[PE2-ospf-1] quit

2. Configure basic MPLS and enable MPLS LDP on the MPLS backbone to establish LDP LSPs:

# Configure PE 1.

[PE1] mpls lsr-id 1.1.1.9

[PE1] mpls ldp

[PE1-ldp] quit

[PE1] interface ten-gigabitethernet 2/0/3

[PE1-Ten-GigabitEthernet2/0/3] mpls enable

[PE1-Ten-GigabitEthernet2/0/3] mpls ldp enable

[PE1-Ten-GigabitEthernet2/0/3] quit

# Configure the P router.

[P] mpls lsr-id 2.2.2.9

[P] mpls ldp

[P-ldp] quit

[P] interface ten-gigabitethernet 2/0/3

[P-Ten-GigabitEthernet2/0/3] mpls enable

[P-Ten-GigabitEthernet2/0/3] mpls ldp enable

[P-Ten-GigabitEthernet2/0/3] quit

[P] interface ten-gigabitethernet 2/0/4

[P-Ten-GigabitEthernet2/0/4] mpls enable

[P-Ten-GigabitEthernet2/0/4] mpls ldp enable

[P-Ten-GigabitEthernet2/0/4] quit

# Configure PE 2.

[PE2] mpls lsr-id 3.3.3.9

[PE2] mpls ldp

[PE2-ldp] quit

[PE2] interface ten-gigabitethernet 2/0/3

[PE2-Ten-GigabitEthernet2/0/3] mpls enable

[PE2-Ten-GigabitEthernet2/0/3] mpls ldp enable

[PE2-Ten-GigabitEthernet2/0/3] quit

3. Configure IPv6 VPN instances on the PEs to allow CE access:

# Configure PE 1.

[PE1] ip vpn-instance vpn1

[PE1-vpn-instance-vpn1] route-distinguisher 100:1

[PE1-vpn-instance-vpn1] vpn-target 111:1

[PE1-vpn-instance-vpn1] quit

[PE1] ip vpn-instance vpn2

[PE1-vpn-instance-vpn2] route-distinguisher 100:2

[PE1-vpn-instance-vpn2] vpn-target 222:2

[PE1-vpn-instance-vpn2] quit

[PE1] interface ten-gigabitethernet 2/0/0

[PE1-Ten-GigabitEthernet2/0/0] ip binding vpn-instance vpn1

[PE1-Ten-GigabitEthernet2/0/0] ipv6 address 2001:1::2 96

[PE1-Ten-GigabitEthernet2/0/0] quit

[PE1] interface ten-gigabitethernet 2/0/1

[PE1-Ten-GigabitEthernet2/0/1] ip binding vpn-instance vpn2

[PE1-Ten-GigabitEthernet2/0/1] ipv6 address 2001:2::2 96

[PE1-Ten-GigabitEthernet2/0/1] quit

# Configure PE 2.

[PE2] ip vpn-instance vpn1

[PE2-vpn-instance-vpn1] route-distinguisher 200:1

[PE2-vpn-instance-vpn1] vpn-target 111:1

[PE2-vpn-instance-vpn1] quit

[PE2] ip vpn-instance vpn2

[PE2-vpn-instance-vpn2] route-distinguisher 200:2

[PE2-vpn-instance-vpn2] vpn-target 222:2

[PE2-vpn-instance-vpn2] quit

[PE2] interface ten-gigabitethernet 2/0/0

[PE2-Ten-GigabitEthernet2/0/0] ip binding vpn-instance vpn1

[PE2-Ten-GigabitEthernet2/0/0] ipv6 address 2001:3::2 96

[PE2-Ten-GigabitEthernet2/0/0] quit

[PE2] interface ten-gigabitethernet 2/0/1

[PE2-Ten-GigabitEthernet2/0/1] ip binding vpn-instance vpn2

[PE2-Ten-GigabitEthernet2/0/1] ipv6 address 2001:4::2 96

[PE2-Ten-GigabitEthernet2/0/1] quit

# Configure IP addresses for the CEs according to Figure 31. (Details not shown.)

# Execute the display ip vpn-instance command on the PEs to display information about the VPN instances. Use the ping command on the PEs to verify that the PEs can ping their attached CEs. (Details not shown.)

4. Establish EBGP peer relationships between the PEs and CEs to allow them to exchange VPN routes:

# Configure CE 1.

<CE1> system-view

[CE1] bgp 65410

[CE1-bgp-default] peer 2001:1::2 as-number 100

[CE1-bgp-default] address-family ipv6 unicast

[CE1-bgp-default-ipv6] peer 2001:1::2 enable

[CE1-bgp-default-ipv6] import-route direct

[CE1-bgp-default-ipv6] quit

[CE1-bgp-default] quit

# Configure the other CEs (CE 2 through CE 4) in the same way that CE 1 is configured. (Details not shown.)

# Configure PE 1.

[PE1] bgp 100

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] peer 2001:1::1 as-number 65410

[PE1-bgp-default-vpn1] address-family ipv6 unicast

[PE1-bgp-default-ipv6-vpn1] peer 2001:1::1 enable

[PE1-bgp-default-ipv6-vpn1] quit

[PE1-bgp-default-vpn1] quit

[PE1-bgp-default] ip vpn-instance vpn2

[PE1-bgp-default-vpn2] peer 2001:2::1 as-number 65420

[PE1-bgp-default-vpn2] address-family ipv6 unicast

[PE1-bgp-default-ipv6-vpn2] peer 2001:2::1 enable

[PE1-bgp-default-ipv6-vpn2] quit

[PE1-bgp-default-vpn2] quit

[PE1-bgp-default] quit

# Configure PE 2 in the same way that PE 1 is configured. (Details not shown.)

# Execute the display bgp peer ipv6 vpn-instance command on the PEs to verify that a BGP peer relationship in Established state has been established between a PE and a CE. (Details not shown.)

5. Configure an MP-IBGP peer relationship between the PEs:

# Configure PE 1.

[PE1] bgp 100

[PE1-bgp-default] peer 3.3.3.9 as-number 100

[PE1-bgp-default] peer 3.3.3.9 connect-interface loopback 0

[PE1-bgp-default] address-family vpnv6

[PE1-bgp-default-vpnv6] peer 3.3.3.9 enable

[PE1-bgp-default-vpnv6] quit

[PE1-bgp-default] quit

# Configure PE 2.

[PE2] bgp 100

[PE2-bgp-default] peer 1.1.1.9 as-number 100

[PE2-bgp-default] peer 1.1.1.9 connect-interface loopback 0

[PE2-bgp-default] address-family vpnv6

[PE2-bgp-default-vpnv6] peer 1.1.1.9 enable

[PE2-bgp-default-vpnv6] quit

[PE2-bgp-default] quit

# Execute the display bgp peer vpnv6 command on the PEs to verify that a BGP peer relationship in Established state has been established between the PEs. (Details not shown.)

Verifying the configuration

# Execute the display ipv6 routing-table vpn-instance command on the PEs.

[PE1] display ipv6 routing-table vpn-instance vpn1

Destinations : 5 Routes : 5

Destination: ::1/128 Protocol : Direct

NextHop : ::1 Preference: 0

Interface : InLoop0 Cost : 0

Destination: 2001:1::/96 Protocol : Direct

NextHop : :: Preference: 0

Interface : XGE2/0/0 Cost : 0

Destination: 2001:1::2/128 Protocol : Direct

NextHop : ::1 Preference: 0

Interface : InLoop0 Cost : 0

Destination: 2001:3::/96 Protocol : BGP4+

NextHop : ::FFFF:3.3.3.9 Preference: 255

Interface : XGE2/0/3 Cost : 0

Destination: FE80::/10 Protocol : Direct

NextHop : :: Preference: 0

Interface : NULL0 Cost : 0

[PE1] display ipv6 routing-table vpn-instance vpn2

Destinations : 5 Routes : 5

Destination: ::1/128 Protocol : Direct

NextHop : ::1 Preference: 0

Interface : InLoop0 Cost : 0

Destination: 2001:2::/96 Protocol : Direct

NextHop : :: Preference: 0

Interface : XGE2/0/1 Cost : 0

Destination: 2001:2::2/128 Protocol : Direct

NextHop : ::1 Preference: 0

Interface : InLoop0 Cost : 0

Destination: 2001:4::/96 Protocol : BGP4+

NextHop : ::FFFF:3.3.3.9 Preference: 255

Interface : XGE2/0/3 Cost : 0

Destination: FE80::/10 Protocol : Direct

NextHop : :: Preference: 0

Interface : NULL0 Cost : 0

The output shows that PE 1 has routes to the remote CEs. Output on PE 2 is similar.

# Verify that CEs of the same VPN can ping each other, whereas those of different VPNs cannot. For example, CE 1 can ping CE 3 (2001:3::1), but cannot ping CE 4 (2001:4::1). (Details not shown.)

Example: Configuring BGP AS number substitution

Network configuration

As shown in Figure 32, CE 1 and CE 2 belong to VPN 1, and are connected to PE 1 and PE 2. The two CEs have the same AS number, 600. Configure BGP AS number substitution on the PEs to avoid route loss.

Figure 32 Network diagram

‌

Table 12 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
CE 1	XGE2/0/0	10:1::2/96	P	Loop0	2.2.2.9/32
	XGE2/0/1	100::1/96		XGE2/0/0	20.1.1.2/24
PE 1	Loop0	10.1.1.1/32		XGE2/0/1	30.1.1.1/24
	XGE2/0/0	10:1::1/96	PE 2	Loop0	10.1.1.2/32
	XGE2/0/1	20.1.1.1/24		XGE2/0/0	10:2::1/96
CE 2	XGE2/0/0	10:2::2/96		XGE2/0/1	30.1.1.2/24
	XGE2/0/1	200::1/96

‌

Procedure

1. Configure basic IPv6 MPLS L3VPN:

¡ Configure OSPF on the MPLS backbone to allow the PEs and P device to learn the routes of the loopback interfaces from each other.

¡ Configure basic MPLS and MPLS LDP on the MPLS backbone to establish LDP LSPs.

¡ Establish an MP-IBGP peer relationship between the PEs to advertise VPN IPv6 routes.

¡ Configure the VPN instance of VPN 1 on PE 1 to allow CE 1 to access the network.

¡ Configure the VPN instance of VPN 1 on PE 2 to allow CE 2 to access the network.

¡ Configure BGP as the PE-CE routing protocol, and redistribute routes of the CEs into the PEs.

For more information about basic IPv6 MPLS L3VPN configurations, see "Example: Configuring IPv6 MPLS L3VPNs."

# Execute the display ipv6 routing-table command on CE 2 to verify that CE 2 has not learned the route to the VPN (100::/96) behind CE 1.

<CE2> display ipv6 routing-table

Destinations : 5 Routes : 5

Destination: ::1/128 Protocol : Direct

NextHop : ::1 Preference: 0

Interface : InLoop0 Cost : 0

Destination: 10:2::/96 Protocol : Direct

NextHop : :: Preference: 0

Interface : XGE2/0/0 Cost : 0

Destination: 10:2::2/128 Protocol : Direct

NextHop : ::1 Preference: 0

Interface : InLoop0 Cost : 0

Destination: 200::/96 Protocol : Static

NextHop : :: Preference: 60

Interface : NULL0 Cost : 0

Destination: FE80::/10 Protocol : Direct

NextHop : :: Preference: 0

Interface : NULL0 Cost : 0

# Execute the display ipv6 routing-table command on CE 1 to verify that CE 1 has not learned the route to the VPN behind CE 2. (Details not shown.)

# Execute the display ipv6 routing-table vpn-instance command on the PEs. The output shows the route to the VPN behind the peer CE. This example uses PE 2.

<PE2> display ipv6 routing-table vpn-instance vpn1

Destinations : 6 Routes : 6

Destination: ::1/128 Protocol : Direct

NextHop : ::1 Preference: 0

Interface : InLoop0 Cost : 0

Destination: 10:2::/96 Protocol : Direct

NextHop : :: Preference: 0

Interface : XGE2/0/0 Cost : 0

Destination: 10:2::1/128 Protocol : Direct

NextHop : ::1 Preference: 0

Interface : InLoop0 Cost : 0

Destination: 100::/96 Protocol : BGP4+

NextHop : ::FFFF:10.1.1.1 Preference: 255

Interface : XGE2/0/1 Cost : 0

Destination: 200::/96 Protocol : BGP4+

NextHop : 10:2::2 Preference: 255

Interface : XGE2/0/0 Cost : 0

Destination: FE80::/10 Protocol : Direct

NextHop : :: Preference: 0

Interface : NULL0 Cost : 0

# Enable BGP update packet debugging on PE 2. The output shows that PE 2 has advertised the route for 100::/96, and the AS_PATH is 100 600.

<PE2> terminal monitor

<PE2> terminal logging level 7

<PE2> debugging bgp update vpn-instance vpn1 10:2::2 ipv6

<PE2> refresh bgp all export ipv6 vpn-instance vpn1

*Jun 13 16:12:52:096 2012 PE2 BGP/7/DEBUG:

BGP_IPV6.vpn1: Send UPDATE to update-group 0 for following destinations:

Origin : Incomplete

AS path : 100 600

Next hop : ::FFFF:10.1.1.1

100::/96,

*Jun 13 16:12:53:024 2012 PE2 BGP/7/DEBUG:

BGP.vpn1: Send UPDATE MSG to peer 10:2::2(IPv6-UNC) NextHop: 10:2::1.

# Execute the display bgp routing-table ipv6 peer received-routes command on CE 2 to verify that CE 2 has not received the route to 100::/96.

<CE2> display bgp routing-table ipv6 peer 10:2::1 received-routes

Total number of routes: 0

2. Configure BGP AS number substitution:

# Configure BGP AS number substitution on PE 1.

<PE1> system-view

[PE1] bgp 100

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] peer 10:1::2 substitute-as

[PE1-bgp-default-vpn1] quit

[PE1-bgp-default] quit

# Configure BGP AS number substitution on PE 2.

<PE2> system-view

[PE2] bgp 100

[PE2-bgp-default] ip vpn-instance vpn1

[PE2-bgp-default-vpn1] peer 10:2::2 substitute-as

[PE2-bgp-default-vpn1] quit

[PE2-bgp-default] quit

Verifying the configuration

# The output shows that among the routes advertised by PE 2 to CE 2, the AS_PATH of 100::/96 has changed from 100 600 to 100 100.

*Jun 27 18:07:34:420 2013 PE2 BGP/7/DEBUG:

BGP_IPV6.vpn1: Send UPDATE to peer 10:2::2 for following destinations:

Origin : Incomplete

AS path : 100 100

Next hop : 10:2::1

100::/96,

# Display again the routing information that CE 2 has received, and the routing table. The output shows that CE 2 has learned the route 100::/96.

<CE2> display bgp routing-table ipv6 peer 10:2::1 received-routes

Total number of routes: 1

BGP local router ID is 12.1.1.3

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

* >e Network : 100:: PrefixLen : 96

NextHop : 10:2::1 LocPrf :

PrefVal : 0 OutLabel : NULL

MED :

Path/Ogn: 100 100?

<CE2> display ipv6 routing-table

Destinations : 6 Routes : 6

Destination: ::1/128 Protocol : Direct

NextHop : ::1 Preference: 0

Interface : InLoop0 Cost : 0

Destination: 10:2::/96 Protocol : Direct

NextHop : :: Preference: 0

Interface : XGE2/0/0 Cost : 0

Destination: 10:2::2/128 Protocol : Direct

NextHop : ::1 Preference: 0

Interface : InLoop0 Cost : 0

Destination: 100::/96 Protocol : BGP4+

NextHop : 10:2::1 Preference: 255

Interface : XGE2/0/0 Cost : 0

Destination: 200::/96 Protocol : Static

NextHop : :: Preference: 60

Interface : NULL0 Cost : 0

Destination: FE80::/10 Protocol : Direct

NextHop : :: Preference: 0

Interface : NULL0 Cost : 0

# Verify that Ten-GigabitEthernet 2/0/1 of CE 1 and Ten-GigabitEthernet 2/0/1 of CE 2 can ping each other. (Details not shown.)

Example: Configuring BGP AS number substitution and SoO attribute

Network configuration

CE 1, CE 2, and CE 3 belong to VPN 1, and are connected to PE1, PE 2, and PE 3. CE 1 and CE 2 reside in the same site. CE1, CE2, and CE 3 all use AS number 600.

To avoid route loss, configure BGP AS number substitution on PEs.

To avoid routing loops, configure the same SoO attribute on PE 1 and PE 2 for CE 1 and CE 2.

Figure 33 Network diagram

‌

Table 13 Interface and IP address assignment

Device	Interface	IP address	Device	Interface	IP address
CE 1	Loop0	100::1/96	CE 3	Loop0	200::1/96
	XGE2/0/0	10:1::1/96		XGE2/0/0	10:3::1/96
CE 2	XGE2/0/0	10:2::1/96	PE 2	Loop0	2.2.2.9/32
PE 1	Loop0	1.1.1.9/32		XGE2/0/0	10:2::2/96
	XGE2/0/0	10:1::2/96		XGE2/0/1	40.1.1.1/24
	XGE2/0/1	20.1.1.1/24		XGE2/0/2	20.1.1.2/24
	XGE2/0/2	30.1.1.1/24	P	Loop0	3.3.3.9/32
PE 3	Loop0	4.4.4.9/32		XGE2/0/0	30.1.1.2/24
	XGE2/0/0	10:3::2/96		XGE2/0/1	40.1.1.2/24
	XGE2/0/1	50.1.1.2/24		XGE2/0/2	50.1.1.1/24

‌

Procedure

1. Configure basic IPv6 MPLS L3VPN:

¡ Configure OSPF on the MPLS backbone to allow the PEs and P device to learn the routes of the loopback interfaces from each other.

¡ Configure basic MPLS and MPLS LDP on the MPLS backbone to establish LDP LSPs.

¡ Establish an MP-IBGP peer relationship between the PEs to advertise VPN IPv6 routes.

¡ Configure the VPN instance of VPN 1 on PE 1 to allow CE 1 to access the network.

¡ Configure the VPN instance of VPN 1 on PE 2 to allow CE 2 to access the network.

¡ Configure the VPN instance of VPN 1 on PE 3 to allow CE 3 to access the network.

¡ Configure BGP as the PE-CE routing protocol, and redistribute routes of the CEs into the PEs.

For more information about basic MPLS L3VPN configurations, see "Example: Configuring IPv6 MPLS L3VPNs."

2. Configure BGP AS number substitution:

# Configure BGP AS number substitution on PE 1, PE 2, and PE 3. For more information about the configuration, see "Example: Configuring BGP AS number substitution."

# Display routing information on CE 2. The output shows that CE 2 has learned the route 100::/96 from CE 1. A routing loop has occurred because CE 1 and CE 2 reside in the same site.

<CE2> display bgp routing-table ipv6 peer 10:2::2 received-routes

Total number of routes: 2

BGP local router ID is 12.1.1.3

Status codes: * - valid, > - best, d - dampened, h - history,

s - suppressed, S - stale, i - internal, e - external

a - additional-path

Origin: i - IGP, e - EGP, ? - incomplete

* >e Network : 100:: PrefixLen : 96

NextHop : 10:2::2 LocPrf :

PrefVal : 0 OutLabel : NULL

MED :

Path/Ogn: 100 100?

* >e Network : 200:: PrefixLen : 96

NextHop : 10:2::2 LocPrf :

PrefVal : 0 OutLabel : NULL

MED :

Path/Ogn: 100 100?

3. Configure BGP SoO attribute:

# On PE 1, configure the SoO attribute as 1:100 for CE 1.

<PE1> system-view

[PE1] bgp 100

[PE1-bgp-default] ip vpn-instance vpn1

[PE1-bgp-default-vpn1] address-family ipv6

[PE1-bgp-default-ipv6-vpn1] peer 10:1::1 soo 1:100

# On PE 2, configure the SoO attribute as 1:100 for CE 2.

<PE2> system-view

[PE2] bgp 100

[PE2-bgp-default] ip vpn-instance vpn1

[PE2-bgp-default-vpn1] address-family ipv6

[PE2-bgp-default-ipv6-vpn1] peer 10:2::1 soo 1:100

Verifying the configuration

# PE 2 does not advertise routes received from CE 1 to CE 2 because the same SoO attribute has been configured. Display the routing table of CE 2. The output shows that the route 100::/96 has been removed.

<CE2> display ipv6 routing-table

Destinations : 4 Routes : 4

Destination: ::1/128 Protocol : Direct

NextHop : ::1 Preference: 0

Interface : InLoop0 Cost : 0

Destination: 10:2::/96 Protocol : Direct

NextHop : :: Preference: 0

Interface : XGE2/0/0 Cost : 0

Destination: 10:2::1/128 Protocol : Direct

NextHop : ::1 Preference: 0

Interface : InLoop0 Cost : 0

Destination: 200::/96 Protocol : Static

NextHop : :: Preference: 60

Interface : NULL0 Cost : 0

07-MPLS Configuration Guide

About MPLS L3VPN

MPLS L3VPN concepts

Site

VPN instance

VPN-IPv4 address

Route target attributes

MP-BGP

MPLS L3VPN route advertisement

Route advertisement from the local CE to the ingress PE

Route advertisement from the ingress PE to the egress PE

Route advertisement from the egress PE to the remote CE

Basic VPN networking scheme

HoVPN

OSPF VPN extension

OSPF for VPNs on a PE

OSPF area configuration between a PE and a CE

BGP/OSPF interaction

Routing loop avoidance

BGP AS number substitution and SoO attribute

VPNv4 route backup for a VPNv4 route

VPNv4 route backup for an IPv4 route

IPv4 route backup for a VPNv4 route

ECMP VPN route redistribution

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 OSPF between a PE and a CE

About this task

Procedure

About this task

Procedure

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

Configuring the PE

Configuring the CE

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

Configuring the PE

Configuring the CE

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

Configuring HoVPN

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Configuring an OSPF sham link

Redistributing the loopback interface address

Creating a sham link

Configuring BGP AS number substitution and SoO attribute

About this task