VRRP Configuration Command Reference

This command sets the simple text authentication key used to generate master VRRP advertisement messages and validates VRRP advertisements.

If simple text password authentication is not required, the authentication-key command is not required.

The command is configurable in both non-owner and owner vrrp nodal contexts.

The key parameter identifies the simple text password to be used when VRRP Authentication Type 1 is enabled on the virtual router instance. Type 1 uses an eight octet long string that is inserted into all transmitted VRRP advertisement messages and is compared against all received VRRP advertisement messages. The authentication data fields are used to transmit the key.

The key string is case sensitive and is left justified in the VRRP advertisement message authentication data fields. The first field contains the first four characters with the first octet (starting with IETF RFC bit position 0) containing the first character. The second field similarly holds the fifth through eighth characters. Any unspecified portion of the authentication data field is padded with a 0 value in the corresponding octet.

If the command is re-executed with a different password key defined, the new key is used immediately.

The authentication-key command can be executed at anytime.

To change the current in-use password key on multiple virtual router instances:

Identify the current master.

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

This command associates router IP addresses with the parental IP interface IP addresses.

The backup command has two distinct functions when used in an owner or a non-owner context of the virtual router instance.

Non-owner virtual router instances actually create a routable IP interface address that is operationally dependent on the virtual router instance mode (master or backup). The backup command in owner virtual router instances does not create a routable IP interface address; it simply defines the existing parental IP interface IP addresses that are advertised by the virtual router instance.

For owner virtual router instances, the backup command defines the IP addresses that are advertised within VRRP advertisement messages. This communicates the IP addresses that the master is representing to backup virtual routers receiving the messages. Advertising a correct list is important. The specified ip-addr must be equal to one of the existing parental IP interface IP addresses (primary or secondary) or the backup command will fail.

For non-owner virtual router instances, the backup command actually creates an IP interface IP address used for routing IP packets and communicating with the system when the access commands are defined (ping-reply, telnet-reply, and ssh-reply). The specified ip-addr must be an IP address that is within one of the parental IP interface local subnets created with the address or secondary commands. If a local subnet does not exist that includes the specified ip-addr or if ip-addr is the same IP address as the parental IP interface IP address, the backup command will fail.

The new interface IP address created with the backup command assumes the mask and parameters of the corresponding parent IP interface IP address. The ip-addr is only active when the virtual router instance is operating in the master state. When not operating as master, the virtual router instance acts as if it is operationally down. It will not respond to ARP requests to ip-addr, nor will it route packets received with its vrid derived source MAC address. A non-master virtual router instance always silently discards packets destined to ip-addr. A single virtual router instance may only have a single virtual router IP address from a given parental local subnet. Multiple virtual router instances can define a virtual router IP address from the same local subnet as long as each is a different IP address.

In IPv4, up to sixteen backup ip-addr commands can be executed within the same virtual router instance. Executing backup multiple times with the same ip-addr results in no operation performed and no error generated. At least one successful backup ip-addr command must be executed before the virtual router instance can enter the operational state.

When operating as (non-owner) master, the default functionality associated with ip-addr is ARP response to ARP requests to ip-addr, routing of packets destined to the virtual router instance source MAC address and silently discarding packets destined to ip-addr. Enabling the non-owner-access parameters selectively allows ping, Telnet and SSH connectivity to ip-addr when the virtual router instance is operating as master.

The no form of the command removes the specified virtual router IP address from the virtual router instance. For non-owner virtual router instances, this causes all routing and local access associated with the ip-addr to cease. For owner virtual router instances, the no backup command only removes ip-addr from the list of advertised IP addresses. If the last ip-addr is removed from the virtual router instance, the virtual router instance will enter the operationally down state

This command associates router IPv6 addresses with the parental IP interface IP addresses.

The backup command has two distinct functions when used in an owner or a non-owner context of the virtual router instance.

Non-owner virtual router instances actually create a routable IP interface address that is operationally dependent on the virtual router instance mode (master or backup). The backup command in owner virtual router instances does not create a routable IP interface address; it simply defines the existing parental IP interface IP addresses that are advertised by the virtual router instance.

For owner virtual router instances, the backup command defines the IP addresses that are advertised within VRRP advertisement messages. This communicates the IP addresses that the master is representing to backup virtual routers receiving the messages. Advertising a correct list is important. The specified ipv6-addr must be equal to one of the existing parental IP interface IP addresses (link-local or global) or the backup command will fail.

