Can't find what you need?


• Ask the Community
• Create a Case
Reset Search
 

 

Article

VRRP errors, high latency and packet loss - VRID Invalid value incrementing

« Go Back

Information

 
TitleVRRP errors, high latency and packet loss - VRID Invalid value incrementing
Symptoms
Customer seeing VRID Invalid : 1782534 (about +2 every second).
VRID error can be seen on show vrrp detail and it is increasing every second. 
SLX# show vrrp detail | include VRID
VRID 1
    VRID Invalid   : 2419396
VRID 1
    VRID Invalid   : 2419396

 
Environment
  • SLX 9640
  • 18r.2.00a
Cause
The VRID Invalid counter is incremented when a VRRP interface receives an advertised VRID that is not programmed on the local interface
The most common cause is a misconfigured VE on the VRRP peer.
Also if there is an orphaned peer setup on the VLAN attempting to participate in VRRP this message can be seen
Resolution
Ensure Configuration matches between all participating VRRP peers
  • When using Multiple VRIDs, ensure all VRIDs are configured on each device
If Configurations match on all VRRP peers, check to see if VRRP messages are being sent by an errant/orphaned peer:

Collect TCP Dump:
  1. Access Linux Shell
SLX1# start-shell
  1. Elevate to Root 
[admin@SLX1]# su
  1. Navigate to appropriate VRF
  • VRF ID can be found using the "show vrf" command in SLX OS
[root@SLX1]# /fabos/cliexec/vrfcmd 1 bash
  1. Verify Interfaces are seen
[root@SLX1]# ifconfig

ve1407    Link encap:Ethernet  HWaddr 60:9c:9f:de:69:15  
          inet addr:10.0.0.3  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:9194  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:5000 
          RX bytes:0 (0.0 B)  TX bytes:1008 (1008.0 B)
  1. Initiate TCP Dump
[root@SLX1]# tcpdump -i ve1407 -vvv vrrp -c 100
tcpdump: listening on ve1407, link-type EN10MB (Ethernet), capture size 65535 bytes
10:23:20.040092 IP (tos 0xc0, ttl 255, id 0, offset 0, flags [DF], proto VRRP (112), length 40)
    10.0.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 21, prio 200, authtype none, intvl 1s, length 20, addrs: 10.0.0.1
10:23:20.040131 IP (tos 0xc0, ttl 255, id 0, offset 0, flags [DF], proto VRRP (112), length 40)
    10.0.0.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 22, prio 200, authtype none, intvl 1s, length 20, addrs: 10.0.0.161
10:23:20.041303 IP (tos 0xc0, ttl 255, id 34468, offset 0, flags [none], proto VRRP (112), length 40)
    10.0.0.252 > 224.0.0.18: VRRPv2, Advertisement, vrid 62, prio 110, authtype none, intvl 1s, length 20, addrs: 10.0.0.254
10:23:20.041436 IP (tos 0xc0, ttl 255, id 34504, offset 0, flags [none], proto VRRP (112), length 40)
    10.0.0.251 > 224.0.0.18: VRRPv2, Advertisement, vrid 61, prio 110, authtype none, intvl 1s, length 20, addrs: 10.0.0.253
  • In this Example, IP address 10.0.0.2 is sending the expected VRRP advertisements on VRID 21 and 22
  • We also see two additional devices; 10.0.0.252 and 10.0.0.251 sending additional advertisements on VRID 62 and 61 respectively
  1. Locate device on the network and correct configuration or remove it from VRRP.
Additional notes

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255