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
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
