Troubleshooting high availability

Troubleshooting VRRP

Master/backup state change for the VRRP group

Symptom

The master and backup states of the devices have changed in the VRRP group. Log in to the two devices in the VRRP group separately, and execute the display vrrp command:

·     In the command output, if the State field value is Master on one device and is Backup on the other device, the VRRP group is operating correctly, and no action is required.

·     If other conditions exist, take relevant actions as described in this document.

<Sysname> display vrrp

IPv4 Virtual Router Information:

 Running Mode      : Standard

 Enhanced sending of gratuitous ARP packets : Disabled

 Total number of virtual routers : 1

 Interface          VRID  State        Running Adver   Auth     Virtual

                                       Pri     Timer   Type        IP

 ---------------------------------------------------------------------

 GE2/0/1            1     Master       150     100     Simple   1.1.1.1

Common causes

The following are the common causes of this type of issue:

·     An interface event is received. The state of the interface configured with the VRRP group has changed.

·     The virtual IP address of the VRRP group is deleted.

·     The status of the track entry associated with the VRRP group has changed.

·     The master receives a VRRP packet with a higher priority.

·     The current device becomes the IP address owner.

·     Upon expiration of the timer, the backup has not received any VRRP packet from the master.

·     The backup receives a packet with a priority of 0.

·     A preemption occurs.

·     The VRRP group is associated with a master VRRP group. A state change in master VRRP group results in a state change in the subordinate VRRP group.

Analysis

Figure 1 shows the troubleshooting flowchart.

Figure 1 Flowchart for troubleshooting master/backup state change of the VRRP group

 

Solution

1.     To resolve the issue:

2.     Log in to the two devices in the VRRP group separately and execute the display logbuffer | include VRRP_STATUS_CHANGE command. Obtain the log with the VRRP_STATUS_CHANGE digest. This log carries the state of the device in the VRRP group and the reason for the state change.

¡     The states of a device in the VRRP group include:

-     Master—Indicates that the device is the master in the VRRP group.

-     Backup—Indicates that the device is the backup in the VRRP group.

-     Initialize—Indicates that the VRRP group is disabled on the device.

-     Inactive—Indicates that the VRRP group is in invalid state. The reason might be that the virtual IP address is not configured, or the VRRP group is associated with a nonexistent master VRRP group.

¡     The state change reasons for the VRRP group of the device include:

-     Interface event received—Indicates that an interface event has been received, and the state of the interface configured with the VRRP group has changed (reason 1).

-     IP address deleted—The virtual IP address of the VRRP group has been deleted (reason 2).

-     The status of the tracked object changed—The status of the track entry associated with the VRRP group has changed (reason 3).

-     VRRP packet received—The master received a VRRP packet with a higher priority (reason 4).

-     Current device has changed to IP address owner—The current device has become the IP address owner (reason 5).

-     Master-down-timer expired—Upon expiration of the master-down-timer, the backup has not received any VRRP packet from the master (reason 6).

-     Zero priority packet received—The backup has received a packet with a priority of 0 (reason 7).

-     Preempt—A preemption has occurred (reason 8).

For example, the following log indicates that the state of the VRRP group on interface GigabitEthernet 2/0/1 has changed from Master to Initialize due to a state change of interface GigabitEthernet 2/0/1.

<Sysname> display logbuffer | include VRRP_STATUS_CHANGE

%Mar 12 14:10:32:110 2023 Sysname VRRP4/6/VRRP_STATUS_CHANGE: The status of IPv4 virtual router 1 (configured on GigabitEthernet2/0/1) changed from Master to Initialize: Interface event received.

3.     Take relevant actions based on the VRRP state in the log and the state change reason.

¡     For reason 1 (an interface event has been received, and the state of the interface configured with the VRRP group has changed):

Execute the display interface command on both the local and remote ends to view the state of the connected interfaces of the VRRP group. If the interface state is Down, locate and resolve the interface failure based on the output information.

¡     For reason 2 (the virtual IP address of the VRRP group has been deleted): Execute the vrrp [ ipv6 ] vrid command in interface view to configure a virtual IP address for the VRRP group.

