cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1144
Views
3
Helpful
7
Replies

Cisco Switch as DHCP Server with DHCP Snooping enabled

xzevallos
Level 1
Level 1

I have a C9200 switch configured as a DHCP server.  Its SVI interface is on VLAN 201.  There are no DHCP clients connected to this switch, they are all behind a router acting as a relay agent with helper address pointing to the switch SVI address.  This works perfectly.

If I enable DHCP Snooping on VLAN 201 on this switch, the switch stops providing DHCP addresses.  What do I need to do to make it work with snooping enabled?

2 Accepted Solutions

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

My friends,

Please allow me to join.

M02@rt37 , @luis_cordova - I humbly beg to differ. Configuring DHCP Snooping on the switch that operates as a DHCP server for clients behind a relay agent is, pardon me for being blunt, misplaced and useless.

Remember that the DHCP Snooping is used to protect against various attacks on DHCP-driven networks. This is done by very selectively accepting DHCP messages on untrusted and trusted ports and performing additional sanity checks on their contents. DHCP Snooping will drop DHCP packets under these circumstances:

1) Drop server-sent DHCP packets (OFFER, ACK, NAK, LEASEQUERY) received on untrusted ports. This is intended to prevent connecting an unauthorized DHCP server to the network, or having a computer impersonate a DHCP server.

2) Drop DHCP packets received on untrusted ports where the source MAC address of the frame and the client MAC address in the DHCP payload do not match. This is to prevent a host to send out DHCP packets on behalf of another host. Note that this covers both malicious client activity as well as DHCP relay agent operation.

3) Drop DHCP RELEASE and DECLINE messages received on untrusted ports where the client MAC address in the DHCP payload is associated with a different untrusted port in the snooping database. This is to prevent a host to specifically release or refuse an address on behalf of another host.

4) Drop DHCP messages received on untrusted ports that have non-zero GIADDR or that have Option 82 present. This is to prevent a host from impersonating a DHCP relay agent.

If a DHCP packet passed these checks, it will be accepted, but as for forwarding, if it is a packet received on an untrusted port (a client packet), it can only be forwarded out the trusted ports but never through other untrusted ports; a packet received on a trusted port (a server packet) will only be forwarded out the port toward the final client but never flooded (the switch will use the Option 82 contents, client's MAC address in the DHCP payload and the client's destination MAC address in this order to know what port to forward out the packet toward the client).

The gist of all these checks and changed forwarding rules is to prevent leaking the inherently broadcast-based DHCP communication to unintended hosts, prevent rogue DHCP servers from leasing IP addresses, and prevent hosts from trying malicious tricks on behalf of other hosts or relay agents.

The botom line is that the DHCP Snooping is distinctly an access layer defense and protection technique for a single broadcast domain at a time. It makes little sense to activate it on the distribution layer if the access layer has already been sufficiently protected, and it absolutely does not make sense to activate it on a switch that is not directly connected to the DHCP clients and that depends on a relay agent to forward the DHCP communication back and forth. Such a switch is in a different broadcast domain than the clients, and to implement protections here makes no sense as the communication between the DHCP server and relay agent is always unicast.

Note that the rules 2 and 4 above make it plainly impossible to reasonably use DHCP Snooping on such a switch. Rule 2 cannot be fulfilled because relayed DHCP messages will have a source MAC in the frame header that is different from the client MAC address in the DHCP payload, and rule 4 specifically disallows receiving DHCP messages that passed through a relay agent.

You could bypass those checks by configuring the physical port on the switch connected to the relay agent as a trusted port but that begs the question why we even bothered to enable the DHCP Snooping on that switch in the first place, since a trusted port is exempted from DHCP Snooping anyway and DHCP Snooping provides no protection for trusted ports.

So for practical purposes, enabling DHCP Snooping on this Cat9200 switch that has no directly connected DHCP clients and all of them being behind a relay agent just does not make sense.

@xzevallos , if I missed any intent of what you tried to accomplish please correct me!

And of course, any and all questions, opinions and corrections are welcome!

Best regards,
Peter

 

View solution in original post

@xzevallos,

DHCP snooping is primarily used to protect against rogue DHCP servers and unauthorized DHCP traffic within the same broadcast domain. In the case where DHCP clients are behind a DHCP relay agent, the relay agent itself is responsible for forwarding DHCP requests and responses to and from the DHCP server. Therefore, enabling DHCP snooping on the switch with the DHCP server is not only unnecessary but can also disrupt the DHCP communication between the relay agent and the server.

In your specific scenario, where all DHCP clients are behind a router acting as a relay agent, you should not enable DHCP snooping on the switch with the DHCP server. It should be disabled to ensure that the DHCP relay process functions correctly, allowing DHCP requests and responses to flow between clients and the DHCP server without interference.

Thanks to @Peter Paluch, for clarification.

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

View solution in original post

7 Replies 7

luis_cordova
VIP Alumni
VIP Alumni

Hello


You must configure the interfaces that participate in DHCP traffic as trusted.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9200/software/release/16-11/configuration_guide/ip/b_1611_ip_9200_cg/configuring_dhcp.html#concept_6493BE0255A1485284CA0F2E6A580BEA


Could you share the switch configurations?

Regards

xzevallos
Level 1
Level 1

Hello,

Here is my DHCP configuration.  It is in a lab but I want to implement this in production.

ip dhcp database flash:/dhcp-bindings write-delay 60
ip dhcp excluded-address 172.16.2.1 172.16.2.3

