Re: [openstack-dev] [neutron] Are routed TAP interfaces (and DHCP for them) in scope for Neutron?
Hi Carl, I think I already answered your questions in my previous email below - but possibly that just means that I am misunderstanding exactly what you are asking! More inline On 06/05/15 18:13, Carl Baldwin wrote: This brings up something I'd like to discuss. We have a config option called allow_overlapping_ips which actually defaults to False. It has been suggested [1] that this should be removed from Neutron and I've just started playing around with ripping it out [2] to see what the consequences are. A purely L3 routed network, like Calico, is a case where it is more complex to implement allowing overlapping ip addresses. Well, yes. At least it means needing per-address space namespaces on the compute host. Because there might be two VMs on the same host and with the same IP, in different private address spaces, and there couldn't possibly be a way of routing both of those correctly, without putting their TAP interfaces into different namespaces. Then there's still the question of how to route across the fabric to the destination compute host (or to a border gateway), and how to communicate, to that compute host, the address space that it should route it. To solve that, in Calico, we're thinking of using stateless 464XLAT. There's a fuller exposition of all this, if you'd like more detail, at http://docs.projectcalico.org/en/latest/overlap-ips.html. If we deprecate and eventually remove allow_overlapping_ips, will this be a problem for Calico? I don't think so, but I'm not sure I've fully grasped the implications. For people using Calico today, we'd simply document and advertise that overlapping IPs aren't supported yet, and that would be the same regardless of whether allow_overlapping_ips still exists. (More broadly, there are other things in the Neutron API that Calico has a different take on. For example floating IPs - where Calico's approach is that if you want a VM to be publically addressable, you just give it an IP from a public range. We currently try to cover those things via documentation, as here: http://docs.projectcalico.org/en/latest/calico-neutron-api.html. But a longer term view would be for us to suggest evolving some of the Neutron API's concepts such that they have interpretations that make sense for both traditional Neutron networks and for Calico-like routed networks. Hence the question that I asked when starting this thread: are routed TAP interfaces [or perhaps I should have said 'routed networking'] in scope for Neutron? If they are, that might eventually have consequences for how the Neutron API should be expressed.) Then, in the hopefully not-too-distant future, Calico _will_ support overlapping IPs, and then it certainly won't be a problem if allow_overlapping_ips no longer exists. Is the shared address space in Calico confined to a single flat network Yes. or do you already support tenant private networks with this technology? No, not yet. If I recall from previous discussions, I think that it only supports Neutron's flat network model in the current form, so I don't think it should be a problem. Am I correct? Please confirm. Correct. Many thanks for your interest and reply! Neil [1] http://lists.openstack.org/pipermail/openstack-dev/2014-May/036336.html [2] https://review.openstack.org/#/c/179953/ On Fri, May 1, 2015 at 8:22 AM, Neil Jerram neil.jer...@metaswitch.com wrote: Thanks for your reply, Kevin, and sorry for the delay in following up. On 21/04/15 09:40, Kevin Benton wrote: Is it compatible with overlapping IPs? i.e. Will it give two different VMs the same IP address if the reservations are setup that way? No, not as I've described it below, and as we've implemented Calico so far. Calico's first target is a shared address space without overlapping IPs, so that we can handle everything within the default namespace. But we do also anticipate a future Calico release to support private address spaces with overlapping IPs, while still routing all VM data rather than bridging. That will need the private address TAP interfaces to go into a separate namespace (per address space), and have their data routed there; and we'd run a Dnsmasq in that namespace to provide that space's IP addresses. Within each namespace - whether the default one or private ones - we'd still use the other changes I've described below for how the DHCP agent creates the ns-XXX interface and launches Dnsmasq. Does that make sense? Do you think that this kind of approach could be in scope under the Neutron umbrella, as an alternative to bridging the TAP interfaces? Thanks, Neil On 16/04/15 15:12, Neil Jerram wrote: I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq with options such that it works (= provides DHCP service) for TAP interfaces that are _not_ bridged to the DHCP interface (ns-XXX). For the sake of being concrete, this involves:
Re: [openstack-dev] [neutron] Are routed TAP interfaces (and DHCP for them) in scope for Neutron?
This brings up something I'd like to discuss. We have a config option called allow_overlapping_ips which actually defaults to False. It has been suggested [1] that this should be removed from Neutron and I've just started playing around with ripping it out [2] to see what the consequences are. A purely L3 routed network, like Calico, is a case where it is more complex to implement allowing overlapping ip addresses. If we deprecate and eventually remove allow_overlapping_ips, will this be a problem for Calico? Is the shared address space in Calico confined to a single flat network or do you already support tenant private networks with this technology? If I recall from previous discussions, I think that it only supports Neutron's flat network model in the current form, so I don't think it should be a problem. Am I correct? Please confirm. Carl [1] http://lists.openstack.org/pipermail/openstack-dev/2014-May/036336.html [2] https://review.openstack.org/#/c/179953/ On Fri, May 1, 2015 at 8:22 AM, Neil Jerram neil.jer...@metaswitch.com wrote: Thanks for your reply, Kevin, and sorry for the delay in following up. On 21/04/15 09:40, Kevin Benton wrote: Is it compatible with overlapping IPs? i.e. Will it give two different VMs the same IP address if the reservations are setup that way? No, not as I've described it below, and as we've implemented Calico so far. Calico's first target is a shared address space without overlapping IPs, so that we can handle everything within the default namespace. But we do also anticipate a future Calico release to support private address spaces with overlapping IPs, while still routing all VM data rather than bridging. That will need the private address TAP interfaces to go into a separate namespace (per address space), and have their data routed there; and we'd run a Dnsmasq in that namespace to provide that space's IP addresses. Within each namespace - whether the default one or private ones - we'd still use the other changes I've described below for how the DHCP agent creates the ns-XXX interface and launches Dnsmasq. Does that make sense? Do you think that this kind of approach could be in scope under the Neutron umbrella, as an alternative to bridging the TAP interfaces? Thanks, Neil On 16/04/15 15:12, Neil Jerram wrote: I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq with options such that it works (= provides DHCP service) for TAP interfaces that are _not_ bridged to the DHCP interface (ns-XXX). For the sake of being concrete, this involves: - creating the ns-XXX interface as a dummy, instead of as a veth pair - launching dnsmasq with --bind-dynamic --listen=ns-XXX --listen=tap* --bridge-interface=ns-XXX,tap* - not running in a separate namespace - running the DHCP agent on every compute host, instead of only on the network node - using the relevant subnet's gateway IP on the ns-XXX interface (on every host), instead of allocating a different IP for each ns-XXX interface. I proposed a spec for this in the Kilo cycle [1], but it didn't get enough traction, and I'm now wondering what to do with this work/function. Specifically, whether to look again at integrating it into Neutron during the Liberty cycle, or whether to maintain an independent DHCP agent for my project outside the upstream Neutron tree. I would very much appreciate any comments or advice on this. For answering that last question, I suspect the biggest factor is whether routed TAP interfaces - i.e. forms of networking implementation that rely on routing data between VMs instead of bridging it - is in scope for Neutron, at all. If it is, I understand that there could be a lot more detail to work on, such as how it meshes with other Neutron features such as DVR and the IPAM work, and that it might end up being quite different from the blueprint linked below. But it would be good to know whether this would ultimately be in scope and of interest for Neutron at all. Please do let me now what you think. Many thanks, Neil [1] https://blueprints.launchpad.net/neutron/+spec/dhcp-for-routed-ifs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Are routed TAP interfaces (and DHCP for them) in scope for Neutron?
Thanks for your reply, Kevin, and sorry for the delay in following up. On 21/04/15 09:40, Kevin Benton wrote: Is it compatible with overlapping IPs? i.e. Will it give two different VMs the same IP address if the reservations are setup that way? No, not as I've described it below, and as we've implemented Calico so far. Calico's first target is a shared address space without overlapping IPs, so that we can handle everything within the default namespace. But we do also anticipate a future Calico release to support private address spaces with overlapping IPs, while still routing all VM data rather than bridging. That will need the private address TAP interfaces to go into a separate namespace (per address space), and have their data routed there; and we'd run a Dnsmasq in that namespace to provide that space's IP addresses. Within each namespace - whether the default one or private ones - we'd still use the other changes I've described below for how the DHCP agent creates the ns-XXX interface and launches Dnsmasq. Does that make sense? Do you think that this kind of approach could be in scope under the Neutron umbrella, as an alternative to bridging the TAP interfaces? Thanks, Neil On 16/04/15 15:12, Neil Jerram wrote: I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq with options such that it works (= provides DHCP service) for TAP interfaces that are _not_ bridged to the DHCP interface (ns-XXX). For the sake of being concrete, this involves: - creating the ns-XXX interface as a dummy, instead of as a veth pair - launching dnsmasq with --bind-dynamic --listen=ns-XXX --listen=tap* --bridge-interface=ns-XXX,tap* - not running in a separate namespace - running the DHCP agent on every compute host, instead of only on the network node - using the relevant subnet's gateway IP on the ns-XXX interface (on every host), instead of allocating a different IP for each ns-XXX interface. I proposed a spec for this in the Kilo cycle [1], but it didn't get enough traction, and I'm now wondering what to do with this work/function. Specifically, whether to look again at integrating it into Neutron during the Liberty cycle, or whether to maintain an independent DHCP agent for my project outside the upstream Neutron tree. I would very much appreciate any comments or advice on this. For answering that last question, I suspect the biggest factor is whether routed TAP interfaces - i.e. forms of networking implementation that rely on routing data between VMs instead of bridging it - is in scope for Neutron, at all. If it is, I understand that there could be a lot more detail to work on, such as how it meshes with other Neutron features such as DVR and the IPAM work, and that it might end up being quite different from the blueprint linked below. But it would be good to know whether this would ultimately be in scope and of interest for Neutron at all. Please do let me now what you think. Many thanks, Neil [1] https://blueprints.launchpad.net/neutron/+spec/dhcp-for-routed-ifs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Are routed TAP interfaces (and DHCP for them) in scope for Neutron?
I haven't yet had any responses to this, so reflagging it in case it was just missed in the helter skelter of activity that is the openstack-dev mailing list... On the other hand, if I need to describe more clearly what I'm on about, please don't be afraid to say that! Any comments and steer would be appreciated, even if they're more of a high level gut feel, than an exhaustive treatment. Thanks, Neil On 16/04/15 15:12, Neil Jerram wrote: I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq with options such that it works (= provides DHCP service) for TAP interfaces that are _not_ bridged to the DHCP interface (ns-XXX). For the sake of being concrete, this involves: - creating the ns-XXX interface as a dummy, instead of as a veth pair - launching dnsmasq with --bind-dynamic --listen=ns-XXX --listen=tap* --bridge-interface=ns-XXX,tap* - not running in a separate namespace - running the DHCP agent on every compute host, instead of only on the network node - using the relevant subnet's gateway IP on the ns-XXX interface (on every host), instead of allocating a different IP for each ns-XXX interface. I proposed a spec for this in the Kilo cycle [1], but it didn't get enough traction, and I'm now wondering what to do with this work/function. Specifically, whether to look again at integrating it into Neutron during the Liberty cycle, or whether to maintain an independent DHCP agent for my project outside the upstream Neutron tree. I would very much appreciate any comments or advice on this. For answering that last question, I suspect the biggest factor is whether routed TAP interfaces - i.e. forms of networking implementation that rely on routing data between VMs instead of bridging it - is in scope for Neutron, at all. If it is, I understand that there could be a lot more detail to work on, such as how it meshes with other Neutron features such as DVR and the IPAM work, and that it might end up being quite different from the blueprint linked below. But it would be good to know whether this would ultimately be in scope and of interest for Neutron at all. Please do let me now what you think. Many thanks, Neil [1] https://blueprints.launchpad.net/neutron/+spec/dhcp-for-routed-ifs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Are routed TAP interfaces (and DHCP for them) in scope for Neutron?
Is it compatible with overlapping IPs? i.e. Will it give two different VMs the same IP address if the reservations are setup that way? If not, this approach won't work for many use cases so I think you will probably just have to write a new DHCP agent that operates in this distributed fashion. I haven't yet had any responses to this, so reflagging it in case it was just missed in the helter skelter of activity that is the openstack-dev mailing list... On the other hand, if I need to describe more clearly what I'm on about, please don't be afraid to say that! Any comments and steer would be appreciated, even if they're more of a high level gut feel, than an exhaustive treatment. Thanks, Neil On 16/04/15 15:12, Neil Jerram wrote: I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq with options such that it works (= provides DHCP service) for TAP interfaces that are _not_ bridged to the DHCP interface (ns-XXX). For the sake of being concrete, this involves: - creating the ns-XXX interface as a dummy, instead of as a veth pair - launching dnsmasq with --bind-dynamic --listen=ns-XXX --listen=tap* --bridge-interface=ns-XXX,tap* - not running in a separate namespace - running the DHCP agent on every compute host, instead of only on the network node - using the relevant subnet's gateway IP on the ns-XXX interface (on every host), instead of allocating a different IP for each ns-XXX interface. I proposed a spec for this in the Kilo cycle [1], but it didn't get enough traction, and I'm now wondering what to do with this work/function. Specifically, whether to look again at integrating it into Neutron during the Liberty cycle, or whether to maintain an independent DHCP agent for my project outside the upstream Neutron tree. I would very much appreciate any comments or advice on this. For answering that last question, I suspect the biggest factor is whether routed TAP interfaces - i.e. forms of networking implementation that rely on routing data between VMs instead of bridging it - is in scope for Neutron, at all. If it is, I understand that there could be a lot more detail to work on, such as how it meshes with other Neutron features such as DVR and the IPAM work, and that it might end up being quite different from the blueprint linked below. But it would be good to know whether this would ultimately be in scope and of interest for Neutron at all. Please do let me now what you think. Many thanks, Neil [1] https://blueprints.launchpad.net/neutron/+spec/dhcp-for-routed-ifs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Are routed TAP interfaces (and DHCP for them) in scope for Neutron?
I have a Neutron DHCP agent patch whose purpose is to launch dnsmasq with options such that it works (= provides DHCP service) for TAP interfaces that are _not_ bridged to the DHCP interface (ns-XXX). For the sake of being concrete, this involves: - creating the ns-XXX interface as a dummy, instead of as a veth pair - launching dnsmasq with --bind-dynamic --listen=ns-XXX --listen=tap* --bridge-interface=ns-XXX,tap* - not running in a separate namespace - running the DHCP agent on every compute host, instead of only on the network node - using the relevant subnet's gateway IP on the ns-XXX interface (on every host), instead of allocating a different IP for each ns-XXX interface. I proposed a spec for this in the Kilo cycle [1], but it didn't get enough traction, and I'm now wondering what to do with this work/function. Specifically, whether to look again at integrating it into Neutron during the Liberty cycle, or whether to maintain an independent DHCP agent for my project outside the upstream Neutron tree. I would very much appreciate any comments or advice on this. For answering that last question, I suspect the biggest factor is whether routed TAP interfaces - i.e. forms of networking implementation that rely on routing data between VMs instead of bridging it - is in scope for Neutron, at all. If it is, I understand that there could be a lot more detail to work on, such as how it meshes with other Neutron features such as DVR and the IPAM work, and that it might end up being quite different from the blueprint linked below. But it would be good to know whether this would ultimately be in scope and of interest for Neutron at all. Please do let me now what you think. Many thanks, Neil [1] https://blueprints.launchpad.net/neutron/+spec/dhcp-for-routed-ifs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
