RE: [WIRELESS-LAN] Measuring RADIUS Auths

[Mattson III, Ken V.]

I am pretty sure it is raw ("The number of RADIUS Access-Request packets sent 
to this server. This does not include retransmissions.").

1.3.6.1.4.1.14179.2.5.3.1.8.3 is the retransmissions.
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en=Translate=bsnRadiusAuthClientAccessRetransmissions#oidContent


Output from a snmpbulkwalk on one of our controllers:
.1.3.6.1.4.1.14179.2.5.3.1.7.3 = Counter32: 93421076
.1.3.6.1.4.1.14179.2.5.3.1.7.4 = Counter32: 0
.1.3.6.1.4.1.14179.2.5.3.1.8.3 = Counter32: 31652
.1.3.6.1.4.1.14179.2.5.3.1.8.4 = Counter32: 0


Kenneth V. Mattson III
Director - Network and Data
DoIT
Creighton University
402-280-2743
402-981-1140
 
A password is like a toothbrush:
Choose a good one, change it regularly and don't share it.

-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Charles Rumford
Sent: Friday, October 16, 2015 12:13 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Measuring RADIUS Auths

Is that raw requests or complete auths?

> On Oct 16, 2015, at 12:46 PM, Mattson III, Ken V.  
> wrote:
> 
> We poll our controllers directly.
> 
> 
> 
> http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1.14179.2.5.3.1.7=Translate=SUBMIT=true
> 
> 
> 
> We use the following OIDs:
> 
> 
> 
> 1.3.6.1.4.1.14179.2.5.3.1.7.3&1.3.6.1.4.1.14179.2.5.3.1.8.3
> 
> 
> 
> And graph them here:
> 
> 
> 
> http://mrtg.creighton.edu/WiSM/WiSM_Radius_Statistics.html
> 
> 
> 
> 
> 
> 
> 
> Kenneth V. Mattson III
> Director - Network and Data
> DoIT
> Creighton University
> 402-280-2743
> 402-981-1140
> 
> A password is like a toothbrush:
> Choose a good one, change it regularly and don't share it.
> 
> 
> 
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ciesinski, Nick
> Sent: Friday, October 16, 2015 10:20 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Measuring RADIUS Auths
> 
> 
> 
> This is the access key  AV3Q6TQB  I can’t add you for some reason.  Did you 
> ID change in CCW?
> 
> 
> 
> Nick
> 
> On Oct 16, 2015, at 10:11 AM, Walter Reynolds  wrote:
> 
> 
> 
> Since you mention in the thread that you have Cisco with Freeradius backend, 
> I thought I would point out that if you are request that show up in total 
> request.
> 
> 
> 
> That being said, our heaviest loaded Freeradius box seems to be hitting max 
> and we have hit as high as 150 auths/sec with an average of 80/sec over a 
> minute window.
> 
> 
> 
> Stand alone Two processor Quad core Intel Xeon X5570  @ 2.93GHz with 6Gb ram
> 
> 
> 
> A VM single Quad core with 8Gb ram seems to be peaking at 80/sec with a one 
> minute avg of 60/sec
> 
> 
> 
> 
> 
> 
> Walter Reynolds
> 
> Principal Systems Security Development Engineer
> Information and Technology Services
> University of Michigan
> (734) 615-9438
> 
> 
> 
> On Thu, Oct 15, 2015 at 5:08 PM, Charles Rumford  
> wrote:
> 
> I’m currently embarking on a project to determine the number of RADIUS auths 
> per minute each one of my controllers is generating
> 
> I was curious if anyone has embarked on a similar journey and tried to 
> measure auth rates coming from their controllers?
> 
> I have a couple of ideas that I’m up for sharing, but I wanted to see if 
> anyone else has done this.
> 
> Thanks!
> 
> 
> Charles Rumford
> Network Engineer/Senior Wireless Engineer
> ISC Network Operations
> University of Pennsylvania
> OpenPGP Key ID: 0xF3D8215A
> (p) 215-746-2808
> 
> 
> **
> Participation and subscription information for this EDUCAUSE Constituent 
> Group discussion list can be found at http://www.educause.edu/groups/.
> 
> 
> 
> ** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found 
> athttp://www.educause.edu/groups/.
> 
> 
> 
> 
> 
> ** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found 
> 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/.
> 


Charles Rumford
Network Engineer/Senior Wireless Engineer
ISC Network Operations
University of Pennsylvania
OpenPGP Key ID: 0xF3D8215A
(p) 215-746-2808


**
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] How to handle Wi-Fi Calling?

[Frank Sweetser]

Personally, I would think that using WiFi calling as a replacement for cell 
coverage (as opposed to an enhancement) is a long ways off, especially given 
how many phones are still out there that don't support it.  Instead, I'd 
suggest looking at a 3rd party DAS system, which would also have the advantage 
of allowing you to work with multiple carriers.  We've been having good 
results with Seamless Cellular, though I'm sure there are plenty of other 
vendors out there:


http://www.seamlesscellular.com/

Frank Sweetser fs at wpi.edu|  For every problem, there is a solution that
Manager of Network Operations   |  is simple, elegant, and wrong.
Worcester Polytechnic Institute |   - HL Mencken

On 10/16/2015 02:14 PM, Smith, Todd wrote:

Hello,

Yesterday, a regional VP for AT Wireless told my Enterprise Architect and CIO that 
AT was not interested in pursuing a distributed antenna system with us and made it 
clear that they would not be moving forward with any DAS in the future.  In seems, that 
Wi-Fi calling is the moving forward strategy for AT for poor cellular signal and 
presumably other carriers.  I wasn’t in the meeting but I am confident that it has been 
reported accurately.

Does this sound like anything that anyone else has heard?  If so, how are other 
institutions handling this?  It seems silly that our organization which is in 
the planning stages for a Wi-Fi wireless upgrade anyway would build in the 
necessary upgrades to accumulate cell carrier backhaul traffic for no 
compensation whatsoever.

As usual, my job is to do or die, so I am trying to see what others might have 
done and if possible start a line of discussion to reason out the best way to 
handle poor cellular coverage in both older buildings as well as brand new 
LEEDS certified buildings.

1)  Would you create a new SSID for cellular traffic with QoS enabled and 
open to the Internet with UDP 500 and 4500 open as well as more normal ports?
2)  I can’t find any solid reference that details exactly how much 
bandwidth per call.  I have literally read in the last couple of hours, 
everything from 2.5Kbps to 1Mbps to a general consensus from 60-128Kbps per 
call.
3)  2.4Ghz or 5Ghz or both?
4)  Much of the discussion of seamless handover from cell to Wi-Fi involved 
HD Voice which seems to be provisioned as part of VoLTE and only available in 
some areas; i.e. not my coverage area.  How to communicate to your normal users 
and any public that uses your Wi-Fi that when they switch between platforms; 
the call will be dropped?
5)  Would we be responsible for maintaining redundant Internet connections 
just to support cell calls?  Is there any requirement that would state that 
since we are providing cellular infrastructure that we are responsible for a 
certain minimum SLA?

Is there any other questions or comments to think about?

Todd





==

CONFIDENTIALITY NOTICE: The information contained in this
message may
be privileged and confidential. If this e-mail contains protected
health information, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited,
except as permitted by law. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting it from your computer. Thank you.



**
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] Measuring RADIUS Auths

[Charles Rumford]

Is that raw requests or complete auths?

> On Oct 16, 2015, at 12:46 PM, Mattson III, Ken V.  
> wrote:
> 
> We poll our controllers directly.
> 
> 
> 
> http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1.14179.2.5.3.1.7=Translate=SUBMIT=true
> 
> 
> 
> We use the following OIDs:
> 
> 
> 
> 1.3.6.1.4.1.14179.2.5.3.1.7.3&1.3.6.1.4.1.14179.2.5.3.1.8.3
> 
> 
> 
> And graph them here:
> 
> 
> 
> http://mrtg.creighton.edu/WiSM/WiSM_Radius_Statistics.html
> 
> 
> 
> 
> 
> 
> 
> Kenneth V. Mattson III
> Director - Network and Data
> DoIT
> Creighton University
> 402-280-2743
> 402-981-1140
> 
> A password is like a toothbrush:
> Choose a good one, change it regularly and don't share it.
> 
> 
> 
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ciesinski, Nick
> Sent: Friday, October 16, 2015 10:20 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] Measuring RADIUS Auths
> 
> 
> 
> This is the access key  AV3Q6TQB  I can’t add you for some reason.  Did you 
> ID change in CCW?
> 
> 
> 
> Nick
> 
> On Oct 16, 2015, at 10:11 AM, Walter Reynolds  wrote:
> 
> 
> 
> Since you mention in the thread that you have Cisco with Freeradius backend, 
> I thought I would point out that if you are request that show up in total 
> request.
> 
> 
> 
> That being said, our heaviest loaded Freeradius box seems to be hitting max 
> and we have hit as high as 150 auths/sec with an average of 80/sec over a 
> minute window.
> 
> 
> 
> Stand alone Two processor Quad core Intel Xeon X5570  @ 2.93GHz with 6Gb ram
> 
> 
> 
> A VM single Quad core with 8Gb ram seems to be peaking at 80/sec with a one 
> minute avg of 60/sec
> 
> 
> 
> 
> 
> 
> Walter Reynolds
> 
> Principal Systems Security Development Engineer
> Information and Technology Services
> University of Michigan
> (734) 615-9438
> 
> 
> 
> On Thu, Oct 15, 2015 at 5:08 PM, Charles Rumford  
> wrote:
> 
> I’m currently embarking on a project to determine the number of RADIUS auths 
> per minute each one of my controllers is generating
> 
> I was curious if anyone has embarked on a similar journey and tried to 
> measure auth rates coming from their controllers?
> 
> I have a couple of ideas that I’m up for sharing, but I wanted to see if 
> anyone else has done this.
> 
> Thanks!
> 
> 
> Charles Rumford
> Network Engineer/Senior Wireless Engineer
> ISC Network Operations
> University of Pennsylvania
> OpenPGP Key ID: 0xF3D8215A
> (p) 215-746-2808
> 
> 
> **
> Participation and subscription information for this EDUCAUSE Constituent 
> Group discussion list can be found at http://www.educause.edu/groups/.
> 
> 
> 
> ** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found 
> athttp://www.educause.edu/groups/.
> 
> 
> 
> 
> 
> ** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found 
> 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/.
> 


