strange MTU issue

Unanswered Question
Mar 6th, 2009
User Badges:

On a LES circuit, CPE IP:10.250.40.194/30 Peer end IP:10.250.40.193/30

packet loss only happens when ping peer IP with packet size b/t approx 1520-3400Byte. But never got packet loss when pinging the IP address behind PE(like remote side in the VPN)


RT2#ping 10.250.40.193 size 1900 re 100


Type escape sequence to abort.

Sending 100, 1900-byte ICMP Echos to 10.250.40.193, timeout is 2 seconds:

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

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

Success rate is 96 percent (96/100), round-trip min/avg/max = 8/9/24 ms



RT2#ping 10.250.40.193 size 8000 re 100


Type escape sequence to abort.

Sending 100, 8000-byte ICMP Echos to 10.250.40.193, timeout is 2 seconds:

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

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

Success rate is 100 percent (100/100), round-trip min/avg/max = 16/19/20 ms



RT2# ping 10.250.37.43 size 1800 re 100


Type escape sequence to abort.

Sending 100, 1800-byte ICMP Echos to 10.250.37.43, timeout is 2 seconds:

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

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

Success rate is 100 percent (100/100), round-trip min/avg/max = 8/12/20 ms

WYE-Slough-RT2# ping 10.250.37.43 size 1700 re 100


10.250.37.43 is remote side IP behind the PE.


However there is no packet loss at all when ping on PE to CPE whatsoever size of MTU.


Is it CPE IOS problem??

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
adamclarkuk_2 Fri, 03/06/2009 - 02:51
User Badges:
  • Silver, 250 points or more

Hi


You are not testing the MTU here is the packets might possibly be fragmented depending on the MTU set on the interfaces.


Run the tests again with the df-bit option in your ping.

kevin.shi Fri, 03/06/2009 - 03:09
User Badges:

Sure its fragmentation issue. seems CPE doesn't cope with it very well.


MTU is 1500 on the FE port.


RT2#ping 10.250.40.193 df-bit size 1500


Type escape sequence to abort.

Sending 5, 1500-byte ICMP Echos to 10.250.40.193, timeout is 2 seconds:

Packet sent with the DF bit set

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/12 ms

RT2#ping 10.250.40.193 df-bit size 1501


Type escape sequence to abort.

Sending 5, 1501-byte ICMP Echos to 10.250.40.193, timeout is 2 seconds:

Packet sent with the DF bit set

.....

Success rate is 0 percent (0/5)

WYE-Slough-RT2#

adamclarkuk_2 Fri, 03/06/2009 - 03:19
User Badges:
  • Silver, 250 points or more

Hi


The above out is as expected, send the same amount of pings as the first test with the MTU set to 1500 ( as this was the max MTU that made it through), if you get similar results, (ie loss) then it's not an MTU issue)

kevin.shi Fri, 03/06/2009 - 03:55
User Badges:

I have stated in the first thread, packets loss only happens with ping packet size between 1520-3400.

there is no packet loos at all when size is below 1500byte.


if it's not an MTU issue, then what is the issue?

gnijs Fri, 03/06/2009 - 08:49
User Badges:
  • Bronze, 100 points or more

if you ping with sizes 1520-3400, the router will fragment the packets into several packets with maximum size typicall 1500 bytes (the MTU of the interfaces).


so when you do a ping size 3000, you are actually sending two packets of each 1500.


except when you use the df-bit option. this will tell the router to use maxumum the mtu size (so maximum 1500). Therfore, the above output is as expected (no reply for 1501).


You should do this ping for each hop on the path (ping 1500 first hop, ping 1500 second hop, ping 1500 third hop etc) to verify if the mtu of the whole path is 1500 and not smaller.



kevin.shi Tue, 03/17/2009 - 07:52
User Badges:

I have done ping test with DF bit set. 1500 is only allowed.


But how to explain packets loss things and it only happens when packets size is between 1520-3400. there is no packet loss at all when I even set size 6000 and 15000 and this happens only one direction ie. CPE to PE.

Actions

This Discussion