Operation of Protocol Independent Multicast, Sparse Mode (PIM-SM)
You learned earlier how shared trees are more scalable in sparsely populated multicast internetworks, and how they can even be used in densely populated internetworks. The discussion may have left you with the impression that shared multicast trees are always preferable over source-based trees. Such is not the case.
Figure 5-54 shows a situation in which a source-based tree might be preferred over a shared tree. In this topology, the source and destination are closer to each other than they are to the core router at which the shared tree is rooted. A source-based tree directly between the source and destination is preferable, if only the associated overhead could be reduced.
Unlike CBT, PIM-SM supports both shared and source-based trees, which is the primary reason it is presently the multicast routing protocol of choice in most modern internetworks.
PIM-SM is described in RFC 2362.[13]
PIM-SM Basics
PIM-SM uses seven PIMv2 messages:
Notice that three of the messages (Hello, Join/Prune, and Assert) also are used by PIM-DM. There are four messages unique to PIM-SM, just as there are two messages (Graft and Graft-Ack) used only by PIM-DM.
Several functions are common to PIM-SM and PIM-DM:
Neighbor discovery through exchange of Hello messages Recalculation of the RPF interface when the unicast routing table changes Election of a designated router on multiaccess networks The use of Prune Overrides on multiaccess networks Use of Assert messages to elect a designated forwarder on multiaccess networks
These functions are all described in the PIM-DM section and so are not described again here.
Unlike PIM-DM, PIM-SM uses explicit joins, making the creation of both shared and source-based multicast trees more efficient.
Finding the Rendezvous Point
As you have already learned, a shared tree is rooted at a router somewhere in the multicast internetwork rather than at the source. CBT calls this router the core, and PIM-SM calls it the rendezvous point (RP). Before a shared tree can be established, the joining routers must know how to find the RP. The router can learn the address of the RP in three ways:
The RP address can be statically configured on all routers. An open-standard bootstrap protocol can be used to designate and advertise the RP. The Cisco-proprietary Auto-RP protocol can be used to designate and advertise the RP.
The use of all three methods is demonstrated in Chapter 6.
As with static routes, statically configuring RP addresses on all routers has the advantage of providing very specific control of the internetwork, but at the cost of high administrative overhead. Static RP configuration is generally only feasible on small multicast internetworks.
The Bootstrap Protocol
The bootstrap protocol, first supported in Cisco IOS Software Release 11.3T, is essentially the same protocol used by CBT to advertise core routers, with a few changes in message names and formats. To run the bootstrap protocol, candidate bootstrap routers (C-BSRs) and candidate rendezvous points (C-RPs) are administratively designated in the internetwork. Typically, the same set of routers is configured as both C-BSRs and C-RPs. The C\_BSRs and C-RPs identify themselves by means of an IP address, which is typically configured to be the address of a loopback interface.
The first step is for a bootstrap router (BSR) to be elected from the C-BSRs. Each C-BSR is assigned a priority between 0 and 255 (the default is 0) and a BSR IP address. When a router is configured as a candidate BSR, it sets a bootstrap timer to 130 seconds and listens for a Bootstrap message.
Bootstrap messages advertise the originator's priority and BSR IP address. When a C-BSR receives a Bootstrap message, it compares the originator's priority with its own priority. If the originator has a higher priority, the receiver resets its bootstrap timer and continues to listen. If the receiver's priority is higher, it declares itself the BSR and begins sending Bootstrap messages every 60 seconds. If the priorities are equal, the higher BSR IP address is the tiebreaker.
If a C-BSR's 130-second bootstrap timer expires, the router assumes that there is no BSR, declares itself the BSR, and begins sending Bootstrap messages every 60 seconds.
Bootstrap messages use the All_PIM_Routers destination address of 224.0.0.13 and have a TTL of 1. When a PIM router receives a Bootstrap message, it sends a copy out all interfaces except the one on which the message was received. This procedure not only ensures that the Bootstrap messages are flooded throughout the multicast domain, it also ensures that every PIM router receives a copy and thus knows which router is the BSR.
A C-RP is configured with an RP IP address and a priority between 0 and 255. The router can be configured to be a candidate RP for only certain multicast groups, or it can be the C\_RP for all groups. When the BSR is known by reception of Bootstrap messages, the C\_RP begins unicasting Candidate-RP-Advertisement messages to the BSR. These messages contain the originator's RP address, the group addresses for which the originator is a candidate RP, and its priority.
The BSR compiles the C-RPs, their respective priorities, and their corresponding groups into an RP-Set, and it advertises the RP-Set throughout the PIM domain in Bootstrap messages. Also included in the Bootstrap message is an 8-bit hash-mask. Again, all PIM routers receive the Bootstrap messages because of the destination address 224.0.0.13.
When a router must join a shared tree as the result of receiving either an IGMP message or a PIM Join message, it examines the RP-Set learned from the BSR via Bootstrap messages.
If there is only one C-RP for the group, that router is selected as the RP. If there are multiple C-RPs for the group, each with different priorities, the router with the lowest priority number is chosen as the RP. If there are multiple C-RPs for the group with equally low priorities, a hash function is run. The input of the function is the group prefix, the hash-mask, and the C-RP address, and the output is some numeric value. The C-RP with the highest resulting value becomes the RP. If the hash function returns the same value for more than one C-RP, the C-RP with the highest IP address becomes the RP.
NOTE
The hash function, if you must know, is as follows:
Value(G,M,C) = (1103515245 * ((11035515245 * (G&M) + 12345) XOR C) + 12345) mod 231
where:
G = Group prefix M = Hash-mask C = C-RP address
This set of procedures ensures that all routers in the domain select the same RP for the same group. The only reason the hash function is necessary is to incorporate the hash-mask, which allows some number of consecutive group addresses to be mapped to the same RP. The use of the hash-mask is demonstrated in Chapter 6.
The Auto-RP Protocol
Auto-RP was first supported in Cisco IOS Software Release 11.1(6). It was developed by Cisco to provide automatic discovery of the RP before the bootstrap protocol was specified for PIM-SM. As with bootstrap, candidate RPs (C-RPs) are designated in the PIM-SM domain and are identified by designated IP addresses, usually the address of a loopback interface. One or more RP mapping agents, routers that play a role similar to BSRs, also are designated. The four major differences from the bootstrap protocol are as follows:
Auto-RP is Cisco proprietary and usually cannot be used in multivendor topologies. However, some other vendors now support Auto-RP. RP mapping agents are designated rather than elected from a set of candidates as BSRs are. RP mapping agents map groups to RPs instead of advertising an RP-Set and distributing the selection process throughout the domain. Rather than the multicast address 224.0.0.13 used by bootstrap and understood by all PIM routers, Auto-RP uses two reserved multicast addresses: 224.0.1.39 and 224.0.1.40.
When a Cisco PIM-SM router is configured to be a candidate RP for one or more groups, it advertises itself and the groups for which it is a C-RP in RP-Announce messages. These messages are multicast every 60 seconds to the reserved Cisco-RP-Announce address 224.0.1.39. The configured mapping agents for the domain listen for this address. From all the received RP-Announce messages, the mapping agent selects an RP for a group based on the numerically highest IP address of all the group's C-RPs.
The RP mapping agent then advertises the complete list of group-to-RP mappings in RP-Discovery messages. These messages are sent every 60 seconds to the reserved Cisco-RP-Discovery address 224.0.1.40. All Cisco PIM-SM routers listen for this address and thus learn the correct RP to use for each known group.
PIM-SM and Shared Trees
The major difference between a shared tree route entry and a source-based or SPT route entry is that the shared tree entry is not source-specific—in keeping with the fact that many sources share the same tree. Therefore, the entry is a (*, G) pair, where the asterisk is a wildcard representing any and all source addresses sending to the group G.
When a PIM-SM DR receives an IGMP Membership Report from a host requesting a join to a multicast group, it first checks to see whether there is already an entry in the multicast table for the group. If there is an entry for the group, the interface on which the IGMP message was received is added to the entry as an outgoing interface. No other action is necessary.
If no entry exists, a (*, G) entry is created for the group, and the outgoing interface is added. The router then looks up the group-to-RP mapping for this group (as demonstrated in Example 5-14), the unicast routing table is consulted for the route to the specified RP, and the upstream interface to the RP is added to the incoming (RPF) interface.
Example 5-14 The show ip pim rp mapping Command Displays a Router's Group-to-RP Mappings. Here, All Multicast Groups Are Mapped to the RP 172.16.224.1
Iron#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static
RP: 172.16.224.1 (?)
Iron#
Example 5-15 shows an example of a (*, G) route entry at router Iron in Figure 5-55.
Example 5-15 This (*, G) Entry Indicates That the Upstream Neighbor on the Shared Tree for Group 236.82.134.23 Is 172.16.224.1, Reachable Out Interface S1.708, and That the RP for the Group Is 172.16.224.1. The Flags Associated with the Entry Indicate Sparse Mode and That There Is a Connected Member (on Interface E0)
Iron#show ip mroute 236.82.134.23
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 236.82.134.23), 00:08:58/00:02:59, RP 172.16.224.1, flags: SC
Incoming interface: Serial1.708, RPF nbr 172.16.2.242
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:08:59/00:02:47
Iron#
The router then sends a Join/Prune message out the upstream interface to 224.0.0.13, as illustrated by Figure 5-56. The message includes the address of the group to be joined and the address of the RP. The prune section of the message is empty. Two flags also are set—the wildcard bit (WC-bit) and the RP-tree bit (RPT-bit):
When the upstream router receives the Join/Prune, one of four situations and associated actions holds true:
The router is not the RP, and it is on the shared tree. The router adds the interface on which it received the Join/Prune to the outgoing interface list for the group. The router is not the RP, and it is not on the tree. The router creates a (*, G) entry and sends its own Join/Prune upstream toward the RP. The router is the RP, and it has an entry for the group. The router adds the interface on which it received the Join/Prune to the outgoing interface list for the group. The router is the RP, and it has no entry for the group. The router creates a (*, G) entry and adds the receiving interface to the outgoing interface list for the group.
The implication of the last bullet is that a group does not have to have a source for a tree to be built from members of the RP.
Once the shared tree is established, routers periodically send Join/Prune messages to upstream neighbors as a keepalive. The Join/Prune lists all route entries for which the destination neighbor is the previous-hop router. The default period is 60 seconds. This can be changed with the Cisco IOS Software command ip pim message-interval. The holdtime is 3 times the Join/Prune interval, or 3 minutes by default, and it is advertised in the Join/Prune message. If a PIM-SM router does not hear a Join/Prune for a known group from a downstream neighbor within the holdtime, it prunes the downstream router from the outgoing interface list of the group entry. Example 5-16 shows the entry for group 236.82.134.23 in router Tin of Figure 5-55. The outgoing interface to router Iron, S1.805, indicates that the interface will be pruned if a Join/Prune is not received from Iron within 2 minutes, 11 seconds.
Example 5-16 The Entry for Group 236.82.134.23 at Tin in Figure 5-55 Shows the Remaining Holdtime Associated with Downstream Router Iron. Notice That There Is No C Flag Set for This Entry, Because Tin Has No Directly Connected Group Members
Tin#show ip mroute 236.82.134.23
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set
Timers: Uptime/Expires
(*, 236.82.134.23), 00:09:39/0:02:56, RP 172.16.224.1, flags: S
Incoming interface: Serial1.805, RPF neighbor 172.16.2.237
Outgoing interface list:
Serial1.807, Forward state, Sparse mode, uptime 00:09:39, expires 0:02:11
Tin#
Pruning occurs in the same manner. When a router wants to prune itself from a shared tree because it no longer has any directly connected group members or downstream neighbors, it sends a Join/Prune message out the RPF interface to the upstream neighbor. The group and RP address are listed in the Prune section, and the WC-bit and RPT-bit are set. The upstream router then removes the receiving interface from the outgoing interface list for the group. If that router has no more downstream neighbors and no connected group members, it also prunes itself.
NOTE
The Prune Override mechanism, as described in the PIM-DM section, is used to ensure that downstream neighbors on multiaccess networks are not inadvertently pruned.
Source Registration
The fundamental concept of shared trees, mentioned several times already, is that the multicast tree is rooted at a core or rendezvous point rather than at the source. The question arises, then, of how the source delivers multicast packets to the RP for delivery over the branches of the tree. Recall that CBT resolves the question by using bidirectional trees—packets can flow both down a branch from the core and up the branch toward the core. The source's directly connected router joins the shared tree to the core and then sends its traffic up the branch to the core. The problem with bidirectional trees is that it is very hard to ensure a loop-free topology, because RPF checks cannot be performed when there is no distinct "upstream" and "downstream."
Unlike CBT, PIM-SM uses RPF checks. Therefore, its trees must be unidirectional—that is, traffic can flow only down tree branches from the RP. The unidirectional traffic ensures a clearly defined incoming or RPF interface. If traffic flows only from the RP outward, however, how does a source deliver its multicast traffic to the RP?
When a PIM-SM router first receives a multicast packet from a directly connected source, it looks in its group-to-RP mappings to find the correct RP for the destination group, as demonstrated in the output in Example 5-17. This step is the same as when a member signals a group join with an IGMP message.
Example 5-17 The Group-to-RP Mapping of Router Aluminum in Figure 5-55. Compare This to Example 5-14; Iron Has a Static RP Napping, Whereas Aluminum Has Learned the RP Address Dynamically
Aluminum#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4, uptime: 00:02:39, expires: 00:02:17
RP 172.16.224.1 (?), PIMv2 v1
Info source: 172.16.2.245 (?)
Aluminum#
After the group's RP is determined, the router encapsulates the multicast packet in a PIM Register message and sends the message to the RP. Instead of multicasting, the Register message is unicast to the RP address, as illustrated by Figure 5-57.
When the RP receives the Register message, the multicast packet is decapsulated. If the multicast routing table already has an entry for the group, copies of the multicast packet are forwarded out all interfaces on the outgoing interface list, as illustrated by Figure 5-58.
If there is a significant amount of multicast traffic to be sent to the RP, it is inefficient to continue encapsulating the packets in Register messages to get them to the RP. Therefore, the RP creates an (S, G) entry in its multicast table and initiates an SPT to the source DR by multicasting a Join/Prune message, as illustrated by Figure 5-59. In this message, the source address is included, WC-bit = 0, and RPT-bit = 0 to indicate that the path is a source-based SPT rather than a shared RPT.
Once the SPT is established and the RP is receiving the group traffic over that tree, it sends a Register Stop message to the source's DR to tell the router to stop sending the multicast packets in Register messages, as illustrated by Figure 5-60.
If there are no group members when the source begins sending multicast traffic to the RP, the RP does not build an SPT. Instead, it just sends a Register Stop to the source's DR, telling it to stop sending the encapsulated multicast packets in Register messages. The RP has a (*, G) entry for the group, and when a member joins, the RP can then initiate the SPT.
A mechanism known as Register Suppression helps protect against the DR continuing to send packets to a failed RP. When a DR receives a Register Stop, it starts a 60-second Register-Suppression timer. When the timer expires, the router again sends its multicast packets to the RP in Register messages. However, 5 seconds before this occurs, the DR sends a Register message with a flag set, called the Null-Register bit, and with no encapsulated packets. If this message triggers a Register Stop from the RP, the Register-Suppression timer is reset.
The debug messages in Example 5-18 show the sequence of events that occurs when router Aluminum begins sending multicast traffic to group 236.82.134.23. In this particular case, no members have yet joined the group. As a result, the RP (Brass) immediately sends a Register Stop message to Aluminum in response to the Register.
Example 5-18 This RP Has No Members for Group 236.82.134.23. As a Result, It Immediately Replies to the Register Message from Aluminum (172.16.2.233) with a Register Stop Message. Notice That Both Messages Are Unicast Rather Than Multicast
Brass#debug ip pim 236.82.134.23
PIM debugging is on
Brass#
PIM: Received Register on Serial1.509 from 172.16.2.233 for 172.16.1.1, group
236.82.134.23
PIM: Send Register-Stop to 172.16.2.233 for 172.16.1.1, group 236.82.134.23
Example 5-19 shows the route entry for the group. Notice that there are both (*, G) and (S, G) entries for the group. The (*, G) entry shows a null incoming interface and an RPF neighbor of 0.0.0.0, indicating that this router is the root of the shared tree. The (S, G) entry shows that router Platinum (172.16.2.246), the upstream neighbor toward the source, is the RPF neighbor. There are no interfaces on the outgoing interface list, so the entry is pruned.
Example 5-19 The Routing Entry for Group 236.82.134.23 at the RP. No Members Have Joined the Group
Brass#show ip mroute 236.82.134.23
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 236.82.134.23), 00:07:38/00:02:59, RP 172.16.224.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1.509, Forward/Sparse, 00:03:06/00:02:50
(172.16.1.1, 236.82.134.23), 00:07:38/00:01:21, flags: P
Incoming interface: Serial1.509, RPF nbr 172.16.2.246
Outgoing interface list: Null
Brass#
Example 5-20 shows the route entries for the group at Aluminum, the source's DR. Here, the (*, G) entry also exists, with the Ethernet interface connecting to the source in the outgoing interface list. The incoming interface list is null. The (S, G) entry shows the same Ethernet interface on the incoming interface list. The entries have two flags in common: One flag indicates that the source is directly connected; the other (F) indicates that the router must send a Register message for the group traffic.
Example 5-20 The Corresponding Route Entry at the Source's DR Shows a Pruned SPT Entry
Aluminum#show ip mroute 236.82.134.23
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop, State/Mode
(*, 236.82.134.23), 00:15:30/00:02:59, RP 172.16.224.1, flags: SJCF
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:15:23/00:02:28
(172.16.1.1/32, 236.82.134.23), 00:00:29/00:02:30, flags: PCFT
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list: Null
Aluminum#
The T flag on the (S, G) entry indicates that the entry represents an SPT, and the P entry indicates that there are no interfaces on the outgoing interface list. If there were an RPF neighbor, the router would send a Prune message to it for the group.
The final flag of interest is the J flag on the (*, G) entry. This flag indicates that the router switches to the SPT when a packet is received on the shared tree. Just how PIM-SM routers switch from shared trees to SPTs is the subject of the following section.
The debug messages in Example 5-21 show the sequence of events that occurs when the host attached to router Iron joins the group. The Join/Prune message, which was generated by Iron and multicast hop by hop to the RP, is received from Tin. The interface to Tin is added to the (*, G) entry; the interface is also added to the (S, G) entry, because the SPT to Aluminum will be used. Next, an SPT Join message is sent to Aluminum.
Example 5-21 These debug Messages Show the Member Attached to Router Iron Joining Group 236.82.134.23
Brass#debug ip pim 236.82.134.23
PIM debugging is on
Brass#
PIM: Received v2 Join/Prune on Serial1.508 from 172.16.2.238, to us
PIM: Join-list: (*, 236.82.134.23) RP 172.16.224.1, RPT-bit set, WC-bit set, S-bit
set
PIM: Add Serial1.508/172.16.2.241 to (*, 236.82.134.23), Forward state
PIM: Add Serial1.508/172.16.2.241 to (172.16.1.1/32, 236.82.134.23)
PIM: Building Join/Prune message for 236.82.134.23
PIM: For 172.16.2.246, Join-list: 172.16.1.1/32
PIM: Send periodic Join/Prune to 172.16.2.246 (Serial1.509)
Example 5-22 shows the resulting route entries at the RP, and Example 5-23 shows the resulting route entries at the source's DR.
Example 5-22 When a Group Member Joins, Its Interface Is Added to the (*, G) Entry. It Also Is Added to the (S, G) Entry Because of the SPT to Aluminum
Brass#show ip mroute 236.82.134.23
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 236.82.134.23), 00:29:58/00:03:05, RP 172.16.224.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1.509, Forward/Sparse, 00:29:58/00:02:52
Serial1.508, Forward/Sparse, 00:24:36/00:03:05
(172.16.1.1, 236.82.134.23), 00:24:54/00:02:59, flags: T
Incoming interface: Serial1.503, RPF nbr 172.16.2.246
Outgoing interface list:
Serial1.508, Forward/Sparse, 00:24:36/00:02:35
Brass#
Example 5-23 The Interface Toward the RP Has Been Added to the Outgoing Interface List of Aluminum's (S, G) Entry, and the Entry Is No Longer in Prune State
Aluminum#show ip mroute 236.82.134.23
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop, State/Mode
(*, 236.82.134.23), 00:00:47/00:02:59, RP 172.16.224.1, flags: SJCF
Incoming interface: Serial0/1.309, RPF nbr 172.16.2.245
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:00:01/00:02:58
(172.16.1.1/32, 236.82.134.23), 00:00:47/00:02:59, flags: CFT
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/1.309, Forward/Sparse, 00:00:34/00:02:58
Aluminum#
PIM-SM and Shortest Path Trees
In Figure 5-61, router Lead has been added to the PIM-SM domain, and Lead has a group member attached. Under basic shared-tree rules, Lead would join the shared tree rooted at Brass. It is obvious in the illustration, however, that the direct link to Aluminum is a more efficient path for the multicast packets from the source to Lead's group member.
You already have seen how PIM-SM can build an SPT between the RP and the source DR. The protocol also allows SPTs to be built all the way from a router with attached group members to the source DR, to alleviate inefficiencies in topologies, such as the one in Figure 5-61.
Example 5-24 shows Lead building an SPT after its group member requests a join via IGMP. First, the router sends a Join to the RP (out S1.605), as expected. When the multicast packets begin arriving, the router can observe the IP address of the source. Consulting its unicast routing table, it sees that the source IP address is reachable via a different interface (S1.603) than the interface to the RP. Lead sends a Join to Aluminum, and an SPT is built directly between those two routers. When Lead begins receiving the multicast traffic for (172.16.1.1, 236.82.134.23) over the SPT, it sends a Prune message to the RP removing itself from the shared tree.
Example 5-24 Lead Joins the Shared RPT. After It Begins Receiving the Multicast Traffic, It Joins the SPT Directly from the Source DR and Prunes Itself from the RPT
Lead#debug ip pim 236.82.134.23
PIM debugging is on
Lead#
PIM: Check RP 172.16.224.1 into the (*, 236.82.134.23) entry
PIM: Send v2 Join on Serial1.605 to 172.16.2.254 for (172.16.224.1/32,
236.82.134.23), WC-bit, RPT-bit, S-bit
PIM: Building batch join message for 236.82.134.23
PIM: Send Join on Serial1.603 to 172.16.2.250 for (172.16.1.1/32, 236.82.134.23),
S-bit
PIM: Send v2 Prune on Serial1.605 to 172.16.2.254 for (172.16.1.1/32,
236.82.134.23), RPT-bit, S-bit
Lead#
Example 5-25 shows the multicast route entries for group 236.82.134.23 at Lead. The (*, G) entry for the shared tree still exists, and it continues to exist as long as the router has members or downstream neighbors for the group. Notice, however, that the (S, G) entry indicates a different incoming interface and a different RPF neighbor.
Example 5-25 Lead's Route Entries for Group 236.82.134.23 Show That the Router Has Switched from the RPT to the SPT
Lead#show ip mroute 236.82.134.23
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 236.82.134.23), 00:26:26/00:02:58, RP 172.16.224.1, flags: SJC
Incoming interface: Serial1.605, RPF nbr 172.16.2.254
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:26:26/00:02:12
(172.16.1.1, 236.82.134.23), 00:26:26/00:02:36, flags: CJT
Incoming interface: Serial1.603, RPF nbr 172.16.2.250
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:26:26/00:02:12
Lead#
Example 5-26 shows the route entries for Aluminum, and Example 5-27 shows the route entries for Brass. You can observe that Aluminum is forwarding on SPT trees to both Lead and Brass. At Brass, the interface to Lead is not in the outgoing interface list of the (S, G) entry, because the RP is not forwarding to that router.
Example 5-26 Aluminum's Multicast Route Entry for Group 236.82.134.23, Showing an SPT to Both Lead and Brass
Aluminum#show ip mroute 236.82.134.23
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop, State/Mode
(*, 236.82.134.23), 00:08:17/00:02:59, RP 172.16.224.1, flags: SJCF
Incoming interface: Serial0/1.309, RPF nbr 172.16.2.234
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:07:33/00:02:30
(172.16.1.1/32, 236.82.134.23), 00:08:17/00:02:59, flags: CFT
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0/1.309, Forward/Sparse, 00:08:07/00:02:48
Serial0/1.306, Forward/Sparse, 00:06:55/00:02:59
Aluminum#
Example 5-27 Brass's Route Entries for Group 236.82.134.23. The Interface to Lead (S1.506) Remains on the Outgoing Interface List of the (*, G) Entry but Is Not on the Outgoing Interface List of the (S, G) Entry
Brass#show ip mroute 236.82.134.23
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 236.82.134.23), 00:13:13/00:03:20, RP 172.16.224.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1.508, Forward/Sparse, 00:13:04/00:03:20
Serial1.509, Forward/Sparse, 00:12:30/00:02:18
Serial1.506, Forward/Sparse, 00:11:52/00:02:33
(172.16.1.1, 236.82.134.23), 00:13:14/00:02:59, flags: T
Incoming interface: Serial1.509, RPF nbr 172.16.2.246
Outgoing interface list:
Serial1.508, Forward/Sparse, 00:13:05/00:02:49
Brass#
RFC 2362 specifies that a router should switch from the RPT to an SPT when "the data rate is high." What, then, constitutes a high data rate? The answer is rather arbitrary. It might depend on the cumulative available bandwidth across the route, the congestion along the route, the performance of the routers, or any number of other factors. You, as the network administrator, must make the determination based on the unique characteristics of your own internetwork.
Cisco uses a simple default. Cisco routers join the SPT immediately after receiving the first packet on the shared tree for a given (S, G). This default can be changed with the command ip pim spt-threshold, in which the threshold for switching to the SPT is specified in kilobits per second (the default represents 0 Kbps). The router measures the arrival rate of packets once every second. If packets for either any group or a specified group arrive at a rate exceeding the threshold, the router switches. When a router switches to the SPT, it monitors the arrival rate on the source tree. If the group's rate falls below the configured threshold for more than 60 seconds, the router attempts to switch back to the shared tree for that group.
The keyword infinity also can be used with the command to prevent a router from ever switching to the SPT.
Interestingly, a router switches to an SPT even if the shortest route to the source is through the RP. In the previous examples, router Iron stayed on the RPT. The reason is that, to simplify the introduction to PIM-SM tree behavior, the statement ip pim spt-threshold infinity was added to Iron's configuration. Example 5-28 displays Iron's route entry for group 236.82.134.23. The command is then removed from the router's configuration, and the route is observed again. You can see that the router, after the SPT threshold is set back to the default, immediately switched to the SPT. The route entries at the RP remain as they appear in Example 5-27, because the interface toward Iron is already on the outgoing interface list of the (S, G) entry.
Example 5-28 Iron's Entries for Group 236.82.134.23, Before and After the SPT Switching Threshold Has Been Reset to the Default
Iron#show ip mroute 236.82.134.23
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 236.82.134.23), 00:00:57/00:02:59, RP 172.16.224.1, flags: SC
Incoming interface: Serial1.708, RPF nbr 172.16.2.242
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:00:57/00:02:02
Iron#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Iron(config)#no ip pim spt-threshold infinity
Iron(config)#^Z
Iron#
2d01h: %SYS-5-CONFIG_I: Configured from console by console
Iron#show ip mroute 236.82.134.23
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 236.82.134.23), 00:01:23/00:02:59, RP 172.16.224.1, flags: SJC
Incoming interface: Serial1.708, RPF nbr 172.16.2.242
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:01:23/00:02:34
(172.16.1.1, 236.82.134.23), 00:00:11/00:02:59, flags: CJT
Incoming interface: Serial1.708, RPF nbr 172.16.2.242
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:00:12/00:02:47
Iron#
In Example 5-28 and in several previous figures, a J flag is associated with either the (*, G) entry, the (S, G) entry, or both. This is the Join SPT flag. When associated with a (*, G) entry, it indicates that traffic flowing down the shared tree exceeds the SPT threshold. If the SPT has not already been joined, it will be following the next received group packet. When associated with an (S, G) entry, the J flag indicates that the SPT has been joined because the RPT traffic has exceeded the SPT threshold.
Table 5-11 lists and describes all the flags that may be associated with an mroute. This list is taken directly from the Cisco IOS Software Command Reference.
Table 5-11. mroute Flags|
| D-Dense
| Entry is operating in dense mode.
| | S-Sparse
| Entry is operating in sparse mode.
| | C-Connected
| A member of the multicast group is present on the directly connected interface.
| | L-Local
| The router itself is a member of the group.
| | P-Pruned
| The route has been pruned.
| | R-RP-bit set
| Indicates that the (S, G) entry is pointing toward the RP. This is typically prune state along the shared tree for a particular source.
| | F-Register flag
| Indicates that the software is registering for a multicast source.
| | T-SPT-bit set
| Indicates that packets have been received on the shortest path tree.
| | J-Join SPT
| For (*, G) entries, indicates that the rate of traffic flowing down the shared tree is exceeding the SPT-Threshold set for the group. (The default SPT-Threshold setting is 0 Kbps.) When the J-Join SPT flag is set, the next (S, G) packet received down the shared tree triggers an (S, G) join in the direction of the source, thereby causing the router join the source tree.
For (S, G) entries, indicates that the entry was created because the SPT-Threshold for the group was exceeded. When the J-Join SPT flag is set for (S, G) entries, the router monitors the traffic rate on the source tree and attempts to switch back to the shared tree for this source if the traffic rate on the source tree falls below the group's SPT-Threshold for more than 1 minute.
|
PIMv2 Message Formats
PIMv2 messages are encapsulated in IP packets with a protocol number of 103. Except for the cases in which the messages are unicast, the IP destination address is the reserved multicast address 224.0.0.13, and the TTL is set to 1. Both the multicast address and the TTL ensure that the messages are forwarded only to neighboring routers.
Although version 2 is the current version, PIMv1 is still common. That version uses an IP protocol number of 2, making it a subset of the IGMP protocol. Version 1 uses a multicast address of 224.0.0.2.
Cisco IOS supports PIMv2 beginning with 11.3(2)T. It provides backward compatibility with PIMv1 by automatically switching to that version on any interface on which a version neighbor is detected. An interface also can be manually set to PIMv1 or PIMv2 with the ip pim version command.
For the sake of space, only PIMv2 message formats are covered in this book. For PIMv1 formats, refer to the appropriate Internet drafts.
You will notice that several message types have field labels that refer to encoded addresses. For more information on the encoding formats and details of these fields, see section 4.1 of RFC 2362.
All Reserved fields in the following messages are set to all zeros and are ignored upon receipt.
PIMv2 Message Header Format
All PIM messages have a standard header, shown in Figure 5-62.
The fields for the PIMv2 message header are defined as follows:
Version specifies the version number. The current version number is 2, although PIMv1 is still in common usage. Type specifies the type of PIM message encapsulated behind the header. Table 5-12 lists the PIMv2 message types. Table 5-12. PIMv2 Message Types|
| 0
| Hello
| | 1
| Register (used in PIM-SM only)
| | 2
| Register-Stop (used in PIM-SM only)
| | 3
| Join/Prune
| | 4
| Bootstrap (used in PIM-SM only)
| | 5
| Assert
| | 6
| Graft (used in PIM-DM only)
| | 7
| Graft-Ack (used in PIM-DM only)
| | 8
| Candidate-RP-Advertisement (used in PIM-SM only)
|
Checksum is a standard IP-style checksum, using a 16-bit one's complement of the one's complement of the PIM message, excluding the data portion of the Register message.
PIMv2 Hello Message Format
PIMv2 Hello messages, the format of which is illustrated in Figure 5-63, are used for neighbor discovery and neighbor keepalives. The messages are sent every 30 seconds by default, and the period can be changed with the command ip pim query-interval.
The fields for the PIMv2 Hello message are defined as follows:
Option Type specifies the type of option in the Option Value field. Presently, only Option Type 1 is used. This specifies that the Option Value field is a holdtime. Values 2 through 16 are reserved. Option Length specifies the length, in bytes, of the Option Value field. When the Option Value is a holdtime (Option Type = 1), the Option Length is 2. Option Value is a variable-length field carrying the value of whatever option is specified by the Option Type. Holdtime (Option Type = 1, Option Length =2) is the time that a router waits to hear a Hello message from a PIM neighbor before declaring the neighbor dead. The holdtime is 3.5 times the Hello interval.
The format shows that multiple option TLVs (type/length/value) can be carried in a single Hello message.
PIMv2 Register Message Format
Register messages, the format of which is illustrated in Figure 5-64, used only by PIM-SM, are unicast from the source's DR to the RP, and they carry the initial multicast packets from the source. That is, Register messages are used to tunnel multicast traffic from the source to the RP when an SPT has not yet been established from the source's DR to the RP.
The fields for the PIMv2 Register message are defined as follows:
Checksum, in Register messages, is calculated only on the message header. The data packet portion is excluded. B is the Border bit. The bit is set to 0 if the originator is a DR with a directly connected source. The bit is set to 1 if the source is a PIM Multicast Border Router (PMBR). PMBRs, and other interdomain multicast issues, are discussed in Chapter 7. N is the Null-Register bit. A DR that is probing the RP before expiring its local Register-Suppression timer sets this bit to 1. Multicast Data Packet is a single packet from the source that is being tunneled to the RP in the Register message.
PIMv2 Register Stop Message Format
The Register Stop message, the format of which is illustrated in Figure 5-65, is sent by an RP to a DR originating Register messages. The packet is used in one of two situations:
The RP is receiving the sourced multicast packets over the SPT and no longer needs to receive them encapsulated in Register messages. There are no group members, either directly attached or over SPTs or RPTs, for the RP to forward the packets to.
The fields for the PIMv2 Register Stop message are defined as follows:
Encoded Group Address is the multicast group IP address for which the receiver should stop sending Register messages. Encoded Unicast Source Address is the IP address of the multicast source. This field can also specify the wildcard source for (*, G) entries by setting the address to all zeros.
PIMv2 Join/Prune Message Format
Join/Prune messages, the format of which is illustrated in Figure 5-66, are sent upstream to either RPs or sources and are used to join and prune both RPTs and SPTs. The message consists of a list of one more multicast groups. For each multicast address, there is a list of one or more source addresses. Together, these lists specify all (S, G) and (*, G) entries to be joined or pruned.
The fields for the PIMv2 Join/Prune message are defined as follows:
Encoded Unicast Upstream Neighbor Address is the IP address of the RPF or upstream neighbor to which the message is being sent. Number of Groups specifies the number of multicast groups contained in the message. Encoded Multicast Group Address specifies an IP address of a multicast group. Number of Joined Sources specifies the number of Encoded Joined Source Addresses listed under this multicast group address. Number of Pruned Sources specifies the number of Encoded Pruned Source Addresses listed under this multicast group address. Encoded Joined Source Address specifies the source address for an (S, G) pair or a wildcard for a (*, G) pair. The two wildcards in a (*, *, RP) triple (described in Chapter 7) can also be specified in this field. In addition to the source address, three flags are encoded into this field: - S is the Sparse bit. The bit is set to 1 for PIM-SM and is used for version 1 compatibility. - W is the wildcard (WC) bit. If it's set to 1, the Encoded Joined Source Address represents the wildcard in a (*, G) or (*, *, RP) entry. When it's set to 0, the Encoded Joined Source Address represents the source address in an (S, G) entry. When a join is sent to an RP, the W bit must be set to 1. - R is the RPT bit. When the bit is set to 1, the join is sent to the RP. When the bit is set to 0, the join is sent to the source.
Encoded Pruned Source Address specifies the address of a pruned source. The encoding is the same as for the Encoded Joined Source Address field, and the S, W, and R bits apply to the pruned address as they do to the joined address.
PIMv2 Bootstrap Message Format
Bootstrap messages, the format of which is illustrated in Figure 5-67, are originated by bootstrap routers (BSRs) every 60 seconds and are flooded throughout a PIM-SM domain to ensure that all routers determine the same RPs for the same groups. The message contains a list of one or more multicast group addresses. For each of these group addresses, there is a list of Candidate RPs (C-RPs) and their priorities. This list is the RP-Set for that group. Receiving routers use a common algorithm to determine, from the list of C-RPs, the RP for the group. The algorithm is designed to ensure that all routers in the PIM domain derive the same RP address. Bootstrap messages also are used to elect a BSR, as described in the section "The Bootstrap Protocol."
The fields for the PIMv2 Boostrap message are defined as follows:
Fragment Tag is used when a Bootstrap message must be divided into fragments because the message length exceeds the maximum packet size. The fragment tag is a randomly generated number that is assigned to all fragments of the same message. That is, all fragments of any unique Bootstrap message will have the same number in the Fragment Tag field. Hash Mask Length describes the mask to be used in the hash algorithm. The length of the mask is set using the ip pim bsr-candidate command. BSR Priority is a number between 0 and 255 that specifies the priority of the originating candidate BSR. The C-BSR with the highest priority becomes the BSR. This priority is set using the ip pim bsr-candidate command. Encoded Unicast BSR Address is the IP address of the domain's BSR. Encoded Group Address specifies an IP address of a multicast group. RP Count specifies the number of C-RPs listed for the given multicast group—that is, the size of the RP-Set. The description of the size of the RP-Set is important, because if the Bootstrap message is fragmented and one of the fragments is lost, the determination of the RP may become inconsistent across the PIM domain. Therefore, if the number of RPs in the received RP-Set does not match the RP count, the entire set is discarded. Fragment RP Count specifies the number of C-RPs included in this fragment for this group. Encoded Unicast RP Address is the IP address of a C-RP. RP Holdtime is the time a BSR should wait to hear a Candidate-RP-Advertisement message from a C-RP before deleting the C-RP from the RP-Set. The holdtime is 150 seconds. RP Priority is a number between 0 and 255 used in the RP selection algorithm. The "highest" priority is 0.
The PIMv2 Assert Message Format
The PIMv2 Assert message, the format of which is illustrated in Figure 5-68, is used to elect a designated forwarder on multiaccess networks. When a PIM router receives a multicast packet on an interface that is on the outgoing interface for the packet's group, the router assumes that there must be another router connected to that data link forwarding for the group. The router sends an Assert so that other routers sharing the multiaccess network can decide which of them will forward packets for the group.
The fields for the PIMv2 Assert message are defined as follows:
Encoded Group Address is the multicast IP destination address of the packet that triggered the Assert. Encoded Unicast Source Address is the IP source address of the multicast packet that triggered the Assert. Metric Preference is a preference value assigned to the unicast routing protocol that provided the route to the source. This value is used in the same way an administrative distance is used, to provide a consistent metric when comparing routes from diverse routing protocols. Metric is the metric associated with the route to the source in the originator's unicast routing table.
The PIMv2 Graft Message Format
A PIM-DM router sends a PIMv2 Graft message to its upstream neighbor to request a rejoin to a previously pruned tree. The format of the message is the same as the Join/Prune message shown in Figure 5-66, except that the Type = 6.
The PIMv2 Graft-Ack Message Format
A PIM-DM router sends a Graft-Ack message to a downstream neighbor in response to a Graft message. The format of the Graft-Ack message is the same as the Join/Prune message shown in Figure 5-66, except that the Type = 7.
The Candidate-RP-Advertisement Message Format
Candidate RPs (C-RPs) periodically unicast Candidate-RP-Advertisement messages to BSRs. The BSR uses the information in the message to build its RP-Set, which is in turn advertised to all PIM-SM routers in the domain within Bootstrap messages. Figure 5-69 shows the format of the Candidate-RP-Advertisement message.
The fields for the Candidate-RP-Advertisement message are defined as follows:
Prefix Count specifies the number of multicast group addresses included in the message. If the originator is a C-RP for all multicast groups in the domain, the Prefix Count is 0. Priority is a number between 0 and 255, specifying the priority of the originating C\_RP. This number is used in the algorithm for selecting an RP. Priorities are represented inverse to the value of the priority number; 0 is the highest priority, and 255 is the lowest. Holdtime specifies the amount of time the message is valid. Encoded Unicast RP Address is the C-RP address. This address is the IP address of one of the router's interfaces; typically, the address of a loopback interface is used. Encoded Group Address specifies one or more multicast group addresses for which the originator is a candidate RP.
|
