[ovs-discuss] problem with LACP Failover

Pacôme MASSOL pacome at pmassol.net
Sat Aug 4 12:53:55 UTC 2012


Hello,

thanks for your advices but i'm still stuck.

At the beginning, everything is OK :

$ sudo ovs-dpctl dump-flows sw0
in_port(3),eth(src=08:00:27:9b:24:12,dst=08:00:27:77:b1:55),eth_type(0x0800),ipv4(src=10.0.0.1,dst=10.0.0.2,proto=1,tos=0,ttl=128,frag=no),icmp(type=0,code=0), 
packets:119, bytes:11662, used:0.362s, actions:1
in_port(1),eth(src=08:00:27:77:b1:55,dst=08:00:27:9b:24:12),eth_type(0x0800),ipv4(src=10.0.0.2,dst=10.0.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0), 
packets:121, bytes:11858, used:0.362s, actions:3
$ sudo ovs-dpctl dump-flows sw0
in_port(3),eth(src=08:00:27:9b:24:12,dst=08:00:27:77:b1:55),eth_type(0x0800),ipv4(src=10.0.0.1,dst=10.0.0.2,proto=1,tos=0,ttl=128,frag=no),icmp(type=0,code=0), 
packets:121, bytes:11858, used:0.559s, actions:1
in_port(1),eth(src=08:00:27:77:b1:55,dst=08:00:27:9b:24:12),eth_type(0x0800),ipv4(src=10.0.0.2,dst=10.0.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0), 
packets:123, bytes:12054, used:0.560s, actions:3

When I put down one of the bonded tun interface on the host :
$ sudo ifconfig sw0p0 down

$ sudo ovs-dpctl dump-flows sw0
in_port(1),eth(src=08:00:27:77:b1:55,dst=08:00:27:9b:24:12),eth_type(0x0800),ipv4(src=10.0.0.2,dst=10.0.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0), 
packets:6, bytes:588, used:0.966s, actions:drop
$ sudo ovs-dpctl dump-flows sw0
in_port(1),eth(src=08:00:27:77:b1:55,dst=08:00:27:9b:24:12),eth_type(0x0800),ipv4(src=10.0.0.2,dst=10.0.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0), 
packets:8, bytes:784, used:0.492s, actions:drop


The other command teaches me nothing :

$ sudo ovs-appctl ofproto/trace sw0 
'in_port(1),eth(src=08:00:27:77:b1:55,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=10.0.0.2,tip=10.0.0.1,op=1,sha=08:00:27:77:b1:55,tha=00:00:00:00:00:00)'
Flow: priority0:tunnel0:in_port0001:tci(0) 
mac08:00:27:77:b1:55->ff:ff:ff:ff:ff:ff type0806 proto1 tos0 ttl0 
ip10.0.0.2->10.0.0.1 arp_ha08:00:27:77:b1:55->00:00:00:00:00:00
Rule: table=0 cookie=0 priority=0
OpenFlow actions=NORMAL

Final flow: unchanged
Datapath actions: 0

$ sudo ovs-appctl ofproto/trace sw0 
'in_port(3),eth(src=08:00:27:9b:24:12,dst=08:00:27:77:b1:55),eth_type(0x0800),ipv4(src=10.0.0.1,dst=10.0.0.2,proto=1,tos=0,ttl=128,frag=no)'
Flow: priority0:tunnel0:in_port0003:tci(0) 
mac08:00:27:9b:24:12->08:00:27:77:b1:55 type0800 proto1 tos0 ttl128 
ip10.0.0.1->10.0.0.2
Rule: table=0 cookie=0 priority=0
OpenFlow actions=NORMAL

Final flow: unchanged
Datapath actions: drop




