openstack team mailing list archive

[Aimon Bustardo <abustardo@xxxxxxxx>]

Hi Patrick, by using 802.1QiQ aren't we increasing the total VLAN count
to 4096*4096 (16277216) possible VLANS, each with the possibility of
using the same /8 network? In which case he in table storage of MACs is
the limiting factor.


Aimon

On 2/3/11 8:03 PM, Patrick Ancillotti wrote:
> Hey Guys, 
>
> I think Paul may have gotten a bit mixed up between VLAN and CAM tables on switches. The VLAN part of an ethernet frame is 12 bits (0 - 4095) which limits it accordingly. CAM tables however are a limit within switching gear that lists the MAC addresses and their respective source and destination ports. The lower end Cisco switches like the 2960 class switches have a limit of around 8000 MAC addresses, whereas others higher in the stack such as the 4948E class have limits upwards of 55000 MAC addresses, although some vendors have CAM tables in the hundreds of thousands for even their mid range switches. 
>
> That said, VLAN's are extremely limited, even with QinQ (VLANs within VLANs) when you're talking about 50 000 customers, or even 500 000 customers in the same layer 2 domain, and in many cases using smaller layer 2 domains creates unfortunately small service areas for capacity.
>
> For more info: 
> http://en.wikipedia.org/wiki/Virtual_LAN
> http://en.wikipedia.org/wiki/CAM_Table
>
> Thanks,
> Patrick
>
> On 3 Feb 2011, at 07:47, Paul Voccio wrote:
>
>> Diego,
>>
>> Due to our networking topology, having a vlan per customer isn't really
>> feasible. Most switches are limited at 4k or 8k or even 32k. With more
>> customers than these switches can reasonably accommodate, having a single
>> vlan per customer either limits the portability within a cloud or limits
>> the scale at which you can build your cloud. Open vSwitch will alleviate
>> some of this pain, but until we get it in XenServer, we're somewhat stuck
>> on flat networking.
>>
>> Paul
>>
>> On 2/3/11 4:20 AM, "Diego Parrilla Santamaría"
>> <diego.parrilla.santamaria@xxxxxxxxx> wrote:
>>
>>> Hi Monsyne,
>>>
>>> it's a very interesting topic and I'm curious about the reason why you
>>> are using the Flat Networking set up. From the conversations in other
>>> threads it seems the Service Providers prefer different networking
>>> approaches: VLAN oriented basically.
>>>
>>> Regards
>>> Diego
>>>
>>> -
>>> Diego Parrilla
>>> nubeblog.com | nubeblog@xxxxxxxxxxxx | twitter.com/nubeblog
>>> +34 649 94 43 29
>>>
>>>
>>>
>>>
>>> On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon <mdragon@xxxxxxxxxxxxx>
>>> wrote:
>>>> I am sorting out some possible implementations for the
>>>> multi-tenant-accounting blueprint, and the related system-usage-records
>>>> bp,
>>>> and I just wanted to run this by anyone interested in such matters.
>>>>
>>>> Basically, for multitenant purposes we need to introduce the concept of
>>>> an
>>>> 'account' in nova, representing a customer,  that basically acts as a
>>>> label
>>>> for a group of resources (instances, etc), and for access control (i.e
>>>> customer a cannot mess w/ customer b's stuff)
>>>>
>>>> There was some confusion on how best to implement this, in relation to
>>>> nova's project concept.  Projects are kind of like what we want an
>>>> account
>>>> to be, but there are some associations (like one project per network)
>>>> which
>>>> are not valid for our flat networking setup.  I am kind of
>>>> straw-polling on
>>>> which is better here:
>>>>
>>>> The options are:
>>>> 1) Create a new 'account' concept in nova,  with an account basically
>>>> being
>>>> a subgroup of a project (providers would use a single, default project,
>>>> with
>>>> additional projects added if needed for separate brands, or resellers,
>>>> etc),
>>>> add in access control per account as well as project, and make sure
>>>> apis/auth specify account appropriately,  have some way for a default
>>>> account to used (per project) so account doesn't get in the way for
>>>> non-multitenant users.
>>>>
>>>> 2) having account == nova's "project", and changing the network
>>>> associations, etc so projects can support our model (as well as current
>>>> models).  Support for associating accounts (projects) together for
>>>> resellers, etc would either be delegated outside of nova or added later
>>>> (it's not a current requirement).
>>>>
>>>> In either case, accounts would be identified by name, which would  be an
>>>> opaque string an outside system/person would assign, and could
>>>> structure to
>>>> their needs (ie. for associating accounts with common prefixes, etc)
>>>>
>>>> --
>>>>
>>>> --
>>>>   -Monsyne Dragon
>>>>   work:         210-312-4190
>>>>   mobile        210-441-0965
>>>>   google voice: 210-338-0336
>>>>
>>>>
>>>>
>>>> Confidentiality Notice: This e-mail message (including any attached or
>>>> embedded documents) is intended for the exclusive and confidential use
>>>> of
>>>> the
>>>> individual or entity to which this message is addressed, and unless
>>>> otherwise
>>>> expressly indicated, is confidential and privileged information of
>>>> Rackspace.
>>>> Any dissemination, distribution or copying of the enclosed material is
>>>> prohibited.
>>>> If you receive this transmission in error, please notify us immediately
>>>> by
>>>> e-mail
>>>> at abuse@xxxxxxxxxxxxx, and delete the original message.
>>>> Your cooperation is appreciated.
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> Confidentiality Notice: This e-mail message (including any attached or
>> embedded documents) is intended for the exclusive and confidential use of the
>> individual or entity to which this message is addressed, and unless otherwise
>> expressly indicated, is confidential and privileged information of Rackspace. 
>> Any dissemination, distribution or copying of the enclosed material is prohibited.
>> If you receive this transmission in error, please notify us immediately by e-mail
>> at abuse@xxxxxxxxxxxxx, and delete the original message. 
>> Your cooperation is appreciated.
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

-- 
Aimon Bustardo | Morph Labs | +1.310.625.0608 (mobile) | +1.310.437.4898 (office) | www.morphlabs.com | aimon@xxxxxx