dhcp-snooping option 82 drops valid dhcp requests on 2610 series Procurve switches

Question

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.

Solution 1

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 :)

Solution 2

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.

Comments

[Bad Dos]

Are the dhcp servers on the same subnet or are they being relayed by a router? I know cisco routers/l3 switches require ip dhcp relay information trust-all command if they are doing the dhcp forward.

[Admin]

They are on the same subnet. Everything is completely flat from a Layer-3 perspective.

[Bad Dos]

Does DHCP function properly if you plug say a laptop into the switch that is directly connected to the dhcp server? Maybe one of the uplinks in your switch topology isn't trusted.

[Admin]

Yes. It works when machine is connected to the same switch as the DHCP server. I don't trust the uplink port on the upstream switch. You only trust ports that the DHCPOFFER or DHCPACK packets are coming from - the port the DHCP server is attached to. If I trusted the Trunk port on the upstream switch, the switch would allow a dhcp server to respond across that uplink to its clients. FWIW, I have a support request in the with HP and they seem similarly baffled.

[Bad Dos]

I'm not familiar with HP, but in Cisco you would trust the uplink port on the access switch, but the switch it connects to would not trust that port. This ensures dhcp offers can flow down to the access switch, but that nothing from the access switch comes up and no other ports on the access switch are trusted either.

[Admin]

Maybe HP does things differently. You only set the trust the ports that your DHCPOFFERs or DHCPACKs are coming from, which in this case is the port the DHCP server is connected to on the upstream switch, and the trunk on the downstream switch.

[Dan Pritts]

You said that "dhcp relay isn't enabled"...but clearly it is, based on your show dhcp-relay output. Try disabling it explicitly.

[Admin]

@DanPritts - I revisited this issue since I had some spare time this week. You are absolutely correct. Even though dhcp relaying is not explicitly enabled it is on, presumably by default. Turning off dhcp relay yielded the correct behavior. You should write an answer so I can mark it as accepted.