openstack team mailing list archive

[Paul Voccio <paul.voccio@xxxxxxxxxxxxx>]

Patrick,

You're right.  I guess that¹s what I get for typing a response too fast.

Paul

On 2/3/11 10:03 PM, "Patrick Ancillotti"
<patrick.ancillotti@xxxxxxxxxxxxx> 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
>