<div dir="ltr"><div>Hi Girish, Venu,</div><div><br></div><div>I sent a RFC patch series for the solution discussed. Could you give it a try when you get the chance?</div><div><br></div><div>Thanks,</div><div>Han<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 9, 2020 at 10:04 AM 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"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 9, 2020 at 9:06 AM Venugopal Iyer <<a href="mailto:venugopali@nvidia.com" target="_blank">venugopali@nvidia.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 lang="EN-US">
<div>
<p class="MsoNormal">Sorry for the delay, Han, a quick question below:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-left:0.5in"><b>From:</b> <a href="mailto:ovn-kubernetes@googlegroups.com" target="_blank">ovn-kubernetes@googlegroups.com</a> <<a href="mailto:ovn-kubernetes@googlegroups.com" target="_blank">ovn-kubernetes@googlegroups.com</a>>
<b>On Behalf Of </b>Han Zhou<br>
<b>Sent:</b> Wednesday, June 3, 2020 4:27 PM<br>
<b>To:</b> Girish Moodalbail <<a href="mailto:gmoodalbail@gmail.com" target="_blank">gmoodalbail@gmail.com</a>><br>
<b>Cc:</b> Tim Rozet <<a href="mailto:trozet@redhat.com" target="_blank">trozet@redhat.com</a>>; Dumitru Ceara <<a href="mailto:dceara@redhat.com" target="_blank">dceara@redhat.com</a>>; Daniel Alvarez Sanchez <<a href="mailto:dalvarez@redhat.com" target="_blank">dalvarez@redhat.com</a>>; Dan Winship <<a href="mailto:danwinship@redhat.com" target="_blank">danwinship@redhat.com</a>>; <a href="mailto:ovn-kubernetes@googlegroups.com" target="_blank">ovn-kubernetes@googlegroups.com</a>; ovs-discuss <<a href="mailto:ovs-discuss@openvswitch.org" target="_blank">ovs-discuss@openvswitch.org</a>>; Michael Cambria <<a href="mailto:mcambria@redhat.com" target="_blank">mcambria@redhat.com</a>>;
 Venugopal Iyer <<a href="mailto:venugopali@nvidia.com" target="_blank">venugopali@nvidia.com</a>><br>
<b>Subject:</b> Re: [ovs-discuss] [OVN] flow explosion in lr_in_arp_resolve table<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
<table style="margin-left:0.5in;background:rgb(255,235,156) none repeat scroll 0% 0%" cellspacing="3" cellpadding="0" border="1">
<tbody>
<tr>
<td style="padding:0.75pt">
<p class="MsoNormal"><b><span style="font-size:7.5pt;font-family:"Verdana",sans-serif;color:black">External email: Use caution opening links or attachments</span></b><span style="font-size:7.5pt;font-family:"Verdana",sans-serif;color:black">
</span><u></u><u></u></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">Hi Girish, yes, that's what we concluded in last OVN meeting, but sorry that I forgot to update here.<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><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).<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-left:0.5in">><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">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><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">I am working on the formal patch.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<p class="MsoNormal" style="margin-left:0.5in">> 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))<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-left:0.5in">><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">I am working on this as well, but delayed a little. I hope to have something this week.<u></u><u></u></p>
<p class="MsoNormal"><b><i>[vi> ] Just wanted to check if this should be learn_From_unsolicit_arp (unsolicited ARP request or reply) instead of learn_from_arp_request? This is just to protect from potential rogue usage of  GARP reply flooding the MAC bindings.?<u></u><u></u></i></b></p>
<p class="MsoNormal"><b><i><u></u> </i></b></p></div></div></div></div></div></div></blockquote><div><br></div><div>Hi Venu, as discussed earlier in this thread it is hard to check if it is GARP in OVN from the router ingress pipeline. The proposal here cares about ARP request only. It seems the best option so far.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><div><div><div><div><p class="MsoNormal"><b><i><u></u></i></b></p>
<p class="MsoNormal"><b><i>Thanks,<u></u><u></u></i></b></p>
<p class="MsoNormal"><b><i><u></u> <u></u></i></b></p>
<p class="MsoNormal"><b><i>-venu</i></b><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<p class="MsoNormal" style="margin-left:0.5in">><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>.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:0.5in">-- <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+unsubscribe@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/CADtzDCma-PU%3D3Gd%3DKLOkzuWKrKdBmqWVc-%3Dd-h6KAUqcvbzMgA%40mail.gmail.com?utm_medium=email&utm_source=footer" target="_blank">
https://groups.google.com/d/msgid/ovn-kubernetes/CADtzDCma-PU%3D3Gd%3DKLOkzuWKrKdBmqWVc-%3Dd-h6KAUqcvbzMgA%40mail.gmail.com</a>.<u></u><u></u></p>
</div>
</div>
</div>

</blockquote></div></div>
</blockquote></div>