NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
GS724T no gui and presumably high cpu usage
I have at GS724Tv3 that sits in my DMZ. i.e. connects the firewall to the DMZ machines and the firewall for the inner network.
My issues are:
(1) it rarely responds to ping requests (maybe 1 out of 100 tries, and then with a high latency of maybe .700ms) on the management IP and
(2) the management GUI is unaccessable (on a rare occasion the browser will show "Netgear GS724T" but that's it)
(3) Smart Control Center is able to connect and read the basic info. But a file transfer (say to send a different firmware) will fail.
(4) Neither rebooting the switch nor power cycling the switch will fix the issue.
Other info and/or configuration details:
(a) The switch operates as expected with the given configuration.
(b) I am using a half dozen VLANs (with the management VLAN moved off of "1")
(c) No LAGGs configured
(d) I am running a diffserv to manage VOIP traffic to/from 1 port and the firewall. (Not running on the Voice VLAN).
(e) Running the latest firmware 5.4.2.30 booting from secondary. 5.4.2.19 is in primary and the same issue occurs with this firmware.
Having read several other discussions searching for an answer it appears the reason for the severe lag in responding on the management interface is likely that the internal cpu is likely fully utilized. So before I take further steps to try and debug my question is, "what functions/services can cause high cpu utilization on the internal CPU?"
I have read that if the DNS is misconfigured and NTP is searching for a time it can cause an issue. While I don't think this is the case it is possible the DNS is misconfigured as I did change the IP for my DNS. (But I think I corrected it in the switch.)
My next step in debugging will be to unplug all ports but one on the switch and power cycle it. Then see if the management GUI is available. If so, depending on what might cause high cpu usage I can turn that off and see if I can pinpoint what exactly is causing the issue by systematically turning services back on?
Any suggestions here?
I solved this one.
The two firewalls attached to the switch were multicasting state and config data back and forth. The switch had IGMP snooping enabled from a previous configuration (no longer used). Oddly, the configured snooping VLAN was not where the multicast traffic was happening.
When I turned off the multicast sync between the firewalls the GS724T GUI was responsive again. I then turned off IGMP snooping. (Probably would have gone a LOT quicker if I had known snooping was a CPU vs. switching HW function.)
11 Replies
Hi h2oBob,
Welcome to our community! :)
May you be able to run syslog so that we can determine what seems to be happening in your network? It seems that even if you tried to reboot the switch, it won't go back to its default state. Is it possible to disconnect all of the devices to the switch then try if we can still access the gui without any issues.
Regards,
Hi,
I was out of town, hence the delay.
Here is what I verified... If I disconnected the 3 esxi servers connected to the switch I could access the management gui. Plug them back in and I could not access the gui.
With the servers disconnected I configured diffserv classes and policy for prioritizing packets to/from the management IP and enabled it on the port from my management PC. With this in place I'm able to contact the management interface even with the servers connected to the switch.
So while the issue is resolved, I am still left with an unanswered question that would help understand the root cause. The total amount of traffic is WELL below the rated maximum per port and total for the switch. So i'm guessing there is something specific the CPU is reacting to that is being ingressed.
What type of traffic from the servers would cause the switch CPU to be so busy it could not respond to management inquiries? OR, what specifically are the duties of the CPU vs simple switching that is handled by other hardware (which was always working on my switch).
Thank you.
Oops, I may have spoken too soon. The management gui on the switch is once again not accessable, even with the diffserv policies mentioned above in place.
Something is causing a CPU overload. Can you help determine what type of traffic is the issue?
- I know this is an old thread, but it pointed me towards the solution in my case. I’ve had the exact same issue with this switch model in front of an ESXi host.
What caused the problem in my case was a specific portgroup. Precisely, having a portgroup on the ESXi host with the special VLAN 4095 (reserved for the purpose of tagging all VLAN -e.i making it TRUNK) connected to the GS724Tv3 was the root of the encountered problems.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
