Wireless Access

Hi,

I am in a trouble with ARUBA VRRP, I have the follow:

1- Two Controllers in Master/Local

2- management VLAN is 500

3- both are 6000-M3 model

4-They are running 6.1.3.1

5- I configured them fine and they can ping each other on the management VLAN. And they established a link between each other. and Master discovered the local and that appear on the monitor screen.

6- I configured the VRRP as follow:

Master:

-----------

!

vrrp 1

ip 10.1.1.1

vlan 500

preempt

authentication 123

no shut

priority 110

!

vrrp 2

ip 10.1.1.2

vlan 500

preempt

authentication 321

no shut

!

on Local:

-----------

!

vrrp 1

ip 10.1.1.1

vlan 500

preempt

authentication 123

no shut

!

vrrp 2

ip 10.1.1.2

vlan 500

preempt

authentication 321

no shut

priority 110

!

(reload both)

7- after this the following happen:

a- Master controller will be Master in vrrp 1 and will be backup in vrrp 2

b- Local controller will be Master on both vrrp 1 and vrrp 2 

c- the link between Master/Local will go down (I can not see the local from the master monitoring screen)

d- from the master I can not ping the local management IP address and VRRP 2 address, however, I can ping any other address.

e- from the local I can not ping the master management IP address, however, I can ping other addresses.

This mean that the VRRP configuration caused me trouble between the controllers and the Local is not even switching to backup for VRRP1 !!!! even though the password is same and it has lower priority and preempt is enabled.

Am I missing something in the configuration or is it a software image issue?

I don't think you should (or can) run VRRP on the VLAN that the controller uses as it's controller IP.  Can you run VRRP on a different VLAN?   If you do "show controller-ip", is VLAN 500 listed there?  If so, having that IP move to a local controller may cause issues.

If you have to run VRRP on that VLAN, can you switch the controller-ip to a different VLAN?  Careful doing that, though.  It will cause the APs to bounce or potentially not come back at all if they can't reach the new controller-ip.

The other problem is was just thinking of is that the master/local relationship builds an IPSec tunnel between the controllers.  When you don't have VRRP running, it works OK.  When you setup VRRP, the local is trying to reach the VLAN 500 address (the masters controller-ip) through the IPSec tunnel and can't.  I think you need to move the controller-ip to another VLAN or the loopback when you get a maintenance window.

I want to mention that I have four IP address in the same subnet/vlan

10.1.1.3 for Master (controller-ip)

10.1.1.4 for Local (controller-ip)

10.1.1.1 for VRRP-1 (Master is Active)

10.1.1.2 for VRRP-2 (Local is Active)

I used controller-ip vlan 500 for both Local and management.

and I used masterip 10.1.1.3 in local and localip 10.1.1.4 in master.

Is a matter with subnet IP address or VLAN number , if I used 10.1.1.3 and 10.1.1.4 in loopback interface and used controller-ip loopback , would this solve the issue or I have to change the subnet.

I got you that it can not reach the master when having VRRP, however, the local also stay Master in both VRRPs and I really do not know why it can not reach it ! would the local try and use VRRP IP instead of the management IP making the master discard the packet ? so if I used the option there of specifying the source IP from Local WebUI would this solve the issue.

one more point about the controller-ip function: (as per the UG)

The Controller IP address is used by the controller to communicate with external devices such as APs.

however, if AP is using VIP address as Master Controller IP, why would Controller use the configured (controller-ip) address instead of its VIP which received the pack from AP !

The APs (lms-ip) should point to the VIP address.  That way, which ever controller is the VRRP primary will respond.   The local controller should be it's tunnel to the controller-ip of the master.

Does that make sense?  Sorry this is so complicated.  I hardly see VRRP between masters & locals.  Normally, we would run VRRP between two masters or two locals.  It works either way (or should), but its sort of different.

hi olino,

I remember that in the ACMP bootcamp we used the following

on Master

--------------

vlan 50

ip 10.1.50.100

subnet 255.255.255.0

localip 10.1.50.101 ipsec aruba123

!

vrrp 110

auth aruba123

ip 10.1.50.110

priority 110

vlan 50

preempt

no shut

tracking master-up-time 30 20 (I really do not why I need this if I do not have Master/Master redundancy)

!

vrrp 120

auth aruba123

ip 10.1.50.120

priority 100

vlan 50

preempt

no shut

tracking master-up-time 30 20 (I really do not why I need this if I do not have Master/Master redundancy)

on Local

---------------

vlan 60

ip 10.1.60.100

vlan 50

ip 10.1.50.101

masterip 10.1.50.100 ipsec aruba123

!

vrrp 110

auth aruba123

ip 10.1.50.110

priority 100

vlan 50

preempt

no shut

tracking master-up-time 30 20 (I really do not why I need this if I do not have Master/Master redundancy)

!

vrrp 120

auth aruba123

ip 10.1.50.120

priority 110

vlan 50

preempt

no shut

tracking master-up-time 30 20 (I really do not why I need this if I do not have Master/Master redundancy)

!

Olino, from this can we say that we need to change the (controller-ip) command to any un-used vlan to solve the issue e.g. controller-ip vlan 1

while knowning that :

interface vlan 1

ip address 172.16.0.254

and I will remove the vlan 1 from all the interfaces and trunks making it a dead end IP ?!

???

Without knowing more about your environment, I hate to say that its OK to change the controller-ip.  It is possible that changing that will make the APs lose connectivity with the controller, I think.  Your best bet may be to open a TAC ticket where they can troubleshoot the original issue and maybe find a less disruptive solution.