Archive for the ‘Packet Analysis’ Category
I don’t know about you but when I find myself performing packet captures and analyzing PCAPs I usually only know the symptoms of the issue I am attempting to troubleshoot. IE: Connection timeouts, slow response, long transfer times, etc. I usually don’t know much more than that, only in rare occasions do I get a heads up and insight into the behaviors of the application I am trying to troubleshoot. For all the other situations I need to rely on the PCAPs and interpret what and how the applications are communicating. Whether or not the application is behaving properly and performance is as it should be or if there is indeed something amiss somewhere.
Now for me the easiest way to do this is by using the reviewing the ‘Summary’ page under the ‘Statistics’ menu. A sample summary page is below:
A few great call-outs from this screen:
- Packet Size Limit -Knowing whether or not the packets within the capture were sliced after the first so many bytes is important to know, as sometimes you might not see the entire TCP header or wireshark will start classifying the packets as malformed. Although you will also see a ‘Truncated’ message within the packet indicating the packet was sliced.
- First Packet, Last Packet, & Elapsed time -Matching up the time of a packet capture with when the particular issue occurred is crucial, after all you don’t want to find yourself analyzing the wrong capture. The Elapsed time is important to make note of as this give you the ability to establish a baseline, knowing how long a process takes can you help you identify an issue or identify expected behavior in the future.
- Avg. Packet Size – Depending on what you are trying to troubleshoot the average packet size can be a quick indicator in regards to whether or not your fully using the MTU an your network. If you are troubleshooting data transfers normally you would expect the Avg. Packet to be quite large. If you see exceptionally small packet sizes data transfers may take a lengthy amount of time due to the increase TCP overload and normal L3 forwarding. Same goes for the Avg Mbit/sec, if you have large packets flowing you can expect to see a higher throughput rate, and the opposite for lower packet size rate.
The next spot that is worth checking out is the ‘Conversations’ which is also found under ‘Statistics’ this quaint little window gives you a brief overview of any Source/Destination devices identified within the capture. From an L2 Ethernet perspective up to a L4 TCP/UDP Perspective allowing you see what end points are really involved with this communication along with how much data was sent, the length of time the connection, etc. It’s not completely unheard of for applications to communicate with other devices (Web Servers, DB Servers, File Servers, Other App Servers) to perform whatever tasks it is trying to perform and it could be very possible this third server may or may not be slowing down the process.
So by using these two windows in Wireshark you’ve identified the following:
- The length of time the process take. – Found in the elapsed time of the capture, as long as the entire process was captured that is.
- The endpoints involved with this communication. – Remember it is important to cut down as much background noise as possible.
- How much data is transferred and at what size & rate. – This can very helpful when working data transfers.
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:
- Identifies fragmented packets.
- 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.
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 126.96.36.199
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.
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.
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.
I touched on the IPv6 addressing scheme a few weeks ago before and I wanted to continue the trend into a few more IPv6 related posts but that last IPS post spiked my interest, so I had to publish that one. Now we know the addressing scheme is different in IPv6 but what about the packet format? Obviously the packet headers will be larger because the source and destination addresses within that header are now 128 bits but let’s see what else we have in the IPv6 header:
Now that doesn’t look too intimidating right? I think that looks a little simpler compared to the IPv4 packet header. Now let’s see what we got going on here:
- Version: This field is in an IPv4 packet and simply tells us what version of IP we are running. Since this is an IPv6 packet it’s going to have a value of 6
- Traffic Class: This is the equivalent of the DiffServ/DSCP portion of the IPv4 packet which carries the QoS markings of the packet. Just like in IPv4 the first 6 bits are designated for the DSCP value, and the next 2 bits are for ECN (Explicit Congestion Notifications) capable devices.
- Flow Label: This field is 20 bits long and is defined in RFC 6437, I’ll admit finding information about the flow label is tough, but the RFC state this field could be used as a ‘hash’ for the routing devices look at and make forwarding decisions based on the field’s value. Its intention is for stateless ECMP (Equal Cost Multi-Path) or LAG mechanisms, but we will have to see how different vendors implement this feature. I’d take guess that IPv6 CEF will use the flow label, but I’ll have to wait and see.
- Payload Length: Specifies the size of the data payload following the IPv6 header.
- Next Header: This field is 8-bits and specifies the layer 4 transport protocol which follows the IP header. These values are hex format as well, you’ll notice ICMPv6 has a value of 0x3a, IPv6 protocol numbers use the same numbers that were used in IPv4. IANA’s list of protocol numbers can be found here.
- Hop Limit: This is also an 8-bit field and replaces the TTL field that was in the IPv4 header. Each hop decrements the hop limit value by 1 and when the hop limit reaches Zero the packet is discarded.
- Source/Destination: This should go without saying but it tells you the source IPv6 address of the packet and the destination IPv6 address this packet is destined to. As you would expect both of these field are 128-bits each.
So there is a snappy run down of the IPv6 IP Packet header, I think it is actually simpler than the IPv4 IP packet headers but don’t tell that to a Cisco router. Remember these packet headers are considerably larger than their IPv4 counterparts so it takes more processor power to process IPv6 packets which is not a problem for the ISR G2’s we have todays but it is something you might want to keep in mind when run IPv6 on older hardware.
Now back to CCIE: R/S Labbing I go!
Generic Routing Encapsulation, not much to say about it, its generic right? Well, it’s pretty tough to find a network that does not utilize GRE tunnels in one way, shape, or form. Whether they are Encrypted GRE tunnels or GRE tunnels riding over IPSec tunnels for branch connectivity chances are GRE is being used somewhere in your network. After all GRE provides us with various features that traditional IPSec tunnels do not offer us. Such as allowing multicast traffic to traverse the tunnel providing us scalability with the use of a routing protocol. It provides us these features because of how it interacts with the IP packet, some people refer to GRE as a layer 3.5 protocol because of how it encapsulates the existing layer 3 IP packet.
Below we can see how GRE interacts with the IP packet:
Notice you can see two sets of IP address in that packet, the first set of IP addresses (10.0.0.1 & 10.0.0.2) are the tunnel addresses, the second set of addresses under the GRE header is the real data that was sent through the tunnel, and it’s simple ICMP echo request from 188.8.131.52 to 184.108.40.206.
And for a closer at the fields within the GRE encapsulation.
Also notice the protocol type at the bottom, GRE can be used to encapsulate more than just IP Packets SNA, IPX, Appletalk and quite a few others can also be encapsulated with GRE.
More information can be in RFC 2784 which explains the IP Packet fields in greater detail then I covered here.
Now, as far as how the configuration goes for a normal GRE tunnel goes it is fairly minimal:
However, there are a few things that can be a little rough to get the hang of at first. The first thing unlike physical interface you can declare tunnel interfaces from configuration mode and you can start at any number. Now like any other interface you will want to assign your tunnel its own IP address since these GRE tunnels operate around layer 3 they will need IP addresses on the same subnet so both tunnel interfaces can communicate. The only other requirements for configuring a GRE tunnel is specifying the tunnel source and the tunnel destination. The tunnel source can be a physical interface or an IP address just keep in mind the tunnel source needs to be local on the router. The tunnel destination is going to the address of the remote router you are terminating the tunnel to. You will want to make sure the tunnel source and tunnel destination configured have connectivity to each other since it is between these addresses the GRE tunnel will run over.
There you go, GRE in a nutshell!
Probably the most common 802.11 management frame is the beacon frame. This frame is broadcasted from the AP listing the capabilities of the WLAN, but what exactly is listed? Let’s take a quick look.
Here we can easily make out some of the capabilities of the WLAN, for example the SSID is probably going to be the first thing you notice TestSSID in this case, this is what provides the name of the WLAN. As you know SSID broadcasting can be disabled (Also called Closed System) at which point the SSID field will be blank.
Next we will take a look at the what data rates are supported by this WLAN:
Here you can see the a few supported data rates and the extended supported data rates. This tells us the WLAN is capable of supporting both 802.11b and 802.11g WLAN clients. You’ll notice the Data rate of 5.5 has a (B) next to it, it just so happens 5.5 is set a mandatory data for this WLAN, so if a WLAN client can not support a data rate of 5.5 it will not be able to successfully authenticate and associate to the WLAN.
Next up we are going to at the RSN (Robust Security Network) information for this WLAN.
As you can see from the RSN Information element (IE), this WLAN is 802.11i compliant, showing it’s capable of AES/CCMP which means your WLAN clients will need to support 802.11i/WPA2 with AES in order to successfully communicate with this WLAN.
A few other noticeable features we can find in this beacon frame is the WLAN supports High-Throughput (HT), which is 802.11n (Draft 1 in this case). So this is an 802.11b/b/n WLAN in the 2.4 GHz RF range.
This access point did not have multiple antennas attached to it, which is why the TxBF and ASEL capabilities are currently at 0x0000 and 0x00.
You will also notice in the 6th line down that the WLAN is 802.11e compliant meaning some QoS will be performed, and the line after that states: no non-ERP STA’s, do not use protection this states no 802.11b clients are currently connected only 802.11g WLAN clients are currently connected to this WLAN so protection mechanism’s are not in use.
Now, at the end of the beacon frame you will notice all this Unknown information, as you have probably guessed (or read) this information is vendor specific, which is common for every vendor to have put their own proprietary information within the Beacon frames. The main thing is make sure this extra information does not create its own incompatible issues with older WLAN client devices.
So in conclusion there’s a basic Cisco WLAN beacon frame, it should be a mirror image of the configuration for your WLAN. Looking at the beacon is just a simple way to make sure the WLAN is doing what’s it’s configured to do.