Hello Harley,
That statement is confusing indeed. The DHCP Snooping seems to be one of those techniques which got explained badly some time in the past, and all the documents now seem to carry the bad legacy
Let me talk a little more about the basics of the DHCP Snooping. The point of DHCP Snooping is to prevent against several potential security issues when using DHCP service:
- Client DHCP messages are usually broadcast and therefore delivered to all stations, not just to the DHCP server
- Server DHCP replies may be unicast but their destination may not be currently known, or they may be broadcast, again causing them to be received also by other stations, not just the intended recipient
- It is possibly, either inadvertently or maliciously, to connect an unauthorized, rogue DHCP server into the network with all the disruptive effects
- DHCP messages may be maliciously injected into the network by attackers
- Attackers may try to exhaust the DHCP pools
DHCP Snooping tries to solve these problems by defining ports on the switch as trusted and untrusted. The trusted ports are generally uplinks towards DHCP servers, while untrusted ports are the ports where clients are connected.
When a DHCP message is received, the switch will drop it if it meets one of the following criteria:
- A packet from a DHCP server, such as a DHCPOFFER, DHCPACK, DHCPNAK, or DHCPLEASEQUERY packet, is received on an untrusted port
- A packet is received on an untrusted interface, and the source MAC address and the DHCP client hardware address do not match
- The switch receives a DHCPRELEASE or DHCPDECLINE broadcast message that has a MAC address in the DHCP snooping binding database, but the interface information in the binding database does not match the interface on which the message was received
- An untrusted port receives a DHCP message that includes a non-zero relay-agent IP address, or that includes Option-82 information option
If the DHCP message was not dropped and was received on an untrusted interface, the switch will insert the Option-82 to identify the exact switch and its port that received this message, and will forward the message only through trusted ports. Furthermore, when a DHCP message (a response) arrives through a trusted port, the switch will examine the Option-82 present in this message, and will forward it only if this switch is the one that has forwarded the original request, and will forward it only through the particular interface on which the original request was received (this information is carried in the Option-82). This prevents leaking the messages to other stations.
The DHCP Snooping is therefore best activated immediately on the access layer switches, and hence is not required anymore in deeper layers of the network (distribution, aggregation, core) because all DHCP messages should have been properly sanitized at the network edge.
There are situations, mostly in service provider environments, when your access layer switches do not support the DHCP Snooping but for whatever reason, they insert the Option-82 into the DHCP messages. This is often done to identify a particular client to the DHCP server to provide a customized profile for the customer (think FTTx, PON - many STB boxes use this option when initializing their IP stack). These access layer switches are usually connected to distribution layer switches which are also called aggregation switches. Now, you would like to perform the DHCP Snooping on these distribution = aggregation switches. However, this poses a huge problem according to the rules commented so far:
- If you define the ports towards access switches on the aggregation switch as untrusted, the DHCP messages will be dropped because they already contain Option-82 (see the last rule about discarding DHCP messages on untrusted ports)
- If you define the ports as trusted then no DHCP Snooping database entries will be populated on these ports. DHCP Snooping database is populated only from DHCP messages on untrusted ports.
In any case, with what we have discussed so far, you would not be able to run the DHCP Snooping in this network on the aggregation switches successfully.
This is what the document you've referenced in your original post talks about. If - and only if! - you have a similar topology, i.e. access switches unable to perform DHCP Snooping but inserting the Option-82 into DHCP messages - you will need to allow the aggregation switch to accept DHCP messages containing the Option-82 on its untrusted ports. That can be done either in the global config mode for all untrusted ports or on individual interfaces using the ip dhcp snooping option allow untrusted command. It is a workaround but it allows you to have the downlinks on the aggregation switch defined as untrusted, and perform the usual DHCP Snooping on them.
Please note that if you have a network that supports DHCP Snooping on its access layer then this workaround is not necessary at all. As I have explained earlier, in a properly designed network, all clients are connected to the access layer, and if the access layer uses DHCP Snooping, there is no point in running it on distribution layer.
I've seen recommendations to disallow the insertion of the Option-82 into DHCP messages. In 99.9% of cases, that is a totally bad idea. The Option-82 very strongly helps the DHCP Snooping to prevent leakage of the DHCP messages to unintended recipients. Without Option-82, this fantastic advantage is totally lost.
I hope this helps a bit.
Best regards,
Peter
