Initial Interdomain Network Topology

Take a look at a detailed example of an ISP customer within an interdomain multicast network implemented SSM in its network using URD, and learn the three ways to implement SSM in an interdomain environment.

The current IP multicast infrastructure in the Internet and many enterprise intranets is based on the Protocol Independent Multicast sparse mode (PIM-SM) protocol and Multicast Source Discovery Protocol (MSDP). These protocols are 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 Source Specific Multicast (SSM), receivers provide this information through the source addresses relayed to the last hop routers by Internet Group Management Protocol Version 3 (IGMPv3), IGMP Version 3 lite (IGMP v3lite), or URL Rendezvous Directory (URD).

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 a more advantageous IP multicast service.

This chapter describes how an Internet service provider (ISP) customer within an interdomain multicast network implements SSM in its network using URD. This chapter begins by introducing the initial interdomain ISP topology and describing basic SSM operations (including SSM IP address range). There are three ways to implement SSM in an interdomain environment: using IGMPv3 host signaling, using IGMP v3lite host signaling, and using URD host signaling. Each of these possibilities is briefly described. This chapter then presents and discusses the recommended implementation solution: SSM using URD host signaling. This discussion includes benefits and ramifications of implementing SSM using URD host signaling, necessary prerequisites, and implementation process steps. This chapter concludes with a list of recommended and related documents.

The SSM solution presented in this chapter is based on an actual customer situation. This solution was tested and verified in a lab environment and has been deployed in the field. Alternative ways to implement SSM, such as with IGMPv3 and IGMP v3lite host signaling, are discussed but were not implemented in our lab environment.

The scope of this chapter is to describe basic design and deployment of SSM using URD. It does not discuss in detail the general operation of the protocols associated with developing interdomain multicast networks such as PIM-SM. For more information about PIM-SM, refer to Chapter 1, "IP Multicast Technology Overview."

Initial Interdomain Network Topology

The SSM network scenario used in this chapter is based on the hypothetical interdomain ISP network scenario described in Chapter 2, "Implementing Interdomain Multicast Using MSDP." Figure 6-1 shows the logical connections of the initial interdomain multicast network topology. Each ISP in Figure 6-1 has established Border Gateway Protocol (BGP) peering and its own autonomous system (AS). The design of each ISP multicast network topology depends on the individual requirements of the ISP.

Figure 6-1 Logical Connections of the Initial Interdomain Multicast Network Topology

Understanding SSM

SSM is a datagram delivery model that best supports one-to-many applications, also known as Internet broadcast applications. SSM is a core networking technology for the Cisco implementation of IP multicast solutions targeted for applications such as audio and video broadcasting.

To run SSM with IGMPv3, SSM must be supported in the Cisco IOS router, in the host where the application is running, and in the application itself. IGMP v3lite and URD, two Cisco-developed transition solutions, 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. IGMPv3, IGMP v3lite, and URD interoperate with each other so that both IGMP v3lite and URD can easily be used as transitional solutions toward full IGMPv3 support in hosts.

This section covers the following topics:

• Differences Between SSM and ISM
• SSM IP Address Range
• SSM Operations

Differences between SSM and ISM

The Internet Standard Multicast (ISM) service is described in RFC 1112, "Host Extensions for IP Multicasting." This service consists of the delivery of IP datagrams from any source to a group of receivers called the multicast host group. 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 receive this traffic when they become 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 receive this traffic when they become members of the (S, G) channel rather than the host group. No signaling is required to become a source in either SSM or ISM. However, in SSM, receivers must subscribe or unsubscribe to (S, G) channels to receive or stop receiving traffic from specific sources. In other words, in SSM, receivers can receive traffic only from (S, G) channels to which they are subscribed. 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 uses IGMP INCLUDE mode membership reports, which are supported only in IGMPv3.

SSM IP Address Range

SSM can coexist with 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 232.0.0.0 through 232.255.255.255 for SSM applications and protocols. Cisco IOS 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, existing IP multicast receiver applications will not receive any traffic when they try to use addresses in the SSM range unless the application is modified to use explicit (S, G) channel subscription or is SSM-enabled through URD.

SSM Operations

