I have a question regarding the PIM RPT to SPT switchover . A PIM DR router configured for sparse mode tries to swithover to SPT if the source if the multcast is reachable via a better path rather than going through the RP. What would happen in a situation where the source is origination the multicast using ist secondary address which is not routed but is only advertised in its multcast streams and as a result the receivers althogh they see this address cannot reach the source and switchover to SPT.
From my understanding, when you are using PIM-Sparse Mode, and a Multicast Source initiates a Multicast Stream, when the Multicast Receiver, receives the first multicast packet, it initiates a SPT Switchover by default. So it will send a PIM (S,G) Join towards the souce, and once the tree is built, the PIM DR of the Multicast Receiver, will send a PIM Prune to the RP, and from the RP to the source.
Now if the multicast stream is started from a secondary IP address, which is not routable to the rest of the network, that is a very good question. I'm assuming, since the First-Hop router(DR) of the segment on the Multicast Source, will encapsulate the multicast packets in unicast, and make it to the RP, so if the RP, doesn't know how to get to the Multicast souce to create a SPT from the RP to the Multicast Source this would not work.
Thanks for your reply and what you say makes perfect sense and thats what I believe too. What confused me was we had a new multicast setup (Triple Play for IPTV) where the source originating the traffic was sending the multicast stream using the sync interface between itself and the seconday interface. Surprisingly the RP which should ideally do an RPF check for the source whenever it receives a register message did have the (S,G) entry for the non routed source for that group. Unfortunately it happened when I was not in office and could not check myself. I'll try to replicate this if possible and get back.
Another interesting observation, I tried to replicate this in GNS by making a router a host which would source the traffic and by assigning a loopback address to it which would act as the secondary address. What was weird was when I ping a unicast address with the loopback as source the source address in the captures would correctly be seen as the loopback address as intended and not the physical address . But when I ping a multicast address with the loopback as the source the captures show the source as the physical interface not the loopback, I have no idea why that would happen, anyone who's seen this happen and know whats could be the reason ?
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...