For non-owner virtual router instances, the backup command actually creates an IP interface IP address used for routing IP packets and communicating with the system when the access commands are defined (ping-reply, telnet-reply, and ssh-reply). The specified ipv6-addr must be an IP address that is within one of the parental IP interface local subnets created with the link-local-address or address commands. If a local subnet does not exist that includes the specified ipv6-addr or if ipv6-addr is the same IP address as the parental IP interface IP address, the backup command will fail.

The new interface IP address created with the backup command assumes the mask and parameters of the corresponding parent IP interface IP address. The ipv6-addr is only active when the virtual router instance is operating in the master state. For IPv6 VRRP, the parental interface's IP address that is in the same subnet as the backup address must be manually-configured, non EUI-64 and configured to be in the preferred state.

When not operating as master, the virtual router instance acts as if it is operationally down. It will not respond to ARP requests to ipv6-addr, nor will it route packets received with its vrid derived source MAC address. A non-master virtual router instance always silently discards packets destined to ipv6-addr. A single virtual router instance may only have a single virtual router IP address from a given parental local subnet. Multiple virtual router instances can define a virtual router IP address from the same local subnet as long as each is a different IP address.

Executing backup multiple times with the same ipv6-addr results in no operation performed and no error generated. At least one successful backup ipv6-addr command must be executed before the virtual router instance can enter the operational state.

When operating as (non-owner) master, the default functionality associated with ipv6-addr is ARP response to ARP requests to ip-addr, routing of packets destined to the virtual router instance source MAC address and silently discarding packets destined to ipv6-addr. An IPv6 virtual router instance can enter the operational state only if one of the configured backup address is a link-local address and the router advertisement of the interface is configured to use the virtual MAC address. Enabling the non-owner-access parameters selectively allows ping, Telnet and traceroute connectivity to ipv6-addr when the virtual router instance is operating as master.

The no form of the command removes the specified virtual router IP address from the virtual router instance. For non-owner virtual router instances, this causes all routing and local access associated with the ipv6-addr to cease. For owner virtual router instances, the no backup command only removes ipv6-addr from the list of advertised IP addresses. If the last ipv6-addr or the link-local address is removed from the virtual router instance, the virtual router instance will enter the operationally down state

This commands assigns a bi-directional forwarding detect (BFD) session to a given VRRP/SRRP instance. This BFD sessions provided a heartbeat mechanism that can be used to speed up the transition of the standby VRRP router to an active state. If the associated BFD session fails, the VRRP routers will immediately send a VRRP Advertisement message. In addition, the standby VRRP router(s) will transition to a Master state to speed convergence. The normal VRRP election process will then take place based on the Advertisement messages sent by all VRRP routers.

There can be only one BFD session assigned to any given VRRP/SRRP instance, but there can be multiple SRRP/VRRP sessions using the same BFD session.

The parameters used for the BFD sessions are set by the BFD command under the IP interface.

The no form of this command removes BFD from the configuration.

This command configures a VRRP initialization delay timer.

This command sets an explicit MAC address used by the virtual router instance overriding the VRRP default derived from the VRID.

Changing the default MAC address is useful when an existing HSRP or other non-VRRP default MAC is in use by the IP hosts using the virtual router IP address. Many hosts do not monitor unessential ARPs and continue to use the cached non-VRRP MAC address after the virtual router becomes master of the host’s gateway address.

The mac command sets the MAC address used in ARP responses when the virtual router instance is master. Routing of IP packets with mac-address as the destination MAC is also enabled. The mac setting must be the same for all virtual routers participating as a virtual router or indeterminate connectivity by the attached IP hosts will result. All VRRP advertisement messages are transmitted with mac-address as the source MAC.

The command can be configured in both non-owner and owner vrrp nodal contexts.

The mac command can be executed at any time and takes effect immediately. When the virtual router MAC on a master virtual router instance changes, a gratuitous ARP is immediately sent with a VRRP advertisement message. If the virtual router instance is disabled or operating as backup, the gratuitous ARP and VRRP advertisement message is not sent.

The no form of the command restores the default VRRP MAC address to the virtual router instance.

This command enables the virtual router instance to inherit the master VRRP router’s advertisement interval timer which is used by backup routers to calculate the master down timer.

