VPN multicast traffic between the PEs and the CEs is transmitted on a per-VPN-instance basis. The public network multicast traffic between the PEs and the P device is transmitted through the public network. Multicast VPN provides independent multicast services for the public network, VPN A, and VPN B.

For more information about CEs, PEs and Ps, see MPLS Configuration Guide.

MVPN scheme

MVPN is used to implement multicast VPN. MVPN only requires the PEs to support multiple VPN instances and the public network provided by the service provider to support multicast. There is no need to upgrade CEs and Ps or change their PIM configurations. The MVPN scheme is transparent to CEs and Ps.

MVPN supports the following modes: MDT, RSVP-TE, mLDP, and BIER.

Basic concepts in MDT-based MVPN

This section introduces the following basic concepts in MDT-based MVPN:

· MVPN—An MVPN logically defines the transmission boundary of the multicast traffic of a VPN over the public network. It also physically identifies all the PEs that support that VPN instance on the public network. Different VPN instances correspond to different MVPNs.

· Multicast distribution tree (MDT)—An MDT is a multicast distribution tree constructed by all PEs in the same VPN. MDT includes default MDT and data MDT.

· Multicast tunnel (MT)—An MT is a tunnel that interconnects all PEs in an MVPN. The local PE encapsulates a VPN multicast packet into a public network multicast packet and forwards it through the MT over the public network. The remote PE decapsulates the public network multicast packet to get the original VPN multicast packet.

· Multicast tunnel interface (MTI)—An MTI is the entrance or exit of an MT, equivalent to an entrance or exit of an MVPN. MTIs are automatically created when the MVPN for the VPN instance is created. PEs use the MTI to access the MT. The local PE sends VPN data out of the MTI. The remote PEs receive the private data from their MTIs. An MTI runs the same PIM mode as the VPN instance to which the MTI belongs. PIM is enabled on MTIs when a minimum of one interface in the VPN instance is enabled with PIM. When PIM is disabled on all interfaces in the VPN instance, PIM is also disabled on MTIs.

· Default group—A default group is a unique multicast address assigned to each MVPN on the public network. It is the unique identifier of an MVPN on the public network and helps build the default MDT for an MVPN on the public network. A PE encapsulates a VPN multicast packet (a multicast protocol packet or a multicast data packet) into a public network multicast packet. The default group address is used as the public network multicast group.

· Default MDT—A default MDT uses a default group address as its group address. In a VPN, the default MDT is uniquely identified by the default group. A default MDT is automatically created after the default group is specified and will always exist on the public network, regardless of the presence of any multicast services on the public network or the VPN.

· Data group—An MVPN is assigned a unique data group for MDT switchover. The ingress PE selects a least used address from the data group range to encapsulate the VPN multicast packets when the multicast traffic of the VPN reaches or exceeds a threshold. Other PEs are notified to use the address to forward the multicast traffic for that VPN. This initiates the switchover to the data MDT.

· Data MDT—A data MDT is an MDT that uses a data group as it group address. At MDT switchover, PEs with downstream receivers join a data group to build a data MDT. The ingress PE forwards the encapsulated VPN multicast traffic along the data MDT over the public network.

How MDT-based MVPN works

For a VPN instance, multicast data transmission on the public network is transparent. The VPN data is exchanged between the MTIs of the local PE and the remote PE. This implements the seamless transmission of the VPN data over the public network. However, the multicast data transmission process (the MDT transmission process) over the public network is very complicated.

NOTE:

The following types of PIM neighboring relationships exist in MVPN:

· PE-P PIM neighboring relationship—Established between the public network interface on a PE and the peer interface on the P device over the link.

· PE-PE PIM neighboring relationship—Established between PEs that are in the same VPN instance after they receive the PIM hello packets.

· PE-CE PIM neighboring relationship—Established between a PE interface that is bound with the VPN instance and the peer interface on the CE over the link.

Default MDT establishment

The multicast routing protocol running on the public network can be PIM-DM, PIM-SM or PIM-SSM. The process of creating a default MDT is different in these PIM modes.

Default MDT establishment in a PIM-DM network

Figure 2 Default MDT establishment in a PIM-DM network

As shown in Figure 2, PIM-DM is enabled on the network, and all the PEs support VPN instance A. The process of establishing a default MDT is as follows:

1. To establish PIM neighboring relationships with PE 2 and PE 3 through the MTI for VPN instance A, PE 1 does the following:

a. Encapsulates the PIM protocol packet of the private network into a public network multicast data packet. PE 1 does this by specifying the source address as the IP address of the MVPN source interface and the multicast group address as the default group address.

b. Sends the multicast data packet to the public network.

For other PEs that support VPN instance A as default group members, PE 1 of VPN instance A initiates a flood-prune process in the entire public network. A (11.1.1.1, 239.1.1.1) state entry is created on each device along the path on the public network. This forms an SPT with PE 1 as the root, and PE 2 and PE 3 as leaves.

2. At the same time, PE 2 and PE 3 separately initiate a similar flood-prune process.

Finally, three independent SPTs are established in the MVPN, constituting the default MDT in the PIM-DM network.

Default MDT establishment in a PIM-SM network

Figure 3 Default MDT establishment in a PIM-SM network

As shown in Figure 3, PIM-SM is enabled on the network, and all the PEs support VPN instance A. The process of establishing a default MDT is as follows:

1. PE 1 initiates a join to the public network RP by specifying the multicast group address as the default group address in the join message. A (*, 239.1.1.1) state entry is created on each device along the path on the public network.

2. At the same time, PE 2 and PE 3 separately initiate a similar join process.

Finally, an RPT is established in the MVPN, with the public network RP as the root and PE 1, PE 2, and PE 3 as leaves.

3. To establish PIM neighboring relationships with PE 2 and PE 3 through the MTI for VPN instance A, PE 1 does the following:

b. Sends the multicast data packet to the public network.

The public network interface of PE 1 registers the multicast source with the public network RP, and the public network RP initiates a join to PE 1. A (11.1.1.1, 239.1.1.1) state entry is created on each device along the path on the public network.

4. At the same time, PE 2 and PE 3 separately initiate a similar register process.

Finally, three SPTs between the PEs and the RP are established in the MVPN.

In the PIM-SM network, the RPT, or the (*, 239.1.1.1) tree, and the three independent SPTs constitute the default MDT.

Default MDT establishment in a PIM-SSM network

Figure 4 Default MDT establishment in a PIM-SSM network

As shown in Figure 4, PIM-SSM runs on the network, and all the PEs support VPN instance A. The process of establishing a default MDT is as follows:

1. PE 1, PE 2, and PE 3 exchange MDT route information (including BGP interface address and the default group address) through BGP.

2. PE 1 sends a subscribe message to PE 2 and PE 3. Each device on the public network creates an (S, G) entry. An SPT is established in the MVPN with PE 1 as the root and PE 2 and PE 3 as the leaves.

At the same time, PE 2 and PE 3 separately initiate a similar process, and establish an SPT with itself as the root and the other PEs as the leaves.

3. The three independent SPTs constitute the default MDT in the PIM-SSM network.

In PIM-SSM, the term "subscribe message" refers to a join message.

Default MDT characteristics

No matter which PIM mode is running on the public network, the default MDT has the following characteristics:

· All PEs that support the same VPN instance join the default MDT.

· All multicast packets that belong to this VPN are forwarded along the default MDT to every PE on the public network, even if no active downstream receivers exist.

Default MDT-based delivery

After the default MDT is established, the multicast source forwards the VPN multicast data to the receivers in each site along the default MDT. The VPN multicast packets are encapsulated into public network multicast packets on the local PE, and transmitted along the default MDT. Then, they are decapsulated on the remote PE and transmitted in that VPN site.

VPN multicast data packets are forwarded across the public network differently in the following circumstances:

· If PIM-DM or PIM-SSM is running in the VPN, the multicast source forwards multicast data packets to the receivers along the VPN SPT across the public network.

· When PIM-SM is running in the VPN:

¡ Before the RPT-to-SPT switchover, if the multicast source and the VPN RP are in different sites, the VPN multicast data packets travel to the VPN RP along the VPN SPT across the public network. If the VPN RP and the receivers are in different sites, the VPN multicast data packets travel to the receivers along the VPN RPT over the public network.

¡ After the RPT-to-SPT switchover, if the multicast source and the receivers are in different sites, the VPN multicast data packets travel to the receivers along the VPN SPT across the public network.

The following example explains how multicast data packets are delivered based on the default MDT when PIM-DM is running in both the public network and the VPN network.

As shown in Figure 5:

· PIM-DM is running in both the public network and the VPN sites.

