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 attribute

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

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

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

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

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

· 16-bit AS number:32-bit user-defined number. For example, 100:1.

· 32-bit IPv4 address:16-bit user-defined number. For example, 172.1.1.1:1.

· 32-bit AS number:16-bit user-defined number, where the minimum value of the AS number is 65536. For example, 65536:1.

MP-BGP

MP-BGP supports multiple address families, for example, 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.

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

‌

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

Figure 6 Network diagram for routing loop avoidance

‌

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

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

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

· Route tag (for Type 5 or 7 LSAs)—The two PEs 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 7 Application of BGP AS number substitution and SoO attribute

‌

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

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

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

‌

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

‌

As shown in Figure 11, 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. (Optional.) Configuring MPLS L3VPN FRR

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

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

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

5. (Optional.) Maintaining MPLS L3VPN networks

¡ Enabling SNMP notifications for MPLS L3VPN

¡ Enabling logging for BGP route flapping

Prerequisites for MPLS L3VPN

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

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

2. Configure basic MPLS for the MPLS backbone.

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

Configuring VPN instances

All VPN instance configurations are performed on PEs.

Creating a VPN instance

About this task

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

Restrictions and guidelines

If you configure an RD for a VPN instance, all address families in the VPN instance must use the same RD as the VPN instance.

If you do not configure an RD for a VPN instance, address families in the VPN instance can use different RDs.

To configure an RD for a VPN instance, make sure either of the following conditions exists:

· No RDs have been configured for address families in the VPN instance.

In this case, the RD of the VPN instance will be synchronized to all address families in the VPN instance.

· All address families in the VPN instance use the same RD.

In this case, you must configure the same RD as the address families for the VPN instance.

When you remove the RD from an address family, the RD will also be removed from the VPN instance of the address family.

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 ]

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. Create an OSPF area and enter area view.

area area-id

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

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.

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.

¡ 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

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

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

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

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

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.

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

This feature applies only to IBGP routes.

If an IBGP 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.

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.

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

About this task

The VPNv4 address family supports both IPv4 and IPv6 peers, so the device might learn routes with the same prefix from the IPv4 and IPv6 peers. You can perform this task to control the route priorities.

When an MPLS L3VPN supports both IPv4 and IPv6, the VPNv4 address family might learn routes with the same prefix from the IPv4 and IPv6 peers. In this scenario, the route learned from the IPv6 peer might be selected as the optimal route, and the route learned from the IPv4 peer will not be advertised. You can configure this feature on the IPv4 peers in the VPNv4 address family to ensure that routes learned from the IPv4 peers are preferred.

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. Prefer routes learned from the specified peer or peer group during optimal route selection.

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

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

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

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

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

reflect between-clients

By default, route reflection between clients is enabled.

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

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.

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 public instance.

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

By default, no route target is configured for 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.

Configuring route replication for the public instance 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 to the public 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 network 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 | 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 a BGP/MPLS L3VPN network, only VPN instances that have matching route targets can communicate with each other.

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, you can configure BGP route replication between public and VPN instances.

After you configure this feature, the public and VPN instances replicate all BGP routes including route attributes from each other.

Restrictions and guidelines

This feature also enables BGP route replication between VPN instances, so VPNs cannot be isolated. Configure this feature only in specific scenarios, for example, the traffic cleaning scenario.

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 ]

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 the network management and monitoring configuration guide for the device.

Procedure

1. Enter system view.

system-view

2. Enable SNMP notifications for MPLS L3VPN.

snmp-agent trap enable l3vpn [ vrf-down | vrf-ipv6-down | vrf-ipv6-up | vrf-up ] *

By default, SNMP notifications for MPLS L3VPN are enabled.

Enabling logging for BGP route flapping

About this task

This feature enables BGP to generate logs for BGP route flappings that trigger log generation. The generated logs are sent to the information center. For the logs to be output correctly, you must also configure information center on the device. For more information about the information center, see Network Management and Monitoring Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter BGP VPNv4 address family view or BGP-VPN VPNv4 address family view.

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

bgp as-number [ instance instance-name ]

address-family vpnv4

¡ Execute the following commands in sequence to enter BGP-VPN VPNv4 address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family vpnv4

3. Enable logging for BGP route flapping.

