Then this is a fault in Cisco's mac filter. What's the point of the filter if it still accepts packets from the far side? No banned device should get ANY information (even a single packet) from our network.

Or are the incoming packet counts (the basis of the graphs) incremented even if the packets are then dropped? That would explain the small traffic: they are ATTEMPTS to connect, but are dropped. No large traffic since the connections never complete so no application data roared across.

Of course, if that is indeed true, this would make my monitoring much more useful since I could see successful traffic (large spikes) as well as attempted but unsuccessful traffic (small spikes). As long as no info leaks to the outside to unknown devices, I guess it's good to see when attempts are made (so I can call the police).

Maybe I misunderstood you, by a mac filter I read that you were restricting inbound traffic on the port to specific mac addresses.

If this is the case, then the port has to recieve the packets, to check if they are from the appropriate address. If not they just don't get forwarded if the address doen't match.

Such a filter does not stop the switch from transmitting data, you would have to turn this off on the port, "no cdp enable" etc. commands.

I'll need the switches to communicate correctly when the mac address matches, so I can't turn off negotiation on the port.

And I understand that physically, packets must be received before they are dropped (and so increment traffic).

But are you saying my inside switch is SENDING packets out to a device which has the wrong mac address!?! Because if that's the case, mac filtering DOES NOT WORK CORRECTLY on the 3560.