This article describes the below error message and provides solution for the same.

vrrp-group 1'
'priority-cost' for worst case must not exceed configured 'priority' for 'vrrp-group'
error: configuration check-out failed

Common Scenarios Leading to This Error:

1) Priority-cost too high: You've configured a priority-cost value (or the sum of multiple priority-cost values) that, when subtracted from the base priority, would result in a priority less than 1.

Example: If your priority  is 100, and you configure a priority-cost of 100 for an interface, if that interface goes down, the effective priority becomes 0. While 0 is technically used for shutdown, Junos generally prevents a configured priority-cost from forcing a live priority to 0 or negative during normal operation. A common configuration is to set priority  to 100 and priority-cost to 10. If the interface goes down, the priority becomes 90. If you set priority to 10 and priority-cost to 10, then the effective priority becomes 0 and this will throw an error.

2) Small base priority: Your initial priority for the VRRP group might be relatively low, making it easier for even a moderate priority-cost to bring the effective priority below the acceptable threshold.

This error log indicates a configuration conflict in the Junos device related to VRRP (Virtual Router Redundancy Protocol).

Priority: In VRRP, each router in a VRRP group is assigned a priority value (0-255). The router with the highest priority becomes the master.

Priority-cost: This is an optional feature where you can configure a "cost" value that is deducted from the VRRP group's configured priority if a tracked interface or object goes down. This allows a router to lower its priority dynamically, forcing a mastership change if its ability to forward traffic is impaired.

The Conflict: The error message explicitly states that the calculated "worst-case" priority (i.e., the configured priority minus the sum of all priority-cost values) would result in a value that is lower than what is acceptable given the initial priority.

=>More precisely, it's saying that the priority-cost itself, when applied, would make the effective priority fall below the minimum allowed effective priority, or even below 0. Due to this, the device is refusing to commit the configuration. The new configuration is syntactically invalid or logically unsound according to Junos rules.

How to Resolve the Issue:

You need to adjust your VRRP configuration to ensure that the effective priority, even in the worst-case scenario (with all applicable priority-cost values deducted), remains a valid and functional value (typically 1 or higher, depending on the specific Junos version and platform rules for priority-cost calculation).

1)Increase the base priority.

2)Decrease the priority-cost.