Description

After upgrading ACX7000-Transform devices to 26.2R1-EVO, VRRP may become unstable and fail over repeatedly on interfaces protected by a small filter-specific policer (e.g., a 32k bandwidth-limit policer applied to VRRP/multicast traffic). The issue does not occur on 24.2R2-S4.2-EVO with the same configuration. Lab reproduction shows the root cause is not a VRRP protocol defect: a hardware policer-fairness capability, enabled by default starting in 26.2, randomizes each policer bucket's credit level by up to 8K. On small policers or policers with a small burst size, this added randomness can push VRRP advertisement packets over the enforced rate, causing them to be dropped and triggering false VRRP mastership transitions.



Symptoms

Customers see repeated VRRP master/backup transitions in the log on the backup node while the true master remains reachable:
vrrpd[14057]: VRRPD_NEW_MASTER: Interface et-0/0/7.803 became VRRP master for group 83 with master reason Adjacency down or no response from master
vrrpd[14057]: VRRPD_NEW_BACKUP: Interface et-0/0/7.803 became VRRP backup for group 83
vrrpd[14057]: VRRPD_LOST_MASTERSHIP: Interface et-0/0/7.803 VRRP state changed from master to backup for group 83 with reason 'Received packet priority high'
A control-plane packet capture on the backup node shows a gap of 3–4 missed VRRP advertisements from the master right before each failover.
To confirm policer-fairness state, run:
show evo-pfemand filter policer-fairness
  • 24.2R2-S4.2-EVO: Current policer fairness state is: Disabled
  • 26.2R1-EVO: Current policer fairness state is: Enabled
Engineers can also reproduce the drop in a 24.2 lab by manually enabling the feature:
set evo-pfemand filter policer-fairness enable
show firewall on the affected interface will show the configured policer's discard counters incrementing on the VRRP filter term while VRRP is flapping, confirming policer-driven drops rather than a protocol-level failure.

Solution

This is not a VRRP protocol issue. The behavior is caused by a hardware (BCM ASIC) policer-fairness capability that randomizes meter-bucket credit by 0–8K to prevent one traffic stream from starving another when several streams share the same filter-specific policer. This fairness feature is enabled globally as of 26.2R1-EVO (it was disabled by default in 24.2), and it is a chip-level, all-or-nothing setting — it cannot be selectively disabled per policer.

The side effect only appears with small policers or small burst sizes, since the added randomness becomes proportionally significant. VRRP/multicast policers configured near typical values (e.g., 32k bandwidth-limit, 12k burst-size-limit) are especially exposed.

Workaround: 

Increase the burst-size-limit on the affected policer by at least 8K to absorb the added randomization and prevent VRRP advertisement drops. For example, raising a policer from a 12k to a 20k+ burst size (or more conservatively to 100k burst / 500k bandwidth as validated in testing) resolves the flapping without disabling the filter.

Example policer configuration for reference:
set firewall policer police-32k filter-specific
set firewall policer police-32k if-exceeding bandwidth-limit 32k
set firewall policer police-32k if-exceeding burst-size-limit 20k
set firewall policer police-32k then discard
This is currently tracked under PR1979122, under review by the PFE/EVO development team. For additional details, refer to https://prsearch.juniper.net/problemreport/PR1979122.

Modification History

2026-09-12 : Article Created