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