Wireless Access

I have (2) local controllers on the same VLAN that I want to use VRRP for redundancy. I do not want to use the network switch to run the heartbeats for the vrrp master so I am wondering if there is a better way to accomplish sending the heartbeats to the backup controller.

I was thinking a crossover cable between controllers but not sure how this would be set up. Also, tried tracking and it seems to work.

I am looking for a best practice for the VRRP instance.

---

@jsween wrote:

I have (2) local controllers on the same VLAN that I want to use VRRP for redundancy. I do not want to use the network switch to run the heartbeats for the vrrp master so I am wondering if there is a better way to accomplish sending the heartbeats to the backup controller.

I was thinking a crossover cable between controllers but not sure how this would be set up. Also, tried tracking and it seems to work.

I am looking for a best practice for the VRRP instance.

---

Requirements:

1.  Both controllers need to send multicast traffic to each other to advertise availability for a single high availability address

2.  Only one that has priority will answer on the HA address

3.  All the access point traffic will be pointed at that controller

4.  A switch must be used to deliver frames from those access points to those controllers that own the HA address.,

Long Story short:

- Do not put a cable between the controllers for a VRRP, because it is not only heartbeats that need to be delivered, access point traffic needs to be delivered from the rest of the network to that HA address.  That means the controllers need to be plugged into a switch.

Please see the Aruba Mobility Controllers VRD on the VRD page here  http://www.arubanetworks.com/technology/reference-design-guides/#Fundamentals for more information on redundancy.

Thank you for the reply

I was not going to remove the controller from the network but I wanted the VRRP to be cabled in a better configuration.

my thought is that on the network is you lose one ping the VRRP will flip. Now that loss of ping could be any little disruption. Also, when we use a trunk for the controllers it seems that both sides of the VRRP want to be master. I can ping across and it looks fine. The only fix I found is to raise the priority of one side of the VRRP.

this is why we think a cross over cable running the VRRP heartbeat would be better.

John

---

@jsween wrote:

Thank you for the reply

 

I was not going to remove the controller from the network but I wanted the VRRP to be cabled in a better configuration.

my thought is that on the network is you lose one ping the VRRP will flip. Now that loss of ping could be any little disruption. Also, when we use a trunk for the controllers it seems that both sides of the VRRP want to be master. I can ping across and it looks fine. The only fix I found is to raise the priority of one side of the VRRP.

this is why we think a cross over cable running the VRRP heartbeat would be better.

John

---

So, the VRRP by default is configured so that the backup device will assume responsibility after not seeing VRRP multicast from the master for two seconds.  A normal or even heavily utilized wired network should have no problems delivering musticast between the two controllers (not pings).

If on a wired network you are dropping traffic, that is a huge issue and it should not happen.  One controller needs to have a higher priority than the other in practice.

If you have a reliable wired network you should not need a crossover cable.  Since you also need an uplink on that VLAN to your network anyway, a crossover cable between both controllers would be extra and would also introduce spanning tree considerations into your network, which could be troublesome.  There is no practical reason to do so.