Date:	Tue, 11 Nov 2014 11:08:19 +0100
From:	Ulf samuelsson <netdev@...gii.com>
To:	Brian Haley <brian.haley@...com>
Cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: How to make stack send broadcast ARP request when entry is STALE?

If I set ucast_solicit to '0', then I always send broadcast, which is not desirable.

In the PROBE state of the ARP state machine, "probes" count from 0 .. ucast_probes.

I can see the following arguments for letting "probes" count from 
  
   0.. (ucast_probes + app_probes + mcast_probes)
   

A: This is how the IPv6 is doing it. 
     It is not standardized in IPv4, but why should the IPv4 have a different behaviour?

B: If you do not send out broadcast if unicast fails, then a broadcast will be sent out 
     anyway, once the ARP entry is removed by the garbage collector.
     You get an annoyingly long delay before that happens.

C: If a large data centre does not want broadcasts to be sent out, 
     then they can set mcast_probes to 0, in which case no broadcasts will be sent
     out in PROBE state.

D:  When in other states, the counter runs until it a reply is had, or the counter wraps around.
      It is sending broadcast all the time.


Best Regards
Ulf Samuelsson
ulf@...gii.com
+46  (722) 427 437


> 10 nov 2014 kl. 23:52 skrev Brian Haley <brian.haley@...com>:
> 
>> On 11/07/2014 05:11 AM, Ulf samuelsson wrote:
>> The HP router is configured by a customer, and they intentionally limit replies
>> to broadcast, and that is how they want it.
> 
> So this is the crux of the problem - the customer has configured the router so
> that it doesn't play well with most modern network stacks that try and use
> unicast so they don't send unnecessary broadcast packets.  I don't know why I
> thought this was something wrong with the router software.
> 
> Did you try this?
> 
> $ sudo sysctl net.ipv4.neigh.eth0.ucast_solicit=0
> 
> It works for me.
> 
> And they really should re-think their decision on that configuration setting.
> 
> -Brian
> 
> 
>> In the previous version of the build system, the Interpeak stack was used
>> and this would in PROBE state send unicast ARP request, and if that failed
>> send broadcast ARP.
>> 
>> The native linux stack, when in PROBE state sends only unicast until it decides
>> that it should enter FAILED state.
>> 
>> The 'mcast_probes' variable seems to be totally ignored, except the first  time,
>> so I do not see why it is there.
>> 
>> Best Regards
>> Ulf Samuelsson
>> ulf@...gii.com
>> +46  (722) 427 437
>> 
>> 
>>>> 7 nov 2014 kl. 10:54 skrev Brian Haley <brian.haley@...com>:
>>>> 
>>>> On 11/05/2014 07:48 AM, Ulf samuelsson wrote:
>>>> Have a problem with an HP router at a certain location, which
>>>> is configured to only answer to broadcast ARP requests.
>>>> That cannot be changed.
>>> 
>>> Sorry to hear about the problem, but my only suggestions would be to try the latest firmware and/or put a call in to support.  I don't happen work in the division that makes routers...
>>> 
>>>> The first ARP request the kernel sends out, is a broadcast request,
>>>> which is fine, but after the reply, the kernel sends unicast requests,
>>>> which will not get any replies.
>>> 
>>> You might be able to hack this by inserting an ebtables rule - check the dnat target section of the man page - don't know the exact syntax but it would probably end in '-j dnat --to-destination ff:ff:ff:ff:ff:ff'
>>> 
>>> -Brian
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@...r.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
> 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists