Dynamic port configuration in Aruba OS-CX switches

- Posted in Aruba Network by

Aruba's OS-CX switches have the ability to profile devices connected to ports and dynamically assign roles and policies (ACLs) to those ports. The ACLs can include the usual stuff--filtering on source, destination and protocol. But, they can also include configuration parameters like VLAN assignment.

Here's a simple example that can be useful when deploying access points with bridged VLANs. In this example, the switch makes a profile of the connected device using LLDP (you can use CDP, too), parses the response and assigns a role to the port. The role has policies that assign VLANs.

To see how this would work, let’s say that we have an access point on port 1/1/10. Examining the LLDP query on the port, we get the following:

enter image description here

In our test for the presence of an AP, we will search the description for "IAP". To make the example a little more interesting, we will also skip any AP-305s we might find. The following are rules that will match our LLDP port access test. These are arranged like a sieve; the first pattern that matches wins.

 port-access lldp-group AP-lldp-group
      seq 10 ignore sys-desc 305
      seq 20 match sys-desc IAP

Next, we define the role and the policies that we want to associate with access points that match the above port-access tests. The block below says that the role is called "lldp-AP," and that the policies "create a trunk and allow VLANs 12,22,40 and 100, and make 100 be the native VLAN."

 port-access role lldp-AP                                                                                                                                                                   
     vlan trunk native 100                                                                                                                                                                  
     vlan trunk allowed 12,22,40,100               

This last section is the glue that pulls the port-access tests and the role assignment together. It says "if the device on port x matches AP-lldp-group tests then assign the role of lldp-AP."

 port-access device-profile AP-lldp-devprofile                                                                                                                                              
     associate role lldp-AP
     associate lldp-group AP-lldp-group

Dynamic profiling can be applied to other kinds of devices too, including printers, projectors and phones. When used in conjunction with Aruba Central or NetEdit, elements of the policies and port-access tests can be described using variables, such as this:

 port-access role lldp-AP                                                                                                                                                                   
     vlan trunk native %_native_VLAN%                                                                                                                                                                  
     vlan trunk allowed 

When used in conjunction with ClearPass and controllers, the ports can implement enhanced profiling, role assignment and dynamic segmentation whereby VLANs that don’t even exist on the switch can be tunneled from other parts of the organization.

Aruba AOS10

- Posted in Aruba Network by

Previous enterprise Aruba operating environments AOS 6.5 and AOS 8 were controller-based. Controller-based access points are the product of a time when APs were radio heads, capturing and producing wireless packets and ferrying them to a central controller. Little data processing was done at the access point—particularly in tunnel mode. Radio management, authentication and encryption were all performed centrally, at the controller.

Because of the increasing complexity of wireless networking protocols, the increasing speeds of wireless connections, and the increasing capability of access points, it is becoming advantageous to let the AP perform all of the processing and bridge traffic to the network at wire speed.

This is giving controllers the diminutive role of configuration and reporting. Configuration and reporting are less demanding than wireless network termination, and require much less bandwidth. Accordingly, it is possible to place portal anywhere, including out on the Internet.

Under Aruba AOS10, each access point is a controller. It gets it configuration from Aruba AOS10 Central. It acts in tandem with its neighboring access points to create a seamless wireless experience.

enter image description here

The picture above shows the components of an Aruba AOS10 network.

Access points (and switches) communicate with Aruba Central for configuration and logging. Each AP bridges traffic directly onto the network natively, via VLANs or both. Each AP communicates with its neighbors as far as several hops away. This enables roaming and forwarding of firewall state.

ClearPass, when in use, provides advanced authentication and security services, role-based access, network awareness and UEBA. ClearPass Policy Manager communicates with the access points directly, implementing RADIUS-based user access and Aruba firewall policies.

Controllers are not required, but they can be included in AOS10 for users who wish to have tunneled SSIDs or tunneled node 802.1x-based switch port access. The benefits of tunneled traffic are that data traverse the network fully encrypted and tunnels make it possible to extend access to remote layer-2 networks. Central on Prem(ises) duplicates the cloud-based AOS10 Central management capability onsite. It is offered particularly for those enterprises that, by choice or regulation, prefer to manage the network from within their own network.

  • Kevin Dowd