We are slowly starting to implement dhcp-snooping on our HP ProCurve 2610 series switches, all running the R.11.72 firmware. I'm seeing some strange behavior where dhcp-request or dhcp-renew
packets are dropped when originating from "downstream" switches due "untrusted relay information from client".
The full error:
Received untrusted relay information from client <mac-address> on port <port-number>
In more detail we have a 48 port HP2610 (Switch A) and a 24 port HP2610 (Switch B). Switch B is "downstream" of Switch A by virtue of a DSL connection to one of Switch A ports. The dhcp server is connected to Switch A. The relevant bits are as follows:
Switch A
dhcp-snooping
dhcp-snooping authorized-server 192.168.0.254
dhcp-snooping vlan 1 168
interface 25
name "Server"
dhcp-snooping trust
exit
Switch B
dhcp-snooping
dhcp-snooping authorized-server 192.168.0.254
dhcp-snooping vlan 1
interface Trk1
dhcp-snooping trust
exit
The switches are set to trust BOTH the port the authorized dhcp server is attached to and its IP address. This is all well and good for the clients attached to Switch A, but the clients attached to Switch B get denied due to the "untrusted relay information" error. This is odd for a few reasons 1) dhcp-relay is not configured on either switch, 2) the Layer-3 network here is flat, same subnet. DHCP
packets should not have a modified option 82 attribute.
dhcp-relay does appear to be enabled by default however:
SWITCH A# show dhcp-relay
DHCP Relay Agent : Enabled
Option 82 : Disabled
Response validation : Disabled
Option 82 handle policy : append
Remote ID : mac
Client Requests Server Responses
Valid Dropped Valid Dropped
---------- ---------- ---------- ----------
0 0 0 0
SWITCH B# show dhcp-relay
DHCP Relay Agent : Enabled
Option 82 : Disabled
Response validation : Disabled
Option 82 handle policy : append
Remote ID : mac
Client Requests Server Responses
Valid Dropped Valid Dropped
---------- ---------- ---------- ----------
40156 0 0 0
And interestingly enough the dhcp-relay agent seems very busy on Switch B, but why? As far as I can tell there is no reason why dhcp requests need a relay with this topology. And furthermore I can't tell why the upstream switch is dropping legitimate dhcp requests for untrusted relay information when the relay agent in question (on Switch B) isn't modifying the option 82 attributes anyway.
Adding the no dhcp-snooping option 82 on Switch A allows the dhcp traffic from Switch B to be approved by Switch A, by virtue of just turning off that feature. What are the repercussions of not validating option 82 modified dhcp traffic? If I disable option 82 on all my "upstream" switches - will they pass dhcp traffic from any downstream switch regardless of that traffic's legitimacy?
This behavior is client operating system agnostic. I see it with both Windows and Linux clients. Our DHCP servers are either Windows Server 2003 or Windows Server 2008 R2 machines. I see this behavior regardless of the DHCP servers' operating system.
Can anyone shed some light on what's happening here and give me some recommendations on how I should proceed with configuring the option 82 setting? I feel like i just haven't completely grokked dhcp-relaying and option 82 attributes.
