[ovs-discuss] first ping lost
fred at mautadine.com
Mon Sep 14 18:14:41 UTC 2015
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
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.
On Mon, Sep 14, 2015 at 1:05 PM, Lukas Erlacher <erlacher at in.tum.de> wrote:
> 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.
> discuss mailing list
> discuss at openvswitch.org
More information about the discuss