The master-int-inherit command is only available in the non-owner nodal context and is used to allow the current virtual router instance master to dictate the master down timer for all backup virtual routers. The master-int-inherit command has no effect when the virtual router instance is operating as master.

If master-int-inherit is not enabled, the locally configured message-interval must match the master’s VRRP advertisement message advertisement interval field value or the message is discarded.

The no form of the command restores the default operating condition which requires the locally configured message-interval to match the received VRRP advertisement message advertisement interval field value.

This command configures the administrative advertisement message timer used by the master virtual router instance to send VRRP advertisement messages and to derive the master down timer as backup.

For an owner virtual router instance, the administrative advertisement timer directly sets the operational advertisement timer and indirectly sets the master down timer for the virtual router instance.

Non-owner virtual router instances usage of the message-interval setting is dependent on the state of the virtual router (master or backup) and the state of the master-int-inherit parameter.

VRRP advertisements messages that are fragmented, or contain IP options (IPv4), or contain extension headers (IPv6) require a longer message interval to be configured.

The in-use value of the message interval is used to derive the master down timer to be used when the virtual router is operating in backup mode based on the following formula:

(3x (in-use message interval) + skew time)

The skew time portion is used to slow down virtual routers with relatively low priority values when competing in the master election process.

The command is available in both non-owner and owner vrrp nodal contexts.

By default, a message-interval of 1 second is used.

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

This command adds a VRRP priority control policy association with the virtual router instance.

To further augment the virtual router instance base priority, VRRP priority control policies can be used to override or adjust the base priority value depending on events or conditions within the chassis.

The policy can be associated with more than one virtual router instance. The priority events within the policy either override or diminish the base priority set with the priority command dynamically affecting the in-use priority. As priority events clear in the policy, the in-use priority can eventually be restored to the base priority value.

The policy command is only available in the non-owner vrrp nodal context. The priority of owner virtual router instances is permanently set to 255 and cannot be changed by VRRP priority control policies. For non-owner virtual router instances, if the policy command is not executed, the base priority is used as the in-use priority.

The no form of the command removes existing VRRP priority control policy associations from the virtual router instance. All associations must be removed prior to deleting the policy from the system.

The preempt mode value controls whether a specific backup virtual router preempts a lower priority master.

When preempt is enabled, the virtual router instance overrides any non-owner master with an "in use" message priority value less than the virtual router instance in-use priority value. If preempt is disabled, the virtual router only becomes master if the master down timer expires before a VRRP advertisement message is received from another virtual router.

The IP address owner will always become master when available. Preempt mode cannot be disabled on the owner virtual router.

The default value for preempt mode is enabled.

This command configures the base router priority for the virtual router instance used in the master election process.

The priority is the most important parameter set on a non-owner virtual router instance. The priority defines a virtual router’s selection order in the master election process. Together, the priority value and the preempt mode allow the virtual router with the best priority to become the master virtual router.

The base-priority is used to derive the in-use priority of the virtual router instance as modified by any optional VRRP priority control policy. VRRP priority control policies can be used to either override or adjust the base priority value depending on events or conditions within the chassis.

The priority command is only available in the non-owner vrrp nodal context. The priority of owner virtual router instances is permanently set to 255 and cannot be changed.

For non-owner virtual router instances, the default base priority value is 100.

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

This command enables the non-owner master to reply to ICMP echo requests directed at the virtual router instances IP addresses.

Non-owner virtual router instances are limited by the VRRP specifications to responding to ARP requests destined to the virtual router IP addresses and routing IP packets not addressed to the virtual router IP addresses. Many network administrators find this limitation frustrating when troubleshooting VRRP connectivity issues.

The SR OS allows this access limitation to be selectively lifted for certain applications. Ping, Telnet and SSH can be individually enabled or disabled on a per-virtual-router-instance basis.

The ping-reply command enables the non-owner master to reply to ICMP echo requests directed at the virtual router instances IP addresses. The Ping request can be received on any routed interface. Ping must not have been disabled at the management security level (either on the parental IP interface or based on the Ping source host address).

When ping-reply is not enabled, ICMP echo requests to non-owner master virtual IP addresses are silently discarded.

Non-owner backup virtual routers never respond to ICMP echo requests regardless of the ping-reply setting.

The ping-reply command is only available in non-owner vrrp nodal context.

By default, ICMP echo requests to the virtual router instance IP addresses are silently discarded.

