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, including IPv4 multicast and VPN-IPv4 address families.

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

MPLS L3VPN route advertisement

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

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

Route advertisement from the local CE to the ingress PE

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

Route advertisement from the ingress PE to the egress PE

The ingress PE performs the following operations:

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

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

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

Route advertisement from the egress PE to the remote CE

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

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

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

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

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

MPLS L3VPN packet forwarding

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

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

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

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

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

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.

Hub and spoke networking scheme

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

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

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

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

These route targets rules produce the following results:

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

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

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

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

Figure 5 Network diagram for hub and spoke network

‌

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

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

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

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

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

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

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

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

Extranet networking scheme

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

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

Figure 6 Network diagram for extranet networking scheme

‌

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

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

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

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

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

Multirole host

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

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

Figure 7 Network diagram

‌

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

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

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

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

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

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

IMPORTANT:

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

‌

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

‌

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

OSPF sham link

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

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

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

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

Figure 9 Network diagram for sham link

‌

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

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

BGP AS number substitution and SoO attribute

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

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

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

Figure 10 Application of BGP AS number substitution and SoO attribute

‌

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

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

VPNv4 route backup for an IPv4 route

Figure 12 Network diagram

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

‌

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

‌

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

vSystem support for features

Non-default vSytems support configuring RDs in system view.

For information about the support of non-default vSystems for the commands, see MPLS L3VPN command reference. For information about vSystem, see Virtual Technologies Configuration Guide.

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.

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.

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, CR-LSP 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 ] | vpn-instance d-vpn-instance-name next-hop-address }

Configuring RIP between a PE and a CE

About this task

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

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

Procedure

1. Enter system view.

system-view

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

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

A RIP process can belong to only one VPN instance.

3. Redistribute BGP routes.

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

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

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

network network-address [ wildcard-mask ]

By default, RIP is disabled on an interface.

Configuring OSPF between a PE and a CE

About this task

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

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

Procedure

1. Enter system view.

system-view

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

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

Parameter

Usage guidelines

router-id router-id

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

vpn-instance vpn-instance-name

An OSPF process can belong to only one VPN instance.

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

‌

3. Redistribute BGP routes.

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

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

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

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

domain-id domain-id [ secondary ]

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

Configuring the PE

1. Enter system view.

system-view

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

bgp as-number [ instance instance-name ]

By default, BGP is not enabled.

3. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

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

4. Configure the CE as the VPN EBGP peer.

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

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

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

address-family ipv4 [ unicast ]

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

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

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

7. Redistribute the routes of the local CE.

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

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

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

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

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

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

Configuring the CE

1. Enter system view.

system-view

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

bgp as-number [ instance instance-name ]

By default, BGP is not enabled.

3. Configure the PE as a BGP peer.

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

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

address-family ipv4 [ unicast ]

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

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

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

6. Configure route redistribution.

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

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

Configuring 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.) Allow the RR to send routes received from a peer or peer group to its clients.

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

By default, an RR can send received routes to its clients.

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

reflect between-clients

By default, route reflection between clients is enabled.

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

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

rr-filter ext-comm-list-number

By default, the RR does not filter reflected routes.

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

reflect change-path-attribute

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

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 [ direct | { isis | ospf | rip } process-id | static ]

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.

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

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv4 address family view.

address-family vpnv4

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

