We solved the Throughput problem with Colin's valuable helps and analysis.
Firstly, we reduced the RF utilization. We have too high AP power on 2.4ghz band. We set it using the following configurations:
Configuration> Wireless> AP Configuration> click on “Kablosuz-1”. Expand RF Management, Expand 802.11g Radio. Click on Adaptive Radio Management. Click on Advanced. Change “Allowed Bands for 40mhz Channels” to “none”. Change the Max-TX-EIRP to 18, and change the Min-TX-Eirp to 12. Uncheck 80 mhz support. Click on Apply.
We haven't Broadcast Filtering on our Virtual Aps.
You can fix this by going to configuration:
Wireless> AP Configuration> click on “Kablosuz-1”. Expand Wireless LAN. Expand Virtual AP. Click on Kablosuz-1-vAPp. In the right pane, make sure that Drop Broadcast and Unknown Multicast has a checkbox next to it. Click on Apply. Click on SDU-eduroam-vAPp. In the right pane, make sure that Drop Broadcast and Unknown Multicast has a checkbox next to it. Click on Apply. Go to configuration> Wireless> AP Configuration> click on “SDU-Aps”. Expand Wireless LAN. Expand Virtual AP. Click on SDU-WiFi-vAPp. In the right pane, make sure that Drop Broadcast and Unknown Multicast has a checkbox next to it. Click on Apply.
Also we have too much logging enabled on the controller. The controller generates a lot of logs.
We use these commands to reduce log stress on our contoller.
config t
no logging level debugging arm
no logging level debugging arm subcat all
no logging level debugging arm subcat client-match
no logging level debugging arm subcat radio-mgmt
no logging level debugging network
no logging level debugging network subcat all
no logging level debugging network subcat dhcp
no logging level debugging network subcat mobility
no logging level debugging network subcat packet-dump
no logging level debugging security
no logging level debugging security subcat aaa
no logging level debugging security subcat all
no logging level debugging security subcat certmgr
no logging level debugging security subcat dot1x
no logging level debugging security subcat firewall
no logging level debugging security subcat ids
no logging level debugging security subcat ids-ap
no logging level debugging security subcat ike
no logging level debugging security subcat kerberos
no logging level debugging security subcat mobility
no logging level debugging security subcat ntlm
no logging level debugging security subcat packet-trace
no logging level debugging security subcat vpn
no logging level debugging security subcat webserver
no logging level debugging security subcat wl-sync
no logging level debugging system
no logging level debugging system subcat all
no logging level debugging system subcat amon
no logging level debugging system subcat amon-ale
no logging level debugging system subcat amon-amp
no logging level debugging system subcat ap
no logging level debugging system subcat configuration
no logging level debugging system subcat ha
no logging level debugging system subcat mapc
no logging level debugging system subcat messages
no logging level debugging system subcat pan
no logging level debugging system subcat reg-tbl
no logging level debugging system subcat snmp
no logging level debugging system subcat webserver
no logging level debugging user
no logging level debugging user subcat all
no logging level debugging user subcat captive-portal
no logging level debugging user subcat client-match
no logging level debugging user subcat dot1x
no logging level debugging user subcat mapc
no logging level debugging user subcat pan
no logging level debugging user subcat radius
no logging level debugging user subcat voice
no logging level debugging user subcat vpn
no logging level debugging wireless
no logging level debugging wireless subcat all
logging level warning wireless
logging level warning system
logging level warning network
logging level warning user
logging level warning arm
exit
After entering commands, the log situations were as follows:
(SduAruba7220) #show logging level verbose
LOGGING LEVELS
--------------
Facility Level Sub Category Process
-------- ----- ------------ -------
arm warnings N/A N/A
network warnings N/A N/A
security warnings N/A N/A
system warnings N/A N/A
user warnings N/A N/A
wireless warnings N/A N/A
Another problem is access points have a lot of bootstraps. We saw them using this command:
#show ap debug counters
According to Colin's theory, the cause of bootstraps is we use almost 200 APs and we have just one 1 gig port on controller. According to Colin's, a single gigabit Ethernet port for every 100 access points. That is true. This is cause our users and throughput to drop randomly. We need to add secong 1 GE links to controller. And we need to have a port channel.
Port Status
-----------
Slot-Port PortType AdminState OperState PoE Trusted SpanningTree PortMode Speed Duplex
--------- -------- ---------- --------- --- ------- ------------ -------- ----- ------
0/0/0 GE Disabled Down N/A Yes Disabled Access Auto Auto
0/0/1 GE Disabled Down N/A Yes Disabled Trunk Auto Auto
0/0/2 GE Enabled Up N/A Yes Disabled Trunk 1 Gbps Full
0/0/3 GE Enabled Down N/A Yes Disabled Access Auto Auto
0/0/4 GE Enabled Down N/A Yes Disabled Access Auto Auto
0/0/5 GE Enabled Down N/A Yes Disabled Access Auto Auto
There is an article about to set it up.
http://community.arubanetworks.com/t5/ArubaOS-and-Controllers/EtherChannel-between-Aruba-and-Cisco-switch/m-p/438/highlight/true#M45
The system works very vell. Thank you Colin Joseph.
Best regards,
Hakan Orcan
Suleyman Demirel University
Information Technologies Department
Network and Systems Management Group