CoS shaping rate configured with absolute value may stop working on EX4600 platforms if the switch is rebooted. In this article, the Junos OS releases in which the issue is resolved and a workaround are given, along with the reason for such behavior.
The CoS/QoS shaping rate is seen to stop working after rebooting the switch if shaping rate is defined with an absolute value.
Example Configuration
set class-of-service traffic-control-profiles QOS-TCP shaping-rate 50m
PFE Output Before Rebooting
{master:0}
root@jtac-ex4600-40f-r2002> start shell
root@jtac-ex4600-40f-r2002:RE:0% vty fpc0
TOR platform (1500 Mhz Pentium processor, 511MB memory, 0KB flash)
TFXPC0(jtac-ex4600-40f-r2002 vty)# show cos hw ifd_index 656
Unit : 0
populate temp_cos_halp_ifd (0x22faf620),0x22faf620
IFD: ge-0/0/22 (656), unit: 0 bcm_port 23 mmu_port 25 num_uc_qs 12 mc_qs 10 ext_qs 0 port_grp 3
===========================================================================================
EGRESS CONFIG:
Port 23 Gport 0x8000017
AdmCtl: uc_lmt_en 0 mc_lmt_en 0
CtlParm SP0 SP1 SP2 SP3
MC Shrd Lmt 0 8172 0 0
MC Sh ResVal 0 0 0 0
UC Shrd Lmt 13332 0 21504 0
UC Sh ResVal 0 0 0 0
MC Color Lmt 0 0 0 0
UC Col Yel Lmt 0 0 0 0
UC Col Red Lmt 0 0 0 0
S1: Gport 0x34009717
S2: max_s2_nodes 5 used_s2_nodes: 0
S2 Node: idx 0 Gport 0x34009817 MC Available 1
S2 Node: idx 1 Gport 0x34009917 UC Available 0
fc_set_id: 64953 queues active:
Sched Params: Weight 1 mode 5 bw_flags 0x0
Tx rate: 0 kbps Shape rate: 50000 kbps
UCQ0 (HWQ 0) Gport 0x2405c128 s2_offset: 0
Sched: Weight 1 mode 5 bw_flags 0x0
Tx rate: 0 kbps Shape rate: 50000 kbps
AdmCtrl: q_spid 0 q_min 48 shared_lmt 7 qlmt_en 0
qlmt_dyn 1 alpha 7 col_en 0 col_lmt_dyn 1
lmt_yel 0 off 12 red 0 off 12 sh_off 12
PFE Output After Rebooting
{master:0}
root@jtac-ex4600-40f-r2002> start shell
root@jtac-ex4600-40f-r2002:RE:0% vty fpc0
TOR platform (1500 Mhz Pentium processor, 511MB memory, 0KB flash)
TFXPC0(jtac-ex4600-40f-r2002 vty)# show cos hw ifd_index 656
Unit : 0
populate temp_cos_halp_ifd (0x22faf620),0x22faf620
IFD: ge-0/0/22 (656), unit: 0 bcm_port 23 mmu_port 25 num_uc_qs 12 mc_qs 10 ext_qs 0 port_grp 3
===========================================================================================
EGRESS CONFIG:
Port 23 Gport 0x8000017
AdmCtl: uc_lmt_en 0 mc_lmt_en 0
CtlParm SP0 SP1 SP2 SP3
MC Shrd Lmt 0 8172 0 0
MC Sh ResVal 0 0 0 0
UC Shrd Lmt 13332 0 21504 0
UC Sh ResVal 0 0 0 0
MC Color Lmt 0 0 0 0
UC Col Yel Lmt 0 0 0 0
UC Col Red Lmt 0 0 0 0
S1: Gport 0x34009717
S2: max_s2_nodes 5 used_s2_nodes: 0
S2 Node: idx 0 Gport 0x34009817 MC Available 1
S2 Node: idx 1 Gport 0x34009917 UC Available 0
fc_set_id: 64953 queues active:
Sched Params: Weight 1 mode 5 bw_flags 0x0
Tx rate: 0 kbps Shape rate: 0 kbps <<<<<<<<<<<<<
UCQ0 (HWQ 0) Gport 0x2405c128 s2_offset: 0
Sched: Weight 1 mode 5 bw_flags 0x0
Tx rate: 0 kbps Shape rate: 0 kbps <<<<<<<<<<<
AdmCtrl: q_spid 0 q_min 48 shared_lmt 7 qlmt_en 0
qlmt_dyn 1 alpha 7 col_en 0 col_lmt_dyn 1
lmt_yel 0 off 12 red 0 off 12 sh_off 12
After rebooting, CoS fails to shape traffic as per configured rate as seen in the above output.
As per PR1472223, when shaping is applied with an absolute value, bandwidth programming is not done correctly after reboot of the switch.
This issue has been resolved in Junos OS releases 18.1R3-S9, 18.4R3, 19.1R3, 19.2R2, 19.3R2-S1, 19.3R3, 19.4R2, and 20.1R1 as per PR1472223.
Meanwhile, to work around the problem, remove the shaping-rate configuration, commit, re-apply it, and commit again.