Cisco Multicast Routing & Switching

Chapter 7: Protocol Independent Multicast-Sparse Mode  
  Overview  
  Protocol Independent Multicast-Sparse Mode (PIM-SM) is similar to PIM-DM in that both protocols depend on the underlying unicast routing protocol for determining RPF interfaces. A sparse mode protocol is assumed to operate in an environment where the multicast sources and multicast receivers are not closely located, so the distribution of PIM-SM nodes is sparse. This does not imply that PIM-SM cannot be used in a LAN environment but implies that sparse mode protocols operate more efficiently over Wide Area Networks (WAN). Dense mode protocols, on the other hand, use a broadcast and prune methodology, whereas multicast routers assume everyone wants to receive multicast traffic. Under this model, traffic from a multicast source is sent on all downstream interfaces until an interface is pruned from the multicast tree. An interface has a limited prune time, after which the interface is grafted back onto the multicast delivery tree and multicast traffic is again flooded onto the network.  
  Sparse mode protocols use an explicit join model in which multicast traffic is only forwarded onto an interface if receivers downstream have joined the group. Dense mode protocols, however, use source trees that are dynamically created for each source using the Reverse Path Forwarding (RPF) technique. PIM-SM uses shared trees for the delivery of multicast traffic. A shared tree contains a central point to which all senders of a particular multicast group send their traffic (see Figure 7-1). Each sender routes traffic along the shortest path to the central point, which then distributes the traffic to all receivers of the group along the shortest path. The group central point in PIM-SM is referred to as the Rendezvous Point (RP). Multiple RPs can exist in a network, but there should only be one RP for a particular multicast group.  
   
  Figure 7-1: PIM-Sparse Mode shared delivery tree  
  Figure 7-2 actually contains three source-based trees, depending on how you look at it. Assume the RP is the receiver of the multicast traffic; the paths from routers A and B are the source-based trees because the traffic flows along the shortest path given by the RPF interfaces. Now assume the RP is the sender of the multicast traffic. The path to every receiver in the group from the RP is again the shortest path tree. When these three trees are combined, you have the shared tree of PIM-SM. The combination of these trees is not necessarily the shortest path between the senders and the receivers, as can be seen in Figure 7-2. In the figure, we have the same network topology as in Figure 7-1, except now we are running PIM-DM instead of PIM-SM. Thus, two source trees follow the shortest path from each sender to each receiver.  
   
  Figure 7-2: PIM-Dense Mode source delivery trees  
  You may be thinking, what s the point? Why not use the source-based trees instead of the shared tree because the shared tree is not the optimum path? This question can be answered in two ways. The first answer is that PIM-SM has a mechanism that allows the last hop router, the one with directly attached receivers, to join the source tree and leave the shared tree. This process is called shortest path tree (SPT) switchover. The decision to switchover is based on configured thresholds that we will examine later in the chapter. The second answer is sparse mode routers do not maintain as much state information as dense mode routers, making the maintenance of state more efficient.  
  Another question that has probably come to mind concerns the RP. How do the routers know where the RP is? A brief answer is that there are three ways for routers to know the location of the RP. The first way is to manually configure the address of the RP on each router that is running PIM-SM. The other two ways are dynamic and depend on the version of PIM-SM that is being employed in the network. PIM-SM version one has a mechanism called Auto-RP and PIM-SM version 2 uses candidate RP advertisements. We will see later how to configure all three methods. For now, we will assume that all the PIM-SM routers know the location of the RP. As with PIM-DM, the trees are constructed by using the routes in the unicast routing table. As we have seen in the previous chapter, the shared tree may not always be the same for a different unicast routing protocol.
PIM-SM Protocol Operation  and Neighbor Discovery  
  PIM-SM version 1 packets are encapsulated in IGMP packets, as shown in Figure 7-3. PIM-SM packets have a common header that contains a code identifying the PIM-SM message type and the PIM mode: dense, sparse, or sparse-dense (see Figure 7-4). The message types are listed in Table 7-1 and neighbor discovery or router query messages are identified as type 0 (see Figure 7-5); the modes for PIM query messages are displayed in Table 7-2. Router query messages are used to discover neighbors that are attached to a common network. Discover may be a misleading term, however, because there is not an explicit neighbor list section comparable to a DVMRP neighbor discovery message.  
   
  Figure 7-3: Encapsulation of a PIM-SM version 1 packet in an IGMP datagram  
   
  Figure 7-4: PIM-SM version 1 packet header  
  Table 7-1: PIM-SM Version 1 Message Codes  
 
 
  Code  
Message Type  
 
 
 
  0  
Router Query  
 
  1  
Register  
 
  2  
Register-Stop  
 
  3  
Join/Prune  
 
  4  
RP Reachability  
 
  5  
Assert  
 
 
 
   
  Figure 7-5: PIM-SM version 1 Query Message packet format  
  Table 7-2: PIM-SM version 1 Query Message modes  
 
 
  Code  
Mode  
 
 
 
  0  
Dense Mode  
 
  1  
Sparse  
 
  2  
