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.