Charles Rumford
Network Engineer/Senior Wireless Engineer
ISC Network Operations
University of Pennsylvania
OpenPGP Key ID: 0xF3D8215A
(p) 215-746-2808


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



signature.asc
Description: Message signed with OpenPGP using GPGMail

How to handle Wi-Fi Calling?

[Smith, Todd]

Hello,

Yesterday, a regional VP for AT Wireless told my Enterprise Architect and CIO 
that AT was not interested in pursuing a distributed antenna system with us 
and made it clear that they would not be moving forward with any DAS in the 
future.  In seems, that Wi-Fi calling is the moving forward strategy for AT 
for poor cellular signal and presumably other carriers.  I wasn’t in the 
meeting but I am confident that it has been reported accurately.

Does this sound like anything that anyone else has heard?  If so, how are other 
institutions handling this?  It seems silly that our organization which is in 
the planning stages for a Wi-Fi wireless upgrade anyway would build in the 
necessary upgrades to accumulate cell carrier backhaul traffic for no 
compensation whatsoever.

As usual, my job is to do or die, so I am trying to see what others might have 
done and if possible start a line of discussion to reason out the best way to 
handle poor cellular coverage in both older buildings as well as brand new 
LEEDS certified buildings.

1)  Would you create a new SSID for cellular traffic with QoS enabled and 
open to the Internet with UDP 500 and 4500 open as well as more normal ports?
2)  I can’t find any solid reference that details exactly how much 
bandwidth per call.  I have literally read in the last couple of hours, 
everything from 2.5Kbps to 1Mbps to a general consensus from 60-128Kbps per 
call.
3)  2.4Ghz or 5Ghz or both?
4)  Much of the discussion of seamless handover from cell to Wi-Fi involved 
HD Voice which seems to be provisioned as part of VoLTE and only available in 
some areas; i.e. not my coverage area.  How to communicate to your normal users 
and any public that uses your Wi-Fi that when they switch between platforms; 
the call will be dropped?
5)  Would we be responsible for maintaining redundant Internet connections 
just to support cell calls?  Is there any requirement that would state that 
since we are providing cellular infrastructure that we are responsible for a 
certain minimum SLA?

Is there any other questions or comments to think about?

Todd





==

CONFIDENTIALITY NOTICE: The information contained in this
message may
be privileged and confidential. If this e-mail contains protected
health information, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited,
except as permitted by law. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting it from your computer. Thank you.



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

Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

[Howard, Christopher]

I'm honestly not surprised to hear that they are going to push wifi calling and 
nothing else.  They want to drop all cellular service other than data, long 
term, in my opinion.

I have AT myself, and ran the iOS 9 beta from the beginning, which got me 
early access to AT wifi calling.  Needless to say, it has not been a pleasant 
experience.  Calls drop all the time.

For our wireless we have not had to do anything.  Calls just work without 
opening inbound ports (we don't limit much going outbound).  My calls run about 
65kbps.

The pain point is something you've already mentioned - roaming.  If at any time 
you roam from wifi to cell and there is no VoLTE service in your area, the call 
dies.  We apparently don't have VoLTE in Chattanooga, TN.  If I stay in my 
office I can usually hold a call, and roaming from AP to AP is sometimes ok.  
Sometimes the roam between APs is enough to drop the call.  I've also noticed 
that if I get more than 2 cell bars, the phone will want to go off of wifi 
calling on its own.  Even at home where I only have 1 AP and can be sitting 15 
feet from it, I'll drop calls because my phone decided to roam back to cell 
during a live call.

To directly answer your questions:
1. I don't plan on doing anything special.  We have enough free bandwidth to 
handle a large number of 65kbps calls.
2. Mine have been 65kbps or there about.
3. We run both frequencies, but my phone tends to stay 5ghz.  I don't think we 
would change anything to support wifi calling.
4. I'm not sure how we will get this across other than to let our helpdesk know 
what to tell people when they call in about it.  We'll be looking into this 
more I'm sure.
5. I'm a little surprised that carriers are being allowed to run calls over end 
user networks.  911 is a big deal, and if our wifi is up enough that the phone 
can do wifi calling, but there are issues going on to prevent calls, who gets 
blamed here?  In an emergency, it's too much to troubleshoot what's going on 
and figure out that you have to cut off your wireless to get a call through.  
As far as I know, there's nothing we have to do in terms of uptime or anything.

-Christopher

On Oct 16, 2015, at 2:14 PM, Smith, Todd 
> wrote:

Hello,

Yesterday, a regional VP for AT Wireless told my Enterprise Architect and CIO 
that AT was not interested in pursuing a distributed antenna system with us 
and made it clear that they would not be moving forward with any DAS in the 
future.  In seems, that Wi-Fi calling is the moving forward strategy for AT 
for poor cellular signal and presumably other carriers.  I wasn’t in the 
meeting but I am confident that it has been reported accurately.

Does this sound like anything that anyone else has heard?  If so, how are other 
institutions handling this?  It seems silly that our organization which is in 
the planning stages for a Wi-Fi wireless upgrade anyway would build in the 
necessary upgrades to accumulate cell carrier backhaul traffic for no 
compensation whatsoever.

As usual, my job is to do or die, so I am trying to see what others might have 
done and if possible start a line of discussion to reason out the best way to 
handle poor cellular coverage in both older buildings as well as brand new 
LEEDS certified buildings.

1)  Would you create a new SSID for cellular traffic with QoS enabled and 
open to the Internet with UDP 500 and 4500 open as well as more normal ports?
2)  I can’t find any solid reference that details exactly how much 
bandwidth per call.  I have literally read in the last couple of hours, 
everything from 2.5Kbps to 1Mbps to a general consensus from 60-128Kbps per 
call.
3)  2.4Ghz or 5Ghz or both?
4)  Much of the discussion of seamless handover from cell to Wi-Fi involved 
HD Voice which seems to be provisioned as part of VoLTE and only available in 
some areas; i.e. not my coverage area.  How to communicate to your normal users 
and any public that uses your Wi-Fi that when they switch between platforms; 
the call will be dropped?
5)  Would we be responsible for maintaining redundant Internet connections 
just to support cell calls?  Is there any requirement that would state that 
since we are providing cellular infrastructure that we are responsible for a 
certain minimum SLA?

Is there any other questions or comments to think about?

Todd





==

CONFIDENTIALITY NOTICE: The information contained in this
message may
be privileged and confidential. If this e-mail contains protected
health information, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited,
except as permitted by law. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting it from your computer. Thank you.



**
Participation and subscription 

RE: [WIRELESS-LAN] How to handle Wi-Fi Calling?

[Smith, Todd]

Frank,

Thanks for the feedback.  My thought is that it silly to scrap plans for a DAS 
beacuse one vendor chooses to not be a part of it.  The somewhat scary part is 
that we would told that even if we had a DAS that AT wouldn't be providing 
signal for it.

Obviously, we can relay and ampify any OTA signal, but that it differernt that 
a connection back to the carrier's network.

Todd


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Frank Sweetser [f...@wpi.edu]
Sent: Friday, October 16, 2015 3:21 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

Personally, I would think that using WiFi calling as a replacement for cell
coverage (as opposed to an enhancement) is a long ways off, especially given
how many phones are still out there that don't support it.  Instead, I'd
suggest looking at a 3rd party DAS system, which would also have the advantage
of allowing you to work with multiple carriers.  We've been having good
results with Seamless Cellular, though I'm sure there are plenty of other
vendors out there:

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.seamlesscellular.com_=CQIFaQ=2GaipCMI-4CXTl0y2l8grQS3faC7QKiDQZYpyUtD00M=uvxIRDMxwssmr2VjVNRe6I_MeNT0SmtowN9dpqcMAFc=NXkjomrT3tAlBdDINCRObWkJEimTOp5YtYebqoXGFzY=2C-TkXW52Z23_K51s-saiv4V-sFmqA-qJhXaL_jD76s=

Frank Sweetser fs at wpi.edu|  For every problem, there is a solution that
Manager of Network Operations   |  is simple, elegant, and wrong.
Worcester Polytechnic Institute |   - HL Mencken

==

CONFIDENTIALITY NOTICE: The information contained in this
message may
be privileged and confidential. If this e-mail contains protected
health information, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited,
except as permitted by law. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting it from your computer. Thank you.

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

Re: [WIRELESS-LAN] Multi Vendor environments in WiFi space

[Jeffrey D. Sessler]

Oli,

It didn’t require a lot of work. My Cisco team keeps me informed of the 
specials/promos, and I try to align my purchasing with the promos, and if 
possible, Cisco’s end-of-year/quarter. At no time did I need to pull out a bat 
and beat on them… :)

In my case, it was the refresh of about 275 AP’s (1142/1252) for 3700-series, 
and the purchase of about 40 switches. A big chunk of the discount came from 
the trade-in credit.

Jeff

From: 
"wireless-lan@listserv.educause.edu" 
> 
on behalf of 
"oliver.elli...@bristol.ac.uk" 
>
Reply-To: "oliver.elli...@bristol.ac.uk" 
>
Date: Friday, October 16, 2015 at 1:25 AM
To: 
"wireless-lan@listserv.educause.edu" 
>
Subject: Re: [WIRELESS-LAN] Multi Vendor environments in WiFi space

Jeff

How did you achieve that discount, was it a significant bulk order? We tend to 
buy large amounts of switches and APs separately, if we can save a lot of money 
buying them together that would be nice!

Oli

On 15 October 2015 at 19:15, Jeffrey D. Sessler 
> wrote:
I think it's always wise to look at other vendors when you're about to replace 
that amount of equipment, but unless you are unhappy, it's unlikely that the 
alternative will come out less expensive i.e. hardware purchase, plus 
learning/supporting another vendor.

If you're happy, work with your incumbent vendor to see what they'll do to keep 
you in the family.

For Cisco, right now there is a deal where you can get substantial additional 
discounts on wireless if it's paired with switching (which also gets extra 
discounts), and these stack on top of the discount you get normally. Let's just 
say that 70%-ish off is not difficult. I took advantage of the discount last 
year and the cost for a 3702i was pretty amazing.

Jeff


-Original Message-
From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]
 On Behalf Of Oliver, Jeff
Sent: Thursday, October 15, 2015 9:42 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Multi Vendor environments in WiFi space

All,

This is probably an old topic, but I have not seen anything in a while on it.

At present we are a Cisco shop with regard to our wireless deployment, and we 
are looking at changing out a substantial number (250) of our AP's (1131 to 
3702). These AP's represent about 30% of our deployment so is a substantial 
investment, and as such our CIO has asked us to look at other solutions.

I am wondering if any of you are running multi vendor environments and if so, 
what the UX is like? What are the toolsets like regarding management of two 
disparate systems?



Cheers,
Jeff

---

Jeffrey L. Oliver
Sr. Network Analyst
Information Technology Services
The University of Lethbridge
4401 University Drive, Lethbridge, Alberta, T1K 3M4

Tel:403.329.5162
Mob:403.315.4461
Fax:403.382.7108

URI:jeff.oli...@uleth.ca

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




--
Oliver Elliott
Senior Network Specialist
IT Services
University of Bristol
e: oliver.elli...@bristol.ac.uk
t: 0117 39 (41131)
** 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] How to handle Wi-Fi Calling?

[Howard, Christopher]

We try to shoot for -65dB as well, so that could be contributing to dropped 
calls.  I'm on a iPhone 6 plus.  Roaming on wifi has always been a pain. :)  
Stick something sensitive on there like calling and it's worse.  I do have 
better luck if I sit still.

Based on the codec descriptions it appears AT is using G711.

-Christopher

On Oct 16, 2015, at 4:49 PM, Jon Scot Prunckle 
> wrote:

Frans,

Thank you for the very enlightening email!

Our university is on the periphery of VoIP.  WiFi calling is going to have an 
interesting impact on our network.  Our 5GHz "coverage" low-end threshold is 
-65 dBm.  We may see an uptick in trouble reports.

This information will be valuable for improving our user experience!

Thank you again!

Sincerely,


J. Scot Prunckle



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> 
on behalf of Frans Panken 
>
Sent: Friday, October 16, 2015 3:35 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

You need at least -62db RF-plan to roam between APs without loosing a call. 
Some devices are more picky than others (iphone 5c and higher give less 
problems). I observed that the scanning time of Android is often too high which 
makes roaming a bad user experience (but I have not tested the latest versions).

If you have no QoS and you are surrounded by many clients, you will experience 
problems in your call (either on the listening side or on the speaking side or 
on both sides). Not because of the bandwith requirements for a call but mainly 
because of the high sampling rate of VoIP and the jitter caused by 
retransmissions and the exponential back-off of the Wi-Fi protocol. This may 
result in dropping the call. The bandwidth requirements per call depend on the 
codec used. The traditional G711 codec results in a 64kbit/s connection whereas 
G729 is only 8 kbit/s. Skype uses a SILK codec, using between 6 and 40 kbit/s. 
Note, this is at the application layer. As a result of the overhead and 
inefficiency of the Wi-Fi protocol, the data rate on the Wi-Fi layer is much 
higher!
5Ghz is (much) better suitable for VoIP than 2,4Ghz. Especially with high 
number of active clients per AP.

The downsize I experience from Wi-Fi calling on a smartphone is that all phones 
give priority to incomming 2G/3G/4G calls. No matter what device or app you 
use, your Wi-Fi calls drops if a person tries to reach you via the cellular 
network. But that won't bother you if your indoor reach is poor.

I am surprised that mobile carriers in the US allow end-user networks in their 
VoIP communication path. That is unusual in the Netherlands (where we have less 
need for Wi-Fi calling as we have sound coverage and carriers are not offering 
Wi-Fi calling and will gladly install DAS instead in the case of bad indoor 
coverage which happens often as a result of e.g., foil on windows or because 
carriers move 2G/3G voice to high frequencies which penetrate badly through 
walls and windows).

-Frans


Op 16/10/15 om 21:34 schreef Howard, Christopher:
I'm honestly not surprised to hear that they are going to push wifi calling and 
nothing else.  They want to drop all cellular service other than data, long 
term, in my opinion.

I have AT myself, and ran the iOS 9 beta from the beginning, which got me 
early access to AT wifi calling.  Needless to say, it has not been a pleasant 
experience.  Calls drop all the time.

