I've been thinking more about this q-in-q and how to make it
compatible with everyone. I think a simple modification to my existing
work would do the trick, some sort of configuration option in the form
of a list. Something like 'qinq-physdevs', and then I just do the same
thing but check against t
Here's my rough draft:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Q-in-Q+for+isolated+networks+functional+spec
On Sun, Oct 21, 2012 at 11:41 PM, Chiradeep Vittal
wrote:
> +1 on the FS.
>
> On 10/20/12 10:52 PM, "Marcus Sorensen" wrote:
>
>>The admin does have to create a new physical
+1 on the FS.
On 10/20/12 10:52 PM, "Marcus Sorensen" wrote:
>The admin does have to create a new physical network, the patch just
>allows you to use a tagged network as that physical network rather
>than a real eth device. It is true that cloudstack doesn't know about
>q-in-q per se, but it is
The admin does have to create a new physical network, the patch just
allows you to use a tagged network as that physical network rather
than a real eth device. It is true that cloudstack doesn't know about
q-in-q per se, but it is the one creating the q-in-q vlans. The admin
does have to create any
It looks like your patch does not require the admin to configure anything
wrt
physical networks. The admin knows the list of "outer" VLANs and
CloudStack is
blissfully unaware of the QinQ stuff.
This requires the hypervisors to be independently configured (out-of-band)
with the
outer VLAN bridges
Ah, well it's pretty simple, so I'll just paste it here. Again,
perhaps more should be implemented regarding the MTU (like
functionality to configure MTU on the virtual router), but if you know
what to do it can all work via switch configs.
diff --git
a/plugins/hypervisors/kvm/src/com/cloud/hyper
On Thu, Oct 18, 2012 at 12:42 AM, Marcus Sorensen wrote:
> Sorry, I've been up to my ears. I've attached the simple patch that
> makes this all happen, if anyone wants to take a look. This is the
> code that looks for physical devices. It's passed a bridge and then
> determines the parent of that
Sorry, I've been up to my ears. I've attached the simple patch that
makes this all happen, if anyone wants to take a look. This is the
code that looks for physical devices. It's passed a bridge and then
determines the parent of that bridge, then whether that parent is a
tagged device and goes one m
Ok, I'll pull out the changes and let people see them. Cloudstack
seems to let me put the same vlan ranges on multiple physicals, though
I haven't done much actual testing with large numbers of vlans. I
imagine there would be other bottlenecks if they all needed to be up
on the same host at once. L
On 10/15/12 8:35 AM, "Kelceydamage@bbits" 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
> wrote:
>
>> This sounds like it can be modeled as multiple physical network
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
wrote:
> This sounds like it can be modeled as multiple physical networks? That is,
> each "outer" vlan (400, 401, etc) is a separ
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
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
13 matches
Mail list logo
