Comment 10 for bug 1512199

@Swaminathan, I used code from stable/kilo. Maybe it has some difference from yours.
When i change the vm1 fixed ip from 10.0.20.4 to 10.0.20.22+10.0.20.24, the arp cache in local compute node A is:
# ip netns exec qrouter-ddda3633-da7e-4fb1-9bc9-7f762a40f962 arp -n
Address HWtype HWaddress Flags Mask Iface
10.0.30.11 ether fa:16:3e:4c:3c:2e CM qr-08365e9f-76
10.0.20.22 ether fa:16:3e:38:bb:ea CM qr-8cb7b03f-77
10.0.20.7 ether fa:16:3e:43:06:0f CM qr-8cb7b03f-77
10.0.30.2 (incomplete) qr-08365e9f-76
10.0.30.10 ether fa:16:3e:1f:50:9d CM qr-08365e9f-76
10.0.20.6 ether fa:16:3e:7a:82:03 CM qr-8cb7b03f-77
10.0.20.4 ether fa:16:3e:38:bb:ea CM qr-8cb7b03f-77
10.0.20.2 ether fa:16:3e:8b:c3:4b CM qr-8cb7b03f-77
10.0.20.24 ether fa:16:3e:38:bb:ea C qr-8cb7b03f-77

the arp cache in another compute node B is:
# ip netns exec qrouter-ddda3633-da7e-4fb1-9bc9-7f762a40f962 arp -n
Address HWtype HWaddress Flags Mask Iface
10.0.30.11 ether fa:16:3e:4c:3c:2e CM qr-08365e9f-76
10.0.20.24 (incomplete) qr-8cb7b03f-77
10.0.20.6 ether fa:16:3e:7a:82:03 CM qr-8cb7b03f-77
10.0.20.4 ether fa:16:3e:38:bb:ea CM qr-8cb7b03f-77
10.0.20.22 ether fa:16:3e:38:bb:ea CM qr-8cb7b03f-77
10.0.20.2 ether fa:16:3e:8b:c3:4b CM qr-8cb7b03f-77
10.0.20.20 (incomplete) qr-8cb7b03f-77
10.0.30.10 ether fa:16:3e:1f:50:9d CM qr-08365e9f-76
10.0.20.7 ether fa:16:3e:43:06:0f CM qr-8cb7b03f-77
10.0.20.10 (incomplete) qr-8cb7b03f-77
10.0.30.2 (incomplete) qr-08365e9f-76

The mac for ip 10.0.20.24 could not learnt by arp request in dvr. So vm from other subnet in compute B could connect to vm1, but vm which in the same subnet with vm1 in compute B could connect to vm1.

Besides, if I assign one more ip address to vm using allowed_address_pairs, the results is the same that new assigned ip could not use.