All things related to multicast

[debbie fligor <>]

On Jan 24, 2007, at 11:34, Todd Chapman wrote:

> Debbie,
>
> We have the same issue here. It turns out that the Foundry L3 code  
> does not
> properly set the PIM-SM bit and the Netscreen firewall then drops the
> packets. This is a bug that Foundry is aware of. What version of  
> code are
> you running? We are running 7.6.04L. I believe the bug is resolved in
> 7.8.0E. We attempted to upgrade to this version and ran into  
> another bug
> with the number of BGP communities being limited to 64. At this  
> time, we are
> still running the 7.6.04 version, anxiously awaiting the version  
> with all
> the right fixes in place. Foundry is testing at this time and  
> expects to
> release it mid-February.

We're at 7.8.02d.  I remember that bug, it was really hard to find --  
it took over a year of intermittent problems before they caught it  
while looking at another one.  If you hadn't already figured it out,  
if you clear the mcache  and make the state rebuild, it more often  
than not gets it right for quite a while.  Obviously this isn't a  
very easy work around but if you have a high-profile service on  
multicast you can keep it working.

Once you get to a 7.8.0e or later version, PIM on the jetcore line  
should be pretty stable (unless there are new bugs).  we managed 8  
months of PIM working really well on that code (I think we were at  
7.8.0g most of that time), and then replaced our core with NetIron  
40Gs.  I really don't recommend those for PIM users if there's any  
chance you need/want a static mroute.  We still have the jetcore's in  
the exit, so that's what Netscreens are speaking PIM to.

I don't know how good your sales team is, but here's a bug list you  
probably want to make sure is in your bgp-fixed version, as they  
don't always make it into various code trains:

> > ----------
> > 41588	- Registration packets stopped being sent by directly  
> > attached PIM
> > router for S,G resulting in it not being in the RP's mcache. (7800e)
> >
> > 40881	- CLI mroute cannot specify distance for the RPF address.   
> > (7800d)
> >
> > 39923	- MSDP Peer misadvertising SA's with himself as the RP  
> > (originator)
> > which was not correct. (7800c)
> >
> > 31950	- MSDP flags are set in the mcache if it is being advertised  
> > to an
> > MSDP peer. (7800b)
> >
> > 35328	- MSDP sa-filter blocks all SA Cache, not just those that  
> > match the
> > ACL in the route-map.  (7800b)
> >
> > 35809	- MSDP Adv=1 flag is not set for local sources causing the  
> > multicast
> > stream not to be seen outside the PIM domain. (7800b)

If it's got all of these, it's hopefully got all their multicast bug- 
fixes rolled in.

thanks for the idea, that's probably not our problem (this code is  
supposed to have all these patches in it), but it was a good thing to  
check.


> Hope this helps.
>
> Todd Chapman
> UC Davis NOC
>
> -----Original Message-----
> From: debbie fligor 
> [mailto:]
> Sent: Wednesday, January 24, 2007 8:36 AM
> To: wg-multicast List
> Cc: debbie fligor
> Subject: a Netscreen firewall question
>
> We're trying to switch from using a mulitcast bypass around our  
> firewalls to
> sending the multicast traffic through them. No, we don't feel like  
> it needs
> to go through the firewalls, but the new core routers we got have a
> frustrating feature where if you use any static mroutes, it can't  
> populate
> the rest of the multicast routing table with the unicast routing  
> table, so a
> default mroute to the bypass requires us to hand configure every  
> subnet with
> an mroute in every core router, which is really annoying (to put it  
> mildly).
> Apparently changing this on the routers is not possible so we would  
> like our
> multicast default to match the unicast default route, which goes  
> through the
> firewalls.
>
> we built it in our lab, and got it working with a single path on  
> slightly
> newer code, but when we tried to do it for real in our dual path exit
> (firewalls in active-active) existing multicast connections stayed  
> working
> but new connections wouldn't come up. We're going to have the  
> switch vendor
> come in to help us debug the problem, but if anyone has known  
> issues or
> ideas we'd love to hear them.
>
> The firewalls are netscreen 5200's, the RPs are ciscos and the L2 and
> L3 switches are all Foundry.  All ideas are appreciated (and yes,  
> for our
> next bid static mroutes working together with dynamic routing  
> protocols to
> update the mcast routing table will be a requirement).
>
>
>
>
> -----
> -debbie
> Debbie Fligor, n9dn       Network Engineer, CITES, Univ. of Il
> email: 
>
>           <http://www.uiuc.edu/ph/www/fligor>
> "Every keystroke can be monitored. And the computers never forget."

-----
-debbie
Debbie Fligor, n9dn       Network Engineer, CITES, Univ. of Il
email: 

          <http://www.uiuc.edu/ph/www/fligor>
"Every keystroke can be monitored. And the computers never forget."