4. VRRP
This chapter provides information about configuring Virtual Router Redundancy Protocol (VRRP) parameters.
Topics in this chapter include:
4.1. VRRP Overview
Virtual Router Redundancy Protocol (VRRP) is a method of implementing a redundant IP interface shared between two or more routers on a common LAN segment, allowing a group of routers to function as one virtual router. With VRRP, one router is designated as the virtual router master and the other routers in the group act as backups. If the IP interface of the virtual router is specified as a default gateway on hosts directly attached to the LAN, the routers sharing the IP interface by participating in VRRP as part of the virtual router instance will prevent a single point of failure by ensuring access to this gateway address. VRRP can be implemented on IES and VPRN service interfaces. VRRPv3 can also be implemented on IES and VPRN service interfaces, including r-VPLS interfaces for both IES and VPRN.
The virtual router master forwards all packets sent to the virtual IP address. If the virtual router master fails, an election process begins and the backup router configured with the highest acceptable priority becomes the elected virtual router master. The new master router assumes the packet forwarding for the local hosts.
The 7705 SAR supports VRRPv3 for IPv4 and IPv6 as described in RFC 5798. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are in separate domains and do not overlap.
VRRP is supported on Ethernet adapter cards only.
 | Note: This section describes the configuration parameters of VRRP on IES and VPRN service interfaces as well as configuration parameters of VRRP policies. CLI command descriptions for VRRP policies are given in VRRP Command Reference. For CLI command descriptions related to IES and VPRN service interfaces, refer to the 7705 SAR Services Guide. |
