Re: [WIRELESS-LAN] Student Gaming behind NAT

[Hunter Fuller]

I'm interested in why you would separate it into a different VRF.

Anyway, we have gotten rid of NAT on Resnet and it is amazing. We are
piloting the same situation on wireless. Do it as soon as you can get away
with it. You will get fewer tickets. There is less info to chase down about
issues. Students will stop asking you how to change their NAT type because
it will always be Open. You will sleep better at night. You will find a $20
bill in a pair of pants you hadn't worn in a while. Etc.

Seriously, it's the best. Your firewall and ACLs will protect your
constituents, because that's what they're designed to do, y'know?


On Tue, Feb 14, 2017 at 10:52 AM Voelker, Andy 
wrote:

We’re having increasing problems with newer games operating on a 1:1 NAT in
our residence halls.  Some of these games have a dozen port entries per
platform (Xbox, PS4, PC) and after all that the games still aren’t acting
reliably.  We’re using a Palo Alto firewall, which carries application
signatures for SOME games, but not that many.  I’m finding myself spending
too much time on this, yet not able to dedicate enough to get to a good
solution.  I’m interested to hear how others are handling this (since I’m
new to operating this type of service).



Little background info:  We have a device SSID with a WPA2-PSK that dumps
onto the student network, which carries some network permissions but
relatively few.  A potential solution would be to stop NATing addresses,
provide a public IPs to the device network, and segment them into an
off-campus-only VRF.  However, students are starting to interact with their
consoles using their PC’s and mobile devices, which would not work in this
model.  By this I mean screen-casting, live streaming, etc.  I suspect that
need will grow.  Also other “things” that use the device network like
Chromecast, Sonos, Google Home, WiFi lights, etc would be useless unless we
wrote firewall rules that allowed each and every one of these protocols.
Many of these rely on mDNS, DIAL, etc though.  Not easy.





I covet your thoughts.  Thanks in advance.



​

Andy Voelker

Network Administrator and IT Infrastructure Team Lead

Davidson College


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

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

Re: [WIRELESS-LAN] Student Gaming behind NAT

[Howard, Christopher]

We use Palo Alto as well and 1:1 NAT was working fine for us, at first.  
However, we were using it in such a way that if the pool of addresses ran out, 
it would fallback to a PAT pool.  We noticed that if a game console ended up in 
the PAT fallback it would fail to work.

What we ended up doing is giving the consoles a public IP to completely remove 
NAT, but used those public IPs inside our border firewalls.  The game console 
subnet is in the same VRF that the students are in.  This way they can reach 
them even though consoles are public IP and student devices are not - same 
route table internally.  After that we didn't have to make any changes to the 
Palo Altos.  All games have been functioning fine without having to open any 
ports inbound.  The only real downside is having to carve out some public IP 
space for it and move those IPs inside.

The mDNS/DIAL/etc stuff we still have on private addresses using NAT.  We are 
an Aruba shop, so we have clearpass.  The only thing we use clearpass for is 
the enablement of AirGroup and who can see which device (we limit to the 
building, basically).  We don't use clearpass as a NAC or anything like that.

Christopher Howard
Director, Network Engineering
University of Tennessee at Chattanooga
christopher-how...@utc.edu

On Feb 14, 2017, at 11:52 AM, Voelker, Andy 
> wrote:

We’re having increasing problems with newer games operating on a 1:1 NAT in our 
residence halls.  Some of these games have a dozen port entries per platform 
(Xbox, PS4, PC) and after all that the games still aren’t acting reliably.  
We’re using a Palo Alto firewall, which carries application signatures for SOME 
games, but not that many.  I’m finding myself spending too much time on this, 
yet not able to dedicate enough to get to a good solution.  I’m interested to 
hear how others are handling this (since I’m new to operating this type of 
service).

Little background info:  We have a device SSID with a WPA2-PSK that dumps onto 
the student network, which carries some network permissions but relatively few. 
 A potential solution would be to stop NATing addresses, provide a public IPs 
