On Wed, 2016-11-23 at 10:33 +0200, Julian Anastasov wrote: > Hello, > > On Wed, 23 Nov 2016, yuehaibing wrote: > > > As to my topo,HOST1 and HOST3 share one route on HOST2, tcp connection > > between HOST2 and HOST3 may call tcp_ack to set dst->pending_confirm. > > > > So dst_neigh_output may wrongly freshed n->confirmed which stands for > > HOST1,however HOST1'MAC had been changed. > > > > The possibility of this occurred Significantly increases ,when ping and > > TCP transaction are set the same processor affinity on the HOST2. > > > > It seems that the issue is brought in commit > > 5110effee8fde2edfacac9cd12a9960ab2dc39ea ("net: Do delayed neigh > > confirmation."). > > Bad news. Problem is not in delayed confirmation but > in the mechanism to use same dst for different neighbours on > LAN. We don't have a dst->neighbour reference anymore. > > For IPv4 this is related to rt->rt_uses_gateway but > also to DST_NOCACHE. In the other cases we can not call > dst_confirm, may be we should lookup the neigh entry instead. > But we need a way to reduce such lookups on every packet, > for example, by remembering in struct sock and checking if > some bits of jiffies (at least 4-5) are changed from > previous lookup.
I thought bonding would keep the MAC address 'alive'. If TCP packets are confirmed, this means the old MAC address is still valid, what am I missing here ?