On Oct 12, 2004, at 12:37 PM, Charles Steinkuehler wrote:
<snip>
I'll read up on the packages and give it a go.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.
That was my thought, but over time the packet loss on the _outside_ LEAF connection has degraded to be unusable: rarely under 50%, even with (supposedly) no inside clients up, so I had to ask.
- 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).
The firewall is also a primary suspect, even though I replaced it.
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...
One fileserver, a switch, five desktops (only three users), two networked printers, The switch had me going for a while until I remembered that it had it's own ip address. They turned off all the computers and printers and nmap still showed a host up! My fault that time, not theirs.
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?):
I've already shipped _another_ DachBox down there so I can eliminate LEAF hardware issues.
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.
The Flowpoint 2200 DSL router does indeed have a built-in 4-port switch.
- 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?).
I definitely will, Charles. Hopefully, I'll discover something that will help someone with a similar problem in the future. That's the best outcome I can imagine for this fiasco.
Keep us posted on what you find!
BTW, please accept my heartfelt thanks not only for your advice with this incident, but for providing the Dachstein system in the first place. Since I installed these machines (all running on antiquated hardware) several years ago, they have run 24/365 with the longest uptime and lowest maintenance of any electronic device I've ever used, let alone built by hand on a zero budget with almost no prior experience. In my 30+ years maintaining and using technical systems from mining equipment to nuclear power plants to data networks, I've never seen or heard of any machine that does so much and requires so little in return. You and everyone who has helped you with LRP have much reason to be proud.
Dale Mirenda
------------------------------------------------------- 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