to the device network, and segment them into an off-campus-only VRF.  However, 
students are starting to interact with their consoles using their PC’s and 
mobile devices, which would not work in this model.  By this I mean 
screen-casting, live streaming, etc.  I suspect that need will grow.  Also 
other “things” that use the device network like Chromecast, Sonos, Google Home, 
WiFi lights, etc would be useless unless we wrote firewall rules that allowed 
each and every one of these protocols.  Many of these rely on mDNS, DIAL, etc 
though.  Not easy.


I covet your thoughts.  Thanks in advance.

​
Andy Voelker
Network Administrator and IT Infrastructure Team Lead
Davidson College

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


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

Re: [WIRELESS-LAN] Student Gaming behind NAT

[Coehoorn, Joel]

Our firewall vendor (Untangle) is experimenting with a restricted UPnP
option, that may eventually allow us to use it for only approved devices
and approved ports, for an approved timespan. Other UPnP requests would be
rejected.

Not sure yet how I feel about the feature. If it works, I know our
student's would love it and I'm confident I could secure it to protect our
own public-facing services. But I'm not sure how it could allow two NAT'd
devices to both have, say, port 3074 forwarded at the same time.

On Feb 14, 2017 10:52 AM, "Voelker, Andy"  wrote:

> We’re having increasing problems with newer games operating on a 1:1 NAT
> in our residence halls.  Some of these games have a dozen port entries per
> platform (Xbox, PS4, PC) and after all that the games still aren’t acting
> reliably.  We’re using a Palo Alto firewall, which carries application
> signatures for SOME games, but not that many.  I’m finding myself spending
> too much time on this, yet not able to dedicate enough to get to a good
> solution.  I’m interested to hear how others are handling this (since I’m
> new to operating this type of service).
>
>
>
> Little background info:  We have a device SSID with a WPA2-PSK that dumps
> onto the student network, which carries some network permissions but
> relatively few.  A potential solution would be to stop NATing addresses,
> provide a public IPs to the device network, and segment them into an
> off-campus-only VRF.  However, students are starting to interact with their
> consoles using their PC’s and mobile devices, which would not work in this
> model.  By this I mean screen-casting, live streaming, etc.  I suspect that
> need will grow.  Also other “things” that use the device network like
> Chromecast, Sonos, Google Home, WiFi lights, etc would be useless unless we
> wrote firewall rules that allowed each and every one of these protocols.
> Many of these rely on mDNS, DIAL, etc though.  Not easy.
>
>
>
>
>
> I covet your thoughts.  Thanks in advance.
>
>
>
> ​
>
> Andy Voelker
>
> Network Administrator and IT Infrastructure Team Lead
>
> Davidson College
>
>
> ** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at http://www.educause.edu/
> discuss.
>
>

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

Student Gaming behind NAT

[Voelker, Andy]

We’re having increasing problems with newer games operating on a 1:1 NAT in our 
residence halls.  Some of these games have a dozen port entries per platform 
(Xbox, PS4, PC) and after all that the games still aren’t acting reliably.  
We’re using a Palo Alto firewall, which carries application signatures for SOME 
games, but not that many.  I’m finding myself spending too much time on this, 
yet not able to dedicate enough to get to a good solution.  I’m interested to 
hear how others are handling this (since I’m new to operating this type of 
service).

Little background info:  We have a device SSID with a WPA2-PSK that dumps onto 
the student network, which carries some network permissions but relatively few. 
 A potential solution would be to stop NATing addresses, provide a public IPs 
to the device network, and segment them into an off-campus-only VRF.  However, 
students are starting to interact with their consoles using their PC’s and 
mobile devices, which would not work in this model.  By this I mean 
screen-casting, live streaming, etc.  I suspect that need will grow.  Also 
other “things” that use the device network like Chromecast, Sonos, Google Home, 
WiFi lights, etc would be useless unless we wrote firewall rules that allowed 
each and every one of these protocols.  Many of these rely on mDNS, DIAL, etc 
though.  Not easy.


I covet your thoughts.  Thanks in advance.

​
Andy Voelker
Network Administrator and IT Infrastructure Team Lead
Davidson College


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

Re: [WIRELESS-LAN] Some Nyansa feedback before the call...

[Mike Fitzgerald]

I agree with Ryan's take. We've also been involved since very early on.  
We just have our wireless controller links mirrored over to two crawlers 
(having to do with our network layout).  It's watching three 
controllers, about 2200 AP's, all Aruba Networks. We're not watching 
wired connections, mostly because it's a challenge due to our network 
design (very redundant, multipath. etc.)


While I'm not the wireless engineer, I often get involved when 
connectivity complaints hit the ticket system and Voyance is always my 
stating point.  I've found it much easier to troubleshoot from there vs 
separate visits to Airwave, DNS server logs, DHCP server logs, etc.  
I've found Voyance to be pretty accurate in diagnosing the root cause of 
problems. I've actually been doing a top-down review of the entire 
network infrastructure, both wired and wireless and have been using 
Voyance's reports/alerts to help focus on areas of most concern.  Our 
wireless engineer has been using Voyance to help determine where we need 
to be disabling the 2.4Ghz band due to being a dense deployment and AP's 
seeing too many neighbors. Since that requires creating two AP profiles 
in a given building (5+2.4Ghz, and 5Ghz only), being able to create a 
custom group in Voyance to report both groups as one entity comes in handy.


We also found instances of unintended consequences related to changes in 
design or policy.  Something as simple as a change in our password 
change policy (required expiration) ended up causing end-user devices to 
ping-pong back and forth between our 802.1x and open SSID's.  People 
would change their password, but forget to update their 802.1x 
credentials cached on their phones, etc.  Their 802.1x connection would 
fail due to bad password (easy to see in Voyance's timeline feature) and 
their device would then jump over to our open SSID.  Our Clearpass 
server would look at the connection request for the open SSID and 
because we tag devices that are capable of 802.1x, redirect to a "you 
should be over on 802.1x, go away" page) and then drop their connection 
after a short duration. The device would then go back to try 802.1x 
again and start the cycle over again. The end-users didn't notice 
because their phones would just switch to their carrier's data 
connection while this was all going on.  Voyance reported this high 
level of SSID hopping and once we looked at some client timelines and 
noticed what was going on, led us to update the password change web site 
to call out in large terms the fact that users needed to forget and 
reconnect their 802.1x connections using their new password.  Not 
service-impacting, except for users with small carrier data plans, who 
could get slammed with over-use charges, but still a good catch.


Voyance also caught a case where the source interface for radius 
requests on one of our controllers was incorrect.  Things were working, 
because the alternate address was available, but traffic took an 
unexpected path back from the radius server.  This issue would have 
impacted us if we had a failure (or scheduled maintenance) of one of our 
distribution layer switches, which was in the unexpected path. Another 
good catch that I don't see any of the other tools we have (Airwave, 
Solarwinds Orion) would have caught. It has also recently caught some 
DNS issues that turned out to be performance problems one of the servers 
(behind a load-balancer) that didn't show up in the server monitoring. 
In one case, it was free space exhaustion, that wasn't being properly 
monitored/alerted and in another case, it was a a run-away process that 
was swamping I/O on the box.


We haven't done any tuning because we didn't see the need.  The product 
learns what is "normal" for your environment, sets a baseline and then 
alerts based on variation from the norm.  Because it is based on 
percentages, it tends to adjust well (although not flawlessly) when load 
on the network rises and falls.  We've found that we get some unexpected 
alerts when student breaks happen, which is unexpected because it is 
when the load on the network is the least.  We're still trying to 
understand that but it's not high on the list of things to do.


I must say that in the beginning, I found myself questioning a lot of 
the alerts because we just weren't getting complaints. As I 
investigated, I discovered many instances where things weren't behaving 
as we thought, even though end-users really weren't noticing.  I now 
joke with our Nyansa contacts that my network is so clean now, I may no 
longer need the product...  When Voyance does throw an alert now, it 
is highly likely that there's a real problem.


For me, I find it well worth the investment and I find the Nyansa folks 
to be very willing to consider changes to the product. Being an 
operations guy at heart, I pushed for a number of the more "real-time" 
features, as opposed to the long-term reporting features.  I also like 
that I don't have 

RE: [WIRELESS-LAN] Some Nyansa feedback before the call...

[Chuck Enfield]

Thanks Ryan for the great answers, and Lee for seeding the pot with good 
questions.



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Turner, Ryan H
Sent: Tuesday, February 14, 2017 4:01 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Some Nyansa feedback before the call...



All,





Before I begin, a little disclosure.  This is not an official endorsement. 
These are my opinions, and are solely mine and not those of my institution.





I first mentioned Nyansa back in June or July this past year.  There were a 
couple super early adopters (I remember Liberty, specifically).  I also 
mentioned it at the educause wireless session.  I was very hesitant, 
initially, to engage in a pilot.   However, given the praise from early 
adopters, and shops like Liberty which seem to run great shops, I decided to 
give it a go.





We went on a pilot beginning in the middle of August.  We decided near the 
beginning of October to purchase.   Due to purchasing woes, the actual 
purchase wasn't completed until the last few weeks.  However, that gave us 
an extended trial with the product on our campus.  Our campus has around 
8,500 Aruba access points, and we were looking at data from about 5,000 of 
those during this long period.





Let me give you the quick summary, and then I'll go into detail...





To date, I haven't seen a more comprehensive wireless performance monitoring 
platform than I have with this product.  From our experience, it has been 
extremely accurate in building dynamic thresholds, without any 
administrative interference, of many services/metrics that are important to 
us.  As a general rule, if it sends me an alert, it is significant.  During 
the last few months, it successfully discovered several significant problems 
with services that may have gone unnoticed much longer.  And it alerted us 
to problems prior to any client calling us.  Those included DNS servers 
which were not responding quick enough to client requests, a DHCP server 
that was significantly adversely affected to a relatively small number of 
errors on a fiber, performance issues with several nework access control 
gateways responding successfully, but very slowly to 802.1x and MAX 
authenticatrion requests that had gone unnoticed, and has diagnosed several 
client issues successfully.  I am sure I am forgetting some things, but 
those are the highlights.





Let me try and answer some of the questions:





-  Can it be tuned to meet our specific concerns and reduce false 
positives?

Maybe, but I am curious what you want to tune.  The DNS alerts can be 
annoying if people are using external DNS servers that you don't want to 
monitor.  You can tune that out.  All the other thresholds are made 
dynamically, and seem to be spot on.  The thresholds are tuned based on 
client count, so I 'think' it isn't blindly based on a single threshold 
(verify this with Nyansa, but I think this is the way it works)

-  Can conclusions made by Voyance be verified?

We had them verify a few things that we just didn't believe.  In one 
instance, they did determine that the alert was false because of the unusual 
way we deployed the pilot.  They made adjustments to the software to fix 
this.  On other instances, we have used log sources to validate what we were 
being alerted on, and those logs have confirmed the tool's findings

-  What are the highest-impact analytics provided?

For 'analytics', I really like the monitoring of networking services (ARP, 
DHCP, DNS).  They have been invaluable.

-  Is it telling us what our other tools can’t?

Yes and No.  In some instances, like the dynamic thresholds, I haven't seen 
other tools work as well.  From my perspective, it does a lot of things 
'better'.   Being able to compare your numbers to other similar institutions 
gives you a really good idea of what you are doing great and what you can do 
better.  The client monitoring is spectacular.  In our environment, we have 
to run multiple servers just to collect all the client data, and then we 
have to locally visit those servers individually to get a full picture of 
client connectivity.  Nyansa pulls this all together in the same pane.  The 
search results are nearly instantaneous.  The timelines are very helpful. 
Also, the software detects when you update controller firmware, and you can 
see if firmware makes things better or worse.  Much more, but this is enough 
for now.

-  Do the analytics lead to actionable information? What % of the 
time?

Yes.  I would say 75% of the time based on our experience.  It does take a 
few weeks to get those thresholds tuned (automatically)

-  Are recommendations made by Voyance possible, or are they 
untenable best practices not right for our environment?

I prefer running fiber taps to my tools as I don't trust span ports.  In 
order for the product to work 

RE: [WIRELESS-LAN] Some Nyansa feedback before the call...