· Receiver of the VPN multicast group G (225.1.1.1) in Site 2 is attached to CE 2.

· Source in Site 1 sends multicast data to multicast group (G).

· The default group address used to forward public network multicast data is 239.1.1.1.

Figure 5 Multicast data packet delivery

A VPN multicast data packet is delivered across the public network as follows:

1. Source sends a VPN multicast data packet (192.1.1.1, 225.1.1.1) to CE 1.

2. CE 1 forwards the VPN multicast data packet along an SPT to PE 1, and the VPN instance on PE 1 examines the MVRF.

If the outgoing interface list of the forwarding entry contains an MTI, PE 1 processes the VPN multicast data packet as described in step 3. The VPN instance on PE 1 considers the VPN multicast data packet to have been sent out of the MTI, because step 3 is transparent to it.

3. PE 1 encapsulates the VPN multicast data packet into a public network multicast packet (11.1.2.1, 239.1.1.1) by using the GRE method. The source IP address of the packet is the MVPN source interface 11.1.1.1, and the destination address is the default group address 239.1.1.1. PE 1 then forwards it to the public network.

4. The default MDT forwards the multicast data packet (11.1.2.1, 239.1.1.1) to the public network instance on all the PEs. After receiving this packet, every PE decapsulates it to get the original VPN multicast data packet, and passes it to the corresponding VPN instance. If a PE has a downstream interface for an SPT, it forwards the VPN multicast packet down the SPT. Otherwise, it discards the packet.

5. The VPN instance on PE 2 looks up the MVRF and finally delivers the VPN multicast data to Receiver.

By now, the process of transmitting a VPN multicast data packet across the public network is completed.

MDT switchover

Switching from default MDT to data MDT

When a multicast packet of a VPN is transmitted through the default MDT on the public network, the packet is forwarded to all PEs that support that VPN instance. This occurs whether or not any active receivers exist in the attached sites. When the rate of the multicast traffic of that VPN is high, multicast data might get flooded on the public network. This increases the bandwidth use and brings extra burden on the PEs.

To optimize multicast transmission of large VPN multicast traffic that enters the public network, the MVPN solution introduces a dedicated data MDT. A data MDT is built between the PEs that connect VPN multicast receivers and multicast sources. When specific network criteria are met, the device switches over from the default MDT to the data MDT to forward VPN multicast traffic to receivers.

The device initiates a switchover of the default MDT to the data MDT as follows:

1. The source-side PE (PE 1, for example) periodically examines the forwarding rate of the VPN multicast traffic. The PE initiates a switchover of the default MDT to the data MDT only when the following criteria are both met:

¡ The VPN multicast data has passed the ACL rule filtering for MDT switchover.

¡ The traffic rate of the VPN multicast stream has exceeded the switchover threshold and stayed higher than the threshold for a certain length of time.

2. PE 1 selects a least-used address from the data group range. Then, it sends an MDT switchover message to all the other PEs down the default MDT. This message contains the VPN multicast source address, the VPN multicast group address, and the data group address.

3. Each PE that receives this message examines whether it interfaces with a VPN that has receivers of that VPN multicast stream.

If so, it joins the data MDT rooted at PE 1. Otherwise, it caches the message and will join the data MDT when it has attached receivers.

4. After sending the MDT switchover message, PE 1 starts the data-delay timer. When the timer expires, PE 1 uses the default group address to encapsulate the VPN multicast data. The multicast data is then forwarded down the data MDT.

5. After the multicast traffic is switched over from the default MDT to the data MDT, PE 1 continues sending MDT switchover messages periodically. Subsequent PEs with attached receivers can then join the data MDT. When a downstream PE no longer has active receivers attached to it, it leaves the data MDT.

For a given VPN instance, the default MDT and the data MDT are both forwarding tunnels in the same MVPN. A default MDT is uniquely identified by a default group address, and a data MDT is uniquely identified by a data group address. Each default group is uniquely associated with a data group range.

Backward switching from data MDT to default MDT

After the VPN multicast traffic is switched over to the data MDT, the multicast traffic conditions might change and no longer meet the switchover criterion. In this case, PE 1, as in the preceding example, initiates a backward MDT switchover process when any of the following criteria are met:

· The traffic rate of the VPN multicast data has dropped below the switchover threshold. In addition, the traffic rate has stayed lower than the threshold for a certain length of time (known as the data hold-down period).

· The associated data group range is changed, and the data group address for encapsulating the VPN multicast data is out of the new address range.

· The ACL rule for controlling the switchover from the default MDT to the data MDT has changed, and the VPN multicast data fails to pass the new ACL rule.

Inter-AS MDT-based MVPN

In an inter-AS VPN networking scenario, VPN sites are located in multiple ASs. These sites must be interconnected. Inter-AS VPN provides the following solutions:

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

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

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

For more information about the three inter-AS VPN solutions, see MPLS L3VPN configuration in MPLS Configuration Guide.

Based on these solutions, there are three ways to implement inter-AS MDT-based MVPN:

· Inter-AS option A MDT-based MVPN.

· Inter-AS option B MDT-based MVPN.

· Inter-AS option C MDT-based MVPN.

Inter-AS option A MDT-based MVPN

As shown in Figure 6:

· Two VPN instances are in AS 1 and AS 2.

· PE 3 and PE 4 are ASBRs for AS 1 and AS 2, respectively.

· PE 3 and PE 4 are interconnected through their respective VPN instance and treat each other as a CE.

Figure 6 Inter-AS option A MDT-based MVPN

To implement inter-AS option A MDT-based MVPN, a separate MVPN must be created in each AS. Multicast data is transmitted between the VPNs in different ASs through the MVPNs.

Multicast packets of VPN instance 1 are delivered as follows:

1. CE 1 forwards the multicast packet of VPN instance 1 to PE 1.

2. PE 1 encapsulates the multicast packet into a public network packet and forwards it to PE 3 through the MTI interface in MVPN 1.

3. PE 3 considers PE 4 as a CE of VPN instance 1, so PE 3 forwards the multicast packet to PE 4.

4. PE 4 considers PE 3 as a CE of VPN instance 2, so it forwards the multicast packet to PE 2 through the MTI interface in MVPN 2 on the public network.

5. PE 2 forwards the multicast packet to CE 2.

Multicast packets of VPN 2 are delivered in the same way.

Because only VPN multicast data is forwarded between ASBRs, different PIM modes can run within different ASs. However, the same PIM mode must run on all interfaces that belong to the same VPN (including interfaces with VPN bindings on ASBRs).

Inter-AS option B MDT-based MVPN

In inter-AS option B MDT-based MVPN, RPF vector and BGP connector are introduced:

· RPF vector—Attribute encapsulated in a PIM join message. It is the next hop of BGP MDT route from the local PE to the remote PE. Typically, it is the ASBR in the local AS.

When a device receives the join message with the RPF vector, it first checks whether the RPF vector is its own IP address. If so, the device removes the RPF vector, and sends the message to its upstream neighbor according to the route to the remote PE. Otherwise, it keeps the RPF vector, looks up the route to the RPF vector, and sends the message to the next hop of the route. In this way, the PIM message can be forwarded across the ASs and an MDT is established.

· BGP connector—Attribute shared by BGP peers when they exchange VPNv4 routes. It is the IP address of the remote PE.

The local PE fills the upstream neighbor address field with the BGP connector in a join message. This ensures that the message can pass the RPF check on the remote PE after it travels along the MT.

As shown in Figure 7:

· A VPN network involves AS 1 and AS 2.

· PE 3 and PE 4 are the ASBRs for AS 1 and AS 2, respectively.

· PE 3 and PE 4 are interconnected through MP-EBGP and treat each other as a P device.

· PE 3 and PE 4 advertise VPN-IPv4 routes to each other through MP-EBGP.

· An MT is established between PE 1 and PE 2 for delivering VPN multicast traffic across the ASs.

Figure 7 Inter-AS option B MDT-based MVPN

To implement inter-AS option B MDT-based MVPN, only one MVPN needs to be established for the two ASs. VPN multicast data is transmitted between different ASs on the public network within this MVPN.

The establishment of the MVPN on the public network is as follows:

1. PE 1 originates a PIM join message to join the SPT rooted at PE 2. In the join message, the upstream neighbor address is the IP address of PE 2 (the BGP connector). The RPF vector attribute is the IP address of PE 3. PE 1 encapsulates the join message as a public network packet and forwards it through the MTI.

2. P 1 determines that the RPF vector is not an IP address of its own. It looks up the routing table for a route to PE 3, and forwards the packet to PE 3.

