Reviewed: https://review.openstack.org/438171 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=723169245978db29fdd42af18d5958e76c23a0fe Submitter: Jenkins Branch: master
commit 723169245978db29fdd42af18d5958e76c23a0fe Author: Harald Jensas <[email protected]> Date: Sat Feb 25 11:05:22 2017 +0100 Only add "on-link" routes for L2 adjacent subnets When multiple subnets exist on a single network, the DHCP agent adds on-link routes for all of them since they are in the same L2 network. If either subnet has a segment_id it can only be considered as on-link if they match, else we should not include a subnet route. These extra routes are optional anyways according to RFC 3442, but were added for the use case when all of the subnets are considered adjacent, which allows instances to bypass the router and communicate directly. Closes-Bug: #1668145 Change-Id: Iae889e9226a61059cd4f3d37fbe48d013b7a3482 Implements: blueprint tripleo-routed-networks-deployment ** Changed in: neutron Status: In Progress => Fix Released -- 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: [RFE] Allow operator control of "on-link" routes for subnets in the same Neutron network Status in neutron: Fix Released 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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
