Hey Rhod - You are correct that the WGB only supports a single VLAN, but the root AAP it connects to can have multiple VLANs (and SSIDs).
Jay Killion, CCIE #17873 R/S > >Message: 1 >Date: Thu, 13 Feb 2014 08:36:05 +1100 >From: Rhodri Jenkins <[email protected]> >To: [email protected] >Subject: Re: [OSL | CCIE_Wireless] Autonomous - Reliability >Message-ID: <[email protected]> >Content-Type: text/plain; charset="windows-1252" > >Interesting thread here guys, >I have a more fundamental question though? Everything I?ve ever read says >WGB?s do not support vlans. This would suggest otherwise. I have >configured WGB?s with clients in different vlans. >What am I missing? > >Rhod > > >On 10 Feb 2014, at 2:49 pm, [email protected] >wrote: > >> 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) >> >> From: Jeff Rensink <[email protected]> >> Subject: Re: [OSL | CCIE_Wireless] Autonomous - Reliability >> Date: 10 February 2014 2:49:42 pm AEDT >> To: Justin Kurynny <[email protected]> >> Cc: "Jay Killion \(jakillio\)" <[email protected]>, >>"[email protected]" <[email protected]> >> >> >> I'd agree. I have to assume they put the labs through their paces >>before releasing them. So they won't ask you to do something that's not >>possible due to bugs. It would be really poor quality control to just >>put something in the lab, assuming it will work as planned. But there >>are bugs that you could very well need to know how to work around (like >>the end station filter bug in ACS). >> >> Regards, >> >> Jeff Rensink : Sr Instructor : iPexpert >> CCIE # 24834 :: Wireless / R&S >> :: World-Class Cisco Certification Training >> >> Direct: +1.810.326.1444 >> :: Free Videos >> :: Free Training / Product Offerings >> :: CCIE Blog >> :: Twitter >> >> >> On Sun, Feb 9, 2014 at 9:33 PM, Justin Kurynny <[email protected]> >>wrote: >> 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. J 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]] On Behalf Of Jay >>Killion (jakillio) >> Sent: Sunday, February 09, 2014 17:37 >> To: Jeff Rensink; Andre Aubet >> Cc: [email protected] >> >> >> 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]> >> Date: Sunday, February 9, 2014 9:38 AM >> To: Andre Aubet <[email protected]> >> Cc: Jay Killion <[email protected]>, >>"[email protected]" <[email protected]> >> 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 >> CCIE # 24834 :: Wireless / R&S >> :: World-Class Cisco Certification Training >> >> >> >> Direct: +1.810.326.1444 >> :: Free Videos >> :: Free Training / Product Offerings >> :: CCIE Blog >> :: Twitter >> >> >> >> On Sat, Feb 8, 2014 at 3:33 AM, Andre Aubet <[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]>: >> >> >> >> 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 >> CCIE # 24834 :: Wireless / R&S >> :: World-Class Cisco Certification Training >> >> >> >> Direct: +1.810.326.1444 >> :: Free Videos >> :: Free Training / Product Offerings >> :: CCIE Blog >> :: Twitter >> >> >> >> On Fri, Feb 7, 2014 at 4:45 PM, Jeff Rensink <[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 >> CCIE # 24834 :: Wireless / R&S >> :: World-Class Cisco Certification Training >> >> >> >> Direct: +1.810.326.1444 >> :: Free Videos >> :: Free Training / Product Offerings >> :: CCIE Blog >> :: Twitter >> >> >> >> On Fri, Feb 7, 2014 at 1:04 PM, Jay Killion (jakillio) >><[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]> >> Date: Thursday, February 6, 2014 11:28 AM >> To: Jay Killion <[email protected]> >> Cc: Jason Boyers <[email protected]>, >>"[email protected]" <[email protected]> >> >> >> 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]>: >> >> 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]>: >> >> 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]> >> Date: Thursday, February 6, 2014 8:19 AM >> To: Jay Killion <[email protected]> >> Cc: Andre Aubet <[email protected]>, >>"[email protected]" <[email protected]> >> >> >> 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 >> >> >> >> On Thu, Feb 6, 2014 at 8:29 AM, Jay Killion (jakillio) >><[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]> >> Date: Thursday, February 6, 2014 1:50 AM >> To: Jay Killion <[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]>: >> >> 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 >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: ></archives/ccie_wireless/attachments/20140213/d82f637a/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 60 >********************************************* _______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
