My suspicion is that MAC ACLs are simply stored in the configuration file, just like regular ACLs. I’ve gone into a device and verified this. Now if you have 200 MAC addresses, that’s not going to be a problem as far as the size of your configuration file goes. A single line like the following takes up 30 characters which is 30 bytes.
permit any host 0000.0000.0001
200 of these statements is 6KB of data. Even 1000 entries will result in 30KB, so this is not much of a concern. If I remember correctly, you are using Cisco 9000 series devices which should not present any problem for such file sizes.
What is more of a concern is the CPU processing needed to actually apply these ACLs to traffic. Once again, with the devices you are using, this shouldn’t be an issue, but it’s a good idea to monitor memory and CPU usage as you employ the ACLs.
Normal access lists filter traffic between subnets at locations where routing takes place. VACLs are capable of filtering traffic within a VLAN, and thus within the same subnet. It is important to note that VACLs use access lists to function. They actually reference an access list (which has a deny any any statement at the end as usual). You can find out more about how they are configured and how they work at the following lesson:
One question I have here. The ACL in question is permitting “any” traffic to the server. Which is then dropped by the first entry in the VACL. So this will drop all traffic going to the server from the 192.168.1.0 zero subnet, because all traffic on the 192.168.1.0 network will match this statement, not just the two servers show in the digram. So was this example meant to drop just these two hosts? or the whole subnet from talking to the server, because surely this config is dropping all hosts to the server…
Remember that a VACL is applied to the whole VLAN and not to a particular interface. This means that all traffic that appears on VLAN 10 (in the example) must adhere to the VACL. The example shown in the lesson blocks all traffic that is destined to 192.168.1.100. It permits all other traffic. The result is that any traffic, from any source that tries to reach 192.168.1.100 (the server) is blocked. It doesn’t specify source.
This example was meant to drop anything going to the server, from anywhere. Communication between hosts is possible, as is communication from the server to a host, but not any traffic destined for the server IP address.
Let’s say I want to make sure that the two computers are unable to communicate with the server.
And in the lesson, the ACL that is applied actually blocks all traffic destined to the server, including traffic from these two hosts. In order to block these specific hosts, then ACL 100 should include the host addresses as sources.
So yes, you’re right, it may be worth making the statement in the lesson clearer. I’ll let Rene know to take a look.
I hope this has been helpful and thanks for the feedback!
I have gone into the lab and have confirmed that the command that Rene used in the lesson is not available on the virtual switch I am using in CML. Specifically, I’m using the following:
(vios_l2-ADVENTERPRISEK9-M), Experimental Version 15.2(20200924:215240)
The command permit any any under the MAC ACL configuration allows you to enter only the keywords listed in your post, and does not let you put in the hex value of the protocol for which you want to filter.
I will let Rene know to take a look and clarify if he used a different platform.
Will it be any impact to operational data traffic when we add new line of ACL on VACL?
I mean, just concern about when we add new ACL into the VACL, there will be reprogramming process on switch and could impact to data traffic (drop packet) that even the subnet not related to ACL.
If you have a VACL that has already been applied to a VLAN, and it is actively referencing an ACL, then making any changes to the VACL, or the ACL will affect production traffic. Such changes should be made with care and during a maintenance window to minimize any detrimental effects that may occur from errors or misconfiguration.
Now having said that, can you make changes without having production traffic affected? Well yes you can. You can add a new ACL to the VACL and changes to traffic filtering will be applied immediately. If the configuration is correct, then you will have no impact on any other operational data traffic beyond whatever filtering changes the new ACL introduces. So yes, you should be able to make such a change successfully.
Once again, however, keep in mind that any errors or misconfiguration will directly affect production traffic.
So VACL are capable of inspecting the IP header to match an IP address. Does that mean that VACL are only available on L3 switches? Or can i have a VACL on a “classic” L2 switch?
The VACL feature is available on switches that support the LAN BASE IOS image. The LAN BASE IOS image is what is used by pure “Layer 2” switches. I have been able to confirm this using Cisco’s Feature Navigator and in particular, for the CAT 3650 platform using the LAN BASE IOS image.
I have a hard time making sense of this example, I don’t get it.
SW1(config)#access-list 100 permit ip any host 192.168.1.100
matches all traffic towards the server.
SW1(config)#vlan access-map NOT-TO-SERVER 10
SW1(config-access-map)#match ip address 100
SW1(config-access-map)#action drop
SW1(config-access-map)#vlan access-map NOT-TO-SERVER 20
SW1(config-access-map)#action forward
With sequence 10 we drop all traffic, with sequence 20 we forward anything else? What traffic is anything else? In this example, all traffic will be dropped and never reach sequence 20?
If the above is correct, is it possible to correct it in a way to drop just these two hosts. In real life, this is a more realistic scenario than blocking all traffic towards the server, I believe.
Best Regards,
Martin
Update:
I got it, without sequence 20 the hosts won’t be able to reach each other, nothing in VLAN 10 will. So in order to block only these two hosts, we have to be granular with the access list and permit only for 192.168.10.1, 192.168.10.3 and then drop it in the VLAN access-map? Please confirm, as my lab don’t seem to like the VLAN access-map.
Like access lists, a VACL has an implicit deny all at the end. So if you don’t add the action forward action at the end, then we would have this behavior:
Seq 10 → Drop all packets that have a destination IP of 192.168.1.100
Implicit Deny → Drop all packets
Therefore nothing will get through.
By adding sequence 20 with the action forward command we get this behavior:
Seq 10 → Drop all packets that have a destination IP of 192.168.1.100
Seq 20 → Permit all packets (those that haven’t been matched by Seq 10)
Implicit Deny → Drop all packets
You can see that in the second case, no packets will ever reach the implicit deny since Seq 20 matches everything that hasn’t already been matched by Seq 10.
Now the VACL will be applied to all traffic traversing the VLAN. That means that packets sent by either H1 or H2 toward the server will be filtered by this VACL. Does that make sense?
The VACL in the lesson references an ACL. The ACL matches a destination address of 192.168.1.100 which is that of the server. So all IP packets with a destination address of 192.168.1.100 will be matched by the VACL and dropped.
If you want to prevent only H1 and H2 from reaching the server and allow the rest of the subnet, then you would have to change the ACL to match IP packets with the IP addresses of H1 and H2 in the source address field and the server IP address in the destination field. In other words, packets from H1 and H2 towards the server should be dropped, and everything else allowed. To do this, we’ll need multiple entries in the ACL. Let’s create a new ACL with number 101:
SW1(config)#access-list extended 101
SW1(config-ext-nacl)# 10 permit ip host 192.168.1.1 host 192.168.1.100
SW1(config-ext-nacl)# 20 permit ip host 192.168.1.2 host 192.168.1.100
This ACL matches all IP packets from H1 and from H1 to the server. Then you would have the VACL reference this ACL, match it, and configure a drop action. Don’t forget to include the action forward at the end of the VACL to allow all other traffic. Does that make sense?
Just to inform and help
I’ve tried it and when you add a new ip to ACL , it is blocked right away.
I added 20 permit ip any host 192.168.1.2 , based on the topology of the VACL lesson.
It is blocked right away.
However when I tried to execute MAC access list command it didnt accept 0x86DD.
SW1(config-ext-macl)#permit any any 0x86DD 0x000
% Invalid input detected at '^' marker.
Switch version is , (vios_l2-ADVENTERPRISEK9-M), Experimental Version 15.2(20200924:215240) it is CML switch.
Thanks for testing that out and sharing your results, it’s always useful for readers of the forum.
I tried the same thing on my CML environment and got the same error message as you. Investigating a little further, I found that the command in this particular switch does not accept an EtherType number, but only keywords like so:
I am using the exact same version as you. It seems that the EtherTypes that you can use are limited to these particular ones, and it doesn’t include IPv6. Take a look at this Cisco command reference that describes the command with many more options than those shown above:
I believe it is a limitation of the specific IOS version.
