05-23-2015 05:29 AM - edited 03-08-2019 12:09 AM
R1, R2, R3, R4, R5 are all running PIM Sparse.
R3 is the RP.
Server, R6, and Host1 are not powered on.
R2 is the only Router with a Prune Flag for (*, 224.0.1.40).
R1#show ip mroute (*, 224.0.1.40), 00:04:15/00:02:49, RP 10.0.0.3, flags: SJCL Incoming interface: FastEthernet3/0, RPF nbr 10.2.2.3 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:04:06/00:02:44 FastEthernet0/0, Forward/Sparse, 00:04:14/00:02:49 R2#show ip mroute (*, 224.0.1.40), 00:48:25/00:02:42, RP 10.0.0.3, flags: SJPL Incoming interface: FastEthernet2/0, RPF nbr 10.2.1.1 Outgoing interface list: Null R3#sh ip mroute (*, 224.0.1.40), 00:26:00/00:03:09, RP 10.0.0.3, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet3/0, Forward/Sparse, 00:25:56/00:03:09 FastEthernet1/0, Forward/Sparse, 00:25:57/00:02:30 Loopback0, Forward/Sparse, 00:25:59/00:02:02 R4#sh ip mroute (*, 224.0.1.40), 00:27:46/00:02:20, RP 10.0.0.3, flags: SJCL Incoming interface: FastEthernet1/0, RPF nbr 10.2.4.3 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:26:05/00:02:37 Loopback0, Forward/Sparse, 00:27:45/00:02:20 R5#sh ip mroute (*, 224.0.1.40), 00:34:25/00:02:44, RP 10.0.0.3, flags: SJCL Incoming interface: FastEthernet2/0, RPF nbr 10.2.6.4 Outgoing interface list: FastEthernet1/0, Forward/Sparse, 00:26:20/00:03:02 FastEthernet0/0, Forward/Sparse, 00:34:24/00:02:01
How does PIM Sparse decide that it is best to Prune/Null FastEthernet0/0 on R2?
Solved! Go to Solution.
05-26-2015 03:46 AM
If you want R2 to become DR for 10.2.3.0/24 network, then you can change DR priority with "ip pim dr-priority" interface command.
Probably you mixing RP and SP trees. RPT's top point is in RP and circle should be broken at 10.2.3.0/24 segment. And SPT top node might be source server.
05-26-2015 02:28 AM
Any...one...?
05-26-2015 03:46 AM
If you want R2 to become DR for 10.2.3.0/24 network, then you can change DR priority with "ip pim dr-priority" interface command.
Probably you mixing RP and SP trees. RPT's top point is in RP and circle should be broken at 10.2.3.0/24 segment. And SPT top node might be source server.
05-26-2015 04:19 AM
Yeah... but my question is more on... how did that happen?
Did they send some packet that goes one round and find that the best place to prune is between R2 & R5?
Or does it got to do with the IGP Route from each router to the RP?
By the way, you mentioned about changing the DR.
If I were to change the DR on 10.2.3.0/24 to R2, does that mean that R5 will Prune its interface instead of R2 pruning its interface?
05-26-2015 07:02 AM
Andrew,
I am not entirely sure what is going on but I do have a couple of remarks and observations.
The 224.0.1.40 group is the RP-DISCOVERY group for AutoRP. Mapping agents send their group-to-RP mappings to this group, and every other AutoRP-compatible router in the network joins this group to learn the resulting group-to-RP mappings.
In your previous thread here, R2 was the mapping agent. Is R2 by any choice a mapping agent again here? If so, it could explain what you see: As a mapping agent, R2 is not interested in learning the group-to-RP mappings, quite the contrary - R2 is going to create and propagate those mappings in the first place. That is perhaps why the group is shown as pruned with an empty OIL (outgoing interface list). If R2 needs to send a periodic group-to-RP mapping to the RP-DISCOVERY group again, I would personally believe it is going to do it via a PIM-Register message toward the RP although I have frankly never analyzed the AutoRP process in the presence of an already known RP in detail. Because I like open solutions better, I consider BSR to be, in many ways, superior to AutoRP.
But this is what we should truly investigate in detail: How are AutoRP messages (announcements from RP-candidates, group-to-RP mappings from mapping agents) delivered across a network when an RP is already known? Are the 224.0.1.39 (RP-ANNOUNCE) and 224.0.1.40 (RP-DISCOVERY) strictly dense mode? I doubt that, as the output from other routers show that the RP-DISCOVERY group is being treated in sparse mode with the RP nicely identified as 10.0.0.3.
Best regards,
Peter
05-26-2015 07:32 AM
How are AutoRP messages (announcements from RP-candidates, group-to-RP mappings from mapping agents) delivered across a network when an RP is already known? Are the 224.0.1.39 (RP-ANNOUNCE) and 224.0.1.40 (RP-DISCOVERY) strictly dense mode?
It travels in dense mode. And it is up to router to decides which group-rp map to pick up. No? I always hoped this is how it is going.
- See more at: https://supportforums.cisco.com/discussion/12515281/how-does-pim-sparse-decide-which-interface-prune#comment-1052675605-26-2015 01:23 PM
Hi,
It travels in dense mode.
Actually, I have made a small experiment with routers preconfigured both for sparse mode and sparse-dense mode, and I have preconfigured them with a static address of an RP (recall that on IOS, automatic RP discovery takes precedence to the statically configured RP). In both cases, the mapping agent did just what I expected: It used the PIM-Register message to encapsulate its group-to-RP mapping message to send it to the RP. When the RP created an SPT toward the mapping agent, subsequent messages were delivered over the SPT. This is sparse-mode delivery, not dense mode.
So in fact, the delivery of the AutoRP messages is performed according just to the same rules of operation as any other ordinary multicast traffic:
And it is up to router to decides which group-rp map to pick up.
I am not sure about the precise meaning of this comment. It does not seem to describe the AutoRP operation, however. In AutoRP, mapping agents are responsible for both collecting the list of candidate RPs and the groups they are willing to serve, and for making the final group-to-RP assignments. These final assignments are then advertised from mapping agents to all routers in the network. If multiple mapping agents are present, only the one having the highest source IP will continue operating as the mapping agent, all other routers configured to act as mapping agents will suppress their mapping agent functionality until the current mapping agent dies.
Perhaps you are confusing this with the BSR functionality. In this mechanism, indeed, it is up to individual routers to make their own (albeit globally consistent) assignment of groups to candidate RPs. The bootstrap routers (similar to mapping agents in AutoRP) merely collect the list of all candidate RPs and the groups they would like to serve but they do not do the final group-to-RP assignment.
Best regards,
Peter
05-26-2015 02:31 PM
Hi Peter,
This thread is unrelated to the other thread.
And all routers have static Rendezvous Point configured using "ip pim rp-address 10.0.0.3".
This can be seen from the Flag: S - Sparse
The configurations might not be clean, there might be some other configurations during the time of capture, but I can't remember.
Clearly it can be seen that the link furthest from the RP (10.2.3.0/24), is being prune.
All I can think of is that it might have to do with IGP.
None of the Routers RIB to the 10.0.0.3 goes through that link.
It might be the reason on why it is being prune, but I can't be sure.
Another thing is that why was it prune on R2's end and not R5's end.
Might be because the pruning was done on the non-DR end, as the DR for that link is R5.
But then again, this is just a hypothesis.
05-26-2015 02:52 PM
Okay... I've just confirmed that the Pruning is done on non-DR's end.
I used AMediaFilm "ip pim dr-priority" and here's the results.
R2#show ip mroute (*, 224.0.1.40), 00:01:00/00:02:57, RP 10.0.0.3, flags: SJPL Incoming interface: FastEthernet2/0, RPF nbr 10.2.1.1 Outgoing interface list: Null R5#show ip mroute (*, 224.0.1.40), 00:03:27/00:02:20, RP 10.0.0.3, flags: SJCL Incoming interface: FastEthernet2/0, RPF nbr 10.2.6.4 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:03:27/00:02:20 R2#show ip pim interface Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 10.2.3.2 FastEthernet0/0 v2/S 1 30 1 10.2.3.5 10.2.1.2 FastEthernet2/0 v2/S 1 30 1 10.2.1.2 R2(config)#interface FastEthernet0/0 R2(config-if)#ip pim dr-priority 2 *May 27 05:22:45.599: %PIM-5-DRCHG: DR change from neighbor 10.2.3.5 to 10.2.3.2 on interface FastEthernet0/0 R2(config-if)#do show ip pim interface Address Interface Ver/ Nbr Query DR DR Mode Count Intvl Prior 10.2.3.2 FastEthernet0/0 v2/S 1 30 2 10.2.3.2 10.2.1.2 FastEthernet2/0 v2/S 1 30 1 10.2.1.2 R2(config-if)#do sh ip mroute (*, 224.0.1.40), 00:01:57/00:02:49, RP 10.0.0.3, flags: SJCL Incoming interface: FastEthernet2/0, RPF nbr 10.2.1.1 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:00:10/00:02:49 R5(config)#do sh ip mroute (*, 224.0.1.40), 00:06:12/00:02:22, RP 10.0.0.3, flags: SJPL Incoming interface: FastEthernet2/0, RPF nbr 10.2.6.4 Outgoing interface list: Null
05-26-2015 02:52 PM
Okay.
I've also confirmed that the pruning is based on the Routes in the RIB.
R2(config-if)#no ip pim dr-priority 2 *May 27 05:31:25.195: %PIM-5-DRCHG: DR change from neighbor 10.2.3.2 to 10.2.3.5 on interface FastEthernet0/0 R5#show ip mroute (*, 224.0.1.40), 00:14:28/00:02:06, RP 10.0.0.3, flags: SJCL Incoming interface: FastEthernet2/0, RPF nbr 10.2.6.4 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:00:05/00:02:54 R5#show ip route 10.0.0.3 Routing entry for 10.0.0.3/32 Known via "eigrp 1", distance 90, metric 158720, type internal Redistributing via eigrp 1 Last update from 10.2.6.4 on FastEthernet2/0, 00:00:02 ago Routing Descriptor Blocks: * 10.2.6.4, from 10.2.6.4, 00:00:02 ago, via FastEthernet2/0 Route metric is 158720, traffic share count is 1 Total delay is 5200 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2 R5(config)#interface FastEthernet2/0 R5(config-if)#delay 100 R5#show ip route 10.0.0.3 Routing entry for 10.0.0.3/32 Known via "eigrp 1", distance 90, metric 161280, type internal Redistributing via eigrp 1 Last update from 10.2.3.2 on FastEthernet0/0, 00:00:01 ago Routing Descriptor Blocks: * 10.2.3.2, from 10.2.3.2, 00:00:01 ago, via FastEthernet0/0 Route metric is 161280, traffic share count is 1 Total delay is 5300 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 3 R5#show ip mroute (*, 224.0.1.40), 00:16:22/00:02:16, RP 10.0.0.3, flags: SJPCL Incoming interface: FastEthernet0/0, RPF nbr 10.2.3.2 Outgoing interface list: Null
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide