NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
GS305EP Switch's Management Interface Cyclically Goes Offline
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?
7 Replies
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?
Gratefully,
Vinh
Hi Vinh,
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.
HelpDesk321 wrote:
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.
HelpDesk321 wrote:
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.
HelpDesk321 wrote:
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.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
