AW: [WIRELESS-LAN] MS-CHAPv2 cracks for WPA2-Enterprise?

[Sachse, Hartmut]

Here is a good article from Andrews Wifi-Blog addressing this topic:

http://revolutionwifi.blogspot.de/2012/07/is-wpa2-security-broken-due-to-defcon.html

Conclusion: PEAP security now only rely on the certificates used for the TLS 
tunnel. It's important to enable certificate verification on client-side. 



Greetings

Hartmut Sachse
Systems Engineer


__

pdv-systeme Sachsen GmbH
Zur Wetterwarte 4, 01109 Dresden

Telefon +49 351 2-0
Telefax +49 351 2-333

E-Mail: sac...@pdv-sachsen.net
http://www.pdv-sachsen.net

Handelsregister: Amtsgericht Dresden, HRB 1632
Geschäftsführer: Gerald Gruhl, Lutz Dähne

 
-Ursprüngliche Nachricht-
Von: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] Im Auftrag von Steve Bohrer
Gesendet: Montag, 30. Juli 2012 22:46
An: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Betreff: [WIRELESS-LAN] MS-CHAPv2 cracks for WPA2-Enterprise?

I'm hoping that people with crypto-clue can comment on the the recently 
introduced ChapCrack tool with respect to 802.1x WPA2- Enterprise wifi using 
PEAP/MS-CHAPv2. So far all I've found is "magazine level" references, e.g.:
   
http://news.cnet.com/8301-1009_3-57481855-83/tools-boast-easy-cracking-of-microsoft-crypto-for-businesses/

The vulnerabilities seem to be with MS-CHAPv2 on Microsoft's PPTP VPNs, but the 
articles also mention WPA2-Enterprise wireless. Do these tools work against 
PEAP/MS-CHAPv2 as well as against PPTP implementations? (That is, I don't 
really know how PEAP is similar/ dissimilar to PPTP.)

As it happens, until very recently we were using TTLS/PAP for our 802.1x 
authentication, but it is a pain for users to initially
connect: On Windows, they have to install the SecureW2 supplicant, and 
Mac/iPhone/iEtc devices need to install a custom wireless config file (or, on 
older Macs, specify the 802.1x configuration manually).

We've just added support for PEAP/MS-CHAP, which is much easier for users in 
that it pretty much "just works": you enter your username and password, and 
accept our RADIUS server's certificate, and you are on.

It would be a drag if we just swapped to a much more vulnerable protocol. 
Thanks for any clarifications you can offer.

Steve Bohrer
Network Admin
Bard College at Simon's Rock
413-528-7645

**
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/.

RE: [WIRELESS-LAN] MS-CHAPv2 cracks for WPA2-Enterprise?

[Lee H Badman]

Unfortunately... you can enable cert verification, but not enforce on the 
client side unless you strictly manage the client. 


 
 

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Sachse, Hartmut
Sent: Thursday, August 02, 2012 3:10 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] AW: [WIRELESS-LAN] MS-CHAPv2 cracks for WPA2-Enterprise?

Here is a good article from Andrews Wifi-Blog addressing this topic:

http://revolutionwifi.blogspot.de/2012/07/is-wpa2-security-broken-due-to-defcon.html

Conclusion: PEAP security now only rely on the certificates used for the TLS 
tunnel. It's important to enable certificate verification on client-side. 



Greetings

Hartmut Sachse
Systems Engineer


__

pdv-systeme Sachsen GmbH
Zur Wetterwarte 4, 01109 Dresden

Telefon +49 351 2-0
Telefax +49 351 2-333

E-Mail: sac...@pdv-sachsen.net
http://www.pdv-sachsen.net

Handelsregister: Amtsgericht Dresden, HRB 1632
Geschäftsführer: Gerald Gruhl, Lutz Dähne

 
-Ursprüngliche Nachricht-
Von: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] Im Auftrag von Steve Bohrer
Gesendet: Montag, 30. Juli 2012 22:46
An: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Betreff: [WIRELESS-LAN] MS-CHAPv2 cracks for WPA2-Enterprise?

I'm hoping that people with crypto-clue can comment on the the recently 
introduced ChapCrack tool with respect to 802.1x WPA2- Enterprise wifi using 
PEAP/MS-CHAPv2. So far all I've found is "magazine level" references, e.g.:
   
http://news.cnet.com/8301-1009_3-57481855-83/tools-boast-easy-cracking-of-microsoft-crypto-for-businesses/

