Hi Daniel
Yes that is correct. It can get confusing, sometimes the documentation is difficult to decipher, but that’s what we’re here for!
I hope this has been helpful!
Laz
was wondering how to configure the DHCP snooping across multiple switches ?
do i need to enable the trust command on the trunk interface and configure dhcp globally on all the switches ?
Hello Soufiane
DHCP snooping is not a feature that requires communication between switches in order to be enabled across multiple devices. There is no negotiation between switches involved to make it work. DHCP snooping operates on a per-interface basis. For example:
- Untrusted ports will drop any incoming DHCP OFFER packet
- Trusted ports will accept all incoming DHCP OFFER packets
- Untrusted ports can be configured to rate-limit incoming DHCP DISCOVER packets
Now if you have multiple switches, then it is necessary to make all of the DHCP-server-facing interfaces trusted. In other words, based on your topology, any port that can expect to see legitimate incoming DHCP OFFER packets from the DHCP server should be trusted. For example, in this topology:
…you can see that ports that can be expected to receive DHCP OFFERS from the upstream DHCP server are made trusted.
Unless you have some specialized requirements, the basic rule of thumb is indeed to make ports that connect switches trusted ports, and ports that connect to hosts untrusted ports.
I hope this has been helpful!
Laz
Thank you for the explanation, so my concern is the global dhcp command that need to be applied on all of the devices where there is Trusted port right ?
Hello Soufiane
Any device that will be performing DHCP snooping must have the global ip dhcp snooping command configured. This means that if you need to configure trusted and untrusted ports on a switch, you must enable snooping on that device using this command.
Now, if you have a switch in your topology that is connected only to other switches, and not to any hosts, and if you configure DHCP snooping on all of the switches connected to it, theoretically, you don’t need to enable DHCP snooping on that particular switch. This is because all trusted/untrusted ports should already be configured on all of the other devices.
Even so, it is best practice to enable DHCP snooping on all devices in your topology to ensure that even if there is a topology change or even a configuration change by an administrator, any unauthorized DHCP messages will still be “caught” by this switch.
I hope this has been helpful!
Laz
SW1(config)#interface fa0/1
SW1(config-if)#ip dhcp snooping limit rate 10
Shouldn’t the rate limit be applied on Fa0/2 instead of Fa0/1 ?
Hello Atul
The purpose of the rate-limiting of DHCP packets in this particular case is to limit the number of DHCP messages sent by the host. Hosts can send DHCP Discover and DHCP Request packets. It is unusual for a host to send too many of these, so anything beyond a certain threshold can become suspicious, so it is useful to rate-limit these. More info on the types of packets sent in DHCP can be found here.
Now you can rate-limit DHCP packets on a trusted port, such as Fa0/2 in the lesson where the DHCP server is connected. However, this should be done with caution as DHCP servers may need to send many DHCP messages at particular times (like in the morning when all users turn on their PCs for example), so it is more difficult to determine what kind of limit to put there. In any case, a rate limit on a trusted port is not that useful, since it is trusted, and you expect DHCP packets to appear on that interface anyway. But these are the principles to keep in mind.
I hope this has been helpful!
Laz
1 Like
Awesome… Thanks Laz 
1 Like
Hi Lazaros, here is a dilemma , i do have a 3 vlan ( 30,31,35) configured via sub interfaces in a cisco FTD and connected to L3/L2 switch, dhcp seem to be working on the switch for 10 and 11 that have the default gateway configured on the switch itself with the helper-address.
even puting the dhcp snooping trust command on the port switch connected straight to the sub interfaces in the FTD, didn’t resolve the issue.
have you seen a scenario like that before ? and if you can give me a suggestion please .
i do have a year subscription with networklessons.
Thanks.
Hello Soufiane
I’m not sure I fully understand the problem. What I understand is that you have an FTD with a trunk connection to an L3 switch, carrying VLANs 30, 31, and 32 via subinterfaces on the FTD. Your DHCP is working for VLANs 10 and 11. I don’t quite understand where your problem is. What isn’t working the way you expect it to? Can you clarify?
Thanks!
Laz
In the DHCP Snooping lesson, it basically appears as though you should mark any port in which a DHCP Offer message must ingress so that the client can get its IP address from DHCP. However, in your illustration, it seems as though the trunk port in the top right switch should also be trusted. Is that not the case? Perhaps that in that illustration that port is intended to be shown in an STP blocking state? But regardless, that can always change so shouldn’t that port also be trusted?
In the DHCP Snooping lesson, it basically appears as though you should mark any port in which a DHCP Offer message must ingress so that the client can get its IP address from DHCP. However, in your illustration, it seems as though the trunk port in the top right switch should also be trusted. Is that not the case? Perhaps that in that illustration that port is intended to be shown in an STP blocking state? But regardless, that can always change so shouldn’t that port also be trusted?
Hello @mcpp66 ,
I agree, and I just changed this. When the link from the top left to switch to the bottom left switch fails, traffic would go through the top right switch, so it should be a trusted port.
Rene
Hello Mike
Strictly speaking, yes, that port should also be trusted since some DHCP messages may be received on that port, assuming the STP topology may change. And if it does, DHCP would fail. I will let Rene know to consider making the change on the diagram.
Thanks for pointing that out!
Laz
“interface that is untrusted will block DHCP offer messages.” I did not understand that when I first went through this lesson. I understood it as this, if not trusted port, DHCP wont work. That is wrong. . .untrusted just means it can not send OFFER messages. . . which are needed (if you are a dhcp server). Untrusted ports can work just fine for dhcp clients. Took me a while of doing this in the labs on my switches. . . .then I realized. Had to lab it up, to get that concept.
Hello Rod
Thanks for the insight into how the specific topic is perceived.
I essence, that is what we’re saying. If you have a DHCP server connected to an Untrusted port, then DHCP will not work. Offer messages are vital to allow DHCP to function correctly. However, untrusted ports should have only clients connected to them. They should not be relaying OFFER messages sent by DHCP severs that may be directly connected, or may be upstream to the switch itself.
This just goes to show how important labbing things up is! It really helps you to get your head around all of these concepts.
I hope this has been helpful!
Laz
Hello Team
As i know the command
# ip dhcp snooping limit rate 10
Should be apply on all interfaces that connect with end device right ? Because this will prevent end devices to send discover messages and protect dhcp server from losing addresse pool ,
so in lab why you didn’t apply on both interfaces PC + hacker ? As i think now hacker can send many dhcp discovery messages Because not limit on his interface but he cannot send dhcp offer becuae already applied untrusted port on it
Hello Barakat
Yes, the ip dhcp snooping limit rate 10 command should typically be applied to all untrusted ports to prevent devices from sending DHCP messages more frequently than necessary. In the lesson, ideally, this command should be applied to the Fa0/3 interface as well.
Typically, the rate limit applies to the untrusted interfaces. If you want to set up rate limiting for the trusted interfaces, you must keep in mind that trusted interfaces aggregate all DHCP traffic in the switch, so you will typically have many more DHCP messages on such a port, so you will need to adjust the rate limit of the interfaces to a higher value.
For more information about this command, take a look at this Cisco command reference documentation:
I hope this has been helpful!
Laz
Hello Shrikant
Thanks for sharing your diagram. I’m not sure what your question is, however, it seems that you are wondering about applying DHCP snooping to a trunk port.
You can apply DHCP snooping to a trunk port, and in fact, it’s common to do so in scenarios where you have multiple VLANs and you want to ensure DHCP integrity across them.
DHCP snooping works by filtering and allowing DHCP messages on specific ports, regardless of whether those ports are access or trunk ports. When you enable DHCP snooping on a VLAN, it applies to all ports that are members of that VLAN, including trunk ports that carry the VLAN in question.
If you have a more specific question about your shared topology, let us know!
I hope this has been helpful!
Laz