Subscriber's CoS parameters can be groupped in the traffic control profile (TCP). To save resources, TCP with the same parameters forms TCP template so the same template can be used for many subscribers. Due to some rare issue, subscribers can be mapped to the wrong TCP template so such subscribers are programmed with the wrong CoS parameters.

The parameters, received from RADIUS server, for a particular subscriber (based on the session ID) can be seen using the following command:

show dynamic-configuration session information session-id <Subscriber's Session ID>

....

Interface set: is_10

....

Dynamic configuration:

junos-cos-delay-buffer-rate: 100000K

junos-cos-excess-rate-low: 24

junos-cos-scheduler-map: scheduler-map_name

junos-cos-shaping-rate: 100000K

....

In this particular example the CoS TCP was assigned on interface-set level (is_10 in this example). Checking the actual CoS parameters which are assigned on the interface-set is_10:

user@router-re0> show class-of-service interface-set is_10

Interface-set: is_10, Index: 76341

Physical interface: xe-1/0/0, Index: 583

Maximum usable queues: 8, Queues in use: 8

Output traffic control profile: tcp_name_UID1000, Index: 4294969838



{master}

user@router> show class-of-service traffic-control-profile tcp_name_UID1000

Traffic control profile: tcp_name_UID1000, Index: 4294969838

Shaping rate: 500000000

Shaping rate burst: 1 bytes

Scheduler map: sm_name

Delay Buffer rate: 500000000

Excess rate low: proportion 16

Overhead accounting mode: Frame Mode

Overhead bytes: -4

You can see that the CoS parameters in the assigned TCP template are different than what is assigned for the subscriber. 

The root cause of the issue has not been found as the issue is not reproducible. To clear the state the incorrect CoS TCP template should be deleted. The CoS TCP template is deleted if no subscribers are using it so to delete this CoS TCP all subscribers with such TCP should be logged off.