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 ou...
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.)
I would like to have a follow up on this thread. Please let us know if everything is ok now or you still need further assistance.
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?
You may need to run a syslog in order for us to determine which one is causing the traffic. Are all the ports being used?
Regards,
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.Ok, I went in and changed the syslog from "Warning" to "Info". Getting a ton of output now. What do you suggest I look for?
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
