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" <[email protected]> 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: [email protected] >> [mailto:[email protected]] On Behalf Of ychen >> Sent: Tuesday, 27 March, 2018 14:44 >> To: [email protected] >> 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 >> [email protected] >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
