On 10/15/12 8:35 AM, "Kelceydamage@bbits" <kel...@bbits.ca> wrote:
>That's a far more elegant way then I tried, which was creating tagged >interfaces within guests. > >Sent from my iPhone > >On Oct 15, 2012, at 12:54 AM, Chiradeep Vittal ><chiradeep.vit...@citrix.com> wrote: > >> This sounds like it can be modeled as multiple physical networks? That >>is, >> each "outer" vlan (400, 401, etc) is a separate physical network in the >> same zone. That could work, although it is probable that the zone >> configuration API bits prevent more than 4k VLANs per zone (that can be >> changed to per physical network). >> >> As long as communication between guests on different physical networks >> happens via the public network, it should be Ok. >> I'd like to see the patch. >> >> Thanks >> >> On 10/12/12 1:09 AM, "Marcus Sorensen" <shadow...@gmail.com> wrote: >> >>> Guys, in looking for a free and scalable way to provide private >>>networks >>> for customers I've been running a QinQ setup that has been working >>>quite >>> well. I've sort of laid the groundwork for it already in changing the >>> bridge naming conventions about a month ago for KVM(to names that won't >>> collide if the same vlans is used twice on different phys). >>> >>> Basically the way it works is like this. Linux has two ways of creating >>> tagged networks, the eth#.# and the less used vlan# network devices. I >>> have >>> a tiny patch that causes cloudstack to treat vlan# devs as though they >>> were >>> physical NICs. In this way, you can do something like physical devices >>> eth0,eth1,and vlan400. management traffic on eth0's bridge, storage on >>> eth1.102's bridge, maybe eth1.103 for public/guest, then create say a >>> vlan400 that is tag 400 on eth1. You add a traffic type of guest to it >>>and >>> give it a vlan range, say 10-4000. Then you end up with cloudstack >>>handing >>> out vlan400.10, vlan400.11, etc for guest networks. Works great for >>> network >>> isolation without burning through a bunch of your "real" vlans. In the >>> unlikely event that you run out, you just create a physical vlan401 and >>> start over with the vlan numbers. >>> >>> In theory all-you-can-eat isolated networks without having to configure >>> hundreds of vlans on your networking equipment. This may require >>> additional >>> config on any upstream switches to pass the double tags around, but in >>> general from what I've seen the inner tags just pass through on >>>anything >>> layer 2, it should only get tricky if you try to tunnel, route or strip >>> tags. >>> >>> This is especially nice with system VM routers and VPC (cloudstack >>>takes >>> care of everything), but admittedly external routers probably will have >>> spotty support for being able to route double tagged stuff. I'm also a >>>bit >>> afraid that if I were to get it merged in that it would just become >>>this >>> undocumented hack thing that few know about and nobody uses. So I'm >>> looking >>> for feedback on whether this sounds useful enough to commit, how it >>>should >>> be documented, and whether it makes sense to hint at this in the GUI >>> somehow. >> > +1 This actually sounds amazing Marcus. I'd love to see and use this implementation. -- Æ
