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.
You said that "dhcp relay isn't enabled"...but clearly it is, based on your show dhcp-relay output.
Try disabling it explicitly; based on the comments above I suspect your problem will go away :)
Actually, packet on switch A is getting drooped because you received a DHCP client packet with option82 on a untrusted port. This option-82 is inserted by the switchB.
I think below should work -
On, SwitchB - disable option 82 so that this does not insert these options. mark the interface-25 as trust to allow DHCP server packet to flow down to the.
On , SwitchA- You can keep option-82 enabled/disabled here. it shouldn't matter. mark the port which is connected to switchB as un-trusted. mark the port which is connected to the dhcp-server as trusted.
I think you might be misinterpreting the idea of a trusted port. I agree that trusting only the ports from which the offers are coming is intuitive but my understand is that you need to trust the trunk port on Switch A as well. You mark ports trusted that are connected to equipment that you know and trust. Just because you mark the trunk on Switch A as trusted does not mean you're going to allow a rogue DHCP server to exist on switch B. If setup correctly, switch B doesn't trust any port other that its trunk as well so you have still prevented a rogue DHCP server from sitting on switch B and sending offers to clients on switch A.
In short, you are supposed to trust ports connected to your own DHCP servers and ports connected to other switches that you manage (so you can be sure that there aren't any other trusted ports).