Re: [ovs-discuss] Possible issue/bug at Open vSwitch and ovsdb.

[Andy Zhou]

I posted the fix to the mailing list.  The patch now include a unit
test to cover this bug.
https://mail.openvswitch.org/pipermail/ovs-dev/2017-May/332362.html

On Thu, May 11, 2017 at 1:16 PM, Andy Zhou  wrote:
> On Thu, May 11, 2017 at 2:42 AM, Tulio Ribeiro
>  wrote:
>> Hi Andy,
>>
>> I did the patch but now the command $sudo ovs-vsctl add-br s1 stuck (the
>> bridge is added but the command does not return).
>>
>> The command sudo ovs-vsctl set-controller s1 tcp:192.168.1.215:6653 do not
>> return as well.
>>
>> The role of a bridge is not defined, which means, the initial role is empty,
>> but should be "other".
>
> Is ovs-vswitchd still running in your system? The change should not affect how
> the first command works any ways. I just tested the change locally at
> it seems to work.
>
>>
>> Regards.
>>
>> Att,
>>
>> Tulio Ribeiro - LaSIGE.
>>
>> On 05/10/2017 11:27 PM, Andy Zhou wrote:
>>>
>>> On Wed, May 10, 2017 at 11:40 AM, Tulio Ribeiro
>>>  wrote:

 Hi guys, sorry to bother you again and send this direct message, but I
 did a
 test without using Mininet, and the problem/behavior persists.

 Could someone try to test this, please?
 Thanks a lot in advance.
>>>
>>> Thanks for reporting, I think it is a bug that triggered by having the
>>> same controller
>>> connection settings in multiple bridges, as shown in your example.
>>>
>>> Do you mind try the fix below and let me know if it helps?  I did not
>>> test beyond compiling it.
>>>
>>>
>>> diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
>>> index 31203d1ec232..5d13a1712168 100644
>>> --- a/vswitchd/bridge.c
>>> +++ b/vswitchd/bridge.c
>>> @@ -2704,34 +2704,31 @@ static void
>>>   refresh_controller_status(void)
>>>   {
>>>   struct bridge *br;
>>> -struct shash info;
>>> -const struct ovsrec_controller *cfg;
>>> -
>>> -shash_init();
>>>
>>>   /* Accumulate status for controllers on all bridges. */
>>>   HMAP_FOR_EACH (br, node, _bridges) {
>>> +struct shash info = SHASH_INITIALIZER();
>>>   ofproto_get_ofproto_controller_info(br->ofproto, );
>>> -}
>>>
>>> -/* Update each controller in the database with current status. */
>>> -OVSREC_CONTROLLER_FOR_EACH(cfg, idl) {
>>> -struct ofproto_controller_info *cinfo =
>>> -shash_find_data(, cfg->target);
>>> +/* Update each controller of the bridge in the database with
>>> + * current status. */
>>> +struct ovsrec_controller **controllers;
>>> +size_t n_controllers = bridge_get_controllers(br, );
>>> +size_t i;
>>> +for (i = 0; i < n_controllers; i++) {
>>> +struct ovsrec_controller *cfg = controllers[i];
>>> +struct ofproto_controller_info *cinfo =
>>> +shash_find_data(, cfg->target);
>>>
>>> -if (cinfo) {
>>> +ovs_assert(cinfo);
>>>   ovsrec_controller_set_is_connected(cfg,
>>> cinfo->is_connected);
>>>   ovsrec_controller_set_role(cfg,
>>> ofp12_controller_role_to_str(
>>> -   cinfo->role));
>>> +cinfo->role));
>>>   ovsrec_controller_set_status(cfg, >pairs);
>>> -} else {
>>> -ovsrec_controller_set_is_connected(cfg, false);
>>> -ovsrec_controller_set_role(cfg, NULL);
>>> -ovsrec_controller_set_status(cfg, NULL);
>>>   }
>>> -}
>>>
>>> -ofproto_free_ofproto_controller_info();
>>> +ofproto_free_ofproto_controller_info();
>>> +}
>>>   }
>>
>>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Possible issue/bug at Open vSwitch and ovsdb.

[Andy Zhou]

On Thu, May 11, 2017 at 2:42 AM, Tulio Ribeiro
 wrote:
> Hi Andy,
>
> I did the patch but now the command $sudo ovs-vsctl add-br s1 stuck (the
> bridge is added but the command does not return).
>
> The command sudo ovs-vsctl set-controller s1 tcp:192.168.1.215:6653 do not
> return as well.
>
> The role of a bridge is not defined, which means, the initial role is empty,
> but should be "other".

Is ovs-vswitchd still running in your system? The change should not affect how
the first command works any ways. I just tested the change locally at
it seems to work.