For our wireless we have not had to do anything.  Calls just work without 
opening inbound ports (we don't limit much going outbound).  My calls run about 
65kbps.

The pain point is something you've already mentioned - roaming.  If at any time 
you roam from wifi to cell and there is no VoLTE service in your area, the call 
dies.  We apparently don't have VoLTE in Chattanooga, TN.  If I stay in my 
office I can usually hold a call, and roaming from AP to AP is sometimes ok.  
Sometimes the roam between APs is enough to drop the call.  I've also noticed 
that if I get more than 2 cell bars, the phone will want to go off of wifi 
calling on its own.  Even at home where I only have 1 AP and can be sitting 15 
feet from it, I'll drop calls because my phone decided to roam back to cell 
during a live call.

To directly answer your questions:
1. I don't plan on doing anything special.  We have enough free bandwidth to 
handle a large number of 65kbps calls.
2. Mine have been 65kbps or there about.
3. We run both frequencies, but my phone tends to stay 5ghz.  I don't think we 
would change anything to support wifi calling.
4. I'm not sure how we will get this across other than to let our helpdesk know 
what to tell people when they call in about it.  We'll be looking into this 
more I'm 

Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

[Frans Panken]

You need at least -62db RF-plan to roam between APs without loosing a
call. Some devices are more picky than others (iphone 5c and higher give
less problems). I observed that the scanning time of Android is often
too high which makes roaming a bad user experience (but I have not
tested the latest versions).

If you have no QoS and you are surrounded by many clients, you will
experience problems in your call (either on the listening side or on the
speaking side or on both sides). Not because of the bandwith
requirements for a call but mainly because of the high sampling rate of
VoIP and the jitter caused by retransmissions and the exponential
back-off of the Wi-Fi protocol. This may result in dropping the call.
The bandwidth requirements per call depend on the codec used. The
traditional G711 codec results in a 64kbit/s connection whereas G729 is
only 8 kbit/s. Skype uses a SILK codec, using between 6 and 40 kbit/s.
Note, this is at the application layer. As a result of the overhead and
inefficiency of the Wi-Fi protocol, the data rate on the Wi-Fi layer is
much higher!
5Ghz is (much) better suitable for VoIP than 2,4Ghz. Especially with
high number of active clients per AP.

The downsize I experience from Wi-Fi calling on a smartphone is that all
phones give priority to incomming 2G/3G/4G calls. No matter what device
or app you use, your Wi-Fi calls drops if a person tries to reach you
via the cellular network. But that won't bother you if your indoor reach
is poor.

I am surprised that mobile carriers in the US allow end-user networks in
their VoIP communication path. That is unusual in the Netherlands (where
we have less need for Wi-Fi calling as we have sound coverage and
carriers are not offering Wi-Fi calling and will gladly install DAS
instead in the case of bad indoor coverage which happens often as a
result of e.g., foil on windows or because carriers move 2G/3G voice to
high frequencies which penetrate badly through walls and windows).

-Frans


Op 16/10/15 om 21:34 schreef Howard, Christopher:
> I'm honestly not surprised to hear that they are going to push wifi
> calling and nothing else.  They want to drop all cellular service
> other than data, long term, in my opinion.
>
> I have AT myself, and ran the iOS 9 beta from the beginning, which
> got me early access to AT wifi calling.  Needless to say, it has not
> been a pleasant experience.  Calls drop all the time.
>
> For our wireless we have not had to do anything.  Calls just work
> without opening inbound ports (we don't limit much going outbound).
>  My calls run about 65kbps.
>
> The pain point is something you've already mentioned - roaming.  If at
> any time you roam from wifi to cell and there is no VoLTE service in
> your area, the call dies.  We apparently don't have VoLTE in
> Chattanooga, TN.  If I stay in my office I can usually hold a call,
> and roaming from AP to AP is sometimes ok.  Sometimes the roam between
> APs is enough to drop the call.  I've also noticed that if I get more
> than 2 cell bars, the phone will want to go off of wifi calling on its
> own.  Even at home where I only have 1 AP and can be sitting 15 feet
> from it, I'll drop calls because my phone decided to roam back to cell
> during a live call.
>
> To directly answer your questions:
> 1. I don't plan on doing anything special.  We have enough free
> bandwidth to handle a large number of 65kbps calls.
> 2. Mine have been 65kbps or there about.
> 3. We run both frequencies, but my phone tends to stay 5ghz.  I don't
> think we would change anything to support wifi calling.
> 4. I'm not sure how we will get this across other than to let our
> helpdesk know what to tell people when they call in about it.  We'll
> be looking into this more I'm sure.
> 5. I'm a little surprised that carriers are being allowed to run calls
> over end user networks.  911 is a big deal, and if our wifi is up
> enough that the phone can do wifi calling, but there are issues going
> on to prevent calls, who gets blamed here?  In an emergency, it's too
> much to troubleshoot what's going on and figure out that you have to
> cut off your wireless to get a call through.  As far as I know,
> there's nothing we have to do in terms of uptime or anything.
>
> -Christopher
>
>> On Oct 16, 2015, at 2:14 PM, Smith, Todd > > wrote:
>>
>> Hello,
>>
>> Yesterday, a regional VP for AT Wireless told my Enterprise
>> Architect and CIO that AT was not interested in pursuing a
>> distributed antenna system with us and made it clear that they would
>> not be moving forward with any DAS in the future.  In seems, that
>> Wi-Fi calling is the moving forward strategy for AT for poor
>> cellular signal and presumably other carriers.  I wasn’t in the
>> meeting but I am confident that it has been reported accurately.
>>
>> Does this sound like anything that anyone else has heard?  If so, how
>> are other institutions handling this?  It seems silly that our
>> 

Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

[Jon Scot Prunckle]

Frans,


Thank you for the very enlightening email!


Our university is on the periphery of VoIP.  WiFi calling is going to have an 
interesting impact on our network.  Our 5GHz "coverage" low-end threshold is 
-65 dBm.  We may see an uptick in trouble reports.


This information will be valuable for improving our user experience!


Thank you again!


Sincerely,


J. Scot Prunckle



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Frans Panken 

Sent: Friday, October 16, 2015 3:35 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

You need at least -62db RF-plan to roam between APs without loosing a call. 
Some devices are more picky than others (iphone 5c and higher give less 
problems). I observed that the scanning time of Android is often too high which 
makes roaming a bad user experience (but I have not tested the latest versions).

If you have no QoS and you are surrounded by many clients, you will experience 
problems in your call (either on the listening side or on the speaking side or 
on both sides). Not because of the bandwith requirements for a call but mainly 
because of the high sampling rate of VoIP and the jitter caused by 
retransmissions and the exponential back-off of the Wi-Fi protocol. This may 
result in dropping the call. The bandwidth requirements per call depend on the 
codec used. The traditional G711 codec results in a 64kbit/s connection whereas 
G729 is only 8 kbit/s. Skype uses a SILK codec, using between 6 and 40 kbit/s. 
Note, this is at the application layer. As a result of the overhead and 
inefficiency of the Wi-Fi protocol, the data rate on the Wi-Fi layer is much 
higher!
5Ghz is (much) better suitable for VoIP than 2,4Ghz. Especially with high 
number of active clients per AP.

The downsize I experience from Wi-Fi calling on a smartphone is that all phones 
give priority to incomming 2G/3G/4G calls. No matter what device or app you 
use, your Wi-Fi calls drops if a person tries to reach you via the cellular 
network. But that won't bother you if your indoor reach is poor.

I am surprised that mobile carriers in the US allow end-user networks in their 
VoIP communication path. That is unusual in the Netherlands (where we have less 
need for Wi-Fi calling as we have sound coverage and carriers are not offering 
Wi-Fi calling and will gladly install DAS instead in the case of bad indoor 
coverage which happens often as a result of e.g., foil on windows or because 
carriers move 2G/3G voice to high frequencies which penetrate badly through 
walls and windows).

-Frans


Op 16/10/15 om 21:34 schreef Howard, Christopher:
I'm honestly not surprised to hear that they are going to push wifi calling and 
nothing else.  They want to drop all cellular service other than data, long 
term, in my opinion.

I have AT myself, and ran the iOS 9 beta from the beginning, which got me 
early access to AT wifi calling.  Needless to say, it has not been a pleasant 
experience.  Calls drop all the time.

For our wireless we have not had to do anything.  Calls just work without 
opening inbound ports (we don't limit much going outbound).  My calls run about 
65kbps.

The pain point is something you've already mentioned - roaming.  If at any time 
you roam from wifi to cell and there is no VoLTE service in your area, the call 
dies.  We apparently don't have VoLTE in Chattanooga, TN.  If I stay in my 
office I can usually hold a call, and roaming from AP to AP is sometimes ok.  
Sometimes the roam between APs is enough to drop the call.  I've also noticed 
that if I get more than 2 cell bars, the phone will want to go off of wifi 
calling on its own.  Even at home where I only have 1 AP and can be sitting 15 
feet from it, I'll drop calls because my phone decided to roam back to cell 
during a live call.

To directly answer your questions:
1. I don't plan on doing anything special.  We have enough free bandwidth to 
handle a large number of 65kbps calls.
2. Mine have been 65kbps or there about.
3. We run both frequencies, but my phone tends to stay 5ghz.  I don't think we 
would change anything to support wifi calling.
4. I'm not sure how we will get this across other than to let our helpdesk know 
what to tell people when they call in about it.  We'll be looking into this 
more I'm sure.
5. I'm a little surprised that carriers are being allowed to run calls over end 
user networks.  911 is a big deal, and if our wifi is up enough that the phone 
can do wifi calling, but there are issues going on to prevent calls, who gets 
blamed here?  In an emergency, it's too much to troubleshoot what's going on 
and figure out that you have to cut off your wireless to get a call through.  
As far as I know, there's nothing we have to do in terms of uptime or anything.

-Christopher

On Oct 16, 2015, at 2:14 PM, Smith, Todd 

Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

[Kevin McCormick]

WiFi calling is the future, some companies (Republic Wireless, Project 
Fi) are already there.


We do not have QoS setup on wireless. Best effort works well for me when 
making calls during the day over WiFi with my Republic Wireless service. 
Although we do have dense 802.11ac wifi in the building where I work.


Basically calls are made over WiFi when available and Republic with 
switch the call to Cell if WiFi signal degrades or is unavailable. I do 
not feel we as an institution need to micro manage all the different 
data types and services that uses our network. I do not think we need to 
worry about to having extra equipment, links to support calling, nor be 
responsible for cellular infrastructure.


Kevin McCormick
Western Illinois University



On 10/16/2015 1:14 PM, Smith, Todd wrote:

Hello,

Yesterday, a regional VP for AT Wireless told my Enterprise Architect and CIO that 
AT was not interested in pursuing a distributed antenna system with us and made it 
clear that they would not be moving forward with any DAS in the future.  In seems, that 
Wi-Fi calling is the moving forward strategy for AT for poor cellular signal and 
presumably other carriers.  I wasn’t in the meeting but I am confident that it has been 
reported accurately.

Does this sound like anything that anyone else has heard?  If so, how are other 
institutions handling this?  It seems silly that our organization which is in 
the planning stages for a Wi-Fi wireless upgrade anyway would build in the 
necessary upgrades to accumulate cell carrier backhaul traffic for no 
compensation whatsoever.

As usual, my job is to do or die, so I am trying to see what others might have 
done and if possible start a line of discussion to reason out the best way to 
handle poor cellular coverage in both older buildings as well as brand new 
LEEDS certified buildings.

1)  Would you create a new SSID for cellular traffic with QoS enabled and 
open to the Internet with UDP 500 and 4500 open as well as more normal ports?
2)  I can’t find any solid reference that details exactly how much 
bandwidth per call.  I have literally read in the last couple of hours, 
everything from 2.5Kbps to 1Mbps to a general consensus from 60-128Kbps per 
call.
3)  2.4Ghz or 5Ghz or both?
4)  Much of the discussion of seamless handover from cell to Wi-Fi involved 
HD Voice which seems to be provisioned as part of VoLTE and only available in 
some areas; i.e. not my coverage area.  How to communicate to your normal users 
and any public that uses your Wi-Fi that when they switch between platforms; 
the call will be dropped?
5)  Would we be responsible for maintaining redundant Internet connections 
just to support cell calls?  Is there any requirement that would state that 
since we are providing cellular infrastructure that we are responsible for a 
certain minimum SLA?

Is there any other questions or comments to think about?

Todd





==

CONFIDENTIALITY NOTICE: The information contained in this
message may
be privileged and confidential. If this e-mail contains protected
health information, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited,
except as permitted by law. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting it from your computer. Thank you.



**
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] How to handle Wi-Fi Calling?

[Jason Watts]

