VRRP Command Reference

This command creates the context to configure a VRRP priority control policy that is used to control the VRRP in-use priority based on priority control events. The VRRP priority control policy commands define policy parameters and priority event conditions.

The virtual router instance priority command defines the initial or base value to be used by non-owner virtual routers. This value can be modified by assigning a VRRP priority control policy to the virtual router instance. The VRRP priority control policy can override the base priority setting to establish the actual in-use priority of the virtual router instance.

The policy command must be created first, before it can be associated with a virtual router instance.

Because VRRP priority control policies define conditions and events that must be maintained, they can be resource-intensive. The number of policies is limited to 1000.

The policy IDs do not have to be consecutive integers. The range of available policy identifiers is from 1 to 999.

The no form of the command deletes the specific policy ID from the system.

The policy ID must be removed first from all virtual router instances before the no policy command can be issued. If the policy ID is associated with a virtual router instance, the command fails.

This command sets a lower limit on the virtual router in-use priority that can be derived from the delta priority control events.

Each VRRP priority ID places limits on the delta priority control events to define the in-use priority of the virtual router instance. Setting this limit prevents the sum of the delta priority events from lowering the in-use priority value of the associated virtual router instances below the configured value.

The limit has no effect on explicit priority control events. Explicit priority control events are controlled by setting the in-use priority to any value between 1 and 254.

Only non-owner virtual router instances can be associated with VRRP priority control policies and their priority control events.

Once the total sum of all delta events is calculated and subtracted from the base priority of the virtual router instance, the result is compared to the delta-in-use-limit value. If the result is less than the limit, the delta-in-use-limit value is used as the virtual router in-use priority value. If an explicit priority control event overrides the delta priority control events, the delta-in-use-limit has no effect.

Setting the limit to a higher value than the default of 1 limits the effect of the delta priority control events on the virtual router instance base priority value. This allows for multiple priority control events while minimizing the overall effect on the in-use priority

Setting the limit to a value equal to or larger than the virtual router instance base priority prevents the delta priority control events from having any effect on the virtual router instance in-use priority value.

Changing the in-use priority limit causes an immediate re-evaluation of the in-use priority values for all virtual router instances associated with this VRRP policy ID based on the current sum of all active delta control policy events.

The no form of the command reverts to the default value.

This command associates a text string with a configuration context to help identify the content in the configuration file.

The no form of the command removes the string from the configuration.

This command creates the context to configure VRRP priority control events used to define criteria to modify the VRRP in-use priority.

A priority control event specifies an object to monitor and the effect on the in-use priority level for an associated virtual router instance.

Up to 32 priority control events can be configured.

The no form of this command clears any configured priority events.

This command creates the context to configure a host unreachable priority control event to monitor the ability to receive ICMP echo reply packets from an IP host address.

A host unreachable priority event creates a continuous ICMP echo request (ping) probe to the specified IP address. If a ping fails, the event is considered to be set. If a ping is successful, the event is considered to be cleared.

Up to 32 unique (different IP address) host unreachable events can be configured.

The host-unreachable command can reference any valid local or remote IP address. The ability to use ARP to find a local IP address or find a remote IP address within a route prefix in the route table is considered part of the monitoring procedure. The host unreachable priority event operational state tracks ARP or route table entries dynamically appearing and disappearing from the system. The operational state of the host unreachable event can be one of the following:

Unlike other priority event types, the host unreachable priority event monitors a repetitive task. A historical evaluation is performed on the success rate of receiving ICMP echo reply messages. The operational state takes the cleared and set orientation from the historical success rate. The informational portion of the operational state is derived from the result of the last attempt. It is possible for the previous attempt to fail while the operational state is still cleared due to an insufficient number of failures to cause it to become set. It is also possible for the state to be set while the previous attempt was successful.

When an event transitions from clear to set, the set is processed immediately and must be reflected in the associated virtual router instance in-use priority value. As the event transitions from clear to set, a hold-set timer is started with the value configured by the event’s hold-set command. This timer prevents the event from clearing until it expires, damping the effect of event flapping. If the event clears and becomes set again before the hold-set timer expires, the timer is reset to the hold-set value, extending the time before another clear can take effect.

The hold-set timer must expire and the historical success rate must be met prior to the event operational state becoming cleared.

The no form of the command deletes the specific IP host monitoring event. The event can be deleted at any time. When the event is deleted, the in-use priority of all associated virtual router instances must be re-evaluated. The event hold-set timer has no effect on the removal procedure.

This command configures a port down priority control event that monitors the operationally state of a port. When the port enters the operational down state, the event is considered set. When the port enters the operationally up state, the event is considered cleared.

