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.jer...@metaswitch.com <mailto:neil.jer...@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.jer...@metaswitch.com <mailto:neil.jer...@metaswitch.com>
> > <mailto:neil.jer...@metaswitch.com
> <mailto:neil.jer...@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.jer...@metaswitch.com
> <mailto:neil.jer...@metaswitch.com>
> <mailto:neil.jer...@metaswitch.com
> <mailto:neil.jer...@metaswitch.com>>
> > > <mailto:neil.jer...@metaswitch.com
> <mailto:neil.jer...@metaswitch.com>
> > <mailto:neil.jer...@metaswitch.com
> <mailto:neil.jer...@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-requ...@lists.openstack.org?subject:unsubscribe
> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> >
> <http://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://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://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
