LACP For AP’s With Two Ethernet Ports

I was asked on how to configure LACP for AP’s connected to a controller and I was not able to answer this question out of my mind so I decided to figure it out for myself. And as always, when I need to test something, I write a post about it. This is my post on how to configure LACP for AP’s. I will describe this feature for controller-based AP’s and also for Instant AP’s

Connecting two ethernet ports has two main benefits:

• more bandwidth
• high availability for AP’s which can draw power on both ports

LACP for AP’s with Controller

If you use LACP for AP’s with a controller there are several flavors, depending on the controller setup you have. I will only show the most common ones, for a standalone controller and for a cluster of controllers, as I assume, that if you run more than one controller it will be a cluster.

LACP for AP’s with a Controller Cluster

This setup is the easiest one so it comes first. I assume, that you have a L2 connected cluster up and running and that your AP’s are deployed around your site. If you need help for this setup, here is my post about the cluster setup:

ArubaOS 8 Cluster Setup

The first problem with LACP on an AP is that there is mostly only one type of communication, coming from the AP going to the Controller and vice versa. Only two types of protocols are involved, IPSec and GRE. IPSec does not matter, as this is only used for AP Controller communication. The important part is the GRE protocol as the client data is transferred in this GRE tunnel.

As there are only two communication partners involved the normal load sharing algorithms did not work. Most of the time it is L2 based. So we need to change this to L3 based load balancing.

For Comware based devices it looks like this:

link-aggregation global load-sharing mode destination-ip source-ip

For Aruba OS based switches this looks like this:

trunk-load-balance l3

Afterward, you need to create a trunk (link-aggregation group for Comware) and connect your AP’s with both ports. Make sure, to make this trunk (link-aggregation group for Comware) based on active LACP and not static! Upon reboot of the AP, the AP will detect the LACP BPDU’s and will activate LACP on both ports.

As we are running a cluster, each client will be connected to a different Controller in the cluster. And with the help of the L3 load balancing for the trunk (link-aggregation group for Comware) both links are utilized.

The AP will define one port per controller as you can see here:

(Cluster-Member-1) #show ap debug lacp ap-name ap515 verbose

AP LACP GRE Striping IP: 0.0.0.0

AP LACP Status
--------------
Link Status  LACP Rate  Num Ports  Actor Key  Partner Key  Partner MAC
-----------  ---------  ---------  ---------  -----------  -----------
Up           slow       2          9          2            5c:8a:38:95:80:17

Slave Interface Status
----------------------
Slave I/f Name  Permanent MAC Addr  Link Status  Member of LAG  Link Fail Count
--------------  ------------------  -----------  -------------  ---------------
eth0            90:4c:81:cf:3c:22   Up           Yes            0
eth1            90:4c:81:cf:3c:23   Up           Yes            1

GRE Traffic Received on Enet Ports
----------------------------------
Zone  Index  Controller IP  Enet 0 Rx Count  Enet 1 Rx Count
----  -----  -------------  ---------------  ---------------
0     0      10.201.201.11  0                88209
0     1      10.201.201.12  172112           92439

GRE Traffic Sent on Enet Ports
------------------------------
Zone  Index  Controller IP  Enet 0 Tx Count  Enet 1 Tx Count
----  -----  -------------  ---------------  ---------------
0     0      10.201.201.11  9114             0
0     1      10.201.201.12  0                242736

Link Aggregation UACs outgoing interface
---------------------------------
zone=0 idx=0 IPv4=10.201.201.11 odev=eth0
zone=0 idx=1 IPv4=10.201.201.12 odev=eth1
---------------------------------
eth0   UACs 1
eth1   UACs 1

As you see in the output above, the AP defines one physical port for each UAC in the cluster. This makes sure, that the sending traffic is balanced based on the user load balancing in the cluster. The receiving traffic is balanced on the L3 information in the GRE header by the switch.

With the command above, you also see the traffic distribution and that both ports are up and member of the Link aggregation group.

As you can see, you do not need to configure anything on the controller. That makes it so easy with a cluster of Controllers.

LACP for AP’s with a Standalone Controller

With a standalone Controller the story is different. You have only one controller and only one controller IP, so here is the point, where it gets tricky.

For all AP’s with two ethernet interfaces, it is possible to create a second IP for the controller. This IP needs to be in the subnet of the controller LMS IP but it does not need to be configured on the controller at all. The AP will use “eth0” to send all traffic to the LMS IP and “eth1” for the additional IP. We will call this IP the “GRE Striping IP”. The AP will also assign 5GHz traffic to “eth0” and 2.4GHz traffic to “eth1”. You cannot change this. Sounds complex, but is very easy.

To start, configure the switches the same way as above. If you connected the AP’s now, they will do LACP as well, but they will only use “eth0” to send traffic and both interfaces to receive traffic.

The first thing on the controller is to configure a LMS IP for the AP’s. Go to “Configuration–>AP Groups” and select your AP group and switch to the LMS tab:

In the config it would look like this:

ap system-profile "default"
    session-acl ""
    lms-ip 10.201.201.10
    ap-console-password 6ff4d0d32c19eaf0cef1e5167b205a809127f17fb4638c1d
    bkup-passwords 114129e32c28546a0caabf2e7d391904913f992794a6508f
!

I use the default system profile for this test. The important option is the third line for the “lms–ip“.

The next step is to configure the “GRE Striping IP”. The AP uses this IP for a secondary GRE tunnel to the controller. You do not need to configure this IP on an interface on the controller. Select this IP in a way, that the second switch port is used for this GRE tunnel. A good choice would be “lms–ip” + 1. In my case “10.201.201.11”. If this is not possible and your “lms–ip” is even, chose an odd IP or vice versa. This should allow the switch to load balance the traffic.

To set the “GRE Striping IP” go to “Configuration–>System” and select the “Profiles” tab. Now select “AP” and “AP LACP LMS map information”:

Enable “AP LACP Striping IP” and add the “GRE Striping IP” with the “LMS IP”. From the CLI it looks like this:

ap-lacp-striping-ip
    aplacp-enable
    striping-ip 10.201.201.11 lms 10.201.201.10
!

Afterward your AP’s will create a tunnel for each radio, but to a different IP destinations. The 5GHz radio will use the “LMS IP” and the 2.4GHz radio will use the “GRE Striping IP” for the GRE tunnel. To check if it is working we can use the same command as above:

(Standalone) [mynode] #show ap debug lacp ap-name a0:2b:b8:86:65:00 verbose

AP LACP GRE Striping IP: 10.201.201.11

AP LACP Status
--------------
Link Status  LACP Rate  Num Ports  Actor Key  Partner Key  Partner MAC
-----------  ---------  ---------  ---------  -----------  -----------
Up           slow       2          17         2            5c:8a:38:95:80:17

Slave Interface Status
----------------------
Slave I/f Name  Permanent MAC Addr  Link Status  Member of LAG  Link Fail Count
--------------  ------------------  -----------  -------------  ---------------
eth0            a0:2b:b8:86:65:00   Up           Yes            0
eth1            a0:2b:b8:86:65:01   Up           Yes            0

GRE Traffic Received on Enet Ports
----------------------------------
Radio Num  Enet 0 Rx Count  Enet 1 Rx Count
---------  ---------------  ---------------
0          0                3980
1          136392           0
non-wifi   0                4819

Traffic Sent on Enet Ports
--------------------------
Radio Num  Enet 0 Tx Count  Enet 1 Tx Count
---------  ---------------  ---------------
0          4478             0
1          0                48260
non-wifi   7159             45

On the output above you find the “GRE Striping IP in the first line and in the lower part the load sharing between the two ethernet ports.

The “show ap database” command now includes the “s” flag for the AP’s with two ethernet interfaces:

(Standalone) [mynode] #show ap database

AP Database
-----------
Name               Group      AP Type  IP Address      Status         Flags  Switch IP       Standby IP
----               -----      -------  ----------      ------         -----  ---------       ----------
a0:2b:b8:86:65:00  default    225      10.200.200.100  Up 1h:34m:24s  2s     10.201.201.10   0.0.0.0
AP515              default    515      10.200.200.100  Down           2      10.201.201.10   0.0.0.0
RAP205             RAP-Group  205      10.0.0.24       Down           Rc2    10.201.201.111  0.0.0.0

Flags: 1 = 802.1x authenticated AP use EAP-PEAP; 1+ = 802.1x use EST; 1- = 802.1x use factory cert; 2 = Using IKE version 2
       B = Built-in AP; C = Cellular RAP; D = Dirty or no config
       E = Regulatory Domain Mismatch; F = AP failed 802.1x authentication
       G = No such group; I = Inactive; J = USB cert at AP; L = Unlicensed
       M = Mesh node
       N = Duplicate name; P = PPPoe AP; R = Remote AP; R- = Remote AP requires Auth;
       S = Standby-mode AP; U = Unprovisioned; X = Maintenance Mode
       Y = Mesh Recovery
       c = CERT-based RAP; e = Custom EST cert; f = No Spectrum FFT support
       i = Indoor; o = Outdoor; s = LACP striping; u = Custom-Cert RAP; z = Datazone AP
       p = In deep-sleep status

Total APs:3

Even with one Controller, the setup is very easy, even if it sounds complex in the first place.

LACP for AP’s with Instant AP’s

With Instant AP’s, it is very easy again. As they do not tunnel the traffic (except you use VPN for some SSID’s), all users are directly seen on the port. So it even does not matter, if you chose L2 or L3 load sharing on the switch. I have configured the switch as above for the CAP’s connected to a Controller cluster. Now, let’s check what we can see from the IAP:

AP LACP GRE Striping IP: 0.0.0.0


AP LACP Status
--------------
Link Status  LACP Rate  Num Ports  Actor Key  Partner Key  Partner MAC
-----------  ---------  ---------  ---------  -----------  -----------
Up           slow       2          17         2            5c:8a:38:95:80:17

Slave Interface Status
----------------------
Slave I/f Name  Permanent MAC Addr  Link Status  Member of LAG  Link Fail Count
--------------  ------------------  -----------  -------------  ---------------
eth0            a0:2b:b8:86:65:00   Up           Yes            0
eth1            a0:2b:b8:86:65:01   Up           Yes            0

