Branch Controller Config for Cloud Services Controllers. Aruba M3MK1, 7024, 7240, 620, 7280, 650, ArubaOS 6.5.3.x, 3200

Chapter 11

Branch Controller Config for Cloud Services Controllers

Many distributed enterprises with branch and remote offices and locations use cost-effective hybrid WAN connectivity solutions that include low-cost DSL, 4G and LTE technologies, rather than relying solely on traditional E1/T1 or T3/E3 dedicated circuits. 7000 Series Cloud Services Controllers are optimized for these types of locations, which are more likely to use cloud security architectures instead of dedicated security appliances, and where clients are likely to access applications in the cloud, rather than on local application servers.

Throughout this document the term branch controller will refer to a 7000 Series Series Cloud Services controller that has been configured via a branch config group created using the ArubaOS Smart Config WebUI.

ArubaOS supports these distributed enterprises through the following features designed specifically for branch and remote offices: n n n n n n

Authentication survivability allows 7000 Series controllers to store user access credentials and key reply attributes whenever clients are authenticated with external RADIUS servers or LDAP authentication servers, providing authentication and authorization survivability when remote authentication servers are not accessible.

Integration with existing Palo Alto Networks Firewalls, like WildFire™ anti-virus and anti-malware detection services. In deployments with multiple Palo Alto Networks (PAN) firewalls, 7000 Series controllers can select the best PAN firewall based on priority and availability.

Policy-based routing on each uplink interface, which allows you specify the next hop to which packets are routed. ArubaOS supports multiple next-hop lists, to ensure connectivity in the event that a device on the list becomes unreachable.

Uplink and VPN redundancy, and per-interface bandwidth contracts to limit traffic for individual applications (or categories of applications) either sent from or received by a selected interface.

Packet compression between Aruba devices (such as devices at the branch and main office), to maximize the amount of data that can be carried by the network.

A WAN health-check feature that uses ping-probes to measure WAN availability and latency on each uplink.

The following diagram depicts managed node where a branch controller in the branch office learns the address, routing information, and other provisioning information from the master controller.

ArubaOS 6.5.3.x

| User Guide Branch Controller Config for Cloud Services Controllers | 217

This chapter describes the features and functions of a branch controller, and includes the following topics: n n n n n n

Branch Deployment Features on page 218

Zero-Touch Provisioning on page 232

Using Smart Config to create a Branch Config Group on page 239

PortFast and BPDU Guard on page 260

Preventing WAN Link Failure on Virtual APs on page 262

Branch WAN Dashboard on page 263

n n n n n n n n

Branch Deployment Features

This section describes the following branch controller features. For details on the configuration parameters for each of these features, see

Using Smart Config to create a Branch Config Group on page 239

.

Layer-3 Redundancy for Branch Controller Masters on page 219

WAN Failure (Authentication) Survivability on page 220

WAN Health Check on page 226

WAN Optimization through IP Payload Compression on page 226

Interface Bandwidth Contracts on page 227

Branch Integration with a Palo Alto Networks (PAN) Portal on page 228

Branch Controller Routing Features on page 231

Cloud Management on page 232Cloud Management on page 232

218 | Branch Controller Config for Cloud Services Controllers ArubaOS 6.5.3.x | User Guide

Scalable Site-to-Site VPN Tunnels

ArubaOS 6.4.4.0 and later supports site-to-site IPSEC tunnels based on a Fully Qualified Domain Name (FQDN).

When you identify the remote peer for a branch config group using an FQDN, that config group can be applied across multiple branch controllers, as the configured FQDN can resolve to different IP addresses for each local branch, based on local DNS settings.

In ArubaOS 6.4.4.0 and later releases, crypto maps for site-to-site VPNs support a VLAN ID as the identifier for the source network. When the VPN settings are pushed to branch controller, the IKE negotiation process uses the IP address range for the VLAN. This feature allows you to push the same source network configuration to multiple branch controllers, as each branch controller negotiates a different source source network IP for its

VLAN based on the IP pool for that local branch.

Layer-3 Redundancy for Branch Controller Masters

ArubaOS 6.4.4.0 introduces support for a redundant secondary master controller in branch controller deployments. This prevents a scenario where a master controller acts as a single point of failure if the link to the master goes down, or a co-located Master-Standby VRRP controller pair fail due to a network failure or local natural disaster.

Configuring Layer-3 Redundancy

The IP address of a primary master and a secondary, backup master controller can be defined for a branch during the

Zero-touch provisioning process , and is either defined in a DHCP server, is manually entered into the

branch controller during the initial startup dialog, or defined via an Activate server. The primary and secondary master controllers must be manually kept in synchronization by ensuring all the configuration, certificates, and branch controller whitelist, AP whitelist and local user database are the same in both of them.

Database settings are not automatically synchronized from a primary master to a secondary master with Layer-3 redundancy. All database settings, certificates, whitelist settings and profile configurations must be kept in sync manually.

Viewing Controller Connectivity Status

The status of the branch's connection to a primary and secondary master controller appears in the

WAN dashboard

page of the branch controller WebUI. To display the current status of the branch controller's connectivity to the master and secondary master IP addresses, click the Layer3 Redundancy tab on the

Status section of the dashboard.

Figure 39 Branch Controller Redundancy Status

Failover Behaviors

When a provisioned branch controller detects that its primary master is unreachable, it attempts to reconnect to the primary master for the time period defined by the

Master L3 Redundancy Switchover Timeout

in its branch controller configuration. If the branch controller cannot reconnect to the primary master controller during this switchover timeout period, and the secondary controller is up and reachable, the branch controller

ArubaOS 6.5.3.x


reloads and associates to the secondary controller as the new master. The branch controller then synchronizes its branch and global configuration settings from the new master, and reloads again to apply those settings.

n n n n n n n n

WAN Failure (Authentication) Survivability

This section contains the following information about the authentication survivability feature. This feature is supported on 7000 Series controllers.

Supported Client and Authentication Types

Administrative Functions

About the Survival Server

Trigger Conditions for Critical Actions

Authentication for Captive Portal Clients

Authentication for 802.1X Clients

Authentication for MAC Address-Based Clients

Authentication for WISPr Clients

Authentication survivability allows controllers to provide client authentication and authorization survivability when remote authentication servers are not accessible. It stores user access credentials, as well as key reply attributes, whenever clients are authenticated with external RADIUS servers or LDAP authentication servers.

When external authentication servers are not accessible, the controller uses its local Survival Server to continue providing authentication and authorization functions by using the user access credentials and key reply attributes that were stored earlier.

Authentication survivability is critical to WLANs managed by branch controllers since most branch controllers use geographically remote authentication servers to provide authentication and authorization services. When those authentication servers are not accessible, clients can't access the WLAN because the branch controller can't authenticate them.

This feature can be configured for branch controllers using the Smart Config WebUI, or for master and local controllers using the aaa auth-survivability commands in the command-line interface. For details on configuring this feature using the Smart Config WebUI, see

WAN Configuration on page 256 .

Supported Client and Authentication Types

The following combination of clients and authentication types are supported with the authentication survivability feature (see

Table 55

):

Table 55: Clients and Supported Authentication Types

Clients

Captive Portal clients

802.1X clients

Authentication Methods

Password Authentication Protocol (PAP) n n

Termination disabled : Extensible Authentication Protocol-Transport

Layer Security (EAP-TLS) with an external RADIUS server

Termination enabled : EAP-TLS with Common Name (CN) lookup with an external authentication server

PAP External Captive Portal clients using the XML-API

MAC-based Authentication clients PAP


Clients

VPN clients

VIA and other VPN clients

Wireless Internet Service Provider roaming (WISPr) clients

Authentication Methods n n

PAP with an external authentication server

CN lookup with an external authentication server

PAP method and CN lookup

PAP

In this initial release, the external authentication server can be either a RADIUS server or an LDAP server.

Supported Key Reply Attributes

The following key reply attributes are supported: n n n n n n n n n

ARUBA_NAMED_VLAN

ARUBA_NO_DHCP_FINGERPRINT

ARUBA_ROLE

ARUBA_VLAN

MS_TUNNEL_MEDIUM_TYPE

MS_TUNNEL_PRIVATE_GROUP_ID

MS_TUNNEL_TYPE

PW_SESSION_TIMEOUT

PW_USER_NAME

Support Restrictions

The authentication survivability feature has the following support restrictions: n n n n n

The Survival Server cache database is station-based (thus, the MAC address is the key), so authentication survivability is not supported for any station with a zero MAC address.

For a client using EAP-TLS, you must install the issuer certificate of the Survival Server certificate as a

TrustedCA certificate in the client station.

For an 802.1X client using EAP-TLS that does not terminate at the controller, the issuer certificate for the client certificate must be imported as a TrustedCA or an intermediateCA certificate at the controller—just as the same certificate must be installed at the terminating External RADIUS server.

The Survival Server does not support the Online Certificate Status Protocol (OCSP) nor the Certificate

Revocation List (CRL) for EAP-TLS.

Authentication survivability will not activate if Authentication Server Dead Time is configured as 0.

To configure Authentication Server Dead Time, on the controller, navigate to: Configuration > SECURITY >

Authentication > Advanced > Authentication Timers > Authentication ServerDeadTime (min) .

Administrative Functions

This section describes the scenarios that illustrate the functionality that the authentication survivability feature provides. For more information, see: n


ArubaOS 6.5.3.x


Enabling Authentication Survivability on a Local Branch Controller

You can configure each local branch controller to enable or disable Authentication Survivability; by default, this feature is disabled.

When authentication survivability is enabled, the enabled authentication survivability state is published, which instructs the Survival Server to start storing client access credential attributes and Key Reply attributes.

Configuring the Survival Server Certificate

A default server certificate is provided in the controller so that the local Survival Server can terminate EAP-TLS

802.1X requests.

Best practices is to import a customer server certificate into the controller and assign it to the local survival server.

Configuring the Lifetime of the Authentication Survivability Cache

All access credentials and Key Reply attributes that are saved in the local Survival Server remain in the system until they expire. The system-wide lifetime parameter auth-survivability cache lifetime has a range from 1 to 72 hours, and a default value of 24 hours. You must configure this parameter in each controller.

User Credential and Key Reply Attributes Are Saved Automatically

When a station is authenticated by an external authentication server, required access credential attributes and

Key Reply attributes are stored in the local Survival Server RADIUS database in an enabled authentication survivability ArubaOScontroller.

Expired User Credential and Key Reply Attributes Are Purged Automatically

At the controller, a timer task that runs every 10 minutes purges expired user credential attributes and Key

Reply attributes that are stored in the Survival Server cache.

About the Survival Server

A local Survival Server runs on the controller to perform authentication functions, as well as EAP-termination using the RADIUS protocol.

The Survival Server consists of a turn-key FreeRADIUS server, plus MySQL database tables.

When authentication survivability is enabled, a FreeRADIUS server runs on the controller. The Survival Server is configured to accept RADIUS requests from the local host and retrieve the access credential and Key Reply attributes from the MySQL database. The Survival Server supports EAP-TLS, PAP, and Common Name (CN) lookup.

Trigger Conditions for Critical Actions

This section describes the trigger conditions for critical authentication survivability actions.

Storing User Access Credential and Key Reply Attributes to Survival Cache

Aruba OS stores the user access credential and Key Reply attributes under the following conditions:

1. Authentication survivability is enabled

2. The non-zero MAC-address client is authenticated using one of the following options: a. Authenticated with an External RADIUS server using PAP or EAP-TLS b. Authenticated with an External LDAP server using PAP c. Successful query on Common Name (CN) with an External RADIUS or LDAP server


Picking Up the Survival Server for Authentication

The Survival Server performs an authentication or query request when authentication survivability is enabled, and one of the following is true:

1. All servers are out of service in the server group if fail-through is disabled

2. All in-service servers failed the authentication and at least one server is out of service when fail-through is enabled.

Access Credential Data Stored

In addition to the username, the following access credential data is stored: n n n

Password Authentication Protocol (PAP): authmgr receives the password provided by the client and then stores the encrypted SHA-1 hashed value of the password.

When employing 802.1X with disabled termination using EAP-TLS, the EAP indicator is stored.

The CN lookup EXIST indicator is stored.

Authentication for Captive Portal Clients

This section describes the authentication procedures for Captive Portal clients us, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the Survival Server takes over the handling of authentication requests.

This section describes the following authentication scenarios: n n

Captive Portal clients authentication using Password Authentication Protocol (PAP)

External Captive Portal clients authentication using the XML-API

Captive Portal Client Authentication Using PAP

Table 56

describes what occurs for Captive Portal clients using PAP as the authentication method.

Table 56: Captive Portal Authentication Using PAP

When Authentication Servers Are

Available n n

If authentication succeeds, the associated access credential with an encrypted SHA-1 hash of the password and Key Reply attributes are stored in the Survival Server database.

If authentication fails, the associated access credential and Key Reply attributes associated with the PAP method (if they exist) are deleted from the Survival Server database.

When Authentication Servers Are Not Available

When no in-service server in the associated server group is available, the Survival Server is used to authenticate the Captive portal client using PAP.

The Survival Server uses the previously stored unexpired access credential to perform authentication and, upon successful authentication, returns the previously stored Key Reply attributes.

External Captive Portal Client Authentication Using the XML-API

Table 57

