[ovs-discuss] Thoughts on gratuitous ARP

Ihar Hrachyshka ihrachys at redhat.com
Thu Nov 16 18:02:52 UTC 2017


Also note that you really need this kernel patch series [1] to have
ARP cache to work in all cases. It's nice to have both REQUESTs and
REPLYs sent but it won't help in all cases. The series guarantees that
you don't get in an indefinite loop with stale MAC data as described
in [2]. Note that the series is for client side, not server (if you
get failures in tempest, the series should be applied to the kernel
running tempest).

[1] https://www.spinics.net/lists/linux-rdma/msg45907.html
[2] https://ihrachyshka.com/2017/05/25/the-failure-part-3-diggin-the-kernel/

On Thu, Nov 16, 2017 at 7:36 AM, Miguel Angel Ajo Pelayo
<majopela at redhat.com> wrote:
> I have a patch ready for ovn to send REPLIES additionally to the requests
> so, if we believe it makes sense, I can send it to the dev list.
>
> On Thu, Nov 16, 2017 at 4:18 PM, Ihar Hrachyshka <ihrachys at redhat.com>
> wrote:
>>
>> In neutron reference implementation, initially we were sending ARP
>> REPLYs only that didn't work with existing kernels in specific
>> scenarios. We added ARP REQUESTs (while continuing sending REPLYs). I
>> think it makes sense to send both types because some nodes may e.g.
>> know about REPLYs and not REQUESTs. If linux kernel had the mistake of
>> ignoring gratuitous REQUESTs till very recently, there may be other,
>> more niche networking stacks also exposing inconsistent behavior.
>>
>> Ihar
>>
>> On Thu, Nov 16, 2017 at 6:22 AM, Miguel Angel Ajo Pelayo
>> <majopela at redhat.com> wrote:
>> > Sorry, it's the other way around.
>> >
>> > REQUEST is what neutron reference solution started using (ANSWER was the
>> > previous type of ARP packet which was leading to issues with the buggy
>> > kernels).
>> >
>> > Since ovn-controller emits gratuitous ARPs as broadcast ARP requests,
>> > that
>> > should
>> > work.
>> >
>> > @Ihar, if you can confirm that our understanding is correct, that'd be
>> > great, I also
>> > see that your upstream kernel patch is really modifying the behaviour to
>> > also
>> > catch ANSWER packets with sha == tha, which should be equivalent as per
>> > RFC.
>> >
>> > On Wed, Nov 15, 2017 at 8:10 PM, Miguel Angel Ajo Pelayo
>> > <majopela at redhat.com> wrote:
>> >>
>> >> See inline email, I wasn't subscribed to ovs-discuss, sorry :)
>> >>
>> >>
>> >> On Nov 15, 2017 2:32 PM, "Miguel Angel Ajo Pelayo"
>> >> <majopela at redhat.com>
>> >> wrote:
>> >>
>> >>
>> >> We're finding that sometimes reused floating IP addresses
>> >> won't be reachable, for some reason. And I remembered that,
>> >> we found the same issue once for the reference
>> >> solution once, it was fixed here: [1]
>> >>
>> >> Basically because the linux kernel, under some conditions will
>> >> ignore the gARP requests, and reset a timeout value that would
>> >> keep ignoring those requests. But if it received a REPLY
>> >> packet instead, it worked.
>> >>
>> >> I believe that we may want to do the same in ovn controller.
>> >>
>> >> [1]
>> >>
>> >> https://github.com/openstack/neutron/commit/82831b9d8d4bd61f90610df9eca8c7f6e447f8d8
>> >>
>> >>
>> >
>
>


More information about the discuss mailing list