ACL for blocking none valid dhcp requests

[mael]

Hi!

Is it possible to block relayed DHCP request that doesn't contain a specific option60 or a specific range of customers source mac-adress (inbedded in the DHCP request, not source mac because the requests are relayed) in a ACL?

With regards
Mattias

[mael]

Hi Tri!

Thanks for your response. However DHCP snooping in my case won't help anything. First of all it's not a customer port, than you're suggestion would be valid. It's a big L3 network....so if a request would block the port, a shitstorm would occour with our support.
Blocking MAC would result in no change at all because it's a L3 link and not a L2 (blocking the remote router MAC would also result in a shitstorm, excuse my french :-P).

So....I rewrite my question:
I wan't an ACL that blocks DHCP Discovery packets that is not included a specific option60 vendor-id?

Example:

entry Allowed_DHCP {
if {
protocol udp;
destination-port bootps;

} then {
permit;
}
}

DHCP snooping works on L2, not relayed requests on a L3 link.

Guessing I need some L7 functionality because of a specific word in a packet. So Extreme's ACL won't help hence it's only L2-L4.
So to answer my own question....It's not possible :'(

[Tripathy__Priya]

My first thought would be to use snooping always because when we tend to receive a lot of junk requests from other devices that customers plug into the networks that can well be taken care by this feature for violation action set on them.

By default DHCP snooping is disabled on the switch. To enable DHCP snooping on the switch, use the following command:

enable ip-security dhcp-snooping vlan ports [all | ] violationaction [drop-packet {[block-mac | block-port] [duration | permanently] | none]}] {snmp-trap}

The violation action setting determines what action(s) the switch takes when a rogue DHCP server packet is seen on an untrusted port or the IP address of the originating server is not among those of the configured trusted DHCP servers. The DHCP server packets are DHCP OFFER, ACK and NAK. The following list describes the violation actions:

• block-mac—The switch automatically generates an ACL to block the MAC address on that port. The switch does not blackhole that MAC address in the FDB. The switch can either temporarily or permanently block the MAC address.
• block-port—The switch blocks all traffic on that port by disabling the port either temporarily or permanently.
• none—The switch takes no action to drop the rogue DHCP packet or block the port, and so on. In this case, DHCP snooping continues to build and manage the DHCP bindings database and DHCP forwarding will continue in hardware as before.

Any violation that occurs causes the switch to generate an Event Management System (EMS) log message as well. Hence this implementation would be a worth one.....

[mael]

Hi Patrick!

That's not really an issue because we don't have control over that network. Today I do everything in our DHCP server, if a device doesn't have a specific vendor-id we just deny them an IP.
However we receive a lot of junk requests from other devices that customers plug into the networks.
My first thought was DHCP snooping but I can't find that it's possible to block any requests that doesn't contain a specific vendor-id (option60). It's possible to add a vendor-id string, but that would not solve anything 😉

With regards
Mattias

[Patrick_Voss]

Hello Mael,

That is possible but you could also use dhcp snooping to prevent Invalid DHCP servers from sending request to Clients. Here is an article that explains this:

https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-configure-DHCP-Snooping-on-EXOS

If this will resolve your situation it will be much easier to implement then to build a specific ACL and use up ACL resources.

Hope this helps!