<div dir="ltr">No worries, thanks for the update Han.<div><br></div><div>Once you have the patch, we can test your changes on our cluster and provide you an update.</div><div><br></div><div>Regards,</div><div>~Girish</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 3, 2020 at 4:27 PM Han Zhou <<a href="mailto:zhouhan@gmail.com">zhouhan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Girish, yes, that's what we concluded in last OVN meeting, but sorry that I forgot to update here.<br><div><br>On Wed, Jun 3, 2020 at 3:32 PM Girish Moodalbail <<a href="mailto:gmoodalbail@gmail.com" target="_blank">gmoodalbail@gmail.com</a>> wrote:<br>><br>> Hello all,<br>><br>> To kind of proceed with the proposed fixes, with minimal impact, is the following a reasonable approach?<br>><br>> Add an option, namely dynamic_neigh_routes={true|false}, for a gateway router. With this option enabled, the nextHop IP's MAC will be learned through a ARP request on the physical network. The ARP request will be flooded on the L2 broadcast domain (for both join switch and external switch).<br><div>></div><div><br></div><div>The RFC patch fulfils this purpose: <a href="https://patchwork.ozlabs.org/project/openvswitch/patch/1589614395-99499-1-git-send-email-hzhou@ovn.org/" target="_blank">https://patchwork.ozlabs.org/project/openvswitch/patch/1589614395-99499-1-git-send-email-hzhou@ovn.org/</a></div><div>I am working on the formal patch.</div><div><br></div>> Add an option, namely learn_from_arp_request={true|false}, for a gateway router. The option is interpreted as below:\<br>> "true" - learn the MAC/IP binding and add a new MAC_Binding entry (default behavior)<br>> "false" - if there is a MAC_binding for that IP and the MAC is different, then update that MAC/IP binding. The external entity might be trying to advertise the new MAC for that IP. (If we don't do this, then we will never learn External VIP to MAC changes)<br>><br>> (Irrespective of, learn_from_arp_request is true or false, always do this -- if the TPA is on the router, add a new entry (it means the remote wants to communicate with this node, so it makes sense to learn the remote as well))<br><div>></div><div><br></div><div>I am working on this as well, but delayed a little. I hope to have something this week.<br></div><div><br></div>><br>> For now, I think it is fine for ARP packets to be broadcasted on the tunnel for the `join` switch case. If it becomes a problem, then we can start looking around changing the logical flows.<br>><br>> Thanks everyone for the lively discussion.<br>><br>> Regards,<br>> ~Girish<br>><br>> On Thu, May 28, 2020 at 7:33 AM Tim Rozet <<a href="mailto:trozet@redhat.com" target="_blank">trozet@redhat.com</a>> wrote:<br>>><br>>><br>>><br>>> On Thu, May 28, 2020 at 7:26 AM Dumitru Ceara <<a href="mailto:dceara@redhat.com" target="_blank">dceara@redhat.com</a>> wrote:<br>>>><br>>>> On 5/28/20 12:48 PM, Daniel Alvarez Sanchez wrote:<br>>>> > Hi all<br>>>> ><br>>>> > Sorry for top posting. I want to thank you all for the discussion and<br>>>> > give also some feedback from OpenStack perspective which is affected<br>>>> > by the problem described here.<br>>>> ><br>>>> > In OpenStack, it's kind of common to have a shared external network<br>>>> > (logical switch with a localnet port) across many tenants. Each tenant<br>>>> > user may create their own router where their instances will be<br>>>> > connected to access the external network.<br>>>> ><br>>>> > In such scenario, we are hitting the issue described here. In<br>>>> > particular in our tests we exercise 3K VIFs (with 1 FIP) each spanning<br>>>> > 300 LS; each LS connected to a LR (ie. 300 LRs) and that router<br>>>> > connected to the public LS. This is creating a huge problem in terms<br>>>> > of performance and tons of events due to the MAC_Binding entries<br>>>> > generated as a consequence of the GARPs sent for the floating IPs.<br>>>> ><br>>>><br>>>> Just as an addition to this, GARPs wouldn't be the only reason why all<br>>>> routers would learn the MAC_Binding. Even if we wouldn't be sending<br>>>> GARPs for the FIPs, when a VM that's behind a FIP would send traffic to<br>>>> the outside, the router will generate an ARP request for the next hop<br>>>> using the FIP-IP and FIP-MAC. This will be broadcasted to all routers<br>>>> connected to the public LS and will trigger them to learn the<br>>>> FIP-IP:FIP-MAC binding.<br>>><br>>><br>>> Yeah we shouldn't be learning on regular ARP requests.<br>>>  <br>>>><br>>>><br>>>> > Thanks,<br>>>> > Daniel<br>>>> ><br>>>> ><br>>>> > On Thu, May 28, 2020 at 10:51 AM Dumitru Ceara <<a href="mailto:dceara@redhat.com" target="_blank">dceara@redhat.com</a>> wrote:<br>>>> >><br>>>> >> On 5/28/20 8:34 AM, Han Zhou wrote:<br>>>> >>><br>>>> >>><br>>>> >>> On Wed, May 27, 2020 at 1:10 AM Dumitru Ceara <<a href="mailto:dceara@redhat.com" target="_blank">dceara@redhat.com</a><br>>>> >>> <mailto:<a href="mailto:dceara@redhat.com" target="_blank">dceara@redhat.com</a>>> wrote:<br>>>> >>>><br>>>> >>>> Hi Girish, Han,<br>>>> >>>><br>>>> >>>> On 5/26/20 11:51 PM, Han Zhou wrote:<br>>>> >>>>><br>>>> >>>>><br>>>> >>>>> On Tue, May 26, 2020 at 1:07 PM Girish Moodalbail<br>>>> >>> <<a href="mailto:gmoodalbail@gmail.com" target="_blank">gmoodalbail@gmail.com</a> <mailto:<a href="mailto:gmoodalbail@gmail.com" target="_blank">gmoodalbail@gmail.com</a>><br>>>> >>>>> <mailto:<a href="mailto:gmoodalbail@gmail.com" target="_blank">gmoodalbail@gmail.com</a> <mailto:<a href="mailto:gmoodalbail@gmail.com" target="_blank">gmoodalbail@gmail.com</a>>>> wrote:<br>>>> >>>>>><br>>>> >>>>>><br>>>> >>>>>><br>>>> >>>>>> On Tue, May 26, 2020 at 12:42 PM Han Zhou <<a href="mailto:zhouhan@gmail.com" target="_blank">zhouhan@gmail.com</a><br>>>> >>> <mailto:<a href="mailto:zhouhan@gmail.com" target="_blank">zhouhan@gmail.com</a>><br>>>> >>>>> <mailto:<a href="mailto:zhouhan@gmail.com" target="_blank">zhouhan@gmail.com</a> <mailto:<a href="mailto:zhouhan@gmail.com" target="_blank">zhouhan@gmail.com</a>>>> wrote:<br>>>> >>>>>>><br>>>> >>>>>>> Hi Girish,<br>>>> >>>>>>><br>>>> >>>>>>> Thanks for the summary. I agree with you that GARP request v.s. reply<br>>>> >>>>> is irrelavent to the problem here.<br>>>> >>>><br>>>> >>>> Well, actually I think GARP request vs reply is relevant (at least for<br>>>> >>>> case 1 below) because if OVN would be generating GARP replies we<br>>>> >>>> wouldn't need the priority 80 flow to determine if an ARP request packet<br>>>> >>>> is actually an OVN self originated GARP that needs to be flooded in the<br>>>> >>>> L2 broadcast domain.<br>>>> >>>><br>>>> >>>> On the other hand, router3 would be learning mac_binding IP2,M2 from the<br>>>> >>>> GARP reply originated by router2 and vice versa so we'd have to restrict<br>>>> >>>> flooding of GARP replies to non-patch ports.<br>>>> >>>><br>>>> >>><br>>>> >>> Hi Dumitru, the point was that, on the external LS, the GRs will have to<br>>>> >>> send ARP requests to resolve unknown IPs (at least for the external GW),<br>>>> >>> and it has to be broadcasted, which will cause all the GRs learn all<br>>>> >>> MACs of other GRs. This is regardless of the GARP behavior. You are<br>>>> >>> right that if we only consider the Join switch then the GARP request<br>>>> >>> v.s. reply does make a difference. However, GARP request/reply may be<br>>>> >>> really needed only on the external LS.<br>>>> >>><br>>>> >><br>>>> >> Ok, but do you see an easy way to determine if we need to add the<br>>>> >> logical flows that flood self originated GARP packets on a given logical<br>>>> >> switch? Right now we add them on all switches.<br>>>> >><br>>>> >>>>>>> Please see my comment inline below.<br>>>> >>>>>>><br>>>> >>>>>>> On Tue, May 26, 2020 at 12:09 PM Girish Moodalbail<br>>>> >>>>> <<a href="mailto:gmoodalbail@gmail.com" target="_blank">gmoodalbail@gmail.com</a> <mailto:<a href="mailto:gmoodalbail@gmail.com" target="_blank">gmoodalbail@gmail.com</a>><br>>>> >>> <mailto:<a href="mailto:gmoodalbail@gmail.com" target="_blank">gmoodalbail@gmail.com</a> <mailto:<a href="mailto:gmoodalbail@gmail.com" target="_blank">gmoodalbail@gmail.com</a>>>> wrote:<br>>>> >>>>>>>><br>>>> >>>>>>>> Hello Dumitru,<br>>>> >>>>>>>><br>>>> >>>>>>>> There are several things that are being discussed on this thread.<br>>>> >>>>> Let me see if I can tease them out for clarity.<br>>>> >>>>>>>><br>>>> >>>>>>>> 1. All the router IPs are known to OVN (the join switch case)<br>>>> >>>>>>>> 2. Some IPs are known and some are not known (the external logical<br>>>> >>>>> switch that connects to physical network case).<br>>>> >>>>>>>><br>>>> >>>>>>>> Let us look at each of the case above:<br>>>> >>>>>>>><br>>>> >>>>>>>> 1. Join Switch Case<br>>>> >>>>>>>><br>>>> >>>>>>>> +----------------+        +----------------+<br>>>> >>>>>>>> |   l3gateway    |        |   l3gateway    |<br>>>> >>>>>>>> |    router2     |        |    router3     |<br>>>> >>>>>>>> +-------------+--+        +-+--------------+<br>>>> >>>>>>>>             IP2,M2         IP3,M3<br>>>> >>>>>>>>               |             |<br>>>> >>>>>>>>            +--+-------------+---+<br>>>> >>>>>>>>            |    join switch     |<br>>>> >>>>>>>>            +---------+----------+<br>>>> >>>>>>>>                      |<br>>>> >>>>>>>>                   IP1,M1<br>>>> >>>>>>>>              +-------+--------+<br>>>> >>>>>>>>              |  distributed   |<br>>>> >>>>>>>>              |     router     |<br>>>> >>>>>>>>              +----------------+<br>>>> >>>>>>>><br>>>> >>>>>>>><br>>>> >>>>>>>> Say, GR router2 wants to send the packet out to DR and that we<br>>>> >>>>> don't have static mappings of MAC to IP in lr_in_arp_resolve table on GR<br>>>> >>>>> router2 (with Han's patch of dynamic_neigh_routes=true for all the<br>>>> >>>>> Gateway Routers). With this in mind, when an ARP request is sent out by<br>>>> >>>>> router2's hypervisor the packet should be directly sent to the<br>>>> >>>>> distributed router alone. Your commit 32f5ebb0622 (ovn-northd: Limit<br>>>> >>>>> ARP/ND broadcast domain whenever possible) should have allowed only<br>>>> >>>>> unicast. However, in ls_in_l2_lkup table we have<br>>>> >>>>>>>><br>>>> >>>>>>>>   table=19(ls_in_l2_lkup      ), priority=80   , match=(eth.src ==<br>>>> >>>>> { M2 } && (arp.op == 1 || nd_ns)), action=(outport = "_MC_flood";<br>>>> >>> output;)<br>>>> >>>>>>>>   table=19(ls_in_l2_lkup      ), priority=75   , match=(flags[1] ==<br>>>> >>>>> 0 && arp.op == 1 && arp.tpa == { IP1}), action=(outport =<br>>>> >>>>> "jtor-router2"; output;)<br>>>> >>>>>>>><br>>>> >>>>>>>> As you can see, `priority=80` rule will always be hit and sent out<br>>>> >>>>> to all the GRs. The `priority=75` rule is never hit. So, we will see ARP<br>>>> >>>>> packets on the GENEVE tunnel. So, we need to change `priority=80` to<br>>>> >>>>> match GARP request packets. That way, for the known OVN IPs case we<br>>>> >>>>> don't do broadcast.<br>>>> >>>>>>><br>>>> >>>>>>> Since the solution to case 2) below (i.e.<br>>>> >>>>> learn_from_arp_request=false) solves the problem of case 1), too, I<br>>>> >>>>> think we don't need this change just for case 1). As @Dumitru Ceara<br>>>> >>>>>  mentioned, there is some cost because it adds extra flows. It would be<br>>>> >>>>> significant amount of flows if there are a lot of snat_and_dnat IPs.<br>>>> >>>>> What do you think?<br>>>> >>>><br>>>> >>>> I think the following might be a solution, although with the cost of<br>>>> >>>> adding as many flows as dnat_and_snat IPs are configured:<br>>>> >>>><br>>>> >>>> - priority 80: explicitly determine if an ARP request is a self<br>>>> >>>> originated GARP for configured IP addresses and dnat_and_snat IPs (by<br>>>> >>>> matching on all eth.src and arp.tpa pairs) and if so flood on all<br>>>> >>>> non-patch ports.<br>>>> >>>> - priority 75: if arp.tpa is owned by an OVN logical router port,<br>>>> >>>> "unicast" it only on the patch port towards the router.<br>>>> >>>> - priority 1: flood any broadcast packet.<br>>>> >>>><br>>>> >>>> Together with the learn_from_arp_request=false knob this would cover<br>>>> >>>> both case 1 (join switch) and case 2 (external switch).<br>>>> >>>><br>>>> >>>> Wdyt?<br>>>> >>>><br>>>> >>> Would the "learn_from_arp_request=false knob" cover both cases? If yes,<br>>>> >>> we don't need to add more flows of priority 80, or more accurately:<br>>>> >>> whether to update the priority-80 flows is not directly related to the<br>>>> >>> current problem.<br>>>> >>><br>>>> >><br>>>> >> Yes, it would, except for the fact that the ARP requests would still be<br>>>> >> flooded to all routers (and ignored at the destination). Which is afaiu<br>>>> >> what Girish was worried about. In order to address that part too I'm<br>>>> >> afraid we have to update the priority-80 flows.<br>>>> >><br>>>> >> Regards,<br>>>> >> Dumitru<br>>>> >><br>>>> >>>>>><br>>>> >>>>>><br>>>> >>>>>> Han, yes it will work. However, my only concern is that we would send<br>>>> >>>>> all these ARP requests via tunnel to each of 1000 hypervisors and these<br>>>> >>>>> hypervisors will just drop them on the floor. when they see<br>>>> >>>>> learn_from_arp_request=false.<br>>>> >>>>><br>>>> >>>>> I think maybe it is not a problem since it happens only once on the Join<br>>>> >>>>> switch. Once the MAC is learned, it won't broadcast again. It may be<br>>>> >>>>> more of a problem on the external LS if periodical GARP is required<br>>>> >>>>> there. However, I'd suggest to have some test and see if it is really a<br>>>> >>>>> problem, before trying to solve it.<br>>>> >>>>><br>>>> >>>>>><br>>>> >>>>>> Han, Dumitru,<br>>>> >>>>>><br>>>> >>>>>> Why can't we swap the priorities of the above two flows so that the<br>>>> >>>>> ARP request for NexHop IP known to OVN will be always sent via<br>>>> >>> `unicast`?<br>>>> >>>>><br>>>> >>>>> If swapped, even GARP won't get broadcasted. Maybe that's not the<br>>>> >>>>> desired behavior.<br>>>> >>>>><br>>>> >>>><br>>>> >>>> This is definitely not desired as we'd be hitting the prio 75 flow that<br>>>> >>>> would send the self originated GARP request (IPx) packet back towards<br>>>> >>>> the router port that owns IPx.<br>>>> >>>><br>>>> >>>>>><br>>>> >>>>>> Regards,<br>>>> >>>>>> ~Girish<br>>>> >>>>>><br>>>> >>>>>>><br>>>> >>>>>>>><br>>>> >>>>>>>> 2. External Logical Switch Case<br>>>> >>>>>>>><br>>>> >>>>>>>>                        <a href="http://10.10.10.0/24" target="_blank">10.10.10.0/24</a> <<a href="http://10.10.10.0/24" target="_blank">http://10.10.10.0/24</a>><br>>>> >>> <<a href="http://10.10.10.0/24" target="_blank">http://10.10.10.0/24</a>><br>>>> >>>>><br>>>> >>>>>>>>    -------------------------+--------------------------<br>>>> >>>>>>>>                             |<br>>>> >>>>>>>>                          localnet<br>>>> >>>>>>>>                       +-----+-----+<br>>>> >>>>>>>>                       | external  |<br>>>> >>>>>>>>          +------------+    LS1    +-------------+<br>>>> >>>>>>>>          |            +-----+-----+             |<br>>>> >>>>>>>>          |                  |                   |<br>>>> >>>>>>>>      10.10.10.2         10.10.10.3          10.10.10.4<br>>>> >>>>>>>>         SNAT               SNAT                SNAT<br>>>> >>>>>>>>    +-----+-----+      +-----+-----+       +-----------+<br>>>> >>>>>>>>    | l3gateway |      | l3gateway |       | l3gateway |<br>>>> >>>>>>>>    |   node1   |      |   node2   |       |   node3   |<br>>>> >>>>>>>>    +-----------+      +-----------+       +-----------+<br>>>> >>>>>>>><br>>>> >>>>>>>> In this case, we have some of the IPs in OVN and some in the<br>>>> >>>>> physical network. If we fix (1) above, all the ARP requests for the<br>>>> >>>>> OVN's router IPs will be unicast. However, all the ARP requests to<br>>>> >>>>> external IPs, say 10.10.10.1 on the "physical router", will be<br>>>> >>>>> broadcast. Now, we will see these ARP broadcasts on all the L3 gateway<br>>>> >>>>> routers. With 'learn_from_arp_request=false' [a], then the MAC_Binding<br>>>> >>>>> table will not explode for both ARP and GARP requests.<br>>>> >>>>>>>><br>>>> >>>>>>>> So, I don't think GARP requests and replies is the issue here?<br>>>> >>>>> Furthermore, learning from the GARP replies are blocked on certain<br>>>> >>>>> routers. For example:<br>>>> >>>>><br>>>> >>>  <a href="https://www.juniper.net/documentation/en_US/junose15.1/topics/concept/ip-gratuitous-arps-transmission-overview.html" target="_blank">https://www.juniper.net/documentation/en_US/junose15.1/topics/concept/ip-gratuitous-arps-transmission-overview.html</a><br>>>> >>>>>  says "By default, updating the ARP cache on GARP replies is disabled on<br>>>> >>>>> the router.". So, our NAT addresses mapping will not be learnt.<br>>>> >>>><br>>>> >>>> Just as a side note, the above doesn't mean Juniper boxes don't support<br>>>> >>>> learning from GARP replies, just that they'd need extra configuration. I<br>>>> >>>> don't necessarily think that's a bad thing if properly documented in OVN<br>>>> >>>> that we would be generating GARP replies.<br>>>> >>>><br>>>> >>>> Regards,<br>>>> >>>> Dumitru<br>>>> >>>><br>>>> >>>>>>>><br>>>> >>>>>>>> Regards,<br>>>> >>>>>>>> ~Girish<br>>>> >>>>>>>><br>>>> >>>>>>>><br>>>> >>>>>>>> [a] - From Han's mail, the meaning of learn_from_arp_request=false<br>>>> >>>>> --> if the TPA is on the router, add a new entry (it means the<br>>>> >>>>>>>>>     remote wants to communicate with this node, so it makes<br>>>> >>> sense to<br>>>> >>>>>>>>>     learn the remote as well). Otherwise, ignore it and no new<br>>>> >>>>> entry added.<br>>>> >>>>>>>><br>>>> >>>>>>>><br>>>> >>>>>>>><br>>>> >>>>>><br>>>> >>>>>> --<br>>>> >>>>>> You received this message because you are subscribed to the Google<br>>>> >>>>> Groups "ovn-kubernetes" group.<br>>>> >>>>>> To unsubscribe from this group and stop receiving emails from it, send<br>>>> >>>>> an email to <a href="mailto:ovn-kubernetes%2Bunsubscribe@googlegroups.com" target="_blank">ovn-kubernetes+unsubscribe@googlegroups.com</a><br>>>> >>> <mailto:<a href="mailto:ovn-kubernetes%252Bunsubscribe@googlegroups.com" target="_blank">ovn-kubernetes%2Bunsubscribe@googlegroups.com</a>><br>>>> >>>>> <mailto:<a href="mailto:ovn-kubernetes%252Bunsubscribe@googlegroups.com" target="_blank">ovn-kubernetes%2Bunsubscribe@googlegroups.com</a><br>>>> >>> <mailto:<a href="mailto:ovn-kubernetes%25252Bunsubscribe@googlegroups.com" target="_blank">ovn-kubernetes%252Bunsubscribe@googlegroups.com</a>>>.<br>>>> >>>>>> To view this discussion on the web visit<br>>>> >>>>><br>>>> >>> <a href="https://groups.google.com/d/msgid/ovn-kubernetes/CAAF2STRnem2PeSahuwhro1t%2BQJxchZNC7viq8n-ngM9KU%2B%2B-Xw%40mail.gmail.com" target="_blank">https://groups.google.com/d/msgid/ovn-kubernetes/CAAF2STRnem2PeSahuwhro1t%2BQJxchZNC7viq8n-ngM9KU%2B%2B-Xw%40mail.gmail.com</a>.<br>>>> >>>><br>>>> >>><br>>>> >>> --<br>>>> >>> You received this message because you are subscribed to the Google<br>>>> >>> Groups "ovn-kubernetes" group.<br>>>> >>> To unsubscribe from this group and stop receiving emails from it, send<br>>>> >>> an email to <a href="mailto:ovn-kubernetes%2Bunsubscribe@googlegroups.com" target="_blank">ovn-kubernetes+unsubscribe@googlegroups.com</a><br>>>> >>> <mailto:<a href="mailto:ovn-kubernetes%2Bunsubscribe@googlegroups.com" target="_blank">ovn-kubernetes+unsubscribe@googlegroups.com</a>>.<br>>>> >>> To view this discussion on the web visit<br>>>> >>> <a href="https://groups.google.com/d/msgid/ovn-kubernetes/CADtzDCkHGft30Vx_Yx3fiCeki4NM4YwCvNJaU2S2mGv4buLwgg%40mail.gmail.com" target="_blank">https://groups.google.com/d/msgid/ovn-kubernetes/CADtzDCkHGft30Vx_Yx3fiCeki4NM4YwCvNJaU2S2mGv4buLwgg%40mail.gmail.com</a><br>>>> >>> <<a href="https://groups.google.com/d/msgid/ovn-kubernetes/CADtzDCkHGft30Vx_Yx3fiCeki4NM4YwCvNJaU2S2mGv4buLwgg%40mail.gmail.com?utm_medium=email&utm_source=footer" target="_blank">https://groups.google.com/d/msgid/ovn-kubernetes/CADtzDCkHGft30Vx_Yx3fiCeki4NM4YwCvNJaU2S2mGv4buLwgg%40mail.gmail.com?utm_medium=email&utm_source=footer</a>>.<br>>>> >><br>>>> >> _______________________________________________<br>>>> >> discuss mailing list<br>>>> >> <a href="mailto:discuss@openvswitch.org" target="_blank">discuss@openvswitch.org</a><br>>>> >> <a href="https://mail.openvswitch.org/mailman/listinfo/ovs-discuss" target="_blank">https://mail.openvswitch.org/mailman/listinfo/ovs-discuss</a><br>>>> ><br>>>><br>>> --<br>>> You received this message because you are subscribed to the Google Groups "ovn-kubernetes" group.<br>>> To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:ovn-kubernetes%2Bunsubscribe@googlegroups.com" target="_blank">ovn-kubernetes+unsubscribe@googlegroups.com</a>.<br>>> To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/ovn-kubernetes/CADO7ZnoBqbOvo-2jjTOKPA3otgA_4LYqiao2k718guFdW8kTAg%40mail.gmail.com" target="_blank">https://groups.google.com/d/msgid/ovn-kubernetes/CADO7ZnoBqbOvo-2jjTOKPA3otgA_4LYqiao2k718guFdW8kTAg%40mail.gmail.com</a>.</div></div>
</blockquote></div>