Chapter 6 - Protocol Independent Multicast - Dense Mode

Chapter 6: Protocol Independent Multicast Dense Mode

	Overview

	Protocol Independent Multicast-Dense Mode (PIM-DM) is similar to Distance Vector Multicast Routing Protocol (DVMRP) in a number of ways. Both are referred to as dense mode protocols. A dense mode protocol operates in an environment where the multicast sources and multicast receivers are located in the same area, such as a local area network (LAN). Dense mode protocols also assume that bandwidth is not a limiting factor. Both protocols operate using a broadcast and prune methodology where 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. Both protocols create source-based delivery trees that connect each specific multicast source with each downstream receiver. Source trees are dynamically created for each source using the Reverse Path Forwarding (RPF) technique. The major difference between DVMRP and PIM-DM is that DVMRP uses a built-in multicast routing protocol while PIM-DM relies on the configured unicast routing protocol. This means that you can use any of the IP routing protocols (RIP, IGRP, EIGRP, or OSPF) with PIM-DM.

	PIM-DM is independent of the IP routing protocol chosen to run on your network, hence the name, Protocol Independent Multicast. This also means that in the same network DVMRP and PIM could possibly construct divergent source based delivery trees as shown in Figures 6-1, 6-2, and 6-3. In Figure 6-1, DVMRP is being used as the multicast routing protocol. Since DVMRP builds routing tables based on RIP, the source based tree for the network in Figure 6-1 would be through the 28.8K connections since this path offers a lower hop count than the path through the T1 connections.

	Figure 6-1: DVMRP source-based tree

	In Figure 6-2, OSPF is the unicast routing protocol which has a metric based on the link speed and not the hop count. In this case, the shortest path from the receiver to the source is through the T1 connections instead of the 28.8K connections. Figure 6-3 shows that PIM-DM is independent of the unicast routing protocol in the sense that it doesn t matter which unicast routing protocol is used since PIM-DM will still operate. Figure 6-3 does show that PIM-DM is, in some ways actually, dependent on the selected unicast routing protocol since the source based delivery tree can be different depending on the protocol used.

	Figure 6-2: PIM-DM source-based tree in an OSPF environment

	Figure 6-3: PIM-DM source-based tree in an RIP environment

PIM-DM Version 1, Protocol Operation

	The source based trees that are constructed in a PIM-DM environment are created in the same manner as DVMRP as shown in Figure 6-4.

	In Figure 6-4, router A receives a multicast packet from the source and examines the source IP address of the packet to see if the packet was received on the Reverse Path Forwarding (RPF) interface. The RPF interface is used to send a unicast packet back to the source. Becasuse the source is directly attached to router A, the interface is the RPF.

	Figure 6-4: Dynamically created source-based trees

	Router A then floods the packet on all interfaces except for the interface on which the packet was received. When router B receives the packet from router A, router B will determine if the packet was received on the RPF interface for the particular source. The packet passes the RPF test and so the packet is forwarded to router C and receiver 1. Router C performs the same RPF on the packet and forwards the packet to router B and receiver 2. When B receives the packet from C and C receives the packet from B, the RPF test fails since the packet was not received on the interface that is on the shortest path back to the source. The packet is then discarded. If we take a close look at Figure 6-4, we can see that we have a source tree for each receiver that connects each receiver to the source.

	The RPF interface is selected by examining the IP routing table, an example of which is given in Listing 6-1. From the sample routing table, we can determine the RPF interface for any multicast source. Remember that the multicast source is a unicast class A, B, or C address and not a multicast class D address. For example, if the router receives a multicast packet on the serial 1 interface from the source 130.10.9.1, should the packet be forwarded? By examining the routing table in Listing 6-1 we find that the unicast route back to 130.10.9.1 is through interface serial 0 so the packet did not arrive on the RPF interface. For this case, the multicast packet would be dropped and no further processing would occur. We can determine the RPF interface for each known source network by examining the routing table. Each route listed contains a forwarding interface, which is also the RPF interface. How would the router handle multicast traffic from sources not in the routing table? For this situation the default route would be used.

	Listing 6-1: Example Cisco router IP routing table

	Codes: C_ _connected, S_ _static, I_ _IGRP, R_ _RIP, M_ _mobile, B_ _BGP

     D_ _EIGRP, EX_ _EIGRP external, O_ _OSPF, IA_ _OSPF inter area

     E1_ _OSPF external type 1, E2_ _OSPF external type 2, E_ _EGP

     i_ _IS-IS, L1_ _IS-IS level21, L2_ _IS-IS level22, *_ _candidate default

