Open Stack

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.

>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.

>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.


On Thu, Sep 17, 2015 at 10:17 AM, Neil Jerram <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/
>
> 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>> 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>>> 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://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
> >
>
>
> __________________________________________________________________________
> 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
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150917/a57674be/attachment-0001.html>