Article ID: 12682
Products
SecureStack C3, firmware 1.02.01.0004 and higher
SecureStack C2, firmware 5.02.01.0006 and higher
SecureStack B3, firmware 1.02.01.0004 and higher
SecureStack B2, firmware 4.02.01.0006 and higher
G-Series, firmware 1.02.00.0043 and higher
D-Series, firmware 6.03.01.0008 and higher
Changes
Configured DHCP Snooping ('set dhcpsnooping...')(
12008).
A client on a trusted port ('set dhcpsnooping trust port <
port-string> enable') attempts to get an IP address assignment via the DHCP process.
Symptoms
The DHCP process does not complete successfully.
The client does not receive an IP address.
Cause
Only trusted DHCP
servers - not DHCP
clients - should be connected on trusted ports.
By design, DHCP packets from DHCP clients connected on trusted ports get forwarded without creating the tentative binding for that host/DHCP client. When the DHCP server (on a trusted port) responds to the DHCP client message, because DHCP Snooping doesn't have the host/client binding information it drops the DHCP server's response packet to the client.
What is seen on a sniffer trace is that the server responds to the client's Discover request by sending a pair of Offer responses, one using destination UDP port 67 (to notify other servers) and one using destination UDP port 68 (to negotiate with the client). The switch as explained above drops the port 68 traffic, so the client never sees the server's attempt to negotiate. Though the client repeatedly tries to Discover a DHCP server, it never succeeds.
Solution
Functions as Designed (FAD).
Place any DHCP
client behind a DHCPSnooping
untrusted port ('set dhcpsnooping trust port <
port-string> disable'). Note that "untrusted" is the default state for a port.
Also note that the FAD expectations have been changed as of firmware 6.61.07.0010.
G/C5/C3/B5/B3/A4 release notes state, in the 'Changes and Enhancements in 6.61.07.0010' section:
17362 & 17619 Addressed an issue which prevented DHCP to function properly on trusted ports when DHCP snooping was enabled.