Can anyone point to a good technical doc or whitepaper that describes 
how this is supposed to work with IOS9 for instance?


 * Is IOS9 or carrier code determining when/if wifi calling is possible?
 * How is a wireless carrier who's chief business is to operate a
   wireless network and sell access to it able to offload traffic to
   random networks and still sell that service to customers without the
   explicit cooperation of the operators of those random networks?
 * Do these "wifi" minutes get charged to customers? SMS?
 * To echo what Christopher said, what about 911 etc, who is
   responsible for call quality and completion?
 * What about geolocation and emergency, does the wifi enhance it or
   obsfucate it in any way?

It's getting pretty murky out there!



On 10/16/2015 3:34 PM, Howard, Christopher wrote:
I'm honestly not surprised to hear that they are going to push wifi 
calling and nothing else.  They want to drop all cellular service 
other than data, long term, in my opinion.


I have AT myself, and ran the iOS 9 beta from the beginning, which 
got me early access to AT wifi calling.  Needless to say, it has not 
been a pleasant experience.  Calls drop all the time.


For our wireless we have not had to do anything.  Calls just work 
without opening inbound ports (we don't limit much going outbound). 
 My calls run about 65kbps.


The pain point is something you've already mentioned - roaming.  If at 
any time you roam from wifi to cell and there is no VoLTE service in 
your area, the call dies.  We apparently don't have VoLTE in 
Chattanooga, TN.  If I stay in my office I can usually hold a call, 
and roaming from AP to AP is sometimes ok.  Sometimes the roam between 
APs is enough to drop the call.  I've also noticed that if I get more 
than 2 cell bars, the phone will want to go off of wifi calling on its 
own.  Even at home where I only have 1 AP and can be sitting 15 feet 
from it, I'll drop calls because my phone decided to roam back to cell 
during a live call.


To directly answer your questions:
1. I don't plan on doing anything special.  We have enough free 
bandwidth to handle a large number of 65kbps calls.

2. Mine have been 65kbps or there about.
3. We run both frequencies, but my phone tends to stay 5ghz.  I don't 
think we would change anything to support wifi calling.
4. I'm not sure how we will get this across other than to let our 
helpdesk know what to tell people when they call in about it.  We'll 
be looking into this more I'm sure.
5. I'm a little surprised that carriers are being allowed to run calls 
over end user networks.  911 is a big deal, and if our wifi is up 
enough that the phone can do wifi calling, but there are issues going 
on to prevent calls, who gets blamed here?  In an emergency, it's too 
much to troubleshoot what's going on and figure out that you have to 
cut off your wireless to get a call through.  As far as I know, 
there's nothing we have to do in terms of uptime or anything.


-Christopher

On Oct 16, 2015, at 2:14 PM, Smith, Todd > wrote:


Hello,

Yesterday, a regional VP for AT Wireless told my Enterprise 
Architect and CIO that AT was not interested in pursuing a 
distributed antenna system with us and made it clear that they would 
not be moving forward with any DAS in the future.  In seems, that 
Wi-Fi calling is the moving forward strategy for AT for poor 
cellular signal and presumably other carriers.  I wasn’t in the 
meeting but I am confident that it has been reported accurately.


Does this sound like anything that anyone else has heard?  If so, how 
are other institutions handling this?  It seems silly that our 
organization which is in the planning stages for a Wi-Fi wireless 
upgrade anyway would build in the necessary upgrades to accumulate 
cell carrier backhaul traffic for no compensation whatsoever.


As usual, my job is to do or die, so I am trying to see what others 
might have done and if possible start a line of discussion to reason 
out the best way to handle poor cellular coverage in both older 
buildings as well as brand new LEEDS certified buildings.


1)  Would you create a new SSID for cellular traffic with QoS 
enabled and open to the Internet with UDP 500 and 4500 open as well 
as more normal ports?
2)  I can’t find any solid reference that details exactly how 
much bandwidth per call.  I have literally read in the last couple of 
hours, everything from 2.5Kbps to 1Mbps to a general consensus from 
60-128Kbps per call.

3)  2.4Ghz or 5Ghz or both?
4)  Much of the discussion of seamless handover from cell to 
Wi-Fi involved HD Voice which seems to be provisioned as part of 
VoLTE and only available in some areas; i.e. not my coverage area. 
 How to communicate to your normal users and any public that uses 
your Wi-Fi that when they switch between platforms; the call will be 
dropped?
5)  Would we be responsible for maintaining redundant 

RE: [WIRELESS-LAN] How to handle Wi-Fi Calling?

[Smith, Todd]

Christopher,

Those are some great answers and I apperciate the input!  

1) Has the call drop percentage improved as the service is maturing?
2) 65Kbps is much better then I was expecting, so that it good.  Do you notice 
many spikes in bandwidth as the call is in progress?
3) Do you have a splash page or captive portal on your open wireless?  Does 
that interfere with AT Wi-Fi calling in your experience?
4) I agree that E911 is going to be a serious issue.  On AT Wi-Fi calling 
FAQ, the user has to specify a location that they would normally be using Wi-Fi 
Calling for E911 purposes.  It is also going to try to get location information 
from the Wi-Fi networks to locate the call, but it will default back to stored 
location as a last result.

Thanks

Todd



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Howard, Christopher 
[christopher-how...@utc.edu]
Sent: Friday, October 16, 2015 3:34 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?


I'm honestly not surprised to hear that they are going to push wifi calling and 
nothing else.  They want to drop all cellular service other than data, long 
term, in my opinion. 


I have AT myself, and ran the iOS 9 beta from the beginning, which got me 
early access to AT wifi calling.  Needless to say, it has not been a pleasant 
experience.  Calls drop all the time.


For our wireless we have not had to do anything.  Calls just work without 
opening inbound ports (we don't limit much going outbound).  My calls run about 
65kbps.


The pain point is something you've already mentioned - roaming.  If at any time 
you roam from wifi to cell and there is no VoLTE service in your area, the call 
dies.  We apparently don't have VoLTE in Chattanooga, TN.  If I stay in my 
office I can usually hold a call, and roaming from AP to AP is sometimes ok.  
Sometimes the roam between APs is enough to drop the call.  I've also noticed 
that if I get more than 2 cell bars, the phone will want to go off of wifi 
calling on its own.  Even at home where I only have 1 AP and can be sitting 15 
feet from it, I'll drop calls because my phone decided to roam back to cell 
during a live call.


To directly answer your questions:
1. I don't plan on doing anything special.  We have enough free bandwidth to 
handle a large number of 65kbps calls.
2. Mine have been 65kbps or there about.
3. We run both frequencies, but my phone tends to stay 5ghz.  I don't think we 
would change anything to support wifi calling.
4. I'm not sure how we will get this across other than to let our helpdesk know 
what to tell people when they call in about it.  We'll be looking into this 
more I'm sure.
5. I'm a little surprised that carriers are being allowed to run calls over end 
user networks.  911 is a big deal, and if our wifi is up enough that the phone 
can do wifi calling, but there are issues going on to prevent calls, who gets 
blamed here?  In an emergency, it's too much to troubleshoot what's going on 
and figure out that you have to cut off your wireless to get a call through.  
As far as I know, there's nothing we have to do in terms of uptime or anything.

-Christopher 

==

CONFIDENTIALITY NOTICE: The information contained in this
message may
be privileged and confidential. If this e-mail contains protected
health information, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited,
except as permitted by law. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting it from your computer. Thank you.

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

Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

[Howard, Christopher]

I don't see that the service has improved all that much.  I'm still running the 
beta program, so I'm currently on iOS 9.1 beta 5 I think.  However, I don't 
really do calls a whole lot.  It's been a few days according to the call log.

I can only watch the bandwidth usage when I'm on the phone at my desk.  It 
tends to start in the low 40kbps area and climb up from there.  I've not seen 
one hit triple digits yet.

We do have a captive portal and honestly I've not tried wifi calling when stuck 
in there yet.  If it uses DNS it will break at this point in time, but if they 
have a list of hard coded IP address in the phone software it will still work.  
Our captive portal is strictly DNS smoke and mirrors.

Now that you mention it, I do remember it asking for an address and giving me a 
warning in ALL CAPS for 911.

-Christopher

On Oct 16, 2015, at 3:50 PM, Smith, Todd 
> wrote:

Christopher,

Those are some great answers and I apperciate the input!

1) Has the call drop percentage improved as the service is maturing?
2) 65Kbps is much better then I was expecting, so that it good.  Do you notice 
many spikes in bandwidth as the call is in progress?
3) Do you have a splash page or captive portal on your open wireless?  Does 
that interfere with AT Wi-Fi calling in your experience?
4) I agree that E911 is going to be a serious issue.  On AT Wi-Fi calling 
FAQ, the user has to specify a location that they would normally be using Wi-Fi 
Calling for E911 purposes.  It is also going to try to get location information 
from the Wi-Fi networks to locate the call, but it will default back to stored 
location as a last result.

Thanks

Todd



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] 
On Behalf Of Howard, Christopher 
[christopher-how...@utc.edu]
Sent: Friday, October 16, 2015 3:34 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?


I'm honestly not surprised to hear that they are going to push wifi calling and 
nothing else.  They want to drop all cellular service other than data, long 
term, in my opinion.


I have AT myself, and ran the iOS 9 beta from the beginning, which got me 
early access to AT wifi calling.  Needless to say, it has not been a pleasant 
experience.  Calls drop all the time.