¡     For reason 3 (state change of the track entry associated with the VRRP group), first execute the display vrrp [ ipv6 ] command to obtain the ID of the associated track entry, and then use the display track command to locate and resolve the track entry fault.

¡     For reason 4 (the master received a VRRP packet with a higher priority), no action is required.

¡     For reason 5 (the current device has become the IP address owner), as a best practice, take the following actions:

Identify whether the local device is required to be configured as the IP address owner of the VRRP group: Execute the display vrrp [ ipv6 ] command without parameters on the local device to view the virtual IP address of the VRRP group, and execute the display interface brief command on the local device to view the device interface IP address. If the IP address of an interface on the device in the VRRP group is the same as the virtual IP address of the VRRP group, the device is called the IP address owner. If the VRRP group contains an IP address owner, it acts as the master as long as it is operating correctly.

-     If the device is required to be configured as the IP address owner, no action is required.

-     If the device is not required to be configured as the IP address owner, execute the vrrp [ ipv6 ] vrid command in interface view to edit the virtual IP address of the VRRP group.

¡     For reason 6 (the backup has not received any VRRP packet from the master upon expiration of the timer):

-     Identify whether the peer device is faulty. Execute the display vrrp [ ipv6 ] command on the peer device. If the value for the State field is Initialize, VRRP fails to operate on this device. Identify the failure reason and restore the peer device.

-     Identify whether the connected interfaces of the VRRP group are faulty. Execute the display interface command on both the local and peer devices to view the connected interface state of the VRRP group. If the interface state is Down, locate and resolve the interface failure based on the output information.

-     Identify whether the VRRP configuration is incorrect by executing the display current-configuration | inculde vrrp command on the local and peer devices. The VRRP settings on the local and peer devices must meet the following requirements:

-     The VRRP group number and virtual IP address settings must be the same on the local and peer devices. If they are different, configure them again with the vrrp [ ipv6 ] vrid command.

-     IPv4 VRRP requires version consistency. If the versions are inconsistent, execute the vrrp version command in interface view to edit the version number. IPv6 VRRP supports only VRRPv3 that is not configurable.

-     IPv4 VRRP requires authentication mode consistency. In addition, make sure authentication keys, if configured, are consistent. If the previous settings are inconsistent, execute the vrrp vrid authentication-mode command in interface view to edit the settings. IPv6 VRRP does not support authentication.

¡     For reason 7 (the backup has received a packet with a priority of 0), as a best practice, take the following actions:

-     Execute the display vrrp [ ipv6 ] verbose command on the local and peer devices to view the configured VRRP priority (Config pri field).

If the configuration is correct, no action is required.

If the configuration is incorrect, execute the vrrp [ ipv6 ] vrid priority command in interface view to edit the configuration.

-     Execute the display vrrp [ ipv6 ] verbose command on the local and peer devices to view the configured VRRP priority (Config pri field) and effective VRRP priority (Running pri field). If the values are inconsistent, obtain the associated track entry number, and the use the display track command to locate and resolve the track entry fault.

¡     For reason 8 (a preemption has occurred):

-     If the preemption is manually triggered by the administrator, no action is required.

-     If the preemption is automatically performed, the monitored object is faulty, and you need to further locate the reason for the automatic preemption.

4.     Identify whether the state change of the VRRP group is due to the state change of the associated master VRRP group.

5.     Execute the display vrrp [ ipv6 ] verbose command on the local device to obtain the name of the associated master VRRP group from the Follow Name field.

¡     If the master VRRP group does not exist, execute the vrrp [ ipv6 ] vrid command to create the master VRRP group.

¡     If the master VRRP group already exists, further locate the reason for state change in the master VRRP group according to the reason field value provided in the master VRRP group log.

6.     If the issue persists, collect configuration data, log messages, and alarm information, and then contact H3C Support for help.

Related alarm and log messages

Alarm messages

Module name: VRRP-MIB

·     vrrpTrapNewMaster（1.3.6.1.2.1.68.0.1）

Module name: HH3C-VRRP-EXT-MIB (supported by only V7B75)

·     hh3cVrrpExtStateChange（1.3.6.1.4.1.25506.2.24.2.0.1）

Log messages

·     VRRP4/6/VRRP_STATUS_CHANGE

·     VRRP6/6/VRRP_STATUS_CHANGE