Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

DHCP Snooping preventing device roaming?

Okay, So I have a bunch of 2960 edge devices that all have DHCP snooping and port security enabled (standard configurations, no sticky mac's but a 5 address limit on the interfaces I'm having trouble with, configs below). I also have a number of Small Business 8 port switches dotted around the place to increase port capacity (under tech's desks mostly). The problem arises in the following situation;

There are 2 2960's, 2960-1 and 2960-2. Attached to 2960-1 are two unmanaged 8 port SB switches, switchA and switchB.

When wiring a laptop into switchA everything is cool, DHCP address is assigned and everything is happy, however, when that device is then patched into switchB, the mac address table, port-security cache and DHCP snooping bindings table do not update, and since port security is nailing all macs to SecureDynamic (which in the CAM appears as STATIC), this is not surprising. I clear the port security address table, clear the CAM table for the relevant interface and clear the ip dhcp binding for the address in question and still nothing, laptop see's the connection but DHCP resolutely refuses to pick up an address. Wireshark confirms that the laptop is sending out the DHCP discover messages but nothing comes back. The only way to get the device talking again is to patch it into the original cable in switchA. Patch the device into 2960-2 however and everything is cool. #update Also, if a static address is assigned the problem disappears, predictably.

I'm pretty sure that the problem stems from these unmanaged switches but need to know if I'm missing something vital.

Any help is much appreciated!

relevant config;

ip dhcp snooping vlan 2002,2026

ip dhcp snooping

network-policy profile 2026

voice vlan 2026

interface GigabitEthernet3/0/1

description EDGE PORT

switchport access vlan 2002

switchport mode access

switchport port-security maximum 5

switchport port-security

network-policy 2026

srr-queue bandwidth share 1 30 35 5

priority-queue out

mls qos trust cos

macro description EDGE

auto qos trust

storm-control broadcast level bps 5m 2m

storm-control multicast level bps 30m 20m

storm-control action shutdown

storm-control action trap

spanning-tree portfast

spanning-tree bpduguard enable

Thanks again!

8 REPLIES
Bronze

DHCP Snooping preventing device roaming?

Is this a 2960 stack we are talking about here?

Are these two unmanaged switches connected to the same interface on 2960-1 ?

New Member

DHCP Snooping preventing device roaming?

They are two independent stacks, so we are talking two distinct logical devices. The un-managed switches are connected on different interfaces, switchA on 2/0/25 and switchB on 3/0/1.

Bronze

Re: DHCP Snooping preventing device roaming?

Can I see the output of:

#show ip dhcp snooping statistics detail

My initial thoughts are that it may have to do with DHCP option 82 being inserted (it is on by default).

You can try disabling it by entering the global command:  (Unless you are running an environment where this option is absolutely necessary, for most it is not)

no ip dhcp snooping information option

New Member

DHCP Snooping preventing device roaming?

Hi

I am having exactly same issue where mini switches are connected to an access layer switch with the port on the access layer switch being configured with port security.  When a device is disconnected from the mini switch the devices mac remains as a secure address on the access layer switch port and therefore is not cleared from the CAM table.  I fixed the issue of the devices mac address being stuck in the CAM table by enabling an inactivity aging timer in the port security config, ie.

switchport port-security aging type inactivity

switchport port-security aging time 2

By doing this the inactivity timer disassociates the mac from the port and thus the mac is removed from the CAM table, so then when the device is connected to another switch port either directly or via another mini switch the switch receives a frame from an unknown mac and associates the mac with the new switch port.  Okay, so that's all fine.  However, the device cannot pickup an IP with DHCP (static IP works fine).  When I disabled dhcp snooping on the access layer switch AND the core layer switch which relays the DHCP broadcasts everything works fine.  Like above I tried clearing the DHCP snooping binding entry but this didn't solve the problem.

Can someone help with explaining whether removing the option-82 would help and if so why ?

Thanks

New Member

DHCP Snooping preventing device roaming?

update:

tried disabling the option-82 which didn't help.

Here is the DHCP snooping statistics output (show ip dhcp snooping statistics detail)

From the Access Layer Switch:

Packets Processed by DHCP Snooping                    = 2481

Packets Dropped Because

   IDB not known                                       = 0

   Queue full                                          = 0

   Interface is in errdisabled                         = 0

   Rate limit exceeded                                 = 0

   Received on untrusted ports                         = 0

   Nonzero giaddr                                      = 0

   Source mac not equal to chaddr                      = 0

   No binding entry                                    = 0

   Insertion of opt82 fail                             = 0

   Unknown packet                                      = 0

   Interface Down                                      = 0

   Unknown output interface                            = 0

   Misdirected Packets                                 = 0

   Packets with Invalid Size                           = 0

   Packets with Invalid Option                         = 0

From the Core switch (where the DHCP requests are relayed)

Packets Processed by DHCP Snooping                    = 890993

Packets Dropped Because

   IDB not known                                       = 0

   Queue full                                          = 0

   Interface is in errdisabled                         = 0

   Rate limit exceeded                                 = 0

   Received on untrusted ports                         = 0

   Nonzero giaddr                                      = 3

   Source mac not equal to chaddr                      = 0

   No binding entry                                    = 0

   Insertion of opt82 fail                             = 0

   Unknown packet                                      = 0

   Interface Down                                      = 0

   Unknown output interface                            = 11

   Misdirected Packets                                 = 0

   Packets with Invalid Size                           = 0

   Packets with Invalid Option                         = 0

There are clearly some dropped packets here but I don't understand why ?

New Member

DHCP Snooping preventing device roaming?

Update:

Issuing the following global config command fixes these issues:

authentication mac-move permit

This enables the authorised MAC addresses in the snooping binding table to be reassigned to the new port where the device is connected.

Bronze

DHCP Snooping preventing device roaming?

Interesting, however, you don't seem to be using any 802.1x authentication on your ports, for which the "authentication mac-move permit" command was created. Would the command also have an effect on a normal port-security + dhcp snooping, but non 802.1x port ?

New Member

DHCP Snooping preventing device roaming?

I agree with you.  However according to TAC which provided this as the fix for this issue I understand that firstly this used to be the default on earlier versions of IOS and secondly that dot1x is actually there even if not enabled with the ports in a permanent authorised state.  Given that we don't have dot1x port authentication enabled and this clearly fixed the issues I can only conclude there is obviously an impact on non dot1x ports.  If you can shed anymore light as to why this is the case I would welcome any further comment/discussion.

1730
Views
0
Helpful
8
Replies
CreatePlease login to create content