describes the authentication procedures for External Captive Portal clients using the XML-API, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the Survival Server takes over the handling of authentication requests.

ArubaOS 6.5.3.x


Table 57: Captive Portal Authentication Using XML-API

When Authentication Servers Are Available

For authentication requests from an External Captive

Portal using the XML-API, PAP is used to authenticate these requests with an external authentication server.

n If authentication succeeds, the associated access credential with an encrypted SHA-1 hash of the password and Key Reply attributes are stored in the

Survival Server database.

n If authentication fails, the associated access credential and Key Reply attributes associated with the PAP method (if they exist) are deleted from the


When Authentication Servers Are Not

Available

When no in-service server in the associated server group is available, the Survival Server is used to authenticate the Captive portal client using PAP.

The Survival Server uses the previously stored unexpired access credential to perform authentication and, upon successful authentication, returns the previously stored

Key Reply attributes.

Authentication for 802.1X Clients

This section describes the authentication procedures for 802.1X clients, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the

Survival Server takes over the handling of authentication requests.

For 802.1X clients, the authentication scenarios include two different 802.1X termination modes: n n

802.1X termination disabled at the Wireless LAN Controller

802.1X termination enabled at the Wireless LAN Controller

802.1X Termination Disabled at the Wireless LAN Controller

Table 58: 802.1X Authentication Using EAP-TLS


For an 802.1X client that terminates at an external RADIUS server using EAP-TLS: n n

If authentication is accepted, the associated access credential with the EAP-TLS indicator, in addition to the

Key Reply attributes, are stored in the Survival Server database.

If authentication is rejected, the associated access credential and Key Reply attributes associated with the

EAP-TLS method (if they exist) are deleted from the



Available

When there is no available in-service server in the associated server group, the Survival Server terminates and authenticates 802.1X clients using

EAP-TLS.

The Survival Server uses the previously stored unexpired access credential to perform authentication and, upon successful authentication, returns the previously stored Key Reply attributes.

In this case, the client station must be configured to accept the server certificate assigned to the Survival

Server.

802.1X Termination Enabled at the Wireless LAN Controller

For an 802.1X client for which termination is enabled at the wireless LAN controllerusing EAP-TLS with

Common Name (CN) lookup, a query request about the Common Name is sent to the external authentication server.

The external authentication server can be either a RADIUS server or an LDAP server.


Table 59: 802.1X Client Authentication Using EAP_TLS with CN Lookup

When Authentication Servers Are Available n n

If the query succeeds, the associated access credential with a returned indicator of EXIST , plus the Key Reply attributes, are stored in the Survival Server database.

If the query fails, the associated access credential and

Key Reply attributes associated with the Query method

(if they exist) are deleted from the Survival Server database.


Available

When there is no available in-service server in the associated server group, the Survival Server performs CN lookup for 802.1X clients for which termination is enabled at the controller using EAP-

TLS.

The Survival Server returns previously stored Key

Reply attributes as long as the client with the EXIST indicator is in the Survival Server database.

Authentication for MAC Address-Based Clients

This section describes the authentication procedures for MAC address-based clients, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the Survival Server takes over the handling of authentication requests.

Table 60: MAC-Based Client Authentication Using PAP

When Authentication Servers Are Available n n

If authentication succeeds, the associated access credential, along with an encrypted SHA-1 hash of the password and Key Reply attributes, are stored in the


If authentication fails, the associated access credential and Key Reply attributes associated with the PAP method (if they exist) are deleted from the Survival

Server database.


Available

When there is no available in-service server in the associated server group, the Survival Server authenticates the MAC-based authentication client using PAP.

The Survival Server returns previously stored Key

Reply attributes as long as the client with the EXIST indicator is in the Survival Server database.

Authentication for WISPr Clients

This section describes the authentication procedures for Wireless Internet Service Provider roaming (WISPr) clients, both when the branch's authentication servers are available and when they are not available. When the authentication servers are not available, the Survival Server takes over the handling of authentication requests.

The external authentication server can be either a RADIUS server or an LDAP server.

ArubaOS 6.5.3.x


Table 61: WISPr Authentication Using PAP



Available

For a WISPr client authenticated by an external server using

PAP: n If authentication succeeds, the associated access credential, along with an encrypted SHA-1 hash of the password and Key Reply attributes, are stored in the


n

If authentication fails, the associated access credential and Key Reply attributes (if they exist) associated with the PAP method are deleted from the Survival Server database.

When there is no available in-service server in the associated server group, the Survival Server authenticates the WISPr client using PAP.

Upon successful authentication, the Survival Server uses the previously stored unexpired credential to perform authentication, and returns the previously stored Key Reply attributes .

WAN Health Check

The health-check feature uses ping-probes to measure WAN availability and latency on selected uplinks. Based upon the results of this health-check information, the controller can continue to use its primary uplink, or failover to a backup link. Latency is calculated based on the round-trip time (RTT) of ping responses. The results of this health check appear in the WAN section of the

Monitoring Dashboard .

For details on configuring this feature using the Smart Config WebUI, see


.

WAN Optimization through IP Payload Compression

Data compression reduces the size of data frames that are transmitted over a network link, thereby reducing the time required to transmit the frame across the network. IP payload compression is one of the key features of the WAN bandwidth optimization solution, which is comprised of the following elements: n n n

IP Payload Compression

Traffic Management and QoS

Caching

Since the branch controller can send traffic to destinations other than the corporate headquarters on the same link, the preferred method is to enable payload compression on the IPsec tunnel between the branch controller and the master controller.

IP payload should be enabled only between Aruba devices. When this hardware-based compression feature is enabled, the quality of unencrypted traffic (such as Skype4b or Voice traffic) is not compromised through increased latency or decreased throughput.

Starting from ArubaOS 6.5.1, WAN optimization through IP payload compression is supported in 7205 controllers.

Distributed Layer 3 Branch Deployment Model

In the branch deployment model shown in

Figure 40

, the IPsec tunnels are terminated on the master controller. IPsec tunnels are treated as master-local tunnels.


Figure 40 Branch Deployment Model with Master Controller in HQ

Modes of Operation

There are three modes of operation for the deflation and inflation compression processes: n n n

Static Compression

For static compression, a predefined Huffman code is used that may not be ideal for the block in question, but it usually achieves acceptable compression. The advantage of static compression is its speed of execution.

Dynamic Compression

The advantage of dynamic compression is a higher compression ratio. However, dynamic compression is slower than static compression, as it requires two passes to complete the process.

No Compression

You can use no compression for data such as an embedded image file that might already be in a compressed format. Such data does not compress well, and may even increase in size.



n

Interface Bandwidth Contracts

7000 Series controllers have the ability to classify and identify applications on the network. If a 7000

Series controller is configured as a branch office controller, you can create bandwidth contracts to limit traffic for individual applications (or categories of applications) either sent from or received by a selected interface.

There are two basic models for using this feature.

Limiting lower-priority traffic : If there is a lower-priority application or application type that you want to limit, apply a bandwidth contract just to that application, and allow all other application traffic to pass without any limits.

ArubaOS 6.5.3.x


n

Protecting higher-priority traffic : If you want to guarantee bandwidth for a company-critical application or application group, you can add that application to an exception list, then apply a bandwidth contract to all remaining traffic.

You can apply bandwidth contracts using one or both of these models. Each interface supports up to 64 bandwidth contracts. An interface bandwidth contract is applied to downstream traffic before a user-role bandwidth contract is applied, and upstream traffic, the user-role bandwidth contract is applied before the interface bandwidth contract.

For all traffic using compression and encryption, bandwidth contracts are applied after that traffic is compressed and encrypted. If you apply more than one bandwidth contract to any specific category type, then the bandwidth contracts are applied in the following order.

1. A contract that explicitly excludes an application

2. A contract that explicitly excludes an application category

3. A contract that applies to a specific application

4. A contract that applies to a specific application category

5. A generic bandwidth contract, not specific to any application or application category



App and App Category Visibility

WAN uplinks are typically of relatively low bandwidth. The actual upstream/downstream bandwidth that a

WAN uplink provides is usually different from what the service provider provides. Hence, ensure that the traffic transmitted by a Branch controller matches the actual rate provided by the service provider. This avoids congestion in the link from the Branch controller to the WAN. Congestion may cause traffic to be dropped and if the uplink has both high and low priority traffic, low priority traffic might not be dropped first. Hence, a

Branch controller classifies traffic into multiple priorities and shapes the egress traffic to match the actual upstream bandwidth.

If there is any unused bandwidth in the downstream direction, a Branch controller allows the users to use the unused bandwidth although this bandwidth exceeds the allocation of the user. A Branch controller ensure this by using an ingress scheduler with minimum-bandwidth guarantees.

Minimum bandwidth guarantees are provided on per traffic class basis. Additional classification is done on the traffic flows and these are assigned newer traffic classes. Use hardware assist or software scheduler to schedule these new traffic classes to achieve minimum-bandwidth guarantees. Maximum bandwidth is enforced with bandwidth contracts.

Allocate higher bandwidth to critical applications and schedule them with higher priority.

Due to the wide range of bandwidth possibilities, percentages are used to provision bandwidth for the interface bandwidth contracts. Use the templates to configure multiple different bandwidth links across all

Branch controllers. For example, 50 % for 500 Mbps for a 1 Gbps link or 50 mbps for a 100 mbps uplink.

On the WAN dashboard, for the AppRF window, currently the statistics/flows are detailed to view the AppRF stats on a per-uplink basis.

Branch Integration with a Palo Alto Networks (PAN) Portal

Branch controller deployments can leverage their networks' existing PaloAlto infrastructure to access more advanced security services, including antivirus services, malware detection and seamless integration with the

Palo Alto Networks WildFire TM cloud-based threat detection.


Enable Palo Alto firewall integration on a master controller to securely redirect internet inbound traffic from branch controllers using the branch config group into the PAN firewall. Although this configuration setting can be used on standalone or local controllers, this feature can only be used on controllers in these types of deployments when used in conjunction with the controller uplink VLAN manager feature.

The uplink VLAN manager is enabled by default on branch controller uplinks. Master or local (non-branch) controllers using the PAN portal feature must enable the uplink VLAN manager using the uplink command in the controller command-line interface.

Figure 41 Branch Controller and PAN Firewall Integration

Integration Workflow

The following steps describes the work flow to integrate a branch controller with a Palo Alto Networks (PAN)

Large-Scale VPN (LSVPN) firewall.

1. Palo Alto Portal certificates are installed on the master controller, and the master controller is configured with the Palo Alto portal IP address or FQDN, Palo Alto certificate, and the username and password for device authentication using the Configuration> Branch > Smart Config > WAN section of the master controller WebUI.

2. The 7000 Series branch controller is provisioned via Aruba Activate and downloads its configuration

(including Palo Alto Networks integration settings).

3. The Palo Alto portal may be configured with the device number (a text string comprised of the device serial number followed by its MAC address) of the branch controller(s) at each remote office site. This allows the branch controller to bypass the username and password challenge to authenticate to the portal.

4. The branch controller initiates a secure connection to the Palo Alto portal. Once the branch controller is authenticated, the Palo Alto portal sends the branch controller a list of PAN gateways and priority levels.

Once the branch controller is authenticated, that device appears in the PAN satellite list, as shown in the figure below.

ArubaOS 6.5.3.x


Figure 42 Palo Alto Networks Active Satellites List

.

5. The branch controller uses the Palo Alto Networks gateway list and credentials from the portal to contact all

PAN gateways. Each PAN gateway sends the branch controller information that allows the branch controller to automatically create a secure IPsec tunnel and exchange branch subnet routes with each PAN gateway.

6. The branch controller maintains a priority list of IPsec tunnels to each PAN gateway to enable failover in the event a PAN gateway becomes unreachable.

7. Policy-based routing access control lists (ACLs) on the branch controller selectively routes traffic to the PAN gateways.

8. Traffic redirected from the branch controller is inspected via the Palo Alto Networks firewall.

Configuration Prerequisites

The Palo Alto Networks LSVPN framework can integrate with a branch controller by establishing an IPsec tunnels between the firewall and the controller. Integrating a Palo Alto Networks firewall with a 7000

Series controller requires that all user traffic is routed, so it can be managed by a policy-based routing access control list.

The following certificate requirements must be fulfilled before the branch controller can integrate with the Palo

Alto Networks Large-Scale VPN (LSVPN) framework: n n n the LSVPN framework must be installed and active on your network. For more information on configuring

Palo Alto Networks products, refer to the Palo Alto Networks Technical Documentation portal .

The CA certificate used by the Palo Alto portal must be installed on the master controller, so that it can be pushed down to the branch controllers.

On the PAN gateway devices, you must enable the accept published routes option, and the devices must install the server certificates derived from the management portal root CA.

In deployments with multiple PAN firewalls, you must configure the PAN management portal with a list of gateways and the priorities for each PAN gateway. Even if the PAN management portal uses serial number registration with preregistered serial numbers or MAC addresses, best practice is to configure LDAP, Radius,

Kerberos or Local Database authentication as well. This allows a controller to authenticate to the portal even if the portal does not recognize the controller's MAC address.




Branch Controller Routing Features

The following sections describe some of the features that can be configured using the Smart Config WebUI. For details on configuring these feature using the Smart Config WebUI, see

Routing Configuration on page 249 .

Uplink Routing Using Nexthop Lists

