[openstack-dev] [neutron] What semantics are expected when booting a VM on an external network?
Kevin Benton
blak111 at gmail.com
Tue Sep 22 08:48:14 UTC 2015
There is no guarantee that two separate external networks will have routing
connectivity to each other. It seems like your (b) statement implies that.
On Sep 19, 2015 3:12 PM, "Neil Jerram" <Neil.Jerram at metaswitch.com> wrote:
> On 17/09/15 19:38, Kevin Benton wrote:
> > router:external only affects the behavior of Neutron routers. It
> > allows them to attach to it with an external gateway interface which
> > implies NAT and floating IPs.
>
> I presume you're talking about the reference implementation here. OK,
> but my concern first is about what it _means_, in particular for
> instances attached to such a network. Which your next paragraph addresses:
>
> >
> > From an instance's perspective, an external network would be no
> > different than any other provider network scenario that uses a
> > non-Neutron router. Nothing different happens with the routing of
> > traffic.
>
> Right, thanks. It seems to me that you're saying the same thing here as
> my (b) below. In case not, please do say more precisely what isn't
> correct about my (b) statement.
>
> >
> > >Also I believe that (c) is already true for Neutron external networks
> > - i.e. it doesn't make sense to assign a floating IP to an instance
> > that is directly on an external network. Is that correct?
> >
> > Well not floating IPs from the same external network, but you could
> > conceivably have layers where one external network has an internal
> > Neutron router interface that leads to another external network via a
> > Neutron router.
>
> Agreed.
>
> Many thanks for your input in this thread!
>
> Regards,
> Neil
>
> >
> >
> > On Thu, Sep 17, 2015 at 10:17 AM, Neil Jerram
> > <Neil.Jerram at metaswitch.com <mailto:Neil.Jerram at metaswitch.com>> wrote:
> >
> > Thanks so much for your continuing answers; they are really
> > helping me.
> >
> > I see your points now about the special casing, and about the
> semantic
> > expectations and internal wiring of a Neutron network being just the
> > same for an external network as for non-external. Hence, the
> > model for
> > an L3-only external network should be the same as it would be for an
> > L3-only tenant network, except for the router:external flag (and
> might
> > be along the lines that you've suggested, of a subnet with a null
> > network).
> >
> > It still seems that 'router:external true' might be a good match for
> > some of the other 'routed' semantics in [1], though, so I'd like to
> > drill down more on exactly what 'router:external true' means.
> >
> > A summary of the semantics at [1] is:
> > (a) L3-only connectivity between instances attached to the network.
> > (b) Data can be routed between between this network and the
> > outside, and
> > between multiple networks of this type, without needing Neutron
> > routers
> > (c) Floating IPs are not supported for instances on this network.
> > Instead, wherever an instance needs to be routable from, attach it
> > to a
> > network with a subnet of IP addresses that are routable from that
> > place.
> >
> > [1] https://review.openstack.org/#/c/198439/
> > <https://review.openstack.org/#/c/198439/>
> >
> > According to [2], router:external "Indicates whether this network is
> > externally accessible." Which I think is an exact match for (b) -
> > would
> > you agree? (Note: it can't mean that every instance on that network
> > actually _is_ contactable from outside, because that depends on IP
> > addressing, and router:external is a network property, not
> > subnet. But
> > it can mean that every instance is _potentially_ contactable, without
> > the mediation of a Neutron router.)
> >
> > [2] http://developer.openstack.org/api-ref-networking-v2-ext.html
> >
> > Also I believe that (c) is already true for Neutron external
> > networks -
> > i.e. it doesn't make sense to assign a floating IP to an instance
> that
> > is directly on an external network. Is that correct?
> >
> > In summary, for the semantics that I'm wanting to model, it sounds
> > like
> > router:external true already gives me 2 of the 3 main pieces.
> There's
> > still serious work needed for (a), but that's really nice news, if
> I'm
> > seeing things correctly (since discovering that instances can be
> > attached to an external network).
> >
> > Regards,
> > Neil
> >
> >
> >
> >
> > On 17/09/15 17:29, Kevin Benton wrote:
> > >
> > > Yes, the L2 semantics apply to the external network as well (at
> > least
> > > with ML2).
> > >
> > > One example of the special casing is the external_network_bridge
> > > option in the L3 agent. That would cause the agent to plug directly
> > > into a bridge so none of the normal L2 agent wiring would occur.
> > With
> > > the L2 bridge_mappings option there is no reason for this to exist
> > > anymore because it ignoring network attributes makes debugging a
> > > nightmare.
> > >
> > > >Yes, that makes sense. Clearly the core semantic there is IP.
> > I can
> > > imagine reasonable variation on less core details, e.g. L2
> > broadcast vs.
> > > NBMA. Perhaps it would be acceptable, if use cases need it, for
> > such
> > > details to be described by flags on the external network object.
> > >
> > > An external network object is just a regular network object with a
> > > router:external flag set to true. Any changes to it would have
> > to make
> > > sense in the context of all networks. That's why I want to make
> sure
> > > that whatever we come up with makes sense in all contexts and isn't
> > > just a bolt on corner case.
> > >
> > > On Sep 17, 2015 8:21 AM, "Neil Jerram"
> > <Neil.Jerram at metaswitch.com <mailto:Neil.Jerram at metaswitch.com>
> > > <mailto:Neil.Jerram at metaswitch.com
> > <mailto:Neil.Jerram at metaswitch.com>>> wrote:
> > >
> > > Thanks, Kevin. Some further queries, then:
> > >
> > > On 17/09/15 15:49, Kevin Benton wrote:
> > > >
> > > > It's not true for all plugins, but an external network should
> > > provide
> > > > the same semantics of a normal network.
> > > >
> > > Yes, that makes sense. Clearly the core semantic there is
> > IP. I can
> > > imagine reasonable variation on less core details, e.g. L2
> > > broadcast vs.
> > > NBMA. Perhaps it would be acceptable, if use cases need it,
> > for such
> > > details to be described by flags on the external network
> object.
> > >
> > > I'm also wondering about what you wrote in the recent thread
> > with Carl
> > > about representing a network connected by routers. I think
> > you were
> > > arguing that a L3-only network should not be represented by
> > a kind of
> > > Neutron network object, because a Neutron network has so many
> L2
> > > properties/semantics that it just doesn't make sense, and
> better
> > > to have
> > > a different kind of object for L3-only. Do those L2
> > > properties/semantics apply to an external network too?
> > >
> > > > The only difference is that it allows router gateway
> > interfaces
> > > to be
> > > > attached to it.
> > > >
> > > Right. From a networking-calico perspective, I think that
> > means that
> > > the implementation should (eventually) support that, and
> > hence allow
> > > interconnection between the external network and private
> Neutron
> > > networks.
> > >
> > > > We want to get rid of as much special casing as possible
> > for the
> > > > external network.
> > > >
> > > I don't understand here. What 'special casing' do you mean?
> > >
> > > Regards,
> > > Neil
> > >
> > > > On Sep 17, 2015 7:02 AM, "Neil Jerram"
> > > <Neil.Jerram at metaswitch.com
> > <mailto:Neil.Jerram at metaswitch.com>
> > <mailto:Neil.Jerram at metaswitch.com
> > <mailto:Neil.Jerram at metaswitch.com>>
> > > > <mailto:Neil.Jerram at metaswitch.com
> > <mailto:Neil.Jerram at metaswitch.com>
> > > <mailto:Neil.Jerram at metaswitch.com
> > <mailto:Neil.Jerram at metaswitch.com>>>> wrote:
> > > >
> > > > Thanks to the interesting 'default network model'
> > thread, I
> > > now know
> > > > that Neutron allows booting a VM on an external network.
> > > :-) I didn't
> > > > realize that before!
> > > >
> > > > So, I'm now wondering what connectivity semantics are
> > > expected (or
> > > > even
> > > > specified!) for such VMs, and whether they're the same
> > as -
> > > or very
> > > > similar to - the 'routed' networking semantics I've
> > > described at [1].
> > > >
> > > > [1]
> > > >
> > >
> >
> https://review.openstack.org/#/c/198439/5/doc/source/devref/routed_networks.rst
> > > >
> > > > Specifically I wonder if VM's attached to an external
> > network
> > > > expect any
> > > > particular L2 characteristics, such as being able to L2
> > > broadcast to
> > > > each other?
> > > >
> > > > By way of context - i.e. why am I asking this?... The
> > > > networking-calico project [2] provides an
> > implementation of the
> > > > 'routed'
> > > > semantics at [1], but only if one suspends belief in
> > some of the
> > > > Neutron
> > > > semantics associated with non-external networks, such as
> > > needing a
> > > > virtual router to provide connectivity to the outside
> > > world. (Because
> > > > networking-calico provides that external connectivity
> > > without any
> > > > virtual router.) Therefore we believe that we need to
> > > propose some
> > > > enhancement of the Neutron API and data model, so that
> > > Neutron can
> > > > describe 'routed' semantics as well as all the
> traditional
> > > ones. But,
> > > > if what we are doing is semantically equivalent to
> > > 'attaching to an
> > > > external network', perhaps no such enhancement is
> > needed...
> > > >
> > > > [2]
> > > https://git.openstack.org/cgit/openstack/networking-calico
> > > <https://git.openstack.org/cgit/openstack/networking-calico>
> > > >
> > <https://git.openstack.org/cgit/openstack/networking-calico>
> > > >
> > > > Many thanks for any input!
> > > >
> > > > Neil
> > > >
> > > >
> > > >
> > >
> >
> __________________________________________________________________________
> > > > OpenStack Development Mailing List (not for usage
> > questions)
> > > > Unsubscribe:
> > > >
> > >
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > >
> > <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > > >
> > >
> > <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > >
> > <
> http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> > <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Kevin Benton
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150922/c0f0274d/attachment-0001.html>
More information about the OpenStack-dev
mailing list