Hello, everyone.
When would we use these VLAN ACLs in the real world? I’ve never thought of a scenario where we would want to limit communication within the same VLAN. If we wanted to do that, wouldn’t it be more efficient to place the servers in a separate subnet?
Also, any clue why my hosts cannot talk after I clear the ARP cache?
It’s as if it completely blocked ARP traffic for some reason? Why is this? ARP operates on L2. Yet if I do this, it works
Thank you.
David
Hello David
Ideally, in a properly designed network, you would typically use separate subnets and VLANs to control the communication between hosts. That is indeed best practice. However, VACLs add a layer of flexibility for situations where you may not have the luxury of creating separate VLANs/subnets, either due to a lack of budget for the appropriate equipment and infrastructure to create those subnets, or because you need a quick and dirty security solution (even if it is temporary),
Since VACLs are used to filter traffic within the same VLAN, they can work as an additional layer of flexibility. This is especially useful when you have servers or devices within the same VLAN that should not interact with each other using particular protocols.
Another scenario could be in a shared hosting environment, where multiple clients are on the same VLAN but shouldn’t be able to communicate with each other’s servers for privacy and security reasons.
VACLs can also be used for traffic control, allowing you to manage the flow of traffic within a VLAN to prevent network congestion or to prioritize certain types of traffic.
So while it’s true that creating separate subnets is a common method for controlling traffic, VACLs provide an additional layer of control within a VLAN, giving you more flexibility to manage your network.
Another alternative to VACLs is the use of private VLANs. As you can see there are several features that can be used to deliver similar results. Which one you will end up using depends on cost, time, permanence of solution, and convenience.
VACLs filter traffic at both Layers 2 and 3. Also, any traffic that does not match any of the permit or redirect statements in the VACL access map is implicitly dropped. This means that the VACL you created will implicitly drop ARP messages. The communication will continue to operate until either the ARP cache expires, or until you clear the ARP cache. Because the ARP cache has a timeout of several hours, you wouldn’t see the impact of this during the timeframe of creating a lab, so it is not an issue… unless you clear the ARP cache as you did.
So the solution is what you suggested, to add a match statement in the VACL and forward the ARP messages.
I hope this has been helpful!
Laz
Greetings Rene, what is the difference between a VACL and regular standard or extended ACL on a layer3 VLAN
Ex.
Interface Vlan 10
Ip access-group not-to-server
I think I know the answer but wanted your input.Thanks.
Hello Gordon
The main difference between a VACL and a regular ACL lies in their functionality and where they are applied.
A regular ACL, either standard or extended, is used primarily for filtering network traffic and can be applied on a router’s interface, either inbound or outbound. ACLs control traffic based on the source and/or destination IP addresses and Transport layer ports.
On the other hand, a VACL functions by defining a set of rules or filters that determine which types of network traffic are allowed or denied between devices within the same VLAN. These rules are typically based on criteria such as source and destination IP addresses, source and destination MAC addresses, and protocol types.
For more information about VACLs and how they work, take a look at this NetworkLessons note on VACLs.
Now the example config you shared in your post applies an ACL on a VLAN interface or an SVI. (Just a note, the in or out keyword is missing, it should be added at the end of the command). This will result in filtering any traffic directed to or from that interface.
If you were to apply a VACL to VLAN 10, then all traffic that traverses the VLAN (regardless of whether or not it is directed to or from the VLAN 10 SVI) would be subject to the rules of that VACL. Does that make sense?
I hope this has been helpful!
Laz
Laz,
Great answer. It makes a lot of sense. I love the website by the way. Thanks for all you guys do. 
Hi.
How to deny the same network L2 layer?
I want to deny all networks on 144.144.144.0/24 and permit the 144.144.144.1 IP, which is the gateway.
I don’t know if my config is correct, but pinging to the gateway fails.
The match count for all ACLs on 144.1/32 and 144.0/24 is incremented.
access-list 101 permit ip any host 144.144.144.1
access-list 100 permit ip any 144.144.144.0 0.0.0.255
!
vlan access-map vacl 10
match ip address 101
action forward
!
vlan access-map vacl 20
match ip address 100
action drop
!
vlan access-map vacl 30
action forward
!
vlan filter vacl vlan-list 144
VPCS> ping 144.144.144.1
144.144.144.1 icmp_seq=1 timeout
144.144.144.1 icmp_seq=2 timeout
144.144.144.1 icmp_seq=3 timeout
Extended IP access list 100
10 permit ip any 144.144.144.0 0.0.0.255 (23 matches)
Extended IP access list 101
10 permit ip any host 144.144.144.1 (23 matches)
Hi @musalyh ,
Can you try adding one extra permit statement for the return traffic from the router?
access-list 101 permit ip any host 144.144.144.1
access-list 101 permit ip host 144.144.144.1 any
Rene
Hello, everyone.
These ACLs are quite tricky, especially if we consider the fact that they will also filter layer 2 traffic.
I have a question regarding something I encountered in CML and I am thinking that this could be an IOSvL2 bug but I have to confirm.
Here is my topology:
My goal is to isolate PC7 and to block any traffic destined to it from the other PCs. I was using a MAC ACL to accomplish this to get some practice with it. PC7 has a MAC of 5254.0014.80ed
SW1(config-access-map)#do show access-lists | begin MAC
Extended MAC access list BLOCK
permit any host 5254.0014.80ed (250 matches)
deny any any (461 matches)
SW1(config-access-map)#do show vlan access-map BLOCK_PC7
Vlan access-map "BLOCK_PC7" 10
Match clauses:
mac address: BLOCK
Action:
drop
Vlan access-map "BLOCK_PC7" 20
Match clauses:
Action:
forward
SW1(config-access-map)#
This configuration should drop anything destined to PC7’s MAC, right? But this isn’t quite the case
PC2#ping 192.168.10.7 repeat 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 192.168.10.7, timeout is 2 seconds:
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 6/9/15 ms
PC2#
A ping for example still works. The funny thing is that when I shutdown the interface between SW1 and PC7 and then re-enable it, the ping no longer works 
SW1(config)#interface G0/3
SW1(config-if)#shut
*Feb 12 12:24:43.143: %LINK-5-CHANGED: Interface GigabitEthernet0/3, changed state to administratively down
*Feb 12 12:24:44.143: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to down
SW1(config-if)#no shut
*Feb 12 12:24:47.963: %LINK-3-UPDOWN: Interface GigabitEthernet0/3, changed state to up
*Feb 12 12:24:48.963: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/3, changed state to up
PC2#ping 192.168.10.7 repeat 6
Type escape sequence to abort.
Sending 6, 100-byte ICMP Echos to 192.168.10.7, timeout is 2 seconds:
......
Success rate is 0 percent (0/6)
PC2#
If I then change the action on the entry number 10 to forward
SW1(config)#vlan access-map BLOCK_PC7 10
SW1(config-access-map)#action forward
PC2#ping 192.168.10.7 repeat 6
Type escape sequence to abort.
Sending 6, 100-byte ICMP Echos to 192.168.10.7, timeout is 2 seconds:
!!!!!!
Success rate is 100 percent (6/6), round-trip min/avg/max = 1/2/3 ms
PC2#
It works, which proves that the communication did not work because of the 10th entry Which is exactly what I wanted. However, if I configure it to drop again.
SW1(config)#vlan access-map BLOCK_PC7 10
SW1(config-access-map)#action forward
SW1(config-access-map)#action drop
PC2#ping 192.168.10.7 repeat 6
Type escape sequence to abort.
Sending 6, 100-byte ICMP Echos to 192.168.10.7, timeout is 2 seconds:
!!!!!!
Success rate is 100 percent (6/6), round-trip min/avg/max = 1/2/3 ms
PC2#
The ping still works Is this a CML bug?
Thank you.
David
Hi David,
This got me curious. At first, I thought it would be an IOSvl2 bug. VACLs are applied in hardware, so it’s always tricky when you try this on a virtual device.
However, I just tested this on a 3560 and I see the exact same result.
Two devices, they can ping each other. When I apply the VACL, they can still ping each other. When I clear the MAC table and do another ping, it relearns both MAC addresses.
Only when I do a shut on the interface that connects to the second device, the VACL is applied and no longer allows this traffic. It probably has to do with installing the VACL in hardware.
I can confirm that when you use the vlan filter command, you’ll see the TCAM utilization increasing.
Without, it looks like this on my 3650:
SW1#show platform hardware fed switch active fwd-asic resource tcam utilization
CAM Utilization for ASIC [0]
Table Max Values Used Values
--------------------------------------------------------------------------------
Unicast MAC addresses 32768/512 18/21
L3 Multicast entries 4096/512 0/9
L2 Multicast entries 4096/512 0/11
Directly or indirectly connected routes 16384/7168 3/19
QoS Access Control Entries 2560 40
Security Access Control Entries 3072 126
Netflow ACEs 768 15
Policy Based Routing ACEs 1024 9
Flow SPAN ACEs 512 5
Output Flow SPAN ACEs 512 8
Control Plane Entries 512 255
Tunnels 256 17
Lisp Instance Mapping Entries 768 3
SGT_DGT 4096/512 0/1
CLIENT_LE 4096/256 0/0
INPUT_GROUP_LE 6144 0
OUTPUT_GROUP_LE 6144 0
Macsec SPD 256 2
Look for the Security Access Control Entries line. Once enabled, it looks like this:
SW1#$rm hardware fed switch active fwd-asic resource tcam utilization
CAM Utilization for ASIC [0]
Table Max Values Used Values
--------------------------------------------------------------------------------
Unicast MAC addresses 32768/512 18/21
L3 Multicast entries 4096/512 0/9
L2 Multicast entries 4096/512 0/11
Directly or indirectly connected routes 16384/7168 3/19
QoS Access Control Entries 2560 40
Security Access Control Entries 3072 138
Netflow ACEs 768 15
Policy Based Routing ACEs 1024 9
Flow SPAN ACEs 512 5
Output Flow SPAN ACEs 512 8
Control Plane Entries 512 255
Tunnels 256 17
Lisp Instance Mapping Entries 768 3
SGT_DGT 4096/512 0/1
CLIENT_LE 4096/256 0/0
INPUT_GROUP_LE 6144 0
OUTPUT_GROUP_LE 6144 0
Macsec SPD 256 2
The used values for Security Access Control Entries increases. So, it seems to install something but doesn’t take effect until you shut/no shut that interface.
I tried looking into more specific commands or to debug this, but I couldn’t find anything useful on the 3650.
Rene
Hello Rene.
I might have figured it out. The reason why my PC could not ping PC7 after the interface was shutdown and then re-enabled was because of… STP. Which caused the port to spend 15 seconds in Listening/Learning which made me assume that the VACL was working.
If I configure portfast on the port facing PC7, the ping succeeds right away, even after restarting the interface.
PC2#ping 192.168.10.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.7, timeout is 2 seconds:
.!!!!
The reason why this doesn’t work is because MAC ACLs only work for L2 traffic. They do not work with traffic that carries an IPv4 or an IPv6 header, they can literally only filter L2 traffic.
So even if I try to configure an ACl like this
Extended MAC access list BLOCK
permit any host 5254.0014.80ed
deny any any
It won’t match any communication towards 5254.xx because an ICMP ping has a L3 header. ARP of course succeeds because the destination MAC there is a broadcast which matches the deny any any entry.
So to actually deny the communication between PC7 and everyone else, I would have to filter out the ARP reply since it resides on L2 and that one has an actual unicast MAC address.
SW1(config)#mac access-list extended BLOCK
SW1(config-ext-macl)#permit host 5254.0014.80ed any
SW1(config-ext-macl)#deny any any
PC2(config)#do ping 192.168.10.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.7, timeout is 2 seconds:
...
Success rate is 0 percent (0/3)
PC2(config)#arp 192.168.10.7 5254.0014.80ed arpa
PC2(config)#do ping 192.168.10.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/6 ms
PC2(config)#
MAC ACLs are weird.
David.
Hi David,
I’ll give this another try tomorrow. I’ll add a static arp entry on both hosts so they always know how to reach each other, then see if they can ping each other with the VACL active.
I couldn’t find anything in Cisco documentation that claims it won’t work for Ethernet frames that contain an IPv4 or IPv6 packet but that’s easy to test.
Rene
Here’s finally the written version for this:
This demonstrates that switches ignore IP packets when you have a MAC filter in a VACL.