A next-hop IP is the IP address of a adjacent router or device with Layer-2 connectivity to the controller. If the controller uses policy-based routing to forward packets to a next hop device and that device becomes unreachable, the packets matching the policy will not reach their destination.

The nexthop list provides redundancy for the next-hop devices by forwarding the traffic to a backup next hop device in case of failures. If the active next-hop device on the list becomes unreachable, traffic matching a policy-based routing ACL is forwarded using the highest-priority active next-hop device on the list.

If preemptive failover is enabled and a higher priority next hop becomes reachable again, packets are again forwarded to the higher priority next-hop device.

For more information on creating a routing policy that references a nexthop list, see

Configuring Firewall Policies on page 381

.

A maximum of four next-hop device entries can be added to a nexthop list. Each next-hop device can be assigned a priority, which decides the order of selection of the next hop. If a higher priority next-hop device goes down, the next higher priority active next-hop device is chosen for forwarding.

If all the next-hop devices are configured with same priority, the order is determined based on the order in which they are configured. If all the next-hops devices are down, traffic is passed regular destination-based forwarding.

In a typical deployment scenario with multiple uplinks, the default route only uses one of the uplink next-hop devices for forwarding packets. If a next hop device becomes unreachable, the packets will not reach their destination.

If your deployment uses policy-based routing based on a nexthop list, any of the uplink next hop devices could be used for forwarding traffic. This requires a valid ARP entry (route-cache) in the system for all the policybased routing next-hop devices. Each controller supports up to 32 nexthop lists.

In a branch office deployment, the site uplinks can obtain their IP addresses and default gateway using DHCP.

In such deployments, the nexthop list configuration can use the VLAN IDs of uplink VLANs. If the VLAN gets an

IP address using DHCP, and the default gateway is determined by the VLAN interface, the gateway IP is used as the next-hop IP address.

Branch deployments may also require policy-based redirection of traffic to different VPN tunnels. The nexthop list allows you to select an IPsec map to redirect traffic through IPsec tunnels.

Policy-Based Routing

Policy-based routing is an optional feature that allows packets to be routed based on access control lists (ACLs) configured by the administrator. By default, when a controller receives a packet for routing, it looks up the destination IP in the routing table and forwards the packet to the next-hop router. If policy-based routing is configured, the nexthop device can be chosen based on a defined access control list.

In a typical deployment scenario with multiple uplinks, the default route only uses one of the uplink next-hop devices for forwarding packets. If a next-hop device becomes unreachable, the packets will not reach their destination. If your deployment uses policy-based routing based on a nexthop list, any of the uplink next-hop devices can be used for forwarding traffic. This requires a valid ARP entry (Route-cache) in the system for all the policy-based routing next hop devices.

ArubaOS 6.5.3.x


Inbound Interface Access Lists

In a branch controller environment, where an IPsec map defines the connections between the local branch controllers and a master controller, the global routing ACL master-boc-traffic is applied to all IPsec maps between the master and the branch controllers. If any branch controller requires a different ACL, access the command-line interface of that branch controller and issue the command routing-policy-map branch <macaddr> access-list <acl> to associate a different ACL to the L3 GRE tunnel between that one branch controller and its master. This local setting will override the global settings defined in the master-boc-traffic ACL. For more information on configuring routing ACLs, see

Creating a Firewall Policy on page 382

.

To immediately associate a branch controller to the secondary master without waiting for the switchover timeout period to elapse, navigate to the Network>Controller>System settings page of the branch controller WebUI, and click the Switchover link.

If a branch controller detects that the link to the primary master controller is active but the branch cannot properly connect to the primary master due to a configuration error, the branch controller will wait for 10 minutes, then reboot and attempt to reconnect to the primary master. After 10 failed reboot and reconnect attempts, the branch controller will return to a factory default state and restart the provisioning process.

Cloud Management

ArubaOS enables the 7000 Series controllers to be managed by Aruba Central at a future date.

All communication between the controllers and Central will be secured. The controllers can establish connection with Central even if the controllers are behind NAT servers.

If the topology includes master and local controllers, a single master controller can communicate with Central.

In a master-local cluster topology, a local controller can communicate with both the master controller and

Central. The master controller will be the source for configuration data of the local controllers. Central manages the local configuration on the local controller.

Zero-Touch Provisioning

Traditionally, the deployment of controllers was a multiple step process where the master controller information and local configurations were first pre-provisioned. After the local controller connected to the network, it established a secure tunnel to the master and downloaded the global configuration.

Zero touch provisioning makes the deployment of local controllers plug-n-play. The local controller now learns the required information from the network and provisions itself automatically. A 7000 Series branch controller is a zero-touch provision (ZTP) controller that automatically gets its local and global configuration and license limits from a central controller.

A controller does not need to be configured as a branch controller to be provisioned using ZTP.

ZTP offers the following advantages over a standard local controller: n n n simple deployment reduced operational cost limits to provisioning errors

The main elements of ZTP are: n n auto discovery of the primary master (and optionally, backup master) controller.

configuration download from the master controller


Provisioning a controller includes completing the following: n n n setting the role setting the country code configuring the local configuration

The local configuration is the configuration that is specific to a controller. That is, not the global configuration shared by a network of controllers. This includes, but is not limited to, IP addresses and VLANs.

Once the controller is provisioned, it is ready to obtain its global configuration either by: n n

The administrator entering the global configuration directly from the WebUI or CLI of a master controller

The controller retrieving the global configuration from a master controller

Previously the steps of setting the role, setting the country code, and configuring the local configuration could only be performed manually by an administrator. With ZTP, these steps can be automatically completed.

The local configuration that a branch controller retrieves through ZTP is called as branch config group.

A controller that is deployed using ZTP is called as branch controller.

Only the 7000 Series cloud services controllers may be deployed as branch controllers.

Before you Begin

Before you deploy a 7000 Series branch controller, use the smart config feature on the master controller to a create branch config group. The master controller can push a branch config group configuration to a branch controller when the branch becomes active on the network. The smart config feature is enabled by default. For more information on branch config group settings, refer to

Using Smart Config to create a Branch Config

Group on page 239 .

The parameters of role, country code, and IP address of the master controller are collectively known as the provisioning parameters.

Provisioning Modes for Branch Deployments

The administrator has the choice of several provisioning modes that alter how the branch controller is supplied with its own IP address, role, country code, and branch config group.

During the various provisioning modes, the branch controller is supplied with the IP address of the primary master controller, or, for deployments requiring Layer-3 redundancy, the IP addresses of the primary and backup master controllers. Once the branch controller learns the IP address of the primary master controller, the branch controller contacts the master controller and retrieves its branch config group.

Provisioning a controller means defining the following values for that device: n n n the role of the controller (master or branch) the country code local configuration settings

ArubaOS supports the following provisioning modes for branch controllers: n auto: In this mode, branch controller: l l l obtains its IP address from DHCP obtains its role, country code, and the IP addresses of the primary controller and any defined secondary controller from DHCP Options or a provisioning rule in Activate retrieves its branch config group from the primary master controller

ArubaOS 6.5.3.x


n n mini-setup: In this mode, the branch controller: l has its role set to branch when mini-setup is initiated l l l obtains its IP address from DHCP is configured through the console with its country code and the IP address of the primary master controller and (optionally) the secondary master controller IP.

retrieves its branch config group from the primary master controller full-setup: In this mode, the branch controller: l is configured with its role set to branch through the console l l l is configured to obtain its IP address through manual configuration of a static IP, DHCP, or PPPoE is configured through the console with its country code and the IP address of the primary master controller and (optionally) the secondary master controller IP retrieves its branch config group from the primary master controller

Automatically Provisioning a Branch Controller

When a factory-default branch controller boots, it starts the auto-provisioning process.

First it will obtain its IP address through DHCP by sending a DHCP discover on the default uplink port. The default uplink port is configured as an access port in VLAN 4094.

Second, it will attempt to retrieve the provisioning parameters from the DHCP options in the DHCP lease it has obtained. If the provisioning parameters could not be obtained from the DHCP options, the branch controller will attempt to retrieve the provisioning parameters from Activate.

If the branch controller is unsuccessful in retrieving the provisioning parameters from Activate, it will retry in 30 seconds. The branch controller keeps trying to retrieve the provisioning parameters from Activate every 30 seconds until it is successful or the administrator interrupts Auto-Provisioning by initiating mini-setup or fullsetup.

To interrupt the auto provisioning process, enter the string mini-setup or full-setup at the initial setup dialog prompt shown below.

Auto-provisioning is in progress. Choose one of the following options to override or debug...

'enable-debug' : Enable auto-provisioning debug logs

'disable-debug': Disable auto-provisioning debug logs

'mini-setup' : Stop auto-provisioning and start mini setup dialog for smart-branch role

'full-setup' : Stop auto-provisioning and start full setup dialog for any role

Enter Option (partial string is acceptable):_

DHCP Options

When the branch controller sends the DHCP discover message to obtain its IP address, it adds a DHCP option

60 b Vendor Class Identifier to that DHCP discover message, where DHCP Option 60 is set to “ArubaMC”.

If the DHCP Offer does have DHCP Option 60 = ArubaMC, the branch controller will accept the DHCP lease and send a DHCP request. It will also look for DHCP Option 43 – Vendor Specific Information in the DHCP Lease. If

DHCP Option 43 is present in the Offer, the branch controller will parse it to learn the provisioning parameters.

The role is not explicitly specified in DHCP Option 43. However, the controller will set its Role to branch if the other provisioning parameters are present in DHCP Option 43.

If the DHCP Offer does not have DHCP Option 60 = ArubaMC, the branch controller will still accept the DHCP lease and send a DHCP request. However, once it is bound to the IP address, it will initiate the next mode of auto-provisioning and query Activate for a provisioning rule.


DHCP Server Provisioning

The branch controller adds ArubaMC as a DHCP option-60 vendor class identifier in its DHCP discovery messages, so the DHCP offer from the server must include ArubaMC as a DHCP option-60 vendor class identifier. The controller gets the master information and country code from the DHCP server, which is configured with the master information corresponding to that identifier. The server may also send vendorspecific information (VSI - option 43) in its response to the controller.

Before you deploy a branch controller using ZTP, configure the DHCP server with the following information: n n

The option-60 vendor class identifier ArubaMC

Option-43 Vendor Specific Information (VSI) with the primary master IP address, the country code, and optionally, a secondary master IP (for deployments requiring Layer-3 redundancy). This VSI must be in one of the following formats, where the IP address of a master controller is in dotted-decimal notation (a.b.c.d) format or a fully qualified domain name format (master.example.com), and the country code contains a valid ISO 3166 country codes, such as US , AU , or IN l

<Master-IP-address> l l

<Master-ip-address>,<Country-code>

<Primary-master-IP-address>, <Country-Code>,<Secondary-master-IP-address>

If the DHCP offer from the server does not include ArubaMC as DHCP option 60, the branch controller will still accept the DHCP Lease and send a DHCP Request. However, once the branch controller is bound to an IP

Address, it will query Activate for additional provisioning information. If the controller does not receive the

ArubaMC identifier through option-60, or if the received IP address is not valid, option-43 is completely discarded and ZTP moves to the next discovery method. For details, refer to

Activate Provisioning on page 235

Activate Provisioning

If the branch controller does not receive its provisioning parameters through DHCP options, it will query

Activate for a provisioning rule that assigns that branch to a master controller.

When a branch controller establishes an HTTPS connection to the Activate server and requests provisioning information, the Activate server authenticates the controller and provides that branch device with provisioning information, including the IP address of its master controller and secondary master, and its country code. If the branch controller is unsuccessful in retrieving the provisioning parameters from Activate, it will retry in 30 seconds. The branch controller will keep trying to retrieve the provisioning parameters from Activate every 30 seconds until it is successful, or the administrator interrupts the auto-provisioning by initiating Mini-Setup or

Full-Setup provisioning.

Before you can use Activate to associate branch controllers with a master controller, you must configure additional device settings on each branch and master controller, create a folder for those branch devices, then assign a provisioning rule to that folder that associates the branch controllers to a specified master. Use the following procedures to configure device details for the master and branch controllers, create folders, and define the provisioning rule.

Upgrading an ArubaOS 6.x Device to ArubaOS 8.x via Activate

Starting with ArubaOS 6.5.2, a factory-default controller running ArubaOS 6.x can use Activate Zero-Touch

Provisioning to upgrade its software to ArubaOS 8.x as part of the provisioning process. If Activate detects that a factory-default branch controller running ArubaOS 6.5.2 or later has been assigned a Managed Device to

Master Controller provisioning rule, Activate will automatically send that branch controller the information it needs to automatically download and upgrade to the latest version of ArubaOS 8.x.

Configuring Device details for a Branch Controller

When you place an order for a controller, that device appears in the Activate Devices list displaying the preconfigured settings for its serial number, MAC address, and software image. Before you can add a branch

ArubaOS 6.5.3.x


controller to a master controller whitelist, you must use the Activate interface to assign a name to each branch controller, and use the Activate interface to identify a master controller in a branch controller deployment.

Follow the steps below to use Activate to configure branch or master controller device settings

1. Click the Devices icon at the top of the page to display the Devices page.

2. Select a branch or master controller from the Devices list. If the list is very large, you can click the filter icon by any Devices list column heading and choose which entries to display, then select the branch controller from the smaller, filtered list.