log-route-flap monitor-time monitor-count [ log-count-limit | route-policy route-policy-name ] *

By default, logging for BGP route flapping is disabled.

Display and maintenance commands for MPLS L3VPN

Resetting BGP connections

You can soft-reset or reset BGP sessions to apply new BGP configurations. A soft reset operation updates BGP routing information without tearing down BGP connections. A reset operation updates BGP routing information by tearing down, and then re-establishing BGP connections. Soft reset requires that BGP peers have route refresh capability.

Execute the following commands in user view to soft reset or reset BGP connections:

Task	Command
Soft-reset BGP sessions for the VPNv4 address family.	refresh bgp [ instance instance-name ] { ipv4-address [ mask-length ] \| all \| external \| group group-name \| internal } { export \| import } vpnv4 [ vpn-instance vpn-instance-name ]
Soft-reset BGP sessions for the BGP IPv4 RT filter family.	refresh bgp [ instance instance-name ] { ipv4-address [ mask-length ] \| all \| external \| group group-name \| internal } { export \| import } ipv4 rtfilter
Reset BGP sessions for the VPNv4 address family.	reset bgp [ instance instance-name ] { as-number \| ipv4-address [ mask-length ] \| all \| external \| internal \| group group-name } vpnv4 [ vpn-instance vpn-instance-name ]
Reset BGP sessions for the BGP IPv4 RT filter family.	reset bgp [ instance instance-name ] { as-number \| ipv4-address [ mask-length ] \| all \| external \| internal \| group group-name } ipv4 rtfilter

‌

For more information about the refresh bgp vpnv4 and reset bgp vpnv4 commands, see Layer 3—IP Routing Command Reference.

Displaying and maintaining MPLS L3VPN information

Execute the following display commands in any view and reset commands in user view to display and maintain MPLS L3VPN information:

Task	Command
Display BGP VPNv4 route dampening parameters.	display bgp [ instance instance-name ] dampening parameter vpnv4
Display BGP RT filter peer group information.	display bgp [ instance instance-name ] group ipv4 rtfilter [ group-name group-name ]
Display BGP VPNv4 peer group information.	display bgp [ instance instance-name ] group vpnv4 [ vpn-instance vpn-instance-name ] [ group-name group-name ]
Display BGP RT filter information.	display bgp [ instance instance-name ] ipv4 rtfilter [ peer ipv4-address [ statistics ] \| statistics ]
Display BGP RT filter peer information.	display bgp [ instance instance-name ] peer ipv4 rtfilter [ ipv4-address mask-length \| { ipv4-address \| group-name group-name } log-info \| [ ipv4-address ] verbose ]
Display BGP VPNv4 peer information.	display bgp [ instance instance-name ] peer vpnv4 [ vpn-instance vpn-instance-name ] [ ipv4-address mask-length \| { ipv4-address \| group-name group-name } log-info \| [ ipv4-address ] verbose ]
Display information about dampened BGP VPNv4 routes.	display bgp [ instance instance-name ] routing-table dampened vpnv4
Display BGP VPNv4 route flapping information.	display bgp [ instance instance-name ] routing-table flap-info vpnv4 [ ipv4-address [ { mask \| mask-length } [ longest-match ] ] \| as-path-acl as-path-acl-number ]
Display incoming labels for BGP IPv4 unicast routes.	display bgp [ instance instance-name ] routing-table ipv4 [ unicast ] [ vpn-instance vpn-instance-name ] inlabel
Display outgoing labels for BGP IPv4 unicast routes.	display bgp [ instance instance-name ] routing-table ipv4 [ unicast ] [ vpn-instance vpn-instance-name ] outlabel
Display BGP 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 ] ] \| peer ipv4-address { advertised-routes \| received-routes } [ default-rt \| [ origin-as as-number ] [ route-target ] \| statistics ] \| statistics ]
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 \| [ 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 ] \| peer ipv6-address { advertised-routes \| received-routes } [ ipv4-address [ mask-length \| mask ] \| 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 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 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 ]
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

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 12 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 12. (Details not shown.)

# Execute the display ip vpn-instance command on the PEs to display the configuration of the VPN instance, for example, on PE 1.

[PE1] display ip vpn-instance

Total VPN-Instances configured : 2

Total IPv4 VPN-Instances configured : 2

Total IPv6 VPN-Instances configured : 0

VPN-Instance Name RD Address family Create time

vpn1 100:1 IPv4 2012/02/13 12:49:08

vpn2 100:2 IPv4 2012/02/13 12:49:20

# Use the ping command on the PEs to verify that the PEs can ping their attached CEs, for example, on PE 1.

[PE1] ping -vpn-instance vpn1 10.1.1.1

Ping 10.1.1.1 (10.1.1.1): 56 data bytes, press CTRL_C to break

56 bytes from 10.1.1.1: icmp_seq=0 ttl=255 time=1.000 ms

56 bytes from 10.1.1.1: icmp_seq=1 ttl=255 time=2.000 ms

56 bytes from 10.1.1.1: icmp_seq=2 ttl=255 time=0.000 ms

56 bytes from 10.1.1.1: icmp_seq=3 ttl=255 time=1.000 ms

56 bytes from 10.1.1.1: icmp_seq=4 ttl=255 time=0.000 ms

--- Ping statistics for 10.1.1.1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.000/0.800/2.000/0.748 ms

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 BGP AS number substitution

Network configuration

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

‌

Table 2 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 GigabitEthernet 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 14 Network diagram

‌

Table 3 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 15 Network diagram

‌

Table 4 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 4, 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] if-match ip address prefix-list abc

[PE1-route-policy] apply fast-reroute backup-nexthop 3.3.3.3

[PE1-route-policy] 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

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 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 BkSRLabel: NULL

SIDIndex: NULL InLabel: NULL

Tunnel ID: 0x401 Interface: XGE2/0/1

BkTunnel ID: 0x409 BkInterface: XGE2/0/2

FtnIndex: 0x0 TrafficIndex: N/A

Connector: N/A PathID: 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 16 Network diagram

‌

Table 5 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 5, 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] if-match ip address prefix-list abc

[PE2-route-policy] apply fast-reroute backup-nexthop 3.3.3.3

[PE2-route-policy] 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

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 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 BkSRLabel: NULL

SIDIndex: NULL InLabel: NULL

Tunnel ID: Invalid Interface: XGE2/0/1

BkTunnel ID: 0x409 BkInterface: XGE2/0/2

FtnIndex: 0x0 TrafficIndex: N/A

Connector: N/A

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 17 Network diagram

‌

Table 6 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 6, 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] if-match ip address prefix-list abc

[PE1-route-policy] apply fast-reroute backup-nexthop 10.1.1.1

[PE1-route-policy] 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: 00h00m04s

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 Neighbor: 2.2.2.2

Flags: 0x110060 OrigNextHop: 2.2.2.2

Label: 1275 RealNextHop: 172.2.1.2

BkLabel: NULL BkNextHop: 10.1.1.1

SRLabel: NULL BkSRLabel: NULL

SIDIndex: NULL InLabel: NULL

Tunnel ID: 0x409 Interface: XGE2/0/2

BkTunnel ID: Invalid BkInterface: XGE2/0/1

FtnIndex: 0x0 TrafficIndex: N/A

Connector: N/A PathID: 0x0

Configuring IPv6 MPLS L3VPN

About IPv6 MPLS L3VPN

IPv6 MPLS L3VPN 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 18 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 18 Network diagram for the IPv6 MPLS L3VPN model

‌

IPv6 MPLS L3VPN packet forwarding

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

· 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. (Optional.) Configuring IPv6 MPLS L3VPN FRR

3. (Optional.) Controlling MPLS L3VPN route advertisement and reception

¡ Configuring BGP AS number substitution and SoO attribute

¡ Configuring the AIGP attribute

¡ Configuring the BGP additional path feature

¡ 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

4. (Optional.) Enabling logging for BGP route flapping

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

If you configure an RD for a VPN instance, all address families in the VPN instance must use the same RD as the VPN instance.

If you do not configure an RD for a VPN instance, address families in the VPN instance can use different RDs.

To configure an RD for a VPN instance, make sure either of the following conditions exists:

· No RDs have been configured for address families in the VPN instance.

In this case, the RD of the VPN instance will be synchronized to all address families in the VPN instance.

· All address families in the VPN instance use the same RD.

In this case, you must configure the same RD as the address families for the VPN instance.