>
> Regards.
>
> Att,
>
> Tulio Ribeiro - LaSIGE.
>
> On 05/10/2017 11:27 PM, Andy Zhou wrote:
>>
>> On Wed, May 10, 2017 at 11:40 AM, Tulio Ribeiro
>>  wrote:
>>>
>>> Hi guys, sorry to bother you again and send this direct message, but I
>>> did a
>>> test without using Mininet, and the problem/behavior persists.
>>>
>>> Could someone try to test this, please?
>>> Thanks a lot in advance.
>>
>> Thanks for reporting, I think it is a bug that triggered by having the
>> same controller
>> connection settings in multiple bridges, as shown in your example.
>>
>> Do you mind try the fix below and let me know if it helps?  I did not
>> test beyond compiling it.
>>
>>
>> diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
>> index 31203d1ec232..5d13a1712168 100644
>> --- a/vswitchd/bridge.c
>> +++ b/vswitchd/bridge.c
>> @@ -2704,34 +2704,31 @@ static void
>>   refresh_controller_status(void)
>>   {
>>   struct bridge *br;
>> -struct shash info;
>> -const struct ovsrec_controller *cfg;
>> -
>> -shash_init();
>>
>>   /* Accumulate status for controllers on all bridges. */
>>   HMAP_FOR_EACH (br, node, _bridges) {
>> +struct shash info = SHASH_INITIALIZER();
>>   ofproto_get_ofproto_controller_info(br->ofproto, );
>> -}
>>
>> -/* Update each controller in the database with current status. */
>> -OVSREC_CONTROLLER_FOR_EACH(cfg, idl) {
>> -struct ofproto_controller_info *cinfo =
>> -shash_find_data(, cfg->target);
>> +/* Update each controller of the bridge in the database with
>> + * current status. */
>> +struct ovsrec_controller **controllers;
>> +size_t n_controllers = bridge_get_controllers(br, );
>> +size_t i;
>> +for (i = 0; i < n_controllers; i++) {
>> +struct ovsrec_controller *cfg = controllers[i];
>> +struct ofproto_controller_info *cinfo =
>> +shash_find_data(, cfg->target);
>>
>> -if (cinfo) {
>> +ovs_assert(cinfo);
>>   ovsrec_controller_set_is_connected(cfg,
>> cinfo->is_connected);
>>   ovsrec_controller_set_role(cfg,
>> ofp12_controller_role_to_str(
>> -   cinfo->role));
>> +cinfo->role));
>>   ovsrec_controller_set_status(cfg, >pairs);
>> -} else {
>> -ovsrec_controller_set_is_connected(cfg, false);
>> -ovsrec_controller_set_role(cfg, NULL);
>> -ovsrec_controller_set_status(cfg, NULL);
>>   }
>> -}
>>
>> -ofproto_free_ofproto_controller_info();
>> +ofproto_free_ofproto_controller_info();
>> +}
>>   }
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Possible issue/bug at Open vSwitch and ovsdb.

[Tulio Ribeiro]

Hi Andy,

I did the patch but now the command $sudo ovs-vsctl add-br s1 stuck (the 
bridge is added but the command does not return).


The command sudo ovs-vsctl set-controller s1 tcp:192.168.1.215:6653 do 
not return as well.


The role of a bridge is not defined, which means, the initial role is 
empty, but should be "other".


Regards.

Att,

Tulio Ribeiro - LaSIGE.

On 05/10/2017 11:27 PM, Andy Zhou wrote:

On Wed, May 10, 2017 at 11:40 AM, Tulio Ribeiro
 wrote:

Hi guys, sorry to bother you again and send this direct message, but I did a
test without using Mininet, and the problem/behavior persists.

Could someone try to test this, please?
Thanks a lot in advance.

Thanks for reporting, I think it is a bug that triggered by having the
same controller
connection settings in multiple bridges, as shown in your example.

Do you mind try the fix below and let me know if it helps?  I did not
test beyond compiling it.


diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 31203d1ec232..5d13a1712168 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -2704,34 +2704,31 @@ static void
  refresh_controller_status(void)
  {
  struct bridge *br;
-struct shash info;
-const struct ovsrec_controller *cfg;
-
-shash_init();

  /* Accumulate status for controllers on all bridges. */
  HMAP_FOR_EACH (br, node, _bridges) {
+struct shash info = SHASH_INITIALIZER();
  ofproto_get_ofproto_controller_info(br->ofproto, );
-}

-/* Update each controller in the database with current status. */
-OVSREC_CONTROLLER_FOR_EACH(cfg, idl) {
-struct ofproto_controller_info *cinfo =
-shash_find_data(, cfg->target);
+/* Update each controller of the bridge in the database with
+ * current status. */
+struct ovsrec_controller **controllers;
+size_t n_controllers = bridge_get_controllers(br, );
+size_t i;
+for (i = 0; i < n_controllers; i++) {
+struct ovsrec_controller *cfg = controllers[i];
+struct ofproto_controller_info *cinfo =
+shash_find_data(, cfg->target);

-if (cinfo) {
+ovs_assert(cinfo);
  ovsrec_controller_set_is_connected(cfg, cinfo->is_connected);
  ovsrec_controller_set_role(cfg, ofp12_controller_role_to_str(
-   cinfo->role));
+cinfo->role));
  ovsrec_controller_set_status(cfg, >pairs);
-} else {
-ovsrec_controller_set_is_connected(cfg, false);
-ovsrec_controller_set_role(cfg, NULL);
-ovsrec_controller_set_status(cfg, NULL);
  }
-}

