MVPN IP allows a service provider to configure and support multicast traffic in an MPLS VPN environment. This feature supports routing and forwarding of multicast packets for each individual VRF instance, and it also provides a mechanism to transport VPN multicast packets across the service provider backbone.

A VPN is network connectivity across a shared infrastructure, such as an ISP. Its function is to provide the same policies and performance as a private network, at a reduced cost of ownership, thus creating many opportunities for cost savings through operations and infrastructure.

An MVPN allows an enterprise to transparently interconnect its private network across the network backbone of a service provider. The use of an MVPN to interconnect an enterprise network in this way does not change the way that enterprise network is administered, nor does it change general enterprise connectivity.

• Provides a scalable method to dynamically send information to multiple locations.

• Provides high-speed information delivery.

• Provides connectivity through a shared infrastructure.

MVPN introduces multicast routing information to the VPN routing and forwarding table. When a provider edge (PE) device receives multicast data or control packets from a customer edge (CE) router, forwarding is performed according to the information in the Multicast VPN routing and forwarding instance (MVRF). MVPN does not use label switching.

A set of MVRFs that can send multicast traffic to each other constitutes a multicast domain. For example, the multicast domain for a customer that wanted to send certain types of multicast traffic to all global employees would consist of all CE routers associated with that enterprise.

MVPN establishes a static default MDT for each multicast domain. The default MDT defines the path used by PE routers to send multicast data and control messages to every other PE router in the multicast domain.

If Source Specific Multicast (SSM) is used as the core multicast routing protocol, then the multicast IP addresses used for the default and data multicast distribution tree (MDT) must be configured within the SSM range on all PE routers.

MVPN also supports the dynamic creation of MDTs for high-bandwidth transmission. Data MDTs are a feature unique to Cisco IOS software. Data MDTs are intended for high-bandwidth sources such as full-motion video inside the VPN to ensure optimal traffic forwarding in the MPLS VPN core. The threshold at which the data MDT is created can be configured on a per-router or a per-VRF basis. When the multicast transmission exceeds the defined threshold, the sending PE router creates the data MDT and sends a User Datagram Protocol (UDP) message, which contains information about the data MDT to all routers on the default MDT. The statistics to determine whether a multicast stream has exceeded the data MDT threshold are examined once every second. After a PE router sends the UDP message, it waits 3 more seconds before switching over; 13 seconds is the worst case switchover time and 3 seconds is the best case.

Data MDTs are created only for (S, G) multicast route entries within the VRF multicast routing table. They are not created for (*, G) entries regardless of the value of the individual source data rate.

In the following example, a service provider has a multicast customer with offices in San Jose, New York, and Dallas. A one-way multicast presentation is occurring in San Jose. The service provider network supports all three sites associated with this customer, in addition to the Houston site of a different enterprise customer.

The default MDT for the enterprise customer consists of provider routers P1, P2, and P3 and their associated PE routers. PE4 is not part of the default MDT, because it is associated with a different customer. The figure shows that no data flows along the default MDT, because no one outside of San Jose has joined the multicast.

An employee in New York joins the multicast session. The PE router associated with the New York site sends a join request that flows across the default MDT for the multicast domain of the customer. PE1, the PE router associated with the multicast session source, receives the request. The figure depicts that the PE router forwards the request to the CE router associated with the multicast source (CE1a).

The CE router (CE1a) begins to send the multicast data to the associated PE router (PE1), which sends the multicast data along the default MDT. Through default MDT, traffic from CE1a is sent to all the PEs. Immediately sending the multicast data, PE1 recognizes that the multicast data exceeds the bandwidth threshold for which a data MDT should be created. Therefore, PE1 creates a data MDT, sends a message to all routers using the default MDT that contains information about the data MDT, and, three seconds later, begins sending the multicast data for that particular stream using the data MDT. Only PE2 has interested receivers for this source, so only PE2 will join the data MDT and receive traffic on it.

The other PE routers also receive traffic from the default MDT.

PE routers maintain a PIM relationship with other PE routers over the default MDT and a PIM relationship with its directly attached PE routers.

An MVRF, which is created per multicast domain, requires the device to create a tunnel interface from which all MVRF traffic is sourced. A multicast tunnel interface is an interface that the MVRF uses to access the multicast domain. It can be thought of as a conduit that connects an MVRF and the global MVRF. One tunnel interface is created per MVRF.

The mdt keyword has been added to the address-family ipv4 command to configure an MDT address-family session. MDT address-family sessions are used to pass the source PE address and MDT group address to PIM using Border Gateway Protocol (BGP) MDT Subaddress Family Identifier (SAFI) updates.

OIF stat in a native multicast setup implements an extra output to include the packet count sent over the (S,G) entry and the traffic rate.