The vulnerabilities seem to be with MS-CHAPv2 on Microsoft's PPTP VPNs, but the 
articles also mention WPA2-Enterprise wireless. Do these tools work against 
PEAP/MS-CHAPv2 as well as against PPTP implementations? (That is, I don't 
really know how PEAP is similar/ dissimilar to PPTP.)

As it happens, until very recently we were using TTLS/PAP for our 802.1x 
authentication, but it is a pain for users to initially
connect: On Windows, they have to install the SecureW2 supplicant, and 
Mac/iPhone/iEtc devices need to install a custom wireless config file (or, on 
older Macs, specify the 802.1x configuration manually).

We've just added support for PEAP/MS-CHAP, which is much easier for users in 
that it pretty much "just works": you enter your username and password, and 
accept our RADIUS server's certificate, and you are on.

It would be a drag if we just swapped to a much more vulnerable protocol. 
Thanks for any clarifications you can offer.

Steve Bohrer
Network Admin
Bard College at Simon's Rock
413-528-7645

**
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/.

RE: Wireless Client Subnet sizing

[Osborne, Bruce W]

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:tristanrho...@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 
>>> mailto:CAP8VL9hbfk669TT=XGMu5WdMt25_eopDZ=xvcvceohabjrr...@mail.gmail.com>>,
>>>  Mark Duling mailto:mark.dul...@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

On Tue, Jul 31, 2012 at 2:43 PM, Luke Jenkins 
mailto:ljenk...@weber.edu>> 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 
mailto:craigsim...@sfu.ca>> 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. craigsim...@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 
> 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/.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

RE: MS-CHAPv2 cracks for WPA2-Enterprise?

[Osborne, Bruce W]

In addition, if you are using WPA2-Enterprise, you need to decrypt the AES 
encrypted stream before you get to PEAP (You should not be using TKIP). 

Just because MS-CHAPv2 VPNs are broken does not mean that WPA2-Enterprise is 
broken.

Bruce Osborne
Network Engineer
IT Network Services
 
(434) 592-4229
 
LIBERTY UNIVERSITY
Training Champions for Christ since 1971

-Original Message-
From: Christopher Wieringa [mailto:cwier...@calvin.edu] 
Sent: Wednesday, August 01, 2012 8:56 AM
Subject: Re: MS-CHAPv2 cracks for WPA2-Enterprise?

It is possibly to do WPA2-Enterprise with only EAP-MSCHAPv2 authentication, and 
this is what would be considered completely vulnerable now.  Don't do this 
anymore if you are doing it.  

AFAIK, if you are using WPA2-Enterprise with PEAP/EAP-MSCHAPv2 you should still 
be fine.  While you could break the EAP-MSCHAPv2 authentication, you can only 
do it if you can decrypt the PEAP tunnel.  The PEAP tunnel is a TLS tunnel; so 
it is important to make sure wireless clients specify which certificate 
authorities they trust for the PEAP tunnel and verify the presented server's 
certificate.  At that point you can be reasonably sure that your traffic is not 
being intercepted and decrypted with a fake certificate and that your 
EAP-MSCHAPv2 conversation has not been intercepted.

Chris Wieringa

>>> On 7/30/2012 at 5:19 PM, Kees Pronk  wrote:
> Hi Steve,
> 
> In the answers on mentioned article the comment by Yuhong "This only 
> affects WPA-Enterprise with PEAP-MSCHAPv2, and can be stopped by 
> verifying the certificate"
> is imho correct. But I will keep a close watch on the several Wi-Fi 
> blogs to make sure.
> See also chapter 4 page 132 of the CWSP official study guide (highly 
> recommended).
> 
> BR, Kees Pronk
> 
> 
> Netwerk admin & engineer
>  
> Avans Hogeschool
> Diensteenheid ICT en Facilitaire Dienst (DIF) - ICT-Beheer
>  
> Bezoekadres:
> Hogeschoollaan 1, Kamer HG204
> 4818 CR  Breda
>  
> Postadres:
> Postbus 90116
> 4800 RA Breda
>  
> E: cl.pr...@avans.nl
> T: 076-5238054
> 
> 
 Steve Bohrer  7/30/2012 10:45  >>>
