Wireless Access

 View Only

  • 1.  AOS 10 – Poor Performance with Tunnelled SSIDs via Gateway

    Posted Jun 22, 2025 06:54 AM

    Hi all,

    We're currently working on a proof of concept using Aruba AOS 10 hardware, with a network design that includes Gateways for tunnelled SSIDs. During testing, we've encountered significant performance issues when using tunnelled SSIDs.

    Scenario:

    • SSID configured in bridged mode: ~180 Mbps download

    • Same SSID in tunnelled mode via Gateway: ~30 Mbps

    This performance drop is consistent and repeatable.

    Has anyone else experienced similar issues with tunnelled SSIDs in AOS 10?

    Ive some some info around checking MTU - the gateway is configured to use jumbo frames, and currently the Access points is on the same L2 as the gateway (as part of our troubleshooting).

    Thanks in advance for any insights!



  • 2.  RE: AOS 10 – Poor Performance with Tunnelled SSIDs via Gateway

    Posted Jun 22, 2025 07:23 PM

    if you are running L2 adjacency between AOS10 APs and gateways, then ensure the VLANs  associated with tunneled SSID are only defined at the Gateway.

    also note that I would not recommend using L2 adj in campus env.



    ------------------------------
    If my post was useful accept solution and/or give kudos.
    Any opinions expressed here are solely my own and not necessarily that of HPE or Aruba.
    ------------------------------



  • 3.  RE: AOS 10 – Poor Performance with Tunnelled SSIDs via Gateway

    Posted Jun 22, 2025 07:46 PM

    thanks.  The tunneled SSID are only on the gateway.

    I agree; in this case we have just tried to remove any other networking elements to see if the issue remained - which it has.


    Original Message


  • 4.  RE: AOS 10 – Poor Performance with Tunnelled SSIDs via Gateway

    Posted Jun 23, 2025 02:56 AM

    Does the traffic pass through a firewall between the APs and the Gateway? What version of AOS 10 are you running on your APs and Gateways? What model Gateway?

    If you expect to use jumbo frames at the Gateway you will have to ensure that the path between the AP and the Gateway also allows jumbo frames. This means all switches and routers that the GRE packets will pass through on their journey. 

    The validated solutions guide states this about Jumbo frames in a tunneled mode deployment:

    Jumbo MTU Support (Optional) Tunneled WLANs use GRE encapsulation, which adds overhead to the packet size. Standard MTU values are sufficient in most deployments. However, when clients generate large frames or when deploying User-Based Tunneling (UBT), enabling jumbo MTU support in the underlay is recommended. HPE Aruba Networking recommends configuring an MTU of 9198 on AOS-10 gateways and AOS-CX switches when large frames are expected. Improper MTU sizing can result in fragmentation, latency, and performance degradation under specific traffic conditions.

    Underlay validation should include path testing, proper routing configuration, and confirmation that all intermediate devices support the required MTU where applicable.


    Original Message


  • 5.  RE: AOS 10 – Poor Performance with Tunnelled SSIDs via Gateway

    Posted Jun 23, 2025 04:49 AM

    Software/Firmware Versions:

    • Gateways 10.4.1.7
    • Access Points: 10.7.1.1

    originally there was a firewall here between the devices

    • VLAN 10 had the APs within it.
    • VLAN 5 had the Gateways within it.

    These were routed by a firewall, with an MTU of 9000.

    As I couldn't get this to perform as I expected, I removed the firewall, and both the Gateway, and the AP are now both sitting on VLAN 5.  However pinging the interface of the AP from the firewall, I get fragmentation at 1252 (1280bytes) - which makes no sense to me.

    (9004-DCO) *#ping 192.168.95.100 packet-size 1252 df-flag 

! - Success  . - Failure  D - Duplicate Response
Press 'q' to abort.
Sending 5, 1252-byte ICMP Echos to 192.168.95.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1.775/2.9976/6.79 ms

(9004-DCO) *#ping 192.168.95.100 packet-size 1253 df-flag 

! - Success  . - Failure  D - Duplicate Response
Press 'q' to abort.
Sending 5, 1253-byte ICMP Echos to 192.168.95.100, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

    What is also a little odd to be is I get the same result to the other gateway:

    (9004-DCO) *#ping 192.168.95.13 packet-size 1252 df-flag

! - Success  . - Failure  D - Duplicate Response
Press 'q' to abort.
Sending 5, 1252-byte ICMP Echos to 192.168.95.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1.502/2.2436/2.747 ms

(9004-DCO) *#ping 192.168.95.13 packet-size 1253 df-flag

! - Success  . - Failure  D - Duplicate Response
Press 'q' to abort.
Sending 5, 1253-byte ICMP Echos to 192.168.95.13, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

    However, if I ping the firewall I can ping up to 1472

    (9004-DCO) *#ping 192.168.95.1 packet-size 1472 df-flag

! - Success  . - Failure  D - Duplicate Response
Press 'q' to abort.
Sending 5, 1472-byte ICMP Echos to 192.168.95.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1.416/1.7398/2.037 ms

    I can't go beyond this however.  But from the firewall, I can ping the gateway, without fragmentation up to the expected 8972.

     


    Original Message


  • 6.  RE: AOS 10 – Poor Performance with Tunnelled SSIDs via Gateway

    Posted Jun 23, 2025 05:01 AM

    The switch and all other switches in the path between AP and GW will require MTU to be configured for jumbo frames also.


    Original Message


  • 7.  RE: AOS 10 – Poor Performance with Tunnelled SSIDs via Gateway

    Posted Jun 23, 2025 05:21 AM

    This is a very simple topology at the moment.

    • 1x Switch
    • 1x Firewall
    • 2x Gateways
    • 2x Access Points

    So the gateway can ping the firewall, via the switch with a packet size of 1472.  It can ping the other gateway, or the access point with a packet size of 1252.

    The firewall can ping both the gateway and the access point using a packet size of 8972 - so the odd thing appears to to be outbound traffic from the Aruba Gear itself.


    Original Message


Related Content