dhcp relay (ip helper) bypasses mac acl

[tstokkeland]

I haven't really done much with mac ACL's before - I have a temporary need to block some devices from getting a DHCP address -  it seems the ip helper-address function encapsulates and sends that request before the interface mac acl is hit - is there any documentation anywhere on this?

(the mac's in the list are getting an IP, but any further communication is blocked as it should))

here is the relavant config (4500 swithc with sup V):

mac access-list extended badGuys
deny   host 2222.2222.2222 any
deny   host 1111.2222.2222 any
permit any any

interface GigabitEthernet6/2
switchport access vlan 500
switchport mode access
mac access-group badGuys in
spanning-tree portfast

interface GigabitEthernet6/3
switchport trunk encapsulation dot1q
switchport mode trunk
mac access-group badGuys in

interface Vlan500
ip address 192.168.1.1 255.255.255.0
ip helper-address 10.5.1.1

any help appreciated - or rtfm pointer (I did a lot of searches but found little)

[Eugene Lau · Accepted solution]

Hi Thomas,

I'm just on the run at the moment and can't grab the link for you but if you needed a reference, you can search for "Configuring Network Security with ACLs" in the configuration guide for 4500.

The MAC ACL feature is used  for non-IP traffic or certain ether types.

If you want to deny certain MAC's from connecting to this switched, you can use the

mac-address-table static mac_address vlan vlan_ID drop 

This would drop ALL traffic to and from this Host. This feature is documented in the same section as MAC ACL's.

HTH

Eugene.

[tstokkeland]

ah thank you - I will try that

[tstokkeland]

that did work nicely thank you -  I am still questioning why the ip address helper is processed before a mac acl - oh well

[Eugene Lau · Accepted solution]

That's great news Thomas!

By design, today, a MAC access-list does not match on IPv4 packets (this may change if there's new capabilities added to this feature)

IPv4 packets are recognised at layer 2 by the ethertype 0x0800, and you'll see this in the sniffer trace. For example a  DHCP request will have this ethertype hence the MAC ACL will not match (deny or permit)

It's been a while since I've tested something but from memory, I believe that even if you specified an IPv4 ethertype (it's an option after configuring the xxxx.xxxx.xxxx in the extended MAC ACL), the MAC ACL will not match on this frame. You could give this a go and see what happens

Eugene.

[tstokkeland]

ah ok - I missed that whole thing, I had no idea, I just assumed the switch always inspected all frames if there was a mac acl there -  thank you

[gene.uhl]

See, I am not sure, but I disagree with the logic here.     The comment "

IPv4 packets are recognised at layer 2 by the ethertype 0x0800, and  you'll see this in the sniffer trace. For example a  DHCP request will  have this ethertype hence the MAC ACL will not match (deny or permit)" should then be viable for all IPv4 packets, like http, https, ftp, telnet, etc all IP based services and then all traffic would pass by the mac-acl as those packets will also be recognized as IPv4.

I am guessing that the DHCP solicit is a broadcast that is picked up by the switch service of IP helper/dhcp relay and processed by that service and passed on PRIOR to actually being processed ingress on the port.  It has to, as even these packets along with all the IPv4 packets are going to have the source mac address of the client and a destination mac address of the default gateway (or proxy arp) address (except for the dhcp broadcast as it will not have destination)

That is my opinion.

Thanks

Gene