Subject: Filtering Multicast traffic

From: Kostas Strakadounas <[email-masked]>
Date: Tue, 25 Nov 1997 13:03:02 +0200

Hello,

We want to handle the following situation:
At this moment we have enabled PIM-DM over our Cisco based backbone.
We are ready to establish a DVMRP tunnel with our provider
in order to get connected to the Multicast Internet Backbone.
For this purpose we will use a SUN (spark station 4) running 
ipmulti 3.5 and mrouted 3.8

However, as our international link is heavily loaded in the incoming 
direction, we would like to be able to filter incoming Multicast traffic
and not get the content of the multicast groups.
We would like also to send some local multicast groups to the
outgoing direction.
Do you have any suggestions on how this kind of filtering can be done?

Can we achive this by blocking the SDR announcements to our users?
Is there any other way to permit our users joining the mbone multicast
groups?

Kind regards

Strakadounas Costas
FORTHnet S.A.

---

From: Dave Thaler <[email-masked]>
Date: Tue, 25 Nov 1997 10:28:13 -0500 (EST)

> Do you have any suggestions on how this kind of filtering can be done?

One way would be to advertise routes to your local prefixes out, 
but not allow any routes from the MBone in.

> Can we achive this by blocking the SDR announcements to our users?

No.  This will not prevent joining via a web page, or command-line,
or whatever else.

-Dave

---

From: John Meylor <[email-masked]>
Date: Tue, 25 Nov 1997 09:54:13 -0800

> ipmulti 3.5 and mrouted 3.8

If you are already running PIM-DM, you should consider exchanging 
multicast with the Mbone via a dvmrp-mode tunnel from one of your
cisco routers.  This will allow you to utilize access lists directly
on the tunnel. See commands below.

> and not get the content of the multicast groups.

You can either rate-limit traffic, or filter incoming routes used
by Mbone sources.  For rate-limiting:

[no] ip multicast rate-limit in | out [video] | [whiteboard]
                                 [group-list <acl>] [source-list <acl>]
<kbps>
        Controls the rate a sender from the source-list can send to a 
        multicast group in group-list. Any packets greater than <kbps>
are 
        silently discarded. The default value for <kbps> is 0, meaning
all
        packets are discarded. If "in" is used, only <kbps> will be
        accepted on the interface. IF "out" is used, only a maximum of
        <kbps> kilobits per second will transmitted on the interface. If 
        keywords "video" or "whiteboard" are used, then rate-limiting is
        performed based on the UDP port number used for the respective
media.
        For this to work, "ip sdr listen" must be enabled so the port
number
        can be obtained from the sdr cache. If sdr is not enabled, or
the
        group address is not in the sdr cache, no rate-limiting is done
for
        the group. The default setting of this command is disabled,
meaning
        there is no rate-limiting in effect. [11.0]

This will allow you to control the use of your limited bandwidth, 
however, your users will still be able to see the Mbone sources.
To prevent this use the following command on your ciscos.

[no] ip dvmrp accept-filter <access-list> [neighbor-list <nbr-acl>]
                                [<distance>]
        Configures an acceptance filter for incoming DVMRP Reports. Any 
        destinations that match <access-list> received in DVMRP reports 
        from neighbors in the <nbr-acl> are stored in the DVMRP routing
table 
        with <distance>. The distance is used to compare with the same 
        destination in the unicast routing table. The lower distance
route 
        (either from the unicast routing table or DVMRP routing table)
will 
        take precedence when computing the RPF interface for a source of
a 
        multicast packet. When no filters are configured on an
interface, all 
        destinations are accepted with distance 0. An <access-list>
value of 0,
        accepts all destinations. <access-list> can be a simple or
extended
        access-list. If extended access-lists are used, you have both
address
        and netmask granularity. An <nbr-acl> value of 0 means accept
from 
        all neighbors on interface. [10.2]

> We would like also to send some local multicast groups to the

You can announce your PIM enabled subnets by injecting then into
DVMRP routing table with the following command:

[no] ip dvmrp metric <metric> [list <access-list>] 
                         {[<protocol> <process-id>] | dvmrp]
        When PIM is configured on an interface and DVMRP neighbors are
        discovered, the router will, by default,  send DVMRP Report
messages. 
        Under certain circumstances, it may be desirable to tailor the
metric
        used for various unicast routes. This command allows one to
configure
        the metric associated with a set of destinations for Reports
sent out
        this interface. The acceptable <metric> value is between 0 and
32, 
        where 0 means that the route will not be advertised and 32 means 
        infinity and the route is advertised unreachable. If an
<access-list> 
        is specified, only the destinations that match the access-list
will be
        reported with the configured metric. <access-list> can be a
simple or
        extended access-list. When extended access-lists are used, you
have
        both address and netmask granularity. Any destinations not
advertised 
        due to split horizon will not use the configured metric. 

        If the <protocol><process-id> is configured, only routes learned
by
        the specified routing protocol will be advertised in DVMRP
Report
        messages. This parameter can be used in conjunction with
<access-list>
        so a selective list of destinations learned from a given routing
        protocol may be reported. If this command is not used, only
directly
        connected networks are advertised when DVMRP neighbors are
discovered.

        If the "dvmrp" keyword is configured, only routes from the DVMRP 
        routing table will be selected to be advertised with <metric>.

        This command can be used multiple times on an interface. [10.2]

> Do you have any suggestions on how this kind of filtering can be done?

For more information see:

ftp://ftpeng.cisco.com/ipmulticast/html/ipmulticast.html

- John Meylor

---

From: Peter Tebault <[email-masked]>
Date: Tue, 25 Nov 1997 09:54:46 -0800

I guess that if you are going to establish this tunnel, that you do want the
MBONE content to go to some local networks, just not to your international
ones.

Assuming that your international links are running PIM-DM as the routing
protocol, you can just slap a simple IP filter on the outgoing interface (on
the domestic side of the international link).  This filter will prevent the
traffic from going over the international link.  Be sure to leave a hole in
the filter for your scoped-IP traffic (239.n.n.n...) to go through.

-Pete-