Network Sniffer/Packet Analyzer

[mbackof]

I recently started a position where I'm providing IT support for a number of medical centers with a central data center. Periodically throughout the day I'm having a lot of speed issues with my network, and this company does not have a sniffer tool available. Are there any that you have used and can recommend to me. I need to figure out what I'm going to use so I can try to get it into the 2005 budget. I'm not going to be able to spend several thousand dollars but I am thinking that I might be able to budget $500-$1000 on it.

Thanks,

Mike

 

[polm]

http://ethereal.com

 

[whalen]

If you are looking to spend money on a tool, take a look at EtherPeek by Wildpackets. There is a demo that you can check out to see if you like it.

 

[monzi]

Ettercap, or download a linux live cd filled with "hacking tools"

and have fun.

google: "linux live cd +security tools"

 

[spidey07]

Originally posted by: whalen
If you are looking to spend money on a tool, take a look at EtherPeek by Wildpackets. There is a demo that you can check out to see if you like it.

yeah, etherpeek is very nice...a step above the free ethereal.

My bet is this is WAN related and has to do with whatever is connecting the buildings. With today's switched networks you just don't see performance problems on a LAN.

 

[mbackof]

AT&T/Verizon DS3 circuits are connecting the majority of the buildings. If this is a bandwidth issue over the DS3 connections I need to "prove it" so that is why I want the tool. The other issue I have are vendor serviced Windows machines on the network without virus scanners and adequate patches. If they are infected by trojans, this should help me find them. Thanks for the feedback on the sniffers guys, keep it coming.

Mike

 

[jtusa]

Iris

Very easy to use yet very intuitive and useful. Very easy to setup filters based on almost anything, built in decoder, etc. Not sure of the price tag, but it isn't cheap.

 

[Garion]

A few thoughts, since I used to do this kind of stuff fairly often..

A sniffer is only so good. A lot of NIC's hide most of the L1/L2 errors from the upper layers, so you don't see them. i.e., you're not going to see a CRC error on an Ethernet frame with a sniffer. What you'll see on a sniffer are SYMPTOMS of network problems, not the problems themselves. The one sniffer product that does better than others is Network General Sniffer. It's an excellent product, but VERY pricey and probably out of your budget.

If you're looking for problems, the best place to start is your infrastructure. Look at your switches and routers and see what they are up to. Look for things like CRC errors, collisions, runts, giants, etc. on your switch ports and various errors on the WAN links.

If you're comfortable with Linux, go out and find a spare box and install MRTG or something of the like. Get it setup to poll your switches and routers to see what's going on. I'd make sure to run it at least every minute, so that you have granular data.

Other tips..

Is there anything common about these slow times? Is it everyone or is it just a few people? It could be just one or two things happening that have a ripple-down affect. i.e., a server-to-server data copy job starts which consumes 90% of the resources on the mail file server with home directories. Access to this server becomes very slow, causing machines to slow down in general as people work on documents, e-mail pst's on their home drive, etc.

A few other tricks:

- Setup something as simple as a ping test from a non-domain machine that has nothing major running on it.
- Go get Ping Plotter and setup a constant ping across your network to see where the latency starts.
- Use something like MRTG to look at all of the stats in a slow network time and see if there seems to be anything that looks odd.
- Check your server jobs - Backups, data syncs, database dumps for backups, etc. They can have a profound ripple-down affect on your users.


- G

 

[jtusa]

Originally posted by: Garion
A few thoughts, since I used to do this kind of stuff fairly often..

A sniffer is only so good. A lot of NIC's hide most of the L1/L2 errors from the upper layers, so you don't see them. i.e., you're not going to see a CRC error on an Ethernet frame with a sniffer. What you'll see on a sniffer are SYMPTOMS of network problems, not the problems themselves. The one sniffer product that does better than others is Network General Sniffer. It's an excellent product, but VERY pricey and probably out of your budget.

If you're looking for problems, the best place to start is your infrastructure. Look at your switches and routers and see what they are up to. Look for things like CRC errors, collisions, runts, giants, etc. on your switch ports and various errors on the WAN links.

If you're comfortable with Linux, go out and find a spare box and install MRTG or something of the like. Get it setup to poll your switches and routers to see what's going on. I'd make sure to run it at least every minute, so that you have granular data.

Other tips..

Is there anything common about these slow times? Is it everyone or is it just a few people? It could be just one or two things happening that have a ripple-down affect. i.e., a server-to-server data copy job starts which consumes 90% of the resources on the mail file server with home directories. Access to this server becomes very slow, causing machines to slow down in general as people work on documents, e-mail pst's on their home drive, etc.

A few other tricks:

- Setup something as simple as a ping test from a non-domain machine that has nothing major running on it.
- Go get Ping Plotter and setup a constant ping across your network to see where the latency starts.
- Use something like MRTG to look at all of the stats in a slow network time and see if there seems to be anything that looks odd.
- Check your server jobs - Backups, data syncs, database dumps for backups, etc. They can have a profound ripple-down affect on your users.


- G

Good info.

 

[skyking]

Good stuff indeed!

- Check your server jobs - Backups, data syncs, database dumps for backups, etc. They can have a profound ripple-down affect on your users.

This one is worth a look. Sometimes, a previous administrator will set a cron job to run while he is in the office to verify it is working. It does not get set back, and is running at peak network times, instead of 3 in the morning.

 

[Tazanator]

well I run linux based routers and the tcpdump -aqi (port) has been wonderfull I see who and what kind of traffic to where. cost free

 

[BurnItDwn]

you may want to check out SNORT to see if it meets your needs. it's open source and not too hard to use. I used to tinker with it on Linux, however it may have been ported over to other platforms by now.

 

[ScottMac]

If you believe the problem is on the DS3, Ethereal or EtherPeek isn't going to help much. Best case is that you can "rule out" what it isn't (the LAN infrastructure, active or otherwise).

I would suggest calling the provider and asking for bandwidth reports for a month, reported one week at a time. Their monitoring system should be able to generate and deliver these reports. If they won't do it for free or cheap, tell 'em to kiss off ... this is pretty standard stuff.

Next, you need to budget for a WAN analyzer (not cheap). HP, Tektronix, or Fluke (as well as Network Associates -"Sniffer"-) would be candidates to check with. In addition to the WAN analysis, you'll also have a Pro-quality analyzer for you LAN .... freebies and build-your-own / cheap software are OK for common stuff, but when the nasty stuff hits the fan, you need pro-grade stuff. At the very least, you have the benefot of an expert system (software with logic to suggest anomolies) to filter out and identifiy most porblems.

Finally, if you're not a "bits & bytes" packet-slinger kinda person, and maybe don't have one on staff, I'd also suggest finding a good consulting group that has the staff, the tools, and the expertise to resolve network issues by way of packet probes and traffic snapshots and traces. Looking at at a capture is one thing, understanding the protocols well enough to do something about it is a different animal.

There are a boatload of problems that require a coordinated / synchronized capture at more than one location (read: multiple probes / analyzers and the staff to use them).

As far as justification: you're working for a hospital, the most-often sued type of organiation in the country. One good network outage and it'll cost 'em millions to tens-of-millions of dollars. The cost of the analyzers or consultants is spit by comparison. The bean counters know this better than anyone. It should be easy enough to make the case to spend the money (maybe you'll get some cool training out of the deal as well).

That's my .02, FWIW

Scott