The no form of the command configures discarding all ICMP echo request messages destined to the non-owner virtual router instance IP addresses.

This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.

The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

The no form of this command administratively enables an entity.

This command enables the non-owner master to reply to SSH requests directed at the virtual router instance IP addresses. This command is only applicable to IPv4.

Non-owner virtual router instances are limited by the VRRP specifications to responding to ARP requests destined to the virtual router IP addresses and routing IP packets not addressed to the virtual router IP addresses.

This limitation can be disregarded for certain applications. Ping, Telnet and SSH can be individually enabled or disabled on a per-virtual-router-instance basis.

The ssh-reply command enables the non-owner master to reply to SSH requests directed at the virtual router instances IP addresses. The SSH request can be received on any routed interface. SSH must not have been disabled at the management security level (either on the parental IP interface or based on the SSH source host address). Proper login and CLI command authentication is still enforced.

When ssh-reply is not enabled, SSH requests to non-owner master virtual IP addresses are silently discarded.

Non-owner backup virtual routers never respond to SSH requests regardless of the ssh-reply setting.

The ssh-reply command is only available in non-owner vrrp nodal context.

By default, SSH requests to the virtual router instance IP addresses are silently discarded.

The no form of the command discards all SSH request messages destined to the non-owner virtual router instance IP addresses.

This command specifies whether this VRRP instance allows forwarding packets to a standby router. When disabled, a standby router should not forward traffic sent to virtual router's MAC address. However, the standby router should forward traffic sent to the standby router’s real MAC address. When enabled, a standby router should forward all traffic.

This command enables the non-owner master to reply to TCP port 23 Telnet requests directed at the virtual router instances’ IP addresses.

Non-owner virtual router instances are limited by the VRRP specifications to responding to ARP requests destined to the virtual router IP addresses and routing IP packets not addressed to the virtual router IP addresses. Many network administrators find this limitation frustrating when troubleshooting VRRP connectivity issues.

This limitation can be disregarded for certain applications. Ping, SSH and Telnet can each be individually enabled or disabled on a per-virtual-router-instance basis.

The telnet-reply command enables the non-owner master to reply to Telnet requests directed at the virtual router instances’ IP addresses. The Telnet request can be received on any routed interface. Telnet must not have been disabled at the management security level (either on the parental IP interface or based on the Telnet source host address). Proper login and CLI command authentication is still enforced.

When telnet-reply is not enabled, Telnet requests to non-owner master virtual IP addresses are silently discarded.

Non-owner backup virtual routers never respond to Telnet requests regardless of the telnet-reply setting.

The telnet-reply command is only available in non-owner vrrp nodal context.

By default, Telnet requests to the virtual router instance IP addresses will be silently discarded.

The no form of the command configures discarding all Telnet request messages destined to the non-owner virtual router instance IP addresses.

This command is valid only if the VRRP virtual router instance associated with this entry is a non-owner.

When this command is enabled, a non-owner master can reply to traceroute requests directed to the virtual router instance IP addresses.

A non-owner backup virtual router never responds to such traceroute requests regardless of the trace-route-reply status.

This command creates the context to configure a VRRP virtual router instance. A virtual router is defined by its virtual router identifier (VRID) and a set of IP addresses.

The optional owner keyword indicates that the owner controls the IP address of the virtual router and is responsible for forwarding packets sent to this IP address. The owner assumes the role of the master virtual router.

All other virtual router instances participating in this message domain must have the same vrid configured and cannot be configured as owner. Once created, the owner keyword is optional when entering the vrid for configuration purposes.

A vrid is internally associated with the IP interface. This allows the vrid to be used on multiple IP interfaces while representing different virtual router instances.

For IPv4, up to four VRRP VRID nodes can be configured on a router interface. Each virtual router instance can manage up to 16 backup IP addresses. For IPv6, only one VRID can be configured on a router interface.

The optional passive keyword indicates that a vrid can be configured as passive, in which case, the VRRP advertisement messages are suppressed on transmission and reception, and all routers configured with the same vrid become master. Passive VRIDs can exceed the limit of four VRRP VRID nodes on a router interface.

The no form of the command removes the specified vrid from the IP interface. This terminates VRRP participation and deletes all references to the vrid in conjunction with the IP interface. The vrid does not need to be shut down to remove the virtual router instance.

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.

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 creates a text description stored in the configuration file for a configuration context.

