yahoo-eng-team team mailing list archive

[Harald Jensås <harald.jensas@xxxxxxxxx>]

Public bug reported:

When adding multiple subnets on a single network the dhcp agent will set
dhcp-options to advertise "on-link"/"same-segment" classless static
routes to all the subnets.

A couple of use cases where these on-link/link-local routes are
undesirable:

a) When using Ironic for baremetal provisioning the baremetal nodes
might be on a different L2 broadcast segment with a DHCP-relay.

b) In a Spine-Leaf deployed Openstack, a pattern is to use identical
VLAN id's for provider networks in each leaf. Same VLAN id, but
different L2 domain and different IP subnets.


IMO, creating these routes are a bit opinionated. If we don't create them by default, the operator/end-user is fully able to create them if they are desired on a per-subnet basis. But since we decided these "should" be there, the operator loose the ability to control this.

** Affects: neutron
     Importance: Undecided
     Assignee: Harald Jensås (harald-jensas)
         Status: In Progress

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

Title:
  Allow the end user control of "on-link" routes for subnets in the same
  Neutron network

Status in neutron:
  In Progress

Bug description:
  When adding multiple subnets on a single network the dhcp agent will
  set dhcp-options to advertise "on-link"/"same-segment" classless
  static routes to all the subnets.

  A couple of use cases where these on-link/link-local routes are
  undesirable:

  a) When using Ironic for baremetal provisioning the baremetal nodes
  might be on a different L2 broadcast segment with a DHCP-relay.

  b) In a Spine-Leaf deployed Openstack, a pattern is to use identical
  VLAN id's for provider networks in each leaf. Same VLAN id, but
  different L2 domain and different IP subnets.

  
  IMO, creating these routes are a bit opinionated. If we don't create them by default, the operator/end-user is fully able to create them if they are desired on a per-subnet basis. But since we decided these "should" be there, the operator loose the ability to control this.

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