Wireshark Reviews

I really get excited when I am able to reproduce problems in the lab.

With this specific case, the customer was experiencing errors within their web browsers that looked like either a network or server issue. The specific symptom was that certain images would not display. If you waited a while, and ‘refreshed’ the page, more of it loaded or the entire page loaded properly.

I’m sure you can imagine the chaos this type of intermittent problem causes. The sequence of events unfolds in the following manner; the client reports the webpage issue to the help desk and the help desk tests the webpage with mixed results. In either event, the problem goes to the server group who tests and finds nothing wrong, and then the problem goes to the network group which, in most cases, does not see the problem. Then the political fist fights, finger pointing and witch hunt commence…..

In this case, they even managed to capture some packets during the problem and saw a HTTP “Service Unavailable” message and were having issues interpreting exactly what that would mean. I was there doing some other work when they dumped, uh, I mean asked me if I could help.

They explained that when the problem was occurring, the network management system was not reporting that the server or application was down. I asked how they knew that and they said that they pinged the server, tested for tcp port 80 and lastly retrieved the html page. Wow, I was impressed. I don’t see too many people monitoring from the IP layer up to the Application layer.

I then told them that even though this was an excellent way of monitoring, I wasn’t too surprised that no outages were recorded. If it was an application issue, the pings will still work as well the TCP port check. If all you did was retrieve a single html file, it would not use the same number of connections as actually loading a page and rendering images, etc…

That’s when the lab work came in. I went to my lab and configured IIS to only accept 1 connection, created a simple html file which had a few images on it. After the first try I saw the exact same issue the client experienced as well as the same HTTP message in the analyzer. AWESOME!!!

In the video below you will see how I did it and the results.

Enjoy
http://www.youtube.com/watch?v=-xVqKe53t5s

It always gives me sense of satisfaction when I have a challenge and can leverage some knowledge to figure out.

Today I was in the lab and was powering on two Cisco switches when I noticed that they weren’t labeled with their IP addresses. I’m not sure why I did not label them, but now I have to pay for it.

For those of you who have not been in this situation before I will explain. My switches have a DB9 serial connection and of course good luck finding a computer with a serial port. So now I have to rummage through the box of wires to find the serial to USB adapter. I have had to buy a second one in 2 years since my original does not have a Windows 7 driver, but I digress. After I find the cable, I have to find the installation disk because last week I migrated to a new laptop…. I’m sure you get the picture.

On to plan B. I know the switches have IP addresses since I hard code IP addresses on all of my switches.

Now here’s where a bit of knowledge comes in. I know that when a device powers up and either obtains an IP addresses via DHCP/BOOTP or statically has an IP assigned it will send out a specific ARP called a gratuitous ARP.

Perfect, now all I have to do is make sure the switch port is connected to my subnet, start any protocol analyzer (I chose Wireshark) and power up the switches.

In this video I show you how to find the Gratuitous ARP quickly, create a display filter and lastly, locate the 2 switches’ IP addresses.

Enjoy
http://www.youtube.com/watch?v=EUmHdVeBBNc

NAT Packet Analysis Using Wireshark

One of the most popular questions I get when people get the hang of protocol analysis is the daunting exercise of multitrace analysis. As with anything else the best advice is to start with the basics before tackling anything complicated.

Multitrace analysis is only effective if you truly understand your vendors products, networking and how it relates to the OSI model or packet analysis. I always suggest that you start at layer 1 and work yourself up. The key is to know what fields in the frame or packet changes, or remains the same. Ideally when you figure this out you can use a better capture or display filter

A multitrace capture of a hub, switched, or bridged network is most straight forward since a hub or switch is transparent at layer 1 or 2 and doesn’t change anything in the packet.

When you move up to layer 3 or routing, several things change in the packet such as MAC address, IP TTL and TOS. Of course your mileage will vary, and any device could be configured to muck with more bits in the packet, but I figure I would give you a point of reference.

At layer 4 we get into application gateways, proxy, firewalls and NAT type devices where the following packet fields gets modified; MAC address, IP address, IP TOS, TCP/UDP port numbers, TCP ACK/SEQ values, etc.

Lastly at layer 7, we are dealing with multi-tiered applications and basically everything changes in the packet.

In this video example I do a multitrace analysis of a simple netgear router/NAT/firewall device where I take a trace from the WAN and LAN side to compare. Not to sound like a broken record, but please remember that your devices might behave totally differently and these notes and techniques should only be used as a reference in your environment.

http://www.youtube.com/watch?v=J9FzaFryQIw