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

the outsider openindiana at out-side.nl
Fri Jan 6 07:30:38 UTC 2017


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

_______________________________________________
openindiana-discuss mailing list
openindiana-discuss at openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss




More information about the openindiana-discuss mailing list