IP Fragmentation -can already fragmented packet gets fragmented again

[raja d]

1.In the Below diagram if PC-A starts sending packet where would the fragmentation start ? How many times will the packet be fragmented , will it be only once or more than once , if so how ?

[Georg Pauwen]

Hello,

as I understand it, the packet will be fragmented at every hop that has a lower MTU setting than the one before (provided, obviously, that the DF (Don't Fragment) bit has not been set...

[Joseph W. Doherty]

"PC-A"?  Diagram shows a VPC1 and VPC2.(?)

Diagram also shows different hosts, on same media, with different MTU.(?)  That's possible, but a bad thing as L2 doesn't fragment (i.e. L2 switches don't fragment).

IP fragmentation happens at L3 "hops" (like on your routers) when next hop egress interface's MTU is smaller than size of packet to be transmitted.  As George notes, if DF not set, egress interface will fragment such a packet.

Yes, fragmented packets, going further along path, can be fragmented again.

However, keeping in mind that actual packet, to be transmitted, has to be larger than what a L3 interface supports, not all fragmented packets might be fragmented again.  (Often, a receiving device that receives a too large packet will consider it corrupted and discard it.  Some Cisco switches, I understand, if physically capable of accepting the "too large" packet, but only "configured" for smaller, will accept it but will not forward it out another L2 interface unless that interface can handle [i.e. both logically and physically] that size packet.)

For example, a 1500 byte packet to be transmitted on a interface that supports a 1400 MTU will be split such that the first fragment will be 1400 bytes and the second fragment will be (probably) 120 bytes.  (Why 120 and not 100?  The second fragment will have a new L3 header [which will be at least 20 bytes].) If those two fragments then hit an interface with a 1390 MTU, the second fragment should not be fragmented again, but the first fragment will be split into a 1390 byte packet and a 50 byte packet.  (Again, a new IP header is created.)  You now have 3 fragmented packets, sized 1390, 50 and 120.

If they hit another L3 interface, supporting a MTU of 1000, we will then have four fragmented packet size 1000, 410, 50 and 120.

Hopefully none of these fragmented packets are lost, because losing any, even one, requires retransmitting the original 1500 byte packet, even when you've only lost 10 bytes of the original packet (i.e. the 3rd fragment).  (One of the possible issues when there's fragmentation.)

[raja d]

For a packet already fragmented the question arises for me is that IP
protocol has only one ID field ,fragment offset ,
Which means each fragmented packet will have the same ID value and offset
based on the sequence .
Here if we fragment an already fragmented packet It would cause problem in
reassembly as new I'd value and offset has to be created .even if the same
ID value is maintained for new fragments offset value would start from 0
causing the sequence to fumble . Please explain . Many thanks for your
replies greatly appreciated .

[Joseph W. Doherty]

No, for a fragmented fragment, basically, its much like the original fragmentation.  I.e. the fragment being fragmented has the same ID but its length and offset are calculated once again (as are the new fragment's).

E.g. (NB: offsets and lengths, in example, not accounting for new IP headers [or 8 byte alignments, later also not mentioned in my first post])

1500 to 1400

1st: length 1400, offset 0, more yes
2nd: length 100, offset 1400, more no

1400 to 1000

1st: length 1000, offset 0, more yes
2nd: length 400, offset 1000, more yes
3rd: length 100, offset 1400, more no

When receiving hosts receives either the first set or second set of fragments, it can reconstruct the original packet.

[raja d]

Hi Joseph thankyou once again ,

So in the above scenario where you explained ,  the initial fragments are  two, one with 1400 length  another with 100 

Which didn't change the second packets offset on the refragmentation .

But consider the scenario where the  initial packet size as 2800 size getting fragmented into two packets  (ignore the 20 byte ip headers and virtual reassembly) 

1st fragment -length 1400 offset 0

2nd fragment -length 1400 offset 2800

If these two fragment reaches 1000 ip mtu 

The result would be 

1st fragment 

Length 1000 offset 0

Length 400 offset  1400

2nd fragment 

Length1000 offset 0

Length 400 offset 1400

Which looses the continuity of the sequence , the second packets offset if fragmented should obviously start from 0 rather than 1401 

In such case I feel router would drop the  already fragmented packet .

Help me to understand this so I can sleep jn peace .

[Georg Pauwen]

Hello,

is this an exam question, a theoretical question, or a real world question ? I guess in order to really get you an answer, your environment would need to be set up in a simulator, and then analyzed using a sniffer (e.g. Wireshark)...

[fwitron1981]

The real question will be do both customer and ISP will need BGP. This is real world.

[Joseph W. Doherty]

Ah, I believe I understand both your question, and confusion.

Offsets are relative to the original packet, not fragmented packets, so starting with:

packet 2800 to 1400

1st fragment -length 1400 offset 0
2nd fragment -length 1400 offset 1400 (BTW not 2800)

packets 1400 to 1000

1st fragment -length 1000 offset 0
2nd fragment -length 400 offset 1000
3rd fragment -length 1000 offset 1400
4th fragment -length 400 offset 2400

[raja d]

No it's not an exam, it's a real world scenario , most of the devices won't support ICMP and obviously ending up in situation of multiple fragmentation , fragmented packets r dropped by firewall and nat points 

[Joseph W. Doherty]

Did my prior reply (attached to Georg's posting - oops) answer your question?  Or, something still unclear?