[Turner, Ryan H]

No.  Since we are are currently only on main campus, those weird device types 
that you see in the residence halls haven't appeared, yet.

I haven't been proactive with reported client issues.  I have been more focused 
on the macro.

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Tuesday, February 14, 2017 7:44 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Some Nyansa feedback before the call...

Thanks Ryan. One of the first client and issues I dug into was a no-problem 
Xbox that Nyansa classified as a multi-problem Windows phone. Have you seen any 
of this sort of thing?

Lee

Lee Badman
Network Architect/Wireless TME
Syracuse University
315.443.3003

-Original Message-
From: Turner, Ryan H [rhtur...@email.unc.edu]
Received: Tuesday, 14 Feb 2017, 4:01
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
[WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]
Subject: [WIRELESS-LAN] Some Nyansa feedback before the call...

All,



Before I begin, a little disclosure.  This is not an official endorsement.  
These are my opinions, and are solely mine and not those of my institution.



I first mentioned Nyansa back in June or July this past year.  There were a 
couple super early adopters (I remember Liberty, specifically).  I also 
mentioned it at the educause wireless session.  I was very hesitant, initially, 
to engage in a pilot.   However, given the praise from early adopters, and 
shops like Liberty which seem to run great shops, I decided to give it a go.



We went on a pilot beginning in the middle of August.  We decided near the 
beginning of October to purchase.   Due to purchasing woes, the actual purchase 
wasn't completed until the last few weeks.  However, that gave us an extended 
trial with the product on our campus.  Our campus has around 8,500 Aruba access 
points, and we were looking at data from about 5,000 of those during this long 
period.



Let me give you the quick summary, and then I'll go into detail...



To date, I haven't seen a more comprehensive wireless performance monitoring 
platform than I have with this product.  From our experience, it has been 
extremely accurate in building dynamic thresholds, without any administrative 
interference, of many services/metrics that are important to us.  As a general 
rule, if it sends me an alert, it is significant.  During the last few months, 
it successfully discovered several significant problems with services that may 
have gone unnoticed much longer.  And it alerted us to problems prior to any 
client calling us.  Those included DNS servers which were not responding quick 
enough to client requests, a DHCP server that was significantly adversely 
affected to a relatively small number of errors on a fiber, performance issues 
with several nework access control gateways responding successfully, but very 
slowly to 802.1x and MAX authenticatrion requests that had gone unnoticed, and 
has diagnosed several client issues successfully.  I am sure I am forgetting 
some things, but those are the highlights.



Let me try and answer some of the questions:


-  Can it be tuned to meet our specific concerns and reduce false 
positives?
Maybe, but I am curious what you want to tune.  The DNS alerts can be annoying 
if people are using external DNS servers that you don't want to monitor.  You 
can tune that out.  All the other thresholds are made dynamically, and seem to 
be spot on.  The thresholds are tuned based on client count, so I 'think' it 
isn't blindly based on a single threshold (verify this with Nyansa, but I think 
this is the way it works)
-  Can conclusions made by Voyance be verified?
We had them verify a few things that we just didn't believe.  In one instance, 
they did determine that the alert was false because of the unusual way we 
deployed the pilot.  They made adjustments to the software to fix this.  On 
other instances, we have used log sources to validate what we were being 
alerted on, and those logs have confirmed the tool's findings
-  What are the highest-impact analytics provided?
For 'analytics', I really like the monitoring of networking services (ARP, 
DHCP, DNS).  They have been invaluable.
-  Is it telling us what our other tools can't?
Yes and No.  In some instances, like the dynamic thresholds, I haven't seen 
other tools work as well.  From my perspective, it does a lot of things 
'better'.   Being able to compare your numbers to other similar institutions 
gives you a really good idea of what you are doing great and what you can do 
better.  The client monitoring is spectacular.  In our environment, we have to 
run multiple servers just to collect all the client data, and then we have to 
locally visit those servers individually to get a full picture of client 
connectivity.  Nyansa pulls this all together in the same pane.  The 

RE: [WIRELESS-LAN] Some Nyansa feedback before the call...

[Lee H Badman]

