Netvanta 1550-48P loss of management connection. No console connection

[Anonymous]

Good afternoon,

I have an issue I am trying to resolve.  We currently have Netvanta 1550-48P switches in service.  Occasionally I am not able to access my default management IP address via telnet.  If I connect a console cable up to the console port I cannot gain access to the switch either.  Once I power cycle the switch everything works fine again.  Whenever these management interfaces are down the switch is still able to pass regular traffic correctly.  We use this switches mainly for segregating data/VOIP traffic by VLAN.  Has anyone else ever seen this issue.  Thank you.

[jayh]

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.

[Anonymous]

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.

[Anonymous]

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.

1. Remove IP address / management interfaces on high broadcast and multicast traffic VLAN's
2. Enable IGMP snooping on networks/Vlans with high Multicast

Configuring IGMP Snooping

https://supportforums.adtran.com/docs/DOC-6593​

    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

   Autolink

   DNS

   Http Client

   Webserver

   SNMP

   Maintenence events for various interfaces

   Fan Control

   OAM

   Ping

   Traceroute

   DHCP

   LLDP

   Port Auth.

   Bridging (Aging cache)

   Clustering / ActivChassis

   GVRP

   IGMP

   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.

https://supportforums.adtran.com/docs/DOC-6763

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.