Huawei AC6005-8 WLAN V200R006C10SPC200

[Prof. Michele GHERLONE]

Hi all.
I have recently installed a WIFI lan in my department with 31 AP Huawei
AP5130DN that communicate through a VLAN with the AC mentioned in the
subject.
I was wondering if anyone has got experience in setting up and configuring
such an environment with freeradius.
The AP are connected to six HP S3600 switches that send traffic to an
aggregation switch to which the AC is connected through one of its
Gigabitethernet interfaces.
The AC has been setup to do 802.1x PEAP authentication through one FR server.

root at bigserver:~# radiusd -v
radiusd: FreeRADIUS Version 3.0.12, for host i686-pc-linux-gnu, built on
Dec 13 2016 at 01:58:57
FreeRADIUS Version 3.0.12
Copyright (C) 1999-2016 The FreeRADIUS server project and contributors

The AC has 2 VLANs: 1 e 300 (same as all the aforementioned switches). All
relevant Gigabitethernet interfaces both on the switches and on AC are
link-type HYBRID with tagged VLAN 300 and untagged VLAN 1.
VLAN 300 is the management VLAN and all APs communicate with the AC
through CAPWAP protocol on VLAN 300.
VLAN 1 is the service VLAN and has layer 3 VLANIF 1 with IP 192.168.2.43
VLANIF has also ACL2000 with NAT rule 5: permit source 172.32.1.0
0.0.0.255
172.32.1.0 is the layer 3 ip address of VLAN 300 (AC is 172.32.1.1 on the
inbound interface).
AC and FR ping with no problems each other (192.168.2.43 <-> 192.168.2.1).
Freeradius is configured to listen to 192.168.2.1 on standard UDP port
1812 and 1813.
192.168.2.1 is also the ETH0 interface ip address of the linux server it
was configured on.
AC is also configured for accounting through FR.
Everything is working fine, meaning that FR *IS* capable of doing PEAP
with sql, accounting and simultaneous-use properly configured.
The only persistent problem are traffic bottlenecks between the FR and the
AC. Very rarely the packets  for completing the PEAP whole auth cycle are
exchanged subsequently; more often the AC stops sending packets after the
first or second Access-Challenge is sent by FR.
In a very low traffic scenario the situation happens less frequently and
authentications  succeed almost normally.
As soon as users number increases the UDP traffic slows down and users
experience unacceptable authentication delays.
The VAP forward mode is tunnel and NOT direct Forward mode.
I do not attach here radiusd -X output because the problem IS NOT in FR
configuration: like I said, PEAP authentication between AC and FR CAN
succeed. Of course I am more than willing to do it if I'll be asked to do
so.
My problem is something hindering the UDP packet flow communication
between 192.168.2.1 (freeradius) and 192.168.2.43 (AC).
I am writing to the list in the hope that someone has already dealt with
same equipment and possibly run into the same problem.
Any help and/or attention to my situation would be highly appreciated. How
could I for example debug the traffic flow regarding AAA on the AC? Am I
facing some trivial timeout issues or what is actually causing this
hindrance?
Is EAPOL taking place in the CAPWAP tunnel if the VAP is configured to do
tunnel forwarding mode?
What do I have to configure in order to establish some traffic priority
for the communication between AC and FR (both EAPOL and UDP traffic)? I've
been struggling with this issue for almost 1 month now, and I really am in
desperate need of someone familiar with my operating environment. Thanks
for your time and attention.
MacGherl60