All things related to multicast

[John Kristoff <>]

On Mon, 01 May 2006 23:02:09 -0700
ken lindahl 
<>
 wrote:

> i will shamelessly confess that SAP listening is enabled in all
> of our routers, and on more than one occasion i have successfully
> used "show ip sap" to quickly narrow down the location of a problem.
> ("ok, 134 sessions shown on this router, 132 on this one, but only 67
> on this one, wtf???")

I admit we had it enabled on a number of routers at NU for a long
time also, but had recently removed them after a few problems.  One
that may cause you to consider disabling it is to consider the DoS
vector 224.2.125.254 is by having it enabled.  Unless you can somehow
limit that group from the outside, that is an easy way for someone
to get your routers to listen to (and surprise, respond! to packets).

> we have nearly 100 routers in nearly as many buildings on campus and
> in remote offices. i hope you're not suggesting that we install and
> operate a host system in each of those locations. imo, we're much
> better off being able to use tools on the routers themselves.

Perhaps you can use some other baseline to ensure multicast is
operating properly?  Do you still have that many uses for SAP,
as opposed to multicast in general?  Perhaps simply monitor some
more generic multicast stats in the routers and compare those?
I wrote a very crude and simple script, not one that you'd probably
use, but just to give you an idea of the sort of thing that might
be a good alternative to running a beacon or some sort of SAP
listener everwhere:

  <http://aharp.ittns.northwestern.edu/software/mcastsum>

> if there's still business incentive for promoting multicast, then
> there ought to be business incentive for making it as easy as pos-
> sible to debug, and the question becomes how many users think SAP
> listening makes it easier to debug multicast problems. i do, but
> i don't know how many others feel the same.

I actually didn't find SAP all that useful in the past few years.

John