[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