An established network in which IP multicast service is based on PIM-SM can support SSM services. You can also deploy SSM alone in a network without the full range of protocols that are required for interdomain PIM-SM (for example, MSDP, Auto-RP, or bootstrap router [BSR]) if only SSM service is needed. However, multiprotocol BGP might be required (and Cisco recommends its use) to maintain IP multicast connectivity if multiple autonomous systems are deployed in a network.

If SSM is deployed in a network already configured for PIM-SM (Cisco IOS Software Release 12.0 or later is recommended), only the last hop routers must be upgraded to a Cisco IOS Software Release 12.1(5)T or later that supports SSM. Routers that are not directly connected to receivers can run Cisco IOS Software Release 12.0 or later releases. In general, non-last hop routers must run only PIM-SM in the SSM range and might need additional access control configuration to suppress MSDP signalling, registering, or PIM-SM shared tree operations from occurring within the SSM range.

In Cisco IOS Software Release 12.1(3)T and later releases, you enable the SSM operation mode by configuring the SSM range through the ip pim ssm 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, IGMP v3lite, or URD. Each of these methods must be configured on a per-interface basis. IGMP v3lite and URD (S, G) channel subscriptions are ignored for groups outside the SSM range.

• PIM operations within the SSM range of addresses change to PIM source-specific mode (PIM-SSM). PIM-SSM, the routing protocol that supports the implementation of SSM, is derived from PIM-SM. In PIM-SSM mode, only PIM (S, G) join and prune messages are generated by the router, and no (S, G) rendezvous point tree (RPT) or (*, G) RPT messages are generated. Incoming messages related to 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 the router is a last hop router. Routers that are not last hop routers can run PIM-SM for SSM groups (for example, if they do not yet support SSM).

• No MSDP Source-Active (SA) messages within the SSM range will be accepted, generated, or forwarded.

Possible Solutions for Implementing SSM

The following sections discuss three possible solutions for implementing SSM with Cisco IOS software:

• Solution 1: IGMPv3 Host Signaling

• Solution 2: IGMP v3lite Host Signaling

• Solution 3: URD Host Signaling

Solution 1: IGMPv3 Host Signaling

IGMPv3 is the third version of the Internet Engineering Task Force (IETF) standards track protocol used by hosts to signal membership to last hop routers of multicast groups. IGMPv3 introduces the ability for hosts to signal group membership with filtering capabilities with respect to sources, which is required for SSM. A host can either signal that it wants to receive traffic from all sources sending to a group except for some specific sources (called EXCLUDE mode), or that it wants to receive traffic only from some specific sources sending to the group (called INCLUDE mode).

IGMPv3 can operate with both ISM and SSM. In ISM, the last hop router accepts both EXCLUDE and INCLUDE mode reports. In SSM, the last hop router accepts only INCLUDE mode reports, but ignores EXCLUDE mode reports. For more information on IGMPv3, refer to the Cisco IOS Software Release 12.1(5)T IGMP Version 3 feature module.

Solution 2: IGMP v3lite Host Signaling

IGMP v3lite is a Cisco-developed transitional solution that enables you to write and run SSM applications on hosts that do not yet support IGMPv3 in their operating system kernel. IGMP v3lite allows immediate development of SSM receiver applications and switches to IGMPv3 as soon as it becomes available.

You must compile applications with the Host Side IGMP Library (HSIL) for IGMP v3lite. This software provides a subset of the IGMPv3 applications programming interface (API) that is required to write SSM-aware applications. HSIL was developed for Cisco by Talarian and is available on the following web site:

www.talarianmulticast.com/cgi-bin/igmpdownld

One part of the HSIL is a client library linked to the SSM application. It provides the SSM subset of the IGMPv3 API to the SSM application. If possible, the library checks whether the operating system kernel supports IGMPv3. If it does, the API calls are passed through to the kernel. If the kernel does not support IGMPv3, the library uses the IGMP v3lite mechanism.

