[AusNOG] Egress shaping on Telstra EA Service

Andrew Yager andrew at rwts.com.au
Fri Dec 23 15:29:14 EST 2016


Thanks to everyone who has come back to me and helped verify configurations
etc.

Have been working with an excellent engineer on Telstra's side and we
narrowed it down to a faulty device on their side.

Thanks,
Andrew


On 16 December 2016 at 13:23, Andrew Yager <andrew at rwts.com.au> wrote:

> Hi,
>
> I'm working through troubleshooting a 200M EA service. Shapers are done on
> Juniper MX (head end) and Juniper SRX300 (customer end).
>
> Ingress we are receiving full bandwidth to shaping value (195Mbps)
> Egress we are only receiving 30Mbps for TCP traffic only.
>
> If I clamp the shaper down to 10Mbps, I see that the speed drops to a flat
> 9.8Mbps.
>
> If I do an iperf using UDP, I'm seeing the full 195Mbps from client
> machine out.
>
> Does anyone have any ideas about what this could be? We've got a few other
> SRX300s in the field using the same config; and so it doesn't look like
> that's the problem - and also given that clamping the shaping to 10Mbps
> evens the results it seems like the SRX won't be what is at fault.
>
> Shaper config on customer side:
>
> # show class-of-service
> interfaces {
>     ge-0/0/0 { <!-- this is facing customer machine for testing
>         unit 0 {
>             scheduler-map policer;
>         }
>     }
>     ge-0/0/5 { <!-- this is facing Telstra NTU
>         unit 0 {
>             scheduler-map policer;
>         }
>     }
> }
> scheduler-maps {
>     policer {
>         forwarding-class best-effort scheduler rate-limit-195m;
>     }
> }
> schedulers {
>     rate-limit-195m {
>         shaping-rate 195m;
>     }
> }
>
> # run show class-of-service scheduler-map policer
> Scheduler map: policer, Index: 55355
>
>   Scheduler: rate-limit-195m, Forwarding class: best-effort, Index: 19467
>     Transmit rate: unspecified, Rate Limit: none, Buffer size: remainder,
> Buffer Limit: none, Priority: low
>     Excess Priority: unspecified
>     Shaping rate: 195000000 bps
>     Drop profiles:
>       Loss priority   Protocol    Index    Name
>       Low             any             1    <default-drop-profile>
>       Medium low      any             1    <default-drop-profile>
>       Medium high     any             1    <default-drop-profile>
>       High            any             1    <default-drop-profile>
>
>
> UDP Iperf from client outbound that shows it's not the link capacity…
>
> [ ID] Interval      Transfer    Bandwidth        Jitter  Lost/Total Datagrams
> [  3]  0.0-27.7 sec  636 MBytes  192 Mbits/sec  0.029 ms 24291/478152 (5.1%)
> [  3]  0.0-27.7 sec  1 datagrams received out-of-order
> [  4] local xx port 5001 connected with xx port 58752
> [  4]  0.0-10.3 sec  229 MBytes  187 Mbits/sec  16.141 ms 8958/172410 (5.2%)
> [  4]  0.0-10.3 sec  1 datagrams received out-of-order
> [  3] local xx port 5001 connected with xx port 60477
> [  3]  0.0-10.0 sec  228 MBytes  191 Mbits/sec  0.039 ms 9595/172190 (5.6%)
> [  3]  0.0-10.0 sec  1 datagrams received out-of-order
> [  4] local xx port 5001 connected with xx port 50602
> [  4]  0.0-30.0 sec  683 MBytes  191 Mbits/sec  0.023 ms 29513/516460 (5.7%)
>
>
> Any advice/input would be appreciated. I'm also curious if there is any
> chance this could still be Telstra?
>
> Thanks,
> Andrew
>



-- 
*Andrew Yager, CEO* *(BCompSc, JNCIS-SP, MACS (Snr) CP)*
Real World Technology Solutions - IT People you can trust
Voice | Data | IT Procurement | Managed IT
rwts.com.au | 1300 798 718


*Real World is a Dell Premier Partner*

This document should be read only by those persons to whom it is addressed
and its content is not intended for use by any other persons. If you have
received this message in error, please notify us immediately. Please also
destroy and delete the message from your computer. Any unauthorised form of
reproduction of this message is strictly prohibited. We are not liable for
the proper and complete transmission of the information contained in this
communication, nor for any delay in its receipt. Please consider the
environment before printing this e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20161223/898990c1/attachment.html>


More information about the AusNOG mailing list