Thanks Ryan. One of the first client and issues I dug into was a no-problem 
Xbox that Nyansa classified as a multi-problem Windows phone. Have you seen any 
of this sort of thing?

Lee

Lee Badman
Network Architect/Wireless TME
Syracuse University
315.443.3003

-Original Message-
From: Turner, Ryan H [rhtur...@email.unc.edu]
Received: Tuesday, 14 Feb 2017, 4:01
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]
Subject: [WIRELESS-LAN] Some Nyansa feedback before the call...


All,


Before I begin, a little disclosure.  This is not an official endorsement.  
These are my opinions, and are solely mine and not those of my institution.


I first mentioned Nyansa back in June or July this past year.  There were a 
couple super early adopters (I remember Liberty, specifically).  I also 
mentioned it at the educause wireless session.  I was very hesitant, initially, 
to engage in a pilot.   However, given the praise from early adopters, and 
shops like Liberty which seem to run great shops, I decided to give it a go.


We went on a pilot beginning in the middle of August.  We decided near the 
beginning of October to purchase.   Due to purchasing woes, the actual purchase 
wasn't completed until the last few weeks.  However, that gave us an extended 
trial with the product on our campus.  Our campus has around 8,500 Aruba access 
points, and we were looking at data from about 5,000 of those during this long 
period.


Let me give you the quick summary, and then I'll go into detail...


To date, I haven't seen a more comprehensive wireless performance monitoring 
platform than I have with this product.  From our experience, it has been 
extremely accurate in building dynamic thresholds, without any administrative 
interference, of many services/metrics that are important to us.  As a general 
rule, if it sends me an alert, it is significant.  During the last few months, 
it successfully discovered several significant problems with services that may 
have gone unnoticed much longer.  And it alerted us to problems prior to any 
client calling us.  Those included DNS servers which were not responding quick 
enough to client requests, a DHCP server that was significantly adversely 
affected to a relatively small number of errors on a fiber, performance issues 
with several nework access control gateways responding successfully, but very 
slowly to 802.1x and MAX authenticatrion requests that had gone unnoticed, and 
has diagnosed several client issues successfully.  I am sure I am forgetting 
some things, but those are the highlights.


Let me try and answer some of the questions:


-  Can it be tuned to meet our specific concerns and reduce false 
positives?
Maybe, but I am curious what you want to tune.  The DNS alerts can be annoying 
if people are using external DNS servers that you don't want to monitor.  You 
can tune that out.  All the other thresholds are made dynamically, and seem to 
be spot on.  The thresholds are tuned based on client count, so I 'think' it 
isn't blindly based on a single threshold (verify this with Nyansa, but I think 
this is the way it works)
-  Can conclusions made by Voyance be verified?
We had them verify a few things that we just didn't believe.  In one instance, 
they did determine that the alert was false because of the unusual way we 
deployed the pilot.  They made adjustments to the software to fix this.  On 
other instances, we have used log sources to validate what we were being 
alerted on, and those logs have confirmed the tool's findings
-  What are the highest-impact analytics provided?
For 'analytics', I really like the monitoring of networking services (ARP, 
DHCP, DNS).  They have been invaluable.
-  Is it telling us what our other tools can’t?
Yes and No.  In some instances, like the dynamic thresholds, I haven't seen 
other tools work as well.  From my perspective, it does a lot of things 
'better'.   Being able to compare your numbers to other similar institutions 
gives you a really good idea of what you are doing great and what you can do 
better.  The client monitoring is spectacular.  In our environment, we have to 
run multiple servers just to collect all the client data, and then we have to 
locally visit those servers individually to get a full picture of client 
connectivity.  Nyansa pulls this all together in the same pane.  The search 
results are nearly instantaneous.  The timelines are very helpful.  Also, the 
software detects when you update controller firmware, and you can see if 
firmware makes things better or worse.  Much more, but this is enough for now.
-  Do the analytics lead to actionable information? What % of the time?
Yes.  I would say 75% of the time based on our experience.  It does take a few 
weeks to get those thresholds tuned (automatically)
-  Are recommendations made by Voyance possible, or are they untenable 
best practices not right for our 

