Wireshark

Sniffing traffic on a Cisco switch

Hello again folks, so if you’ve been in networking long enough you’ve probably ran into issues where you just wish you could look right at the network traffic. As I’ve posted before, one of the best ways to do this is to use a packet sniffer such as the old Ethereal, or the new Wireshark.

Wireshark uses WinPcap to capture the packets and display them to you in realtime on your screen so you can view what’s going on in your network. But how do you get the packets on your switch to come to your laptop in the first place? You do this by implementing Port Span on a Cisco switch. Span stands for Switched Port Analyzer and what it does is mirrors all of the traffic from a source port to a destination port you specify.

This can be of great use when troubleshooting traffic flows through a switch. Just the other day I was troubleshooting some traffic flow through a trunked etherchannel interface and I needed to find out what was going on with one of the vlans. By using SPAN I was able to get to the root of the problem quite quickly.

More on how to implement it here.

-RP

Packet sniffing is your best friend…

Sometimes when you are troubleshooting network issues, you just can’t seem to put your finger on the source of the problem. Whatever it is that is causing your network issue is evading you and you’re wondering how are you going to track it down.

I find using a packet sniffer to actually look at the traffic flowing on the network is helpful at this point. You will most likely have to configure your switch to mirror all traffic to one of the ports on the switch so you can plugin a laptop with a packet sniffer onto that port to monitor the traffic.

One of my favourite packet sniffers to use is Wireshark, formerly known as Ethereal. You can also use Network Monitor which comes builtin with Microsoft’s operating systems. Once you have it up and running you can watch network traffic scroll past your screen live and hopefully find the source of your problems.

-RP

Any doesn’t always mean Any…

Hi folks, here’s another little tidbit from the wonderful world of firewalls. In the consulting world I have had to work with my fair share of firewall products. From SMB based devices all the way to the larger Enterprise products. There is one thing that I have run into time and time again and that is the dreaded “Any” rule/object. The reason I say dreaded, is because sometimes what is assumed by Any can end up causing you a ton of headaches.

A lot of firewalls have the ability to create a rule where you can specify to allow Any traffic from Any to Any. Unfortunately as people have found, Any doesn’t always mean Any. What I mean by this is that despite what Any implies, what in actuality happens is that the firewall still ends up blocking some things. When this happens, a network administrator might end up troubleshooting everything and still come up short trying to figure out why things aren’t working properly in the network. I have heard lots of network admins tell me “But I have the firewall configured with an all-open any to any rule for testing! It should work!” and of course it doesn’t. Now not all firewalls are this way but there are some where you will run into this.

So what’s the solution? Turn on detailed logging, and watch the logs for denied traffic. Also using a packet sniffer like Wireshark or Microsoft’s own Network Monitor (found on your server CD by using add/remove components) can help you to determine how the traffic is flowing and what is happening to it. At that point you will be able to determine if a firewall is blocking the traffic or not and be able to fix your problem by creating a rule to allow that type of specific traffic through.

-RP