The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Your software release may not support all the features documented in this module. For the latest caveats and feature information,
see
Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module,
and to see a list of the releases in which each feature is supported, see the feature information table at the end of this
module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature
Navigator, go to
www.cisco.com/go/cfn. An account on Cisco.com is not required.
Prerequisites for
Configuring SSM
The
following are the prerequisites for configuring source-specific multicast (SSM)
and SSM mapping:
Before you configure SSM
mapping, you must perform the following tasks:
Enable IP
multicast routing.
Enable PIM
sparse mode.
Configure
SSM.
Before you configure static
SSM mapping, you must configure access control lists (ACLs) that define the
group ranges to be mapped to source addresses.
Before you can configure and use SSM mapping with DNS lookups, you need
to add records to a running DNS server. If you do not already have a DNS server
running, you need to install one.
Note
You can use
a product such as
Cisco Network Registrar
to add records to a running DNS server.
Restrictions for
Configuring SSM
The following are
the restrictions for configuring SSM:
To run SSM with
IGMPv3, SSM must be supported in the Cisco IOS router, the host where the
application is running, and the application itself.
Existing applications in a network predating SSM will not work within
the SSM range unless they are modified to support (S, G) channel
subscriptions. Therefore, enabling SSM in a network may cause problems for existing
applications if they use addresses within the designated SSM range.
IGMP
Snooping—IGMPv3 uses new membership report messages that might not be correctly
recognized by older IGMP snooping
devices.
Address management is still necessary to some degree when SSM is used
with Layer 2 switching mechanisms. Cisco Group Management Protocol (CGMP), IGMP
snooping, or Router-Port Group Management Protocol (RGMP) support only
group-specific filtering, not (S, G) channel-specific filtering. If different
receivers in a switched network request different (S, G) channels sharing the
same group, they do not benefit from these existing mechanisms. Instead, both
receivers receive all (S, G) channel traffic and filter out the unwanted
traffic on input. Because SSM can re-use the group addresses in the SSM range
for many independent applications, this situation can lead to decreased traffic
filtering in a switched network. For this reason, it is important to use random
IP addresses from the SSM range for an application to minimize the chance for
re-use of a single address within the SSM range between different applications.
For example, an application service providing a set of television channels
should, even with SSM, use a different group for each television (S, G)
channel. This setup guarantees that multiple receivers to different channels
within the same application service never experience traffic aliasing in
networks that include Layer 2 devices.
In PIM-SSM, the last hop router will continue to periodically send (S,
G) join messages if appropriate (S, G) subscriptions are on the interfaces.
Therefore, as long as receivers send (S, G) subscriptions, the shortest path
tree (SPT) state from the receivers to the source will be maintained, even if
the source is not sending traffic for longer periods of time (or even never).
The opposite
situation occurs with PIM-SM, where (S, G) state is maintained only if the
source is sending traffic and receivers are joining the group. If a source
stops sending traffic for more than 3 minutes in PIM-SM, the (S, G) state is
deleted and only reestablished after packets from the source arrive again
through the RPT (rendezvous point tree). Because no mechanism in PIM-SSM
notifies a receiver that a source is active, the network must maintain the (S,
G) state in PIM-SSM as long as receivers are requesting receipt of that
channel.
The following are
the restrictions for configuring SSM mapping:
The SSM Mapping feature does
not share the benefit of full SSM. SSM mapping takes a group G join from a host and identifies this
group with an application associated with one or more sources, therefore, it
can only support one such application per group G. Nevertheless, full SSM
applications may still share the same group also used in SSM mapping.
Enable IGMPv3 with care on the last hop router when you rely solely
on SSM mapping as a transition solution for full SSM.
When you enable both SSM
mapping and IGMPv3 and the hosts already support IGMPv3 (but not SSM), the
hosts send IGMPv3 group reports. SSM mapping does not support these IGMPv3
group reports, and the router does not correctly associate sources with these
reports.
Information About SSM and SSM Mapping
SSM Components
Overview
SSM is a datagram
delivery model that best supports one-to-many applications, also known as
broadcast applications.
It is an extension of IP
multicast in which datagram traffic is forwarded to receivers from only those
multicast sources that the receivers have explicitly joined. For multicast
groups configured for SSM, only SSM distribution trees (no shared trees) are
created.
SSM is a core
networking technology for Cisco's implementation of IP multicast solutions
targeted for audio and video broadcast application environments and is
described in RFC 3569. The following components together support the
implementation of SSM:
Internet Group
Management Protocol Version 3 (IGMPv3)
Protocol Independent
Multicast (PIM) SSM, or PIM-SSM, is the routing protocol that supports the
implementation of SSM and is derived from PIM sparse mode (PIM-SM). IGMP is the
Internet Engineering Task Force (IETF) standards track protocol used for hosts
to signal multicast group membership to routers. IGMP Version 3 supports source
filtering, which is required for SSM. IGMP For SSM to run with IGMPv3, SSM must
be supported in the router, the host where the application is running, and the
application itself.
How SSM Differs from Internet Standard Multicast
The standard IP multicast infrastructure in the Internet and many enterprise intranets is based on the PIM-SM protocol and
Multicast Source Discovery Protocol (MSDP). These protocols have proved to be reliable, extensive, and efficient. However,
they are bound to the complexity and functionality limitations of the Internet Standard Multicast (ISM) service model. For
example, with ISM, the network must maintain knowledge about which hosts in the network are actively sending multicast traffic.
With SSM, this information is provided by receivers through the source addresses relayed to the last-hop devices by IGMPv3.
SSM is an incremental response to the issues associated with ISM and is intended to coexist in the network with the protocols
developed for ISM. In general, SSM provides IP multicast service for applications that utilize SSM.
ISM service is described in RFC 1112. This service consists of the delivery of IP datagrams from any source to a group of
receivers called the multicast host group. The datagram traffic for the multicast host group consists of datagrams with an
arbitrary IP unicast source address S and the multicast group address G as the IP destination address. Systems will receive
this traffic by becoming members of the host group. Membership in a host group simply requires signaling the host group through
IGMP Version 1, 2, or 3.
In SSM, delivery of datagrams is based on (S, G) channels. Traffic for one (S, G) channel consists of datagrams with an IP
unicast source address S and the multicast group address G as the IP destination address. Systems will receive this traffic
by becoming members of the (S, G) channel. In both SSM and ISM, no signaling is required to become a source. However, in SSM,
receivers must subscribe or unsubscribe to (S, G) channels to receive or not receive traffic from specific sources. In other
words, receivers can receive traffic only from (S, G) channels to which they are subscribed, whereas in ISM, receivers need
not know the IP addresses of sources from which they receive their traffic. The proposed standard approach for channel subscription
signaling utilizes IGMP INCLUDE mode membership reports, which are supported only in IGMP Version 3.
SSM can coexist with the ISM service by applying the SSM delivery model to a configured subset of the IP multicast group
address range. The Internet Assigned Numbers Authority (IANA) has reserved the address range from 232.0.0.0 through 232.255.255.255
for SSM applications and protocols. The software allows SSM configuration for an arbitrary subset of the IP multicast address
range from 224.0.0.0 through 239.255.255.255. When an SSM range is defined, an existing IP multicast receiver application
will not receive any traffic when it tries to use addresses in the SSM range unless the application is modified to use explicit
(S, G) channel subscription or is SSM-enabled through a URL Rendezvous Directory (URD).
SSM Operations
An established network in which IP multicast service is based on PIM-SM can support SSM services. SSM can also be deployed
alone in a network without the full range of protocols that are required for interdomain PIM-SM. That is, SSM does not require
an RP, so there is no need for an RP mechanism such as Auto-RP, MSDP, or bootstrap router (BSR).
If SSM is deployed in a network that is already configured for PIM-SM, then only the last-hop routers must be upgraded to
a software image that supports SSM. Routers that are not directly connected to receivers do not have to upgrade to a software
image that supports SSM. In general, these non-last-hop routers must only run PIM-SM in the SSM range. They may need additional
access control configuration to suppress MSDP signaling, registering, or PIM-SM shared-tree operations from occurring within
the SSM range.
The SSM mode of operation is enabled by configuring the SSM range using the ippimssm global configuration command. This configuration has the following effects:
For groups within the SSM range, (S, G) channel subscriptions are accepted through IGMPv3 INCLUDE mode membership reports.
PIM operations within the SSM range of addresses change to PIM-SSM, a mode derived from PIM-SM. In this mode, only PIM (S,
G) Join and Prune messages are generated by the router. Incoming messages related to rendezvous point tree (RPT) operations
are ignored or rejected, and incoming PIM register messages are immediately answered with Register-Stop messages. PIM-SSM
is backward-compatible with PIM-SM unless a router is a last-hop router. Therefore, routers that are not last-hop routers
can run PIM-SM for SSM groups (for example, if they do not yet support SSM).
For groups within the SSM range, no MSDP Source-Active (SA) messages within the SSM range will be accepted, generated, or
forwarded.
IGMPv3 Host Signaling
IGMPv3 is the third
version of the IETF standards track protocol in which hosts signal membership
to last-hop routers of multicast groups. IGMPv3 introduces the ability for
hosts to signal group membership that allows filtering capabilities with
respect to sources. A host can signal either that it wants to receive traffic
from all sources sending to a group except for some specific sources (a mode
called EXCLUDE) or that it wants to receive traffic only from some specific
sources sending to the group (a mode called INCLUDE).
IGMPv3 can operate
with both ISM and SSM. In ISM, both EXCLUDE and INCLUDE mode reports are
accepted by the last-hop router. In SSM, only INCLUDE mode reports are accepted
by the last-hop router.
Benefits of
SSM
IP Multicast Address
Management Not Required
In the ISM service,
applications must acquire a unique IP multicast group address because traffic
distribution is based only on the IP multicast group address used. If two
applications with different sources and receivers use the same IP multicast
group address, then receivers of both applications will receive traffic from
the senders of both applications. Even though the receivers, if programmed
appropriately, can filter out the unwanted traffic, this situation would cause
generally unacceptable levels of unwanted traffic.
Allocating a unique
IP multicast group address for an application is still a problem. Most
short-lived applications use mechanisms like Session Description Protocol (SDP)
and Session Announcement Protocol (SAP) to get a random address, a solution
that does not work well with a rising number of applications in the Internet.
The best current solution for long-lived applications is described in RFC 2770,
but this solution suffers from the restriction that each autonomous system is
limited to only 255 usable IP multicast addresses.
In SSM, traffic
from each source is forwarded between routers in the network independent of
traffic from other sources. Thus different sources can reuse multicast group
addresses in the SSM range.
Denial of Service Attacks
from Unwanted Sources Inhibited
In SSM, multicast
traffic from each individual source will be transported across the network only
if it was requested (through IGMPv3, IGMP v3lite, or URD memberships) from a
receiver. In contrast, ISM forwards traffic from any active source sending to a
multicast group to all receivers requesting that multicast group. In Internet
broadcast applications, this ISM behavior is highly undesirable because it
allows unwanted sources to easily disturb the actual Internet broadcast source
by simply sending traffic to the same multicast group. This situation depletes
bandwidth at the receiver side with unwanted traffic and thus disrupts the
undisturbed reception of the Internet broadcast. In SSM, this type of denial of
service (DoS) attack cannot be made by simply sending traffic to a multicast
group.
Easy to Install and
Manage
SSM is easy to
install and provision in a network because it does not require the network to
maintain which active sources are sending to multicast groups. This requirement
exists in ISM (with IGMPv1, IGMPv2, or IGMPv3).
The current
standard solutions for ISM service are PIM-SM and MSDP. Rendezvous point (RP)
management in PIM-SM (including the necessity for Auto-RP or BSR) and MSDP is
required only for the network to learn about active sources. This management is
not necessary in SSM, which makes SSM easier than ISM to install and manage,
and therefore easier than ISM to operationally scale in deployment. Another
factor that contributes to the ease of installation of SSM is the fact that it
can leverage preexisting PIM-SM networks and requires only the upgrade of last
hop routers to support IGMPv3, IGMP v3lite, or URD.
Ideal for Internet Broadcast
Applications
The three benefits
previously described make SSM ideal for Internet broadcast-style applications
for the following reasons:
The ability to
provide Internet broadcast services through SSM without the need for unique IP
multicast addresses allows content providers to easily offer their service (IP
multicast address allocation has been a serious problem for content providers
in the past).
The prevention
against DoS attacks is an important factor for Internet broadcast services
because, with their exposure to a large number of receivers, they are the most
common targets for such attacks.
The ease of
installation and operation of SSM makes it ideal for network operators,
especially in those cases where content needs to be forwarded between multiple
independent PIM domains (because there is no need to manage MSDP for SSM
between PIM domains).
SSM Mapping Overview
SSM mapping supports
SSM transition
when supporting SSM on the end system is impossible or unwanted due
to administrative or technical reasons. Using SSM to deliver live streaming
video to legacy STBs that do not support IGMPv3
or for applications that do
not use the IGMPv3 host stack is a typical application of SSM mapping.
In a typical STB
deployment, each TV channel uses one separate IP multicast group and has one
active server host sending the TV channel. A single server may of course send
multiple TV channels, but each to a different group. In this network
environment, if a router receives an IGMPv1 or IGMPv2 membership report for a
particular group G, the report implicitly addresses the well-known TV server
for the TV channel associated with the multicast group.
SSM mapping
introduces a means for the last hop router to discover sources sending to
groups. When SSM mapping is configured, if a router receives an IGMPv1 or
IGMPv2 membership report for a particular group G, the router translates this
report into one or more (S, G) channel memberships for the well-known sources
associated with this group.
When the router
receives an IGMPv1 or IGMPv2 membership report for group G, the router uses SSM
mapping to determine one or more source IP addresses for group G. SSM mapping
then translates the membership report as an IGMPv3 report INCLUDE (G, [S1, G],
[S2, G]...[Sn, G] and continues as if it had received an IGMPv3 report. The
router then sends out PIM joins toward (S1, G) to (Sn, G) and continues to be
joined to these groups as long as it continues to receive the IGMPv1 or IGMPv2
membership reports and as long as
it continues to receive the
IGMPv1 or IGMPv2 membership reports, and the SSM mapping for the group
remains the same. SSM mapping, thus, enables you to leverage SSM for video
delivery to legacy STBs that do not support IGMPv3 or for applications that do
not take advantage of the IGMPv3 host stack.
SSM mapping enables
the last hop router to determine the source addresses either by a statically
configured table on the router or by consulting a DNS server. When the
statically configured table is changed, or when the DNS mapping changes, the
router will leave the current sources associated with the joined groups.
Static SSM Mapping
SSM static mapping
enables you to configure the last hop router to use a static map to determine
the sources sending to groups. Static SSM mapping requires that you configure
access lists (ACLs) to define group ranges. The groups permitted by those ACLs
then can be mapped to sources using the
ipigmpstaticssm-map global configuration command.
You can configure
static SSM mapping in smaller networks when a DNS is not needed or to locally
override DNS mappings that may be temporarily incorrect. When configured,
static SSM mappings take precedence over DNS mappings.
DNS-Based SSM Mapping
DNS-based SSM mapping
enables you to configure the last hop router to perform a reverse DNS lookup to
determine sources sending to groups (see the figure below). When DNS-based SSM
mapping is configured, the router constructs a domain name that includes the
group address G and performs a reverse lookup into the DNS. The router looks up
IP address resource records (IP A RRs) to be returned for this constructed
domain name and uses the returned IP addresses as the source addresses
associated with this group. SSM mapping supports up to 20 sources for each
group. The router joins all sources configured for a group.
The SSM mapping
mechanism that enables the last hop router to join multiple sources for a group
can be used to provide source redundancy for a TV broadcast. In this context,
the redundancy is provided by the last hop router using SSM mapping to join two
video sources simultaneously for the same TV channel. However, to prevent the
last hop router from duplicating the video traffic, it is necessary that the
video sources utilize a server-side switchover mechanism where one video source
is active while the other backup video source is passive. The passive source
waits until an active source failure is detected before sending the video
traffic for the TV channel. The server-side switchover mechanism, thus, ensures
that only one of the servers is actively sending the video traffic for the TV
channel.
To look up one or
more source addresses for a group G that includes G1, G2, G3, and G4, the
following DNS resource records (RRs) must be configured on the DNS server:
G4.G3.G2.G1
[multicast-domain] [timeout]
IN A
source-address-1
IN Asource-address-2
IN Asource-address-n
The
multicast-domain argument is a configurable DNS
prefix. The default DNS prefix is in-addr.arpa. You should only use the default
prefix when your installation is either separate from the internet or if the
group names that you map are global scope group addresses (RFC 2770 type
addresses that you configure for SSM) that you own.
The
timeout
argument configures the length of time for which the router performing SSM
mapping will cache the DNS lookup. This argument is optional and defaults to
the timeout of the zone in which this entry is configured. The timeout
indicates how long the router will keep the current mapping before querying the
DNS server for this group. The timeout is derived from the cache time of the
DNS RR entry and can be configured for each group/source entry on the DNS
server. You can configure this time for larger values if you want to minimize
the number of DNS queries generated by the router. Configure this time for a
low value if you want to be able to quickly update all routers with new source
addresses.
Note
Refer to your DNS
server documentation for more information about configuring DNS RRs.
To configure
DNS-based SSM mapping in the software, you must configure a few global commands
but no per-channel specific configuration is needed. There is no change to the
configuration for SSM mapping if additional channels are added. When DNS-based
SSM mapping is configured, the mappings are handled entirely by one or more DNS
servers. All DNS techniques for configuration and redundancy management can be
applied to the entries needed for DNS-based SSM mapping.
SSM Mapping Benefits
The SSM Mapping feature provides almost the same ease of network installation and management as a pure SSM solution based
on IGMPv3. Some additional configuration is necessary to enable SSM mapping.
The SSM benefit of inhibition of DoS attacks applies when SSM mapping is configured. When SSM mapping is configured the only
segment of the network that may still be vulnerable to DoS attacks are receivers on the LAN connected to the last hop router.
Since those receivers may still be using IGMPv1 and IGMPv2, they are vulnerable to attacks from unwanted sources on the same
LAN. SSM mapping, however, does protect those receivers (and the network path leading towards them) from multicast traffic
from unwanted sources anywhere else in the network.
Address assignment within a network using SSM mapping needs to be coordinated, but it does not need assignment from outside
authorities, even if the content from the network is to be transited into other networks.
How to Configure SSM and SSM Mapping
Configuring Source Specific
Multicast
Follow these steps to configure
SSM:
Before you begin
If you want to use
an access list to define the Source Specific Multicast (SSM) range, configure
the access list before you reference the access list in the
ippimssm command.
SUMMARY STEPS
enable
configureterminal
ipmulticast-routing [distributed]
ippimssm {default |
rangeaccess-list}
interfacetypenumber
ippimsparse-mode
Repeat Steps 1
through 6 on every interface that uses IP multicast.
(Optional)
Displays the multicast groups having receivers that are directly connected to
the device and that were learned through IGMP.
A
receiver must be active on the network at the time that this command is issued
in order for receiver information to be present on the resulting display.
Step 12
showipmroute
Example:
Device# show ip mroute
(Optional)
Displays the contents of the IP mroute table.
This
command displays whether a multicast group is configured for SSM service or a
source-specific host report has been received.
Configuring SSM Mapping
Configuring Static SSM
Mapping(CLI)
Perform this task
to configure the last hop router in an SSM deployment to use static SSM mapping
to determine the IP addresses of sources sending to groups.
Before you begin
Enable IP
multicast routing, enable PIM sparse mode, and configure SSM before performing
this task.
.
Before you
configure static SSM mapping, you must configure ACLs that define the group
ranges to be mapped to source addresses.
SUMMARY STEPS
enable
configureterminal
ipigmpssm-mapenable
noipigmpssm-mapquerydns
ipigmpssm-mapstaticaccess-listsource-address
Repeat Step 5
to configure additional static SSM mappings, if required.
end
show running-config
copy running-config
startup-config
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables
privileged EXEC mode.
Enter your
password if prompted.
Step 2
configureterminal
Example:
Device# configure terminal
Enters global
configuration mode.
Step 3
ipigmpssm-mapenable
Example:
Device(config)# ip igmp ssm-map enable
Enables SSM
mapping for groups in the configured SSM range.
Note
By default,
this command enables DNS-based SSM mapping.
Step 4
noipigmpssm-mapquerydns
Example:
Device(config)# no ip igmp ssm-map query dns
(Optional)
Disables DNS-based SSM mapping.
Note
Disable
DNS-based SSM mapping if you only want to rely on static SSM mapping. By
default, the
ipigmpssm-map command
enables DNS-based SSM mapping.
Step 5
ipigmpssm-mapstaticaccess-listsource-address
Example:
Device(config)# ip igmp ssm-map static 11 172.16.8.11
Configures
static SSM mapping.
The ACL
supplied for the
access-list
argument defines the groups to be mapped to the source IP address entered for
the
source-address
argument.
Note
You can
configure additional static SSM mappings. If additional SSM mappings are
configured and the router receives an IGMPv1 or IGMPv2 membership report for a
group in the SSM range, the
device determines the source addresses
associated with the group by walking each configured
ipigmpssm-mapstatic command. The
device associates up to 20 sources per
group.
Step 6
Repeat Step 5
to configure additional static SSM mappings, if required.
--
Step 7
end
Example:
Device(config)# end
Ends the
current configuration session and returns to privileged EXEC mode.
Step 8
show running-config
Example:
Device# show running-config
Verifies your entries.
Step 9
copy running-config
startup-config
Example:
Device# copy running-config startup-config
(Optional) Saves your entries
in the configuration file.
Configuring DNS-Based SSM
Mapping(CLI)
Perform this task
to configure the last hop router to perform DNS lookups to learn the IP
addresses of sources sending to a group.
Before you begin
Enable IP
multicast routing, enable PIM sparse mode, and configure SSM before performing
this task.
.
Before you can
configure and use SSM mapping with DNS lookups, you need to be able to add
records to a running DNS server. If you do not already have a DNS server
running, you need to install one.
Specifies the
address of one or more name servers to use for name and address resolution.
Step 7
Repeat Step
Step 6 to configure additional DNS
servers for redundancy, if required.
--
Step 8
end
Example:
Device(config-if)# end
Returns to
privileged EXEC mode.
Step 9
show running-config
Example:
Device# show running-config
Verifies your entries.
Step 10
copy running-config
startup-config
Example:
Device# copy running-config startup-config
(Optional) Saves your entries
in the configuration file.
Configuring Static Traffic Forwarding with SSM Mapping
Perform this task to configure static traffic forwarding with SSM mapping on the last hop router. Static traffic forwarding
can be used in conjunction with SSM mapping to statically forward SSM traffic for certain groups. When static traffic forwarding
with SSM mapping is configured, the last hop router uses DNS-based SSM mapping to determine the sources associated with a
group. The resulting (S, G) channels are then statically forwarded.
Before you begin
This task does not include the steps for configuring DNS-based SSM mapping. See the Configuring DNS-Based SSM Mapping(CLI) task for more information about configuring DNS-based SSM mapping.
SUMMARY STEPS
enable
configureterminal
interfacetypenumber
ipigmpstatic-groupgroup-addresssourcessm-map
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Router> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configureterminal
Example:
Router# configure terminal
Enters global configuration mode.
Step 3
interfacetypenumber
Example:
Router(config)# interface gigabitethernet 1/0/0
Selects an interface on which to statically forward traffic for a multicast group using SSM mapping and enters interface configuration
mode.
Note
Static forwarding of traffic with SSM mapping works with either DNS-based SSM mapping or statically-configured SSM mapping.
Step 4
ipigmpstatic-groupgroup-addresssourcessm-map
Example:
Router(config-if)# ip igmp static-group 232.1.2.1 source ssm-map
Configures SSM mapping to be used to statically forward a (S, G) channel out of the interface.
Use this command if you want to statically forward SSM traffic for certain groups, but you want to use DNS-based SSM mapping
to determine the source addresses of the channels.
Configuring Static Traffic Forwarding with SSM Mapping
(CLI)
Follow these steps to
configure static traffic forwarding with SSM mapping on the last hop router:
SUMMARY STEPS
enable
configureterminal
interfaceinterface-id
ip igmp
static-groupgroup-addresssource ssm-map
end
show running-config
copy running-config
startup-config
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables
privileged EXEC mode. Enter your password if prompted.
Step 2
configureterminal
Example:
Device# configure terminal
Enters the global
configuration mode.
Step 3
interfaceinterface-id
Example:
Device(config)# interface
gigabitethernet 1/0/1
Selects an
interface on which to statically forward traffic for a multicast group using
SSM mapping, and enters interface configuration mode.
The specified interface must be one of the following:
A routed port—A physical port
that has been configured as a Layer 3 port by entering the
no switchport
interface configuration command. You will also need to enable IP PIM
sparse-dense-mode on the interface, and join the interface as a statically
connected member to an IGMP static group. For a configuration example, see
Example: Interface Configuration as a Routed Port
An SVI—A VLAN interface
created by using the
interface vlanvlan-id global
configuration command. You will also need to enable IP PIM sparse-dense-mode on
the VLAN, join the VLAN as a statically connected member to an IGMP static
group, and then enable IGMP snooping on the VLAN, the IGMP static group, and
physical interface. For a configuration example, see
Example: Interface Configuration as an SVI
These interfaces must have IP
addresses assigned to them.
Note
Static forwarding
of traffic with SSM mapping works with either DNS-based SSM mapping or
statically configured SSM mapping.
Step 4
ip igmp
static-groupgroup-addresssource ssm-map
Example:
Device(config-if)# ip igmp
static-group 239.1.2.1 source
ssm-map
Configures SSM
mapping to statically forward a (S, G) channel from the interface.
Use this command
if you want to statically forward SSM traffic for certain groups. Use DNS-based
SSM mapping to determine the source addresses of the channels.
Step 5
end
Example:
Device(config)# end
Returns to
privileged EXEC mode.
Step 6
show running-config
Example:
Device# show running-config
Verifies your entries.
Step 7
copy running-config
startup-config
Example:
Device# copy running-config startup-config
(Optional) Saves your entries
in the configuration file.
Verifying SSM Mapping
Configuration and Operation
Perform this
optional task to verify SSM mapping configuration and operation.
Enables
privileged EXEC mode. Enter your password if prompted.
Example:
Device> enable
Step 2
showipigmpssm-mapping
(Optional)
Displays information about SSM mapping.
The following
example shows how to display information about SSM mapping configuration. In
this example, SSM static mapping and DNS-based SSM mapping are enabled.
Example:
Device# show ip igmp ssm-mapping
SSM Mapping : Enabled
DNS Lookup : Enabled
Mcast domain : ssm-map.cisco.com
Name servers : 10.0.0.3
10.0.0.4
Step 3
showipigmpssm-mappinggroup-address
(Optional)
Displays the sources that SSM mapping uses for a particular group.
The following
example shows how to display information about the configured DNS-based SSM
mapping. In this example, the router has used DNS-based mapping to map group
232.1.1.4 to sources 172.16.8.5 and 172.16.8.6. The timeout for this entry is
860000 milliseconds (860 seconds).
Example:
Device# show ip igmp ssm-mapping 232.1.1.4
Group address: 232.1.1.4
Database : DNS
DNS name : 4.1.1.232.ssm-map.cisco.com
Expire time : 860000
Source list : 172.16.8.5
: 172.16.8.6
(Optional)
Displays the multicast groups with receivers that are directly connected to the
router and that were learned through IGMP.
The following
is sample output from the
showipigmpgroups command with the
group-address
argument and
detail keyword.
In this example the “M” flag indicates that SSM mapping is configured.
Example:
Device# show ip igmp group 232.1.1.4 detail
Interface: GigabitEthernet2/0/0
Group: 232.1.1.4 SSM
Uptime: 00:03:20
Group mode: INCLUDE
Last reporter: 0.0.0.0
CSR Grp Exp: 00:02:59
Group source list: (C - Cisco Src Report, U - URD, R - Remote,
S - Static, M - SSM Mapping)
Source Address Uptime v3 Exp CSR Exp Fwd Flags
172.16.8.3 00:03:20 stopped 00:02:59 Yes CM
172.16.8.4 00:03:20 stopped 00:02:59 Yes CM
172.16.8.5 00:03:20 stopped 00:02:59 Yes CM
172.16.8.6 00:03:20 stopped 00:02:59 Yes CM
Step 5
showhost
(Optional)
Displays the default domain name, the style of name lookup service, a list of
name server hosts, and the cached list of hostnames and addresses.
The following
is sample output from the
showhostcommand. Use this command to display DNS
entries as they are learned by the router.
Example:
Device# show host
Default domain is cisco.com
Name/address lookup uses domain service
Name servers are 10.48.81.21
Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
temp - temporary, perm - permanent
NA - Not Applicable None - Not defined
Host Port Flags Age Type Address(es)
10.0.0.0.ssm-map.cisco.c None (temp, OK) 0 IP 172.16.8.5
172.16.8.6
172.16.8.3
172.16.8.4
Step 6
debugipigmpgroup-address
(Optional)
Displays the IGMP packets received and sent and IGMP host-related events.
The following
is sample output from the
debugipigmpcommand when SSM static mapping is enabled.
The following output indicates that the router is converting an IGMPv2 join for
group G into an IGMPv3 join:
Example:
IGMP(0): Convert IGMPv2 report (*,232.1.2.3) to IGMPv3 with 2 source(s) using STATIC.
The following
is sample output from the
debugipigmp command when DNS-based SSM mapping is
enabled. The following output indicates that a DNS lookup has succeeded:
Example:
IGMP(0): Convert IGMPv2 report (*,232.1.2.3) to IGMPv3 with 2 source(s) using DNS.
The following
is sample output from the
debugipigmp command when DNS-based SSM mapping is enabled
and a DNS lookup has failed:
IGMP(0): DNS
source lookup failed for (*, 232.1.2.3), IGMPv2 report failed
Monitoring SSM and SSM Mapping
Monitoring SSM
To monitor SSM, use
the following commands in privileged EXEC mode, as needed:
Command
Purpose
Device# showipigmpgroupsdetail
Displays
the (S, G) channel subscription through IGMPv3.
Device# showipmroute
Displays
whether a multicast group supports SSM service or whether a source-specific
host report was received.
Monitoring SSM Mapping
Use the
privileged EXEC commands in the following table to monitor SSM mapping.
Table 1. SSM Mapping Monitoring
Commands
Command
Purpose
Device#
show ip igmp ssm-mapping
Displays information about
SSM mapping.
Device#show ip igmp
ssm-mappinggroup-address
Displays the sources that SSM
mapping uses for a particular group.
Device#show ip igmp groups [group-name
|
group-address |
interface-type
interface-number] [detail]
Displays the multicast groups
with receivers that are directly connected to the router and that were learned
through IGMP.
Device#show
host
Displays the default domain
name, the style of name lookup service, a list of name server hosts, and the
cached list of hostnames and addresses.
Device#debug ip
igmpgroup-address
Displays the IGMP packets
received and sent and IGMP host-related events.
Configuration Examples for SSM and SSM Mapping
SSM with IGMPv3 Example
The following example shows how to configure a device (running IGMPv3) for SSM:
ip multicast-routing
!
interface GigabitEthernet3/1/0
ip address 172.21.200.203 255.255.255.0
description backbone interface
ip pim sparse-mode
!
interface GigabitEthernet3/2/0
ip address 131.108.1.2 255.255.255.0
ip pim sparse-mode
description ethernet connected to hosts
ip igmp version 3
!
ip pim ssm default
SSM Filtering Example
The following example shows how to configure filtering on legacy RP routers running software releases that do not support
SSM routing. This filtering will suppress all unwanted PIM-SM and MSDP traffic in the SSM range. Without this filtering, SSM
will still operate, but there may be additional RPT traffic if legacy first hop and last hop routers exist in the network.
ip access-list extended no-ssm-range
deny ip any 232.0.0.0 0.255.255.255 ! SSM range
permit ip any any
! Deny registering in SSM range
ip pim accept-register list no-ssm-range
ip access-list extended msdp-nono-list
deny ip any 232.0.0.0 0.255.255.255 ! SSM Range
! .
! .
! .
! See ftp://ftpeng.cisco.com/ipmulticast/config-notes/msdp-sa-filter.txt for other SA
! messages that typically need to be filtered.
permit ip any any
! Filter generated SA messages in SSM range. This configuration is only needed if there
! are directly connected sources to this router. The “ip pim accept-register” command
! filters remote sources.
ip msdp redistribute list msdp-nono-list
! Filter received SA messages in SSM range. “Filtered on receipt” means messages are
! neither processed or forwarded. Needs to be configured for each MSDP peer.
ip msdp sa-filter in msdp-peer1 list msdp-nono-list
! .
! .
! .
ip msdp sa-filter in msdp-peerN list msdp-nono-list
SSM Mapping Example
The following configuration example shows a router configuration for SSM mapping. This example also displays a range of other
IGMP and SSM configuration options to show compatibility between features. Do not use this configuration example as a model
unless you understand all of the features used in the example.
Note
Address assignment in the global SSM range 232.0.0.0/8 should be random. If you copy parts or all of this sample configuration,
make sure to select a random address range but not 232.1.1.x as shown in this example. Using a random address range minimizes
the possibility of address collision and may prevent conflicts when other SSM content is imported while SSM mapping is used.
!
no ip domain lookup
ip domain multicast ssm.map.cisco.com
ip name-server 10.48.81.21
!
!
ip multicast-routing distributed
ip igmp ssm-map enable
ip igmp ssm-map static 10 172.16.8.10
ip igmp ssm-map static 11 172.16.8.11
!
!
.
.
.
!
interface GigabitEthernet0/0/0
description Sample IGMP Interface Configuration for SSM-Mapping Example
ip address 10.20.1.2 255.0.0.0
ip pim sparse-mode
ip igmp last-member-query-interval 100
ip igmp static-group 232.1.2.1 source ssm-map
ip igmp version 3
ip igmp explicit-tracking
ip igmp limit 2
ip igmp v3lite
ip urd
!
.
.
.
!
ip pim ssm default
!
access-list 10 permit 232.1.2.10
access-list 11 permit 232.1.2.0 0.0.0.255
!
This table describes the significant commands shown in the SSM mapping configuration example.
Table 2. SSM Mapping Configuration Example Command Descriptions
Command
Description
noipdomainlookup
Disables IP DNS-based hostname-to-address translation.
Note
The
noipdomain-list command is shown in the configuration only to demonstrate that disabling IP DNS-based hostname-to-address translation does
not conflict with configuring SSM mapping. If this command is enabled, the Cisco IOS XE software will try to resolve unknown
strings as hostnames.
ipdomainmulticastssm-map.cisco.com
Specifies ssm-map.cisco.com as the domain prefix for SSM mapping.
ipname-server10.48.81.21
Specifies 10.48.81.21 as the IP address of the DNS server to be used by SSM mapping and any other service in the software
that utilizes DNS.
ipmulticast-routing
Enables IP multicast routing.
ipigmpssm-mapenable
Enables SSM mapping.
ipigmpssm-mapstatic10172.16.8.10
Configures the groups permitted by ACL 10 to use source address 172.16.8.10.
In this example, ACL 10 permits all groups in the 232.1.2.0/25 range except 232.1.2.10.
ipigmpssm-mapstatic11172.16.8.11
Configures the groups permitted by ACL 11 to use source address 172.16.8.11.
In this example, ACL 11 permits group 232.1.2.10.
ippimsparse-mode
Enables PIM sparse mode.
ipigmplast-member-query-interval100
Reduces the leave latency for IGMPv2 hosts.
Note
This command is not required for configuring SSM mapping; however, configuring this command can be beneficial for IGMPv2
hosts relying on SSM mapping.
ipigmpstatic-group232.1.2.1sourcessm-map
Configures SSM mapping to be used to determine the sources associated with group 232.1.2.1. The resulting (S, G) channels
are statically forwarded.
ipigmpversion3
Enables IGMPv3 on this interface.
Note
This command is shown in the configuration only to demonstrate that IGMPv3 can be configured simultaneously with SSM mapping;
however, it is not required.
ipigmpexplicit-tracking
Minimizes the leave latency for IGMPv3 host leaving a multicast channel.
Note
This command is not required for configuring SSM mapping.
ipigmplimit2
Limits the number of IGMP states resulting from IGMP membership states on a per-interface basis.
Note
This command is not required for configuring SSM mapping.
ipigmpv3lite
Enables the acceptance and processing of IGMP v3lite membership reports on this interface.
Note
This command is shown in the configuration only to demonstrate that IGMP v3lite can be configured simultaneously with SSM
mapping; however, it is not required.
ipurd
Enables interception of TCP packets sent to the reserved URD port 465 on an interface and processing of URD channel subscription
reports.
Note
This command is shown in the configuration only to demonstrate that URD can be configured simultaneously with SSM mapping;
however, it is not required.
ippimssmdefault
Configures SSM service.
The
default keyword defines the SSM range access list as 232/8.
Configures the ACLs to be used for static SSM mapping.
Note
These are the ACLs that are referenced by the
ipigmpssm-mapstatic commands in this configuration example.
DNS Server Configuration Example
To configure DNS-based SSM mapping, you need to create a DNS server zone or add records to an existing zone. If the routers
that are using DNS-based SSM mapping are also using DNS for other purposes besides SSM mapping, you should use a normally-configured
DNS server. If DNS-based SSM mapping is the only DNS implementation being used on the router, you can configure a fake DNS
setup with an empty root zone, or a root zone that points back to itself.
The following example shows how to create a zone and import the zone data using Network Registrar:
Router> zone 1.1.232.ssm-map.cisco.com. create primary file=named.ssm-map
100 Ok
Router> dns reload
100 Ok
The following example shows how to import the zone files from a named.conf file for BIND 8:
Router> ::import named.conf /etc/named.conf
Router> dns reload
100 Ok:
Note
Network Registrar version 8.0 and later support import BIND 8 format definitions.
Additional
References
Related
Documents
Related
Topic
Document
Title
For
complete syntax and usage information for the commands used in this chapter.
IP Multicast Routing Command
Reference (Catalyst 3650 Switches)
The Cisco
Support website provides extensive online resources, including documentation
and tools for troubleshooting and resolving technical issues with Cisco
products and technologies.
To receive
security and technical information about your products, you can subscribe to
various services, such as the Product Alert Tool (accessed from Field Notices),
the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS)
Feeds.
Access to
most tools on the Cisco Support website requires a Cisco.com user ID and
password.