<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br>On Sat, Nov 10, 2018 at 12:21 AM Ben Pfaff &lt;<a href="mailto:blp@ovn.org" target="_blank">blp@ovn.org</a>&gt; wrote:<br>&gt;<br>&gt; On Mon, Oct 29, 2018 at 05:21:13PM +0530, Numan Siddique wrote:<br>&gt; &gt; On Mon, Oct 29, 2018 at 5:00 PM Daniel Alvarez Sanchez &lt;<a href="mailto:dalvarez@redhat.com" target="_blank">dalvarez@redhat.com</a>&gt;<br>&gt; &gt; wrote:<br>&gt; &gt;<br>&gt; &gt; &gt; Hi,<br>&gt; &gt; &gt;<br>&gt; &gt; &gt; After digging further. The problem seems to be reduced to reusing an<br>&gt; &gt; &gt; old gateway IP address for a dnat_and_snat entry.<br>&gt; &gt; &gt; When a gateway port is bound to a chassis, its entry will show up in<br>&gt; &gt; &gt; the MAC_Binding table (at least when that Logical Switch is connected<br>&gt; &gt; &gt; to more than one Logical Router). After deleting the Logical Router<br>&gt; &gt; &gt; and all its ports, this entry will remain there. If a new Logical<br>&gt; &gt; &gt; Router is created and a Floating IP (dnat_and_snat) is assigned to a<br>&gt; &gt; &gt; VM with the old gw IP address, it will become unreachable.<br>&gt; &gt; &gt;<br>&gt; &gt; &gt; A workaround now from networking-ovn (OpenStack integration) is to<br>&gt; &gt; &gt; delete MAC_Binding entries for that IP address upon a FIP creation. I<br>&gt; &gt; &gt; think that this however should be done from OVN, what do you folks<br>&gt; &gt; &gt; think?<br>&gt; &gt; &gt;<br>&gt; &gt; &gt;<br>&gt; &gt; Agree. Since the MAC_Binding table row is created by ovn-controller, it<br>&gt; &gt; should<br>&gt; &gt; be handled properly within OVN.<br>&gt;<br>&gt; I see that this has been sitting here for a while.  The solution seems<br>&gt; reasonable to me.  Are either of you working on it?<br><br>I started working on it. I came up with a solution (see patch below) which works but I wanted to give you a bit more of context and get your feedback:<br><br><br><div><div><font face="monospace, monospace">                           ^ localnet</font></div><div><font face="monospace, monospace">                           |</font></div><div><font face="monospace, monospace">                       +---+---+</font></div><div><font face="monospace, monospace">                       |       |</font></div><div><font face="monospace, monospace">                +------+  pub  +------+</font></div><div><font face="monospace, monospace">                |      |       |      |</font></div><div><font face="monospace, monospace">                |      +-------+      |</font></div><div><font face="monospace, monospace">                |    <a href="http://172.24.4.0/24" target="_blank">172.24.4.0/24</a>    |</font></div><div><font face="monospace, monospace">                |                     |</font></div><div><font face="monospace, monospace">   172.24.4.220 |                     | 172.24.4.221</font></div><div><font face="monospace, monospace">            +---+---+             +---+---+</font></div><div><font face="monospace, monospace">            |       |             |       |</font></div><div><font face="monospace, monospace">            |  LR0  |             |  LR1  |</font></div><div><font face="monospace, monospace">            |       |             |       |</font></div><div><font face="monospace, monospace">            +---+---+             +---+---+</font></div><div><font face="monospace, monospace">     10.0.0.254 |                     | 20.0.0.254</font></div><div><font face="monospace, monospace">                |                     |</font></div><div><font face="monospace, monospace">            +---+---+             +---+---+</font></div><div><font face="monospace, monospace">            |       |             |       |</font></div><div><font face="monospace, monospace"><a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a> |  SW0  |             |  SW1  | <a href="http://20.0.0.0/24" target="_blank">20.0.0.0/24</a></font></div><div><font face="monospace, monospace">            |       |             |       |</font></div><div><font face="monospace, monospace">            +---+---+             +---+---+</font></div><div><font face="monospace, monospace">                |                     |</font></div><div><font face="monospace, monospace">                |                     |</font></div><div><font face="monospace, monospace">            +---+---+             +---+---+</font></div><div><font face="monospace, monospace">            |       |             |       |</font></div><div><font face="monospace, monospace">            |  VM0  |             |  VM1  |</font></div><div><font face="monospace, monospace">            |       |             |       |</font></div><div><font face="monospace, monospace">            +-------+             +-------+</font></div><div><font face="monospace, monospace">            10.0.0.10             20.0.0.10</font></div><div><font face="monospace, monospace">          172.24.4.100           172.24.4.200</font></div></div><div><br></div><div><br></div><div>When I ping VM1 floating IP from the external network, a new entry for 172.24.4.221 in the LR0 datapath appears in the MAC_Binding table:</div><div><br></div><div><div>_uuid               : 85e30e87-3c59-423e-8681-ec4cfd9205f9</div><div>datapath            : ac5984b9-0fea-485f-84d4-031bdeced29b</div><div>ip                  : &quot;172.24.4.221&quot;</div><div>logical_port        : &quot;lrp02&quot;</div><div>mac                 : &quot;00:00:02:01:02:04&quot;</div></div><div><br></div><div><br></div><div>Now, if LR1 gets removed and the old gateway IP (172.24.4.221) is reused for VM2 FIP with different MAC and new gateway IP is created (for example 172.24.4.222 00:00:02:01:02:99),  VM2 FIP becomes unreachable from VM1 until the old MAC_Binding entry gets deleted as pinging 172.24.4.221 will use the wrong address (&quot;00:00:02:01:02:04&quot;).</div><div><br></div><div>With the patch below, removing LR1 results in deleting all MAC_Binding entries for every datapath where &#39;172.24.4.221&#39; appears in the &#39;ip&#39; column so the problem goes away.</div><div><br></div><div>Another solution would be implementing some kind of &#39;aging&#39; for MAC_Binding entries but perhaps it&#39;s more complex.</div><div>Looking forward for your comments :)</div><div><br></div><div><br></div><div>diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c<br></div></div><div dir="ltr">index 58bef7d..a86733e 100644<br>--- a/ovn/northd/ovn-northd.c<br>+++ b/ovn/northd/ovn-northd.c<br>@@ -2324,6 +2324,18 @@ cleanup_mac_bindings(struct northd_context *ctx, struct hmap *ports)<br>     }<br> }<br><br>+static void<br>+delete_mac_binding_by_ip(struct northd_context *ctx, const char *ip)<br>+{<br>+    const struct sbrec_mac_binding *b, *n;<br>+    SBREC_MAC_BINDING_FOR_EACH_SAFE (b, n, ctx-&gt;ovnsb_idl) {<br>+        if (strstr(ip, b-&gt;ip)) {<br>+            sbrec_mac_binding_delete(b);<br>+        }<br>+    }<br>+}<br>+<br>+<br> /* Updates the southbound Port_Binding table so that it contains the logical<br>  * switch ports specified by the northbound database.<br>  *<br>@@ -2383,6 +2395,15 @@ build_ports(struct northd_context *ctx,<br>     /* Delete southbound records without northbound matches. */<br>     LIST_FOR_EACH_SAFE(op, next, list, &amp;sb_only) {<br>         ovs_list_remove(&amp;op-&gt;list);<br>+<br>+        /* Delete all MAC_Binding entries which match the IP addresses of the<br>+         * deleted logical router port (ie. port with a peer). */<br>+        const char *peer = smap_get(&amp;op-&gt;sb-&gt;options, &quot;peer&quot;);<br>+        if (peer) {<br>+            for (int i = 0; i &lt; op-&gt;sb-&gt;n_mac; i++) {<br>+                delete_mac_binding_by_ip(ctx, op-&gt;sb-&gt;mac[i]);<br>+            }<br>+        }<br>         sbrec_port_binding_delete(op-&gt;sb);<br>         ovn_port_destroy(ports, op);<br>     }</div></div></div></div></div>