peer { group-name | ipv4-address [ mask-length ] | 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.

Configuring multirole host

About configuring multirole host

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

· Configure and apply PBR.

· Configure static routes.

Configuring and applying PBR

1. Enter system view.

system-view

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

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

3. Configure match criteria for the node.

See Layer 3—IP Routing Configuration Guide.

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

This step matches packets from the multirole host.

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

apply access-vpn vpn-instance vpn-instance-name&<1-4>

By default, no VPN instance is specified.

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

5. Return to system view.

quit

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

interface interface-type interface-number

7. Apply the policy to the interface.

ip policy-based-route policy-name

By default, no policy is applied to the interface.

Configuring a static route

1. Enter system view.

system-view

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

ip route-static vpn-instance s-vpn-instance-name dest-address { mask-length | mask } vpn-instance d-vpn-instance-name next-hop-address

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

Specifying the VPN label processing mode on the egress PE

About this task

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

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

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

Restrictions and guidelines

The POPGO forwarding mode (vpn popgo) and per-VPN instance label allocation mode (label-allocation-mode per-vrf) are mutually exclusive. Do not configure both modes in a BGP instance. For more information about the label-allocation-mode command, see 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. Specify the VPN label processing mode as POPGO forwarding.

vpn popgo

The default is POP forwarding.

Configuring MPLS L3VPN FRR

About MPLS L3VPN FRR

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

· Method 1—Execute the pic command in BGP-VPN IPv4 unicast address family view. 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 for configuring MPLS L3VPN FRR

Executing the pic command in BGP-VPN IPv4 unicast 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.

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

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 Layer 3—IP Routing Command Reference.

6. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

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

address-family ipv4 [ unicast ]

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

1. Enter system view.

system-view

2. Configure BFD.

¡ 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. Enter BGP instance view.

bgp as-number [ instance instance-name ]

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

5. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

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

address-family ipv4 [ unicast ]

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 an OSPF sham link

About OSPF sham links

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

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

Prerequisites

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

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

· Configure OSPF in the LAN where customer CEs reside.

Redistributing the loopback interface address

1. Enter system view.

system-view

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

interface loopback interface-number

3. Associate the loopback interface with a VPN instance.

ip binding vpn-instance vpn-instance-name

By default, the interface is not associated with any VPN instances and belongs to the public network.

4. Configure an IP address for the loopback interface.

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

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

5. Return to system view.

quit

6. Enter BGP instance view.

bgp as-number [ instance instance-name ]

7. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

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

address-family ipv4 [ unicast ]

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

import-route direct

By default, no direct routes are redistributed into BGP.

Creating a sham link

1. Enter system view.

system-view

2. Enter OSPF view.

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

As a best practice, specify a router ID.

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

route-tag tag-value

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

4. Enter OSPF area view.

area area-id

5. Configure a sham link.

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

Configuring BGP AS number substitution and SoO attribute

About this task

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

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

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

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

4. Enable the BGP AS number substitution feature.

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

By default, BGP AS number substitution is disabled.

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

address-family ipv4 [ unicast ]

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

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

By default, the SoO attribute is not configured.

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

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

peer { group-name | ipv4-address [ mask-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.

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

¡ In BGP VPNv4 address family view:

peer { group-name | ipv4-address [ make-length ] | ipv6-address [ prefix-length ] } additional-paths { receive | send } *

¡ In BGP-VPN VPNv4 address family view:

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.

¡ In BGP VPNv4 address family view:

peer { group-name | ipv4-address [ make-length ] | ipv6-address [ prefix-length ] } advertise additional-paths best number

¡ In BGP-VPN VPNv4 address family view:

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.

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

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 network or other VPN instances.

· Enables the public network to communicate with a VPN instance by replicating routes from the VPN instance.

In an intelligent traffic control network, traffic of different tenants is assigned to different VPNs. To enable the tenants to communicate with the public network, configure this feature to replicate routes from the public network to the VPN instances.

Replicating routes from the public network or VPN instances to a 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 network or other VPN instances.

route-replicate from { public | vpn-instance vpn-instance-name } protocol { bgp as-number | direct | static | { isis | ospf | rip } process-id } [ advertise ] [ route-policy route-policy-name ]

By default, a VPN instance cannot replicate routes from the public network or other VPN instances.

Replicating routes from a VPN instance to the public network

1. Enter system view.

system-view

2. Enter public instance view.

ip public-instance

3. Enter public instance IPv4 address family view.

address-family ipv4

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

route-replicate from vpn-instance vpn-instance-name protocol { bgp as-number | direct | static | { isis | ospf | rip } process-id } [ advertise ] [ route-policy route-policy-name ]

By default, the public network cannot replicate routes from VPN instances.

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.

Procedure

1. Enter system view.

system-view

2. Enter a BGP configuration 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 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 IPv4 unicast address family view:

bgp as-number [ instance instance-name ]

ip vpn-instance vpn-instance-name

address-family ipv4 [ unicast ]

¡ Execute the following commands in sequence to enter BGP-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 IPv4 unicast address family view and BGP IPv6 unicast address family view, this command redistributes ECMP routes to the routing table of the public instance.

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

By default, SNMP notifications for MPLS L3VPN are enabled.

Display and maintenance commands for MPLS L3VPN

‌

IMPORTANT:

Non-default vSystems do not support some of the display and maintenance commands. For information about vSystem support for these commands, see MPLS L3VPN command reference.

‌

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 display commands in any view and reset commands in user view.

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 \| 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 ] \| statistics ] \| statistics ]
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 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 ]
Display OSPF sham link information.	display ospf [ process-id ] sham-link [ area area-id ]
Display VPN peer information.	display vpn-peer [ peer-id vpn-peer-id \| peer-name vpn-peer-name \| verbose ]
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 display ip routing-table, display bgp group vpnv4, display bgp peer vpnv4, and display bgp update-group vpnv4 commands, see Layer 3—IP Routing Command Reference.

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

