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?

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:

• If RP is preconfigured on routers then the AutoRP traffic (224.0.1.39, 224.0.1.40) is delivered in sparse mode. It does not matter whether the routers are configured for pure sparse mode or for combined sparse-dense mode because in both these cases, the RP is already known.
• If no RP is preconfigured on routers then the AutoRP traffic is delivered in dense mode provided that the routers are configured for sparse-dense mode. If the routers are configured for pure sparse mode, no AutoRP traffic will be delivered unless either a static RP is configured on all routers or the ip pim autorp listener is configured (in which case, however, specifically the AutoRP traffic reverts to dense mode flooding even though the routers are configured for pure sparse mode).

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

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.

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

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