When a failed device comes back, does the VIP automatically move back to it?
Short answer
Yes. The VIP is configured to run on the device that is given the Master role; when that device goes out of service, the VIP moves to the peer device, and when the device comes back and is healthy, the VIP returns to it. In the Only VRRP method, the Master device takes the VIP back when it rejoins VRRP; in the TR7-checked methods, the VIP is returned to the configured role when the checks of both devices succeed. The return is also a VIP transition. If the VIP is to stay on the device where it is, the Master/Slave role is changed with Edit IP; if the return is to happen at a planned moment, Disable for and Enable for are used.
How Does the Return Happen?
| VIP Transition Method | Failure | Return |
|---|---|---|
| Only VRRP | When the VRRP advertisements from the Master stop, the VIP moves to the peer device | When the Master device is turned on and joins VRRP, it takes the VIP back |
| TR7 Link Check · TR7 GW Check · TR7 Link and GW Check | When the check fails only on the Master device, the VIP moves to the peer device | When the checks of both devices succeed, the VIP returns to the configured role, that is, to the Master device |
As long as the VIP stays on the peer device, TR7 shows this as an abnormal state: while the two devices are connected to each other, on the Network → Interfaces screen, Master VIP is absent on the Master side and Slave VIP is active on the peer side; in the vService list, both halves appear as Warning. As long as the Master device cannot be reached, on the peer device's screen, the Master column shows Cluster connection is down and the peer device column shows Both VIP might be active (interface and IP statuses).
Controlling the Moment of Return
- In planned maintenance: The VIPs are turned off for the maintenance device with Disable for <device name>; even if the device is turned on, the VIP does not return. When they are turned on at a suitable moment with Enable for <device name>, the VIP returns (What should I watch out for when taking a device in the cluster into maintenance?).
- If the VIP is to stay on the peer device: The VIP is right-clicked and the Master/Slave role is changed with Edit IP; the device carrying the VIP becomes the Master (Edit IP).
How to Verify?
- Network → Interfaces: the VIP appears in the two columns as
Master VIP is activeandSlave VIP. - Load Balancer vService list: both halves are green; the "VIP … is on slave" message in the Details tab of the preview is gone.
- Settings → System Logs → Notification Logs: in the VIP Status events, it is seen that the VIP moved to the Master device, and the device that produced the event is seen in the Source column (notification types).
Common Misconceptions
- "The VIP stays on the device it moved to." The VIP returns to the device that is given the Master role; to move it permanently, the role is changed.
- "The time of the return cannot be chosen." In planned maintenance, the VIP is kept on the peer device with Disable for, and the return is performed at a low-traffic moment with Enable for (What should I watch out for when taking a device in the cluster into maintenance?).
- "A VIP turned off with Disable for also returns." A VIP turned off for one device stays on the other device until Enable for is performed.
How it is done in the documentation
