MTU Question.

rajput001 · ‎11-22-2011

Can some one please explain the two different behaviour of MTU as per below output :

In the first output why we dont see the packet loss although the packet size is bigger than the MTU size.

where as in the output 2 we notice the packet loss where as the packet size is 1481 and MTU size is 1480.

=== OutPut 1 ===

ROU#sh int t3

Tunnel3 is up, line protocol is up

Hardware is Tunnel

Description: ***Connect to Ro_03 Tunnel1 Fe0/0/0***

Internet address is 21.233.41.21/30

MTU 17920 bytes, BW 4096 Kbit/sec, DLY 50000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive set (10 sec), retries 3

Tunnel source 21.233.7.22 (GigabitEthernet0/0/4), destination

21.233.41.246

Tunnel Subblocks:

src-track:

Tunnel3 source tracking subblock associated with

GigabitEthernet0/0/4

Set of tunnels with source GigabitEthernet0/0/4, 10 members (includes iterators), on interface <OK>

Tunnel protocol/transport IP/IP

Tunnel TTL 255, Fast tunneling enabled

Tunnel transport MTU 1480 bytes

Tunnel transmit bandwidth 8000 (kbps)

Tunnel receive bandwidth 8000 (kbps)

Last input never, output never, output hang never

Last clearing of "show interface" counters never

Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/0 (size/max)

5 minute input rate 12000 bits/sec, 1 packets/sec

5 minute output rate 13000 bits/sec, 1 packets/sec

16274329 packets input, 3173533969 bytes, 0 no buffer

Received 0 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

18686934 packets output, 8984626725 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out

ITC#ping

Protocol [ip]:

Target IP address: 21.233.41.22

Repeat count [5]: 1000

Datagram size [100]: 2048

Timeout in seconds [2]:

Extended commands [n]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 1000, 2048-byte ICMP Echos to 21.233.41.22, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (1000/1000), round-trip min/avg/max = 33/33/76 ms

=== OutPut 2==

ROU#ping

Protocol [ip]:

Target IP address: 21.233.179.241

Repeat count [5]: 1000

Datagram size [100]: 1481

Timeout in seconds [2]:

Extended commands [n]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 1000, 1481-byte ICMP Echos to 21.233.179.241, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!..!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!..!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!.!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!

Success rate is 98 percent (984/1000), round-trip min/avg/max = 69/70/175 ms

===

Best Regards,

cadet alain · ‎11-22-2011

Hi,

if this was MTU problem you would have 0 % success rate but only if the icmp echo packets had the DF bit set because otherwise ( which is your case) the router will fragment packets that have a larger MTU than the link on which they're going to forward. Can you raise your timeout value and do the test again.

Regards.

Alain.

Don't forget to rate helpful posts.

rajput001 · ‎11-22-2011

Hi Cadet-alain,

Thanks for your reply ,can you please tell me why on first output ( i assume no fragmentation occur ) as the packet size is bigger than the MTU size and it run sucessfully , where as on the 2nd output packetsize is slightly bigger then the MTU size and having packet loss . I am curious to know the reason why on 1st out put no packet loss occur.

regards,

Muhammad

cadet alain · ‎11-22-2011

Hi,

yes indeed they both should be dropped in this case and all packets.If you want to know the MTU use a ping sweep with the DF bit set.

Are the 2 pings taking the same path? what does a traceroute to both IPs is reporting?

Regards.

Alain.

Don't forget to rate helpful posts.