VRRP
This chapter provides information about configuring Virtual Router Redundancy Protocol (VRRP) parameters.
VRRP overview
VRRP for IPv4 is supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.
VRRP for IPv6 is supported only for VPRN interfaces on 7210 SAS-Mxp.
VRRP for IPv6 does not support authentication. See IETF RFC 5798 for more information.
VRRP describes a method of implementing a redundant IP interface shared between two or more routers on a common LAN segment, allowing a group of routers to function as one virtual router. When this IP interface is specified as a default gateway on hosts directly attached to this LAN, the routers sharing the IP interface prevent a single point of failure by limiting access to this gateway address. VRRP can be implemented on IES service interfaces, VPRN interfaces, and on core network IP interfaces.
The VRRP standards RFC 3768 use the term ‟master” state to denote the virtual router that is currently acting as the active forwarding router for the VRRP instance.
If the virtual router in the master state fails, the backup router configured with the highest acceptable priority becomes the active virtual router. The new active router assumes the normal packet forwarding for the local hosts.
The following figure shows an example of a VRRP configuration.
VRRP components
VRRP consists of the following components.
Virtual router
A virtual router is a logical entity managed by VRRP that acts as a default router for hosts on a shared LAN. It consists of a Virtual Router Identifier (VRID) and a set of associated IP addresses (or an address) across a common LAN. A VRRP router can backup one or more virtual routers.
The purpose of supporting multiple IP addresses within a single virtual router is for multi-netting. This is a common mechanism that allows multiple local subnet attachment on a single routing interface. Up to four virtual routers are possible on a single IP interface. The virtual routers must be in the same subnet. Each virtual router has its own VRID, state machine, and messaging instance.
IP address owner
VRRP can be configured in either the owner or non-owner mode. The owner is the VRRP router whose virtual router IP address is the same as the real interface IP address. The VRRP router configured as the owner responds to packets that are addressed to one of the IP addresses for ICMP pings, TCP connections, and others. Other virtual router instances participating in this message domain must have the same VRID configuration and cannot be configured as owner.
The 7210 SAS allows the virtual routers to be configured as non-owners of the IP address. VRRP on a router can be configured to allow non-owners to respond to ICMP echo requests when they become the virtual router in master state for the VRRP instance. Telnet and other connection-oriented protocols can also be configured for master. However, the individual application conversations (connections) will not survive a VRRP failover. A non-owner VRRP router operating as a backup will not respond to any packets addressed to any of the virtual router IP addresses.
Primary and secondary IP addresses
A primary address is an IP address selected from the set of real interface address. VRRP advertisements are always sent using the primary IP address as the source of the IP packet.
To be active, an IP interface must always have a primary IP address assigned for VRRP. Nokia routers support both primary and secondary IP addresses (multi-netting) on the IP interface. The virtual router VRID primary IP address is always the primary address on the IP interface. VRRP places this primary IP address in the source IP address field of the IP header for all VRRP messages sent on that interface.
Virtual router master state
The VRRP router that controls the IP addresses associated with a virtual router is considered to be in the master state, is the active router for the VRRP instance, and is responsible for forwarding packets sent to the VRRP IP address. An election process provides dynamic failover of the forwarding responsibility if the master becomes unavailable. In such an event, any of the virtual router IP addresses on the LAN can be used as the default first hop router by end-hosts. This capability enables a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end host.
If the active router is unavailable, each backup virtual router for the VRID compares the configured priority values to determine the master role. In case of a tie, the virtual router with the highest primary IP address becomes master.
Setting the preempt parameter to false prevents a backup virtual router configured with a better priority value from becoming master when an existing non-owner virtual router is the current master. This is determined on a first-come, first-served basis.
While master, a virtual router originates all IP packets and routes them into the LAN using the physical MAC address for the IP interface as the Layer 2 source MAC address, not the VRID MAC address. ARP packets also use the parent IP interface MAC address as the Layer 2 source MAC address and insert the virtual router MAC address in the appropriate hardware address field. VRRP messages are the only packets transmitted using the virtual router MAC address as the Layer 2 source MAC.
Virtual router backup
A new virtual router master is selected from the set of VRRP routers available to assume forwarding responsibility for a virtual router in case the current master fails.
Owner and non-owner VRRP
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. Only one virtual router in the domain can be configured as owner. All other virtual router instances participating in this message domain must have the same VRID configured.
Priority is the most important parameter to be defined on a non-owner virtual router instance and defines the virtual router selection order in the master election process. The priority value and the preempt mode are used to determine the virtual router with the highest priority that can 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.
See VRRP non-owner accessibility for information about non-owner access parameters.
Configurable parameters
In addition to backup IP addresses, to facilitate configuration of a virtual router on routers, the following parameters can be defined in owner configurations:
The following parameters can be defined in non-owner configurations:
Virtual router ID (VRID)
The VRID must be configured with the same value on each virtual router associated with the redundant IP address (IP addresses). It is placed in all VRRP advertisement messages sent by each virtual router.
Priority
The priority value affects the interaction between this VRID and the same VRID of other virtual routers participating on the same LAN. A higher priority value defines a greater priority in becoming the virtual router master for the VRID. The priority value can only be configured when the defined IP address on the IP interface is different from the virtual router IP address (non-owner mode).
When the IP address on the IP interface matches the virtual router IP address (owner mode), the priority value is fixed at 255, the highest value possible. This virtual router member is considered the owner of the virtual router IP address. There can only be one owner of the virtual router IP address for all virtual router members.
The priority value 0 is reserved for VRRP advertisement message purposes. It is used to tell other virtual routers in the same VRID that this virtual router is no longer acting as master, triggering a new election process. When this happens, each backup virtual router sets its master down timer equal to the skew time value. This shortens the time until one of the backup virtual routers becomes master.
The current master virtual router must transmit a VRRP advertisement message immediately upon receipt of a VRRP message with priority set to 0. This prevents another backup from becoming master for a short period of time.
Non-owner virtual routers may be configured with a priority of 254 through 1. The default value is 100. Multiple non-owners can share the same priority value. When multiple non-owner backup virtual routers are tied (transmit VRRP advertisement messages simultaneously) in the election process, both become master simultaneously, the one with the best priority will win the election. If the priority value in the message is equal to the master local priority value, then the primary IP address of the local master and the message is evaluated as the tie breaker. The higher IP address becomes master. (The primary IP address is the source IP address of the VRRP advertisement message.)
The priority is also used to determine when to preempt the existing master. If the preempt mode value is true, VRRP advertisement messages from inferior (lower priority) masters are discarded, causing the master down timer to expire and the transition to master state.
The priority value also dictates the skew time added to the master timeout period.
IP addresses
Each virtual router participating in the same VRID should be defined with the same set of IP addresses. These are the IP addresses being used by hosts on the LAN as gateway addresses.
Multi-netting supports a total of 64 primary and secondary IP addresses on the IP interface. Up to 64 addresses can be assigned to a specific a virtual router instance.
Message interval and master inheritance
Each virtual router is configured with a message interval per VRID within which it participates. This parameter must be the same for every virtual router on the VRID.
For IPv4, the default advertisement interval is 1 s and can be configured between 1 s and 255 s 900 ms. For IPv6, the default advertisement interval is 1 s and can be configured between 1 s and 40 s 950 ms.
7210 SAS supports a minimum message interval of 1 second. It does not support use of sub-second message intervals.
As specified in the RFCs, the advertisement interval field in every received VRRP advertisement message must match the locally configured advertisement interval. If a mismatch occurs, depending on the inherit configuration, the current master's advertisement interval setting can be used to operationally override the locally configured advertisement interval setting. If the current master changes, the new master setting is used. If the local virtual router becomes master, the locally configured advertisement interval is enforced.
If a VRRP advertisement message is received with an advertisement interval set to a value different from the local value and the inherit parameter is disabled, the message is discarded without processing.
The master virtual router on a VRID uses the advertisement interval to load the advertisement timer, specifying when to send the next VRRP advertisement message. Each backup virtual router on a VRID uses the advertisement interval (with the configured local priority) to derive the master down timer value.
VRRP advertisements messages that are fragmented, or contain IP options (IPv4) or extension headers (IPv6) require a longer message interval.
Skew time
The skew time is used to add a time period to the master down interval. This is not a configurable parameter. It is derived from the current local priority of the virtual router VRID. To calculate the skew time, the virtual router evaluates the following formula:
for IPv4 - Skew Time = ((256 – priority) / 256) seconds
for IPv6 - Skew Time = (((256 – priority) * Master_Adver_Interval) / 256) centiseconds
The higher the priority value, the smaller the skew time will be. This means that virtual routers with a lower priority will transition to master slower than virtual routers with higher priorities.
Master down interval
The master down interval is a calculated value used to load the master down timer. When the master down timer expires, the virtual router enters the master state. To calculate the master down interval, the virtual router evaluates the following formula:
Master Down Interval = (3 x Operational Advertisement Interval) + Skew Time
The operational advertisement interval is dependent upon the state of the inherit parameter. When the inherit parameter is enabled, the operational advertisement interval is derived from the current master advertisement interval field in the VRRP advertisement message. When inherit is disabled, the operational advertisement interval must be equal to the locally configured advertisement interval.
The master down timer is only operational when the local virtual router is operating in backup mode.
Preempt mode
Preempt mode is a true or false configured value which controls whether a specific backup virtual router preempts a lower priority master. The IP address owner will always become master when available. Preempt mode cannot be set to false on the owner virtual router. The default value for preempt mode is true.
When preempt mode is true, the advertised priority from the incoming VRRP advertisement message from the current master is compared to the local configured priority. If the local priority is higher, the received VRRP advertisement message is discarded. This will result in the eventual expiration of the master down timer causing a transition to the master state. If the received priority is equal to the local priority, the message is not discarded and the current master will not be discarded. Note that when in the backup state, the received primary IP address is not part of the decision to preempt and is not used as a tie breaker when the received and local priorities are equal.
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.
VRRP message authentication
The authentication type parameter defines the type of authentication used by the virtual router in VRRP advertisement message authentication. VRRP message authentication is applicable to IPv4 only. The current master uses the configured authentication type to indicate any egress message manipulation that must be performed in conjunction with any supporting authentication parameters before transmitting a VRRP advertisement message. The configured authentication type value is transmitted in the message authentication type field with the appropriate authentication data field filled in. Backup routers use the authentication type message field value in interpreting the contained authentication data field within received VRRP advertisement messages.
VRRP supports two message authentication methods that provide different degrees of security. The supported authentication types are:
0 - no authentication
1 - simple text password
Authentication type 0 — no authentication
The use of type 0 indicates that VRRP advertisement messages are not authenticated (provides no authentication). The master transmitting VRRP advertisement messages will transmit the value 0 in the egress messages authentication type field and the authentication data field. Backup virtual routers receiving VRRP advertisement messages with the authentication type field equal to 0 will ignore the authentication data field in the message.
All compliant VRRP advertisement messages are accepted. The following fields within the received VRRP advertisement message are checked for compliance (the VRRP specification may require additional checks):
IP header checks specific to VRRP:
IP header destination IP address - must be 224.0.0.18
IP header TTL field - must be equal to 255, the packet must not have traversed any IP routed hops
IP header protocol field - must be 112 (decimal)
VRRP message checks:
Version field
Must be set to the value 2.
Type field
Must be set to the value of 1 (advertisement).
Virtual router ID field
Must match one of the configured VRID on the ingress IP interface (All other fields are dependent on matching the virtual router ID field to one of the interfaces configured VRID parameters).
Priority field
Must be equal to or greater than the VRID in-use priority or be equal to 0 (Note, equal to the VRID in-use priority and 0 requires further processing regarding master/backup and senders IP address to determine the validity of the message).
Authentication type field
Must be equal to 0.
Advertisement interval field
Must be equal to the VRID configured advertisement interval.
Checksum field
Must be valid
Authentication data fields
Must be ignored.
VRRP messages not meeting the criteria are silently dropped.
Authentication type 1 — simple text password
The use of type 1 indicates that VRRP advertisement messages are authenticated with a clear (simple) text password. All virtual routers participating in the virtual router instance must be configured with the same 8 octet password. Transmitting virtual routers place a value of 1 in the VRRP advertisement message authentication type field and put the configured simple text password into the message authentication data field. Receiving virtual routers compare the message authentication data field with the local configured simple text password based on the message authentication type field value of 1.
The same checks are performed for type 0 with the following exceptions (the VRRP specification may require additional checks):
VRRP message checks:
authentication type field - must be equal to 1
authentication data fields - must be equal to the VRID configured simple text password
Any VRRP message not meeting the type 0 verification checks with the preceding exceptions are silently discarded.
Authentication failure
Any received VRRP advertisement message that fails authentication must be silently discarded with an invalid authentication counter incremented for the ingress virtual router instance.
Authentication data
This feature is different from the VRRP advertisement message field with the same name. This is any required authentication information that is pertinent to the configured authentication type. The type of authentication data used for each authentication type is listed in the following table.
Authentication type |
Authentication data |
|---|---|
0 |
None; authentication is not performed |
1 |
Simple text password consisting of 8 octets |
Virtual MAC address
On the 7210 SAS, the MAC address is not configurable. The 7210 SAS derives the MAC address to use from the VRID assigned as defined in the standard.
VRRP advertisement message IP address list verification
VRRP advertisement messages contain an IP address count field that indicates the number of IP addresses listed in the sequential IP address fields at the end of the message.
The implementation always logs mismatching events. The decision on where and whether to forward the generated messages depends on the configuration of the event manager.
To facilitate the sending of mismatch log messages, each virtual router instance keeps the mismatch state associated with each source IP address in the VRRP master table. Whenever the state changes, a mismatch log message is generated indicating the source IP address within the message, the mismatch or match event and the time of the event.
With secondary IP address support, multiple IP addresses may be found in the list and it should match the IP address on the virtual router instance. Owner and non-owner virtual router instances have the supported IP addresses explicitly defined, making mismatched supported IP address within the interconnected virtual router instances a provisioning issue.
IPv6 virtual router instance operationally up
If the IPv6 virtual router is configured with a minimum of one link-local backup address, the router advertisement of the parent interface must be configured to use the virtual MAC address for the virtual router to be considered operationally up.
Policies
Policies can be configured to control VRRP priority with the virtual router instance. 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 override or diminish the base priority 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.
Policies can only be configured in the non-owner VRRP context. For non-owner virtual router instances, if policies are not configured, then the base priority is used as the in-use priority.
VRRP priority control policies
This implementation of VRRP supports control policies to manipulate virtual router participation in the VRRP master election process and master self-deprecation. The local priority value for the virtual router instance is used to control the election process and master state.
VRRP virtual router policy constraints
Priority control policies can only be applied to non-owner VRRP virtual router instances. Owner VRRP virtual routers cannot be controlled by a priority control policy because they are required to have a priority value of 255 that cannot be diminished. Only one VRRP priority control policy can be applied to a non-owner virtual router instance.
Multiple VRRP virtual router instances may be associated with the same IP interface, allowing multiple priority control policies to be associated with the IP interface.
An applied VRRP priority control policy only affects the in-use priority on the virtual router instance when the preempt mode has been enabled. A virtual router instance with preempt mode disabled will always use the base priority as the in-use priority, ignoring any configured priority control policy.
VRRP virtual router instance base priority
Non-owner virtual router instances must have a base priority value between 1 and 254. The value 0 is reserved for master termination. The value 255 is reserved for owners. The default base priority for non-owner virtual router instances is the value 100.
The base priority is the starting priority for the VRRP instance. The actual in-use priority for the VRRP instance is derived from the base priority and an optional VRRP priority control policy.
VRRP priority control policy delta in-use priority limit
A VRRP priority control policy enforces an overall minimum value that the policy can inflict on the VRRP virtual router instance base priority. This value provides a lower limit to the delta priority events manipulation of the base priority.
A delta priority event is a conditional event defined in the priority control policy that subtracts a specific amount from the current, in-use priority for all VRRP virtual router instances to which the policy is applied. Multiple delta priority events can apply simultaneously, creating a dynamic priority value. The base priority for the instance, less the sum of the delta values derives the actual priority value in-use.
An explicit priority event is a conditional event defined in the priority control policy that explicitly defines the in-use priority for the virtual router instance. The explicitly defined values are not affected by the delta in-use priority limit. When multiple explicit priority events happen simultaneously, the lowest value is used for the in-use priority. The configured base priority is not a factor in explicit priority overrides of the in-use priority.
The allowed range of the Delta In-Use Priority Limit is 1 to 254. The default is 1, which prevents the delta priority events from operationally disabling the virtual router instance.
VRRP priority control policy priority events
The main function of a VRRP priority control policy is to define conditions or events that impact the system ability to communicate with outside hosts or portions of the network. When one or multiple of these events are true, the base priority on the virtual router instance is either overwritten with an explicit value, or a sum of delta priorities is subtracted from the base priority. The result is the in-use priority for the virtual router instance. Any priority event may be configured as an explicit event or a delta event.
Explicit events override all delta events. When multiple explicit events occur, the event with the lowest priority value is assigned to the in-use priority. As events clear, the in-use priority is reevaluated accordingly and adjusted dynamically.
Delta priority events also have priority values. When no explicit events have occurred within the policy, the sum of the occurring delta events priorities is subtracted from the base priority of each virtual router instance. If the result is lower than the delta in-use priority limit, the delta in-use priority limit is used as the in-use priority for the virtual router instance. Otherwise, the in-use priority is set to the base priority less the sum of the delta events.
Each event generates a VRRP priority event message indicating the policy-id, the event type, the priority type (delta or explicit) and the event priority value. Another log message is generated when the event is no longer true, indicating that it has been cleared.
Priority event hold-set timers
Hold-set timers are used to dampen the effect of a flapping event. A flapping event is where the event continually transitions between clear and set. 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 to count down to zero. If the timer reaches zero, the event will be allowed to enter the cleared state again. Entering the cleared state is always dependent on the object controlling the event conforming to the requirements defined in the event. It is possible, on some event types, to have a further set action reload the hold-set timer. This extends the amount of time that must expire before entering the cleared state.
See LAG degrade priority event for an example of a hold-set timer setting.
Port down priority event
The port down priority event is tied to either a physical port or a SONET/SDH channel. The port or channel operational state is evaluated to determine a port down priority event or event clear.
When the port or channel operational state is up, the port down priority event is considered false or cleared. When the port or channel operational state is down, the port down priority event is considered true or set.
LAG degrade priority event
The LAG degrade priority event is tied to an existing Link Aggregation Group (LAG). The LAG degrade priority event is conditional to percentage of available port bandwidth on the LAG. Multiple bandwidth percentage thresholds may be defined, each with its own priority value.
If the LAG transitions from one threshold to the next, the previous threshold priority value is subtracted from the total delta sum while the new threshold priority value is added to the sum. The new sum is then subtracted from the base priority and compared to the delta in-use priority limit to derive the new in-use priority on the virtual router instance.
The following example illustrates a LAG priority event and interaction with the hold-set timer in changing the in-use priority.
The following state and timer settings are used for the LAG events listed in the following table:
user-defined thresholds - 2 ports down 3 ports down
LAG configured ports - 4 ports
hold-set timer (hold-set) - 5 seconds
Time |
LAG port state |
Parameter |
State |
Comments |
|---|---|---|---|---|
0 |
All ports down |
Event State |
Set - 4 ports down |
|
Event Threshold |
3 ports down |
|||
Hold-Set Timer |
5 seconds |
Set to hold-set parameter |
||
1 |
One port up |
Event State |
Set - 4 ports down |
Cannot change until Hold-Set Timer expires |
Event Threshold |
3 ports down |
|||
Hold-Set Timer |
5 seconds |
Event does not affect timer |
||
2 |
All ports up |
Event State |
Set - 4 ports down |
Still waiting for Hold-Set Timer expires |
Event Threshold |
3 ports down |
|||
Hold-Set Timer |
3 seconds |
|||
5 |
All ports up |
Event State |
Cleared - All ports up |
|
Event Threshold |
None |
Event cleared |
||
Hold-Set Timer |
Expired |
|||
100 |
Three ports down |
Event State |
Set - 3 ports down |
|
Event Threshold |
3 ports down |
|||
Hold-Set Timer |
Expired |
Set to hold-set parameter |
||
102 |
Two ports down |
Event State |
Set - 3 ports down |
|
Event Threshold |
3 ports down |
|||
Hold-Set Timer |
3 seconds |
|||
103 |
All ports up |
Event State |
Set - 3 ports down |
|
Event Threshold |
3 ports down |
|||
Hold-Set Timer |
2 second |
|||
104 |
One ports down |
Event State |
Set - 3 ports down |
|
Event Threshold |
3 ports down |
|||
Hold-Set Timer |
1 second |
Current threshold is 2, so 1 down has no effect |
||
105 |
One ports down |
Event State |
Set - 1 port down |
|
Event Threshold |
2 ports down |
|||
Hold-Set Timer |
Expired |
Host unreachable priority event
The host unreachable priority event creates a continuous ping task that is used to test connectivity to a remote host. The path to the remote host and the remote host must be capable and configured to accept ICMP echo request and replies for the ping to be successful.
The ping task is controlled by interval and size parameters that define how often the ICMP request messages are transmitted and the size of each message. A historical missing reply parameter defines when the ping destination is considered unreachable.
When the host is unreachable, the host unreachable priority event is considered true or set. When the host is reachable, the host unreachable priority event is considered false or cleared.
Route unknown priority event
The route unknown priority event defines a task that monitors the existence of a specific route prefix in the system routing table.
The route monitoring task can be constrained by a condition that allows a prefix that is less specific than the defined prefix to be considered as a match. The source protocol can be defined to indicate the protocol the installed route must be populated from. To further define match criteria when multiple instances of the route prefix exist, an optional next hop parameter can be defined.
When a route prefix exists within the active route table that matches the defined match criteria, the route unknown priority event is considered false or cleared. When a route prefix does not exist within the active route table matching the defined criteria, the route unknown priority event is considered true or set.
VRRP non-owner accessibility
Although the RFC states that only VRRP owners can respond to ping and other management-oriented protocols directed to the VRID IP addresses, allows an override of this restraint on a per VRRP virtual router instance basis.
Non-owner access ping reply
When non-owner access ping reply is enabled on a virtual router instance, ICMP echo request messages destined for the non-owner virtual router instance IP addresses are not discarded at the IP interface when operating in master mode. ICMP echo request messages are always discarded in backup mode.
When non-owner access ping reply is disabled on a virtual router instance, ICMP echo request messages destined for the non-owner virtual router instance IP addresses are silently discarded in both the master and backup modes.
Non-owner access Telnet
When non-owner access Telnet is enabled on a virtual router instance, authorized Telnet sessions may be established that are destined to the virtual router instance IP addresses when operating in master mode. Telnet sessions are always discarded at the IP interface when destined to a virtual router IP address operating in backup mode. Enabling non-owner access Telnet does not guarantee Telnet access, proper management and security features must be enabled to allow Telnet on this interface and possibly from the specific source IP address.
When non-owner access Telnet is disabled on a virtual router instance, Telnet sessions destined for the non-owner virtual router instance IP addresses are silently discarded in both master and backup modes.
Non-owner access SSH
When non-owner access SSH is enabled on a virtual router instance, authorized SSH sessions may be established that are destined to the virtual router instance IP addresses when operating in master mode. SSH sessions are always discarded at the IP interface when destined for a virtual router IP address operating in backup mode. Enabling non-owner access SSH does not guarantee SSH access, proper management and security features must be enabled to allow SSH on this interface and possibly from the specific source IP address. SSH is applicable to IPv4 VRRP only.
When non-owner access SSH is disabled on a virtual router instance, SSH sessions destined for the non-owner virtual router instance IP addresses are silently discarded in both master and backup modes.
VRRP configuration process overview
The following figure shows the process to provision VRRP parameters.
Configuration notes
This section describes VRRP configuration restrictions.
General
Creating and applying VRRP policies are optional.
Backup command:
The backup IP addresses must be on the same subnet. The backup addresses explicitly define which IP addresses are in the VRRP advertisement message IP address list.
In the owner mode, the backup IP address must be identical to one of the interface IP addresses. The backup address explicitly defines which IP addresses are in the VRRP advertisement message IP address list.
For IPv6, one of the configured backup addresses must be the link-local address of the owner VRRP instance.
Configuring VRRP with CLI
This section provides information to configure VRRP using the command line interface.
VRRP configuration overview
Configuring VRRP policies and configuring VRRP instances on interfaces and router interfaces is optional. The basic owner and non-owner VRRP configurations on an IES or router interface must specify the backup ip-address parameter.
VRRP helps eliminate the single point of failure in a routed environment by using virtual router IP address shared between two or more routers connecting the common domain. VRRP provides dynamic fail over of the forwarding responsibility if the master becomes unavailable.
The VRRP implementation allows one master per IP subnet. All other VRRP instances in the same domain must be in backup mode.
Preconfiguration requirements
The following information describes VRRP preconfiguration requirements:
VRRP policies:
VRRP policies must be configured before they can be applied to an interface or IES VRRP instance. VRRP policies are configured in the config>vrrp context.
Configuring VRRP on an IES service interface:
The service customer account must be created before configuring an IES VRRP instance.
The interface address must be specified in the both the owner and non-owner IES or router interface instances.
Basic VRRP configurations
This section contains information about basic VRRP configurations.
VRRP policy
Configuring and applying VRRP policies are optional. There are no default VRRP policies. Each policy must be explicitly defined. A VRRP configuration must include the following:
policy ID
define at least one of the following priority events:
port down
LAG port down
host unreachable
route unknown
Sample VRRP policy configuration output
A:SR2>config>vrrp>policy# info
----------------------------------------------
delta-in-use-limit 50
priority-event
port-down /1/2
hold-set 43200
priority 100 delta
exit
port-down /1/3
priority 200 explicit
exit
lag-port-down 1
number-down 3
priority 50 explicit
exit
exit
host-unreachable 10.10.24.4
drop-count 25
exit
route-unknown 10.10.0.0/32
priority 50 delta
exit
exit
----------------------------------------------
VRRP IES service parameters
VRRP parameters are configured within an IES service with two contexts, owner or non-owner. The status is specified when the VRRP configuration is created. When configured as owner, the virtual router instance owns the backup IP addresses. All other virtual router instances participating in this message domain must have the same VRID configured and cannot be configured as owner.
For IPv4, up to 4 virtual routers IDs (vrid) can be configured on an IES service interface.
VRRP parameters configured within an IES service must include the following:
VRID
backup IP addresses
The following is a sample IES service owner and non-owner VRRP configuration output.
A:SR2>config>service>ies# info
----------------------------------------------
interface "tuesday" create
address 10.10.36.2/24
sap 7/1/1.2.2 create
vrrp 19 owner
backup 10.10.36.2
authentication-type password
authentication-key "testabc"
exit
exit
interface "testing" create
address 10.10.10.16/24
sap 1/1/55:0 create
vrrp 12
backup 10.10.10.15
policy 1
authentication-type password
authentication-key "testabc"
exit
exit
no shutdown
----------------------------------------------
A:SR2>config>service>ies#
VRRP router interface parameters
VRRP parameters are configured on a router interface with two contexts, owner or non-owner. The status is specified when the VRRP configuration is created. When configured as owner, the virtual router instance owns the backed up IP addresses. All other virtual router instances participating in this message domain must have the same VRID configured and cannot be configured as owner.
For IPv4, up to 4 virtual routers IDs (VRIDs) can be configured on a router interface. For IPv6, only one virtual router instance can be configured on a router interface.
VRRP parameters configured on a router interface must include the following:
VRID
backup IP addresses
The following is a sample router interface owner and non-owner VRRP configuration output.
A:SR4>config>router# info
#------------------------------------------
echo "IP Configuration "
#------------------------------------------
interface "system"
address 10.10.0.4/32
exit
interface "test1"
address 10.10.14.1/24
exit
interface "test2"
address 10.10.10.23/24
vrrp 1 owner
backup 10.10.10.23
authentication-key "testabc"
exit
exit
#------------------------------------------
A:SR4>config>router#
Common configuration tasks
This section provides a brief overview of the tasks that must be performed to configure VRRP and provides the CLI commands.
VRRP parameters are defined under a service interface or a router interface context. An IP address must be assigned to each IP interface. Only one primary IP address can be associated with an IP interface, but several secondary IP addresses can also be associated.
Owner and non-owner configurations must include the following parameters:
All participating routers in a VRRP instance must be configured with the same VRID.
The owner configuration must include at least one backup IP address.
For IPv6, all participating routers must be configured with the same link-local backup address (the address configured for the owner instance).
Other owner and non-owner configurations include the following optional commands:
- authentication-key
- message-interval
In addition to the common parameters, the following non-owner commands can be configured:
master-int-inherit
priority
policy
ping-reply
preempt
telnet-reply
ssh-reply (IPv4 only)
[no] shutdown
Creating interface parameters
If you have multiple subnets configured on an Ethernet interface, you can configure VRRP on each subnet.
The following is a sample IP interface configuration output.
A:SR1>config>router# info
#------------------------------------------
echo "IP Configuration "
#------------------------------------------
interface "system"
address 10.10.0.1/32
exit
interface "testA"
address 10.123.123.123/24
exit
interface "testB"
address 10.10.14.1/24
secondary 10.10.16.1/24
secondary 10.10.17.1/24
secondary 10.10.18.1/24
exit
router-id 10.10.0.1
#------------------------------------------
A:SR1>config>router#
Configuring VRRP policy components
The following is a sample VRRP policy configuration output.
A:SR1>config>vrrp# info
----------------------------------------------
policy 1
delta-in-use-limit 50
priority-event
port-down 1/1/2
hold-set 43200
priority 100 delta
exit
route-unknown 0.0.0.0/0
protocol isis
exit
exit
exit
----------------------------------------------
A:SR1>config>vrrp#
Configuring service VRRP parameters
VRRP parameters can be configured on an interface in a service to provide virtual default router support which allows traffic to be routed without relying on a single router in case of failure.
Non-owner VRRP example
The following is a sample basic non-owner VRRP configuration output.
A:SR2>config>service>ies# info
----------------------------------------------
...
interface "testing" create
address 10.10.10.16/24
sap 1/1/55:0 create
vrrp 12
backup 10.10.10.15
policy 1
authentication-key "testabc"
exit
exit
no shutdown
----------------------------------------------
A:SR2>config>service>ies#
Owner service VRRP example
The following is a sample owner VRRP configuration output.
A:SR4>config>router# info
#------------------------------------------
echo "IP Configuration "
#------------------------------------------
...
interface "test2"
address 10.10.10.23/24
vrrp 1 owner
backup 10.10.10.23
authentication-key "testabc"
exit
exit
#------------------------------------------
A:SR4>config>router#
Configuring router interface VRRP parameters
VRRP parameters can be configured on an interface in an interface to provide virtual default router support which allows traffic to be routed without relying on a single router in case of failure.
Router interface VRRP non-owner
The following is a sample non-owner interface VRRP configuration output.
A:SR2>config># info
#------------------------------------------
interface "if-test"
address 10.20.30.40/24
secondary 10.10.50.1/24
secondary 10.10.60.1/24
secondary 10.10.70.1/24
vrrp 1
backup 10.20.30.41
ping-reply
telnet-reply
authentication-key "testabc"
exit
exit
#------------------------------------------
A:SR2>config>#
Router interface VRRP owner
The following is a sample router interface owner VRRP configuration output.
A:SR2>config>router# info
#------------------------------------------
interface "vrrpowner"
address 10.10.10.23/24
vrrp 1 owner
backup 10.10.10.23
authentication-key "testabc"
exit
exit
#------------------------------------------
A:SR2>config>router#
VRRP configuration management tasks
This section describes the VRRP configuration management tasks.
Modifying a VRRP policy
To access a specific VRRP policy, you must specify the policy ID. To display a list of VRRP policies, use the show vrrp policy command.
The following is a sample modified VRRP policy configuration output.
A:SR2>config>vrrp>policy# info
----------------------------------------------
delta-in-use-limit 50
priority-event
port-down 1/1/2
hold-set 43200
priority 100 delta
exit
port-down 1/1/3
priority 200 explicit
exit
host-unreachable 10.10.24.4
drop-count 25
exit
exit
----------------------------------------------
A:SR2>config>vrrp>policy#
Deleting a VRRP policy
Policies are only applied to non-owner VRRP instances. A VRRP policy cannot be deleted if it is applied to an interface or to an IES service. Each instance in which the policy is applied must be deleted.
The Applied column in the following example displays whether or not the VRRP policies are applied to an entity.
A:SR2#
===============================================================================
VRRP Policies
===============================================================================
Policy Current Current Current Delta Applied
Id Priority & Effect Explicit Delta Sum Limit
-------------------------------------------------------------------------------
1 200 Explicit 200 100 50 Yes
15 254 None None 1 No
32 100 None None 1 No
===============================================================================
A:SR2#
Modifying service and interface VRRP parameters
Modifying non-owner parameters
When a VRRP instance is created as non-owner, it cannot be modified to the owner state. The VRID must be deleted and then recreated with the owner keyword to invoke IP address ownership.
Modifying owner parameters
When a VRRP instance is created as owner, it cannot be modified to the non-owner state. The VRID must be deleted and then recreated without the owner keyword to remove IP address ownership.
Entering the owner keyword is optional when entering the VRID for modification purposes.
Deleting VRRP on an interface or service
The VRID does not need to be shut down to remove the virtual router instance from an interface or service.
config>router#interface
config>router# interface if-test
config>router>if# shutdown
config>router>if# exit
config>router# no interface if-test
config>router#
The following shows the command usage to delete a VRRP instance from an interface or IES service.
config>service#ies 10
config>service>ies# interface ‟test”
config>service>ies>if# vrrp 1
config>service>ies>if>vrrp# shutdown
config>service>ies>if>vrrp# exit
config>service>ies>if# no vrrp 1
config>service>ies>if# exit all
VRRP command reference
VRRP commands are supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.
Command hierarchies
Configuration commands
VRRP network interface commands
config
- router
- [no] interface interface-name
- address {ip-address/mask | ip-address netmask} [broadcast all-ones | host-ones]
- no address
- arp-timeout seconds
- no arp-timeout
- description description-string
- no description
- [no] shutdown
- static-arp ip-address ieee-address
- [no] static-arp ip-address
- vrrp virtual-router-id [owner]
- no vrrp virtual-router-id
- authentication-key [authentication-key | hash-key] [hash | hash2]
- no authentication-key
- [no] backup ip-address
- [no] bfd-enable service-id interface interface-name dst-ip ip-address
- [no] bfd-enable interface interface-name dst-ip ip-address
- init-delay seconds
- no init-delay
- [no] master-int-inherit
- message-interval {[seconds] [milliseconds milliseconds]}
- no message-interval
- [no] ping-reply
- policy policy-id
- no policy
- [no] preempt
- priority priority
- no priority
- [no] ssh-reply
- [no] standby-forwarding
- [no] telnet-reply
- [no] shutdown
- [no] traceroute-reply
VRRP IPv6 interface commands
VRRP IPv6 interface commands are only supported on 7210 SAS-Mxp.
config
- router
- [no] interface interface-name
- [no] ipv6
- vrrp virtual-router-id [owner]
- no vrrp virtual-router-id
- [no] backup ip-address
- init-delay seconds
- no init-delay
- [no] master-int-inherit
- message-interval {[seconds] [milliseconds milliseconds]}
- no message-interval
- [no] ping-reply
- policy policy-id
- no policy
- [no] preempt
- priority priority
- no priority
- [no] shutdown
- [no] standby-forwarding
- [no] telnet-reply
- [no] traceroute-reply
VRRP priority control event policy commands
config
- vrrp
- [no] policy policy-id [context service-id]
- delta-in-use-limit limit
- no delta-in-use-limit
- description description string
- no description
- [no] priority-event
- [no] host-unreachable ip-address
- drop-count consecutive-failures
- no drop-count
- hold-clear seconds
- no hold-clear
- hold-set seconds
- no hold-set
- interval seconds
- no interval
- priority priority-level [{delta | explicit}]
- no priority
- timeout seconds
- no timeout
- [no] lag-port-down lag-id
- hold-clear seconds
- no hold-clear
- hold-set seconds
- no hold-set
- [no] number-down number-of-lag-ports-down
- priority priority-level [delta | explicit]
- no priority
- [no] port-down port-id
- hold-clear seconds
- no hold-clear
- hold-set seconds
- no hold-set
- priority priority-level [delta | explicit]
- no priority
- [no] route-unknown ip-prefix/mask
- hold-clear seconds
- no hold-clear
- hold-set seconds
- no hold-set
- less-specific [allow-default]
- no less-specific
- [no] next-hop ip-address
- priority priority-level [delta | explicit]
- no priority
- protocol protocol
- no protocol[protocol]
- [no] protocol ospf
- [no] protocol isis
- [no] protocol static
Show commands
show
- vrrp
- policy [policy-id [event event-type specific-qualifier]]
- router
- vrrp
- instance
- instance [interface interface-name [vrid virtual-router-id]]
- statistics
Monitor commands
Clear commands
clear
- vrrp
- statistics
- router
- vrrp
- interface ip-int-name [vrid virtual-router-id]
- statistics interface interface-name [vrid virtual-router-id]
- statistics
Debug commands
debug
- router
- vrrp
- events
- events interface ip-int-name [vrid virtual-router-id]
- no events
- no events interface ip-int-name [vrid virtual-router-id]
- packets
- packets interface ip-int-name [vrid virtual-router-id]
- packets
- no packets
- no packets interface ip-int-name [vrid virtual-router-id]
- no packets
Command descriptions
Configuration commands
Interface configuration commands
authentication-key
Syntax
authentication-key [authentication-key | hash-key] [hash | hash2]
no authentication-key
Context
config>router>if>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures 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 any time.
To change the current in-use password key on multiple virtual router instances:
Identify the current master.
Shutdown the virtual router instance on all backups.
Execute the authentication-key command on the master to change the password key.
Execute the authentication-key command and no shutdown command on each backup.
The no form of this command reverts to the default value.
Default
no authentication-key
Parameters
- authentication-key
Specifies the authentication key. Allowed values are any string up to 8 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
- hash-key
Specifies the hash key. The key can be any combination of ASCII characters up to 22 (hash-key1) or 121 (hash-key2) characters (encrypted). If spaces are used in the string, enclose the entire string in quotation marks (‟ ”).
This is useful when a user must configure the parameter, but for security purposes, the actual unencrypted key value is not provided.
- hash
Specifies that the key is entered in an encrypted form. If the hash parameter is not used, the key is assumed to be in a non-encrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash parameter specified.
- hash2
Specifies that the key is entered in a more complex encrypted form. If the hash2 parameter is not used, the less encrypted hash form is assumed.
backup
Syntax
[no] backup ip-address
Context
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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 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 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 proper list is important. The specified ip-address must be equal to the existing parental IP interface IP addresses (primary) or the backup command will fail.
For non-owner virtual router instances, the backup command 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-address must be an IP address of the parental IP interface local subnets created with the address. If a local subnet does not exist that includes the specified ip-address or if ip-address 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-address 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-address, nor will it route packets received with its vrid derived source MAC address. A non-master virtual router instance always silently discards packets destined for ip-address. A single virtual router instance may only have a single virtual router IP address from a specific 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.
When operating as a (non-owner) master, the default functionality associated with ip-address is ARP response to ARP requests to ip-address, routing of packets destined for the virtual router instance source MAC address, and silently discarding packets destined for ip-address. Enabling the non-owner-access parameters selectively allows ping, Telnet, and SSH connectivity to ip-address when the virtual router instance is operating as master.
The no form of this 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-address to cease. For owner virtual router instances, the no backup command only removes ip-address from the list of advertised IP addresses. If the last ip-address is removed from the virtual router instance, the virtual router instance will enter the operationally down state
Default
no backup
Special Cases
- Assigning the Virtual Router ID IP Address
When 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 the parent IP interface defined IP addresses (primary). 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-address command.
- Virtual Router Instance IP Address Assignment Conditions
The RFC does not specify that the assigned IP addresses to the virtual router instance must be in the same subnet as the parent IP interface primary IP address. The only requirement is that all virtual routers participating in the same virtual router instance have the same virtual router IP addresses assigned. To avoid confusion, the assigned virtual router IP addresses must be in a local subnet of one of the parent IP interfaces IP addresses. For owner virtual router instances the assigned virtual router IP address must be the same as the parental IP interface primary.
The following rules apply when adding, changing, or removing parental and virtual router IP addresses:
- Owner Virtual Router IP Address Parental Association
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 oIP address within the parental IP interface.
Example - Owner Virtual Router Instance
Parent IP addresses:
10.10.10.10/24
Virtual router IP addresses:
10.10.10.11
Invalid (not equal to parent IP address)
10.10.10.10
Associated (same as parent IP address 10.10.10.10)
10.10.11.11
Invalid (not equal to parent IP address)
- Non-Owner Virtual Router IP Address Parental Association
When an IP address is assigned to a non-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 a valid IP address within one of the parental IP interfaces local subnet. Local subnets are created by the primary IP address in conjunction with the IP addresses mask. If the defined virtual router IP address is equal to the associated subnet broadcast address, it is invalid. Virtual router IP addresses for non-owner virtual router instances that are equal to a parental IP interface IP address are also invalid.
The same virtual router IP address may not be assigned to two separate virtual router instances. If the virtual router IP address already exists on another virtual router instance, the virtual router IP address assignment will fail.
Example - Non-Owner Virtual Router Instance
Parent IP addresses:
10.10.10.10/24
Virtual router IP addresses:
10.10.10.11
Associated with 10.10.10.10 (in subnet)
10.10.10.10
Invalid (same as parent IP address)
10.10.11.11
Invalid (outside of all Parent IP subnets)
- Virtual Router IP Address Assignment without Parent IP Address
When assigning an IP address to a virtual router instance, an associated IP address (see Owner Virtual Router IP Address Parental Association and Non-Owner Virtual Router IP Address Parental Association) on the parental IP interface must already exist. If an associated IP address on the parental IP interface is not configured, the virtual router IP address assignment fails.
- Parent Primary IP Address Changed
When a virtual router IP address is set and the associated parent IP interface IP address is changed, the new parent IP interface IP address is evaluated to ensure it meets the association rules defined in backup Owner Virtual Router IP Address Parental Association or Non-Owner Virtual Router IP Address Parental Association. If the association check fails, the parental IP address change is not allowed. If the parental IP address change fails, the previously configured IP address definition remains in effect.
Only the primary parent IP address can be changed. Parent Primary IP Address Removal describes IP address removal conditions.
- Parent Primary IP Address Removal
When a virtual router IP address is successfully set, but removing the associated parent IP interface IP address is attempted and fails. All virtual router IP addresses associated with the parental IP interface IP address must be deleted before removing the parental IP address. This includes virtual router IP address associations from multiple virtual router instances on the IP interface.
Parameters
- ip-address
Specifies the virtual router IP address, in dotted-decimal notation. The IP virtual router IP address must be in the same subnet of the parental IP interface IP address or equal to the primary IP address for owner virtual router instances.
bfd-enable
Syntax
[no] bfd-enable [service-id] interface interface-name dst-ip ip-address
[no] bfd-enable interface interface-name dst-ip ip-address
Context
config>router>if>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This commands assigns a bidirectional forwarding (BFD) session providing heart-beat mechanism for the specific VRRP instance. There can be only one BFD session assigned to any specific VRRP instance, but there can be multiple VRRP sessions using the same BFD session.
By enabling BFD on a specific protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set by the BFD command under the IP interface. The specified interface may not be configured with BFD; when it is, the virtual router will then initiate the BFD session.
The no form of this command removes BFD from the configuration.
Parameters
- service-id
Specifies the service ID of the interface running BFD.
- interface interface-name
Specifies the name of the interface running BFD. The specified interface may not yet be configured with BFD. However, when it is, this virtual router will then initiate the BFD session.
- dst-ip ip-address
Specifies the destination address to be used for the BFD session.
init-delay
Syntax
init-delay seconds
no init-delay
Context
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures a VRRP initialization delay timer.
Parameters
- seconds
Specifies the initialization delay timer for VRRP, in seconds.
master-int-inherit
Syntax
[no] master-int-inherit
Context
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command enables the virtual router instance to inherit the master VRRP router 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 VRRP advertisement message advertisement interval field value or the message is discarded.
The no form of this command reverts to the default operating condition which requires the locally configured message-interval to match the received VRRP advertisement message advertisement interval field value.
Default
no master-int-inherit
message-interval
Syntax
message-interval {[seconds] [milliseconds milliseconds]}
no message-interval
Context
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
When a non-owner is operating as master for the virtual router, the configured message-interval is used as the operational advertisement timer similar to an owner virtual router instance. The master-int-inherit command has no effect when operating as master.
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 advertisement messages that are fragmented contain IP options (IPv4) 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.
In 7210, the least timer values supported is 1 second. Timers less than 1 second cannot be used.
The no form of this command reverts to the default value.
Default
1 second
Parameters
- seconds
Specifies the number of seconds that will transpire before the advertisement timer expires expressed as a decimal integer.
- milliseconds milliseconds
Specifies the time interval, in milliseconds, between sending advertisement messages.
policy
Syntax
policy policy-id
no policy
Context
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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 this command removes existing VRRP priority control policy associations from the virtual router instance. All associations must be removed before deleting the policy from the system.
Default
no policy
Parameters
- policy-id
Specifies the policy ID of the VRRP priority control, expressed as a decimal integer. The vrrp-policy-id must already exist for the command to function.
preempt
Syntax
[no] preempt
Context
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command overrides an existing VRRP master if the virtual router in-use priority is higher than the current master.
The priority of the non-owner virtual router instance, the preempt mode allows the best available virtual router to force itself as the master over other available virtual routers.
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 effect 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.
A master non-owner virtual router only allows itself to be preempted when the incoming VRRP advertisement message priority field value is one of the following:
Greater than the virtual router in-use priority value.
Equal to the in-use priority value and the source IP address (primary IP address) is greater than the virtual router instance primary IP address.
By default, preempt mode is enabled on the virtual router instance.
The no form of this command disables preempt mode and prevents the non-owner virtual router instance from preempting another, less desirable virtual router.
priority
Syntax
priority base-priority
no priority
Context
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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 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 this command reverts to the default value.
Default
100
Parameters
- base-priority
Specifies the base priority used by the virtual router instance, expressed as a decimal integer. If no VRRP priority control policy is defined, the base-priority is the in-use priority for the virtual router instance.
ping-reply
Syntax
[no] ping-reply
Context
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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 for 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 command 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 this command configures discarding all ICMP echo request messages destined for the non-owner virtual router instance IP addresses.
Default
no ping-reply
shutdown
Syntax
[no] shutdown
Context
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Special Cases
- Non-Owner Virtual Router
Non-owner virtual router instances can be administratively shutdown. This allows the termination of VRRP participation in the virtual router and stops all routing and other access capabilities with regards to the virtual router IP addresses. Shutting down the virtual router instance provides a mechanism to maintain the virtual routers without causing false backup/master state changes.
If the shutdown command is executed, no VRRP advertisement messages are generated and all received VRRP advertisement messages are silently discarded with no processing.
By default, virtual router instances are created in the no shutdown state.
Whenever the administrative state of a virtual router instance transitions, a log message is generated.
Whenever the operational state of a virtual router instance transitions, a log message is generated.
- Owner Virtual Router
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.
- VRRP Protocol Handling
On all 7210 SAS platforms, VRRP is created in the no shutdown state.
On the 7210 SAS-Mxp, the protocol is handled as follows.
The configure>router>if>vrrp command instantiates the protocol in the no shutdown state and resources are allocated to enable the node to process the protocol.
To deallocate resources, you must issue the configure>router>if>vrrp>shutdown and configure>router>if>no vrrp commands to allow the node to boot up correctly after the reboot. It is not sufficient to only issue a configure>router>if>vrrp>shutdown command.
Note:The resources for VRRP are allocated when the VRRP context is enabled either in the base routing instance or the VPRN service instance. Resources are deallocated when the configuration of the last VRRP context under either base routing instances or VPRN service is removed.
- VRRPv3 Protocol Handling
On all 7210 SAS platforms, VRRPv3 is created in the no shutdown state.
On the 7210 SAS-Mxp, the protocol is handled as follows.
The configure>router>if>ipv6>vrrp command instantiates the protocol in the no shutdown state and resources are allocated to enable the node to process the protocol.
To deallocate resources, you must issue the configure>router>if>ipv6>vrrp>shutdown and configure>router>if>ipv6>no vrrp commands to allow the node to boot up correctly after the reboot. It is not sufficient to only issue a configure>router>if>ipv6>vrrp>shutdown command.
Note:The resources for VRRPv3 are allocated when the VRRPv3 context is enabled either in the base routing instance, or in the VPRN service instance. Resources are deallocated when the configuration of the last VRRPv3 context, under either base routing instances or VPRN service, is removed.
ssh-reply
Syntax
[no] ssh-reply
Context
config>router>if>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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 this command discards all SSH request messages destined for the non-owner virtual router instance IP addresses.
Default
no ssh-reply
standby-forwarding
Syntax
[no] standby-forwarding
Context
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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 real MAC address. When enabled, a standby router should forward all traffic.
telnet-reply
Syntax
[no] telnet-reply
Context
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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 for 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.
The no form of this command configures discarding all Telnet request messages destined to the non-owner virtual router instance IP addresses.
Default
no telnet-reply
traceroute-reply
Syntax
[no] traceroute-reply
Context
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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.
Default
no traceroute-reply
vrrp
Syntax
vrrp vrid [owner]
no vrrp vrid
Context
config>router>interface
config>router>if>ipv6 (7210 SAS-Mxp only)
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures 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. When 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. For IPv6, only one vrrp vrid node can be configured on a router interface. Each virtual router instance can manage up to 16 backup IP addresses.
The no form of this 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.
Default
no vrrp
Special Cases
- Virtual Router Instance Owner IP Address Conditions
It is possible for the virtual router instance owner to be created before assigning the parent IP interface primary IP address. 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.
- VRRP Owner Command Exclusions
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 because of 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 vrrpvrid instance.
traceroute-reply
Parameters
- vrid
Specifies the virtual router ID for the IP interface, expressed as a decimal integer.
- owner
Specifies 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. When 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.
Priority policy commands
delta-in-use-limit
Syntax
delta-in-use-limit in-use-priority-limit
no delta-in-use-limit
Context
config>vrrp>policy
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures 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.
When 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 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 this command reverts to the default value.
Default
1
Parameters
- in-use-priority-limit
Specifies the lower limit of the in-use priority base, as modified by priority control policies. The limit has the same range as the non-owner virtual router instance base-priority parameter. If the result of the total delta priority control events minus the virtual router instances base-priority is less than the in-use-priority-limit, the in-use-priority-limit value is used as the virtual router instances in-use priority value.
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.
description
Syntax
description string
no description
Context
config>vrrp>policy
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command creates a text description for a configuration context to help identify the content in the configuration file.
The no form of this command removes the string from the configuration.
Parameters
- string
Specifies the description character string. Allowed values are any string up to 80 characters composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, and so on), the entire string must be enclosed within double quotes.
policy
Syntax
policy policy-id [context service-id]
no policy policy-id
Context
config>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures 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 this 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.
Parameters
- vrrp-policy-id
Specifies the VRRP priority control ID, expressed as a decimal integer, that uniquely identifies this policy from any other VRRP priority control policy defined on the system. Up to 1000 policies can be defined.
- context service-id
Specifies the service ID to which this policy applies. A value of zero (0) means that this policy does not apply to a service but applies to the base router instance.
priority-event
Syntax
[no] priority-event
Context
config>vrrp>policy
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures 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 this command clears any configured priority events.
Priority policy event commands
hold-clear
Syntax
hold-clear seconds
no hold-clear
Context
config>vrrp>policy>priority-event>port-down
config>vrrp>policy>priority-event>lag-port-down
config>vrrp>policy>priority-event>route-unknown
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures the hold clear time for the event.
The hold-clear time is used to prevent blackhole 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.
Default
no hold-clear
Parameters
- seconds
Specifies the amount of time in seconds by which the effect of a cleared event on the associated virtual router instance is delayed.
hold-set
Syntax
hold-set seconds
no hold-set
Context
config>vrrp>policy>priority-event>host-unreachable
config>vrrp>policy>priority-event>lag-port-down
config>vrrp>policy>priority-event>port-down
config>vrrp>policy>priority-event>route-unknown
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command specifies the amount of time that must pass before the set state for a VRRP priority control event can transition to the cleared state to dampen flapping events. A flapping event continually transitions between clear and set.
The hold-set command 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. 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.
When 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 this command reverts the default value.
Default
0
Parameters
- seconds
Specifies the number of seconds that the hold-set timer waits after an event enters a set state or enters a higher threshold set state, depending on the event type.
The value of 0 disables the hold-set timer, preventing any delay in processing lower set thresholds or cleared events.
priority
Syntax
priority priority-level [{delta | explicit}]
no priority
Context
config>vrrp>policy>priority-event>host-unreachable
config>vrrp>policy>priority-event>lag-port-down>number-down
config>vrrp>policy>priority-event>port-down
config>vrrp>policy>priority-event>route-unknown
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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 any set events have an explicit priority value, all the delta priority values are ignored.
The set event with the lowest explicit priority value defines the in-use priority that are used by all virtual router instances associated with the policy.
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, therefore, there is no impact on the in-use priority.
The no form of this command reverts to the default values.
Default
0
Parameters
- priority-level
Specifies the priority level adjustment value, expressed as a decimal integer.
- delta | explicit
Specifies what effect the priority-level will have on the base priority value.
When delta is specified, the priority-level value is subtracted from the associated virtual router instance 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.
Priority policy port down event commands
port-down
Syntax
[no] port-down port-id
Context
config>vrrp>policy>priority-event
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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, 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 will indicate:
Set – non-provisioned
Set – not populated
Set – down
Cleared – up
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. When 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 this 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.
Default
no port-down
Parameters
- port-id
Specifies the port ID of the port monitored by the VRRP priority control event.
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.
Priority policy LAG events commands
lag-port-down
Syntax
[no] lag-port-down lag-id
Context
config>vrrp>policy>priority-event
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures 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:
Set – non-existent
Set – one port down
Set – two ports down
Set – three ports down
Set – four ports down
Cleared – all ports up
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 enter 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 this 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.
Default
no lag-port-down
Parameters
- lag-id
Specifies 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 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.
number-down
Syntax
[no] number-down number-of-lag-ports-down
Context
config>vrrp>policy>priority-event>lag-port-down
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures 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 specific threshold, that is the active threshold.
The no form of this 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.
Default
no number-down
Parameters
- number-of-lag-ports-down
Specifies the number of LAG ports down to create a set event threshold. This is the active threshold when the number of down ports in the LAG equals or exceeds number-of-lag-ports-down, but does not equal or exceed the next highest configured number-of-lag-ports-down.
Priority policy host unreachable event commands
drop-count
Syntax
drop-count consecutive-failures
no drop-count
Context
config>vrrp>priority-event>host-unreachable
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures the number of consecutively sent ICMP echo request messages that must fail before the host unreachable priority control event is set.
The drop-count command is used to define the number of consecutive message send attempts that must fail for the host-unreachable priority event to enter the set state. Each unsuccessful attempt increments the event consecutive message drop counter. With each successful attempt, the event consecutive message drop counter resets to zero.
If the event consecutive message drop counter reaches the drop-count value, the host-unreachable priority event enters the set state.
The event hold-set value defines how long the event must stay in the set state even when a successful message attempt clears the consecutive drop counter. The event is not cleared until the consecutive drop counter is less than the drop-count value and the hold-set timer has a value of zero (expired).
The no form of this command reverts to the default value.
Default
3
Parameters
- consecutive-failures
Specifies the number of ICMP echo request message attempts that must fail for the event to enter the set state. It also defines the threshold so a lower consecutive number of failures can clear the event state.
host-unreachable
Syntax
[no] host-unreachable ip-address
Context
config>vrrp>policy>priority-event
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures 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 following table lists the possible operational states of the host-unreachable event.
| Host unreachable operational state | Description |
|---|---|
Set – no ARP |
No ARP address found for ip-address for drop-count consecutive attempts. Only applies when IP address is considered local. |
Set – no route |
No route exists for ip-address for drop-count consecutive attempts. Only applies when IP address is considered remote. |
Set – host unreachable |
ICMP host unreachable message received for drop-count consecutive attempts. |
Set – no reply |
ICMP echo request timed out for drop-count consecutive attempts. |
Set – reply received |
Last ICMP echo request attempt received an echo reply but historically not able to clear the event. |
Cleared – no ARP |
No ARP address found for ip-address - not enough failed attempts to set the event. |
Cleared – no route |
No route exists for ip-address - not enough failed attempts to set the event. |
Cleared – host unreachable |
ICMP host unreachable message received - not enough failed attempts to set the event. |
Cleared – no reply |
ICMP echo request timed out - not enough failed attempts to set the event. |
Cleared – reply received |
Event is cleared - last ICMP echo request received an echo reply. |
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 result of the last attempt. It is possible for the previous attempt to fail while the operational state is still cleared due to an insufficient number of failures to cause it to become set. It is also possible for the state to be set while the previous attempt was successful.
When an event transitions from clear to set, the set is processed immediately and must be reflected in the associated virtual router 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 must be expired and the historical success rate must be met before the event operational state becoming cleared.
The no form of this 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 hold-set timer has no effect on the removal procedure.
Default
no host-unreachable
Parameters
- ip-address
Specifies the IP address of the host for which the specific event will monitor connectivity. The ip-address 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.
interval
Syntax
interval seconds
no interval
Context
config>vrrp>priority-event>host-unreachable
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command configures the number of seconds between host unreachable priority event ICMP echo request messages directed to the host IP address.
The no form of this command reverts to the default value.
Default
1
Parameters
- seconds
Specifies the number of seconds between the ICMP echo request messages sent to the host IP address for the host unreachable priority event.
timeout
Syntax
timeout seconds
no timeout
Context
config>vrrp>priority-event>host-unreachable
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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 one of the following occurs.
An internal error occurs preventing message sending (request unsuccessful).
An internal error occurs preventing message reply receiving (request unsuccessful).
A required route table entry does not exist to reach the IP address (request unsuccessful).
A required ARP entry does not exist and ARP request timed out (request unsuccessful).
A valid reply is received (request successful).
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 before the timeout period for a specific 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 before 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 this command reverts to the default value.
Default
1
Parameters
- seconds
Specifies the number of seconds before an ICMP echo request message is timed out. When a message is timed out, a reply with the same identifier and sequence number is discarded.
Priority policy route unknown event commands
less-specific
Syntax
[no] less-specific [allow-default]
Context
config>vrrp>policy>priority-event>route-unknown
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command enables 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 this command prevents RTM lookup results that are less specific than the route prefix from matching.
Default
no less-specific
Parameters
- allow-default
Specifies that 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).
next-hop
Syntax
[no] next-hop ip-address
Context
config>vrrp>policy>priority-event>route-unknown
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command adds an enabled 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 this 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.
Default
no next-hop
Parameters
- ip-address
Specifies the IP address for an acceptable next hop IP address for a returned route prefix from the RTM when looking up the route-unknown route prefix.
protocol
Syntax
protocol {ospf | is-is | static}
no protocol
Context
config>vrrp>policy>priority-event>route-unknown
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
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 this 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.
Default
no protocol
Parameters
- ospf
Specifies OSPF as an eligible route source for a returned route prefix from the RTM when looking up the route-unknown route prefix. The ospf parameter is not exclusive from the other available protocol parameters. If protocol is executed without the ospf parameter, a returned route prefix with a source of OSPF will not be considered a match and will cause the event to enter the set state.
- is-is
Specifies IS-IS as an eligible route source for a returned route prefix from the RTM when looking up the route-unknown route prefix. The is-is parameter is not exclusive from the other available protocol parameters. If protocol is executed without the is-is parameter, a returned route prefix with a source of IS-IS will not be considered a match and will cause the event to enter the set state.
- static
Specifies a static route as an eligible route source for a returned route prefix from the RTM when looking up the route-unknown route prefix. The static parameter is not exclusive from the other available protocol parameters. If protocol is executed without the static parameter, a returned route prefix with a source of static route will not be considered a match and will cause the event to enter the set state.
route-unknown
Syntax
[no] route-unknown prefix/mask-length
Context
config>vrrp>policy>priority-event
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command enables 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 described in the following table.
| route-unknown operational state | Description |
|---|---|
Set – non-existent |
The route does not exist in the route table |
Set – inactive |
The route exists in the route table but is not being used |
Set – wrong next hop |
The route exists in the route table but does not meet the next-hop requirements |
Set – wrong protocol |
The route exists in the route table but does not meet the protocol requirements |
Set – less specific found |
The route exists in the route table but does is not an exact match and does not meet any less-specific requirements |
Set – default best match |
The route exists in the route table as the default route but the default route is not allowed for route matching |
Cleared – less specific found |
A less specific route exists in the route table and meets all criteria including the less-specific requirements |
Cleared – found |
The route exists in the route table manager and meets all criteria |
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 that matches all the preceding criteria (if defined in the event control commands) is not found, 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 this 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.
Default
no route-unknown
Parameters
- prefix
Specifies the IP prefix address to be monitored by the route unknown priority control event, in dotted decimal notation.
- mask-length
Specifies the subnet mask length, expressed as a decimal integer, associated with the IP prefix defining the route prefix to be monitored by the route unknown priority control event.
- ip-address
Specifies the IP address of the host for which the specific event will monitor connectivity. The ip-address 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-address 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.
Show commands
instance
Syntax
instance interface interface-name [vrid virtual-router-id]
Context
show>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays information for VRRP instances.
If no command line options are specified, summary information for all VRRP instances displays.
Parameters
- interface interface-name
Displays detailed information for the VRRP instances on the specified IP interface including status and statistics.
- vrid virtual-router-id
Displays detailed information for the specified VRRP instance on the IP interface.
Output
The following output is an example of VRRP instance information, and Output fields: VRRP instance describes the output fields.
Sample output*A:ALA-A# show router vrrp instance
===============================================================================
VRRP Instances
===============================================================================
Interface Name VR Id Own Adm State Base Pri Msg Int
IP Opr Pol Id InUse Pri Inh Int
-------------------------------------------------------------------------------
n2 1 No Up Master 100 1
IPv4 Up n/a 100 No
Backup Addr: 5.1.1.10
-------------------------------------------------------------------------------
Instances : 2
===============================================================================
*A:ALA-A#
*A:ALA-A# show router vrrp instance interface n2 vrid 1
===============================================================================
VRRP Instance 1 for interface "n2"
===============================================================================
Owner : No VRRP State : Master
Primary IP of Master: 5.1.1.2 (Self)
Primary IP : 5.1.1.2 Standby-Forwarding: Disabled
VRRP Backup Addr : 5.1.1.10
Admin State : Up Oper State : Up
Up Time : 09/23/2004 06:53:45 Virt MAC Addr : 00:00:5e:00:01:01
Auth Type : None
Config Mesg Intvl : 1 In-Use Mesg Intvl : 1
Master Inherit Intvl: No
Base Priority : 100 In-Use Priority : 100
Policy ID : n/a Preempt Mode : Yes
Ping Reply : No Telnet Reply : No
SSH Reply : No Traceroute Reply : No
Init Delay : 0 Init Timer Expires: 0.000 sec
Creation State : Active
-------------------------------------------------------------------------------
Master Information
-------------------------------------------------------------------------------
Primary IP of Master: 5.1.1.2 (Self)
Addr List Mismatch : No Master Priority : 100
Master Since : 09/23/2004 06:53:49
-------------------------------------------------------------------------------
Masters Seen (Last 32)
-------------------------------------------------------------------------------
Primary IP of Master Last Seen Addr List Mismatch Msg Count
-------------------------------------------------------------------------------
5.1.1.2 09/23/2004 06:53:49 No 0
-------------------------------------------------------------------------------
Statistics
-------------------------------------------------------------------------------
Become Master : 1 Master Changes : 1
Adv Sent : 103 Adv Received : 0
Pri Zero Pkts Sent : 0 Pri Zero Pkts Rcvd: 0
Preempt Events : 0 Preempted Events : 0
Mesg Intvl Discards : 0 Mesg Intvl Errors : 0
Addr List Discards : 0 Addr List Errors : 0
Auth Type Mismatch : 0 Auth Failures : 0
Invalid Auth Type : 0 Invalid Pkt Type : 0
IP TTL Errors : 0 Pkt Length Errors : 0
Total Discards : 0
===============================================================================
*A:ALA-A#
7210SAS>show>router# vrrp instance interface "n1" vrid 1
===============================================================================
VRRP Instance 1 for interface "n1"
===============================================================================
Owner : No VRRP State : Init
Primary IP of Master: 0.0.0.0 (Self)
Primary IP : 0.0.0.0 Standby-Forwarding: Disabled
VRRP Backup Addr : None
Admin State : Up Oper State : Down
Up Time : 02/16/2000 02:01:54 Virt MAC Addr : 00:00:5e:00:01:01
Auth Type : None
Config Mesg Intvl : 1 In-Use Mesg Intvl : 1
Master Inherit Intvl: No
Base Priority : 100 In-Use Priority : 100
Policy ID : n/a Preempt Mode : Yes
Ping Reply : No Telnet Reply : No
SSH Reply : No Traceroute Reply : No
Init Delay : 0 Init Timer Expires: 0.000 sec
Creation State : Init
-------------------------------------------------------------------------------
Master Information
-------------------------------------------------------------------------------
Primary IP of Master: 0.0.0.0 (Self)
Addr List Mismatch : Unknown Master Priority : 0
Master Since : 02/16/2000 02:01:54
-------------------------------------------------------------------------------
Masters Seen (Last 32)
-------------------------------------------------------------------------------
Primary IP of Master Last Seen Addr List Mismatch Msg Count
-------------------------------------------------------------------------------
None
-------------------------------------------------------------------------------
Statistics
-------------------------------------------------------------------------------
Become Master : 0 Master Changes : 0
Adv Sent : 0 Adv Received : 0
Pri Zero Pkts Sent : 0 Pri Zero Pkts Rcvd: 0
Preempt Events : 0 Preempted Events : 0
Mesg Intvl Discards : 0 Mesg Intvl Errors : 0
Addr List Discards : 0 Addr List Errors : 0
Auth Type Mismatch : 0 Auth Failures : 0
Invalid Auth Type : 0 Invalid Pkt Type : 0
IP TTL Errors : 0 Pkt Length Errors : 0
Total Discards : 0
===============================================================================
7210SAS>show>router#
| Label | Description |
|---|---|
Interface name |
The name of the IP interface |
VR ID |
The virtual router ID for the IP interface |
Own Owner |
Yes — Specifies that the virtual router instance as owning the virtual router IP addresses |
No — Indicates that the virtual router instance is operating as a non-owner |
|
Adm |
Up — Indicates that the administrative state of the VRRP instance is up |
Down — Indicates that the administrative state of the VRRP instance is down |
|
Opr |
Up — Indicates that the operational state of the VRRP instance is up |
Down — Indicates that the operational state of the VRRP instance is down |
|
State |
When owner, backup defines the IP addresses that are advertised within VRRP advertisement messages. When non-owner, backup 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). |
Pol ID |
The value that uniquely identifies a Priority Control Policy |
Base Priority |
The base-priority value is used to derive the in-use priority of the virtual router instance as modified by any optional VRRP priority control policy. |
InUse Priority |
The current in-use priority associated with the VRRP virtual router instance |
Msg Int |
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 |
Inh Int |
Yes — When the VRRP instance is a non-owner and is operating as a backup and the master-int-inherit command is enabled, the master down timer is indirectly derived from the value in the advertisement interval field of the VRRP message received from the current master. |
No — When the VRRP instance is operating as a backup and the master-int-inherit command is not enabled, the configured advertisement interval is matched against the value in the advertisement interval field of the VRRP message received from the current master. If the two values do not match, then the VRRP advertisement is discarded. If the VRRP instance is operating as a master, this value has no effect. |
|
Backup Addr |
The backup virtual router IP address |
BFD |
Indicates BFD is enabled. |
VRRP State |
Specifies whether the VRRP instance is operating in a master or backup state |
Policy ID |
The VRRP priority control policy associated with the VRRP virtual router instance A value of 0 indicates that no control policy is associated with the virtual router instance |
Preempt Mode |
Yes — The preempt mode is enabled on the virtual router instance where it will preempt a VRRP master with a lower priority |
No — The preempt mode is disabled and prevents the non-owner virtual router instance from preempting another, less desirable virtual router |
|
Ping Reply
|
Yes — A non-owner master is enabled to reply to ICMP Echo requests directed to the virtual router instance IP addresses Ping Reply is valid only if the VRRP virtual router instance associated with this entry is a non-owner A non-owner backup virtual router never responds to such ICMP echo requests irrespective if Ping Reply is enabled |
No — ICMP echo requests to the virtual router instance IP addresses are discarded |
|
Telnet Reply |
Yes — Non-owner masters can to reply to TCP port 23 Telnet requests directed at the virtual router instances IP addresses |
No — Telnet requests to the virtual router instance IP addresses are discarded |
|
SSH Reply |
Yes — Non-owner masters can to reply to SSH requests directed at the virtual router instances IP addresses |
No — All SSH request messages destined for the non-owner virtual router instance IP addresses are discarded |
|
Primary IP of Master |
The IP address of the VRRP master |
Primary IP |
The IP address of the VRRP owner |
Up Time |
The date and time when the operational state of the event last changed |
Virt MAC Addr |
The virtual MAC address used in ARP responses when the VRRP virtual router instance is operating as a master |
Auth Type |
Specifies the VRRP authentication Type 0 (no authentication), Type 1 (simple password), or Type 2 (MD5) for the virtual router |
Addr List Mismatch |
Specifies whether a trap was generated when the IP address list received in the advertisement messages received from the current master did not match the configured IP address list. This is an edge triggered notification. A second trap will not be generated for a packet from the same master until this event has been cleared. |
Master Priority |
The priority of the virtual router instance which is the current master |
Master Since |
The date and time when operational state of the virtual router changed to master For a backup virtual router, this value specifies the date and time when it received the first VRRP advertisement message from the virtual router which is the current master. |
policy
Syntax
policy [vrrp-policy-id [event event-type specific-qualifier]]
Context
show>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays VRRP priority control policy information.
If no command line options are specified, a summary of the VRRP priority control event policies displays.
Parameters
- vrrp-policy-id
Displays information about the specified priority control policy ID.
- event event-type
Displays information about the specified VRRP priority control event within the policy ID.
- specific-qualifier
Display information about the specified qualifier.
Output
The following outputs are examples of VRRP policy information. The associated tables describe the output fields.
Sample outputA:ALA-A# show vrrp policy
===============================================================================
VRRP Policies
===============================================================================
Policy Current Current Current Delta Applied
Id Priority & Effect Explicit Delta Sum Limit
-------------------------------------------------------------------------------
1 None None None 1 Yes
2 None None None 1 No
===============================================================================
A:ALA-A#
A:ALA-A# show vrrp policy 1
===============================================================================
VRRP Policy 1
===============================================================================
Description : 10.10.200.253 reachability
Current Priority: None Applied : No
Current Explicit: None Current Delta Sum : None
Delta Limit : 1
-------------------------------------------------------------------------------
Applied To VR Opr Base In-use Master Is
Interface Name Id Pri Pri Pri Master
-------------------------------------------------------------------------------
None
-------------------------------------------------------------------------------
Priority Control Events
-------------------------------------------------------------------------------
Event Type & ID Event Oper State Hold Set Priority In
Remaining &Effect Use
-------------------------------------------------------------------------------
Host Unreach 10.10.200.252 n/a Expired 20 Del No
Host Unreach 10.10.200.253 n/a Expired 10 Del No
Route Unknown 10.10.100.0/24 n/a Expired 1 Exp No
===============================================================================
A:ALA-A#
| Label | Description |
|---|---|
Policy Id |
The VRRP priority control policy associated with the VRRP virtual router instance A value of 0 indicates that no control policy is associated with the virtual router instance |
Current Priority & Effects |
|
Current Explicit |
When multiple explicitly defined events associated with the priority control policy happen simultaneously, the lowest value of all the current explicit priorities will be used as the in-use priority for the virtual router. |
Current Delta Sum |
The sum of the priorities of all the delta events when multiple delta events associated with the priority control policy happen simultaneously. This sum is subtracted from the base priority of the virtual router to give the in-use priority. |
Delta Limit |
The delta-in-use-limit for a VRRP policy. When the total sum of all delta events has been calculated and subtracted from the base-priority of the virtual router, the result is compared to the delta-in-use-limit value. If the result is less than this value, 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. If the delta-in-use-limit is 0, the sum of the delta priority control events to reduce the virtual router's in-use-priority to 0 can prevent it from becoming or staying master. |
Current Priority |
The configured delta-in-use-limit priority for a VRRP priority control policy or the configured delta or explicit priority for a priority control event |
Applied |
The number of virtual router instances to which the policy has been applied The policy cannot be deleted unless this value is 0 |
Description |
A text string which describes the VRRP policy |
Event Type & ID |
A delta priority event is a conditional event defined in a priority control policy that subtracts a specific amount from the base priority to give the current in-use priority for the VRRP virtual router instances to which the policy is applied. |
An explicit priority event is a conditional event defined in a priority control policy that explicitly defines the in-use priority for the VRRP virtual router instances to which the policy is applied. Explicit events override all delta Events. When multiple explicit events occur simultaneously, the event with the lowest priority value defines the in-use priority. |
|
Event Oper State |
The operational state of the event |
Hold Set Remaining |
The amount of time that must pass before the set state for a VRRP priority control event can transition to the cleared state to dampen flapping events. |
Priority & Effect |
Delta — The priority-level value is subtracted from the associated virtual router instance 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. |
Explicit — 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. |
|
In Use |
Specifies whether the event is currently affecting the in-use priority of some virtual router |
A:ALA-A#show vrrp policy 1 event port-down
===============================================================================
VRRP Policy 1, Event Port Down 1/1/1
===============================================================================
Description :
Current Priority: None Applied : Yes
Current Explicit: None Current Delta Sum : None
Delta Limit : 1
-------------------------------------------------------------------------------
Applied To VR Opr Base In-use Master Is
Interface Name Id Pri Pri Pri Master
-------------------------------------------------------------------------------
ies301backup 1 Down 100 100 0 No
-------------------------------------------------------------------------------
Priority Control Event Port Down 1/1/1
-------------------------------------------------------------------------------
Priority : 30 Priority Effect : Delta
Hold Set Config : 0 sec Hold Set Remaining: Expired
Value In Use : No Current State : Cleared
# trans to Set : 6 Previous State : Set-down
Last Transition : 04/13/2007 04:54:35
===============================================================================
A:ALA-A#
A:ALA-A# show vrrp policy 1 event host-unreachable
===============================================================================
VRRP Policy 1, Event Host Unreachable 10.10.200.252
===============================================================================
Description : 10.10.200.253 reachability
Current Priority: None Applied : No
Current Explicit: None Current Delta Sum : None
Delta Limit : 1
-------------------------------------------------------------------------------
Applied To VR Opr Base In-use Master Is
Interface Name Id Pri Pri Pri Master
-------------------------------------------------------------------------------
None
-------------------------------------------------------------------------------
Priority Control Event Host Unreachable 10.10.200.252
-------------------------------------------------------------------------------
Priority : 20 Priority Effect : Delta
Interval : 1 sec Timeout : 1 sec
Drop Count : 3
Hold Set Config : 0 sec Hold Set Remaining: Expired
Value In Use : No Current State : n/a
# trans to Set : 0 Previous State : n/a
Last Transition : 04/13/2007 23:10:24
===============================================================================
A:ALA-A#
A:ALA-A# show vrrp policy 1 event route-unknown
===============================================================================
VRRP Policy 1, Event Route Unknown 10.10.100.0/24
===============================================================================
Description : 10.10.200.253 reachability
Current Priority: None Applied : No
Current Explicit: None Current Delta Sum : None
Delta Limit : 1
-------------------------------------------------------------------------------
Applied To VR Opr Base In-use Master Is
Interface Name Id Pri Pri Pri Master
-------------------------------------------------------------------------------
None
-------------------------------------------------------------------------------
Priority Control Event Route Unknown 10.10.100.0/24
-------------------------------------------------------------------------------
Priority : 1 Priority Effect : Explicit
Less Specific : No Default Allowed : No
Next Hop(s) : None
Protocol(s) : None
Hold Set Config : 0 sec Hold Set Remaining: Expired
Value In Use : No Current State : n/a
# trans to Set : 0 Previous State : n/a
Last Transition : 04/13/2007 23:10:24
===============================================================================
A:ALA-A#
| Label | Description |
|---|---|
Description |
A text string which describes the VRRP policy |
Policy Id |
The VRRP priority control policy associated with the VRRP virtual router instance A value of 0 indicates that no control policy is associated with the virtual router instance |
Current Priority |
The base router priority for the virtual router instance used in the master election process |
Current Explicit |
When multiple explicitly defined events associated with the priority control policy happen simultaneously, the lowest value of all the current explicit priorities will be used as the in-use priority for the virtual router. |
Applied |
The number of virtual router instances to which the policy has been applied. The policy cannot be deleted unless this value is 0. |
Current Delta Sum |
The sum of the priorities of all the delta events when multiple delta events associated with the priority control policy happen simultaneously. This sum is subtracted from the base priority of the virtual router to give the in-use priority. |
Delta Limit |
The delta-in-use-limit for a VRRP policy. When the total sum of all delta events has been calculated and subtracted from the base-priority of the virtual router, the result is compared to the delta-in-use-limit value. If the result is less than this value, 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. If the delta-in-use-limit is 0, the sum of the delta priority control events to reduce the virtual router's in-use-priority to 0 can prevent it from becoming or staying master. |
Applied to Interface Name |
The interface name where the VRRP policy is applied |
VR ID |
The virtual router ID for the IP interface |
Opr |
Up — Indicates that the operational state of the VRRP instance is up |
Down — Indicates that the operational state of the VRRP instance is down |
|
Base Pri |
The base priority used by the virtual router instance |
InUse Priority |
The current in-use priority associated with the VRRP virtual router instance |
Master Priority |
The priority of the virtual router instance which is the current master |
Priority |
The base priority used by the virtual router instance |
Priority Effect |
Delta — A delta priority event is a conditional event defined in a priority control policy that subtracts a specific amount from the base priority to give the current in-use priority for the VRRP virtual router instances to which the policy is applied. |
Explicit — A conditional event defined in a priority control policy that explicitly defines the in-use priority for the VRRP virtual router instances to which the policy is applied. Explicit events override all delta events. When multiple explicit events occur simultaneously, the event with the lowest priority value defines the in-use priority. |
|
Current Priority |
The configured delta-in-use-limit priority for a VRRP priority control policy, or the configured delta, or explicit priority for a priority control event |
Event Oper State |
The operational state of the event |
Hold Set Remaining |
The amount of time that must pass before the set state for a VRRP priority control event can transition to the cleared state to dampen flapping events |
Priority |
The base priority used by the virtual router instance |
Priority Effect |
Delta — The priority-level value is subtracted from the associated virtual router instance 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. |
Explicit — 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. |
|
Hold Set Config |
The configured number of seconds that the hold-set timer waits after an event enters a set state or enters a higher threshold set state, depending on the event type. |
Value In Use |
Yes — The event is currently affecting the in-use priority of some virtual router |
No — The event is not affecting the in-use priority of some virtual router |
|
# trans to Set |
The number of times the event has transitioned to one of the 'set' states |
Last Transition |
The time and date when the operational state of the event last changed |
statistics
Syntax
statistics
Context
show>router>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command displays statistics for VRRP instance.
Output
The following output is an example of VRRP statistics information, and Output fields: VRRP statistics describes the output fields.
Sample outputA:ALA-48# show router vrrp statistics
===============================================================================
VRRP Global Statistics
===============================================================================
VR Id Errors : 0 Version Errors : 0
Checksum Errors : 0
===============================================================================
A:ALA-48#
| Label | Description |
|---|---|
VR Id Errors |
Displays the number of virtual router ID errors |
Version Errors |
Displays the number of version errors |
Checksum Errors |
Displays the number of checksum errors |
Monitor commands
instance
Syntax
instance interface interface-name vr-id virtual-router-id [interval seconds] [repeat repeat] [absolute | rate]
Context
monitor>router>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command monitors statistics for a VRRP instance.
Parameters
- interface interface-name
Specifies the name of the existing IP interface on which VRRP is configured.
- vr-id virtual-router-id
Specifies the virtual router ID for the existing IP interface, expressed as a decimal integer.
- interval seconds
Specifies the interval for each display, in seconds.
- repeat repeat
Specifies how many times the command is repeated.
- absolute
Specifies that the raw statistics are displayed, without processing. No calculations are performed on the delta or rate statistics.
- rate
Specifies that the rate-per-second for each statistic is displayed instead of the delta.
Output
The following output is an example of VRRP instance information.
Sample output*A:ALA-A# monitor router vrrp instance interface n2 vr-id 1
===============================================================================
Monitor statistics for VRRP Instance 1 on interface "n2"
===============================================================================
-------------------------------------------------------------------------------
At time t = 0 sec (Base Statistics)
-------------------------------------------------------------------------------
Become Master : 1 Master Changes : 1
Adv Sent : 1439 Adv Received : 0
Pri Zero Pkts Sent : 0 Pri Zero Pkts Rcvd: 0
Preempt Events : 0 Preempted Events : 0
Mesg Intvl Discards : 0 Mesg Intvl Errors : 0
Addr List Discards : 0 Addr List Errors : 0
Auth Type Mismatch : 0 Auth Failures : 0
Invalid Auth Type : 0 Invalid Pkt Type : 0
IP TTL Errors : 0 Pkt Length Errors : 0
Total Discards : 0
===============================================================================
*A:ALA-A#
Clear commands
interface
Syntax
interface ip-int-name [vrid virtual-router-id]
Context
clear>router>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command resets VRRP protocol instances on an IP interface.
Parameters
- ip-int-name
Specifies the IP interface to reset the VRRP protocol instances.
- vrid vrid
Resets the VRRP protocol instance for the specified VRID on the IP interface.
statistics
Syntax
statistics [policy policy-id]
Context
clear>router>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command clears and resets VRRP entities.
Parameters
- policy policy-id
Clears statistics for the specified policy.
statistics
Syntax
statistics interface interface-name [vrid virtual-router-id]
statistics policy [vrrp-policy-id]
Context
clear>router>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command clears statistics for VRRP instances on an IP interface or VRRP priority control policies.
Parameters
- interface interface-name
Clears the VRRP statistics for all VRRP instances on the specified IP interface.
- vrid virtual-router-id
Clears the VRRP statistics for the specified VRRP instance on the IP interface.
- policy [vrrp-policy-id]
Clears VRRP statistics for all or the specified VRRP priority control policy.
Debug commands
events
Syntax
events
events interface ip-int-name [vrid virtual-router-id]
no events
no events interface ip-int-name [vrid virtual-router-id]
Context
debug>router>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command enables debugging for VRRP events.
The no form of this command disables debugging.
Parameters
- ip-int-name
Displays the specified interface name.
- vrid virtual-router-id
Displays the specified VRID.
packets
Syntax
packets interface ip-int-name [vrid virtual-router-id]
packets
no packets interface ip-int-name [vrid virtual-router-id]
no packets
Context
debug>router>vrrp
Platforms
Supported on all 7210 SAS platforms as described in this document
Description
This command enables debugging for VRRP packets.
The no form of this command disables debugging.
Parameters
- ip-int-name
Displays the specified interface name.
- vrid virtual-router-id
Displays the specified VRID.