[ovs-discuss] issue with traffic flow

westlake westlake2012 at videotron.ca
Fri May 1 21:59:38 UTC 2015


There is a traffic flow issue with openvswitch when sessioning between a 
main bridge port and a member port.

eg,
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0

a tuntap device is added to br0
ovs-vsctl add-port br0 tap0

and this tap0 device is used by a virtual machine.

br0 gets a dhcp ip address without issue, and the VM machine which uses 
tap0 also gets a dhcp ip address from an external routing box, so these 
two ip's are on the same network.

Here's where it gets fuzzy and difficult to explain, and it tends to 
happen all the time when ssh is used with iptables. The main problem is 
a large delay when there is a session going on between the hypervisor 
and VM.

I'll start with the noticeable problem,

Hypervisor-on-br0<-openvswitch->VM-on-tap0

When an ssh(client) command is issued to talk to the VM, there is no 
delay at all. ssh -vv shows nothing particular and the starting of the 
ssh session with the login prompt shows up immediately.

However, exactly the same scenario, only having to use iptables (and 
this occurs regardless of the distro in the VM)

--> tcpdump shows there is traffic immediately returned -- and this is 
tcpdump running on the VM, ... only that the login prompt on the 
hypervisor does not show the prompt until 30 seconds later! weird.

I've tried to file this and thought it might have been iptables or the 
distro's kernel that I'm using at fault, but apparently this also 
happens with another distro as a VM guest.

For some reason "iptables" in a VM is creating a "delay" with 
openvswitch, .. I have no idea why this is, but even ssh -vv doesn't 
seem to indicate to me much.

All I know is there is a "delay".. furthermore to clarify something, 
traffic between a wired client issuing ssh outside the hypervisor gets 
an instantaneous ssh login prompt regardless iptables is up or not.  For 
some reason having "iptables" enabled (in the VM) is creating a delay 
between the hypervisor and VM guest.

the iptables rule is very simple,

iptables -I INPUT -p tcp --dport 22 -j ACCEPT
iptables -P INPUT DROP

iptables -L -n -v (there is nothing detail revealing anything other than 
port 22 being set)

Openvswitch is running on a debian system, and I thought it may have 
been due to a bug with iptables or the the new default kernel being used 
on the recent release of debian but I'm pretty sure something odd is 
happening with openvswitch causing this.  It doesn't make sense why 
"iptables" in a VM would be causing a delay in ssh session but it is.

I've tried to bring this up on debian bugreporting, but I don't think it 
has anything to do with iptables or kernel because tcpdump tells me the 
packets from the VM are timely responding.. there is a long delay (30 
seconds) in tcpdump before the client suddently starts to show a login 
prompt. According to what I'm seeing there is a "prompt" after the 30 
second delay before there is new traffic to be seen -- telling me there 
are packets hanging somewhere around back at the hypervisor side.

anyone want to take a jab at it be my guest..

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783747
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783958



More information about the discuss mailing list