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:[email protected]] On Behalf Of Britton Anderson Sent: Tuesday, August 08, 2017 3:25 PM To: [email protected] 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:[email protected]> | 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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=<psk value>. 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=<psk value>" 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 <[email protected]<mailto:[email protected]>> on behalf of Hunter Fuller <[email protected]<mailto:[email protected]>> Sent: Friday, August 4, 2017 4:59 PM To: [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 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<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 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<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 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.
