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)
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> |
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.
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