yet another DHCP Snooping problem

[scott.hammond]

We have had a rash of problems with rogue DHCP servers of late so its time to bite the bullet and enable snooping. Problem is I cant get it to work.

With it enabled the test phone cant get an IP from the production DHCP server but rather it will only pull one from the "rogue" server that is untrusted.

I have tried every option, every variation, all vlans did nothing, turning off option 82 did nothing, tried using the database, nothing...I just never see bindings.

Please help!

I have a C3560CPD-8PT-S

ip dhcp snooping vlan 154

ip dhcp snooping

!

interface GigabitEthernet0/4 < Cisco phone

switchport access vlan 154

switchport mode access

spanning-tree portfast

ip dhcp snooping limit rate 100

!

interface GigabitEthernet0/8 < cisco 2811 playing the part of the rogue DHCP server

switchport access vlan 154

switchport mode access

spanning-tree portfast

ip dhcp snooping limit rate 100

!

interface GigabitEthernet0/10 < uplink to the Windows DHCP

switchport trunk encapsulation dot1q

switchport trunk allowed vlan 1,43,154,200,1000

switchport mode trunk

ip dhcp snooping trust

!

interface Vlan1000 < The L3 management interface

ip address 10.60.250.115 255.255.255.0

!

comms_temp_s01#show ip dhcp snooping

Switch DHCP snooping is enabled

DHCP snooping is configured on following VLANs:

154

DHCP snooping is operational on following VLANs:

154

DHCP snooping is configured on the following L3 Interfaces:

Insertion of option 82 is enabled

   circuit-id default format: vlan-mod-port

   remote-id: 5897.1ed1.2280 (MAC)

Option 82 on untrusted port is not allowed

Verification of hwaddr field is enabled

Verification of giaddr field is enabled

DHCP snooping trust/rate is configured on the following Interfaces:

Interface                  Trusted    Allow option    Rate limit (pps)

-----------------------    -------    ------------    ----------------  

GigabitEthernet0/1         no         no              100      

  Custom circuit-ids:

GigabitEthernet0/2         no         no              100      

  Custom circuit-ids:

GigabitEthernet0/3         no         no              100      

  Custom circuit-ids:

Interface                  Trusted    Allow option    Rate limit (pps)

-----------------------    -------    ------------    ----------------  

GigabitEthernet0/4         no         no              100      

  Custom circuit-ids:

GigabitEthernet0/5         no         no              100      

  Custom circuit-ids:

GigabitEthernet0/6         no         no              100      

  Custom circuit-ids:

GigabitEthernet0/7         no         no              100      

  Custom circuit-ids:

GigabitEthernet0/8         no         no              100      

  Custom circuit-ids:

GigabitEthernet0/10        yes        yes             unlimited

  Custom circuit-ids:

comms_temp_s01#

[Peter Paluch]

Hi Scott,

This is strange. Did you indeed post the exact configuration from the switch performing the DHCP Snooping? Is it by any chance possible that the IP phone is communicating in a different voice VLAN than the 154? Usually, a port towards a Cisco IP phone is configured using switchport voice vlan - are you using a different IP phone?

Best regards,

Peter

[scott.hammond]

No voice vlans, but the phone seems to be the problem. Tried it with my macbook and it worked as it should. (with option 82 disabled)

Then I did a factory reset on the phone and it reloaded firmware, now it is working without fail. So it looks like I beat my head against the wall all this time thanks to a squirrely phone.

Confirmed with another random laptop it is working as it should. Thanks for the reply.

[Peter Paluch]

Hello Scott,

Well... it is possible that the phone somehow retained the old IP address and did not really obtain it from the rogue DHCP server. Good point.

Anyway, why did you deactivate the Option-82 insertion? Is it giving you any troubles?

Best regards,

Peter

[scott.hammond]

it wouldnt work with it enabled......

not that I admit to understanding what it does exactly, I saw endless threads about it with most people saying it wasnt needed. So I tried it and it worked without it just fine.

I started to read the documents on what it did and about one paragraph in I started thinking dark thoughts and listening to country music. So I thought I should leave it be and just think happy thoughts.

[Peter Paluch]

Hi Scott,

Well, the Option-82 is actually a very useful option helping the switch to forward the DHCP server's response back only through the very switchport the client's original query was received on. Sadly, some DHCP server implementations have troubles processing it (they actually are not supposed to process it at all - they are simply supposed to just put it back into each reply they sent to such a marked query). Also, Cisco's DHCP implementation is trying to be very sane to the point of refusing DHCP messages carrying Option-82 in certain circumstances.

I wonder - are you using a DHCP Relay between your IP phone and the Windows DHCP server? Or is the IP phone on the same VLAN as the DHCP server? Perhaps we can make the Option-82 work after all.