The description 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 a VRRP priority control policy which is used to control the VRRP in-use priority based on priority control events. It is a parental node for the various VRRP priority control policy commands that define the 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 or diminish the base priority setting to establish the actual in-use priority of the virtual router instance.

The policy policy-id 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-id do not have to be consecutive integers. The range of available policy identifiers is from 1 to 9999.

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 will fail.

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 within the priority-event node.

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

This command configures the hold clear time for the event. The seconds parameter specifies the hold-clear time, the amount of time in seconds by which the effect of a cleared event on the associated virtual router instance is delayed.

The hold-clear time is used to prevent black hole conditions when 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 event can transition to the cleared state to dampen flapping events. A flapping event continually transitions between clear and set.

The hold-set command is used to dampen the effect of a flapping event. The hold-set value is loaded into a hold set timer that prevents a set event from transitioning to the cleared state until it expires.

Each time an event transitions between cleared and set, the timer is loaded and begins a countdown to zero. When the timer reaches zero, 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 reload 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 virtual router instances in-use priority can be removed. As with lag-port-down events, this may be a decrease in the set effect if the clearing amounts to a lower set threshold.

The hold-set command can be executed at anytime. If the hold-set timer value is configured larger than the new seconds setting, the timer is loaded with the new hold-set value.

The no form of the command reverts the default value.

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 keywords are 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, thus, there is no impact on the in-use priority.

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

This command creates a context to configure an event set threshold within a lag-port-down priority control event. The weight-down command defines a sub-node within the lag-port-down event and is uniquely identified with the lag-ports-down-weight parameter. Each weight-down node within the same lag-port-down event node must have a unique lag-ports-down-weight value. Each weight-down node has its own priority command that takes effect whenever that node represents the current threshold. A single LAG can use either weight-threshold or port threshold. The command is required for proper operation on mixed port-speed LAGs and can be used for non-mixed port-speed LAGs as well.

The total number of sub-nodes (uniquely identified by the lag-ports-down-weight parameter) allowed in the system is 2048.

A weight-down node is not required for each possible number of ports that could be down. The active threshold is always the closest lower threshold.

The no form of the command deletes the event set threshold. The threshold may be removed at any time. If the removed threshold is the current active threshold, the event set thresholds must be re-evaluated after removal.

This command configures an instance of a multi-chassis IPsec tunnel-group Priority Event used to override the base priority value of a VRRP virtual router instance depending on the operational state of the event.

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

Multiple unique port-down event nodes can be configured within the priority-event context up to the overall limit of 32 events. Up to 32 events can be defined in any combination of types.

The port-down command can reference an arbitrary port or channel. The port or channel does not need to be preprovisioned or populated within the system. The operational state of the port-down event is set as follows:

When the port or channel 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 instances in-use priority value. As the event transitions from cleared to set, a hold set timer is loaded with the value configured by the events 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.

When the event enters the operationally up state, the event is considered to be cleared. Once the events hold-set expires, the effects of the events 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 or channel monitoring event. The event may be removed at anytime. When the event is removed, the in-use priority of all associated virtual router instances will be re-evaluated. The events hold-set timer has no effect on the removal procedure.

This command creates the context to configure Link Aggregation Group (LAG) priority control events that monitor the operational state of the links in the LAG.

The lag-port-down command configures a priority control event. 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.

Multiple unique lag-port-down event nodes can be configured within the priority-event node up to the maximum of 32 events.

The lag-port-down command can reference an arbitrary LAG. The lag-id does have to already exist within the system. The operational state of the lag-port-down event will indicate:

When the lag-id is created, or a port in lag-id becomes operationally up or down, the event operational state must be updated appropriately.

When one or more of the LAG composite ports enters the operationally down state or the lag-id is deleted or does not exist, 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 instances in-use priority value. As the event transitions from clear to set, a hold set timer is loaded with the value configured by the events 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 lag-port-down event is considered to have a tiered event set state. While the priority impact per number of ports down is totally configurable, as more ports go down, the effect on the associated virtual router instances in-use priority is expected to increase (lowering the priority). When each configured threshold is crossed, any higher thresholds are considered further event sets and are processed immediately with the hold set timer reset to the configured value of the hold-set command. As the thresholds are crossed in the opposite direction (fewer ports down then previously), the priority effect of the event is not processed until the hold set timer expires. If the number of ports down threshold again increases before the hold set timer expires, the timer is only reset to the hold-set value if the number of ports down is equal to or greater than the threshold that set the timer.

