Dale Mirenda wrote:
<snip>
- Have you been using anything like MRTG to monitor bandwidth usage via snmp? The traffic graphs can often quickly tell you where to start looking for problems (ie: inbound traffic is pegged...go find the rouge kazza user and get them to "play nice"; outbound traffic pegged...look for an infected system; traffic looks normal...start verifying your configurations and infrastructure).My, that is timely. My #1 project for today was to check my SuSE distro for a network traffic monitor that I can run on Linux, with output that my untrained eye can comprehend. I will look for MRTG. Does it only work with snmp enabled devices? I know my HP ProCurve switches can be configured to provide snmp data, and I'm sure that my Linux fileservers can be somehow, and the HP networked printers probably. But how about the Win98 desktops? And does Dachstein-CD-1.0.2 provide snmp data by default, or do I need to implement that as well? I know I can find this out for myself with a bit of research, but I'm getting short of time and I'd like to play with this stuff on my healthy net in Seattle before I try to get it running in Boise, so please forgive the newbie whining. I'm not really a newbie, but this crisis has made me feel like one.
There are a couple of snmp packages on the Dachstein CD: snmp - cmu snmp Ver:3.6b7 netsnmpd - net-snmp (aka ucd-snmp) from Andrew Hoying (repackaged)
The cmu snmp is older, and I think both packages have known issues, but I only allow access via specific IP's, typically over a VPN, so I haven't worried about it. IIRC, you can setup both in fairly short order to serve up simple read-only statistics for gathering data on bandwidth, cpu-load, etc.
- My 'gut reaction' is to suspect either infrastructure (ie: bad cable, switch, hub, NIC, etc) or an unidentified host generating lots of traffic.I'm kind of leaning toward infrastructure myself, although I tried to address that early on. I would like to ask a question about spyware:
I have to admit that spyware is high on my list of suspects because that office has had problems with it before, slowing and crashing computers. On a previous visit I found it on every machine and cleaned it up with the Lavasoft product. Assuming for the moment that my technically-challenged crew in Boise really did turn off all of the client machines on their network, is there any way the spyware traffic could continue to tie up the router? I thought that when the computers on the network were down, the problem should go away. Is it possible that whatever is on the other end of the spyware connection is still bombarding the network with requests and continuing to overwhelm the LEAFbox?
Typically, it's only local connections that would be capable of overwhelming your firewall. Most high-speed connections (ie: DSL, cable-modem, T1, and similar) top out at a few MBits/s, which can easily be handled by an early Pentium class machine. My low-end P1-166 machines (with SDRAM) can handle about 30 MB/s before 'choking', and I have a P2-366 that passes 90+ MBits/s (hooked to a 100 MB/s at a co-lo).
When your on-site helper pulled the plug to the internal network and the firewall box was still being overloaded, either something very wierd is going on with your firewall and/or upstream link or your helper didn't really get the right cable...
Random thought: One thing to check for might be running out of masquerade ports. This can happen if you have a lot of local activity getting masqueraded (how many users are at this facility?):
net ipfilter list masq | wc -l
Of course, making sure you're not running low on RAM or other system resources (CPU cycles has already been mentioned) would be a good idea as well.
- Remember to look for rouge wireless APs!Well, those folks can't even spell WAP, but then the most clueless users are the most dangerous, aren't they?
These days, setting up a WAP is as simple as spending $50 (or less) at someplace like Best Buy. I'm not saying that's your problem, but it's one thing that I think could explain all observed behavior except the oddity of packet loss when the internal network cable was unplugged. Even that might be explained (without assuming the worst of your on-site help) if the WAP was connected upstream of the firewall (ie: perhaps your DSL modem is one of those that has a built-in 4-port switch, and your unknown network 'helper' was carefully following the 1-page installation graphic that showed the WAP plugged directly into the cable/dsl-modem?).
Keep us posted on what you find!
-- Charles Steinkuehler [EMAIL PROTECTED]
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
