Routers can forward a multicast packet by using either a dense-mode multicast routing protocol or a sparse-mode multicast routing protocol.
Multicast Forwarding Using Dense Mode
The design of a dense-mode routing protocol instructs the router to forward the multicast traffic on all the configured interfaces, with some exceptions to prevent looping.
Dense-mode routers typically do not want to receive multicast packets for a particular group if both of the following are true:
■ The router does not have any active downstream routers that need packets for that group.
■ The router does not know of any hosts on directly connected subnets that have joined that group.
Multicast routers use a Reverse Path Forwarding (RPF) check to prevent loops. The RPF check adds this additional step to a dense-mode router’s forwarding logic:
Look at the source IP address of the multicast packet. If my route that matches the source lists an outgoing interface that is the actual interface on which the packet was received, the packet passes the RPF check. If not, do not replicate and forward the packet.
The RPF check implements a strategy by which routers accept packets that arrive over the shortest path, and discard those that arrive over longer routes.
Multicast Forwarding Using Sparse Mode
Sparse-mode
protocols do not forward the group traffic to any other router unless it receives a message from thatrouter requesting copies of packets sent to a particular multicast group. A downstream router requests to receive the packets only for one of two reasons:
■ The router has received a request to receive the packets from some downstream router.
■ A host on a directly connected host has sent an IGMP Join message for that group.
Multicast Scoping
multicast scoping is the practice of defining boundaries that determine how far multicast traffic will travel in your network. The following sections discuss two methods of multicast scoping:
■ TTL scoping
A router forwards the multicast packet only on those interfaces whose configured TTL value is less than or equal to the TTL value of the multicast packet.
■ Administrative scoping
Administratively scoped multicast addresses are private addresses in the range 239.0.0.0 to 239.255.255.255. They can be used to set administrative boundaries to limit the forwarding of multicast traffic outside of a domain. It requires manual configuration. You can configure and apply a filter on a router’s interface so that multicast traffic with group addresses in the private address range is not allowed to enter or exit the interface.
Dense-Mode Routing Protocols
There are three dense-mode routing protocols:
■ Protocol Independent Multicast Dense Mode (PIM-DM)
■ Distance Vector Multicast Routing Protocol (DVMRP)
■ Multicast Open Shortest Path First (MOSPF)
PIMv2, the current version of PIM, sends Hello messages every 30 seconds (default) on every interface on which PIM is configured. By receiving Hellos on the same interface, routers discover neighbors, establish adjacency, and maintain adjacency. PIMv2 Hellos use IP protocol number 103 and reserved multicast destination address 224.0.0.13, called the All-PIM-Routers multicast address. The Hello messages contain a Holdtime value, typically three times the sender’s PIM hello interval. If the receiver does not receive a Hello message from the sender during the Holdtime period, it considers the sending neighbor to be dead.
The PIM Prune message is sent by one router to a second router to cause the second router to remove the link on which the Prune is received from a particular (S,G) SPT.
Following statements define upstream router and downstream router from the perspective of a router named R1:
■ R1’s upstream router is the router from which R1 receives multicast packets for a particular SPT.
■ R1’s downstream router is a router to which R1 forwards some multicast packets for a particular SPT.
PIM-DM routers can choose to send a Prune message for many reasons, one of which was covered earlier with regard to Figure 17-6. The main reasons are summarized here:
■ When receiving packets on a non-RPF interface.
■ When a router realizes that both of the following are true:
— No locally connected hosts in a particular group are listening for packets.
— No downstream routers are listening for the group.
In reality, there is no separate Prune message and Join message; instead, PIM-DM and PIM-SM use a single message called a Join/Prune message. A Prune message is actually a Join/Prune message with a group address listed in the Prune field, and a Join message is a Join/Prune message with a group address listed in the Join field.
The PM State Refresh message can be sent, just before a neighbor’s Prune timer expires, to keep the interface in a pruned state.
A router sends a Graft message to an upstream neighbor—a neighbor to which it had formerly sent a Prune message—causing the upstream router to put the link back into a forwarding state (for a particular (S,G) SPT).
three small topics related to operations that only matter when PIM is used on LANs:
■ Prune Override - when one router sends a Prune message on a multiaccess network, other routers might not want the link pruned by the upstream routers;
■ Assert messages - The Assert message is used to prevent wasted effort when more than one router attaches to the same LAN. The winner gets the right to be responsible for forwarding multicasts onto the LAN.
■ Designated routers - PIM Hello messages are also used to elect a designated router (DR) on a multiaccess network. A PIM-DM or PIM-SM router with the highest IP address becomes a DR.
Both PIM-DM and PIM-SM use these features in the same way.
Sparse-Mode Routing Protocols
There are two sparse-mode routing protocols:
■ Protocol Independent Multicast Sparse Mode (PIM-SM)
■ Core-Based Tree (CBT)
With PIM-SM, downstream routers must request to receive multicasts using PIM Join messages. Also, once they are receiving those messages, the downstream router must continually send Join messages
to the upstream router—otherwise, the upstream router stops forwarding, putting the link in a pruned state.
PIM-SM also uses the following mechanisms that are used by PIM-DM:
■ PIM Neighbor discovery through exchange of Hello messages.
■ Recalculation of the RPF interface when the unicast routing table changes.
■ Election of a DR on a multiaccess network. The DR performs all IGMP processes when IGMPv1 is in use on the network.
■ The use of Prune Overrides on multiaccess networks.
■ Use of Assert messages to elect a designated forwarder on a multiaccess network. The winner of the Assert process is responsible for forwarding unicasts onto that subnet.
PIM-SM uses a two-step process to initially deliver multicast packets from a particular source to the hosts wanting to receive packets. Later, the process is improved beyond these initial steps. The
steps for the initial forwarding of multicasts with PIM-SM are as follows:
1. Sources send the packets to a router called the rendezvous point (RP).
2. The RP sends the multicast packets to all routers/hosts that have registered to receive packets for that group. This process uses a shared tree.
Usually, a loopback interface address is used as an RP address.
The source may keep sending multicasts, but RP will not register the source unless it has clients that want to receive muiticast data.
PIM Register - message encapsulates the first multicast packet sent by source. RP sends Register-Stop if it doesn't have m-cast clients. If the RP now knows of at least one router/host that needs to receive these multicast packets, it does not reply to this briefer Register message As a result, R1, when its timer expires, again sends its multicast packets to R3 (RP) encapsulated in PIM Register messages.
The concept of the shared tree for a multicast group, also called the root-pathtree (RPT) - it's a tree with the RP as the root. PIM-SM routers collectively create the RPT by sending PIM Join messsages toward the RP. PIM-SM routers choose to send a Join under two conditions:
■ When a PIM-SM router receives a PIM Join message on any interface other than the interface used to route packets toward the RP Sparse-Mode Routing Protocols;
■ When a PIM-SM router receives an IGMP Membership Report message from a host on a directly connected subnet;
The notation (*,G) represents a single RPT. The * represents a wildcard, meaning “any source,” because the PIM-SM routers use this shared tree regardless of the source of the packets. For example, a packet sent from any source IP address, arriving at the RP, and destined to group 228.8.8.8, would cause the RP to use its (*,228.8.8.8) multicast routing table entries, because these entries are part of the RPT for group 228.8.8.8.
When the RP receives a Register message for an active multicast group, the RP doesn't send a Register-Stop messages, instead it reacts to the Register message by deencapsulating the multicast packet and forwarding it. The functions of Register message are:
■ To allow a router to inform the RP that it has a local source for a particular multicast group
■ To allow a router to forward multicasts to the RP, encapsulated inside a unicast packet, until the registration process is completed
After receiving Register message, the RP joins the SPT for the source of the group by sending PIM-SM Join message for the group towards the source.
If the network has multiple sources for the same group, traffic from all the sources would first travel to the RP. and then travel down this shared RPT to all the receivers. Because all sources in the multicast group use a common shared tree, a wildcard notation of (*,G) is used to identify an RPT, where * represents all sources and G represents the multicast group address.
PIM-SM routers choose to maintain the forwarding state on links based on two general criteria:
■ A downstream router continues to send PIM joins for the group.
■ A locally connected host still responds to IGMP Query messages with IGMP Report messages for the group.
Shortest-Path Tree Switchover
Each PIM-SM router can build the SPT between itself and the source of a multicast group and take advantage of the most efficient path available from the source to the router. This feature allows a PIM-SM router to avoid using the inefficient path. Once the router starts receiving the group traffic over the SPT, it can send a Prune message to the upstream router of the shared tree to stop forwarding the traffic for the group. After router receives one packet on the RPT, it can learn the IP address of a source, and initialize a switchover to the SPT for that (source,group) combination.
Dynamically Finding RPs and Using Redundant RPs
A PIM-SM router can use one of the following three methods to learn the IP address of an RP:
■ With Unicast RP, the RP address is statically configured on all the PIM-SM routers (including the RP) with the Cisco IOS global command ip pim rp-address address. This is the method used for the five-router topology shown in Figure 17-19.
■ The Cisco-proprietary Auto-RP protocol can be used to designate the RP and advertise its IP address so that all PIM-SM routers can learn its IP address automatically.
■ A standard BootStrap Router (BSR) protocol can be used to designate the RP and advertise its IP address so that all the PIM-SM routers can learn its IP address automatically.
Using Auto-RP, routers dynamically learn the unicast IP address used by each RP. Auto-RP uses a two-step process,:
1. RP sends RP-Announce messages to the reserved mcast addres 224.0.1.39, stating that the router is an RP; the message also allows the router to advertise the mcast groups for which it is the RP. The RP continues to send these RP-Announce messages every minute.
2. Auto-RP requires that one router be configured as a mapping agent (usually the same router as an RP, but can be a different PIM-SM router) - it learns all the RPs and mcast groups they each support, then m-casts another message, called RP-Discovery, that identifies the RP for each range of mcast group addresses. This message goes to reserved m-cast address 224.0.1.40. It is this RP-Discovery message that actually informs the general router population as to which routers they should use as RPs.
The following list summarizes the steps used by Auto-RP:
1. Each RP is configured to use Auto-RP and to announce itself and its supported multicast groups via RP-Announce messages (224.0.1.39).
2. The Auto-RP mapping agent, which may or may not also be an RP router, gathers information about all RPs by listening to the RP-Announce messages.
3. The mapping agent builds a mapping table that lists the currently best RP for each range of multicast groups, with the mapping agent picking the RP with the highest IP address if multiple RPs support the same multicast groups.
4. The mapping agent sends RP-Discover messages to 224.0.1.40 advertising the mappings.
5. All routers listen for packets sent to 224.0.1.40 to learn the mapping information and find the correct RP to use for each multicast group.
Auto-RP creates a small chicken-and-egg problem in that the purpose of Auto-RP is to find the RPs, but to get the RP-Announce and RP-Discovery messages, PIM-SM routers would need to send a Join toward the RP, which they do not know yet. To overcome this problem, one option is to use a variation of PIM called sparse-dense mode. In PIM sparse-dense mode, a router uses PIM-DM rules when it does not know the location of the RP, and PIM-SM rules when it does know the location of the RP. So, under normal conditions with Auto-RP, the routers would use dense mode long enough to learn the group-to-RP mappings from the mapping agent, and then switch over to sparse mode. However, if any other multicast traffic occurred before the routers learned of the RPs using Auto-RP, the multicast packets would be forwarded using dense-mode rules. This can result in extra network traffic. PIM sparse-dense mode is configured per interface using the ip pim sparse-dense-mode interface subcommand.
To avoid unnecessary dense-mode flooding, configure each router as an Auto-RP Listener and use sparse-mode on the interface. When you enable this feature, only Auto-RP traffic (groups
224.0.1.39 and 224.0.1.40) is flooded out all sparse-mode interfaces. You configure this feature with the global command "ip pim autorp listener".
Dynamically Finding the RP Using BSR
From a very general perspective, BSR works similarly to Auto-RP. Each RP sends a message to another router, which collects the group-to-RP mapping information. That router then distributes the mapping information to the PIM routers. However, any examination of BSR beyond that level of detail shows that these two tools do differ in many ways.
The following are differences between the actions of the BSR, and their implications, and the actions of the Auto-RP mapping agent:
■ The BSR router does not pick the best RP for each multicast group; instead, the BSR router sends all group-to-RP mapping information to the other PIM routers inside bootstrap messages.
■ PIM routers each independently pick the currently best RP for each multicast group by running the same hash algorithm on the information in the bootstrap message.
■ The BSR floods the mapping information in a bootstrap message sent to the all-PIM-routers multicast address (224.0.0.13).
■ The flooding of the bootstrap message does not require the routers to have a known RP or to support dense mode. (This will be described in more detail in the next few pages.)
The other important part of BSR operation is for each candidate RP (c-RP) to inform the BSR router that it is an RP and to identify the multicast groups it supports. This part of the process with BSR is simple if you keep in mind the following point:
All PIM routers already know the unicast IP address of the BSR based on the earlier receipt of bootstrap messages.
Configuring BSR is similar to configuring AutoRP. At a minimum, you need to tell a router that it is a candidate RP or candidate BSR, and which interface to use for the source of its messages. You can optionally tie an access list with the command to limit the groups for which the router will be the RP, or specify a preference to control the election among multiple BSRs.
Anycast RP with Multicast Source Discovery Protocol (MSDP)
The key differences between using Anycast RP and using either Auto-RP or BSR relate to how the redundant RPs are used. The differences are as follows:
■ Without Anycast RP—RP redundancy allows only one router to be the active RP for each multicast group. Load sharing of the collective work of the RPs is accomplished by using one RP for some groups and another RP for other groups.
■ With Anycast RP—RP redundancy and load sharing can be achieved with multiple RPs concurrently acting as the RP for the same group
The way Anycast RP works is to have each RP use the same IP address. The RPs must advertise this address, typically as a /32 prefix, with its IGP.
The two biggest benefits of this design with Anycast RP are as follows:
■ Multiple RPs share the load for a single multicast group.
■ Recovery after a failed RP happens quickly. If an RP fails, multicast traffic is only interrupted for the amount of time it takes the IGP to converge to point to the other RP sharing the same IP address.
Interdomain Multicast Routing with MSDP
The design of Anycast RP can create a problem because each individual RP builds its own shared tree, but any multicast source sends packets to only one of the RPs.
It can be the case, when East and West are two multicast domains, and they are part of the same company, but muiticast domains might also belong to different companies or different ISPs. The solution to this problem is for the RPs to tell each other about all known sources by using MSDP. When a PIM router registers a multicast source with its RP, the RP uses MSDP to send messages to peer RP. These Source Active (SA) messages list the IP addresses of each source for each multicast group and are sent as unicasts over a TCP connection mainteined between peer RPs. MSDP peers must be statically configured and RPs must have routes to each of theirs peers and to the sources. Typically, BGP or Multicast BGP (MBGP) is used for this routing.
***Summary: Finding the RP
Static: Simple reference to unicast IP address
Auto-RP: Sends RP-Announce to 224.0.1.39; relies on sparse-dense mode. Mapping agent sends via 224.0.1.40
BSR: Sends c-RP advertisements as unicasts to BSR IP address; does not need sparse-dense mode. Sends bootstrap messages flooded over non-RPF path.
Anycast RP: Each RP uses identical IP addresses. Can use Auto-RP or BSR normal processes.
Bidirectional PIM
To appreciate bidirectional PIM, a brief review of PIM-SM’s normal operations is useful. While many variations can occur, the following general steps can be used by PIM-SM:
1. The RP builds a shared tree, with itself as the root, for forwarding multicast packets.
2. When a source first sends multicasts, the router nearest the source forwards the multicasts to the RP, encapsulated inside a PIM Register message.
3. The RP joins the source-specific tree for that source by sending a PIM Join toward that source.
4. Later, the routers attached to the same LANs as the receivers can send a PIM Join toward the source to join the SPT for that source.
With bidirectional PIM, the last three steps in this list are not performed. Bidirectional PIM instead follows these steps:
1. As with normal PIM-SM, the RP builds a shared tree, with itself as the root, for forwarding multicast packets.
2. When a source sends multicasts, the router receiving those multicasts does not use a PIM Register message. Instead, it forwards the packets in the opposite direction of the shared tree, back up the tree toward the RP. This process continues for all multicast packets from the source.
3. The RP forwards the multicasts via the shared tree.
4. All packets are forwarded per Steps 2 and 3. The RP does not join the source tree for the source, and the leaf routers do not join the SPT, either.
Source-Specific Multicast
Internet Standard Multicast (ISM) can lead to problems such as the following:
■ Overlapping multicast IP addresses—With a limited number of multicast addresses and a large amount of multicasts, multiple streams might use the same address. Receivers will then get the stream they wanted plus any others using that address. Hopefully, the application will drop the unwanted multicast, but it has used up network resources unnecessarily.
■ Denial-of-service attacks—If an attacker acts as a source sending traffic to a known multicast address, that traffic then is forwarded through the network to all receivers in the group. Enough traffic could interrupt the actual stream and overburden network routers and switches.
■ Deployment complexity—The deployment of RPs, AutoRP, BSR, and MSDP can get complex in a very large network with many sources and receivers.
Source Specific Multicast (SSM) is a solution to those limitations. SSM receivers know the unicast IP address of their source, and specify it when they join a group. With SSM, receivers subscribe to an (S, G) channel, giving both the source address and the mcast group address.
This helps relieve the problems listed previously:
■ Because each stream, or channel, is identified by the combination of a unicast source and multicast group address, overlapping group addresses are okay. Hosts only receive traffic from their specified sources.
■ Denial-of-service attacks are more difficult because an attacker has to know both the source and group addresses, and the path to their source has to pass RPF checks through the network.
■ RPs are not needed to keep track of which sources are active, because source addresses are already known. In addition, SSM can be deployed in a network already set up for PIM-SM. Only edge routers nearest the hosts need to be configured for SSM.
To configure basic SSM, you enable it globally with the command ip pim ssm {default | range access-list}. The multicast address range of 232.0.0.0 through 232.255.255.255 has been designated by IANA as the SSM
range. The keyword default permits the router to forward all multicasts in that range. You can limit the multicast groups by defining them in an access list and using the range keyword. You must also enable IGMP v3 under each interface with the ip igmp version 3 command.