...
In IPv6 networks, hosts learn about routers by receiving Router Advertisements used by the Neighbor Discovery (ND) protocol. ND already has a built-in mechanism to determine unreachable routers. However, it can take up to 38 seconds to detect an unreachable router. It is possible to change parameters and make detection faster, but it will increase the overhead of ND traffic especially if there are a lot of hosts. VRRP allows detecting the detection of unreachable routers within 3 seconds without additional traffic overhead.
Virtual Router Redundancy Protocol (VRRP) provides a solution by combining a number of routers into a logical group called Virtual Router (VR). VRRP implementation in RouterOS is compliant with based on VRRPv2 RFC 3768 and VRRPv3 RFC 5798.
It is recommended to use the same version of RouterOS for all devices with the same VRID used to implement VRRP.
| Note |
|---|
According to RFC authentication is deprecated for VRRP v3 |
...
Virtual IP associated with VR must be identical and set on all VR nodes. On the Owner router, the Virtual IP must be the same as the real IP. For example, on the Owner router real IP and virtual IP is 192.168.1.1, on the Backup router virtual IP is 192.168.1.1, but the real IP is 192.168.1.2. All virtual and real addresses should be from the same network.
| Note |
|---|
It is not recommended to set up a Mikrotik router as an Owner router. VRRP address and real IP address should not be the same. |
All virtual and real addresses should be from the same network.
| Note |
|---|
RouterOS can not be configured as Owner. VRRP address and real IP address should not be the same. |
If the Master of VR is associated with multiple IP addresses, then Backup routers belonging to the same VR must also be associated with the same set of virtual IP addresses. If the virtual If the Master of VR is associated with multiple IP addresses, then Backup routers belonging to the same VR must also be associated with the same set of virtual IP addresses. If the virtual address on the Master is not also on Backup a misconfiguration exists and VRRP advertisement packets will be discarded.
All Virtual Router members can be configured so that virtual IP is not the same as physical IP. Such a Virtual virtual address can be called a floating or pure virtual IP address. The advantage of this setup is the flexibility given to the administrator. Since the virtual IP address is not the real address of any one of the participant routers, the administrator can change these physical routers or their addresses without any need to reconfigure the virtual router itself.
...
- responds to ND Neighbor Solicitation message for the associated IPv6 address;
- sends ND Router Advertisements for the associated IPv6 addresses.
If the advertisement packet is received by master node:
...
Connection tracking synchronization
Similar to different High availabilityfeatures, RouterOS v7 supports VRRP connection tracking VRRP connection tracking synchronization.
The VRRP connection tracking synchronization requires that RouterOS connection tracking is running. By default, connection tracking is working in auto mode. If VRRP devices do not contain any firewall rules, you need to manually enable connection tracking:
| Code Block | ||
|---|---|---|
| ||
/ip/firewall/connection/tracking/set enabled=yes |
synchronization. To sync connection tracking entries configure the device as follows:
| Code Block | ||
|---|---|---|
| ||
/interface/vrrp/set vrrp1 sync-connection-tracking=yes |
...
Connection tracking entries are synchronized only from the Master to the Backup device. Preemption-mode and
When both sync-connection tracking are mutually exclusive-tracking and preemption-mode are enabled, and a router with higher VRRP priority becomes online, the connections get synchronized first, and only then the router with higher priority becomes the VRRP master.
| Tip |
|---|
If multiple VRRP interfaces are configured between two units, then it is enough to enable sync-connection-tracking=yes on one (preferably master) VRRP interface. |
...
| Property | Description | |||||
|---|---|---|---|---|---|---|
| arp (disabled | enabled | proxy-arp | reply-only; Default: enabled) | ARP resolution protocol mode | |||||
| arp-timeout(integer; Default: auto) | ||||||
| authentication (ah | none | simple; Default: none) | Authentication method to use for VRRP advertisement packets.
| |||||
| group-master authority (interface; Default: none) | Allows combining multiple VRRP interfaces to maintain the same VRRP status within the group. For example, VRRP instances run on LAN and WAN networks with NAT in-between. If one VRRP instance is Master and the other is Backup on the same device, the entire network malfunctions due to NAT failure. Grouping LAN and WAN VRRP interfaces ensure ensures that both are either VRRP Master or Backup. In a VRRP group, VRRP control traffic gets sent only by the group masterauthority. That's why in a typical WAN+LAN setup, it is recommended to use the LAN network as the group master to keep VRRP control traffic in the internal network.
Group-authority was previously called "group-master", "group-master" is kept for compatibility with scripts, but if both are set only "group-authority" will be taken into account. | |||||
| interface (string; Default: ) | Interface name on which VRRP instance will be running | |||||
| interval (time [10ms..4m15s]; Default: 1s) | VRRP update interval in seconds. Defines how often the master sends advertisement packets. | |||||
| mtu (integer; Default: 1500) | Layer3 MTU size. Since RouterOS v7.7, the VRRP interface always uses slave interface MTU | |||||
| name (string; Default: ) | VRRP interface name | |||||
| on-backup (string; Default: ) | Script to execute when the node is switched to the backup state | |||||
| on-master (string; Default: ) | Script to execute when the node is switched to master state | |||||
| on-fail (string; Default: ) | Script to execute when the node fails | |||||
| password (string; Default: ) | Password required for authentication. Can be ignored if authentication is not used. | |||||
| preemption-mode (yes | no; Default: yes) | Whether the master node always has the priority. When set to 'no' the backup node will not be elected to be a master until the current master fails, even if the backup node has higher priority than the current master. This setting is ignored if the owner router becomes available | |||||
| priority (integer: 1..254; Default: 100) | Priority of VRRP node used in Master election algorithm. A higher number means higher priority. '255' is reserved for the router that owns VR IP and '0' is reserved for the Master router to indicate that it is releasing responsibility. | |||||
| remote-address (IPv4; Default: ) | Specifies the remote address of the other VRRP router for syncing connection tracking. If not set, the system autodetects the remote address via VRRP. The remote address is used only if sync-connection-tracking=yes. Explicitly setting a remote address has the following benefits:
Sync connection tracking uses UDP port 8275. | |||||
| v3-protocol (ipv4 | ipv6; Default: ipv4) | A protocol that will be used by VRRPv3. Valid only if the version is 3. | |||||
| version (integer [2, 3]; Default: 3) | Which VRRP version to use. | |||||
| vrid (integer: 1..255; Default: 1) | Virtual Router identifier. Each Virtual router must have a unique id number | |||||
| sync-connection-tracking(string; Default: no) | Synchronize connection tracking entries from Master to Backup device. Does not work together with preemption-modeThe VRRP connection tracking synchronization requires that RouterOS connection tracking is running. |