Gateway of last resort is not set

I130.10.128.0 255.255.255.0 [100/1115174 ] via 130.10.11.3, 00:00:40, Serial1

C130.10.252.0 255.255.255.0 is directly connected, Loopback0

I130.10.253.0 255.255.255.0 [100/265657 ] via 130.10.11.3, 00:00:40, Serial1

I130.10.246.0 255.255.255.0 [100/1115611 ] via 130.10.11.3, 00:00:40, Serial1

O130.10.8.0 255.255.255.0 [110/2641 ] via 130.10.5.5, 00:12:29, Serial0

O IA 130.10.9.0 255.255.255.0 [110/5268 ] via 130.10.5.5, 00:12:29, Serial0

C130.10.10.0 255.255.255.0 is directly connected, Ethernet0

C130.10.11.0 255.255.255.0 is directly connected, Serial1

I130.10.12.0 255.255.255.0 [100/1115111 ] via 130.10.11.3, 00:00:41, Serial1

I130.10.13.0 255.255.255.0 [100/265257 ] via 130.10.11.3, 00:00:41, Serial1

O IA 130.10.251.251 255.255.255.255 [110/5263 ] via 130.10.5.5, 00:12:33, Serial0

O IA 130.10.250.250 255.255.255.255 [110/2632 ] via 130.10.5.5, 00:12:33, Serial0

O 130.10.5.5 255.255.255.255 [110/2631 ] via 130.10.5.5, 00:12:33, Serial0

O 130.10.5.1 255.255.255.255 [110/5262 ] via 130.10.5.5, 00:12:33, Serial0

C 130.10.5.0 255.255.255.0 is directly connected, Serial0

O IA 130.10.100.0 255.255.255.192 [110/2632 ] via 130.10.5.5, 00:00:13, Serial0

I 193.10.10.0 [100/1115174 ] via 130.10.11.3, 00:00:45, Serial1

Neighbor Discovery

	PIM-DM version 1 packets are encapsulated in Internet Group IGMP packets as shown in Figure 6-5. PIM-DM packets have a common header (see Figure 6-6) which contains a code identifying the PIM-DM message type and the PIM mode, dense, sparse or sparse-dense. The message types are listed in Table 6-1 and neighbor discovery or router query messages (see Figure 6-7) are identified as type 0 (see Table 6-2). Router query messages are used to discover neighbors that are attached to a common network. Discovery may be a misleading term since there is not an explicit neighbor list section comparable to a DVMRP neighbor discovery message.

	Figure 6-5: Encapsulation of a PIM-DM version 1 packet in an IGMP datagram

	Figure 6-6: PIM-DM version 1 packet header

	Table 6-1: PIM-DM version 1 Message Codes

	Code

Message Type

	0

Router Query

	1

Register (Sparse Mode)

	2

Register-Stop (Sparse Mode)

	3

Join/Prune

	4

RP Reachability (Sparse Mode)

	5

Assert

	6

Graft

	7

Graft-ACK

	Table 6-2: PIM-DM version 1 Query Message Modes

	Code

Mode

	0

Dense Mode

	1

Sparse

	2

Sparse-Dense

	Figure 6-7: PIM-DM version 1 Query Message packet format

	A better name for a router query message could be a neighbor inform message. When a neighbor receives a query message, the IP address of the neighbor is recorded. No explicit mechanism acknowledges that the query was received. Instead, the receiving router will simply transmit its own query message that has the effect of informing other PIM-DM routers on the network of its existence. When a query message is received from a neighbor, the interface is added to the outgoing interface list. The outgoing interface list is used to determine which interfaces the PIM-DM router should forward multicast traffic. Of course, if there are no other PIM-DM routers on the network, the interface would be added to the outgoing list if there are receivers requesting traffic for a particular multicast group. 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 dense 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 (see Chapter 3). The elected DR is the PIM-DM enabled router with the highest IP address. The query process and DR election is shown in Figure 6-8. For this scenario, router C is elected DR since it has the highest IP address on the multi-access network.

	Figure 6-8: PIM-DM 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-DM is disabled on the interface or the router actually crashes and burns, 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-DM Packet Forwarding

	When a PIM-DM 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 on which neighbors were discovered or on interfaces that have multicast receivers that have indicated their desire to receive the traffic using IGMP. Figure 6-9 shows the various possibilities for forwarding of multicast traffic. Router A has discovered a PIM-DM neighbor on interface S0.

	A host has signaled that it wishes to receive multicast traffic for a particular group. The host doesn t care where the multicast traffic originates, so any packets for this group from any source reaching router A will be forwarded to the host on E0.

	Figure 6-9: PIM-DM packet forwarding

	No PIM-DM neighbors or multicast receivers have been found on interface S1 so the oilist for this interface will be null. The oilist for the ethernet interface will contain the state (*,G) indicating that router A should forward traffic for group G from any source onto the ethernet interface. The oilist for the S0 interface will contain the state (S,G) indicating that router A should forward multicast traffic for group G from source S to router C. Traffic will also be forwarded if the interface has been manually configured to receive traffic. Traffic is forwarded using the RPF technique, which you will recall, only accepts packets on the interface on the shortest path back to the source. For DVMRP this is generally unambiguous since each DVMRP router runs the same routing protocol. PIM-DM uses whatever IP routing protocol has been configured on the router to determine the RPF technique. We will see how to deal with situations involving a network running more than one IP routing protocol.

	Interface States

	The oilist for a router interface can be null or in the (*,G) or (S,G) state. An interface can also be in both the (S,G) and (*,G) states. In Figure 6-10, router A has PIM-DM enabled on all interfaces. When the host attaches to the E1 interface of router A, it will join the multicast group 224.0.18.10 by sending an IGMP join message to router A. Router A will add the entry (*,224.0.18.10) to the E1 interface, indicating that multicast traffic for group 224.0.18.10 from any source should be sent onto the ethernet interface. The same (*,G) state can exist in more than one oilist. Input interfaces for a multicast group will have (S,G) state and the same (S,G) state will not exist on more than one interface since a router can only have one best path back to a multicast source. The input interface is the interface over which a router expects to receive multicast traffic from a specific source. This interface is simply the RPF interface.

	Figure 6-10: Router state is (*,G) when a receiver joins a multicast group.

	In Figure 6-11, router A receives a multicast packet from the source 172.16.1.2 for group 224.0.18.10. Router A creates the (S,G) state for the serial interface since a PIM-DM neighbor has been discovered on this interface. If the serial interface on router A is not on the shortest path back to the source for the downstream router, the interface will be pruned.

	Figure 6-11: Routers maintain (S,G) state for multicast sources

	In Figure 6-12, we have two sources for the multicast group 224.0.18.10. Router A has a host which has joined this group using IGMP. Router A will accept traffic on interface S1 from the source 172.16.3.2, from router B and on interface S0 from the source 172.16.1.2, and from router C because these are the RPF interfaces for the respective sources. The oilist for the serial interface on router B will contain the (S,G) state (172.16.3.2,224.0.18.10). The serial interface on router C will contain the (S,G) state (172.16.1.2,224.0.18.10).

	Figure 6-12: Each multicast source will have (S,G) state on the directly attached router.

