In customer case after upgrading to a target release customer observed some of the QoS leaves were missing in the telemtry polled data.
Here is an example: Displaying different results under the sensor group junos/system/linecard/interface/queue.
path: "sensor_1006_1_1:/junos/system/linecard/interface/queue/:/interfaces/interface/state/:PFE"
sequence_number: 65
timestamp: 1710884772125
kv: {
key: "__timestamp__"
uint_value: 1710884772126
}
..
key: "state/counters/out-queue[queue-number='0']/pkts"
uint_value: 0
key: "state/counters/out-queue[queue-number='0']/bytes"
key: "state/counters/out-queue[queue-number='0']/tail-drop-pkts"
key: "state/counters/out-queue[queue-number='0']/rl-drop-pkts"
key: "state/counters/out-queue[queue-number='0']/rl-drop-bytes"
key: "state/counters/out-queue[queue-number='0']/red-drop-pkts"
key: "state/counters/out-queue[queue-number='0']/red-drop-bytes"
key: "state/counters/out-queue[queue-number='0']/avg-buffer-occupancy"
key: "state/counters/out-queue[queue-number='0']/cur-buffer-occupancy"
key: "state/counters/out-queue[queue-number='0']/peak-buffer-occupancy"
key: "state/counters/out-queue[queue-number='0']/allocated-buffer-size"
```
------------------------------
path: "sensor_1005_1_1:/junos/system/linecard/interface/queue/:/interfaces/interface/state/:PFE"
sequence_number: 59
timestamp: 1710885668010
uint_value: 1710885668011
key: "__prefix__"
str_value: "/interfaces/interface[name='ae1']/"
key: "init-time"
uint_value: 1707952277
key: "state/parent-ae-name"
str_value: ""
str_value: "/interfaces/interface[name='et-0/0/19']/"
uint_value: 1707952289
str_value: "ae1"
Additionally, the leaves from the subscription /junos/cos-forwarding-class-information/ are present
component_id: 65535
path: "sensor_1011:/junos/cos-forwarding-class-information/:/junos/cos-forwarding-class-information/:xmlproxyd_TM_Thread_4"
sequence_number: 8
timestamp: 1710885672789
uint_value: 1710885672789
key: "__junos_re_stream_creation_timestamp__"
uint_value: 1710885672786
key: "__junos_re_payload_get_timestamp__"
uint_value: 1710885672788
str_value: "/junos/cos-forwarding-class-information/fc-map/fc-map-item[fc-name='be1']/"
key: "fc-number"
str_value: "/junos/cos-forwarding-class-information/fc-map/fc-map-item[fc-name='af2']/"
uint_value: 1
Upon further analysis, the issue would be observed only in the data streamed to the Jvision Collector for Telemetry on the PTX platform running Junos 21.4 onwards when the AE (Aggregate Ethernet) IFL (logical interface) statistic were enabled for this platform. However, the new change inadvertently unblocked IFD (physical interface) and queue statistics for AE interface and failed to filter non-local child IFDs belonging to an AE bundle while streaming data from an FPC. This results in the collector receiving incorrect, missing, or changed telemetry data regarding IFD/IFL from the PTX platform.
While attempting to enable IFL traffic statistics for AE (Aggregate Ethernet) interfaces on the PTX platform, the harvesting of physical IFD and queue statistics for AE interfaces was inadvertently unblocked. This has led to the collector receiving incorrect, missing, or changed telemetry data regarding IFD/IFL.
The issue has been fixed via PR1729197 to make result from the AE IFL statistic limited only on logical interface (IFL), not extended into the realm of physical interfaces (IFD).
This issue might be seen if the following conditions are met:
● On Junos 22.3X60.
● PTX platform.
● The telemetry IFD/IFL data was streamed over to the Jvision collector.