Understanding Cisco MAC Access-Lists: Configuration and Limitatio...

When preparing for any Network Certification Exam, one of the first topics that you’ll learn about are Access Control Lists (ACLs). Every document or Certification-related book I’ve ever read introduces students to ACLs from the perspective of IPv4 Access-Lists. Sometimes MAC Access-Lists are also mentioned briefly, but only to let the reader know they exist as another type of ACL. Rarely are any details given about how MAC ACLs actually work, or what their significant limitations are.

Today, the vast majority of host devices (laptops, PCs, tablets, smartphones, etc) in networks rely on DHCP to obtain their IPv4 addresses. Matching on these addresses via IPv4 ACLs can be problematic since they are dynamic and unpredictable by their very nature (unless DHCP reservations have been configured). So the moment it's learned that a feature called “MAC Access-Lists” exists, it raises interest in many people. They assume that this might solve the dilemma of how to prevent Host-A from sending IP packets to Host-B when the IPv4 addresses of both hosts are unpredictable.

So let’s talk briefly about this Cisco IOS feature called MAC Access-Lists. This post concentrates on Cisco IOS MAC Access-Lists and their configuration (and limitations) in Cisco devices (namely, mainline Cisco IOS).

As you’ve probably guessed by the name, this feature is used to match on source and/or destination MAC addresses of Ethernet frames. The construction of a MAC ACL is pretty much the same format as the construction of a named IP Access-List. Take the topology below as an example.

unnamed-1

If I want to match on a unique (host) source MAC address going to another unique (host) destination MAC address, I would do it as follows:

mac access-list extended INE

deny host 001f.ca05.eab0 host 001a.6c30.8fde

permit any any

In the above example, I've created a named MAC ACL (called "INE") which is supposed to block the source MAC of 001f.ca05.eab0 from sending frames to the destination MAC of 001a.6c30.8fde. The second entry permits everything else. The first MAC entry ending with eab0 belongs to H1 and the second MAC ending with 8fde belongs to H2.

Within a MAC ACL, you can also wildcard bits within the MAC address. And just like in a normal IPv4 ACL, zeros mean "match this bit" and ones mean "ignore this bit". So if I rewrote my MAC ACL to look like this...

mac access-list extended INE

deny host 001f.ca00.0000 0000.0011.1111 host 001a.6c30.8fde

permit any any

...now I've utilized a wildcard mask against the source MAC, which is causing the ACL to only care about the OUI (first half of the MAC) from the source MAC (001f.caxx.xxxx).

And like IPv4 ACLs, MAC ACLs must be referenced by a feature in order to be useful. Some features (among many) that can utilize MAC ACLs are VLAN Access-Maps, Port ACLs, and MAC access-groups.

However, here's the REAL problem with MAC ACLs and the reason that very few people use them: they don't work against IPv4 or IPv6 traffic. So no matter what feature you have referencing the MAC ACL, it (the feature) will only work if the traffic is NON-IPv4 traffic. So let's say that I wanted to use the MAC ACL I had created above to deny H1 from sending any IPv4 packets to H2. You might THINK to configure the following:

unnamed-1

mac access-list extended INE

deny host 001f.ca05.eab0 host 001a.6c30.8fde

permit any any

interface FastEthernet0/1

description Connects-to-H1

mac access-group INE in

But upon further testing, you'd realize that H1 WAS still allowed to send packets back-and-forth to H2. This demonstrates a limitation of MAC ACLs. They can't match on IPv4 traffic. But in my example, there would be a sneaky way around this.

If H1 wants to send traffic to H2, it would first need to ARP for H2 (in this case, H1 and H2 are both in the same VLAN). Keeping in mind that the Ethertype field for ARP is NOT 0x0800 (which is the Ethertype used for IPv4 traffic) but rather 0x0806, I could modify my configuration as follows:

mac access-list extended INE

deny host 001a.6c30.8fde host 001f.ca05.eab0

*Notice above that I'm now matching on H2's MAC as the source, sending to H1's MAC as the destination*

permit any any

interface FastEthernet0/2

description Connects-To-H2

mac access-group INE in

Now, when H2 sends an ARP Reply/Response to H1 (because it is not technically an IPv4 packet) that ARP Reply WOULD be matched by the MAC ACL and dropped. Hence this configuration DOES work to prevent H1 from speaking with H2, because it will never receive an ARP reply from H2.

Unfortunately this method ONLY works on two devices in the same VLAN. There would be no way to utilize a MAC ACL to prevent H1 from selectively sending/receiving packets from devices in other VLANs.

In summary, if your desire is to permit-or-block non-IPv4/IPv6 traffic between hosts, then MAC Access-Lists (associated with either VLAN Access-Maps or Port ACLs) will work well. If your desire is to permit-or-block traffic based on the Layer-3 (or higher) characteristics of that traffic, then your best options are either VLAN Access-Maps (if matching on Layer-4 traffic characteristics, or traffic from hosts with static IP addresses) or Private-VLANs (for traffic to/from hosts with dynamic IP address assignments).

Hopefully this blog has shed some light on the benefits and drawbacks of using MAC Access-Lists.

If you'd like to learn more from Keith, sign up for his free Webinar on IPv6!

An Introduction to MAC Access-Lists