Sparse-Dense  
 
 
 
  A better name for a router query message could be a neighbor inform message or a PIM Hello message. When a neighbor receives a query message, the IP address of the neighbor is recorded, but there is no explicit mechanism to acknowledge that the query was received. Instead, the receiving router simply transmits its own query message that has the effect of informing other PIM-SM routers on the network of its existence.  
  When a query message is received from a neighbor, will the interface be added to the outgoing interface list as it was in PIM-DM? The answer is no. PIM-SM uses an explicit join model; having a PIM-SM neighbor on an interface is not sufficient for adding the interface to the output interface list. A downstream receiver must join a group before traffic is forwarded on the interface. For a multi-access network, such as an ethernet, the query message is sent to the all-routers multicast address, 224.0.0.2, and serves as the Designated Router (DR) election mechanism. For sparse mode PIM, the designated router only has a function if IGMP version 1 is being used. In this case, the DR becomes the IGMP querier for the network (refer to Chapter 3, Internet Group Management Protocol ). The elected DR is the PIM-SM enabled router with the highest IP address. The query process and DR election is shown in Figure 7-6. For this scenario, router C would be elected DR because it has the highest IP address on the multi-access network.  
   
  Figure 7-6: PIM-SM router query and DR election  
  The holdtime parameter in the router query message indicates how much time will elapse before this neighbor is declared dead. Subsequent router queries from a neighbor will reset this time, so the query interval must be less than the holdtime interval. The router queries act as a keep-alive mechanism to inform neighboring routers that this router is still alive and well. If PIM-SM is disabled on the interface or the router becomes disabled, then the holdtime for this router will expire on the neighboring routers. If the holdtime expires for a neighbor that was elected DR for the multi-access network, then a new DR will need to be elected.  
  PIM-SM Packet Forwarding  
  When a PIM-SM router receives the initial multicast packet from a source, the packet is flooded onto all interfaces in the output interface list (oilist). Recall that the oilist is populated with those interfaces that lead to downstream receivers which have indicated their desire to receive the traffic using IGMP. In PIM-DM, there is only one RPF interface for a particular source. With PIM-SM, there can be two RPF possibilities for a particular source, depending on whether the traffic is flowing down the shared tree or down the source tree (see Figure 7-7).  
   
  Figure 7-7: PIM-SM RPF check depends on the tree used.  
  Packet forwarding is similar to PIM-DM. If the group is in the oilist and it is not in the prune state, then the packet will be forwarded. One major difference between PIM-DM forwarding and PIM-SM forwarding is that in PIM-DM an interface is added to the oilist if a PIM-DM neighbor has been discovered on the interface or if a join has been received or forwarded from a neighbor. In PIM-SM, the interface will only be put in the list if the downstream neighbor has sent a join to this router, if there is a directly attached receiver for the group and a join has been received, or if the interface has been manually configured to join the group.  
  PIM-SM Joining  A leaf router will send a (*,G) Join message toward the RP if the leaf router has received a Join from a directly attached receiver or from a downstream neighbor. The router will forward the join to the RP along the unicast route, and each router along the path to the RP will process the Join. If a router does not have (*,G) state, then the state will be created and the Join will be sent toward the RP. If the router does have the state, then the Join message has reached the shared tree and the router does not have to do anything.  
  PIM-SM Registering  When a PIM-SM-enabled router initially receives a multicast packet from a sender, the router may or may not have the state for this source and group. A sender does not have to join the group it is sending to use IGMP. The router only needs to register with the RP using a PIM-SM register packet (see Figure 7-8).  
   
  Figure 7-8: PIM Sparse-Mode Register Packet Format  
  The Register packet is then sent as a unicast packet to the RP. The multicast packets that are received by the router directly attached to the source are encapsulated in Register messages, one per message. When the RP receives the Register message, the multicast packet will be extracted and sent down the shared tree toward the receivers. The RP will also send a (S,G) Join back toward the source in order to build the shortest path tree back to the source.  
  Once the path is established from the source to the RP, the source leaf router will begin to send multicast packets toward the RP as normal IP multicast packets. The source will also send the multicast packets encapsulated in Register messages, so the RP will receive them twice. When the RP detects that multicast packets from the source are being received as normal IP multicast packets, the RP sends a Register-Stop packet to the router directly attached to the source (see Figure 7-9).  
   
  Figure 7-9: PIM-Sparse Mode Register-Stop Packets  
  Upon reception of the Register-Stop message, the first-hop router will quit encapsulating the multicast traffic in Register messages and only send them to the RP as normal IP multicast packets. Figure 7-10 illustrates the registering process.  
   
  Figure 7-10: The PIM-SM RP Registration Process  
  PIM-SM Interface Pruning  
  When the last receiver for a group on an interface sends a version 2 IGMP Leave message or simply times out in IGMP version 1, then the router IGMP state for the group is deleted. Additionally, the interface is removed from the (*,G) and (S,G) entries on the oilist for the group G.  
  If the (*,G) state has been removed from every interface in the oilist, then a Prune message is sent up the shared tree towards the RP. If upstream routers do not have the state for the group, except on the interface on which the prune is received, then the Prune message is forwarded towards the RP. If the Prune message arrives at a router on the shared tree that still has receivers for the group on a different interface, the Prune message stops and is not forwarded toward the RP. The same procedure occurs if the router is receiving traffic on the source-based tree, instead of the shared tree. The format of the Prune/Join message is contained in Figure 7-11.  
   
  Figure 7-11: PIM Join/Prune packet format  
  The Upstream Neighbor Address is the address to which the Join/Prune packet is being sent. Its holdtime value indicates the lifetime of the Join/Prune. When a Prune is received, traffic from the source/group indicated in the Prune message is no longer forwarded onto the interface, while Join messages can be used to add a pruned interface to the oilist.  
  No Graft messages exist in PIM-SM because it is an explicit join model; Grafts instead are used in PIM-DM to add an interface back to the oilist if the interface is in the Prune state (in PIM-DM, Prune states expire and traffic is reflooded). Grafts can add an interface back in the oilist before the Prune state expires.  
  In PIM-SM, when an interface is pruned, the only way to add it back to the oilist is to use a Join message. The Mask Length (mask len) and Address Length (adr len) fields indicate the length in bytes of the mask and address for the group(s) to be pruned from the source-based delivery tree. Either the Prune list or the Join list may be empty, but a Join/Prune packet should never be sent when both the Join and Prune lists are empty. The format for the Group list is shown in Figure 7-12. The number of groups in the Group list is determined by the Number of Groups parameter in Figure 7-11.  
   
  Figure 7-12: Group list format  
  Each group is identified by the address and mask of the group to be pruned or joined. Following the Address and Mask Pair is the number of Join and Prune sources for the group. Join sources are listed first, followed by the Prune sources, and they are represented by the encoded format of Figure 7-13.  
   
  Figure 7-13: Encoded Source Address format  
  The S bit in the encoded source address format indicates whether or not this is a Sparse Mode group and should be set to 1 for Sparse Mode groups. The W bit is the wildcard bit and indicates whether the entry applies to a specific source/group (S,G), where W equals 0, or if the entry applies to all sources of the group (*,G), where W equals 1. The R bit applies to PIM-SM. Recall that in PIM-SM there can be either a source-based tree or a shared tree. The R bit indicates whether the packet is being sent toward the source (R = 0) or toward the RP (R = 1). The Len filed is the length of the source mask in bits and the source address is the IP address of the source to be joined or pruned.  
   
  Figure 7-14: Assert messages are used to prevent multiple copies of multicast traffic on a multi-access network.  
  PIM-SM Assert Message  
  To avoid duplicate multicast packets from traversing multi-access networks, PIM-SM uses the Assert message to determine a designated forwarding router for a multi-access network. Figure 7-14 demonstrates the situation that would warrant the Assert mechanism. The steps taken are as follows:  
  1.   Router A receives multicast traffic.  
  2.   Routers B and C are PIM-SM neighbors, so the multicast traffic is forwarded to routers B and C.  
  3.   Router D is a PIM-SM neighbor, so routers B and C forward the traffic onto the ethernet LAN. Assume router B transmits first. Router C receives the multicast packet on an interface that has this group in the oilist. This alerts router C to the fact that a PIM-SM neighbor on the ethernet LAN has forwarded traffic for the group.  
  4.   Router C forwards the multicast packet to routers B and D. B notices that the packet has arrived on an output interface for the group. Router D really doesn t care because this router is not forwarding traffic for the group onto the ethernet LAN. Router D has received the same multicast packet twice, a situation that needs to be eliminated.  
  If a router receives a multicast packet for which it has a state, either (S,G) or (*,G) on an outgoing interface, then the router knows that there is another router forwarding packets onto the network. For example, the serial interfaces for both routers B and C are the RPF interfaces back to the multicast source. When router A receives a packet from the source, the packet is forwarded to both routers B and C. With no other mechanism in place, both routers B and C will forward the traffic to router D, creating duplicate packets on the network. Assert messages are used to avoid this situation.  
  An Assert message also contains the group address and mask for the multicast source and the router s metric back to the source (see Figure 7-15). If both routers have an equal metric back to the source, then the router with the highest IP address becomes the forwarder for the network. The router that is not the forwarder prunes the interface.  
   
  Figure 7-15: PIM Assert packet format  
  Back in Figure 7-14, even though router D does not send Assert messages, it must listen to the Assert messages and determine which router is the designated router for the LAN. This information is necessary so that router D knows where to send Prune and Join messages for the group.  
  The Assert process is straightforward if both routers are running the same IP routing protocol. Recall that PIM-SM uses whatever protocol has been configured on the router to determine the RPF interface and the metric for the RPF interface. For the configuration in Figure 7-16, both routers on the multi-access network are running OSPF and the metrics back to the source are comparable. The OSPF metric is calculated by dividing 100,000,000 by the bandwidth of the link. The metric for the T1 link is approximately 67 and for the 28.8K link the metric is 3472. By comparing the metrics of the two links back to the source, we can easily choose the T1 link because it has a smaller metric than the 28.8K link. If different routing protocols are being utilized, then the metrics cannot be compared.  
   
  Figure 7-16: Routers B and C have comparable metrics to the source, so they can be used in an Assert message to elect the designated forwarder.  
  In Figure 7-17, router B is running OSPF and router C is running RIP. Comparing the metric back to the source for the two routers is like comparing apples and oranges. OSPF uses the speed of the interface to determine the metric and RIP uses a simple hop count. In this case, the metric preference value in the assert packet is used to determine which router will forward traffic and which router will prune the interface. Metric preference is analogous to an administrative distance for a unicast routing protocol. For example, the default administrative distance for RIP is 120 and for OSPF it is 110. Using the defaults always causes an OSPF route to be preferred over a RIP route.  
   
  Figure 7-17: Routers B and C have metrics that cannot be compared. The Assert mechanism would use the metric preference to determine the designated forwarder.  
  Metric preferences can also be configured for each unicast-routing protocol. When PIM-SM receives an Assert message for a group, the metric preference is compared to its own metric preference. If they are equal, then the metrics can be compared to determine which router will forward traffic. If the metric preference values are different, then the router with the lowest metric preference is selected as the forwarder on the network. If we assign a lower metric value for OSPF than for RIP, then the routers on the multi-access network in Figure 7-17 will select the OSPF router to forward traffic, and the RIP router will prune its interface for the group.  
  PIM-SM Version 2  
  PIM-SM version 2 is specified in RFC 2362, June 1998. In this section, we will examine the differences between PIM-SM versions 1 and 2. The first major change is that version 2 messages are no longer encapsulated in IGMP messages but are encapsulated in IP packets with protocol number 103 (see Figure 7-18). PIM-SM version 2 messages are sent to the multicast group 224.0.0.13, ALL-PIM-ROUTERS.  
   
  Figure 7-18: Encapsulation of a PIM-SM version 2 packet in an IP datagram  
  The PIM-SM version 2 packet header has been modified from the version 1 packet header (see Figure 7-19). The types of messages identified in the packet header, along with the version 1 types, are listed in Table 7-3. As you can see, there have been a few modifications from Table 7-1.  
   
  Figure 7-19: PIM-SM version 2 packet header format  
  Table 7-3: PIM versions 1 and 2 message types  
 
 
  Type  