Some Nyansa feedback before the call...

[Turner, Ryan H]

All,


Before I begin, a little disclosure.  This is not an official endorsement.  
These are my opinions, and are solely mine and not those of my institution.


I first mentioned Nyansa back in June or July this past year.  There were a 
couple super early adopters (I remember Liberty, specifically).  I also 
mentioned it at the educause wireless session.  I was very hesitant, initially, 
to engage in a pilot.   However, given the praise from early adopters, and 
shops like Liberty which seem to run great shops, I decided to give it a go.


We went on a pilot beginning in the middle of August.  We decided near the 
beginning of October to purchase.   Due to purchasing woes, the actual purchase 
wasn't completed until the last few weeks.  However, that gave us an extended 
trial with the product on our campus.  Our campus has around 8,500 Aruba access 
points, and we were looking at data from about 5,000 of those during this long 
period.


Let me give you the quick summary, and then I'll go into detail...


To date, I haven't seen a more comprehensive wireless performance monitoring 
platform than I have with this product.  From our experience, it has been 
extremely accurate in building dynamic thresholds, without any administrative 
interference, of many services/metrics that are important to us.  As a general 
rule, if it sends me an alert, it is significant.  During the last few months, 
it successfully discovered several significant problems with services that may 
have gone unnoticed much longer.  And it alerted us to problems prior to any 
client calling us.  Those included DNS servers which were not responding quick 
enough to client requests, a DHCP server that was significantly adversely 
affected to a relatively small number of errors on a fiber, performance issues 
with several nework access control gateways responding successfully, but very 
slowly to 802.1x and MAX authenticatrion requests that had gone unnoticed, and 
has diagnosed several client issues successfully.  I am sure I am forgetting 
some things, but those are the highlights.


Let me try and answer some of the questions:


-  Can it be tuned to meet our specific concerns and reduce false 
positives?
Maybe, but I am curious what you want to tune.  The DNS alerts can be annoying 
if people are using external DNS servers that you don't want to monitor.  You 
can tune that out.  All the other thresholds are made dynamically, and seem to 
be spot on.  The thresholds are tuned based on client count, so I 'think' it 
isn't blindly based on a single threshold (verify this with Nyansa, but I think 
this is the way it works)
-  Can conclusions made by Voyance be verified?
We had them verify a few things that we just didn't believe.  In one instance, 
they did determine that the alert was false because of the unusual way we 
deployed the pilot.  They made adjustments to the software to fix this.  On 
other instances, we have used log sources to validate what we were being 
alerted on, and those logs have confirmed the tool's findings
-  What are the highest-impact analytics provided?
For 'analytics', I really like the monitoring of networking services (ARP, 
DHCP, DNS).  They have been invaluable.
-  Is it telling us what our other tools can’t?
Yes and No.  In some instances, like the dynamic thresholds, I haven't seen 
other tools work as well.  From my perspective, it does a lot of things 
'better'.   Being able to compare your numbers to other similar institutions 
gives you a really good idea of what you are doing great and what you can do 
better.  The client monitoring is spectacular.  In our environment, we have to 
run multiple servers just to collect all the client data, and then we have to 
locally visit those servers individually to get a full picture of client 
connectivity.  Nyansa pulls this all together in the same pane.  The search 
results are nearly instantaneous.  The timelines are very helpful.  Also, the 
software detects when you update controller firmware, and you can see if 
firmware makes things better or worse.  Much more, but this is enough for now.
-  Do the analytics lead to actionable information? What % of the time?
Yes.  I would say 75% of the time based on our experience.  It does take a few 
weeks to get those thresholds tuned (automatically)
-  Are recommendations made by Voyance possible, or are they untenable 
best practices not right for our environment?
I prefer running fiber taps to my tools as I don't trust span ports.  In order 
for the product to work well, each 'area' needs to come to a single crawler.  
This makes using taps difficult or impossible (not enough interfaces on the 
crawlers for large environments), so I have to rely on a tap agg switch.
-  Is there daily value, or is longer-term trending required?
Absolutely.  I will use this as the first place I go to when troubleshooting 
client issues.
-  Is there single-user