This article explains the meaning and instances when ICMP fails with Frag reassembly time exceeded
ICMP is a great way to check for link availability, however, it is not a good way to test latency or delay on a Juniper Networks platform. One of the best and most accurate ways to test for latency is to simulate data plane traffic using a traffic generator for the transit traffic.
Juniper Networks platform architecture separates the control plane from the data plane. There are various rate-limiting and prioritization functions within the packet forwarding engine (PFE) and the routing engine. When a ping is sent from the routing platform to the end device, it uses the control plane on the local router to generate the ICMP request packet. The control plane is used again when the ICMP reply packet is received from the end device.
Here is a snippet from a lab node outlining the ping test which is failing with Frag reassembly time exceeded error:
root@router-re0> show route table TEST_ICMP.inet.0 192.168.100.5 TEST_ICMP.inet.0: 48472 destinations, 114874 routes (48472 active, 0 holddown, 3 hidden)+ = Active Route, - = Last Active, * = Both192.168.100.4/31 *[Direct/0] 1w1d 11:00:29 > via xe-0/1/1:3.28 [BGP/170] 1w1d 02:18:52, MED 0, localpref 100 AS path: 65525 ?, validation-state: unverified > to 192.168.100.5 via xe-0/1/1:3.28root@router-re0> show interfaces terse xe-0/1/1:3 | match 10.139.145. xe-0/1/1:3.28 up up inet 192.168.100.4/31
This article focuses on ICMP failures with Frag reassembly time exceeded error only which would look as follows:
root@router-re0> ping routing-instance TEST_ICMP 192.168.100.5 count 1000 size 1500 rapidPING 192.168.100.4 (192.168.100.4): 1500 data bytes!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!36 bytes from 192.168.100.4: Frag reassembly time exceededVr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 c0 05dc fa93 0 0000 40 01 9b9a 192.168.100.5 192.168.100.4.!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!36 bytes from 192.168.100.4: Frag reassembly time exceededVr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 c0 05dc fc57 0 0000 40 01 9b9a 192.168.100.5 192.168.100.4.!!!!!!!!!!!!!!!!36 bytes from 192.168.100.4: Frag reassembly time exceededVr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 c0 05dc 04f6 0 0000 40 01 9b9a 192.168.100.5 192.168.100.4.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!36 bytes from 192.168.100.4: Frag reassembly time exceededVr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 c0 05dc 0682 0 0000 40 01 9c9a 192.168.100.5 192.168.100.4.!!!!!!!!!!!!!!!!!!36 bytes from 192.168.100.4: Frag reassembly time exceededVr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 c0 05dc 0b83 0 0000 40 01 9b9a 192.168.100.5 192.168.100.4.!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.36 bytes from 192.168.100.4: Frag reassembly time exceededVr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 c0 05dc 1225 0 0000 40 01 9c9a 192.168.100.5 192.168.100.4!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!.!!!!!!!!!!!36 bytes from 192.168.100.4: Frag reassembly time exceededVr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 c0 05dc 1a96 0 0000 40 01 9b9a 192.168.100.5 192.168.100.4!!!!!!36 bytes from 192.168.100.4: Frag reassembly time exceededVr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 c0 05dc 1e6c 0 0000 40 01 9b9a 192.168.100.5 192.168.100.4.!!!!!!!!!!!!--- 192.168.100.4 ping statistics ---1000 packets transmitted, 946 packets received, 5% packet lossround-trip min/avg/max/stddev = 2.797/11.264/110.719/7.230 ms
ICMP Time Exceeded error messages indicate that a forwarding or reassembly operation took too long to complete and that the reporting device is discarding the data. To provide more detailed reporting, the Time Exceeded message provides two different sub-messages (using the ICMP Message Code fields]
1. Time-to-Live Exceeded in Transit
This error message is used when an IP datagram’s Time-to-Live value has reached zero but the datagram has not yet been delivered to its final destination. Since the Time-to-Live field indicates the maximum number of hops a datagram can take, the router cannot forward a datagram with a Time-to-Live value of zero and must destroy it instead. Since most systems use Time-to-Live values of 30 or more, this message generally indicates that a routing loop is preventing the datagram from being delivered. However, this message is also used with the traceroute program to identify the routers in between a source and destination system.
2. Fragment Reassembly Time Exceeded
This error message is used when a datagram has been fragmented but the destination system has not received all of the fragments within the allotted time (60 seconds on most Unix systems). This message generally indicates that a fragment has been lost in transit somewhere and that the destination system is discarding the other fragments that it has received.
If a host reassembling a fragmented datagram (or packet) cannot complete the reassembly due to missing fragments within its time limit it discards the datagram and it may send an ICMP - time exceeded message. If fragment zero is not available then no ICMP - time exceeded message is needed to be sent at all. Code 0 may be received from a gateway and Code 1 from a host.
Pictorial representation of the ICMP packet and the codes used for time exceeded error:
ICMP ping failure with frag reassembly time exceeded error in itself, is not a cause for alarm as ICMP messages are considered low priority within Junos OS. The routing platform will respond to and process other higher-priority messages, such as routing updates, before processing the ICMP messages. The microkernel may introduce tens of milliseconds of processing delay to ICMP message handling. The delay is not uniform, meaning that some ICMP messages might be delayed while others may not be delayed. So, ICMP ping latency in traffic generated for the device itself is not a recommended way of testing the bandwidth or integrity of the link.You can follow the Tshoot steps from KB85326 [juniper.net] for further isolation for ping packet loss on the directly connected interface.