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 |

 Lead Network Communications Specialist |

 University of Alaska |

 907.450.8250



On Mon, Aug 7, 2017 at 7:46 AM, Hunter Fuller 
> 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 
> 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 
> 
on behalf of Hunter Fuller >
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 
> 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