Regarding the Option-82 and its purpose, please check these threads if you haven't already:

https://supportforums.cisco.com/thread/2089454

https://supportforums.cisco.com/thread/2060498

https://supportforums.cisco.com/thread/2117566

I admit - it is not an easy reading but the point is that if it does not work with Option-82, something else is broken in your network and we should fix that instead.

Best regards,

Peter

[scott.hammond]

The dhcp server is in the server farm, far far away. We use helper addresses on the SVI's or subinterfaces whatever the case may be.

Reading the threads now. (went and bought some tequila)

[Peter Paluch]

Hi Scott,

Oooh, I'd have some tequila, too

Anyway, this issue may actually boil down to configuring the ip dhcp relay information trusted on the very SVIs or subinterfaces where you also happen to have the ip helper-address command configured.

Best regards,

Peter

[scott.hammond]

and the survey says!

we cant use option 82

windoze 2k3

[Peter Paluch]

Hi Scott,

Can you post a reference to the article that says this? If that's true then - well, oh, Windows... I should have known there's gonna be trouble with that bloody thing

Best regards,

Peter

[scott.hammond]

our AD admin says no.

Quick google says no.

that said...I enabled the relay trust and it might have worked. Doing some testing now, will let you know.

[scott.hammond]

confirmed on a segment behind an SVI as well as a segment behind a sub-interface that option 82 works with the relay trust command. (with a dhcp server that doesnt support option 82)

now the question becomes...is it worth it?

I would have to modify about 200 SVI's and around 500 subinterfaces to make it happen. Or I could not use it and only modify the access switches alone.

(bear in mind its less about the work and more about getting the rest of the team on board with a new standard on subinterfaces)

[Peter Paluch]

Hello Scott,

I have always considered the Option-82 to be a useful feature to help the switch contain the possibly broadcasted DHCP response back only to the client to whom it belongs. We could argue whether it indeed brings a significant improvement in security. In general, a DHCP server response received on a trusted port is forwarded by a DHCP Snooping switch according to this algorithm:

• If the Option-82 is present and was inserted by this switch, forward the frame only through the port identified in this option. If the Option-82 is present but was not inserted by this switch, or if it is missing, proceed to the next step.
• From the DHCP message, read the MAC address of the client from the chaddr field (Client Hardware ADDRess) and look it up in the CAM table. If found, forward the message through the identified port. If the CAM lookup fails, proceed to the next step.
• From the frame that carries the DHCP message, read the destination MAC address field from the Ethernet frame header and look it up in the CAM table. If found, forward the message through the identified port. If the CAM lookup fails, drop the frame. Note that this also includes a broadcast destination MAC.

Note that the Option-82 is actually used only by the switch that originally inserted it. Then again, these are usually the only switches that run the DHCP Snooping (you run the DHCP Snooping on the access layer only - it makes no sense to run it on distribution layer switches, as the DHCP traffic has already been sanitized at the network edge). If a topology change event occured resulting into the CAM table being flushed, the CAM lookups would fail. The Option-82 helps here to contain and assist the frame delivery.

Instead of configuring the ip dhcp relay information trusted on SVIs and subifs individually, there is a global level configuration command ip dhcp relay information trust-all. You could configure this on a per-box basis, as opposed to per-interface basis. Perhaps this could be a workable compromise.

Let me know your opinion on this. And - thank you for your patience! Many people would be just happy with having the thing work... somehow. I appreciate you are willing to try out different approaches.

Best regards,

Peter

[scott.hammond]

The global command works well. However! Now I am having issues where I have several access switches connected together. The next topology I tested was Router>SwitchA>SwitchB

Router with trust all and Switch A snooping worked fine.

Switch B would not work unless I stripped 82. Tried the global relay trust on Switch A and Switch B hosts still could not get IP's... Thoughts?

[Peter Paluch]

Hello Scott,

The ip dhcp relay information trust-all command relates only to the operation of DHCP Server and DHCP Relay Agent. It does not influence the operation of a DHCP Snooping switch, that's why it had no effect.

Are your switches interconnected by trusted ports? Are the links between your switches configured using ip dhcp snooping trust on both ends? It is possible that you are hitting a situation where the DHCP Snooping switch is dropping DHCP messages containing Option-82 on untrusted ports because of the following rule:

The switch drops a DHCP packet when one of these situations occurs:

[cut]

• A DHCP relay agent forwards a DHCP packet that includes a relay-agent IP address that is not 0.0.0.0, or the relay agent forwards a packet that includes option-82 information to an untrusted port.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/15.0_2_se/configuration/guide/swdhcp82.html#wp1078853

Best regards,

Peter