For our wireless we have not had to do anything.  Calls just work without 
opening inbound ports (we don't limit much going outbound).  My calls run about 
65kbps.


The pain point is something you've already mentioned - roaming.  If at any time 
you roam from wifi to cell and there is no VoLTE service in your area, the call 
dies.  We apparently don't have VoLTE in Chattanooga, TN.  If I stay in my 
office I can usually hold a call, and roaming from AP to AP is sometimes ok.  
Sometimes the roam between APs is enough to drop the call.  I've also noticed 
that if I get more than 2 cell bars, the phone will want to go off of wifi 
calling on its own.  Even at home where I only have 1 AP and can be sitting 15 
feet from it, I'll drop calls because my phone decided to roam back to cell 
during a live call.


To directly answer your questions:
1. I don't plan on doing anything special.  We have enough free bandwidth to 
handle a large number of 65kbps calls.
2. Mine have been 65kbps or there about.
3. We run both frequencies, but my phone tends to stay 5ghz.  I don't think we 
would change anything to support wifi calling.
4. I'm not sure how we will get this across other than to let our helpdesk know 
what to tell people when they call in about it.  We'll be looking into this 
more I'm sure.
5. I'm a little surprised that carriers are being allowed to run calls over end 
user networks.  911 is a big deal, and if our wifi is up enough that the phone 
can do wifi calling, but there are issues going on to prevent calls, who gets 
blamed here?  In an emergency, it's too much to troubleshoot what's going on 
and figure out that you have to cut off your wireless to get a call through.  
As far as I know, there's nothing we have to do in terms of uptime or anything.

-Christopher

==

CONFIDENTIALITY NOTICE: The information contained in this
message may
be privileged and confidential. If this e-mail contains protected
health information, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited,
except as permitted by law. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting it from your computer. Thank you.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at 

RE: [WIRELESS-LAN] How to handle Wi-Fi Calling?

[Smith, Todd]

Jason,

Did you have some feedback?  Your message came through without any text.

Todd


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jason Watts [jwa...@pratt.edu]
Sent: Friday, October 16, 2015 3:51 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

todd.sm...@camc.org> wrote:

Hello,

Yesterday, a regional VP for AT Wireless told my Enterprise Architect and CIO 
that AT was not interested in pursuing a distributed antenna system with us 
and made it clear that they would not be moving forward with any DAS in the 
future.  In seems, that Wi-Fi calling is the moving forward strategy for AT 
for poor cellular signal and presumably other carriers.  I wasn’t in the 
meeting but I am confident that it has been reported accurately.

Does this sound like anything that anyone else has heard?  If so, how are other 
institutions handling this?  It seems silly that our organization which is in 
the planning stages for a Wi-Fi wireless upgrade anyway would build in the 
necessary upgrades to accumulate cell carrier backhaul traffic for no 
compensation whatsoever.

As usual, my job is to do or die, so I am trying to see what others might have 
done and if possible start a line of discussion to reason out the best way to 
handle poor cellular coverage in both older buildings as well as brand new 
LEEDS certified buildings.

1)  Would you create a new SSID for cellular traffic with QoS enabled and 
open to the Internet with UDP 500 and 4500 open as well as more normal ports?
2)  I can’t find any solid reference that details exactly how much 
bandwidth per call.  I have literally read in the last couple of hours, 
everything from 2.5Kbps to 1Mbps to a general consensus from 60-128Kbps per 
call.
3)  2.4Ghz or 5Ghz or both?
4)  Much of the discussion of seamless handover from cell to Wi-Fi involved 
HD Voice which seems to be provisioned as part of VoLTE and only available in 
some areas; i.e. not my coverage area.  How to communicate to your normal users 
and any public that uses your Wi-Fi that when they switch between platforms; 
the call will be dropped?
5)  Would we be responsible for maintaining redundant Internet connections 
just to support cell calls?  Is there any requirement that would state that 
since we are providing cellular infrastructure that we are responsible for a 
certain minimum SLA?

Is there any other questions or comments to think about?

Todd





==

CONFIDENTIALITY NOTICE: The information contained in this
message may
be privileged and confidential. If this e-mail contains protected
health information, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited,
except as permitted by law. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting it from your computer. Thank you.



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

--
Jason Watts | Senior Network Administrator
H1
PRATT INSTITUTE
Academic Computing


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

==

CONFIDENTIALITY NOTICE: The information contained in this
message may
be privileged and confidential. If this e-mail contains protected
health 

Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

[Hunter Fuller]

This thread prompted me to take a look at my phone's Wi-Fi calling
settings. (I have T-Mobile.) It also asked me for an E911 address.

This terrifies me.

What are the chances that I will be calling 911 from home, as compared to
some other random place where I might have Wi-Fi?...



--
Hunter Fuller
Network Engineer
VBRH Annex B-1
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Systems and Infrastructure

On Fri, Oct 16, 2015 at 2:50 PM, Smith, Todd  wrote:

> Christopher,
>
> Those are some great answers and I apperciate the input!
>
> 1) Has the call drop percentage improved as the service is maturing?
> 2) 65Kbps is much better then I was expecting, so that it good.  Do you
> notice many spikes in bandwidth as the call is in progress?
> 3) Do you have a splash page or captive portal on your open wireless?
> Does that interfere with AT Wi-Fi calling in your experience?
> 4) I agree that E911 is going to be a serious issue.  On AT Wi-Fi
> calling FAQ, the user has to specify a location that they would normally be
> using Wi-Fi Calling for E911 purposes.  It is also going to try to get
> location information from the Wi-Fi networks to locate the call, but it
> will default back to stored location as a last result.
>
> Thanks
>
> Todd
>
>
>
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Howard, Christopher [
> christopher-how...@utc.edu]
> Sent: Friday, October 16, 2015 3:34 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?
>
>
> I'm honestly not surprised to hear that they are going to push wifi
> calling and nothing else.  They want to drop all cellular service other
> than data, long term, in my opinion.
>
>
> I have AT myself, and ran the iOS 9 beta from the beginning, which got
> me early access to AT wifi calling.  Needless to say, it has not been a
> pleasant experience.  Calls drop all the time.
>
>
> For our wireless we have not had to do anything.  Calls just work without
> opening inbound ports (we don't limit much going outbound).  My calls run
> about 65kbps.
>
>
> The pain point is something you've already mentioned - roaming.  If at any
> time you roam from wifi to cell and there is no VoLTE service in your area,
> the call dies.  We apparently don't have VoLTE in Chattanooga, TN.  If I
> stay in my office I can usually hold a call, and roaming from AP to AP is
> sometimes ok.  Sometimes the roam between APs is enough to drop the call.
> I've also noticed that if I get more than 2 cell bars, the phone will want
> to go off of wifi calling on its own.  Even at home where I only have 1 AP
> and can be sitting 15 feet from it, I'll drop calls because my phone
> decided to roam back to cell during a live call.
>
>
> To directly answer your questions:
> 1. I don't plan on doing anything special.  We have enough free bandwidth
> to handle a large number of 65kbps calls.
> 2. Mine have been 65kbps or there about.
> 3. We run both frequencies, but my phone tends to stay 5ghz.  I don't
> think we would change anything to support wifi calling.
> 4. I'm not sure how we will get this across other than to let our helpdesk
> know what to tell people when they call in about it.  We'll be looking into
> this more I'm sure.
> 5. I'm a little surprised that carriers are being allowed to run calls
> over end user networks.  911 is a big deal, and if our wifi is up enough
> that the phone can do wifi calling, but there are issues going on to
> prevent calls, who gets blamed here?  In an emergency, it's too much to
> troubleshoot what's going on and figure out that you have to cut off your
> wireless to get a call through.  As far as I know, there's nothing we have
> to do in terms of uptime or anything.
>
> -Christopher
>
> ==
>
> CONFIDENTIALITY NOTICE: The information contained in this
> message may
> be privileged and confidential. If this e-mail contains protected
> health information, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited,
> except as permitted by law. If you have received this communication in
> error, please notify the sender immediately by replying to this message
> and deleting it from your computer. Thank you.
>
> **
> 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] How to handle Wi-Fi Calling?

[Smith, Todd]

Christopher,

If you get a chance, can you test the call from your captive portal and see 
what happens?  Don't make any heroic effeorts, but I would be very curious to 
see what happens.

Todd


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Howard, Christopher 
[christopher-how...@utc.edu]
Sent: Friday, October 16, 2015 4:03 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

I don't see that the service has improved all that much.  I'm still running the 
beta program, so I'm currently on iOS 9.1 beta 5 I think.  However, I don't 
really do calls a whole lot.  It's been a few days according to the call log.

I can only watch the bandwidth usage when I'm on the phone at my desk.  It 
tends to start in the low 40kbps area and climb up from there.  I've not seen 
one hit triple digits yet.

We do have a captive portal and honestly I've not tried wifi calling when stuck 
in there yet.  If it uses DNS it will break at this point in time, but if they 
have a list of hard coded IP address in the phone software it will still work.  
Our captive portal is strictly DNS smoke and mirrors.

Now that you mention it, I do remember it asking for an address and giving me a 
warning in ALL CAPS for 911.

-Christopher


==

CONFIDENTIALITY NOTICE: The information contained in this
message may
be privileged and confidential. If this e-mail contains protected
health information, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited,
except as permitted by law. If you have received this communication in
error, please notify the sender immediately by replying to this message
and deleting it from your computer. Thank you.

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

RE: [WIRELESS-LAN] How to handle Wi-Fi Calling?