3. PE 3 removes the RPF vector because the RPF vector is its own IP address. It fails to find a BGP MDT route to PE 2, so it encapsulates a new RPF vector (IP address of PE 4) in the packet and forwards it to PE 4.

4. PE 4 removes the RPF vector because the RPF vector is its own IP address. It has a local route to PE 2, so it forwards the packet to P 2, which is the next hop of the route to PE 2.

5. P 2 sends the packet to PE 2.

6. PE 2 receives the packet on the MTI and decapsulates the packet. The receiving interface is the RPF interface of the RPF route back to PE 1 for the join message, and the join message passes the RPF check. The SPT from PE 1 to PE 2 is established.

When PE 1 joins the SPT rooted at PE 1, PE 2 also initiates a join process to the SPT rooted at PE 1. A MDT is established when the two SPTs are finished.

Inter-AS option C MDT-based MVPN

As shown in Figure 8:

· A VPN instance spans AS 1 and AS 2.

· PE 3 and PE 4 are the ASBRs for AS 1 and AS 2, respectively.

· PE 3 and PE 4 are interconnected through MP-EBGP and treat each other as a P device.

· PEs in different ASs establish a multihop MP-EBGP session to advertise VPN-IPv4 routes to each other.

Figure 8 Inter-AS option C MDT-based MVPN

To implement inter-AS option C MDT-based MVPN, only one MVPN needs to be created for the two ASs. Multicast data is transmitted between the two ASs through the MVPN.

Multicast packets are delivered as follows:

1. CE 1 forwards the VPN instance multicast packet to PE 1.

2. PE 1 encapsulates the multicast packet into a public network multicast packet and forwards it to PE 3 through the MTI interface on the public network.

3. PE 3 and PE 4 are interconnected through MP-EBGP, so PE 3 forwards the public network multicast packet to PE 4 along the VPN IPv4 route.

4. The public network multicast packet arrives at the MTI interface of PE 2 in AS 2. PE 2 decapsulates the public network multicast packet and forwards the VPN multicast packet to CE 2.

Basic concepts in RSVP-TE-based MVPN

This section introduces the following concepts in RSVP-TE-based MVPN:

· Inclusive tunnel—Transmits all multicast packets (including multicast protocol packets and multicast data packets of all multicast groups) for an MVPN. Only one inclusive tunnel can be established between two PEs in the MVPN. A PE encapsulates multicast data packets and PIM BSMs of an MVPN into public network multicast data packets and sends them over the public network through the inclusive tunnel.

· Selective tunnel—Transmits multicast packets of one or more multicast groups for an MVPN. Multiple selective tunnels can be established between two PEs in the MVPN.

How RSVP-TE-based MVPN works

RSVP-TE-based MVPN operation

Packet transmission on the public network is transparent for a VPN instance. Each two PEs establish IBGP neighbor relationship and use BGP to advertise routing information for MVPN. The following types of routes are used to create RSVP-TE tunnels for an MVPN:

· Intra-AS I-PMSI A-D route—PEs use this type of route to establish inclusive tunnels.

· S-PMSI A-D route—The multicast source-side PE sends this type of route to receiver-side PEs for tunnel switchover when selective tunnel creation is enabled and the tunnel creation criterion is met.

· Leaf A-D route—A receiver-side PE that has attached receivers replies with a Leaf A-D route when it receives an S-PMSI A-D route from the multicast source-side PE. RSVP-TE creates selective tunnels between receiver-side PEs and the multicast-side PE based on the neighbor information contained in Leaf A-D routes.

· Source Active A-D route—The multicast source-side PE sends this type of route to receiver-side PEs to advertise the location of the multicast source.

· C-multicast route—After receiving the Source Active A-D route from the multicast source-side PE, a receiver-side PE replies with a C-Multicast route to request the multicast source-side PE to send multicast data.

Multicast packets of a VPN instance are seamlessly transmitted from a CE to the inclusive tunnel on the PE based on the PIM routing table. These packets are then transmitted to the remote PE through the inclusive tunnel. After receiving the packets, the remote PE decapsulates the packets to get the original private packets. The multicast source-side PE creates selective tunnels when multicast traffic that meets the tunnel switchover criterion arrives.

Inclusive tunnel establishment

As shown in Figure 9, the private network runs PIM, and the public network uses MPLS backbone. The inclusive tunnels are established as follows:

1. PE 1, PE 2, and PE 3 mutually establish IBGP neighbor relationship and exchange routing information to get the public network address of each PE.

2. PE 1 (source of the tunnel) sends an Intra-AS I-PMSI A-D route to PE 2 and PE 3 (destination of the tunnel) to advertise the inclusive tunnel information.

3. PE 2 and PE 3 each establish an inclusive tunnel with PE 1. The inclusive tunnel on the public network does not rely on PIM running on the private network.

Figure 9 Inclusive tunnel establishment

Selective tunnel establishment and tunnel switchover

As shown in Figure 10, selective tunnels are established and switched as follows:

1. After multicast source-side PE 1 receives a multicast packet of the (S, G) entry that meets the tunnel switchover criterion, it sends an S-PMSI A-D route to PE 2 and PE 3.

2. PE 2 does not send a response because it has no receivers of the (S,G) entry attached.

3. PE 3 replies with a Leaf A-D route because it is attached to a receiver of the entry.

4. PE 1 and PE 3 establish a selective tunnel.

5. Subsequent multicast packets of the (S,G) entry that enters the public network from PE 1 are switched over to the selective tunnel from the inclusive tunnel.

Figure 10 Selective tunnel establishment

Basic concepts in mLDP-based MVPN

Basic concepts in mLDP-based MVPN are the same as those in RSVP-TE-based MVPN. For more information about basic concepts in RSVP-TE-based MVPN, see "Basic concepts in RSVP-TE-based MVPN."

How mLDP-based MVPN works

mLDP-based MVPN operation

The operation of mLDP-based MVPN is similar to that of RSVP-TE-based MVPN. They differ in the direction in which the public network P2MP tunnel is created.

· RSVP-TE-based MVPN—Starting from the ingress PE, the upstream devices use RSVP to establish RSVP-TE P2MP tunnels with downstream devices. In this mode, the ingress PE needs to know the IP address of the egress PE.

· mLDP-based MVPN—Starting from the egress PE, the downstream devices use LDP to establish mLDP P2MP tunnels with downstream devices. In this mode, the egress PE needs to the IP address of the ingress PE.

For more information about the RSVP-TE-based MVPN operation, see "RSVP-TE-based MVPN operation."

Inclusive tunnel establishment

As shown in Figure 11, the private network runs PIM, and the public network uses MPLS backbone. The inclusive tunnels are established as follows:

1. PE 1, PE 2, and PE 3 mutually establish IBGP neighbor relationship and exchange routing information.

2. PE 1 (the source of the tunnel) advertises the inclusive tunnel information to PE 2 and PE 3.

3. PE 2 and PE 3 each uses LDP to establish an inclusive mLDP tunnel with PE 1. The inclusive tunnel on the public network does not rely on PIM running on the private network.

Figure 11 Establishment of the inclusive tunnel

Selective tunnel establishment and tunnel switchover

mLDP-based MVPN supports switchover from the inclusive tunnel to selective tunnels to off-load traffic for specific (S, G) entries from the inclusive tunnel. An MVPN can have multiple selective tunnels.

As shown in Figure 12, the process of selective tunnel creation and the tunnel switchover is as follows:

1. Upon receiving a multicast packet for the (S, G) entry that meets the tunnel switchover criterion, the multicast source-side PE 1 sends an S-PMSI A-D route to PE 2 and PE 3.

2. PE 2 does not respond to the route because it has no receivers of the (S,G) entry attached.

3. PE 3 which has a receiver attached uses LDP to establish a selective tunnel with PE 1.

4. Subsequent multicast packets for the (S,G) entry are transmitted over the selective tunnel instead of the inclusive tunnel on the public network.

Figure 12 Selective tunnel establishment and tunnel switchover

Inter-AS mLDP-based MVPN

In an inter-AS VPN networking scenario, VPN sites are located in multiple ASs. These sites must be interconnected. Inter-AS VPN provides the following solutions:

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

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

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

For more information about the three inter-AS VPN solutions, see MPLS L3VPN configuration in MPLS Configuration Guide.

Inter-AS option A mLDP-based MVPN

As shown in Figure 13:

· A VPN instance spans AS 100 and AS 200.

· PE 3 and PE 4 are ASBRs for AS 100 and AS 200, respectively.

· PE 3 and PE 4 are interconnected through their respective VPN instance and treat each other as a CE.

Figure 13 Inter-AS option A mLDP-based MVPN

