|
Table Of Contents
Source Specific Multicast (SSM) Mapping
Configuring Static SSM Mapping
Configuring DNS-Based SSM Mapping
Configuring Static Traffic Forwarding with SSM Mapping
Verifying SSM Mapping Configuration and Operation
Configuration Examples for SSM Mapping
Example: DNS Server Configuration
Feature Information for Source Specific Multicast (SSM) Mapping
Source Specific Multicast (SSM) Mapping
First Published: May 2, 2005Last Updated: September 10, 2010
The Source Specific Multicast (SSM) Mapping feature extends the Cisco IOS suite of SSM transition tools, which also includes URL Rendezvous Directory (URD) and Internet Group Management Protocol Version 3 Lite (IGMP v3lite). SSM mapping supports SSM transition in cases where neither URD nor IGMP v3lite is available, or when supporting SSM on the end system is impossible or unwanted due to administrative or technical reasons. SSM mapping enables you to leverage SSM for video delivery to legacy set-top boxes (STBs) that do not support IGMPv3 or for applications that do not take advantage of the IGMPv3 host stack.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see 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 for Source Specific Multicast (SSM) Mapping" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•Prerequisites for SSM Mapping
•Information About SSM Mapping
•Configuration Examples for SSM Mapping
•Feature Information for Source Specific Multicast (SSM) Mapping
Prerequisites for SSM Mapping
•One option available for using SSM mapping is to install it together with a Domain Name System (DNS) server to simplify administration of the SSM Mapping feature in larger deployments.
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. The Cisco IOS software does not provide for DNS server functionality. You may want to use a product such as Cisco Network Registrar (CNR).
Restrictions for SSM Mapping
•The SSM Mapping feature does not share the benefit of full SSM (unlike URD or IGMP v3lite). Because SSM mapping takes a group G join from a host and identifies this group with an application associated with one or more sources, 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. That is, SSM mapping is compatible with simultaneous URD, IGMP v3lite or IGMPv3 membership reports.
•Enable IGMPv3 with care on the last hop router when you rely solely on SSM mapping as a transition solution for full SSM.
When both SSM mapping and IGMPv3 are enabled, the router will send out IGMPv3 membership query messages instead of IGMPv3 membership messages. If the receiver hosts that are to be supported with SSM mapping can only support IGMPv1 or IGMPv2, then enabling SSM mapping on an interface with IGMPv3 is fine. IGMPv3 membership query messages will be interpreted as IGMPv1 or IGMPv2 queries and the host will continue to report with IGMPv1 or IGMPv2 reports.
However, when both SSM mapping and IGMPv3 are enabled and the hosts already support IGMPv3 (but not SSM), then they will start to send IGMPv3 group reports. These IGMPv3 group reports are not supported with SSM mapping and the router will not correctly associate sources with these reports.
Information About SSM Mapping
SSM Components
SSM is a datagram delivery model that best supports one-to-many applications, also known as broadcast applications. SSM is a core networking technology for the Cisco implementation of IP multicast solutions targeted for audio and video broadcast application environments and is described in RFC 3569. The following two Cisco IOS components together support the implementation of SSM:
•Protocol Independent Multicast source-specific mode (PIM-SSM)
•Internet Group Management Protocol Version 3 (IGMPv3)
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. IGMPv3 supports source filtering, which is required for SSM. For SSM to run with IGMPv3, SSM must be supported in the Cisco IOS router, the host where the application is running, and the application itself.
SSM Benefits
IP Multicast Address Management
In the Internet Standard Multicast (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, 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 problematic. 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 among routers in the network independently of traffic from other sources. Thus different sources can reuse multicast group addresses in the SSM range.
Inhibition of Denial of Service Attacks
In SSM, multicast traffic from each individual source will be transported across the network only if it was requested (through IGMPv3 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 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.
Installation and Management
SSM is easy to install and provision in a network because it does not require the network to maintain information about 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 Multicast Source Discovery Protocol (MSDP). Rendezvous point (RP) management in PIM-SM (including the necessity for Auto-RP or bootstrap router [BSR]) and MSDP is required only for the network to learn about active sources. This management is not necessary in SSM. SSM is therefore easier than ISM to install and manage and easier 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.
Internet Broadcast Applications
The three benefits listed above 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 of 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 Transition Solutions
The Cisco IOS suite of SSM transition solutions consists of the following transition solutions that enable the immediate development and deployment of SSM services, without the need to wait for the availability of full IGMPv3 support in host operating systems and SSM receiver applications:
•Internet Group Management Protocol Version 3 lite (IGMP v3lite)
•URL Rendezvous Directory (URD)
•SSM mapping
IGMP v3lite is a solution for application developers that allows immediate development of SSM receiver applications switching to IGMPv3 as soon as it becomes available.
For more information about IGMP v3lite, see the "Configuring Source Specific Multicast" module.
URD is an SSM transition solution for content providers and content aggregators that allows them to deploy receiver applications that are not yet SSM enabled (through support for IGMPv3) by enabling the receiving applications to be started and controlled through a web browser.
For more information about URD, see the see the "Configuring Source Specific Multicast" module.
SSM mapping supports SSM transition in cases where neither URD nor IGMP v3lite are available, or when supporting SSM on the end system is impossible or unwanted due to administrative or technical reasons.
SSM Mapping Overview
SSM mapping supports SSM transition in cases where neither URD nor IGMP v3lite is available, or 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 is a typical application of SSM mapping.
Prior to the introduction of SSM mapping, the following conditions would have prevented SSM transition in the case of legacy STB deployments with STB receivers that only support IGMPv1 or IGMPv2:
•The operating system on the receivers do not support IGMPv3; thus, IGMPv3 cannot be used to support SSM.
•Moreover, the application running on the receivers cannot be upgraded to support SSM; thus, IGMPv3 lite cannot be used to support SSM transition.
•To further exacerbate the issue, the application itself cannot be started through a web browser; thus, URD cannot be used to support SSM transition.
SSM mapping provides an SSM transition solution for hosts and applications that meet those conditions.
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.
Note As is the case for the other SSM transition solutions (URD and IGMP v3lite), SSM mapping only needs to be configured on the last hop router connected to receivers. No support is needed on any other routers in the network. SSM mapping, in addition, is fully compatible with IGMPv3, IGMP v3lite, and URD.
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 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 ip igmp static ssm-map 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 Figure 1). 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.
Figure 1 DNS-Based SSM-Mapping
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 swichover 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 A source-address-2
IN A source-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 Cisco IOS software, you must configure a few global commands but no per-channel specific configuration is needed. There is no change to the Cisco IOS 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 connectioned 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 Mapping
This section contains the following tasks:
•Configuring Static SSM Mapping (required)
•Configuring DNS-Based SSM Mapping (required)
•Configuring Static Traffic Forwarding with SSM Mapping (optional)
•Verifying SSM Mapping Configuration and Operation (optional)
Configuring Static SSM Mapping
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.
Prerequisites
•Enable IP multicast routing, enable PIM sparse mode, and configure SSM before performing this task. For more information, see the "Configuring Basic Multicast" module.
•Before you configure static SSM mapping, you must configure ACLs that define the group ranges to be mapped to source addresses.
For information about how to configure an ACL, see the "Creating an IP Access List and Applying It to an Interface" module.
Restrictions
•Enable IGMPv3 with care on the last hop router when you rely solely on SSM mapping as a transition solution for full SSM.
When both SSM mapping and IGMPv3 are enabled, the router will send out IGMPv3 membership query messages instead of IGMPv3 membership messages. If the receiver hosts that are to be supported with SSM mapping can only support IGMPv1 or IGMPv2, then enabling SSM mapping on an interface with IGMPv3 is fine. IGMPv3 reports will be interpreted as IGMPv1 or IGMPv2 queries and the host will continue to report with IGMPv1 or IGMPv2 reports.
However, when both SSM mapping and IGMPv3 are enabled, if the hosts already support IGMPv3 (but not SSM), then they will start to send IGMPv3 group reports. These IGMPv3 group reports are not supported with SSM mapping and the router will not correctly associate sources with these reports.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip igmp ssm-map enable
4. no ip igmp ssm-map query dns
5. ip igmp ssm-map static access-list source-address
6. Repeat Step 5 to configure additional static SSM mappings, if required.
7. end
DETAILED STEPS
What to Do Next
Proceed to the "Configuring DNS-Based SSM Mapping" section or to the "Verifying SSM Mapping Configuration and Operation" section.
Configuring DNS-Based SSM Mapping
Perform this task to configure the last hop router to perform DNS lookups to learn the IP addresses of sources sending to a group.
Prerequisites
•Enable IP multicast routing, enable PIM sparse mode, and configure SSM before performing this task. For more information, see the "Configuring Basic Multicast" module.
•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. The Cisco IOS software does not provide for DNS server functionality. You may want to use a product such as Cisco Network Registrar (CNR).
Restrictions
•Enable IGMPv3 with care on the last hop router when you rely solely on SSM mapping as a transition solution for full SSM.
When both SSM mapping and IGMPv3 are enabled, the router will send out IGMPv3 membership query messages instead of IGMPv3 membership messages. If the receiver hosts that are to be supported with SSM mapping can only support IGMPv1 or IGMPv2, then enabling SSM mapping on an interface with IGMPv3 is fine. IGMPv3 reports will be interpreted as IGMP version 1 or IGMP version 2 queries and the host will continue to report with IGMPv1 or IGMPv2 reports.
However, when both SSM mapping and IGMPv3 are enabled, if the hosts already support IGMPv3 (but not SSM), then they will start to send IGMPv3 group reports. These IGMPv3 group reports are not supported with SSM mapping and the router will not correctly associate sources with these reports.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip igmp ssm-map enable
4. ip igmp ssm-map query dns
5. ip domain multicast domain-prefix
6. ip name-server server-address1 [server-address2...server-address6]
7. Repeat Step 6 to configure additional DNS servers for redundancy, if required.
DETAILED STEPS
What to Do Next
Proceed to the "Configuring Static Traffic Forwarding with SSM Mapping" section or to the "Verifying SSM Mapping Configuration and Operation" section.
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.
Prerequisites
This task does not include the steps for configuring DNS-based SSM mapping. See the "Configuring DNS-Based SSM Mapping" task for more information about configuring DNS-based SSM mapping.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip igmp static-group group-address source ssm-map
DETAILED STEPS
What to Do Next
Proceed to the "Verifying SSM Mapping Configuration and Operation" section.
Verifying SSM Mapping Configuration and Operation
Perform this optional task to verify SSM mapping configuration and operation.
SUMMARY STEPS
1. enable
2. show ip igmp ssm-mapping
3. show ip igmp ssm-mapping group-address
4. show ip igmp groups [group-name | group-address | interface-type interface-number] [detail]
5. show host
6. debug ip igmp group-address
DETAILED STEPS
Step 1 enable
Enables privileged EXEC mode. Enter your password if prompted.
Router> enableStep 2 show ip igmp ssm-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.
Router# show ip igmp ssm-mappingSSM Mapping : EnabledDNS Lookup : EnabledMcast domain : ssm-map.cisco.comName servers : 10.0.0.310.0.0.4Step 3 show ip igmp ssm-mapping group-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).
Router# show ip igmp ssm-mapping 232.1.1.4Group address: 232.1.1.4Database : DNSDNS name : 4.1.1.232.ssm-map.cisco.comExpire time : 860000Source list : 172.16.8.5: 172.16.8.6Step 4 show ip igmp groups [group-name | group-address | interface-type interface-number] [detail]
(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 show ip igmp groups command with the group-address argument and detail keyword. In this example the "M" flag indicates that SSM mapping is configured.
Router# show ip igmp group 232.1.1.4 detail
Interface: Ethernet2Group: 232.1.1.4 SSMUptime: 00:03:20Group mode: INCLUDELast reporter: 0.0.0.0CSR Grp Exp: 00:02:59Group source list: (C - Cisco Src Report, U - URD, R - Remote,S - Static, M - SSM Mapping)Source Address Uptime v3 Exp CSR Exp Fwd Flags172.16.8.3 00:03:20 stopped 00:02:59 Yes CM172.16.8.4 00:03:20 stopped 00:02:59 Yes CM172.16.8.5 00:03:20 stopped 00:02:59 Yes CM172.16.8.6 00:03:20 stopped 00:02:59 Yes CMStep 5 show host
(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 show host command. Use this command to display DNS entries as they are learned by the router.
Router# show hostDefault domain is cisco.comName/address lookup uses domain serviceName servers are 10.48.81.21Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidatetemp - temporary, perm - permanentNA - Not Applicable None - Not definedHost Port Flags Age Type Address(es)10.0.0.0.ssm-map.cisco.c None (temp, OK) 0 IP 172.16.8.5172.16.8.6172.16.8.3172.16.8.4Step 6 debug ip igmp group-address
(Optional) Displays the IGMP packets received and sent and IGMP host-related events.
The following is sample output from the debug ip igmp command 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:
IGMP(0): Convert IGMPv2 report (*,232.1.2.3) to IGMPv3 with 2 source(s) using STATIC.The following is sample output from the debug ip igmp command when DNS-based SSM mapping is enabled. The following output indicates that a DNS lookup has succeeded:
IGMP(0): Convert IGMPv2 report (*,232.1.2.3) to IGMPv3 with 2 source(s) using DNS.The following is sample output from the debug ip igmp 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 failedConfiguration Examples for SSM Mapping
This section provides the following configuration examples:
•Example: DNS Server Configuration
Example: SSM Mapping
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 lookupip domain multicast ssm.map.cisco.comip name-server 10.48.81.21!!ip multicast-routingip igmp ssm-map enableip igmp ssm-map static 10 172.16.8.10ip igmp ssm-map static 11 172.16.8.11!!...!interface Ethernet0/0description Sample IGMP Interface Configuration for SSM-Mapping Exampleip address 10.20.1.2 255.0.0.0ip pim sparse-modeip igmp last-member-query-interval 100ip igmp static-group 232.1.2.1 source ssm-mapip igmp version 3ip igmp explicit-trackingip igmp limit 2ip igmp v3liteip urd!...!ip pim ssm default!access-list 10 permit 232.1.2.10access-list 11 permit 232.1.2.0 0.0.0.255!Table 1 describes the significant commands shown in the SSM mapping configuration example.
Example: DNS Server Configuration
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:
nrcmd> zone 1.1.232.ssm-map.cisco.com. create primary file=named.ssm-map100 Oknrcmd> dns reload100 OkThe following example shows how to import the zone files from a named.conf file for BIND 8:
nrcmd> ::import named.conf /etc/named.confnrcmd> dns reload100 Ok:
Note Network Registrar version 8.0 and later support import BIND 8 format definitions.
Additional References
Related Documents
Related Topic Document TitleSSM concepts and configuration
"Configuring Basic IP Multicast" module
Cisco IOS IP multicast commands: complete command syntax, command mode, defaults, command history, usage guidelines, and examples
IGMP v3lite and URD concepts and configuration
"Configuring Source Specific Multicast" chapter in the "IP Multicast" part of the Cisco IOS IP Configuration Guide, Release 12.2
Standards
Standards TitleNo new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
RFCs TitleRFC 2365
Administratively Scoped IP Multicast
RFC 2770
GLOP Addressing in 233/8
RFC 3569
An Overview of Source-Specific Multicast
Technical Assistance
Feature Information for Source Specific Multicast (SSM) Mapping
Table 2 lists the features in this module and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note Table 2 lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Glossary
DNS—Domain Name System. System used on the Internet for translating names of network nodes into addresses.
IGMP—Internet Group Management Protocol. Protocol used by IP hosts to report their multicast group memberships to an adjacent multicast router.
IGMPv3—IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address.
PIM—Protocol Independent Multicast. Multicast routing architecture that allows the addition of IP multicast routing on existing IP networks. PIM is unicast routing protocol independent and can be operated in two modes: dense and sparse.
SSM—Source Specific Multicast. A datagram delivery model that best supports one-to-many applications, also known as broadcast applications. SSM is the core networking technology for the Cisco implementation of the IP Multicast Lite suite of solutions targeted for audio and video broadcast application environments
URD—URL Rendezvous Directory. Multicast solution that directly provides the network with information about the specific source of a content stream. It enables the network to quickly establish the most direct distribution path from the source to the receiver, thus substantially reducing the time and effort required in receiving the streaming media. URD allows an application to identify the source of the content stream through a web page link or web directly. When that information is sent back to the application it is then conveyed back to the network using URD.
VRF—A VPN routing and forwarding instance. A VRF consists of an IP routing table, a derived forwarding table, a set of interfaces that use the forwarding table, and a set of rules and routing protocols that determine what goes into the forwarding table. In general, a VRF includes the routing information that defines a customer VPN site that is attached to a PE router.
Note Refer to the Internetworking Terms and Acronyms for terms not included in this glossary.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2005-2010 Cisco Systems, Inc. All rights reserved.