On 2017/12/17 5:01, Adrian P wrote: ... > Further investigation reveals something strange: when the > communication starts with an arp request (which happens almost all the > time), the bridge wrongly assigns the eth0 mac address to port 1, > instead of port 3. > > Flow again: > > default gw --- vmware --- [ ens160 bridge tap ] --- eth0 > > On my bridge, ens160 is port 1, and the tap interface is port 3. Eth0 > mac address is fa:16:3e:9a:04:95 > > What I have found is that in the forwarding table, the bridge wrongly > assigns the eth0 mac address to the port 1, which is ens160 interface, > instead of assigning it to the port 3, which is the tap interface. > This happens only if the arp table in the cirros VM instance does not > contain the mac address of the destination I am pinging (default gw in > this case), so the cirros VM sends an arp request. See below the eth0 > mac address wrongly assigned in the forwarding table to the port 1: > > # brctl showmacs brq025a9a94-58 | grep fa:16:3e:9a:04:95 > 1 fa:16:3e:9a:04:95 no 0.67 > > However, if I manually add the mac address of the destination IP I am > pining into the cirros VM instance arp table, and there is no arp > request sent, just icmp packets going out, then the bridge correctly > assigns the eth0 mac address to the port 3, which is the tap > interface, and everything starts working fine. See below the eth0 mac > address correctly assigned in the forwarding table to the port 3: > > # brctl showmacs brq025a9a94-58 | grep fa:16:3e:9a:04:95 > 3 fa:16:3e:9a:04:95 no 9.26 > It looks like the broadcast arp request is coming back from gw or vmware. Would you check it? -- Toshiaki Makita
