Tracy, Yes, I'm hoping that the ACS access issue was either human error (me) or lab anomaly. After a few failed attempts to access it myself, I gave up trying on my own and just got the proctor involved.
I had a similar client PC issue. The NIC was down and there was no admin access to enable it. Again, proctor intervention. That only happened to me one time, luckily. Justin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tracy Sutton Sent: Wednesday, February 12, 2014 08:25 To: [email protected] Subject: Re: [OSL | CCIE_Wireless] CCIE_Wireless Digest, Vol 58, Issue 58 I had CLI access to ACS during my lab (version 2) and did need to reset ACS during my lab time! I also had an issue with the client PC because the network wasn't enabled (Wireless NIC) and I could not see any SSIDs that I have configured and working. I believe the proctor was the one that had to do this for me in my lab experience. There are bugs with the code level being used as with the end station filter parameter setting is one that comes to mind. I do believe all devices have CLI access. Regards, Tracy Sutton CCIEW# 37101 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, February 12, 2014 9:47 AM To: [email protected] Subject: CCIE_Wireless Digest, Vol 58, Issue 58 Send CCIE_Wireless mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://onlinestudylist.com/cgi-bin/mailman/listinfo/ccie_wireless or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of CCIE_Wireless digest..." Today's Topics: 1. Re: Autonomous - Reliability (Jeff Rensink) ---------------------------------------------------------------------- Message: 1 Date: Wed, 12 Feb 2014 08:46:31 -0600 From: Jeff Rensink <[email protected]> To: Andreas di Zazzo <[email protected]> Cc: "Jay Killion \(jakillio\)" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [OSL | CCIE_Wireless] Autonomous - Reliability Message-ID: <caluhjv2uzg6uxcpvknebg4je3o+iebtvfruf_kw3pw1nzcy...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Since there is no version of code that is bug free, it is a fact of life in the lab. But I'm surprised that Justin didn't have CLI access to the ACS server. That's the only way that we have to restart services as well as configure an NTP server/time. I can say for sure that in the past I know CLI access has been available. But maybe it's a newer revision of the lab with different access. Justin, did they ever mention any CLI credentials for ACS in the lab content? If not then it sounds like it was by design. But that's a shame as restarting the ACS service is almost a way of life thanks to bugs and general flakiness. Regards, Jeff Rensink : Sr Instructor : iPexpert <http://www.ipexpert.com/> CCIE # 24834 :: Wireless / R&S :: World-Class Cisco Certification Training Direct: +1.810.326.1444 :: Free Videos <http://www.youtube.com/ipexpertinc> :: Free Training / Product Offerings <http://www.facebook.com/ipexpert> :: CCIE Blog <http://blog.ipexpert.com/> :: Twitter <http://www.twitter.com/ipexpert> On Wed, Feb 12, 2014 at 4:45 AM, Andreas di Zazzo < [email protected]> wrote: > PoE is not the only way to power an AP, but that will be the scenario > in the actual lab. > > I did not refer to that ACS bug no. I do not have the exact bug ID but > the behavior is that the ACS stops responding on RADIUS requests. > In the ACS View this can easily be identified if you know what to look > for. The behavior is because some internal counter value exceeded what > it can hold. > This happend *all the time* for me both in my personal lab and in the > real lab and it is an extremely frustrating bug since each restart of > the ACS takes a long time to perform. > > It is ridicilous if you ask me to standardize the CCIE Wireless lab on > a ACS version with such a bug in it, but that's life. > > > -----Original Message----- > From: Justin Kurynny [mailto:[email protected] > <[email protected]>] > Sent: Wed 2/12/2014 10:04 AM > To: Andreas di Zazzo; Jay Killion (jakillio) > Cc: [email protected] > Subject: RE: [OSL | CCIE_Wireless] Autonomous - Reliability > > Andreas, > > Hopefully without trying to sound argumentative, I respectfully > disagree with and can clarify a few points. > > I can think of at least two pieces of hard equipment plus a dependency > platform and an environmental shell to which you are not given > administrative access. > > Sure, ACS may have been a fluke for me, however, when I queried the > proctors on separate instances, in 100% of cases they helpfully > performed the reboots as requested instead of politely sending me back to my > seat. > The bug I believe we've all been referring to is CSCth66302: "Radius > Authentication Request Rejected due to critical logging Error." This > bug behavior is described as follows: "The critical logging error > occurs because the acsLocalStore log on the system becomes locked." Is > this the same bug ID you're referring to? > > Regarding access points, a PoE port is not the only way to power an AP. > > > Justin > > From: Andreas di Zazzo > [mailto:[email protected]<[email protected]> > ] > Sent: Wednesday, February 12, 2014 00:12 > To: Justin Kurynny; Jay Killion (jakillio) > Cc: [email protected] > Subject: RE: [OSL | CCIE_Wireless] Autonomous - Reliability > > > For the lab - You will have console access to all equipment (maybe not > GUI access to all devices however). > I don't know what you mean with ACS database lockout but if you mean > the counter bug that causes it to "freeze" you solve this issue by > logging in with SSH and do a stop/start. > You will be given the credentials to the ACS server to allow you to do > this (different credentials than the web-GUI uses). > > In the case of autonomous AP failures, you will always have the option > to reset the AP by cutting PoE power from the switch-port since you > can manage the switch. > > -----Original Message----- > From: [email protected]< > mailto:[email protected]<ccie_wireless-bounces > @onlinestudylist.com>> > on behalf of Justin Kurynny > Sent: Wed 2/12/2014 8:27 AM > To: 'Jay Killion (jakillio)' > Cc: [email protected]< > mailto:[email protected]<ccie_wireless@onlinestudylist > .com> > > > Subject: Re: [OSL | CCIE_Wireless] Autonomous - Reliability > > Jay, > > In the practice lab at home, you have full administrative access to > all of your equipment and have both CLI access and GUI access. This > may not necessarily be the case for you on some platforms in the lab > environment. > > That said, I've seen the ACS database lockout issue more times than I > care to mention and every time it required proctor intervention. I've > also twice had APs crash on me while performing config tasks and not > recycle themselves on their own (different models, different > circumstances), and both instances required the proctor hard bouncing them. > > IME, the proctors are extremely helpful and generally get right to > fulfilling your request if a power cycle is what you need. > > Justin > > From: Jay Killion (jakillio) > [mailto:[email protected]<[email protected]> > ] > Sent: Monday, February 10, 2014 17:49 > To: Justin Kurynny > Cc: [email protected]< > mailto:[email protected]<ccie_wireless@onlinestudylist > .com> > > > Subject: Re: [OSL | CCIE_Wireless] Autonomous - Reliability > > Hey Justin - > > I'm curious, you said there were a handful of times you had to ask the > proctor to hard reset a system because it was the only workaround. > Without giving the specific lab requirement, can you specify some > detail around what required a hard reboot? I've been doing labs daily > for the past few months and other than rebooting AP's, the only thing > I would have to reset would be ACS - but you can obviously start / > stop the app without the proctor. I'm just having a hard time > thinking of conditions that would require proctor intervention, short > of locking yourself out with a misconfigured AAA or something like that. > > Thanks - > > Jay Killion, CCIE #17873 R/S > > > From: Justin Kurynny > <[email protected]<mailto:[email protected]<[email protected] > > > >> > Date: Sunday, February 9, 2014 9:33 PM > To: Jay Killion > <[email protected]<mailto:[email protected]<[email protected]> > >> > Cc: "[email protected]< > mailto:[email protected]<[email protected]>>" > <[email protected]< > mailto:[email protected]<ccie_wireless@onlinestudylist > .com> > >> > Subject: RE: [OSL | CCIE_Wireless] Autonomous - Reliability > > Others, feel free to disagree here, but I'd have to say that it is > extremely unlikely that you will be required to configure specifically > for a known bug as part of a task or that you will otherwise be tested > directly on code faults. Unlikely, but not impossible, of course. :) > At the same time, it is equally likely that you will unintentionally > get hit with a bug in the course of your configuration and testing. > That's just the nature of software, and bugs can strike anywhere, > anytime (usually at the most inconvenient times). > > The more time you spend in the practice lab doing and re-doing configs > from scratch, the more likely you will run across the most common > bugs/quirks, and the more prepared you will be to deal with them if > you see them. There were a handful of times I had to ask the proctor > for a system hard reset because I knew that was the only workaround. > Had I not known about that particular bug's characteristics, I might > have wasted a lot more time troubleshooting my configuration. > > Justin > > From: [email protected]< > mailto:[email protected]<ccie_wireless-bounces > @onlinestudylist.com>> > [mailto:[email protected]<ccie_wireless-bounce > [email protected]>] > On Behalf Of Jay Killion (jakillio) > Sent: Sunday, February 09, 2014 17:37 > To: Jeff Rensink; Andre Aubet > Cc: [email protected]< > mailto:[email protected]<ccie_wireless@onlinestudylist > .com> > > > Subject: Re: [OSL | CCIE_Wireless] Autonomous - Reliability > > I can't find a specific bug either for our code, but Andre's certainly > seems to match. > > Is it fair to assume that considering how long this version of the lab > has been out, we wouldn't be asked to configure something like this? > I would hope that items broken by bugs would have been vetted out by this > point. > > Jay Killion, CCIE #17873 R/S > > From: Jeff Rensink > <[email protected]<mailto:[email protected]<jrensink@ipexpert. > com> > >> > Date: Sunday, February 9, 2014 9:38 AM > To: Andre Aubet > <[email protected]<mailto:[email protected]<[email protected]> > >> > Cc: Jay Killion > <[email protected]<mailto:[email protected]<[email protected]>>>, > "[email protected]< > mailto:[email protected]<[email protected]>>" > <[email protected]< > mailto:[email protected]<ccie_wireless@onlinestudylist > .com> > >> > Subject: Re: [OSL | CCIE_Wireless] Autonomous - Reliability > > I'm getting skunked trying to get any results in the bug search tool. > But I'm guessing that's what we are seeing here. So evidently in our > lab code, if infrastructure-client is needed, we need to have the WGB > SSID using the VLAN associated with bridge-group 1. > > I'd be curious to see if the same behavior is exhibited in 15.x code. > > > Regards, > > > > Jeff Rensink : Sr Instructor : iPexpert<http://www.ipexpert.com/> > > CCIE # 24834 :: Wireless / R&S > > :: World-Class Cisco Certification Training > > > > > Direct: +1.810.326.1444 > > :: Free Videos<http://www.youtube.com/ipexpertinc> > > :: Free Training / Product Offerings<http://www.facebook.com/ipexpert> > > :: CCIE Blog<http://blog.ipexpert.com/> > :: Twitter<http://www.twitter.com/ipexpert> > > On Sat, Feb 8, 2014 at 3:33 AM, Andre Aubet <[email protected]< > mailto:[email protected] <[email protected]>>> wrote: > Hi all, > Found this bug: https://tools.cisco.com/bugsearch/bug/CSCef04592 > > This is not exactly the same behavior we have, not even the same > release, but the main condition is met: WGB associates to a non-native > VLAN on an > AP1230 (...) Removing the infrastructure-client command or downgrading > to > 12.2(13)JA4 restores connectivity > > This bug has never been fixed. However, it would prove the > infrastructure-client command actually messes with the bridge behavior. > > Due to an electrical maintenance this week-end, I won't be able to try > and reproduce this issue, and my lab is shut :-( > > But in my previous tests, I wasn't exactly in the same conditions than > Jay. I always kept consistency across the wireless link (using either > one vlan with access port on each side of the link, and then two vlans > with trunk port on both sides). > > Andre. > > 2014-02-07 23:52 GMT+01:00 Jeff Rensink <[email protected]< > mailto:[email protected] <[email protected]>>>: > > OK, further info that may be a clue as to the issue. > > When I look at my switch port behind the WGB, I'm getting interesting > STP message. It's just a standard access port in VL 17. The switch > port on AAP is a trunk port with a native VL of 110. > > Without the infra-client command, STP is all good on my WGB port. > Once I turn on infra-client on AAP1, I get the following logs on the > switch connected to the WGB. > > *Mar 1 08:01:27.454: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with > inconsistent peer vlan id 110 on FastEthernet0/2 VLAN17. > *Mar 1 08:01:27.454: %SPANTREE-2-BLOCK_PVID_LOCAL: Blocking > FastEthernet0/2 on VLAN0017. Inconsistent local vlan. > > So it appears that something is going on with the bridging on AAP1 > once the infra-client command goes into effect. Best I can tell, > traffic from the WGB going to the root is being dropped off on VL17 > correctly. That is evidenced by the DHCP debugging showing an offer > on VL 17 on the DHCP server. But it appears that VL110 traffic is > being sent to the WGB on the reverse direction instead of VL 17 > traffic. That would explain why even a static IP isn't working and the weird > STP logs. > > Is there a bug surrounding this feature in our code? I'll try and > start looking. > > > Regards, > > > > Jeff Rensink : Sr Instructor : iPexpert<http://www.ipexpert.com/> > > CCIE # 24834 :: Wireless / R&S > > :: World-Class Cisco Certification Training > > > > > Direct: +1.810.326.1444<tel:%2B1.810.326.1444> > > :: Free Videos<http://www.youtube.com/ipexpertinc> > > :: Free Training / Product Offerings<http://www.facebook.com/ipexpert> > > :: CCIE Blog<http://blog.ipexpert.com/> > :: Twitter<http://www.twitter.com/ipexpert> > > On Fri, Feb 7, 2014 at 4:45 PM, Jeff Rensink <[email protected]< > mailto:[email protected] <[email protected]>>> wrote: > This is quite interesting... I've been playing around with this and > I'm replicating Jay's behavior. I even wrote up AAP1's config from > scratch as I would do it on my own and still see the same thing. I > see the DHCP request making it to the server, but the response > evidently never makes it back with the infrastructure-client command > enabled. Here are a few things that I've tried. > > > * On AAP2, I've tried all flavors of the WGB multicast mode with no > change in behavior > * I tried making VLAN 17 the native VLAN on AAP1 with no change in > behavior > > * Tried making VL 17 native on just the radio interface as well as > both the radio and the ethernet port > > * I set both the VLAN 17 interface on both the radio and ethernet port > to be the native VLAN AND also assigned bridge-group 1 to the VL17 > sub-interfaces and then AAP2 pulled an IP address. Of course this put > AAP1's BVI on VL 17 as well. > > So thus far, it seems to only work across bridge group 1 on AAP1 when > the infrastructure-client command is enabled. At least in my testing. > > > Regards, > > > > Jeff Rensink : Sr Instructor : iPexpert<http://www.ipexpert.com/> > > CCIE # 24834 :: Wireless / R&S > > :: World-Class Cisco Certification Training > > > > > Direct: +1.810.326.1444<tel:%2B1.810.326.1444> > > :: Free Videos<http://www.youtube.com/ipexpertinc> > > :: Free Training / Product Offerings<http://www.facebook.com/ipexpert> > > :: CCIE Blog<http://blog.ipexpert.com/> > :: Twitter<http://www.twitter.com/ipexpert> > > On Fri, Feb 7, 2014 at 1:04 PM, Jay Killion (jakillio) > <[email protected] <mailto:[email protected] <[email protected]>>> wrote: > Hey Andre - > > Attached are the configs from the two AP's (AAP 1 is the root, 2 is > the WGB). I just tried it again with the exact same results. WGB > will associate without any issue, but no DHCP (and if you assign a > static, it won't ping). Just remove 'infrastructure client' from the > root and things will immediately start working. > > I'm certainly interested to see what you find. > > Thanks - > Jay Killion, CCIE #17873 R/S > > From: Andre Aubet > <[email protected]<mailto:[email protected]<[email protected]> > >> > Date: Thursday, February 6, 2014 11:28 AM > To: Jay Killion > <[email protected]<mailto:[email protected]<[email protected]> > >> > Cc: Jason Boyers > <[email protected]<mailto:[email protected]<[email protected]>>>, > "[email protected]< > mailto:[email protected]<[email protected]>>" > <[email protected]< > mailto:[email protected]<ccie_wireless@onlinestudylist > .com> > >> > > Subject: Re: [OSL | CCIE_Wireless] Autonomous - Reliability > > Ok, I just tried to configure the whole thing: > > * authentication open eap + authentication network-eap > * radius-server local on root AP > * DHCP server on core switch behind AP > * infrastructure-client on AP > * WGB using dot1x profile to authenticate on root AP > * DHCP client configured on WGB BVI1 > And all works fine. I added vlans in the WGB to act as a trunk link, > and I can ping many clients behind my WGB in different vlans. > > I'm sure there is a specific command interacting with the > infrastructure-client that made your association/authentication fail. > Unless the radio was buggy, and when you removed the > infrastructure-client command, if forced the radio interface to reset. > > 2014-02-06 Andre Aubet > <[email protected]<mailto:[email protected]<[email protected]> > >>: > Jay, > > Can you share your full configuration for the two APs? I just tried > myself to configure a WGB using infrastructure-client on the root AP, > but it works great. > > Andre. > > 2014-02-06 Jay Killion (jakillio) <[email protected]< > mailto:[email protected] <[email protected]>>>: > No, I just used "station-role workgroup-bridge" configured. But you > make a great point, it's good to try the different options together to > find out what breaks what. > > > From: Jason Boyers > <[email protected]<mailto:[email protected]<[email protected]> > >> > Date: Thursday, February 6, 2014 8:19 AM > To: Jay Killion > <[email protected]<mailto:[email protected]<[email protected]> > >> > Cc: Andre Aubet > <[email protected]<mailto:[email protected]<[email protected]>>>, > "[email protected]< > mailto:[email protected]<[email protected]>>" > <[email protected]< > mailto:[email protected]<ccie_wireless@onlinestudylist > .com> > >> > > Subject: Re: [OSL | CCIE_Wireless] Autonomous - Reliability > > On the WGB, do you have "station-role workgroup-bridge multicast mode > client" configured? That is incompatible with the "infrastructure client" > command on the root side. I found it helpful to go through the > different combinations ("station-role workgroup-bridge" with and > without the various multicast mode commands, with and without > infrastructure client, and such) to ensure how things will and will > not work. There are some combinations that simply won't pass traffic. > > Jason Boyers, CCIE #26024 (Wireless) > Blog: netboyers.wordpress.com<http://netboyers.wordpress.com> > > On Thu, Feb 6, 2014 at 8:29 AM, Jay Killion (jakillio) > <[email protected] <mailto:[email protected] <[email protected]>>> wrote: > Hey Andre - > > Yes, the full requirement was, "Ensure that the association reliable. > So the AP disassociates clients only many packets are lost. Use the > maximum reliable setting for the association to stay up.". Given that > the word "reliable" and "reliability" are used 7 times in the CCO WGB > documentation and every single one of them are in the section on > "infrastructure client", I interpreted the requirement as wanting both > "packet retries" and "infrastructure client". But anyways... > > Yes, I was using both "auth open" and "auth eap" for the SSID. The > WGB would associate and authenticate every time without any issue, > even after rebooting both sides. The instant I removed > "infrastructure client" from the root side, without any further > changes, the WGB side immediately received DHCP and pings started working. > > I'm still not sure why it wouldn't work with "infrastructure client", > but good to know for the future. > > > From: Andre Aubet > <[email protected]<mailto:[email protected]<[email protected]> > >> > Date: Thursday, February 6, 2014 1:50 AM > To: Jay Killion > <[email protected]<mailto:[email protected]<[email protected]> > >> > Subject: Re: [OSL | CCIE_Wireless] Autonomous - Reliability > > Hi Jay, > > You really met an interesting behavior here!!! > > I just read the complete lab requirement, it says: > Ensure that the association reliable. So the AP disassociates clients > only many packets are lost. Use the maximum reliable setting for the > association to stay up. > > For this, I would have used the packet retries command I think. It > allows the client entry to be removed only after a specified number of > missed > 802.11 packets (maximum being 127 I think). > > About the infrastructure client, what it actually does: > > * sends a first time the multicast/broadcast frame, and re-send it in > an encapsulated unicast frame to the WGB. It allows the frame to be > acknowledged by the WGB. > * allows the WGB, which is normally treated as a wireless client, to > associate to an infrastructure only AP In your configuration, this is > weird the WGB can't get an IP address. You say the association works > fine, but the DHCP Discover isn't received by the DHCP server. If it > didn't work with a static IP address, I would think something is > missing in your configuration. > > By any chance, were you using the authentication network-eap method to > associate, or only authentication open eap. I think network-eap (Cisco > proprietary) is a requirement when using an infrastructure mode. > > Andre. > > 2014-02-06 Jay Killion (jakillio) <[email protected]< > mailto:[email protected] <[email protected]>>>: > Hi all - > > I'm working on WB2 lab 3 and the following requirement was given for > an autonomous WGB, "Ensure that the association is reliable." I > thought the question was looking for me to configure "infrastructure > client" on the root AP since CCO documentation says to do this for > "increased reliability". Turns out that wasn't what the lab was > looking for, but it did bring up an interesting result - no DHCP even > though the WGB associated without any issue. > > The other requirement for this task was to have the WGB receive it's > IP address via DHCP. I couldn't for the life of me figure out why > DHCP wasn't working, as my debugs showed the AP sending them but never > getting a reply (or being seen by the DHCP server). Even if I > configured a static IP address for the BVI, pings still wouldn't work. > > I finally looked at the answer to see what I was missing and noticed > IPX didn't use "infrastructure client" as part of their solution. I > removed that piece and everything immediately started working. I've > read what "infrastructure client" does - reliably deliver multicast > and ARP's, but I don't see why this broke the ping / DHCP from the WGB. > > Any insight? > > Thanks > Jay Killion, CCIE #17873 R/S > > > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc< > http://www.youtube.com/ipexpertinc> > > > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc< > http://www.youtube.com/ipexpertinc> > > > > > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc< > http://www.youtube.com/ipexpertinc> > > > > > > > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc > -------------- next part -------------- An HTML attachment was scrubbed... URL: </archives/ccie_wireless/attachments/20140212/bc4998fb/attachment.html> ------------------------------ _______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc End of CCIE_Wireless Digest, Vol 58, Issue 58 ********************************************* _______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc _______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
