[j-nsp] MX/Trio traffic-control-profile burst-size (controlling microbursts)

[Chris Kawchuk]

Howdy All,

I'm attempting to smooth out some traffic on an MX Gig Port on an MX80-T (Trio Card) running 11.4R2.14 (Yeah, I'm being adventurous here).

The underlying Gig link is going via a carrier lease on one of those Ethernet-over-SONET jobbies on the Carrier's side; which is limited to 150mbit (STM-1/OC3); and their gear has notoriously "small" buffer sizes (meaning that any bursts > 4k are dropped.. yeah, great equipment...). Hence, I need to not only shape, but control the burst size to get rid of any micro-bursting on the port. (even a small 50m bursty stream will attempt to burst to line-rate, due to the token-method that the shaper uses; thus flooding the Carrier's EoSDH/EoSONET equipment and leading to packet drops).

So to do this, I did:

class-of-service {
    traffic-control-profiles {
        chrisk-test {
            scheduler-map My-Standard-QoS;
            shaping-rate 150m burst-size 4k;
        }
    interfaces {
        ge-1/0/9 {
            output-traffic-control-profile chrisk-test;
        }

ge-1/0/9 is setup as a standard interface, no hierarchal, no-per-unit sched.... just a plain-olde Gig Port. I'm using a tc-profile as it allows setting of a burst-size; while the standard c-o-s { interfaces { "shaping-rate" }} does not. However, upon testing, it appears that the burst-size is completely ignored. (verified with a nice EXFO test set, generating some very bursty traffic).

I have also tried using the following (which are MX/Trio specific, thinking I have the wrong commands):

shaping-rate-priority-high 150m burst-size 4k;
shaping-rate-priority-medium 150m burst-size 4k;
shaping-rate-priority-low 150m burst-size 4k;

... Also tried differing burst-sizes (4k, 8k, 16k, 32k, etc) and nothing seems to take effect.

I will note that I did this on a DPCE-Q Card under 10.4Rsomething, and it works fine in terms of controlling the microbursts. I can also somewhat solve this by shaping at the per-queue level with a scheduler referencing a shaping-rate X burst-size 4k and it also works; however, shaping every queue is not a solution here. (I can explain more on this point if anyone needs...)

Hoping for some collective clue here.... (My next attempt will be to downgrade to 11.2Rx - but I'm not expecting any love from that version either...)

I highly suspect I'm missing something obvious.

- CK.