> Can you be a bit more specific about the setup details? Are you trying to describe a setup like this
eth0 - 10 (or 100) Mbps NIC connecting to the Internet eth1 - 10 (or 100) Mbps NIC connecting to LAN A (eth1, 192.168.1.0 network) eth2 - 10 (or 100) Mbps NIC connecting to LAN B (eth2, 192.168.3.0 network) ftp client on LAN A or B (from either net, same issue) ftp server is on the "internet" (for testing, my local office network, which is private network 192.168.2.0, ftp server is 192.168.2.3) I've removed norfc1918 from eth0 in the interfaces file for testing. Both local nets are MASQ'ed through eth0. LANs A and B have routes to each other (i.e., the router does NOT NAT this traffic, however I block traffic between them - see rules below.) ftp throughput is between 50 Kbps and 100 Kbps, depending on NICs tested? - range is actually around 40-120). ftp server actually does (not "can easily") deliver 80 Mbps to an ftp client on local lan - correct. ftp: 131170400 bytes received in 11.69Seconds 11222.66Kbytes/sec I tested SCP from the firewall to my local network (ie connecting to eth0) and it was not fast, approximately 23Kbs (that's bits and forgive me for changing terms if i do it.) The total data transferred was 2.67 megabytes. >After a slow transfer, what does "ip -s link show" report? Are there significant numbers of bad packets? Possibly, output follows from the post SCP transfer described above. Eth0 is plugged into a Netgear switch: 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 RX: bytes packets errors dropped overrun mcast 2152 16 0 0 0 0 TX: bytes packets errors dropped carrier collsns 2152 16 0 0 0 0 2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 0 0 0 0 0 0 3: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc htb qlen 1000 link/ether 00:00:c0:98:d9:8f brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 223554 2573 0 0 0 58 TX: bytes packets errors dropped carrier collsns 3142834 4217 3 0 0 56 4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:00:c0:ab:f5:9d brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 4228 46 0 0 0 2 TX: bytes packets errors dropped carrier collsns 60 1 0 0 0 0 5: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:00:c0:79:f4:9d brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 6480 0 54 0 0 0 >During a slow transfer, what does "top" report about CPU load? If this is high ... is the router running unusually complex iptables (Shorewall) rulesets? (If yes, please report the details.) - No, CPU usage is very low. I think the rulesets are very simple, however I've posted them below just in case. Please note I've trimmed all comments except one, and I've removed an ACCEPT line that allows me to SSH from an internet . # /etc/shorewall/policy loc net ACCEPT loc3 net ACCEPT loc loc3 REJECT loc3 loc REJECT net all DROP ULOG all all REJECT ULOG # /etc/shorewall/rules ACCEPT fw net tcp 53 ACCEPT fw net udp 53 ACCEPT loc fw tcp 22 ACCEPT loc fw icmp 8 ACCEPT loc3 fw icmp 8 ACCEPT net fw icmp 8 ACCEPT fw loc icmp 8 ACCEPT fw loc3 icmp 8 ACCEPT fw net icmp 8 ACCEPT loc fw udp 53 ACCEPT loc3 fw udp 53 ACCEPT loc fw tcp 80 ACCEPT loc fw tcp stat ACCEPT fw net udp ntp ACCEPT loc fw udp ntp ACCEPT loc3 fw udp ntp ACCEPT fw net:63.208.196.94 tcp www # Testing only, remove before installation! ACCEPT net fw tcp 22 >Do pings of the ftp server by the client show any unusual latency? Consistently 2ms, no dropped packets out of about 100 sent. >That diagnostic information, combined with the usual basics ("ip addr show"; "netstat -nr"; "more /proc/interrupts"; "more /proc/ioports", and enough description to let us know which eth* interface is associated with which LAN) and perhaps some details about the ftp server and client, should help folks spot the problem. ip addr show: 1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc htb qlen 1000 link/ether 00:00:c0:98:d9:8f brd ff:ff:ff:ff:ff:ff inet 192.168.2.54/24 brd 192.168.2.255 scope global eth0 4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:00:c0:ab:f5:9d brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global eth1 5: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:00:c0:79:f4:9d brd ff:ff:ff:ff:ff:ff inet 192.168.3.1/24 brd 192.168.3.255 scope global eth2 netstat -nr failed: netstat: -r (display routing table) is not compiled in. ip route show 192.168.3.0/24 dev eth2 proto kernel scope link src 192.168.3.1 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.54 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 default via 192.168.2.1 dev eth0 /proc/interrupts CPU0 0: 159264 XT-PIC timer 1: 2 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 14174 XT-PIC eth0 5: 0 XT-PIC eth2 8: 0 XT-PIC rtc 10: 5374 XT-PIC eth1 14: 796 XT-PIC ide0 NMI: 0 ERR: 0 more /proc/ioports 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 0240-025f : eth2 0280-029f : eth0 0300-031f : eth1 03c0-03df : vga+ 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 >Also, I cannot tell if this same ftp transfer operated at better speeds under Bering 1.2 (or even if a test was possible, since you don't say how many NICs the old router had), so please clarify that detail. Old router had two PCI NICS (3C905s, both Rev A) To be honest, I'm not certain if this problem existed on 1.2. I generally test them here before installation to make sure throughput is reasonable but I didn't keep notes. I can restore this box to its previous state very easily, and will let you know the result. Thanks for your assistance with this. - Bob Coffman ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix ------------------------------------------------------------------------ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html