On 2016/11/24 15:51, Julian Anastasov wrote: > > Hello, > > On Wed, 23 Nov 2016, Eric Dumazet wrote: > >> On Wed, 2016-11-23 at 15:37 +0100, Hannes Frederic Sowa wrote: >> >>> Irregardless about the question if bonding should keep the MAC address >>> alive, a MAC address can certainly change below a TCP connection. >> >> Of course ;) >>
I configured bonding fail_over_mac=1 ,so the bonding MAC always be the MAC address of the currently active slave. >>> >>> dst_entry is 1:n to neigh_entry and as such we can end up confirming an >>> aging neighbor while sending a reply with dst->pending_confirm set while >>> the confirming packet actually came from a different neighbor. >>> >>> I agree with Julian, pending_confirm became useless in this way. >> >> Let's kill it then ;) > > It works for traffic via gateway. I now see that > we can even avoid write in dst_confirm: > > if (!dst->pending_confirm) > dst->pending_confirm = 1; > > because it is called by non-dup TCP ACKs. > > But for traffic to hosts on LAN we need different solution, > i.e. for cached dsts with rt_gateway = 0 (last entry below). > > rt_uses_gateway rt_gateway DST_NOCACHE Description > ==================================================================== > 1 nh_gw ANY Traffic via gateway > 0 LAN_host 1 FLOWI_FLAG_KNOWN_NH (nexthop > set by IPVS, hdrincl, xt_TEE) > 0 0 0 1 dst for many subnet hosts > > Regards > > -- > Julian Anastasov <j...@ssi.bg> > > . > As above,Is there a plan to fix the problem ? Should we just not call dst_confirm when in the case rt->rt_uses_gateway/DST_NOCACHE?
