On a single LAN segment, you need to map multicast groups to special MAC addresses for proper delivery to a network interface card (NIC). You accomplish this by mapping the least significant 23 bits of the multicast IP address into the least significant 23 bits of the Ethernet MAC address. In addition, all multicast MAC addresses start with the leading sequence 01:00:5E. For example, the multicast MAC address for RIPv2 routers (224.0.0.9) is represented as 01:00:5E:00:00:09.
Every address in the 224.0.0.0/4 Class D aggregate is referred to as multicast group. This is similar to FF:FF:FF:FF:FF:FF representing a subnet broadcast. This Class D address space is organized as presented in Table 14-1. However, from a modern classless point of view, you should avoid referring to "Class D" addresses.
| Class | Range |
|---|---|
| Reserved link-local addresses | 224.0.0.0/24 |
| Globally scoped addresses | 224.0.1.0–238.255.255.255 |
| Source-specific multicast (SSM) | 232.0.0.0/8 |
| GLOP addresses | 233.0.0.0/8 |
| Limited-scope addresses | 239.0.0.0/8 |
GLOP integrates the autonomous system number (ASN) of a domain into the second and third octet of the 233.x.x.0/8 prefix to accomplish uniqueness for interdomain multicast routing. Relevant additional resources include the following:
-
RFC 3180/RFC 3138, "GLOP"
-
RFC 2365, "Administrative Scoped Multicast"
-
RFC 3171, "IANA Guidelines for IPv4 Multicast Address Assignments"
-
"Source-Specific Protocol Independent Multicast in 232/8," draft-ietf-mboned-ssm232-06.txt
-
"IPv4 Multicast Unusable Group And Source Addresses," draft-ietf-mboned-ipv4-mcast-unusable-01.txt
It is particularly interesting to ping the group address 224.0.0.1 (all multicast hosts on this subnet) and 224.0.0.2 (all multicast routers on this subnet) to figure out which hosts are multicast enabled on your LAN or act as multicast routers. For a complete list, see the Internet Assigned Numbers Authority (IANA) Internet multicast address summary at http://www.iana.org/assignments/multicast-addresses.
Some important multicast group addresses of the reserved local control block are printed in Table 14-2. Most likely, you will find a couple of familiar addresses. No multicast router—regardless of its Time To Live (TTL)—should ever forward IP datagrams with these destination addresses. Hence the name local scope.
| Address | Multicast Group Assignment |
|---|---|
| 224.0.0.0 | Base address (reserved) |
| 224.0.0.1 | All systems on this subnet |
| 224.0.0.2 | All routers on this subnet |
| 224.0.0.3 | Unassigned |
| 224.0.0.4 | DVMRP routers |
| 224.0.0.5 | All OSPF routers |
| 224.0.0.6 | All OSPF designated routers |
| 224.0.0.7 | Internet Stream Protocol V2+ (ST2+) routers |
| 224.0.0.8 | Internet Stream Protocol V2+ (ST2+) hosts/agents |
| 224.0.0.9 | RIPv2 routers |
| 224.0.0.10 | IGRP routers |
| 224.0.0.11 | Mobile agents |
| 224.0.0.12 | DHCP server/relay agent |
| 224.0.0.13 | All PIM routers |
| 224.0.0.18 | VRRP |
| 224.0.0.102 | HSRP |
NOTE
It is necessary to set net.inet.icmp.bmcastecho to 1 on BSD systems for pings to multicast groups to succeed. Either add this entry to /etc/sysctl.conf or set it manually by typing sysctl -w net.inet.icmp.bmcastecho=1.
Administratively Scoped IP Multicast
Scoping is the art of limiting multicast traffic distribution to certain administrative boundaries defined by boundary routers capable of per-interface scoped IP multicast configurations and filters (RFC 2365). Historically, TTL scoping (topological scoping) has been used to control the distribution of multicast traffic, especially within the multicast backbone (MBONE). However, TTL scoping negatively impacts Distance Vector Multicast Routing Protocol (DVMRP) pruning efficiency.
The administratively scoped IPv4 multicast address space is defined as 239.0.0.0/8. Scoped addresses are required to be unique only within administrative boundaries. According to RFC 2365, "The basic forwarding rule for interfaces with configured TTL thresholds is that a packet is not forwarded across the interface unless its remaining TTL is greater than the threshold."
Cisco boundary filters can be configured with the ip multicast boundary {ACL} interface command. mrouted scope examples are provided with the manual page and default configuration file; the setup is straightforward.
The Multicast Protocol Cocktail
An entire zoo of protocols is related to multicast and can be divided into intra- and interdomain multicast protocols.
The intradomain multicast protocols are as follows:
-
DVMRP— Distance Vector Multicast Routing Protocol, RFC 1075
-
PIM-SM/PIM-DM— Protocol Independent Multicast Sparse/Dense Mode, RFC 2362
-
IGMPv1/v2/v3— Internet Group Management Protocol, RFCs 2236 and 3376
-
CGMP— Cisco (proprietary) Group Management Protocol
-
MOSPF— Multicast OSPF, RFCs 1584 and 1585
-
CBTv2/v3— Core-Based Tree Multicast Protocol, RFC 2189
-
RGMP— Router-Port Group Management Protocol (IETF draft)
-
SDP— Session Directory Protocol
-
PGM— Pragmatic General Multicast, RFC 3208
-
MLD— Multicast Listener Discovery Protocol, RFC 3590
The interdomain multicast protocols are as follows:
-
MBGP— Multiprotocol BGP, a.k.a. "Multicast" BGP
-
MSDP— Multicast Source Discovery Protocol, RFC 3618
-
BGMP— Border Gateway Multicast Protocol, draft-ietf-bgmp-spec-05.txt
Although these really are a lot of standards and protocols, do not be intimidated. Although they all serve specific and structured purposes, this chapter deals only with IGMP, DVMRP, and PIM-DM/PIM-SM. These protocols are presented in a LAN context in Figure 14-1.
There exists a clear differentiation between multicast signaling information and actual data forwarding (reverse-path forwarding to be precise). Some approaches rely on their own signaling (mrouted), whereas others require additional unicast routing information (for example, PIM). For an excellent introduction to these protocols, consult the Cisco.com article "Configuring IP Multicast Routing."
0 comments:
Post a Comment