[ovs-dev] [OVN] "Finish up ARP support" approach

Tiago Lam tiagolam at gmail.com
Wed Nov 8 18:19:29 UTC 2017


Hey all,

As pointed out in a previous email (email below), I'm hoping to work on
the "ARP re-checking bindings, expiring bindings" item on OVN's TODO.rst
file. I've since started tackling it, and I think I've made some good
progress, so I thought I'd share the logic here to see if you have any
thoughts / suggestions.

Currently, the logic is very similar to the work done in the patch [1]
("OVN: Add support for periodic router advertisements"):
1. A new 'arp_configs' column as been added to the Logical_Router_Port
table in NB DB. Currently, it only adds an option, 'timeout';
2. Similar to the IPv6's RAs patch, one can configure a 'timeout' for
the router's logical port using the 'timeout' key, as in:

    ovn-nbctl set Logical_Router_Port ro-sw arp_configs:timeout=60

3. In northd, when read from the NB DB, those options are copied to
corresponding logical port in the Port_Binding table in SB DB (the copy
is done when the ingress table 8, for ARP Resolution, is set up);
4. In the ovn-controller, a map is maintained to keep track of the ARP
state of each local logical port scanned from the SB DB;
5. In order to perform the revalidation on the MAC-IP binds, for each
logical port that's bound to the current chassis, it checks if there's
MAC-IP bindings in the MAC_Binding table:
  a. If the 'timestamp' of the entry has expired (taking into account
  the configured 'timeout'), send a Unicast ARP;
  b. If entry is still not updated within the 'timeout', send send a
  broadcast ARP;
  c. If that hasn't work either, the entry is disposed of.

This requires, however, a change in the SB DB schema, to store a
'timestamp' for each MAC-IP mapping in the Data_Binding table. I found
no other way of going around this, since we will need to know if the
entry has actually been updated when we try to revalidate.

Going further, there could maybe be some improvements to align the IPv6
ND work with this, since part of the functionality overlaps.

I'm finishing some testing at the moment and should be able to send it
soon, but any thoughts regarding the above would be much appreciated!

(My previous email was sent a couple of weeks ago to the "Discussion"
list. But since I didn't get much adherence there, I thought I would
send this one here to have a broader visibility (in fact, I've seen
similar "proposal" emails being sent here, so perhaps this is indeed the
best place).)

Thanks.

[1] https://patchwork.ozlabs.org/patch/834112/

On 10/25/2017 10:34 PM, Tiago Lam wrote:
> Hi folks,
> 
> Looking into the OVN project and ways to contribute back.
> 
> I've looked into the `TODO.rst` file under `ovn/` (How up to date is
> it?) and, more specifically, to the "Finish up ARP/ND support" item,
> which seems to be a good one to tackle at first.
> 
> Last week's "OVN: Add support for periodic router advertisements" patch
> seems to have added further support to ND under IPv6. So, after looking
> through the patch, I'm thinking on approaching ARP the following way
> (which is similar to the way RAs was done):
> - Add an `options` field to set the expiration value (probably
> defaulting to 60 seconds) to the `Logical_Router_Port` table in the NB DB;
> - (Maybe even an additional field to set if one wants to disable the
> bind re-checks before expiration);
> - In `northd`, translate those `options` in the `Logical_Router_Port` NB
> DB into `options` in the `Port_Binding` table in the SB DB;
> - For each run of `pinctrl_run`, check for each binding of each port if
> the expiration has passed:
>     - If so, and the re-check options has been enabled, send an ARP
> packet, leading to the update of the MAC binding.
>     - If not, and a check has been performed already, or if the re-check
> options is disabled, delete the binding.
> 
> Now, it is still not clear to me what will be the best way to track each
> last-checked time for each binding, so one can then delete the entry
> after the expiration (maybe through options on the `MAC_Binding` table
> as well?).
> 
> This is very theoretic for now, but do you see any drawbacks to this
> approach? And is this more or less what's intended for the "Finish up
> ARP support" TODO item?
> 
> Thanks,
> 
> Tiago.
> 


More information about the dev mailing list