All things related to multicast

["John Zwiebel" <>]

> 
> Actually, while I have been writing this, a nice "60" second periodic 
> packet loss problem has started on the UOregon -> MCT link, 
> starting at 
> about 1:32 PM EST. Symptom is about 300 milliseconds or so of 
> dead time 
> every 63 +- 2 seconds. Most recent events were (NTS time)
> 13:49:30
> 13:50:35
> 13:41:38
> 13:52:40
> 13:53:41
> 
> and, based on past experience, this could easily run for hours. Note 
> that 10 packets lost out of every 2400 is a loss rate of 0.4%
> 

FWIW:
This is probably a PIM implementation problem.

This can happen a number of ways but the easiest to explain would
be...

In a topology where the shortest-path overlaps the shared-path a
downstream router may end up sending both a (S,G) join and an (S,G,RP)
prune in the same packet.  The upstream router will process the JOIN
and then process the PRUNE resulting in a pruned interface.  Another 
downstream router that is also on the SPT then sends an (S,G) join
to override the prune -- reinstating connectivity, but with the 2 
second loss.

The problem is two-fold, but if the upstream router were to -not-
process (S,G,RP)PRUNEs for 'immediate olist' entries, then the 
problem would not show up.  Since the difference between 'immediate'
and 'inherited' olists is fairly new (maybe a year old -- at least
in general circulation) it is quite likely that router vendors have
not yet fully deployed code to recognize this problem.  I know that
when I left Cisco last June we were still trying to implement a
full solution.

Now, let me be the first to say that the situation I 'made-up' about
having a prune and a join sent to the same RPF neighbor is quite
contrived.  The important thing is what the upstream router does with
that information, and in Marshall's case, it appears to me that an 
(S,G) entry is being incorrectly pruned by an (S,G,R) PRUNE.

z