Traffic Sent on Enet Ports
--------------------------
Radio Num  Enet 0 Tx Count  Enet 1 Tx Count
---------  ---------------  ---------------
0          0                0
1          0                0
non-wifi   2283             1045

You can see, that both links are up and part of a LAG. Unfortunately, on the IAP platform, you do not see the traffic distribution on both links. Here we need to check the switch:

[Aruba]dis interface GigabitEthernet 1/0/1
 GigabitEthernet1/0/1 current state: UP
 IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 5c8a-3895-8019
 Description: GigabitEthernet1/0/1 Interface
 Loopback is not set
 Media type is twisted pair, Port hardware type is 1000_BASE_T
 1000Mbps-speed mode, full-duplex mode
 Link speed type is autonegotiation, link duplex type is autonegotiation
 Flow-control is not enabled
 The Maximum Frame Length is 9600
 Broadcast MAX-ratio: 100%
 Unicast MAX-ratio: 100%
 Multicast MAX-ratio: 100%
 PVID: 202
 Mdi type: auto
 Port link-type: trunk
  VLAN passing  : 1(default vlan), 200, 202, 204
  VLAN permitted: 1(default vlan), 2-4094
  Trunk port encapsulation: IEEE 802.1q
 Port priority: 0
 Last clearing of counters:  Never
 Peak value of input: 421 bytes/sec, at 2000-04-26 12:19:33
 Peak value of output: 380 bytes/sec, at 2000-04-26 12:17:48
 Last 300 seconds input:  2 packets/sec 421 bytes/sec 0%
 Last 300 seconds output:  1 packets/sec 314 bytes/sec 0%
 Input (total):  2016 packets, 238924 bytes
	 432 unicasts, 1308 broadcasts, 276 multicasts, 0 pauses
 Input (normal):  2016 packets, 238924 bytes
	 432 unicasts, 1308 broadcasts, 276 multicasts, 0 pauses
 Input:  0 input errors, 0 runts, - giants, - throttles
	 0 CRC, - frame, 0 overruns, 0 aborts
	 - ignored, - parity errors
 Output (total): 1074 packets, 194710 bytes
	 308 unicasts, 51 broadcasts, 715 multicasts, 0 pauses
 Output (normal): 1074 packets, 194710 bytes
	 308 unicasts, 51 broadcasts, 715 multicasts, 0 pauses
 Output: 0 output errors, - underruns, - buffer failures
	 0 aborts, 0 deferred, 0 collisions, - late collisions
	 - lost carrier, - no carrier

[Aruba]dis interface GigabitEthernet 1/0/3
 GigabitEthernet1/0/3 current state: UP
 IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: 5c8a-3895-801b
 Description: GigabitEthernet1/0/3 Interface
 Loopback is not set
 Media type is twisted pair, Port hardware type is 1000_BASE_T
 1000Mbps-speed mode, full-duplex mode
 Link speed type is autonegotiation, link duplex type is autonegotiation
 Flow-control is not enabled
 The Maximum Frame Length is 9600
 Broadcast MAX-ratio: 100%
 Unicast MAX-ratio: 100%
 Multicast MAX-ratio: 100%
 PVID: 202
 Mdi type: auto
 Port link-type: trunk
  VLAN passing  : 1(default vlan), 200, 202, 204
  VLAN permitted: 1(default vlan), 2-4094
  Trunk port encapsulation: IEEE 802.1q
 Port priority: 0
 Last clearing of counters:  Never
 Peak value of input: 4059 bytes/sec, at 2000-04-26 12:11:27
 Peak value of output: 861 bytes/sec, at 2000-04-26 12:18:33
 Last 300 seconds input:  2 packets/sec 724 bytes/sec 0%
 Last 300 seconds output:  2 packets/sec 701 bytes/sec 0%
 Input (total):  3127 packets, 1682001 bytes
	 2913 unicasts, 16 broadcasts, 198 multicasts, 0 pauses
 Input (normal):  3127 packets, 1682001 bytes
	 2913 unicasts, 16 broadcasts, 198 multicasts, 0 pauses
 Input:  0 input errors, 0 runts, - giants, - throttles
	 0 CRC, - frame, 0 overruns, 0 aborts
	 - ignored, - parity errors
 Output (total): 2681 packets, 571917 bytes
	 2513 unicasts, 42 broadcasts, 126 multicasts, 0 pauses
 Output (normal): 2681 packets, 571917 bytes
	 2513 unicasts, 42 broadcasts, 126 multicasts, 0 pauses
 Output: 0 output errors, - underruns, - buffer failures
	 0 aborts, 0 deferred, 0 collisions, - late collisions
	 - lost carrier, - no carrier

You can see in and out packets on both interfaces, so we know, that LACP and traffic distribution is working.

This concludes this post. Did you use redundant connected AP’s in you environment?

If you find this post useful, leave me a comment and share it with your friends. If you don’t like the post, leave me a comment and tell me what you don’t like. But whatever you do, leave me a comment.