3. If the controller will be used as the master controller, select the Master Controller checkbox.

4. In the Device Detail section of the Devices page, enter the following values: n

Device name : (Required) an IP address or fully-qualified domain name for the branch or master controller n n

Full name : (Optional) a user-friendly name for the device

Description : (Optional) a short text string describing the device

5. Click Done to save your settings.

Figure 43 Device Details for a Branch Controller

Creating a New Branch Controller Folder

Associate multiple branch controllers to the same master controller by moving those branch controllers into a single Activate folder.

A folder can contain only one model of branch controller, using the same country code and mapping to the same branch config group. Different folders need to be created for branch controllers of different model types, or that use a different country code or branch config group.

Follow the steps below to add a new folder to the Folders list:

1. Click the Setup icon to display the Setup page.

2. Click the New link in the title bar of the Folders list. The Create a New Folder window appears.

3. Enter the following information for the folder: n n

Name : Name of the new branch controller folder. The folder name must be 100 characters or less, and cannot include the characters ?

, # or & .

Parent : The new folder's parent folder. The new folder will be created under the selected parent.


n

Notes : (Optional) Use this field to add any additional notes about the folder.

4. Click Done to save the new folder.

Configuring the Provisioning Rule

A folder can only have one provisioning profile configured within it and the Provisioning Profile can only reference one branch config group. consequently, it is necessary to create a folder and associate the provisioning rule for each group of branch controllers that share a common branch config group.

Follow the steps below to create a new provisioning rule for the new branch controller folder

1. Click the Setup icon to display the Setup page.

2. In the folders section of the Setup page, select the new branch controller folder.

3. Click the New link in the title bar of the Rules list. The Create a New Rule window appears at the bottom of the page. Enter a value for each required field described in the tables below, then click Done to save your settings.

Figure 44 New Provisioning Rule

Table 62: Provisioning Rule Configuration Settings

Provisioning

Rule Setting

Description

Rule Type Click the Rule Type drop-down list, and select Provisioning Rule .

Parent Folder

Provision Type

Select the folder to which this provisioning rule applies.

Select the Branch to Master Controller rule type.

Primary Controller MAC address of the primary master controller. Activate sends a branch controller whitelist with information about the controllers in this folder to the master controller with this MAC address.

Primary Ctrl IP Enter the IP address of the primary master controller.

ArubaOS 6.5.3.x


Provisioning

Rule Setting

Backup Controller

Backup Ctrl IP

Country Code

Branch Config

Group

Description

(Optional) MAC address of a backup master controller, for deployments that require Layer-3 redundancy.

(Optional) Enter the IP address of the secondary (backup) master controller.

Select a country code to be assigned to the branch controllers in this folder.

Enter the name of a branch config group to assign that group of branch configuration settings to the branch controllers in this folder.

Moving a Branch Controller to the New Folder

Follow the steps below to assign one or more branch controllers to a folder:

1. Click the Devices icon at the top of the page to display the Devices page.

2. Click the filter icon by any Devices list column heading and choose which entries to display. You can repeat this step and filter the list by multiple criteria types until the Devices list shows only those devices you want to move to a new folder.

3. Click the Move to Folder button at the top of the Devices page. A drop-down window appears, displaying with all folder names.

4. Select the destination folder for the devices.

5. A confirmation window appears, showing the total number of devices that will be moved.

6. Click OK to confirm the change, or click Cancel to cancel the move.

You can also assign an individual device to a new folder by selecting that device from the Devices list and manually changing its parent folder in the Device Details window.

Retrieval of Branch Controller Whitelist from Activate

Activate may be configured to supply the list of branch controllers to the master controller to be added to the whitelist in smart config.

The master controller sends a query to Activate every hour.

The enable mode CLI command “activate sync” may be used to initiate an immediate query to Activate.

When the master controller sends the query to Activate, Activate searches for all provisioning rules of type branch to master controller, that specify the MAC address of this master controller in the primary controller field.

Activate Interface Communication

The branch controller and the master controller interact with the Activate server to receive information about each other. Once the Activate server is properly configured with the appropriate folders and provisioning rules,

Activate automatically manages the relationship between a master controller and all the branch controllers associated with that master.

The master controller regularly contacts the Activate server to get a list of its associated branch controllers.

Branch controllers interact with the Activate server to learn about their role, master controller information, and their regulatory domain. The master controller sends its own information and not branch controller information. Activate reuses information in the AP-information field for controller interactions between master and branch controllers.

The following steps describe the how master controller retrieves the whitelist database from the Activate server.


1. The master controller sends an initial post with a keepalive connection type that includes the following information: n n n n type = Provision update mode = controller a session ID

AP information that includes <serial number>, <mac-address>, <model>

2. Activate responds with the following information: n type = provision update n n an Activate-assigned session ID status n connection = keep alive.

3. The master controller then sends a second POST with ‘close’ connection type with the following information: n n type = provision update, the session ID received from Activate, n n n n

Device information that includes <serial number>, <mac-address>, <model> certificate length signed certificate device certificate

4. Activate then responds with the following information: n type = provision update, n n the same session ID that Activate assigned in the first response status = success or failure n n mode = master the list of branch controllers from the whitelist database, where each list entry contains a <macaddress>,<serial number>,<model>,<mode>,<hostname>, and <config group>

Using Smart Config to create a Branch Config Group

Before you begin to configure a branch config group for individual branch controllers, you must select a master controller to serve as the master for a group of branch controllers on a network. A controller can act either as a master or a branch controller, but not both.

Any change to an active branch controller’s DHCP pool configuration causes the branch controller to reboot.

Only 7200 Series controllers can server as a master controller for a group of branch controllers on a network.

Create and configure a branch config group on a master controller by navigating to the Configuration >

BRANCH > Smart Config section of the master controller WebUI. The Smart Config page contains eight tabs for configuring the branch config group settings.

The BRANCH > Smart Config section of the master controller WebUI is available on the 7200 Series controllers only.

The configuration parameter on each of these tabs are described in the following pages:

ArubaOS 6.5.3.x


n n n n n n n n

Config Group Management Settings on page 240

System Configuration on page 244

Networking Configuration on page 247

Routing Configuration on page 249

VPN Configuration on page 253

WAN Configuration on page 256

Branch Config Group Summary on page 259

Whitelist Configuration on page 259

Config Group Management Settings

Use this tab to create a new branch config group, select the model of branch controller to which this config group will be applied, and choose either the Static or Dynamic IP address management option for your deployment.

Address Pools

Each branch controller must have a pool of addresses it can dynamically assign to APs or users on each of its

VLANs, and a separate IP address that branch controller uses to create a GRE tunnel to the master controller.

Branch controller VLAN pools and the tunnel pool are defined on the master controller. Branch controller address pools are pushed out to each branch controller when it comes up on the network. If a branch controller is removed from the master, the IP addresses allocated to that branch controller can be reused and reassigned to a new branch controller.

A master controller must have a separate VLAN pool defined for each VLAN used by its branch controller. A

VLAN pool allocates a static, continuous block of multiple IP addresses to each branch controller. The branch controller acts as a DNS proxy server and dynamically assign IP addresses from its allocated pool to each AP or client on the VLAN.

The tunnel pool on a branch controller defines a range of IP addresses that the branch controller uses to create a GRE tunnel within the IPsec tunnel back to the master controller. Unlike VLAN pools, which allocates multiple addresses to each branch controller VLAN, the tunnel DHCP pool assigns a single tunnel IP address to each branch controller.

Static vs Dynamic IP Management

If you choose the dynamic IP management option, you must define one or more IP address pools with a range of sharable addresses. The master controller then divides each IP address pool into unique subnets that can support the required number of clients per branch, and assigns one of these subnet to each branch controller.

If a branch deployment has existing IP addressing that needs to be preserved (for example, the printers at a branch office have static IP addresses), then the branch config group should use static IP addressing. When you create a branch config group that uses static IP addressing, you must export the ArubaOS static IP addressing template from the master controller, define the IP settings for the devices that need a static IP address within that template, then import the template file back into a branch config group.

Starting from ArubaOS 6.5, the ZTP feature is enhanced to support 16 VLANs per branch controller as against just four in the earlier versions of ArubaOS. Except this VLAN enhancement, all the other configurations for the

ZTP feature remain the same as in previous ArubaOS versions.

The Bulk Edit template (in Excel sheet) on the branch controller allows you to specify the static IP assignment for individual branch controller devices. The static IP configuration is maintained in this Bulk Edit CSV file, with each line in the file representing the settings for a specific branch controller device. To support this enhancement, the Bulk Edit Excel sheet (.CSV format) is now expanded to allow for addition of up to 16 VLANs for each branch controller.


The DHCP pools for the VLANs will have settings for the following parameters: pool name, domain name, domain name server, VLAN ID, IP address, mask, and the IP address exclude list.

To create a new branch config group:

1. Navigate to Configuration > Branch > Smart Config and select the Management tab.

2. Click the New button under the branch config group list. You are prompted to enter a name for the new branch config group profile.

3. Click OK .

4. Next, click the Model drop-down list and select the model type of your branch controllers. Each profile can support a single controller model .

5. Click the IP Address Management drop-down list and select the Static or Dynamic option.

6. If you select Dynamic , each branch office controller will get an IP address using DHCP.

7. If you select Static , the WebUI gives you the option to select export and download the static IP address template export-RemoteNode.csv

, or select import and upload a completed static IP address .csv file.

8. Click Apply to save your settings.

The export-RemoteNode.csv

template defines the following settings for each branch controller in the branch config group. Complete the template by adding information for up to 16 IP address pools for each branch controller.

Table 63: Branch Config Group Template Setting

Parameter Description

MAC Address

Description

Time Zone

DST

Pool

Domain

DNS

Vlan

Vlan IP

Mask

Exclude List

IP Helper

MAC address of the controller.

A brief description of the controller

A text string indicating the controller's time zone.

NOTE: This string must contain three or more characters of a supported time zone in any of the formats described in

Table 64 , for example,

HongKong or UTC+08 or CCT .

Specify ON or OFF to indicate if the controller's time zone is currently using daylight savings time.

Name of an IP address pool. The template supports up to four different address pools, so different address pools can be used for APs, employees, or guest users.

Name of the branch controller domain.

IP address of the DNS server.

ID of the branch controller VLAN.

IP address of the branch controller

Netmask of the branch controller network.

A comma-separated list of IP addresses or IP address ranges that should not be assigned to clients associated to that branch controller. For example, 15.15.15.11-

15.15.15.20,15.15.15.25,15.15.15.31-15.15.15.40.

DHCP server relay agent IP address.

The new branch config group appears in the Branch Config Group List table. This table displays the branch config group name, validated/not validated status, and reboot status for each branch config group.

ArubaOS 6.5.3.x


n n

Status : A status of Validated indicates that the branch config group has a complete configuration that can be applied to branch controllers. (For example, a branch config group might have a status of Not Validated if the branch config group does not have a IP address defined for the controller or a controller

VLAN interface.)

Reboot Required : This field indicates that the branch config group includes a configuration change that requires a reboot on the branch controllers using that config group.

The table below describes the time zone formats supported by the export-RemoteNode.csv

template. Each line in the table describes three or more time zone formats for a single location, though only one is required for the template. For example, specify Edinburgh or UTC+00 or UTC or BST .


Table 64: Supported Branch Config Group Time Zone Formats

UTC- Time Zones UTC+ Time Zones n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n

"International-Date-Line-West", "UTC-12",

"American-Samoa", "UTC-11", "SST"

"Hawaii", "UTC-10", "HST"

"Alaska", "UTC-09", "AKST"

"Baja-California", "UTC-08", "PST"

"Pacific-Time", "UTC-08", "PST"

"Arizona", "UTC-07", "MST"

"Chihuahua", "UTC-07", "MST"

"La-Paz", "UTC-07", "MST"

"Mazatlan", "UTC-07", "MST"

"Mountain-Time", "UTC-07", "MST"

"Central-America", "UTC-06"

"Central-Time", "UTC-06", "CST""CDT"

"Guadalajara", "UTC-06", "CST", "CDT"

"Mexico-City", "UTC-06", "CST", "CDT"

"Monterrey", "UTC-06", "CST", "CDT"

"Saskatchewan", "UTC-06", "CST"

"Bogota", "UTC-05", "EST"

"Lima", "UTC-05", "EST"

"Quito", "UTC-05", "EST"

"Eastern-Time", "UTC-05", "EST" "EDT"

"Indiana(East)", "UTC-05", "EST" "EDT"

"Caracas", "UTC-04:30", "VET"

"Asuncion", "UTC-04", "AST" "PYST"

"Atlantic-Time(Canada)", "UTC-04", "AST" "ADT"

"Cuiaba", "UTC-04", "AST","AMST"

"Georgetown", "UTC-04", "AST"

"Manaus", "UTC-04", "AST"

"San-Juan", "UTC-04", "AST"

"Santiago", "UTC-04", "AST", "SAND"

"Newfoundland", "UTC-03:30", "NST", "NDT"

"Brasilia", "UTC-03", "BST" "BRAD"

"Buenos-Aires", "UTC-03", "BST", "ARST"

"Cayenne", "UTC-03", "BST"

"Fortaleza", "UTC-03", "BST"

"Greenland", "UTC-03", "BST", "GRED"

"Montevideo", "UTC-03", "BST," "UYST"

