Description

The Virtual IP address (VIP) of Virtual Router Redundancy Protocol (VRRP)'s primary may fail to handle ingress traffic.

This issue is reported as PR1338277 or PR1352741 , depending on the combination of software and hardware.

Symptoms

Sometimes, it may be necessary to configure multiple VRRP sessions on the same physical interface with the same VRRP group ID.

Sample configuration:

[edit]
lab@R2# show interfaces xe-1/2/1  
vlan-tagging;
unit 0 {
    vlan-id 100;
    family inet {
        address 10.12.12.2/30;
    }
    family mpls;
}
unit 10 {
    vlan-id 10;
    family inet {
        address 192.168.254.100/24 {
            vrrp-group 10 {
                virtual-address 192.168.254.101;
                accept-data;
            }
        }
    }
}
unit 20 {
    vlan-id 20;
    family inet {
        address 192.168.255.100/24 {
            vrrp-group 10 {
                virtual-address 192.168.255.101;
                accept-data;
            }
        }
    }
}

This configuration in turn, generates two VRRP sessions which contain identical virtual MAC address as per VRRP design (RFC 2378).

[edit]
lab@R2# run show vrrp extensive | match "physical|vip:|virtual mac" 
Physical interface: xe-1/2/1, Unit: 10, Vlan-id: 10, Address: 192.168.254.100/24
  Preempt: yes, Accept-data mode: yes, VIP count: 1, VIP: 192.168.254.101  
  Virtual Mac: 00:00:5e:00:01:0a
Physical interface: xe-1/2/1, Unit: 20, Vlan-id: 20, Address: 192.168.255.100/24
  Preempt: yes, Accept-data mode: yes, VIP count: 1, VIP: 192.168.255.101  
  Virtual Mac: 00:00:5e:00:01:0a

The issue is seen after one of the IFL is deleted (or IFL is moved into/out of a routing-instance).

The other VIP is unreachable as well.

[edit]
lab@R2# delete interfaces xe-1/2/1.20 

[edit]
lab@R2# commit 
commit complete

[edit]
lab@R2# run show vrrp extensive | match "physical|vip:|virtual mac"    
Physical interface: xe-1/2/1, Unit: 10, Vlan-id: 10, Address: 192.168.254.100/24
  Preempt: yes, Accept-data mode: yes, VIP count: 1, VIP: 192.168.254.101     
  Virtual Mac: 00:00:5e:00:01:0a

Ping from client:
lab@R1> ping 192.168.254.101 rapid    
PING 192.168.254.101 (192.168.254.101): 56 data bytes
.....
--- 192.168.254.101 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

Solution

During the configuration change mentioned above, the virtual MAC address is occasionally deleted in packet forwarding engine (PFE) regardless of the state of remaining VRRP sessions that are still using it. As a result, the remaining IFLs keep claiming VRRP primary but dropping all ingress traffic towards VIP.

Fix:

  • Prior to Junos 17.3, the fix is available per PR1338277 .
  • From Junos 17.3 and later, the fix is available per PR1352741 , only if VRRP delegation is enabled.


Exception:

Starting from Junos 17.3, in case of network services mode Enhanced IP , the issue will no longer occur because the method to handle virtual MAC in PFE is different.


Workaround:

During the issue:

  1. Release VRRP primary from all affected sessions to correct the PFE state (e.g. make the priority lower than the backup router).
  2. Rollback configuration to the expected one.

Otherwise, avoid configuring the same group-id for multiple VRRP sessions on the same aggregated Ethernet or physical port.