ICMP | TTL | Fragmentation - PING command Parameters

[yurs]

Hi Folks, 

I hope you all doing well. I took some confusion. I was recently playing with the ping command and what I observe while using the ping command with different parameters. I have the following things to question, which I am looking for the answer. 

1. I could not define the TTL value in the ICMP packet even I have used -i with ping commands, why I could not?
2. How can we fragment our ICMP packet with a higher buffer size? I have tried but no luck. any idea, please?
3. how -a tag in Ping command works. any example, please?

Looking forward to a discussion on it. I will be very thankful to you. 

Regards!

Yurs

[TJ-20933766 · Accepted solution]

The following commands are in a Windows CMD

1. If you run a packet capture on your computer's network interface (like Wireshark), you will be able to see the TTL change when using the -i command. By default, my computer will set the TTL of a packet to 128. That can be modified with the following command:

ping -i 2 8.8.8.8

Here in the screen shot, you can see the TTL is highlighted and showing to be a value of 2 for the ICMP echo request sourced from my PC:

2. What do you mean by fragment the ICMP packet with a higher buffer size? A packet is usually fragmented because it is larger than the Maximum Transmission Unit of an interface so a single packet becomes two. The ICMP Echo Request (Type 8, Code 0) packet payload by default is 32 bytes. You can change that with the following command:

ping -l 1000 8.8.8.8

This will change the buffer size to 1000 bytes. You can also add the "do not fragment" command to see what the maximum size of a packet is allowed along a path in your network:

C:\Users\Tyson>ping -f -l 1800 8.8.8.8

Pinging 8.8.8.8 with 1800 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 8.8.8.8:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

I set the packet size to 1800 and as you can see by the responses, the packet could not be sent by my computer's network interface because it needed to be fragmented but wasn't allowed due to the "Do Not Fragment" bit in the packet header being set. The packet is then just discarded and the error is shown.

Now if your computer is able to send a packet larger than that of say your router's interface MTU, the router will send an ICMP Type 3, Code 4 which simply is the router's way of telling the computer that the packet was dropped because it was too big and couldn't fragment it.

The computer's output is slightly different in this case as well:

C:\Users\Tyson>ping -f -l 1475 8.8.8.8

Pinging 8.8.8.8 with 1475 bytes of data:
Reply from 10.0.0.1: 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 8.8.8.8:
    Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),

Notice that only 1/4 packets made it. That's because after the computer received the first packet from the router telling it the packet was dropped due to not being able to fragment it, the other 3 packets were not even sent from the computer. The packet capture confirms this by only showing the outbound initial packet followed by the packet sourced from the router who could not fragment.

3. The -a command is used to find a hostname associated with a known IP address. For example, you could use it to find the computer/server names within an organization.

[yurs]

@TJ-20933766  Thank you for such a good explanation. 

My media can maximum send datagram size of 1472. without fragmentation. As shown in the image below:

I used -f to show you that fragmentation is not needed. 

 but when I send a packet greater than 1472 it gives me "Request Time out". as shown below. 

That's why I ask how to fragment the ICMP packet as used -f for do not fragmentation.

Thank you!

[Georg Pauwen]

Hello,

I get the same results, not only from 8.8.8.8 (the public Google DNS server), but also from many, most actually, websites. I think a lot of providers simply drop ICMP packets with anthing other than the default size, simply for security reason. After all, why would anyone need to use these higher than default packet sizes (unless you are moving in the direction of being a hacker trying to scan for vulnerabilities...that is probably the reasoning behind this).

[yurs]

@Georg Pauwen I think you are right, maybe there is any DDoS attack protection kind of policy. But still, first, need to check if either our device is supported fragmentation or not. 

[Joseph W. Doherty]

Other vendors OSs, including Windows, determines ping sizes a bit differently from Cisco network devices, even when the MTU, for both, is the same.

• Ethernet Frame size (exclusive of header and CRC) = 1500 bytes (Cisco uses this)
• IP MTU size = 20 bytes
• ICMP header = 8 bytes
• ICMP payload = 1472 bytes (Windows uses this)

[TJ-20933766]

That is very strange. Have you tried turning on wireshark to see if your system is even fragmenting the ICMP echo requests and sending them out when you try anything larger than 1472 bytes?

What operating system are you using? If you're using Windows, you might try opening the cmd.exe and trying the same size packet and see if you get a different result.

[yurs]

Yes I am using windows, I tried from the CMD but the result is the same.

Another thing I just found that is I can ping my default gateway with a great value than 1472 and yes its fragments the packet with a greater datagram only for my default gateway. 

and is fragmenting the packets for 8.8.8.8 as well still no reply.. 

[TJ-20933766]

That's why I like to run Wireshark sometimes just to make sure that my computer is sending the packets I think it is sending. As you were able to see, your 15000 byte ICMP echo request (that's big! lol) was being sent as 11 fragments which were all 1480 bytes long except the last one which was 208 bytes.

I too do not get responses when trying to ping 8.8.8.8 with an ICMP echo request that large. I suspect that somewhere along the path to Google DNS, there is something that is blocking ICMP from being that large (could be locked down to prevent DoS).

If I ping my default gateway with an ICMP echo that is 15000 bytes long, I do get a response and can verify just as you did that the large packet is fragmented into many smaller ones.

[yurs]

If there is DoS Attack prevention, then the ping command should not reply to us with an error instead of "Request Time out". As far as I know "Request time out" means the packet is reaching the destination but the destination is not responding. Because of this prevention, should we not get any other error? is it a limitation of the ping command?