Cisco L2 switch port ACL options

Question

I'm trying to understand Cisco Switch ACL options I can potentially use to limit traffic. Switch is a IE2000 series with Lanbase IOS. It is L2, with trunk port to uplink switches, multiple VLANs on switch, but L3/vlan routing is handled by a L3 switch up the chain.

What I want to do - there is a device on one physical port that is faulting, seemingly due to to much network traffic (device does not fault when uplink on switch is unplugged & there are at least 100 devices on the VLAN) - as a stop gap until we can do some better network engineering, is limit access to the device to the 2-3 ip addresses that actually need to talk to the device. If I could put an ACL on the switchport to limit traffic sent to the device, it would have been perfect, but as far as I can tell, Cisco only allows inbound ACLs on a switch port (unless I am misunderstanding what Cisco calls inbound and outbound).

Looks like I may be able to put a inbound ACL on the physical port used for the trunk - but that would affect all VLANs? Also, I would need understand traffic for rest of devices on switch & to check if we were using Etherchannel on that port as I am sure that may complicate things.

However, it looks like Cisco allows ACLs on VLANs, and I need to wrap my head around how that would work. I comprehend how ACLs would work on the L3 switch doing routed. For the L2 - can I just create a SVI for the VLAN without an ip address, and then put on inbound ACL on the VLAN SVI to limit traffic before it goes to physical ports for that VLAN?

Ex: External <-> Trunk Port(s) <-> {ACL???} <-> VLAN# SVI <-> Phys. Ports on VLAN#

Thanks, JT

Answer 1

No, an ACL applied on an SVI will only affect traffic routed through that SVI. The traffic of interest is layer-2 switched through the access switch, and simply creating an SVI doesn't change that.

If you are able to reconfigure the malfunctioning device onto a new subnet, you could create an entirely new subnet using an SVI, put the device into the subnet, and then a related ACL would work.

However, it sounds like you're trying to find the least-invasive way to mitigate your problem temporarily. I don't know if the above is practical in your environment. A layer-3 ACL on the upstream gateway would seem more appropriate, if you're able to configure it there.