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
