VRRP is configured on a per-interface basis from within
config-interface mode. To define a new VR address, use
vrrp-virtual-router <vrid> for IPv4 or
ipv6 vrrp-virtual-router <vrid> for
IPv6 when configuring an interface.
<vrid> must be an integer from
1-255. This identifier must be
identical for all nodes in the same cluster using a specific VR address. The VR
ID must also be different from VR IDs used for other VR addresses on any other
VRRP router on the network segment connected to this interface.
The VR ID must only be unique on a single layer 2 network segment. The same VR ID may be used on different segments.
In situations where it is unclear whether or not there is other VRRP traffic on a segment, run packet captures looking for VRRP to see if any turns up. There would typically be at least one VRRP advertisement per second from other nodes on the network. A packet capture would also show which VR IDs are active on the segment and thus should be avoided.
Though it is common to use the last octet of the VR address as the VR ID, this is not required.
Example which creates a new virtual router address:
tnsr(config)# int TenGigabitEthernet6/0/0 tnsr(config-interface)# ip vrrp-virtual-router 220 tnsr(config-vrrp4)#
This command enters
config-vrrp4 (IPv4) or
config-vrrp6 (IPv6) mode to
configure the properties of the VR address. This mode includes the following
- virtual-address <ip-address>
The IPv4 or IPv6 address which will be shared by the virtual router. Also referred to as the “Virtual Router Address” or “VR Address”.
For the primary node, or owner, for this address (priority
255), the same IP address must be configured on an interface.
- accept-mode (true|false)
Controls whether TNSR will accept packets delivered to this virtual address while in master state if it is not the IP address owner (Priority of
255). The default is
Deployments that rely on pinging the virtual address or using it for services such as DNS or IPsec should enable this feature.
Accept mode has no effect when the VR address priority is set to
255. In that case, the router with priority
255is considered the owner of the address and will already receive traffic without accept mode.
IPv6 Neighbor Solicitations and Neighbor Advertisements MUST NOT be dropped when accept-mode is ‘false’.
- preempt (true|false)
Instructs TNSR whether or not to preempt a lower priority peer to become master. The default value is
true, and the owner of a VR address will always preempt other nodes, no matter how this value is set. When set to
false, a failed node will not take back over from the current master when it recovers, but would wait until a new election occurs.
- priority <priority>
The priority for the VR address on this host. Higher values are preferred during the master election process, with the highest priority router currently operating winning the election.
The primary node, which is the owner of the VR address, must use a priority of
255and no other node should have that priority. Lower priority nodes should use unique priority values, evenly distributed throughout the
1-254range, depending on the number of nodes. The default value is
255is not compatible with NAT. To use VRRP on an interface configured for outbound NAT, use a lower priority (
1-254) instead. Since no router will be the owner of the VR address in this case, enable
accept-modeto receive traffic for the VR address if communication with the TNSR host is necessary.
- v3-advertisement-interval <interval>
The interval, specified in centiseconds (hundredths of a second), at which VRRP advertisements will be sent by this node. The default value is
100, or one second. The value may be in the range of
- track-interface <interface> priority-decrement <value>
This command configures interface tracking, which allows the status of a different interface to affect the priority value advertised for this VR address. This allows TNSR to demote itself when other interfaces fail in some way, otherwise known as “preemption”.
The following conditions constitute a failure which results in a priority decrease when tracking an interface:
The tracked interface is administratively disabled
The tracked interface suffers a link loss
The tracked interface no longer has an IP address matching the address family of this VR address
When the priority is decreased by the configured amount, other routers with the same VR address may preempt this router and assume a master role if they now have a higher priority for the VR address. In other words, this allows a VR address to demote itself upon detecting a problem without harshly changing the VR address status directly.
Without interface tracking, VRRP only protects against situations which cause a failure of the entire node at once (e.g. reboot, power off, stopping TNSR).
Consider a scenario with all routers sharing the same VR address configured with interface tracking, and all suffer the same failure. For example, a dead switch. In that case, the current master would still be master even with adjusted priority values since all affected routers would have adjusted their priorities by the same amount. If instead the VR address state were adjusted directly to assume a backup role, then there would be no active master remaining, and connectivity would be lost to this VR address.
The interface monitored by TNSR for making VR address priority adjustments. This must be a different interface, not the interface holding the VR address.
The amount by which the priority value will be decreased when the status of
<interface>changes to a failed state. May be from
0-255. The chosen value is up to the administrator and varies depending on the importance of the interface being tracked and the desirability of triggering a preemption.
For example, if this router is typically the owner of the VR address with a priority of
255, and the next highest router has a priority of
200, then a value of
60would ensure that a failure will decrease the priority sufficiently to allow the other router to assume the master role.
The advertised priority value can only decrease to a minimum of