Resolving MAC address conflicts for different namespaces in neutron

Yesterday our tester asked for a bug:
1. New VM (IP assigned via DHCP)
2. Bind the public network IP, after the public network ip,ssh login, delete the VM.
3. Then create a new VM, manually assign IP,IP using the intranet IP in step 1.
4. After binding the public network IP, SSH authentication, unable to connect.

The following are reproduced:
IP and MAC addresses for virtual machines:

192.168.10.2 fa:16:3e:33:8e:7c

After you delete the virtual machine, recreate it, and get the MAC address:

fa:16:3e:be:1a:3e

Ping the gateway IP in the virtual machine and find that the ping is not in.
On the TAP device where the virtual machine is located, Tcpdump analyzes and finds ICMP request and reply.

But this is just an illusion, and then the grasp of the packet analysis:
The MAC address of the requested and reply was found to be inconsistent:

Figure 1:
The source Mac is the new MAC address when the virtual machine sends the request

Figure 2:
When replying, the purpose Mac is the old MAC address

As a result, the packet cannot enter the virtual machine and ping is not displayed inside the virtual machine.

As a result, the packet cannot enter the virtual machine and ping is not displayed inside the virtual machine.

Then check the network node and the ARP table of compute nodes, and find that everything is OK.

Locate the problem in the Qrouter namespace, view the ARP table for the namespace, and find out about 192.168.10.2, maintenance, or previous ARP tables.

# IP netns exec qrouter-9b4da896-6baf-4e56-b368-85b25591908a arp-a
? (192.168.1.254) at 78:2b:cb:6b:9c:9a [ether] on qg-7356347e-91
? (10.20.30.2) at fa:16:3e:bc:b1:3d [ether] on qr-760f5ff8-3a
? (10.20.30.28) at fa:16:3e:0e:88:49 [ether] on qr-760f5ff8-3a
? (192.168.10.2) at fa:16:3e:33:8e:7c [ether] on qr-b82a5c08-87
Execute the arp-d command in the namespace, after deleting this arp table, OK.

This is because the ARP table entries maintained in the Linux system and the ARP table inconsistencies in the qrouter command space result in 2 layers of impassability.

The reason is generally clear, L2 pop driver when updating the ARP table, only send RPC messages to the Linux bridge Agent,l3 namespace will not receive this message.

I've probably thought about 2 ways:
1. Adjust the IP neighbor kernel parameters base_reachable_time, modify ARP aging time, but in the/proc/sys/net/ipv4/neigh directory only see and QR corresponding tap equipment, this method basically cannot change.

2. When create port, send notification to L3. This is what DHCP does, but at this point, you can't get the router ID, how do you send a message?