Wireless Access

We are having a strange problem with our solution.

We have  a controller (7210 running 6.4.4.16) some 225AP on campus mode and a WPA2 SSID in tunnel mode.

 

When i generate packets with large sizes using iperf in my machine after a while all user on that SSID start having connection problems.

 

From what i have read in tunnel mode the controller receives and handles all 802.11 data packets, action frames and EAPOL frames over a GRE tunnel and that packets over 1472 would be dropped (anti replay in wpa2 http://www.airheads.eu/t5/Controller-Based-WLANs/Why-do-the-fragmented-or-out-of-order-WPA-WPA2-packets-get/ta-p/177784)  and i can see "AESCCM Decryption Failures" erros.

 

All this would be ok if it only affected the client that is doing this, but right now it affects all clients on that ap connected to that SSID.

 

So the big question is if anyone has also this problem and if a Aruba Guru can shed so light on this (i have also a case on tac).

 

Note - If i put the AP on decrypt mode all is ok (but i dont want them this way).

We don't expect that wireless clients would pass larger packets on a consistent basis.  Decrypt-tunnel is a way to avoid enabling jumbo frames on your network and to pass oversized packets.

 

If you feel your application is appropriate in tunnel mode, please open a TAC case and file a bug.

 

 

Thanx Colin, but is it normal this behaviour that a client doing this type of traffic kills all the other clients on the same SSID?

 

Wireless is a shared mechanism, so there are quite a few things that can be done by a single client to disrupt traffic like passing high levels of a certain type of traffic. Fortunately you know that decrypt tunnel can be enabled.

what exactly are you sending and how? What is your iperf string and how long does it run before it impacts other clients? I can't know what you're doing, but it's certainly possible that if one client is going to flood an AP with traffic that the AP can't moderate, that it could impact other clients connection quality. This can happen legitimately (say a single client subscribes to a high bandwidth multicas stream) and illegitimately (say a client starts flooding the air with large frame UDP packets consuming the radio). Would be good if you have airwave to also pull the graph of the radio stats for that specific AP radio while this test is ongoing to look at things like re-transmits and frame/phy errors, etc. 

thanks for the reply,

I think i am not generation that much traffic (iperf3.exe -c 10.80.250.7 -u -b 10m -i 1 -f m -l 1500 ) 10mb of big udp packets shouldnt impact the other users. It takes very few seconds for this to kill the other web traffic (if we are pinging with small packets at the same time they go trough wich is strange...).

All this makes my think that i and not starving the "air".

 

I also have clients saying that they have problems in APs in wich i am not doing the tests.

When i put the SSID in decrypt mode i also stop this behaviour (it drops my large packets but other clients dont have problems)

 

When the controller drops packets that arrive in the GRE tunnel out of order (i think 802.11 data packets)  do they drop all of sequencial packets also until the "good" one arrives?

Also does the AP puts more then one 802.11 data packets per GRE packet (from different users).

Because only in this scenario i can see why the droped packets of my sessions are braking the other user traffic (or something at the AP level...)

 

PS - I have opened a TAC case so i guess they will use the Airwave for advanced debug. I am also going to connect a AP directly in the same switch that the controllers are connected to take all other network gear from the equation.

 

 

Regards,

Vass

I know Colin (altough sometimes its very hard for the clients to understand that). But has i said i dont think i am doing sufficient "bad" traffic in this case, and i have people complaining also in other places of the Campus 

Some more info:

After talking with tac and lowering the SAP Mtu the problem was contained.

But i wasn´t happy with this solution and started digging more into it.

From various tests i am now thinking that one of our firewalls its trying to re-assemble the fragmented GRE packets and not being able to do it when there is a lot of fragmented packets, we are doing some more debugs to see if this is true.

Will post the results later on for future reference.