[c-nsp] Equivalent of "ip multicast boundary" on N7k for blocking data packets?

Phil Mayers p.mayers at imperial.ac.uk
Wed Jun 5 08:22:24 EDT 2013


On 05/06/13 12:50, Dobbins, Roland wrote:
>
> On Jun 4, 2013, at 4:54 AM, Phil Mayers wrote:
>
>> including that you don't need to write both ingress and egress
>> ACLs. Though I suppose the latter are more flexible.
>
> Egress ACLs are generally considered to be a Bad Thing, as they allow
> potentially undesirable packets past the port/linecard ASICs before
> dropping them on egress.

Well, as you say, "generally". Multicast is of course a slightly 
different beast to unicast.

TBH the egress functionality in multicast boundary (and therefore, an 
egress ACL on platforms that merge this into normal ACLs) is sort-of 
redundant - it makes more sense to prevent hosts joining the group, 
either via IGMP ACLs (at the edge) or PIM J/P ACLs (in the core, but 
this feature is absent on 6500) so that the platform doesn't ever try to 
emit the packets, than block them at egress data-plane.

As for egress ACLs - for multicast, maybe there are circumstances where 
you want different data-plane filtering to control-plane, and in 
different ways on different egress interfaces, in which case an egress 
ACL works. Or different ingress/egress data-plane filtering, in which 
case the IOS boundary stuff is too limited.

And of course in the general case, if the packets arrive labelled, maybe 
the ingress ACL doesn't run on that platform, so egress is your only 
filtering option.

...all of which argue in favour of splitting the boundary function into 
data-plane ingress/egress ACLs and separate control-plane IGMP/PIM 
join/leave ACLs. So I appear to have argued with myself and won ;o)


More information about the cisco-nsp mailing list