[openstack-dev] [neutron] Re: [Blueprint vlan-aware-vms] VLAN aware VMs
beyounn at gmail.com
Thu Dec 19 05:58:53 UTC 2013
Could you unlock your doc at
It require a permission to read.
On 12/18/13, 4:20 AM, Ian Wells wrote:
> 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 . 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
> On 17 December 2013 06:17, Isaku Yamahata <isaku.yamahata at gmail.com
> <mailto: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: 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.
>  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.
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev