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
