James,
I feel your pain.
Given your CPU power and available memory, I would not look
into the generic kernel networking code/netfilter/iptables
for performance issues. You should have plenty of CPU cycles
to spare. "top" should report a CPU that's almost idle.
I have boxes 500 Mhz machines with 600+ iptables rules doing
HTTP proxying and not having any load problems.
The first (and pretty much the only) thing that springs to
mind, is a misconfigured cable speed or duplex setting
on the NIC. Look for info on the web on how to enable
full duplex 100 Mbps on your NICs (they may be running
half duplex and/or at 10 Mbps). If your machine is on
a switch, you may be able to get some port stats from
the switch like alignment/CRC errors, etc. that could
point to issues with the driver.
Oh, and for traffic meanurement, take a look at iptraf.
Good luck,
Filip
-----Original Message-----
From: James A. Pattie [mailto:[EMAIL PROTECTED]]
Sent: Tue 26/02/2002 20:13
To: [EMAIL PROTECTED]
Cc:
Subject: Update on Firewall Speed Question
Here's whats happened sofar:
I've run 'vmstat 1' while doing the transfers and verified that there is
no swapping taking place. This is on a dual capable PIII 600 system
(with only 1 cpu). Buffer and Cache memory went up/down by about 1 MB
during the file transfer (workstation to dmz) but only a couple thousand
bytes when doing the download (dmz to workstation).
He installed a 3Com 3c905B or C card in the DMZ server, which cuts down
the transfer time from 2 minutes to 90 seconds when doing a straight
windows to windows transfer, but the time didn't change when going
through the firewall.
I've optimized my firewall rules to make the ESTABLISHED,RELATED check be
at the top rather than about 5 rules down and removed the marking of
packets and matching on those marks, but without any performance change.
The incoming packets are diverted into chains based upon the protocol
in use. If doing chains based upon interface first would increase
performance, I'd be willing to try that. I haven't seen a definitive
document that says doing user chains in this order, etc. is more
efficient than this scenario, etc.
The only time he noticed a performance change was when I realized I was
running iptables 1.2.2a and then updated to 1.2.4. He said it shaved
about 30 seconds to 1 minute off the time. I don't see how changing
iptables would improve what the kernel is doing, but...
Is there any way to see the rate of packets coming into, through and out
of the firewall? I'm thinking now that the bottleneck is either when
packets enter the firewall (internal nic - 3c905C) or when they are
leaving the firewall into the DMZ (3c905B).
I'm not seeing any dropped packets that are related to the file transfer
connection and there are no collisions, etc. being reported. If anyone
has any further ideas, suggestions, etc. please let me know.
Thanks,
James A. Pattie wrote:
> Hi,
>
> I've got a compaq box setup with 3 3Com nics (10/100 - 3C905[ABC])
> using 3Com's network driver for the B & C cards. I'm running linux
> 2.4.17 and iptables 1.2.4. The firewall rules are based off of
> PCXFirewall 2.11 and PCXFirewall Rules 1.4 (http://pcxfirewall.sf.net).
> The box has 128 MB memory, 4 9GB SCSI drives doing softwared raid 5, and
> over 2 GB of swap space.
>
> The problem I'm having is my client is trying to do SMB file
> transfers from an internal machine to a Windows 2K box in the DMZ. When
> downloading from the DMZ server to their Windows 2K workstation, the
> transfer takes about 2 - 2.5 minutes (which is what it takes if you have
> the 2 machines in the same network without going through the firewall).
> But pushing files from his workstation to the DMZ server takes 5 - 8
> minutes. Inititally it was taking over 20 minutes, but I stopped using
> the onboard ThunderLan nic and switched to a 3Com and also re-ordered
> the SMB rules to be right after my DNS rules.
>
> Does anyone have any ideas as to how to make the upload go quicker?
> I've played with changing the txqueuelen value but that has always made
> it go slower. I'm not seeing collisions, etc. and he has switched to
> using a 3Com card in the DMZ server from the onboard ThunderLan nic.
> This actually made the upload time be longer. :(
>
> The client is threatening to move to CISCO because the outside
> programmer that the DMZ server is for, thinks that CISCO is more secure,
> etc. than Linux, and also because he doesn't like Linux. The sysadmin
> I'm working with wants to keep linux because of the cost difference and
> he hasn't seen any major issues, other than this speed problem.
>
> The only thing I can see to improve in my firewall rules is to not
> mark every incoming packet, which is the mechanism I'm using to know
> which interface a packet came in when I'm working with the POSTROUTING
> chain. I'm working on making a version that does everything by user
> chains (more so than I currently am), but it won't be ready for several
> days. The client wants a solution by Thursday.
>
> I've also tried just doing routing from the internal network to the
> dmz, no firewalling, and it is slower by several seconds, so not doing
> firewalling isn't the solution. (This firewall is behind another
> firewall which is acting as the choke point for their network.)
>
> Any suggestions, pointers, etc. would be very much appreciated.
>
> Thanks,
>
--
James A. Pattie
[EMAIL PROTECTED]
Linux -- SysAdmin / Programmer
PC & Web Xperience, Inc.
http://www.pcxperience.com/
Title: RE: Update on Firewall Speed Question
- RE: Update on Firewall Speed Question Sneppe Filip
- RE: Update on Firewall Speed Question Sneppe Filip
- RE: Update on Firewall Speed Question Sneppe Filip
