[c-nsp] 2960S vlan ACL eating some L2 transit packets!?

[Gert Doering]

Hi,

a customer ran across an interesting effect today, that I can't explain.

Scenario: a 2960 switch that has a number of hosts and an internet 
gateway router connected to it, everything in "vlan 2".  Management 
interface of that switch is also in vlan 2.  

The management interface *is* reachable from the outside world, because 
there is nothing truly reliable "inside" (it's a small setup) that could 
be used as a stepping stone to check the switch in case there are issues.

To protect the switch from "joe random on the Internet" poking it, we
have applied an ACL to vlan 2:

access-list 100 permit ip 2.2.2.0 0.0.0.31 any
access-list 100 permit ip host 4.5.6.7 any
access-list 100 permit ip host 4.5.6.8 any
access-list 100 deny   ip any any log

interface Vlan2
 ip address 1.1.1.126 255.255.255.0
 ip access-group 100 in


this used to work perfectly well for many years, and to my knowledge, is
still considered "best practice".


Now, the customer decided to get a new 2960 with "more horsepower", got
himself a WS-C2960S-48TS-S with 12.2(55)SE7 on it, and started seeing 
heaps of log deny entries in his logfile:

Jan 13 10:57:05 stupid 324148: 3d20h: %SEC-6-IPACCESSLOGP: list 100 denied udp 1.1.1.2(0) -> 1.1.1.1(0), 1 packet
Jan 13 10:57:06 stupid 324149: 3d20h: %SEC-6-IPACCESSLOGP: list 100 denied udp 1.1.1.2(0) -> 1.1.1.1(0), 1 packet
Jan 13 10:57:07 stupid 324150: 3d20h: %SEC-6-IPACCESSLOGP: list 100 denied udp 1.1.1.2(0) -> 1.1.1.1(0), 1 packet
Jan 13 10:57:08 stupid 324151: 3d20h: %SEC-6-IPACCESSLOGP: list 100 denied udp 1.1.1.2(0) -> 1.1.1.1(0), 1 packet
Jan 13 10:57:09 stupid 324152: 3d20h: %SEC-6-IPACCESSLOGP: list 100 denied udp 1.1.1.2(0) -> 1.1.1.1(0), 1 packet
Jan 13 10:57:10 stupid 324153: 3d20h: %SEC-6-IPACCESSLOGP: list 100 denied udp 1.1.1.2(0) -> 1.1.1.1(0), 1 packet
Jan 13 10:57:11 stupid 324154: 3d20h: %SEC-6-IPACCESSLOGP: list 100 denied udp 1.1.1.2(0) -> 1.1.1.1(0), 1 packet
Jan 13 10:57:12 stupid 324155: 3d20h: %SEC-6-IPACCESSLOGP: list 100 denied tcp 1.1.1.100(0) -> 100.78.182.2(0), 1 packet
Jan 13 10:57:13 stupid 324156: 3d20h: %SEC-6-IPACCESSLOGP: list 100 denied udp 1.1.1.2(0) -> 1.1.1.1(0), 1 packet
Jan 13 10:57:13 stupid 324157: 3d20h: %SEC-6-IPACCESSLOGP: list 100 denied udp 1.1.1.2(0) -> 100.169.184.225(0), 1 packet
Jan 13 10:57:15 stupid 324158: 3d20h: %SEC-6-IPACCESSLOGP: list 100 denied tcp 100.55.35.37(0) -> 1.1.1.10(0), 1 packet


The first 3 octets of the IP addresses have been changed to 1.1.1.x, but the
4th octet is unchanged, so it's really "traffic that is just crossing the
device on layer 2", not addressed to the management interface on 1.1.1.126.


Question 1: is that documented anywhere?  ACLs on "interface vlan X" on
            a layer2-only switch used to only apply to management traffic,
            never ever to transit traffic


Now, it get's more interesting: while the switch is logging lots of denies,
and *is* actually dropping packets, it's only dropping a fraction of all
packets transitting - so you can still ssh through it, for example, but it
feels "sluggish" - you all know that feeling in your fingers when you have
a few percent of packet loss.

Question 2: if it's supposed to drop these l2 transit packets, why is it
            not dropping all of them?

Question 3: what's the recommended bug free (hah) software for 2960S?


(There are a number of workarounds, like "apply the ACL only to vty 0 15",
or "permit everything that is not to 1.1.1.126", but I want to *understand*
what is happening here)

thanks,

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20140113/81641cdf/attachment.sig>