Le 30/07/2012 23:06, Ethan Jackson a écrit :
> Well, based on the output you've given, the bond looks healthy.
> You'll have to figure out where precisely the packets are getting
> dropped.  Typically I do this by using ovs-dpctl dump-flows to figure
> out what the datapath is a given packet.  If you're still stuck, you
> may want to check out the ovs-appctl ofproto/trace command.  You can
> give it an exact match datapath flow, and it will tell you in detail
> how userspace came to its forwarding decision.
>
> Ethan
>
> On Fri, Jul 27, 2012 at 12:28 AM, Pacôme MASSOL <pacome at pmassol.net> wrote:
>> Le 26/07/2012 23:21, Ethan Jackson a écrit :
>>
>>> Please keep replies on the list.
>>>
>>>
>> Ooops sorry !
>>
>> Thank you for your help. What I tried since your last message :
>>
>>
>> This my startup configuration (VMs halted) :
>>
>> -----
>> killall ovsdb-server
>> killall ovs-vswitchd
>>
>> for tap in `seq 0 3`; do ip tuntap del mode tap sw0p$tap; done;
>>
>> rmmod openvswitch
>>
>> modprobe openvswitch
>>
>> for tap in `seq 0 3`; do ip tuntap add mode tap sw0p$tap; done;
>> for tap in `seq 0 3`; do ip link set sw0p$tap up; done;
>>
>> rm -f /etc/openvswitch/conf.db
>> ovsdb-tool create /etc/openvswitch/conf.db
>> /usr/share/openvswitch/vswitch.ovsschema
>>
>> mkdir  /var/run/openvswitch
>> ovsdb-server --remote=punix:/var/run/openvswitch/db.sock --pidfile --detach
>>
>> ovs-vsctl --no-wait init
>>
>> ovs-vswitchd --pidfile --detach
>>
>> ovs-vsctl add-br sw0
>> ovs-vsctl add-port sw0 sw0p2
>> ovs-vsctl add-bond sw0 bond0 sw0p0 sw0p1
>>
>> ovs-vsctl set port bond0 bond_mode=balance-tcp
>> ovs-vsctl set port bond0 lacp=active
>> ovs-vsctl set port bond0 other_config:lacp-time=fast
>> ----
>>
>>
>> Then I launch the 2 VMS (Windows 10.0.0.1 with LACP Intel proprietary driver
>> configured with 802.3ad and a simple Linux Debian guest 10.0.0.2)
>>
>> When the Windows  guest is on, I get on the host :
>> # ovs-appctl bond/show bond0
>> bond_mode: balance-tcp
>> bond-hash-algorithm: balance-tcp
>>
>> bond-hash-basis: 0
>> updelay: 0 ms
>> downdelay: 0 ms
>> next rebalance: 5899 ms
>>
>> lacp_negotiated: true
>>
>> slave sw0p1: enabled
>>      active slave
>>      may_enable: true
>>
>> slave sw0p0: enabled
>>      may_enable: true
>>
>>
>>
>>  From now, it is really confusing. From the Linux vm, I ping the Win VM, the
>> first 8 pings are OK and then it stops (without any intervention).
>>
>>
>> What Wireshark says under Windows :
>> - bonded NIC : ICMP requests from Linux and Win ARP requests
>> - first NIC : only Win ARP requests (+LACP announces)
>> - second NIC : only ICMP requests from Linux (+LACP announces)
>> What tcpdump says under Linux :
>> - Win ARP Requests
>> - Linux ARP Replies
>> - ICMP Requests
>>
>>
>> Linux ARP replies never reach the Win VM.
>>
>>
>> Bond state on the host :
>>
>> # ovs-appctl bond/show bond0
>> bond_mode: balance-tcp
>> bond-hash-algorithm: balance-tcp
>>
>> bond-hash-basis: 0
>> updelay: 0 ms
>> downdelay: 0 ms
>> next rebalance: 8452 ms
>>
>> lacp_negotiated: true
>>
>> slave sw0p1: enabled
>>      active slave
>>      may_enable: true
>>      hash 237: 0 kB load
>>
>>
>> slave sw0p0: enabled
>>      may_enable: true
>>      hash 80: 1 kB load
>>
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/discuss
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss




More information about the discuss mailing list