Issue with Incoming traffic on Linux server

[Kripa_1]

Hi Gurus,

Iam facing a strange issue..

The ftp and scp are taking too long for even small files. After digging into the issue i observed that the incoming traffic to the server is only 1mb/s , but outgoing traffic is 50mb/s. Network team says that all settings at the network level are fine.

Iam quite confused how to proceed.

OS in read hat Linux 5.3.

Both server and switch settings are 1000Mb/s FD with Auto-negotiation on.

Thanks.

[Steven E. Protter]

Shalom,

mii-tool eth0 (replace eth0 with actual lan)
ethtool eth0

You may be going through a switch or routing the traffic through a much slower public Internet connection. Check into that.

Are you using network bonding? Perhaps that is out of whack.

netstat -in

traceroute to various sites, check the routes.

Consider yum -y update to update the entire system.

Check cabling and switches.

SEP

[wobbe]

Perhaps you server's harddisk is bussy writing other stuff?
Check you network speed with some other tool I like to use iperf. It runs both on windows and linux. Use the -w parameter to get the speeds up. And check the connection both ways.
FYI: mii-tool only reports speed up to 100mbit

[Kripa_1]

netstat -in
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth2 1500 0 55489035 0 0 0 30662707 0 0 0 BMRU
lo 16436 0 24209816 0 0 0 24209816 0 0 0 LRU

ethtool eth2
Settings for eth2:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: FIBRE
PHYAD: 2
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: g
Link detected: yes


I am not able to find any issues at the server end. Network team confirms that all settings are correct at the switch level. Will this be an issue at the cable level?

Is there any way to find out at the OS level where the issue actually exists?

[Gerardo Arceri]

I've experienced a similar issue about one year ago and the switch/firewall firmware was to blame, can you put another box in the same subnet and see if you can repeat the problem from that host (avoiding any intermediate routers/firewalls), that way you can shift the blame to the networkin people by proving nothing is wrong with the server.