Description

We've received customer about slow downloads through this device. Further investigation revealed that the traffic passing through ae11.1000 is affected and download speeds are reduced to a maximum of 2.3 MB/s, this is consistent and reproducable for several customer but does not a appears to apply to all traffic. IPv6 on ae11.2000 for example from the same source and destination is not affected by the reduced download speed.

A test executed last week resulted in a brief resolution of the issue by disabling a specific port in the ae11 lag, the download speed improved to line rate maximum. When that specific port was re-enabled, the speed dropped again. However when that specific port was disabled again, the donwload speed remained low. This situation could be reproduced on another port in the LAG on the same day.
This lead us to believe that problem was 'jumping' to another port due to changes in the port to bucket mapping. In an attempt to pinpoint a possible port issue all ports within ae11 were disabled and one port was activated in turn, in these tests the download was slow on every single individual port.

Today we have created a brand new LAG (ae12) for just IPv4 traffic and added up to 2 ports, also in this new LAG the download speed did not improve. Additionally, we have routed traffic back to ibrstr5 so that it entered through another LAG (ae1) and also in this case the problem remained. The earlier test made us believe the problem was very specific to ae11 but it appears the issue is beyond the LAG itself.

Symptoms

Topology:

Client <-> MX1 <-> MX2 <-> Server

Solution

The MX2-Server was having best-effort queue mapping at MX2 interface, but the MX1-MX2 interface was not mapped to COS config at MX2.

Hence whenever traffic was taking MX1-MX2, in any of the test customer tried, the packets were getting dropped at MX2.

 

Issue was resolved after adding the interface under COS config in MX2.

 

MX2:

show class-of-service interface ae11

Physical interface: ae11, Index: 129

Maximum usable queues: 8, Queues in use: 4

Exclude aggregate overhead bytes: disabled

Logical interface aggregate statistics: disabled

  Scheduler map: <default>, Index: 2

 Congestion-notification: Disabled

 

 Logical interface: ae11.1000, Index: 323

Object         Name         Type          Index

Classifier       exp-default      exp            10

Classifier       ipprec-compatibility ip            13

 

 Logical interface: ae11.2000, Index: 324

Object         Name         Type          Index

Classifier       dscp-ipv6-compatibility dscp-ipv6         9

 

 Logical interface: ae11.32767, Index: 325

Object         Name         Type          Index

Classifier       ipprec-compatibility ip            13

 

Since ae11 was not under the CoS interface hierarchy, the router used default hardware queue for classification.

Due to this:

  • Default buffer allocation happens.
  • Default WRED/drop thresholds will be seen.
  • No guaranteed bandwidth for BE queue, as its def value.

 

Even though the interface bandwidth wasn't saturated, drops can occur due to microbursts.

  • Traffic arrives in bursts.
  • Hardware queue buffer fills briefly.
  • Default drop profile triggers early drop.
  • Drops occur even though average utilization is low.

 

The reason for above is:

  • Buffer allocation was small
  • WRED thresholds were aggressive by default

 

So the queue dropped packets during bursts.

When we added the interface into CoS config, the queue BW were clearly defined & hence bursts gets absorbed in the same, resulting in no drops.

Modification History

2026-03-18 : Article Created