Whats causing Input drops and overruns between 3502lap and 3750g switch?
At our HQ we have 6 3502 LAPs terminating into a 3750g switch stack. We have an issue with performance in some instances which I think is RF related, however in doing all due diligence I am looking at the Ethernet layer as well between the switch and the AP's in the area's of the performance issues.
I am seeing some Input Overruns and Input Drops on all of the AP's at the HQ location. One I am looking at now has 330 overrun and 34564 input drops. I have other remote sites and when checking those interface statistics they have 0 input drops and overruns. The other difference is that the remote sites are in flex connect mode whereas the HQ is in local mode.
Are the input drops and overruns a concern, or is it just because there's a lot more traffic at the HQ?
I use the GUI to the 5508 wireless lan controller to manage the AP's.
In the room where they are having problems, maybe 8 PC's and a few iphones are connected?
It appears that they are non-overlapping channels.
For instance some of the computers that jump to a further away AP 3 floors up I see are on channels 44,48 and 3 floors up that AP is on channels 60,64. For 2.4 Ghz the AP in the room is channel 1 and the AP 3 floors up is 11, and the AP 1 floor up is 6.
I think I may make a post in the wireless forums to progress further on some SNMP traps I see: Though I just wanted to make sure the switching / Ethernet layer was well taken care of also.
Interference Profile Updated to Pass for Base Radio MAC: 50:1c:bf:80:25:e0 and slotNo: 0
Interference Profile Failed for Base Radio MAC: 50:1c:bf:80:5f:d0 and slotNo: 0
Rogue AP : 00:15:ff:46:ce:9d removed from Base Radio MAC : 50:1c:bf:80:5f:d0 Interface no:0(802.11b/g)
Rogue AP : 00:15:ff:46:ce:9d removed from Base Radio MAC : 50:1c:bf:80:25:e0 Interface no:0(802.11b/g)
Coverage hole pre alarm for client d8:d1:cb:97:5a:02 on 802.11b/g interface of AP 58:35:d9:39:5d:90 (AP4). Hist: 1 3 1 4 4 7 6 14 10 8 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
keithsauer507, did you ever get this issue resolved? We have the same problem with our 3502, 3602, and 3702 LWAPs. Only difference is that we're not getting output drops on our switches feeding the problem LWAPs. All of the LWAPs hanging off this switch and others (4510R+E, 3560X-48PS, etc.) are getting Input Overruns and Input Drops. The problem's not isolated to a particular switch or type of switch, but seems to be prevalent on the entire subnet. In other words, some subnets have zero to minimal input buffer issues, and every LWAP on other subnets have the errors. I'm thinking it’s a traffic issue (multicast, broadcast, etc.) on the LWAPs management VLAN but don't see anything obvious.
Got a TAC Case open since last week with no luck so far.
Update, TAC suggested that we configure our multicast handled by the controllers to multicast (not unicast, which is how we're configured). We are looking into making this change, without enabling multicast service on the rf side of the house to help reduce the additional cpu cycles when unicast packets are created by multicast seen by the controller's management interfaces. However, after two weeks of working with TAC, we noticed that we were no longer getting input overruns, and input drops were minimal so are taking our time with the change and closed the case.
Plus, cpu cycles don't seem very high (around 50% for our 7 controllers and 4000 users, so no rush.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...