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:

http://www.juniper.net/techpubs/software/junos/junos76/swconfig76-network-interfaces/html/interfaces-physical-config5.html

Packet capture of a Juniper Ping

cattura-ping_.bmp: 2.305KB

-- MarcoMarletta - 15 Nov 2006

Topic revision: r1 - 2006-11-15 - MarcoMarletta
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2004-2009 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.