CCIE or Null!

My journey to CCIE!

Archive for the ‘Wireshark’ Category

Wireshark Tid-bit: What does the IP Identification field tell us?

with one comment

There are many different fields in the various headers we get to examine during packet analysis, one of the most overlooked field is theĀ IP Identification field. This simple 16-bit field is displayed in Hex and has a few different uses, most importantly:

  1. Identifies fragmented packets.
  2. Identifies the individual packets that the sender transmits.

How does this help us?

  • Well, by reviewing the IP Identification numbers you can easily identify which packet was dropped in the conversation, by comparing the packet captures from two different capture points.
  • This field can also give us a glimpse at how busy the end-devices are. The IP Identification field will increase by ‘1’ for every packet from the sender. Remember the IP ID Value is specific to each individual and not to a specific conversation. If you are following a specific conversation we may see consecutive IP ID #’s or we could see large jumps in the IP ID # intervals. Depending on the numbers this could tell us if the end-devices could be overloaded, or under-utilized and depending on the situation that could point us to a smoking gun.
  • If the packets get fragmented they will have the same IP ID number, the Fragment Offset field will also be set as well. This is helpful in following a conversation over particular link changes.
  • Seeing the same IP ID #’s in the same packet capture could also identify switching or routing loops within our network. The IP ID #’s will always increase, seeing the duplicate numbers means were are seeing the same packet more than once. The first thing you want to do is verify your capture point is functioning properly and make sure your capture point is in the right spot. Once you verified that it’s time to go hunting for the loop.

Quick Example:

IP Ident-2

By reviewing the IP ID numbers of the packets what can we tell about this conversation with Wireshark.org?

  • All the IP ID #’s are unique, no routing/switching loops
  • The IP ID #’s are pretty consecutive on both sides of the conversation. Showing both endpoints are not being highly utilized at this point in time. In fact there are one or two gaps on the 192.168.1.4 side of the conversation showing that endpoint is a little busier than 162.159.241.165

Written by Stephen J. Occhiogrosso

December 2, 2014 at 9:00 AM

Wireshark tid-bit: Packets larger than the MTU size.. why, how?

with one comment

Ever so often when I was doing some packet analysis I would come across systems that were sending packets larger the Ethernet MTU of the segment. Or so I thought those packets were getting transmitted, eventually I finally figured out why I was seeing packets with an increased packet size.

The answer was large segment/send offload (LSO) – When this feature is enabled it is the responsibility of NIC Hardware to chop up the data ensuring why it conforms to the MTU of media/network segment.

LSO

 

Now that we know why we are seeing these large packets, the next part of the question is how are we seeing these large packets in Wireshark. Well, Wireshark relies on WinPCAP or LibPCAP depending on your platform, these two tools capture the packets just before the packets hit the NIC Card and get transferred to the actual network.

WinPcap

 

The above image is from Winpcap.org, showing the kernel level NPF just above NIC Drive, thus explaining how Wireshark is able to see the larger traffic. Before it hits the NIC Driver and gets segmented due to its LSO capabilities.

Winpcap/Libpcap Architecture

Winpcap.org – Winpcap Internals

 

 

Written by Stephen J. Occhiogrosso

November 25, 2014 at 9:00 AM

%d bloggers like this: