The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The Multicast VPN (MVPN) feature provides the ability to support multicast over a Layer 3 Virtual Private Network (VPN). As enterprises extend the reach of their multicast applications, service providers can accommodate these enterprises over their Multiprotocol Label Switching (MPLS) core network. IP multicast is used to stream video, voice, and data to an MPLS VPN network core.
Historically, point-to-point tunnels were the only way to connect through a service provider network. Although such tunneled networks tend to have scalability issues, they represented the only means of passing IP multicast traffic through a VPN.
Because Layer 3 VPNs support only unicast traffic connectivity, deploying in conjunction with a Layer 3 VPN allows service providers to offer both unicast and multicast connectivity to Layer 3 VPN customers.
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
IP multicast is enabled and the PIM interfaces are configured using the tasks described in the "Configuring Basic IP Multicast " module.
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 Internet service provider (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.
MVPN introduces multicast routing information to the VPN routing and forwarding table. When a provider edge (PE) router 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. 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.
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 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.
Multicast distributed switching (MDS) is supported for MVPN on the Cisco 7500 series routers. When MDS is configured, ensure that all interfaces enabled for IP multicast have MDS enabled correctly--verify that no interface has the no ip mroute-cache command configured (including loopback interfaces).
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.
In a single autonomous system, if the default MDT for an MVPN is using PIM sparse mode (PIM-SM) with a rendezvous point (RP), then PIM is able to establish adjacencies over the Multicast Tunnel Interface (MTI) because the source PE and receiver PE discover each other through the RP. In this scenario, the local PE (the source PE) sends register messages to the RP, which then builds a shortest-path tree (SPT) toward the source PE. The remote PE, which acts as a receiver for the MDT multicast group, then sends (*, G) joins toward the RP and joins the distribution tree for that group.
However, if the default MDT group is configured in a PIM Source Specific Multicast (PIM-SSM) environment rather than a PIM-SM environment, the receiver PE needs information about the source PE and the default MDT group. This information is used to send (S, G) joins toward the source PE to build a distribution tree from the source PE (without the need for an RP). The source PE address and default MDT group address are sent using BGP.
The table lists the BGP advertisement methods for sending the source PE address and the default MDT group that are available (by Cisco IOS release).
Cisco IOS Release |
BGP Advertisement Method |
---|---|
|
Extended Communities |
|
BGP address family MDT SAFI |
When BGP extended communities are used, the PE loopback (source address) information is sent as a VPNv4 prefix using Route Distinguisher (RD) Type 2 (to distinguish it from unicast VPNv4 prefixes). The MDT group address is carried in a BGP extended community. Using a combination of the embedded source in the VPNv4 address and the group in the extended community, PE routers in the same MVRF instance can establish SSM trees to each other.
Note |
Prior to the introduction of MDT SAFI support, the BGP extended community attribute was used as an interim solution to advertise the IP address of the source PE and default MDT group before IETF standardization. A BGP extended community attribute in an MVPN environment, however, has certain limitations: it cannot be used in inter-AS scenarios (because the attribute is nontransitive), and it uses RD Type 2 (which is not a supported standard). |
In Cisco IOS software releases that support the MDT SAFI, the source PE address and the MDT group address are passed to PIM using BGP MDT SAFI updates. The RD type has changed to RD type 0 and BGP determines the best path for the MDT updates before passing the information to PIM.
Note |
To prevent backwards-compatibility issues, BGP allows the communication of the older style updates with peers that are unable to understand the MDT SAFI address family. |
In Cisco IOS software releases that support the MDT SAFI, the MDT SAFI address family needs to be explicitly configured for BGP neighbors using the address-family ipv4 mdt command. Neighbors that do not support the MDT SAFI still need to be enabled for the MDT SAFI in the local BGP configuration. Prior to the introduction of the MDT SAFI, additional BGP configuration from the VPNv4 unicast configuration was not needed to support MVPN.
Because the new MDT SAFI does not use BGP route-target extended communities, the regular extended community methods to filter these updates no longer apply. As a result, the match mdt-group route-map configuration command has been added to filter on the MDT group address using Access Control Lists (ACLs). These route maps can be applied--inbound or outbound--to the IPv4 MDT address-family neighbor configuration.
In Cisco IOS Release 12.0(30)S3, automigration to the MDT SAFI functionality was introduced to ease the migration to the MDT SAFI. This functionality was integrated into Cisco IOS Releases 12.2(33)SRA1, 12.2(31)SB2, and 12.2(33)SXH. When migrating a Cisco IOS release to the MDT SAFI, existing VPNv4 neighbors will be automatically configured for the MDT SAFI upon bootup based on the presence of an existing default MDT configuration (that is, pre-MDT SAFI configurations will be automatically converted to an MDT SAFI configuration upon bootup). In addition, when a default MDT configuration exists and a VPNv4 neighbor in BGP is configured, a similar neighbor in the IPv4 MDT address family will be automatically configured.
Note |
Because there is no VRF configuration on route reflectors (RRs), automigration to the MDT SAFI will not be triggered on RRs. The MDT SAFI configuration, thus, will need to be manually configured on RRs. Having a uniform MDT transmission method will reduce processing time on the routers (because MDT SAFI conversion is not necessary). |
When moving from a pre-MDT SAFI to an MDT SAFI environment, the upmost care should be taken to minimize the impact to the MVPN service. The unicast service will not be affected, other than the outage due to the reload and recovery. To upgrade a network to support the MDT SAFI, we recommend that you perform the following steps:
Note |
In the case of a multihomed BGP RR scenario, one of the RRs must be upgraded and configured last. The upgraded PEs will use this RR to relay MDT advertisements while the other RRs are being upgraded. |
The following policy configuration parameters are supported under the MDT SAFI:
Perform this task to configure a default MDT group for a VRF.
The default MDT group must be the same group configured on all devices that belong to the same VPN. The source IP address will be the address used to source the BGP sessions.
1. enable
2. configure terminal
3. ip multicast-routing
4. ip multicast-routing vrf vrf-name
5. ip vrf vrf-name
6. mdt default group-address
Perform this task to configure an MDT address family session on PE devices to establish MDT peering sessions for MVPN.
Before MVPN peering can be established through an MDT address family, MPLS and Cisco Express Forwarding (CEF) must be configured in the BGP network and multiprotocol BGP on PE devices that provide VPN services to CE devices.
1. enable
2. configure terminal
3. router bgp as-number
4. address-family ipv4 mdt
5. neighbor neighbor-address activate
6. neighbor neighbor-address send-community [both | extended | standard]
7. exit
8. address-family vpnv4
9. neighbor neighbor-address activate
10. neighbor neighbor-address send-community [both | extended | standard]
11. end
Perform this task to configure a data MDT group.
A data MDT group can include a maximum of 256 multicast groups per VPN per VRF per PE device. Multicast groups used to create the data MDT group are dynamically chosen from a pool of configured IP addresses.
1. enable
2. configure terminal
3. ip vrf vrf-name
4. mdt data group-address-range wildcard-bits [threshold kb/s] [list access-list]
5. mdt log-reuse
6. exit
Perform this task to limit the number of multicast routes that can be added in a device.
1. enable
2. configure terminal
3. ip multicast vrf vrf-name route-limit limit [threshold]
4. ip multicast mrinfo-filter access-list
Perform this task to verify information about the MDT default group.
1. enable
2. show ip msdp [vrf vrf-name] peer [peer-address | peer-name]
3. show ip msdp [vrf vrf-name] summary
4. show ip pim [vrf vrf-name] mdt bgp
5. show ip pim [vrf vrf-name] mdt send
6. show ip pim mdt history
In the following example, PIM-SSM is configured in the backbone. Therefore, the default and data MDT groups are configured within the SSM range of IP addresses. Inside the VPN, PIM-SM is configured and only Auto-RP announcements are accepted.
ip vrf vrf1 rd 1:1 route-target export 1:1 route-target import 1:1 mdt default 232.0.0.1 mdt data 232.0.1.0 0.0.0.255 threshold 500 list 101 ! ip pim ssm default ip pim vrf vrf1 accept-rp auto-rp
In the following example, multicast routing is enabled with a VPN routing instance named vrf1:
ip multicast-routing vrf1
In the following example, an MDT address family session is configured on a PE router to establish MDT peering sessions for MVPN.
! ip vrf test rd 55:2222 route-target export 55:2222 route-target import 55:2222 mdt default 232.0.0.1 ! ip multicast-routing ip multicast-routing vrf test ! router bgp 55 . . . ! address-family vpnv4 neighbor 192.168.1.1 activate neighbor 192.168.1.1 send-community both ! address-family ipv4 mdt neighbor 192.168.1.1 activate neighbor 192.168.1.1 send-community both !
In the following example, the VPN routing instance is assigned a VRF named blue. The MDT default group for a VPN VRF is 239.1.1.1, and the multicast group address range for MDT groups is 239.1.2.0 with wildcard bits of 0.0.0.3:
ip vrf blue rd 55:1111 route-target both 55:1111 mdt default 239.1.1.1 mdt data 239.1.2.0 0.0.0.3 end
In the following example, the number of multicast routes that can be added in to a multicast routing table is set to 200,000 and the threshold value of the number of mroutes that will cause a warning message to occur is set to 20,000:
! ip multicast-routing distributed ip multicast-routing vrf cisco distributed ip multicast cache-headers ip multicast route-limit 200000 20000 ip multicast vrf cisco route-limit 200000 20000 no mpls traffic-eng auto-bw timers frequency 0 !
Related Topic |
Document Title |
---|---|
Cisco IOS commands |
|
Extranet MVPN concepts, tasks, and configuration examples |
“ Configuring Multicast VPN Extranet Support ” module |
Inter-AS MVPN concepts, tasks, and configuration examples |
“ Configuring Multicast VPN Inter-AS Support ” module |
MVPN MIB concepts and tasks |
“ Multicast VPN MIB ” module |
IP multicast commands: complete command syntax, command mode, command history, defaults, usage guidelines, and examples |
Standard/RFC |
Title |
---|---|
No new or modified standards or specific RFCs are supported by this feature, and support for existing standards has not been modified by this feature. |
-- |
MIB |
MIBs Link |
---|---|
CISCO_MVPN_MIB.my |
To locate and download MIBs for selected platforms, Cisco IOS XE releases, and feature sets, use Cisco MIB Locator found at the following URL: |
Description |
Link |
---|---|
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password. |
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Feature Name |
Releases |
Feature Information |
---|---|---|
Multicast VPN--IP Multicast Support of MPLS VPNs |
12.0(23)S 12.2(13)T 12.2(14)S 12.0(25)S1 12.0(26)S 12.0(32)SY 12.2(18)SXE Cisco IOS XE Release 2.5 15.0(1)S 15.2(2)S Cisco IOS XE Release 3.6S Cisco IOS XE Release 3.9S |
The Multicast VPN feature provides the ability to support multicast over a Layer 3 Virtual Private Network (VPN). As enterprises extend the reach of their multicast applications, service providers can accommodate these enterprises over their Multiprotocol Label Switching (MPLS) core network. IP multicast is used to stream video, voice, and data to an MPLS VPN network core. Support was added for the Cisco Catalyst 6000 Series Switches was added. In Cisco IOS Release 15.2(2)S, support was added for the Cisco ME 3600X and 3800X Series Ethernet Access Switches. In Cisco IOS XE Release 3.6S, support for the following PE-CE connections was added: HDLC, PPP, Frame-Relay, ATM AAL5SNAP, MLPPP, MLFR, and GRE tunnel connections. In Cisco IOS XE Release 3.9S, support was added for the Cisco ASR 903 Router. |