• Per-prefix OIF stats are supported on BDI and routed interfaces on the RSP2 module

router#show ip mfib 203.0.0.1
/* OIF Stats - BDI */
 (192.1.1.2,203.0.0.1) Flags: HW
   SW Forwarding: 1/0/1478/0, Other: 0/0/0
   HW Forwarding:   4983/34/1478/397, Other: 0/0/0
   BDI100 Flags: A
   BDI20 Flags: F NS
     Pkts: 5235/0/0    Rate: 34 pps

/* OIF Stats - Routerd port */
 (192.1.1.2,203.0.0.1) Flags: HW
   SW Forwarding: 0/0/0/0, Other: 0/0/0
   HW Forwarding:   490/34/1478/397, Other: 0/0/0
   BDI100 Flags: A
   TenGigabitEthernet0/0/25 Flags: F NS
     Pkts: 584/0/0    Rate: 34 pps

Aggregate multicast statistics (packet count) is implemented for all the (S,G) entries for which the given BDI serves as the OIF.

For example, if the outgoing BDI is common for all the groups then the packets are aggregated. No SDM templates are required on the RSP2 module.

Aggregate stats are supported only on BDI interfaces and are implemented as part of the output broadcast and output IP multicast packet counts.

Note	From Cisco IOS XE Bengaluru 17.4.1 release, multicast SLA measurement with MLDP is supported only on aggregated BDI egress stats on the head node only. No changes to aggregated BDI ingress stats for the tail node.

Router# show interface bdi 103 | i broad
/* Send or Receive (native multicast) */
     Received 0 broadcasts (5 IP multicasts)
     Output 0 broadcasts (17153 IP multicasts)

Router# show interface bdi 102 | i broad
/* You grep for broad here because the output IP multicasts are present in the same line */
     Received 0 broadcasts (34356 IP multicasts)
     Output 0 broadcasts (41 IP multicasts)

/* BDI stats – Receive(MLDP Tail-Node) */

Router#show ip mfib vrf
MCAST 255.1.1.2
VRF MCAST
(*,255.1.1.2) Flags: C HW
   SW Forwarding: 0/0/0/0, Other: 0/0/0
   HW Forwarding:   1000/0/1478/0, Other: 0/0/0
   Lspvif29, LSM/C4, RPF-ID: *, Flags: A NS
   BDI25 Flags: F NS
     Pkts: 52/0/0    Rate: 5 pps
(10.1.1.2,255.1.1.2) Flags: HW
   SW Forwarding: 43/0/1478/0, Other: 0/0/0
   HW Forwarding:   1000/100/1478/1154, Other: 0/0/0
   Lspvif29, LSM/C4, RPF-ID: *, Flags: A
   BDI25 Flags: F NS
     Pkts: 1000/0/43    Rate: 100 pps

Router# show interface bdi 105
Received 0 broadcasts (1000 IP multicasts)
Output 0 broadcasts (11 IP multicasts)

• MVPN-GRE over routed pseudowire feature is supported from Cisco IOS XE Fuji 16.9.1 onwards.

• The update source interface for the Border Gateway Protocol (BGP) peerings must be the same for all BGP peerings configured on the router in order to configure the default Multicast Distribution Tree (MDT) accurately.

• If you use a loopback address for BGP peering, the PIM sparse mode must be enabled on the loopback address.

• Multiple BGP update sources are not supported and configuring them can break MVPN Reverse Path Forwarding (RPF) checking.

• PIM Dense mode is not supported on core network.

• IGMP snooping should be disabled in PE nodes for multicast to work over routed pseudowire.

• Only PIM-SSM is supported with MVPN-GRE over routed pseudowire.

• Only one PW under a VFI is supported.

• A maximum of 15 routed pseudowires are supported for MPVN-GRE over routed pseudowire.

To configure Multicast VPN over routed pseudowire:

enable
configure terminal 
ip multicast-routing distributed
ip multicast-routing vrf vrf-name distributed
ip vrf cu1
mdt default 232.0.0.1
router bgp 100
address-family ipv4 mdt
neighbor 2.2.2.2 activate
exit
address-family vpnv4
neighbor 2.2.2.2 activate
ip vrf cu1
mdt data 232.0.0.5 0.0.0.0
mdt data threshold 1000
l2 vfi VPLS_A manual
vpn id 1000
bridge-domain 1000
neighbor 2.2.2.2 encapsulation mpls
interface bdi 1000
ip address 39.1.1.1 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0

Note

MDT pools are multicast group addresses. The range of threshold is from 1 to 4294967 kbps. Use the optional list keyword and access-list argument to define the (S, G) MVPN entries to be used in a data MDT pool, which further limits the creation of a data MDT pool to the particular (S, G) MVPN entries defined in the access list specified for the access-list argument.