Is the switch's management IP accessible from the public Internet? I've seen this type of thing when the switch is under a brute-force password guessing attack. You can create an access-list containing your trusted hosts or subnets and apply it to the ssh line as an access-class. I strongly advise not to use telnet, use SSH.
Another possibility is if you're using TACACS authentication and the server somehow becomes unreachable.
1 of 1 people found this helpful
That sounds like symptoms of a NetVanta switch that is running the firmware it was shipped with. Have you upgraded the firmware to a current maintenance release?
I can recall at least a few times where I ran a switch right out of the box, and have the sames issue. After upgrading the firmware, the problem never appeared again.
Usually, when this happens, you cannot ping the management IP address either.
These reasons already mentioned are all possibilities that can cause the management interface to stop responding.
The console interface and all other management interfaces to the switch are the lowest priority.
Unresponsive management interface which including the lack of ping responses to the IP interfaces, is not unusual to these switches when high network traffic is taking first priority.
To resolve this network traffic issue, there are a few options.
- Remove IP address / management interfaces on high broadcast and multicast traffic VLAN's
- Enable IGMP snooping on networks/Vlans with high Multicast
Configuring IGMP Snooping
3. Or decrease the traffic that requires CPU switching or routing. This includes all Broadcast, and Multicast at the IP and MAC layers. To determine if you're seeing traffic that is CPU intensive - do the enable command - " show proc cpu ".
If the PC Config process is a large percentage, the following list of tasks are included in this thread -
Command line interface
Maintenence events for various interfaces
Bridging (Aging cache)
Clustering / ActivChassis
Also, another process (s) could be a large percentage, which could be the cause of this behavior.
A network packet capture can also be helpful in determining the cause if still not know.
SNMP managers that are hitting the Switch with requests that are not in the standards or are not ADTRAN OIDs can also consume the CPU. SolarWinds SNMP manager by default will cause this issue.
The CPU utilization should drop back, after reboot, to 20 - 50% for a 5 min Avg load if the network is running optimally and most traffic is being handled in hardware and not being sent to the CPU. This can be seen also on the "System Summary" in the Web interface.
Rebooting often helps this problem at first since everything that is generating this traffic, loses connection and often stops till it re-establishes connections again, which shows it is not hardware failure.
Also if the NV1550 or other switch and it is not running R13.5.2 ( EMR release ), this would be the next step if this problem is not resolved, or if you want all bug fixes to be deployed.