Controller Based WLANs

Does VRRP work through an Un-Trusted port of controller, if yes what config changes should be done to accommodate this?

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:    

Code: ---------
config t
ip access-list session VRRP-Allow    
any any 112 permit
user-role logon    
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 6.1.3.4 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.

Version history
Revision #:
2 of 2
Last update:
‎10-08-2015 04:19 AM
Updated by:
 
Contributors
Search Airheads
Showing results for 
Search instead for 
Did you mean: 
Is this a frequent problem?

Request an official Aruba knowledge base article to be written by our experts.