What an array of emoticons here...
This should be simple, but I'm stumped. I'm hoping I'm just misunderstanding something about the platform. This is a 3750 (C3750G-48TS) running 12.2(55)SE8.
I have an access VLAN per port and want to apply a simple ACL. It appears to not be working. :wall:
Quick config snippets below. Pretend the client IP I want to block is 10.10.10.2.
The physical port, standard with inbound/outbound basic rate limiting:
!
interface GigabitEthernet1/0/17
description foobar - suite xxx
switchport access vlan 17
switchport mode access
ip access-group blocksmtp in
load-interval 30
speed auto 100
srr-queue bandwidth limit 35
spanning-tree portfast
service-policy input 30mb-up
!
The access list:
ip access-list extended blocksmtp
deny tcp host 10.10.10.2 any eq smtp
permit ip any any
!
The VLAN:
!
interface Vlan17
description foobar - suite xxx
ip address 10.10.10.1 255.255.255.248
no ip redirects
no ip proxy-arp
!
With a ping running to 10.10.10.2, I would expect the "any any" permit to increment quite a bit, but it's not:
sh access-lists blocksmtp
Extended IP access list blocksmtp
10 deny tcp host 10.10.10.2 any eq smtp
20 permit ip any any (18 matches)
I've also tried applying this to the vlan interface, same deal.
Are the counters wrong or am I doing something the switch is not really supposed to support? I'm also seeing mixed info on whether to apply to the physical port or the VLAN interface...
We usually apply the ACL to the VLAN, so that if we dynamically apply a new VLAN to a switchport (Hello, NAC!), we got the right ACL for the job already associated with the VLAN.
Quote from: deanwebb on May 19, 2016, 06:16:22 PM
We usually apply the ACL to the VLAN, so that if we dynamically apply a new VLAN to a switchport (Hello, NAC!), we got the right ACL for the job already associated with the VLAN.
So either should work then? How platform-specific is that rule?
What I find odd is my counter still hasn't budged. I grabbed netflow data from before and after applying this and all outbound smtp from that IP did stop. So it's working, but no confirmation on the switch that it's actually matching anything. Grrr.
This is also why I use firewalls whenever possible to block traffic. They're much better at rule counts.
As for vendors, I've only done ACLs on Cisco gear. If you say "Arista! Arista! Arista!" loudly enough, a person familiar with their product line will appear in 3... 2... 1...
:haha1:
Er, I'm pretty sure you cannot apply a L3 ACL on a L2 switchport. Those support L2 port ACLs only, ingress only.
L3 ACLs need to be applied on SVIs or routed ports only
http://www.ciscopress.com/articles/article.asp?p=1181682&seqNum=4
From the Port ACL section:
QuoteThe main benefit with Port ACL is that it can filter IP traffic (using IP access lists) and non-IP traffic (using MAC access list). Both types of filtering can be achieved—that is, a Layer 2 interface can have both an IP access list and a MAC access list applied to it at the same time.
i stand corrected then.
though i have never seen this in prod!
OP do you have a host somewhere infected with malware and it's sending SMTP? That's annoying when that happens :)
For this to work, wouldn't the switch need to load that ACL into the ASIC ? If it's really working but the any-any counter is not incrementing correctly then it could be a code issue?
I have QoS on my 2960S with ACLs matching IP and ports so that software clients can get QoS for voice and video. With the QoS applied to nearly all 48 ports, editing an ACL can sometimes take ages I assume while the switch is compiling it in the back end however it does it.
What I'm getting at is if the config really is blocking SMTP then I reckon for the switch to be quick at switching, then not looking at "any any" on every packet might be a shortcut of the switch so to do its job quickly which is switching. I don't know if I'm right or not though :)
I remember learning and labbing VLAN ACLs for the CCNP years ago. Glad I'm not using them in production :)
Just an update - it did work, counters don't budge regardless of which interface I use. I'm going with Dieselboy's explanation on that. And wintermute, thanks for that link, that's the clearest most awesome piece of documentation I've seen on a cisco-owned domain. I should probably fetch a copy of that book.
Been a while since I touched 3750s but if I remember correctly, this might be the same for all HW switch platforms as well, ACL counters will generally only reflect packets seen/dropped by the control plane and not the data plane. This is probably true for route-map counters as well.
So in your scenario I would have thought that the ICMP replies would count. This only strengthen the case that you cannot trust HW switched ACL counters in L3 switches.
One workaround to this is to use the "log" keyword, this will make the packet be packets be handled by the CPU and thus match logged, but this of course also has a performance hit.
Quote from: netspork on May 21, 2016, 08:53:27 PM
Just an update - it did work, counters don't budge regardless of which interface I use. I'm going with Dieselboy's explanation on that. And wintermute, thanks for that link, that's the clearest most awesome piece of documentation I've seen on a cisco-owned domain. I should probably fetch a copy of that book.
To clarify, the counters not working is expected behaviour on a switch. The entire switching, including filtering via ACL, is applied in hardware, thus on the ASIC. The ASIC can't count, only the CPU can. The counter increases you see are packets that got through the ACL on that line and hit the CPU. Usually broadcasts of some kind.