*Notice above that I'm now matching on H2's MAC as the source, sending to H1's MAC as the destination* 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:ĭeny host 001a.6c30.8fde host 0 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). But in my example, there would be a sneaky way around this. This demonstrates a limitation of MAC ACLs. You might THINK to configure the following:īut upon further testing, you'd realize that H1 WAS still allowed to send packets back-and-forth to H2. 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. So no matter what feature you have referencing the MAC ACL, it (the feature) will only work if the traffic is NON-IPv4 traffic. 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. Some features (among many) that can utilize MAC ACLs are VLAN Access-Maps, Port ACLs, and MAC access-groups. 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 ().Īnd like IPv4 ACLs, MAC ACLs must be referenced by a feature in order to be useful. And just like in a normal IPv4 ACL, zeros mean "match this bit" and ones mean "ignore this bit". Within a MAC ACL, you can also wildcard bits within the MAC address. The first MAC entry ending with eab0 belongs to H1 and the second MAC ending with 8fde belongs to H2. The second entry permits everything else. In the above example, I've created a named MAC ACL (called "INE") which is supposed to block the source MAC of 0 from sending frames to the destination MAC of 001a.6c30.8fde. 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:ĭeny host 0 host 001a.6c30.8fde The construction of a MAC ACL is pretty much the same format as the construction of a named IP Access-List. This post concentrates on Cisco IOS MAC Access-Lists and their configuration (and limitations) in Cisco devices (namely, mainline Cisco IOS).Īs you’ve probably guessed by the name, this feature is used to match on source and/or destination MAC addresses of Ethernet frames. So let’s talk briefly about this Cisco IOS feature called MAC Access-Lists.
#Cisco mac address access list how to
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 the moment it's learned that a feature called “MAC Access-Lists” exists, it raises interest in many people. 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). Today, the vast majority of host devices (laptops, PCs, tablets, smartphones, etc) in networks rely on DHCP to obtain their IPv4 addresses. Rarely are any details given about how MAC ACLs actually work, or what their significant limitations are. Sometimes MAC Access-Lists are also mentioned briefly, but only to let the reader know they exist as another type of ACL. Every document or Certification-related book I’ve ever read introduces students to ACLs from the perspective of IPv4 Access-Lists. When preparing for any Network Certification Exam, one of the first topics that you’ll learn about are Access Control Lists (ACLs).
0 kommentar(er)
