[OpenIndiana-discuss] arp response tuning for IP Source Guard

[Doug Hughes]

It seems to me that you might be hitting up against "arp_defend_rate" 
which by default says that the maximum arps it should be expecting in 
one hour is 100. It's he's sending 3 per minute, that's already 180. I 
could be wrong. I'd probably try setting that to 300 and confirm what's 
going on by using "snoop arp" and then focussing in on the mac address 
of the switch and seeing how many are coming in an hour.



On 1/6/2017 2:30 AM, the outsider wrote:
> Are you or the technicians SURE that this technique is still valid for
> current world with a lot of virtual servers attached to one switch port?
> This technique was invented in a time that every switchport was connected to
> at most one MAC address, so when the switch detects more than one MAC
> address at a port there was something illegal happening. (or the switchport
> was connected to a switch)
>
> -----Oorspronkelijk bericht-----
> Van: Tim Mooney [mailto:Tim.Mooney at ndsu.edu]
> Verzonden: vrijdag 6 januari 2017 0:50
> Aan: openindiana-discuss at openindiana.org
> Onderwerp: Re: [OpenIndiana-discuss] arp response tuning for IP Source Guard
>
> In regard to: Re: [OpenIndiana-discuss] arp response tuning for IP
> Source...:
>
>> On 01/05/17 15:37, Tim Mooney wrote:
>>> When that was enabled for the subnet I'm on, my hipster workstation
>>> and the hipster VirtualBox VM I have both started experiencing packet
> loss.
>>> Talking with the network engineers, the Cisco switch is sending
>>> batches of 3 ARP probes periodically, and both my workstation and the
>>> VM appear to be periodically not responding to the ARP probes.  That
>>> causes the switch to temporarily ban/block packets from either
>>> system, which is what's causing the intermittent packet loss.
>>>
>>> Anyone have any suggestions for what tuning I should be looking at
>>> that would tell the Illumos network stack that it's OK to respond to
>>> semi-frequent batches of ARP probes?
>> It would be great to see the syslog messages and (if possible) a
>> packet trace showing what's going on.  In general, if the system
>> itself is directly responsible for these outages, it will at least log
>> something about the event.
> At the log level I've been running at, there hasn't been anything useful
> logged related to this.  If necessary, I can definitely dial up the logging.
>
>> Are these ARP requests or responses?  There are subtle differences
>> between the two.
> According to our principal network engineer, the Cisco switch was defaulting
> to sending 3 ARP probes (in quick succession) every 60 seconds.  He has
> since dialed that back to just 1 per 60 seconds for this particular switch,
> to see if that had any impact on the issue, but it did not.
>
> He's done a bunch more research since I sent my initial question to this
> list, and right now he thinks the issue may be that the ARP probe from the
> Cisco switch is unicast, but Solaris apparently may be issuing ARP responses
> as *broadcast*, which the switch may not be expecting.
>
> The reference he found related to broadcast ARP responses is here:
>
>   	http://seclists.org/nmap-dev/2009/q1/176
>   
> http://unix.derkeiler.com/Mailing-Lists/SunManagers/2009-01/msg00015.html
>
> He's also suggested that I might be able to set 'arp_defend_interval'
> to something like 20 seconds, so that my workstation just periodically sends
> unsolicited ARPs for itself, to essentially preempt the switch's probes.
> Based on the docs he found:
>
>   	http://docs.oracle.com/cd/E36784_01/html/E36845/gnogz.html
>
> Since the docs say "Never" in answer to the "When to change" for any of
> these settings, I haven't actually tried setting arp_defend_interval.
> The way I read the docs, it seems like arp_publish_interval might be better,
> but I know better than to argue with our principal network engineer about
> anything network related.  :-)
>
>> Based on what I remember from working on this code many years ago, one
>> of the really confusing bits to deal with is Ethernet bridge
>> ("switch") behavior itself.  Many bridges (I think at least Extreme,
>> and probably
>> others) have special mechanisms built-in to protect against ARP
>> storms, and they rate-limit based on the number of broadcasts.  This
>> is (I
>> believe!) independent of any sort of "Source Guard" feature.  I ran
>> into this issue numerous times when testing Solaris IP Duplicate
>> Address Detection.
> Thanks much for the response!
>
> Tim