ADSL pppoe MTU setting

I am trying to optimize my pppoe mtu setting, first using from cmd i found 1452 + 28 (1480) to be best but when I try same test from MT (OS Ver 3.30) is giving from “corrupted” to “packet too large and cannot be fragmented”


http://www6.nohold.net/Cisco2/ukp.aspx?pid=80&login=1&app=search&vw=1&articleid=386


Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\admin>ping http://www.google.ie -f -l 1472

Pinging www-cctld.l.google.com [209.85.143.94] with 1472 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 209.85.143.94:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\admin>ping http://www.google.ie -f -l 1492

Pinging www-cctld.l.google.com [209.85.143.94] with 1492 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 209.85.143.94:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\admin>ping http://www.google.ie -f -l 1452

Pinging www-cctld.l.google.com [209.85.143.94] with 1452 bytes of data:
Reply from 209.85.143.94: bytes=64 (sent 1452) time=57ms TTL=52
Reply from 209.85.143.94: bytes=64 (sent 1452) time=57ms TTL=52
Reply from 209.85.143.94: bytes=64 (sent 1452) time=58ms TTL=52
Reply from 209.85.143.94: bytes=64 (sent 1452) time=58ms TTL=52

Ping statistics for 209.85.143.94:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 57ms, Maximum = 58ms, Average = 57ms


MikroTik RouterOS 3.30 (c) 1999-2009 http://www.mikrotik.com/

/interface pppoe-client
add ac-name=“” add-default-route=no allow=pap,chap,mschap1,mschap2 comment=“”
dial-on-demand=no disabled=no interface=ether1 max-mru=1480 max-mtu=1480
mrru=disabled name=pppoe-out1 password=broadband1 profile=default
service-name=“” use-peer-dns=no user=XXXXXXXX
add ac-name=“” add-default-route=no allow=pap,chap,mschap1,mschap2 comment=“”
dial-on-demand=no disabled=no interface=ether2 max-mru=1480 max-mtu=1480
mrru=disabled name=pppoe-out2 password=broadband1 profile=default
service-name=“” use-peer-dns=no user=XXXXXXXX

[admin@Load_X] > ping http://www.google.com size=1480 do-not-fragment
209.85.143.99 92 byte ping: ttl=54 time=39 ms (corrupted)
209.85.143.99 92 byte ping: ttl=54 time=42 ms (corrupted)
209.85.143.99 92 byte ping: ttl=54 time=38 ms (corrupted)
209.85.143.99 92 byte ping: ttl=54 time=48 ms (corrupted)
209.85.143.99 92 byte ping: ttl=54 time=39 ms (corrupted)
5 packets transmitted, 5 packets received, 0% packet loss
100% replies corrupted
round-trip min/avg/max = 38/41.2/48 ms

[admin@Load_X] > ping http://www.google.com size=1452 do-not-fragment
209.85.143.99 92 byte ping: ttl=54 time=39 ms (corrupted)
209.85.143.99 92 byte ping: ttl=54 time=38 ms (corrupted)
209.85.143.99 92 byte ping: ttl=54 time=39 ms (corrupted)
209.85.143.99 92 byte ping: ttl=54 time=38 ms (corrupted)
209.85.143.99 92 byte ping: ttl=54 time=38 ms (corrupted)
5 packets transmitted, 5 packets received, 0% packet loss
100% replies corrupted
round-trip min/avg/max = 38/38.4/39 ms

[admin@Load_X] > ping http://www.google.com size=1492 do-not-fragment
packet too large and cannot be fragmented
packet too large and cannot be fragmented
packet too large and cannot be fragmented
packet too large and cannot be fragmented
packet too large and cannot be fragmented

There is nothing wrong with any of those replies. your maximum mtu indeed appears to be 1480. ‘(corrupted)’ means the router did get the reply but the content of the packet was not the same as it was in the ping. some servers (like google for example), limit the reply bytes. in windows you see that as ‘bytes=64 (sent 1452)’ , in routeros, you see it as ‘(corrupted)’. also unlike windows(that you need to add 28 bytes to the pinged packet), in linux the size that you specify is the actually size of the packets that will be sent. 1492 is more than your mtu so you get packet too large response.

@Devil

Thank you for your reply