To implement inter-AS option A mLDP-based MVPN, a separate MVPN must be created in each AS. Multicast data of the VPN instance is transmitted across the ASs through the separate MVPNs in each AS.

Multicast packets of the VPN instance are delivered as follows:

1. CE 1 forwards a multicast packet of VPN instance 1 to PE 1.

2. PE 1 encapsulates the multicast packet into an MPLS packet and forwards it to PE 3 through mLDP tunnel 1.

3. PE 3 considers PE 4 as a CE of MVPN 1, so PE 3 decapsulates the MPLS packet and forwards the multicast packet to PE 4.

4. PE 4 considers PE 2 as a CE of MVPN 2, so PE 4 encapsulates the multicast packet into an MPLS packet and then forwards the packet to PE 2 through mLDP tunnel 2.

5. PE 2 decapsulates the MPLS packet and then forwards the multicast packet to CE 2.

In inter-AS option A, PEs in different ASs cannot advertise Source Active A-D routes to each other. Therefore, you must configure MSDP or Anycast-RP between RPs to allow Source Active A-D routes to be advertised across ASs.

Inter-AS option B mLDP-based MVPN

As shown in Figure 14:

· A VPN instance spans AS 100 and AS 200.

· PE 3 and PE 4 are the ASBRs for AS 100 and AS 200, respectively.

· PE 3 and PE 4 are interconnected through MP-EBGP and treat each other as a P device.

· PE 3 and PE 4 advertise VPN-IPv4 routes to each other through MP-EBGP.

Figure 14 Inter-AS option B mLDP-based MVPN

To implement inter-AS option B mLDP-based MVPN, only one MVPN needs to be established across all ASs. VPN multicast data is transmitted across the ASs through this MVPN.

Multicast packets of the VPN instance are transmitted as follows:

1. Upon receiving a multicast packet of a multicast group in the VPN instance, CE 1 advertises the RP information for this group to PE 1 as follows:

¡ If the RP is PE 1, CE 1 directly sends a register message to PE 1 to advertise the RP information.

¡ If the RP is CE 1 or CE 2, CE 1 advertises the RP information to PE 1 through MSDP or Anycast-RP depending on the actual configuration.

2. PE 1 sends a Source Active A-D route to PE 3, PE 4, and PE 2 through BGP.

3. PE 2 sends a C-multicast route to join the multicast group if it has a receiver attached. The C-multicast route will be advertised to PE 4, PE 3, and PE 1 through BGP.

4. Upon receiving the C-multicast route, PE 1 encapsulates the multicast packet into an MPLS packet and then sends the packet to PE 2 through the mLDP tunnel.

5. PE 2 decapsulates the MPLS packet and then sends the multicast packet to CE 2.

Inter-AS option C mLDP-based MVPN

As shown in Figure 15:

· A VPN instance spans AS 100 and AS 200.

· PE 3 and PE 4 are the ASBRs for AS 100 and AS 200, respectively.

· PE 3 and PE 4 are interconnected through MP-EBGP and treat each other as a P device.

· PEs in different ASs establish a multihop MP-EBGP session to advertise VPN-IPv4 routes to each other.

Figure 15 Inter-AS option C mLDP-based MVPN

To implement inter-AS option C mLDP-based MVPN, only one MVPN needs to be created cross all ASs. Multicast data is transmitted across the ASs through this MVPN.

Multicast packets of the VPN instance are delivered as follows:

1. Upon receiving a multicast packet of a multicast group in the VPN instance, CE 1 advertises the RP information for this group to PE 1 as follows:

¡ If the RP is PE 1, CE 1 directly sends a register message to PE 1 to advertise the RP information.

¡ If the RP is CE 1 or CE 2, CE 1 advertises the RP information to PE 1 through MSDP or Anycast-RP depending on the actual configuration.

2. PE 1 sends a source-active A-D route to PE 2 through BGP.

3. PE 2 sends a C-multicast route to join the multicast group if it has a receiver attached. The C-multicast route will be advertised to PE 1 through BGP.

4. PE 1 encapsulates the multicast packet into an MPLS packet and then sends the packet to PE 2 through the mLDP tunnel.

5. PE 2 decapsulates the MPLS packet and then sends the multicast packet to CE 2.

Basic concepts in BIER

BIER domain and BIER sub-domain

All BFRs in a network are referred to as a BIER domain. A BIER domain can contain one or more sub-domains. Each sub-domain is identified by a sub-domain ID. All BFIRs and BFERs in a sub-domain are called BIER edge devices.

BFR ID

A BFR ID uniquely identifies a BIER edge device in a sub-domain. A transit BFR does not need to have a BFR ID.

BFR prefix

A BFR prefix is an IP address that uniquely identifies a BFR in a sub-domain. A BFR prefix must be routable in the sub-domain and can only be the IP address of a loopack interface.

Bit string

A bit string represents a set of BIER edge devices, with each bit corresponding to a BFR ID, starting from the rightmost position. The bit string length (BSL) refers to the number of bits in the bit string. A bit string with three bits can identify a maximum of three BIER edge devices. The BIER edge device with BFR ID is represented as 001.

Set identifier

When the number of BFR IDs is greater than the number of bits in the bit string, the bit string needs to be divided into sets identified by set identifiers (SI). For example, if the maximum BFR ID is 10 in a BIER sub-domain and the bit string length is 4, the bit string needs to be divided into three SIs (SI 0, SI 1, and SI 2). The maximum SI is (Maximum BFR ID–1)/BSL rounded down to the nearest integer.

Bit Index Routing Table

The Bit Index Routing Table (BIRT) is generated based on the BIER information ((sub-domain, BSL, and BFR ID) and routing informtion carried by IGP. The BIRT is used to guide the forwarding of BIER packets in a BIER sub-domain.

Forwarding Bit Mask

The Forwarding Bit Mask (F-BM) represents a set of edge nodes in a BIER sub-domain that are reachable through a BFR neighbor (BFR-NBR). The bit mask is obtained by taking the logical OR of the bit strings of all reachable edge nodes.

Bit Index Forwarding Table

The Bit Index Forwarding Table (BIFT) can guide the per-hop forwarding of multicast traffic in a BIER sub-domain.

The BIFT is used to map from the BFR ID of a BFER to the corresponding F-BM and BFR-NBR. Multiple BIFT can exist on a BFR. Each BIFT is identified by a combination of the BSL, SD, and SI).

How BIER-based MVPN works

BIER-based MVPN operation

BIER-based MVPN encapsulates multicast traffic in a private network and sends it to other nodes in the BIER sub domain.

The multicast source-side PE sends BGP MVPN routes to receiver-side PEs for establishing BIER tunnels. This process is similar to that of RSVP-TE-based MVPN and mLDP-based MVPN except that the Intra-AS I-PMSI A-D route, S-PMSI A-D route, and Leaf A-D route carry BIER information, including BFR ID, Sub domain ID, and BFR prefix. After encapsulating the received private network multicast traffic with Bit String, the PE performs BIER forwarding for the traffic in the public network. For more information about BIER forwarding, see BIER Configuration Guide.

Similar to RSVP-TE-based MVPN and mLDP-based MVPN, in BIER-based MVPN mode, multicast packets of a VPN instance are seamlessly transmitted from a CE to the inclusive tunnel on the PE based on the PIM routing table. These packets are then transmitted to the remote PE through the inclusive tunnel. After receiving the packets, the remote PE decapsulates the packets to get the original private packets. The multicast source-side PE creates selective tunnels when multicast traffic that meets the tunnel switchover criterion arrives.

Inclusive tunnel establishment

As shown in Figure 16, the private network runs PIM, and the public network uses BIER. The inclusive tunnels are established as follows:

1. PE 1 sends an Intra-AS I-PMSI A-D route to PE 2 and PE 3. The route contains the following information:

¡ Route Target—Controls route transmission and receiving. It is configured as the export target of PE 1.

¡ PMSI Tunnel attribute—Transmits tunnel information, where the value for the Tunnel Type field is the BIER tunnel, and the field contains BIER information including Sub domain ID, BFR ID, and BFR prefix for PE 1.

2. Upon receiving the Intra-AS I-PMSI A-D route, PE 2 and PE 3 identify whether the Route Target field matches the Import Target configured in the local VPN instance. If they match, the PEs accept the route and respond with a Leaf A-D route to PE 1. The route contains the following information:

¡ Route Target— Controls route transmission and receiving. It is configured as the export target of PE 2 or PE 3.

¡ PMSI Tunnel attribute—Transmits tunnel information, where the value for the Tunnel Type field is the BIER tunnel. This field contains information about the BFIRs and BFERs in the same sub domain as PE 1. The information is obtained by checking the BFR ID and BFR prefix configured in the local sub domain with an ID same as that in the Intra-AS I-PMSI A-D route sent by PE 1.

3. Upon receiving the Leaf A-D route, PE 1 identifies whether the Route Target field matches the Import Target configured in the local VPN instance. If they match, PE 1 accept the route and marks PE 2 and PE 3 as members of the MVPN. At the same time, PE 1 obtains the SI based on the BFR ID in the route and the value of the BSL in the BIER sub domain. Then PE 1 combines information about all leaf nodes and generates bit string for the (S, G) entry to establish an inclusive tunnel.

Figure 16 Inclusive tunnel establishment

Selective tunnel establishment and tunnel switchover

BIER-based MVPN supports switchover from the inclusive tunnel to selective tunnels to off-load traffic for specific (S, G) entries from the inclusive tunnel. An MVPN can have multiple selective tunnels.

As shown in Figure 17, the process of selective tunnel creation and the tunnel switchover is as follows:

1. PE 1 sends an S-PMSI A-D route to PE 2 and PE 3. The route contains the following information:

¡ Route Target—Controls route transmission and receiving. It is configured as the export target of PE 1.

2. Upon receiving the S-PMSI A-D route, PE 2 and PE 3 identify whether the Route Target field matches the Import Target configured in the local VPN instance. If they match, the PEs accept the route and if a downstream receiver exists, the two PEs respond with a Leaf A-D route to PE 1. The route contains the following information:

¡ Route Target— Controls route transmission and receiving. It is configured as the export target of PE 2 or PE 3.

Figure 17 Selective tunnel establishment and tunnel switchover

‌

Inter-AS BIER-based MVPN

In an inter-AS VPN networking scenario, VPN sites are located in multiple ASs. These sites must be interconnected. Inter-AS VPN provides the following solutions:

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

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

For more information about the three inter-AS VPN solutions, see MPLS L3VPN configuration in MPLS Configuration Guide.

Inter-AS option A BIER-based MVPN

As shown in Figure 18:

· A VPN instance spans AS 100 and AS 200.

· PE 3 and PE 4 are ASBRs for AS 100 and AS 200, respectively.

· PE 3 and PE 4 are interconnected through their respective VPN instance and treat each other as a CE.

Figure 18 Inter-AS option A BIER-based MVPN

To implement inter-AS option A mLDP-based MVPN, a separate MVPN must be created in each AS. Multicast data of the VPN instance is transmitted across the ASs through the separate MVPNs in each AS.

Multicast packets of the VPN instance are delivered as follows:

1. CE 1 forwards a multicast packet of VPN instance 1 to PE 1.

2. PE 1 encapsulates the multicast packet into an MPLS packet and forwards it to PE 3 through BIER tunnel 1.

3. PE 3 considers PE 4 as a CE of MVPN 1, so PE 3 decapsulates the MPLS packet and forwards the multicast packet to PE 4.

4. PE 4 considers PE 2 as a CE of MVPN 2, so PE 4 encapsulates the multicast packet into an MPLS packet and then forwards the packet to PE 2 through BIER tunnel 2.

5. PE 2 decapsulates the MPLS packet and then forwards the multicast packet to CE 2.

Inter-AS option C BIER-based MVPN

As shown in Figure 19:

· A VPN instance spans AS 100 and AS 200.

· PE 3 and PE 4 are the ASBRs for AS 100 and AS 200, respectively.

· PE 3 and PE 4 are interconnected through MP-EBGP and treat each other as a P device.

· PEs in different ASs establish a multihop MP-EBGP session to advertise VPN-IPv4 routes to each other.

Figure 19 Inter-AS option C BIER-based MVPN

To implement inter-AS option C mLDP-based MVPN, only one MVPN needs to be created cross all ASs. Multicast data is transmitted across the ASs through this MVPN.

Multicast packets of the VPN instance are delivered as follows:

1. Upon receiving a multicast packet of a multicast group in the VPN instance, CE 1 advertises the RP information for this group to PE 1 as follows:

¡ If the RP is PE 1, CE 1 directly sends a register message to PE 1 to advertise the RP information.

¡ If the RP is CE 1 or CE 2, CE 1 advertises the RP information to PE 1 through MSDP or Anycast-RP depending on the actual configuration.

2. PE 1 sends a source-active A-D route to PE 2 through BGP.

3. PE 2 sends a C-multicast route to join the multicast group if it has a receiver attached. The C-multicast route will be advertised to PE 1 through BGP.

4. PE 1 encapsulates the multicast packet into an MPLS packet and then sends the packet to PE 2 through the BIER tunnel.

5. PE 2 decapsulates the MPLS packet and then sends the multicast packet to CE 2.

MVPN extranet

MVPN extranet implements inter-VPN multicast traffic transmission. In MVPN extranet, the multicast source and receivers are in different VPNs. In actual application, the MVPN extranet solution ensures that the service provider in a VPN provides multicast services for users in other VPNs.

The following terms are used in the MVPN extranet solution:

· Source VPN instance—VPN instance to which the multicast source belongs.

· Receiver VPN instance—VPN instance to which the multicast receiver belongs.

· Source PE—PE directly connected to the multicast source.

· Receiver PE—PE directly connected to multicast receivers.

As shown in Figure 20, multicast source Source 1 is in Site 1 of VPN A. Receiver 1 and Receiver 2 are located in Site 2 of VPN A and Site 1 of VPN B, respectively. MVPN enables Receiver 1 to receive multicast data from Source 1, and MVPN extranet enables Receiver 2 to receive multicast data from Source 1.

The MVPN extranet solution can be implemented through the source-PE-based MVPN extranet option or the receiver-PE-based MVPN extranet option.

Figure 20 MVPN extranet

Source-PE-based MVPN extranet option

To use this option, create a receiver VPN instance on the source PE and specify a default group for this VPN instance. The default group for the receiver VPN instance must be the same as the default group specified on other PEs in this VPN instance.

This option is available only in MDT-based MVPN.

As shown in Figure 21, perform the following tasks:

1. For multicast traffic transmission from Site 1 to Site 2, configure MVPN for VPN A on PE 1 and PE 2.

2. For multicast traffic transmission from Site 1 to Site 3, create VPN B and configure MVPN for VPN B on PE 1.

3. Configure an MVPN extranet RPF selection policy for VPN B on PE 1.

Figure 21 Source-PE-based MVPN extranet option

When Receiver 2 in VPN B joins the multicast group that matches the policy, multicast packets from Source 1 are transmitted as follows:

1. PE 1 replicates and encapsulates the packets for VPN A and VPN B and forwards them.

2. The packets travel along default MDTs of VPN A and VPN B and arrive at PE 2 and PE 3.

3. PE 2 and PE 3 decapsulate and forward the packets to receivers.

Receiver-PE-based MVPN extranet option

To use this option, create a source VPN instance on the receiver PE and specifies a default group for this VPN instance. The default group for the source VPN instance must be the same as the default group specified on other PEs in this VPN instance.

This option is available in MDT-based MVPN, RSVP-TE-based MVPN, and mLDP-based MVPN. This example uses MDT-based MVPN.

As shown in Figure 22, configure PEs as follows:

1. For multicast traffic transmission from Site 1 to Site 2, configure MVPN for VPN A on PE 1 and PE 2.

2. For multicast traffic transmission from Site 1 to Site 3, create VPN A and configure MVPN for VPN A on PE 3.

3. Configure an MVPN extranet RPF selection policy for VPN B on PE 3.

Figure 22 Receiver-PE-based MVPN extranet option

When Receiver 2 in VPN B joins the multicast group that matches the RPF selection policy, multicast packets from Source 1 are encapsulated on PE 1 and transmitted along the default MDT.

· When the packets arrive at PE 2, PE 2 decapsulates the packets and forwards them to Receiver 1.

· When the packets arrive at PE 3, PE 3 decapsulates the packets and forwards them to Receiver 2 based on the MVPN extranet RPF selection policy.

M6VPE

Only mLDP-based M6VPE is supported in the current software version.

The multicast IPv6 VPN provider edge (M6VPE) feature enables PEs to transmit IPv6 multicast traffic of a VPN instance over the public network. Only the IPv4 network is available for the backbone network.

As shown in Figure 23, the public network runs IPv4 protocols, and sites of VPN instance VPN A run IPv6 multicast protocols. To transmit IPv6 multicast traffic between CE 1 and CE 2, configure M6VPE on the PEs.

Figure 23 M6VPE network