When using the IGMP v3lite mechanism, the library tells the operating system kernel to join to the whole multicast group. Joining to the whole group is the only method for the application to receive traffic for that multicast group (if the operating system kernel supports only IGMPv1 or IGMPv2). In addition, the library signals the (S, G) channel subscriptions to an IGMP v3lite server process, which is also part of the HSIL. A server process is needed because multiple SSM applications might be on the same host. This server process sends IGMP v3lite-specific (S, G) channel subscriptions to the last hop Cisco IOS router, which must be enabled for IGMP v3lite. The Cisco IOS router sees both the IGMPv1 or IGMPv2 group membership reports from the operating system kernel and the (S, G) channel subscription from the HSIL server process. If the router sees both of these messages, it will interpret them as an SSM (S, G) channel subscription and join to the channel through PIM-SSM.

Solution 3: URD Host Signaling

URD is a Cisco-developed transitional solution that enables the deployment of SSM with existing IP multicast receiver applications that do not support IGMPv3. The software on the end-user systems running the application do not need to be updated. URD is a content provider solution in which receiver applications can be started or controlled through a web browser.

The next section explains URD Host Signaling in more detail.

Proposed Solution: URD Host Signaling

The company in this proposed solution implemented URD because it wanted to immediately deploy SSM services with existing IP multicast receiver applications that did not support IGMPv3. The company did not want to upgrade any software on its end-user systems.

This section addresses the following issues pertaining to this URD Host Signaling scenario:

• Strategy
• Network Topology
• Benefits
• Ramifications
• How URD Host Signaling Works

Strategy

This proposed solution's strategy assumes that IP multicast using MSDP is already deployed in the ISP's autonomous system and that IP multicast connectivity exists between ISPs.

The following strategy deploys SSM with URD:

• Determine an IP multicast address range to run SSM. The suggested default range is from 232.0.0.0 through 232.255.255.255.

• Disable rendezvous point (RP) and MSDP peers from processing this SSM address range as ISM services.

• Configure edge devices to process URD host reports.

Network Topology

Figure 6-2 shows the logical connections of the SSM network topology. As demonstrated in Figure 6-2, the IPTV server is the SSM source and is located within ISP2. (The URD web server also happens to be located within ISP2, but the URD web server could have been located in any of the ISPs. Because its location is not critical, the URD web server has been omitted from the diagram.) The IPTV client is the SSM/URD client. The SSM/URD client is located within the customer network ISP1AC1. The audio and video streams use the group addresses 232.0.2.1 and 232.0.2.2. Within this topology, please note that any existing RPs or MSDP peers have disabled processing of the SSM range.

Figure 6-2 Logical Connections of the Initial SSM Network Topology

Benefits

Deploying SSM in a network provides the following benefits:

• IP multicast address management is not required

• Denial-of-service attacks from unwanted sources are inhibited

• Easy to install and manage

• Ideal for Internet broadcast applications

The sections that follow address these benefits at greater length.

IP Multicast Address Management Is 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, 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 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 obtain a random address, but this solution does not work well given the rising number of applications in the Internet. The best current solution for long-lived applications is GLOP Addressing, which is described in Chapter 1. GLOP Addressing strategy was originally meant to be a temporary solution until a coherent multicasting address allocation scheme was devised. The GLOP Addressing solution suffers from the restriction that each autonomous system is limited to only 255 usable IP multicast addresses. SSM does not rely on a unique group address because the combination of the source and group is always unique. If you use SSM, multicast addressing is no longer an issue for interdomain multicast.

In SSM, traffic from each source is forwarded between routers in the network independent of traffic from other sources, so different sources can reuse multicast group addresses in the SSM range.

Denial-of-Service Attacks from Unwanted Sources Are Inhibited

In SSM, multicast traffic from each individual source is 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 a multicast group to all receivers requesting that multicast group. In Internet broadcast applications, this ISM behavior is undesirable because it allows unwanted sources to easily disturb the actual Internet broadcast source by sending traffic to the same multicast group. This denial-of-service attack depletes bandwidth at the receiver side with unwanted traffic and disrupts the reception of the Internet broadcast. In SSM, because traffic is transported across the network only when it is requested, simply sending traffic to a multicast group does not cause this type of denial-of-service attack.

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 are required only for the network to learn about active sources. This management is not necessary in SSM, making SSM easier to install and manage, and easier to operationally scale in deployment. Another factor that contributes to SSM's easy installation is 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 services (IP multicast address allocation has been a serious problem for content providers).

• The prevention of denial-of-service 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).

Ramifications

Deploying SSM in a network has the following ramifications:

• Legacy applications within the SSM range restrictions

• IGMP v3lite and URD require a Cisco last hop router

• Address management restrictions

• State maintenance limitations

The sections that follow address these ramifications at greater length.

Legacy Applications Within the SSM Range Restrictions

Existing applications in a network predating SSM will not work within the SSM range unless they are modified to support (S, G) channel subscriptions or are enabled through URD. Therefore, enabling SSM in a network might cause problems for existing applications if they use addresses within the designated SSM range. An example of this problem would be the failure of sources and receivers to communicate because the PIM-SM network would no longer use the RP to introduce sources and receivers. Receivers learn about sources through the RP in PIM-SM. SSM does not use this in-band mechanism. Applications using SSM address ranges must use an out-of-band method to notify receivers that the source is active.

IGMP v3lite and URD Require a Cisco Last Hop Router

The IETF is standardizing SSM and IGMPv3 solutions. However, Cisco developed IGMP v3lite and URD. For IGMP v3lite and URD to operate properly for a host, the last hop router toward that host must be a Cisco IOS router with IGMP v3lite or URD enabled.

Address Management Restrictions

Address management is still necessary to some degree when SSM is used with Layer 2 switching mechanisms. Cisco Group Management Protocol (CGMP), IGMP Snooping, and Router-Port Group Management Protocol (RGMP) currently support only group-specific filtering, not (S, G) channel-specific filtering. If different receivers in a switched network request different (S, G) channels that share the same group, they will not benefit from these existing mechanisms. Instead, both receivers will receive all (S, G) channel traffic and filter out the unwanted traffic on input. SSM's ability to reuse group addresses in the SSM range for many independent applications can lead to less-than-expected traffic filtering in a switched network. Follow the recommendations set forth in the IETF drafts for SSM to use random IP addresses out of the SSM range. This minimizes the chance for reuse of a single address within the SSM range between different applications. For example, even with SSM, an application service providing a set of television channels should use a different group for each television (S, G) channel. This setup guarantees that multiple receivers on different channels within the same application service never experience traffic aliasing in networks that include Layer 2 switches.

State Maintenance Limitations

In PIM-SSM, the last hop router will periodically send (S, G) join messages if appropriate (S, G) subscriptions are on the interfaces. 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 does not send traffic for longer periods of time than in normal PIM-SM (or even if the source has never been active).

This case differs from 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 will be deleted and reestablished only after packets from the source arrive again through the RPT. 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.

How URD Host Signalling Works

URD operates by passing a special URL from the web browser to the last hop router. This URL is called a URD intercept URL. A URD intercept URL is encoded with the (S, G) channel subscription and has a format that allows the last hop router to easily intercept it. The router recognizes the URD intercept URL because it is on the well-known TCP port 465.

As soon as the last hop router intercepts an (S, G) channel subscription encoded in a URD intercept URL and sees an IGMP group membership report for the same multicast group from the receiver application, the last hop router will use PIM-SSM to join toward the (S, G) channel as long as the application maintains the membership for the multicast group G. The URD intercept URL is needed only initially to provide the last hop router with the address of the sources to join to.

A URD intercept URL has the following syntax:

webserver:465/path?group=group&source=source1&...source=sourceN&

The webserver string is the name or IP address to which the URL is targeted. This target need not be the IP address of an existing web server, except for situations where the web server wants to recognize that the last hop router failed to support the URD mechanism. The number 465 indicates the URD port. Port 465 is reserved for Cisco by the IANA for the URD mechanism. No other applications can use this port.

When a host's browser encounters a URD intercept URL, it tries to open a TCP connection to the web server on port 465. If the last hop router is enabled for URD on the interface where the router receives the TCP packets from the host, it will intercept all packets for TCP connections destined to port 465 independent of the actual destination address of the TCP connection (that is, independent of the address of the web server). Once intercepted, the last hop router will "speak" a simple subset of HTTP on this TCP connection, emulating a web server.

The only HTTP request that the last hop router will understand and reply to is the following GET request:

GET argument HTTP/1.0
argument = /path?group=group&source=source1&...source=sourceN&

