Team,
Last evening (Christmas eve) we setup a pair of Cisco 3850 with IP Base version 3.3.35SE (recommended) and 3.7.0E (very latest).
We got these to replace a very old switch that had died. Attached to this network are windows 7 PC's with all the standard patches, service packs, etc.
with standard port configs - no PC would work - and in fact on each screen we got the windows 7 IP Conflict pop up box.
This seemed very odd to us, as we know these IP's are all static (no dhcp on this segment at all)
we went with a very vanilla config on each port
interface g1/0/1
switchport host
that is it - nothing special at all.
well, after hours of research we found the 3850 has a problem where its "ip device tracking" (even though disabled, by way of NOT being enabled on any interface) will effect the windows 7 PC's ip address in use detection port start up phase!
This is a very big problem. I am frankly SHOCKED Cisco would release a major switch that is going to not work when connected to the average network with windows 7 PC's.
we tried 3+ hours of prescribed work-arounds found when researching this issue -
ip device tracking probe delay 10 (global config)
ip device tracking max 0 (disabed, on interface)
finally,
nmsp attach suppress (interface, however this appears to be a default command in all IOS-XE versions we tried, as the command did NOT show in the show run) . this effected many different nic card vendors (laptops, desktops) and nic card drivers levels from old to very recent.
Finally,
we compared a 3850 in another location to this one - and we never got HIT by this problem before because that 3850 only as TRUNK ports and no windows 7 hosts directly attached.
Doing more research, I found out this also can effect vmware guests running windows SERVER.
this is now a huge issue as we have a scheduled deployment of 3850's throughout our network which is going to be put on hold.
the work-around I came up with which is not great is -
Make ALL the "access" ports connected to PC TRUNK ports and leave the NATIVE vlan (untagged) as the vlan you want the PC's to be in
interface g1/0/1
switchport mode trunk
switchport trunk native vlan 1
this is NOT an acceptable workaround as this presents security issues even with
switchport trunk allowed vlan 1, etc. as the only allowed vlan.
Note: this issue manifested itself and windows 7 PC's were UNABLE to use the network. if you do "ipconfig /all | more" you would see
192.168.0.140(duplicate) and the interface would actually use 169.254.0.239(duplicate) so the duplicate message appeared twice in the output.
1) With and without an SVI interface on each 3850 for the vlan where the windows 7 machines had a duplicate
2) when we had an SVI and the command ip device tracking probe use-svi (or whatever the hidden command is I forget now, but it took it)
3) when we had aaa new-model configured - and not configured - thinking this was some artifact of having aaa turn on something like 802.1x port state
4) when could confirm NO DHCP SNOOPING
5) when we DID not use static IP's - and had the switch assign DHCP addresses - the Windows 7 PC's STILL had duplicates and didnt work for their "Just leased" ip's.
6) when we could confirm ios-xe ip device tracking = disabled with show ip device tracking status, etc.
This is a major problem for this 3850 and unless we get a definitive answer on why this is happening and how we can rectify we are going to have to return our 3850's and get HP Procurve's something I would rather avoid doing. There is NO REASON I can imagine other than older switches who's ports default to ROUTED ports (i.e.. no ip switchport) where a switch should not at least function as a bare switch with essentially a default configuration out of the box.
Any ideas? I'm working well now with the ports ALL in trunking mode with vlan 1 native, but this is not a scalable workaround we can live with as we have security risks of a port not blocking certain vlans from going out ports to pc's, etc. that attackers could send tags on at that point, etc.
thanks,
Joe Brunner
#19366
