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.ancillo...@rackspace.com> 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.santama...@gmail.com> 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 | nubeb...@nubeblog.com | twitter.com/nubeblog >>> +34 649 94 43 29 >>> >>> >>> >>> >>> On Thu, Feb 3, 2011 at 2:37 AM, Monsyne Dragon <mdra...@rackspace.com> >>> 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 ab...@rackspace.com, and delete the original message. >>>> Your cooperation is appreciated. >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> 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 ab...@rackspace.com, and delete the original message. >> Your cooperation is appreciated. >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
