Re: [WIRELESS-LAN] Cisco APs losing CAPWAP session

[Dan Brisson]

Garry, We actually did bump up the ARP pps limit right from the start.  We found out pretty quickly we needed to do that when we enabled it on the wired ports before we installed wireless.  We've set that to: ip arp inspection limit rate 70 I did find a switch that had a DAI drop in the log, but it didn't correlate with when the AP went down and even further, the port that was reported was not the port the AP was connected to that dropped.  So much for the DAI theory, but yeah, IP Source Verify is perhaps silently dropping it, for whatever reason. DHCP snooping is still enabled on the switches that we disabled DAI and IP Source-verify. Thanks, -dan Dan Brisson Network Engineer University of Vermont (Ph) 802.656.8111 dbris...@uvm.edu On 2/6/2012 3:17 PM, Garry Peirce wrote: If DAI, I’d expect your switch logs would show the AP ports being disabled (and assume you must have auto-recovery enabled) Perhaps somehow hitting DAI’s ARP default inbound pps limit? If so, question may be why the switch would see more than (default) 15 pps of ARP traffic inbound from lightweight APs.   If no DAI entries on the switch, then might be source guard more silently dropping packets for some reason. You might try configuring one/or the other feature to help determine which it is.   While working without issue now, is DHCP snooping (alone) still configured on the AP ports?     From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Dan Brisson Sent: Monday, February 06, 2012 9:47 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Cisco APs losing CAPWAP session   For those following this thread, while we still haven't determined the exact cause of this problem, we also have not had a drop from an AP where we turned off DAI and IP source verify.  Seems logical that one (or both) of those could be causing problems, although what is not entirely logical is how that would be related to load/activity, since the APs never drop when the students are gone on break. TAC has been very responsive and at this point I've asked if we can get someone from the Switching side to look at the possibility that DAI and/or IP Source verify could be the cause. -dan Dan Brisson Network Engineer University of Vermont (Ph) 802.656.8111 dbris...@uvm.edu On 2/1/2012 2:38 PM, Dan Brisson wrote: Ah right, yes, 'mls qos' is NOT configured on any of the 3560X switches. We used DAI and DHCP snooping b/c the majority of APs are actually in student rooms due to, well, no other place really to put them.  :)  Now that you've brought that up, though, we had to go in the ceiling in one of our newer, bigger complexes.  I'm going to turn off DAI and IP Source verify there and see if the drops stop. Will let folks know what I find. Thanks! -dan Dan Brisson Network Engineer University of Vermont (Ph) 802.656.8111 dbris...@uvm.edu On 2/1/2012 12:41 PM, Garry Peirce wrote: Dan, A small but important point to verify re: QoS. By ‘no QoS in place’, does that mean the global  ‘mls qos’ is NOT configured on the resHall switches or that no specific QoS config has been configured?  Ex. if the global ‘mls qos’ is enabled, all ports (including APs) would be untrusted by default with all packet markings remarked as 0. Also, any QoS/service policies on the relevant router’s interfaces?   Given the L2 functions you mention are unique to the ResHall side, I’d disable them on the ports used by the APs. I wouldn’t expect these L2 security functions to be needed on known AP ports and removing them might provide further insight on the issue. DAI disabling AP ports due to ARP pps threshold (odd)? Is errdisable auto-recovery of DAI enabled? Any log data from the switch of an affected AP?       From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Dan Brisson Sent: Wednesday, February 01, 2012 11:35 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Cisco APs losing CAPWAP session   Ok, thanks for validating.  It also seemed a bit strange to me and yes, I checked a bunch APs that haven't dropped recently and they all showed 10-12ms. One thing that occurred to me is we are doing DHCP snooping and Dynamic Arp Inspection on the 3560Xs.  That is unique to this part of campus as we haven't yet rolled that out to the entire admin side. Thanks, -dan Dan Brisson Network Engineer University of Vermont (Ph) 802.656.8111 dbris...@uvm.edu On 2/1/2012 10:23 AM, Mike King wrote:   On Wed, Feb 1, 2012 at 10:03 AM, Dan Brisson <dbris...@uvm.edu> wrote:   It's been awhile since I've read these, but If I interpret this correctly,  It took 1m 15s for the AP to associate to the controller.  That's a very long time.   Mine usually have association in the 10-20 second range.   Not sure what that indicates, but it's an anomaly from my point of view.   I don't think it's a rouge herring.  (See Backhoe joke from earlier in the thread)   Mike ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.