We are observing that configured Class of Service (CoS) policies are not taking effect on one or more interfaces. Symptoms include one or more of the following:

And also we observed the below alarms and core dumps generated.

root@JTAC> show chassis alarms

Alarm time Class Description

2026-02-05 11:27:29 IST Major Application cosd fail on node Re0

root@JTAC> show system core-dumps no-forwarding

re0:
--------------------------------------------------------------------------
-rw-------  1 root  root   1584469360 Feb 5  11:04 /var/core/re0/cosd.re.re0.10960.2026_02_05.11_02_09.tar.gz
-rw-------  1 root  root   1584766280 Feb 5  11:31 /var/core/re0/cosd.re.re0.22599.2026_02_05.11_27_22.tar.gz
-rw-------  1 root  root   1584876902 Feb 5  11:33 /var/core/re0/cosd.re.re0.23629.2026_02_05.11_27_26.tar.gz
total files: 3

set class-of-service forwarding-classes class best-effort queue-num 0

set class-of-service forwarding-classes class business-apps queue-num 1

set class-of-service forwarding-classes class network-control queue-num 2

set class-of-service forwarding-classes class voice-video queue-num 3

COSD core is seen when we try to re-use the default forwarding class name which is replaced from earlier custom name.

This is specifically happening when we use the Queue number which is already associated with a default forwarding class.

Once the issue is hit, COSD process is completely stalled and is not getting recovered till we remove the problematic config and restart the class of service daemon.

The def FCs have queue numbers already mapped & when we define differently, the EVO code will crash.

This is a Day-1 behaviour for all EVO devices.

This is evident from core dump & internal PR1827230 has the info reg this.

The fix is currently added in 25.2R1-EVO & above releases.

Fix:

> Adding support for reusing default FC names

-First, we populate the custom FC's into the map

-Then we populate the default FC's only if they have not been overridden

> Also, updating the FC ID allocation algorithm.

-If a candidate FC exists, assign the first candidate FC (sorted by name) for the queue number of the default that it is replacing and assign the default's FC ID.

This is how it works in JUNOS

Workaround:

Different/Custom FC names can be used as an alternative. This has no bearing on the functionality.

Initial sample Config, which was working fine:

set class-of-service forwarding-classes class BE queue-num 0

set class-of-service forwarding-classes class BizApps-AF2 queue-num 3

set class-of-service forwarding-classes class BizApps-AF3 queue-num 2

set class-of-service forwarding-classes class LBE queue-num 6

set class-of-service forwarding-classes class NC queue-num 7

set class-of-service forwarding-classes class NetTools-AF1 queue-num 4

set class-of-service forwarding-classes class Video-AF4 queue-num 1

set class-of-service forwarding-classes class voice-ef queue-num 5

New sample Config which caused the issue:

set class-of-service forwarding-classes class best-effort queue-num 0

set class-of-service forwarding-classes class business-apps queue-num 1

set class-of-service forwarding-classes class network-control queue-num 2

set class-of-service forwarding-classes class voice-video queue-num 3

Edited new Config (changed defaults names to alternate), working fine:

set class-of-service forwarding-classes class BE queue-num 0

set class-of-service forwarding-classes class business-apps queue-num 1

set class-of-service forwarding-classes class NC queue-num 2

set class-of-service forwarding-classes class voice-video queue-num 3