authentication-key [authentication-key | hash-key] [hash | hash2]
no authentication-key
config>router>if>vrrp
Supported on all 7210 SAS platforms as described in this document
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.
no 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.
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.
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.
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.
[no] backup ip-address
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
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
no backup
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.
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:
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) |
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) |
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.
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.
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.
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.
[no] bfd-enable [service-id] interface interface-name dst-ip ip-address
[no] bfd-enable interface interface-name dst-ip ip-address
config>router>if>vrrp
Supported on all 7210 SAS platforms as described in this document
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.
Specifies the service ID of the interface running BFD.
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.
Specifies the destination address to be used for the BFD session.
init-delay seconds
no init-delay
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
This command configures a VRRP initialization delay timer.
Specifies the initialization delay timer for VRRP, in seconds.
[no] master-int-inherit
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
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.
no master-int-inherit
message-interval {[seconds] [milliseconds milliseconds]}
no message-interval
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
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.
1 second
Specifies the number of seconds that will transpire before the advertisement timer expires expressed as a decimal integer.
Specifies the time interval, in milliseconds, between sending advertisement messages.
policy policy-id
no policy
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
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.
no policy
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.
[no] preempt
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
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 base-priority
no priority
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
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.
100
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.
[no] ping-reply
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
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.
no ping-reply
[no] shutdown
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
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.
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.
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.
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.
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.
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.
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.
[no] ssh-reply
config>router>if>vrrp
Supported on all 7210 SAS platforms as described in this document
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.
no ssh-reply
[no] standby-forwarding
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
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.
[no] telnet-reply
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
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.
no telnet-reply
[no] traceroute-reply
config>router>if>vrrp
config>router>if>ipv6>vrrp (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
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.
no traceroute-reply
vrrp vrid [owner]
no vrrp vrid
config>router>interface
config>router>if>ipv6 (7210 SAS-Mxp only)
Supported on all 7210 SAS platforms as described in this document
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.
no vrrp
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.
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
Specifies the virtual router ID for the IP interface, expressed as a decimal integer.
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.