"Salvador", "UTC-03", "BST", "BRST"

"Mid-Atlantic", "UTC-02", "FNT"

"Azores", "UTC-01", "AZOST", "AZOST"

"Cape-Verde-Is", "UTC-01", "CVT"

"Casablanca", "UTC+00", "UTC",

"Coordinated-Universal-Time", "UTC+00", "UTC",

"Dublin", "UTC+00", "UTC", "IST"

"Edinburgh", "UTC+00", "UTC", "BST"

"Lisbon", "UTC+00", "UTC", "WEST"

"London", "UTC+00", "UTC", "BST"

"Monrovia", "UTC+00", "UTC",

"Reykjavik", "UTC+00", "UTC",

"Amsterdam", "UTC+01", "CET", "CEST"

"Berlin", "UTC+01", "CET", "CEST"

"Bern", "UTC+01", "CET", "CEST"

"Rome", "UTC+01", "CET", "CEST"

"Stockholm", "UTC+01", "CET", "CEST"

"Vienna", "UTC+01", "CET", "CEST"

"Belgrade", "UTC+01", "CET", "CEST"

"Bratislava", "UTC+01", "CET", "CEST"

"Budapest", "UTC+01", "CET", "CEST"

"Ljubljana", "UTC+01", "CET", "CEST"

"Prague", "UTC+01", "CET", "CEST" n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n

"Casablanca", "UTC+00", "UTC",

"Coordinated-Universal-Time", "UTC+00", "UTC",

"Dublin", "UTC+00", "UTC", "IST"

"Edinburgh", "UTC+00", "UTC", "BST"

"Lisbon", "UTC+00", "UTC", "WEST"

"London", "UTC+00", "UTC", "BST"

"Monrovia", "UTC+00", "UTC",

"Reykjavik", "UTC+00", "UTC",

"Amsterdam", "UTC+01", "CET", "CEST"

"Berlin", "UTC+01", "CET", "CEST"

"Bern", "UTC+01", "CET", "CEST"

"Rome", "UTC+01", "CET", "CEST"

"Stockholm", "UTC+01", "CET", "CEST"

"Vienna", "UTC+01", "CET", "CEST"

"Belgrade", "UTC+01", "CET", "CEST"

"Bratislava", "UTC+01", "CET", "CEST"

"Budapest", "UTC+01", "CET", "CEST"

"Ljubljana", "UTC+01", "CET", "CEST"

"Prague", "UTC+01", "CET", "CEST"

"Brussels", "UTC+01", "CET", "CEST"

"Copenhagen", "UTC+01", "CET", "CEST"

"Madrid", "UTC+01", "CET", "CEST"

"Paris", "UTC+01", "CET", "CEST"

"Sarajevo", "UTC+01", "CET", "CEST"

"Skopje", "UTC+01", "CET", "CEST"

"Warsaw", "UTC+01", "CET", "CEST"

"Zagreb", "UTC+01", "CET", "CEST"

"West-Central-Africa", "UTC+01", "CET"

"Windhoek", "UTC+01", "CET", "WAST"

"Amman", "UTC+02", "EET", "EEST"

"Athens", "UTC+02", "EET," "EEST"

"Bucharest", "UTC+02", "EET," "EEST"

"Beirut", "UTC+02", "EET", "EEST"

"Cairo", "UTC+02", "EET"

"Damascus", "UTC+02", "EET", "EEST"

"East-Europe", "UTC+02", "EET", "EEST"

"Harare", "UTC+02", "EET"

"Pretoria", "UTC+02", "EET"

"Helsinki", "UTC+02", "EET" "EEST"

"Istanbul", "UTC+02", "EET" "EEST"

"Kyiv", "UTC+02", "EET" "EEST"

"Riga", "UTC+02", "EET" "EEST"

"Sofia", "UTC+02", "EET" "EEST"

"Tallinn", "UTC+02", "EET" "EEST"

"Vilnius", "UTC+02", "EET" "EEST"

"Jerusalem", "UTC+02", "EET" "IST"

"Baghdad", "UTC+03", "MSK"

"Minsk", "UTC+03", "MSK"

"Kuwait", "UTC+03", "MSK"

"Riyadh", "UTC+03", "MSK"

"Nairobi", "UTC+03", "MSK"

"Tehran", "UTC+03:30", "IRST"

"Abu-Dhabi", "UTC+04", "GST"

"Muscat", "UTC+04", "GST"

"Baku", "UTC+04", "GST" "AZST"

"Moscow", "UTC+04", "GST"

"St.Petersburg", "UTC+04", "GST"

"Volgograd", "UTC+04", "GST"

"Port-Louis", "UTC+04", "GST"

"Tbilisi", "UTC+04", "GST"

ArubaOS 6.5.3.x


Table 64: Supported Branch Config Group Time Zone Formats

UTC- Time Zones UTC+ Time Zones n n n n n n n n n n n n n n n n n n

"Brussels", "UTC+01", "CET", "CEST"

"Copenhagen", "UTC+01", "CET", "CEST"

"Madrid", "UTC+01", "CET", "CEST"

"Paris", "UTC+01", "CET", "CEST"

"Sarajevo", "UTC+01", "CET", "CEST"

"Skopje", "UTC+01", "CET", "CEST"

"Warsaw", "UTC+01", "CET", "CEST"

"Zagreb", "UTC+01", "CET", "CEST"

"West-Central-Africa", "UTC+01", "CET"

"Windhoek", "UTC+01", "CET" "WAST"

"Amman", "UTC+02", "EET" "EEST"

"Athens", "UTC+02", "EET" "EEST"

"Bucharest", "UTC+02", "EET" "EEST"

"Beirut", "UTC+02", "EET" "EEST"

"Cairo", "UTC+02", "EET"

"Damascus", "UTC+02", "EET" "EEST"

"East-Europe", "UTC+02", "EET" "EEST"

"Harare", "UTC+02", "EET" n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n

"Yerevan", "UTC+04", "GST"

"Kabul", "UTC+04:30", "AFT"

"Islamabad" ,"UTC+05", "PKT"

"Karachi" ,"UTC+05", "PKT"

"Tashkent" ,"UTC+05", "PKT"

"Chennai" ,"UTC+05:30", "IST"

"Kolkata" ,"UTC+05:30", "IST"

"Mumbai" ,"UTC+05:30", "IST"

"New-Delhi" ,"UTC+05:30", "IST"

"Sri-Jayawardenepura", "UTC+05:30", "IST"

"Kathmandu", "UTC+05:45", "NPT"

"Astana", "UTC+06", "BTT"

"Dhaka", "UTC+06", "BTT"

"Ekaterinburg", "UTC+06", "BTT"

"Yangon", "UTC+06:30", "MMT"

"Bangkok", "UTC+07", "THA"

"Hanoi", "UTC+07", "THA"

"Jakarta", "UTC+07", "THA"

"Novosibirsk", "UTC+07", "THA"

"Beijing" ,"UTC+08", "CCT"

"Chongqing" ,"UTC+08", "CCT"

"Hong Kong" ,"UTC+08", "CCT"

"Krasnoyarsk" ,"UTC+08", "CCT"

"Kuala-Lumpur", "UTC+08", "CCT"

"Perth", "UTC+08", "CCT"

"Singapore", "UTC+08", "CCT"

"Taipei", "UTC+08", "CCT"

"Urumqi" ,"UTC+08", "CCT"

"Ulaanbaatar", "UTC+08", "CCT"

"Irkutsk", "UTC+09", "JST"

"Osaka", "UTC+09", "JST"

"Sapporo", "UTC+09", "JST"

"Tokyo", "UTC+09", "JST"

"Seoul", "UTC+09", "JST"

"Adelaide", "UTC+09:30", "ACST" "CST"

"Darwin", "UTC+09:30", "ACST"

"Brisbane", "UTC+10", "AEST"

"Canberra","UTC+10", "AEST"

"Melbourne","UTC+10", "AEST"

"Sydney","UTC+10", "AEST"

"Guam", "UTC+10", "AEST"

"Port-Moresby", "UTC+10",

"Hobart" ,"UTC+10", "AEST"

"Yakutsk", "UTC+10", "AEST"

"Solomon-Is.", "UTC+11", "NST"

"New-Caledonia", "UTC+11", "NST"

"Vladivostok", "UTC+11", "NST"

"Auckland", "UTC+12", "NZT"

"Wellington", "UTC+12", "NZT"

"Fiji", "UTC+12", "NZT"

"Magadan", "UTC+12"

"Nukualofa", "UTC+13"

"Samoa", "UTC+13"

System Configuration

Configure general system settings for the branch controllers in a branch config group by navigating to

Configuration > Branch > Smart Config and selecting the System tab. The settings on the System tab are described in the table below.


Figure 45 Branch Config Group System Settings


General

System Contact An alphanumeric string that specifies the name of the system contact for the controller

The name of a system admin user Admin User

Admin Password The password for the system admin user

Servers

AirWave Server (Optional) IP address of the AirWave server, if the branch office controller is managed or monitored by AirWave.

Syslog Server (Optional) IP address of an external syslog server. You will define syslog facility levels in subsequent configuration fields on this page.

IP address of the domain server.

Domain Name

Server

Domain name (Optional) Default domain name to be used by the branch controllers. The branch controllers use the default domain name to complete hostnames that do not contain domain names.

(Optional) Certificate to be used for captive-portal authentication.

Captive Portal

Server

Certificate

Time Zone

RADIUS interface source

VLAN

Advanced Settings

Time zone for the branch office controller. Click the DST checkbox if the selected timezone is currently using daylight-savings time.

This field identifies the interface for outgoing RADIUS packets. The IP address of the specified interface is included in the IP header of RADIUS packets.

Master L3

Redundancy

Switchover

Timeout

If the branch controller is configured with a primary and a secondary master controller, this switchover period defines the number of minutes that a branch controller will wait before switching its master controller from an unreachable primary controller to the backup controller.

n n

Range: 15 - 60 minutes

Default: 15 minutes

NOTE: This timeout period does not apply if a user manually switches a branch controller from a primary to a secondary master controller by clicking the Switchover link on the Network >

Controller > System settings page of the branch controller WebUI.

firewall-visibility (Optional) Enable or disable the firewall visibility feature. For more information, see

Firewall on page 833 .

AppRF

URL Filtering

(Optional) Enable or disable the AppRF feature. For more information, see

AppRF on page 805

.

(Optional) Enable Web Content Classification. For more information, see

Web Content on page

812

.

Mark

Management

Frames

(Optional) Enable or disable the marking of IPsec mangement frames. This option is disabled by default.

ArubaOS 6.5.3.x



Jumbo

Management

Frames

Skype4B Listen

Port

AirGroup

(Optional) Enable or disable jumbo Ethernet frames on branch office controller ports. If you enable this feature, you must define the Maximum Transmission Unit (MTU) for these frames.

The supported range is 1789 to 9612 bytes.

(Optional) ArubaOS provides value-added services such as prioritization of Lync/Skype for

Business sessions, call quality metrics, and visibility by implementing Lync/Skype for Business

Application Layer Gateway (ALG). Use this parameter to define the Lync/Skype for Business listening port. For more information, see

Configuring the Lync/Skype for Business Listening Port on page 958

.

(Optional) Enable or disable the AirGroup feature on the branch office controller. For more information on AirGroup, see

AirGroup on page 1004

.

AirGroup MDNS (Optional) Enable or disable support for multicast Domain Name System (mDNS) service records. For more information, see

Zero Configuration Networking on page 1004

.

AirGroup DLNA (Optional) Enable or disable support for DLNA (Digital Living Network Alliance); a network standard that is derived from UPnP (Universal Plug and Play) in addition to the mDNS protocol.

For more information, see

Zero Configuration Networking on page 1004

.

Syslog Facility Levels

Network

Security

System

User

Wireless

(Optional) Click the syslog facility levels drop-down lists to change the severity level at which the different types of syslog messages are logged. By default, all message types are logged at the warnings level. For more information on syslog levels, refer to the ArubaOS Syslog Messages

Guide.

Revocation CheckPoints

CA Cert (Optional) The branch controller can act as an OCSP client and issue OCSP queries to remote

OCSP responders located on the intranet or Internet. If you have uploaded an OCSP responder certificate to the master controller, click Edit to modify the certificates used to sign OCSP for the revocation check point. For more information on configuring a controller as an OCSP client, see

Configuring the Controller as an OCSP Client on page 305

.

SNMP


Parameter

Community

Strings for

SNMPv1 and

SNMPv2

Trap Receiver

Description

Enter community string to authenticate SNMPv1 and SNMPv2 requests. For more information on SNMP settings, see

Configuring SNMP

.

SNMPv3 Users

Enter host information about a SNMP trap receiver that can receive and interpret the traps sent by the controller. Click New , enter the following types of trap information, then click Add .

n n

IP address: Trap receiver IP address

SNMP version: SNMPv1,SNMPv 2c, or SNMPv3.

n n n

Security Name: SNMP security name string

Engine ID: Engine ID of SNMP server in hexadecimal format. (SNMPv3 only)

UDP Port: UDP port on which the trap receiver listens for traps. The default is the UDP port number 162.

n n

Type: Specify whether the controller can send inform messages to the trap receiver to acknowledge traps. (SNMPv2c or SNMPv3 only)

