Usage Guidelines

After you have enabled the ip multicast-routing command, IPv4 multicast forwarding is enabled. Because IPv4 multicast forwarding is enabled by default, use the no form of the ip mfib command to disable IPv4 multicast forwarding.

Usage Guidelines

After you have enabled the ip multicast-routing command, IPv4 MFIB interrupt-level switching of both incoming packets and outgoing packets is enabled by default on interfaces that support it.

Use the no form of the ip mfib cef command with the input keyword to disable IPv4 MFIB interrupt switching of incoming packets on a specific interface.

Use the no form of the ip mfib cef command with the output keyword to disable IPv4 MFIB interrupt switching of outgoing packets on a specific interface.

Use the show ip mfib interface command to display IPv4 MFIB-related information about interfaces and their forwarding status.

Usage Guidelines

Because multicast forwarding is enabled automatically on all interfaces when IPv4 multicast routing is enabled using the ip multicast-routing command, the ip mfib forwarding command is used to reenable multicast forwarding of packets received from or destined for an interface, if it has been previously disabled.

Use the no ip mfib forwarding command with the input keyword to disable IPv4 multicast forwarding of packets received from an interface, although the specified interface will still continue to receive multicast packets destined for applications on the router itself.

Use the no ip mfib forwarding command with the output keyword to disable IPv4 multicast forwarding of packets destined for an interface.

Usage Guidelines

The Test Sender and Test Receiver can be either a router or a host.

If a router (or host) belongs to more than one test group, it can be a Test Sender for one group and a Test Receiver for the other group. It, however, cannot be the Test Sender and Test Receiver for the same group.

Usage Guidelines

Use this command to control which Managers a Test Sender or Test Receiver must respond to.

If neither the test-sender nor test-receiver keyword is configured, the access list applies to both.

Usage Guidelines

Use the ip mrm manager command to specify the name of the MRM test to be created or modified and enter MRM manager configuration mode where you specify the parameters of the MRM test.

Usage Guidelines

The ip mroute command is used to configure static mroutes. Static mroutes are similar to unicast static routes but differ in the following ways:

• Static mroutes are used to calculate RPF information, not to forward traffic.

• Static mroutes cannot be redistributed.

Static mroutes are strictly local to the router on which they are defined. Because Protocol Indepedent Multicast (PIM) does not have its own routing protocol, there is no mechanism to distribute static mroutes throughout the network. Consequently, the administration of static mroutes tends to be more complicated then the administration of unicast static routes.

When static mroutes are configured, they are stored on the router in a separate table referred to as the static mroute table . When configured, the ip mroute command enters a static mroute into the static mroute table for the source address or source address range specified for the source-address and mask arguments. Sources that match the source address or that fall in the source address range specified for the source-address argument will RPF to either the interface associated with the IP address specified for the rpf-address argument or the local interface on the router specified for the interface-type and interface-number arguments. If an IP address is specified for the rpf-address argument, a recursive lookup is done from the unicast routing table on this address to find the directly connected neighbor.

If there are multiple static mroutes configured, the router performs a longest-match lookup of the mroute table. When the mroute with the longest match (of the source-address) is found, the search terminates and the information in the matching static mroute is used. The order in which the static mroutes are configured is not important.

The administrative distance of an mroute may be specified for the optional distance argument. If a value is not specified for the distance argument, the distance of the mroute defaults to zero. If the static mroute has the same distance as another RPF source, the static mroute will take precedence. There are only two exceptions to this rule: directly connected routes and the default unicast route.

Tip	Remember that the distance of a matching mroute is compared to the distance of any other matching routes found in the other sources of RPF information. The static mroute is used if its distance is equal to or less than the distance of other routes.

For the Multicast VPN Extranet Support feature, the fallback-lookup and global keywords and an additional vrf keyword and vrf-name argument were added to the syntax of the ip mroute command. Use the ip mroute command with the fallback-lookup keyword and vrf vrf-name keyword and argument to specify the source MVRF. By default, extranet MVPN relies on the unicast routing policies to determine the RPF interface. When the RPF lookup originates in a receiver MVRF, and it finds that the RPF interface is not located in the same MVRF, the router uses the information in the Border Gateway Protocol (BGP) imported route to determine the source MVRF. The RPF lookup then continues and resolves in the source MVRF. In cases where the multicast and unicast topologies are incongruent, you can override the default behavior by configuring a static mroute in the receiver MVRF to explicitly specify the source MVRF using the ip mroute command with the fallback-lookup keyword and vrf vrf-name keyword and argument.

Static mroutes can also be configured to support RPF for extranet MVPN in the case where the source is present in an MVRF and the receiver is in the global table. In this case, because BGP does not allow VPNv4 routes to be imported into the IPv4 routing table, unicast cannot obtain the source MVRF information needed to resolve the RPF lookup. To enable the RPF lookup to be resolved in this case, a static mroute can be configured to explicitly specify the source MVRF using the ip mroute command with the fallback-lookup keyword and the global keyword.

