IP Fragmentation

asked 2021-01-11 14:01:14 +0000

whodey1994
1 ●1 ●1

I'm testing to understand fragmentation and not sure of the Wireshark interpretation. I hard coded the workstation to 1100 MTU and pinged 1100 to another host. The first captured packet is showing Fragmented IP protocol (Reassembled in #2), the second packet Ping Request (Reply in 3) and third packet Echo Ping Reply (Request in 2)e Ping echo request. With the IPv4 preferences Reassemble to fragmented IPv4 datagrams unchecked, the first packet is Ping request and the second packet is the IP fragmented. Can anyone explain? What is the correct setting and interpreting the fragmentation? Also, if this was UDP traffic such as audio/video, would it have an effect on the LAN versus the WAN with higher latency?

edit retag flag offensive close merge delete

Comments

I have three captures and not sure of the Wireshark interpretation. Capture #2 and #3 are from SPAN sending to a capture appliance.

Capture #1 is tcpdump from the workstation. Capture #2 is from Data center 1 Capture #3 is from Data Center 2

1 workstation capture

IPV4 1114 Fragmentation (Reassembled in #2)
UDP 62

2 DC 1 Capture

IPV4 62 Fragmented IP Protocol
UDP 1114

3 DC 2 Capture

IPV4 62 Fragmented IP Protocol
UDP 1114

Why is the workstation frame 1 shows 1114 bytes and Reassembled in #2 but frame #1 from DC1 and DC2 shows 62 bytes length as the first frame? I checked the IPV4 Reassembly and unchecked but still same result. I would expect all three captures frames would be the same.

whodey1994 ( 2021-02-26 22:41:08 +0000 )edit

add a comment

answered 2021-01-11 16:10:06 +0000

Jaap

13730 ●684 ●115

In the first instance (with Reassemble fragmented IPv4 datagrams checked) Wireshark sees that the first packet is only part of the IPv4 datagram and holds off dissection until it has everything of that IPv4 datagram. It now can only show an IPv4 fragment. So it happens that the second packet is that missing part of the complete IPv4 datagram. Therefore once the second packet is received the dissection is started on the reassembled IPv4 datagram and the ICMP echo request is dissected.

In the second instance (with Reassemble fragmented IPv4 datagrams unchecked) Wireshark sees that the first packet is only part of the IPv4 datagram, but starts dissection anyway since we didn't ask for reassembly. Then the second packet comes in view. Wireshark can see that it's a later (not the first) part of some IPv4 datagram, so knows it can't dissect it further that an IPv4 fragment.

The difference is in the resulting dissection. In the first instance the dissection of the reassembled IPv4 datagram is the complete ICMP request, while in the second instance it's only the first bit.

Comments

Thanks for the detail explanation. So it's ideal to leave the Reassemble fragmented IPv4 datagrams checked then.

whodey1994 ( 2021-01-12 00:45:52 +0000 )edit

Ideal depends on your situation, but it's usually desirable so that's why it's the default setting.

Jaap ( 2021-01-12 19:50:30 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

IP Fragmentation

Comments

1 workstation capture

2 DC 1 Capture

3 DC 2 Capture

1 Answer

Comments

Your Answer

Question Tools

Stats

IP Fragmentation edit

Comments

1 workstation capture

2 DC 1 Capture

3 DC 2 Capture

1 Answer

Comments

Your Answer

Question Tools

Stats

IP Fragmentation