Retry: If the controller is configured to send inform messages, this field specifies the number of times the controller will retry sending inform messages to the trap receiver before giving up.

n Timeout: Estimated round trip time to the trap receiver, in seconds.

For more information on SNMP settings, see

Configuring SNMP

.

Information about SNMPv3 users. Click New to open a message box that allows you to enter the following information types, then click Add .

n n

User: A string representing the name of the SNMP user.

Authentication Protocol: Select either MD5 or SHA authentication n n

Authentication Password: Authentication key for use with the SHA authentication protocol.

Privacy Protocol: Select either AES or DES encryption.

n Privacy Password: Privacy key for encrypted messages.

For more information on SNMP settings, see

Configuring SNMP

.

Networking Configuration

Configure user and uplink VLANs for the branch controllers in a branch config group, map named VLANs to one ore more VLAN IDs, define branch config group port settings and tunnels, and enable or disable the Spanning

Tree Protocol (STP) by navigating to Configuration>Branch>Smart Config and selecting the Networking tab.

Use the configuration settings on the Networking tab to configure the PortFast and BPDU Guard features for a branch config group. For complete details on these features, see

PortFast and BPDU Guard on page 260 .

The settings on the Networking tab are described in the table below.

Figure 46 Branch Controller Networking Settings.

Parameter Description

User VLANs

VLAN ID

Description

Identifier for the VLAN.

Text string describing the VLAN.

ArubaOS 6.5.3.x


Parameter

NAT Inside

Description

Click this checkbox to enable source NAT for this VLAN. When applied, NAT is applied to both outbound and non-public, inter-VLAN traffic, with the desired IP address of the VLAN interface as the source address.

Nat Outside Starting in ArubaOS 6.4.4.0, click this checkbox to enable destination NAT for this VLAN. With this option, NAT is applied only to outbound traffic with the IP address of the VLAN interface as the source address. Non-public, inter-VLAN traffic which is routed locally remains unaffected.

BCMC Optimization Click this checkbox to effectively prevent flooding of BCMC traffic on all VLAN member ports.

This option ensures controlled flooding of BCMC traffic without compromising the client connectivity.

Operstate Click this checkbox to select the operational state for the VLAN ( Up or Down ).

IP Address Select one of the following parameters from the drop-down list to allow a VLAN to get an

IP address using DHCP: n n dhcp-client - The VLAN to select the IP address from the DHCP server, if this option is selected.

dhcp-pool - A static IP address is assigned to the vlan based on the configured dhcp pools in the Routing tab, if this option is selected.

Named VLAN Mapping

Name Name assigned to an individual VLAN or group of VLANs (a VLAN pool).

VLAN Specify one or more VLAN IDs to associate the VLAN ID(s) to the VLAN name. For more information on configuring named VLANs, see

Configuring VLANs on page 105 .

Uplink VLANs

VLAN ID

Priority

Description

Operstate

IP Address

Ports

Specify the VLAN ID of the wired uplink network connection used by the branch controller.

Specify the priority of the VLAN by selecting a value from 101-255.

(Optional) text string used to describe the VLAN

Identify the VLAN operational state as UP or DOWN.

Specify whether the VLAN will receive its IP address using DHCP or PPPoE.


Parameter n n n n n n n n n n n

Port Settings:

Port Enable

Enable

Description

Trusted

Speed/Duplex

Mode

Native VLAN

Trunk/Access

VLAN

PortFast

BPDU Guard

Tunnels

Description

Click Edit to edit the settings for an individual interface port, or to apply an access control list

(ACL) to inbound traffic, outbound traffic, or session traffic on a selected VLAN.

NOTE: For complete details on the PortFast and BPDU Guard features, see

PortFast and

BPDU Guard on page 260

. For more information on configuring the port settings for branch controllers in a branch config group, see

Configuring Ports on page 109

and

Roles and

Policies on page 381 .

n n n n n n n

Tunnel settings:

Tunnel ID

Source IP

Destination IP

Mode

Keepalive

MTU

Trusted

ArubaOS supports generic routing encapsulation (GRE) tunnels between the branch controller and APs. To define tunnel settings for the branch controllers using this branch config group, click

Spanning Tree Configuration

New , select your tunnel settings, then click vidual GRE tunnel configuration parameters, see

Add . For more information on indi-

Configuring GRE Tunnels on page 114 .

Spanning Tree

Enabled

Spanning Tree Protocol (STP) can ensure a single active path between any two network nodes, thus avoiding bridge loops. Select this checkbox to enable spanning tree if you are employing STP in your network.

Routing Configuration

Use this tab to configure static routes and DHCP pools, policy-based routing, and uplink routing using nexthop lists.

Configuring Routing for a Branch Config Group

To configure the different routing settings for a branch config group, select the Routing sub-tab to configure the controller IP and NAS-IP VLANs, static routes and DHCP pools, then optionally click the PBR sub tab to configure policy-based routing (PBR) settings such as nexthop lists and PBR rules and targets.

Controller IP

A valid branch config group requires a VLAN to be assigned to the controller IP address. To assign an VLAN to a controller IP:

1. Navigate to Configuration>Branch>Smart Config>Routing and select the Routing sub-tab.

2. Click the Controller-IP drop-down list and select a VLAN ID from the list of uplink VLANs configured on the

Branch>Smart Config>Networking tab.

3. Click Apply .

NAS IP

ArubaOS 6.5.x allows you configure a branch controller NAS IP with a VLAN. This setting is optional; if the NAS

IP VLAN is not configured for branch controllers, the controller IP defined in the RADIUS server configuration

ArubaOS 6.5.3.x


address is used as the NAS IP.

To assign an VLAN to a NAS IP:

1. Navigate to Configuration>Branch>Smart Config>Routing and select the Routing sub-tab.

2. Click the Override NAS-IP drop-down list and select a VLAN ID from the list of uplink VLANs configured on the Branch>Smart Config>Networking tab.

3. Click Apply .

Static Routes

A static route allows the branch controller to connect to an upstream router or switch instead of the default gateway. To define a static route for your branch config group:

1. Select the Routing sub-tab.

2. Click New to open a pop-up window that allows you to configure the following static route settings:

Table 65: Branch Controller Static Route Settings


Destination IP

Destination Mask

NextHop

IPsec

Destination IP addresses in dotted decimal format.

Destination netmask, in dotted decimal format.

The IP address of the forwarding router in dotted decimal format.

To use a static IPsec route, map click the IPsec drop-down list and select a static

IPsec route map, or click New and enter the name of a new IPsec route map.

DHCP Pools

Client devices within a branch office will obtain their IP addresses from a DHCP pool.

1. Select the Routing sub-tab.

2. Click New to open a pop-up window that allows you to configure the following DHCP pool settings:

Table 66: Branch Controller DHCP Pool Settings


VLAN

Pool Name

Domain Name

DNS Server

IP Address Range

Lease

Option

VLAN ID. Click the VLAN drop-down list and select a VLAN ID from the list of uplink

VLANs configured on the Branch>Smart Config>Networking tab.

Name that identifies this VLAN pool.

Domain name of the DNS server.

IP address of the DNS server.

IP addresses at the start and end of the branch controller’s address range, in dotted-decimal format and the netmask per branch. The WebUI converts the netmask per branch to hosts count.

Example: If the netmask per branch is /27, WebUI calculates the hosts count as 32.

Similarly, if netmask per branch is /24, the WebUI calculates the hosts count as 256.

Lease time for addresses in the DHCP pool. If unconfigured, the default value is 12 hours.

Use this field assign the client to a VLAN based upon the DHCP signature ID.


Next-Hop Device lists

If the controller uses policy-based routing to forward packets to a next hop device, a next-hop list ensures that if the primary next-hop device becomes unreachable, the packets matching the policy can still reach their destination. For more information on nexthop devices, see

Routing Configuration on page 249 .

To define a next-hop list:

1. Navigate to Configuration>Branch>Smart Config>Routing and select the PBR sub-tab.

2. Click the Add button below the Nexthop Configuration table to open a pop-up window that allows you to configure the following next-hop settings:

Table 67: Branch Controller Next-Hop Settings


Nexthop-list name Name for the new nexthop list.

Nexthop IP / DHCP

Preemptive-Failover

IP address of the nexthop device or the VLAN ID of the VLAN used by the nexthop device. If the VLAN gets an IP address using DHCP, and the default gateway is determined by the VLAN interface, the gateway IP is used as the nexthop IP address.

When you click Add to define a NextHop IP or DHCP value, a pop-up list appears and field requires you to select either the IP or DHCP option.

n n

IP: In the Nexthop Value and Priority fields, enter the IP address and priority of the nexthop device

DHCP: In the Nexthop Value and Priority fields select the VLAN and priority of the nexthop device.

If preemptive failover is disabled and the highest-priority device on the nexthop list is disabled, the new primary nexthop device remains the primary even when the original device comes back online.

PBR Rules

A policy-based routing (PBR) rule is an ACL that can forward traffic as normal, or route traffic over a VPN tunnel specified by an IPsec map, routed to a nexthop router on a nexthop list, or redirected over an L3 GRE tunnel or tunnel group.

If you modify an existing ACL by adding a new rule with the same position as an existing rule, the previously existing rule will be overwritten. The Smart Config section of the ArubaOS WebUI does not prevent you from creating duplicate rules in different positions, though this is not allowed when creating ACLs using the

Configuration>Security>Firewall Policies section of the ArubaOS WebUI, or when using the ip access-list commands in the ArubaOS command-line interface.

To associate a policy based routing rule with the branch config group,

1. Navigate to Configuration>Branch>Smart Config>Routing , and select the PBR subtab .

2. Click the Route ACL name drop-down list. Select an existing route ACL, or click New to define a new ACL.

3. If you selected New in the previous step, enter a name for the new ACL, then click Add . Next, you must define the rules for the new ACL.

4. Click the Add button below the PBR rules list, and define the following values:

ArubaOS 6.5.3.x


Table 68: Policy Based Routing ACL Rule Parameters

Field Description

IP version

Source

(required)

Specifies whether the policy applies to IPv4 or IPv6 traffic.

Source of the traffic, which can be one of the following: n n any: Acts as a wildcard and applies to any source address.

user: This refers to traffic from the wireless client.

n n n host: This refers to traffic from a specific host. When this option is chosen, you must configure the IP address of the host.

network: This refers to a traffic that has a source IP from a subnet of IP addresses. When this option is chosen, you must configure the IP address and network mask of the subnet.

alias: This refers to using an alias for a host or network. You configure the alias by navigating to the Configuration > Advanced Services > Stateful Firewall > Destination page.

Destination of the traffic, which can be configured in the same manner as Source.

Destination

(required)

Service

(required)

Action

(required)

Position

Type of traffic, which can be one of the following: n any: This option specifies that this rule applies to any type of traffic.

n application: For session and route policies on a 7000 Series controller, you can create a rule that applies to a specific application type. Click the Application drop-down list and select an application type.

n n application category: For session and route policies on a 7000 Series controller, you can create a rule that applies to a specific application category. Click the Application Category drop-down list and select a category type.

protocol: Using this option, you specify a different layer 4 protocol (other than TCP/UDP) by configuring the IP protocol value.

n n n service: Using this option, you use one of the pre-defined services (common protocols such as

HTTPS, HTTP, and others) as the protocol to match for the rule to be applied. You can also specify a network service that you have manually configured. For details, see

Configuring

Firewall Policies on page 381

.

tcp: A range of TCP port(s) that must be used by the traffic in order for the rule to be applied.

udp: A range of UDP port(s) hat must be used by the traffic in order for the rule to be applied.

The action that you want the controller to perform on a packet that matches the specified criteria.

This can be one of the following: n Forward Regularly: Packets are forwarded to their next destination without any changes.

n n n n

Forward to ipsec-map: Packets are forwarded through an IPsec tunnel defined by the specified

IPsec map. You must specify the position of the forwarding or routing rule. (1 is first, default is last)

Forward to next-hop-list: packets are forwarded to the highest priority active device on the selected next hop list. You must also specify the position of the forwarding or routing rule (1 is first, default is last). For more information on next-hop lists, see

Routing Configuration on page

249 .

Forward to tunnel: Packets are forwarded through the tunnel with the specified tunnel ID. You must also specify the position of the forwarding or routing rule (1 is first, default is last). For more information on GRE tunnels, see

Configuring GRE Tunnels on page 114

.

Forward to tunnel group: Packets are forwarded through the active tunnel in a GRE tunnel group. You must also specify the position of the forwarding or routing rule (1 is first, default is last). For more information on tunnel groups, see

Configuring GRE Tunnel Groups on page 123 .

(Optional) Define a position for the rule in the ACL. Rules processed according to their position numbers, and new Rules are added at the end of an ACL by default. A position of 1 puts the rule at the top of the list.

Targets for PBR Rules

A Policy Based Routing (PBR) rule does not become active until it is applied to a VLAN interface or user role. To define a target for a PBR rule:


1. Select the PBR sub-tab.

2. Click the Add button below the Target table.

3. Click the PBR Rule Name drop-down list and select the rule to be applied to the target.

4. Select the target type: VLAN or User Role .

n n

If you selected the VLAN type, click the Target drop-down list and select a VLAN ID to apply the rule to the VLAN interface's inbound traffic.

If you selected the User Role type, click the Target drop-down list and select a user role. The rule will be applied to traffic from clients with the selected user role.

5. Click Done .

