Controller Based WLANs

Problem:

In ArubaOS, we can source nat the user traffic by using a nat pool. 
The nat pool can be configured and mapped to the user-acl as below to source nat specific traffic.  

(Rajaguru-6.4.4.5) (config) #ip nat pool NAT-POOL-NAME 10.17.170.18 10.17.170.18

(Rajaguru-6.4.4.5) (config) #ip access-list session NAT-ACL
(Rajaguru-6.4.4.5) (config-sess-NAT-ACL)#any any any src-nat pool NAT-POOL-NAME
(Rajaguru-6.4.4.5) (config-sess-NAT-ACL)#exit

(Rajaguru-6.4.4.5) (config) #user-role NAT-USER
(Rajaguru-6.4.4.5) (config-role) #access-list session NAT-ACL
(Rajaguru-6.4.4.5) (config-role) #exit

If the IP address used in the NAT pool is also used in the VRRP, there may be ARP collision or duplicate IP from the controller detected on the network. 

When a nat pool is used to source nat the user traffic, the nat-pool IP address get mapped to the physical interface MAC address of the controller. 
So the ARP entry for the nat-pool IP on the uplink switch would point to the MAC address of the controller. 

CONTROLLER IP: 
============== 
(Rajaguru-6.4.4.5) #show ip interface brief 

Interface                   IP Address / IP Netmask        Admin   Protocol
vlan 1                     10.17.170.3 / 255.255.255.224   up      up  
loopback                    unassigned / unassigned        up      up  


ARP ENTRY FOR THE VLAN INTERFACE IP AND NAT POOL IP ON THE UPLINK SWITCH: 
========================================================================= 
(Rajaguru-S1500) #show arp        

Codes: * - Local Addresses, S - Static, A - Auth

Total ARP entries: 5

IPV4 ARP Table
--------------
 Protocol    IP Address    Hardware Address   Interface  Age (min)
----------   ----------    ----------------   ---------  ---------
 * Internet  10.17.170.2   00:0b:86:ab:c0:c0  vlan1      NA
   Internet  10.17.170.3   00:1a:1e:00:b1:40  vlan1      0    <----- 
   Internet  10.17.170.18  00:1a:1e:00:b1:40  vlan1      1    <----- 

Sometimes a network admin may prefer to use the VRRP IP on the controller in the nat-pool when there are redundant controllers. 
A VRRP IP address is always mapped to a Virtual MAC address 00:00:5E:00:01:XX . 
The last byte of the address (XX) is the Virtual Router IDentifier (VRID), which is different for each virtual router in the network. 

For example, the Virtual MAC for VRRP ID 10 is 00:00:5e:00:01:0a. 

(Rajaguru-6.4.4.5) (config) #show vrrp 

Virtual Router 10:
    Description 
    Admin State UP, VR State MASTER
    IP Address 10.17.170.10, MAC Address 00:00:5e:00:01:0a, vlan 1
    Priority 100, Advertisement 1 sec, Preemption Disable Delay 0
    Auth type NONE ********
    tracking is not enabled

So, the ARP entry for the VRRP IP on the uplink switch would point to the Virtual MAC address. 

(Rajaguru-S1500) #show arp | include 10.17.170.10,IP
IPV4 ARP Table
 Protocol    IP Address    Hardware Address   Interface  Age (min)
   Internet  10.17.170.10  00:00:5e:00:01:0a  vlan1      1

If, we use the VRRP IP in the nat-pool configuration, then the controller can respond to this IP address with two different MAC addresses. 

1. VRRP Virtual MAC address. 
2. Physical interface MAC address due to the NAT pool configuration. 

This can result in the uplink devices detecting an ARP COLLISION and reporting DUPLICATE IP. 

(Rajaguru-S1500) #show clock 

Fri May 27 01:46:49 PST 2016

(Rajaguru-S1500) #show arp | include 10.17.170.10,IP
IPV4 ARP Table
 Protocol    IP Address    Hardware Address   Interface  Age (min)
   Internet  10.17.170.10  00:00:5e:00:01:0a  vlan1      1


(Rajaguru-S1500) #show clock       

Fri May 27 01:48:06 PST 2016

(Rajaguru-S1500) #show arp | include 10.17.170.10,IP
IPV4 ARP Table
 Protocol    IP Address    Hardware Address   Interface  Age (min)
   Internet  10.17.170.10  00:1a:1e:00:b1:40  vlan1      0

The uplink Firewall, may trigger syslog messages indicating the ARP collision as below, 

ASA: Received ARP response collision from 10.17.170.10/0000.5e00.010a on interface XXXXXX_Physical with existing ARP entry 10.17.170.10/001a.1e00.b140
ASA: Received ARP response collision from 10.17.170.10/001a.1e00.b140 on interface XXXXXX_Physical with existing ARP entry 10.17.170.10/0000.5e00.010a 

The NAT POOL configuration does not get synchronized between the master and standby or the local controllers. This configuration is specific to a controller. 

So the best practice to avoid ARP collision, is the use separate NAT pools in the master and standby controllers with the respective physical or a different IP address for the source nat.