Hi Tiago, Please see few comments inline
On Wed, Nov 8, 2017 at 11:49 PM, Tiago Lam <tiago...@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 > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev