Wireless Access

 

I have a work-from-home user complains about RAP-155 consuming too much bandwidth that over-subscribe her monthly download allowance.  I check the RAP-155 in AirWave also running MRTG at the switchport that connects to port E0 of RAP-155.  Both graphs agree that RAP-155 constantly consuming between 1.5 to 2 Mbps coming from the Internet into the RAP when idling. 

 

Is this normal behavior of RAP?  My current solution is telling user to turn off the RAP when they are not in use.

 

My AOS is 6.3.1.8, and RAP terminates at a 3600 controller.

 

Best Regards,

#3600

The RAP will consume some bandwidth from management traffic being sent to the controller. I'm not positive on how much that is as I haven't ever measured it.

You can run:

show datapath session table | include tunnel<#>

(replace tunnel number with the tunnel ID for that rap)

Thank you both for your replies.

 

I do not expect the RAP needs that much bandwidth to communicate with controller while idling (I’ll call it keep-alive, but I am not sure if it is the correct terminology)

 

Let’s exam the data path of three RAP-155s, which have the same data consumption rate: RAP-1 is having active client while RAP-2 and RAP-3 are idling.  It looks like in RAP-1 tunnel 17 is keep-alive while in RAP-2 and RAP-3 are tunnel 50 and tunnel 28 respectively.  We can see the large number of packets in all three RAPs for keep-alive

 

Note that all RAPs are working normal

 

(WC03) # show datapath session table | include 10.129.254.84
10.129.254.84   172.18.254.96   47   0     0      0/0     0 46  0   tunnel 17   469f 16903     3873876    FC
10.129.254.84   172.18.254.96   17   8211  8419   0/0     0 0   1   local       8    0         0          FYI
10.129.254.84   172.18.254.96   17   8209  8419   0/0     0 0   1   tunnel 82   6    0         0          FYCI
10.129.254.84   172.18.254.96   17   8209  8421   0/0     0 0   0   tunnel 82   2    0         0          FYCI
10.129.254.84   172.18.254.96   17   8211  8224   0/0     0 0   0   local       2    0         0          FYI
10.129.254.84   172.18.254.96   17   8209  8209   0/0     0 0   0   tunnel 82   1c   6         5302       FCI
172.18.254.96   10.129.254.84   47   0     0      0/0     7 24  0   tunnel 17   46a0 8924852   948888740  F
172.18.254.96   10.129.254.84   17   8421  8209   0/0     0 0   0   tunnel 82   3    0         0          FYI
172.18.254.96   10.129.254.84   17   8419  8211   0/0     0 0   0   local       9    1         161        FCI
172.18.254.96   10.129.254.84   17   8419  8209   0/0     0 0   0   tunnel 82   7    0         0          FYI
172.18.254.96   10.129.254.84   17   8224  8211   0/0     0 0   0   local       3    2         1032       FCI
172.18.254.96   10.129.254.84   17   8209  8209   0/0     0 0   1   tunnel 82   1d   0         0          FYI

(WC03) # show datapath session table | include 10.129.254.76
10.129.254.76   172.18.254.96   47   0     0      0/0     0 48  0   tunnel 50   39ae 197343    75126093   FC
172.18.254.96   10.129.254.76   47   0     0      0/0     7 24  0   tunnel 50   39af 12740453  1405272065  F

(WC03) # show datapath session table | include 10.129.254.83
10.129.254.83   172.18.254.96   47   0     0      0/0     0 46  0   tunnel 28   77f3 24116     4901394    FC
172.18.254.96   10.129.254.83   47   0     0      0/0     7 24  0   tunnel 28   77f4 16180546  1713550184  F
(WC03) #

 

 

I do not have solution for this problem, but a work around

If your RAP user vlan (wired or wireless) is the same with the controller ip address vlan you will see thousand of ESP protocol packet from the controller to the RAP over the Internet. 

 

So the solution is creating a vlan for RAP wired port and also for Wi-Fi SSID, then you see bandwidth reduce from average 1.5 Mbps to only a few hundred packets

In this AirWave graph you can see the bandwidth usage before and after the change.  Before the change, user only turns on RAP when she works, but now she let the RAP online all the time and the RAP only consums a small bandwidth.

ngutri,

 

The user might have high bandwidth because of broadcasts that are propagated on that wired VLAN that the user is on.  Any broadcasts sent on a VLAN, copies of it must be sent to every RAP that has a wired interface in that VLAN.  When working with wireless, the "drop broadcast and multicast" at the Virtual AP level stops this from happening.  With regards to the wired VLAN, enabling "broadcast and multicast optimization" on the VLAN on the controller does the same thing...

 

Please see the knowledgebase article here:  http://community.arubanetworks.com/t5/Controller-Based-WLANs/How-to-stop-unknown-unicast-from-LAN-to-be-flooded-by-the/ta-p/179934