Sorry, had this email half-written in my drafts, didn't realize I hadn't sent it yet.
dan Yeah, we've definitely had a thread of discussions on this. Here's my understanding of what happened so far: In October (https://bugs.launchpad.net/quantum/+bug/1066282) Alex Xu reported a bug that an IP outside the subnet was allowed, and garyk says its expected behavior. Then in November (https://bugs.launchpad.net/quantum/+bug/1078490), Ishii reported that the l3-agent had an error if the gateway IP was not in the subnet. The general discussion in the bug (ishii, danwent, garyk) suggested that we could either require the gateway IP to be in the subnet, or if we wanted to get fancy, we could enforce that it was either in the subnet, or reachable via a host_route associated with that subnet (this would map more closely to what the linux kernel enforces, which is just that any gateway IP is reachable via a different route). My personal take on this is that when dealing with logical constructs, its less likely that you're going to run into complex scenarios such as requiring the gateway IP to be in a different subnet (more often, such scenarios are the result of kludgy designs due to limitations of physical topologies). So from my end, I tend to think enforcing that makes sense. It does make me a bit queasy to be back-porting this to folsom, especially since a stable release should only change behavior if obviously fixes something that was previously broken. This is especially true since an initial indication on launchpad indicated that allowing a Gateway IP outside the subnet was expected behavior (I suspect the only way such a system could be working is if they were using something other than the quantum-l3-agent for L3, such as a physical router on a provider network, or a VM router, acting as the gateway). On Sat, Jan 5, 2013 at 9:11 AM, Gary Kotton <[email protected]> wrote: > Hi, > One issues that keeps on coming up is should the defined gateway be on the > subnet CIDR. Sadly I do not recall why we did not enforce this. Is this > something we should enforce? > The the default gateway is not on the same subnet but is on the same > physical network. This can be done in conjunction with a proxy ARP. > > I have added a patch:- > @@ -1014,6 +1015,10 @@ class QuantumDbPluginV2(quantum_**plugin_base_v2.** > QuantumPluginBaseV2): > s['gateway_ip'] and > s['gateway_ip'] != attributes.ATTR_NOT_SPECIFIED)**: > self._validate_ip_version(ip_**ver, s['gateway_ip'], > 'gateway_ip') > + if not QuantumDbPluginV2._check_**subnet_ip(s['cidr'], > + s['gateway_ip']): > + error_message = _("Gateway %s is not valid on subnet") % > s['gateway_ip'] > + raise q_exc.InvalidInput(error_**message=error_message) > > Prior to pushing this (need to update some tests) > > One option that has arisen is to have a flag indication that the gateway > can be on a different network. > > What is our stand on this? > Thanks > Gary > > > -- > Mailing list: > https://launchpad.net/~**quantum-core<https://launchpad.net/~quantum-core> > Post to : > [email protected].**net<[email protected]> > Unsubscribe : > https://launchpad.net/~**quantum-core<https://launchpad.net/~quantum-core> > More help : > https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
