Network mystery

Good evening/morning,
I need help troubleshooting my network, actually the internet access speed.

I have an OpenSuse 12.3 box with a guest WinXP inside (bridged). It’s wired to my 50/5 Mbps UPC router. The internet on these two is extremely slow and unstable. Every now and then it works fine for few minutes, but usually download speeds are below 1 Mbps; quite often around 20 Kbps (!!!).
The OpenSuse box has some samba shares. Reading those by the guest XP is super fast. It’s also super fast on to get to them from my 1Gbps LAN attached PCs, so I guess the network card is not an issue. Copying files between the guest XP and other machines on the network works perfect. The internet on all other PCs (wireless and wired) connected to the same router is great. For testing I use speedtest.net and some random FTP server. So on my wireless laptop just few minutes ago I was getting FTP download speed of nearly 2 MByte/s and right after that the same download from OpenSuse or guest XP was running at 2-4 KBytes/s.

I googled out that disabling IPv6 in Yast will sort it out. I tried it yesterday and I thought it did (or maybe it did for a while) as I was getting speedtest.net download results of 53Mbps but today it’s back to “normal”. I also found

echo "0" >/proc/sys/net/ipv4/tcp_window_scaling

somewhere on this forum but it made no difference. I don’t really know where to start other than to try random methods found here and there so if anyone has proper knowledge please tell me what to type in and I’ll post the results. Thanks in advance.

So to sum it up: the network seems fast all ways but the internet is slow on Opensuse + guest XP. Sometimes it will download half of a 100MB file at proper speed and then it will slow down to 1KByte/s. Speedtest.net also shows the same pattern. The speedo at first shoots right out to the red range and then it falls down to nearly nothing, finishing with the result of 0.4Mbps or so.

A couple preliminary questions: wired or wireless (assuming wired)? Also
what are you using for virtualization (KVM, VirtualBox, vmware something,
etc.)?

Good luck.

Wired with a 1G cable. KVM. When the guest is down it’s all the same. One option is that my br0 is configured wrong, but I created it in Yast (the text mode one) and left all the defaults in place. I can try removing it and using the default eth0 instead.

[/etc/sysconfig/network # cat ifcfg-eth0
BOOTPROTO='static'
BROADCAST=''ETHTOOL_
OPTIONS=''IPADDR='0.0.0.0/32'
MTU=''
NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller'
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'


/etc/sysconfig/network # cat ifcfg-br0
BOOTPROTO='dhcp'
BRIDGE='yes'
BRIDGE_FORWARDDELAY='0'
BRIDGE_PORTS='eth0'
BRIDGE_STP='on'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR=''
MTU='1500'
NAME='Network Bridge'
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'](zeus:/etc/sysconfig/network # cat ifcfg-eth0BOOTPROTO='static'BROADCAST=''ETHTOOL_OPTIONS=''IPADDR='0.0.0.0/32'MTU=''NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller'NETMASK=''NETWORK=''REMOTE_IPADDR=''STARTMODE='auto'USERCONTROL='no'zeus:/etc/sysconfig/network # cat ifcfg-br0BOOTPROTO='dhcp'BRIDGE='yes'BRIDGE_FORWARDDELAY='0'BRIDGE_PORTS='eth0'BRIDGE_STP='on'BROADCAST=''ETHTOOL_OPTIONS=''IPADDR=''MTU='1500'NAME='Network Bridge'NETMASK=''NETWORK=''REMOTE_IPADDR=''STARTMODE='auto'USERCONTROL='no')

Just tried removing the bridge and restoring eth0 to use dhcp but it made no difference. If there are any network config experts around please shout. Thanks.

My understanding, then, is that for a bunch of wired boxes (no wireless
issues) connections to/from this openSUSE 12.3 box and its KVM-based
windows VM is just fine. Also access for other boxes on the network
(presumably wired) is just fine to the Internet. Also, access from this
box to the Internet is fine sometimes, and at other times it is
intolerably slow. My next suggestion, then, is to get a LAN trace of
something that is initially fast and then slows down. Start from the
client (openSUSE) side with the download also running on that box (not the
VM) and see if something can be seen over time. The problem with this is
that the capture will become very big, but if you can post it somewhere
then somebody can probably review it to see if something is really
amiss… window sizes, dropped packets, other slowness… lots of options.
Maybe before doing that, review some of your stats information for the
various cards, using the command below for starters (and please post the
output):

Code:

ip -s link

LAN trace command:

Code:

sudo /usr/sbin/tcpdump -n -s 0 -i eth0 -w /tmp/dnld.cap

Post the /tmp/dnld.cap file, in case that isn’t obvious.

Good luck.

Pretty much. Within LAN all is great. SMB, FTP, in and out of the SUSE box, you name it. And all other boxes get full 50 Mbps out of my connection out. All connected to the same router, all wired (for testing purposes). One thing I forgot to mention: upload speed seems to be unaffected and is always around 5 Mbps (normal).

My next suggestion, then, is to get a LAN trace of
something that is initially fast and then slows down. Start from the
client (openSUSE) side with the download also running on that box (not the
VM) and see if something can be seen over time. The problem with this is
that the capture will become very big, but if you can post it somewhere
then somebody can probably review it to see if something is really
amiss… window sizes, dropped packets, other slowness… lots of options.
Maybe before doing that, review some of your stats information for the
various cards, using the command below for starters (and please post the
output):

Code:

ip -s link


1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    RX: bytes  packets  errors  dropped overrun mcast
    15642      215      0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    15642      215      0       0       0       0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT qlen 1000
    link/ether 08:60:6e:e8:8f:e7 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    442151478  365509   0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    74567118   237440   0       0       0       0
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
    link/ether 08:60:6e:e8:8f:e7 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    52430941   42164    0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    2286181    23885    0       0       0       0
8: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN mode DEFAULT qlen 500
    link/ether fe:54:00:e1:dc:4d brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast
    17505      142      0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    54975      253      0       0       0       0

LAN trace command:

Code:

sudo /usr/sbin/tcpdump -n -s 0 -i eth0 -w /tmp/dnld.cap


tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
110665 packets captured
112417 packets received by filter
1751 packets dropped by kernel

Post the /tmp/dnld.cap file, in case that isn’t obvious.

The file is located here.
It is an FTP download. Started fast and then stalled close to the end of the file. Hope it’s a nice read.

Good luck.

Thanks. One thing I found out today was that RTL8111/8168 doesn’t work with some kernels. The instructions say to replace the R8169 driver that is loaded by default by the one from Realtek website R8168. I did that earlier today but that made no difference.

Right, I think I found the solution. I installed r8168 v8.030 instead of v8.035 and all seems fine for now. In case if anyone hits the same problem with this network card…

Right, it appears that installing an older version of the r8168 driver fixed the problem. In case if anyone hits network speed stability issues with RTL8111/8168, the correct driver seems to be 8.030 (the newest one at the moment is 8.035).