Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
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. –  Bad Dos May 13 '12 at 20:09
    
They are on the same subnet. Everything is completely flat from a Layer-3 perspective. –  kce May 14 '12 at 17:52
    
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. –  Bad Dos May 15 '12 at 15:12
    
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. –  kce May 16 '12 at 17:56
    
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. –  Bad Dos May 17 '12 at 1:51
show 3 more comments

2 Answers

up vote 1 down vote accepted

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

share|improve this answer
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.