Description Version 2  
 
Description Version 1  
 
 
 
  0  
Hello  
 
Router query  
 
  1  
Register (Sparse mode)  
 
Same  
 
  2  
Register-Stop (Sparse mode)  
 
Same  
 
  3  
Join/Prune  
 
Same  
 
  4  
Bootstrap (Sparse mode)  
 
RP Reachability (Sparse mode)  
 
  5  
Assert  
 
Same  
 
  6  
Graft (Dense mode)  
 
Same  
 
  7  
Graft-Ack (Dense mode)  
 
Same  
 
  8  
Candidate RP advertisement  
 
Type not used  
 
 
 
  The router query message that was used as the Neighbor Discovery mechanism in version 1 has been replaced by the Hello message, shown in Figure 7-20.  
   
  Figure 7-20: PIM-SM Version 2 Hello message format  
  The Option fields for the Hello message are listed in Table 7-4 and the values of the holdtime in Table 7-5.  
  Table 7-4: Hello message Option fields  
 
 
  Option Type  
Option Length  
 
Option Value  
 
 
 
  1  
2  
 
Hold time  
 
  2 16  
Reserved  
 
Reserved  
 
 
 
  Table 7-5: Hello message holdtime values  
 
 
  Value  
Description  
 
 
 
  0xFFFF  
