Help MTU SIZE

[ammar19814]

Hello,

      I have a paclet flow issue and I know its due to MTU size over ip/vpn. I need to know the optimum size of the MTU size. Check the trace log from the router and let me know ..

:

HEAD.OFFICE#ping

Protocol [ip]:

Target IP address: 192.168.188.1

Repeat count [5]: 10

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: 130.1.1.4

Type of service [0]:

Set DF bit in IP header? [no]: yes

Validate reply data? [no]:

Data pattern [0xABCD]:

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]: 1500

Sweep interval [1]:

Type escape sequence to abort.

Sending 510, [1450..1500]-byte ICMP Echos to 192.168.188.1, timeout is 2 seconds:

Packet sent with a source address of 130.1.1.4

Packet sent with the DF bit set

Reply to request 0 (228 ms) (size 1450)

Reply to request 1 (224 ms) (size 1451)

Reply to request 2 (224 ms) (size 1452)

Reply to request 3 (224 ms) (size 1453)

Reply to request 4 (220 ms) (size 1454)

Reply to request 5 (428 ms) (size 1455)

Reply to request 6 (228 ms) (size 1456)

Request 7 timed out (size 1457)

Request 8 timed out (size 1458)

Request 9 timed out (size 1459)

Request 10 timed out (size 1460)

Request 11 timed out (size 1461)

Request 12 timed out (size 1462)

Request 13 timed out (size 1463)

Request 14 timed out (size 1464)

Request 15 timed out (size 1465)

Request 16 timed out (size 1466)

Request 17 timed out (size 1467)

Request 18 timed out (size 1468)

Request 19 timed out (size 1469)

Request 20 timed out (size 1470)

Request 21 timed out (size 1471)

Request 22 timed out (size 1472)

Request 23 timed out (size 1473)

Request 24 timed out (size 1474)

Request 25 timed out (size 1475)

Request 26 timed out (size 1476)

Request 27 timed out (size 1477)

Request 28 timed out (size 1478)

Request 29 timed out (size 1479)

Request 30 timed out (size 1480)

Request 31 timed out (size 1481)

Request 32 timed out (size 1482)

Request 33 timed out (size 1483)

Request 34 timed out (size 1484)

Request 35 timed out (size 1485)

Request 36 timed out (size 1486)

Request 37 timed out (size 1487)

Request 38 timed out (size 1488)

Request 39 timed out (size 1489)

Request 40 timed out (size 1490)

Request 41 timed out (size 1491)

Request 42 timed out (size 1492)

Request 43 timed out (size 1493)

Request 44 timed out (size 1494)

Request 45 timed out (size 1495)

Request 46 timed out (size 1496)

Request 47 timed out (size 1497)

Request 48 timed out (size 1498)

Request 49 timed out (size 1499)

Request 50 timed out (size 1500)

Reply to request 51 (220 ms) (size 1450)

Reply to request 52 (220 ms) (size 1451)

Reply to request 53 (228 ms) (size 1452)

Reply to request 54 (224 ms) (size 1453)

Reply to request 55 (224 ms) (size 1454)

Reply to request 56 (224 ms) (size 1455)

Reply to request 57 (228 ms) (size 1456)

Request 58 timed out (size 1457)

Request 59 timed out (size 1458)

Request 60 timed out (size 1459)

Request 61 timed out (size 1460)

Request 62 timed out (size 1461)

Request 63 timed out (size 1462)

Request 64 timed out (size 1463)

Request 65 timed out (size 1464)

Request 66 timed out (size 1465)

Request 67 timed out (size 1466)

Request 68 timed out (size 1467)

Request 69 timed out (size 1468)

Request 70 timed out (size 1469)

Request 71 timed out (size 1470)

Request 72 timed out (size 1471)

Request 73 timed out (size 1472)

Request 74 timed out (size 1473)

Request 75 timed out (size 1474)

Request 76 timed out (size 1475)

Request 77 timed out (size 1476)

