commit c5fa966e8fe8e770ee9a367428df4be698e3edc0
Author: Kevin Benton <email address hidden>
Date: Thu Feb 9 00:27:20 2017 -0800
Stop making IP-specific provider rules in SG code
Setting up rules to allow DHCPv6, DHCP, and RAs from specific
IP addresses based on Neutron resources has a few issues:
1. It violates separation of concerns. We are implementing logic to
calculate where an IPv6 RA advertisement or DHCP advertisement
should be coming from in the security group code. This code should
not be trying to guess IPv6 LLAs, know about subnet modes, DHCP server implementations, or the type of L3 plugin being used. Currently all
of these assumptions are baked into code that should only be
filtering, which makes it very rigid and brittle when it comes to
other implementations for DHCP and/or RAs.
2. It has scaling issues on large networks. Every time one of these
provider rules is updated, it triggers every L2 agent to refresh
all of the security group rules for ports in that network, which puts
significant load on the server.
3. It's main purpose: preventing spoofing of RA[1,2] and DHCP packets,
has long been superceded by preventing VMs from acting as DHCP/RA servers[3][4].
This patch completely removes all of this logic and just returns
static provider rules to the agents that allow all DHCP server
and RA traffic ingress to the client. This addresses the issues
highlighted above since the code is significantly simplified and
the provider rules don't require refreshes on the agents.
Now that the provider rules never change, the RPC notification
listener on the agent-side for 'notify_provider_updated' is now
just a NOOP that doesn't trigger any refreshes. The notification
was left in place on the server side for older version agents
that have stale IP-specific provider rules. The entire notification
can be removed in the future.
The one open concern with this approach is that VMs will now be
able to receive DHCP offers from other DHCP servers on the same
network that aren't being filtered (e.g. a VM with port security
disabled or another device on a provider network). In order to
address this for DHCP, this patch adds two rules that only allow
DHCP offers targeted to either the broadcast or the correct client
IP. This prevents incorrect offers from ever reaching the client.
For RAs, this patch just allows all RAs so we may pick up
advertisements from other v6 routers attached to a network;
however, the instance won't actually be allowed to use bad addresses.
Reviewed: https:/ /review. openstack. org/456745 /git.openstack. org/cgit/ openstack/ neutron/ commit/ ?id=c5fa966e8fe 8e770ee9a367428 df4be698e3edc0
Committed: https:/
Submitter: Jenkins
Branch: stable/ocata
commit c5fa966e8fe8e77 0ee9a367428df4b e698e3edc0
Author: Kevin Benton <email address hidden>
Date: Thu Feb 9 00:27:20 2017 -0800
Stop making IP-specific provider rules in SG code
Setting up rules to allow DHCPv6, DHCP, and RAs from specific
IP addresses based on Neutron resources has a few issues:
1. It violates separation of concerns. We are implementing logic to
implementations , or the type of L3 plugin being used. Currently all
servers[ 3][4].
calculate where an IPv6 RA advertisement or DHCP advertisement
should be coming from in the security group code. This code should
not be trying to guess IPv6 LLAs, know about subnet modes, DHCP server
of these assumptions are baked into code that should only be
filtering, which makes it very rigid and brittle when it comes to
other implementations for DHCP and/or RAs.
2. It has scaling issues on large networks. Every time one of these
provider rules is updated, it triggers every L2 agent to refresh
all of the security group rules for ports in that network, which puts
significant load on the server.
3. It's main purpose: preventing spoofing of RA[1,2] and DHCP packets,
has long been superceded by preventing VMs from acting as DHCP/RA
This patch completely removes all of this logic and just returns
static provider rules to the agents that allow all DHCP server
and RA traffic ingress to the client. This addresses the issues
highlighted above since the code is significantly simplified and
the provider rules don't require refreshes on the agents.
Now that the provider rules never change, the RPC notification provider_ updated' is now
listener on the agent-side for 'notify_
just a NOOP that doesn't trigger any refreshes. The notification
was left in place on the server side for older version agents
that have stale IP-specific provider rules. The entire notification
can be removed in the future.
The one open concern with this approach is that VMs will now be
able to receive DHCP offers from other DHCP servers on the same
network that aren't being filtered (e.g. a VM with port security
disabled or another device on a provider network). In order to
address this for DHCP, this patch adds two rules that only allow
DHCP offers targeted to either the broadcast or the correct client
IP. This prevents incorrect offers from ever reaching the client.
For RAs, this patch just allows all RAs so we may pick up
advertisements from other v6 routers attached to a network;
however, the instance won't actually be allowed to use bad addresses.
1. https:/ /bugs.launchpad .net/neutron/ +bug/1262759 57204eb746c0faa b2c70409a94 a28806c5053e38e f86f43b7771 /git.openstack. org/cgit/ openstack/ neutron/ tree/
neutron/ agent/linux/ iptables_ firewall. py
?h=521b1074f175 74a5234843bce68 f3810995e0e1d# n475 396f74db9d98299 3f994082731 3dd6a1a0a85c09b 8e65422a13)
2. I1d5c7aaa8e4cf0
3. Ice1c9dd349864d
4. https:/
Closes-Bug: #1653830
Closes-Bug: #1663077
Change-Id: Ibfbf011284cbde
(cherry picked from commit ae9d1160bdaedc2