Multicast-VPN/IP Multicast Support for MPLS VPNs
Feature Overview
This 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.
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 a 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 route 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.
Multicast-VPN Routing and Forwarding and Multicast Domains
Multicast-VPN 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 VRF (MVRF).
A set of Multicast-VPN Routing and Forwarding 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 multicast distribution tree (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) messages, which 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. 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 sending the multicast data, PE1 recognizes that the multicast data exceeds the bandwidth threshold as 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 as well as a PIM relationship with its directly attached PE routers.
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
Multicast distributed switching (MDS) is supported for Multicast-VPN 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).
Use the following commands to enable MDS for a particular VRF:
ip multicast-routing distributed
ip multicast-routing vrf vrf-name distributed
The following example shows how to configure MDS on Ethernet interface 1/1/1:
interface ethernet 1/1/1
ip mroute-cache distributed
Benefits
‧Provides a scalable solution to dynamically send information to multiple locations.
‧Provides high-speed information delivery.
‧Provides connectivity through a shared infrastructure.
Restrictions
‧If the core multicast routing is using Source Specific Multicast (SSM), then the data and default MDT groups must be configured within the SSM range of IP addresses by default.
‧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 for the default MDT to be configured properly. If you use a loopback address for BGP peering, then PIM sparse mode must be enabled on the loopback address.
‧The ip mroute-cache command must be enabled on the loopback interface used as the BGP peering interface in order for distributed multicast switching to function on the platforms that support it. The no ip mroute-cache command must not be present on these interfaces.
‧MPLS Multicast does not support multiple BGP peering update sources.
‧Data MDTs are not created for VRF PIM dense mode multicast streams because of the flood and prune nature of dense mode multicast flows and the resulting periodic bring-up and tear-down of such data MDTs.
‧Multiple BGP update sources are not supported and configuring them can break Multicast-VPN RPF checking. The source IP address of the Multicast-VPN tunnels is determined by the highest IP address used for the BGP peering update source. If this IP address is not the IP address used as the BGP peering address with the remote PE router, Multicast-VPN will not function properly.
Configuration Tasks
See the following sections for configuration tasks for this feature. Each task in the list is identified as either required or optional.
‧Enabling a VPN for Multicast Routing (required)
‧Enabling PIM on Interfaces (required)
‧Configuring a Default MDT Group for a VPN VRF (required)
‧Configuring the Multicast Group Address Range for Data MDT Groups (optional)
‧Recording Data MDT Reuse (optional)
‧Configuring the IP Source Address of Register Messages (required)
‧Storing IP Multicast Packet Headers (required)
‧Configuring an MSDP Peer (optional)
‧Limiting the Number of Multicast Routes (optional)
‧Filtering Multicast Router Information Request Packets (optional)
Enabling a VPN for Multicast Routing
To enable IP multicast routing, use the following command in global configuration mode:
Router(config)# ip multicast-routing vrf vrf-name
Enabling PIM on Interfaces
Configure Protocol Independent Multicast (PIM) on all interfaces used for IP multicast. We recommend configuring PIM sparse mode on all physical interfaces of Provider Edge (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.
To configure PIM on an interface to be in sparse mode, use the following command in interface configuration mode:
Router(config-if)# ip pim sparse-mode
Configuring a Default MDT Group for a VPN VRF
To configure a default MDT group for a VRF, use the following commands beginning in global configuration mode:
Router(config)# ip vrf vrf-name
Router(config-vrf)# mdt default group-address
Configuring the Multicast Group Address Range for Data MDT Groups
To configure the multicast group address range for data MDT groups, use the following commands beginning in global configuration mode:
Router(config)# ip vrf vrf-name
Router(config-vrf)# mdt data group-address-range wildcard-bits [threshold threshold-value] [list access-list]
Recording Data MDT Reuse
To enable the recording of data MDT reuse, use the following commands beginning in global configuration mode.
Router(config)# ip vrf vrf-name
Router(config-vrf)# mdt log-reuse
Configuring the IP Source Address of Register Messages
Register messages are unicast messages sent by the designated router (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 (SA) 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 following command in global configuration mode. The optional vrf vrf-name argument has been added to ip pim register-source commands to define the VPN routing instance by assigning a VRF name.
Router(config)# ip pim [vrf vrf-name] register-source type interface-number
Storing IP Multicast Packet Headers
You can store IP multicast packet headers in a cache and then display them to determine any of the following information:
‧Who is sending IP multicast packets to what groups
‧Interpacket delay
‧Duplicate IP multicast packets (if any)
‧Multicast forwarding loops in your network (if any)
‧Scope of the group
‧UDP port numbers
‧Packet length
To allocate a circular buffer to store IP multicast packet headers that the router receives, use the following command in global configuration mode. The optional vrf vrf-name argument has been added to ip multicast commands to define the VPN routing instance by assigning a VRF name:
Router(config)# ip multicast [vrf vrf-name] cache-headers [rtp]
Configuring an MSDP Peer
To configure a Multicast Source Discovery Protocol (MSDP) peer, use the following command in global configuration mode. The optional vrf vrf-name argument has been added to ip msdp commands to define the VPN routing instance by assigning a VRF name:
Router(config)# ip msdp [vrf vrf-name] peer {peer-name peer-address} [connect-source type number] [remote-as as-number]
Limiting the Number of Multicast Routes
To limit the number of multicast routes that can be added in a router, use the following command in global configuration mode.
Router(config)# ip multicast route-limit limit threshold
Filtering Multicast Router Information Request Packets
To limit the number of multicast routes that can be added in a router, use the following command in global configuration mode.
Router(config)# ip multicast mrinfo-filter acl
Verifying the MSDP Peer
To display detailed information about and to verify information regarding the MSDP peer, perform the following steps.
Step 1 Enter the show ip msdp peer command to verify detailed information about MSDP peer
Router# show ip msdp peer 224.135.250.116
Step 2 Enter the show ip msdp summary to display MSDP peer status:
Router# show ip msdp summary
Verifying Information for the MDT Default Group
To display information about and to verify information about the BGP advertisement of the route distinguisher (RD) for the MDT default group, use the show ip pim mdt bgp command in EXEC mode.
Router# show ip pim mdt bgp
Verifying Information for the MDT Data Group
To display detailed information about and to verify information regarding the MDT data group, perform the following steps.
Step 1 Enter the show ip pim mdt receive command to show the data MDT advertisements received by a specified router:
Router# show ip pim vrf vpn8 mdt receive detail
Step 2 Enter the show ip pim mdt send command to show the MDT advertisements that a specified router has made:
Router# show ip pim mdt send
Step 3 Enter the show ip pim mdt history command to display the data MDTs that have been reused during the past configured interval.
Configuration Examples
This section provides the following configuration examples:
‧Enabling a VPN for Multicast Routing Example
‧Configuring the Multicast Group Address Range for Data MDT Groups 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
Enabling a VPN for Multicast Routing Example
In the following example, Multicast routing is enabled with a VPN routing instance named of vrf1:
Router(config)#ip multicast-routing vrf1
Configuring the Multicast Group Address Range for Data MDT Groups Example
In the following example, the VPN routing instance is assigned a VRF name of 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:
Router(config)# ip vrf blue
Router(config-vrf)# rd 55:1111
Router(config-vrf)# route-target both 55:1111
Router(config-vrf)# mdt default 239.1.1.1
Router(config-vrf)# mdt data 239.1.2.0 0.0.0.3
Router(config-vrf)# end
Configuring the IP Source Address of Register Messages Example
In the following example, the IP source address of the register message is configured to the E1 interface of a DR:
Router(config)# ip pim register-source E1/0/1
Router> show running-config incl register
ip pim register-source Ethernet1/0/1
Storing IP Multicast Packet Headers Example
In the following example, a circular buffer is allocated to store IP multicast packet headers that the router receives. The VPN routing instances in this example are named vrf1 and vrf2:
Router(config)# ip multicast vrf vrf1 cache-headers
Router(config)# ip multicast vrf vrf2 cache-headers
Router> show running-config
Building configuration...
Current configuration :3552 bytes
!
Last configuration change at 16:52:30 UTC Fri May 31 2002
!
Version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
no service single-slot-reload-enable
!
hostname Router
!
.
.
.
ip vrf vrf1
rd 55:111
route-target export 55:111
route-target import 55:111
mdt default 232.1.1.1
!
ip vrf vrf2
rd 55:112
route-target export 55:112
route-target import 55:112
mdt default 232.2.2.2
!
ip multicast-routing distributed
ip multicast-routing vrf vrf1 distributed
ip multicast-routing vrf vrf2 distributed
ip multicast vrf vrf1 cache-headers
ip multicast vrf vrf2 cache-headers
ip cef distributed
.
.
.
interface Ethernet1/0/3.1
encapsulation dot1Q 1 native
ip vrf forwarding vrf1
ip address 20.1.1.1 255.255.255.0
no ip redirects
no ip proxy-arp
ip pim sparse-dense-mode
no keepalive
no cdp enable
!
interface Ethernet1/0/3.2
encapsulation dot1Q 2
ip vrf forwarding vrf2
ip address 20.1.1.2 255.255.255.0
no ip redirects
no ip proxy-arp
ip pim sparse-dense-mode
no keepalive
no cdp enable
.
.
address-family ipv4 vrf vrf2
redistribute connected
redistribute static
redistribute rip metric 50
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf vrf1
redistribute connected
redistribute static
redistribute rip metric 50
no auto-summary
no synchronization
exit-address-family
.
.
.
end
Configuring an MSDP Peer Example
In the following example, an MSDP peer is configured with a VPN routing instance named of vrf1 and a source of 10.10.0.1 from E1 interface:
ip msdp vrf vrf1 peer 10.10.0.1 connect-source E1/0/1
Limiting the Number of Multicast Routes Example
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:
Router# show running-config
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
!
.
.
.
This 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.
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 a 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 route 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.
Multicast-VPN Routing and Forwarding and Multicast Domains
Multicast-VPN 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 VRF (MVRF).
A set of Multicast-VPN Routing and Forwarding 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 multicast distribution tree (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) messages, which 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. 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 sending the multicast data, PE1 recognizes that the multicast data exceeds the bandwidth threshold as 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 as well as a PIM relationship with its directly attached PE routers.
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
Multicast distributed switching (MDS) is supported for Multicast-VPN 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).
Use the following commands to enable MDS for a particular VRF:
ip multicast-routing distributed
ip multicast-routing vrf vrf-name distributed
The following example shows how to configure MDS on Ethernet interface 1/1/1:
interface ethernet 1/1/1
ip mroute-cache distributed
Benefits
‧Provides a scalable solution to dynamically send information to multiple locations.
‧Provides high-speed information delivery.
‧Provides connectivity through a shared infrastructure.
Restrictions
‧If the core multicast routing is using Source Specific Multicast (SSM), then the data and default MDT groups must be configured within the SSM range of IP addresses by default.
‧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 for the default MDT to be configured properly. If you use a loopback address for BGP peering, then PIM sparse mode must be enabled on the loopback address.
‧The ip mroute-cache command must be enabled on the loopback interface used as the BGP peering interface in order for distributed multicast switching to function on the platforms that support it. The no ip mroute-cache command must not be present on these interfaces.
‧MPLS Multicast does not support multiple BGP peering update sources.
‧Data MDTs are not created for VRF PIM dense mode multicast streams because of the flood and prune nature of dense mode multicast flows and the resulting periodic bring-up and tear-down of such data MDTs.
‧Multiple BGP update sources are not supported and configuring them can break Multicast-VPN RPF checking. The source IP address of the Multicast-VPN tunnels is determined by the highest IP address used for the BGP peering update source. If this IP address is not the IP address used as the BGP peering address with the remote PE router, Multicast-VPN will not function properly.
Configuration Tasks
See the following sections for configuration tasks for this feature. Each task in the list is identified as either required or optional.
‧Enabling a VPN for Multicast Routing (required)
‧Enabling PIM on Interfaces (required)
‧Configuring a Default MDT Group for a VPN VRF (required)
‧Configuring the Multicast Group Address Range for Data MDT Groups (optional)
‧Recording Data MDT Reuse (optional)
‧Configuring the IP Source Address of Register Messages (required)
‧Storing IP Multicast Packet Headers (required)
‧Configuring an MSDP Peer (optional)
‧Limiting the Number of Multicast Routes (optional)
‧Filtering Multicast Router Information Request Packets (optional)
Enabling a VPN for Multicast Routing
To enable IP multicast routing, use the following command in global configuration mode:
Router(config)# ip multicast-routing vrf vrf-name
Enabling PIM on Interfaces
Configure Protocol Independent Multicast (PIM) on all interfaces used for IP multicast. We recommend configuring PIM sparse mode on all physical interfaces of Provider Edge (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.
To configure PIM on an interface to be in sparse mode, use the following command in interface configuration mode:
Router(config-if)# ip pim sparse-mode
Configuring a Default MDT Group for a VPN VRF
To configure a default MDT group for a VRF, use the following commands beginning in global configuration mode:
Router(config)# ip vrf vrf-name
Router(config-vrf)# mdt default group-address
Configuring the Multicast Group Address Range for Data MDT Groups
To configure the multicast group address range for data MDT groups, use the following commands beginning in global configuration mode:
Router(config)# ip vrf vrf-name
Router(config-vrf)# mdt data group-address-range wildcard-bits [threshold threshold-value] [list access-list]
Recording Data MDT Reuse
To enable the recording of data MDT reuse, use the following commands beginning in global configuration mode.
Router(config)# ip vrf vrf-name
Router(config-vrf)# mdt log-reuse
Configuring the IP Source Address of Register Messages
Register messages are unicast messages sent by the designated router (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 (SA) 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 following command in global configuration mode. The optional vrf vrf-name argument has been added to ip pim register-source commands to define the VPN routing instance by assigning a VRF name.
Router(config)# ip pim [vrf vrf-name] register-source type interface-number
Storing IP Multicast Packet Headers
You can store IP multicast packet headers in a cache and then display them to determine any of the following information:
‧Who is sending IP multicast packets to what groups
‧Interpacket delay
‧Duplicate IP multicast packets (if any)
‧Multicast forwarding loops in your network (if any)
‧Scope of the group
‧UDP port numbers
‧Packet length
To allocate a circular buffer to store IP multicast packet headers that the router receives, use the following command in global configuration mode. The optional vrf vrf-name argument has been added to ip multicast commands to define the VPN routing instance by assigning a VRF name:
Router(config)# ip multicast [vrf vrf-name] cache-headers [rtp]
Configuring an MSDP Peer
To configure a Multicast Source Discovery Protocol (MSDP) peer, use the following command in global configuration mode. The optional vrf vrf-name argument has been added to ip msdp commands to define the VPN routing instance by assigning a VRF name:
Router(config)# ip msdp [vrf vrf-name] peer {peer-name peer-address} [connect-source type number] [remote-as as-number]
Limiting the Number of Multicast Routes
To limit the number of multicast routes that can be added in a router, use the following command in global configuration mode.
Router(config)# ip multicast route-limit limit threshold
Filtering Multicast Router Information Request Packets
To limit the number of multicast routes that can be added in a router, use the following command in global configuration mode.
Router(config)# ip multicast mrinfo-filter acl
Verifying the MSDP Peer
To display detailed information about and to verify information regarding the MSDP peer, perform the following steps.
Step 1 Enter the show ip msdp peer command to verify detailed information about MSDP peer
Router# show ip msdp peer 224.135.250.116
Step 2 Enter the show ip msdp summary to display MSDP peer status:
Router# show ip msdp summary
Verifying Information for the MDT Default Group
To display information about and to verify information about the BGP advertisement of the route distinguisher (RD) for the MDT default group, use the show ip pim mdt bgp command in EXEC mode.
Router# show ip pim mdt bgp
Verifying Information for the MDT Data Group
To display detailed information about and to verify information regarding the MDT data group, perform the following steps.
Step 1 Enter the show ip pim mdt receive command to show the data MDT advertisements received by a specified router:
Router# show ip pim vrf vpn8 mdt receive detail
Step 2 Enter the show ip pim mdt send command to show the MDT advertisements that a specified router has made:
Router# show ip pim mdt send
Step 3 Enter the show ip pim mdt history command to display the data MDTs that have been reused during the past configured interval.
Configuration Examples
This section provides the following configuration examples:
‧Enabling a VPN for Multicast Routing Example
‧Configuring the Multicast Group Address Range for Data MDT Groups 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
Enabling a VPN for Multicast Routing Example
In the following example, Multicast routing is enabled with a VPN routing instance named of vrf1:
Router(config)#ip multicast-routing vrf1
Configuring the Multicast Group Address Range for Data MDT Groups Example
In the following example, the VPN routing instance is assigned a VRF name of 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:
Router(config)# ip vrf blue
Router(config-vrf)# rd 55:1111
Router(config-vrf)# route-target both 55:1111
Router(config-vrf)# mdt default 239.1.1.1
Router(config-vrf)# mdt data 239.1.2.0 0.0.0.3
Router(config-vrf)# end
Configuring the IP Source Address of Register Messages Example
In the following example, the IP source address of the register message is configured to the E1 interface of a DR:
Router(config)# ip pim register-source E1/0/1
Router> show running-config incl register
ip pim register-source Ethernet1/0/1
Storing IP Multicast Packet Headers Example
In the following example, a circular buffer is allocated to store IP multicast packet headers that the router receives. The VPN routing instances in this example are named vrf1 and vrf2:
Router(config)# ip multicast vrf vrf1 cache-headers
Router(config)# ip multicast vrf vrf2 cache-headers
Router> show running-config
Building configuration...
Current configuration :3552 bytes
!
Last configuration change at 16:52:30 UTC Fri May 31 2002
!
Version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
no service single-slot-reload-enable
!
hostname Router
!
.
.
.
ip vrf vrf1
rd 55:111
route-target export 55:111
route-target import 55:111
mdt default 232.1.1.1
!
ip vrf vrf2
rd 55:112
route-target export 55:112
route-target import 55:112
mdt default 232.2.2.2
!
ip multicast-routing distributed
ip multicast-routing vrf vrf1 distributed
ip multicast-routing vrf vrf2 distributed
ip multicast vrf vrf1 cache-headers
ip multicast vrf vrf2 cache-headers
ip cef distributed
.
.
.
interface Ethernet1/0/3.1
encapsulation dot1Q 1 native
ip vrf forwarding vrf1
ip address 20.1.1.1 255.255.255.0
no ip redirects
no ip proxy-arp
ip pim sparse-dense-mode
no keepalive
no cdp enable
!
interface Ethernet1/0/3.2
encapsulation dot1Q 2
ip vrf forwarding vrf2
ip address 20.1.1.2 255.255.255.0
no ip redirects
no ip proxy-arp
ip pim sparse-dense-mode
no keepalive
no cdp enable
.
.
address-family ipv4 vrf vrf2
redistribute connected
redistribute static
redistribute rip metric 50
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf vrf1
redistribute connected
redistribute static
redistribute rip metric 50
no auto-summary
no synchronization
exit-address-family
.
.
.
end
Configuring an MSDP Peer Example
In the following example, an MSDP peer is configured with a VPN routing instance named of vrf1 and a source of 10.10.0.1 from E1 interface:
ip msdp vrf vrf1 peer 10.10.0.1 connect-source E1/0/1
Limiting the Number of Multicast Routes Example
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:
Router# show running-config
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
!
.
.
.
Comments