All things related to multicast

["Morytko, Steve" <>]

Thanks to all for their thoughts regarding how to best avoid this
problem. We figured it out ourselves and simply took "ip sap listen" off
a couple of routers when we discovered the cause and it seems most
everyone else here has too or suggests that is the best solution. It's
comforting to know that we had such good company :)

From my reading it appears that with "ip sap listen on" excessive router
resources are consumed during abnormal SAP events. Except for problem
diagnosis there is normally no reason to have the router become a sap
listener. I might add that it would be an easy thing to forget to
remove. 

However, I'd wager that there are a substantial number of I2
multicast-enabled customers that are not subscribed to this list who may
still be trying to understand what happened to their routers yesterday
(if they had ip sap listen enabled). While the source of yesterday's
problem was discovered and removed quickly the vulnerability still
exists for them. As we know VLC is easily obtained and just about anyone
anywhere could, and someday soon probably will, create this problem
again. 

Current BCP aside, I looked up the command on the Cisco web site and
their documentation doesn't discourage its use or offer any warnings. In
fact, some (apparently dated) documents suggest that it's needed.

http://www.cisco.com.ru/univercd/cc/td/doc/product/software/ios124/124cg
/himc_c/mcbmonit.htm 


http://www.cisco.com/en/US/docs/ios/12_2/ipmulti/command/reference/1rfmu
lt3.html#wp1047131


Cisco isn't the only place that suggests sap listen use either:

http://www.garr.it/emc_training/tutorials/mcast.txt

A web search revealed a couple of other hits including 2 from this list:

https://mail.internet2.edu/wws/arc/wg-multicast/2006-03/msg00009.html


https://mail.internet2.edu/wws/arc/wg-multicast/2000-11/msg00012.html

The former recommends removing it and the latter has it embedded in the
sample config.

All in all it's easy to see why someone might have it on or think it
should be on unless you're on top of the current BCP.

Based on the recent exchange on this list there seems to be some debate
regarding whether or not one should apply rate limiting.

I suppose a simple reactive way to detect the problem in the future is
to maintain and monitor a router with ip sap listen turned on and
identify the offending network/host when it happens. Presumably this
would be done at some I2 administrative site.

I'm not sure what the proactive solution is. Is it easy to reach all I2
member institution technical contacts with a warning? Events like this
don't do much to promote the use of IP multicast which isn't exactly
what we're all hoping for. 

I suspect that most subscribers to this list are relatively savvy with
regard to multicast but there is a large population out there that
simply wants a cookie-cutter template to use to get multicast installed
and operating smoothly (myself included). While great strides have been
made I'm not sure we're there yet and there's some work to do.  

Back into my hole,

Steve


Steve Morytko
UConn UITS Network Engineering
860-486-1405

 
 

> -----Original Message-----
> From: Pekka Savola 
> [mailto:]
> Sent: Friday, February 22, 2008 1:32 AM
> To: Simon Lockhart
> Cc: Alan Crosswell; Morytko, Steve; 
> 
> Subject: Re: SDP spike
> 
> On Thu, 21 Feb 2008, Simon Lockhart wrote:
> > On Thu Feb 21, 2008 at 03:09:23PM -0500, Alan Crosswell wrote:
> >> There still is the rate-limiting issue.  If someone DoSes SAP, then
if
> >> you rate limit, odds are you will lose the good announcements and
SAP
> >> will become useless.
> >
> > If someone DoS's SAP, then SAP becomes useless anyway - our users on
the
> > end of DSL lines were complaining that their DSL lines were full of
SAP
> > traffic (as well as their router CPU melting).
> >
> > Is it sensible to rate-limit SAP to 1Mbps? Anyone doing this with
"ip
> > multicast rate-limit" on Cisco, and got advice?
> 
> We've rate-limited SAP to 1Mbps on our edge to protect our customers
as
> well.  We did this on Jan 11 2006 when the previous SAP flood (from
> Greece, if I recall correctly) occurred.  We're doing this with
Juniper.
> 
> I'm happy I bothered to add the limiter back then as we didn't see any
> issues now :-).
> 
> Pekka