All things related to multicast

[Pekka Savola <>]

On Fri, 21 Sep 2007, Yuri Kolomiyets wrote:
> *Mar  4 03:05:50.810: PIM(0): Prune-list: (10.0.3.2/32, 239.255.100.100) 
> RPT-bit set
> *Mar  4 03:05:50.810: PIM(0): Prune GigabitEthernet1/0/24/239.255.100.100 
> from (10.0.3.2/32, 239.255.100.100) - deleted
>
> *Mar  4 03:06:50.814: PIM(0): Received v2 Join/Prune on GigabitEthernet1/0/24 
> from 10.0.0.2, to us
> *Mar  4 03:06:50.814: PIM(0): Join-list: (*, 239.255.100.100), RPT-bit set, 
> WC-bit set, S-bit set
> *Mar  4 03:06:50.814: PIM(0): Update GigabitEthernet1/0/24/10.0.0.2 to (*, 
> 239.255.100.100), Forward state, by PIM *G Join
> *Mar  4 03:06:50.814: PIM(0): Prune-list: (10.0.3.2/32, 239.255.100.100) 
> RPT-bit set
...
> So as you said, the former is the case: works till the first timeout after 
> the initial join with SPT switch disabled on HP. I'm still not sure why Cisco 
> puts it in the SPT istead of RPT since I did set the SPT threshold to 
> infinity, but I don't think that's what causing the problem.
>
> It seems to me that it's a bug in HP and instead of putting the S,G in the 
> join list with RPT-bit set, they are putting it in the prune list. Does that 
> sound about right?

Yeah, it seems HP is putting the source in Prune list with RPT bit set. 
That would be OK if the HP had joined (S,G,spt) tree first.  As it hasn't, 
I can't think of any way to justify that behaviour.  Seems like a clear 
bug in HP.

So, it seems it's basically the same problem (HP thinks it has joined SPT 
or has active SPT state but doesn't) with SPT switchover enabled or 
disabled, it's just manifesting in different ways.

Pekka