When the router receives a GET request, it tries to parse the argument according to the preceding syntax to derive one or more (S, G) channel memberships. The path string of the argument is anything up to, but not including, the first question mark. The router ignores this string. The group and source1 through sourceN strings are the IP addresses or fully qualified domain names of the channels for which this argument is a subscription request. If the argument matches the syntax shown, the router interprets the argument to be subscriptions for the channels (source1, group) through (sourceN, group).

The router will accept the channel subscriptions if the following conditions are met:

• The multicast group's IP address is within the SSM range.

• The IP address of the host that originated the TCP connection is directly connected to the router.

If the channel subscription is accepted, the router will respond to the TCP connection with the following HTML page format:

HTTP/1.1 200 OK
Server:cisco IOS
Content-Type:text/html
<html>
<body>
Retrieved URL string successfully
</body>
</html>

If an error condition occurs, the <body> part of the returned HTML page will carry an appropriate error message. The HTML page is a by-product of the URD mechanism. Depending on how the web pages carrying a URD intercept URL are designed, this returned text can be displayed to the user or be sized so that the actual returned HTML page is invisible.

The primary effect of the URD mechanism is that the router "remembers" received channel subscriptions and matches them against IGMP group membership reports received by the host. The router will remember a URD (S, G) channel subscription for up to three minutes without a matching IGMP group membership report. When the router sees that it has received both an IGMP group membership report for a multicast group G and a URD (S, G) channel subscription for the same group G, it will join the (S, G) channel through PIM-SSM. The router then continues to join to the (S, G) channel based on only the presence of a continuing IGMP membership from the host. One initial URD channel subscription is all that needs to be added through a web page to enable SSM with URD.

If the last hop router from the receiver host is not enabled for URD, it will not intercept the HTTP connection toward the web server on port 465. This situation results in a TCP connection to port 465 on the web server. If no further provisions on the Web server are taken, the user might see a notice (for example, "Connection refused") in the area of the web page reserved for displaying the URD intercept URL (if the web page was designed to show this output). You can also let the web server "listen" to requests on port 465 and install a Common Gateway Interface (CGI) script to allow the web server to know if a channel subscription failed (for example, to subsequently return more complex error descriptions to the user).

Because the router returns a Content-Type of text and HTML, the best way to include the URD intercept URL into a web page is to use a frame. By defining the size of the frame, you can also hide the URD intercept URL on the displayed page.

By default, URD is disabled on all interfaces. When URD is configured on an interface using the ip urd interface configuration command, it is active only for IP multicast addresses in the SSM range.

Implementing URD Host Signaling

The following sections describe how an ISP customer within an interdomain multicast network implemented SSM in its network using URD. This section covers the following topics:

• Prerequisite

• Implementation Process Steps

Prerequisite

The prerequisite for deploying SSM using URD is to configure interdomain multicast using the following configuration tasks:

• Configure MBGP to exchange multicast routing information.

• Configure multicast borders appropriately.

For more information on how to perform these configuration tasks, refer to Chapter 2.

Implementation Process Steps

The following steps were used to configure SSM using URD on the devices shown in Figure 6-2. For more information about the commands used to configure SSM using URD, please refer to Appendix A, "IP Multicast Command Summary." For more information about how each device in the ISP was configured, please refer to Chapter 7, "Device Characteristics and Configuration Files for Implementing Interdomain Multicast Using SSM."

The multicast solutions in this document were tested with valid IP addresses. Normally, when a configuration file is published, the valid IP addresses are replaced with IP addresses specified in RFC 1918, "Address Allocation for Private Networks." Because the range of available IP addresses was insufficient to span the range of IP addresses used in this solution, the first octet of the valid IP addresses was replaced with a variable. In the example configurations provided in the following sections, the first octet of these reserved IP addresses has been replaced with the letter J or the letter K for privacy reasons. The letter J always represents one unique number, and the letter K always represents a unique number that is different from J.

The example configurations are intended for illustrative purposes only. The letters J and K must be replaced with valid numbers when these IP addresses are configured in an actual network.

Use the following steps to configure SSM using URD on the devices shown in Figure 6-2:

Step 1 Select and enable the SSM range in the ISP.

The following sample configuration shows how to select and enable the SSM range in ISP1:

ip pim ssm

Step 2 Configure filters on the RP for PIM-SM and MSDP traffic in the SSM address range.

The following sample configuration shows how to configure filters on the RP (ISP1BB3 router) for PIM-SM and MSDP traffic in the SSM address range:

ip msdp sa-filter in J.4.0.203 list 124
ip msdp sa-filter out J.4.0.203 list 124

The following access list is configured on the ISP1BB3 router:

access-list 124 deny   ip any host 224.0.2.2
access-list 124 deny   ip any host 224.0.1.3
access-list 124 deny   ip any host 224.0.1.24
access-list 124 deny   ip any host 224.0.1.22
access-list 124 deny   ip any host 224.0.1.2
access-list 124 deny   ip any host 224.0.1.35
access-list 124 deny   ip any host 224.0.1.60
access-list 124 deny   ip any host 224.0.1.39
access-list 124 deny   ip any host 224.0.1.40
access-list 124 deny   ip any 239.0.0.0 0.255.255.255
access-list 124 deny   ip 10.0.0.0 0.255.255.255 any
access-list 124 deny   ip 127.0.0.0 0.255.255.255 any
access-list 124 deny   ip 172.16.0.0 0.15.255.255 any
access-list 124 deny   ip 192.168.0.0 0.0.255.255 any
access-list 124 deny   ip any 232.0.0.0 0.255.255.255

Step 3 Configure URD on user interfaces.

The following sample configuration shows how to configure URD on Ethernet5/3 on the ISP1AC1 router. The ip urd interface configuration command enables interception of TCP packets sent to the reserved URD port 465 on an interface and the processing of URD channel subscription reports.

ISP1AC1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
ISP1AC1(config)# interface Ethernet 5/3
ISP1AC1(config-if)# ip urd
ISP1AC1(config-if)#

Step 4 Verify that URD clients can connect to a source. (Optional)

(a) Enable debug output and attempt to connect to a source:

ISP1AC1# debug ip igmp 232.0.2.1
ISP1AC1# debug ip igmp 232.0.2.2
ISP1AC1# debug ip urd
ISP1AC1# debug ip mrouting

Mar 7 14:17:37 PST:URD:Intercepted TCP SYN packet from K.250.1.41, 0:772431754(ack:seq)
Mar 7 14:17:37 PST:URD:Intercepted TCP ACK packet from K.250.1.41, 48154099:772431755(ack:seq)
Mar 7 14:17:37 PST:URD:Data intercepted from K.250.1.41, offset 5
Mar 7 14:17:37 PST:URD:Enqueued string:'/cgi-bin/error.html
              ?group=232.0.2.2&port=22306&source=J.2.11.6&lifet'
Mar 7 14:17:37 PST:URD:Dequeued URD packet, len:137
Mar 7 14:17:37 PST:URD:String:/cgi-bin/error.html
              ?group=232.0.2.2&port=22306&source=J.2.11.6&lifetim e=7200
              &group=232.0.2.1&port=49254&source=J.2.11.6&lifetime=7200
Mar 7 14:17:37 PST:URD:Matched token:group
Mar 7 14:17:37 PST:URD:Parsed value:232.0.2.2
Mar 7 14:17:37 PST:URD:Matched token:source
Mar 7 14:17:37 PST:URD:Parsed value:J.2.11.6
Mar 7 14:17:37 PST:URD:Matched token:lifetime
Mar 7 14:17:37 PST:URD:Parsed value:7200
Mar 7 14:17:37 PST:URD:Matched token:group
Mar 7 14:17:37 PST:URD:Parsed value:232.0.2.1
Mar 7 14:17:37 PST:URD:Matched token:source
Mar 7 14:17:37 PST:URD:Parsed value:J.2.11.6
Mar 7 14:17:37 PST:URD:Matched token:lifetime
Mar 7 14:17:37 PST:URD:Parsed value:7200

Mar 7 14:17:37 PST:URD:Creating IGMP source state for group 232.0.2.2
Mar 7 14:17:37 PST:IGMP:Setting source flags 18 on (J.2.11.6,232.0.2.2)

Mar 7 14:17:37 PST:URD:Creating IGMP source state for group 232.0.2.1
Mar 7 14:17:38 PST:MRT:Create (J.2.11.6/32, 232.0.2.1), RPF 
  FastEthernet3/0/K.250.1.1, PC 0x609E5CA0
