!! Difference in ping size between Juniper and Cisco routers
Juniper
Let's take a POS interface on Junipers:
nocview@RT1-BO1-RE0> show interfaces so-1/3/0.0 Logical interface so-1/3/0.0 (Index 89) (SNMP ifIndex 118) Description: RT1.BO1-RT.BO1 Flags: Point-To-Point SNMP-Traps Encapsulation: Cisco-HDLC Protocol inet, MTU: 4470 Flags: None Addresses, Flags: Is-Preferred Is-Primary Destination: 193.206.134.236/30, Local: 193.206.134.238, Broadcast: 193.206.134.239 Protocol inet6, MTU: 4470 Flags: None Addresses, Flags: Is-Preferred Is-Primary Destination: 2001:760:ffff:ffff::30/126, Local: 2001:760:ffff:ffff::32 Addresses, Flags: Is-Preferred Destination: fe80::/64, Local: fe80::280:42ff:fe14:566e
You can see the POS interface has an IP MTU of 4470 bytes.
The data link MTU (in this case Cisco-HDLC) is instead 4474 bytes, obtained adding
4470 (MTU IP) + 4 (HDLC encapsulation) = 4474 (MTU HDLC).
If we issue a ping command with packet size 4470 byte with option "don't fragment" the result is:
nocview@RT1-BO1-RE0> ping 193.206.134.237 source 193.206.134.238 size 4470 do-not-fragment PING 193.206.134.237 (193.206.134.237): 4470 data bytes ping: sendto: Message too long ping: sendto: Message too long ping: sendto: Message too long ping: sendto: Message too long ^C --- 193.206.134.237 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss
The packet doesn't pass because it can't be fragmented and exceeds the MTU.
The maximum possible value of the size field in this case is 4442 byte, obtained from:
4470 (MTU IP) - 20 (Header IP) - 8 (Header ICMP Echo request) = 4442 (data).
In fact:
nocview@RT1-BO1-RE0> ...134.237 source 193.206.134.238 size 4442 do-not-fragment PING 193.206.134.237 (193.206.134.237): 4442 data bytes 4450 bytes from 193.206.134.237: icmp_seq=0 ttl=255 time=14.492 ms 4450 bytes from 193.206.134.237: icmp_seq=1 ttl=255 time=3.322 ms 4450 bytes from 193.206.134.237: icmp_seq=2 ttl=255 time=2.300 ms 4450 bytes from 193.206.134.237: icmp_seq=3 ttl=255 time=2.297 ms 4450 bytes from 193.206.134.237: icmp_seq=4 ttl=255 time=4.791 ms ^C --- 193.206.134.237 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.297/5.440/14.492/4.617 ms
As you can see the packet is transmitted without problems, and the answer is 4450 bytes (net value of the IP header)
Cisco
Let's take a POS interface on a Cisco:
POS1/2 is up, line protocol is up Hardware is Packet over SONET Description: RT.BO1-RT1.BO1 Internet address is 193.206.134.237/30 MTU 4470 bytes, BW 2488000 Kbit, DLY 100 usec, rely 255/255, load 19/255 Encapsulation HDLC, crc 32, loopback not set Keepalive set (10 sec) Scramble enabled Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 2w4d Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 6707 drops 30 second input rate 168386000 bits/sec, 31248 packets/sec 30 second output rate 192103000 bits/sec, 34614 packets/sec 31360462409 packets input, 23510447908174 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 parity 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 34140229828 packets output, 23302168245011 bytes, 0 underruns 0 output errors, 0 applique, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions
As you can see, the show interface on Ciscos gives only the IP MTU, in this case 4470 bytes.
If we issue a ping command with packet size 4470 byte with option "don't fragment" the result is:
RT-BO1>ping Protocol [ip]: Target IP address: 193.206.134.238 Repeat count [5]: Datagram size [100]: 4470 Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 193.206.134.237 Type of service [0]: Set DF bit in IP header? [no]: y Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 4470-byte ICMP Echos to 193.206.134.238, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
The packet transits regularly since the Cisco router generates a packet with a gross size of 4470 bytes that doesn't exceed the MTU.
In fact, if we generate a packet with a size of 4471 bytes, the result is:
RT-BO1>ping Protocol [ip]: Target IP address: 193.206.134.238 Repeat count [5]: Datagram size [100]: 4471 Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 193.206.134.237 Type of service [0]: Set DF bit in IP header? [no]: y Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 4471-byte ICMP Echos to 193.206.134.238, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) RT-BO1>
Conclusion
There is an evident difference of behavior between the two platforms.
In the Juniper case, perhaps due to its inner nature of a BSD host, it is necessary to perform a clever computation of the packet size, taking into account the encapsulation type, and the 20 bytes of the IP header.
References
Header size for "regular" ICMP : 4 byte
http://www.networksorcery.com/enp/protocol/icmp.htm
Header size for ICMP Echo request: 8 byte
http://www.networksorcery.com/enp/protocol/icmp/msg8.htm
Header size for "regular" IP : 20 byte
http://www.networksorcery.com/enp/protocol/ip.htm
Reference to media MTU and encapsulation overhead for Junipers:
Packet capture of a Juniper Ping
cattura-ping_.bmp: 2.305KB
– Main.MarcoMarletta - 15 Nov 2006