-ofproto_free_ofproto_controller_info();
+ofproto_free_ofproto_controller_info();
+}
  }


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Possible issue/bug at Open vSwitch and ovsdb.

[Tulio Ribeiro]

Hi guys, sorry to bother you again and send this direct message, but I 
did a test *without* using Mininet, and the problem/behavior persists.


Could someone try to test this, please?

It is necessary one active controller, I've tested with Floodlight 
controller.


A simple way to verify is, open one term and execute
$watch sudo ovsdb-client dump Controller

In another term, execute this sequence of commands, and see what happens:

$sudo ovs-vsctl add-br s1
$sudo ovs-vsctl add-br s2
$sudo ovs-vsctl set-controller s1 tcp:192.168.1.215:6653
Wait 5 seconds, and execute:
$sudo ovs-vsctl set-controller s2 tcp:192.168.1.215:6653

You will see that *sec_since_connect* are the same, but should not be 
once I connected at different times.


Try to change the role of the controller,  need to change the data 
inside of < > with the appropriate value.
$sudo ovs-vsctl set  Controller *<975fb2ed-6354-45c1-ba12-3c2295bdee7b>* 
role=slave


The role gets back to master after some seconds, why it gets back to master?

I wrote this thread at OVS-Discuss list, but without success.
https://mail.openvswitch.org/pipermail/ovs-discuss/2017-April/044293.html

=

Another test that could be done, take a look at the information defined 
at fail_mode and role.


$sudo ovs-vsctl add-br s1 -- set bridge s1 
other-config:datapath-id=0001 fail_mode=secure
$sudo ovs-vsctl add-br s2 -- set bridge s2 
other-config:datapath-id=0002 fail_mode=secure

$sudo ovs-vsctl set-controller s1 tcp:192.168.1.215:6653
$sudo ovs-vsctl set-controller s2 tcp:192.168.1.215:6653
$sudo ovs-vsctl set Controller 3675a6b5-b9c5-4db3-91cd-ab5226045b56 
role=slave


Regards and many thanks.

: )

Att,

Tulio Ribeiro - LaSIGE.

On 04/26/2017 08:58 PM, Jarno Rajahalme wrote:
Have you tried the mining mailing lists? I haven’t used mininet for 
some years now, but this could be a mininet issue rather than an OVS 
issue.


  Jarno

On Apr 26, 2017, at 2:52 AM, Tulio Ribeiro 
> wrote:


Hi, sorry to bother you sending a direct e-mail, but I'm stuck for 
weeks at the same problem.

I did not find any way to circumvent this issue.

I wrote a question at ovs-discuss and ovs-dev but no one help-me.
https://mail.openvswitch.org/pipermail/ovs-discuss/2017-April/044293.html

I'm facing a little strange behavior.

Suppose that I have 4 switches.
The info showed in *sec_since_connect* (Controller table of ovsdb) 
should show information related with a specific switch, for instance,
if I disconnect s1 and reconnect (stop/start from mininet) the 
information should be different right?


When I monitor the table Controller from ovsdb and send a transaction 
to change some info there, the info is changed but it get back using 
the former info.


Would you please try a simple test?
The test is monitor the table Controller from ovsdb and stop and 
start just one switch, s1 for instance:


Monitor command:
$watch sudo ovsdb-client dump Controller

Mininet command:
$sudo mn --mac --controller=remote,ip=192.168.1.215,port=6653 --topo 
linear,4 --switch ovsk,protocols=OpenFlow14; sudo mn -c


mininet$ switch s1 stop
mininet$ switch s1 start

The value of *sec_since_connect* is the same for all switches...
Other point is, the role when I use two controller are the same as 
well, which means,

the last role_request from a Controller will update all switches roles.


I have tracked the messages between open vSwitch and ovsdb and I 
notice that the transaction created by open vSwicth regarding on a 
role request are been created using the same role for all switches.


Some useful info:
ovsdb-server (Open vSwitch) 2.7.0
ovs-vsctl (Open vSwitch) 2.7.0
DB Schema 7.14.0

Again, sorry to bother you sending a direct message.

Thanks a lot in advance.

Regards
--
Att,

Tulio Ribeiro - LaSIGE.




___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss