Just for the follow up,
Changing the bond-mode from balance-tcp to active-backup fix my
problem.. But it's not the solution. I doubt it's a switch problem
since with linux bonding, it's working fine with the hash policy
layer3+4.
My LACP seems to be correctly negociated with the switch:
---- bond0 ----
status: active negotiated
sys_id: d0:bf:9c:46:56:94
sys_priority: 65534
aggregation key: 1
lacp_time: fast
slave: em1: current attached
port_id: 1
port_priority: 65535
may_enable: true
actor sys_id: d0:bf:9c:46:56:94
actor sys_priority: 65534
actor port_id: 1
actor port_priority: 65535
actor key: 1
actor state: activity timeout aggregation synchronized
collecting distributing
partner sys_id: 34:6f:90:30:14:ab
partner sys_priority: 1
partner port_id: 60
partner port_priority: 1
partner key: 1000
partner state: activity aggregation synchronized collecting distributing
slave: em2: current attached
port_id: 2
port_priority: 65535
may_enable: true
actor sys_id: d0:bf:9c:46:56:94
actor sys_priority: 65534
actor port_id: 2
actor port_priority: 65535
actor key: 1
actor state: activity timeout aggregation synchronized
collecting distributing
partner sys_id: 34:6f:90:30:14:ab
partner sys_priority: 1
partner port_id: 52
partner port_priority: 1
partner key: 1000
partner state: activity aggregation synchronized collecting distributing
If anyone have an idea what's going on!
Thanks,
Fred
On Mon, Sep 14, 2015 at 8:14 PM, Frédéric Marchand <[email protected]> wrote:
> Hello,
>
> Thanks for the reply but I don't think it's arp. The arp table have
> the correct information and also, i tried with static entries on both
> side.
>
> Maybe I should have mentioned that earlier: when i'm connected to ssh
> through one of those fake bridges, the login takes a while (3-4
> seconds, dns timeouts) then it's ok. And if i don't make any input for
> more than 5 seconds, the next input lag a few hundred milliseconds
> (kernel flows TTL?)
>
> By the way, I don't experience those issues using linux bonding and vlan.
>
> Regards,
>
> Fred
>
>
>
>
> On Mon, Sep 14, 2015 at 1:05 PM, Lukas Erlacher <[email protected]> wrote:
>> Hi,
>> On 09/14/2015 05:27 AM, Frédéric Marchand wrote:
>>>
>>> Hello all,
>>>
>>> I've installed and configured openvswitch 2.3.1 on 3 machines (ubuntu
>>> 15.04). I've created a bridge with two interfaces in LACP balance-tcp.
>>> I also added some fake bridges with vlan tags.
>>>
>>> The problem i have is when I ping one of the fake bridge, the first
>>> ping is lost (unless there is a tcp connection already up!):
>>>
>>> PING 10.10.22.11 (10.10.22.11) 56(84) bytes of data.
>>> 64 bytes from 10.10.22.11: icmp_seq=2 ttl=64 time=0.419 ms
>>> 64 bytes from 10.10.22.11: icmp_seq=3 ttl=64 time=0.361 ms
>>
>> Are you sure that's not just an empty arp cache?
>>>
>>>
>>> Here is the configuration:
>>>
>>> ovs-vsctl add-br br-main
>>> ovs-vsctl ovs-vsctl add-bond br-main bond0 em1 em2
>>> ovs-vsctl set port bond0 bond_mode=balance-tcp
>>> ovs-vsctl set port bond0 lacp=active
>>> ovs-vsctl add-br br-data br-main 22
>>> ip addr add 10.10.22.11/24 dev br-data
>>>
>>> LACP seems fine:
>>> ---- bond0 ----
>>> status: active negotiated
>>> sys_id: 34:64:a9:9a:5f:00
>>> sys_priority: 65534
>>> aggregation key: 1
>>> lacp_time: slow
>>>
>>> The machines have broadcom BCM5720 interfaces using tg3 drivers.
>>>
>>> Also, i guess it's linked, DNS queries coming out this interface
>>> timeout most of the time. But if i ping the DNS server while doing an
>>> nslookup, it works fine.
>>>
>>> Anyone knows what is the problem?
>>
>> Could still be an arp problem. Run "arp" before and after trying to send
>> those requests. If it's an arp problem, it should always be the first packet
>> that gets lost and all subsequent packets/requests should be fine.
>>
>> Best,
>> Luke
>> _______________________________________________
>> discuss mailing list
>> [email protected]
>> http://openvswitch.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
