[AusNOG] Speed issues on ASR1k
Paul Wilkins
paulwilkins369 at gmail.com
Sun Mar 19 17:57:02 EST 2017
Firstly define "slow". The thing about TCP is it is amazing, and you can be
running over a wet piece of string, and as long as your wet piece of string
delivers properly formed packets, your web pages will load. These symptoms
suggest packet loss. Loading web pages is seldom helpful as a debug tool,
and you'll do better with low level tools. Flood ping probably first port
of call, assuming there's no QoS shenanigans.
Kind regards
Paul Wilkins
On 19 March 2017 at 16:55, Arash Naderpour <arash_mpc at parsun.com> wrote:
> Hi Pouya,
>
> Any layer 4 adjustment you may have in your settings? (TCP-MSS?)
> Please also describe how you have done the speed test on that EFM link,
> which protocol and what packet size?
>
> Regards,
>
> Arash
>
>
> Date: Sat, 18 Mar 2017 08:15:10 +0000
> From: Pouya Madani <dynamic.mineral at gmail.com>
> To: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
> Subject: [AusNOG] Speed issues on ASR1k
> Message-ID:
> <CADZYfx3jiq-6g-o2+USYuaukKffR9Qp62Qdb+4cAfDvVvEzQyw at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi everyone,
>
> Need thoughts on a speed issue and would appreciate if anyone might be able
> to help as I am running out of ideas.
>
> I have a new ASR1002 in production to operate as LNS but services
> authenticated are experiencing speed issues and web pages not loading
> properly. My initial thought was the MTU size but this doesnt look to be
> the root cause as authenticated services can ping (bbc.com for instance)
> by
> MTU size 1464 (28bit ICMP + 8bit PPP) ok, but (bbc again for example) web
> pages fail to load completely when browsed to. The sample service I am
> testing with is a 20MB EFM and speed test sits around 16MB up/down. No
> input/output errors on any of the interfaces and speed is 1000 duplex full
> on all.
>
> I would appreciate if any one can suggest anything else I might be missing
> out.
>
> Thanks in advance.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/201703
> 18/e4d4e4e5/attachment-0001.html>
>
> ------------------------------
>
> On Sat, Mar 18, 2017 at 8:20 PM, <ausnog-request at lists.ausnog.net> wrote:
>
>> Send AusNOG mailing list submissions to
>> ausnog at lists.ausnog.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>> or, via email, send a message with subject or body 'help' to
>> ausnog-request at lists.ausnog.net
>>
>> You can reach the person managing the list at
>> ausnog-owner at lists.ausnog.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of AusNOG digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Speed issues on ASR1k (Pouya Madani)
>> 2. Re: Speed issues on ASR1k (michael at hobl.com.au)
>> 3. Re: Speed issues on ASR1k (Nathan Brookfield)
>> 4. Re: Speed issues on ASR1k (Pouya Madani)
>> 5. Re: Speed issues on ASR1k (Pouya Madani)
>> 6. Re: Speed issues on ASR1k (Pouya Madani)
>> 7. Re: Speed issues on ASR1k (Nathan Brookfield)
>> 8. Re: Speed issues on ASR1k (Nathan Brookfield)
>> 9. Re: Speed issues on ASR1k (Pouya Madani)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 18 Mar 2017 08:15:10 +0000
>> From: Pouya Madani <dynamic.mineral at gmail.com>
>> To: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
>> Subject: [AusNOG] Speed issues on ASR1k
>> Message-ID:
>> <CADZYfx3jiq-6g-o2+USYuaukKffR9Qp62Qdb+4cAfDvVvEzQyw at mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi everyone,
>>
>> Need thoughts on a speed issue and would appreciate if anyone might be
>> able
>> to help as I am running out of ideas.
>>
>> I have a new ASR1002 in production to operate as LNS but services
>> authenticated are experiencing speed issues and web pages not loading
>> properly. My initial thought was the MTU size but this doesnt look to be
>> the root cause as authenticated services can ping (bbc.com for instance)
>> by
>> MTU size 1464 (28bit ICMP + 8bit PPP) ok, but (bbc again for example) web
>> pages fail to load completely when browsed to. The sample service I am
>> testing with is a 20MB EFM and speed test sits around 16MB up/down. No
>> input/output errors on any of the interfaces and speed is 1000 duplex full
>> on all.
>>
>> I would appreciate if any one can suggest anything else I might be missing
>> out.
>>
>> Thanks in advance.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/201703
>> 18/e4d4e4e5/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 18 Mar 2017 18:27:56 +1000
>> From: michael at hobl.com.au
>> To: Pouya Madani <dynamic.mineral at gmail.com>
>> Cc: ausnog at lists.ausnog.net
>> Subject: Re: [AusNOG] Speed issues on ASR1k
>> Message-ID: <2f514265-1097-481d-89bc-3fe8c933cefa at email.android.com>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> An HTML attachment was scrubbed...
>> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/201703
>> 18/c137bf27/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sat, 18 Mar 2017 08:31:41 +0000
>> From: Nathan Brookfield <Nathan.Brookfield at simtronic.com.au>
>> To: Pouya Madani <dynamic.mineral at gmail.com>
>> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
>> Subject: Re: [AusNOG] Speed issues on ASR1k
>> Message-ID: <2FDEE421-52E5-4A8F-8B25-4040DD79121A at simtronic.com.au>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Towards you upstream providers that are switching the L2TP sessions what
>> is the maximum MTU you can ping with the DF bit sets
>>
>> Nathan Brookfield
>> Chief Executive Officer
>>
>> Simtronic Technologies Pty Ltd
>> http://www.simtronic.com.au
>>
>> On 18 Mar 2017, at 19:16, Pouya Madani <dynamic.mineral at gmail.com<mailto:
>> dynamic.mineral at gmail.com>> wrote:
>>
>> Hi everyone,
>>
>> Need thoughts on a speed issue and would appreciate if anyone might be
>> able to help as I am running out of ideas.
>>
>> I have a new ASR1002 in production to operate as LNS but services
>> authenticated are experiencing speed issues and web pages not loading
>> properly. My initial thought was the MTU size but this doesnt look to be
>> the root cause as authenticated services can ping (bbc.com<http://bbc.com>
>> for instance) by MTU size 1464 (28bit ICMP + 8bit PPP) ok, but (bbc again
>> for example) web pages fail to load completely when browsed to. The sample
>> service I am testing with is a 20MB EFM and speed test sits around 16MB
>> up/down. No input/output errors on any of the interfaces and speed is 1000
>> duplex full on all.
>>
>> I would appreciate if any one can suggest anything else I might be
>> missing out.
>>
>> Thanks in advance.
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/201703
>> 18/0175a50b/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Sat, 18 Mar 2017 20:01:28 +1100
>> From: Pouya Madani <dynamic.mineral at gmail.com>
>> To: Nathan Brookfield <Nathan.Brookfield at simtronic.com.au>
>> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
>> Subject: Re: [AusNOG] Speed issues on ASR1k
>> Message-ID:
>> <CADZYfx1VO4SRcM73SAGOE+BqG3zrCQcdGYXyP6jrfb_Rtifrag at mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> ping to both sample LAC and 4.2.2.4 is at max MTU 1500 with DF bit set
>>
>>
>> #ping vrf INTERNET
>> Protocol [ip]:
>> Target IP address: 203.219.113.35
>> Repeat count [5]: 1
>> Datagram size [100]:
>> Timeout in seconds [2]:
>> Extended commands [n]: y
>> Ingress ping [n]:
>> Source address or interface:
>> Type of service [0]:
>> Set DF bit in IP header? [no]: yes
>> Validate reply data? [no]:
>> Data pattern [0x0000ABCD]:
>> Loose, Strict, Record, Timestamp, Verbose[none]: V
>> Loose, Strict, Record, Timestamp, Verbose[V]:
>> Sweep range of sizes [n]: y
>> Sweep min size [36]: 1450
>> Sweep max size [18024]: 1550
>> Sweep interval [1]:
>> Type escape sequence to abort.
>> Sending 101, [1450..1550]-byte ICMP Echos to 203.219.113.35, timeout is 2
>> seconds:
>> Packet sent with the DF bit set
>> Reply to request 0 (2 ms) (size 1450)
>> Reply to request 1 (1 ms) (size 1451)
>> Reply to request 2 (2 ms) (size 1452)
>> Reply to request 3 (2 ms) (size 1453)
>> Reply to request 4 (1 ms) (size 1454)
>> Reply to request 5 (1 ms) (size 1455)
>> Reply to request 6 (2 ms) (size 1456)
>> Reply to request 7 (1 ms) (size 1457)
>> Reply to request 8 (1 ms) (size 1458)
>> Reply to request 9 (2 ms) (size 1459)
>> Reply to request 10 (1 ms) (size 1460)
>> Reply to request 11 (1 ms) (size 1461)
>> Reply to request 12 (2 ms) (size 1462)
>> Reply to request 13 (1 ms) (size 1463)
>> Reply to request 14 (1 ms) (size 1464)
>> Reply to request 15 (2 ms) (size 1465)
>> Reply to request 16 (1 ms) (size 1466)
>> Reply to request 17 (1 ms) (size 1467)
>> Reply to request 18 (2 ms) (size 1468)
>> Reply to request 19 (2 ms) (size 1469)
>> Reply to request 20 (1 ms) (size 1470)
>> Reply to request 21 (1 ms) (size 1471)
>> Reply to request 22 (1 ms) (size 1472)
>> Reply to request 23 (1 ms) (size 1473)
>> Reply to request 24 (2 ms) (size 1474)
>> Reply to request 25 (1 ms) (size 1475)
>> Reply to request 26 (1 ms) (size 1476)
>> Reply to request 27 (2 ms) (size 1477)
>> Reply to request 28 (1 ms) (size 1478)
>> Reply to request 29 (1 ms) (size 1479)
>> Reply to request 30 (2 ms) (size 1480)
>> Reply to request 31 (1 ms) (size 1481)
>> Reply to request 32 (1 ms) (size 1482)
>> Reply to request 33 (2 ms) (size 1483)
>> Reply to request 34 (1 ms) (size 1484)
>> Reply to request 35 (1 ms) (size 1485)
>> Reply to request 36 (1 ms) (size 1486)
>> Reply to request 37 (2 ms) (size 1487)
>> Reply to request 38 (2 ms) (size 1488)
>> Reply to request 39 (1 ms) (size 1489)
>> Reply to request 40 (1 ms) (size 1490)
>> Reply to request 41 (2 ms) (size 1491)
>> Reply to request 42 (1 ms) (size 1492)
>> Reply to request 43 (1 ms) (size 1493)
>> Reply to request 44 (2 ms) (size 1494)
>> Reply to request 45 (2 ms) (size 1495)
>> Reply to request 46 (1 ms) (size 1496)
>> Reply to request 47 (2 ms) (size 1497)
>> Reply to request 48 (1 ms) (size 1498)
>> Reply to request 49 (2 ms) (size 1499)
>> Reply to request 50 (1 ms) (size 1500)
>> Request 51 timed out (size 1501)
>> Request 52 timed out (size 1502)
>> Request 53 timed out (size 1503)
>> Request 54 timed out (size 1504)
>> Request 55 timed out (size 1505)
>> ^C
>> Success rate is 91 percent (51/56), round-trip min/avg/max = 1/1/2 ms
>>
>>
>>
>> ping vrf INTERNET
>> Protocol [ip]:
>> Target IP address: 4.2.2.4
>> Repeat count [5]: 1
>> Datagram size [100]:
>> Timeout in seconds [2]:
>> Extended commands [n]: y
>> Ingress ping [n]:
>> Source address or interface:
>> Type of service [0]:
>> Set DF bit in IP header? [no]: yes
>> Validate reply data? [no]:
>> Data pattern [0x0000ABCD]:
>> Loose, Strict, Record, Timestamp, Verbose[none]: V
>> Loose, Strict, Record, Timestamp, Verbose[V]:
>> Sweep range of sizes [n]: y
>> Sweep min size [36]: 1450
>> Sweep max size [18024]: 1550
>> Sweep interval [1]:
>> Type escape sequence to abort.
>> Sending 101, [1450..1550]-byte ICMP Echos to 4.2.2.4, timeout is 2
>> seconds:
>> Packet sent with the DF bit set
>> Reply to request 0 (151 ms) (size 1450)
>> Reply to request 1 (151 ms) (size 1451)
>> Reply to request 2 (151 ms) (size 1452)
>> Reply to request 3 (152 ms) (size 1453)
>> Reply to request 4 (152 ms) (size 1454)
>> Reply to request 5 (151 ms) (size 1455)
>> Reply to request 6 (151 ms) (size 1456)
>> Reply to request 7 (152 ms) (size 1457)
>> Reply to request 8 (151 ms) (size 1458)
>> Reply to request 9 (151 ms) (size 1459)
>> Reply to request 10 (152 ms) (size 1460)
>> Reply to request 11 (152 ms) (size 1461)
>> Reply to request 12 (152 ms) (size 1462)
>> Reply to request 13 (151 ms) (size 1463)
>> Reply to request 14 (151 ms) (size 1464)
>> Reply to request 15 (152 ms) (size 1465)
>> Reply to request 16 (151 ms) (size 1466)
>> Reply to request 17 (151 ms) (size 1467)
>> Reply to request 18 (151 ms) (size 1468)
>> Reply to request 19 (151 ms) (size 1469)
>> Reply to request 20 (152 ms) (size 1470)
>> Reply to request 21 (152 ms) (size 1471)
>> Reply to request 22 (151 ms) (size 1472)
>> Reply to request 23 (151 ms) (size 1473)
>> Reply to request 24 (152 ms) (size 1474)
>> Reply to request 25 (151 ms) (size 1475)
>> Reply to request 26 (151 ms) (size 1476)
>> Reply to request 27 (152 ms) (size 1477)
>> Reply to request 28 (151 ms) (size 1478)
>> Reply to request 29 (151 ms) (size 1479)
>> Reply to request 30 (151 ms) (size 1480)
>> Reply to request 31 (151 ms) (size 1481)
>> Reply to request 32 (151 ms) (size 1482)
>> Reply to request 33 (152 ms) (size 1483)
>> Reply to request 34 (151 ms) (size 1484)
>> Reply to request 35 (152 ms) (size 1485)
>> Reply to request 36 (151 ms) (size 1486)
>> Reply to request 37 (151 ms) (size 1487)
>> Reply to request 38 (152 ms) (size 1488)
>> Reply to request 39 (151 ms) (size 1489)
>> Reply to request 40 (151 ms) (size 1490)
>> Reply to request 41 (152 ms) (size 1491)
>> Reply to request 42 (151 ms) (size 1492)
>> Reply to request 43 (151 ms) (size 1493)
>> Reply to request 44 (152 ms) (size 1494)
>> Reply to request 45 (151 ms) (size 1495)
>> Reply to request 46 (151 ms) (size 1496)
>> Reply to request 47 (155 ms) (size 1497)
>> Reply to request 48 (151 ms) (size 1498)
>> Reply to request 49 (151 ms) (size 1499)
>> Reply to request 50 (151 ms) (size 1500)
>> Request 51 timed out (size 1501)
>> Request 52 timed out (size 1502)
>> Request 53 timed out (size 1503)
>> Request 54 timed out (size 1504)
>> ^C
>> Success rate is 92 percent (51/55), round-trip min/avg/max = 151/151/155
>> ms
>>
>> On Sat, Mar 18, 2017 at 7:31 PM, Nathan Brookfield <
>> Nathan.Brookfield at simtronic.com.au> wrote:
>>
>> > Towards you upstream providers that are switching the L2TP sessions what
>> > is the maximum MTU you can ping with the DF bit sets
>> >
>> > Nathan Brookfield
>> > Chief Executive Officer
>> >
>> > Simtronic Technologies Pty Ltd
>> > http://www.simtronic.com.au
>> >
>> > On 18 Mar 2017, at 19:16, Pouya Madani <dynamic.mineral at gmail.com>
>> wrote:
>> >
>> > Hi everyone,
>> >
>> > Need thoughts on a speed issue and would appreciate if anyone might be
>> > able to help as I am running out of ideas.
>> >
>> > I have a new ASR1002 in production to operate as LNS but services
>> > authenticated are experiencing speed issues and web pages not loading
>> > properly. My initial thought was the MTU size but this doesnt look to be
>> > the root cause as authenticated services can ping (bbc.com for
>> instance)
>> > by MTU size 1464 (28bit ICMP + 8bit PPP) ok, but (bbc again for example)
>> > web pages fail to load completely when browsed to. The sample service I
>> am
>> > testing with is a 20MB EFM and speed test sits around 16MB up/down. No
>> > input/output errors on any of the interfaces and speed is 1000 duplex
>> full
>> > on all.
>> >
>> > I would appreciate if any one can suggest anything else I might be
>> missing
>> > out.
>> >
>> > Thanks in advance.
>> > _______________________________________________
>> > AusNOG mailing list
>> > AusNOG at lists.ausnog.net
>> > http://lists.ausnog.net/mailman/listinfo/ausnog
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/201703
>> 18/1b5d7400/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Sat, 18 Mar 2017 20:03:42 +1100
>> From: Pouya Madani <dynamic.mineral at gmail.com>
>> To: michael at hobl.com.au
>> Cc: ausnog at lists.ausnog.net
>> Subject: Re: [AusNOG] Speed issues on ASR1k
>> Message-ID:
>> <CADZYfx3sOKTmLS2Ee8F-Dd_zL_i3+YoaGt3Qbid-02p9kA8qVw at mail.gm
>> ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Thanks Michael Ill PCAP the sample session. The thing is the same session
>> authenticates fine on an existing LNS (7206) with same parameters and does
>> not experience the speed issue on 7206, but does on the asr1k
>>
>> On Sat, Mar 18, 2017 at 7:27 PM, <michael at hobl.com.au> wrote:
>>
>> > My first thoughts would be to check a PCAP for retransmits and ensure
>> > there aren't any funky burst values on the session/s you're
>> authenticating.
>> >
>> > - Michael
>> >
>> >
>> > On 18 Mar. 2017 6:15 pm, Pouya Madani <dynamic.mineral at gmail.com>
>> wrote:
>> >
>> > Hi everyone,
>> >
>> > Need thoughts on a speed issue and would appreciate if anyone might be
>> > able to help as I am running out of ideas.
>> >
>> > I have a new ASR1002 in production to operate as LNS but services
>> > authenticated are experiencing speed issues and web pages not loading
>> > properly. My initial thought was the MTU size but this doesnt look to be
>> > the root cause as authenticated services can ping (bbc.com for
>> instance)
>> > by MTU size 1464 (28bit ICMP + 8bit PPP) ok, but (bbc again for example)
>> > web pages fail to load completely when browsed to. The sample service I
>> am
>> > testing with is a 20MB EFM and speed test sits around 16MB up/down. No
>> > input/output errors on any of the interfaces and speed is 1000 duplex
>> full
>> > on all.
>> >
>> > I would appreciate if any one can suggest anything else I might be
>> missing
>> > out.
>> >
>> > Thanks in advance.
>> >
>> >
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/201703
>> 18/2959254e/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Sat, 18 Mar 2017 20:14:17 +1100
>> From: Pouya Madani <dynamic.mineral at gmail.com>
>> To: trents <trents at linkingservices.com.au>, ausnog at lists.ausnog.net
>> Subject: Re: [AusNOG] Speed issues on ASR1k
>> Message-ID:
>> <CADZYfx1H25h7n09JzWa46sy+VKHv+e0xcqy8WXe6jE6f-HsUcA at mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> tcp-mss is set to adjust to 1452 under virtual-template
>> PPP is coming in via a vlan direct from the switch to the asr
>>
>> On Sat, Mar 18, 2017 at 8:09 PM, trents <trents at linkingservices.com.au>
>> wrote:
>>
>> >
>> > I've seen things like that plenty of times when using AAPT. Its usally
>> the
>> > same culprits. Do you have a tcp adjust mms in your virtual-template and
>> > are you terminating directly I to the asr or via a swicth? I has similar
>> > issues switching from 7200 to asr.
>> >
>> >
>> > Sent from my Samsung Galaxy smartphone.
>> >
>> > -------- Original message --------
>> > From: Pouya Madani <dynamic.mineral at gmail.com>
>> > Date: 18/03/2017 19:15 (GMT+10:00)
>> > To: ausnog at lists.ausnog.net
>> > Subject: [AusNOG] Speed issues on ASR1k
>> >
>> > Hi everyone,
>> >
>> > Need thoughts on a speed issue and would appreciate if anyone might be
>> > able to help as I am running out of ideas.
>> >
>> > I have a new ASR1002 in production to operate as LNS but services
>> > authenticated are experiencing speed issues and web pages not loading
>> > properly. My initial thought was the MTU size but this doesnt look to be
>> > the root cause as authenticated services can ping (bbc.com for
>> instance)
>> > by MTU size 1464 (28bit ICMP + 8bit PPP) ok, but (bbc again for example)
>> > web pages fail to load completely when browsed to. The sample service I
>> am
>> > testing with is a 20MB EFM and speed test sits around 16MB up/down. No
>> > input/output errors on any of the interfaces and speed is 1000 duplex
>> full
>> > on all.
>> >
>> > I would appreciate if any one can suggest anything else I might be
>> missing
>> > out.
>> >
>> > Thanks in advance.
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/201703
>> 18/fa212b58/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Sat, 18 Mar 2017 09:14:52 +0000
>> From: Nathan Brookfield <Nathan.Brookfield at simtronic.com.au>
>> To: "dynamic.mineral at gmail.com" <dynamic.mineral at gmail.com>
>> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
>> Subject: Re: [AusNOG] Speed issues on ASR1k
>> Message-ID: <81A37D39-0309-4518-BAD9-FF2D8BC10F1A at simtronic.com.au>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Do you have the physical interfaces on the ASR and your switch set to
>> 9000 or 9216 for Jumbo's?
>>
>> L2TP is going to take up 40 bytes of your packet so you should be able to
>> ping the LAC at 1540 bytes without fragmentation for the best performance.
>>
>> In saying that, the issue may also be virtual-reassembly on your LNS
>> interfaces as well.
>>
>> Nathan Brookfield
>> Chief Executive Officer
>>
>> Simtronic Technologies Pty Ltd
>> http://www.simtronic.com.au
>>
>> On 18 Mar 2017, at 20:02, Pouya Madani <dynamic.mineral at gmail.com<mailto:
>> dynamic.mineral at gmail.com>> wrote:
>>
>> ping to both sample LAC and 4.2.2.4 is at max MTU 1500 with DF bit set
>>
>>
>> #ping vrf INTERNET
>> Protocol [ip]:
>> Target IP address: 203.219.113.35
>> Repeat count [5]: 1
>> Datagram size [100]:
>> Timeout in seconds [2]:
>> Extended commands [n]: y
>> Ingress ping [n]:
>> Source address or interface:
>> Type of service [0]:
>> Set DF bit in IP header? [no]: yes
>> Validate reply data? [no]:
>> Data pattern [0x0000ABCD]:
>> Loose, Strict, Record, Timestamp, Verbose[none]: V
>> Loose, Strict, Record, Timestamp, Verbose[V]:
>> Sweep range of sizes [n]: y
>> Sweep min size [36]: 1450
>> Sweep max size [18024]: 1550
>> Sweep interval [1]:
>> Type escape sequence to abort.
>> Sending 101, [1450..1550]-byte ICMP Echos to 203.219.113.35, timeout is 2
>> seconds:
>> Packet sent with the DF bit set
>> Reply to request 0 (2 ms) (size 1450)
>> Reply to request 1 (1 ms) (size 1451)
>> Reply to request 2 (2 ms) (size 1452)
>> Reply to request 3 (2 ms) (size 1453)
>> Reply to request 4 (1 ms) (size 1454)
>> Reply to request 5 (1 ms) (size 1455)
>> Reply to request 6 (2 ms) (size 1456)
>> Reply to request 7 (1 ms) (size 1457)
>> Reply to request 8 (1 ms) (size 1458)
>> Reply to request 9 (2 ms) (size 1459)
>> Reply to request 10 (1 ms) (size 1460)
>> Reply to request 11 (1 ms) (size 1461)
>> Reply to request 12 (2 ms) (size 1462)
>> Reply to request 13 (1 ms) (size 1463)
>> Reply to request 14 (1 ms) (size 1464)
>> Reply to request 15 (2 ms) (size 1465)
>> Reply to request 16 (1 ms) (size 1466)
>> Reply to request 17 (1 ms) (size 1467)
>> Reply to request 18 (2 ms) (size 1468)
>> Reply to request 19 (2 ms) (size 1469)
>> Reply to request 20 (1 ms) (size 1470)
>> Reply to request 21 (1 ms) (size 1471)
>> Reply to request 22 (1 ms) (size 1472)
>> Reply to request 23 (1 ms) (size 1473)
>> Reply to request 24 (2 ms) (size 1474)
>> Reply to request 25 (1 ms) (size 1475)
>> Reply to request 26 (1 ms) (size 1476)
>> Reply to request 27 (2 ms) (size 1477)
>> Reply to request 28 (1 ms) (size 1478)
>> Reply to request 29 (1 ms) (size 1479)
>> Reply to request 30 (2 ms) (size 1480)
>> Reply to request 31 (1 ms) (size 1481)
>> Reply to request 32 (1 ms) (size 1482)
>> Reply to request 33 (2 ms) (size 1483)
>> Reply to request 34 (1 ms) (size 1484)
>> Reply to request 35 (1 ms) (size 1485)
>> Reply to request 36 (1 ms) (size 1486)
>> Reply to request 37 (2 ms) (size 1487)
>> Reply to request 38 (2 ms) (size 1488)
>> Reply to request 39 (1 ms) (size 1489)
>> Reply to request 40 (1 ms) (size 1490)
>> Reply to request 41 (2 ms) (size 1491)
>> Reply to request 42 (1 ms) (size 1492)
>> Reply to request 43 (1 ms) (size 1493)
>> Reply to request 44 (2 ms) (size 1494)
>> Reply to request 45 (2 ms) (size 1495)
>> Reply to request 46 (1 ms) (size 1496)
>> Reply to request 47 (2 ms) (size 1497)
>> Reply to request 48 (1 ms) (size 1498)
>> Reply to request 49 (2 ms) (size 1499)
>> Reply to request 50 (1 ms) (size 1500)
>> Request 51 timed out (size 1501)
>> Request 52 timed out (size 1502)
>> Request 53 timed out (size 1503)
>> Request 54 timed out (size 1504)
>> Request 55 timed out (size 1505)
>> ^C
>> Success rate is 91 percent (51/56), round-trip min/avg/max = 1/1/2 ms
>>
>>
>>
>> ping vrf INTERNET
>> Protocol [ip]:
>> Target IP address: 4.2.2.4
>> Repeat count [5]: 1
>> Datagram size [100]:
>> Timeout in seconds [2]:
>> Extended commands [n]: y
>> Ingress ping [n]:
>> Source address or interface:
>> Type of service [0]:
>> Set DF bit in IP header? [no]: yes
>> Validate reply data? [no]:
>> Data pattern [0x0000ABCD]:
>> Loose, Strict, Record, Timestamp, Verbose[none]: V
>> Loose, Strict, Record, Timestamp, Verbose[V]:
>> Sweep range of sizes [n]: y
>> Sweep min size [36]: 1450
>> Sweep max size [18024]: 1550
>> Sweep interval [1]:
>> Type escape sequence to abort.
>> Sending 101, [1450..1550]-byte ICMP Echos to 4.2.2.4, timeout is 2
>> seconds:
>> Packet sent with the DF bit set
>> Reply to request 0 (151 ms) (size 1450)
>> Reply to request 1 (151 ms) (size 1451)
>> Reply to request 2 (151 ms) (size 1452)
>> Reply to request 3 (152 ms) (size 1453)
>> Reply to request 4 (152 ms) (size 1454)
>> Reply to request 5 (151 ms) (size 1455)
>> Reply to request 6 (151 ms) (size 1456)
>> Reply to request 7 (152 ms) (size 1457)
>> Reply to request 8 (151 ms) (size 1458)
>> Reply to request 9 (151 ms) (size 1459)
>> Reply to request 10 (152 ms) (size 1460)
>> Reply to request 11 (152 ms) (size 1461)
>> Reply to request 12 (152 ms) (size 1462)
>> Reply to request 13 (151 ms) (size 1463)
>> Reply to request 14 (151 ms) (size 1464)
>> Reply to request 15 (152 ms) (size 1465)
>> Reply to request 16 (151 ms) (size 1466)
>> Reply to request 17 (151 ms) (size 1467)
>> Reply to request 18 (151 ms) (size 1468)
>> Reply to request 19 (151 ms) (size 1469)
>> Reply to request 20 (152 ms) (size 1470)
>> Reply to request 21 (152 ms) (size 1471)
>> Reply to request 22 (151 ms) (size 1472)
>> Reply to request 23 (151 ms) (size 1473)
>> Reply to request 24 (152 ms) (size 1474)
>> Reply to request 25 (151 ms) (size 1475)
>> Reply to request 26 (151 ms) (size 1476)
>> Reply to request 27 (152 ms) (size 1477)
>> Reply to request 28 (151 ms) (size 1478)
>> Reply to request 29 (151 ms) (size 1479)
>> Reply to request 30 (151 ms) (size 1480)
>> Reply to request 31 (151 ms) (size 1481)
>> Reply to request 32 (151 ms) (size 1482)
>> Reply to request 33 (152 ms) (size 1483)
>> Reply to request 34 (151 ms) (size 1484)
>> Reply to request 35 (152 ms) (size 1485)
>> Reply to request 36 (151 ms) (size 1486)
>> Reply to request 37 (151 ms) (size 1487)
>> Reply to request 38 (152 ms) (size 1488)
>> Reply to request 39 (151 ms) (size 1489)
>> Reply to request 40 (151 ms) (size 1490)
>> Reply to request 41 (152 ms) (size 1491)
>> Reply to request 42 (151 ms) (size 1492)
>> Reply to request 43 (151 ms) (size 1493)
>> Reply to request 44 (152 ms) (size 1494)
>> Reply to request 45 (151 ms) (size 1495)
>> Reply to request 46 (151 ms) (size 1496)
>> Reply to request 47 (155 ms) (size 1497)
>> Reply to request 48 (151 ms) (size 1498)
>> Reply to request 49 (151 ms) (size 1499)
>> Reply to request 50 (151 ms) (size 1500)
>> Request 51 timed out (size 1501)
>> Request 52 timed out (size 1502)
>> Request 53 timed out (size 1503)
>> Request 54 timed out (size 1504)
>> ^C
>> Success rate is 92 percent (51/55), round-trip min/avg/max = 151/151/155
>> ms
>>
>> On Sat, Mar 18, 2017 at 7:31 PM, Nathan Brookfield <
>> Nathan.Brookfield at simtronic.com.au<mailto:Nathan.Brookfield
>> @simtronic.com.au>> wrote:
>> Towards you upstream providers that are switching the L2TP sessions what
>> is the maximum MTU you can ping with the DF bit sets
>>
>> Nathan Brookfield
>> Chief Executive Officer
>>
>> Simtronic Technologies Pty Ltd
>> http://www.simtronic.com.au
>>
>> On 18 Mar 2017, at 19:16, Pouya Madani <dynamic.mineral at gmail.com<mailto:
>> dynamic.mineral at gmail.com>> wrote:
>>
>> Hi everyone,
>>
>> Need thoughts on a speed issue and would appreciate if anyone might be
>> able to help as I am running out of ideas.
>>
>> I have a new ASR1002 in production to operate as LNS but services
>> authenticated are experiencing speed issues and web pages not loading
>> properly. My initial thought was the MTU size but this doesnt look to be
>> the root cause as authenticated services can ping (bbc.com<http://bbc.com>
>> for instance) by MTU size 1464 (28bit ICMP + 8bit PPP) ok, but (bbc again
>> for example) web pages fail to load completely when browsed to. The sample
>> service I am testing with is a 20MB EFM and speed test sits around 16MB
>> up/down. No input/output errors on any of the interfaces and speed is 1000
>> duplex full on all.
>>
>> I would appreciate if any one can suggest anything else I might be
>> missing out.
>>
>> Thanks in advance.
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/201703
>> 18/935cf2e6/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Sat, 18 Mar 2017 09:20:43 +0000
>> From: Nathan Brookfield <Nathan.Brookfield at simtronic.com.au>
>> To: "dynamic.mineral at gmail.com" <dynamic.mineral at gmail.com>
>> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
>> Subject: Re: [AusNOG] Speed issues on ASR1k
>> Message-ID:
>> <ME1PR01MB16018B68812451D6BDD32C45DE380 at ME1PR01MB1601.ausprd
>> 01.prod.outlook.com>
>>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> For example:
>>
>>
>> lns01.syd02.nsw#ping 203.219.113.35 source lo100 size 1540 df
>>
>> Type escape sequence to abort.
>> Sending 5, 1540-byte ICMP Echos to 203.219.113.35, timeout is 2 seconds:
>> Packet sent with a source address of X.X.X.acket sent with the DF bit set
>> !!!!!
>> Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms
>> lns01.syd02.nsw#
>>
>>
>> Kindest Regards,
>>
>> Nathan Brookfield (VK2NAB)
>>
>>
>>
>> Chief Executive Officer
>>
>> Simtronic Technologies Pty Ltd
>>
>>
>>
>> Local: (02) 4749 4949 | Fax: (02) 4749 4950 | Direct: (02) 4749 4951
>>
>> Web: http://www.simtronic.com.au<http://www.simtronic.com.au/> | E-mail:
>> nathan.brookfield at simtronic.com.au<mailto:nathan.brookfield@
>> simtronic.com.au>
>>
>>
>>
>> ________________________________
>> From: AusNOG <ausnog-bounces at lists.ausnog.net> on behalf of Nathan
>> Brookfield <Nathan.Brookfield at simtronic.com.au>
>> Sent: Saturday, 18 March 2017 8:14 PM
>> To: dynamic.mineral at gmail.com
>> Cc: ausnog at lists.ausnog.net
>> Subject: Re: [AusNOG] Speed issues on ASR1k
>>
>> Do you have the physical interfaces on the ASR and your switch set to
>> 9000 or 9216 for Jumbo's?
>>
>> L2TP is going to take up 40 bytes of your packet so you should be able to
>> ping the LAC at 1540 bytes without fragmentation for the best performance.
>>
>> In saying that, the issue may also be virtual-reassembly on your LNS
>> interfaces as well.
>>
>> Nathan Brookfield
>> Chief Executive Officer
>>
>> Simtronic Technologies Pty Ltd
>> http://www.simtronic.com.au
>>
>> On 18 Mar 2017, at 20:02, Pouya Madani <dynamic.mineral at gmail.com<mailto:
>> dynamic.mineral at gmail.com>> wrote:
>>
>> ping to both sample LAC and 4.2.2.4 is at max MTU 1500 with DF bit set
>>
>>
>> #ping vrf INTERNET
>> Protocol [ip]:
>> Target IP address: 203.219.113.35
>> Repeat count [5]: 1
>> Datagram size [100]:
>> Timeout in seconds [2]:
>> Extended commands [n]: y
>> Ingress ping [n]:
>> Source address or interface:
>> Type of service [0]:
>> Set DF bit in IP header? [no]: yes
>> Validate reply data? [no]:
>> Data pattern [0x0000ABCD]:
>> Loose, Strict, Record, Timestamp, Verbose[none]: V
>> Loose, Strict, Record, Timestamp, Verbose[V]:
>> Sweep range of sizes [n]: y
>> Sweep min size [36]: 1450
>> Sweep max size [18024]: 1550
>> Sweep interval [1]:
>> Type escape sequence to abort.
>> Sending 101, [1450..1550]-byte ICMP Echos to 203.219.113.35, timeout is 2
>> seconds:
>> Packet sent with the DF bit set
>> Reply to request 0 (2 ms) (size 1450)
>> Reply to request 1 (1 ms) (size 1451)
>> Reply to request 2 (2 ms) (size 1452)
>> Reply to request 3 (2 ms) (size 1453)
>> Reply to request 4 (1 ms) (size 1454)
>> Reply to request 5 (1 ms) (size 1455)
>> Reply to request 6 (2 ms) (size 1456)
>> Reply to request 7 (1 ms) (size 1457)
>> Reply to request 8 (1 ms) (size 1458)
>> Reply to request 9 (2 ms) (size 1459)
>> Reply to request 10 (1 ms) (size 1460)
>> Reply to request 11 (1 ms) (size 1461)
>> Reply to request 12 (2 ms) (size 1462)
>> Reply to request 13 (1 ms) (size 1463)
>> Reply to request 14 (1 ms) (size 1464)
>> Reply to request 15 (2 ms) (size 1465)
>> Reply to request 16 (1 ms) (size 1466)
>> Reply to request 17 (1 ms) (size 1467)
>> Reply to request 18 (2 ms) (size 1468)
>> Reply to request 19 (2 ms) (size 1469)
>> Reply to request 20 (1 ms) (size 1470)
>> Reply to request 21 (1 ms) (size 1471)
>> Reply to request 22 (1 ms) (size 1472)
>> Reply to request 23 (1 ms) (size 1473)
>> Reply to request 24 (2 ms) (size 1474)
>> Reply to request 25 (1 ms) (size 1475)
>> Reply to request 26 (1 ms) (size 1476)
>> Reply to request 27 (2 ms) (size 1477)
>> Reply to request 28 (1 ms) (size 1478)
>> Reply to request 29 (1 ms) (size 1479)
>> Reply to request 30 (2 ms) (size 1480)
>> Reply to request 31 (1 ms) (size 1481)
>> Reply to request 32 (1 ms) (size 1482)
>> Reply to request 33 (2 ms) (size 1483)
>> Reply to request 34 (1 ms) (size 1484)
>> Reply to request 35 (1 ms) (size 1485)
>> Reply to request 36 (1 ms) (size 1486)
>> Reply to request 37 (2 ms) (size 1487)
>> Reply to request 38 (2 ms) (size 1488)
>> Reply to request 39 (1 ms) (size 1489)
>> Reply to request 40 (1 ms) (size 1490)
>> Reply to request 41 (2 ms) (size 1491)
>> Reply to request 42 (1 ms) (size 1492)
>> Reply to request 43 (1 ms) (size 1493)
>> Reply to request 44 (2 ms) (size 1494)
>> Reply to request 45 (2 ms) (size 1495)
>> Reply to request 46 (1 ms) (size 1496)
>> Reply to request 47 (2 ms) (size 1497)
>> Reply to request 48 (1 ms) (size 1498)
>> Reply to request 49 (2 ms) (size 1499)
>> Reply to request 50 (1 ms) (size 1500)
>> Request 51 timed out (size 1501)
>> Request 52 timed out (size 1502)
>> Request 53 timed out (size 1503)
>> Request 54 timed out (size 1504)
>> Request 55 timed out (size 1505)
>> ^C
>> Success rate is 91 percent (51/56), round-trip min/avg/max = 1/1/2 ms
>>
>>
>>
>> ping vrf INTERNET
>> Protocol [ip]:
>> Target IP address: 4.2.2.4
>> Repeat count [5]: 1
>> Datagram size [100]:
>> Timeout in seconds [2]:
>> Extended commands [n]: y
>> Ingress ping [n]:
>> Source address or interface:
>> Type of service [0]:
>> Set DF bit in IP header? [no]: yes
>> Validate reply data? [no]:
>> Data pattern [0x0000ABCD]:
>> Loose, Strict, Record, Timestamp, Verbose[none]: V
>> Loose, Strict, Record, Timestamp, Verbose[V]:
>> Sweep range of sizes [n]: y
>> Sweep min size [36]: 1450
>> Sweep max size [18024]: 1550
>> Sweep interval [1]:
>> Type escape sequence to abort.
>> Sending 101, [1450..1550]-byte ICMP Echos to 4.2.2.4, timeout is 2
>> seconds:
>> Packet sent with the DF bit set
>> Reply to request 0 (151 ms) (size 1450)
>> Reply to request 1 (151 ms) (size 1451)
>> Reply to request 2 (151 ms) (size 1452)
>> Reply to request 3 (152 ms) (size 1453)
>> Reply to request 4 (152 ms) (size 1454)
>> Reply to request 5 (151 ms) (size 1455)
>> Reply to request 6 (151 ms) (size 1456)
>> Reply to request 7 (152 ms) (size 1457)
>> Reply to request 8 (151 ms) (size 1458)
>> Reply to request 9 (151 ms) (size 1459)
>> Reply to request 10 (152 ms) (size 1460)
>> Reply to request 11 (152 ms) (size 1461)
>> Reply to request 12 (152 ms) (size 1462)
>> Reply to request 13 (151 ms) (size 1463)
>> Reply to request 14 (151 ms) (size 1464)
>> Reply to request 15 (152 ms) (size 1465)
>> Reply to request 16 (151 ms) (size 1466)
>> Reply to request 17 (151 ms) (size 1467)
>> Reply to request 18 (151 ms) (size 1468)
>> Reply to request 19 (151 ms) (size 1469)
>> Reply to request 20 (152 ms) (size 1470)
>> Reply to request 21 (152 ms) (size 1471)
>> Reply to request 22 (151 ms) (size 1472)
>> Reply to request 23 (151 ms) (size 1473)
>> Reply to request 24 (152 ms) (size 1474)
>> Reply to request 25 (151 ms) (size 1475)
>> Reply to request 26 (151 ms) (size 1476)
>> Reply to request 27 (152 ms) (size 1477)
>> Reply to request 28 (151 ms) (size 1478)
>> Reply to request 29 (151 ms) (size 1479)
>> Reply to request 30 (151 ms) (size 1480)
>> Reply to request 31 (151 ms) (size 1481)
>> Reply to request 32 (151 ms) (size 1482)
>> Reply to request 33 (152 ms) (size 1483)
>> Reply to request 34 (151 ms) (size 1484)
>> Reply to request 35 (152 ms) (size 1485)
>> Reply to request 36 (151 ms) (size 1486)
>> Reply to request 37 (151 ms) (size 1487)
>> Reply to request 38 (152 ms) (size 1488)
>> Reply to request 39 (151 ms) (size 1489)
>> Reply to request 40 (151 ms) (size 1490)
>> Reply to request 41 (152 ms) (size 1491)
>> Reply to request 42 (151 ms) (size 1492)
>> Reply to request 43 (151 ms) (size 1493)
>> Reply to request 44 (152 ms) (size 1494)
>> Reply to request 45 (151 ms) (size 1495)
>> Reply to request 46 (151 ms) (size 1496)
>> Reply to request 47 (155 ms) (size 1497)
>> Reply to request 48 (151 ms) (size 1498)
>> Reply to request 49 (151 ms) (size 1499)
>> Reply to request 50 (151 ms) (size 1500)
>> Request 51 timed out (size 1501)
>> Request 52 timed out (size 1502)
>> Request 53 timed out (size 1503)
>> Request 54 timed out (size 1504)
>> ^C
>> Success rate is 92 percent (51/55), round-trip min/avg/max = 151/151/155
>> ms
>>
>> On Sat, Mar 18, 2017 at 7:31 PM, Nathan Brookfield <
>> Nathan.Brookfield at simtronic.com.au<mailto:Nathan.Brookfield
>> @simtronic.com.au>> wrote:
>> Towards you upstream providers that are switching the L2TP sessions what
>> is the maximum MTU you can ping with the DF bit sets
>>
>> Nathan Brookfield
>> Chief Executive Officer
>>
>> Simtronic Technologies Pty Ltd
>> http://www.simtronic.com.au
>>
>> On 18 Mar 2017, at 19:16, Pouya Madani <dynamic.mineral at gmail.com<mailto:
>> dynamic.mineral at gmail.com>> wrote:
>>
>> Hi everyone,
>>
>> Need thoughts on a speed issue and would appreciate if anyone might be
>> able to help as I am running out of ideas.
>>
>> I have a new ASR1002 in production to operate as LNS but services
>> authenticated are experiencing speed issues and web pages not loading
>> properly. My initial thought was the MTU size but this doesnt look to be
>> the root cause as authenticated services can ping (bbc.com<http://bbc.com>
>> for instance) by MTU size 1464 (28bit ICMP + 8bit PPP) ok, but (bbc again
>> for example) web pages fail to load completely when browsed to. The sample
>> service I am testing with is a 20MB EFM and speed test sits around 16MB
>> up/down. No input/output errors on any of the interfaces and speed is 1000
>> duplex full on all.
>>
>> I would appreciate if any one can suggest anything else I might be
>> missing out.
>>
>> Thanks in advance.
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/201703
>> 18/b88519e2/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 9
>> Date: Sat, 18 Mar 2017 20:20:31 +1100
>> From: Pouya Madani <dynamic.mineral at gmail.com>
>> To: Nathan Brookfield <Nathan.Brookfield at simtronic.com.au>
>> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
>> Subject: Re: [AusNOG] Speed issues on ASR1k
>> Message-ID:
>> <CADZYfx2=1QCPPn-a6geM4pUBnNz9jaM2TxmJ24B4h4LBaLTnfQ at mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Jumbo is set to 9216 on both Core and Customer-facing interfaces
>>
>> MEL-NDC-CORE01#sh run int gigabitEthernet 0/0/0 | i mtu
>> mtu 9216
>> MEL-NDC-CORE01#sh run int gigabitEthernet 0/0/1 | i mtu
>> mtu 9216
>> MEL-NDC-CORE01#
>>
>>
>>
>> I agree with you Nathan but this is an issue I can look deeper into at a
>> later in time. This does not look to be the root cause of my problem at
>> this stage I just double checked on my other LNS (7206) and max ping MTU
>> is
>> 1500 and the same service does not have speed issues on the 7206
>>
>> On Sat, Mar 18, 2017 at 8:14 PM, Nathan Brookfield <
>> Nathan.Brookfield at simtronic.com.au> wrote:
>>
>> > Do you have the physical interfaces on the ASR and your switch set to
>> 9000
>> > or 9216 for Jumbo's?
>> >
>> > L2TP is going to take up 40 bytes of your packet so you should be able
>> to
>> > ping the LAC at 1540 bytes without fragmentation for the best
>> performance.
>> >
>> > In saying that, the issue may also be virtual-reassembly on your LNS
>> > interfaces as well.
>> >
>> > Nathan Brookfield
>> > Chief Executive Officer
>> >
>> > Simtronic Technologies Pty Ltd
>> > http://www.simtronic.com.au
>> >
>> > On 18 Mar 2017, at 20:02, Pouya Madani <dynamic.mineral at gmail.com>
>> wrote:
>> >
>> > ping to both sample LAC and 4.2.2.4 is at max MTU 1500 with DF bit set
>> >
>> >
>> > #ping vrf INTERNET
>> > Protocol [ip]:
>> > Target IP address: 203.219.113.35
>> > Repeat count [5]: 1
>> > Datagram size [100]:
>> > Timeout in seconds [2]:
>> > Extended commands [n]: y
>> > Ingress ping [n]:
>> > Source address or interface:
>> > Type of service [0]:
>> > Set DF bit in IP header? [no]: yes
>> > Validate reply data? [no]:
>> > Data pattern [0x0000ABCD]:
>> > Loose, Strict, Record, Timestamp, Verbose[none]: V
>> > Loose, Strict, Record, Timestamp, Verbose[V]:
>> > Sweep range of sizes [n]: y
>> > Sweep min size [36]: 1450
>> > Sweep max size [18024]: 1550
>> > Sweep interval [1]:
>> > Type escape sequence to abort.
>> > Sending 101, [1450..1550]-byte ICMP Echos to 203.219.113.35, timeout is
>> 2
>> > seconds:
>> > Packet sent with the DF bit set
>> > Reply to request 0 (2 ms) (size 1450)
>> > Reply to request 1 (1 ms) (size 1451)
>> > Reply to request 2 (2 ms) (size 1452)
>> > Reply to request 3 (2 ms) (size 1453)
>> > Reply to request 4 (1 ms) (size 1454)
>> > Reply to request 5 (1 ms) (size 1455)
>> > Reply to request 6 (2 ms) (size 1456)
>> > Reply to request 7 (1 ms) (size 1457)
>> > Reply to request 8 (1 ms) (size 1458)
>> > Reply to request 9 (2 ms) (size 1459)
>> > Reply to request 10 (1 ms) (size 1460)
>> > Reply to request 11 (1 ms) (size 1461)
>> > Reply to request 12 (2 ms) (size 1462)
>> > Reply to request 13 (1 ms) (size 1463)
>> > Reply to request 14 (1 ms) (size 1464)
>> > Reply to request 15 (2 ms) (size 1465)
>> > Reply to request 16 (1 ms) (size 1466)
>> > Reply to request 17 (1 ms) (size 1467)
>> > Reply to request 18 (2 ms) (size 1468)
>> > Reply to request 19 (2 ms) (size 1469)
>> > Reply to request 20 (1 ms) (size 1470)
>> > Reply to request 21 (1 ms) (size 1471)
>> > Reply to request 22 (1 ms) (size 1472)
>> > Reply to request 23 (1 ms) (size 1473)
>> > Reply to request 24 (2 ms) (size 1474)
>> > Reply to request 25 (1 ms) (size 1475)
>> > Reply to request 26 (1 ms) (size 1476)
>> > Reply to request 27 (2 ms) (size 1477)
>> > Reply to request 28 (1 ms) (size 1478)
>> > Reply to request 29 (1 ms) (size 1479)
>> > Reply to request 30 (2 ms) (size 1480)
>> > Reply to request 31 (1 ms) (size 1481)
>> > Reply to request 32 (1 ms) (size 1482)
>> > Reply to request 33 (2 ms) (size 1483)
>> > Reply to request 34 (1 ms) (size 1484)
>> > Reply to request 35 (1 ms) (size 1485)
>> > Reply to request 36 (1 ms) (size 1486)
>> > Reply to request 37 (2 ms) (size 1487)
>> > Reply to request 38 (2 ms) (size 1488)
>> > Reply to request 39 (1 ms) (size 1489)
>> > Reply to request 40 (1 ms) (size 1490)
>> > Reply to request 41 (2 ms) (size 1491)
>> > Reply to request 42 (1 ms) (size 1492)
>> > Reply to request 43 (1 ms) (size 1493)
>> > Reply to request 44 (2 ms) (size 1494)
>> > Reply to request 45 (2 ms) (size 1495)
>> > Reply to request 46 (1 ms) (size 1496)
>> > Reply to request 47 (2 ms) (size 1497)
>> > Reply to request 48 (1 ms) (size 1498)
>> > Reply to request 49 (2 ms) (size 1499)
>> > Reply to request 50 (1 ms) (size 1500)
>> > Request 51 timed out (size 1501)
>> > Request 52 timed out (size 1502)
>> > Request 53 timed out (size 1503)
>> > Request 54 timed out (size 1504)
>> > Request 55 timed out (size 1505)
>> > ^C
>> > Success rate is 91 percent (51/56), round-trip min/avg/max = 1/1/2 ms
>> >
>> >
>> >
>> > ping vrf INTERNET
>> > Protocol [ip]:
>> > Target IP address: 4.2.2.4
>> > Repeat count [5]: 1
>> > Datagram size [100]:
>> > Timeout in seconds [2]:
>> > Extended commands [n]: y
>> > Ingress ping [n]:
>> > Source address or interface:
>> > Type of service [0]:
>> > Set DF bit in IP header? [no]: yes
>> > Validate reply data? [no]:
>> > Data pattern [0x0000ABCD]:
>> > Loose, Strict, Record, Timestamp, Verbose[none]: V
>> > Loose, Strict, Record, Timestamp, Verbose[V]:
>> > Sweep range of sizes [n]: y
>> > Sweep min size [36]: 1450
>> > Sweep max size [18024]: 1550
>> > Sweep interval [1]:
>> > Type escape sequence to abort.
>> > Sending 101, [1450..1550]-byte ICMP Echos to 4.2.2.4, timeout is 2
>> seconds:
>> > Packet sent with the DF bit set
>> > Reply to request 0 (151 ms) (size 1450)
>> > Reply to request 1 (151 ms) (size 1451)
>> > Reply to request 2 (151 ms) (size 1452)
>> > Reply to request 3 (152 ms) (size 1453)
>> > Reply to request 4 (152 ms) (size 1454)
>> > Reply to request 5 (151 ms) (size 1455)
>> > Reply to request 6 (151 ms) (size 1456)
>> > Reply to request 7 (152 ms) (size 1457)
>> > Reply to request 8 (151 ms) (size 1458)
>> > Reply to request 9 (151 ms) (size 1459)
>> > Reply to request 10 (152 ms) (size 1460)
>> > Reply to request 11 (152 ms) (size 1461)
>> > Reply to request 12 (152 ms) (size 1462)
>> > Reply to request 13 (151 ms) (size 1463)
>> > Reply to request 14 (151 ms) (size 1464)
>> > Reply to request 15 (152 ms) (size 1465)
>> > Reply to request 16 (151 ms) (size 1466)
>> > Reply to request 17 (151 ms) (size 1467)
>> > Reply to request 18 (151 ms) (size 1468)
>> > Reply to request 19 (151 ms) (size 1469)
>> > Reply to request 20 (152 ms) (size 1470)
>> > Reply to request 21 (152 ms) (size 1471)
>> > Reply to request 22 (151 ms) (size 1472)
>> > Reply to request 23 (151 ms) (size 1473)
>> > Reply to request 24 (152 ms) (size 1474)
>> > Reply to request 25 (151 ms) (size 1475)
>> > Reply to request 26 (151 ms) (size 1476)
>> > Reply to request 27 (152 ms) (size 1477)
>> > Reply to request 28 (151 ms) (size 1478)
>> > Reply to request 29 (151 ms) (size 1479)
>> > Reply to request 30 (151 ms) (size 1480)
>> > Reply to request 31 (151 ms) (size 1481)
>> > Reply to request 32 (151 ms) (size 1482)
>> > Reply to request 33 (152 ms) (size 1483)
>> > Reply to request 34 (151 ms) (size 1484)
>> > Reply to request 35 (152 ms) (size 1485)
>> > Reply to request 36 (151 ms) (size 1486)
>> > Reply to request 37 (151 ms) (size 1487)
>> > Reply to request 38 (152 ms) (size 1488)
>> > Reply to request 39 (151 ms) (size 1489)
>> > Reply to request 40 (151 ms) (size 1490)
>> > Reply to request 41 (152 ms) (size 1491)
>> > Reply to request 42 (151 ms) (size 1492)
>> > Reply to request 43 (151 ms) (size 1493)
>> > Reply to request 44 (152 ms) (size 1494)
>> > Reply to request 45 (151 ms) (size 1495)
>> > Reply to request 46 (151 ms) (size 1496)
>> > Reply to request 47 (155 ms) (size 1497)
>> > Reply to request 48 (151 ms) (size 1498)
>> > Reply to request 49 (151 ms) (size 1499)
>> > Reply to request 50 (151 ms) (size 1500)
>> > Request 51 timed out (size 1501)
>> > Request 52 timed out (size 1502)
>> > Request 53 timed out (size 1503)
>> > Request 54 timed out (size 1504)
>> > ^C
>> > Success rate is 92 percent (51/55), round-trip min/avg/max =
>> 151/151/155 ms
>> >
>> > On Sat, Mar 18, 2017 at 7:31 PM, Nathan Brookfield <
>> > Nathan.Brookfield at simtronic.com.au> wrote:
>> >
>> >> Towards you upstream providers that are switching the L2TP sessions
>> what
>> >> is the maximum MTU you can ping with the DF bit sets
>> >>
>> >> Nathan Brookfield
>> >> Chief Executive Officer
>> >>
>> >> Simtronic Technologies Pty Ltd
>> >> http://www.simtronic.com.au
>> >>
>> >> On 18 Mar 2017, at 19:16, Pouya Madani <dynamic.mineral at gmail.com>
>> wrote:
>> >>
>> >> Hi everyone,
>> >>
>> >> Need thoughts on a speed issue and would appreciate if anyone might be
>> >> able to help as I am running out of ideas.
>> >>
>> >> I have a new ASR1002 in production to operate as LNS but services
>> >> authenticated are experiencing speed issues and web pages not loading
>> >> properly. My initial thought was the MTU size but this doesnt look to
>> be
>> >> the root cause as authenticated services can ping (bbc.com for
>> instance)
>> >> by MTU size 1464 (28bit ICMP + 8bit PPP) ok, but (bbc again for
>> example)
>> >> web pages fail to load completely when browsed to. The sample service
>> I am
>> >> testing with is a 20MB EFM and speed test sits around 16MB up/down. No
>> >> input/output errors on any of the interfaces and speed is 1000 duplex
>> full
>> >> on all.
>> >>
>> >> I would appreciate if any one can suggest anything else I might be
>> >> missing out.
>> >>
>> >> Thanks in advance.
>> >> _______________________________________________
>> >> AusNOG mailing list
>> >> AusNOG at lists.ausnog.net
>> >> http://lists.ausnog.net/mailman/listinfo/ausnog
>> >>
>> >
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/201703
>> 18/b190b924/attachment.html>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>> ------------------------------
>>
>> End of AusNOG Digest, Vol 61, Issue 36
>> **************************************
>>
>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20170319/30891a1e/attachment-0001.html>
More information about the AusNOG
mailing list