Hi Ychen, If your tunnel NH is moving IP addresses between MAC addresses or changing the MAC address of an interface hosting the NH IP, I think it should send a GARP to inform the connected subnet about this change. Otherwise the neighbors will blackhole traffic by sending to the wrong MAC address until they refresh their ARP cache. What kind of tunnel NH are you using? A Linux host?
OVS has no means to buffer packets while it is waiting for the ARP reply for an ARP request it has sent out to resolve the tunnel NH. The OVS datapath (including the slowpath) is essentially stateless. This is quite different from the Linux kernel. Your suggestion to let OVS snoop on any incoming tunnel packet to refresh the ARP cache for the tunnel NH seems impractical to me. Normally the tunnel packets are matched by megaflows in the netdev datapath, the tunnel headers are stripped and the packet is recirculated. All this happens down in the datapath, while the ARP cache lives in the ofproto layer. A safe way would be to trigger an ARP refresh in the ofproto layer for every known tunnel neighbor some time before the expiry of its cache entry, similar to what real IP stacks do. But that would duplicate the already available function on the host. I'd rather try to find out why the host is not refreshing the ARP entry or why OVS does not detect the reply to the ARP refresh. BR, Jan From: ychen [mailto:ychen103...@163.com] Sent: Wednesday, 28 March, 2018 06:17 To: Jan Scheurich <jan.scheur...@ericsson.com> Cc: d...@openvswitch.org; Manohar Krishnappa Chidambaraswamy <manohar.krishnappa.chidambarasw...@ericsson.com> Subject: RE: [ovs-dev] can not update userspace vxlan tunnel neigh mac when peer VTEP mac changed HI, Jan, Thanks for your reply. we have already modify code snooping on the GARP packets, but these 2 problem still exists. I think the main problem is that GARP packets are not sending from interfaces when we changed NIC mac address or IP address(read the linux kernel code, there is no such process) so we must depend on data packet to trigger the ARP request. I know that in linux kernel, when ARP packet is triggered, data packets will be cached in a specified time, so the first data packet can still be send out when ARP reply is received. for the second problem, can we update tunnel neigh cache when we receive data packet from remote VTEP? since we can fetch tun_src and outer mac sa from the data packet. At 2018-03-28 04:41:12, "Jan Scheurich" <jan.scheur...@ericsson.com<mailto:jan.scheur...@ericsson.com>> wrote: >Hi Ychen, > >Funny! Again we are already working on a solution for problem 1. > >In our scenario the situation arises with a tunnel next hop being a VRRP >switch pair. The switch sends periodic gratuitous ARPs (GARPs) to announce the >VRRP IP&MAC but OVS native tunneling doesn't snoop on GARPs, only on ARP >replies. The host IP stack, on the other hand, accepts these GARPs and stops >sending refresh ARP requests itself. Hence nothing for OVS to snoop upon. > >The solution is to make OVS snoop on GARP requests also. > >It is quite possible that this will also fix your problem 2. If you also have >a VRRP tunnel next hop which just moves its VRRP IP address but not the MAC >address, should send a GARP with the new IP/MAC mapping when it moves the IP >address, which would now update OVS' tunnel neighbor cache. > >@Mano: Can you submit the GARP patch in the near future? > >BR, Jan > >> -----Original Message----- >> From: >> ovs-dev-boun...@openvswitch.org<mailto:ovs-dev-boun...@openvswitch.org> >> [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of ychen >> Sent: Tuesday, 27 March, 2018 14:44 >> To: d...@openvswitch.org<mailto:d...@openvswitch.org> >> Subject: [ovs-dev] can not update userspace vxlan tunnel neigh mac when peer >> VTEP mac changed >> >> Hi, >> I found that sometime userspace vxlan can not work happily. >> 1. first data packet loss >> when tunnel neigh cache is empty, then the first data packet >> triggered sending ARP packet to peer VTEP, and the data packet >> dropped, >> tunnel neigh cache added this entry when receive ARP reply packet. >> >> err = tnl_neigh_lookup(out_dev->xbridge->name, &d_ip6, &dmac); >> if (err) { >> xlate_report(ctx, OFT_DETAIL, >> "neighbor cache miss for %s on bridge %s, " >> "sending %s request", >> buf_dip6, out_dev->xbridge->name, d_ip ? "ARP" : "ND"); >> if (d_ip) { >> tnl_send_arp_request(ctx, out_dev, smac, s_ip, d_ip); >> } else { >> tnl_send_nd_request(ctx, out_dev, smac, &s_ip6, &d_ip6); >> } >> return err; >> } >> >> >> 2. connection lost when peer VTEP mac changed >> when VTEP mac is already in tunnel neigh cache, exp: >> 10.182.6.81 fa:eb:26:c3:16:a5 br-phy >> >> so when data packet come in, it will use this mac for encaping outer >> VXLAN header. >> but VTEP 10.182.6.81 mac changed from fa:eb:26:c3:16:a5 to >> 24:eb:26:c3:16:a5 because of NIC changed. >> >> data packet continue sending with the old mac fa:eb:26:c3:16:a5, but >> the peer VTEP will not accept these packets because of mac >> not match. >> the wrong tunnel neigh entry aging until the data packet stop sending. >> >> >> if (ovs_native_tunneling_is_on(ctx->xbridge->ofproto)) { >> tnl_neigh_snoop(flow, wc, ctx->xbridge->name); >> } >> >> >> 3. is there anybody has working for these problems? >> >> >> >> _______________________________________________ >> dev mailing list >> d...@openvswitch.org<mailto: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
