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

[James Carlson]

On 01/05/17 18:49, Tim Mooney wrote:
> In regard to: Re: [OpenIndiana-discuss] arp response tuning for IP
> Source...:
>> 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.

If the system were taking any action to take down the interfaces and
defend itself from attack on the network, that would be logged.  If
you're really not seeing log messages, I don't think the system is doing
that.

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

There's nothing about an "ARP probe" (if that's truly what they're
sending) that could cause such a problem, at least as far as I know.

It's hard to give any sort of definitive (or even helpful) answers
without seeing the actual packets and error messages.

> 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 response may be unicast or broadcast.  It depends on the context.

In general, if we haven't replied to a query in a "long time," then it's
possible that some conflicting IP address has been introduced on the
network.  To guard against that, we deliberately broadcast our reply in
an attempt to ferret out that interloper.

If we've responded recently or have actively defended our address
recently, then the response is unicast.

Per the standards, the Cisco box should process both unicast and
broadcast messages.

See section 2.6 in RFC 5227 for more about the issues.

> 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

That might work.  But I don't know what the Cisco box is doing or what
traffic is actually on the network.

If broadcast has anything to do with the problem, I doubt that'll help.
We broadcast when we defend our address.  On purpose.  It's how you
update corrupted ARP caches held by other nodes on the network.

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

I think it's extraordinarily unlikely that tweaking these things will
help anyone on any reasonable network.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>