No time out  
 
  0  
Immediate time out  
 
  Any other value  
Neighbor time out value  
 
 
 
  A timeout value of 0xFFFF means that the neighbor never expires. This value has the affect of preventing periodic Hello messages being sent and is useful on a tariff connection, such as ISDN. Periodic Hellos would keep the link active, even in the absence of user data traffic, but you may not be happy receiving an ISDN bill for nothing more than periodic Hello traffic. A holdtime of zero signifies that the neighbor should immediately time out.  
  The Prune/Join message format has been modified, as shown in Figure 7-21. The encoded unicast and multicast address formats are shown in Figures 7-22 and 7-23.  
   
  Figure 7-21: PIM version 2 Join/Prune packet format  
   
  Figure 7-22: PIM version 2 encoded unicast address format  
   
  Figure 7-23: Encoded Group address format  
  Encoding value is 0 and represents the native encoding for the address family (see Table 7-6). Further encoded address examples are shown in Figures 7-23 and 7-24. Figure 7-25 displays the PIM-SM version 2 Assert message format.  
  Table 7-6: Address Family Assignments  
 
 
  Number  
Description  
 
 
 
  0  
Reserved  
 
  1  
IP Version 4  
 
  2  
IP Version 6  
 
  3  
NSAP  
 
  4  
HDLC (*-bit multidrop)  
 
  5  
BBN 1822  
 
  6  
802  
 
  7  
E.163  
 
  8  
E.164 (SMDS, Frame Relay, ATM)  
 
  9  
F.69 (Telex)  
 
  10  
X.121 (X.25, Frame Relay)  
 
  11  
IPX  
 
  12  
AppleTalk  
 
  13  
DECnet IV  
 
  14  
Banyan Vines  
 
  15  
E.164 with NSAP format subaddress  
 
 
 
   
  Figure 7-24: Encoded Source address  
   
  Figure 7-25: PIM-SM version 2 Assert message format  
   
  Figure 7-26: Static RP assignment. Only leaf routers need to be configured with the address of the RP.  
  The Rendezvous Point Where Is It?  
  We assumed in all of the previous examples that the RP was configured and that the routers knew where it was. In this section, we will look at how this is accomplished. There are three methods that can be used to configure the RP. The first method is a static method and it requires configuring each leaf-designated router with the address of the RP for a group or range of groups. Leaf routers are those routers that have directly connected multicast sources or receivers (see Figure 7-26).  
  If the static RP method and one of the two dynamic RP methods are utilized simultaneously, the dynamic method takes precedence unless the static method is configured to take precedence, as we shall see when we look at the actual router configuration commands. Routers that may become designated routers in case the primary designated router fails need to be configured with the RP address. All the leaf routers in the PIM-SM domain are told where the RP is except for the RP itself! The RP is expected to deduce that it is the RP.  
  PIM version 1 uses a dynamic technique developed by Cisco called Auto-RP. Although one or more routers are statically configured as RPs, non-RP routers do not need to be configured with the address of the RPs. Configured RPs send RP announcements through all PIM-enabled interfaces with a configured TTL value that limits the scope of the announcement. These announcements are sent to the CISCO-RP-ANNOUNCE multicast group with address 224.0.1.39 and are received by an RP mapping agent, shown in Figure 7-27, which can also be the RP. This agent then sends the RP-to-group mappings to the group CISCO-RP-DISCOVERY (224.0.1.40). PIM-SM enabled routers listen to this group to determine the RP-to-group mappings (see Figure 7-28).  
   
  Figure 7-27: Rendezvous points send RP announcements that are received by the mapping agent.  
   
  Figure 7-28: Mapping agents send RP-to-group mappings that are received by PIM-SM-enabled routers.  
  The mapping agent does not seem to be necessary when there is only one RP in the PIM-SM domain, but if there are multiple RPs and the groups are announcing overlap, the mapping agent determines which router will be the RP for which groups. The mapping agent then distributes this information throughout the PIM-SM domain.  
  In PIM version 2 RP, information is disseminated using Bootstrap messages (see Figure 7-29).  
   
  Figure 7-29: PIM-SM Version 2 Bootstrap message format  
  Fragment Tag  
  A randomly generated number that is used to identify fragments. Fragment tags with the same value are from the same Bootstrap message.  
 
  HML  
  Hash Mask Length. The length of the mask to use in the Hash function.  
 
  BSR-priority  
  The Bootstrap router (BSR) priority of the included BSR.  
 
  Encoded Unicast BSR Address  
  The address of the Bootstrap router for the domain.  
 
  RP Count  
  The number of candidate RP addresses in the message for the corresponding group prefix.  
 
  Frag RP C  
  The number of candidate RP addresses in this fragment.  
 
  Encoded Unicast RP Address  
  The address of the candidate RPs for the corresponding group prefix.  
 
  RP Priority  
  The priority if the RP. Highest is 0.  
 
  The PIM-SM domain has a bootstrap router responsible for originating bootstrap messages. These messages are used to elect a BSR if needed (see Figure 7-30) and to distribute RP information that is sent to the multicast group ALL PIM ROUTERS (224.0.0.13). One or more routers are configured as candidate BSRs and the BSR candidate with the highest configured priority will be elected as the Bootstrap router (BSR). If all the priorities are equal, then the candidate BSR with the highest IP address will be elected, while another set of routers will be configured as candidate RPs. Usually the routers that are configured as candidate BSRs are also configured as candidate RPs, which will periodically send Candidate RP Advertisement messages to the elected BSR (see Figure 7-31). Candidate RP Advertisements are also sent to the BSR unicast address (see Figure 7-32).  
   
  Figure 7-30: Each candidate BSR sends Bootstrap messages that are used to elect the BSR.  
   
  Figure 7-31: Candidate RPs send RP announcements to the Bootstrap router.  
   
  Figure 7-32: PIM-SM version 2 Candidate RP advertisement  
  Prefix Count  
  Number of encoded group addresses in the message.  
 
  Priority  
  The priority of the RP for the encoded group address. Zero is highest.  
 
  Holdtime  
  The amount of time this advertisement is valid.  
 
  Encoded Unicast RP Address  
  The address of the candidate RP.  
 
  The Candidate RP advertisements contain the address of the Advertising Candidate RP as well as the groups that can be serviced by the candidate RP. The BSR periodically transmits this information throughout the domain and the PIM-SM routers receive and store it (see Figure 7-33). When a receiver joins a group using IGMP, the router maps the group address to one of the RPs and each candidate BSR sends Bootstrap messages that are used to elect the BSR.  
   
  Figure 7-33: The BSR collects RP announcements, determines the RP to group mappings, and disseminates the RP information throughout the network.  
  SPT Switchover  
  A threshold on a leaf router can be configured that, when exceeded, will cause the router to switch from the shared tree through the RP to the source tree. When PIM-SM is enabled, the default threshold is 0 kbps. This means that when the first packet is received from a multicast source, the router switches from the shared tree to the source tree. The threshold can be configured from 0 to infinity. A setting of infinity prevents the router from ever switching to the source tree.  
  The traffic for the group G from any source S is measured once each second. If the threshold is exceeded, then set a flag for (*,G) to remember that the threshold was exceeded. When the next packet for G arrives from any source, if the threshold exceeded flag is set, then clear the flag in (*,G), set the flag in (S,G), and switch to the source tree for that particular source. Again, every second the state of the flag is in (S,G) will be checked and if the traffic rate is less than the threshold, then switch back to the shared tree. The advantages of switching to the source tree is that traffic is being received on the shortest path tree. The shortest path tree will generally have a lower latency than the shared tree. The disadvantage is that (S,G) state will have to be maintained in the router. In other words, there is more detail that has to be maintained.
