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]> 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 <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 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 <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 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
