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.
The authentication-key command can be executed at anytime.
|
3.
|
Execute the authentication-key command on the master to change the password key.
|
|
4.
|
Execute the authentication-key command and no shutdown command on each backup.
|
The no form of the command reverts to the default value.
Specifies the key is entered in a more complex encrypted form. If the
hash2 parameter is not used, the less encrypted
hash form is assumed.
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
Once the vrid is created on the parent IP interface, IP addresses need to be assigned to the virtual router instance. If the
vrid was created with the keyword
owner, the virtual router instance IP addresses must have one or more of the parent IP interface defined IP addresses (primary and secondary). For non-owner virtual router instances, the virtual router IP addresses each must be within one of the parental IP interface IP address defined local subnets. For both
owner and non-owner virtual router instances, the virtual router IP addresses must be explicitly defined using the
backup ip-addr command.
When an IP address is assigned to an owner virtual router instance, it must be associated with one of the parental IP interface-assigned IP addresses. The virtual router IP address must be equal to the primary or one of the secondary IP addresses within the parental IP interface.
no backup — No virtual router IP address is assigned.
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
Once the vrid is created on the parent IP interface, IP addresses need to be assigned to the virtual router instance. If the
vrid was created with the keyword
owner, the virtual router instance IP addresses must have one or more of the parent IP interface defined IP addresses. For non-owner virtual router instances, the virtual router IP addresses each must be within one of the parental IP interface IP address defined local subnets. For both
owner and non-owner virtual router instances, the virtual router IP addresses must be explicitly defined using the
backup ipv6-addr command.
When an IP address is assigned to an owner virtual router instance, it must be associated with one of the parental IP interface-assigned IP addresses.
no backup — No virtual router IP address is assigned.
[no
] bfd-enable
[service-id] interface
interface-name dst-ip
ip-address
[no
] bfd-enable interface
interface-name dst-ip
ip-address
The no form of this command removes BFD from the configuration.
|
Values
|
service-id: 1 — 2147483647 svc-name: 64 characters maximum
|
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 mac command can be executed at any time and takes effect ediately. When the virtual router MAC on a master virtual router instance changes, a gratuitous ARP is ediately 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.
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.
no master-int-inherit — The virtual router instance does not inherit the master VRRP router’s advertisement interval timer and uses the locally configured message interval.
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.
|
•
|
When a non-owner is in the backup state with master-int-inherit disabled, the configured message-interval value is used to match the incoming VRRP advertisement message advertisement interval field. If the locally configured message interval does not match the advertisement interval field, the VRRP advertisement is discarded.
|
|
•
|
When a non-owner is in the backup state with master-int-inherit enabled, the configured message-interval is ignored. The master down timer is indirectly derived from the incoming VRRP advertisement message advertisement interval field value.
|
VRRP advertisements messages that are fragmented, contain IP options (IPv4), or contain extension headers (IPv6) require a longer message interval to be configured.
By default, a message-interval of 1 second is used.
The no form of the command reverts to the default value.
1 — Advertisement timer set to 1 second
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.
no policy — No VRRP priority control policy is associated with the virtual router instance.
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.
Enabling preempt mode improves the effectiveness of the base
priority and the VRRP priority control policy mechanisms on the virtual router instance. If the virtual router cannot preempt an existing non-owner master, the affect of the dynamic changing of the in-use priority is diminished.
The preempt command is only available in the non-owner
vrrp nodal context. The owner may not be preempted because the priority of non-owners can never be higher than the owner. The owner always preempts all other virtual routers when it is available.
Non-owner virtual router instances only preempt when preempt is set and the current master has an in-use message priority value less than the virtual router instances in-use priority.
The no form of the command disables preempt mode and prevents the non-owner virtual router instance from preempting another, less desirable virtual router.
preempt — The preempt mode enabled on the virtual router instance where it will preempt a VRRP master with a lower priority.
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.
The no form of the command reverts to the default value.
7750 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.
The ping-reply command is only available in non-owner
vrrp nodal context.
The no form of the command configures discarding all ICMP echo request messages destined to the non-owner virtual router instance IP addresses.
no ping-reply — ICMP echo requests to the virtual router instance IP addresses are discarded.
The no form of this command administratively enables an entity.
If the shutdown command is executed, no VRRP advertisement messages are generated and all received VRRP advertisement messages are silently discarded with no processing.
An owner virtual router context does not have a shutdown command. To administratively disable an owner virtual router instance, use the
shutdown command within the parent IP interface node which administratively downs the IP interface.
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.
The ssh-reply command is only available in non-owner
vrrp nodal context.
The no form of the command discards all SSH request messages destined to the non-owner virtual router instance IP addresses.
no ssh-reply — SSH requests to the virtual router instance IP addresses are discarded.
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.
The telnet-reply command is only available in non-owner
vrrp nodal context.
The no form of the command configures discarding all Telnet request messages destined to the non-owner virtual router instance IP addresses.
no telnet-reply — Telnet requests to the virtual router instance IP addresses are discarded.
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 virtual router ID can be configured 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 shutdown to remove the virtual router instance.
It is possible for the virtual router instance owner to be created prior to assigning the parent IP interface primary or secondary IP addresses. When this is the case, the virtual router instance is not associated with an IP address. The operational state of the virtual router instance is down.
By specifying the VRRP vrid as
owner, The following commands are no longer available:
|
•
|
vrrp priority — The virtual router instance owner is hard-coded with a priority value of 255 and cannot be changed.
|
|
•
|
vrrp master-int-inherit — Owner virtual router instances do not accept VRRP advertisement messages; the advertisement interval field is not evaluated and cannot be inherited.
|
|
•
|
ping-reply, telnet-reply and ssh-reply — The owner virtual router instance always allows Ping, Telnet and SSH if the management and security parameters are configured to accept them on the parent IP interface.
|
|
•
|
vrrp shutdown — The owner virtual router instance cannot be shutdown in the vrrp node. If this was allowed, VRRP messages would not be sent, but the parent IP interface address would continue to respond to ARPs and forward IP packets. Another virtual router instance may detect the missing master due to the termination of VRRP advertisement messages and become master. This would cause two routers responding to ARP requests for the same IP addresses. To shutdown the owner virtual router instance, use the shutdown command in the parent IP interface context. This will prevent VRRP participation, IP ARP reply and IP forwarding. To continue parent IP interface ARP reply and forwarding without VRRP participation, remove the vrrp vrid instance.
|
no vrrp — No VRRP virtual router instance is associated with the IP interface.
Identifies this virtual router instance as owning the virtual router IP addresses. If the owner keyword is not specified at the time of
vrid creation, the
vrrp backup commands must be specified to define the virtual router IP addresses. The
owner keyword is not required when entering the
vrid for editing purposes. Once created as
owner, a
vrid on an IP interface cannot have the
owner parameter removed. The
vrid must be deleted and than recreated without the
owner keyword to remove ownership.
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.
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.
Changing the in-use-priority-limit causes an ediate 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.
1 — The lower limit of 1 for the in-use priority, as modified, by delta priorty control events.
Setting the in-use-priority-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.
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.
policy policy-id [context service-id]
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.
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.
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-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.
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.
0 — The hold-set timer is disabled so event transitions are processed ediately.
priority priority-level [{delta
| explicit
}]
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.
|
•
|
If no set events have an explicit priority value, all the set events delta priority values are added and subtracted from the base priority value defined on each virtual router instance associated with the policy.
|
|
•
|
If the delta priorities sum exceeds the delta-in-use-limit parameter, then the delta-in-use-limit parameter is used as the value subtracted from the base priority value defined on each virtual router instance associated with the policy.
|
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.
0 delta — The set event will subtract 0 from the base priority (no effect).
When delta is specified, the
priority-level value is subtracted from the associated virtual router instance’s base priority when the event is set and no explicit events are set. The sum of the priority event
priority-level values on all set delta priority events are subtracted from the virtual router base priority
to derive the virtual router instance in-use priority value. If the
delta priority event is cleared, the
priority-level is no longer used in the in-use priority calculation.
When explicit is specified, the
priority-level value is used to override the base priority of the virtual router instance if the priority event is set and no other
explicit priority event is set with a lower
priority-level. The set
explicit priority value with the lowest
priority-level determines the actual in-use protocol value for all virtual router instances associated with the policy.
[no
] mc-ipsec-non-forwarding
tunnel-grp-id
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 pre-provisioned 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 up state, the event is considered to be cleared. Once the events hold-set expires, the effects of the events
priority value are ediately removed from the in-use priority of all associated virtual router instances.
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.
no port-down — No port down priority control events are defined.
The port-id can only be monitored by a single event in this policy. The port can be monitored by multiple VRRP priority control policies. A port and a specific channel on the port are considered to be separate entities. A port and a channel on the port can be monitored by separate events in the same policy.
|
Values
|
port-id slot/ mda/ port[. channel]
aps-id aps- group-id[. channel] aps keyword group-id 1 — 64 bundle-type-slot/mda.<bundle-num> bundle keyword type ima, ppp bundle-num 1 —256 ccag-id ccag- id. path-id[ cc-type] ccag keyword id 1 — 8 path-id a, b cc-type .sap-net, .net-sap
|
The POS channel on the port monitored by the VRRP priority control event. The port-id.channel-id can only be monitored by a single event in this policy. The channel can be monitored by multiple VRRP priority control policies. A port and a specific channel on the port are considered to be separate entities. A port and a channel on the port can be monitored by separate events in the same policy.
[no
] lag-port-down
lag-id
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 ediately 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 ediately 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.
The LAG ID that the specific event is to monitor expressed as a decimal integer. The lag-id can only be monitored by a single event in this policy. The LAG may be monitored by multiple VRRP priority control policies. A port within the LAG and the LAG ID itself are considered to be separate entities. A composite port may be monitored with the
port-down event while the
lag-id the port is in is monitored by a
lag-port-down event in the same policy.
[no
] number-down
number-of-lag-ports-down
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.
config>vrrp vrrp-policy-id>priority-event>host-unreachable
ip-addr
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.
3 — 3 consecutive ICMP echo request failures are required before the host unreachable priority control event is set.
[no
] host-unreachable
ip-address
[no
] host-unreachable
ipv6-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 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 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 ediately 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 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.
The IP address of the host for which the specific event will monitor connectivity. The ip-addr can only be monitored by a single event in this policy. The IP address can be monitored by multiple VRRP priority control policies. The IP address can be used in one or multiple
ping requests. Each VRRP priority control
host-unreachable and
ping destined to the same
ip-addr is uniquely identified on a per message basis. Each session originates a unique identifier value for the ICMP echo request messages it generates. This allows received ICMP echo reply messages to be directed to the appropriate sending application.
|
Values
|
ipv4-address : a.b.c.d ipv6-address : x:x:x:x:x:x:x:x[-interface] x: [0..FFFF]H interface: 32 chars maximum, mandatory for link local addresses
|
The no form of the command reverts to the default value.
The no form of the command reverts to the default.
config>vrrp vrrp-policy-id>priority-event>host-unreachable
ip-addr
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.
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.
The no form of the command reverts to the default value.
[no
] less-specific
[allow-default
]
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.
no less-specific — The route unknown priority events requires an exact prefix/mask match.
When the allow-default parameter is specified with the
less-specific command, an RTM return of 0.0.0.0 matches the IP prefix. If
less-specific is entered without the
allow-default parameter, a return of 0.0.0.0 will not match the IP prefix. To disable
allow-default, but continue to allow
less-specific match operation, only enter the
less-specific command (without the
allow-default parameter).
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.
no next-hop — No next hop IP address for the route unknown priority control event is defined.
|
Values
|
ipv4-address : a.b.c.d ipv6-address : x:x:x:x:x:x:x:x[-interface] x: [0..FFFF]H interface: 32 chars maximum, mandatory for link local addresses
|
protocol {bgp
| bgp-vpn | ospf
| is-is
| rip
| static
}
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.
no protocol — No route source for the route unknown priority event is defined.
This parameter defines bgp-vpn as an eligible route source for a returned route prefix from the RTM when looking up the
route-unknown route prefix. The
bgp-vpn parameter is not exclusive from the other available
protocol parameters. If
protocol is executed without the
bgp-vpn parameter, a returned route prefix with a source of
bgp-vpn will not be considered a match and will cause the event to enter the set state.
[no
] route-unknown
prefix/
mask-length
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 addres 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 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 ediately 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.
no route-unknown — No route unknown priority control events are defined for the priority control event policy.
The IP address of the host for which the specific event will monitor connectivity. The ip-addr can only be monitored by a single event in this policy. The IP address can be monitored by multiple VRRP priority control policies. The IP address can be used in one or multiple
ping requests. Each VRRP priority control
host-unreachable and
ping destined to the same
ip-addr is uniquely identified on a per message basis. Each session originates a unique identifier value for the ICMP echo request messages it generates. This allows received ICMP echo reply messages to be directed to the appropriate sending application.
|
Values
|
ip-prefix/mask: ip-prefix a.b.c.d (host bits must be 0) mask 0 — 32 ipv6-address/ prefix: ipv6-address x:x:x:x:x:x:x:x (eight 16-bit pieces) x:x:x:x:x:x:d.d.d.d x: [0..FFFF]H prefix-length 1 — 128
|