‌

IPv6 MPLS L3VPN packet forwarding

As shown in Figure 16, 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 16 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, RIPng 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, RIPng route, OSPFv3 route, IPv6 IS-IS route, EBGP, or IBGP route.

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

vSystem support for features

Non-default vSytems support configuring RDs in system view.

For information about the support of non-default vSystems for the commands, see IPv6 MPLS L3VPN command reference. For information about vSystem, see Virtual Technologies Configuration Guide.

IPv6 MPLS L3VPN tasks at a glance

Unless otherwise indicated, configure IPv6 MPLS L3VPN on PEs.

To configure IPv6 MPLS L3VPN, perform the following tasks:

1. Configuring IPv6 MPLS L3VPN basics:

a. Configuring VPN instances

b. Configuring routing between a PE and a CE

c. Configuring routing between PEs

d. (Optional.) Configuring BGP VPNv6 route control

2. Configuring advanced IPv6 MPLS L3VPN networks

Choose the following tasks as needed:

¡ Configuring multirole host

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

3. (Optional.) Configuring an OSPFv3 sham link

4. (Optional.) Configuring BGP AS number substitution and SoO attribute

5. (Optional.) Configuring the BGP additional path feature

6. (Optional.) Configuring route replication

7. (Optional.) Enabling prioritized withdrawal of specific routes

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.

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.

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 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, GRE 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 }

Configuring RIPng between a PE and a CE

About this task

Perform this configuration on the PE. On the CE, configure a common RIPng process.

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

Procedure

1. Enter system view.

system-view

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

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

A RIPng process can belong to only one VPN instance.

3. Redistribute BGP routes.

import-route bgp4+ [ as-number ] [ allow-ibgp ] [ cost cost-value | route-policy route-policy-name ] *

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

4. Return to system view.

quit

5. Enter interface view.

interface interface-type interface-number

6. Enable RIPng on the interface.

ripng process-id enable

By default, RIPng is disabled on an interface.

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

Configuring the PE

1. Enter system view.

system-view

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

bgp as-number [ instance instance-name ]

By default, BGP is not enabled.

3. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

4. Configure the CE as the VPN EBGP peer.

peer { group-name | ipv6-address [ prefix-length ] } as-number as-number

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

address-family ipv6 [ unicast ]

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

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

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

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

7. Redistribute the routes of the local CE.

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

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

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

peer { group-name | ipv6-address [ prefix-length ] } allow-as-loop [ number ]

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

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

Configuring the CE

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Configure the PE as an EBGP peer.

peer { group-name | ipv6-address [ prefix-length ] } as-number as-number

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

address-family ipv6 [ unicast ]

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

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

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

6. Configure route redistribution.

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

A CE must advertise its VPN routes to the connected PE so that the PE can advertise them to the peer CE.

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

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

5. Configure BGP to not change the next hop of routes sent to a peer or peer group.

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

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

In an inter-AS option C network where an RR is used to advertise VPNv6 routes, configure this command on the RR so the RR does not change the next hop of routes sent to BGP peers and clients.

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

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 [ direct | { isisv6 | ospfv3 | ripng } process-id | static ]

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.

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

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP VPNv6 address family view.

address-family vpnv6

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

