All things related to multicast

[Zenon Mousmoulas <>]

This is great, but I'd like to see how it can be extended so that a  
specific appropriate action can be taken automatically, for example  
policing offending sources.
I suppose you would need a stateful service that would track offending  
sources as they appear and disappear and then somehow signal the  
router to take the action, i.e. match the sources with criteria in a  
policy-statement that would be used to apply a particular traffic  
policer.
There are probably many different ways to do such signaling; one could  
be using specially-crafted bgp announcements tagged with a specific  
community that would then be used in source-class filter match  
conditions. Such a method would resemble qos-group tags used in Cisco  
QPPB[1].
I suppose such a service would have to live outside the router. If you  
were to implement something like that, would it also be possible to  
discover offending sources by some other means, e.g. snmp queries,  
rather than through this script and syslog?

Getting this to work automatically is obviously somewhat complicated.  
Some folks may prefer to do it manually or even go with a more naive  
approach of policing all sap traffic. I noticed that you advise  
against such an approach and I certainly agree with your  
justification. However I was wondering if you would care to comment on  
the hack that I happened to mention a couple of weeks ago[2],  
involving the use of multicast flow maps. Would this be feasible at  
all? Would it be too expensive, in terms of router resources?

Thanks again for sharing this information.

Best regards,
Z.

[1] A similar mechanism has previously been developed in GRNET in  
order to provide QoS for MCU users. See: http://rts.grnet.gr/vc-qos.php

[2] https://mail.internet2.edu/wws/arc/wg-multicast/2008-06/msg00035.html

On 27 Ιουν 2008, at 10:52 ΜΜ, Leonard Giuliano wrote:

> Attached is an Event script that Phil just threw together which can  
> be run on a router every 60s to detect any hosts that are sending  
> more than 1Mbps of traffic onto the SAP group.  If it detects a  
> source sending too much traffic on the SAP group, it'll generate a  
> syslog so that the operator can investigate and take appropriate  
> action (filter/police offending source).
>
> Any questions or problems getting it to work, feel free to unicast me.
>
> Hope this is useful,
> Lenny<readme.txt><sap-storm-detector.slax>