IPv6 multicast traffic forwarding over the IPv4 public network is as follows:

1. CE 1 forwards an IPv6 multicast packet for VPN instance VPN A to PE 1.

2. PE 1 encapsulates the IPv6 multicast packet with an IPv4 packet header and transmits the IPv4 packet in the IPv4 backbone network.

3. PE 2 decapsulates the IPv4 packet and forwards the IPv6 multicast packet to CE 2.

Protocols and standards

· RFC 6037, Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs

· RFC 6513, Multicast in MPLS/BGP IP VPNs

· RFC 6514, BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs

Configuring multicast VPN

Restrictions and guidelines: Multicast VPN configuration

The MTIs take effect only after the default group and the MVPN source interface are specified and the MVPN source interface obtains an public IP address.

The PIM mode on an MTI must be the same as the PIM mode running on the VPN instance to which the MTI belongs. When a minimum of one interface on the VPN instance is enabled with PIM, the MTI is enabled with PIM accordingly. When all interfaces on the VPN instance are disabled with PIM, PIM is also disabled on the MTI.

Configure multicast VPN on PEs.

Multicast VPN tasks at a glance

MDT-based MVPN tasks at a glance

To configure MDT-based MVPN, perform the following tasks:

1. Configuring MDT-based MVPN

a. Enabling IP multicast routing for a VPN instance

b. Creating an MDT-based MVPN instance

c. Creating an MVPN address family

d. Specifying the default group

e. Specifying the MVPN source interface

f. (Optional.) Configuring MDT switchover parameters

g. (Optional.) Configuring the RPF vector feature

h. (Optional.) Enabling data group reuse logging

2. Configuring BGP MDT

If PIM-SSM is running on the public network, you must configure BGP MDT.

a. Configuring BGP MDT peers or peer groups

b. (Optional.) Limiting BGP MDT routes received from a peer or peer group

c. (Optional.) Configuring a BGP MDT route reflector

d. (Optional.) Configuring BGP MDT optimal route selection delay

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

RSVP-TE-based MVPN tasks at a glance

To configure RSVP-TE-based MVPN, perform the following tasks on PEs:

1. Enabling IP multicast routing for a VPN instance

2. Configuring BGP IPv4 MVPN route exchange

3. Allowing the device to add extended community attributes to C-multicast routes sent to BGP VPNv4 peers

4. Creating an RSVP-TE-based MVPN instance

5. Creating an MVPN IPv4 address family

6. Specifying the MVPN source interface

7. Enabling inclusive tunnel creation

8. (Optional.) Enabling selective tunnel creation

9. (Optional.) Setting the tunnel switchover delay

mLDP-TE-based MVPN tasks at a glance

To configure mLDP-based MVPN, perform the following tasks on PEs:

1. Enabling IP multicast routing for a VPN instance

2. Configuring BGP IPv4 MVPN route exchange

3. Configuring BGP IPv6 MVPN route exchange

4. Allowing the device to add extended community attributes to C-multicast routes sent to BGP VPNv4 peers

5. Allowing the device to add extended community attributes to C-multicast routes sent to BGP VPNv6 peers

6. Creating an mLDP-based MVPN instance

7. Creating an MVPN IPv4 address family

8. Specifying the MVPN source interface

9. Enabling inclusive tunnel creation

10. (Optional.) Enabling selective tunnel creation

11. (Optional.) Setting the tunnel switchover delay

12. (Optional.) Enabling inter-AS auto-discovery

BIER-based MVPN tasks at a glance

To configure BIER-based MVPN, perform the following tasks on PEs:

1. Enabling IP multicast routing for a VPN instance

2. Configuring BGP IPv4 MVPN route exchange

3. Configuring BGP IPv6 MVPN route exchange

4. Allowing the device to add extended community attributes to C-multicast routes sent to BGP peers

5. Creating a BIER-based MVPN instance

6. Creating an MVPN IPv4 address family

7. Specifying the MVPN source interface

8. Enabling IPv6 underlay for MVPN

9. Configuring multicast service prefix information

10. Specifying the multicast service source address

11. (Optional.) Enabling inclusive tunnel creation

12. (Optional.) Enabling selective tunnel creation

13. (Optional.) Setting the tunnel holddown timer

14. (Optional.) Enabling inter-AS auto-discovery

15. (Optional.) Configuring FRR

Configuring MDT-based MVPN

Prerequisites for configuring MDT-based MVPN

Before you configure MDT-based MVPN, complete the following tasks:

· Configure a unicast routing protocol on the public network.

· Configure MPLS L3VPN on the public network.

· Configure PIM-DM, PIM-SM or PIM-SSM on the public network.

Enabling IP multicast routing for a VPN instance

1. Enter system view.

system-view

2. Create a VPN instance and enter its view.

ip vpn-instance vpn-instance-name

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

3. Configure an RD for the VPN instance.

route-distinguisher route-distinguisher

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

4. Return to system view.

quit

5. Enter interface view.

interface interface-type interface-number

6. Associate the interface with the VPN instance.

ip binding vpn-instance vpn-instance-name

By default, an interface is associated with no VPN instance and belongs to the public network.

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

7. Return to system view.

quit

8. Enable IP multicast routing for the VPN instance and enter MRIB view of the VPN instance.

multicast routing vpn-instance vpn-instance-name

By default, IPv4 multicast routing is disabled for a VPN instance.

For more information about this command, see IP Multicast Command Reference.

Creating an MDT-based MVPN instance

About this task

To provide multicast services for a VPN instance, you must create an MDT-based MVPN instance on PEs that belong to the VPN instance. After the MVPN instance is created, the system automatically creates MTIs and binds them with the VPN instance.

You can create one or more MDT-based MVPN instances on a PE.

Procedure

1. Enter system view.

system-view

2. Create an MDT-based MVPN instance and enter MVPN view.

multicast-vpn vpn-instance vpn-instance-name mode mdt

Creating an MVPN address family

About this task

You must create an MVPN IPv4 address family for a VPN instance before you can perform other MVPN VPN configuration tasks for the VPN instance. For a VPN instance, configurations in MVPN IPv4 address family view applies to IPv4 multicast packets of the instance.

Procedure

1. Enter system view.

system-view

2. Enter MVPN view of a VPN instance.

multicast-vpn vpn-instance vpn-instance-name mode mdt

3. Create an MVPN address family and enter MVPN address family view.

address-family ipv4

Specifying the default group

Restrictions and guidelines

You must specify the same default group on all PEs that belong to the same MVPN.

The default group for an MVPN must be different from the default group and the data group used by any other MVPN.

For an MVPN that transmits both IPv4 and IPv6 multicast packets, you must specify the same default group in MVPN IPv4 address family view and IPv6 address family view.

Procedure

1. Enter system view.

system-view

2. Enter MVPN view.

multicast-vpn vpn-instance vpn-instance-name mode mdt

3. Enter MVPN address family view.

address-family ipv4

4. Specify the default group.

default-group group-address

Specifying the MVPN source interface

About this task

An MTI of a VPN instance uses the IP address of the MVPN source interface as the source address to encapsulate multicast packets for the VPN instance.

Restrictions and guidelines

For the PE to obtain correct routing information, you must specify the interface used for establishing BGP peer relationship as the MVPN source interface.

The MTI takes effect only after the default group and MVPN source interface are specified and the MTI obtains the public IP address of the MVPN source interface.

The MVPN source interface can be configured to borrow the IP address of a loopback interface. As a best practice, specify the mask length for the loopback interface address as 32.

To use IP unnumbered, you must also configure OSPF, IS-IS, and LLDP. For information about configuring OSPF, IS-IS, and LLDP, see "Configuring PIM."

Procedure

1. Enter system view.

system-view

2. Enter MVPN view.

multicast-vpn vpn-instance vpn-instance-name mode mdt

3. Enter MVPN address family view.

address-family ipv4

4. Specify the MVPN source interface.

source interface-type interface-number

By default, no MVPN source interface is specified.

Configuring MDT switchover parameters

About this task

In some cases, the traffic rate of the private network multicast data might fluctuate around the MDT switchover threshold. To avoid frequent switching of multicast traffic between the default MDT and the data MDT, you can specify a data-delay period and a data hold-down period.

· MDT switchover does not take place immediately after the multicast traffic rate exceeds the switchover threshold. It takes place after a data-delay period, during which the traffic rate must stay higher than the switchover threshold.

· Likewise, a backward switchover does not take place immediately after the multicast traffic rate drops below the MDT switchover threshold. It takes place after a data hold-down period, during which the traffic rate must stay lower than the switchover threshold.

Restrictions and guidelines

On a PE, the data group range for an MVPN cannot include the default group or data groups of any other MVPN.

All VPN instances share the data group resources. As a best practice to avoid data group resource exhaustion, specify a reasonable data group range for a VPN instance.

If the public network runs PIM-SSM, the data group range for an MVPN on a PE can overlap with data group ranges for other MDs on other PEs.

Procedure

1. Enter system view.

system-view

2. Enter MVPN view.

multicast-vpn vpn-instance vpn-instance-name mode mdt

3. Enter MVPN address family view.

address-family ipv4

4. Configure the data group range and the switchover criteria.

data-group group-address { mask-length | mask } [ threshold threshold-value | acl acl-number ] *

By default, no data group range exists, and the device never initiates a switchover of the default MDT to a data MDT.

5. Set the data-delay period.

data-delay delay

By default, the data-delay period is 3 seconds.

6. Set the data hold-down period.

data-holddown delay

By default, the data hold-down period is 60 seconds.

Configuring the RPF vector feature

About this task

This feature enables the device to insert the RPF vector (IP address of the ASBR in the local AS) in PIM join messages for other devices to perform RPF check.

Restrictions and guidelines

Perform this task on PEs that have attached receivers.

For the device to work with other manufacturers' products on the RPF vector, you must enable RPF vector compatibility for all H3C P devices and H3C PE devices on the public network.

Procedure

1. Enter system view.

system-view

2. Enter MRIB view of a VPN instance.

multicast routing vpn-instance vpn-instance-name

3. Enable the RPF vector feature.

rpf proxy vector

By default, the RPF vector feature is disabled.

4. Return to system view.

quit

5. Enable RPF vector compatibility.

multicast rpf-proxy-vector compatible

By default, RPF vector compatibility is disabled.

Enabling data group reuse logging

About this task

For a given VPN, the number of VPN multicast streams to be switched over to data MDTs might exceed the number of addresses in the data group range. In this case, the VPN instance on the source-side PE can reuse the addresses in the address range. With data group reuse logging enabled, the address reuse information will be logged. Perform this task on PEs.

The group address reuse logging information has a severity level informational. For more information about the logging information, see Network Management and Monitoring Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter MVPN view.

multicast-vpn vpn-instance vpn-instance-name mode mdt

3. Enter MVPN address family view.

address-family ipv4

4. Enable data group reuse logging.

log data-group-reuse

By default, data group reuse logging is disabled.

Configuring BGP MDT

Configuring BGP MDT peers or peer groups

About this task

Perform this task so that the PE can exchange MDT information with the BGP peer or peer group. MDT information includes the IP address of the PE and default group to which the PE belongs. On a public network running PIM-SSM, the multicast VPN establishes a default MDT rooted at the PE (multicast source) based on the MDT information.

Prerequisites

Before you configure a BGP MDT peer or peer group, you must create a BGP peer or peer group in BGP instance view. For more information about creating a BGP peer or peer group, see BGP configuration in Layer 3—IP Routing Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Create a BGP IPv4 MDT address family and enter its view.

address-family ipv4 mdt

By default, no BGP IPv4 address family exists.

4. Enable the device to exchange MDT routing information with the BGP peer or the peer group.

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

By default, the device cannot exchange BGP MDT routing information with a BGP peer or peer group.

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

Limiting BGP MDT routes received from a peer or peer group

About this task

This feature can prevent attacks that send a large number of BGP MDT routes to the router.

If the number of routes received from a peer or peer group exceeds the upper limit, the router takes one of the following actions based on your configuration:

· Tears down the BGP session to the peer or peer group and does not attempt to re-establish the session.

· Continues to receive routes from the peer or peer group and generates a log message.

· Retains the session to the peer or peer group, but it discards excess routes and generates a log message.

· Tears down the BGP session to the peer or peer group and, after a specific period of time, re-establishes a BGP session to the peer or peer group.

You can specify a percentage threshold for the router to generate a log message. When the ratio of the number of received routes to the maximum number reaches the percentage value, the router generates a log message.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 MDT address family view.

address-family ipv4 mdt

4. Specify the maximum number of BGP MDT routes that a router 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 BGP MDT routes that a router can receive from a peer or peer group is not limited.

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

Configuring a BGP MDT route reflector

About this task

· Configuring a BGP MDT route reflector—BGP MDT peers in the same AS must be fully meshed to maintain connectivity. However, when multiple BGP MDT peers exist in an AS, connection establishment among them might result in increased costs. To reduce connections between BGP MDT peers, you can configure one of them as a route reflector and specify other devices as clients.

· Disabling routing reflection between clients—When clients establish BGP MDT connections with the route reflector, the route reflector forwards (or reflects) BGP MDT routing information between clients. The clients are not required to be fully meshed. To save bandwidth if the clients have been fully meshed, you can disable the routing reflection between clients by using the undo reflect between-clients command.

· Configuring the cluster ID of the route reflector—The route reflector and its clients form a cluster. Typically, a cluster has only one route reflector whose router ID identifies the cluster. However, you can configure several route reflectors in a cluster to improve network reliability. To avoid routing loops, make sure the route reflectors in a cluster have the same cluster ID.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 MDT address family view.

address-family ipv4 mdt

4. Configure the device as a route reflector and specify its peers or peer groups as clients.

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

By default, neither route reflectors nor clients exist.

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

undo reflect between-clients

By default, route reflection between clients is disabled.

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

6. (Optional.) Configure the cluster ID of the route reflector.

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

By default, a route reflector uses its router ID as the cluster ID.

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

Configuring BGP MDT optimal route selection delay

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 MDT address family view.

address-family ipv4 mdt

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

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

Preferring routes learned from the specified peer or peer group during optimal route selection

About this task

Routes learned from the specified peer or peer group take precedence over routes learned from other peers or peer groups if these routes have the same prefix. BGP uses this rule to continue route selection if it fails to select an optimal route by using the peer type selection rule. If BGP still fails route selection, it uses the IGP metric selection rule to select an optimal route.

Procedure

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Enter BGP IPv4 MDT address family view.

address-family ipv4 mdt

4. 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, BGP does not prefer routes learned from any peer or peer groups during optimal route selection.

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

Configuring RSVP-TE-based MVPN

Restrictions and guidelines for RSVP-TE-based MVPN

This feature is available only for the following cards:

Card category	Cards
CEPC	CEPC-XP4LX, CEPC-XP24LX, CEPC-XP48RX, CEPC-CP4RX, CEPC-CP4RXA, CEPC-CP4RX-L, CEPC-CQ8L, CEPC-CQ8LA, CEPC-CQ8L1A, CEPC-CQ16L1
CSPEX	CSPEX-1304X, CSPEX-1404X, CSPEX-1502X, CSPEX-1504X, CSPEX-1504XA, CSPEX-1602X, CSPEX-1602XA, CSPEX-1804X, CSPEX-1512X, CSPEX-1612X, CSPEX-1812X, CSPEX-1802X, CSPEX-1802XA, CSPEX-2612XA, CSPEX-1812X-E, CSPEX-2304X-G, CSPEX-1502XA, CSPEX-1104-E
SPE	RX-SPE200, RX-SPE200-E

Prerequisites for configuring RSVP-TE-based MVPN

Before you configure RSVP-TE-based MVPN, complete the following tasks:

· Configure a unicast routing protocol on the public network.

· Configure MPLS TE and RSVP on the public network.

· Configure BGP to enable PEs to mutually establish neighbor relationship.

Enabling IP multicast routing for a VPN instance

1. Enter system view.

system-view

2. Create a VPN instance and enter its view.

ip vpn-instance vpn-instance-name

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

3. Configure an RD for the VPN instance.

route-distinguisher route-distinguisher

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

4. Return to system view.

quit

5. Enter interface view.

interface interface-type interface-number

6. Associate the interface with the VPN instance.

ip binding vpn-instance vpn-instance-name

By default, an interface is associated with no VPN instance and belongs to the public network.

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

7. Return to system view.

quit

8. Enable IP multicast routing for the VPN instance and enter MRIB view of the VPN instance.

IPv4:

multicast routing vpn-instance vpn-instance-name

By default, IPv4 multicast routing is disabled for a VPN instance.

For more information about this command, see IP Multicast Command Reference.

Configuring BGP IPv4 MVPN route exchange

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify a BGP MVPN peer and its AS number.

peer ipv4-address as-number as-number

4. Enter BGP IPv4 MVPN address family view.

address-family ipv4 mvpn

5. Enable BGP to exchange IPv4 unicast routing information with dynamic BGP peers.

peer ipv4-address mask-length enable

By default, BGP cannot exchange IPv4 unicast routing information with dynamic BGP peers.

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

6. (Optional.) Specify the maximum number of routes that a router 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 a router can receive from a peer or peer group is not limited.

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

7. (Optional.) Configure the BGP Additional Paths feature.

a. Configure the BGP Additional Paths capabilities.

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

By default, no BGP Additional Paths capabilities are configured

b. 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, a maximum number of one Add-Path optimal route can be advertised to a peer or peer group.

c. Set the maximum number of Add-Path optimal routes that can be advertised to all peers.

additional-paths select-best best-number

By default, a maximum number of one Add-Path optimal route can be advertised to all peers.

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

8. (Optional.) Advertise the COMMUNITY or Large Community attribute to a peer or peer group.

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

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

By default, the COMMUNITY attribute advertisement to a peer or peer group is disabled.

¡ Advertise the Large Community attribute to a peer or peer group.

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

By default, the Large Community attribute advertisement to a peer or peer group is disabled.

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

9. (Optional.) Disable route target filtering of received BGP IPv4 MVPN routes.

undo policy vpn-target

By default, a PE device filters route targets for received BGP IPv4 MVPN routes.

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

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

11. 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, BGP does not prefer routes learned from any peer or peer groups during optimal route selection.

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

Allowing the device to add extended community attributes to C-multicast routes sent to BGP VPNv4 peers

About this task

The following BGP extended community attributes are used to identify the route originator of a BGP VPNv4 route:

· Source AS—Carries the number of AS where the MVPN source resides. The format of this attribute is 32-bit AS number:0, for example, 100:0.

· VRF Route Import—Carries the originating address and the VPN instance to which the BGP VPNv4 route belongs. The format of the attribute is 32-bit originating address:VPN instance index, for example, 192.168.122.15:1. The value of the originating address depends on the MVPN source interface configuration.

¡ If the source command is used to specify the MVPN source interface, the originating address is the IP address of the MVPN source interface.

¡ If the source command is not used, the originating address is the router ID of the BGP instance to which the device belongs.

Prerequisites

Before you perform this task, you must establish BGP VPNv4 peer relationship and BGP IPv4 MVPN neighbor relationship between the device and other devices.

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

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

4. Allow the device to add Source AS and VRF Route Import extended community attributes to routes sent to BGP VPNv4 peers.

mvpn-advertise-rt-import

By default, the device is disabled from adding Source AS and RF Route Import extended community attributes to routes sent to BGP VPNv4 peers.

Creating an RSVP-TE-based MVPN instance

About this task

You can create one or more RSVP-TE-based MVPN instances on a PE device.

A VPN instance supports only one MVPN mode.

Procedure

1. Enter system view.

system-view

2. Create an RSVP-TE-based MVPN instance and enter its view.

multicast-vpn vpn-instance vpn-instance-name mode rsvp-te

Creating an MVPN IPv4 address family

Restrictions and guidelines

Configurations in MVPN IPv4 address family view apply only to IPv4 multicast.

Procedure

1. Enter system view.

system-view

2. Enter MVPN view.

multicast-vpn vpn-instance vpn-instance-name mode rsvp-te

3. Create an MVPN IPv4 address family and enter its view.

address-family ipv4

Specifying the MVPN source interface

About this task

An RSVP tunnel uses the IP address of the MVPN source interface as the source address to encapsulate multicast packets from the private network.

Restrictions and guidelines

For the PE to obtain correct routing information, you must specify the interface used for establishing BGP peer relationship as the MVPN source interface.

The MVPN source interface can be configured to borrow the IP address of a loopback interface. As a best practice, specify the mask length for the loopback interface address as 32.

To use IP unnumbered, you must also configure OSPF, IS-IS, and LLDP. For information about configuring OSPF, IS-IS, and LLDP, see "Configuring PIM."

Procedure

1. Enter system view.

system-view

2. Enter MVPN view.

multicast-vpn vpn-instance vpn-instance-name mode rsvp-te

3. Enter MVPN IPv4 address family view.

address-family ipv4

4. Specify the MVPN source interface.

source interface-type interface-number

By default, no MVPN source interface is specified.

Enabling inclusive tunnel creation

Restrictions and guidelines

Once created, the inclusive tunnel always exists whether the multicast traffic is present or not.

Only one inclusive tunnel can be established between two PEs in an MVPN.

Procedure

1. Enter system view.

system-view

2. Enter MVPN view.

multicast-vpn vpn-instance vpn-instance-name mode rsvp-te

3. Enter MVPN IPv4 address family view.

address-family ipv4

4. Enable dynamic inclusive tunnel creation.

inclusive-tunnel dynamic

By default, dynamic inclusive tunnel creation is disabled.

Enabling selective tunnel creation

About this task

Multicast traffic that matches the tunnel switchover criterion is switched over to selective tunnels from the inclusive tunnel after selective tunnel are created.

Restrictions and guidelines

Selective tunnels are created only after the multicast traffic is transmitted over the inclusive tunnel.

Multicast packets of multiple (S, G) entries can share one selective tunnel.

Multiple selective tunnels can be created between two PEs in an MVPN. These selective tunnels are independent from one another.

Procedure

1. Enter system view.

system-view

2. Enter MVPN view.

multicast-vpn vpn-instance vpn-instance-name mode rsvp-te

3. Enter MVPN IPv4 address family view.

address-family ipv4

4. Enable dynamic selective tunnel creation.

selective-tunnel dynamic [ acl { ipv4-acl-number | name ipv4-acl-name } ]

By default, dynamic selective tunnel creation is disabled.

Setting the tunnel switchover delay

About this task

To avoid multicast data loss during tunnel switchover, adjust the delay time for multicast data to switch over from the inclusive tunnel to selective tunnels.

Procedure

1. Enter system view.

system-view

2. Enter MVPN view.

multicast-vpn vpn-instance vpn-instance-name mode rsvp-te

3. Enter MVPN IPv4 address family view.

address-family ipv4

4. Set the tunnel switchover delay.

selective-tunnel delay delay

By default, the tunnel switchover delay is 3 seconds.

Configuring mLDP-based MVPN

Restrictions and guidelines for mLDP-based MVPN

This feature is available only for the following cards:

Card category	Cards
CEPC	CEPC-XP4LX, CEPC-XP24LX, CEPC-XP48RX, CEPC-CP4RX, CEPC-CP4RXA, CEPC-CP4RX-L, CEPC-CQ8L, CEPC-CQ8LA, CEPC-CQ8L1A, CEPC-CQ16L1
CSPEX	CSPEX-1304X, CSPEX-1404X, CSPEX-1502X, CSPEX-1504X, CSPEX-1504XA, CSPEX-1602X, CSPEX-1602XA, CSPEX-1804X, CSPEX-1512X, CSPEX-1612X, CSPEX-1812X, CSPEX-1802X, CSPEX-1802XA, CSPEX-2612XA, CSPEX-1812X-E, CSPEX-2304X-G, CSPEX-1502XA, CSPEX-1104-E
SPE	RX-SPE200, RX-SPE200-E

Prerequisites for configuring mLDP-based MVPN

Before you configure mLDP-based MVPN, complete the following tasks:

· Configure a unicast routing protocol on the public network.

· Configure MPLS LDP on the public network.

· Configure BGP to enable PEs to mutually establish neighbor relationship.

Enabling IP multicast routing for a VPN instance

1. Enter system view.

system-view

2. Create a VPN instance and enter its view.

ip vpn-instance vpn-instance-name

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

3. Configure an RD for the VPN instance.

route-distinguisher route-distinguisher

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

4. Return to system view.

quit

5. Enter interface view.

interface interface-type interface-number

6. Associate the interface with the VPN instance.

ip binding vpn-instance vpn-instance-name

By default, an interface is associated with no VPN instance and belongs to the public network.

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

7. Return to system view.

quit

8. Enable IP multicast routing for the VPN instance and enter MRIB view of the VPN instance.

IPv4:

multicast routing vpn-instance vpn-instance-name

By default, IP multicast routing is disabled for a VPN instance.

For more information about the commands, see multicast routing and forwarding commands in IP Multicast Command Reference.

Configuring BGP IPv4 MVPN route exchange

1. Enter system view.

system-view

2. Enter BGP instance view.

bgp as-number [ instance instance-name ]

3. Specify a BGP MVPN peer and its AS number.

peer ipv4-address as-number as-number

4. Enter BGP IPv4 MVPN address family view.

address-family ipv4 mvpn

5. Enable BGP to exchange IPv4 unicast routing information with BGP peers.

peer ipv4-address enable

By default, BGP cannot exchange IPv4 unicast routing information with BGP peers.