[Smith, Todd]

Thanks to Hunter Fuller who relayed Jason's questions.

I have been piecing together information from muliple sources and there isn't a 
whitepaper that I have found yet.

1) For AT, it is only 4 phones usable for Wi-Fi calling and it has be 
configured by the phone as well as a correct service plan.
2) I don't know, but it is not something that I am happy.
3) Call minutes, No.  SMS are billed according to user's plan.
4) I don't know, but I hate that fact that it looks like our organization is 
going to on the hook for something.

Todd


From: Hunter Fuller [hf0...@uah.edu]
Sent: Friday, October 16, 2015 3:53 PM
To: Smith, Todd
Subject: Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

Todd,

Jason wrote:

Can anyone point to a good technical doc or whitepaper that describes how this 
is supposed to work with IOS9 for instance?


 *   Is IOS9 or carrier code determining when/if wifi calling is possible?
 *   How is a wireless carrier who's chief business is to operate a wireless 
network and sell access to it able to offload traffic to random networks and 
still sell that service to customers without the explicit cooperation of the 
operators of those random networks?
 *   Do these "wifi" minutes get charged to customers? SMS?
 *   To echo what Christopher said, what about 911 etc, who is responsible for 
call quality and completion?
 *   What about geolocation and emergency, does the wifi enhance it or 
obsfucate it in any way?

It's getting pretty murky out there!


--
Hunter Fuller
Network Engineer
VBRH Annex B-1
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Systems and Infrastructure

On Fri, Oct 16, 2015 at 2:51 PM, Smith, Todd 
> wrote:
Jason,

Did you have some feedback?  Your message came through without any text.

Todd


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] 
On Behalf Of Jason Watts [jwa...@pratt.edu]
Sent: Friday, October 16, 2015 3:51 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] How to handle Wi-Fi Calling?

todd.sm...@camc.org>>
 wrote:

Hello,

Yesterday, a regional VP for AT Wireless told my Enterprise Architect and CIO 
that AT was not interested in pursuing a distributed antenna system with us 
and made it clear that they would not be moving forward with any DAS in the 
future.  In seems, that Wi-Fi calling is the moving forward strategy for AT 
for poor cellular signal and presumably other carriers.  I wasn’t in the 
meeting but I am confident that it has been reported accurately.

Does this sound like anything that anyone else has heard?  If so, how are other 
institutions handling this?  It seems silly that our organization which is in 
the planning stages for a Wi-Fi wireless upgrade anyway would build in the 
necessary upgrades to accumulate cell carrier backhaul traffic for no 
compensation whatsoever.

As usual, my job is to do or die, so I am trying to see what others might have 
done and if possible start a line of discussion to reason out the best way to 
handle poor cellular coverage in both older buildings as well as brand new 
LEEDS certified buildings.

1)  Would you create a new SSID for cellular traffic with QoS enabled and 
open to the Internet with UDP 500 and 4500 open as well as more normal ports?
2)  I can’t find any solid reference that details exactly how much 
bandwidth per call.  I have literally read in the last couple of hours, 
everything from 2.5Kbps to 1Mbps to a general consensus from 60-128Kbps per 
call.
3)  2.4Ghz or 5Ghz or both?
4)  Much of the discussion of seamless handover from cell to Wi-Fi involved 
HD Voice which seems to be provisioned as part of VoLTE and only available in 
some areas; i.e. not my coverage area.  How to communicate to your normal users 
and any public that uses your Wi-Fi that when they switch between platforms; 
the call will be dropped?
5)  Would we be responsible for maintaining redundant Internet connections 
just to support cell calls?  Is there any requirement that would state that 
since we are providing cellular infrastructure that we are responsible for a 
certain minimum SLA?

Is there any other questions or comments to think about?

Todd





==

CONFIDENTIALITY NOTICE: The information contained in this
message may
be privileged and confidential. If this e-mail contains protected
health information, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited,
except as permitted by law. If you have received this communication in
error, please 

Re: [WIRELESS-LAN] Multi Vendor environments in WiFi space

[Oliver Elliott]

Jeff

How did you achieve that discount, was it a significant bulk order? We tend
to buy large amounts of switches and APs separately, if we can save a lot
of money buying them together that would be nice!

Oli

On 15 October 2015 at 19:15, Jeffrey D. Sessler 
wrote:

> I think it's always wise to look at other vendors when you're about to
> replace that amount of equipment, but unless you are unhappy, it's unlikely
> that the alternative will come out less expensive i.e. hardware purchase,
> plus learning/supporting another vendor.
>
> If you're happy, work with your incumbent vendor to see what they'll do to
> keep you in the family.
>
> For Cisco, right now there is a deal where you can get substantial
> additional discounts on wireless if it's paired with switching (which also
> gets extra discounts), and these stack on top of the discount you get
> normally. Let's just say that 70%-ish off is not difficult. I took
> advantage of the discount last year and the cost for a 3702i was pretty
> amazing.
>
> Jeff
>
>
> -Original Message-
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Oliver, Jeff
> Sent: Thursday, October 15, 2015 9:42 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: [WIRELESS-LAN] Multi Vendor environments in WiFi space
>
> All,
>
> This is probably an old topic, but I have not seen anything in a while on
> it.
>
> At present we are a Cisco shop with regard to our wireless deployment, and
> we are looking at changing out a substantial number (250) of our AP's (1131
> to 3702). These AP's represent about 30% of our deployment so is a
> substantial investment, and as such our CIO has asked us to look at other
> solutions.
>
> I am wondering if any of you are running multi vendor environments and if
> so, what the UX is like? What are the toolsets like regarding management of
> two disparate systems?
>
>
>
> Cheers,
> Jeff
>
> ---
>
> Jeffrey L. Oliver
> Sr. Network Analyst
> Information Technology Services
> The University of Lethbridge
> 4401 University Drive, Lethbridge, Alberta, T1K 3M4
>
> Tel:403.329.5162
> Mob:403.315.4461
> Fax:403.382.7108
>
> URI:jeff.oli...@uleth.ca
>
> **
> 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/.
>
>


-- 
Oliver Elliott
Senior Network Specialist
IT Services
University of Bristol
e: oliver.elli...@bristol.ac.uk
t: 0117 39 (41131)

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

Re: [WIRELESS-LAN] Measuring RADIUS Auths

[Walter Reynolds]

Since you mention in the thread that you have Cisco with Freeradius
backend, I thought I would point out that if you are doing PEAP/MSChapv2
that the bottleneck is winbind/samba and that it is based on auth's per
second, not purely auth request that show up in total request.

That being said, our heaviest loaded Freeradius box seems to be hitting max
and we have hit as high as 150 auths/sec with an average of 80/sec over a
minute window.

Stand alone Two processor Quad core Intel Xeon X5570  @ 2.93GHz with 6Gb ram

A VM single Quad core with 8Gb ram seems to be peaking at 80/sec with a one
minute avg of 60/sec



Walter Reynolds
Principal Systems Security Development Engineer
Information and Technology Services
University of Michigan
(734) 615-9438

On Thu, Oct 15, 2015 at 5:08 PM, Charles Rumford 
wrote:

> I’m currently embarking on a project to determine the number of RADIUS
> auths per minute each one of my controllers is generating to plan for the
> capacity I need for my RADIUS servers.
>
> I was curious if anyone has embarked on a similar journey and tried to
> measure auth rates coming from their controllers?
>
> I have a couple of ideas that I’m up for sharing, but I wanted to see if
> anyone else has done this.
>
> Thanks!
>
> 
> Charles Rumford
> Network Engineer/Senior Wireless Engineer
> ISC Network Operations
> University of Pennsylvania
> OpenPGP Key ID: 0xF3D8215A
> (p) 215-746-2808
>
>
> **
> 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] Measuring RADIUS Auths

[Ciesinski, Nick]

This is the access key  AV3Q6TQB  I can’t add you for some reason.  Did you ID 
change in CCW?

Nick
On Oct 16, 2015, at 10:11 AM, Walter Reynolds 
> wrote:

Since you mention in the thread that you have Cisco with Freeradius backend, I 
thought I would point out that if you are doing PEAP/MSChapv2 that the 
bottleneck is winbind/samba and that it is based on auth's per second, not 
purely auth request that show up in total request.

That being said, our heaviest loaded Freeradius box seems to be hitting max and 
we have hit as high as 150 auths/sec with an average of 80/sec over a minute 
window.

Stand alone Two processor Quad core Intel Xeon X5570  @ 2.93GHz with 6Gb ram

A VM single Quad core with 8Gb ram seems to be peaking at 80/sec with a one 
minute avg of 60/sec



Walter Reynolds
Principal Systems Security Development Engineer
Information and Technology Services
University of Michigan
(734) 615-9438

On Thu, Oct 15, 2015 at 5:08 PM, Charles Rumford 
> wrote:
I’m currently embarking on a project to determine the number of RADIUS auths 
per minute each one of my controllers is generating to plan for the capacity I 
need for my RADIUS servers.

I was curious if anyone has embarked on a similar journey and tried to measure 
auth rates coming from their controllers?

I have a couple of ideas that I’m up for sharing, but I wanted to see if anyone 
else has done this.

Thanks!


Charles Rumford
Network Engineer/Senior Wireless Engineer
ISC Network Operations
University of Pennsylvania
OpenPGP Key ID: 0xF3D8215A
(p) 215-746-2808


**
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-LAN] Measuring RADIUS Auths

[Watters, John]