PIM-SM Router Configuration Commands  
  PIM-SM is more complicated to configure than PIM-DM because an RP is required for each group. One RP can handle all groups, which can be spread across multiple RPs. The first step is to enable multicast routing in Global Configuration mode using the command  
  ip multicast-routing  
  Next, enable PIM-SM on the router interfaces using the interface command  
  ip pim sparse-mode  
  or  
  ip pim sparse-dense-mode  
  PIM-Sparse-Dense-Mode is used when there are groups with no RP. In this case, groups with an assigned RP are treated as Sparse Mode groups, and groups without an RP are treated as Dense Mode groups.  
  Rendezvous Point Configuration and Static RP Configuration  
  There is not a default RP and one or more must be configured using one of the three methods. For the static case, the RP does not need to be configured, only the leaf routers. To configure the static RP, use the global configuration command  
  ip pim rp-address ip-address [access-list-number] [override]  
  ip-address  
  ip address of the RP  
 
  group-access-list-number  
  Optional. Standard IP access list number, 1 100. If no access list is used, then the RP can handle all groups. Use an access list to limit the groups that the RP will service.  
 
  override  
  Optional. If there is a conflict between the static RP and one configured using Auto-RP, then the static RP takes precedence.  
 
  For example, to configure an RP that handles all groups, use  
  ip pim rp-address 172.16.1.1  
  where 172.16.1.1 is the address of the RP. If we want the RP to only handle a subset of multicast groups, then an access list is needed. If the RP is to handle only group 239.252.1.1, then we would use the following commands:  
  ip pim rp-address 172.16.1.1 1  
  access-list 1 permit 239.252.1.1 0.0.0.0  
  If the RP is to service the groups 239.252.1.0 through 239.252.1.255, then the access list would contain  
  access-list 1 permit 239.252.1.0 0.0.0.255.  
  Auto-RP Configuration  
  For Auto-RP, the RPs and a mapping agent need to be configured. The RPs are configured using the Global Configuration command:  
  ip pim send-rp-announce interface-type interface-number scope ttl  
  group-list access-list-number  
  interface-type interface-number  
  The address of the specified interface is used to identify the RP.  
 
  scope  
  TTL value of the announcements. Limits the distance an RP announcement can travel.  
 
  access-list-number  
  An access-list determines the groups that the RP is announcing that it can service.  
 
  The router sends RP announcements on all PIM-enabled interfaces for a maximum number of hops specified by the scope parameter. The announcements are sent to the group CISCO-RP-ANNOUNCE (224.0.1.39). To enable the RP to announce all multicast groups, use the command below.  
  ip pim send-rp-announce ethernet 0 scope 30 group-list 2  
  access-list 2 permit 224.0.0.0 15.255.255.255  
  The next step in configuring Auto-RP is to configure the RP mapping agent using the global command  
  ip pim send-rp-discovery scope ttl  
  TTL of the Discovery messages. Used to limit the scope of the message.  
  The router configured as a mapping agent will listen for RP announcements to group CISCO-RP-ANNOUNCE (224.0.1.39). The RP mapping agent then sends the RP-to-group mappings to the group CISCO-RP-DISCOVERY (224.0.1.40), and PIM routers get their RP information from the Discovery messages.
