Table Of Contents
Multicast VPN—IP Multicast Support for MPLS VPNs
Prerequisites for Multicast VPN—IP Multicast Support for MPLS VPNs
Restrictions for Multicast VPN—IP Multicast Support for MPLS VPNs
Information About Multicast VPN—IP Multicast Support for MPLS VPNs
IP Multicast Functionality for VRFs
IP Multicast VPN Routing and Forwarding and Multicast Domains
Multicast Distributed Switching Support
How to Configure Multicast VPN—IP Multicast Support for MPLS VPNs
Enabling a VPN for Multicast Routing
Fast-Switching and IP Multicast
Configuring the MDT Address Family in BGP for Multicast VPN
BGP Advertisement Methods for Multicast VPN Support
Auto-Migration to the MDT SAFI
Guidelines for Configuring the MDT SAFI
Guidelines for Upgrading a Network to Support the MDT SAFI
Sample Output for the show ip msdp peer Command
Sample Output for the show ip msdp summary Command
Sample Output for the show ip pim mdt bgp Command
Sample Output for the show ip pim mdt receive detail Command
Sample Output for the show ip pim mdt send Command
Sample Output for the show ip pim mdt history Command
Sample Output for the show ip hardware-mdfs mgid Command
Sample Output for the show ip mds mgid-table Command
Configuration Examples for Multicast VPN—IP Multicast Support for MPLS VPNs
Enabling a VPN for Multicast Routing Example
Configuring the Multicast Group Address Range for Data MDT Groups: Example
Configuring the MDT Address Family in BGP for Multicast VPN: Example
Configuring the IP Source Address of Register Messages: Example
Storing IP Multicast Packet Headers: Example
Configuring an MSDP Peer: Example
Limiting the Number of Multicast Routes: Example
Multicast VPN—IP Multicast Support for MPLS VPNs
The Multicast VPN—IP Multicast Support for MPLS VPNs feature allows a service provider to configure and support multicast traffic in a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) environment. This feature supports routing and forwarding of multicast packets for each individual VPN routing and forwarding (VRF) instance, and it also provides a mechanism to transport VPN multicast packets across the service provider backbone.
Feature Specifications for the Multicast VPN—IP Multicast Support for MPLS VPNs Feature
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
Prerequisites for Multicast VPN—IP Multicast Support for MPLS VPNs
•
•
•
•
Prerequisites for Multicast VPN—IP Multicast Support for MPLS VPNs
Service providers must have a multicast-enabled core in order to use the Cisco Multicast VPN feature. Refer to the "IP Multicast" part of the Release 12.2 Cisco IOS IP Configuration Guide for more information.
Restrictions for Multicast VPN—IP Multicast Support for MPLS VPNs
•
•
•
•
•
•
•
•
•
Information About Multicast VPN—IP Multicast Support for MPLS VPNs
To configure the Multicast VPN—IP Multicast Support for MPLS VPNs feature, you must understand the following concepts:
•
•
•
•
IP Multicast VPNs
The Multicast VPN feature in Cisco IOS software provides the ability to support the multicast feature over a Layer 3 VPN. As enterprises extend the reach of their multicast applications, service providers can accommodate these enterprises over their MPLS core network. IP multicast is used to stream video, voice, and data to an MPLS VPN network core.
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.
Historically, IP in IP generic routing encapsulation (GRE) tunnels was the only way to connect through a service provider network. Although such tunneled networks tend to have scalability issues, they represent the only means of passing IP multicast traffic through a VPN.
MPLS was derived from tag switching and various other vendor methods of IP-switching support enhancements in the scalability and performance of IP-routed networks by combining the intelligence of routing with the high performance of switching. MPLS is now used for VPNs, which is an appropriate combination because MPLS decouples information used for forwarding of the IP packet (the label) from the information carried in the IP header.
A Multicast VPN allows an enterprise to transparently interconnect its private network across the network backbone of a service provider. The use of a Multicast VPN 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.
Because MPLS VPNs support only unicast traffic connectivity, deploying the Multicast VPN feature in conjunction with MPLS VPN allows service providers to offer both unicast and multicast connectivity to MPLS VPN customers.
Benefits of IP Multicast VPNs
•
•
•
IP Multicast Functionality for VRFs
IP multicast features are available for VRFs. These features have the same functionality as they do for non-VRF situations. Many command line interface (CLI) commands have been enhanced through addition of the vrf vrf-name keyword and attribute to include support for VRFs.
Table 1 provides information about Cisco IOS commands that have been enhanced to provide functionality for VRFs. For additional configuration information about the commands described in Table 1, refer to the "Configuring IP Multicast Routing" chapter in the "IP Multicast" part in the Cisco IOS IP Configuration Guide, Release 12.2.
For more information about the following commands, see the "Command Reference" section.
Table 2 provides information about Cisco IOS commands that have been enhanced to provide functionality for VRFs. For additional configuration information about the commands described in Table 2, refer to the "Configuring Multicast Source Discovery Protocol" chapter in the "IP Multicast" part in the Cisco IOS IP Configuration Guide, Release 12.2.
For more information about the following commands, see the "Command Reference" section.
Table 3 provides information about Cisco IOS commands that have been enhanced to provide functionality for VRFs. For more information about the following commands see the "Command Reference" section.
Table 3 IP Multicast Functionality for VRFs—Other IP Multicast Configurations
ip mroute
Configures a multicast static route (mroute).
"Configuring an IP Multicast Static Route" section in "Configuring IP Multicast Routing" chapter.
ip pim accept-register
Configures a candidate RP router to filter PIM register messages.
ip pim ssm
Defines the SSM range of IP multicast addresses.
ip pim bidir-enable
Enables bidir-PIM.
"Configuring Bidirectional PIM" chapter
IP Multicast VPN Routing and Forwarding and Multicast Domains
Multicast VPN introduces multicast routing information to the VPN routing and forwarding table. When a PE router receives multicast data or control packets from a customer-edge (CE) router, forwarding is performed according to the information in the Multicast VRF (MVRF).
A set of Multicast VPN Routing and Forwarding instances 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.
Multicast Distribution Trees
Multicast VPN 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.
Multicast VPN 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 that contains information about the data MDT to all routers in the default MDT. The statistics to determine whether a multicast stream has exceeded the data MDT threshold are examined once every 10 seconds. If multicast distributed switching is configured, the time period can be up to twice as long.
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. Figure 1 shows that no data flows along the default MDT, because no one outside of San Jose has joined the multicast.
Figure 1 Default Multicast Distribution Tree Overview
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 whether it is configured to use Sparse Mode, Bidir or SSM within a VRF which contains both the Dallas and the San Jose sites. PE1, the PE router associated with the multicast session source, receives the request. Figure 2 depicts that the PE router forwards the request to the CE router associated with the multicast source (CE1a).
Figure 2 Initializing the Data MDT
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 after sending the multicast data, PE1 recognizes that the multicast data exceeds the bandwidth threshold at 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.
Figure 3 depicts the final flow of multicast data sourced from the multicast sender in San Jose to the multicast client in New York. Multicast data sent from the multicast sender in San Jose is delivered in its original format to its associated PE router (PE1) using either sparse mode, bidir or SSM. PE1 then encapsulates the multicast data and sends it across the data MDT using the configured MDT data groups. The mode used to deliver the multicast data across the data MDT is determined by the service provider and has no direct correlation with the mode used by the customer. The PE router in New York (PE2) receives the data along the data MDT. The PE2 router deencapsulates the packet and forwards it in its original format toward the multicast client using the mode configured by the customer.
Figure 3 Multicast Distribution Tree with VRFs
Multicast Tunnel Interface
For every multicast domain of which an MVRF is a part, the PE router creates a multicast tunnel interface. 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 multicast VRF.
Multicast Distributed Switching Support
MDS is supported for Multicast VPN on the Cisco 7500 series, Cisco 10000 series, and Cisco 12000 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).
Use the following commands to enable MDS for a particular VRF:
•
•
How to Configure Multicast VPN—IP Multicast Support for MPLS VPNs
This section contains the following procedures:
•
•
Enabling a VPN for Multicast Routing
This task enables a VPN for Multicast Routing.
PIM
PIM can operate in dense mode or sparse mode. It is possible for the router to handle both sparse groups and dense groups at the same time.
In dense mode, a router assumes that all other routers want to forward multicast packets for a group. If a router receives a multicast packet and has no directly connected members or PIM neighbors present, a prune message is sent back to the source. Subsequent multicast packets are not flooded to this router on this pruned branch. PIM builds source-based multicast distribution trees.
In sparse mode, a router assumes that other routers do not want to forward multicast packets for a group, unless there is an explicit request for the traffic. When hosts join a multicast group, the directly connected routers send PIM join messages toward the RP. The RP keeps track of multicast groups. Hosts that send multicast packets are registered with the RP by the first hop router of that host. The RP then sends join messages toward the source. At this point, packets are forwarded on a shared distribution tree. If the multicast traffic from a specific source is sufficient, the first hop router of the host may send join messages toward the source to build a source-based distribution tree.
Fast-Switching and IP Multicast
Fast switching of IP multicast packets is enabled by default on all interfaces (including GRE and Distance Vector Multicast Routing Protocol [DVMRP] tunnels), with one exception: It is disabled and not supported over X.25 encapsulated interfaces. Note the following properties of fast switching:
•
•
Disable fast switching if you want to log debug messages, because when fast switching is enabled, debug messages are not logged.
Note
Prerequisites
You must enable PIM sparse mode on the interface that is used for BGP peering. Configure PIM on all interfaces used for IP multicast. We recommend configuring PIM sparse mode on all physical interfaces of PE routers connecting to the backbone. We also recommend configuring PIM sparse mode on all loopback interfaces if they are used for BGP peering or if their IP address is used as an RP address for PIM.
In order to be able to use Auto-RP within a VRF, the interface facing the CE must be configured for PIM sparse-dense mode.
SUMMARY STEPS
1.
2.
3.
4.
5.
or
ip pim sparse-dense-mode
6.
7.
8.
DETAILED STEPS
What to Do Next
Proceed to the section "Configuring an MDT."
Configuring an MDT
This task configures an MDT.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
What to Do Next
Proceed to the "Configuring the MDT Address Family in BGP for Multicast VPN" task.
Configuring the MDT Address Family in BGP for Multicast VPN
Perform this task to configure an MDT address family session on PE routers to establish MDT peering sessions for MVPN.
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.
BGP Advertisement Methods for Multicast VPN Support
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.
Table 4 lists the BGP advertisement methods for sending the source PE address and the default MDT group that are available (by Cisco IOS release).
BGP Extended Community
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
BGP MDT SAFI
In Cisco IOS 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
In Cisco IOS 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 applies. 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.
Auto-Migration to the MDT SAFI
In Cisco IOS Release 12.0(30)S3, auto-migration 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 neighbors 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
Guidelines for Configuring the MDT SAFI
•
•
Guidelines for Upgrading a Network to Support the MDT SAFI
When moving from a pre-MDT SAFI to an MDT SAFI environment, 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 recommended that you perform the following steps:
1.
2.
Note
Supported Policy
The following policy configuration parameters are supported under the MDT SAFI:
•
•
Prerequisites
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 routers that provide VPN services to CE routers.
Restrictions
The following policy configuration parameters are not supported:
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
DETAILED STEPS
What to Do Next
Proceed to the optional "Customizing IP Multicast VPN" task or the optional "Verifying IP Multicast VPN" task.
Customizing IP Multicast VPN
This task configures additional, optional tasks for IP multicast VPN.
Register Messages
Register messages are unicast messages sent by the DR to the RP router when a multicast packet needs to be sent on a rendezvous point tree (RPT). By default, the IP source address of the register message is set to the address of the outgoing interface of the DR leading toward the RP. To configure the IP source address of a register message to an interface address other than the outgoing interface address of the DR leading toward the RP, use the ip pim register-source command in global configuration mode. The optional vrf vrf-name keyword and argument combination has been added to the ip pim register-source command to define the VPN routing instance by assigning a VRF name.
IP Multicast Headers Storage
You can store IP multicast packet headers in a cache and then display them to determine any of the following information:
•
•
•
•
•
•
•
To allocate a circular buffer to store IP multicast packet headers that the router receives, use the ip multicast cache-headers command in global configuration mode.
Note
The optional vrf vrf-name keyword and argument combination has been added to the ip multicast cache-header command to define the VPN routing instance by assigning a VRF name.
MSDP Peers
MSDP is a mechanism to connect multiple PIM sparse mode (PIM-SM) domains. MSDP allows multicast sources for a group to be known to all RPs in different domains. Each PIM-SM domain uses its own RPs and need not depend on RPs in other domains. An RP runs MSDP over TCP to discover multicast sources in other domains.
An RP in a PIM-SM domain has an MSDP peering relationship with MSDP-enabled routers in another domain. The peering relationship occurs over a TCP connection, where primarily a list of sources sending to multicast groups is exchanged. The TCP connections between RPs are achieved by the underlying routing system. The receiving RP uses the source lists to establish a source path.
The purpose of this topology is to have domains discover multicast sources in other domains. If the multicast sources are of interest to a domain that has receivers, multicast data is delivered over the normal, source-tree building mechanism in PIM-SM.
MSDP is also used to announce sources sending to a group. These announcements must originate at the RP of the domain.
MSDP depends heavily on BGP or multiprotocol BGP (MBGP) for interdomain operation. We recommend that you run MSDP in RPs in your domain that are RPs for sources sending to global groups to be announced to the Internet.
For more information about configuring MSDP, refer to the section "Configuring Multicast Source Discover Protocol" in the "IP Multicast" part of the Cisco IOS IP Configuration Guide, Release 12.2.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
What to Do Next
Proceed to the "Verifying IP Multicast VPN" task.
Verifying IP Multicast VPN
The following task verifies the IP multicast VPN configuration, including information about the MSDP peer and MDT default and data groups.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
Guest
