When you are doing wired redundancy with two controllers, you are probably providing the default gateway to your clients via a VRRP.
Those ports facing the clients are probably going through a captive portal, so they are also untrusted.
This means that all client traffic is introduced to some sort of "logon" role so that they can get the captive portal.
We generally tend to make the below config to allow the controllers to communicate VRRP status between each other on untrusted ports by just adding protocol 112 (VRRP) to the ACL in the logon role:
ip access-list session VRRP-Allow
any any 112 permit
access-list session VRRP-Allow
There is something to be taken care of while using VRRP with untrusted.
VRRP for untrusted port was not designed to work and we have started supporting it but we do not really recommend. “logon” role is not recommended to be the initial role since users in this role keep getting deleted every logon-role-life timer. You can however clone the “logon” role to a custom-role and use that as initial role.
Below are the analysis of VRRP behavior in the untrusted mode, with 18.104.22.168 in setup. The IP user would be created with 0 MAC due to the VRRP packets which have destip/destmac multicast srcip=masterip, srcmac=VRRP MAC
(Aruba3600) #show user
192.168.111.2 00:00:00:00:00:00 logon 00:00:05 1/0 Wired default tunnel
(Aruba3600) #show datapath user | include 192.168.111.2
192.168.111.2 00:00:00:00:00:00 1/0 0/0 13 11 14/65535 1e
2) By default, this is the spoof settings
(Aruba3600) #show firewall | include Spoof
Prohibit IP Spoofing Enabled
Prohibit ARP Spoofing Disabled \
3) There would be some packets other than VRRP that the master sends to Backup, or Backup gets because it is a broadcast. These packets would have srcip=masterip, srcmac=masterMAC. These packets would trigger user_miss due to spoof and would be dropped in auth. This is normal. The MAC spoof message is fine and it will not affect VRRP.
4) Unless the user is in logon role, the entries in (1) will not be deleted since the entry will not ageot from datapath. Default ageout is 5 mins, and there would be a VRRP packet every 15 seconds, so the entry would not ageout. If the default role is "logon" role, there is "Logon user lifetime = 5 minutes" which will kick the user out every 5 mins.
5) Now with the user entry getting deleted every 5 mins, if a non VRRP packet comes before a VRRP packet, the user entry would be created and VRRP packet would generate IP spoof.
So, for VRRP on Primary/Backup controller to work on UN-Trusted port/Vlan, logon role can NOT be used for "Hello" advertisement sent from controllers.