PIM-SM Version 2 RP Selection  
  One or more BSRs need to be configured in the domain using the global configuration command:  
  ip pim bsr-candidate interface-type interface-number hash-mask-length [priority]  
  interface-type interface-number  
  The address of the specified interface will be used to identify the BSR.  
 
  hash-mask-length  
  Length of the mask (32 bits maximum) that is ANDed with the group address before the hash function is called. All groups with the same seed correspond to the same RP. If the value is 24, then only the first 24 bits of the group address are used. Therefore, one RP can have multiple groups.  
 
  priority  
  Optional. Value from 0 to 255. The BSR candidate with the largest priority is preferred. If BSR candidates have the same priority, the one with the highest IP address is elected as the BSR.  
 
  This command causes the router to send Bootstrap messages to PIM neighbors. When a Bootstrap message is received, the priority and address of the message are compared to the previous message. If they are the same, then the message is forwarded. If the received message has a lower priority, or if the priority is the same but the IP address is lower, the message is discarded. Otherwise, the address and priority are cached and the message is forwarded.  
  After the bootstrap router(s) are configured, then the RP routers are configured using the global command:  
  ip pim rp-candidate interface-type interface-number [group-list access-list-number]  
  The address of the specified interface will be used to identify the candidate RP.  
  Optional. Standard IP access list used to determine the groups that the candidate RP advertises  
  To configure a candidate RP that will advertise any multicast group starting with 227, the following command can be used:  
  ip pim rp-candidate serial 1 group-list 51  
  access-list 51 permit 227.0.0.0 0.255.255.255  
  The PIM-SM domain can be divided into BSR subdomains with their own configured BSRs. If you do not want BSR messages to cross domains, use the interface configuration command  
  ip pim border  
  When this command is used, no Bootstrap messages can pass through the router in either direction, but other PIM messages can pass through the router.  
  By default, a router will accept all Join and Prune messages. A router can be configured to accept Joins or Prunes for specified groups for a specified RP. The command used to accomplish this filtering is the global command:  
  ip pim accept-rp {address | auto-rp} [access-list-number]  
  address  
  Address of the RP.  
 
  auto-rp  
  Messages are accepted only for RPs that are in the Auto-RP cache.  
 
  access-list-number  
  Optional. Defines the groups that are allowed.  
 
  This command causes the router to accept only Join and Prune messages destined for the specified RP. If an access list is used, then the group must also be allowed by the list. If the address in the command is an address on the receiving router, then the router is the RP and it will accept messages only for the groups specified. If the group is not allowed by the access list, then the router will respond immediately to Register messages with Register-Stop messages. For example, to configure a router to accept Join and Prune messages for the RP whose ID is 172.16.1.1 related to groups 225.0.0.0 through 225.255.255.255, use the command  
  ip pim accept-rp 172.16.1.1 8  
  access-list 8 permit 225.0.0.0 0.255.255.255  
  RP mapping agents can be configured to filter Auto-RP announcements using the global configuration command:  
  ip pim rp-announce-filter rp-list access-list-number group-list access-list-number  
  rp-list access-list-number  
  Standard access list of RP addresses from which Auto-RP announcements will be accepted.  
 
  group-list access-list-number  
  Standard access list of group addresses that will be accepted.  
 
  For example, to configure an RP mapping agent to accept Auto-RP announcements from the RP with address 172.16.1.1 for all multicast groups, use  
  ip pim rp-announce-filter rplist 12 group-list 13  
  access-list 12 permit 172.16.1.1  
  access-list 13 permit 224.0.0.0 15.255.255.255  
  The PIM version can be configured using the interface configuration command  
  ip pim version [1 | 2]  
  If an interface is configured for version 2 (the default) and a PIM version 1 neighbor is discovered on the interface, then the router automatically switches to PIM version 1. If the PIM version 1 neighbors somehow vanish, the router switches the interface back to PIM version 2.  
   
  Figure 7-34: Example network for static RP configuration. Only the leaf routers need to be configured with the address of the RP.  
  be adjusted using the interface command:  
  ip pim query-interval seconds  
  seconds  
  1 65535 seconds  
 
  The following command changes the PIM query interval to 60 seconds:  
  interface Serial 0  
  ip pim query-interval 60  
  PIM-SM SPT-Switchover is controlled by the global configuration command:  
  ip pim spt-threshold {kbps | infinity} [group-list access-list-number]  
  kbps  
  Traffic rate in kilobits per second.  
 
  infinity  
  The specified groups will use the shared-tree.  
 
  group-list access-list-number  
  Optional. Determines which groups to apply the threshold.  
 
  By default, a PIM-SM router sends periodic Join/Prune messages every 60 seconds. To alter this interval, use the global configuration command  
  ip pim message-interval seconds  
  seconds  
  Value in the range 1 to 65535  
 
  All PIM-SM-enabled routers should be configured with the same message interval time. A router will be pruned from a group if a Join message is not received in the message interval. The default value is three minutes.  
  Example of an PIM-SM Network  
  The networks that follow will be configured for PIM-SM and each of the RP configuration methods (see Figure 7-34). This network will be used to illustrate complete router configurations and the information that can be gathered using PIM Show and Debug commands.  
  Network 1 Static RP Router Configurations  
  Router A  
  hostname A  
  ip multicast-routing  
  interface Ethernet 0  
  ip address 172.16.1.1 255.255.255.0  
  ip pim sparse-mode  
  interface Serial 0  
  ip address 172.16.2.1 255.255.255.0  
  ip pim sparse-mode  
  clock rate 1540000  
  interface Serial 1  
  ip address 172.16.3.1 255.255.255.0  
  ip pim sparse-mode  
  clock rate 1540000  
  router eigrp 100  
  network 172.16.0.0  
  ip pim rp-address 172.16.2.2  
     
  Router B  
  hostname B  
  ip multicast-routing  
  interface Ethernet 0  
  ip address 172.16.4.1 255.255.255.0  
  ip pim sparse-mode  
  interface Serial 1  
  ip address 172.16.3.2 255.255.255.0  
  ip pim sparse-mode  
  router eigrp 100  
  network 172.16.0.0  
  ip pim rp-address 172.16.2.2  
  Router C  
  hostname C  
  ip multicast-routing  
  interface Ethernet 0  
  ip address 172.16.4.2 255.255.255.0  
  ip pim sparse-mode  
  interface Serial 1  
  ip address 172.16.5.2 255.255.255.0  
  ip pim sparse-mode  
  clock rate 1540000  
  router eigrp 100  
  network 172.16.0.0  
  ip pim rp-address 172.16.2.2  
     
  Router RP  
  hostname RP  
  ip multicast-routing  
  interface Serial 0  
  ip address 172.16.2.2 255.255.255.0  
  ip pim sparse-mode  
  interface Serial 1  
  ip address 172.16.5.1 255.255.255.0  
  ip pim sparse-mode  
  router eigrp 100  
  network 172.16.0.0  
  Use the command show ip pim rp to verify that the routers have learned the location of the RP.  
  show ip pim rp [group-name | group-address | mapping]  
  group-name  
  Optional. Show RPs for the named group.  
 
  group-address  
  Optional. Show RPs for the group with the entered group address.  
 
  mapping  
  Optional. Display all group to RP mappings.  
 
  A#show ip pim rp  
  Group: 224.0.1.40, RP: 172.16.2.2, next RP-reachable in 00:01:11  
  The operation of PIM can be verified and monitored using the debug command, debug ip pim.  
  Aadebug ip pim  
  PIM debugging is on  
  08:31:16: PIM: Received v2 Hello on Serial1 from 172.16.2.1  
  08:31:16: PIM: Received v2 Hello on Serial0 from 172.16.5.2  
  08:31:16: PIM: Send v2 Hello on Serial0  
  08:31:26: PIM: Send v2 Hello on Serial1  
  08:31:30: PIM: Received v2 Join/Prune on Serial1 from 172.16.2.1, to us  
  08:31:30: PIM: Join-list: (*, 224.0.1.40) RP 172.16.2.2, RPT-bit set, WC-bit set, S-bit set  
  08:31:30: PIM: Add Serial1/172 .16.2.1 to (*, 224.0.1.40), Forward state  
  08:31:39: PIM: Received v2 Join/Prune on Serial0 from 172.16.5.2, to us  
  08:31:39: PIM: Join-list: (*, 224.0.1.40) RP 172.16.2.2, RPT-bit set, WC-bit set, S-bit set  
  08:31:39: PIM: Add Serial0/172 .16.5.2 to (*, 224.0.1.40), Forward state  
  08:31:40: PIM: Building Join/Prune message for 224.0.1.40  
  08:31:46: PIM: Received v2 Hello on Serial1 from 172.16.2.1  
  08:31:46: PIM: Received v2 Hello on Serial0 from 172.16.5.2  
  08:31:46: PIM: Send v2 Hello on Serial0  
  08:31:56: PIM: Send v2 Hello on Serial1  
  08:32:16: PIM: Received v2 Hello on Serial1 from 172.16.2.1  
  08:32:16: PIM: Received v2 Hello on Serial0 from 172.16.5.2  
  08:32:16: PIM: Send v2 Hello on Serial0  
  Network 2 Auto-RP Configuration  
  Auto-RP  Router Configurations  
  Router MA  
  hostname MA  
     
  ip multicast-routing  
  interface Ethernet 0  
  ip address 172.16.1.1 255.255.255.0  
  ip pim sparse-mode  
  interface Serial 0  
  ip address 172.16.2.1 255.255.255.0  
  ip pim sparse-mode  
  clock rate 1540000  
  interface Serial 1  
  ip address 172.16.3.1 255.255.255.0  
  ip pim sparse-mode  
  clock rate 1540000  
  router eigrp 100  
  network 172.16.0.0  
  ip pim send-rp-announce  
     
     
  Router B  
     
  hostname B  
     
  ip multicast-routing  
  interface Ethernet 0  
  ip address 172.16.4.1 255.255.255.0  
  ip pim sparse-mode  
  interface Serial 1  
  ip address 172.16.3.2 255.255.255.0  
  ip pim sparse-mode  
  router eigrp 100  
  network 172.16.0.0  
     
  Router C  
  hostname C  
     
  ip multicast-routing  
  interface Ethernet 0  
  ip address 172.16.4.2 255.255.255.0  
  ip pim sparse-mode  
  interface Serial 1  
  ip address 172.16.5.2 255.255.255.0  
  ip pim sparse-mode  
  clock rate 1540000  
  router eigrp 100  
  network 172.16.0.0  
     
     
  Router RP  
     
  hostname RP  
     
  ip multicast-routing  
  interface Serial 0  
  ip address 172.16.2.2 255.255.255.0  
  ip pim sparse-mode  
  interface Serial 1  
  ip address 172.16.5.1 255.255.255.0  
  ip pim sparse-mode  
  router eigrp 100  
  network 172.16.0.0  
  ip pim send-rp-announce scope 16 group-list 1  
  access-list 1 permit 224.0.0.0 15.255.255.255  
     
  For the network of Figure 7-35, show the RP mappings on the mapping agent and on the RP router.  
   
  Figure 7-35: PIM-SM using Auto-RP.  
  MA#show ip pim rp mapping  
  PIM Group-to-RP Mappings  
  This system is an RP-mapping agent  
     
  Group(s) 224.0.0.0/4  
  RP 172.16.5.1 (?), v2v1  
    Info source: 172.16.5.1 (?), via Auto-RP  
     Uptime: 00:15:06, expires: 00:02:53  
     
     
  RP#show ip pim rp mapping  
  PIM Group-to-RP Mappings  
  This system is an RP (Auto-RP)  
     
  Group(s) 224.0.0.0/4  
  RP 172.16.5.1 (?), v2v1  
    Info source: 172.16.2.1 (?), via Auto-RP  
     Uptime: 00:17:18, expires: 00:02:33  
  Verify the Auto-RP operation with the debug ip pim:  
  RP#debug ip pim auto-rp  
  PIM Auto-RP debugging is on  
     
  08:46:19: Auto-RP: Received RP-discovery, from 172.16.2.1, RP_cnt 1, holdtime 18  
  0 secs  
  08:46:19: Auto-RP: update (224.0.0.0/4 , RP:172.16.5.1), PIMv2 v1  
  08:46:19: Auto-RP: Build RP-Announce packet for 172.16.5.1, PIMv2/v1  
  08:46:19: Auto-RP: Build announce entry for (224.0.0.0/4 )  
  08:46:19: Auto-RP: Send RP-Announce packet, IP source 172.16.5.1, ttl 16 holdtime 181 secs  
  08:47:19: Auto-RP: Received RP-discovery, from 172.16.2.1, RP_cnt 1, holdtime 180 secs  
  08:47:19: Auto-RP: update (224.0.0.0/4 , RP:172.16.5.1), PIMv2 v1  
  08:47:19: Auto-RP: Build RP-Announce packet for 172.16.5.1, PIMv2/v1  
  08:47:19: Auto-RP: Build announce entry for (224.0.0.0/4 )  
  08:47:19: Auto-RP: Send RP-Announce packet, IP source 172.16.5.1, ttl 16 holdtime 181 secs  
     
     
  MA#debug ip pim auto-rp  
  PIM Auto-RP debugging is on  
     
  08:47:53: Auto-RP: Build RP-Discovery packet  
  08:47:53: Auto-RP: Build mapping (224.0.0.0/4 , RP:172.16.5.1), PIMv2 v1,  
  08:47:53: Auto-RP: Send RP-discovery packet (1 RP entries)  
  08:47:53: Auto-RP: Received RP-discovery, from ourselves (172.16.1.1), ignored  
  08:47:53: Auto-RP: Received RP-announce, from 172.16.5.1, RP_cnt 1, holdtime 181 secs  
  08:47:53: Auto-RP: update (224.0.0.0/4 , RP:172.16.5.1), PIMv2 v1  
  08:48:52: Auto-RP: Build RP-Discovery packet  
  08:48:52: Auto-RP: Build mapping (224.0.0.0/4 , RP:172.16.5.1), PIMv2 v1,  
  08:48:52: Auto-RP: Send RP-discovery packet (1 RP entries)  
  08:48:52: Auto-RP: Received RP-discovery, from ourselves (172.16.1.1), ignored  
  08:48:53: Auto-RP: Received RP-announce, from 172.16.5.1, RP_cnt 1, holdtime 181 secs  
  08:48:53: Auto-RP: update (224.0.0.0/4 , RP:172.16.5.1), PIMv2 v1  
  Network 3 Using Bootstrap Routers  
  BSR-RP  Router Configurations  
  Router BSR1  
  hostname BSR1  
  ip multicast-routing  
  interface Ethernet 0  
  ip address 172.16.1.1 255.255.255.0  
  ip pim sparse-mode  
  interface Serial 0  
  ip address 172.16.2.1 255.255.255.0  
  ip pim sparse-mode  
  clock rate 1540000  
  interface Serial 1  
  ip address 172.16.3.1 255.255.255.0  
  ip pim sparse-mode  
  clock rate 1540000  
  router eigrp 100  
  network 172.16.0.0  
  ip pim bsr-candidate serial 0 24 8  
     
     
  Router RP1  
  hostname RP1  
  ip multicast-routing  
  interface Ethernet 0  
  ip address 172.16.4.1 255.255.255.0  
  ip pim sparse-mode  
  interface Serial 1  
  ip address 172.16.3.2 255.255.255.0  
  ip pim sparse-mode  
  router eigrp 100  
  network 172.16.0.0  
  ip pim rp-candidate ethernet 0  
  Router BSR2  
  hostname BSR2  
  ip multicast-routing  
  interface Ethernet 0  
  ip address 172.16.4.2 255.255.255.0  
  ip pim sparse-mode  
  interface Serial 1  
  ip address 172.16.5.2 255.255.255.0  
  ip pim sparse-mode  
  clock rate 1540000  
  router eigrp 100  
  network 172.16.0.0  
  ip pim bsr-candidate ethernet 0 24 8  
     
     
  Router RP2  
  hostname RP2  
  ip multicast-routing  
  interface Serial 0  
  ip address 172.16.2.2 255.255.255.0  
  ip pim sparse-mode  
  interface Serial 1  
  ip address 172.16.5.1 255.255.255.0  
  ip pim sparse-mode  
  router eigrp 100  
  network 172.16.0.0  
  ip pim rp-candidate serial 0  
     
  Two candidate Bootstrap routers have been configured in the network of Figure 7-36. Router BSR2 should be elected for this because its IP address is higher than BSR2. To view the BSR, use the show ip pim bsr command.  
   
  Figure 7-36: PIM-SM RP selection using Bootstrap routers.  
  rp1ashow ip pim bsr-router  
  PIMv2 Bootstrap information  
  BSR address:172.16.4.2 (?)  
  Uptime:00:06:46, BSR Priority: 8, Hash mask length: 24  
  Expires:00:01:43  
  Next Cand_RP_advertisement in 00:00:35  
  RP: 172.16.5.1(Serial0)  
  PIM-SM Bootstrap Border Router  A PIM-SM network can be divided into regions that are serviced by a regional Bootstrap router. Bootstrap messages can then be confined to a region by configuring a border router that does not allow Bootstrap messages from passing through the router, but the router will forward all other PIM traffic. The interface command used to configure a Bootstrap border router is  
  ip pim border  
  An example of the use of the border command is shown in Figure 7-37.  
   
  Figure 7-37: PIM-SM Bootstrap border router  
  Border Configuration  
  interface Serial 0  
  ip pim sparse-mode  
  ip pim border  
     
  interface Serial 1  
  ip pim sparse-mode  
  ip pim border  
  References  
  RFC 2362, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, 1998  
  RFC 2117, Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification, D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, 1997  
 
 
Related

Категории