Wireless Access

Hi,

While i working on migration of a 6.x master-standby to 8.4.0.4 mc active-active cluster i focus some issues with policy based routing.

In the new active-active cluster i have an internal vlan (999) with a VRRP configuration and internal DHCP. The DHCP server has a default gateway configured 192.168.1.1, the VRRP VIP address. 

When a user connected to controller MC02 (the VRRP master) the nexthop policy works fine. But when a user connected to MC02 (the VRRP backup) the nexthop policy is not working and the traffic is routed out the management interface (200).

When i change the DHCP default gateway from 192.168.1.1 (the VRRP VIP) to 192.168.1.7 (MC01 VLAN999 IP address). It works fine again for MC01.

Now i understand that for PBR to work the default gateway must be on the same controller and cannot be the VIP address.

Can somebody help me, to what is the correct wat to configure this in an active-active cluster. Would be very appreciated ;)

Below some config from a test environment.

user-role nexthoptest 
    access-list session nexthoptest ###acl is any any any permit

ip nexthop-list nexthoplist-nhl 
    ip 172.16.201.254 priority 5 

ip nexthop-list nexthoplist-nhl202 
    ip 172.16.202.254 priority 5 

ip access-list route nexthoptest-acl 
    any any any route next-hop-list nexthoplist-nhl 

ip access-list route nexthoplist-acl202 
    any any any route next-hop-list nexthoplist-nhl202 

ip access-list route nexthoptest-acl 
    any any any route next-hop-list nexthoplist-nhl 

ip access-list route nexthoplist-acl202 
    any any any route next-hop-list nexthoplist-nhl202 routing-policy-map role nexthoptest access-list nexthoplist-acl202

interface vlan 200  ###management vlan
    ip address 172.16.200.7 255.255.255.0 
    no suppress-arp 

interface vlan 201 ###nexthop vlan
    ip address 172.16.201.7 255.255.255.0 
    ip nat outside 

interface vlan 202 ###nexthop vlan
    ip address 172.16.202.7 255.255.255.0 
    ip nat outside 

interface vlan 999 ###internal vlan
    ip address 192.168.1.7 255.255.255.0 
    ip nat inside 
    no suppress-arp 

What is an active-active cluster?

An Mobiltiy Master with two 7210 Mobility Controllers clustered.

When you say "internal" VLAN, do you mean that the user traffic is natted out of the controller and dhcp is provided by the controller?

Yes indeed, not my first choice but have to deal with it in this migration senario.

(I think the most important reason for the customer is that they are using a public IP scope)

I think you are going to need some design help on this one.  Have you tried to get this to work on a single controller?.  I am not sure that natting out of a controller and PBR necessarily work (or have been tested) in a clustered environment.

Hi Colin,

It works for a couple of years in the 6.x master-masterstandby senario. So yes, on a single controller its works fine. But now in a cluster it work some different. Far as i understand now is that PBR need the default gateway on the same controller to work.

Because we use the VRRP VIP address as default gateway it works only for users the have there UAC on the controller that is also the VRRP MASTER. 

Because users are load balanced about two clustered controllers. The users they have the UAC on the controller that is act as the VRRP BACKUP dont have the active default gateway on the same controller and PBR will stuck.

So i didnt known/find if there is a supported solution on this in a clustered setup. I will raise a TAC case and see if they have a solution on this or we have to stay away from BPR.

Many thanks for your help on this! much appriciated!

There is no "active-active" cluster.  Both controllers in a cluster are always active.

I am sure that PBR works on ArubaOS 8, on a single controller, so there is no problem there.  The problem is natting traffic out of a cluster; I am not sure that is supported.  I don't understand what you are saying about a VRRP backup...In a cluster the VRRP exists for two reasons (1) Initial discovery of a cluster by an  AP  and (2) COA (change of authorization), which is optional.  Outside of those functions, VRRP is not used for any traffic management in a cluster, really.

In the most extreme situation, you would have this working (PBR/NAT/dhcp) on a single controller on ArubaOS 8.x and use a backup-lms controller for redundancy.

Hi Colin,

I agree with what your saying any we both think the same about it. It's not the design i should recommended but we run in this situation because of the migratition. We now looking for remove PBR/NAT/VRRP/DHCP and just assign new VLANs to each SSID (where needed) with the default gateway/dhcp on the external firewall and dhcp server.

(mc01) [MDC] *#
Virtual Router 210:
Description INTERN
Admin State UP, VR State BACKUP
IP Address 192.168.1.1, MAC Address 00:00:5e:00:01:d2, vlan 999
Priority 100, Advertisement 1 sec, Preemption Disable Delay 0
Auth type PASSWORD, Auth data: ********
tracking is not enabled

(mc02) [MDC] #
Virtual Router 210:
Description INTERN
Admin State UP, VR State MASTER
IP Address 192.168.1.1, MAC Address 00:00:5e:00:01:d2, vlan 999
Priority 110, Advertisement 1 sec, Preemption Disable Delay 0
Auth type PASSWORD, Auth data: ********
tracking is not enabled
(mc02) [MDC] #

To be clear, the auto-created VRRP ids from 200 and above are ONLY necessary for COA and should not be defined in the cluster definition if you are not doing COA.

I agree that using external dhcp server and firewall is the way to go.