Not sure about the other vendors, but Cisco has the multicast part covered with the the multicast vlan feature included in 7.x code.
"... The WLC will make sure that all multicast streams from the clients on this VLAN pool will always go out on the multicast VLAN. This ensures that the upstream router has just one entry for all the VLANs of the VLAN pool. As a result, only one multicast stream will hit the VLAN pool even if the clients are on different VLANs. Therefore, the multicast packets also sent out on the air will be just one stream." http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bb4900.shtml -Luke =-=-=-=-=-=-=-=-=-=-=-= Luke Jenkins Network Engineer Weber State University On Aug 2, 2012, at 12:05 PM, "Hanset, Philippe C" <[email protected]> wrote: > Craig, > > That's a very good point to remind us. It's easy to forget that with VLAN > pooling each Access-Point does broadcast > to all members based on VLANs represented on that Access-Point. With the > scenario that you demonstrate (we have the same geographical behavior with > class changes), eventually the advantage of VLAN pooling tends to disappear, > especially in well travelled areas, the ones where we have so many people per > AP that we really don't want any BC or MC traffic! > > Here is what I would like to see in the future: > One large VLAN for the entire WLAN (yes, you read that well, just like the > good all days), with dynamic BC/MC filtering based on location. > So basically your controllers will be geographically aware of groups of > Access-Points that need to talk to each other but will not > let the BroadCast and MultiCast traffic go beyond those boundaries. And then > ARP proxy to limit the ARP traffic. > This would address Mobility within the WLAN, and could even address > "Bonjour", while cleaning the air from distant BC/MC that you don't > want to see. It might even provide a little more security since you have to > be in the region to mess with the device ;-) > > It is not uncommon to go back to initial conditions, but in the smarter way! > Fish>Tetrapod>Mammal>Aquatic Mammal ;-) > > Any vendor ready to implement this? > Drawbacks? > (Are there cases of people interested to remotely operate an AppleTV from one > end of campus to another end of campus?) > > Philippe > > Philippe Hanset > Univ. of TN, Knoxville > www.eduroamus.org > > > > On Aug 2, 2012, at 1:06 PM, Craig Simons wrote: > >> This is what we've been doing for years (except we're using /22s). The issue >> that we see now is that with near 100% wireless coverage on our main campus, >> there are no dead spots or bad roaming areas. Users authenticate in on area >> and move to the next area. Take the following scenario: >> >> 100 students attend a lecture in building "A". 25 of these students >> authenticated to wireless on the east side of campus on controller 1 (they >> received an IP in the range assigned that controller). Another 25 of those >> students authenticated on the north side of campus on controller 2, 25 more >> on the south side on controller 3, etc. Now, as they all walk to their >> lecture, their wireless session roams until they sit down in the theatre. At >> this point the APs in the lecture theare are servicing 4 separate networks >> (on the same SSID). To me, it's really a moot point to discuss the wasted >> airtime of management frames, broadcast, etc. Functionally speaking, all of >> the users are sharing the radio spectrum as if they were on the same IP >> subnet. Even though the students can only "see" the broadcast frames of >> their own network, they still have to wait for the air to be clear. >> >> This scenario is something we see all across the board in all areas of our >> campus. So, as we don't have any VLAN pooling features and have to balance >> our IPs manually so that none of the controllers "run out of IPs", my >> thinking is why not just make it easier on ourselves and move to /21s and >> save the hassle of balancing? >> >> Regards, >> Craig >> >> >> SFU SIMON FRASER UNIVERSITY >> Network Services >> Craig Simons >> Network and Systems Administrator >> >> Phone: 778-782-8036 >> Cell: 604-649-7977 >> Email: [email protected] >> Twitter: simonscraig >> >> From: "Kees Pronk" <[email protected]> >> To: [email protected] >> Sent: Wednesday, 1 August, 2012 23:05:49 >> Subject: [WIRELESS-LAN] Betr.: Re: [WIRELESS-LAN] Wireless Client Subnet >> sizing >> >> Aruba networks advises to keep the subnets /23 (for big campuses) because of >> wasted airtime due to increased management (beacons and mgt frames). >> >> I agree Cisco has excellent technical content, but imho for WLAN >> specifically, Aruba is better. >> >> http://www.arubanetworks.com/wp-content/uploads/DG_HighDensity_VRD.pdf >> >> Regards, Kees Pronk >> >> Netwerk admin & engineer >> >> Avans University of Applied Sciences >> Diensteenheid ICT en Facilitaire Dienst (DIF) - ICT-Beheer >> >> Bezoekadres: >> Hogeschoollaan 1, Kamer HG204 >> 4818 CR Breda, The Netherlands >> >> Postadres: >> Postbus 90116 >> 4800 RA Breda >> >> E: [email protected] >> T: @rovinguser >> >> >> >>> Tristan Rhodes <[email protected]> 8/1/2012 11:12 >>> >> Like it was mentioned by Anders, this excellent material is freely available >> after a registration. Funny though, it seems that you can access the file >> directly: >> >> Design and Deployment of Enterprise WLANs (BRKEWN-2010) >> http://d2zmdbbm9feqrf.cloudfront.net/2012/usa/pdf/BRKEWN-2010.pdf >> >> Cisco has the most technical content available, compared to any other >> network vendor that I am aware of. >> >> Cheers! >> >> Tristan >> >> -- >> Tristan Rhodes >> Network Engineer >> Weber State University >> (801) 626-8549 >> >> >> >>> On 7/31/2012 at 5:01 PM, in message >> >>> <CAP8VL9hbfk669TT=XGMu5WdMt25_eopDZ=xvcvceohabjrr...@mail.gmail.com>, >> >>> Mark Duling <[email protected]> wrote: >> >> Luke, it looks like that presentation isn't public. Can you say more about >> Cisco's recommendations on that? Or are they simply saying /21 is the >> maximum recommended size? I'd also be interested in anything they said about >> mcast as it relates to size. >> >> I've setup vlan select on a test WLAN with the intent of breaking up my /21 >> into smaller pieces for the fall, but I've had no problems with it (though >> mcast is off). But I thought I would use smaller subnets since our wireless >> use has gone up quite a bit in recent years and doing it is so simple to do >> now. I've heard conflicting info, and to my surprise one time a TAC engineer >> suggested they should be no larger than /24, which I think is erroneous. >> >> Mark >> >> >> On Tue, Jul 31, 2012 at 2:43 PM, Luke Jenkins <[email protected]> wrote: >> >> >> What type of gear are you using? >> >> Cisco is now recommending using /21s for their unified wireless gear (Sujit >> Ghosh, Cisco Live US 2012 BRKEWN-2010, Slide 75). >> >> >> -Luke >> >> =-=-=-=-=-=-=-=-=-=-=-= >> Luke Jenkins >> Network Engineer >> Weber State University >> >> >> On Jul 31, 2012, at 11:59 AM, Craig Simons <[email protected]> wrote: >> >> > All, >> > >> > We are looking at re-engineering our wireless networking IP space and I'm >> > wondering what type of boundaries other have pushed their networks to. We >> > are currently using /22 networks (14 of them) most of which during a busy >> > period of the day will run around 75-80% utilization (at least as far as >> > DHCP assignments go). When I look at most APs during the day, I see that >> > most APs have users belonging to several networks (roaming), and as we >> > have multicast disabled, it would seem that the advantages of segregating >> > wireless networks on the basis of limiting broadcast domain are moot. Is >> > anyone running /21 networks or larger? >> > >> > We've investigated NAT, but accurately logging internal-external IP >> > address assignments for our users has proven difficult. Our vendor also >> > doesn't currently support any type of "VLAN pooling" feature. >> > >> > Interested in your opinions, >> > Craig >> > >> > >> > >> > -------------------------------------- >> > Craig Simons >> > Network Operations >> > Simon Fraser University >> > Burnaby BC, Canada >> > em. [email protected] >> > ph. 778-782-8036 ( tel:778-782-8036 ) >> > ce. 604-649-7977 ( tel:604-649-7977 ) >> > tw. twitter.com/simonscraig >> > -------------------------------------- >> > ********** Participation and subscription information for this EDUCAUSE >> > Constituent Group discussion list can be found >> > athttp://www.educause.edu/groups/. >> >> ********** >> Participation and subscription information for this EDUCAUSE Constituent >> Group discussion list can be found at http://www.educause.edu/groups/. >> >> >> ********** Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> >> ********** >> Participation and subscription information for this EDUCAUSE Constituent >> Group discussion list can be found at http://www.educause.edu/groups/. >> >> >> --------------------------------------------------------------------------- >> Op deze e-mail zijn de volgende voorwaarden van toepassing: >> The following conditions apply to this e-mail: >> http://emaildisclaimer.avans.nl >> --------------------------------------------------------------------------- >> >> ********** >> Participation and subscription information for this EDUCAUSE Constituent >> Group discussion list can be found at http://www.educause.edu/groups/. >> >> ********** Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found >> athttp://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