Mar 7 14:17:38 PST:MRT:Add/Update Ethernet5/3/232.0.2.1 to the olist of 
  (J.2.11.6, 232.0.2.1), Forward state
Mar 7 14:17:38 PST:MRT:Create (K.250.1.41/32, 232.0.2.1), RPF 
  Ethernet5/3/0.0.0.0, PC 0x609F25FC

Mar 7 14:17:39 PST:IGMP:Received v2 Report on Ethernet5/3 from 
  K.250.1.41 for 232.0.2.2
Mar 7 14:17:39 PST:MRT:Create (J.2.11.6/32, 232.0.2.2), RPF 
  FastEthernet3/0/K.250.1.1, PC 0x609E5CA0
Mar 7 14:17:39 PST:MRT:Add/Update Ethernet5/3/232.0.2.2 to the olist of 
  (J.2.11.6, 232.0.2.2), Forward state
Mar 7 14:17:39 PST:MRT:Create (K.250.1.41/32, 232.0.2.2), RPF 
  Ethernet5/3/0.0.0.0, PC 0x609F25FC
(b)	Verify that SSM flags are set:
ISP1AC1# show ip mroute

IP Multicast Routing Table
Flags:D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Advertised via MSDP, U - URD,
       I - Received Source Specific Host Report
Outgoing interface flags:H - Hardware switched
Timers:Uptime/Expires
Interface state:Interface, Next-Hop or VCD, State/Mode

(*, 224.0.1.40), 00:01:55/00:00:00, RP K.250.0.201, flags:SJCL
  Incoming interface:Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:01:55/00:02:59

(J.2.11.6, 232.0.2.2), 00:00:45/00:02:59, flags:sCTUI
  Incoming interface:FastEthernet3/0, RPF nbr K.250.1.1
  Outgoing interface list:
    Ethernet5/3, Forward/Sparse, 00:00:16/00:02:46

(K.250.1.41, 232.0.2.2), 00:00:45/00:02:14, flags:sPCT
  Incoming interface:Ethernet5/3, RPF nbr 0.0.0.0
  Outgoing interface list:Null

Summary

This chapter described how an ISP customer within an interdomain multicast network implemented SSM in its network using URD. The initial topology was introduced and SSM basics—including SSM IP address range and SSM operation—were discussed. URD Host Signaling was identified as being the best solution for implementing SSM. URD was described and implementation steps were presented.

Related Documents

• Changes in MBGP Commands Between 12.0S and 12.0T/12.1, Cisco Application Note (www.cisco.com/warp/public/cc/pd/iosw/prodlit/mcb12_an.htm)

• Cisco IOS IP and IP Routing Command Reference, Release 12.1 (www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_r/index.htm)

• Cisco IOS IP and IP Routing Configuration Guide, Release 12.1 (www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/index.htm)

• Cisco IOS Software IP Multicast Group External Homepage (ftpeng.cisco.com/ipmulticast/index.html)

• Cisco IOS Software Multicast Services Web Page (www.cisco.com/go/ipmulticast)

• Gaining New Efficiencies in Multicast Service Delivery, Cisco Beyond Basic IP Newsletter V1.36 (www.cisco.com/warp/public/779/servpro/promotions/bbip/volume_01_issue36.htm)

• Source Specific Multicast with IGMPv3, IGMP v3lite, and URD, Cisco IOS Software Release 12.1(5)T feature module (www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtssm5t.htm)

• IGMP Version 3, Cisco IOS Software Release 12.1(5)T feature module(www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtigmpv3.htm)

• IP Multicast Technology Overview, Cisco white paper(www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/mcst_ovr.htm)

• Multicast Source Discovery Protocol SA Filter Recommendations, Cisco Tech Note (www.cisco.com/warp/public/105/49.html)

• Multiprotocol BGP Extensions for IP Multicast, Cisco IOS Software Release 12.0(7)T feature module(www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t7/mbgp.htm)

• RFC 1112, Host extensions for IP multicasting, S. Deering

• RFC 2770, GLOP Addressing in 233/8, D. Meyer, P. Lothberg