<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 19, 2018 at 2:56 PM Daniel Alvarez Sanchez <<a href="mailto:dalvarez@redhat.com">dalvarez@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Having thought this again, I'd rather merge the patch I proposed in my previous email (I'd need tests and propose a formal patch after your feedback) but in the long term I think it'd make sense to also implement some sort of aging to the MAC_Binding entries so that they eventually expire, especially for entries that come from external networks.</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 16, 2018 at 6:41 PM Daniel Alvarez Sanchez <<a href="mailto:dalvarez@redhat.com" target="_blank">dalvarez@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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 <<a href="mailto:blp@ovn.org" target="_blank">blp@ovn.org</a>> wrote:<br>><br>> On Mon, Oct 29, 2018 at 05:21:13PM +0530, Numan Siddique wrote:<br>> > On Mon, Oct 29, 2018 at 5:00 PM Daniel Alvarez Sanchez <<a href="mailto:dalvarez@redhat.com" target="_blank">dalvarez@redhat.com</a>><br>> > wrote:<br>> ><br>> > > Hi,<br>> > ><br>> > > After digging further. The problem seems to be reduced to reusing an<br>> > > old gateway IP address for a dnat_and_snat entry.<br>> > > When a gateway port is bound to a chassis, its entry will show up in<br>> > > the MAC_Binding table (at least when that Logical Switch is connected<br>> > > to more than one Logical Router). After deleting the Logical Router<br>> > > and all its ports, this entry will remain there. If a new Logical<br>> > > Router is created and a Floating IP (dnat_and_snat) is assigned to a<br>> > > VM with the old gw IP address, it will become unreachable.<br>> > ><br>> > > A workaround now from networking-ovn (OpenStack integration) is to<br>> > > delete MAC_Binding entries for that IP address upon a FIP creation. I<br>> > > think that this however should be done from OVN, what do you folks<br>> > > think?<br>> > ><br>> > ><br>> > Agree. Since the MAC_Binding table row is created by ovn-controller, it<br>> > should<br>> > be handled properly within OVN.<br>><br>> I see that this has been sitting here for a while. The solution seems<br>> 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 : "172.24.4.221"</div><div>logical_port : "lrp02"</div><div>mac : "00:00:02:01:02:04"</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 ("00:00:02:01:02:04").</div><div><br></div><div>With the patch below, removing LR1 results in deleting all MAC_Binding entries for every datapath where '172.24.4.221' appears in the 'ip' column so the problem goes away.</div><div><br></div><div>Another solution would be implementing some kind of 'aging' for MAC_Binding entries but perhaps it's more complex.</div><div>Looking forward for your comments :)</div><div><br></div></div></div></div></div></div></blockquote></div></blockquote><div><br></div><div>As discussed with you offline, ageing itself might not solve this issue. We might still hit the issue until the mac _binding entry ages out and flushed out. Your proposed solution seems fine to me.</div><div><br></div><div>Thanks</div><div>Numan</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div></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->ovnsb_idl) {<br>+ if (strstr(ip, b->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, &sb_only) {<br> ovs_list_remove(&op->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(&op->sb->options, "peer");<br>+ if (peer) {<br>+ for (int i = 0; i < op->sb->n_mac; i++) {<br>+ delete_mac_binding_by_ip(ctx, op->sb->mac[i]);<br>+ }<br>+ }<br> sbrec_port_binding_delete(op->sb);<br> ovn_port_destroy(ports, op);<br> }</div></div></div></div></div>
</blockquote></div>
</blockquote></div></div>