In Release 12.2(33)SRB and subsequent 12.2SR releases, the following protocol keywords are no longer supported (to be consistent with the ip route command): bgp , eigrp , isis , iso-igrp , mobile , odr , ospf , rip , route-map , and static . Those keywords are still present in the online help as available keywords; however, if the ip mroute command is entered with one of those deprecated protocol keywords, the command will be rejected and the following error message will display on the console: “The option of specifying protocol is deprecated.”

Usage Guidelines

On the Cisco 7500 Series

If multicast fast switching is disabled on an incoming interface for a multicast routing table entry, the packet will be sent at the process level for all interfaces in the outgoing interface list.

If multicast fast switching is disabled on an outgoing interface for a multicast routing table entry, the packet is process-level switched for that interface, but may be fast switched for other interfaces in the outgoing interface list.

When multicast fast switching is enabled (like unicast routing), debug messages are not logged. If you want to log debug messages, disable fast switching.

If MDS is not enabled on an incoming interface that is capable of MDS, incoming multicast packets will not be distributed switched; they will be fast switched at the Route Processor (RP). Also, if the incoming interface is not capable of MDS, packets will get fast switched or process switched at the RP.

If MDS is enabled on the incoming interface, but at least one of the outgoing interfaces cannot fast switch, packets will be process switched. We recommend that you disable fast switching on any interface when MDS is enabled.

On the Cisco 12000 Series

On the Cisco 12000 series router, all interfaces should be configured for MDS because that is the only switching mode.

Usage Guidelines

Use this command if you want the router to send SA messages for sources active in the PIM dense mode region to MSDP peers.

Specifying the interface-type and interface-number values allow the MSDP peers to forward source-active messages away from this border. The IP address of the interface is used as the originator ID, which is the rendezvous point field in the MSDP source-active message.

Note	We recommend configuring the border router in the sparse mode domain to proxy-register sources in the dense mode domain, and have the sparse mode domain use standard MSDP procedures to advertise these sources.

Note

If you use this command, you must constrain the sources advertised by using the ip msdp redistribute command. Configure the ip msdp redistribute command to apply to only local sources. Be aware that this configuration can result in (S, G) state remaining long after a source in the dense mode domain has stopped sending.

Note	The ip msdp originator-id command also identifies an interface type and number to be used as the RP address. If both the ip msdp border and ip msdp originator-id commands are configured, the address derived from the ip msdp originator-id command determines the address of the RP.

Usage Guidelines

Use the ip msdp cache-rejected-sa command to configure the router to store SA messages that have been recently received from an MSDP peer but were rejected. Once this command is enabled, the router will maintain a rejected SAcache that stores the most recent rejected SA messages. The number of rejected SA message entries to be stored in the rejected SA cache is configured with the number-of-entries argument. If the rejected SA cache overflows, entries are overwritten, starting from the first entry.

Note	Enabling the ip msdp cache-rejected-sa command will not impact the performance of MSDP.

Use the show ip msdp sa-cache command with the rejected-sa keyword to display SA messages rejected from MSDP peers.

Usage Guidelines

This command is automatically configured if at least one MSDP peer is configured. It cannot be disabled.

If you are running a version of Cisco IOS software prior to Release 12.1(7), we recommend enabling the ip msdp cache-sa-state command.

Usage Guidelines

Use the ip msdp default-peer command if you do not want to configure your MSDP peer to be a BGP peer also.

If only one MSDP peer is configured (with the ip msdp peer command), it will be used as a default peer. Therefore, you need not configure a default peer with this command.

If the prefix-list list keyword and argument are not specified, all SA messages received from the configured default peer are accepted.

Remember to configure a BGP prefix list if you intend to configure the prefix-list list keyword and argument with the ip msdp default-peer command.

If the prefix-list list keyword and argument are specified, SA messages originated from rendezvous points (RPs) specified by the prefix-list list keyword and argument will be accepted from the configured default peer. If the prefix-list list keyword and argument are specified but no prefix list is configured, the default peer will be used for all prefixes.

You can enter multiple ip msdp default-peer commands, with or without the prefix-list keyword, as follows. However, all commands must either have the keyword or all must not have the keyword.

• When you use multiple ip msdp default-peer commands with the prefix-list keyword, all the default peers are used at the same time for different RP prefixes. This syntax is typically used in a service provider cloud that connects stub site clouds.

• When you use multiple ip msdp default-peer commands without the prefix-list keyword, a single active peer is used to accept all SA messages. If that peer goes down, then the next configured default peer accepts all SA messages. This syntax is typically used at a stub site.

Usage Guidelines

Configure a description to make the MSDP peer easier to identify. This description is displayed in the output of the show ip msdp peer command.

Usage Guidelines

By default, the router honors all SA request messages from peers. Use this command if you want to control exactly which SA request messages the router will honor.

If no access list is specified, all SA request messages are ignored. If an access list is specified, only SA request messages from those groups permitted will be honored, and all others will be ignored.

Usage Guidelines

Use the ip msdp keepalive command to adjust the interval at which an MSDP peer will send keepalive messages and the interval at which the MSDP peer will wait for keepalive messages from other peers before declaring them down.

Once an MSDP peering session is established, each side of the connection sends a keepalive message and sets a keepalive timer. If the keepalive timer expires, the local MSDP peer sends a keepalive message and restarts its keepalive timer; this interval is referred to as the keepalive interval. Use the keepalive-interval argument to adjust the interval for which keepalive messages will be sent. The keepalive timer is set to the value specified for the keepalive-interval argument when the peer comes up. The keepalive timer is reset to the value of the keepalive-interval argument whenever an MSDP keepalive message is sent to the peer and reset when the timer expires. The keepalive timer is deleted when an MSDP peering session is closed. By default, the keepalive timer is set to 60 seconds.

Note	The value specified for the keepalive-interval argument must be less than the value specified for the holdtime-interval argument and must be at least one second.

The hold-time timer is initialized to the value of the hold-time-interval argument whenever an MSDP peering connection is established, and is reset to value of the hold-time-interval argument whenever an MSDP keepalive message is received. The hold-time timer is deleted whenever an MSDP peering connection is closed. By default, the hold-time interval is set to 75 seconds.

Use the hold-time-interval argument to adjust the interval at which the MSDP peer will wait for keepalive messages from other peers before declaring them down. By default, it may take as long as 75 seconds for an MSDP peer to detect that a peering session with another MSDP peer has gone down. In network environments with redundant MSDP peers, decreasing the hold-time interval (by lowering the value for hold-time-interval argument from the default of 75 seconds) can expedite the reconvergence time of MSDP peers in the event that an MSDP peer fails.

Note

It is recommended that you do not change the command defaults for the ip msdp keepalive command, as the command defaults are in accordance with RFC 3618, Multicast Source Discovery Protocol . If your network environment requires that you modify the defaults, you must configure the same time values for the keepalive-interval and hold-time-interval arguments on both ends of the MSDP peering session.

Usage Guidelines

A mesh group is a group of MSDP speakers that have fully meshed MSDP connectivity among themselves. Source-Active (SA) messages received from a peer in a mesh group are not forwarded to other peers in the same mesh group.

Mesh groups can be used to achieve two goals:

• To reduce SA message flooding

• To simplify peer-Reverse Path Forwarding (RPF) flooding (no need to run Border Gateway Protocol [BGP] or multiprotocol BGP among MSDP peers)

Usage Guidelines

The ip msdp originator-id command identifies an interface type and number to be used as the RP address in an SA message.

Use this command if you want to configure a logical RP. Because only RPs and MSDP border routers originate SAs, there are times when it is necessary to change the ID used for this purpose.

If both the ip msdp border sa-address and ip msdp originator-id commands are configured the address derived from the ip msdp originator-id command determines the address of the RP to be used in the SA message.

Usage Guidelines

The ip msdp password peer command is used to enable MD5 authentication for TCP connections between two MSDP peers. When MD5 authentication is enabled between two MSDP peers, each segment sent on the TCP connection between the peers is verified. MD5 authentication must be configured with the same password on both MSDP peers; otherwise, the connection between them will not be made. Configuring MD5 authentication causes the Cisco IOS software to generate and verify the MD5 digest of every segment sent on the TCP connection.

If a router has a password configured for an MSDP peer, but the MSDP peer does not, a message such as the following will appear on the console while the routers attempt to establish a MSDP session between them:

%TCP-6-BADAUTH: No MD5 digest from [peer's IP address]:11003 to [local router's 
IP address]:179

Similarly, if the two routers have different passwords configured, a message such as the following will appear on the console:

%TCP-6-BADAUTH: Invalid MD5 digest from [peer's IP address]:11004 to [local router's 
IP address]:179

Configuring an MD5 Password in an Established MSDP Session

If you configure or change the password or key used for MD5 authentication between two MSDP peers, the local router will not tear down the existing session after you configure the password. The local router will attempt to maintain the peering session using the new password until the keepalive period expires. If the password is not entered or changed on the remote router before the keepalive period expires, the session will time out and the MSDP session will reset.

Usage Guidelines

The router specified should also be configured as a BGP neighbor.

The interface-type is on the router being configured.