Figure 10 displays an example of a VRRP configuration.
Figure 10: VRRP Configuration
4.2. VRRP Components
VRRP consists of the following components:
4.2.1. Virtual Router
A virtual router is a logical entity managed by VRRP that acts as a default router for hosts on a shared LAN. It consists of a virtual router ID (VRID) and one or more IP addresses across a common LAN. A VRRP router can back up one or more virtual routers.
The purpose of supporting multiple IP addresses within a single virtual router is for multi-netting. This is a common mechanism that allows multiple local subnet attachments on a single routing interface.
Up to four virtual routers are configurable on a single 7705 SAR interface. The virtual routers must be in the same subnet. Each virtual router has its own VRID, state machine, and messaging instance.
4.2.2. IP Address Owner
VRRP can be configured on a router in either owner or non-owner mode. The owner is the VRRP router that has the virtual router's IP addresses as real interface addresses. This is the router that responds to packets addressed to one of the IP addresses for items such as ICMP pings and TCP connections. All other virtual router instances participating in this message domain must have the same VRID configured and cannot be configured as owner.
4.2.3. Primary Address
A primary address is an IP address selected from the set of real interface addresses. For IPv4, VRRP advertisements are always sent using the primary IPv4 address as the source of the IPv4 packet. For IPv6, the link-local address of the interface over which the packet is transmitted is used.
A 7705 SAR IP interface must always have a primary IP address assigned for VRRP to be active on the interface. The 7705 SAR supports primary addresses and multi-netting on the IP interface. The virtual router VRID primary IP address is always the same as the primary address on the IP interface.
4.2.4. Virtual Router Master
A physical router that is participating in VRRP and which controls the IP addresses associated with the virtual router is called the master. The virtual router master is the IP address owner as long as the router is available.
The master is responsible for forwarding packets sent to the VRRP IP addresses. An election process provides dynamic failover of the forwarding responsibility to the backup router if the master becomes unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first-hop router by end hosts. VRRP enables a higher-availability default path without requiring configuration of dynamic routing or router discovery protocols on every end host.
If the master is unavailable, each virtual router backup with the same VRID compares its configured priority values with the other backup routers to determine the master role. Priority values are set with the priority command. In case of a tie, the virtual router backup with the highest primary IP address becomes the master.
The preempt parameter is supported and can be set to false (disabled) to prevent a backup router that has a higher priority value from becoming master if an existing non-owner virtual router is the current master. Disabling Preemption ensures that the preferred router will regain its master status when service restoration occurs and it goes back on line. Preemption can be enabled or disabled.
While operating as the master, a virtual router routes and originates all IP packets into the LAN using the physical MAC address for the IP interface as the Layer 2 source MAC address, not the VRID MAC address. ARP packets also use the parent IP interface MAC address as the Layer 2 source MAC address while inserting the virtual router MAC address in the appropriate hardware address field. VRRP messages are the only packets transmitted using the virtual router MAC address as the Layer 2 source MAC address.
4.2.5. Virtual Router Backup
A new virtual router master is selected from the set of VRRP virtual router backups available to assume forwarding responsibility for a virtual router if the current master fails.
4.2.6. Owner and Non-owner VRRP
Only one virtual router in the domain is configured as owner. The owner has the same real IP address as the virtual router address and is responsible for forwarding packets sent to this IP address. The owner assumes the role of the virtual router master. All virtual router instances participating in this message domain must have the same VRID configured.
VRRP on a 7705 SAR router can be configured to allow non-owners to respond to ICMP echo requests if they become the virtual router master for the virtual router. Telnet and other connection-oriented protocols can be configured for non-owner master response. However, the individual application conversations (connections) do not survive a VRRP failover. A non-owner VRRP router operating as a backup does not respond to any packets addressed to any of the virtual router IP addresses.
The most important parameter defined on a non-owner virtual router instance is the priority parameter. The priority defines the order in which a virtual router is selected as master in the master election process. The priority value and the preempt mode determine which virtual router becomes the virtual router master. In case of tied priority levels, the primary IP address determines which router becomes the master. See Priority and Preempt Mode for details on these parameters.
4.2.7. Configurable Parameters
In addition to virtual IP addresses, to facilitate configuration of a virtual router on 7705 SAR routers, the parameters listed in Table 63 can be defined in owner and non-owner configurations.
Table 63: Owner and Non-owner Virtual Router Parameters
Parameter | Owner Configuration | Non-owner Configuration |
✓ | ✓ | |
✓ | ✓ | |
✓ | ✓ | |
✓ | ✓ | |
✓ | ✓ | |
✓ | ✓ | |
✓ | ||
✓ | ||
✓ | ||
✓ | ||
✓ | ||
✓ | ||
✓ | ||
✓ |
- Master down interval and skew time are not configured directly. They are calculated from the configured value of the message interval.
Note:
4.2.7.1. VRID
The VRID must be configured with the same value on each virtual router associated with the virtual IP address or IP addresses. The VRID is placed in all VRRP advertisement messages sent by each virtual router.
4.2.7.2. Priority
The priority value affects the interaction between all virtual routers with the same VRID participating on the same LAN. The priority value is used during the election process to determine which backup router (or non-owner) will assume the role of master. The priority value can only be configured if the defined IP address on the IP interface is different from the virtual router IP address, meaning that the virtual router is a non-owner.
If the IP address on the IP interface matches the virtual router IP address (owner mode), the priority value is fixed at 255, the highest value possible. This virtual router member is considered the owner of the virtual router IP address. There can only be one owner of the virtual router IP address for all virtual router members.
Priority value 0 is reserved for VRRP advertisement messages. It is used to tell other virtual routers with the same VRID that this virtual router is no longer acting as master, triggering a new election process. If this happens, each virtual router backup sets its master down timer equal to the skew time value. This shortens the time before one of the virtual router backups becomes master. See Master Down Interval and Skew Time for details.
The current virtual router master must transmit a VRRP advertisement message immediately upon receipt of a VRRP message with priority set to 0. This prevents another virtual router backup from becoming master for a short period of time.
Non-owner virtual routers can be configured with a priority of 254 through 1. The default value is 100. It is possible for multiple non-owners to have the same priority value. If a tie is encountered during an election, the router with the highest IP address will win the election.
The priority is also used to determine when to preempt the existing master. If the preempt mode value is true (preempt enabled), VRRP advertisement messages from lower-priority masters are discarded, causing the master down timer to expire and the higher-priority backup router to transition to the master state.
The priority value also dictates the skew time added to the master timeout period. See Skew Time for details.
4.2.7.3. IP Addresses
Each virtual router with the same VRID is defined with the same set of IP addresses. These are the IP addresses used by hosts on the LAN as gateway addresses. Multi-netting supports eight IP addresses on the IP interface.
4.2.7.4. Message Interval and Master Inheritance
Each virtual router is configured with a message interval for each VRID within which it participates. This parameter must be set to the same value for every virtual router within a VRID.
Configuring the message interval value can be done in three ways: using only the milliseconds value, using only the seconds value, or using a combination of the two values, as indicated by the CLI command message interval {[seconds] [milliseconds milliseconds]}. Table 64 shows the ranges for each way of configuring the message interval.
Table 64: Message Interval Configuration Ranges
Configuration | IPv4 | IPv6 |
Using milliseconds value only | 100 to 900 ms | 10 to 990 ms |
Using seconds value only | 1 to 255 s | 1 to 40 s |
Using combination milliseconds and seconds values | 1 s 100 ms to 255 s 900 ms (1.1 s to 255.9 s) | 1 s 10 ms to 40s 990 ms (1.01 s to 40.99 s) |
Default setting | 1 s | 1 s |
The message interval field in every received VRRP advertisement message must match the locally configured message interval. If a mismatch occurs, then—depending on the inherit parameter configuration (master-int-inherit command is enabled)—the current message interval setting of the master can be used to operationally override the locally configured message interval setting. If the current master changes, the new master setting is used. If the local virtual router becomes master, the locally configured message interval is enforced.
If a VRRP advertisement message is received with a message interval set to a value different from the local value and the inherit parameter is disabled, the message is discarded without processing.
The virtual router master uses the message interval as a timer, specifying when to send the next VRRP advertisement message. Each virtual router backup uses the message interval (with the configured local priority) to derive the master down timer value.
VRRP advertisement messages that are fragmented or contain IP options (IPv4) or extension headers (IPv6) require a longer configured message interval.
The virtual router instance can inherit the master VRRP router’s message interval timer, which is used by backup routers to calculate the master down timer.
The inheritance is only configurable in the non-owner context. It is used to allow the current virtual router master to dictate the master down timer for all virtual router backups.
| Note: A message interval is the same as an advertisement interval. |
4.2.7.5. Master Down Interval
The master down interval is the time that the master router can be operationally down before a backup router takes over. The master down interval is a calculated value used to specify the master down timer. If the master down timer expires, the backup virtual router enters the master state. To calculate the master down interval, the virtual router uses the following formula:
Master Down Interval = (3 × Operational Message Interval) + Skew Time
The operational message interval is dependent upon the state of the inherit parameter, as follows. See Message Interval and Master Inheritance for details.
- If the inherit parameter is enabled, the operational message interval is derived from the current master’s message interval field in the VRRP advertisement message.
- If the inherit parameter is disabled, the operational message interval must be equal to the locally configured message interval.
The master down timer is only operational if the local virtual router is operating in backup mode.
4.2.7.6. Skew Time
The skew time is used to add a time period to the master down interval. Skew time is not a configurable parameter. It is derived from the current local priority of the virtual router. To calculate the skew time (as per RFC 5798), the virtual router uses the following formula:
Skew Time = (((256 – priority) × Master_Adver_Interval) / 256) centiseconds
A higher priority value means a smaller skew time. This means that a virtual router with a higher priority will transition to the master router more quickly than a virtual router with a lower priority.
4.2.7.7. Preempt Mode
Preempt mode is a configured true or false value that controls whether a virtual router backup with a higher priority preempts a lower-priority master. Preempt mode cannot be set to false on the owner virtual router.The IP address owner always becomes master if available. The default value for preempt mode is true.
If the preempt mode is true (enabled), the advertised priority from the incoming VRRP advertisement message from the current master is compared to the local configured priority, with the following results.
- If the local priority is higher than the received priority, the received VRRP advertisement message is discarded. This results in the eventual expiration of the master down timer, causing the backup router to transition to the master state.
- If the received priority is equal to the local priority, the message is not discarded and the current master is not replaced. The received primary IP address is not part of the decision to preempt and is not used as a tie breaker if the received and local priorities are equal.
If the preempt mode is false (disabled), the virtual router only becomes master if the master down timer expires before a VRRP advertisement message is received from another virtual router.
4.2.7.8. VRRP Message Authentication (IPv4 only)
VRRP message authentication uses a simple text password authentication key to generate master VRRP advertisement messages and validate received VRRP advertisement messages.
If the authentication-key command is re-executed with a different password key defined, the new key will be used immediately. If a no authentication-key command is executed, the password authentication key is restored to the default value. The authentication-key command may be executed at any time.
VRRP message authentication is applicable to IPv4 VRRP only.
4.2.7.8.1. Authentication Failure
Any received VRRP advertisement message that fails authentication is silently discarded with an invalid authentication counter incremented for the ingress virtual router instance.
4.2.7.9. Virtual MAC Address
The MAC address can be used instead of an IP address in ARP responses if the virtual router instance is master. The MAC address configuration must be the same for all virtual routers with the same VRID; otherwise, the result is indeterminate connectivity by the attached IP hosts. All VRRP advertisement messages are transmitted with the IEEE address as the source MAC address.
4.2.7.10. BFD-Enable
A BFD session can be used to provide a heartbeat mechanism for a VRRP instance. Only one BFD session can be assigned to a VRRP instance, but multiple VRRP instances can use the same BFD session.
BFD controls the state of the associated interface. By enabling BFD on a protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node.
4.2.7.11. Initial Delay Timer
A VRRP initialization delay timer can be configured in the range of 1 to 65535 seconds.
4.2.7.12. VRRP Advertisement Message IP Address List Verification
VRRP messages contain an IP address count field that indicates the number of IP addresses listed in the sequential IP address fields at the end of the message. The 7705 SAR implementation always logs mismatching events. The decision on where and whether to forward the generated messages depends on the configuration of the event manager. The log message is generated by network management and is not the same as the VRRP message.
Each virtual router instance maintains a record of the mismatch states associated with each source IP address in the VRRP master table. If the state changes, a mismatch log message is generated indicating the source IP address within the message, the mismatch or match event, and the time of the event.
If secondary IP addresses are used, the message contains multiple IP addresses, which must match the IP addresses on the virtual router instance. Owner and non-owner virtual router instances have the supported IP addresses explicitly defined, making mismatched supported IP addresses within the interconnected virtual router instances a configuring issue.
4.2.7.13. IPv6 Virtual Router Instance Operationally Up
When the IPv6 virtual router is properly configured with a minimum of one link-local backup address, the parent interface’s router advertisement must be configured to use the virtual MAC address in order for the virtual router to be considered operationally up.
4.2.7.14. Policies
Policies can be configured to control VRRP priority with the virtual router instance. A policy can be associated with more than one virtual router instance. Policies can only be configured in the non-owner VRRP context. See VRRP Priority Control Policies for details.
4.3. VRRP Priority Control Policies
VRRP supports control policies to manipulate virtual router participation in the VRRP master election process and the state of the master. The local priority value for the virtual router instance is used to control the election process and master state.
This section contains information on the following topics:
4.3.1. VRRP Policy Constraints
Priority control policies can only be applied to non-owner VRRP virtual router instances. Owner VRRP virtual routers cannot be controlled by a priority control policy because they must have a priority value of 255 that cannot be lowered. Only one VRRP priority control policy can be applied to a non-owner virtual router instance.
Multiple VRRP virtual router instances can be associated with the same IP interface, allowing multiple priority control policies to be associated with the IP interface.
An applied VRRP priority control policy only affects the in-use priority on the virtual router instance if the preempt mode has been enabled. A virtual router instance with preempt mode disabled always uses the base priority as the in-use priority, ignoring any configured priority control policy.
4.3.2. VRRP Base Priority
The base priority is the starting priority for the VRRP instance and is set using the service interface priority command. The actual in-use priority for the VRRP instance is derived from the base priority and an optional VRRP priority control policy that modifies the base priority.
VRRP priority control policies are used to either override or adjust the base priority value depending on events or conditions within the chassis.
Non-owner virtual router instances must have a base priority value between 1 and 254. The value 0 is reserved to indicate master termination in VRRP advertisement messages. The value 255 is reserved for the VRRP owner. The default base priority for non-owner virtual router instances is 100.
4.3.3. VRRP Priority Control Policy In-use Priority
A VRRP priority control policy enforces an overall minimum value that the policy can impose upon the VRRP virtual router instance base priority. This value provides a lower limit to the delta priority event manipulation of the base priority.
A delta priority event is a conditional event defined in the priority control policy that subtracts a given amount from the current base priority for all VRRP virtual router instances to which the policy is applied. Multiple delta priority events can apply simultaneously, creating a dynamic priority value. The base priority for the instance, minus the sum of the delta values, sets the actual priority in-use value.
An explicit priority event is a conditional event defined in the priority control policy that explicitly defines the in-use priority for the virtual router instance. The explicitly defined values are not affected by the delta in-use priority limit. If multiple explicit priority events happen simultaneously, the lowest value is used for the in-use priority. The configured base priority is not a factor in explicit priority overrides of the in-use priority.
The allowed range of the delta in-use priority limit is 1 to 254. The default is 1, which prevents the delta priority events from operationally disabling the virtual router instance.
4.3.4. VRRP Priority Control Policy Priority Events
This section contains information on the following topics:
The main function of a VRRP priority control policy is to define conditions or events that impact the ability of the system to communicate with outside hosts or portions of the network. If one or more of these events are true, the base priority on the virtual router instance is either overwritten with an explicit value, or a sum of delta priorities is subtracted from the base priority. The result is the in-use priority for the virtual router instance. Any priority event can be configured as an explicit event or a delta event.
Outside hosts are the network entities that generate the IP user traffic. VRRP communication occurs between the routers on the subnet that are using VRRP. The availability of routes and/or hosts can influence the priority of a VRRP router, making the priority variable. If a backup router loses the ability to route to some destinations, its VRRP priority is reduced, making it less desirable as a backup router in case the master fails.
Explicit events override all delta events. If multiple explicit events occur, the event with the lowest priority value is assigned to the in-use priority. As events clear, the in-use priority is re-evaluated accordingly and adjusted dynamically.
Delta priority events also have priority values. If no explicit events have occurred within the policy, the sum of the occurring delta events priorities is subtracted from the base priority of each virtual router instance. If the result is lower than the delta in-use priority limit, the delta in-use priority limit is used as the in-use priority for the virtual router instance. Otherwise, the in-use priority is set to the base priority less the sum of the delta events.
Each event generates a VRRP priority event message indicating the policy ID, the event type, the priority type (delta or explicit) and the event priority value. Another log message is generated if the event is no longer true, indicating that the event has been cleared.
4.3.4.1. Priority Event Hold-set Timers
Hold-set timers are used to dampen the effect of a flapping event. A flapping event occurs when an event continually transitions between clear and set. The hold-set timer prevents a set event from transitioning to the cleared state until it expires.
Each time an event transitions between cleared and set, the timer begins to count down to 0. If the timer reaches 0, the event is allowed to enter the cleared state once more. Entering the cleared state is always dependent on the object controlling the event conforming to the requirements defined in the event itself. It is possible, on some event types, to have another set action reset the hold-set timer. This extends the amount of time that must expire before entering the cleared state.
4.3.4.2. Port Down Priority Event
The port down priority event is associated with a physical port. The port operational state is evaluated to determine a port down priority event or event clear.
If the port operational state is up, the port down priority event is considered false (or cleared). If the port operational state is down, the port down priority event is considered true (or set).
4.3.4.3. LAG Port Down Priority Event
The LAG port down priority event is associated with a LAG. The event monitors the operational state of each port in the specified LAG.
When one or more of the ports enter the operational down state, the event is considered to be set. When all the ports enter the operational up state, the event is considered to be clear. As ports enter the operational up state, any previous set threshold that represents more down ports is considered cleared, while the event is considered to be set.
4.3.4.4. Host Unreachable Priority Event
The host unreachable priority event creates a continuous ping task that is used to test connectivity to a remote host. For the ping to be successful, the path to the remote host, and the remote host itself, must be capable and configured to accept ICMP echo requests and replies.
The ping task is controlled by interval and size parameters that define how often the ICMP request messages are transmitted and the size of each message. A historical missing reply parameter defines if the ping destination is considered unreachable.
If the host is unreachable, the host unreachable priority event is considered true (or set). If the host is reachable, the host unreachable priority event is considered false (or cleared).
4.3.4.5. Route Unknown Priority Event
The route unknown priority event defines a task that monitors the existence of a given route prefix in the routing table of the system.
The route monitoring task can be constrained by a condition that allows a prefix that is less specific than the defined prefix to be considered as a match. The source protocol can be defined to indicate the protocol the installed route must be populated from. To further define match criteria when multiple instances of the route prefix exist, an optional next-hop parameter can be defined.
If a route prefix exists within the active route table that matches the defined match criteria, the route unknown priority event is considered false (or cleared). If a route prefix does not exist within the active route table that matches the defined criteria, the route unknown priority event is considered true (or set).
4.4. VRRP Non-owner Accessibility
Although only VRRP owners can respond to ping and other management-oriented protocols directed to the VRID IP addresses, the 7705 SAR allows an override of this restraint on a per-VRRP virtual router instance basis.
This section contains information on the following topics:
4.4.1. Non-owner Access Ping Reply
If non-owner access ping reply is enabled on a virtual router instance, ICMP echo request messages destined for the non-owner virtual router instance IP addresses are not discarded at the IP interface if the virtual router is operating in master mode. ICMP echo request messages are always discarded in backup mode.
If non-owner access ping reply is disabled on a virtual router instance, ICMP echo request messages destined for the non-owner virtual router instance IP addresses are silently discarded in both the master and backup modes.
4.4.2. Non-owner Access Telnet
If non-owner access Telnet is enabled on a virtual router instance, authorized Telnet sessions can be established that are destined for the virtual router instance IP addresses if the virtual router is operating in master mode. Telnet sessions are always discarded at the IP interface if destined for a virtual router IP address on a virtual router operating in backup mode. Enabling non-owner access Telnet does not guarantee Telnet access; proper management and security features must be enabled to allow Telnet on this interface and possibly from the given source IP address.
If non-owner access Telnet is disabled on a virtual router instance, Telnet sessions destined for the non-owner virtual router instance IP addresses are silently discarded in both master and backup modes.
4.4.3. Non-owner Access SSH
If non-owner access SSH is enabled on a virtual router instance, authorized SSH sessions can be established that are destined for the virtual router instance IP addresses if the virtual router is operating in master mode. SSH sessions are always discarded at the IP interface when destined for a virtual router IP address on a virtual router operating in backup mode. Enabling non-owner access SSH does not guarantee SSH access; proper management and security features must be enabled to allow SSH on this interface and possibly from the given source IP address. SSH is applicable to IPv4 VRRP only.
If non-owner access SSH is disabled on a virtual router instance, SSH sessions destined for the non-owner virtual router instance IP addresses are silently discarded in both master and backup modes.
4.5. VRRP Configuration Process Overview
Figure 11 displays the process to provision VRRP parameters.
Figure 11: VRRP Configuration
4.6. Configuration Notes
The following are VRRP configuration guidelines and caveats:
- creating and applying VRRP policies are optional
- backup command:
- the virtual backup IP addresses must be on the same subnet. The backup addresses explicitly define which IP addresses are in the VRRP message IP address list.
- in owner mode, the backup IP address must be identical to one of the interface IP addresses
- for IPv6, one of the backup addresses configured must be the link-local address of the owner VRRP instance