> I'm hoping that people with crypto-clue can comment on the the 
> recently introduced ChapCrack tool with respect to 802.1x WPA2- 
> Enterprise wifi using PEAP/MS-CHAPv2. So far all I've found is 
> "magazine level" references, e.g.:
>
> http://news.cnet.com/8301-1009_3-57481855-83/tools-boast-easy-cracking
> -of-microsof
> t-crypto-for-businesses/
> 
> The vulnerabilities seem to be with MS-CHAPv2 on Microsoft's PPTP 
> VPNs, but the articles also mention WPA2-Enterprise wireless. Do these 
> tools work against PEAP/MS-CHAPv2 as well as against PPTP 
> implementations? (That is, I don't really know how PEAP is similar/ 
> dissimilar to PPTP.)
> 
> As it happens, until very recently we were using TTLS/PAP for our 
> 802.1x authentication, but it is a pain for users to initially
> connect: On Windows, they have to install the SecureW2 supplicant, and 
> Mac/iPhone/iEtc devices need to install a custom wireless config file 
> (or, on older Macs, specify the 802.1x configuration manually).
> 
> We've just added support for PEAP/MS-CHAP, which is much easier for 
> users in that it pretty much "just works": you enter your username and 
> password, and accept our RADIUS server's certificate, and you are on.
> 
> It would be a drag if we just swapped to a much more vulnerable 
> protocol. Thanks for any clarifications you can offer.
> 
> Steve Bohrer
> Network Admin
> Bard College at Simon's Rock
> 413-528-7645  
> 
> **
> 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/.



--
--
Chris Wieringa
cwier...@calvin.edu
Sr. Systems Engineer
Calvin Information Technology 

**
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/.

RE: MS-CHAPv2 cracks for WPA2-Enterprise?

[Osborne, Bruce W]

Earlier,  I posted that you need to decrypt the AES encrypted stream before you 
get to PEAP.

I forgot that the PEAP authentication happens before the WAP2 4-way handshake. 
Here is an explanation from another user.

If the attacker can get inside the PEAP exchange, regardless of your choice of 
TKIP or AES-CCMP, then they can also get the PMK, which allows them to get the 
PTK and all future key rotation operations for the duration of the PMK (which 
can change depending on your AP hardware, roaming configuration, 802.11r 
support, etc.).

At Liberty, we have certificates on our RADIUS serves that are issued by a 
trusted CA. Our client machines and 802.1X configuration tool set up the 
clients to only trust certificates from that specific root CA and to only use 
specific named RADIUS servers. We also load-balance our RADIUS servers, with 
different certificates on each. To compromise this, an attacker would need to 
get or spoof a certificate for a specific RADIUS server from a specific CA. 
Even then, they would only affect a portion of our users unless they spoof all 
our RADIUS servers.

Bruce Osborne
Network Engineer
IT Network Services
 
(434) 592-4229
 
LIBERTY UNIVERSITY
Training Champions for Christ since 1971


-Original Message-
From: Christopher Wieringa [mailto:cwier...@calvin.edu] 
Sent: Wednesday, August 01, 2012 8:56 AM
Subject: Re: MS-CHAPv2 cracks for WPA2-Enterprise?

It is possibly to do WPA2-Enterprise with only EAP-MSCHAPv2 authentication, and 
this is what would be considered completely vulnerable now.  Don't do this 
anymore if you are doing it.  

AFAIK, if you are using WPA2-Enterprise with PEAP/EAP-MSCHAPv2 you should still 
be fine.  While you could break the EAP-MSCHAPv2 authentication, you can only 
do it if you can decrypt the PEAP tunnel.  The PEAP tunnel is a TLS tunnel; so 
it is important to make sure wireless clients specify which certificate 
authorities they trust for the PEAP tunnel and verify the presented server's 
certificate.  At that point you can be reasonably sure that your traffic is not 
being intercepted and decrypted with a fake certificate and that your 
EAP-MSCHAPv2 conversation has not been intercepted.

Chris Wieringa

