Network issues

[NStorm]

I'm running Linux node1 2.6.32-6-pve #1 SMP Mon Sep 26 06:32:53 CEST 2011 x86_64 GNU/Linux. (Proxmox VE 1.9 distro)
I have the following network setup 192.168.X.0/24 local subnet. HN and all CTs have IPs in that subnet. Like HN has 192.168.X.33 and CTs have 192.168.X.34, 192.168.X.35, etc. Also there is a router to the world in this subnet 192.186.X.254 which NATs to the Internet. My network works from both HN and CTs and internet routed via 192.168.X.254.
HN has the vmbr0 interface, which is bridged to real eth0. The ip 192.168.X.33 are setup on vmbr0, while eth0 left without IP. When I have CTs with veth device, veth101.0 are also bridged there.
The problem is that the CT connections are getting closed after some time of activity. At least for TCP. Easy to test - if I download some big file from CT it stops downloading after some time (around 3 minutes or so). If I stop/resume it, it keeps downloading again.
I don't have this problem when downloading from HN or other real hosts on local subnet, so it's not the .254 router issue.
I've tried various OS templates (CentOS 5, CentOS 6, gentoo) and various network setups (tried venet and veth) - all the same.
Packet capture shows that at that point remote start to retransmit DUP packets as if it doesn't received ACK from me. My host keeps sending DUP ACK but seems like it is not reaching remote, because it keeps sending DUPs back.
I wonder whats the problem and how could I solve it.

 

[NStorm]

Anyone?
I also add that the iptables of both HN and CT are disabled (empty chains with default ACCEPT policy).

 

[udo]

Anyone?
I also add that the iptables of both HN and CT are disabled (empty chains with default ACCEPT policy).

Hi,
you don't need an iptables-rules - otherwise there will no packets go the right direction.

Strange effect. Have you anything configured on the switch (only one MAC-Address allowed, or so)? But then should no traffic be able...

Try another switchport (perhaps directly on the router?).

Udo

 

[NStorm]

As it comes through the same switch port, which is connect to eth0 of the HN and because HN doesn't affected by this issue I can exclude switch as the trouble part. Besides switch it is connected to are unmanaged so it can't be blocking something.
I'm going to try opennode or some other openvz setup to see if this problem occurs with other kernel version.

 

[udo]

As it comes through the same switch port, which is connect to eth0 of the HN and because HN doesn't affected by this issue I can exclude switch as the trouble part. Besides switch it is connected to are unmanaged so it can't be blocking something.
I'm going to try opennode or some other openvz setup to see if this problem occurs with other kernel version.

Hi,
my point of view you can't exclude the switch port (you use different mac-addresses on one port - if one Mac-address work, it's say nothing). But anyway...
Have you tried an debian container? I have the same setup running without trouble (and with and lot of data) for month (one system for over one year).

Does the same happens with an kvm-vm? Which used the same bridge.

Udo

 

[NStorm]

But the venet device uses the same MAC as HN.
I've also noticed that a trace from CT with venet shows HN IP as first hop. Means that traveling through CT->HN reduces packet TTL. Didn't thought it is made this way, because that is not a real route, just a virtual bridge... Probably this could be my issue.

 

[udo]

But the venet device uses the same MAC as HN.
I've also noticed that a trace from CT with venet shows HN IP as first hop. Means that traveling through CT->HN reduces packet TTL. Didn't thought it is made this way, because that is not a real route, just a virtual bridge... Probably this could be my issue.

Hi,
sorry I assume that you use bridged mode. Can you try this?

Udo

 

[NStorm]

I've tried already, wrote that at 1st post:

and various network setups (tried venet and veth) - all the same.

 

[NStorm]

I've fixed the issue by changing the TTL and compiling latest kernel module for my NIC (e1000e.ko) from sourceforge sources. Don't sure which of these solved the problem, but it seems to be working now.