Request 78 timed out (size 1477)

Request 79 timed out (size 1478)

Request 80 timed out (size 1479)

Request 81 timed out (size 1480)

Request 82 timed out (size 1481)

Request 83 timed out (size 1482)

Request 84 timed out (size 1483)

Request 85 timed out (size 1484)

Request 86 timed out (size 1485)

Request 87 timed out (size 1486)

Request 88 timed out (size 1487)

Request 89 timed out (size 1488)

Request 90 timed out (size 1489)

Request 91 timed out (size 1490)

Request 92 timed out (size 1491)

Request 93 timed out (size 1492)

Request 94 timed out (size 1493)

Request 95 timed out (size 1494)

Request 96 timed out (size 1495)

Request 97 timed out (size 1496)

Request 98 timed out (size 1497)

Request 99 timed out (size 1498)

Request 100 timed out (size 1499)

Request 101 timed out (size 1500)

Reply to request 102 (224 ms) (size 1450)

Reply to request 103 (228 ms) (size 1451)

Reply to request 104 (336 ms) (size 1452)

Reply to request 105 (224 ms) (size 1453)

Reply to request 106 (232 ms) (size 1454)

Reply to request 107 (232 ms) (size 1455)

Reply to request 108 (232 ms) (size 1456)

Request 109 timed out (size 1457)

Request 110 timed out (size 1458)

Request 111 timed out (size 1459)

Request 112 timed out (size 1460)

Request 113 timed out (size 1461)

Request 114 timed out (size 1462)

Request 115 timed out (size 1463)

[Peter Paluch]

Hello Ammar,

The maximum MTU for you will be, according to the output, 1456. Hence, these are the commands relevant for you:

ip mtu 1456

ip tcp adjust-mss 1416

To allow for some margin, though, you can configure the MTU for 1450 and MSS adjustment for 1410.

Best regards,

Peter

[ammar19814]

Thanks let me tell you the scenari

My Ho Routers is 130.1.1.4 amd Bo routers is 192.168.188.1 and I am having GRE tunnel as per your advice I did this

nterface Tunnel1

description VPN To H.O

ip address 172.16.10.118 255.255.255

ip mtu 1450

ip tcp adjust-mss 1410

tunnel source 192.168.70.150

tunnel destination 172.20.40.6

When I go to command promt from 130.1.0.0 network and ping

C:\>ping 192.168.188.1 -l 1450 -f

Pinging 192.168.188.1 with 1450 bytes of data:

Reply from 130.1.1.4: 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 192.168.188.1:

    Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),

Approximate round trip times in milli-seconds:

    Minimum = 0ms, Maximum = 0ms, Average = 0ms

[Karsten Iwen]

You are testing it wrong. Based on Peters suggestion you configured the right MTU. But when you send your pings from your Windows-machine, you specify a data-length of 1450 bytes. That will result in a packet-length of 1478 Bytes as 20 byte IP- and 8 Byte ICMP-header gets added (on the router the size is the packet-length and not the data-length).

Try with that ping:

C:\>ping 192.168.188.1 -l 1422 -f

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[ammar19814]

Thanks for the clarification.

[Peter Koltl]

"The tunnel path-mtu-discovery command helps       the GRE interface set its IP MTU dynamically, rather than statically with the ip mtu command. It is actually recommended that both       commands are used. "

A great explanation:

Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC

You should also make sure that ICMP "fragmentation needed and DF set" (type 3, code 4) packets are not blocked on firewalls.

[ammar19814]

on both the side I will have to enable that ?

[adnane dakna]

just to note that "ip tcp adjust-mss  " will work for tcp traffic only

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Ammar Bahri wrote:
on both the side I will have to enable that ? 

Normally/ideally, yes.  (This assumes you have bi-directional traffic that will exceed actual available MTU.)

Also, in addition to what Adname posted about adjust-mss only working for TCP, it only needs to be inserted once in the path, but normally I set it on both sides' tunnel egress interfaces.