03-21-2012 09:08 AM - edited 03-07-2019 05:42 AM
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!
03-21-2012 01:03 PM
Is this a 2960 stack we are talking about here?
Are these two unmanaged switches connected to the same interface on 2960-1 ?
03-22-2012 01:24 AM
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.
03-22-2012 09:51 AM
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
08-03-2012 06:42 AM
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
08-03-2012 07:14 AM
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 ?
09-06-2012 07:03 AM
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.
09-06-2012 09:20 AM
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 ?
09-07-2012 09:38 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: