Main Nav

Message from craigsimons@sfu.ca

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. craigsimons@sfu.ca
ph. 778-782-8036
ce. 604-649-7977
tw. twitter.com/simonscraig
--------------------------------------
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Comments

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
Message from craigsimons@sfu.ca

Good to know. We use Enterasys HiPath. But with the realities of wireless networking (APs being more hub than switch) and the replies I've received off list, it certainly seems like /21s is by no means out of the ordinary. Perhaps I'm still jaded from the good ol' days of bridged wired segments that would cause all sorts of spanning tree fun - stuff that doesn't really apply here.

Regards, 
Craig



SFU SIMON FRASER UNIVERSITY
Network Services

Craig Simons
Network and Systems Administrator

Phone: 778-782-8036
Cell: 604-649-7977
Email: craigsimons@sfu.ca
Twitter: simonscraig


From: "Luke Jenkins" <ljenkins@weber.edu>
To: "Craig Simons" <craigsimons@sfu.ca>
Cc: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Sent: Tuesday, 31 July, 2012 14:43:06
Subject: Re: [WIRELESS-LAN] Wireless Client Subnet sizing

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


Message from mark.duling@biola.edu

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


Mark, yes it’s not public but access is free after registration.

Just register at www.ciscolive365.com to access all presentation material for free which I strongly recommend if you’re using Cisco equipment.

Another forum if you not prefer our “expertise” is Cisco forum at https://supportforums.cisco.com/index.jspa where the story is the same (free access but register if you wish to do you a entry of your own).

I would prefer the answers from support forum rather than the TAC especially if you encounters their infamous 3rd line support which is populated by low cost non Cisco personnel. Trust me I’ve been there. ;)

In order to get a proper answer from the TAC you need to make sure that your TAC case has been escalated to the real Cisco TAC people. There are some very good people there but you won’t reach them right away.

 

Cheers

Anders

 

Från: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] För Mark Duling
Skickat: den 1 augusti 2012 01:01
Till: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Ämne: Re: [WIRELESS-LAN] Wireless Client Subnet sizing

 

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

 

Although we are a Cisco shop, I am not familiar with Cisco's current wireless offerings. We use Aruba wireless and , for our larger segments, we can group several vlans into a pool that is either assigned based off a mac address hash, or load is balanced across subnets. We use /23 subnets in these pools. For users where we cannot use pools, we are currently using /21. Using smaller subnets where possible reduces the broadcasts in the limited RF bandwidth available. When we last adjusted our design, Aruba recommended /24 for the subnets in a vlan pool. We use /23 to reduce the number of vlans in a pool. Bruce Osborne Network Engineer IT Network Services   (434) 592-4229   LIBERTY UNIVERSITY Training Champions for Christ since 1971 -----Original Message----- From: Luke Jenkins [mailto:ljenkins@WEBER.EDU] Sent: Tuesday, July 31, 2012 5:43 PM Subject: Re: Wireless Client Subnet sizing 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
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)
 
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_3g@mail.gmail.com>, Mark Duling <mark.duling@BIOLA.EDU> 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


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: cl.pronk@avans.nl T: @rovinguser >>> Tristan Rhodes 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 , Mark Duling 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

FYI, Aruba Networks has their knowledgebases and documentation freely available too. No registration required.`

Documentation: http://support.arubanetworks.com/DOCUMENTATION/tabid/77/Default.aspx

Tools & Resources: http://support.arubanetworks.com/TOOLSRESOURCES/tabid/76/Default.aspx

ArubaOS KB: http://support.arubanetworks.com/ArubaOSKB/tabid/111/Default.aspx

AirWave KB: http://support.arubanetworks.com/AirWaveKB/tabid/115/Default.aspx

Amigopod KB: http://support.arubanetworks.com/AmigopodKB/tabid/128/Default.aspx

ClearPass KB: http://support.arubanetworks.com/ClearPassKB/tabid/127/Default.aspx

 

Bruce Osborne

Network Engineer

IT Network Services

 

(434) 592-4229

 

LIBERTY UNIVERSITY

Training Champions for Christ since 1971

 

From: Tristan Rhodes [mailto:TristanRhodes@WEBER.EDU]
Sent: Wednesday, August 01, 2012 5:13 PM
Subject: Re: Wireless Client Subnet sizing

 

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)

 

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_3g@mail.gmail.com>, Mark Duling <mark.duling@BIOLA.EDU> 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

 

Message from ceyre@mtroyal.ca

We use vlan pooling with 16 /24's on our network but we tuned down the dhcp lease times to 1 hour as we found that many users don't need their ip for very long. They just connect, check some mail and maybe some "class" stuff and then disconnect. Next time they connect (within your dhcp lease time scope) or lose connectivity due to poor roaming they might (likely) connect on another vlan and then chew up another ip address. We initially had 7 hour leases (and poor roaming) and found that our ip's were getting eaten up pretty quick. After we changed it to an hour, it seems to be pretty good. The /24's work good for us and I've read every Cisco wireless design doc and everyone mentions a different size for scopes. A couple years back it was "try and make them as small as possible to keep the broadcast domain small", now it seems to be creeping back up to /21's. I hope this helps a bit. Craig Eyre Network Analyst IT Services Department Mount Royal University 4825 Mount Royal Gate SW Calgary AB T2P 3T5 P. 403.440.5199 E. ceyre@mtroyal.ca "The difference between a successful person and others is not a lack of strength, not a lack of knowledge, but rather in a lack of will." Vincent T. Lombardi From: "Osborne, Bruce W" To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU, Date: 08/02/2012 05:51 AM Subject: Re: [WIRELESS-LAN] Wireless Client Subnet sizing Sent by: The EDUCAUSE Wireless Issues Constituent Group Listserv FYI, Aruba Networks has their knowledgebases and documentation freely available too. No registration required.` Documentation: http://support.arubanetworks.com/DOCUMENTATION/tabid/77/Default.aspx Tools & Resources: http://support.arubanetworks.com/TOOLSRESOURCES/tabid/76/Default.aspx ArubaOS KB: http://support.arubanetworks.com/ArubaOSKB/tabid/111/Default.aspx AirWave KB: http://support.arubanetworks.com/AirWaveKB/tabid/115/Default.aspx Amigopod KB: http://support.arubanetworks.com/AmigopodKB/tabid/128/Default.aspx ClearPass KB: http://support.arubanetworks.com/ClearPassKB/tabid/127/Default.aspx Bruce Osborne Network Engineer IT Network Services (434) 592-4229 LIBERTY UNIVERSITY Training Champions for Christ since 1971 From: Tristan Rhodes [mailto:TristanRhodes@WEBER.EDU] Sent: Wednesday, August 01, 2012 5:13 PM Subject: Re: Wireless Client Subnet sizing 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_3g@mail.gmail.com>, Mark Duling 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
Message from craigsimons@sfu.ca

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: craigsimons@sfu.ca
Twitter: simonscraig


From: "Kees Pronk" <cl.pronk@AVANS.NL>
To: WIRELESS-LAN@listserv.educause.edu
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: cl.pronk@avans.nl
T: @rovinguser


>>> Tristan Rhodes <TristanRhodes@WEBER.EDU> 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_3g@mail.gmail.com>, Mark Duling <mark.duling@BIOLA.EDU> 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


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



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: craigsimons@sfu.ca
Twitter: simonscraig

From: "Kees Pronk" <cl.pronk@AVANS.NL>
To: WIRELESS-LAN@listserv.educause.edu
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: cl.pronk@avans.nl
T: @rovinguser


>>> Tristan Rhodes <TristanRhodes@WEBER.EDU> 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_3g@mail.gmail.com>, Mark Duling <mark.duling@BIOLA.EDU> 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


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_note09186a0080... -Luke =-=-=-=-=-=-=-=-=-=-=-= Luke Jenkins Network Engineer Weber State University On Aug 2, 2012, at 12:05 PM, "Hanset, Philippe C" 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: craigsimons@sfu.ca >> Twitter: simonscraig >> >> From: "Kees Pronk" >> To: WIRELESS-LAN@listserv.educause.edu >> 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: cl.pronk@avans.nl >> T: @rovinguser >> >> >> >>> Tristan Rhodes 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 , Mark Duling 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 >> >> >>
Message from marcelo.lew@du.edu

Aruba is doing BC/MC location based with a feature they call AirGroup, but it requires another appliance (ClearPass) in conjunction with the controllers. Marcelo Lew Wireless Enterprise Administrator University Technology Services University of Denver Desk: (303) 871-6523 Cell: (303) 669-4217 Fax:  (303) 871-5900 Email: mlew@du.edu -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Luke Jenkins Sent: Thursday, August 02, 2012 2:23 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Betr.: Re: [WIRELESS-LAN] Wireless Client Subnet sizing 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_note09186a0080... -Luke =-=-=-=-=-=-=-=-=-=-=-= Luke Jenkins Network Engineer Weber State University On Aug 2, 2012, at 12:05 PM, "Hanset, Philippe C" 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: craigsimons@sfu.ca >> Twitter: simonscraig >> >> From: "Kees Pronk" >> To: WIRELESS-LAN@listserv.educause.edu >> 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.pd >> f >> >> 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: cl.pronk@avans.nl >> T: @rovinguser >> >> >> >>> Tristan Rhodes 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 , Mark Duling 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 >> >> >>

ClearPass will only be required for residence hall/guest environments. Static device setup will be available in the base controller code. So if you wanted to make available a classroom AppleTV or printer, you could do that right in the controller. ClearPass adds user awareness and creates a “personal” network for all the user’s devices.

 

 

Tim Cappalli, ACMP CCNA | (802) 626-6456

Office of Information Technology (OIT) | Lyndon

» cappalli@lyndonstate.edu | oit.lyndonstate.edu

 

 

PRIVACY & CONFIDENTIALITY NOTICE
This message is for the designated recipient only and may

contain privileged, confidential, or otherwise private
information. If you have received it in error, please notify
the sender immediately and delete the original. Any other
use of an email received in error is prohibited.

 

-----Original Message-----
From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Marcelo Lew
Sent: Thursday, August 02, 2012 4:58 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Betr.: Re: [WIRELESS-LAN] Wireless Client Subnet sizing

 

Aruba is doing BC/MC location based with a feature they call AirGroup, but it requires another appliance (ClearPass) in conjunction with the controllers.

 

Marcelo Lew

Wireless Enterprise Administrator

University Technology Services

University of Denver

Desk: (303) 871-6523

Cell: (303) 669-4217

Fax:  (303) 871-5900

Email: mlew@du.edu

 

 

 

-----Original Message-----

From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Luke Jenkins

Sent: Thursday, August 02, 2012 2:23 PM

To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU

Subject: Re: [WIRELESS-LAN] Betr.: Re: [WIRELESS-LAN] Wireless Client Subnet sizing

 

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" <phanset@UTK.EDU> 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: craigsimons@sfu.ca

>> Twitter: simonscraig

>>

>> From: "Kees Pronk" <cl.pronk@AVANS.NL>

>> To: WIRELESS-LAN@listserv.educause.edu

>> 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.pd

>> f

>>

>> 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: cl.pronk@avans.nl

>> T: @rovinguser

>>

>>

>> >>> Tristan Rhodes <TristanRhodes@WEBER.EDU> 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_3g@mail.gmail.com>, Mark Duling <mark.duling@BIOLA.EDU> 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

>>

>>

>>

Message from marcelo.lew@du.edu

Here is a quick snapshot from our Aruba SE:

 

Some details about AirGroup technology from Aruba.

 

Basically there are 2 pieces in the Aruba AirGroup technology, Mobility Controllers and ClearPass Policy Manager (with Guest License)

 

  1. AirGroup controller features (in version 6.1.5)
    1. mDNS proxy services, send unicast responses back to mDNS queries & reduce mDNS traffic footprint
    2. Ensure cross VLAN visibility/availability of mDNS devices/services
    3. Allow/Block   mDNS services for all users
    4. Allow/Block  mDNS services based on user roles
    5. Match users devices (for ex. iPads) to their closest Wi-Fi  based mDNS servers (for ex. Printers) – requires CPPM
  2. ClearPass Policy Manager (with Guest License) value add (Amigopod 3.9)
    1. Registration portal for WLAN users to register their personal devices (Apple TVs, Printers)
    2. Registration portal for WLAN administrators to register shared devices (conference room Apple TVs, Printers)
    3. Define “personal AirGroups” by specifying a list of users to share devices with
    4. Define role and location (AP Group)  attributes for shared devices

 

 

Marcelo Lew

Wireless Enterprise Administrator

University Technology Services

University of Denver

Desk: (303) 871-6523

Cell: (303) 669-4217

Fax:  (303) 871-5900

Email: mlew@du.edu

 

 

From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Cappalli, Tim G @ LSC-OIT
Sent: Thursday, August 02, 2012 4:45 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Betr.: Re: [WIRELESS-LAN] Wireless Client Subnet sizing

 

ClearPass will only be required for residence hall/guest environments. Static device setup will be available in the base controller code. So if you wanted to make available a classroom AppleTV or printer, you could do that right in the controller. ClearPass adds user awareness and creates a “personal” network for all the user’s devices.

 

 

Tim Cappalli, ACMP CCNA | (802) 626-6456

Office of Information Technology (OIT) | Lyndon

» cappalli@lyndonstate.edu | oit.lyndonstate.edu

 

 

PRIVACY & CONFIDENTIALITY NOTICE
This message is for the designated recipient only and may

contain privileged, confidential, or otherwise private
information. If you have received it in error, please notify
the sender immediately and delete the original. Any other
use of an email received in error is prohibited.

 

-----Original Message-----
From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Marcelo Lew
Sent: Thursday, August 02, 2012 4:58 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Betr.: Re: [WIRELESS-LAN] Wireless Client Subnet sizing

 

Aruba is doing BC/MC location based with a feature they call AirGroup, but it requires another appliance (ClearPass) in conjunction with the controllers.

 

Marcelo Lew

Wireless Enterprise Administrator

University Technology Services

University of Denver

Desk: (303) 871-6523

Cell: (303) 669-4217

Fax:  (303) 871-5900

Email: mlew@du.edu

 

 

 

-----Original Message-----

From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Luke Jenkins

Sent: Thursday, August 02, 2012 2:23 PM

To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU

Subject: Re: [WIRELESS-LAN] Betr.: Re: [WIRELESS-LAN] Wireless Client Subnet sizing

 

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" <phanset@UTK.EDU> 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: craigsimons@sfu.ca

>> Twitter: simonscraig

>>

>> From: "Kees Pronk" <cl.pronk@AVANS.NL>

>> To: WIRELESS-LAN@listserv.educause.edu

>> 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.pd

>> f

>>

>> 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: cl.pronk@avans.nl

>> T: @rovinguser

>>

>>

>> >>> Tristan Rhodes <TristanRhodes@WEBER.EDU> 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_3g@mail.gmail.com>, Mark Duling <mark.duling@BIOLA.EDU> 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

>>

>>

>>

Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.