Consider an example where host-A is sending data to host-B. While the fragments traverses many routers in between, some of the fragments are lost. So now the router identifies this and waits for that lost packet to arrive or it just routes it to the next router? If this is true, how does the lost packet be recovered?
Router Packet Loss – How Routers Handle Lost Packet Fragments
fragmentationpacket-lossrouter
Related Solutions
Sending a good ten minutes of 0-interval MTU-sized DF pings with contents 0x0000 and a second test with contents 0xffff is an excellent way to apply some stress to simple transmission technologies. Lost packets -- or overly delayed packets after the first few packets -- are a clear indication that further investigation is required. It's also a good moment to check that the reported round-trip time is within reasonableness (it's very easy for a transmission provider to provision a circuit which crosses the country and back rather than crossing the city).
Ping is great for finding faults. However, ping alone isn't a great acceptance test for being sure there are no faults. The rest of this answer explains why.
As part of the ping test you should connect with each of your network elements on the path (hosts, switches, routers) and record the transmission traffic and errors counters before the start and after the end. Rising error counters of any type require further investigation. Don't ignore small rises in error counters: even a low rate of loss will devastate TCP performance.
This still isn't to say that the link is acceptable. Let's take 1000Base-LX, ethernet over single-mode fiber. It's possible that the light levels at the receiver are under the specification for that transceiver's model. But we have an above-average sample of that transceiver so all is well. But then that transceiver has a fault and we replace it with a below-average-but-within-specification sample. The link cannot restore to service even though we have fixed the fault. So as part of the acceptance testing we need to check that light levels are within specification at both ends; and we need to check that there is a viable power budget at the extremes of both transmitting and receiving transceiver's performance (to make this easy, manufacturers will give their SFPs nominal ranges where they have done the power budget calculations, such as 10Km for 1000Base-LX/LH. But for any link longer than 10Km you should do your own power budget: five minutes arithmetic can save you hundreds of dollars in allowing you to safely purchase a lower-power SFP). SFPs often have a feature "DOM" which allows you to check the receive light level from the device's command line.
More complex transmission technologies have forward error correction. So the link appears to work under high transmission error rates, but if error rates are higher or more sustained then the FEC is overwhelmed and the transmission passes rubbish. So for these links we are very interested in the counts of error corrections. Interpreting those FEC counters requires understanding the physical transmission, as we're now low enough in the "stack" that we can no longer pretend that media isn't naturally free of errors. But even in these systems a simple ping test is enough stress to give initial results.
Finally, you should be aware that PCs are a cheap but not perfect test platform. So sometimes packet drops are because of the end-systems rather than the transmission. This can be simple IP-layer issues (such as a MTU inconsistent with the subnet, always a possibility when backbone links should be running with a MTU > 9000) or host performance issues (particularly >10Gbps). The cost of "real" ethernet test platforms is extraordinarily high, because you're paying for those issues to have been fully sorted via hardware or clever software (eg, running within the NIC).
You have them all correct.
5th fragment: remember that the routers can change their settings at any time, and the fragmentation limit can change from one packet to the next. When you fragment already fragmented packets, you normally see something like this:
- original sends (say) 4001 byte packet
- through something which fragments it into three: 2000, 2000, 1.
- through something which fragments it into 5: 1600, 400, 1600, 400, 1.
This big-small-big-small is characteristic of fragmented fragments. Normally reassembly is only done at the final host, or a host doing security or NAT. (Note that the fragements can overwrite other fragments, which has had some security implications. I believe most current IP stacks will discard such funny-fragment packets.)
The IP layer discards the bad packet, perhaps sending ICMP problem report. It never gets to the UDP-handling layer.
I do recommend reading RFC 791 on fragmentation and reassembly. https://www.rfc-editor.org/rfc/rfc791
PS. Your example table has some assumptions: 20-byte headers, and that all these packets had the same destination address.
Best Answer
There's no mechanism to request a fragment be resent. The entire packet cannot be reassembled, so the entire packet will have to be resent. This is why Fragmentation Is Bad(tm).
Routers typically do not care about fragmentation. They pass things on exactly as they receive them. (unless it's the source of the fragmentation.) As such, the router will be unaware of missing fragments.
(I'm ignoring the practice of "virtual reassembly".)