ip dhcp pool 1
 network 172.16.2.0 255.255.255.0
 default-router 172.16.2.1
 dns-server 57.1.1.14
 lease 7

interface Vlan201
 ip dhcp server use hardware-address client-id
 ip address 172.16.1.100 255.255.255.0

I tried to configure "ip dhcp snooping trust" under the VLAN interface but the switch does not accept it.

Hello


The command must be on the physical interface that has participation in dhcp traffic.
I hope that works for you.


Greetings

M02@rt37
VIP
VIP

Hello @xzevallos,

When you enable DHCP snooping on a Cisco switch, it becomes more selective about which ports it allows to relay DHCP requests to the DHCP server. By default, all switch ports are untrusted, and the DHCP snooping feature may block DHCP requests on untrusted ports.

On the  physical interface apply  the trust command. The physical interface is the one connecting to your router.

 

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

Peter Paluch
Cisco Employee
Cisco Employee

My friends,

Please allow me to join.

M02@rt37 , @luis_cordova - I humbly beg to differ. Configuring DHCP Snooping on the switch that operates as a DHCP server for clients behind a relay agent is, pardon me for being blunt, misplaced and useless.

Remember that the DHCP Snooping is used to protect against various attacks on DHCP-driven networks. This is done by very selectively accepting DHCP messages on untrusted and trusted ports and performing additional sanity checks on their contents. DHCP Snooping will drop DHCP packets under these circumstances:

1) Drop server-sent DHCP packets (OFFER, ACK, NAK, LEASEQUERY) received on untrusted ports. This is intended to prevent connecting an unauthorized DHCP server to the network, or having a computer impersonate a DHCP server.

2) Drop DHCP packets received on untrusted ports where the source MAC address of the frame and the client MAC address in the DHCP payload do not match. This is to prevent a host to send out DHCP packets on behalf of another host. Note that this covers both malicious client activity as well as DHCP relay agent operation.

3) Drop DHCP RELEASE and DECLINE messages received on untrusted ports where the client MAC address in the DHCP payload is associated with a different untrusted port in the snooping database. This is to prevent a host to specifically release or refuse an address on behalf of another host.

4) Drop DHCP messages received on untrusted ports that have non-zero GIADDR or that have Option 82 present. This is to prevent a host from impersonating a DHCP relay agent.

If a DHCP packet passed these checks, it will be accepted, but as for forwarding, if it is a packet received on an untrusted port (a client packet), it can only be forwarded out the trusted ports but never through other untrusted ports; a packet received on a trusted port (a server packet) will only be forwarded out the port toward the final client but never flooded (the switch will use the Option 82 contents, client's MAC address in the DHCP payload and the client's destination MAC address in this order to know what port to forward out the packet toward the client).

The gist of all these checks and changed forwarding rules is to prevent leaking the inherently broadcast-based DHCP communication to unintended hosts, prevent rogue DHCP servers from leasing IP addresses, and prevent hosts from trying malicious tricks on behalf of other hosts or relay agents.

The botom line is that the DHCP Snooping is distinctly an access layer defense and protection technique for a single broadcast domain at a time. It makes little sense to activate it on the distribution layer if the access layer has already been sufficiently protected, and it absolutely does not make sense to activate it on a switch that is not directly connected to the DHCP clients and that depends on a relay agent to forward the DHCP communication back and forth. Such a switch is in a different broadcast domain than the clients, and to implement protections here makes no sense as the communication between the DHCP server and relay agent is always unicast.

Note that the rules 2 and 4 above make it plainly impossible to reasonably use DHCP Snooping on such a switch. Rule 2 cannot be fulfilled because relayed DHCP messages will have a source MAC in the frame header that is different from the client MAC address in the DHCP payload, and rule 4 specifically disallows receiving DHCP messages that passed through a relay agent.

You could bypass those checks by configuring the physical port on the switch connected to the relay agent as a trusted port but that begs the question why we even bothered to enable the DHCP Snooping on that switch in the first place, since a trusted port is exempted from DHCP Snooping anyway and DHCP Snooping provides no protection for trusted ports.

So for practical purposes, enabling DHCP Snooping on this Cat9200 switch that has no directly connected DHCP clients and all of them being behind a relay agent just does not make sense.

@xzevallos , if I missed any intent of what you tried to accomplish please correct me!

And of course, any and all questions, opinions and corrections are welcome!

Best regards,
Peter

 

@xzevallos,

DHCP snooping is primarily used to protect against rogue DHCP servers and unauthorized DHCP traffic within the same broadcast domain. In the case where DHCP clients are behind a DHCP relay agent, the relay agent itself is responsible for forwarding DHCP requests and responses to and from the DHCP server. Therefore, enabling DHCP snooping on the switch with the DHCP server is not only unnecessary but can also disrupt the DHCP communication between the relay agent and the server.

In your specific scenario, where all DHCP clients are behind a router acting as a relay agent, you should not enable DHCP snooping on the switch with the DHCP server. It should be disabled to ensure that the DHCP relay process functions correctly, allowing DHCP requests and responses to flow between clients and the DHCP server without interference.

Thanks to @Peter Paluch, for clarification.

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.

xzevallos
Level 1
Level 1

Hello @Peter Paluch , M02@rt37 ,

Thank you so much for your detailed explanation, it is very helpful.  After reading it through, I understand that snooping is useless in my case, so I will not enable it.  

Review Cisco Networking for a $25 gift card