peer { group-name | ipv4-address [ mask-length ] | 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.

Configuring multirole host

About configuring multirole host

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

· Configure and apply IPv6 PBR.

· Configure IPv6 static routes.

Configuring and applying IPv6 PBR

1. Enter system view.

system-view

2. Create an IPv6 policy node and enter IPv6 policy node view.

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

3. Configure match criteria for the node.

See Layer 3—IP Routing Configuration Guide.

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

This step matches packets from the multirole host.

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

apply access-vpn vpn-instance vpn-instance-name&<1-4>

By default, no VPN instance is specified.

5. Return to system view.

quit

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

interface interface-type interface-number

7. Apply the policy to the interface.

ipv6 policy-based-route policy-name

By default, no policy is applied to the interface.

Configuring an IPv6 static route

1. Enter system view.

system-view

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

ipv6 route-static vpn-instance s-vpn-instance-name ipv6-address prefix-length vpn-instance d-vpn-instance-name nexthop-address

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

Configuring an OSPFv3 sham link

Prerequisites

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

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

· Configure OSPFv3 in the LAN where customer CEs reside.

Redistributing the loopback interface address

1. Enter system view.

system-view

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

interface loopback interface-number

3. Associate the loopback interface with a VPN instance.

ip binding vpn-instance vpn-instance-name

By default, the interface is not associated with any VPN instances and belongs to the public network.

4. Configure an IPv6 address for the loopback interface.

See Layer 3—IP Services Configuration Guide.

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

5. Enter BGP instance view.

bgp as-number [ instance instance-name ]

6. Enter BGP-VPN instance view.

ip vpn-instance vpn-instance-name

7. Enter BGP-VPN IPv6 unicast address family view.

address-family ipv6 [ unicast ]

8. Redistribute direct routes into BGP (including the loopback interface address).

import-route direct

By default, no direct routes are redistributed into BGP.

Creating a sham link

1. Enter system view.

system-view

2. Enter OSPFv3 view.

ospfv3 [ process-id | vpn-instance vpn-instance-name ] *

3. Enter OSPFv3 area view.

area area-id

4. Configure an OSPFv3 sham link.

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 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 ] | ipv6-address [ prefix-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 ] | ipv6-address [ prefix-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

About this task

In an IPv6 BGP/IPv6 MPLS L3VPN network, only VPN instances that have matching route targets can communicate with each other.

The route replication feature provides the following functions:

· Enables a VPN instance to communicate with the public network or other VPN instances by replicating routes from the public network or other VPN instances.

· Enables the public network to communicate with a VPN instance by replicating routes from the VPN instance.

Replicating routes from the public network or VPN instances to a VPN instance

1. Enter system view.

system-view

2. Enter VPN instance view.

ip vpn-instance vpn-instance-name

3. Enter VPN instance IPv6 address family view.

address-family ipv6

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

route-replicate from { public | vpn-instance vpn-instance-name } protocol { bgp4+ as-number | direct | static | { isisv6 | ospfv3 | ripng } process-id } [ advertise ] [ route-policy route-policy-name ]

By default, a VPN instance cannot replicate routes from the public network or other VPN instances.

Replicating routes from a VPN instance to the public network

1. Enter system view.

system-view

2. Enter public instance view.

ip public-instance

3. Enter public instance IPv6 address family view.

address-family ipv6

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

route-replicate from vpn-instance vpn-instance-name protocol { bgp4+ as-number | direct | static | { isisv6 | ospfv3 | ripng } process-id } [ advertise ] [ route-policy route-policy-name ]

By default, the public network cannot replicate routes from VPN instances.

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.

Display and maintenance commands for IPv6 MPLS L3VPN

‌

IMPORTANT:

Non-default vSystems do not support some of the display and maintenance commands. For information about vSystem support for these commands, see IPv6 MPLS L3VPN command reference.

‌

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 ]
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 \| community-list { { basic-community-list-number \| comm-list-name } [ whole-match ] \| adv-community-list-number } ] \| peer ipv4-address { advertised-routes \| received-routes } [ ipv6-address prefix-length \| statistics ] \| statistics ]
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 OSPFv3 sham link information.	display ospfv3 [ process-id ] [ area area-id ] sham-link [ verbose ]
Display VPN peer information.	display vpn-peer [ peer-id vpn-peer-id \| peer-name vpn-peer-name \| verbose ]

‌

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.

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

Hub and spoke networking scheme

Extranet networking scheme

Multirole host

OSPF VPN extension

OSPF for VPNs on a PE

OSPF area configuration between a PE and a CE

BGP/OSPF interaction

OSPF sham link

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

Procedure

Restrictions and guidelines

Procedure

Restrictions and guidelines

Prerequisites

Procedure

Configuring routing between a PE and a CE

Configuring static routing between a PE and a CE

About this task

Procedure

Configuring RIP between a PE and a CE

About this task

Procedure

Configuring OSPF between a PE and a CE

About this task

Procedure

About this task

Procedure

Configuring the PE

Configuring the CE

Configuring routing between PEs

Configuring BGP VPNv4 route reflection

About this task

Procedure

Configuring BGP VPNv4 route filtering

About this task

Restrictions and guidelines

Procedure

Configuring multirole host

About this task

Restrictions and guidelines

Procedure

Configuring an OSPF sham link

Redistributing the loopback interface address

Creating a sham link

Configuring BGP AS number substitution and SoO attribute

About this task

Procedure

About this task

Procedure

About this task

Procedure

About this task

Replicating routes from the public network or VPN instances to a VPN instance

Replicating routes from a VPN instance to the public network

Enabling ECMP VPN route redistribution

About this task

Procedure

About this task

Procedure

About this task