No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


Troubleshooting of Fault During the VRRP Status Change for AR2200

Publication Date:  2014-12-31 Views:  912 Downloads:  0
Issue Description
VRRP state change fault
Alarm Information
VRRP state change fault
Handling Process
1. The topology is just as below:

Check the vrrp status of the Routers. Found the VRRP status of R1 is master and R2 is initialize. The detail is just as below:
===============display vrrp===============
  GigabitEthernet0/0/1 | Virtual Router 1
    State : Initialize
    Virtual IP :
    Master IP :
    PriorityRun : 100
    PriorityConfig : 100
    MasterPriority : 0
    Preempt : YES   Delay Time : 0 s
    TimerRun : 1 s
    TimerConfig : 1 s
    Auth type : NONE
    Virtual MAC : 0000-5e00-0101
    Check TTL : YES
    Config type : normal-vrrp
    Backup-forward : disabled
    Create time : 2014-11-29 21:07:27
Last change time : 2014-11-29 21:48:34
The customer want Configure a VRRP group on R1 and R2, set a higher priority for R1 so that R2 functions as the master to forward traffic and set the preemption delay to 20s on R1, and set a lower priority for R2 so that R2 functions as the backup. But we found the VRRP status of R1 is master and R2 is initialize.
2. Check the configuration for the VRRP. There isn’t any wrong of the configuration for the VRRP. Let the customer check the ip routing of the R1, R2 and SW. Make sure reachable route among these equipments.
3. After the customer renewed the configuration for the ip routing. Check the VRRP status of the Routers. It show the R1 is master and R2 is backup. Customer feedback that when they do the test of VRRP status change it is fault.
4. Collect the debug information of the R1 and R2. Open the VRRP debug, collecting 1-2 minutes, the command is just as below:
<RX> debugging vrrp packet
<RX> terminal monitor
<RX> terminal debugging
After collecting the above information on the AR1 and AR2 1-2 minutes, please issue the following command to undo the debugs:
<RX> undo terminal debugging
< RX > undo terminal monitor
< RX > undo debugging vrrp packet
5. From the information that collected by step 4, we found there isn’t any mistake of VRRP. Confirm with customer again. The customer feedback that they config NQA for the link that connect R1 with ISP1. The detail just as below:
interface GigabitEthernet0/0/1
description ***BRANCH LAN***
ip address
undo icmp host-unreachable send
undo icmp redirect send
vrrp vrid 1 virtual-ip
vrrp vrid 1 priority 120
vrrp vrid 1 preempt-mode timer delay 20
vrrp vrid 1 track nqa user test reduced 40
nqa test-instance user test
test-type icmp
destination-address ipv4
frequency 20
probe-count 5
start now
But when they make the link that connect R1 with ISP1 down. But the status of R1 and R2 didn’t change.
6. Check the diagnostic information of R1. It show that there isn’t any configuration for NQA in the “display current-configuration”. But we found the configuration of NQA in the “display saved-configuration”. Normally for the system it keep running the current-configuration, so when the link for AR1 (link from  is down or up it won’t make the VRRP status change.
7. Change the configuration for the NQA just as saved configuration, and then the test of VRRP status change successful.
Root Cause
Because of human factors the ip routing between R1 and R2 is fault and also the current-configuration is different with the saved-configuration, so the configuration of NQA is useless. It won’t make the VRRP status change. 
During the Troubleshooting, using different way to reduce the arrange of possible root cause. That will be helpful for the work.