[nsp] ACLs on 2948G-L3

[Mark Vallar]

> > I always knew that the Catalyst 2948G-L3 is a piece of junk, but today
we
> > had a new and exciting effect: ACLs only work "sometimes".
> >
> > I have an ACL, incoming on the Gig50 interface, that has a
> >
> >   deny ip any host <somehost>
> >
> > as the very first statement.  NO permit before that.
> >
> > The host is on a routed vlan interface (bvi40).
> >
> > The deny works for "traceroute", but "ping" or "telnet" *do* get through
> > just fine to the machine, as soon as it's in the CEF adjacency cache.
> > Switching off CEF doesn't work ("not supported on this hardware"), of
> > course.
>
> We have had some very bad experiences with 2948G-L3 and BVIs, to the
> extent that we now only use our one remaining 2948G-L3 as a pure L3
> device. With that caveat, ACLs on the GigE interfaces work for us. I
> would recommend you remove the BVIs if at all possible and see if
> that makes the ACL work.

I have seen the same behavior of ACL's applied on a FE that was not part of
a BVI.  This was on cat2948g-in-mz.120-10.W5.18g.bin, that also had a
problem that rate-limit didn't work either.  I opened a TAC case on the
rate-limit problem and the Cisco engineer sent me a link to a Juniper web
page explaining the difference between the leaky bucket vs. token bucket
algorithm.  After that I didn't even bother with opening a case on the ACL
problem.  Rebooting did not correct the ACL problem either.  It was still
there after we upgraded to cat2948g-in-mz.120-18.W5.22b.bin (go figure), but
the rate-limit problem was fixed in that release.

<sigh>

There is a newer version cat2948g-in-mz.120-25.W5.27.bin dated 31 March
2003.  Anyone want to make a wager that ACL's are still broken?  Either that
or ACL's are fixed and interface counters are now broken.

-Mark