6. Click Apply .

VPN Configuration

Configure IPsec crypto maps and DTP settings for the branch controllers in a branch config group by navigating to Configuration>Branch>Smart Config and selecting the VPN tab. The settings on the VPN tab are described in the table below.

Table 69: Branch Config Group VPN Settings

Parameter Description Description

IPSec maps

Name

Name of the IPsec map.

Disable IPsec map Click this checkbox to temporarily disable a configured IPsec map without deleting it from the branch config group.

Priority

Source Network Type

Source Network

Source Network VLAN

Source Subnet Mask

Destination Network

Priority level for the IPsec map, from 1-9998. An IPsec map with a smaller priority number will take precedence over a map with a greater priority number.

Select one of the supported source network identifier types: n IP Address : Identify the source network (the local network connected to the branch controller) using an IP address.

n n

VLAN : Use a VLAN ID as the source network. When the configuration is pushed to the branch, the IP address range assigned for that VLAN in that branch is used during IKE negotiation.

Any : Use any as the source network.

If you selected the IP Address source network type, enter the IP address the source network in the Source Network field

If you selected VLAN as the source network type, click the VLAN drop-down list and select the VLAN ID of the source network VLAN.

Subnet mask for the source network (the local network connected to the branch controller).

Select one of the supported destination network identifier types: n n

IP Address : Identify the destination network (the remote network to which the local branch network communicates).

Any : Use any as the destination network.

ArubaOS 6.5.3.x



Destination Subnet Mask

Subnet mask for the source network (the remote network to which the local branch network communicates).

Peer Gateway Type

Peer Gateway

Peer Certificate Subject

Name

Select one of the supported peer gateway types: n IP Address : Select this option to identify the remote end point of the VPN tunnel using an IP address.

n

FQDN : This option allows you to use same FQDN across different branches. The FQDN resolves to different IP addresses for each branch, based on its local DNS setting.

Define the peer gateway.

If you selected IP Address for the Peer Gateway Type option, enter the appropriate IP address: n n

If you are configuring an IPsec map for a dynamically addressed remote peer, give the peer gateway a default value of 0.0.0.0

.

If you are configuring an IPsec map for a statically addressed remote peer, enter the IP address of the interface used by the remote peer to connect to the L3 network .

f you selected FQDN for the Peer Gateway Type option, enter the fully qualified domain name for the remote peer.

If you use IKEv2 to establish a site-to-site VPN for a statically addressed remote peer, identify the peer device by entering its certificate subject name in the Peer Certificate Subject Name field.

NOTE: This field is not enabled until you select the Certificate option for authentication at the bottom of the VPN tab. To identify a peer certificate's subject name, issue the show crypto-local pki servercert <certname> subject command in the master controller command-line interface.

Configures the lifetime for the security association (SA), in seconds.

Security Association

Lifetime (seconds)

Security Association

Lifetime (Kilobites)

Specifies the amount of traffic (in kilobytes) that can pass between IPSec peers in the local and remote networks before the security association expires.

Version Click the drop-down list and select None (to create an IPsec map that doesn't use IKE), IKEv1 or IKEv2 .

IKE policies

Factory Certificate

Authentication

VLAN

Select a predefined IKE policy, or a policy manually defined on the Configuration > Advanced > VPN Services > IPsec page of the master con-

troller WebUI. For more information on creating IKE policies, see Configuring

IKE Policies on page 364

.

Select this option to use factory-installed TPM (Trusted Platform Module) certificates for VPN authentication.

Select the VLAN containing the interface of the local branch controller that connects to the Layer-3 network. This setting determines the source IP address used to initiate IKE. If you select None , the default is the VLAN of the controller’s IP address (either the VLAN where the loopback IP is configured, or VLAN 1 if no loopback IP is configured).



PFS

Pre-Connect

Trusted Tunnel

Enforce NATT

If you enable Perfect Forward Secrecy (PFS) mode, new session keys are not derived from previously used session keys. Therefore, if a key is compromised, that compromised key does not affect any previous session keys. PFS mode is disabled by default. To enable this feature, click the PFS drop-down list and select one of the following Perfect Forward Secrecy modes: n n group1 : 768-bit Diffie–Hellman prime modulus group.

group2 : 1024-bit Diffie–Hellman prime modulus group.

n n n group 14 : 2048-bit Diffie–Hellman prime modulus group.

group19 : 256-bit random Diffie–Hellman ECP modulus group.

group20 : 384-bit random Diffie–Hellman ECP modulus group.

Select Pre-Connect to establish the VPN connection, even if there is no traffic being sent from the local network. If you do not select this, the VPN connection is established only when traffic is sent from the local network to the remote network.

Select Trusted Tunnel if traffic between the networks is trusted. If you do not select this, traffic between the networks is untrusted.

Select the Enforce NATT checkbox to enforce IKE and IPSEC NAT Traversal

(NAT-T) on UDP port 4500. This option is disabled by default.

Transform Sets A transform set defines a specific encryption and authentication type used by the dynamic peer. Click the Transform Set drop-down list to select a predefined transform set or a transform set that was manually defined using the Configuration>Advanced Services > VPN Services > Advanced page of the master controller WebUI, then click the arrow button by the dropdown list to add that transform set to the IPsec map.

Dynamically Addressed

Peer

Pre-shared Key

Certificate

Select either the Pre-shared Key or Certificate options to define security options for a dynamically address peer.

For pre-shared key authentication, select Pre-Shared Key , then enter a shared secret in the IKE Shared Secret and Verify IKE Shared Secret fields. This authentication type is generally required in IPsec maps for a VPN with dynamically addressed peers, but can also be used for a static site-tosite VPN.

For certificate authentication, select Certificate , then click the Server Certificate and CA certificate drop-down lists to select certificates previously imported into the controller.

See

Management Access on page 844

for more information on managing certificates.

DPD Parameters

Enable DPD The DPD Parameters checkbox on the VPN tab enables or disables Dead

Peer Detection. When enabled, DPD uses IPsec traffic patterns to minimize the number of IKE messages required to determine the liveliness of an IKE peer. After a dead peer is detected, the branch controller tears down the

IPsec session. Once the network path or other failure condition has been corrected, a new IPsec session is automatically re-established.

ArubaOS 6.5.3.x


Table 70: Default IKE Policy Setting

Policy Name

Policy

Number

IKE

Version

Encryption

Algorithm

Default protection suite

10001

Default RAP

Certificate protection suite

10002

Default RAP

PSK protection suite

10003

Default RAP

IKEv2 RSA protection suite

1004

10005 Default Cluster


Default IKEv2

RSA protection suite

Default IKEv2


1006

10007

Default Suite-B

128bit ECDSA protection suite

10008

IKEv1

IKEv1

IKEv2

IKEv1

IKEv2

IKEv2

IKEv2

3DES-168

AES -256

AES -256

AES -256

AES -256

AES - 128

AES - 128

AES - 128

Hash

Algorithm

Authentica

-tion

Method

SHA 160

SHA 160

Pre-Shared

Key

RSA

Signature

PRF

Method

Diffie-

Hellman

Group

N/A

N/A

2 (1024 bit)

2 (1024 bit)

SHA 160

SSHA160

SHA160

SHA 96

SHA 96

SHA 256-

128

Pre-Shared

Key

RSA

Signature

Pre-Shared

Key

RSA

Signature

Pre-shared key

ECDSA-256

Signature

N/A hmacsha1

Pre-

Shared

Key hmacsha1 hmacsha1

2 (1024 bit)

2 (1024 bit)

2 (1024 bit)

2 (1024 bit)

2 (1024 bit)

Default Suite-B

256 bit ECDSA protection suite

10009

Default RAP

IKEv2 RSA protection suite

10012

IKEv2

IKEv2

AES -256

AES -256

SHA 384-

192

SSHA160

ECDSA-384

Signature

RSA

Signature hmacsha2-256

Random

ECP

Group

(256 bit) hmacsha2-384

Random

ECP

Group

(384 bit) hmacsha1

14 2048bit group

WAN Configuration

Use the WAN tab to define settings for the features described below. For additional information on each of these features, refer also to the following sections of this document: n n n n n n



Branch Controller Routing Features on page 231

WAN Optimization through IP Payload Compression on page 226

Interface Bandwidth Contracts on page 227

Branch Integration with a Palo Alto Networks (PAN) Portal on page 228


To configure WAN survivability, Health Check, Policy-Based Routing, WAN Optimization, Bandwidth

Management and PAN portal settings for the branch controllers in a branch config group ,navigate to

Configuration>Branch>Smart Config and select the WAN tab. The settings on the WAN tab are described in the table below.

Table 71: Branch Config Group WAN Setting


WAN Failure Survivability

Enable Auth-Survivability

Authentication Server

Certificate

Local Cache Lifetime (hrs)

CA Certificate Assigned for

Auth Survivability

This parameter controls whether to use the Survival Server when no other authentication servers in the server group are in-service.

This parameter also controls whether to store the user access credential in the

Survival Server when it is authenticated by an external RADIUS or LDAP server in the server group. Authentication Survivability is enabled or disabled at each controller. This parameter is disabled by default.

NOTE: Authentication Survivability will not activate if Authentication Server Dead

Time is configured as 0. For more information on configuring Authentication

Server Dead Time, see

Configuring Authentication Timers on page 212

.

This parameter allows you to view the name of the server certificate used by the local Survival Server. The local Survival Server is provided with a default server certificate from ArubaOS . The customer server certificate must be imported into the controller first, and then you can assign the server certificate to the local

Survival Server.

This parameter specifies the lifetime in hours for the cached access credential in the local Survival Server. When the specified cache-lifetime expires, the cached access credential is deleted from the controller.

Configured authentication servers are put into the out-of-service (OOS) state when authentication requests time out. The wireless controller picks the next server from the server group when the previous server times out or fails.

When there are no more servers available from the server group, the local

Survival Server processes the authentication request. When the client is authenticated with the local Survival Server, the previously stored Key Reply attributes are included in the RADIUS response.

The Cache Lifetime range is from 1 to 168 hours. The default is 24 hours.

Select the certificate to be used for client authentication.

WAN Health Check

Health-Check

WAN

Probe Mode

Probe Interval (sec)

Select the health-check option to use ping-probes to measure WAN availability and latency on selected uplinks. Based upon the results of this health-check information, the controller can continue to use its primary uplink, or failover to a backup link.

Select the WAN tab to define ping probe settings for the health-check feature

Click the Probe Mode drop-down list and select ping or udp to enable ip probes of the selected type.

The Probe Interval field specifies the probe interval, in seconds. The WAN health-check feature sends the number of probes defined by the Packet Burst per Probe parameter during each probe interval. To change the default interval of 10 seconds, enter a new value into this field.

ArubaOS 6.5.3.x




Packet Burst Per Probe

Probe Retries

The Pocket Burst per Probe field specifies the number of probes to be sent during the probe interval. To change the default value of 5 probes, enter a new value into this field.

The number of times the controller will attempt to resend a probe.

IP/FQDN of remote host

Jitter Measurement

PBR

Probe Mode

IP address or Fully Qualified Domain Name (FQDN) of the remote host to which the ping probes are sent.

Jitter is a variation in the delay of received packets, which can be worsened by network congestion, improper queueing and configuration errors. The WAN health-check feature measures jitter on the connection to the remote host by sending and measuring packets at fixed intervals.

Select the PBR tab to define ping probe settings for policy-based routing.

Click the Probe Mode drop-down list and select ping to enable ip probes.

Probe Interval (sec)

Packet Burst Per Probe

Probe Retries

The Probe Interval field specifies the probe interval, in seconds. The WAN health-check feature sends the number of probes defined by the Packet Burst per Probe parameter during each probe interval. To change the default interval of 10 seconds, enter a new value into this field.

The Pocket Burst per Probe field specifies the number of probes to be sent during the probe interval. To change the default value of 5 probes, enter a new value into this field.

The number of times the controller will attempt to resend a probe.

WAN Optimization

Compression The Compression/Decompression Engine feature is enabled by default. However, the packets are compressed only if the IP Payload Compression Protocol (IPComp) is successfully negotiated via the Internet Key Exchange (IKE) protocol.

BW Management

Uplink

Service Type

Bandwidth Contract

Select an interface uplink to which you will apply the bandwidth contract.

n n n

Select one of the available service types for this bandwidth contract: n None: The contract applies to all upstream or downstream traffic on the interface.

Application: The contract applies to a specific application.

Category: The contract applies to all applications within a category type.

Exclude: If a bandwidth contract is applied to an entire interface or category of applications, you can create a bandwidth contract that excludes a single application or application category from that contract.

If you chose the None, Application or Category option in the Service Type field, select the name of the bandwidth contract to be applied to the interface.




Application

If you chose the Application option in the Service Type field, select the application to which the bandwidth policy will be applied.

Category If you chose the Category option in the Service Type field, select the application category to which the bandwidth contract is applied.

Bandwidth Direction

Apply the bandwidth contract to upstream or downstream traffic.

PAN Portal

Portal IP

Trusted Certificate

User Name

Password

The IP address or fully qualified domain name (FQDN) of the portal.

Specify the name of the self-signed or external certification authority (CA) certificate to establish an SSL connection to the portal.

Username to authenticate to the Palo Alto Networks portal.

Password to authenticate to the Palo Alto Networks portal.

Branch Config Group Summary

The Summary tab on the Configuration>Branch>Smart Config page displays a summary of the branch config group configuration created using the Smart Config WebUI, and a summary of the settings on a specific branch controller.

To view a summary of the branch config group settings:

1. Navigate to Configuration>Branch>Smart Config>Summary .

2. Select the Profile Summary subtab.

3. Click the Profile drop-down list and select the branch config group whose configuration settings you want to review.

To view a summary of the settings specific to an individual branch controller:

1. Navigate to Configuration>Branch>Smart Config>Summary .

2. Select the BOC Summary subtab.

3. Click the Profile drop-down list and select the MAC address of the branch controller whose configuration settings you want to review.

Whitelist Configuration

The branch controller whitelist database links the MAC address of the branch controller to the branch config group. Once you have assigned a branch config group to a branch controller, you cannot edit the config group assigned to the branch controller in the whitelist entry. To assign a different configuration to an unprovisioned branch controller, you must delete the whitelist entry and create a new branch controller whitelist entry with the correct branch config group.

When you remove an entry for an active branch controller from the whitelist on the master controller, that branch controller no longer receives configuration or license updates from the master controller, but continues to operate as previously configured. As the license server is the master controller, any operation related to the licensing does not work after it is detached. If you remove an individual branch controller entry from the

ArubaOS 6.5.3.x


whitelist before that branch controller is connected to the network, that branch controller is not automatically provisioned as a branch controller, and remains inactive on the network until manually provisioned.

If you are using Activate to associate your branch controllers to a master controller, the master controller contacts the Activate server every hour to query for the latest whitelist. To immediately download the latest whitelist, access the controller command-line interface and execute the command activate sync .

You can manually add branch controllers to the master controller whitelist by navigating to

Configuration>Branch>Smart Config and selecting the Whitelist tab. The settings on the Whitelist tab are described in the table below.

Table 72: Branch Config Group Whitelist Settings

Parameter Description

MAC address

MAC address of the branch controller

Hostname

Remote

Group

Hostname of the master controller

The name of the branch config group whose settings are applied to the branch controller.

PortFast and BPDU Guard

The following section describes some of the Layer-2 Spanning Tree Protocol (STP) features for the branch controller solution. Currently, PortFast and Bridge Protocol Data Unit (BPDU) Guard features are supported, which work along with existing L2 STP feature. These two features enhance network reliability, manageability, and security for the existing L2 STP feature.

Some devices and local stacks running on systems/workstations are capable of generating potential STP

BPDUs that cause Denial of Service (DOS) attacks. PortFast and BPDU Guard features provide stability and security for network topologies to prevent such attacks.

PortFast

The PortFast feature is introduced to avoid network connectivity issues. These issues are caused by delays in

STP enabled ports moving from blocking-state to forwarding-state after transitioning from the listening and learning states. STP enabled ports that are connected to devices such as a single switch, workstation, or a server can access the network only after passing all these STP states. Some applications need to connect to the network immediately, else they will timeout.

Enabling the PortFast feature causes a switch or a trunk port to enter the STP forwarding-state immediately or upon a linkup event, thus bypassing the listening and learning states. The PortFast feature is enabled at a port level, and this port can either be a physical or a logical port. When PortFast feature is enabled on a switch or a trunk port, the port immediately transitions to the STP forwarding state.

Though PortFast is enabled the port still participates in STP. If the port happens to be part of topology that could form a loop, the port eventually transitions into STP blocking mode. PortFast is usually configured on an edge port, which means the port should not receive any STP BPDUs. If the port receives any STP BPDU, it moves back to normal/regular mode and will participate in the listening and learning states.

In most deployments, edge ports are access ports. However, in this scenario there are no restrictions in enabling the PortFast feature. The mode of the port changes from PortFast to non-PortFast when the port receives a STP BPDU. To re-enable this feature on a port, run the shut command followed by a no-shut command at the interface/port level.


Configuring PortFast on a non-edge port can cause instability to the STP topology.

BPDU Guard

BPDU Guard feature protects the port from receiving STP BPDUs, however the port can transmit STP BPDUs.

When a STP BPDU is received on a BPDU Guard enabled port, the port is shutdown and the state of the port changes to ErrDis (Error-Disable) state. The port remains in the ErrDis state until the port status is manually changed by using the configuration command shut followed by a no-shut applied on the interface. In most deployments, BPDU Guard feature is configured over the PortFast enabled STP ports, but in this implementation the BPDU Guard feature can be enabled on any of the STP ports, with or without PortFast feature being enabled on these ports.

It is recommended not to enable the BPDU Guard feature on a trunk port that forms the STP topology.

Scenarios Supported on PortFast and BPDU Guard

PortFast and BPDU Guard features are applied at the port/interface level. These features can also be applied in the following scenarios: n n n

RSTP and PVST modes

Access and Trunk ports

Physical and Logical ports

The PortFast and BPDU Guard features can be applied either independently or together.

In the global RSTP mode there is only one RSTP instance running in the entire controller. If the port that is enabled with PortFast and BPDU Guard receives any STP BPDU it will effect all the ports, as the global RSTP runs on a port basis.

In the PVST mode there can be multiple instances of RSTP running as they are based on per VLAN. Though it is based on per VLAN, it will still behave in the same way as it does in the global RSTP mode. For example, if there are five VLANs and each VLAN has a separate RSTP instance running, then any STP BPDU received on any of these five ports effects all ports.

If an STP BPDU is received from any one of the five RSTP instances running, the port that is enabled with BPDU

Guard shuts down and goes to ErrDis state. In other words both PortFast and BPDU Guard features are applied on a port basis for both global RSTP and PVST modes, even though the PVST runs on a per VLAN basis.

Enabling PortFast and BPDU Guard on a Port

The following section guides you to enable the PortFast and BPDU Guard features on a port.

In the Web UI

Follow the steps below to enable PortFast and BPDU Guard features on a port using the WebUI:

1. Navigate to Configuration>Branch>Smart Config and select the Networking tab.

2. In the Ports table, click the port number for which you want to enable PortFast and BPDU Guard.

3. Click Edit .

4. Select the PortFast and BPDU Guard checkbox.

5. Click Update .

To disable PortFast and BPDU Guard uncheck the PortFast and BPDU Guard checkboxes.

ArubaOS 6.5.3.x


It is recommended to enable PortFast only on access port types. However, PortFast can be enabled on the trunk ports by selecting the Trunk checkbox in the WebUI.

In the CLI

Execute the following commands at the command prompt to enable PortFast and BPDU Guard:

(host) (config) #interface gigabitinternet 0/0/4

(host) (config-if)#spanning-tree portfast

(host) (config-if)#spanning-tree bpduguard

To disable PortFast

(host) (config-if) #no spanning-tree portfast

(host) (config-if) #no spanning-tree bpduguard

Execute the following command to enable PortFast on trunk ports:

(host) (config) #interface gigabitethernet 0/0/4

(host) (config-if)#spanning-tree portfast trunk

Execute the following show command to display the status of the STP ports in Global RSTP mode.

(host) (config-if) #show spanning-tree interface gigabitethernet 0/0/4

Execute the following show command to display the status of the STP ports in Instance RSTP (PVST) mode.

(host) #show spanning-tree interface gigabitethernet 0/0/4

Execute the following command to display the status of BPDU Guard enabled port that is in ErrDis state. This command is applicable for ports that are in both the Global RSTP and Instance RSTP (PVST) modes.

(host) (config-if) #show spanning-tree interface gigabitethernet 0/0/4

Preventing WAN Link Failure on Virtual APs

In the branch controller deployments, the local controllers are connected across the WAN link from the master controller to the RADIUS server. A WAN link outage will result in service outage as new users cannot be authenticated to 802.1X Virtual APs. This feature provides limited connectivity to branch controllers even when the WAN link is down. To provide connectivity when the WAN link is down, open and PSK SSID Virtual APs

(VAPs) are available at all times and the user can connect to these VAPs instead of the main 802.1X Virtual AP.

Currently, this feature is targeted for Campus APs in branch office deployments.

When all the WAN links are down, an AP management module in the controller updates the link state using the notification it receives from the health check manager. Depending on the link state, the new set of Virtual APs are made available to the users, ensuring minimum service depending on the deployment. The VAPs for WAN link failure feature can be configured using the branch controller WebUI or command-line interface.

In the WebUI

1. Access the WebUI of a 7000 Series controller configured as a branch controller, and navigate to

Configuration> AP Configuration> AP Group Page .

2. Select an AP Group .

3. Navigate to Wireless LAN > Virtual AP .

4. Select an existing virtual AP or add a new virtual AP.

5. Once you select the virtual AP, click Advanced tab.


6. Modify the WAN Operation Mode drop-down menu value to Primary , Always , or Backup . For WAN link failure, this mode should be set to backup .

The three modes are as follows: l always —The virtual AP is permanently enabled. This is the default mode.

l l backup —The virtual AP is enabled when the WAN link is down. If the WAN link is up, the virtual AP is disabled automatically.

primary —The virtual AP is enabled when the WAN link is up. If the WAN link is down, the virtual AP is disabled automatically.

In the CLI

(host)(Virtual AP profile "default") #wan-operation backup

For example:

(host) (config) #wlan virtual-ap default

(host)(Virtual AP profile "default")#?

wan-operation Virtual-AP WAN operation wmm-traffic-managemen.. WMM Traffic Management Profile

(host)(Virtual AP profile "default")#wan-operation ?

always Enable virtual-AP regardless of WAN link state.

backup primary

Enable virtual-AP when WAN link is down.

Enable virtual-AP only when WAN link is present.

(host)(Virtual AP profile "default") #wan-operation backup

Branch WAN Dashboard

The WAN (Wide Area Network) dashboard, in the Dashboard section of the WebUI, is the landing page for the

Branch controller. The WAN dashboard provides the WAN summary details for VLANs.

Following figure shows a snapshot of the WAN summary dashboard:

The WAN Summary page contains the following tables: n

Status : This section of the WAN Dashboard includes tabs that displays information for the status of monitored links, and for deployments using Layer-3 redundancy the status of the branch connectivity to the primary and secondary master controllers.

l

Status : This section displays the link status and WAN status for VLANs monitored using the uplink manager utility. For each VLAN, the green represents an up status and red represents a down status for

ArubaOS 6.5.3.x


n n n n n the link and WAN. The

uplink health-check feature

is enabled by default on branch controllers. If it is disabled, the WAN status link will appear orange, indicating that this feature is in an error state.

l

Layer3 Redundancy: This section displays the status of the branch controller's connection to the primary master and secondary master controllers defined during the branch controller's provisioning process.

Throughput : Displays the In and Out traffic for VLANs. The Throughput table has four tabs for different uplinks. First tab shows throughput of VLANs having high priority followed by other VLAN data based on its priority. Clicking on each tab loads In and Out traffic throughput data for that particular VLAN.

Latency : Displays Latency data for available VLANs. Each line represents one VLAN.

Alerts : Lists the last five alerts with time stamp and description.

Usage : Displays traffic based on Application Category or Application.

Compression : Displays compression that occurred on all VLANs together.


Branch Controller Config for Cloud Services Controllers. Aruba M3MK1, 7024, 7240, 620, 7280, 650, ArubaOS 6.5.3.x, 3200

Chapter 11

Branch Controller Config for Cloud Services Controllers

Branch Deployment Features

Scalable Site-to-Site VPN Tunnels

Layer-3 Redundancy for Branch Controller Masters

Configuring Layer-3 Redundancy

Viewing Controller Connectivity Status

Failover Behaviors

WAN Failure (Authentication) Survivability

Supported Client and Authentication Types

Administrative Functions

About the Survival Server

Trigger Conditions for Critical Actions

Authentication for Captive Portal Clients

Authentication for 802.1X Clients

Authentication for MAC Address-Based Clients

Authentication for WISPr Clients

WAN Health Check

WAN Optimization through IP Payload Compression

Distributed Layer 3 Branch Deployment Model

Modes of Operation

Interface Bandwidth Contracts

App and App Category Visibility

Branch Integration with a Palo Alto Networks (PAN) Portal

Configuration Prerequisites

Branch Controller Routing Features

Uplink Routing Using Nexthop Lists

Policy-Based Routing

Inbound Interface Access Lists

Cloud Management

Zero-Touch Provisioning

Before you Begin

Provisioning Modes for Branch Deployments

Automatically Provisioning a Branch Controller

Using Smart Config to create a Branch Config Group

Config Group Management Settings

System Configuration

Networking Configuration

Routing Configuration

VPN Configuration

WAN Configuration

Branch Config Group Summary

Whitelist Configuration

PortFast and BPDU Guard

PortFast

BPDU Guard

Scenarios Supported on PortFast and BPDU Guard

Enabling PortFast and BPDU Guard on a Port

Preventing WAN Link Failure on Virtual APs

Branch WAN Dashboard

Related manuals

Aruba

ArubaOS 6.4.3.x

Aruba

ArubaOS 6.4.2.x

Aruba

ArubaOS 6.2.x

Aruba

ArubaOS 6.4.0.0

Aruba

ArubaOS 6.3.x

Aruba

ArubaOS 6.5.1.x

Aruba

ArubaOS 6.4.1

Aruba

ArubaOS 6.5.2.0

Aruba

ArubaOS 6.4.0.0

Aruba

RAP-155

Table of contents