THANKS for posting this.


-jcw
  [UA Logo]

John Watters   The University of Alabama
Office of Information Technology
205-348-3992

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Walter Reynolds
Sent: Friday, October 16, 2015 7:00 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Measuring RADIUS Auths

The script (which was actually created by a co-worker) is run by adding the IP 
address of the WLC and the the SNMP community string.  You will obviously need 
to change the path from  /home/waltr/bin/radiusstats/ to something that works 
for you.  I attached the script and the MIB file

First thing it does is add the date to the output file (output file is the WLC 
IP address appended by .stats)
The join command combines the output of the filtered snmp queries
Next comes the snmptable command.
The tail removes unneeded lines from the query
awk says to give you the columns you need
Second snmptable command
Again tail removes unneeded lines
The sed replaces header with something shorter to better fit on a screen
The column command formats for better readability
Finally we paste the output into the output file.

As far as determining how many Auths overall it is easier to do this on the 
radius server as the cisco stats just keep growing and you would need to run 
this script every minute and then find the difference between the values

With freeradius you can just run something like this to get a second by second 
count

grep "Login OK" /usr/local/var/log/radius/radlog.archive/radius.log-20151016 | 
grep TLS | cut -d " " -f 4 | uniq -c
 12 10:44:59
 16 10:45:00
 18 10:45:01
 21 10:45:02

To get a minute by minute

grep "Login OK" /usr/local/var/log/radius/radlog.archive/radius.log-20151016 | 
grep TLS | cut -d " " -f 4 | cut -d: -f 1,2 | uniq -c
890 10:44
925 10:45




Walter Reynolds
Principal Systems Security Development Engineer
Information and Technology Services
University of Michigan
(734) 615-9438

On Fri, Oct 16, 2015 at 12:46 AM, Watters, John 
<john.watt...@ua.edu<mailto:john.watt...@ua.edu>> wrote:
Please send this stuff out. I would love to use it with our Cisco 8510s and our 
FreeRadius servers.

Thanks.

Sent from my iPhone

> On Oct 15, 2015, at 9:54 PM, Walt Reynolds 
> <wa...@umich.edu<mailto:wa...@umich.edu>> wrote:
>
> We have Cisco controllers and have a script that polls the radius table and 
> then queries the radius stats table to combine the address of the radius 
> servers with their stats.  This is done on a Unix box with snmpwalk and the 
> like.  I will send that out in the morning if you want.
>
> I also did some work and got these same stats into cacti.
>
>
>
> Walter Reynolds
> University of Michigan
>
>> On Oct 15, 2015, at 7:36 PM, Jason Cook 
>> <jason.c...@adelaide.edu.au<mailto:jason.c...@adelaide.edu.au>> wrote:
>>
>> There are some stats on the controllers but we haven't been able to work out 
>> how to poll them via snmp which would be ideal. The other option would be  
>> scripting SSH to run the command and pull the relevant information for 
>> graphing.
>>
>>
>> (Cisco Controller) >show radius auth statistics
>> Authentication Servers:
>>
>> Server Index. 1
>> Server Address... x
>> Msg Round Trip Time.. 0 (msec)
>> First Requests... 0
>> Retry Requests... 0
>> Accept Responses. 0
>> Reject Responses. 0
>> Challenge Responses.. 0
>> Malformed Msgs... 0
>> Bad Authenticator Msgs... 0
>> Pending Requests. 0
>> Timeout Requests. 0
>> Consecutive Drops ... 0
>> Unknowntype Msgs. 0
>> Other Drops.. 0
>>
>>
>> Server Index. 3
>> Server Address... x
>> Msg Round Trip Time.. 66 (msec)
>> First Requests... 2406297
>> Retry Requests... 936
>> Accept Responses...

Re: [WIRELESS-LAN] Multi Vendor environments in WiFi space

[Jeremy Gibbs]

>From my experience, you just have to keep beating up Cisco.  Every time
they say "we can't do lower pricing", don't believe them.  They absolutely
can do lower pricing.  Also make sure you indicate that changing vendors
will mean your following suit with the rest of the hardware when it comes
EOL.  That should make them dig out some deeper discounts.  If they are
unwilling to come down in price to be more competitive, maybe it's a good
time to start moving on to other vendors.

Take a look at Extreme Networks.  They have some great products and usually
beat the pants off of Cisco when it comes to pricing (especially wireless).





*--Jeremy L. Gibbs*
Sr. Network Engineer
Utica College IITS

T: (315) 223-2383
F: (315) 792-3814
E: jlgi...@utica.edu
http://www.utica.edu

On Fri, Oct 16, 2015 at 4:25 AM, Oliver Elliott <
oliver.elli...@bristol.ac.uk> wrote:

> Jeff
>
> How did you achieve that discount, was it a significant bulk order? We
> tend to buy large amounts of switches and APs separately, if we can save a
> lot of money buying them together that would be nice!
>
> Oli
>
> On 15 October 2015 at 19:15, Jeffrey D. Sessler 
> wrote:
>
>> I think it's always wise to look at other vendors when you're about to
>> replace that amount of equipment, but unless you are unhappy, it's unlikely
>> that the alternative will come out less expensive i.e. hardware purchase,
>> plus learning/supporting another vendor.
>>
>> If you're happy, work with your incumbent vendor to see what they'll do
>> to keep you in the family.
>>
>> For Cisco, right now there is a deal where you can get substantial
>> additional discounts on wireless if it's paired with switching (which also
>> gets extra discounts), and these stack on top of the discount you get
>> normally. Let's just say that 70%-ish off is not difficult. I took
>> advantage of the discount last year and the cost for a 3702i was pretty
>> amazing.
>>
>> Jeff
>>
>>
>> -Original Message-
>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Oliver, Jeff
>> Sent: Thursday, October 15, 2015 9:42 AM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: [WIRELESS-LAN] Multi Vendor environments in WiFi space
>>
>> All,
>>
>> This is probably an old topic, but I have not seen anything in a while on
>> it.
>>
>> At present we are a Cisco shop with regard to our wireless deployment,
>> and we are looking at changing out a substantial number (250) of our AP's
>> (1131 to 3702). These AP's represent about 30% of our deployment so is a
>> substantial investment, and as such our CIO has asked us to look at other
>> solutions.
>>
>> I am wondering if any of you are running multi vendor environments and if
>> so, what the UX is like? What are the toolsets like regarding management of
>> two disparate systems?
>>
>>
>>
>> Cheers,
>> Jeff
>>
>> ---
>>
>> Jeffrey L. Oliver
>> Sr. Network Analyst
>> Information Technology Services
>> The University of Lethbridge
>> 4401 University Drive, Lethbridge, Alberta, T1K 3M4
>>
>> Tel:403.329.5162
>> Mob:403.315.4461
>> Fax:403.382.7108
>>
>> URI:jeff.oli...@uleth.ca
>>
>> **
>> 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/.
>>
>>
>
>
> --
> Oliver Elliott
> Senior Network Specialist
> IT Services
> University of Bristol
> e: oliver.elli...@bristol.ac.uk
> t: 0117 39 (41131)
> ** 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] Measuring RADIUS Auths

[Mattson III, Ken V.]

We poll our controllers directly.

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?objectInput=1.3.6.1.4.1.14179.2.5.3.1.7=Translate=SUBMIT=true

We use the following OIDs:

1.3.6.1.4.1.14179.2.5.3.1.7.3&1.3.6.1.4.1.14179.2.5.3.1.8.3

And graph them here:

http://mrtg.creighton.edu/WiSM/WiSM_Radius_Statistics.html



Kenneth V. Mattson III
Director - Network and Data
DoIT
Creighton University
402-280-2743
402-981-1140

A password is like a toothbrush:
Choose a good one, change it regularly and don't share it.

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ciesinski, Nick
Sent: Friday, October 16, 2015 10:20 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Measuring RADIUS Auths

This is the access key  AV3Q6TQB  I can’t add you for some reason.  Did you ID 
change in CCW?

Nick
On Oct 16, 2015, at 10:11 AM, Walter Reynolds 
> wrote:

Since you mention in the thread that you have Cisco with Freeradius backend, I 
thought I would point out that if you are doing PEAP/MSChapv2 that the 
bottleneck is winbind/samba and that it is based on auth's per second, not 
purely auth request that show up in total request.

That being said, our heaviest loaded Freeradius box seems to be hitting max and 
we have hit as high as 150 auths/sec with an average of 80/sec over a minute 
window.

Stand alone Two processor Quad core Intel Xeon X5570  @ 2.93GHz with 6Gb ram

A VM single Quad core with 8Gb ram seems to be peaking at 80/sec with a one 
minute avg of 60/sec



Walter Reynolds
Principal Systems Security Development Engineer
Information and Technology Services
University of Michigan
(734) 615-9438

On Thu, Oct 15, 2015 at 5:08 PM, Charles Rumford 
> wrote:
I’m currently embarking on a project to determine the number of RADIUS auths 
per minute each one of my controllers is generating to plan for the capacity I 
need for my RADIUS servers.

I was curious if anyone has embarked on a similar journey and tried to measure 
auth rates coming from their controllers?

I have a couple of ideas that I’m up for sharing, but I wanted to see if anyone 
else has done this.

Thanks!


Charles Rumford
Network Engineer/Senior Wireless Engineer
ISC Network Operations
University of Pennsylvania
OpenPGP Key ID: 0xF3D8215A
(p) 215-746-2808


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