All things related to multicast

[Leonard Giuliano <>]

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
The file sap-storm-detector.slax is a script that examines the traffic rates 
of all 
individual multicast sources transmitting onto the SAP group, 224.2.127.254, 
and sends a 
syslog if any source is sending more than 125kBps (1Mbps) onto the group.  
Following the 
steps below will run this as an Event Script on the router every 60s.  This 
script can 
be used on any router running Junos 9.0 or later.

Disclaimer: This procedure has worked nicely in the lab, but it is 
recommended that it 
still be tested before deploying into production.

1) Save file sap-storm-detector.slax on router in /var/db/script/op/

2) Add the following config to instantiate as an Ops Script.  With the 
following 
config, you can test this manually from the CLI in operational mode using "op 
sap-storm-detector". If any sources are sending more than 1Mbps onto the SAP 
group, a 
syslog will be generated.

system {
    scripts {
        op {
            file sap-storm-detector.slax;
        }
    }
}

3)  Add the following config to have this Ops script run automatically on the 
router 
every 60s.  The first piece will generate an event every 60 seconds called 
"check-every-minute".  The second section uses that event as a trigger to run 
the Ops 
script as an Event script.

When the script is triggered, it fetchs the traffic statistics for this group 
and tests 
each source to see if they are over the rate limit.  If so, a syslog messages 
is 
generated ("Potential SAP storm from source x.x.x.x").

event-options {
    generate-event {
        check-every-minute time-interval 60;
    }
    policy check-for-sap-storms {
        events check-every-minute;
        then {
            event-script sap-storm-detector.slax;
        }
    }
}

4) Upon receipt of syslog, investigate and take appropriate action against 
the 
offending source.  This could include policing or filtering this individual 
source.

For more information on Ops/Event Scripts, see 
http://www.juniper.net/techpubs/software/junos/junos91/swconfig-automation/frameset.html




Brief Note on SAP

This Event Script will NOT protect the router from a SAP storm.  The only way 
to 
protect the router is to not enable SAP listening on the router (delete 
protocols sap).  
It is strongly recommended that SAP listening and caching not be done on 
routers.  SAP 
listening on the router is used to provide a quick and dirty way of seeing if 
mcast is 
working properly.  This minimal benefit has proven over time to not be worth 
the risk 
of enabling this knob.  Disabling SAP listening on the routers will not 
affect 
downstream receivers- the routers will continue to happily forward all SAP 
traffic, 
they just won't look at and cache the data themselves.

The purpose of this script is to protect downstream receiving hosts, 
firewalls and 
links from a SAP storm.  This will quickly alert the operator of an offending 
source so 
that the operator can then filter/police that individual source without 
affecting other 
properly behaving SAP sources.  The approach of blindly policing traffic from 
all 
sources to 224.2.127.254 actually makes it much easier to DOS the SAP service 
since the 
policer cannot tell the difference between good and bad SAP packets, and the 
good SAP 
traffic will not be allowed through in the event of a storm.  So this script 
allows the 
operator to detect and take action against only bad sources so the good 
sources will 
continue to work.

The idea that unwanted traffic could flood a group is a problem inherent to 
the ASM 
service model.  The only real fix for this is to use SSM.  SAP provides a 
particularly 
attractive target for attack since it is probably the "best" known of all 
well-known 
mcast groups and can be reliably assumed to have a large number of receivers 
at all 
times.
version 1.0;

ns junos = "http://xml.juniper.net/junos/*/junos";;
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm";;
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0";;

import "../import/junos.xsl";

param $group = "224.2.127.254";
param $threshold = 125;

match / {
    var $rpc = <get-multicast-route-information> {
        <group> $group;
        <detail>;
    }

    var $out = jcs:invoke($rpc);

    for-each ($out/route-family/multicast-route) {
        if (forwarding-rate-kilobytes > $threshold) {
            expr jcs:syslog("kern.crit",
                             "Potential SAP storm from source ",
                             multicast-source-address);
        }
    }
}