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.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 -- Aimon Bustardo | Morph Labs | +1.310.625.0608 (mobile) | +1.310.437.4898 (office) | www.morphlabs.com | ai...@mor.ph _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