PIM-DM Interface Pruning

	When the oilist for a particular interface becomes null, there are no downstream PIM-DM routers or multicast receivers attached to the network. The interface does not need to transmit multicast traffic and can, therefore, be pruned from the source-based delivery tree. In Figure 6-13, router A initially receives multicast traffic from the source and floods the traffic onto all interfaces in the oilist. Router B is a PIM-DM-enabled router, but has no attached downstream PIM-DM routers or mulitcast receivers. Router B will send a prune message to its upstream router for this particular multicast source. When router A receives the prune from router B, router A s oilist for the serial link will become null, halting the forwarding of multicast traffic to router B.

	Figure 6-13: The pruning of a PIM-DM interface

	The packet format used for Prune, Join, or Graft messages is illustrated in Figure 6-14.

	Figure 6-14: PIM Join/Prune Packet Format

	The Upstream Neighbor Address is where the Join/Prune packet is sent. For the network in Figure 6-13, router B sends the message to router A so the upstream neighbor address equals the IP address of router A s serial interface. The holdtime indicates the lifetime of the prune. PIM-DM is a cyclic protocol. Initially all packets are forwarded onto interfaces in the oilist. When a prune is received, traffic from the source/group indicated in the prune message no longer forwards onto the interface. The prune remains in effect until the holdtime for the prune expires. When the prune timer expires, the interface is added back to the oilist for the source group. Multicast traffic is again forwarded onto the interface. Join or graft messages can be used to add a pruned interface to the oilist before the prune holdtime expires. The mask length (mask len) and address length (adr len) fields indicate the length in bytes of the mask and the address for the group or groups to be pruned from or grafted onto 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 6-15. The number of groups in the group list is given by the Num. of Groups parameter in Figure 6-14. 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 all listed first, followed by the prune sources represented by the encoded format of Figure 6-16.

	Figure 6-15: Group List format

	Figure 6-16: 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 0 for dense mode groups. The W bit is the wildcard bit and indicates whether the entry applies to a specific source/group (S,G), W = 0 or if the entry applies to all sources of the group (*,G), W = 1. The R bit applies to PIM Sparse Mode (PIM-SM). The Len field 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.

PIM-DM Interface Grafting

	Interfaces that have been pruned from the oilist for a router inter face can be added back into the source-based tree for a multicast source using PIM-DM graft messages (see Figure 6-17). PIM-DM graft messages are the only messages that are acknowledged. The graft messages are acknowledged using the packet format shown in Figure 6-18.

	Figure 6-17: PIM Graft Packet format

	Figure 6-18: PIM Graft-Ack Packet format

	The network in Figure 6-19 will be used as an example of PIM-DM grafting. Router A is forwarding multicast traffic to router B (step 1). Since router B has no downstream PIM-DM neighbors or multicast receivers, router B sends a prune message to router A (step 2). The oilist for the S1 interface on router A is now null and a prune timer has been set using the timer value in the prune message. If a multicast receiver attached to the ethernet on router B wishes to receive traffic, an IGMP join message is sent to router B (step 3). Router B can either wait for the prune timer on router A to expire, which will cause router A to add interface S1 to the oilist for the source, or router B can send a graft message to router A (step 4). The serial interface on router A is in the prune state for the source and has a prune lifetime timer running. Router B has (S,G) and (*,G) entries for the source but these entries are in the prune state. So router B will send a graft message to router A and A will acknowledge will graft acknowledgment message (step 5).

	Figure 6-19: PIM-DM interface pruning and grafting message flow.

One very important characteristic of dense mode protocols is the prune/broadcast cycle. In Figure 6-19, if router B never had any attached receivers or downstream PIM-DM neighbors, then multicast traffic would never need to be forwarded to router B. Initially, router B will prune itself from any source-based delivery trees. Since prunes have a limited lifetime, router B would again be sent multicast traffic from router A. Router B would again send a prune to A, which would timeout, and cause A to forward to B. This triggers a prune, and so it goes. If you are certain that multicast traffic does not need to go to a particular router, then don t enable PIM-DM on the interfaces.

PIM-DM Assert Message

	To avoid duplicate multicast packets from traversing multi-access networks, PIM-DM uses assert messages to determine a designated forward for a multi-access network. Figure 6-20 demonstrates the situation that would warrant the assert mechanism. The steps of this are as follows:

	Figure 6-20: Assert messages are used to prevent multiple copies of multicast traffic on a multi-access network.

	1.		Router A receives multicast traffic.

	2.		Routers B and C are PIM-DM neighbors so the multicast traffic is forwarded to routers B and C.

	3.		Router D is a PIM-DM neighbor so routers B and C will 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 output interface list. This alerts router C to the fact that a PIM-DM 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 since 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 state, either (S,G) or (*,G), on an outgoing interface, the router knows another router is 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 contains the group address and mask for the multicast source and the router s metric back to the source (see Figure 6-21). If both routers have an equal metric back to the source, the router with the highest IP address becomes the forwarder for the network. The router that is not the forwarder will prune the interface. In Figure 6-20, router D does not send Assert messages but must listen to the Assert messages and determine which router is the designated router for the LAN. This information is necessary so router D knows where to send Prune and Graft messages for the group. The assert process is straightforward if both routers are running the same IP routing protocol. Recall that PIM-DM uses whatever protocol has been configured on the router to determine the RPF interface and the metric for the RPF interface.

	Figure 6-21: PIM Assert Packet format

	For the configuration in Figure 6-22, 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 is the T1 link, which is approximately 67, and for the 28.8K link the metric is 3,472. 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, the metrics cannot be compared.

	Figure 6-22: 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 6-23, 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 inter face to determine the metric and RIP uses a simple hop count. For 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 will always cause an OSPF route to be preferred to a RIP route.

	Figure 6-23: 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 be configured for each unicast routing protocol. When PIM-DM receives an assert message for a group, the metric preference is compared to its own metric preference. If they are equal, metrics can be compared to determine which router will forward traffic. If the metric preference values are different, the router with the lowest metric preference will be selected as the forwarder on the network. If we assign a lower metric value for OSPF than for RIP, the routers on the multi-access network in Figure 6-23 will select the OSPF router to forward traffic and the RIP router will prune its interface for the group.

