[ovs-dev] [BUG] broad-/multicast & SLB bonding -> FAIL

Ethan Jackson ethan at nicira.com
Thu Jan 31 19:30:18 UTC 2013


Are you absolutely sure the traffic isn't egressing the first switch,
and then ingressing the other switch into the bond?  It's often hard
to tell with tcpdump which direction traffic is travelling.

Could you please send problematic traffic through the switch, and
while that's going either run ovs-bugtool and send us the tarball, or
run the following commands

ovs-dpctl show -s
ovs-dpctl dump-flows <bridge>

ovs-appclt bond/list
ovs-appctl bond/show
ovs-acpptl lacp/show
ovs-appctl fdb/show <bond bridge>

Thanks,
Ethan

On Wed, Jan 30, 2013 at 5:26 PM, Jesse Gross <jesse at nicira.com> wrote:
> On Mon, Jan 28, 2013 at 12:07 PM, Markus Schuster
> <ml at markus.schuster.name> wrote:
>> On Monday 28 January 2013 20:29:01 Jesse Gross wrote:
>>> Are you configuring bonding directly through the OVS command line or
>>> using Xen tools?
>>
>> I'm using the Xen tools to configure all networking related settings.
>> Currently I'm not deep enough into Open vSwitch - on the ToDo list since a few
>> years...
>>
>>
>>> Can you also send the output of ovs-vsctl show?
>>
>> Sure:
>> --- cut ---
>> d3a05b53-3615-46e2-8d5a-7e47aa50ad84
>>     Bridge "xenbr3"
>>         fail_mode: standalone
>>         Port "xenbr3"
>>             Interface "xenbr3"
>>                 type: internal
>>         Port "eth3"
>>             Interface "eth3"
>>     Bridge "xapi1"
>>         fail_mode: standalone
>>         Port "bond0"
>>             Interface "eth0"
>>             Interface "eth1"
>>         Port "xapi1"
>>             Interface "xapi1"
>>                 type: internal
>>         Port "vif2.0"
>>             Interface "vif2.0"
>>     Bridge "xenbr2"
>>         fail_mode: standalone
>>         Port "xenbr2"
>>             Interface "xenbr2"
>>                 type: internal
>>         Port "eth2"
>>             Interface "eth2"
>>     ovs_version: "1.4.2"
>> --- cut ---
>>
>>
>>> >> Can you also post the logs?
>>> >
>>> > Well, there aren't much log files - at least not much I was able to find.
>>> [..]
>>>
>>> It's also odd that the ovs-vswitchd.log file is empty.  Can you check
>>> the command line to make sure that it is supposed to be logging?
>>
>> Looks like Open vSwitch components are configured to log to syslog:
>> --- cut ---
>> ovsdb-server /etc/openvswitch/conf.db -vANY:CONSOLE:EMER -vANY:SYSLOG:INFO -
>> vANY:FILE:EMER --remote=punix:/var/run/openvswitch/db.sock --
>> remote=db:Open_vSwitch,manager_options --private-key=db:SSL,private_key --
>> certificate=db:SSL,certificate --bootstrap-ca-cert=db:SSL,ca_cert --no-chdir
>> --log-file=/var/log/openvswitch/ovsdb-server.log --
>> pidfile=/var/run/openvswitch/ovsdb-server.pid --detach --monitor
>>
>> ovs-vswitchd unix:/var/run/openvswitch/db.sock -vANY:CONSOLE:EMER -
>> vANY:SYSLOG:INFO -vANY:FILE:EMER --mlockall --no-chdir --log-
>> file=/var/log/openvswitch/ovs-vswitchd.log --pidfile=/var/run/openvswitch/ovs-
>> vswitchd.pid --detach --monitor
>> --- cut ---
>>
>> So I grepped daemon.log for "ovs" - seems to be a good fit. I'll send you that
>> file in a direct message as I don't know the list policy regarding larger
>> files - feel free to forward as needed.
>
> At first glance, all of the configuration seems fine to me.
> Realistically, it's been too long since I've looked at the SLB code to
> track this down.  Ethan, I think you've worked on this the most
> recently, can you take a look?



More information about the dev mailing list