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?
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.)
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.
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).
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 am already running a syslog on the management network. I'll double check the message level setting, but I'm seeing nothing come out of the switch at present. (Will require I unplug servers again, so it will take a day or so to get the downtime.)
While I do this and wait for syslog messages to be generated (hopefully), can we answer the general question of, "what would cause a load that might stop the gui from working?" From what I'm seeing looking at what's being reported by the machines connected to the switch the actual amount of packet traffic is FAR below anything would cause a switching load to be the issue.
Which suggests to me the cpu running the management gui must be doing something based on the type of activity the switch is seeing. What does the CPU do vs the switching hardware? Is the CPU running the vlans? Is it doing NTP checks? Is it running the diffserv? etc. That might help narrow down the debug approach.
Yes, I can send additional info. What exactly do you want? The syslog output I assume? Having looked at it I can't see anything that suggests where to go next. Syslog attached...
Please take this as constructive... I appreciate the help. What I'm trying to understand in the debug process is, "What are we trying to isolate or eliminate?" vs. let's look at information without knowing why. For example, I've asked previously about what would be competing with the GUI for resources as resource starvation might explain why it's not working. We've not discussed the answer to that question.
Since I don't know what the CPU is doing vs the switching hardware (also a previous question) my best guess at the source of the problem here is:
some type of traffic coming from the servers is being watched or snooped by the CPU and the volume of that traffic is overloading the system
there is some type of HW problem with one or more ports that is causing interrupts/exceptions at a high rate that the CPU is servicing,
normal functions of the cpu like diffserv (or other QoS) or syslog are overloaded.
So it would help if we could discuss how to eliminate any of these theories about the source of the problem, or discuss alternative theories about the source of the problem.
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.)
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.