When you remove the RD from an address family, the RD will also be removed from the VPN instance of the address family.

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.

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.

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.

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

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

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.

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 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 vpnv3

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.

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

About this task

The VPNv6 address family supports both IPv4 and IPv6 peers, so the device might learn routes with the same prefix from the IPv4 and IPv6 peers. You can perform this task to control the route priorities.

When an MPLS L3VPN supports both IPv4 and IPv6, the VPNv6 address family might learn routes with the same prefix from the IPv4 and IPv6 peers. In this scenario, the route learned from the IPv4 peer might be selected as the optimal route, and the route learned from the IPv6 peer will not be advertised. You can configure this feature on the IPv6 peers in the VPNv6 address family to ensure that routes learned from the IPv6 peers are preferred.

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. Prefer routes learned from the specified peer or peer group during optimal route selection.

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

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

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

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.

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 public instance.

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

By default, no route target is configured for 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.

Configuring route replication for the public instance 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 instance or other VPN instances.

· Enables the public network to communicate with a VPN instance by replicating routes from the VPN instance to the public 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 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 IPv6 address family view.

address-family ipv6

4. Replicate routes from the public instance or other VPN instances.

route-replicate from { public | vpn-instance vpn-instance-name } protocol { bgp4+ as-number | direct | static | vlink-direct | { isisv6 | ospfv3 } 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 IPv6 address family view.

address-family ipv6

4. Replicate routes from a VPN instance to the public instance.

route-replicate from vpn-instance vpn-instance-name protocol { bgp4+ as-number | direct | static | vlink-direct | { isisv6 | ospfv3 } 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 an IPv6 BGP/IPv6 MPLS L3VPN network, only VPN instances that have matching route targets can communicate with each other.

After you configure this feature, the public and VPN instances replicate all BGP routes including route attributes from each other.

Restrictions and guidelines

This feature also enables BGP route replication between VPN instances, so VPNs cannot be isolated. Configure this feature only in specific scenarios, for example, the traffic cleaning scenario.

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 ]

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 IPv6 MPLS L3VPN information

Execute the following commands in any view to display IPv6 MPLS L3VPN:

Task	Command
Display the IPv6 routing table for a VPN instance.	display ipv6 routing-table vpn-instance vpn-instance-name [ verbose ]
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 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 \| [ 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 \| 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 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

‌

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 20 Network diagram

‌

Table 7 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 20. (Details not shown.)

# Execute the display ip vpn-instance command on the PEs to display information about the VPN instances, for example, on PE 1.

[PE1] display ip vpn-instance

Total VPN-Instances configured : 2

Total IPv4 VPN-Instances configured : 0

Total IPv6 VPN-Instances configured : 2

VPN-Instance Name RD Address family Create time

vpn1 100:1 IPv6 2012/02/13 12:49:08

vpn2 100:2 IPv6 2012/02/13 12:49:20

# Use the ping command on the PEs to verify that the PEs can ping their attached CEs, for example, on PE 1.

[PE1] ping ipv6 -vpn-instance vpn1 2001:1::1

Ping6(56 bytes) 2001:1::2 --> 2001:1::1, press CTRL_C to break

56 bytes from 2001:1::1, icmp_seq=0 hlim=64 time=9.000 ms

56 bytes from 2001:1::1, icmp_seq=1 hlim=64 time=1.000 ms

56 bytes from 2001:1::1, icmp_seq=2 hlim=64 time=0.000 ms

56 bytes from 2001:1::1, icmp_seq=3 hlim=64 time=0.000 ms

56 bytes from 2001:1::1, icmp_seq=4 hlim=64 time=0.000 ms

--- Ping6 statistics for 2001:1::1 ---

5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.000/2.000/9.000/3.521 ms

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 21, 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 21 Network diagram

‌

Table 8 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 22 Network diagram

‌

Table 9 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] 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

06-MPLS Configuration Guide

About MPLS L3VPN

MPLS L3VPN concepts

Site

VPN instance

VPN-IPv4 address

Route target attribute

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

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

About this task

Procedure

Restrictions and guidelines

Procedure

Configuring MPLS L3VPN FRR

About this task

Restrictions and guidelines

Procedure

Configuring BGP AS number substitution and SoO attribute

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Procedure

About this task