[openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs

Ian Wells ijw.ubuntu at cack.org.uk
Wed Dec 18 12:20:50 UTC 2013


A Neutron network is analagous to a wire between ports.  We can do almost
everything with this wire - we can pass  both IP and non-IP traffic, I can
even pass MPLS traffic over it (yes, I tried).  For no rational reason, at
least if you live north of the API, I sometimes can't pass VLAN traffic
over it.  You would think this would be in the specification for what a
network is, but as it happens I don't think we have a specification for
what a network is in those terms.

I have a counterproposal that I wrote up yesterday [1].  This is the
absurdly simple approach, taking the position that implementing trunks
*should* be easy.  That's actually not such a bad position to take, because
the problem lies with certain plugins (OVS-based setups, basically) - it's
not a problem with Neutron.

It's very uncompromising, though - it just allows you to request a
VLAN-clean network.  It would work with OVS code because it allows plugins
to decline a request, but it doesn't solve the VLAN problem for you, it
just ensures that you don't run somewhere where your application doesn't
work, and gives plugins with problems an opportunity for special case
code.  You could expand it so that you're requesting either a VLAN-safe
network or a network that passes *specified* VLANs - which is the starting
position of Eric's document, a plugin-specific solution to a
plugin-specific problem.

I accept that, for as long as we use VLAN based infrastructure, we have to
accommodate the fact that VLANs are a special case, but this is very much
an artifact of the plugin implementation - Linux bridge based network
infrastructure simply doesn't have this problem, for instance.

On 17 December 2013 06:17, Isaku Yamahata <isaku.yamahata at gmail.com> wrote:

> - 2 Modeling proposal
>   What's the purpose of trunk network?
>   Can you please add a use case that trunk network can't be optimized away?
>

Even before I read the document I could list three use cases.  Eric's
covered some of them himself.

The reasons you might want to have a trunked network passing VLAN traffic:
1: You're replicating a physical design for simulation purposes [2]

2: There are any number of reasons to use VLANs in a physical design, but
generally it's a port reduction thing.  In Openstack, clearly I can do this
a different way - instead of using 30 VLANs over one network with two
ports, I can use 30 networks with two ports each.  Ports are cheaper when
you're virtual, but they're not free - KVM has a limitation of, from
memory, 254 ports per VM.  So I might well still want to use VLANs.  I
could arbitrarily switch to another encap technology, but this is the tail
wagging the dog - I have to change my design because Neutron's contract is
inconsistent.

3: I want to condense many tenant networks into a single VM or physical box
because I'm using a single VM to offer logically separated services to
multiple tenants.  This has all the points of (2) basically, that VLANs are
not the only encap I could use, but they're the conventional one and widely
supported.  Provider networks do actually offer the functionality you need
for this already - if you're talking physical - but they would, I think, be
awkward to use in practice, and they would eat NIC ports on your hosts.

-- 
Ian.

[1]
https://docs.google.com/document/d/16DDJLYHxMmbCPO5LxW_kp610oj4goiic_oTakJiXjTs
[2] http://blogs.cisco.com/wp-content/uploads/network1-550x334.png - a
network simulator (search for 'Cisco VIRL'). Shameless plug, sorry, but
it's an Openstack based application and I'm rather proud of it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/bb1feeea/attachment.html>


More information about the OpenStack-dev mailing list