I had some problems on a Cat4500/Sup4 12.2(31)SG and had to open up a TAC case. I got good help right away and I think the issues are worked out.
But the TAC engineer said something that really surprised me. He said they almost never see customers doing all of them. He said usually just port-security or DHCP snooping. This really surprised me.
Is anyone doing all of these, just a few, why? Have you tried? Comments.
We have experimented with various combinations of those features, and after numerous "bug bites", we've stepped back somewhat. While following up on some of the bugs that affected us, I found that Port Security, DHCP Snooping, and DAI should work well together, but IP Source Guard shouldn't be used when DHCP Snooping and Port Security are configured. I can't find the citation right now, but I do have the note I left myself to that effect. I haven't yet tested that combination outside the lab, so there may be issues, but I'm anxious to try. We're running 12.2(25)EWA5 on our 4500's, as 12.2(18)EWx didn't seem to work at all well with DHCP Snooping (all DHCP was blocked, iirc).
I too just got back from Networkers and attended this session, and found that the problems we had all stemmed from documentation issues. When IP Source Guard is enabled, only use the "port-security" option to enable MAC checking if you are using Option 82. That was the issue we had, and we're now going to be redeploying the entire suite.
Yea, I had that on the IP Source Guard command at one time, TAC said to remove.
Here is what we are running on our new limmited production VLAN and associated interfaces.
ip dhcp snooping vlan 66
ip arp inspection vlan 66
switchport access vlan 66
switchport mode access
macro description cisco-desktop
spanning-tree bpduguard enable
ip verify source vlan dhcp-snooping
I'm not sure what "port-security" adds to the line "ip verify source vlan". Since we only allow 1 MAC per interface, plus don't do STICKY, it would seem that the MAC verification is done the port-security function. I've tested it (spoofing) and port-security still shuts down the port when two MACs have been sensed by the switch.
So kofflerg, how big is your rollout of all these features? Successes, failures, etc..
So far the rollout is fairly small, as we've been pretty busy with other projects. However, when I have time to fix anything that might break, we'll be trying it on an entire university campus, about 20k ports on 350ish switches.
I just got back from Cisco Networkers 2006 and I heard about this. I'm planning on implementing at least the DHCP Snooping. Whats your experience been like? Any traps I need to watch out for.
We have all features running on 5 users in production (we were put in a new network/VLAN). We have DHCP Snooping, Port-Security (1 MAC per interface), DAI, and IP Source Guard going.
The stationary users (3 desktops) have not had a single problem. Laptops have been mixed. One laptop user (my coworker) has not had a single problem. My laptop had one irregular incident.
It obtained an IP Address, and then shortly after, the laptop OS (XP) requested a different, specific IP Address on the same network. This was sourced as an IP Unicast, DHCP Request, Option 50, it was sent to L2/L3 broadcast, all Fs. Why in the world the OS requested a specifically different IP Address, I have no idea. The Router, its running IP Helper, responded with a L2/L3 broadcast, all Fs, with the specific request granted. I saw all of this because I did an Ethereal capture on the laptop after the problem began, numerous reboots of the laptop did not clear the problem.
The problem begins somewhere within the Cat45K. The ?sh ip dhcp snooping binding? says my MAC address matches with the original IP Address. Port-Security shows my Interface was Secure-Up. However, ?sh ip verify source? shows my MAC address is mapped to the specifically requested IP address, but the laptop NEVER took on the specifically requested IP Address, even though the OS requested it numerous times. So consequently, no IP communication was permitted.
The PC didn?t take the IP address is asked for, plus DHCP Snooping and IP Source-guard were not on the same page. The genuine source of this problem, I am not 100% sure.
This was on a Cat45K, Sup4, 12.2(31)SG.
There is a TAC Case open, Cisco TAC is trying to duplicate the event. I hope that they are concerned, since DHCP Snooping and IP Source-guard were not on the same page.
it was either the lan protocols troubleshooting class or the troubleshooting the catalyst 3750 and the troubleshooting catalyst 4000 series classes. i'm pretty sure both of the ladder touched up on it.