If you are also BGP peering with this MSDP peer, you should use the same IP address for MSDP as you do for BGP. However, you are not required to run BGP or multiprotocol BGP with the MSDP peer, as long as there is a BGP or MBGP path between the MSDP peers. If there is no path, you must configure the ip msdp default-peer command.

The remote-as as-number keyword and argument are used for display purposes only.

A peer might appear to be in another autonomous system (other than the one it really resides in) when you have an MSDP peering session but do not have a BGP peer session with that peer. In this case, if the prefix of the peer is injected by another autonomous system, it displays as the autonomous system number of the peer.

Usage Guidelines

By default, an RP that is configured to run MSDP will originate SA messages for all local sources for which it is the RP. Local sources that register with an RP, therefore, will be advertised in SA messages, which in some cases is not desirable.

To control what sources are advertised in SA messages, you can configure SA origination filters on an RP using the ip msdp redistribute command. By creating SA origination filters, you can control the sources advertised in SA messages as follows:

• You can prevent an RP from originating SA messages for local sources by configuring the ip msdp redistribute command without any keywords or arguments. Issuing this form of the command effectively prevents the router from advertising local sources in SA messages.

Note	When the ip msdp redistribute command is entered without any keywords or arguments, the router will still forward SA messages from other MSDP peers in the normal fashion; it will just not originate any SA messages for local sources.

• You can configure the router to originate SA messages for (S, G) pairs defined in an extended access list by configuring the ip msdp redistribute command with the optional list keyword and access-list-name argument. Issuing this form of the command effectively configures the router to originate SA messages for local sources that are sending traffic to specific groups that match (S, G) pairs defined in the extended access list. All other local sources will not be advertised in SA messages.

• You can configure the router to originate SA messages for AS paths defined in an AS-path access list by configuring the ip msdp redistribute command with the optional asn keyword and as-access-list-number argument. Issuing this form of the command effectively configures the router to originate SA messages for local sources that are sending traffic to specific groups that the match AS paths defined in an AS-path access list. All other local sources will not be advertised in SA messages.

Note	AS-path access lists are configured using the ip as-path access-list command.

• You can configure the router to originate SA messages for local sources that match the criteria defined in a route map by configuring the ip msdp redistribute command with the optional route-map keyword and map-name argument. Issuing this form of the command effectively configures the router to originate SA messages for local sources that match the criteria defined in the route map. All other local sources will not be advertised in SA messages.

Note	You can configure an SA origination filter that includes an extended access list, an AS-path access list, and a route map (or a combination thereof). In that case, all conditions must be true before any local sources are advertised in SA messages.

Tip	This command affects SA message origination, not SA message forwarding or receipt. If you want to control the forwarding of SA messages to MSDP peers or control the receipt of SA messages from MSDP peers, use the ip msdp sa-filter out command or the ip msdp sa-filter in command, respectively.

Usage Guidelines

Use this command to enable MSDP peers to be compliant with peer-RPF forwarding rules specified in RFC 3618. Such compliance allows you to use Border Gateway Protocol (BGP) route reflectors without running MSDP on them. It also allows you to use an Interior Gateway Protocol (IGP) for the RPF check and thereby run peerings without BGP or Multicast Border Gateway Protocol (MBGP).

Usage Guidelines

If you use the ip msdp sa-filter in command without specifying access list name or route map match criteria, all source/group pairs from the peer are filtered.

If you use the route-map map-name keyword and argument pair, the specified MSDP peer passes only those SA messages that meet the match criteria.

If all match criteria are true, a permit keyword from the route map passes the routes through the filter. A deny keyword will filter routes.

Usage Guidelines

If you use the ip msdp sa-filter out command without specifying access list name or route map match criteria, all source and group pairs from the peer are filtered. If you do specify an access-list name, the specified MSDP peer passes only those SA messages that pass the extended access list.

If you use the route-map map-name keyword and argument pair, the specified MSDP peer passes only those SA messages that meet the match criteria.

If both the list and route-map keywords are used, all conditions must be true to pass any source and group pairs in outgoing SA messages.

If all match criteria are true, a permit keyword from the route map will pass routes through the filter. A deny keyword will filter routes.

Usage Guidelines

Use this command to configure MSDP SA limiters, which impose limits on the number of MSDP SA messages that an MSDP-enabled router can accept (can be cached) from an MSDP peer. This command provides a means to protect an MSDP-enabled router from denial of service (DoS) attacks.

Mechanics of MSDP SA Limiters

• When MSDP SA limiters are configured, the router maintains a per-peer count of SA messages stored in the SA cache.

• SA messages that exceed the limit configured for an MSDP peer are ignored.

• If the router receives SA messages in excess of the configured limit from an MSDP peer, a warning in the following format is generated (once a minute) until the cache is cleared:

%MSDP-4-SA_LIMIT: SA from peer <peer address or name>, RP <RP address> for <mroute> exceeded sa-limit of <configured SA limit for MSDP peer>

Tips for Configuring MSDP SA Limiters

• We recommended that you configure MSDP SA limiters for all MSDP peerings on the router.

• An appropriately low MSDP SA limit should be configured on peerings with a stub MSDP region (an MSDP peer that may have some further downstream peers but does not act as a transit for SA messages across the rest of the Internet).

• An appropriately high SA limit should be configured for all MSDP peerings that act as transits for MSDP SA messages across the Internet.

The output of the show ip msdp count , show ip msdp peer , and show ip msdp summary commands will display the number of SA messages from each MSDP peer that is in the SA cache. If the ip msdp sa-limit command is configured, the output of the show ip msdp peer command will also display the value of the SA message limit for each MSDP peer.

Usage Guidelines

By default, the router does not send any SA request messages to its MSDP peers when a new member joins a group and wants to receive multicast traffic. The new member waits to receive any SA messages that eventually arrive.

Use this command if you want a new member of a group to learn the current, active multicast sources in a connected Protocol Independent Multicast sparse mode (PIM-SM) domain that are sending to a group. The router will send SA request messages to the specified MSDP peer when a new member joins a group. The peer replies with the information in its SA cache. If the peer does not have a cache configured, this command provides nothing.

An alternative to this command is using the ip msdp cache-sa-state command to have the router cache messages.

Usage Guidelines

Use the ip msdp timer command to adjust the interval at which all MSDP peers will wait after peering sessions are reset before attempting to reestablish the peering sessions. This interval is referred to as the connection-retry interval. By default, MSDP peers will wait 30 seconds after is session is reset before attempting to reestablish sessions with other peers. When the ip msdp timer command is configured, the configured connection-retry interval applies to all MSDP peering sessions on the router.

In network environments where fast recovery of Source-Active (SA) messages is required (such as in trading floor network environments), you may want to decrease the connection-retry interval to a time value less than the default value of 30 seconds.

Usage Guidelines

This command limits which multicast data packets are sent in data-encapsulated SA messages. Only multicast packets with an IP header TTL greater than or equal to the ttl-value argument are sent to the MSDP peer specified by the IP address or name.

Use this command if you want to use TTL to scope your multicast data traffic. For example, you could limit internal traffic to a TTL of 8. If you want other groups to go to external locations, you would need to send those packets with a TTL greater than 8.

The default value of the ttl-value argument is 0, which means that all multicast data packets are forwarded to the peer until the TTL is exhausted.

Usage Guidelines

Use the ip multicast boundary command to configure an administratively scoped (user-defined) boundary on an interface in order to filter source traffic coming into the interface and prevent mroute states from being created on the interface.

Note	An IP multicast boundary enables reuse of the same multicast group address in different administrative domains.

A standard ACL is used with the ip multicast boundary command to define the group address range to be permitted or denied on an interface. An extended ACL is used with the ip multicast boundary to define (S, G) traffic to be permitted or denied on an interface. Extended ACLs can also be used to define the (*, G) state to be permitted or denied on an interface, by specifying host 0.0.0.0 for the source address in the permit statements that compose the extended ACL.

When you configure IP multicast boundaries for (S, G) traffic in an Any Source Multicast (ASM) network environment-to ensure that the IP multicast boundaries function properly-you must configure an extended ACL on routers along the rendezvous point tree (RPT) that permits:

• (S, G) traffic by specifying the source and group address range in permit statements.

• (*, G) traffic by specifying host 0.0.0.0 for the source address followed by the group address or group address range in permit statements.

• Traffic destined to the rendezvous point (RP) by including permit statements for (RP, G), where the IP address of the RP is specified for the source followed by the group address or group address range.

The IP multicast boundary guideline for ASM applies only to the routers on the RPT from the last-hop router to the RP. For routers on the RP-to-source branch, you need to define only the (S, G) traffic in the extended ACL (by specifying the source and group address range in permit statements).

When you configure IP multicast boundaries for (S, G) traffic in a Source Specific Multicast (SSM) network environment, you need to define only the (S, G) traffic to be permitted or denied on an interface in the extended ACL.

If you configure the filter-autorp keyword, the user-defined boundary also examines Auto-RP discovery and announcement messages and removes any Auto-RP group range announcements from the Auto-RP packets that are denied by the boundary ACL. An Auto-RP group range announcement is permitted and passed by the boundary only if all addresses in the Auto-RP group range are permitted by the boundary ACL. If any address is not permitted, the entire group range is filtered and removed from the Auto-RP message before the Auto-RP message is forwarded.

Note	Extended ACLs cannot be used with the filter-autorp keyword because Auto-RP announcements do not contain source addresses.

In Cisco IOS software releases that do not support the in and out keywords, the IP multicast boundary both filters source traffic coming into the interface and prevents mroute states from being created on the interface.

In Cisco IOS releases that support the in and out keywords, these keywords are used as follows:

• The in keyword is used to filter source traffic coming into the interface.

• The out keyword is used to prevent mroute states from being created on an interface; that is, it will prevent IGMP reports and PIM joins from creating mroutes states for groups and channels denied by the boundary ACL, and the interface will not be included in the outgoing interface list (OIL).

• If a direction is not specified with the ip multicast boundary command, the IP multicast boundary both filters source traffic coming into the interface and prevents mroute states from being created on the interface.

In addition, the following rules govern the use of the in , out , and filter-autorp keywords with the ip multicast boundary command:

• The in and out keywords support standard or extended ACLs for (S, G) filtering.

• The in and out keywords support standard or extended ACLs for SSM filtering.

• One instance of the in and out keywords can be configured on an interface.

• Only standard ACLs are permitted with the use of the filter -autorp keyword.

In Cisco 7600 series routers:

• A deny any statement at the end of the boundary ACL will cause all multicast boundaries including the link local address in the range (224.0.0.0 - 224.0.0.255) to be dropped in the hardware.

• When the ip multicast boundary access -list [filter -autorp ] command is configured with an empty ACL, it interferes in the proper functioning of Auto-RP in the hardware. Hence, it is important to specify the address you want to allow or deny in the access-list.

In Cisco IOS XE Release 3.2S and later releases, the access-list and filter-autorp argument and keyword are no longer required with the no form of this command.

In Cisco IOS XE Release 3.1S and earlier releases, the no ip multicast boundary command must be configured with the ACL and the filter-autorp keyword to remove the boundary ACL configuration.

A maximum of three instances of an ip multicast boundary command is allowed on an interface: one instance of the command with the in keyword, one instance of the command with the out keyword, and one instance of the command with or without the filter -autorp keyword.

Use the ip multicast boundary block source command to block all incoming multicast traffic on an interface. However, this command allows the multicast traffic to flow out the interface and allows any reserved multicast packets to flow in the interface. This command is primarily used at first-hop routers to prevent local hosts from functioning as multicast sources.

Usage Guidelines

IP multicast packet headers can be stored in a cache and then displayed to determine the following information:

• Who is sending IP multicast packets to which groups

• Interpacket delay

• Duplicate IP multicast packets (if any)

• Multicast forwarding loops in your network (if any)

• Scope of the group

• User Datagram Protocol (UDP) port numbers

• Packet length

Use the show ip mpacket command to display the buffer.

Usage Guidelines

This command is optional. If you want to receive all multicast traffic from all sources on the unidirectional link (UDL), as long as 15 is the lowest distance, you need not change the value of 15.

The default RPF interface is selected when an IGMP query message is received on a UDL and indicates to the router that all sources will use RPF to reach the UDL interface.

Any explicit sources learned by routing protocols will take preference as long as their distance is less than the distance argument configured with the ip multicast default-rpf-distance command.

You might consider changing the default value for one of the following reasons:

• To make IGMP prefer the UDL.

• To configure a value less than existing routing protocols.

• If you want to receive multicast packets from sources on interfaces other than the UDL interface. Configure a value greater than the distances of the existing routing protocols to make IGMP prefer the nonunidirectional link.

Usage Guidelines

Use the ip multicast group-range command to define a global range of IP multicast groups and channels to be permitted or denied. This command is used to disable multicast protocol actions and traffic forwarding for unauthorized groups or channels for all interfaces on the router.

Use the optional vrf keyword with the vrf-name argument to apply an IP multicast group address range to the MVRF instance specified for the vrf-name argument.

For the required access-list argument, specify an access list that defines the multicast groups or channels to be permitted or denied globally:

• A standard ACL can be used to define the group address range to be permitted or denied globally.

• An extended ACL is used with the ip multicast group-range command to define (S, G) traffic to be permitted or denied globally. Extended ACLs can also be used to define the (*, G) state to be permitted or denied globally, by specifying host 0.0.0.0 for the source address in the permit statements that compose the extended ACL.

Note	When using the ip multicast group-range command to configure a multicast address group range in an AutoRP network, you must explicitly permit the AutoRP groups (39/40) in the access list that defines the range; if not, AutoRP packets will not be accepted or forwarded.

Note	If AutoRP is enabled, but a specific group range is denied (for example, 224/8), an AutoRP message for that range will be accepted and the RP mapping will be put into the cache. However, state will not be created for those groups.

Usage Guidelines

This command is supported on Supervisor Engine 720, Supervisor Engine 32, Route Switching Processor 720, and compatible DFCDs.

Note	During the change from egress- to ingress-replication mode, traffic interruptions may occur because the shortcuts are purged and reinstalled. To avoid interruptions in traffic forwarding, enter the ip multicast hardware-switching replication-mode ingress command.

If you enter the no ip multicast hardware-switching replication-mode egress command, only the forced-egress mode resets and not the forced-ingress mode.

If you enter the no ip multicast hardware-switching replication-mode ingress command, only the forced-ingress mode resets and not the forced-egress mode.

Usage Guidelines

Use the ip multicast heartbeat command to configure a multicast router to send SNMP traps to a network management station (NMS) when multicast source traffic being sent to a multicast group fails to meet certain multicast delivery parameters.

When this command is configured, the router monitors multicast source traffic destined to the multicast group address specified for the group-address argument for the number of seconds configured for the seconds argument (the interval). The number of packets present in the interval is not as important as whether any multicast source packets destined to the group were forwarded at all during the interval. A “heartbeat” is present if at least one source packet sent to the group was forwarded during the interval.

Note	A multicast heartbeat is determined by the counter of both the (*, G) and the (S, G) state of a group being tracked. An increment in the counters of any such state is considered to constitute forwarding for the group within the interval.

In addition to the required seconds argument value, two other required parameters must be configured: a value for the minimum-number-intervals argument and a value for the window-size argument. The minimum-number-intervals argument is used to specify the minimum number of intervals where a multicast heartbeat must be present. The window-size argument is used to specify the number of intervals to monitor for a multicast heartbeat (the interval window).

If the router detects a heartbeat in fewer intervals than the minimum, after the interval window, an SNMP trap would be sent from this router to an NMS. The SNMP trap is used to indicate a loss of heartbeat. The SNMP trap triggered by this command is ciscoIpMRouteMissingHeartBeats, which is defined in CISCO-IPMROUTE-MIB.

The ip multicast heartbeat command will not create a multicast forwarding state in the router. Use the ip igmp static-group command on the router or on a downstream router to force forwarding of IP multicast traffic.

Use the snmp-server enable traps command with the ipmulticast keyword to enable the generation of traps associated with multicast heartbeat monitoring. Use the snmp-server host command to configure the sending of IP multicast traps to specific receiver hosts.

Use the debug ip mhbeat command to enable debugging output for IP multicast heartbeat monitoring.

Usage Guidelines

When a multicast-capable internetwork is between two broadcast-only internetworks, you can convert broadcast traffic to multicast at the first hop router, and convert it back to broadcast at the last hop router before delivering the packets to the broadcast clients. However, broadcast packets with the IP source address of 0.0.0.0 (such as a Dynamic Host Configuration Protocol [DHCP] request) will not be translated to any multicast group. Thus, you can take advantage of the multicast capability of the intermediate multicast internetwork. This feature prevents unnecessary replication at the intermediate routers and allows multicast fast switching in the multicast internetwork.

If you need to send a directed broadcast to the subnet, the outgoing interface of the last hop router can be configured with an IP broadcast address of x.x.x.255, where x.x.x.0 is the subnet that you are trying to reach; otherwise, the packet will be converted to 255.255.255.255.

By default, many broadcast applications use a default TTL value of 1. Because the helper-map applies the decremented TTL value of the incoming broadcast packet for the generated multicast packet, and most broadcast applications use a TTL value of 1 hop, broadcast packets may not be translated to multicast packets, and thus, may be dropped rather than forwarded. To circumvent this potential issue, you can manually configure the TTL value for broadcast packets being translated into multicast packets using the ttl keyword and remapping-value argument. For the remapping-value argument, specify a value that will enable the translated packets to reach multicast receivers.

Usage Guidelines

Use the ip multicast limit command to configure mroute state limiters on an interface.

The following forms of the ip multicast limit command are available to configure per interface mroute state limiters:

• ip multicast limit access-list max-entries

This command limits mroute state creation for an ACL-classified set of traffic on an interface when the interface is an outgoing (egress) interface, and limits mroute outgoing interface list (olist) membership when the interface is an incoming (ingress) Reverse Path Forwarding (RPF) interface.

This type of per interface mroute state limiter limits mroute state creation--by accounting each time an mroute permitted by the ACL is created or deleted--and limits mroute olist membership--by accounting each time that an mroute olist member permitted by the ACL is added or removed.

Use the ip multicast limit command without the optional keywords to limit mroute state creation for an ACL-classified set of traffic on an interface when the interface is an outgoing (egress) interface, and to limit mroute olist membership when the interface is an incoming (ingress) Reverse Path Forwarding (RPF) interface. This type of mroute state limiter limits mroute state creation by accounting each time an mroute permitted by the ACL is created or deleted and limits mroute olist membership by accounting each time that an mroute olist member permitted by the ACL is added or removed. Entering this form of the command (that is, with no optional keywords) is equivalent to specifying the ip multicast limit rpf and ip multicast limit out forms of the command.

• ip multicast limit connected access-list max-entries

This command limits mroute state creation for an ACL-classified set of multicast traffic on an incoming (RPF) interface that is directly connected to a multicast source by accounting each time that an mroute permitted by the ACL is created or deleted.

• ip multicast limit out access-list max-entries

This command limits mroute olist membership on an outgoing interface for an ACL-classified set of multicast traffic by accounting each time that an mroute olist member permitted by the ACL is added or removed.

• ip multicast limit rpf access-list max-entries

This command limits mroute state creation for an ACL-classified set of multicast traffic on an incoming (RPF) interface by accounting each time an mroute permitted by the ACL is created or deleted.

For the required access-list argument, specify the ACL that defines the IP multicast traffic to be limited on an interface. A standard or extended ACL can be specified. Standard ACLs can be used to define the (*, G) state to be limited on an interface. Extended ACLs can be used to define the (S, G) state to be limited on an interface. Extended ACLs also can be used to define the (*, G) state to be limited on an interface, by specifying 0.0.0.0 for the source address and source wildcard--referred to as (0, G)--in the permit or deny statements that compose the extended access list.

Mechanics of Per Interface Mroute State Limiters

The mechanics of per interface mroute state limiters are as follows:

• Each time the state for an mroute is created or deleted and each time an olist member is added or removed, the Cisco IOS software searches for a corresponding per interface mroute state limiter that matches the mroute.

• In the case of the creation and deletion of mroutes, the Cisco IOS software searches for a per interface mroute state limiter configured on the incoming (RPF) interface that matches the mroute to be created or deleted. In the case of olist member addition or removal, the Cisco IOS software searches for a per interface mroute state limiter configured on the outgoing interface that matches the mroute to be added or removed.

• The Cisco IOS software performs a top-down search from the list of configured per interface mroute state limiters. Only per interface mroute state limiters that match the direction of traffic are considered. The first per interface mroute state limiter that matches is used for limiting (sometimes referred to as accounting ). A match is found when the ACL permits the mroute state.

• When a match is found, the counter of the per interface mroute state limiter is updated (increased or decreased). If no per interface mroute state limiter is found that matches an mroute, no accounting is performed for the mroute (because there is no counter to update).

• The amount to update the counter with is called the cost (sometimes referred to as the cost multiplier ). The default cost is 1.

Note

A per interface mroute state limiter always allows the deletion of an mroute or the removal of an interface from the olist. In those cases, the respective per interface mroute state limiter decreases the counter by the value of the cost multiplier. In addition, RPF changes to an existing mroute are always allowed (in order to not affect existing traffic). However, a per interface mroute state limiter only allows the creation of an mroute or the addition of an mroute olist member if adding the cost does not exceed the maximum number of mroutes permitted.

Tips for Configuring Per Interface Mroute State Limiters

• To ensure that all mroutes are accounted, you can configure a per interface mroute state limiter whose ACL contains a permit any statement and set the maximum for the max-entries argument to 0. Configuring an mroute state limiter in this manner effectively denies all fall through states, which may be a way to prevent a multicast DoS attack in and out of the interface.

• When creating an ACL, remember that, by default, the end of the ACL contains an implicit deny any statement for everything if it did not find a match before reaching the end.

• An explicit deny statement for a specific mroute in an ACL can be used to specify the state that will not match the ACL (thus, preventing the ACL from being accounted). If an mroute matches a deny statement, the search immediately continues to the next configured mroute state limiter. Configuring an explicit deny statement in an ACL can be more efficient than forcing the mroute to fall through an ACL (by means of the implicit deny any statement at the end of the ACL).

Usage Guidelines

Use this command to apply a cost to mroutes that match per interface mroute state limiters (configured with the ip multicast limit command in interface configuration mode). This command is primarily used to provide bandwidth-based Call Admission Control (CAC) in network environments where multicast flows utilize different amounts of bandwidth. Accordingly, when this command is configured, the configuration is usually referred to as a bandwidth-based multicast CAC policy.

ACLs are used with this command to define the IP multicast traffic for which to apply a cost. Standard ACLs can be used to define the (*, G) state. Extended ACLs can be used to define the (S, G) state. Extended ACLs also can be used to define the (*, G) state, by specifying 0.0.0.0 for the source address and source wildcard--referred to as (0, G)--in the permit or deny statements that compose the extended access list.

Bandwidth-based CAC policies are used with per interface mroute state limiters. Bandwidth-based CAC policies provide the capability to define costs (globally or per MVRF instance) to be applied to mroutes that are being limited by an mroute state limiter. The cost-multiplier argument is used to specify the cost to apply to mroutes that match the ACL specified for the access-list argument.