We are in progress on replacing our Netvanta 1238 and 1324's with Cisco SG350-52MPs. Our Netvanta 1544's will eventually be replaced with some model of Catalyst (I'm just uncertain of the model).
Right now we have deployed 7 SG350-52MP's, but last night while deploying a set we ran into a scenario that felt like a broadcast storm except that it wouldn't dissipate on it's own i had to reset our core Netvanta 1544 before network routing would recover. The network would be stable for 10-20 minutes until vlan routing would stop and i'd loose access to my core 1544 until power cycling it.
Do I need to be mindful of anything specific while deploying these Cisco switches in place of my 1238's and 1324's which I've been fortunate to avoid with the first 7?
The only error i see on the 1238's and 1234 i tried to replace last night is a number of Speed/Duplex mismatch errors which have been on those switches for the longest time.
Thanks for any guidance provided.
Speed/duplex mismatches should obviously be fixed. Most modern gear is fine with auto-negotiation, but if one end is statically configured the other side will generally go to half-duplex which is not good. I'd try everything automatic and if you need to force anything, be sure to force both ends of the link.
Edit: Adtran's implementation of LLDP has been buggy and you may see console messages about speed/duplex mismatch that are bogus. It's best to look at the interface statistics on both ends of the link to be sure.
I would also look closely at spanning-tree. Is your network such that a layer-2 loop is possible? Make sure you're running the same algorithm on both the Cisco and Adtran side. Cisco has some proprietary spanning-tree modes that aren't going to be compatible.
I've been reminded about the speed/duplex mismatches. It's because we have some Shoretel IP230 phones that are gigabit, and the adtran's don't handle the speed negotiation through LLDP very well like you mentioned.
My experience is that Adtran handles the speed/duplex negotiations just fine. However, they continuously barf LLDP messages to the console complaining about mismatches that don't really exist. We've seen this with Polycom phones, apparently the same issue exists with Shoretel. If you actually look at the interface with 'show interface' you'll see that the speed/duplex is fine.
Because LLDP is used by the phones to determine the voice VLAN, you can't turn it off completely. The interface-level command "no lldp receive 802.3-info mac-phy-config" will stop the noise. It would be nice if they just fixed the underlying issue instead. It's just a cosmetic bug, but crying wolf about bogus speed mismatches can cause issues identifying real ones.
Do check for actual duplex mismatches by looking at the interface CRC error, collision, and runt counters but I suspect you'll find that everything negotiated successfully and LLDP is lying to you.
You can just disable LLDP receive and the phone can still learn the Voice VLAN information.
Beware that this can break the LLDP POE negotiation of some phones.
(config-giga-swx 0/10)#no lldp receive