Up to 32 unique port-down events can be defined in any combination of types.

The port-down command can be use on ports even if they are not preprovisioned or populated. The operational state of the port-down event indicates:

When the port is provisioned, populated, or enters the operationally up or down state, the event operational state is updated appropriately.

When the event enters the operationally down, non-provisioned, or non-populated state, the event is considered to be set. When an event transitions from clear to set, the set is processed immediately and must be reflected in the associated virtual router instance in-use priority value. As the event transitions from cleared to set, the hold-set timer is started. This timer prevents the event from clearing until it expires, damping the effect of event flapping. If the event clears and becomes set again before the hold-set timer expires, the timer is reset to the hold-set value, extending the time before another clear can take effect.

When the event enters the operationally up state, the event is considered to be cleared. Once the event hold set expires, the effects of the event priority value are immediately removed from the in-use priority of all associated virtual router instances.

The actual effect on the virtual router instance in-use priority value depends on the defined event priority and its delta or explicit nature.

The no form of the command deletes the specific port monitoring event. The event can be removed at any time. If the event is removed, the in-use priority of all associated virtual router instances is re-evaluated. The event’s hold-set timer has no effect on the removal procedure.

This command creates a context to configure a route unknown priority control event that monitors the existence of a specific active IP route prefix within the routing table.

The route-unknown command configures a priority control event that defines a link between the VRRP priority control policy and the RTM. The RTM registers the specified route prefix as monitored by the policy. If any change (add, delete, new next hop) occurs relative to the prefix, the policy is notified and takes proper action according to the priority event definition. If the route prefix exists and is active in the routing table according to the conditions defined, the event is in the cleared state. If the route prefix is removed, becomes inactive, or fails to meet the event criteria, the event is in the set state.

Up to 32 route-unknown events can be configured.

The route-unknown command can reference any valid IP address mask-length pair. The IP address and associated mask length define a unique IP router prefix. The dynamic monitoring of the route prefix results in one of the following event operational states:

An existing route prefix in the RTM must be active (used by the IP forwarding engine) to clear the event operational state. It can be less specific (the defined prefix can be contained in a larger prefix according to CIDR techniques) if the event has the less-specific statement defined. The less-specific route that incorporates the router prefix can be the default route (0.0.0.0) if the less-specific allow-default statement is defined. The matching prefix can be required to have a specific next-hop IP address if defined by the event next-hop command. Finally, the source of the RTM prefix can be required to be one of the dynamic routing protocols or be statically defined if defined by the event protocol command. If an RTM prefix is not found that matches all the above criteria (if defined in the event control commands), the event is considered to be set. If a matching prefix is found in the RTM, the event is considered to be cleared.

If an event transitions from clear to set, the set is processed immediately and must be reflected in the associated virtual router instance in-use priority value. As the event transitions from clear to set, the hold-set timer is started. This timer prevents the event from clearing until it expires, damping the effect of event flapping. If the event clears and becomes set again before the hold-set timer expires, the timer is reset to the hold-set value, extending the time before another clear can take effect.

The no form of the command is used to remove the specific ip-prefix/mask monitoring event. The event can be removed at any time. When the event is removed, the in-use priority of all associated virtual router instances must be re-evaluated. The event hold-set timer has no effect on the removal procedure.

This command configures the hold-clear time for the event. The hold-clear time is used to prevent black hole conditions if a virtual router instance advertises itself as a master before other conditions associated with the cleared event have had a chance to enter a forwarding state.

This command specifies the amount of time that must pass before the set state for a VRRP priority control event can transition to the cleared state to dampen flapping events. A flapping event continually transitions between clear and set.

The hold-set command dampens the effect of a flapping event. 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 a countdown to 0. When the timer reaches 0, the event is allowed to enter the cleared state. Entering the cleared state is 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.

Once the hold-set timer expires and the event meets the cleared state requirements or is set to a lower threshold, the current set effect on the in-use priority of the virtual router instance can be removed.

The no form of the command reverts to the default value of 0 and the hold-set timer is disabled so that event transitions are processed immediately.

This command controls the effect the set event has on the virtual router instance in-use priority.

When the event is set, the priority level is either subtracted from the base priority of each virtual router instance or it defines the explicit in-use priority value of the virtual router instance depending on whether the delta or explicit keyword is specified.

Multiple set events in the same policy have interaction constraints:

If the priority command is not configured on the priority event, the priority value defaults to 0 and the qualifier keyword defaults to delta with no impact on the in-use priority.

The no form of this command reverts to the default values.