PIM-DM Version 2

	PIM-DM version 2 is specified in the IETF document draft-ietf-im-v2-dm-01.txt dated November 3, 1998. In this section we will examine the differences between PIM-DM 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 (Figure 6-24). PIM-DM version 2 messages are sent to the multicast group 224.0.0.13, ALL-PIM-ROUTERS.

	Figure 6-24: Encapsulation of a PIM-DM version 2 packet in an IP datagram

	Figure 6-26: PIM-DM Version 2 Hello message format

	The PIM-DM version 2 packet header, shown in Figure 6-25, has been modified from the version 1 packet header (see Figure 6-6). The types of messages identified in the packet header along with the version 1 types are listed in Table 6-3. As you can see, there have been a few modifications from Table 6-1.

	Figure 6-25: PIM-DM version 2 packet header format

	Table 6-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 (see Figure 6-26).

	The option fields for the Hello message are listed in Table 6-4 and the values of the hold time in Table 6-5.

	Table 6-4: Hello Message Option Fields

	Option Type

Option Length

Option Value

	1

2

Hold time

	2 16

Reserved

Reserved

	Table 6-5: Hello Message Hold Time 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 times out. This value has the affect of preventing periodic hello messages from being sent. This is especially useful on a tariff connection such as an ISDN. Periodic hellos keep the link active even in the absence of user data traffic. 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 6-27 (compare to the version 1 format in Figure 6-14). The encoded unicast and multicast address formats are shown in Figures 6-28 through 6-31.

	Figure 6-27: PIM version 2 Join/Prune Packet format

	Figure 6-28: PIM version 2 encoded unicast address format

	Figure 6-29: Encoded group address format

	Figure 6-30: Encoded source address

	Figure 6-31: PIM-DM version 2 Assert message format

	Encoding value is 0 and represents the native encoding for the address family (see Table 6-6).

	Table 6-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

	The Graft and Graft Acknowledgment message formats have not changed from version 1.

PIM-DM Router Configuration

	Configuring PIM-DM on Cisco routers is a relatively simple exercise.

	Figure 6-32: Basic PIM-DM router configuration

	The first step is to enable multicast routing in global configuration mode using the command:

	ip multicast-routing

	Next, enable PIM-DM on the router interfaces using the interface command:

	ip pim dense-mode

	The router in Figure 6-32 has a basic configuration shown in the diagram. Although the configuration has EIGRP as the routing protocol, any of the IP routing protocols could have been used.

	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, the router will automatically switch to PIM version 1. If the PIM version 1 neighbors somehow go away, the router will switch the interface back to PIM version 2.

	The default interval for PIM query messages is 30 seconds. This can 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

	Monitoring and Debugging PIM Dense Mode

	The network in Figure 6-33 is configured with PIM-DM and will be used to demonstrate the PIM show and debug commands. The configurations for the routers in Figure 6-33 are listed on the following page.

	Figure 6-33: The network used to demonstrate PIM-DM show and debug commands

	Router A

ip multicast-routing

interface Ethernet 0

ip address 172.16.1.1 255.255.255.0

ip pim dense-mode

interface Serial 0

ip address 172.16.2.1 255.255.255.0

clock rate 1540000

ip pim dense-mode

interface Serial 1

ip address 172.16.3.1 255.255.255.0

clock rate 1540000

ip pim dense-mode

router eigrp 100

network 172.16.0.0

Router B

ip multicast-routing

interface Ethernet 0

ip address 172.16.4.1 255.255.255.0

ip pim dense-mode

interface Serial 1

ip address 172.16.3.2 255.255.255.0

clock rate 1540000

ip pim dense-mode

router eigrp 100

network 172.16.0.0

Router C

ip multicast-routing

interface Serial 0

ip address 172.16.2.2 255.255.255.0

ip pim dense-mode

interface Serial 1

ip address 172.16.5.1 255.255.255.0

clock rate 1540000

ip pim dense-mode

router eigrp 100

network 172.16.0.0

Router D

ip multicast-routing

interface Ethernet 0

ip address 172.16.4.2 255.255.255.0

ip pim dense-mode

interface Serial 1

ip address 176.16.5.2 255.255.255.0

clock rate 1540000

ip pim dense-mode

router eigrp 100

network 172.16.0.0

	Use the EXEC command show ip pim neighbor to view the state of the PIM interfaces on the routers.

	Bashow ip pim neighbor

	PIM Neighbor Table

	Neighbor Address

Interface

Uptime

Expires

Ver

Mode

	172.16.3.1

Serial 1

00:09:40

00:01:35

v2

Dense

	172.16.4.2

Ethernet0

00:41:57

00:01:19

v2

Dense (DR)

	The fields in the neighbor address are described below.

	Neighbor address

	IP Address of the PIM neighbor.

	Interface

	Interface on which the neighbor is attached.

	Uptime

	How long in hours, minutes, and seconds the neighbor has been in the PIM neighbor table.

	Expires

	Time to elapse before the neighbor is removed from the table in hours, minutes, and seconds.

	Mode

	PIM mode of the interface.

	(DR)

	The neighbor is the designated router on a multi-access network.

	The state of a PIM interface can be displayed using the show ip pim interface command.

	show ip pim interface [interface-type interface-number] [count]

	interface-type interface-number

	Optional. Type and number of the interface (Ethernet 0, Serial 1, etc.)

	Optional. Number of packets that have been sent and received on the interface

	B4ashow ip pim interface

	Address

Interface

Version/Mode

Nbr Count

Query Intvl

DR

	172.16.4.2

Ethernet0

v2/Dense

1

30

172.16.4.1

	172.16.3.1

Serial1

v2/Dense

1

30

0.0.0.0

	Address

	IP address of the next hop router.

	Interface

	PIM interface type and number.

	Version/Mode

	Configured PIM mode and version number for the interface.

	Neighbor Count

	Number of discovered PIM neighbors on this interface.

	Query Intvl

	Configured PIM query interval.

	DR

	Address of the designated router. Serial interfaces do not have a designated router so this field is set to 0.0.0.0.

	B#show ip pim interface count

	Address

Interface

FS

Mpackets In/Out

	172.16.4.2

Ethernet0

*

686/0

	172.16.3.1

Serial1

*

738/0

	FS

	* indicates that fast switching is enabled

	Mpackets In/Out

	Number of multicast packets sent or received on the interface.

	The operation of PIM can be verified by executing the debug ip pim command:

	Badebug ip pim

	PIM debugging is on:

	B#

08:18:03: PIM: Send v2 Hello on Ethernet0

08:18:06: PIM: Received v2 Hello on Ethernet0 from 172.16.4.2

08:18:10: PIM: Received v2 Hello on Serial1 from 172.16.3.1

08:18:16: PIM: Send v2 Hello on Serial1

08:18:33: PIM: Send v2 Hello on Ethernet0

08:18:36: PIM: Received v2 Hello on Ethernet0 from 172.16.4.2

08:18:40: PIM: Received v2 Hello on Serial1 from 172.16.3.1

08:18:46: PIM: Send v2 Hello on Serial1

	Notice that PIM queries to or from a particular neighbor are 30 seconds apart. This is the default query interval for PIM.

	References

	IETF draft, Protocol Independent Multicast Version 2 Dense Mode Specification, S. Deering et. al., 1998, draft-ietf-pim-v2-dm-01.txt