https://wiki.openstack.org/wiki/Neutron/DVR_L2_Agent

L2 Interaction with Plugin and L3 Agent

L2 OVS Agent initialization

During initialization the L2 OVS Agent needs to know its hosted unique dvr mac address, in order to key in the appropriate OVS rules into the tunnel and integration bridges. For this purpose, the L2 agent invokes RPC get_dvr_mac_address(host_id) served by ML2 plugin.

Distributed Router creation

A router can be created to explicitly as a distributed router. There is typically no action required on the agents due to creation of router (be in distributed mode or otherwise). Only when an interface is added to the router, there are actions taken in both the L2 and L3 agents. On the plugin side, as usual the created router information is stored in the DB which is shown in the figure below.

Interface addition to a distributed router

A router-interface-add command executed on a distributed router results in routers_updated() RPC to be invoked on the L3-Agent-on-CN. As part of servicing such a request, the L3-Agent-on-CN initially validates if the router affected is a distributed router. If so, it then gets the interface port corresponding to that newly added interface and attaches that port on the integration bridge. This part of operation is similar in nature to that of the L3 Agent except for the difference being that the L3-Agent-on-CN runs in the Compute Node and adds router ports only if such ports are destined on a distributed router.
Ports that are interfaces of a distributed router will have a special device_owner field value as network:router_interface_distributed.
After adding the router interface port on the br-int, the L3-Agent-on-CN requests information about the list of ports on the cloud available on this subnet interface. For this it invokes get_compute_ports_ by_subnet (subnet_id) towards the L3 Plugin. The L3 Plugin then contacts the ML2 Plugin to get all the ports available on the input subnet and returns the list of ports to the L3-Agent-on-CN. The L3-Agent-on-CN caches these ports and then uses the port information to create static ARP entries in the DVR router namespace. This completes the DVR-side handling of the router-interface.
The router interface port added by the L3-Agent-on-CN is detected by the L2 Agent. The L2 Agent identifies if this port is a distributed router interface. If not, it does normal processing. If yes, it does special processing wherein it invokes get_compute_ports_on_host_by_subnet(subnet_id) to get the list of local VMs available on this router interface. It then uses this list of ports and the router interface port information to create OVS rules in the tunnel and the integration bridges.

Interface removal from a distributed router

A router-interface-delete command executed on a distributed router results in routers_updated() RPC to be invoked on the L3-Agent-on-CN. As part of servicing such a request, the L3-Agent-on-CN initially validates if the router affected is a distributed router. If so, it then gets the interface port corresponding to that being deleted. It removes that router interface port on the integration bridge. This part of operation is similar in nature to that of the L3 Agent except for the difference being that the L3-Agent-on-CN runs in the Compute Node and deletes router ports only if such ports belong to a distributed router. After deleting the router interface port on the br-int, the L3-Agent-on-CN hits the port cache to ascertain the list of ports available on the deleted router interface. It then removes the static ARP entries from the router namespace for all the ports in that list. This completes the DVR-side handling of the router-interface deletion.

The router interface port deleted by the L3-Agent-on-CN is detected by the L2 Agent. The L2 Agent identifies if this port is a distributed router interface. If not, it does normal processing. If yes, it does special processing wherein it removes all the OVS rules from the integration and the tunnel bridges, matching the removed router interface port.

New VM added to a subnet interface of a distributed router

When a new tenant VM is added to a subnet interface managed by the distributed router, a CreatePort API invocation is done by Nova to host the new tenant VM. As part of createPort servicing by the ML2 Plugin, the ML2 plugin will inform the L3 Plugin about a new port being available. The L3 Plugin will check if this new port is in a DVR hosted subnet. If not it will not do any processing. If yes, the L3 Plugin will initiate an RPC call port_add() to the L3-Agent-on-CN. The L3-Agent-on-CN will service this RPC in which it will get this port information and add static ARP entry for that port in the corresponding router namespace. This completes the DVR-side handling of the new tenant VM port addition.
The new tenant VM port is detected by the L2 Agent. The L2 Agent identifies if this port is a member of subnet that is already distributed router interface. If not, it does normal processing. If yes, it does special processing wherein it adds this port (OFPORT) to existing OVS Rules in br-int and br-tun for the matching subnet gateway.

Existing VM is removed from a distributed router subnet interface

When a tenant VM is removed from a subnet interface managed by the distributed router, a DeletePort API invocation is done by Nova for the deleted tenant VM. As part of deletePort servicing by the ML2 Plugin, the ML2 plugin will inform the L3 Plugin about a port being deleted. The L3 Plugin will check if this deleted port is in a DVR hosted subnet. If not it will not do any processing. If yes, the L3 Plugin will initiate an RPC call port_delete() to the L3-Agent-on-CN. The L3-Agent-on-CN will service this RPC in which it will get this port information and remove matching static ARP entry for that port in the corresponding router namespace. This completes the DVR-side handling of the tenant VM port removal.
The removed port is detected by the L2 Agent. The L2 Agent identifies if this port is a member of subnet that is already distributed router interface. If not, it does normal processing. If yes, it does special processing wherein it modifies the existing OVS rules in br-int and br-tun so that the rule does not contain this port being deleted (OFPORT).