Link Search Menu Expand Document
calendar_month 07-Mar-24


Microbranch enables an access point to act as a scaled-down branch gateway, providing remote connectivity via IPsec to a hub site. Microbranch is great for remote teleworks and small branches, such as a small suite. Microbranch shares much of the fundamental functionality as the branch gateway, including backup tunnels to other cluster members and data center preference. However, Microbranch has a maximum of five active hub sites.

Microbranch also supports features such as cloud security integration, Policy Based Routing, and WAN health checks. Microbranch does not support Dynamic Path Steering.

Microbranch supports three different tunneling modes which are linked to an SSID: Centralized Layer 2 , Layer 3 NATed, and Layer 3 Routed.

Each tunneling type can be run in parallel on the same Microbranch AP. The table below shows capabilities for each mode.

Layer 3 RoutedLayer 3 NATedCentralized Layer 2
Route orchestration
Local Subnets/DHCP services
Subnets shared with VPNC (Fully Routable in DC)
Internet traffic broken out locally
Load balancing based on route cost
Route orchestration
Local Subnets/DHCP services
Subnets not shared with VPNC
Internet traffic broken out locally
Load balancing based on route cost
No Route orchestration
Subnets exist on VPNC
Full tunneling to VPNC
(Split tunneling can be done with PBR)
Load balancing evenly distributed between VPNC’s


In the topology above, Radius proxy is required for layer 2 mode, since the VPNC is the default gateway for clients. In Centralized Layer 2 mode, the VPNC requires a VRRP Virtual IP address. The Virtual IP address is used as the Radius proxy IP address. If an organization is using layer 3 mode and needs to enable Radius proxy, the VPNC requires a layer 2 connection to establish a VRRP session. It is recommended to use an LACP connection for redundancy.

When deciding the tunneling method, consider:

Layer 3 Routed - The AP makes routing decisions based on its route table. There is a max of 512 routes, so it is important to use branch and hub route summarization. This method is optimal because there is less configuration overhead for the admin and it enables the AP to make optimal routing decisions (without requiring hairpinning through the VPNC). This is the preferred method to deploy Microbranch APs.

Layer 3 NATed - APs use the routing table to make routing decisions; however, traffic initiated by a client in a NATed SSID cannot reach resources located at the hub site. NATed SSIDs do not share their subnet with the SD-WAN fabric. This is a good method to use for guest SSIDs.

Centralized Layer 2 (CL2) - APs tunnel all traffic to the VPNC by default. The VLAN for each branch site resides on the VPNC. APs can break out locally to the Internet based on PBR policy; however, if local breakout is used, it is generally recommended to send all internal IP address space to the VPNC and send all other routing address space to the Internet. This method is generally recommended when devices require layer 2 adjacency to work.

Microbranch APs can use both layer 2 and layer 3 modes in parallel. The VPNCs also can support both modes in parallel; however, if layer 2 is in use, the VPNCs must be L2 adjacent to enable VRRP as described in the previous section.

Layer 2 tunnel orchestration differs from that of layer 3. Layer 2 tunneling builds tunnels to all members within a cluster and load-balances based on the client load. For example, if a hub site has two gateways, the Microbranch AP builds a tunnel to both VPNCs. If client traffic must be forwarded, the AP sends it over a tunnel to VPNC1 and the next client is sent to VPNC2.

Layer 3 tunneling also builds a tunnel to every VPNC; however, traffic is forwarded based on route cost which is dynamically adjusted based on the Overlay Route Orchestrator. This works in the same manner as a branch gateway.

clustering and load balancing

Back to top

© Copyright 2024 Hewlett Packard Enterprise Development LP. The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Aruba Networks and the Aruba logo are registered trademarks of Aruba Networks, Inc. Third-party trademarks mentioned are the property of their respective owners. To view the end-user software agreement, go to Aruba EULA.