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

Numan Siddique nusiddiq at redhat.com
Wed Nov 8 19:00:13 UTC 2017


Hi Tiago,

Please see few comments inline



On Wed, Nov 8, 2017 at 11:49 PM, Tiago Lam <tiagolam at gmail.com> wrote:

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

arp_configs should be configured to all the logical router ports attached
to the router ? or to only gateway router port (i.e with redirect-chassis)
option ?
I am still not very clear what is the requirement ? Why should
ovn-controller send out periodic ARPs ?
In the case of IPv6, it is expected that the router should send out
periodic RA (which provides address mode, prefix etc). Can you please
explain a little bit
more ?

Thanks
Numan




> 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.
> >
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>


More information about the dev mailing list