The external_network_bridge option in the L3 agent allows the L3 agent to plug directly into a bridge and skip all of the management by the L2 agent. This creates two ways to accomplish the same wiring, but it results in differences that cause confusion a issues for debugging.
When the external_network_bridge option is used, all of the provider properties (e.g. VLAN tags, VXLAN VNIs) of the external network are ignored. So we end up with scenarios where users will create an external network with a VLAN tag, attach a router to it, and then complain when it's not sending the correct tagged traffic. It also means that features added to the L2 agent will not apply to router ports (e.g. enhanced debugging, QoS, port mirroring, etc).
The appropriate way to do this is to define a physnet for the external network (e.g. 'external') and then create a bridge_mapping entry for it on the L2 agent that maps it to the external bridge (e.g. 'external:br-ex'). Then when the external Neutron network is created, it should be created with the 'flat' provider type and the 'external' provider physnet.
We should deprecate external_network_bridge in L and remove it in M to migrate people to the more consistent approach with bridge_mappings.
Fix proposed to branch: master
Review: https:/