All things related to multicast

[Yuri Kolomiyets <>]

Pekka Savola wrote:
> Do you mean that it works for a while and then stops (the first 
> timeout) or that it doesn't work to begin with?
I just retested with SPT disabled on both HP and Cisco. By disabled i 
mean I added  "ip pim spt-threshold infinity" on the Cisco side. and "no 
spt-threshold" to the router pim part of the HP.

Here's the behaviour i'm seeing:

Source still joins shows up in the SPT on Cisco.

(10.0.3.2, 239.255.100.100), 00:01:09/00:02:52, flags: PT
 Incoming interface: Vlan30, RPF nbr 0.0.0.0
 Outgoing interface list: Null

When receiver joins behind HP router, here's what i'm seeing:

*Mar  4 03:04:50.815: PIM(0): Received v2 Join/Prune on 
GigabitEthernet1/0/24 from 10.0.0.2, to us
*Mar  4 03:04:50.815: PIM(0): Join-list: (*, 239.255.100.100), RPT-bit 
set, WC-bit set, S-bit set
*Mar  4 03:04:50.815: PIM(0): Add GigabitEthernet1/0/24/10.0.0.2 to (*, 
239.255.100.100), Forward state, by PIM *G Join
*Mar  4 03:04:50.815: PIM(0): Add GigabitEthernet1/0/24/10.0.0.2 to 
(10.0.3.2, 239.255.100.100), Forward state, by PIM *G Jon


Then it works until the first timeout, and then stops and never resumes 
again. The trace shows:

*Mar  4 03:05:50.810: PIM(0): Received v2 Join/Prune on 
GigabitEthernet1/0/24 from 10.0.0.2, to us
*Mar  4 03:05:50.810: PIM(0): Join-list: (*, 239.255.100.100), RPT-bit 
set, WC-bit set, S-bit set
*Mar  4 03:05:50.810: PIM(0): Update GigabitEthernet1/0/24/10.0.0.2 to 
(*, 239.255.100.100), Forward state, by PIM *G Join
*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

> If the latter, the problem might also be in Cisco and you might want 
> to check out that RPT state exists on Cisco and it's sending out the 
> traffic to HP on the RPT state.  If it does do that, then I guess HP 
> just doesn't know to handle the traffic/RPT state and the ball is 
> clearly on their court?
>
> If the former, it's likely that the problems are in HP.  There are 
> probably many, the first of which is why is RPT join failing to 
> refresh in a timely manner.  As Marshall hinted, one may have to check 
> out if IGMP membership reports / timeouts coincide with that (i.e., if 
> the DR loses IGMP state, it'll prune or not refresh the state), though 
> I suppose that shouldn't be a problem in this particular case.
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?

--
Yuri Kolomiyets

Network Services
Information Systems & Technology
University of Waterloo

E-mail: 

Phone: (519) 888-4567 x36999