It turned out that eth2 was a startek NIC. The rest of my NICs
are Linksys LNE100-TX. I bought another LNE100-TX nad that fixed the
problem. I am still getting some errors when I check eth2 but I think
that is because the NIC in my Linux server in the dmz is not a Linksys
LNE100-TX. Hopefully when I replace that NIC the errors will go away
entirely. Here is the reading I get on eth2. (See below) I am not
entirely sure what to make of it but I am hoping that the errors are
caused by the NIC in my Linux server. Thanks for all the help guys!
Troy
eth2: mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:04:5a:83:69:6a brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
150248933 1331746 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 1957210 0 1957210 0
-----Original Message-----
From: Matthew Schalit [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 10, 2002 6:29 PM
To: Ray Olszewski
Cc: troy; [EMAIL PROTECTED]
Subject: Re: [leaf-user] RE:DMZ configuration problems
Ray Olszewski wrote:
>
> I waited to reply in the hope that someone would offer better advice
> than I can.
Well that's not gonna happen anytime soon :)
You pretty well helped him through any leaf config probs
he had. It works now. just slowly :/
Troy,
Slow ftp means driver/nic/cableing/cable-routing issues.
FTP's one of the best ways to bring a problem to light.
There are thousands of posts over the years to usenet
about ftp slow in one direction or from between some
machines but not all, even a few to this list.
Suggest you use matched nics all around.
All 3com, or all Intel, or all SMC. Buy
new Belkin CAT5e or CAT6 cables and get
serious if you have a few $$. Suggest PCI
10/100 nics and leave them to autosense
duplex and linespeed. Use a switch, but
if you can't, then you'd best have a decent
hub, like a netgear or whatnot.
> 1. Are you dropping a lot of packets at the interfaces? After one of
> these slow transfers, look at the output of "ip -s link show" and see
if
> the packet counts suggest any problems.
Lord only knows if he'll be able to actually see the framing
errors or something, but it's an excellent thought.
> 2. Is the firewall processing the packets the way it should be?
We can figure it is Ray, unless there's some strage traffic shaping
going on with TC. Otherwise, it's ACCEPT, DENY, or REJECT. There'll
be no slowness with those three.
> Do you make shell
> connections (with telnet or ssh) from the LAN to the DMZ host?
Excellent suggestion. An scp would be a very good test.
ls -l may be terminal dependant.
> 5. Are there any problems at the hardware level?
If he had an IRQ conflict, I'd think that the OS
would freeze up. That's the usual result, but
linux 2.4 may be different somehow from the way
other OS have historically behaved.
driver problem ==> a device acts strangely, proceeses may hang, maybe
OS hangs.
Can lead to a bsod or panic.
port addy problem ==> memory gets corrupted. procceses eventually
fail, which
gets noticed before the whole OS goes down. On
NT you
may see a Blue Screen of Death, or the OS may
freeze if
some sensative system process gets affected.
On linux
you get a kernel panic.
irq problem ==> two devices try to respond and speak w/the cpu at
the same time and totally hose the flow of traffic
on the ISA bus or PCI bus, causing the whole shebang
to lose all sembalence of logic, and thus the OS
freezes.
No response from keyboard. No BSOD. No Panic.
If the IRQ problem is w/a mouse or keyboard, then the
mainboard can spontaneousely reboot.
I'm a little rusty at diags, so the above may be wrong.
I haven't written it out in a while.
take care you guys,
matt
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
------------------------------------------------------------------------
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
