Chapter 7 - Protocol Independent Multicast - Sparse Mode

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