This command configures the number of consecutively sent ICMP echo request messages that must fail before the host unreachable priority control event is set.

The drop-count command is used to define the number of consecutive message send attempts that must fail for the host unreachable priority event to enter the set state. Each unsuccessful attempt increments the event consecutive message drop counter. With each successful attempt, the event consecutive message drop counter resets to 0.

If the event consecutive message drop counter reaches the drop-count value, the host unreachable priority event enters the set state.

The event hold-set value defines how long the event must stay in the set state even when a successful message attempt clears the consecutive drop counter. The event is not cleared until the consecutive drop counter is less than the drop-count value and the hold-set timer has a value of 0 (expired).

The no form of the command reverts to the default value of 3. Three consecutive ICMP echo request failures are required before the host unreachable priority control event is set.

This command configures the number of seconds between host unreachable priority event ICMP echo request messages directed to the host IP address.

The no form of this command reverts to the default value.

This command defines the time, in seconds, that must pass before considering the far-end IP host unresponsive to an outstanding ICMP echo request message.

The timeout value is not directly related to the configured interval parameter. The timeout value can be larger, equal, or smaller, relative to the interval value. If the timeout value is larger than the interval value, multiple ICMP echo request messages can be outstanding. Every ICMP echo request message transmitted to the far-end host is tracked individually according to the message identifier and sequence number.

With each consecutive attempt to send an ICMP echo request message, the timeout timer is started. The timer decrements until:

Note: A required ARP request can succeed or time out after the message timeout timer expires. In this case, the message request is unsuccessful.

If an ICMP echo reply message is not received prior to the timeout period for a given ICMP echo request, that request is considered to be dropped and the consecutive message drop counter is incremented for the priority event.

If an ICMP echo reply message with the same sequence number as an outstanding ICMP echo request message is received prior to that message timing out, the request is considered successful. The consecutive message drop counter is cleared and the request message no longer is outstanding.

If an ICMP echo reply message with a sequence number equal to an ICMP echo request sequence number that had previously timed out is received, that reply is silently discarded while incrementing the priority event reply discard counter.

The no form of the command reverts to the default value.

This command allows a CIDR shortest-match hit on a route prefix that contains the IP route prefix associated with the route unknown priority event.

The less-specific command modifies the search parameters for the IP route prefix specified in the route-unknown priority event. Using this command allows a CIDR shortest-match hit on a route prefix that contains the IP route prefix.

The less-specific command makes the RTM lookup criteria less restrictive when searching for the ip-prefix/mask. When the route-unknown priority event sends the prefix to the RTM (as if it was a destination lookup), the matching prefix (if a result is found) is checked to see if it is an exact match or a less-specific match. The less-specific command enables a less-specific route table prefix to match the configured prefix. If less-specific is not specified, a less-specific route table prefix fails to match the configured prefix. The allow-default optional keyword extends the less-specific match to include the default route (0.0.0.0).

The no form of the command prevents RTM lookup results that are less specific than the route prefix from matching.

The default value specifies that the route unknown priority event requires an exact ip-prefix/mask match.

This command adds an allowed next-hop IP address to match the IP route prefix for a route-unknown priority control event.

If the next-hop IP address does not match one of the defined IP addresses, the match is considered unsuccessful and the route-unknown event transitions to the set state.

The next-hop command is optional. If no next-hop IP address commands are configured, the comparison between the RTM prefix return and the route-unknown IP route prefix are not included in the next-hop information.

If more than one next-hop IP address is eligible for matching, a next-hop command must be executed for each IP address. Defining the same IP address multiple times has no effect after the first instance.

The no form of the command removes the IP address from the list of acceptable next hops when looking up the route-unknown prefix. If this IP address is the last next hop defined on the route-unknown event, the returned next-hop information is ignored when testing the match criteria. If the IP address does not exist, the no next-hop command returns a warning message, but continues to execute if part of the exec script.

The default value specifies that no next-hop IP address for the route-unknown priority control event is defined.

This command adds one or more route sources to match the route unknown IP route prefix for a route unknown priority control event.

If the route source does not match one of the defined protocols, the match is considered unsuccessful and the route-unknown event transitions to the set state.

The protocol command is optional. If the protocol command is not executed, the comparison between the RTM prefix return and the route-unknown IP route prefix does not include the source of the prefix. The protocol command cannot be executed without at least one associated route source keyword. All keywords are reset each time the command is executed, and only the explicitly defined protocols are allowed to match.

The no form of the command removes protocol route source as a match criteria for returned RTM route prefixes.

To remove specific existing route source match criteria, execute the protocol command and include only the specific route source criteria. Any unspecified route source criteria is removed.