This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
We have four GS305EP switches deployed with static IP addresses. The devices attached to the switches work fine. The switches are not ping-able, hence not accessible, for roughly 24 seconds followed by 56 seconds of accessibility. Upgraded to latest firmware (V1.0.1.1), same behavior. No VLAN'ing (default config). Changing DDOS & Discovery services did not change the behavior. Tests results ran are the same from physical and virtual Windows machines as well as routers. These four GS305EP switches are the only devices on the LAN that behave this way. When they're unreachable, their entries are missing from the local ARP table. Do they have a short ARP expiry time, or something? Even if they did, why would it take exactly 24 seconds for them to reply to the ARP request?
Handling the ARP and it's cache is done by the computer. Linux (and likely other OS) does have a garbage collector for the case the entry is no longer in use. As an example, the Linux man pages 7 says
===
The ARP module maintains a cache of mappings between hardware addresses and protocol addresses. The cache has a limited size so old and less frequently used entries are garbage-collected. Entries which are marked as permanent are never deleted by the garbage-collector. The cache can be directly manipulated by the use of ioctls and its behavior can be tuned by the /proc interfaces described below.
When there is no positive feedback for an existing mapping after some time (see the /proc interfaces below), a neighbor cache entry is considered stale. Positive feedback can be gotten from a higher layer; for example from a successful TCP ACK. Other protocols can signal forward progress using the MSG_CONFIRM flag to sendmsg(2). When there is no forward progress, ARP tries to reprobe. It first tries to ask a local arp daemon app_solicit times for an updated MAC address. If that fails and an old MAC address is known, a unicast probe is sent ucast_solicit times. If that fails too, it will broadcast a new ARP request to the network. Requests are only sent when there is data queued for sending
===
No idea on how you are monitoring the switch admin IP address, or what should make it disappear for such a long time - and why the reprobe should be required.
Keep in mind the tiny uC on the GS305EP (or and most other Plus models) have other jobs like monitoring the full data traffic, eg. for handling IGMP multicast.
Some ad-hoc capturing traffic - filtering just the GS308E MAC - does not show any oddities here. ARP are promptly replied, pings start immediately including the replies form the switch.
GS308E 10.10.1.102 NTGR-98-5d-84
No differences for the GS105PE, GS110EMX, GS808E (S8000 Gaming Switch), GS810EMX (Nighthawk Switch) - just to list a few similar implemented switches.
Do you have any other L2 devices like wireless bridges, Mesh systems, .... in your data path?
Handling the ARP and it's cache is done by the computer. Linux (and likely other OS) does have a garbage collector for the case the entry is no longer in use. As an example, the Linux man pages 7 says
===
The ARP module maintains a cache of mappings between hardware addresses and protocol addresses. The cache has a limited size so old and less frequently used entries are garbage-collected. Entries which are marked as permanent are never deleted by the garbage-collector. The cache can be directly manipulated by the use of ioctls and its behavior can be tuned by the /proc interfaces described below.
When there is no positive feedback for an existing mapping after some time (see the /proc interfaces below), a neighbor cache entry is considered stale. Positive feedback can be gotten from a higher layer; for example from a successful TCP ACK. Other protocols can signal forward progress using the MSG_CONFIRM flag to sendmsg(2). When there is no forward progress, ARP tries to reprobe. It first tries to ask a local arp daemon app_solicit times for an updated MAC address. If that fails and an old MAC address is known, a unicast probe is sent ucast_solicit times. If that fails too, it will broadcast a new ARP request to the network. Requests are only sent when there is data queued for sending
===
No idea on how you are monitoring the switch admin IP address, or what should make it disappear for such a long time - and why the reprobe should be required.
Keep in mind the tiny uC on the GS305EP (or and most other Plus models) have other jobs like monitoring the full data traffic, eg. for handling IGMP multicast.
Some ad-hoc capturing traffic - filtering just the GS308E MAC - does not show any oddities here. ARP are promptly replied, pings start immediately including the replies form the switch.
GS308E 10.10.1.102 NTGR-98-5d-84
No differences for the GS105PE, GS110EMX, GS808E (S8000 Gaming Switch), GS810EMX (Nighthawk Switch) - just to list a few similar implemented switches.
Do you have any other L2 devices like wireless bridges, Mesh systems, .... in your data path?
Thanks for the reply, schumaku. The network is expansive. There are VLAN's to other vendor networks, a few wireless bridges (but they all got knocked out by a hurricane), probably a few loose wiring endpoints, roughly 60 switches, but it's only these four Netgear GS305EP exhibiting this behavior. It's like the management interface is repetitively rebooting. The downstream devices never loose connectivity even though the management interface IP does, so it appears that the switch is not rebooting, just the management interface. It lacks any sort of a log file that I can find. Heck, I can't even get an ARP table off of these. I would like to get some packet captures for functioning and failed ping requests to see what's going on at the ARP level. What app did you use to get the packet capture in the graphic?
Sorry to hear about these hardware losses. If ARP is lost somewhere on on the network, especially when using (expensive?) bridges, troubles are predictable. Somewhat doubt there is a problem on these simple IP stack ARP implementation.
The downstream devices never loose connectivity even though the management interface IP does, so it appears that the switch is not rebooting, just the management interface.
These Plus switches (many, but not all) are build on non-managed but configurable switch chips. The Web UI, the IGMP Multicast handling, and some is implemented on a very basic micro controller.
It lacks any sort of a log file that I can find. Heck, I can't even get an ARP table off of these. I would like to get some packet captures for functioning and failed ping requests to see what's going on at the ARP level.
For the reason mentioned above, there is none of this available.
Keep in mind the price point does just reflect a non-managed PoE switch.
What app did you use to get the packet capture in the graphic?
Standard Wireshark (Version 4.0.10 as of writing) on my all-day work horse notebook, connected with a 2.5G link to a Netgear MultiGig capable switch, operated on a 10G/40G backhaul. Good thing is ARP does go everywhere on the VLAN, this is why it's easy to capture in general.
Thank you for the information, schumaku. I performed the Wireshark traces which confirmed the ARP behavior. I'm beginning to think it is simply a resource issue on the GS305EP switch. Of the 30 or so ARP requests that go unanswered by the switch's management IP address, I get about 20 consecutive replies back 30 seconds after the initial ARP request so the switch is queueing\caching the ARP requests. My band-aid for now is to simply to add static ARP entries in the management workstation's ARP table. Now there's no dropped ICMP packets to the management interface IP of the GS305EP switches. You get what you paid for, I guess.
This does nicely show the broadcast as well as the MAC address directed ARP from the Netgear switch MAC are repeated many (about 20 each!) times - tells me there is a problem with the connectivity e.g. whatever bridges are in the data path in either direction.
No idea what switch resoure shortage you try to construct here....
Kinda shooting from the hip due to the lack of visibility into the switch's processes but with a static ARP entry for the switch in my local Windows ARP table...
Internet Address Physical Address Type 10.1.20.90 94-18-65-6e-46-a1 static
...there is no loss of ICMP requests, 100% ping replies are returned for 10.1.20.90. Observing a 'normal' ARP transaction, when my machine requests 'who is IP_Address', I get an instantaneous, single response from the target host with its MAC address. In the switch's case (10.1.20.90), without the static ARP entry in my Windows machine, the switch appears to buffer the sometimes 30 requests then spits out like 25 replies 30 seconds later, like the switch was too busy processing other things, so the requests are processed from a memory heap in the order in which they were received, some having been discarded, which is why the number of replies will never be greater than the number of requests. Anyhow, I am shying away from these switches because if it is not powerful enough to keep up with simple ARP requests, what other performance issue could exist?
Maybe they'll fix it in a future firmware update. Thank you for taking time to lead me down the right path.
Doubt there is much wrong on these switches - my guess goes much more towards your unknown and unspecified other network implementation, silently eating up standard repeated ARP traffic in and direction.
Compare your ARP traffic with my example data shown 8-)
Of course, the static ARP entries help around the weakness and unreliability of your 08/15 MG class network 8-)
