ArubaOS-CX Dynamic Segmentation: UBT Configuration

Dynamic segmentation decouples who a user is from where the cable is plugged in. Instead of mapping a switch port to a VLAN, the access switch derives a role for the user - from 802.1X, MAC authentication, or a RADIUS attribute - and the role determines the policy, including whether the traffic is carried in a tunnel to a central gateway. User-based tunneling (UBT) makes the access switch the tunnel endpoint, so policies that previously required a controller in every closet can be applied on CX switches. This is how the pieces fit together and how to configure them on AOS-CX.

Concepts

• Role: a named policy object applied to a port or to a client (via RADIUS). It carries the VLAN, ACL, QoS and the gateway-zone assignment.
• Gateway zone: the definition of the tunnel destination - a primary and optional backup UBT gateway address.
• UBT client mode: the access switch acts as the tunnel client, encapsulating user traffic towards the gateway.
• UBT gateway mode: on the central platform (a CX switch or a gateway/controller), the tunnel is terminated and the user's traffic is routed or bridged into the destination network.

The design goal is usually that guest or contractor traffic within a role is tunnelled to a central enforcement point with the full security stack, while internal users are switched locally with their own role policy.

Access switch configuration

switch(config)# port-access ubt-client-mode
switch(config)# port-access gateway-zone
switch(config-gateway-zone)# name dc-zone
switch(config-gateway-zone)# primary-controller ip 10.10.10.11
switch(config-gateway-zone)# backup-controller ip 10.10.10.12
switch(config-gateway-zone)# exit

switch(config)# port-access role employee
switch(config-pa-role)# gateway-zone zone dc-zone
switch(config-pa-role)# exit

switch(config)# interface 1/1/1
switch(config-if)# port-access role employee

On the gateway side, the mirror configuration enables the gateway role for the same zone and terminates the tunnels. The exact parameter names differ slightly between AOS-CX releases, so verify the running configuration after the first device is configured and treat that as the template for the rest of the fleet - the concepts (zone, primary/backup controller, role binding) are stable, the keywords have evolved.

If roles come from RADIUS rather than statically per port, the switch derives the role after authentication and applies the same gateway-zone mapping - which is the configuration that makes a user's segmentation follow them to any port.

Verify

switch# show port-access clients
switch# show port-access role employee
switch# show port-access gateway-zone
switch# show port-access ubt statistics
switch# show running-config | include ubt

show port-access clients is the primary troubleshooting view: it shows the authenticated client, the derived role and the current port-access state. If a role is applied but traffic is not reaching the central gateway, the tunnel statistics and the gateway-zone configuration are the next stops.

Troubleshooting checklist

• Client gets no role: authentication problem, not segmentation. Check RADIUS reachability, the authentication method enabled on the port, and the role name returned by the server - a typo in a RADIUS attribute silently yields a default role.
• Tunnels do not form: routing and reachability between the access switch's source address and the gateway, plus any intermediate firewall. The tunnel is only as good as the underlay path.
• Tunnel up, application broken: MTU. Encapsulation reduces the usable payload, so check the path MTU and consider MSS clamping on the gateway rather than lowering every access port MTU.
• Users lose connectivity when the gateway fails: configure the backup controller and test the failover deliberately. An untested backup is a design assumption.
• High CPU on the access switch: tunnelling large east-west flows through a closet switch is a capacity decision, not a security one. Keep tunnelled traffic to what genuinely needs central enforcement.

Rolling it out safely

1. Deploy one role with one gateway zone on a lab switch and validate authentication, tunnelling and application behaviour end to end.
2. Enable it on a pilot floor, monitoring role assignment and tunnel statistics daily.
3. Extend per building, keeping the role definitions centralised so policy changes do not require per-switch edits.
4. Document the fallback behaviour: what happens to a client when the tunnel cannot be established matters more than what happens when it can.

Related: ArubaOS-CX access vs trunk port modes, ArubaOS-CX VSX configuration guide, and ArubaOS-CX DHCP snooping configuration.

原文链接：https://arubanetworking.hpe.com/techdocs/central/2.5.7/content/nms/aos-cx/cfg/conf-cx-ubt.htm