From: Koen Peetermans (K.Peetermans@chello.be)
Date: Tue Aug 03 2004 - 12:19:24 GMT-3
I'll take a shot at it:
The access-group will check SOURCE IP's, so not the multicast group (that is
in the destination IP field). To filter this with an access-group you would
need an extended acl.
A multicast boundary will filter inbound AND outbound multicast packets,
whereas your access-group only filters in one direction (in the case you
correctly use an extended acl with the multicast addresses as destination),
unless you put in an access-group in AND out.......
Looks like the boundary stuff is more efficient and faster since you're only
using a standard acl......
Kind regards,
Koen.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: dinsdag 3 augustus 2004 16:59
To: Group Study
Subject: Multicast admin boundaries
Hi guys,
Given this acl
access-list 10 deny 239.192.0.0 0.0.255.255
access-list 10 permit any
Now, consider the 2 configs below
int s0
ip multicast boundary 10
versus
int s0
access-group 10 out
What's the difference? The idea is to prevent multicast packets from
traveling too far, but won't either command accomplish the same thing. So,
why do we need a "special" command, ip multicast boundary to simply apply an
acl to an interface?
Thanks, Tim
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:31 GMT-3