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

[Tim Mooney]

In regard to: Re: [OpenIndiana-discuss] arp response tuning for IP Source...:

> 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)

I checked with our principal engineer.  The Cisco switches support
10 MACs per port for IPv4, more than 10 MACs per port for IPv6.  That's
with the IP Source Guard enabled.

Thanks,

Tim

> -----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
>

-- 
Tim Mooney                                             Tim.Mooney at ndsu.edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building                  701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164