On 24/04/15 01:38, Ben Pfaff wrote:
On Fri, Apr 24, 2015 at 01:01:07AM +0100, Mark Clarkson wrote:
On 23/04/15 19:18, Ben Pfaff wrote:
I don't think that the behavior you describe is intentional. It sounds
like a bug or an unexpected interaction between features. I think
you'll have to investigate and figure out why it's happening, and then
once we understand that it can be fixed.
This is also how linux bridge works though, so maybe it is intentional(?).
Although the linux bridge allows a forwarding delay of zero for cases where
there's only one bridge.
We could make OVS support a forwarding delay of zero. Presumably, that
risks loops, but we could argue that it's the sysadmin's choice.
Not sure I'd be comfortable with that. I used to get the same delays
with linux bridges but now ping doesn't miss a single beat when an
interface is added, and I don't understand why. The application quits
every time on ovs and never with linux bridge. Maybe misconfiguration on
my part?
For ovs the following is run after the vethXXXX is created:
ifconfig $5 0.0.0.0 up
ovs-vsctl add-port br0 $5
I switched to linux bridge and now do:
ifconfig $5 0.0.0.0 up
brctl addif br0 $5
For completeness, this is how I set up ovs on each host:
ovs-vsctl add-br br0
ovs-vsctl set bridge br0 stp_enable=true
ovs-vsctl add-port br0 gre0 -- set interface gre0 type=gre
options:remote_ip=$other1
ovs-vsctl add-port br0 gre1 -- set interface gre1 type=gre
options:remote_ip=$other2
ovs-vsctl set bridge br0 other_config:stp-forward-delay=4
ovs-vsctl set bridge br0 other_config:stp-max-age=6
Pings work to all three hosts. All hosts are ubuntu trusty 14.04 with
ubuntu's openvswitch 2.0.2 packages. Kernel 3.16.0-30-generic x86_64.
Doing:
# ovs-vsctl set bridge br0 other_config:stp-forward-delay=4
# ovs-vsctl set bridge br0 other_config:stp-max-age=6
, reduces from 15s to 4s delay, but if an existing connection sends data
during the 'down' time then it receives an RST so the application closes.
I don't understand how that would happen. A RST implies that there is
connectivity. Is some system other than the end host sending the RST?
I don't think it's the end host either because that loses connection to
the network.
Web Browser -eth0-> Host A NAT --> Internal Bridge -gre-> HOST A/B/C VMs
I'm guessing that when the ovs bridged interfaces go away, the kernel
removes the TCP endpoints since they are now invalid. So the kernel
sends the reset when the Web Browser polls the VM application.
I can't be sure it was an RST as I didn't tcpdump it but that's what it
looked like.
I did try to use rstp but openvswitch replied with an error:
# ovs-vsctl set bridge br0 rstp_enable=true
ovs-vsctl: Bridge does not contain a column whose name matches
"rstp_enable"
rstp_enable is referenced in a man page pdf,
http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf, so I checked
http://openvswitch.org/releases/NEWS-2.3.1 but rstp isn't mentioned.
Any idea when rstp will be available?
RSTP is in the "master" version of OVS. You can build from master, if
you want to try it out. It will be in 2.4, when it is released, but the
2.4 release has dragged on far too long and I don't want to predict a
date.
I'll subscribe to the announce list, and try 2.4, thanks.
I have worked around the problem using the standard linux bridge and gretap
for now, which works surprisingly well, but is there any other way to
connect ovs bridges (3+ hosts) without the above problems? I can't help but
think that I'm doing something wrong!
One way would be to use a controller (distributed or centralized) to set
up flows to manage traffic forwarding.
Could I do away with gre tunnels by using flows?
Could you recommend any documentation that describes setting up
controller and flows?
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
