07-03-2019 08:35 AM
Hi All,
I have a question about SPT switchover and the role of the RP-bit set.
As far as I understand, once the SPT switchover is completed, the last hop router will send a prune message back to the shared tree.
On the upstream router where the last hop router is connected , there will be a "R" flag set and at the same time a"P" flag to tell the other routers upstream to prune traffic on the least optimized path , thus all OILs will become NULL.
However in my case it is different. I have example a pri path (where route to the RP is more preferred) and secondary path (where the route to the source is more preferred). I can verify on the secondary path (where the source of the multicast traffic is more preferred), that the S,G entries are set to T. Meaning there is a successful switchover.
However, what I see now on the routers on the primary path , that they only have the (S,G) entries flagged as "R" and not "RP".
In this case the OIL is still active (not null) and pointing to the last hop router or receiver direction , which I beleive that MC traffic is flowing on both directions now....If this is live in the network, this could mean duplicate MC traffic ?
I still expect the last hop router to send a prune message , but I am not receiving it....
What could be the reasons?
mac
Solved! Go to Solution.
07-03-2019 02:44 PM - edited 07-03-2019 02:45 PM
Hi @mac_mac_net83,
Those outputs show that Routing Table on the LHR (R8#) is pointing to R7# to reach both, the RP (11.11.11.11) and the Source of the Multicast traffic (192.168.1.2).
R8#show ip mroute 234.2.2.2 (*, 234.2.2.2), 00:14:55/stopped, RP 11.11.11.11, flags: SJCL Incoming interface: FastEthernet0/0, RPF nbr 78.78.78.7 Outgoing interface list: FastEthernet1/0, Forward/Sparse, 00:12:49/00:02:17 Loopback8, Forward/Sparse, 00:14:51/00:00:08 (192.168.1.2, 234.2.2.2), 00:11:28/00:01:18, flags: LJT Incoming interface: FastEthernet0/0, RPF nbr 78.78.78.7 Outgoing interface list: Loopback8, Forward/Sparse, 00:11:28/00:00:31 FastEthernet1/0, Forward/Sparse, 00:11:28/00:02:17
Therefore R8# is not sending PIM Prune with RP-bit set to R6#.
Use show ip rpf 11.11.11.11 and show ip route 11.11.11.11 to know the reason.
Cheers.
07-04-2019 12:19 AM - edited 07-04-2019 12:23 AM
Hello Mark,
as noted by Hector
from the point of view of the last hop router the upstream interface for the RP address 11.11.11.11 and for the source 192.168.1.2 is the same
(*, 234.2.2.2), 00:14:55/stopped, RP 11.11.11.11, flags: SJCL
>>Incoming interface: FastEthernet0/0, RPF nbr 78.78.78.7
(192.168.1.2, 234.2.2.2), 00:11:28/00:01:18, flags: LJT
>>>Incoming interface: FastEthernet0/0, RPF nbr 78.78.78.7
so R8 has no need to send an RP bit set PIM Prune message to anyone.
R8 has the same RPF neighbor 78.78.78.7 for both so it is attached to likely R7.
check with
show ip rpf 11.11.11.11
show ip route 11.11.11.11
show ip route 192.168.1.2
show ip rpf 192.168.1.2
Edit:
depending on topology R7 can have won a competition with R6 with a PIM assert message for both the RP address and the source address.
Or R7 is providing the best path to both the RP address and the source address.
Or R8 -R6 PIM neighborship is not up in their dedicated link.
Hope to help
Giuseppe
07-03-2019 11:19 AM
Hello,
in order to give you a meaningful answer, we probably need to lab your setup. Can you provide configs and topology ?
07-03-2019 12:10 PM - edited 07-03-2019 12:11 PM
Hello Mac,
can you provide the appropriate
show ip mroute G
for the
(S,G) pair of interest on the routers including last hop router and penultimate hop router ?
the setting of the RP bit on the PIM prune message is one thing that happens as soon as the first multicast packet is delivered over the shared tree Once the last hop router knows the source S address it performs an RPF check on the S address and if the RPF PIM neighbor for S address is different from RPF neighbor for the RP address the switchover to source based tree is started.
Be aware that you will see two entries
(*, G) entry for the shared tree
(S, G) entry for the source based tree
post the whole output so we can check all the possible meaning of flags.
Hope to help
Giuseppe
07-03-2019 01:21 PM
Hello Giuseppe
R8 is my last hop router....sending joins from the Loopback interface:
R8#show ip mroute 234.2.2.2
(*, 234.2.2.2), 00:14:55/stopped, RP 11.11.11.11, flags: SJCL
Incoming interface: FastEthernet0/0, RPF nbr 78.78.78.7
Outgoing interface list:
FastEthernet1/0, Forward/Sparse, 00:12:49/00:02:17
Loopback8, Forward/Sparse, 00:14:51/00:00:08
(192.168.1.2, 234.2.2.2), 00:11:28/00:01:18, flags: LJT
Incoming interface: FastEthernet0/0, RPF nbr 78.78.78.7
Outgoing interface list:
Loopback8, Forward/Sparse, 00:11:28/00:00:31
FastEthernet1/0, Forward/Sparse, 00:11:28/00:02:17
R6 and R7 are the PHRs , with R6 having the best route to the RP, while R7 , having the best route to the source...
As you can see, R7 has flagged T for the (S,G) entry, meaning R8 has swithover to the source via R7.
My expectation is that, R6 , should received a prune message from R8. But it seems it didn't. The flag remains at "R" and I believe MC traffic is flowing in R6 towards R8 as it is not pruned and OIL for the S,G entry is not Null....
R6#show ip mroute
(*, 234.2.2.2), 00:10:49/00:03:27, RP 11.11.11.11, flags: S
Incoming interface: FastEthernet2/0, RPF nbr 46.46.46.4
Outgoing interface list:
FastEthernet2/1, Forward/Sparse, 00:10:49/00:03:27
(192.168.1.2, 234.2.2.2), 00:08:35/00:02:57, flags: R
Incoming interface: FastEthernet2/0, RPF nbr 46.46.46.4
Outgoing interface list: FastEthernet1/0, Forward/Sparse, 00:01:01/00:03:16
R7#show ip mroute 234.2.2.2
(*, 234.2.2.2), 00:13:17/00:03:21, RP 11.11.11.11, flags: S
Incoming interface: FastEthernet2/1, RPF nbr 67.67.67.6
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:13:17/00:03:21
(192.168.1.2, 234.2.2.2), 00:11:00/00:02:21, flags: T
Incoming interface: FastEthernet2/0, RPF nbr 57.57.57.5
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:11:00/00:03:21
07-03-2019 02:44 PM - edited 07-03-2019 02:45 PM
Hi @mac_mac_net83,
Those outputs show that Routing Table on the LHR (R8#) is pointing to R7# to reach both, the RP (11.11.11.11) and the Source of the Multicast traffic (192.168.1.2).
R8#show ip mroute 234.2.2.2 (*, 234.2.2.2), 00:14:55/stopped, RP 11.11.11.11, flags: SJCL Incoming interface: FastEthernet0/0, RPF nbr 78.78.78.7 Outgoing interface list: FastEthernet1/0, Forward/Sparse, 00:12:49/00:02:17 Loopback8, Forward/Sparse, 00:14:51/00:00:08 (192.168.1.2, 234.2.2.2), 00:11:28/00:01:18, flags: LJT Incoming interface: FastEthernet0/0, RPF nbr 78.78.78.7 Outgoing interface list: Loopback8, Forward/Sparse, 00:11:28/00:00:31 FastEthernet1/0, Forward/Sparse, 00:11:28/00:02:17
Therefore R8# is not sending PIM Prune with RP-bit set to R6#.
Use show ip rpf 11.11.11.11 and show ip route 11.11.11.11 to know the reason.
Cheers.
07-04-2019 12:19 AM - edited 07-04-2019 12:23 AM
Hello Mark,
as noted by Hector
from the point of view of the last hop router the upstream interface for the RP address 11.11.11.11 and for the source 192.168.1.2 is the same
(*, 234.2.2.2), 00:14:55/stopped, RP 11.11.11.11, flags: SJCL
>>Incoming interface: FastEthernet0/0, RPF nbr 78.78.78.7
(192.168.1.2, 234.2.2.2), 00:11:28/00:01:18, flags: LJT
>>>Incoming interface: FastEthernet0/0, RPF nbr 78.78.78.7
so R8 has no need to send an RP bit set PIM Prune message to anyone.
R8 has the same RPF neighbor 78.78.78.7 for both so it is attached to likely R7.
check with
show ip rpf 11.11.11.11
show ip route 11.11.11.11
show ip route 192.168.1.2
show ip rpf 192.168.1.2
Edit:
depending on topology R7 can have won a competition with R6 with a PIM assert message for both the RP address and the source address.
Or R7 is providing the best path to both the RP address and the source address.
Or R8 -R6 PIM neighborship is not up in their dedicated link.
Hope to help
Giuseppe
07-04-2019 09:22 AM
07-04-2019 02:15 AM - edited 07-04-2019 02:00 PM
Hello
@mac_mac_net83 wrote:
R8#show ip mroute 234.2.2.2
(*, 234.2.2.2), 00:14:55/stopped, RP 11.11.11.11, flags: SJCL
Incoming interface: FastEthernet0/0, RPF nbr 78.78.78.7
Outgoing interface list:
FastEthernet1/0, Forward/Sparse, 00:12:49/00:02:17
Loopback8, Forward/Sparse, 00:14:51/00:00:08
(192.168.1.2, 234.2.2.2), 00:11:28/00:01:18, flags: LJT
Incoming interface: FastEthernet0/0, RPF nbr 78.78.78.7
Outgoing interface list:
Loopback8, Forward/Sparse, 00:11:28/00:00:31
FastEthernet1/0, Forward/Sparse, 00:11:28/00:02:17
As you can see, R7 has flagged T for the (S,G) entry, meaning R8 has swithover to the source via R7.
Is the SPT path the same as the RP due to incomplete route path ?
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