yahoo-eng-team team mailing list archive

[Kevin Benton <1491668@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: neutron
     Importance: Undecided
     Assignee: Kevin Benton (kevinbenton)
         Status: In Progress

** Changed in: neutron
     Assignee: (unassigned) => Kevin Benton (kevinbenton)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1491668

Title:
  deprecate external_network_bridge option in L3 agent

Status in neutron:
  In Progress

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1491668/+subscriptions