>>> On 7/30/2012 at 5:19 PM, Kees Pronk  wrote:
> Hi Steve,
> 
> In the answers on mentioned article the comment by Yuhong "This only 
> affects WPA-Enterprise with PEAP-MSCHAPv2, and can be stopped by 
> verifying the certificate"
> is imho correct. But I will keep a close watch on the several Wi-Fi 
> blogs to make sure.
> See also chapter 4 page 132 of the CWSP official study guide (highly 
> recommended).
> 
> BR, Kees Pronk
> 
> 
> Netwerk admin & engineer
>  
> Avans Hogeschool
> Diensteenheid ICT en Facilitaire Dienst (DIF) - ICT-Beheer
>  
> Bezoekadres:
> Hogeschoollaan 1, Kamer HG204
> 4818 CR  Breda
>  
> Postadres:
> Postbus 90116
> 4800 RA Breda
>  
> E: cl.pr...@avans.nl
> T: 076-5238054
> 
> 
 Steve Bohrer  7/30/2012 10:45  >>>
> I'm hoping that people with crypto-clue can comment on the the 
> recently introduced ChapCrack tool with respect to 802.1x WPA2- 
> Enterprise wifi using PEAP/MS-CHAPv2. So far all I've found is 
> "magazine level" references, e.g.:
>
> http://news.cnet.com/8301-1009_3-57481855-83/tools-boast-easy-cracking
> -of-microsof
> t-crypto-for-businesses/
> 
> The vulnerabilities seem to be with MS-CHAPv2 on Microsoft's PPTP 
> VPNs, but the articles also mention WPA2-Enterprise wireless. Do these 
> tools work against PEAP/MS-CHAPv2 as well as against PPTP 
> implementations? (That is, I don't really know how PEAP is similar/ 
> dissimilar to PPTP.)
> 
> As it happens, until very recently we were using TTLS/PAP for our 
> 802.1x authentication, but it is a pain for users to initially
> connect: On Windows, they have to install the SecureW2 supplicant, and 
> Mac/iPhone/iEtc devices need to install a custom wireless config file 
> (or, on older Macs, specify the 802.1x configuration manually).
> 
> We've just added support for PEAP/MS-CHAP, which is much easier for 
> users in that it pretty much "just works": you enter your username and 
> password, and accept our RADIUS server's certificate, and you are on.
> 
> It would be a drag if we just swapped to a much more vulnerable 
> protocol. Thanks for any clarifications you can offer.
> 
> Steve Bohrer
> Network Admin
> Bard College at Simon's Rock
> 413-528-7645  
> 
> **
> 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 discus

Re: [WIRELESS-LAN] Wireless Client Subnet sizing

[Craig Eyre]

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. ce...@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:tristanrho...@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...@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 
  

  

  

  
   On Tue, Jul 31,

Our Apple Request Tracking ID

[Johnson, Neil M]

Our authorized Apple support person opened a feature request/trouble ticket for 
me. The ID is as follows:

[386504] AirPlay/Apple TV Enhancement Request

Basically we submitted a truncated version of the petition.

Feel free to quote this ID in your requests to Apple support.

-Neil

--
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319 384-0938
Fax: 319 335-2951
Mobile: 319 540-2081
E-Mail: neil-john...@uiowa.edu


**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.

RE: Our Apple Request Tracking ID

[Colleen Szymanik]

We did the same thing @ University of Pennsylvania as well.  Our goal is to 
attack the issue on multiple fronts: Apple, our vendors and this petition.

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Johnson, Neil M
Sent: Thursday, August 02, 2012 10:41 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Our Apple Request Tracking ID



Our authorized Apple support person opened a feature request/trouble ticket for 
me. The ID is as follows:

[386504] AirPlay/Apple TV Enhancement Request

Basically we submitted a truncated version of the petition.

Feel free to quote this ID in your requests to Apple support.

-Neil

--
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319 384-0938
Fax: 319 335-2951
Mobile: 319 540-2081
E-Mail: neil-john...@uiowa.edu

** 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/.

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

[Craig Simons]

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

- Original Message -

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.pr...@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 


On Tue, Jul 31, 2012 at 2:43 PM, Luke Jenkins  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  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

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

[Hanset, Philippe C]

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



From: "Kees Pronk" mailto:cl.pr...@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.pr...@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 

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

[Luke Jenkins]

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"  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: craigsim...@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
>>  
>> Bezoekadre

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

[Marcelo Lew]

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: m...@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"  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: craigsim...@sfu.ca
>> Twitter: simonscraig
>> 
>> From: "Kees Pronk" 
>> To: WIRELESS-LAN@listserv.edu

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

[Cappalli, Tim G @ LSC-OIT]

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
> cappa...@lyndonstate.edu | 
> oit.lyndonstate.edu

[Description: cid:image001.png@01CD70C4.7967F750]

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: m...@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" 
mailto:phan...@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 eas