> 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: [email protected]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
