Netonix Forums

This seems related to the discussion in:
viewtopic.php?f=6&t=5953&hilit=gratuitous#p31478

However, I think it is a separate issue that was introduced somewhere in v1.5.x.

To the best of my knowledge, (at least in IPv4) gratuitous ARPs (GARPs) should only be sent on an interface state change from down to up. That includes unplug-plug, disable-enable and POR-reboots. If I was seeing them continuously on a network trace, I would normally be triggered to suspect that a port Ethernet was unstable/flapping.

Lets say you take a WS running v1.5.6 factory default. Connect a PC on 192.168.1.29 and start Wireshark.

In addition to the STP packets, the WS will repeatedly send GARP packets in groups of 3 with about 8 seconds between groups.

Ping works fine from either direction, with normal ARP Request & Reply ahead of the ICMP.

Now change the VLAN1 config from 1 to VLAN 11. Only one group of 3 appear after port state change. (Ping still works fine.)

Reverting Management back to VLAN1 restarts the problem.

Down grading firmware to v1.4.8 also stops the repeated GARPs on the default VLAN1.

Now you might want to say the GARPs are needed to maintain connectivity. But I say that's a kluge way of handling network issues, and if it is needed on VLAN1, why does it all work fine when the management VLAN is changed to any other ID?

GARPs where added specifically because people where losing access to the switch when it was in remote area's and something in their network changed in-between.

That problem was plaguing customers for months and after researching other manufacturer's it was found that they used this method to prevent this issue so we adopted it as well.

Hi Stephen,
Perhaps then, this discussion could have been part of the previous post.

However, there is still the inconsistency, that it only seems to run the endless GARPs on VLAN1 and does not with any other VLAN ID.

I'll be honest that I only tested the inconsistency on a management VLAN. I did not try it on additional VLANs that have an assigned IP. And if they don't have an assigned VLAN IP, I guess it would have no address to correctly GARP.

If the VLAN inconsistency is resolved, I guess I would also vote for a config option to only GARP 3 packets on interface status change.

JustJoe wrote:However, there is still the inconsistency, that it only seems to run the endless GARPs on VLAN1 and does not with any other VLAN ID.

I will look into it, this symptom is probably being caused by a similar condition that is doing this:
viewtopic.php?f=6&t=6734

JuseJoe wrote:I guess I would also vote for a config option to only GARP 3 packets on interface status change.

It would probably do more harm than good.
GARP's were added not because of change's that occurred on the switch interface, but on device's in-between. Say:
Switch A <===> Switch B <===> Switch C <===> PC

Then a change occurs on Switch C,
Switch A could become in-accessible.

It took us quite some time to determine that this was even possible, I'm reluctant to implement a convenience change that could have a catastrophic effect on the majority of user's.

Unless it can be demonstrated as to why this should be necessary.

Stephen wrote:...

JuseJoe wrote:I guess I would also vote for a config option to only GARP 3 packets on interface status change.

It would probably do more harm than good.
GARP's were added not because of change's that occurred on the switch interface, but on device's in-between. Say:
Switch A <===> Switch B <===> Switch C <===> PC

Then a change occurs on Switch C,
Switch A could become in-accessible.

It took us quite some time to determine that this was even possible, I'm reluctant to implement a convenience change that could have a catastrophic effect on the majority of user's.

Unless it can be demonstrated as to why this should be necessary.

Let's remember, the reason for the switch network is to communicate with hosts doing "work". Your example is good, but to be more complete it should include:

Remote Host X <===> Switch A <===> Switch B <===> Switch C <===> PC

Reaching Host X is the reason for the network. If the change occurs on Switch C that makes Switch A inaccessible, it's going to make Host X inaccessible too. Unless I'm missing something, IP specific GARPs from S A are not going to help H X.

Further, I suggest maintaining access to S A (which is acting as nothing more than a management interface host) with GARPs would superficially throw me off the network debug trail as in, "If I can reach host S A on the other side of Switch B, why can't I reach Host X?" I would be spending my time on that end instead of why things are getting dropped in between.

I guess after years of network debugging, I expect ARP to act a certain way. I say if you want to make always-GARPs the factory default, I'm fine with that. Just give me a way to override it.

Maybe I'm dreaming, but the real solution to the problem you are describing is to create a "Netonix Keep-alive" that runs between your switches. After establishing that it has other layer2 WS peers, it might do something like flushing ARP table entries related to that missing peer. Then normal ARP protocol could refill that table for the WS management host as well as all the connected hosts. And with that added bit of intelligence, maybe the switches could actually watch for missing GARPs from what they have learned as WS peers, and flush all related host entries? (Not sure if there would be enough info in just the GARPs though.)

Also, WS is relatively sophisticated when trying to accomplish changes on-the-fly without rebooting. If you are seeing the problem as you described it, maybe the live change process needs to be reviewed to see if some type of changes may need to be more disruptive when doing those changes. Because again I say, even though S A can regardless end up all grins with his GARPs you don't want Host X ending up with an unreachable frown.

JustJoe wrote:the real solution to the problem you are describing is to create a "Netonix Keep-alive" that runs between your switches

Effectively, that is what GARP does. If we implement a proprietary protocol that only works between our switches, then if switch C for example is not a Netonix switch, then you have the problem again.

JustJoe wrote: I say if you want to make always-GARPs the factory default, I'm fine with that. Just give me a way to override it.

OK I give, we talked about it internally a bit, it probably won't be harmful to have a checkbox in the config page to disable the GARP request's.
I will look into add it on the next release.

Stephen wrote:

JustJoe wrote:the real solution to the problem you are describing is to create a "Netonix Keep-alive" that runs between your switches

Effectively, that is what GARP does. If we implement a proprietary protocol that only works between our switches, then if switch C for example is not a Netonix switch, then you have the problem again.

Yesss, but my point is maintaining the communication to the switch management hosts is not what the network is about. Maybe a better pic would be:

Remote Host X <===> Switch A <===> Switch B <===> Switch C <===> NOC Internet Backhaul Router.

The important layer 2 connection to maintain in network wide ARP table entries is Host X to NOC router, along with each other's (IP) ARP entries so they can exchange packets without caring about the layer2 segment in between. Correct me if I'm missing something, but I don't think all the switch IP's GARP table entries will help that?

Yes, whole new protocol is not easy. If it was layer2 compatible it should pass through other switches. But I was going beyond and saying if the WSs could recognize their own layer2 hello-keepalive messages, they could take action on their ARP tables when they detect the keepalive missing. Yeah, there would be a delay for the missing-you timer to pop, but eventually it should restore the switches to a state where the ARP Requests & Replies can flow between Host X and NOC Router.

I'm guessing that real culprits are a wireless bridge radio pairs acting as Switch B. UI for a long time has had a problem where their bridge table seems to randomly lose integrity, even when stats claim the link was never interrupted. :(

Stephen wrote:

JustJoe wrote: I say if you want to make always-GARPs the factory default, I'm fine with that. Just give me a way to override it.

OK I give, we talked about it internally a bit, it probably won't be harmful to have a checkbox in the config page to disable the GARP request's.
I will look into add it on the next release.

As long as there are still 3 GARPs on each reboot and each interface status change, I will be happy. :)