RE: [WIRELESS-LAN] Cisco Code Version

[Stobbs, Darren]

Hi Britton,


I’m aware of a couple of bugs on the 1810W if you’re trying to use 
RLAN/Flexconnect to drop the traffic out to a locally switched VLAN (local to 
where the access point is).

The workaround for this is to tunnel the wired traffic to controller for 
central switching, which seems to be the method used by most admins anyway.

If you are trying to do the former scenario, those bugs prevent it and it is 
fixed as an enhancement in 8.5+

I don’t think there is a workaround for the bug you mentioned, other than going 
to 8.3 or instructing users not to extend the wired interfaces with a 
hub/switch.


Darren.


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Britton Anderson
Sent: 08 August 2017 21:25
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

Anybody else running 1810Ws on 8.2 running into the multiple devices per port 
bug?

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCux78581

We are deploying 8540's now running 8.2.160 with 1810s in a dorm hall that we 
are refreshing and we were doing some testing this morning and ran into this 
issue. First device recognized would get an IP address, but the second device 
doesn't get an IP and the DHCP renewal on the first device would then fail. ARP 
entries actually time out for the first learned device from the router upstream 
so the AP completely locks up and stops forwarding packets from those 
interfaces. Wireless still seems to function though.

With all of the discussion we've had on this list so far, I'm reluctant to move 
up to 8.3 or 8.4 this close to semester start (2 weeks away) at this point with 
all of our other testing going quite well on 8.2.160 for our roll out, and I 
would rather not run mixed code versions. Anyone have any experience with this 
bug in the wild, and how did you solve it?

Thanks,
Britton


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

RE: [WIRELESS-LAN] Cisco Code Version

[Viou, Robert]

We ran into multiple devices per port bug and was told by TAC that code 8.3MR1 
corrected that issue.
8.3.121.0 installed and working.


Robert Viou



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Britton Anderson
Sent: Tuesday, August 08, 2017 3:25 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

Anybody else running 1810Ws on 8.2 running into the multiple devices per port 
bug?

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCux78581

We are deploying 8540's now running 8.2.160 with 1810s in a dorm hall that we 
are refreshing and we were doing some testing this morning and ran into this 
issue. First device recognized would get an IP address, but the second device 
doesn't get an IP and the DHCP renewal on the first device would then fail. ARP 
entries actually time out for the first learned device from the router upstream 
so the AP completely locks up and stops forwarding packets from those 
interfaces. Wireless still seems to function though.

With all of the discussion we've had on this list so far, I'm reluctant to move 
up to 8.3 or 8.4 this close to semester start (2 weeks away) at this point with 
all of our other testing going quite well on 8.2.160 for our roll out, and I 
would rather not run mixed code versions. Anyone have any experience with this 
bug in the wild, and how did you solve it?

Thanks,
Britton


Britton Anderson<mailto:blanders...@alaska.edu> |

 Lead Network Communications Specialist |

 University of Alaska<http://www.alaska.edu/oit> |

 907.450.8250<tel:(907)%20450-8250>



On Mon, Aug 7, 2017 at 7:46 AM, Hunter Fuller 
<hf0...@uah.edu<mailto:hf0...@uah.edu>> wrote:
Yeah, it's intriguing to say the least. I will be testing in the lab.
But on a more relevant note, we are not even on 8.5 at all in production. So... 
this is "pie in the sky" for us, for now.

On Sun, Aug 6, 2017 at 11:09 AM Ciesinski, Nick 
<ciesi...@uww.edu<mailto:ciesi...@uww.edu>> wrote:

I think it may be possible but there are a few hurdles to get over.  Cisco is 
using the catch all RADIUS attribute cisco-av-pair for the IPSK which means the 
return value has to be formatted a certain way and not just returning a PSK.



You first need to return a value of psk-mode=ascii which is easy since its the 
same for every device.  Then you need to return the actual PSK formatted as 
psk=.  I have never seen a option within ISE (nor ACS from my 
remembrance) to be able to build a value; it's ether all manually typed in or 
all gotten from another source.  This would mean actually storing "psk=" as a attribute value in your AD. Obviously not that hard to do if you 
are already writing your own interface to get items into AD in the first place.



What I am unsure about is the ability to actually send back a value you get 
from AD in the RADIUS return result.  While in ISE I can choose a AD attribute 
from the selection criteria I don't know if it will actually send the value for 
the particular user/device or just the attribute name from AD.  I have seen ISE 
allow you to select things like AD:Objectname but instead of it returning a 
value it returns "AD:Objectname".  It's been years since I have used ACS but 
recall it working similar when building your rules and return results.



It is worth testing in a lab to see what it will actually return, if its the 
actual value from AD i'd say your good to go.



Nick




From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of Hunter Fuller <hf0...@uah.edu<mailto:hf0...@uah.edu>>
Sent: Friday, August 4, 2017 4:59 PM

To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version
You're right, I had misread that.

Upon reading it that way, though, isn't that fine too? The person's device 
reports its MAC, and then ACS or any other RADIUS just responds with that MAC's 
owner's assigned PSK. If the device's MAC isn't known, we just respond with an 
empty or garbage PSK to prevent them authenticating.

On Fri, Aug 4, 2017 at 4:13 PM Ciesinski, Nick 
<ciesi...@uww.edu<mailto:ciesi...@uww.edu>> wrote:
I think your going to have the same problem with ACS as there is with ISE.  The 
controller does not send the PSK the user used to the RADIUS server for 
verification/validation.  Instead the RADIUS server will send back the PSK 
value the user/device should be using and the WLC does the 
verification/validation based on that return value.

Nick

On Aug 4, 2017, at 4:02 PM, Hunter Fuller 
<hf0...@uah.edu<mailto:hf0...@uah.edu>> wrote:

Yep - we use Cisco ACS, backed with AD. Should be able to just add another rule 
to our ruleset, then co

Re: [WIRELESS-LAN] Cisco Code Version

[Britton Anderson]

Anybody else running 1810Ws on 8.2 running into the multiple devices per
port bug?

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCux78581

We are deploying 8540's now running 8.2.160 with 1810s in a dorm hall that
we are refreshing and we were doing some testing this morning and ran into
this issue. First device recognized would get an IP address, but the second
device doesn't get an IP and the DHCP renewal on the first device would
then fail. ARP entries actually time out for the first learned device from
the router upstream so the AP completely locks up and stops forwarding
packets from those interfaces. Wireless still seems to function though.

With all of the discussion we've had on this list so far, I'm reluctant to
move up to 8.3 or 8.4 this close to semester start (2 weeks away) at this
point with all of our other testing going quite well on 8.2.160 for our
roll out, and I would rather not run mixed code versions. Anyone have any
experience with this bug in the wild, and how did you solve it?

Thanks,
Britton



Britton Anderson <blanders...@alaska.edu> |  Lead Network Communications
Specialist |  University of Alaska <http://www.alaska.edu/oit> |
907.450.8250 <(907)%20450-8250>

On Mon, Aug 7, 2017 at 7:46 AM, Hunter Fuller <hf0...@uah.edu> wrote:

> Yeah, it's intriguing to say the least. I will be testing in the lab.
> But on a more relevant note, we are not even on 8.5 at all in production.
> So... this is "pie in the sky" for us, for now.
>
> On Sun, Aug 6, 2017 at 11:09 AM Ciesinski, Nick <ciesi...@uww.edu> wrote:
>
>> I think it may be possible but there are a few hurdles to get over.
>> Cisco is using the catch all RADIUS attribute cisco-av-pair for the IPSK
>> which means the return value has to be formatted a certain way and not just
>> returning a PSK.
>>
>>
>> You first need to return a value of psk-mode=ascii which is easy since
>> its the same for every device.  Then you need to return the actual PSK
>> formatted as psk=.  I have never seen a option within ISE (nor
>> ACS from my remembrance) to be able to build a value; it's ether all
>> manually typed in or all gotten from another source.  This would mean
>> actually storing "psk=" as a attribute value in your
>> AD. Obviously not that hard to do if you are already writing your own
>> interface to get items into AD in the first place.
>>
>>
>> What I am unsure about is the ability to actually send back a value you
>> get from AD in the RADIUS return result.  While in ISE I can choose a AD
>> attribute from the selection criteria I don't know if it will actually send
>> the value for the particular user/device or just the attribute name from
>> AD.  I have seen ISE allow you to select things like AD:Objectname but
>> instead of it returning a value it returns "AD:Objectname".  It's been
>> years since I have used ACS but recall it working similar when building
>> your rules and return results.
>>
>>
>> It is worth testing in a lab to see what it will actually return, if its
>> the actual value from AD i'd say your good to go.
>>
>>
>> Nick
>>
>>
>> ----------
>> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Hunter Fuller <
>> hf0...@uah.edu>
>> *Sent:* Friday, August 4, 2017 4:59 PM
>>
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> *Subject:* Re: [WIRELESS-LAN] Cisco Code Version
>> You're right, I had misread that.
>>
>> Upon reading it that way, though, isn't that fine too? The person's
>> device reports its MAC, and then ACS or any other RADIUS just responds with
>> that MAC's owner's assigned PSK. If the device's MAC isn't known, we just
>> respond with an empty or garbage PSK to prevent them authenticating.
>>
>> On Fri, Aug 4, 2017 at 4:13 PM Ciesinski, Nick <ciesi...@uww.edu> wrote:
>>
>>> I think your going to have the same problem with ACS as there is with
>>> ISE.  The controller does not send the PSK the user used to the RADIUS
>>> server for verification/validation.  Instead the RADIUS server will send
>>> back the PSK value the user/device should be using and the WLC does the
>>> verification/validation based on that return value.
>>>
>>> Nick
>>>
>>> On Aug 4, 2017, at 4:02 PM, Hunter Fuller <hf0...@uah.edu> wrote:
>>>
>>> Yep - we use Cisco ACS, backed with AD. Should be able to just add
>>> another rule to our ruleset, then configure iPSK on the controllers. Then
>>> it would check the PSK against AD, as the machi

Re: [WIRELESS-LAN] Cisco Code Version

[Hunter Fuller]

Yeah, it's intriguing to say the least. I will be testing in the lab.
But on a more relevant note, we are not even on 8.5 at all in production.
So... this is "pie in the sky" for us, for now.

On Sun, Aug 6, 2017 at 11:09 AM Ciesinski, Nick <ciesi...@uww.edu> wrote:

> I think it may be possible but there are a few hurdles to get over.  Cisco
> is using the catch all RADIUS attribute cisco-av-pair for the IPSK which
> means the return value has to be formatted a certain way and not just
> returning a PSK.
>
>
> You first need to return a value of psk-mode=ascii which is easy since its
> the same for every device.  Then you need to return the actual PSK
> formatted as psk=.  I have never seen a option within ISE (nor
> ACS from my remembrance) to be able to build a value; it's ether all
> manually typed in or all gotten from another source.  This would mean
> actually storing "psk=" as a attribute value in your
> AD. Obviously not that hard to do if you are already writing your own
> interface to get items into AD in the first place.
>
>
> What I am unsure about is the ability to actually send back a value you
> get from AD in the RADIUS return result.  While in ISE I can choose a AD
> attribute from the selection criteria I don't know if it will actually send
> the value for the particular user/device or just the attribute name from
> AD.  I have seen ISE allow you to select things like AD:Objectname but
> instead of it returning a value it returns "AD:Objectname".  It's been
> years since I have used ACS but recall it working similar when building
> your rules and return results.
>
>
> It is worth testing in a lab to see what it will actually return, if its
> the actual value from AD i'd say your good to go.
>
>
> Nick
>
>
> --
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Hunter Fuller <
> hf0...@uah.edu>
> *Sent:* Friday, August 4, 2017 4:59 PM
>
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] Cisco Code Version
> You're right, I had misread that.
>
> Upon reading it that way, though, isn't that fine too? The person's device
> reports its MAC, and then ACS or any other RADIUS just responds with that
> MAC's owner's assigned PSK. If the device's MAC isn't known, we just
> respond with an empty or garbage PSK to prevent them authenticating.
>
> On Fri, Aug 4, 2017 at 4:13 PM Ciesinski, Nick <ciesi...@uww.edu> wrote:
>
>> I think your going to have the same problem with ACS as there is with
>> ISE.  The controller does not send the PSK the user used to the RADIUS
>> server for verification/validation.  Instead the RADIUS server will send
>> back the PSK value the user/device should be using and the WLC does the
>> verification/validation based on that return value.
>>
>> Nick
>>
>> On Aug 4, 2017, at 4:02 PM, Hunter Fuller <hf0...@uah.edu> wrote:
>>
>> Yep - we use Cisco ACS, backed with AD. Should be able to just add
>> another rule to our ruleset, then configure iPSK on the controllers. Then
>> it would check the PSK against AD, as the machine password for the machine
>> account. (We already make machine accounts for registered MACs of game
>> consoles, etc.)
>>
>> On Wed, Aug 2, 2017 at 7:31 PM Joachim Tingvold <joac...@tingvold.com>
>> wrote:
>>
>>> On 1 Aug 2017, at 17:33, Ciesinski, Nick wrote:
>>> > While WLC 8.5 did add IPSK it is probably safe to say its rather
>>> > worthless for most at this time.  For those who have used ISE if you
>>> > watch the video on how they make IPSK work it isn’t feasible to give
>>> > each of your users their own PSK key to connect to wireless.  The
>>> > current implementation within ISE required no feature additions to ISE
>>> > to make it work.  All they do is have a rule to classify a device
>>> > and/or user and then send a particular PSK value that it should be
>>> > using.  This is a 100% manual process  for each device and/or user as
>>> > nothing is baked into ISE to have a user register their account or
>>> > device(s) and be presented a PSK to use.
>>>
>>> IPSK *and* ISE might be "worthless" when combined, but IPSK in it self
>>> is not (even in it's current implementation). The limitations you're
>>> talking about is purely with ISE, and not IPSK.
>>>
>>> We use ClearPass, and we can easily query an SQL-server with MAC<->PSK
>>> mappings, yielding unique PSKs based on MAC-adresses. 

Re: [WIRELESS-LAN] Cisco Code Version

[Ciesinski, Nick]

I think it may be possible but there are a few hurdles to get over.  Cisco is 
using the catch all RADIUS attribute cisco-av-pair for the IPSK which means the 
return value has to be formatted a certain way and not just returning a PSK.


You first need to return a value of psk-mode=ascii which is easy since its the 
same for every device.  Then you need to return the actual PSK formatted as 
psk=.  I have never seen a option within ISE (nor ACS from my 
remembrance) to be able to build a value; it's ether all manually typed in or 
all gotten from another source.  This would mean actually storing "psk=" as a attribute value in your AD. Obviously not that hard to do if you 
are already writing your own interface to get items into AD in the first place.


What I am unsure about is the ability to actually send back a value you get 
from AD in the RADIUS return result.  While in ISE I can choose a AD attribute 
from the selection criteria I don't know if it will actually send the value for 
the particular user/device or just the attribute name from AD.  I have seen ISE 
allow you to select things like AD:Objectname but instead of it returning a 
value it returns "AD:Objectname".  It's been years since I have used ACS but 
recall it working similar when building your rules and return results.


It is worth testing in a lab to see what it will actually return, if its the 
actual value from AD i'd say your good to go.


Nick



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Hunter Fuller <hf0...@uah.edu>
Sent: Friday, August 4, 2017 4:59 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

You're right, I had misread that.

Upon reading it that way, though, isn't that fine too? The person's device 
reports its MAC, and then ACS or any other RADIUS just responds with that MAC's 
owner's assigned PSK. If the device's MAC isn't known, we just respond with an 
empty or garbage PSK to prevent them authenticating.

On Fri, Aug 4, 2017 at 4:13 PM Ciesinski, Nick 
<ciesi...@uww.edu<mailto:ciesi...@uww.edu>> wrote:
I think your going to have the same problem with ACS as there is with ISE.  The 
controller does not send the PSK the user used to the RADIUS server for 
verification/validation.  Instead the RADIUS server will send back the PSK 
value the user/device should be using and the WLC does the 
verification/validation based on that return value.

Nick

On Aug 4, 2017, at 4:02 PM, Hunter Fuller 
<hf0...@uah.edu<mailto:hf0...@uah.edu>> wrote:

Yep - we use Cisco ACS, backed with AD. Should be able to just add another rule 
to our ruleset, then configure iPSK on the controllers. Then it would check the 
PSK against AD, as the machine password for the machine account. (We already 
make machine accounts for registered MACs of game consoles, etc.)

On Wed, Aug 2, 2017 at 7:31 PM Joachim Tingvold 
<joac...@tingvold.com<mailto:joac...@tingvold.com>> wrote:
On 1 Aug 2017, at 17:33, Ciesinski, Nick wrote:
> While WLC 8.5 did add IPSK it is probably safe to say its rather
> worthless for most at this time.  For those who have used ISE if you
> watch the video on how they make IPSK work it isn’t feasible to give
> each of your users their own PSK key to connect to wireless.  The
> current implementation within ISE required no feature additions to ISE
> to make it work.  All they do is have a rule to classify a device
> and/or user and then send a particular PSK value that it should be
> using.  This is a 100% manual process  for each device and/or user as
> nothing is baked into ISE to have a user register their account or
> device(s) and be presented a PSK to use.

IPSK *and* ISE might be "worthless" when combined, but IPSK in it self
is not (even in it's current implementation). The limitations you're
talking about is purely with ISE, and not IPSK.

We use ClearPass, and we can easily query an SQL-server with MAC<->PSK
mappings, yielding unique PSKs based on MAC-adresses. This SQL DB could
be fed via whatever systems that already exists (CMDB or whatnot), or
you could spend an hour making a simple web-frontend.

The only thing holding us back upgrading to 8.5 "right away" (only to
get IPSK) is the same concern Lee has; not touching it until MR3 or
similar, purely for stability reasons (-:

--
Joachim

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

--
Hunter Fuller
Network Engineer
VBH Annex B-5
+1 256 824 5331<tel:(256)%20824-5331>

Office of Information Technology
The University of Alabama in Huntsville
Systems and Infrastructure
** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found

Re: [WIRELESS-LAN] Cisco Code Version

[Hunter Fuller]

You're right, I had misread that.

Upon reading it that way, though, isn't that fine too? The person's device
reports its MAC, and then ACS or any other RADIUS just responds with that
MAC's owner's assigned PSK. If the device's MAC isn't known, we just
respond with an empty or garbage PSK to prevent them authenticating.

On Fri, Aug 4, 2017 at 4:13 PM Ciesinski, Nick  wrote:

> I think your going to have the same problem with ACS as there is with
> ISE.  The controller does not send the PSK the user used to the RADIUS
> server for verification/validation.  Instead the RADIUS server will send
> back the PSK value the user/device should be using and the WLC does the
> verification/validation based on that return value.
>
> Nick
>
> On Aug 4, 2017, at 4:02 PM, Hunter Fuller  wrote:
>
> Yep - we use Cisco ACS, backed with AD. Should be able to just add another
> rule to our ruleset, then configure iPSK on the controllers. Then it would
> check the PSK against AD, as the machine password for the machine account.
> (We already make machine accounts for registered MACs of game consoles,
> etc.)
>
> On Wed, Aug 2, 2017 at 7:31 PM Joachim Tingvold 
> wrote:
>
>> On 1 Aug 2017, at 17:33, Ciesinski, Nick wrote:
>> > While WLC 8.5 did add IPSK it is probably safe to say its rather
>> > worthless for most at this time.  For those who have used ISE if you
>> > watch the video on how they make IPSK work it isn’t feasible to give
>> > each of your users their own PSK key to connect to wireless.  The
>> > current implementation within ISE required no feature additions to ISE
>> > to make it work.  All they do is have a rule to classify a device
>> > and/or user and then send a particular PSK value that it should be
>> > using.  This is a 100% manual process  for each device and/or user as
>> > nothing is baked into ISE to have a user register their account or
>> > device(s) and be presented a PSK to use.
>>
>> IPSK *and* ISE might be "worthless" when combined, but IPSK in it self
>> is not (even in it's current implementation). The limitations you're
>> talking about is purely with ISE, and not IPSK.
>>
>> We use ClearPass, and we can easily query an SQL-server with MAC<->PSK
>> mappings, yielding unique PSKs based on MAC-adresses. This SQL DB could
>> be fed via whatever systems that already exists (CMDB or whatnot), or
>> you could spend an hour making a simple web-frontend.
>>
>> The only thing holding us back upgrading to 8.5 "right away" (only to
>> get IPSK) is the same concern Lee has; not touching it until MR3 or
>> similar, purely for stability reasons (-:
>>
>> --
>> Joachim
>>
>> **
>> Participation and subscription information for this EDUCAUSE Constituent
>> Group discussion list can be found at http://www.educause.edu/discuss.
>>
> --
>
> --
> Hunter Fuller
> Network Engineer
> VBH Annex B-5
> +1 256 824 5331 <(256)%20824-5331>
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Systems and Infrastructure
> ** 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.
>
> --

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

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

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

Re: [WIRELESS-LAN] Cisco Code Version

[Ciesinski, Nick]

I think your going to have the same problem with ACS as there is with ISE.  The 
controller does not send the PSK the user used to the RADIUS server for 
verification/validation.  Instead the RADIUS server will send back the PSK 
value the user/device should be using and the WLC does the 
verification/validation based on that return value.

Nick

On Aug 4, 2017, at 4:02 PM, Hunter Fuller 
> wrote:

Yep - we use Cisco ACS, backed with AD. Should be able to just add another rule 
to our ruleset, then configure iPSK on the controllers. Then it would check the 
PSK against AD, as the machine password for the machine account. (We already 
make machine accounts for registered MACs of game consoles, etc.)

On Wed, Aug 2, 2017 at 7:31 PM Joachim Tingvold 
> wrote:
On 1 Aug 2017, at 17:33, Ciesinski, Nick wrote:
> While WLC 8.5 did add IPSK it is probably safe to say its rather
> worthless for most at this time.  For those who have used ISE if you
> watch the video on how they make IPSK work it isn’t feasible to give
> each of your users their own PSK key to connect to wireless.  The
> current implementation within ISE required no feature additions to ISE
> to make it work.  All they do is have a rule to classify a device
> and/or user and then send a particular PSK value that it should be
> using.  This is a 100% manual process  for each device and/or user as
> nothing is baked into ISE to have a user register their account or
> device(s) and be presented a PSK to use.

IPSK *and* ISE might be "worthless" when combined, but IPSK in it self
is not (even in it's current implementation). The limitations you're
talking about is purely with ISE, and not IPSK.

We use ClearPass, and we can easily query an SQL-server with MAC<->PSK
mappings, yielding unique PSKs based on MAC-adresses. This SQL DB could
be fed via whatever systems that already exists (CMDB or whatnot), or
you could spend an hour making a simple web-frontend.

The only thing holding us back upgrading to 8.5 "right away" (only to
get IPSK) is the same concern Lee has; not touching it until MR3 or
similar, purely for stability reasons (-:

--
Joachim

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

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

Office of Information Technology
The University of Alabama in Huntsville
Systems and Infrastructure
** 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] Cisco Code Version

[Hunter Fuller]

Yep - we use Cisco ACS, backed with AD. Should be able to just add another
rule to our ruleset, then configure iPSK on the controllers. Then it would
check the PSK against AD, as the machine password for the machine account.
(We already make machine accounts for registered MACs of game consoles,
etc.)

On Wed, Aug 2, 2017 at 7:31 PM Joachim Tingvold 
wrote:

> On 1 Aug 2017, at 17:33, Ciesinski, Nick wrote:
> > While WLC 8.5 did add IPSK it is probably safe to say its rather
> > worthless for most at this time.  For those who have used ISE if you
> > watch the video on how they make IPSK work it isn’t feasible to give
> > each of your users their own PSK key to connect to wireless.  The
> > current implementation within ISE required no feature additions to ISE
> > to make it work.  All they do is have a rule to classify a device
> > and/or user and then send a particular PSK value that it should be
> > using.  This is a 100% manual process  for each device and/or user as
> > nothing is baked into ISE to have a user register their account or
> > device(s) and be presented a PSK to use.
>
> IPSK *and* ISE might be "worthless" when combined, but IPSK in it self
> is not (even in it's current implementation). The limitations you're
> talking about is purely with ISE, and not IPSK.
>
> We use ClearPass, and we can easily query an SQL-server with MAC<->PSK
> mappings, yielding unique PSKs based on MAC-adresses. This SQL DB could
> be fed via whatever systems that already exists (CMDB or whatnot), or
> you could spend an hour making a simple web-frontend.
>
> The only thing holding us back upgrading to 8.5 "right away" (only to
> get IPSK) is the same concern Lee has; not touching it until MR3 or
> similar, purely for stability reasons (-:
>
> --
> Joachim
>
> **
> Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/discuss.
>
-- 

--
Hunter Fuller
Network Engineer
VBH Annex B-5
+1 256 824 5331 <(256)%20824-5331>

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

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

Re: [WIRELESS-LAN] Cisco Code Version

[Joachim Tingvold]

On 1 Aug 2017, at 17:33, Ciesinski, Nick wrote:
While WLC 8.5 did add IPSK it is probably safe to say its rather 
worthless for most at this time.  For those who have used ISE if you 
watch the video on how they make IPSK work it isn’t feasible to give 
each of your users their own PSK key to connect to wireless.  The 
current implementation within ISE required no feature additions to ISE 
to make it work.  All they do is have a rule to classify a device 
and/or user and then send a particular PSK value that it should be 
using.  This is a 100% manual process  for each device and/or user as 
nothing is baked into ISE to have a user register their account or 
device(s) and be presented a PSK to use.


IPSK *and* ISE might be "worthless" when combined, but IPSK in it self 
is not (even in it's current implementation). The limitations you're 
talking about is purely with ISE, and not IPSK.


We use ClearPass, and we can easily query an SQL-server with MAC<->PSK 
mappings, yielding unique PSKs based on MAC-adresses. This SQL DB could 
be fed via whatever systems that already exists (CMDB or whatnot), or 
you could spend an hour making a simple web-frontend.


The only thing holding us back upgrading to 8.5 "right away" (only to 
get IPSK) is the same concern Lee has; not touching it until MR3 or 
similar, purely for stability reasons (-:


--
Joachim

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

RE: [WIRELESS-LAN] Cisco Code Version

[Lee H Badman]

Well said, Jake.

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jake Snyder
Sent: Wednesday, August 02, 2017 11:24 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

One of the things as a partner I try to educate customers on is “who is 
recommending what, and why.”

My experience has been that the BU is trying to drive feature adoption, sell 
APs and controllers.  That’s why they exist, so don’t fault them for it.  They 
tend to recommend new APs, new versions of code and new features.  Why?  
Because they are in the business of selling.

Tac is all about which code results in defects are going to generate the least 
amount of tickets, and hopefully that means more stability.

As a partner I try to ride the line.  I tend to determine a customer’s appetite 
for risk, longevity, their market and their staff capability. This puts them 
into 3 buckets: proven technology only, moderate, and bleeding edge.  I’m 
accountable if I recommend something and it doesn’t work well, so I tend to be 
more conservative.  Bleeding edge gets you further in a lifecycle if equipment, 
but you better be prepared to deal with some bugs in the short term.

And I sit down and talk with them about why I feel they should be buying and 
operating in the bucket that makes sense for them.  Ultimately they make the 
buying decision.  Sometimes things bite me, it happens.  But it happens less 
and less over time.

For those of you who are feeling the pain, somehow you are listening to the 
wrong folks, buying outside the bucket that fits your org, or the person 
helping you with that decision is looking at things in a way that doesn’t align 
with your business.

Having the relationship with the BU is important.  Know how to work with Tac 
and having a trusted partner is also important.  And ultimately the you, the 
customer gets to make that decision on where and how you go.
Sent from my iPhone

On Aug 2, 2017, at 8:54 AM, Jeffrey D. Sessler 
<j...@scrippscollege.edu<mailto:j...@scrippscollege.edu>> wrote:
Lee,

I can only speak to my experience, and in the case of the x800 series, we were 
a first-customer-ship and had them in production in Aug 2016. I ran into a few 
bugs, mostly stuck radios, but with direct engagement with the BU, I was 
getting code fixes (or viable workarounds) within hours. I was also having 
weekly meetings with the BU engineering team, and my local SE and SE manager 
were on top of it. I have a similar relationship with the PI team, although PI 
has been solid for me for a long time, and I use the channel mostly for 
enhancement requests.

For the size of your deployment, I’d pursue the same direct relationship with 
the BU. As customers, we can either say to Cisco, “Hey, you have mind reading 
skills so figure it out” or, we can engage directly in an attempt to make the 
product better. I choose the later since I know how complex these systems are 
and I’d rather do my part to improve the product.

On the feature side, I divide items into “essentials” and “fluff”, and I put 
AVC in the “fluff” category. Yes, it’s nice to have, but I can get this 
information from other sources and it’s not necessary to provide the base 
service i.e. I leave the controllers dedicated to the essentials. I suspect a 
lot of customers do the same, so there isn’t the same amount of 
testing/feedback on that feature – thanks for the 400 hours dedicated to fixing 
it. Additionally, on the development bug-resolution front, if I was Cisco, I’d 
prioritize fixing the essentials over the fluff. On the positive side, with the 
AVC off-load features in the new WAPs, controllers should do much better with 
AVC moving forward.

Someday I’d love to compare notes. Somehow, we seem to be dating the same girl, 
yet she’s totally different when she’s with me vs when she’s with you. Maybe a 
nice box of chocolates is in order? LOL ;-)

Jeff



From: 
"wireless-lan@listserv.educause.edu<mailto:wireless-lan@listserv.educause.edu>" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "lhbad...@syr.edu<mailto:lhbad...@syr.edu>" 
<lhbad...@syr.edu<mailto:lhbad...@syr.edu>>
Reply-To: 
"wireless-lan@listserv.educause.edu<mailto:wireless-lan@listserv.educause.edu>" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Wednesday, August 2, 2017 at 6:04 AM
To: 
"wireless-lan@listserv.educause.edu<mailto:wireless-lan@listserv.educause.edu>" 
<WIRELESS-LAN@LISTSERV.E

Re: [WIRELESS-LAN] Cisco Code Version

[Jake Snyder]

One of the things as a partner I try to educate customers on is “who is 
recommending what, and why.”

My experience has been that the BU is trying to drive feature adoption, sell 
APs and controllers.  That’s why they exist, so don’t fault them for it.  They 
tend to recommend new APs, new versions of code and new features.  Why?  
Because they are in the business of selling.

Tac is all about which code results in defects are going to generate the least 
amount of tickets, and hopefully that means more stability.

As a partner I try to ride the line.  I tend to determine a customer’s appetite 
for risk, longevity, their market and their staff capability. This puts them 
into 3 buckets: proven technology only, moderate, and bleeding edge.  I’m 
accountable if I recommend something and it doesn’t work well, so I tend to be 
more conservative.  Bleeding edge gets you further in a lifecycle if equipment, 
but you better be prepared to deal with some bugs in the short term.

And I sit down and talk with them about why I feel they should be buying and 
operating in the bucket that makes sense for them.  Ultimately they make the 
buying decision.  Sometimes things bite me, it happens.  But it happens less 
and less over time.

For those of you who are feeling the pain, somehow you are listening to the 
wrong folks, buying outside the bucket that fits your org, or the person 
helping you with that decision is looking at things in a way that doesn’t align 
with your business.

Having the relationship with the BU is important.  Know how to work with Tac 
and having a trusted partner is also important.  And ultimately the you, the 
customer gets to make that decision on where and how you go.

Sent from my iPhone

> On Aug 2, 2017, at 8:54 AM, Jeffrey D. Sessler <j...@scrippscollege.edu> 
> wrote:
> 
> Lee,
>  
> I can only speak to my experience, and in the case of the x800 series, we 
> were a first-customer-ship and had them in production in Aug 2016. I ran into 
> a few bugs, mostly stuck radios, but with direct engagement with the BU, I 
> was getting code fixes (or viable workarounds) within hours. I was also 
> having weekly meetings with the BU engineering team, and my local SE and SE 
> manager were on top of it. I have a similar relationship with the PI team, 
> although PI has been solid for me for a long time, and I use the channel 
> mostly for enhancement requests.
>  
> For the size of your deployment, I’d pursue the same direct relationship with 
> the BU. As customers, we can either say to Cisco, “Hey, you have mind reading 
> skills so figure it out” or, we can engage directly in an attempt to make the 
> product better. I choose the later since I know how complex these systems are 
> and I’d rather do my part to improve the product.
>  
> On the feature side, I divide items into “essentials” and “fluff”, and I put 
> AVC in the “fluff” category. Yes, it’s nice to have, but I can get this 
> information from other sources and it’s not necessary to provide the base 
> service i.e. I leave the controllers dedicated to the essentials. I suspect a 
> lot of customers do the same, so there isn’t the same amount of 
> testing/feedback on that feature – thanks for the 400 hours dedicated to 
> fixing it. Additionally, on the development bug-resolution front, if I was 
> Cisco, I’d prioritize fixing the essentials over the fluff. On the positive 
> side, with the AVC off-load features in the new WAPs, controllers should do 
> much better with AVC moving forward.
>  
> Someday I’d love to compare notes. Somehow, we seem to be dating the same 
> girl, yet she’s totally different when she’s with me vs when she’s with you. 
> Maybe a nice box of chocolates is in order? LOL ;-)
>  
> Jeff
>  
>  
>  
> From: "wireless-lan@listserv.educause.edu" 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of "lhbad...@syr.edu" 
> <lhbad...@syr.edu>
> Reply-To: "wireless-lan@listserv.educause.edu" 
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> Date: Wednesday, August 2, 2017 at 6:04 AM
> To: "wireless-lan@listserv.educause.edu" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> Subject: Re: [WIRELESS-LAN] Cisco Code Version
>  
> I value what Jeff is doing with Beta, but also have to agree with James. 
> Universities might be different- but we’re not THAT different that 
> controllers and APs should crumble after all these years and generations of 
> vendor offerings. I find code updates can be problematic, too many APs dump 
> back to factory defaults, etc. And we’ve been particularly burned by:
>  
> 8510s did not live up to spec when running AVC
> 8540s gave great results with AVC, to a certain code version, then it failed 
> hard. 400+ TAC/engineering hours (and at least three “now try THIS co

RE: [WIRELESS-LAN] Cisco Code Version

[Lee H Badman]

I think one area where we may have philosophical differences is in how much 
time a vendor relationship should require. We are a small, hopefully 
well-trained and experienced team that accomplishes a lot. We try to choose 
COTS solutions that don’t require a lot of admin overhead. The depth of your 
engagement as described equals a fair amount of OpEx- the hours spent working 
for Cisco are hours not spent elsewhere. If you’re staffed for it and have the 
time, I can see where essentially being auxiliary Cisco QA staff would work. 
It’s always better to be chummy than to feel like a whipping boy.

We try to be good partners when it comes time for support cases and feature 
requests, etc. We contribute to a number of NDA feedback sessions on product 
development, and all that- But a cordial relationship (for me) does not 
exonerate the shipping gear from needing to be solid out of the box- it’s not 
open source, after all.

I have to disagree on AVC. One man’s fluff may be another man’s requirement. If 
the vendor markets it as a feature, then it’s a feature. We had operational 
reasons to use AVC, and I can’t buy into Cisco getting a free pass on its 
inadequacies.  If it’s on the data sheet, it’s expected to work. Otherwise, the 
only answer is for Cisco- not you or I or The Muffin Man- to classify what’s 
essential and what’s fluff.

I promise the vendor doesn’t have to read my mind- we work with them on every 
pain point we hit, but at times we have to take control of the situation when 
the engagement runs too long or gets too negatively impactful.

Different perspectives… it’s all good.

-Lee



Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jeffrey D. Sessler
Sent: Wednesday, August 02, 2017 10:55 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

Lee,

I can only speak to my experience, and in the case of the x800 series, we were 
a first-customer-ship and had them in production in Aug 2016. I ran into a few 
bugs, mostly stuck radios, but with direct engagement with the BU, I was 
getting code fixes (or viable workarounds) within hours. I was also having 
weekly meetings with the BU engineering team, and my local SE and SE manager 
were on top of it. I have a similar relationship with the PI team, although PI 
has been solid for me for a long time, and I use the channel mostly for 
enhancement requests.

For the size of your deployment, I’d pursue the same direct relationship with 
the BU. As customers, we can either say to Cisco, “Hey, you have mind reading 
skills so figure it out” or, we can engage directly in an attempt to make the 
product better. I choose the later since I know how complex these systems are 
and I’d rather do my part to improve the product.

On the feature side, I divide items into “essentials” and “fluff”, and I put 
AVC in the “fluff” category. Yes, it’s nice to have, but I can get this 
information from other sources and it’s not necessary to provide the base 
service i.e. I leave the controllers dedicated to the essentials. I suspect a 
lot of customers do the same, so there isn’t the same amount of 
testing/feedback on that feature – thanks for the 400 hours dedicated to fixing 
it. Additionally, on the development bug-resolution front, if I was Cisco, I’d 
prioritize fixing the essentials over the fluff. On the positive side, with the 
AVC off-load features in the new WAPs, controllers should do much better with 
AVC moving forward.

Someday I’d love to compare notes. Somehow, we seem to be dating the same girl, 
yet she’s totally different when she’s with me vs when she’s with you. Maybe a 
nice box of chocolates is in order? LOL ;-)

Jeff



From: 
"wireless-lan@listserv.educause.edu<mailto:wireless-lan@listserv.educause.edu>" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "lhbad...@syr.edu<mailto:lhbad...@syr.edu>" 
<lhbad...@syr.edu<mailto:lhbad...@syr.edu>>
Reply-To: 
"wireless-lan@listserv.educause.edu<mailto:wireless-lan@listserv.educause.edu>" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Wednesday, August 2, 2017 at 6:04 AM
To: 
"wireless-lan@listserv.educause.edu<mailto:wireless-lan@listserv.educause.edu>" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

I value what Jeff is doing with Beta, but also have to agree with James. 
Universities might be different- but we’re not THAT diff

Re: [WIRELESS-LAN] Cisco Code Version

[Jeffrey D. Sessler]

Lee,

I can only speak to my experience, and in the case of the x800 series, we were 
a first-customer-ship and had them in production in Aug 2016. I ran into a few 
bugs, mostly stuck radios, but with direct engagement with the BU, I was 
getting code fixes (or viable workarounds) within hours. I was also having 
weekly meetings with the BU engineering team, and my local SE and SE manager 
were on top of it. I have a similar relationship with the PI team, although PI 
has been solid for me for a long time, and I use the channel mostly for 
enhancement requests.

For the size of your deployment, I’d pursue the same direct relationship with 
the BU. As customers, we can either say to Cisco, “Hey, you have mind reading 
skills so figure it out” or, we can engage directly in an attempt to make the 
product better. I choose the later since I know how complex these systems are 
and I’d rather do my part to improve the product.

On the feature side, I divide items into “essentials” and “fluff”, and I put 
AVC in the “fluff” category. Yes, it’s nice to have, but I can get this 
information from other sources and it’s not necessary to provide the base 
service i.e. I leave the controllers dedicated to the essentials. I suspect a 
lot of customers do the same, so there isn’t the same amount of 
testing/feedback on that feature – thanks for the 400 hours dedicated to fixing 
it. Additionally, on the development bug-resolution front, if I was Cisco, I’d 
prioritize fixing the essentials over the fluff. On the positive side, with the 
AVC off-load features in the new WAPs, controllers should do much better with 
AVC moving forward.

Someday I’d love to compare notes. Somehow, we seem to be dating the same girl, 
yet she’s totally different when she’s with me vs when she’s with you. Maybe a 
nice box of chocolates is in order? LOL ;-)

Jeff



From: "wireless-lan@listserv.educause.edu" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
on behalf of "lhbad...@syr.edu" <lhbad...@syr.edu>
Reply-To: "wireless-lan@listserv.educause.edu" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Date: Wednesday, August 2, 2017 at 6:04 AM
To: "wireless-lan@listserv.educause.edu" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

I value what Jeff is doing with Beta, but also have to agree with James. 
Universities might be different- but we’re not THAT different that controllers 
and APs should crumble after all these years and generations of vendor 
offerings. I find code updates can be problematic, too many APs dump back to 
factory defaults, etc. And we’ve been particularly burned by:


  *   8510s did not live up to spec when running AVC
  *   8540s gave great results with AVC, to a certain code version, then it 
failed hard. 400+ TAC/engineering hours (and at least three “now try THIS code” 
go rounds) later, we stopped using AVC.  Couldn’t go back to the code that used 
to work because it didn’t support the APs we were now using.
  *   Too many TAC cases drag on far too long for both PI and WLC
  *   The assumption is that you will leave your network in duress- possibly 
impacting thousands of customers- during lengthy debugs
  *   Too many problems happen only at large scale, so even lab-testing doesn’t 
find them first
  *   Too many escalation builds
  *   Code out there for download that really ought to have warnings about its 
use
  *   Mixed messages from SEs, TAC, and Cisco partners on what code can be 
trusted or not

If colleges/universities are so challenging, seems like Cisco should have a 
design guide by now that incorporates the differences to head off the problems. 
And if large-scale networks are problematic, then the recommendation should be 
to reduce large networks to multiple small ones using smaller controllers. 
Whatever the case, we’ve had countless cycles of hearing contrition (“yes, we 
need to do better on our code bugs.. and we will!”) but it never seems to get 
there.  The 3800 rollout was a debacle- these awesome APs were overshadowed by 
poor code for almost a full year before there was code that you could actually 
take a chance on. Cisco isn’t a start-up, and it just feels like either AireOS 
was never that good, or somebody is way too eager to bloat it up with endless 
features at the expense of stability.

At my end, the overarching philosophy is Stability Above All, because we’re 
years into the WLAN being a critical resource. It just feels like that isn’t 
really embraced by the vendor.

Like with the early days of the 3800 AP, it would be nice to be able to look 
forward at Fabric-Enabled Whatever and actually be impressed and excited. But 
when we’re juggling constant WLC/AP bugs, features we can’t use because they 
break and no one can figure out why, the perception of a development culture 
that isn’t doing much to improve the bug front, and recently an increase in 
switch/PoE bugs, it’s really hard to get enthused a

RE: [WIRELESS-LAN] Cisco Code Version

[Lee H Badman]

I value what Jeff is doing with Beta, but also have to agree with James. 
Universities might be different- but we’re not THAT different that controllers 
and APs should crumble after all these years and generations of vendor 
offerings. I find code updates can be problematic, too many APs dump back to 
factory defaults, etc. And we’ve been particularly burned by:


-  8510s did not live up to spec when running AVC

-  8540s gave great results with AVC, to a certain code version, then 
it failed hard. 400+ TAC/engineering hours (and at least three “now try THIS 
code” go rounds) later, we stopped using AVC.  Couldn’t go back to the code 
that used to work because it didn’t support the APs we were now using.

-  Too many TAC cases drag on far too long for both PI and WLC

-  The assumption is that you will leave your network in duress- 
possibly impacting thousands of customers- during lengthy debugs

-  Too many problems happen only at large scale, so even lab-testing 
doesn’t find them first

-  Too many escalation builds

-  Code out there for download that really ought to have warnings about 
its use

-  Mixed messages from SEs, TAC, and Cisco partners on what code can be 
trusted or not

If colleges/universities are so challenging, seems like Cisco should have a 
design guide by now that incorporates the differences to head off the problems. 
And if large-scale networks are problematic, then the recommendation should be 
to reduce large networks to multiple small ones using smaller controllers. 
Whatever the case, we’ve had countless cycles of hearing contrition (“yes, we 
need to do better on our code bugs.. and we will!”) but it never seems to get 
there.  The 3800 rollout was a debacle- these awesome APs were overshadowed by 
poor code for almost a full year before there was code that you could actually 
take a chance on. Cisco isn’t a start-up, and it just feels like either AireOS 
was never that good, or somebody is way too eager to bloat it up with endless 
features at the expense of stability.

At my end, the overarching philosophy is Stability Above All, because we’re 
years into the WLAN being a critical resource. It just feels like that isn’t 
really embraced by the vendor.

Like with the early days of the 3800 AP, it would be nice to be able to look 
forward at Fabric-Enabled Whatever and actually be impressed and excited. But 
when we’re juggling constant WLC/AP bugs, features we can’t use because they 
break and no one can figure out why, the perception of a development culture 
that isn’t doing much to improve the bug front, and recently an increase in 
switch/PoE bugs, it’s really hard to get enthused about adding APIs into 
components that already have long-running issues.

We keep it on the rails for our almost 30K-daily-peak clients, but sometimes it 
can be maddening in ways that you just don’t get on any other product set.

-Lee



Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James Helzerman
Sent: Wednesday, August 02, 2017 7:57 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

With your beta controller how many access points and concurrent device 
connections are you able to test?

We are setting up a similar scenario, not so much for beta testing as for a 
stepping stone to upgrades of our campus controllers.  The controller pair are 
8540s and should have 250-300 APs with around 1000+ devices.  The user base is 
our IT folks in 3 locations so we hope to get good feedback.

I agree that edu is a unique beast for wi-fi but in the end it's seems some 
core functions are what is failing us such as code upgrades and APs stuck in 
CAPWAP flapping state that require the switch ports to be bounced.

Jimmy

On Aug 2, 2017 3:00 AM, "Jeffrey D. Sessler" 
<j...@scrippscollege.edu<mailto:j...@scrippscollege.edu>> wrote:
I participate in the betas and even run a beta controller in production. This 
is complex stuff, and especially in EDU, we see things that no enterprise 
customer will even encounter – or test bed can simulate. For the most part, 
I’ve had no show-stopper issues going back to the post 5.2 days. That said, I 
keep a very open and direct dialog with the BU, and with something like the 
x800 series WAPs, my team did a lot of testing of the product to help get all 
the little bugs worked out.

Jeff

From: 
"wireless-lan@listserv.educause.edu<mailto:wireless-lan@listserv.educause.edu>" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on 

Re: [WIRELESS-LAN] Cisco Code Version

[James Helzerman]

With your beta controller how many access points and concurrent device
connections are you able to test?

We are setting up a similar scenario, not so much for beta testing as for a
stepping stone to upgrades of our campus controllers.  The controller pair
are 8540s and should have 250-300 APs with around 1000+ devices.  The user
base is our IT folks in 3 locations so we hope to get good feedback.

I agree that edu is a unique beast for wi-fi but in the end it's seems some
core functions are what is failing us such as code upgrades and APs stuck
in CAPWAP flapping state that require the switch ports to be bounced.

Jimmy

On Aug 2, 2017 3:00 AM, "Jeffrey D. Sessler" <j...@scrippscollege.edu>
wrote:

> I participate in the betas and even run a beta controller in production.
> This is complex stuff, and especially in EDU, we see things that no
> enterprise customer will even encounter – or test bed can simulate. For the
> most part, I’ve had no show-stopper issues going back to the post 5.2 days.
> That said, I keep a very open and direct dialog with the BU, and with
> something like the x800 series WAPs, my team did a lot of testing of the
> product to help get all the little bugs worked out.
>
>
>
> Jeff
>
>
>
> *From: *"wireless-lan@listserv.educause.edu" <WIRELESS-LAN@LISTSERV.
> EDUCAUSE.EDU> on behalf of James Helzerman <jarh...@umich.edu>
> *Reply-To: *"wireless-lan@listserv.educause.edu" <WIRELESS-LAN@LISTSERV.
> EDUCAUSE.EDU>
> *Date: *Tuesday, August 1, 2017 at 3:39 PM
> *To: *"wireless-lan@listserv.educause.edu" <WIRELESS-LAN@LISTSERV.
> EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] Cisco Code Version
>
>
>
> I feel like we might be used as QA..anyone else?
>
>
>
> On Aug 1, 2017 6:32 PM, "Mccormick, Kevin" <ke-mccorm...@wiu.edu> wrote:
>
> They just released 8.2.160.0. They have not vetted the release as being
> stable. They will recommend after enough downloads and not a lot of bug
> issues.
>
>
> Kevin McCormick
> <https://www.youracclaim.com/badges/3aa51624-4156-498d-bf6f-4a61790d54cf/public_url>
>
> Network Administrator
>
> University Technology - Western Illinois University
>
> ke-mccorm...@wiu.edu | (309) 298-1335 <3092981335> | Morgan Hall 106b
>
> Connect with uTech: Website <http://www.wiu.edu/utech> | Facebook
> <https://www.facebook.com/uTechWIU> | Twitter
> <https://twitter.com/WIU_uTech>
>
>
>
> On Tue, Aug 1, 2017 at 4:00 PM, Marcelo Maraboli <marcelo.marab...@uc.cl>
> wrote:
>
> Hello all
>
> I wonder why CISCO keeps 8.2.151 as "suggested" and not 8.2.160 ??
>
> just a precaution ?
>
> My Cisco partner is telling me to stay in 8.2.151 even if there is 8.5.x
> code our there.
>
>
> what's your opinion ?
>
>
> regards,
>
> On 7/31/17 4:11 PM, Paul Thompson wrote:
>
>
> .160 fixes some real world SIP and 802.11r Fast Transition bugs, if you're
> using either of those features.  I was told by a coworker that the
> engineering prereleases of it had helped with some real life Apple
> connectivity tics, but have less detail on specifics of that.
>
> On Mon, 31 Jul 2017, Lee H Badman wrote:
>
>
>
> 151 here as well- is a bit frustrating that 160 just came out as we’re in
> our “freeze” period now for making changes, pre-semester. Other than the
> typical laundry list of cryptic bugs corrected, does anyone know if 160
> addresses any real-world, commonly impactful 3800-related bugs?
>
>
>
> Lee Badman | Network Architect
>
> Certified Wireless Network Expert (#200) Information Technology Services
> 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244
>
> t 315.443.3003 <(315)%20443-3003> f 315.443.4325 <(315)%20443-4325> e
> lhbad...@syr.edu w its.syr.edu
>
> SYRACUSE UNIVERSITY syr.edu
>
>
>
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of James Helzerman Sent:
> Monday, July 31, 2017 1:57 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: [WIRELESS-LAN] Cisco Code Version
>
>
>
> Hi.  For those with Cisco access points what code version are planning on
> running for start of fall semester?
>
>
>
> At this point we looking at 8.2.151 possibly 8.2.160 but havent tested
> yet.
>
>
>
> Thanks
>
>
>
> -Jimmy
>
>
>
> --
>
> James Helzerman Wireless Network Engineer University of Michigan - ITS
>
> Phone: 734-615-9541 <(734)%20615-9541>
>
> ** Participation and subscription information for this EDUCAUSE
> Constit

Re: [WIRELESS-LAN] Cisco Code Version

[Jeffrey D. Sessler]

I participate in the betas and even run a beta controller in production. This 
is complex stuff, and especially in EDU, we see things that no enterprise 
customer will even encounter – or test bed can simulate. For the most part, 
I’ve had no show-stopper issues going back to the post 5.2 days. That said, I 
keep a very open and direct dialog with the BU, and with something like the 
x800 series WAPs, my team did a lot of testing of the product to help get all 
the little bugs worked out.

Jeff

From: "wireless-lan@listserv.educause.edu" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
on behalf of James Helzerman <jarh...@umich.edu>
Reply-To: "wireless-lan@listserv.educause.edu" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Date: Tuesday, August 1, 2017 at 3:39 PM
To: "wireless-lan@listserv.educause.edu" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

I feel like we might be used as QA..anyone else?

On Aug 1, 2017 6:32 PM, "Mccormick, Kevin" 
<ke-mccorm...@wiu.edu<mailto:ke-mccorm...@wiu.edu>> wrote:
They just released 8.2.160.0. They have not vetted the release as being stable. 
They will recommend after enough downloads and not a lot of bug issues.

Kevin 
McCormick<https://www.youracclaim.com/badges/3aa51624-4156-498d-bf6f-4a61790d54cf/public_url>
Network Administrator
University Technology - Western Illinois University
ke-mccorm...@wiu.edu<mailto:ke-mccorm...@wiu.edu> | (309) 
298-1335 | Morgan Hall 106b
Connect with uTech: Website<http://www.wiu.edu/utech> | 
Facebook<https://www.facebook.com/uTechWIU> | 
Twitter<https://twitter.com/WIU_uTech>
[http://www.wiu.edu/university_technology/images/signatures/currentimage.jpg]

On Tue, Aug 1, 2017 at 4:00 PM, Marcelo Maraboli 
<marcelo.marab...@uc.cl<mailto:marcelo.marab...@uc.cl>> wrote:
Hello all

I wonder why CISCO keeps 8.2.151 as "suggested" and not 8.2.160 ??

just a precaution ?

My Cisco partner is telling me to stay in 8.2.151 even if there is 8.5.x code 
our there.


what's your opinion ?


regards,

On 7/31/17 4:11 PM, Paul Thompson wrote:

.160 fixes some real world SIP and 802.11r Fast Transition bugs, if you're 
using either of those features.  I was told by a coworker that the engineering 
prereleases of it had helped with some real life Apple connectivity tics, but 
have less detail on specifics of that.

On Mon, 31 Jul 2017, Lee H Badman wrote:



151 here as well- is a bit frustrating that 160 just came out as we’re in our 
“freeze” period now for making changes, pre-semester. Other than the typical 
laundry list of cryptic bugs corrected, does anyone know if 160 addresses any 
real-world, commonly impactful 3800-related bugs?



Lee Badman | Network Architect

Certified Wireless Network Expert (#200) Information Technology Services 206 
Machinery Hall 120 Smith Drive Syracuse, New York 13244

t 315.443.3003<tel:(315)%20443-3003> f 315.443.4325<tel:(315)%20443-4325> e 
lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu<http://its.syr.edu>

SYRACUSE UNIVERSITY syr.edu<http://syr.edu>



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James Helzerman Sent: 
Monday, July 31, 2017 1:57 PM To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
Subject: [WIRELESS-LAN] Cisco Code Version



Hi.  For those with Cisco access points what code version are planning on 
running for start of fall semester?



At this point we looking at 8.2.151 possibly 8.2.160 but havent tested yet.



Thanks



-Jimmy



--

James Helzerman Wireless Network Engineer University of Michigan - ITS

Phone: 734-615-9541<tel:(734)%20615-9541>

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




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

--
Marcelo Maraboli Rosselott
Subdirector de Redes y Seguridad
Dirección de Informática
Pontificia Universidad Católica de Chile
http://informatica.uc.cl/
--
Campus San Joaquín, Av. Vicuña Mackenna 4860, Macul
Santiago, Chile
Teléfono: (56) 22354 1341
** 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.

** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list 

RE: [WIRELESS-LAN] Cisco Code Version

[Jason Cook]

I agree Lee, certainly production 8.5 you wouldn’t be too keen to go with the 
first release. We have a dev environment and spare old hardware so I was 
planning to run it up in the old gear hoping to get to point of potential PRD 
July 18…. Which is more MR2 time though, we’ll see how quickly that software 
progresses.

That’s right Nick, the ISE method isn’t exactly the offering we want but 
hopefully that will progress by the time 8.5 is stable. I’m also hoping other 
vendors might come to the table, we are a Cloudpath customer and from what I 
can see they have the framework already to provide a good interface for 
supporting it…. I’ve put a feature request in but hopefully the Ruckus side 
doesn’t stop them supporting something like this.

One this IPSK would give us now is the ability to change a PSK without a big 
bang. We need to roll over our PSK’s, while one only has about 50 devices and 
the other is student accommodation and easily managed over a break it still 
doesn’t sound fun.

--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005
Ph: +61 8 8313 4800

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Ciesinski, Nick
Sent: Wednesday, 2 August 2017 1:04 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

While WLC 8.5 did add IPSK it is probably safe to say its rather worthless for 
most at this time.  For those who have used ISE if you watch the video on how 
they make IPSK work it isn’t feasible to give each of your users their own PSK 
key to connect to wireless.  The current implementation within ISE required no 
feature additions to ISE to make it work.  All they do is have a rule to 
classify a device and/or user and then send a particular PSK value that it 
should be using.  This is a 100% manual process  for each device and/or user as 
nothing is baked into ISE to have a user register their account or device(s) 
and be presented a PSK to use.

Whats there now is good for having multiple PSK’s for different device types or 
user bases (such as all students) it isn’t that PPSK solution like others have. 
 Hopefully a ISE improvement will come at some point in the near future to 
allow a true per user PSK experience.

Granted using a 3rd party RADIUS server and writing your own interface would 
allow you issue a PSK per user not everyone has time for that.

--
Nick Ciesinski, Network Architect
University of Wisconsin - Whitewater
Office: MG208A | Phone: 262-472-7774
E-mail: ciesi...@uww.edu<mailto:ciesi...@uww.edu> | SIP: 
ciesi...@uww.edu<mailto:ciesi...@uww.edu>
PGP Key ID: 0x83042F05
--

On Jul 31, 2017, at 11:13 PM, Jason Cook 
<jason.c...@adelaide.edu.au<mailto:jason.c...@adelaide.edu.au>> wrote:

Thanks, I am aware it’s any radius server so it seems I identified my issue a 
bit hastily./… or not at all ☺
It’s been a while since I played with an Aerohive AP but 3 years ago it was so 
easy to get this up and running on a single AP with different vlans and there’s 
self-registration as well. There were enterprise concerns about how that scales 
and redundancy back then and I haven’t followed the progress of that.

The radius method means it’s not quite an out of the box solution that was so 
simple with PPSK, but perhaps this is architecture requirements…  I guess it 
might be that easy if your using ICE. We are pretty keen to use this at some 
level, ideally with self-rego offering. Using freeradius I’m sure we can 
achieve this, but ongoing management could become interesting/a fair bit of 
development for the self-rego. No doubt we’ll look further into it in a couple 
of months once a few other priorities are ticked off

Regards

--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005
Ph: +61 8 8313 4800

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Samuel Clements
Sent: Tuesday, 1 August 2017 11:51 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

From the iPSK config guide at:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-5/b_Identity_PSK_Feature_Deployment_Guide.pdf

"IPSK can be configured on any AAA serer that supports Cisco av-pair."

 -Sam
This email sent from a mobile computing device. Please excuse typos and brevity.

On Jul 31, 2017, at 8:40 PM, Mccormick, Kevin 
<ke-mccorm...@wiu.edu<mailto:ke-mccorm...@wiu.edu>> wrote:
I just looked at the IPSK video from CIsco here.

https://www.youtube.com/watch?v=deEv-aNXfL0

Not 100% sure ISE is required by the sound of the video.

They say a radius serve such as ISE, and of course Cisco is going to try and 
sell you ISE.

They are using two Cisco-AV-Pairs which are psk-mode=ascii and psk=, 
along with MAC filtering and AAA override.

You may

RE: [WIRELESS-LAN] Cisco Code Version

[Jason Cook]

Sounds standard

--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005
Ph: +61 8 8313 4800

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James Helzerman
Sent: Wednesday, 2 August 2017 8:10 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

I feel like we might be used as QA..anyone else?

On Aug 1, 2017 6:32 PM, "Mccormick, Kevin" 
<ke-mccorm...@wiu.edu<mailto:ke-mccorm...@wiu.edu>> wrote:
They just released 8.2.160.0. They have not vetted the release as being stable. 
They will recommend after enough downloads and not a lot of bug issues.

Kevin 
McCormick<https://www.youracclaim.com/badges/3aa51624-4156-498d-bf6f-4a61790d54cf/public_url>
Network Administrator
University Technology - Western Illinois University
ke-mccorm...@wiu.edu<mailto:ke-mccorm...@wiu.edu> | (309) 
298-1335 | Morgan Hall 106b
Connect with uTech: Website<http://www.wiu.edu/utech> | 
Facebook<https://www.facebook.com/uTechWIU> | 
Twitter<https://twitter.com/WIU_uTech>
[http://www.wiu.edu/university_technology/images/signatures/currentimage.jpg]

On Tue, Aug 1, 2017 at 4:00 PM, Marcelo Maraboli 
<marcelo.marab...@uc.cl<mailto:marcelo.marab...@uc.cl>> wrote:
Hello all

I wonder why CISCO keeps 8.2.151 as "suggested" and not 8.2.160 ??

just a precaution ?

My Cisco partner is telling me to stay in 8.2.151 even if there is 8.5.x code 
our there.


what's your opinion ?


regards,

On 7/31/17 4:11 PM, Paul Thompson wrote:

.160 fixes some real world SIP and 802.11r Fast Transition bugs, if you're 
using either of those features.  I was told by a coworker that the engineering 
prereleases of it had helped with some real life Apple connectivity tics, but 
have less detail on specifics of that.

On Mon, 31 Jul 2017, Lee H Badman wrote:



151 here as well- is a bit frustrating that 160 just came out as we’re in our 
“freeze” period now for making changes, pre-semester. Other than the typical 
laundry list of cryptic bugs corrected, does anyone know if 160 addresses any 
real-world, commonly impactful 3800-related bugs?



Lee Badman | Network Architect

Certified Wireless Network Expert (#200) Information Technology Services 206 
Machinery Hall 120 Smith Drive Syracuse, New York 13244

t 315.443.3003<tel:(315)%20443-3003> f 315.443.4325<tel:(315)%20443-4325> e 
lhbad...@syr.edu<mailto:lhbad...@syr.edu> w its.syr.edu<http://its.syr.edu>

SYRACUSE UNIVERSITY syr.edu<http://syr.edu>



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James Helzerman Sent: 
Monday, July 31, 2017 1:57 PM To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
Subject: [WIRELESS-LAN] Cisco Code Version



Hi.  For those with Cisco access points what code version are planning on 
running for start of fall semester?



At this point we looking at 8.2.151 possibly 8.2.160 but havent tested yet.



Thanks



-Jimmy



--

James Helzerman Wireless Network Engineer University of Michigan - ITS

Phone: 734-615-9541<tel:(734)%20615-9541>

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




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

--
Marcelo Maraboli Rosselott
Subdirector de Redes y Seguridad
Dirección de Informática
Pontificia Universidad Católica de Chile
http://informatica.uc.cl/
--
Campus San Joaquín, Av. Vicuña Mackenna 4860, Macul
Santiago, Chile
Teléfono: (56) 22354 1341
** 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.

** 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] Cisco Code Version

[James Helzerman]

I feel like we might be used as QA..anyone else?

On Aug 1, 2017 6:32 PM, "Mccormick, Kevin" <ke-mccorm...@wiu.edu> wrote:

They just released 8.2.160.0. They have not vetted the release as being
stable. They will recommend after enough downloads and not a lot of bug
issues.

Kevin McCormick
<https://www.youracclaim.com/badges/3aa51624-4156-498d-bf6f-4a61790d54cf/public_url>
Network Administrator
University Technology - Western Illinois University
ke-mccorm...@wiu.edu | (309) 298-1335 <3092981335> | Morgan Hall 106b
Connect with uTech: Website <http://www.wiu.edu/utech> | Facebook
<https://www.facebook.com/uTechWIU> | Twitter
<https://twitter.com/WIU_uTech>


On Tue, Aug 1, 2017 at 4:00 PM, Marcelo Maraboli <marcelo.marab...@uc.cl>
wrote:

> Hello all
>
> I wonder why CISCO keeps 8.2.151 as "suggested" and not 8.2.160 ??
>
> just a precaution ?
>
> My Cisco partner is telling me to stay in 8.2.151 even if there is 8.5.x
> code our there.
>
>
> what's your opinion ?
>
>
> regards,
>
>
> On 7/31/17 4:11 PM, Paul Thompson wrote:
>
>
> .160 fixes some real world SIP and 802.11r Fast Transition bugs, if you're
> using either of those features.  I was told by a coworker that the
> engineering prereleases of it had helped with some real life Apple
> connectivity tics, but have less detail on specifics of that.
>
> On Mon, 31 Jul 2017, Lee H Badman wrote:
>
>
> 151 here as well- is a bit frustrating that 160 just came out as we’re in
> our “freeze” period now for making changes, pre-semester. Other than the
> typical laundry list of cryptic bugs corrected, does anyone know if 160
> addresses any real-world, commonly impactful 3800-related bugs?
>
>
>
> Lee Badman | Network Architect
>
> Certified Wireless Network Expert (#200) Information Technology Services
> 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244
>
> t 315.443.3003 <(315)%20443-3003> f 315.443.4325 <(315)%20443-4325> e
> lhbad...@syr.edu w its.syr.edu
>
> SYRACUSE UNIVERSITY syr.edu
>
>
>
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of James Helzerman Sent:
> Monday, July 31, 2017 1:57 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: [WIRELESS-LAN] Cisco Code Version
>
>
>
> Hi.  For those with Cisco access points what code version are planning on
> running for start of fall semester?
>
>
>
> At this point we looking at 8.2.151 possibly 8.2.160 but havent tested
> yet.
>
>
>
> Thanks
>
>
>
> -Jimmy
>
>
>
> --
>
> James Helzerman Wireless Network Engineer University of Michigan - ITS
>
> Phone: 734-615-9541 <(734)%20615-9541>
>
> ** 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.
>
>
>
>
>
> **
> Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/discuss.
>
>
> --
> *Marcelo Maraboli Rosselott*
> Subdirector de Redes y Seguridad
> Dirección de Informática
> Pontificia Universidad Católica de Chile
> http://informatica.uc.cl/
> --
> Campus San Joaquín, Av. Vicuña Mackenna 4860, Macul
> Santiago, Chile
> Teléfono: (56) 22354 1341
> ** 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.

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

Re: [WIRELESS-LAN] Cisco Code Version

[Mccormick, Kevin]

They just released 8.2.160.0. They have not vetted the release as being
stable. They will recommend after enough downloads and not a lot of bug
issues.

Kevin McCormick
<https://www.youracclaim.com/badges/3aa51624-4156-498d-bf6f-4a61790d54cf/public_url>
Network Administrator
University Technology - Western Illinois University
ke-mccorm...@wiu.edu | (309) 298-1335 <3092981335> | Morgan Hall 106b
Connect with uTech: Website <http://www.wiu.edu/utech> | Facebook
<https://www.facebook.com/uTechWIU> | Twitter
<https://twitter.com/WIU_uTech>


On Tue, Aug 1, 2017 at 4:00 PM, Marcelo Maraboli <marcelo.marab...@uc.cl>
wrote:

> Hello all
>
> I wonder why CISCO keeps 8.2.151 as "suggested" and not 8.2.160 ??
>
> just a precaution ?
>
> My Cisco partner is telling me to stay in 8.2.151 even if there is 8.5.x
> code our there.
>
>
> what's your opinion ?
>
>
> regards,
>
>
> On 7/31/17 4:11 PM, Paul Thompson wrote:
>
>
> .160 fixes some real world SIP and 802.11r Fast Transition bugs, if you're
> using either of those features.  I was told by a coworker that the
> engineering prereleases of it had helped with some real life Apple
> connectivity tics, but have less detail on specifics of that.
>
> On Mon, 31 Jul 2017, Lee H Badman wrote:
>
>
> 151 here as well- is a bit frustrating that 160 just came out as we’re in
> our “freeze” period now for making changes, pre-semester. Other than the
> typical laundry list of cryptic bugs corrected, does anyone know if 160
> addresses any real-world, commonly impactful 3800-related bugs?
>
>
>
> Lee Badman | Network Architect
>
> Certified Wireless Network Expert (#200) Information Technology Services
> 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244
>
> t 315.443.3003 <(315)%20443-3003> f 315.443.4325 <(315)%20443-4325> e
> lhbad...@syr.edu w its.syr.edu
>
> SYRACUSE UNIVERSITY syr.edu
>
>
>
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of James Helzerman Sent:
> Monday, July 31, 2017 1:57 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: [WIRELESS-LAN] Cisco Code Version
>
>
>
> Hi.  For those with Cisco access points what code version are planning on
> running for start of fall semester?
>
>
>
> At this point we looking at 8.2.151 possibly 8.2.160 but havent tested
> yet.
>
>
>
> Thanks
>
>
>
> -Jimmy
>
>
>
> --
>
> James Helzerman Wireless Network Engineer University of Michigan - ITS
>
> Phone: 734-615-9541 <(734)%20615-9541>
>
> ** 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.
>
>
>
>
>
> **
> Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/discuss.
>
>
> --
> *Marcelo Maraboli Rosselott*
> Subdirector de Redes y Seguridad
> Dirección de Informática
> Pontificia Universidad Católica de Chile
> http://informatica.uc.cl/
> --
> Campus San Joaquín, Av. Vicuña Mackenna 4860, Macul
> Santiago, Chile
> Teléfono: (56) 22354 1341
> ** 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] Cisco Code Version

[Trenton Hurt]

http://www.cisco.com/c/en/us/support/docs/wireless/wireless-lan-controller-software/200046-TAC-Recommended-AireOS.html#anc8


On Tue, Aug 1, 2017 at 5:00 PM Marcelo Maraboli <marcelo.marab...@uc.cl>
wrote:

> Hello all
>
> I wonder why CISCO keeps 8.2.151 as "suggested" and not 8.2.160 ??
>
> just a precaution ?
>
> My Cisco partner is telling me to stay in 8.2.151 even if there is 8.5.x
> code our there.
>
>
> what's your opinion ?
>
>
> regards,
>
>
> On 7/31/17 4:11 PM, Paul Thompson wrote:
>
>
> .160 fixes some real world SIP and 802.11r Fast Transition bugs, if you're
> using either of those features.  I was told by a coworker that the
> engineering prereleases of it had helped with some real life Apple
> connectivity tics, but have less detail on specifics of that.
>
> On Mon, 31 Jul 2017, Lee H Badman wrote:
>
>
> 151 here as well- is a bit frustrating that 160 just came out as we’re in
> our “freeze” period now for making changes, pre-semester. Other than the
> typical laundry list of cryptic bugs corrected, does anyone know if 160
> addresses any real-world, commonly impactful 3800-related bugs?
>
>
>
> Lee Badman | Network Architect
>
> Certified Wireless Network Expert (#200) Information Technology Services
> 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244
>
> t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu w its.syr.edu
>
> SYRACUSE UNIVERSITY syr.edu
>
>
>
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] On Behalf Of James Helzerman Sent:
> Monday, July 31, 2017 1:57 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: [WIRELESS-LAN] Cisco Code Version
>
>
>
> Hi.  For those with Cisco access points what code version are planning on
> running for start of fall semester?
>
>
>
> At this point we looking at 8.2.151 possibly 8.2.160 but havent tested
> yet.
>
>
>
> Thanks
>
>
>
> -Jimmy
>
>
>
> --
>
> James Helzerman Wireless Network Engineer University of Michigan - ITS
>
> Phone: 734-615-9541
>
> ** 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.
>
>
>
>
>
> **
> Participation and subscription information for this EDUCAUSE Constituent
> Group discussion list can be found at http://www.educause.edu/discuss.
>
>
> --
> *Marcelo Maraboli Rosselott*
> Subdirector de Redes y Seguridad
> Dirección de Informática
> Pontificia Universidad Católica de Chile
> http://informatica.uc.cl/
> --
> Campus San Joaquín, Av. Vicuña Mackenna 4860, Macul
> Santiago, Chile
> Teléfono: (56) 22354 1341
> ** 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] Cisco Code Version

[Marcelo Maraboli]

Hello all

I wonder why CISCO keeps 8.2.151 as "suggested" and not 8.2.160 ??

just a precaution ?

My Cisco partner is telling me to stay in 8.2.151 even if there is 8.5.x 
code our there.



what's your opinion ?


regards,


On 7/31/17 4:11 PM, Paul Thompson wrote:


.160 fixes some real world SIP and 802.11r Fast Transition bugs, if 
you're using either of those features.  I was told by a coworker that 
the engineering prereleases of it had helped with some real life Apple 
connectivity tics, but have less detail on specifics of that.


On Mon, 31 Jul 2017, Lee H Badman wrote:



151 here as well- is a bit frustrating that 160 just came out as 
we’re in our “freeze” period now for making changes, pre-semester. 
Other than the typical laundry list of cryptic bugs corrected, does 
anyone know if 160 addresses any real-world, commonly impactful 
3800-related bugs?




Lee Badman | Network Architect

Certified Wireless Network Expert (#200) Information Technology 
Services 206 Machinery Hall 120 Smith Drive Syracuse, New York 13244


t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu w its.syr.edu

SYRACUSE UNIVERSITY syr.edu



From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James 
Helzerman Sent: Monday, July 31, 2017 1:57 PM To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Cisco Code 
Version




Hi.  For those with Cisco access points what code version are 
planning on running for start of fall semester?




At this point we looking at 8.2.151 possibly 8.2.160 but havent 
tested yet.




Thanks



-Jimmy



--

James Helzerman Wireless Network Engineer University of Michigan - ITS

Phone: 734-615-9541

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







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


--
*Marcelo Maraboli Rosselott*
Subdirector de Redes y Seguridad
Dirección de Informática
Pontificia Universidad Católica de Chile
http://informatica.uc.cl/
--
Campus San Joaquín, Av. Vicuña Mackenna 4860, Macul
Santiago, Chile
Teléfono: (56) 22354 1341

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

Re: [WIRELESS-LAN] Cisco Code Version

[Ciesinski, Nick]

While WLC 8.5 did add IPSK it is probably safe to say its rather worthless for 
most at this time.  For those who have used ISE if you watch the video on how 
they make IPSK work it isn’t feasible to give each of your users their own PSK 
key to connect to wireless.  The current implementation within ISE required no 
feature additions to ISE to make it work.  All they do is have a rule to 
classify a device and/or user and then send a particular PSK value that it 
should be using.  This is a 100% manual process  for each device and/or user as 
nothing is baked into ISE to have a user register their account or device(s) 
and be presented a PSK to use.

Whats there now is good for having multiple PSK’s for different device types or 
user bases (such as all students) it isn’t that PPSK solution like others have. 
 Hopefully a ISE improvement will come at some point in the near future to 
allow a true per user PSK experience.

Granted using a 3rd party RADIUS server and writing your own interface would 
allow you issue a PSK per user not everyone has time for that.

--
Nick Ciesinski, Network Architect
University of Wisconsin - Whitewater
Office: MG208A | Phone: 262-472-7774
E-mail: ciesi...@uww.edu<mailto:ciesi...@uww.edu> | SIP: 
ciesi...@uww.edu<mailto:ciesi...@uww.edu>
PGP Key ID: 0x83042F05
--

On Jul 31, 2017, at 11:13 PM, Jason Cook 
<jason.c...@adelaide.edu.au<mailto:jason.c...@adelaide.edu.au>> wrote:

Thanks, I am aware it’s any radius server so it seems I identified my issue a 
bit hastily./… or not at all ☺
It’s been a while since I played with an Aerohive AP but 3 years ago it was so 
easy to get this up and running on a single AP with different vlans and there’s 
self-registration as well. There were enterprise concerns about how that scales 
and redundancy back then and I haven’t followed the progress of that.

The radius method means it’s not quite an out of the box solution that was so 
simple with PPSK, but perhaps this is architecture requirements…  I guess it 
might be that easy if your using ICE. We are pretty keen to use this at some 
level, ideally with self-rego offering. Using freeradius I’m sure we can 
achieve this, but ongoing management could become interesting/a fair bit of 
development for the self-rego. No doubt we’ll look further into it in a couple 
of months once a few other priorities are ticked off

Regards

--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005
Ph: +61 8 8313 4800

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Samuel Clements
Sent: Tuesday, 1 August 2017 11:51 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

From the iPSK config guide at:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-5/b_Identity_PSK_Feature_Deployment_Guide.pdf

"IPSK can be configured on any AAA serer that supports Cisco av-pair."

 -Sam
This email sent from a mobile computing device. Please excuse typos and brevity.

On Jul 31, 2017, at 8:40 PM, Mccormick, Kevin 
<ke-mccorm...@wiu.edu<mailto:ke-mccorm...@wiu.edu>> wrote:
I just looked at the IPSK video from CIsco here.

https://www.youtube.com/watch?v=deEv-aNXfL0

Not 100% sure ISE is required by the sound of the video.

They say a radius serve such as ISE, and of course Cisco is going to try and 
sell you ISE.

They are using two Cisco-AV-Pairs which are psk-mode=ascii and psk=, 
along with MAC filtering and AAA override.

You maybe able to pass those Cisco-AV-Pairs with any radius server.

Kevin 
McCormick<https://www.youracclaim.com/badges/3aa51624-4156-498d-bf6f-4a61790d54cf/public_url>
Network Administrator
University Technology - Western Illinois University
ke-mccorm...@wiu.edu<mailto:ke-mccorm...@wiu.edu> | (309) 
298-1335 | Morgan Hall 106b
Connect with uTech: Website<http://www.wiu.edu/utech> | 
Facebook<https://www.facebook.com/uTechWIU> | 
Twitter<https://twitter.com/WIU_uTech>
[http://www.wiu.edu/university_technology/images/signatures/currentimage.jpg]

On Mon, Jul 31, 2017 at 6:57 PM, Jason Cook 
<jason.c...@adelaide.edu.au<mailto:jason.c...@adelaide.edu.au>> wrote:
There is a lot of resolved caveats in the 160 release for the 2800/3800 series. 
We’ve only got a handful of 2800’s operational but a lot to be installed, have 
hit 1 issue but haven’t identified it with a known bug yet.

Despite showing “users connected” to an AP, new users couldn’t join. I 
certainly couldn’t and you wouldn’t necessarily connect to a neighbouring AP 
with strong signal. Rebooting the AP resolved it, came across it on 2 out of 16 
AP’s last week. Due to impact we couldn’t get right into troubleshooting or 
logging a case, but intend to if it returns. Hopefully it’s not on critically 
locate AP’s this time

At this stage likely we’ll be tes

Re: [WIRELESS-LAN] Cisco Code Version

[James Andrewartha]

Yeah, that fabric paradigm seems … well, let’s just quote from 
http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-5/config-guide/b_cg85/few.html

> VXLAN

> After a TCP connection flap in the WLC, it takes about five to six minutes to 
> reestablish the connection. During this time, the access tunnels gets reset 
> during client join.

Table 2 AP Support
AP

Support

11N

No

11AC Wave 1

Yes

11AC Wave 2

Yes

Mesh

No

Table 3 Client Security


Security

Support

Open and Static WEP

No

Table 4 IPv6 Support
IPv6

Support

IPv6 Infra Support

No

IPv6 Client Support

No



And it needs a whole ‘nother controller (APIC-EM) with supported switches 
http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/application-policy-infrastructure-controller-enterprise-module/datasheet-c78-739052.html
 and WLC (8540, 5520, 3504 only).

--
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of Lee H Badman 
<lhbad...@syr.edu>
Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Date: Tuesday, 1 August 2017 at 8:10 pm
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

I’m interested here, greatly… but:


-  8.5 will have to bake thoroughly for us. Not touching it until MR3 
or beyond. Zero trust or faith in early WLC code anymore- seems it’s all beta 
quality at best anymore.

-  Need to see if Cisco requires more licensing in ISE somehow to 
enable the feature (we only use ISE for basic RADIUS right now), and what the 
complexity to implement ends up being.


But if it scales, and if it isn’t nonsensically licensed, and if the code that 
supports it is eventually solid, and if you can use it without getting sucked 
into an immature, complicated, buggy fabric paradigm, it could be hugely 
enabling in certain environments.


-Lee


Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jason Cook
Sent: Tuesday, August 01, 2017 12:13 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

Thanks, I am aware it’s any radius server so it seems I identified my issue a 
bit hastily./… or not at all ☺
It’s been a while since I played with an Aerohive AP but 3 years ago it was so 
easy to get this up and running on a single AP with different vlans and there’s 
self-registration as well. There were enterprise concerns about how that scales 
and redundancy back then and I haven’t followed the progress of that.

The radius method means it’s not quite an out of the box solution that was so 
simple with PPSK, but perhaps this is architecture requirements…  I guess it 
might be that easy if your using ICE. We are pretty keen to use this at some 
level, ideally with self-rego offering. Using freeradius I’m sure we can 
achieve this, but ongoing management could become interesting/a fair bit of 
development for the self-rego. No doubt we’ll look further into it in a couple 
of months once a few other priorities are ticked off

Regards

--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005
Ph: +61 8 8313 4800

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Samuel Clements
Sent: Tuesday, 1 August 2017 11:51 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

From the iPSK config guide at:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-5/b_Identity_PSK_Feature_Deployment_Guide.pdf

"IPSK can be configured on any AAA serer that supports Cisco av-pair."

 -Sam
This email sent from a mobile computing device. Please excuse typos and brevity.

On Jul 31, 2017, at 8:40 PM, Mccormick, Kevin 
<ke-mccorm...@wiu.edu<mailto:ke-mccorm...@wiu.edu>> wrote:
I just looked at the IPSK video from CIsco here.

https://www.youtube.com/watch?v=deEv-aNXfL0

Not 100% sure ISE is required by the sound of the video.

They say a radius serve such as ISE, and of course Cisco is going to try and 
sell you ISE.

They are using two Cisco-AV-Pairs which are psk-mode=ascii and psk=, 
along with MAC filtering and AAA override.

You maybe able to pass those Cisco-AV-Pairs with any radius server.

Kevin 
McCormick<https://www.youracclaim.com/b

RE: [WIRELESS-LAN] Cisco Code Version

[Lee H Badman]

Thanks, Jake.

-Original Message-
From: Jake Snyder [jsnyde...@gmail.com]
Received: Tuesday, 01 Aug 2017, 9:35
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU [WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]
Subject: Re: [WIRELESS-LAN] Cisco Code Version

Lee,
IPSK falls into base licensing as it is just RADIUS 802.1X.

However, you need base licenses for every device doing an IPSK, which may 
increase the number of base licenses you need.  If you were doing MAB before 
for those devices, it should be a wash.

Sent from my iPhone

On Aug 1, 2017, at 6:10 AM, Lee H Badman 
<lhbad...@syr.edu<mailto:lhbad...@syr.edu>> wrote:

I’m interested here, greatly… but:


-  8.5 will have to bake thoroughly for us. Not touching it until MR3 
or beyond. Zero trust or faith in early WLC code anymore- seems it’s all beta 
quality at best anymore.

-  Need to see if Cisco requires more licensing in ISE somehow to 
enable the feature (we only use ISE for basic RADIUS right now), and what the 
complexity to implement ends up being.


But if it scales, and if it isn’t nonsensically licensed, and if the code that 
supports it is eventually solid, and if you can use it without getting sucked 
into an immature, complicated, buggy fabric paradigm, it could be hugely 
enabling in certain environments.


-Lee


Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w 
its.syr.edu<http://its.syr.edu>
SYRACUSE UNIVERSITY
syr.edu<http://syr.edu>

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jason Cook
Sent: Tuesday, August 01, 2017 12:13 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

Thanks, I am aware it’s any radius server so it seems I identified my issue a 
bit hastily./… or not at all :)
It’s been a while since I played with an Aerohive AP but 3 years ago it was so 
easy to get this up and running on a single AP with different vlans and there’s 
self-registration as well. There were enterprise concerns about how that scales 
and redundancy back then and I haven’t followed the progress of that.

The radius method means it’s not quite an out of the box solution that was so 
simple with PPSK, but perhaps this is architecture requirements…  I guess it 
might be that easy if your using ICE. We are pretty keen to use this at some 
level, ideally with self-rego offering. Using freeradius I’m sure we can 
achieve this, but ongoing management could become interesting/a fair bit of 
development for the self-rego. No doubt we’ll look further into it in a couple 
of months once a few other priorities are ticked off

Regards

--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005
Ph: +61 8 8313 4800

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Samuel Clements
Sent: Tuesday, 1 August 2017 11:51 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

>From the iPSK config guide at:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-5/b_Identity_PSK_Feature_Deployment_Guide.pdf

"IPSK can be configured on any AAA serer that supports Cisco av-pair."

 -Sam
This email sent from a mobile computing device. Please excuse typos and brevity.

On Jul 31, 2017, at 8:40 PM, Mccormick, Kevin 
<ke-mccorm...@wiu.edu<mailto:ke-mccorm...@wiu.edu>> wrote:
I just looked at the IPSK video from CIsco here.

https://www.youtube.com/watch?v=deEv-aNXfL0

Not 100% sure ISE is required by the sound of the video.

They say a radius serve such as ISE, and of course Cisco is going to try and 
sell you ISE.

They are using two Cisco-AV-Pairs which are psk-mode=ascii and psk=, 
along with MAC filtering and AAA override.

You maybe able to pass those Cisco-AV-Pairs with any radius server.

Kevin 
McCormick<https://www.youracclaim.com/badges/3aa51624-4156-498d-bf6f-4a61790d54cf/public_url>
Network Administrator
University Technology - Western Illinois University
ke-mccorm...@wiu.edu<mailto:ke-mccorm...@wiu.edu> | (309) 
298-1335 | Morgan Hall 106b
Connect with uTech: Website<http://www.wiu.edu/utech> | 
Facebook<https://www.facebook.com/uTechWIU> | 
Twitter<https://twitter.com/WIU_uTech>
[http://www.wiu.edu/university_technology/images/signatures/currentimage.jpg]

On Mon, Jul 31, 2017 at 6:57 PM, Jason Cook 
<jason.c...@adelaide.edu.au<mailto:jason.c...@adelaide.edu.au>> wrote:
There is a lot of resolved caveats in the 160 release for the 2800/3800 series. 
We’ve only got a handful of 2800’s operational but a lot to be i

RE: [WIRELESS-LAN] Cisco Code Version

[Jason Cook]

Thanks, I am aware it’s any radius server so it seems I identified my issue a 
bit hastily./… or not at all ☺
It’s been a while since I played with an Aerohive AP but 3 years ago it was so 
easy to get this up and running on a single AP with different vlans and there’s 
self-registration as well. There were enterprise concerns about how that scales 
and redundancy back then and I haven’t followed the progress of that.

The radius method means it’s not quite an out of the box solution that was so 
simple with PPSK, but perhaps this is architecture requirements…  I guess it 
might be that easy if your using ICE. We are pretty keen to use this at some 
level, ideally with self-rego offering. Using freeradius I’m sure we can 
achieve this, but ongoing management could become interesting/a fair bit of 
development for the self-rego. No doubt we’ll look further into it in a couple 
of months once a few other priorities are ticked off

Regards

--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005
Ph: +61 8 8313 4800

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Samuel Clements
Sent: Tuesday, 1 August 2017 11:51 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

From the iPSK config guide at:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-5/b_Identity_PSK_Feature_Deployment_Guide.pdf

"IPSK can be configured on any AAA serer that supports Cisco av-pair."

 -Sam
This email sent from a mobile computing device. Please excuse typos and brevity.

On Jul 31, 2017, at 8:40 PM, Mccormick, Kevin 
<ke-mccorm...@wiu.edu<mailto:ke-mccorm...@wiu.edu>> wrote:
I just looked at the IPSK video from CIsco here.

https://www.youtube.com/watch?v=deEv-aNXfL0

Not 100% sure ISE is required by the sound of the video.

They say a radius serve such as ISE, and of course Cisco is going to try and 
sell you ISE.

They are using two Cisco-AV-Pairs which are psk-mode=ascii and psk=, 
along with MAC filtering and AAA override.

You maybe able to pass those Cisco-AV-Pairs with any radius server.

Kevin 
McCormick<https://www.youracclaim.com/badges/3aa51624-4156-498d-bf6f-4a61790d54cf/public_url>
Network Administrator
University Technology - Western Illinois University
ke-mccorm...@wiu.edu<mailto:ke-mccorm...@wiu.edu> | (309) 
298-1335 | Morgan Hall 106b
Connect with uTech: Website<http://www.wiu.edu/utech> | 
Facebook<https://www.facebook.com/uTechWIU> | 
Twitter<https://twitter.com/WIU_uTech>
[http://www.wiu.edu/university_technology/images/signatures/currentimage.jpg]

On Mon, Jul 31, 2017 at 6:57 PM, Jason Cook 
<jason.c...@adelaide.edu.au<mailto:jason.c...@adelaide.edu.au>> wrote:
There is a lot of resolved caveats in the 160 release for the 2800/3800 series. 
We’ve only got a handful of 2800’s operational but a lot to be installed, have 
hit 1 issue but haven’t identified it with a known bug yet.

Despite showing “users connected” to an AP, new users couldn’t join. I 
certainly couldn’t and you wouldn’t necessarily connect to a neighbouring AP 
with strong signal. Rebooting the AP resolved it, came across it on 2 out of 16 
AP’s last week. Due to impact we couldn’t get right into troubleshooting or 
logging a case, but intend to if it returns. Hopefully it’s not on critically 
locate AP’s this time

At this stage likely we’ll be testing and migrating to 8.2.160 (from 8.2.151) 
in the next few weeks

Was keen to begin playing with 8.5 with IPSK finally released, but am 
disappointed with the requirement of ICE(we don’t use) or at least an external 
radius server providing a not so simple implementation we were hoping for. So 
that might be on the back burner ☹


--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005
Ph: +61 8 8313 4800<tel:+61%208%208313%204800>

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>]
 On Behalf Of Entwistle, Bruce
Sent: Tuesday, 1 August 2017 4:16 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

I had seen the comments made by the group during the summer related to bugs and 
the 2800 APs, so as a precautionary measure we did the upgrade.

Bruce Entwistle
Network Manager
University of Redlands

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Monday, July 31, 2017 11:26 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

Bruce,

Was there anything that you were absolutely hitting, or are you doing the “just 
in case” thing here?

Lee Badman | Network Architect

Certified Wireless 

Re: [WIRELESS-LAN] Cisco Code Version

[Samuel Clements]

From the iPSK config guide at:

http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-5/b_Identity_PSK_Feature_Deployment_Guide.pdf

"IPSK can be configured on any AAA serer that supports Cisco av-pair." 

 -Sam

This email sent from a mobile computing device. Please excuse typos and brevity.

> On Jul 31, 2017, at 8:40 PM, Mccormick, Kevin <ke-mccorm...@wiu.edu> wrote:
> 
> I just looked at the IPSK video from CIsco here.
> 
> https://www.youtube.com/watch?v=deEv-aNXfL0
> 
> Not 100% sure ISE is required by the sound of the video.
> 
> They say a radius serve such as ISE, and of course Cisco is going to try and 
> sell you ISE.
> 
> They are using two Cisco-AV-Pairs which are psk-mode=ascii and psk=, 
> along with MAC filtering and AAA override.
> 
> You maybe able to pass those Cisco-AV-Pairs with any radius server.
> 
> Kevin McCormick
> Network Administrator
> University Technology - Western Illinois University
> ke-mccorm...@wiu.edu | (309) 298-1335 | Morgan Hall 106b
> Connect with uTech: Website | Facebook | Twitter
> 
> 
>> On Mon, Jul 31, 2017 at 6:57 PM, Jason Cook <jason.c...@adelaide.edu.au> 
>> wrote:
>> There is a lot of resolved caveats in the 160 release for the 2800/3800 
>> series. We’ve only got a handful of 2800’s operational but a lot to be 
>> installed, have hit 1 issue but haven’t identified it with a known bug yet.
>> 
>>  
>> 
>> Despite showing “users connected” to an AP, new users couldn’t join. I 
>> certainly couldn’t and you wouldn’t necessarily connect to a neighbouring AP 
>> with strong signal. Rebooting the AP resolved it, came across it on 2 out of 
>> 16 AP’s last week. Due to impact we couldn’t get right into troubleshooting 
>> or logging a case, but intend to if it returns. Hopefully it’s not on 
>> critically locate AP’s this time
>> 
>>  
>> 
>> At this stage likely we’ll be testing and migrating to 8.2.160 (from 
>> 8.2.151) in the next few weeks
>> 
>>  
>> 
>> Was keen to begin playing with 8.5 with IPSK finally released, but am 
>> disappointed with the requirement of ICE(we don’t use) or at least an 
>> external radius server providing a not so simple implementation we were 
>> hoping for. So that might be on the back burner L
>> 
>>  
>> 
>>  
>> 
>> --
>> 
>> Jason Cook
>> 
>> Technology Services
>> 
>> The University of Adelaide, AUSTRALIA 5005
>> 
>> Ph: +61 8 8313 4800
>> 
>>  
>> 
>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Entwistle, Bruce
>> Sent: Tuesday, 1 August 2017 4:16 AM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: Re: [WIRELESS-LAN] Cisco Code Version
>> 
>>  
>> 
>> I had seen the comments made by the group during the summer related to bugs 
>> and the 2800 APs, so as a precautionary measure we did the upgrade.
>> 
>>  
>> 
>> Bruce Entwistle
>> 
>> Network Manager
>> 
>> University of Redlands
>> 
>>  
>> 
>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
>> Sent: Monday, July 31, 2017 11:26 AM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: Re: [WIRELESS-LAN] Cisco Code Version
>> 
>>  
>> 
>> Bruce,
>> 
>>  
>> 
>> Was there anything that you were absolutely hitting, or are you doing the 
>> “just in case” thing here?
>> 
>>  
>> 
>> Lee Badman | Network Architect 
>> 
>> Certified Wireless Network Expert (#200)
>> Information Technology Services
>> 206 Machinery Hall
>> 120 Smith Drive
>> Syracuse, New York 13244
>> 
>> t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu w its.syr.edu
>> 
>> SYRACUSE UNIVERSITY
>> syr.edu
>> 
>>  
>> 
>> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Entwistle, Bruce
>> Sent: Monday, July 31, 2017 2:11 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: Re: [WIRELESS-LAN] Cisco Code Version
>> 
>>  
>> 
>> We completed the upgrade from 8.2.151.0 to 8.2.160.0 this morning.  The 
>> primary reason for the upgrade was the identified bugs related to the 2800 
>> APs.
>> 
>>  
>> 
>> Bruce Entwistle
>> 
>> Network Manager
>> 
>> University of Redlands
>> 

Re: [WIRELESS-LAN] Cisco Code Version

[Mccormick, Kevin]

I just looked at the IPSK video from CIsco here.

https://www.youtube.com/watch?v=deEv-aNXfL0

Not 100% sure ISE is required by the sound of the video.

They say a radius serve such as ISE, and of course Cisco is going to try
and sell you ISE.

They are using two Cisco-AV-Pairs which are psk-mode=ascii and psk=, along with MAC filtering and AAA override.

You maybe able to pass those Cisco-AV-Pairs with any radius server.

Kevin McCormick
<https://www.youracclaim.com/badges/3aa51624-4156-498d-bf6f-4a61790d54cf/public_url>
Network Administrator
University Technology - Western Illinois University
ke-mccorm...@wiu.edu | (309) 298-1335 <3092981335> | Morgan Hall 106b
Connect with uTech: Website <http://www.wiu.edu/utech> | Facebook
<https://www.facebook.com/uTechWIU> | Twitter
<https://twitter.com/WIU_uTech>


On Mon, Jul 31, 2017 at 6:57 PM, Jason Cook <jason.c...@adelaide.edu.au>
wrote:

> There is a lot of resolved caveats in the 160 release for the 2800/3800
> series. We’ve only got a handful of 2800’s operational but a lot to be
> installed, have hit 1 issue but haven’t identified it with a known bug yet.
>
>
>
> Despite showing “users connected” to an AP, new users couldn’t join. I
> certainly couldn’t and you wouldn’t necessarily connect to a neighbouring
> AP with strong signal. Rebooting the AP resolved it, came across it on 2
> out of 16 AP’s last week. Due to impact we couldn’t get right into
> troubleshooting or logging a case, but intend to if it returns. Hopefully
> it’s not on critically locate AP’s this time
>
>
>
> At this stage likely we’ll be testing and migrating to 8.2.160 (from
> 8.2.151) in the next few weeks
>
>
>
> Was keen to begin playing with 8.5 with IPSK finally released, but am
> disappointed with the requirement of ICE(we don’t use) or at least an
> external radius server providing a not so simple implementation we were
> hoping for. So that might be on the back burner L
>
>
>
>
>
> --
>
> Jason Cook
>
> Technology Services
>
> The University of Adelaide, AUSTRALIA 5005
>
> Ph: +61 8 8313 4800 <+61%208%208313%204800>
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Entwistle, Bruce
> *Sent:* Tuesday, 1 August 2017 4:16 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] Cisco Code Version
>
>
>
> I had seen the comments made by the group during the summer related to
> bugs and the 2800 APs, so as a precautionary measure we did the upgrade.
>
>
>
> Bruce Entwistle
>
> Network Manager
>
> University of Redlands
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] *On Behalf Of *Lee H Badman
> *Sent:* Monday, July 31, 2017 11:26 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] Cisco Code Version
>
>
>
> Bruce,
>
>
>
> Was there anything that you were absolutely hitting, or are you doing the
> “just in case” thing here?
>
>
>
> *Lee Badman* | Network Architect
>
> Certified Wireless Network Expert (#200)
> Information Technology Services
> 206 Machinery Hall
> 120 Smith Drive
> Syracuse, New York 13244
>
> *t* 315.443.3003 <(315)%20443-3003>  * f* 315.443.4325 <(315)%20443-4325>
> *e* lhbad...@syr.edu *w* its.syr.edu
>
> *SYRACUSE UNIVERSITY*
> syr.edu
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] *On Behalf Of *Entwistle, Bruce
> *Sent:* Monday, July 31, 2017 2:11 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] Cisco Code Version
>
>
>
> We completed the upgrade from 8.2.151.0 to 8.2.160.0 this morning.  The
> primary reason for the upgrade was the identified bugs related to the 2800
> APs.
>
>
>
> Bruce Entwistle
>
> Network Manager
>
> University of Redlands
>
>
>
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>] *On Behalf Of *James Helzerman
> *Sent:* Monday, July 31, 2017 10:57 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* [WIRELESS-LAN] Cisco Code Version
>
>
>
> Hi.  For those with Cisco access points what code version are planning on
> running for start of fall semester?
>
>
>
> At this point we looking at 8.2.151 possibly 8.2.160 but havent tested yet.
>
>
>
> Thanks
>
>
&g

RE: [WIRELESS-LAN] Cisco Code Version

[Jason Cook]

There is a lot of resolved caveats in the 160 release for the 2800/3800 series. 
We’ve only got a handful of 2800’s operational but a lot to be installed, have 
hit 1 issue but haven’t identified it with a known bug yet.

Despite showing “users connected” to an AP, new users couldn’t join. I 
certainly couldn’t and you wouldn’t necessarily connect to a neighbouring AP 
with strong signal. Rebooting the AP resolved it, came across it on 2 out of 16 
AP’s last week. Due to impact we couldn’t get right into troubleshooting or 
logging a case, but intend to if it returns. Hopefully it’s not on critically 
locate AP’s this time

At this stage likely we’ll be testing and migrating to 8.2.160 (from 8.2.151) 
in the next few weeks

Was keen to begin playing with 8.5 with IPSK finally released, but am 
disappointed with the requirement of ICE(we don’t use) or at least an external 
radius server providing a not so simple implementation we were hoping for. So 
that might be on the back burner ☹


--
Jason Cook
Technology Services
The University of Adelaide, AUSTRALIA 5005
Ph: +61 8 8313 4800

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Entwistle, Bruce
Sent: Tuesday, 1 August 2017 4:16 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

I had seen the comments made by the group during the summer related to bugs and 
the 2800 APs, so as a precautionary measure we did the upgrade.

Bruce Entwistle
Network Manager
University of Redlands

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Monday, July 31, 2017 11:26 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

Bruce,

Was there anything that you were absolutely hitting, or are you doing the “just 
in case” thing here?

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Entwistle, Bruce
Sent: Monday, July 31, 2017 2:11 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

We completed the upgrade from 8.2.151.0 to 8.2.160.0 this morning.  The primary 
reason for the upgrade was the identified bugs related to the 2800 APs.

Bruce Entwistle
Network Manager
University of Redlands


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James Helzerman
Sent: Monday, July 31, 2017 10:57 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [WIRELESS-LAN] Cisco Code Version

Hi.  For those with Cisco access points what code version are planning on 
running for start of fall semester?

At this point we looking at 8.2.151 possibly 8.2.160 but havent tested yet.

Thanks

-Jimmy

--
James Helzerman
Wireless Network Engineer
University of Michigan - ITS
Phone: 734-615-9541
** 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.
** 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.

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

Re: [WIRELESS-LAN] Cisco Code Version

[ptedu]

.160 fixes some real world SIP and 802.11r Fast Transition bugs, if you're 
using either of those features.  I was told by a coworker that the 
engineering prereleases of it had helped with some real life Apple 
connectivity tics, but have less detail on specifics of that.


On Mon, 31 Jul 2017, Lee H Badman wrote:



151 here as well- is a bit frustrating that 160 just came out as we’re 
in our “freeze” period now for making changes, pre-semester. Other than 
the typical laundry list of cryptic bugs corrected, does anyone know if 
160 addresses any real-world, commonly impactful 3800-related bugs?


 

Lee Badman | Network Architect

Certified Wireless Network Expert (#200) Information Technology Services 
206 Machinery Hall 120 Smith Drive Syracuse, New York 13244


t 315.443.3003 f 315.443.4325 e lhbad...@syr.edu w its.syr.edu

SYRACUSE UNIVERSITY syr.edu

 

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James Helzerman 
Sent: Monday, July 31, 2017 1:57 PM To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: [WIRELESS-LAN] Cisco Code 
Version


 

Hi.  For those with Cisco access points what code version are planning 
on running for start of fall semester?


 

At this point we looking at 8.2.151 possibly 8.2.160 but havent tested 
yet.


 

Thanks

 

-Jimmy

 

--

James Helzerman Wireless Network Engineer University of Michigan - ITS

Phone: 734-615-9541

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







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

RE: [WIRELESS-LAN] Cisco Code Version

[Entwistle, Bruce]

I had seen the comments made by the group during the summer related to bugs and 
the 2800 APs, so as a precautionary measure we did the upgrade.

Bruce Entwistle
Network Manager
University of Redlands

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman
Sent: Monday, July 31, 2017 11:26 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

Bruce,

Was there anything that you were absolutely hitting, or are you doing the “just 
in case” thing here?

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Entwistle, Bruce
Sent: Monday, July 31, 2017 2:11 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] Cisco Code Version

We completed the upgrade from 8.2.151.0 to 8.2.160.0 this morning.  The primary 
reason for the upgrade was the identified bugs related to the 2800 APs.

Bruce Entwistle
Network Manager
University of Redlands


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James Helzerman
Sent: Monday, July 31, 2017 10:57 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [WIRELESS-LAN] Cisco Code Version

Hi.  For those with Cisco access points what code version are planning on 
running for start of fall semester?

At this point we looking at 8.2.151 possibly 8.2.160 but havent tested yet.

Thanks

-Jimmy

--
James Helzerman
Wireless Network Engineer
University of Michigan - ITS
Phone: 734-615-9541
** 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.
** 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] Cisco Code Version

[Lee H Badman]

Bruce,

Was there anything that you were absolutely hitting, or are you doing the “just 
in case” thing here?

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Entwistle, Bruce
Sent: Monday, July 31, 2017 2:11 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Cisco Code Version

We completed the upgrade from 8.2.151.0 to 8.2.160.0 this morning.  The primary 
reason for the upgrade was the identified bugs related to the 2800 APs.

Bruce Entwistle
Network Manager
University of Redlands


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James Helzerman
Sent: Monday, July 31, 2017 10:57 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [WIRELESS-LAN] Cisco Code Version

Hi.  For those with Cisco access points what code version are planning on 
running for start of fall semester?

At this point we looking at 8.2.151 possibly 8.2.160 but havent tested yet.

Thanks

-Jimmy

--
James Helzerman
Wireless Network Engineer
University of Michigan - ITS
Phone: 734-615-9541
** 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.

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

RE: [WIRELESS-LAN] Cisco Code Version

[Lee H Badman]

151 here as well- is a bit frustrating that 160 just came out as we’re in our 
“freeze” period now for making changes, pre-semester. Other than the typical 
laundry list of cryptic bugs corrected, does anyone know if 160 addresses any 
real-world, commonly impactful 3800-related bugs?

Lee Badman | Network Architect

Certified Wireless Network Expert (#200)
Information Technology Services
206 Machinery Hall
120 Smith Drive
Syracuse, New York 13244
t 315.443.3003   f 315.443.4325   e lhbad...@syr.edu<mailto:lhbad...@syr.edu> w 
its.syr.edu
SYRACUSE UNIVERSITY
syr.edu

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James Helzerman
Sent: Monday, July 31, 2017 1:57 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Cisco Code Version

Hi.  For those with Cisco access points what code version are planning on 
running for start of fall semester?

At this point we looking at 8.2.151 possibly 8.2.160 but havent tested yet.

Thanks

-Jimmy

--
James Helzerman
Wireless Network Engineer
University of Michigan - ITS
Phone: 734-615-9541
** 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] Cisco Code Version

[Entwistle, Bruce]

We completed the upgrade from 8.2.151.0 to 8.2.160.0 this morning.  The primary 
reason for the upgrade was the identified bugs related to the 2800 APs.

Bruce Entwistle
Network Manager
University of Redlands


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of James Helzerman
Sent: Monday, July 31, 2017 10:57 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Cisco Code Version

Hi.  For those with Cisco access points what code version are planning on 
running for start of fall semester?

At this point we looking at 8.2.151 possibly 8.2.160 but havent tested yet.

Thanks

-Jimmy

--
James Helzerman
Wireless Network Engineer
University of Michigan - ITS
Phone: 734-615-9541
** 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] Cisco Code Version

[Jeffrey D. Sessler]

I would go with 8.2.160, especially if you have the new-series x800 WAPs.

Jeff

From: "wireless-lan@listserv.educause.edu" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
on behalf of James Helzerman <jarh...@umich.edu>
Reply-To: "wireless-lan@listserv.educause.edu" 
<WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Date: Monday, July 31, 2017 at 10:57 AM
To: "wireless-lan@listserv.educause.edu" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [WIRELESS-LAN] Cisco Code Version

Hi.  For those with Cisco access points what code version are planning on 
running for start of fall semester?

At this point we looking at 8.2.151 possibly 8.2.160 but havent tested yet.

Thanks

-Jimmy

--
James Helzerman
Wireless Network Engineer
University of Michigan - ITS
Phone: 734-615-9541
** 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.