match the (S, G) pairs defined in the extended access list. All other incoming SA messages from the
MSDP peer will be ignored.
•
You can filter a subset of incoming SA request messages from a specified peer based on match criteria
defined in a route map by configuring the device to only receive SA messages that match the criteria
defined in the route map. All other incoming SA messages from the MSDP peer will be ignored.
•
You can filter a subset of incoming SA messages from a specified peer based on both (S, G) pairs defined
in an extended access list and on match criteria defined in a route map by configuring the device to only
receive incoming SA messages that both match the (S, G) pairs defined in the extended access list and
match the criteria defined in the route map. All other incoming SA messages from the MSDP peer will
be ignored.
•
You can filter a subset of incoming SA messages from a specified peer based on the announcing RP
address contained in the SA message by configuring the device to filter incoming SA messages based
on their origin, even after the SA message may have already been transmitted across one or more MSDP
peers.
•
You can configure an incoming filter list that includes an extended access list, a route map, and either
an RP access list or an RP route map. In this case, all conditions must be true for the MSDP peer to
receive the incoming SA message.
Arbitrary filtering of SA messages can result in downstream MSDP peers being starved of SA messages
for legitimate active sources. Care, therefore, should be taken when using these sorts of filters. Normally,
incoming filter lists are used only to reject undesirable sources, such as sources using private addresses.
Caution
TTL Thresholds in MSDP
The time-to-live (TTL) value provides a means to limit the number of hops a packet can take before being
dropped. The
ip multicast ttl-threshold
command is used to specify a TTL for data-encapsulated SA messages
sent to specified MSDP peers. By default, multicast data packets in SA messages are sent to an MSDP peer,
provided the TTL value of the packet is greater than 0, which is standard TTL behavior.
In general, a TTL-threshold problem can be introduced by the encapsulation of a source
’
s initial multicast
packet in an SA message. Because the multicast packet is encapsulated inside of the unicast SA message
(whose TTL is 255), its TTL is not decremented as the SA message travels to the MSDP peer. Furthermore,
the total number of hops that the SA message traverses can be drastically different than a normal multicast
packet because multicast and unicast traffic may follow completely different paths to the MSDP peer and
hence the remote PIM-SM domain. As a result, encapsulated packets can end up violating TTL thresholds.
The solution to this problem is to configure a TTL threshold that is associated with any multicast packet that
is encapsulated in an SA message sent to a particular MSDP peer using the
ip multicast ttl-threshold
command.
The
ip msdp ttl-threshold
command prevents any multicast packet whose TTL in the IP header is less than
the TTL value specified for the
ttl-value
argument from being encapsulated in SA messages sent to that peer.
SA Request Messages
You can configure a noncaching device to send SA request messages to one or more specified MSDP peers.
IP Multicast Routing Configuration Guide, Cisco IOS XE Release 3SE (Catalyst 3650 Switches)
OL-29890-01
183
Configuring MSDP
TTL Thresholds in MSDP