The event contains number-down nodes that define the priority delta or explicit value to be used based on the number of LAG composite ports that are in the operationally down state. These nodes represent the event set thresholds. Not all port down thresholds must be configured. As the number of down ports increase, the number-down ports-down node that expresses a value equal to or less than the number of down ports describes the delta or explicit priority value to be applied.

The no form of the command deletes the specific LAG monitoring event. The event can be removed at anytime. When the event is removed, the in-use priority of all associated virtual router instances must be reevaluated. The events hold-set timer has no effect on the removal procedure.

This command creates a context to configure an event set threshold within a lag-port-down priority control event.

The number-down command defines a sub-node within the lag-port-down event and is uniquely identified with the number-of-lag-ports-down parameter. Each number-down node within the same lag-port-down event node must have a unique number-of-lag-ports-down value. Each number-down node has its own priority command that takes effect whenever that node represents the current threshold.

The total number of sub-nodes (uniquely identified by the number-of-lag-ports-down parameter) allowed in a single lag-port-down event is equal to the total number of possible physical ports allowed in a LAG.

A number-down node is not required for each possible number of ports that could be down. The active threshold is always the closest lower threshold. When the number of ports down equals a given threshold, that is the active threshold.

The no form of the command deletes the event set threshold. The threshold may be removed at any time. If the removed threshold is the current active threshold, the event set thresholds must be re-evaluated after removal.

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’s consecutive message drop counter. With each successful attempt, the event’s consecutive message drop counter resets to zero.

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

The event’s 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 zero (expired).

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

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.

Multiple unique (different ip-address) host-unreachable event nodes can be configured within the priority-event node to a maximum of 32 events.

The host-unreachable command can reference any valid local or remote IP address. The ability to ARP 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 are listed in Table 39.

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 its cleared and set orientation from the historical success rate. The informational portion of the operational state is derived from the last attempt’s result. 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 instances in-use priority value. As the event transitions from clear to set, a hold set timer is loaded with the value configured by the events 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 be expired 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 may be deleted at anytime. When the event is deleted, the in-use priority of all associated virtual router instances must be reevaluated. The event’s hold-set timer has no effect on the removal procedure.

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 the command reverts to the default value.

This command allows the operator to increase the size of IP packet by padding the PDU.

The no form of the command reverts to the default.

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 may 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 may 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 loaded with the timeout value. The timer decrements until:

It is possible for a required ARP request to succeed or timeout 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 increments the consecutive message drop counter 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. Specifying less-specific allows a CIDR shortest match hit on a route prefix that contains the IP route prefix.

The less-specific command eases the RTM lookup criteria when searching for the prefix/mask-length. When the route-unknown priority event sends the prefix to the RTM (as if it was a destination lookup), the result route table 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. When less-specific is not specified, a less specific route table prefix fails to match the configured prefix. The allow-default optional parameter 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.

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-address, 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.

When more than one next hop IP addresses are 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 error, but continues to execute if part of an exec script.

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 will not include the source of the prefix. The protocol command cannot be executed without at least one associated route source parameter. All parameters are reset each time the protocol 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.

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 Route Table Manager (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.

The command creates a route-unknown node identified by prefix/mask-length and containing event control commands.

Multiple unique (different prefix/mask-length) route-unknown event nodes can be configured within the priority-event node up to the maximum limit of 32 events.

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 event operational states listed in Table 40.

An existing route prefix in the RTM must be active (used by the IP forwarding engine) to clear the event operational state. It may be less specific (the defined prefix may be contained in a larger prefix according to Classless Inter-Domain Routing (CIDR) techniques) if the event has the less-specific statement defined. The less specific route that incorporates the router prefix may be the default route (0.0.0.0) if the less-specific allow-default statement is defined. The matching prefix may 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 may 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.

When an event transitions from clear to set, the set is processed immediately and must be reflected in the associated virtual router instances in-use priority value. As the event transitions from clear to set, a hold set timer is loaded with the value configured by the events 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 no form of the command is used to remove the specific prefix/mask-length monitoring event. The event can be removed at anytime. When the event is removed, the in-use priority of all associated virtual router instances must be reevaluated. The events hold-set timer has no effect on the removal procedure.