Re: [ovs-discuss] Possible issue/bug at Open vSwitch and ovsdb.
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(&info);
/* Accumulate status for controllers on all bridges. */
HMAP_FOR_EACH (br, node, &all_bridges) {
+struct shash info = SHASH_INITIALIZER(&info);
ofproto_get_ofproto_controller_info(br->ofproto, &info);
-}
-/* Update each controller in the database with current status. */
-OVSREC_CONTROLLER_FOR_EACH(cfg, idl) {
-struct ofproto_controller_info *cinfo =
-shash_find_data(&info, 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, &controllers);
+size_t i;
+for (i = 0; i < n_controllers; i++) {
+struct ovsrec_controller *cfg = controllers[i];
+struct ofproto_controller_info *cinfo =
+shash_find_data(&info, 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, &cinfo->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(&info);
+ofproto_free_ofproto_controller_info(&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.
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 mailto:tribe...@lasige.di.fc.ul.pt>> 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
[ovs-discuss] Wrong ovsdb update after "switch s1 stop/start" and role request message.
quot;table":"Interface"},{"where":[["_uuid","==",["uuid","84130607-162d-4e29-8f9d-bc67079259dd"]]],"row":{"statistics":["map",[["collisions",0],["rx_bytes",0],["rx_crc_err",0],["rx_dropped",0],["rx_errors",0],["rx_frame_err",0],["rx_over_err",0],["rx_packets",0],["tx_bytes",7900],["tx_dropped",0],["tx_errors",0],["tx_packets",100]]]},"op":"update","table":"Interface"},{"where":[["_uuid","==",["uuid","a440437f-eaf4-4b46-b2ff-b79743b66321"]]],"row":{"statistics":["map",[["collisions",0],["rx_bytes",0],["rx_crc_err",0],["rx_dropped",0],["rx_errors",0],["rx_frame_err",0],["rx_over_err",0],["rx_packets",0],["tx_bytes",7742],["tx_dropped",0],["tx_errors",0],["tx_packets",98]]]},"op":"update","table":"Interface"}],
id=1549
2017-04-25T05:59:53.908Z|44183|jsonrpc|DBG|tcp:192.168.1.200:5000:
received notification, method="update2",
params=["f59c188f-a945-4022-8d6a-655e3f01c41d",{"Controller":{"bcb46630-8509-485e-a7c0-c5df7cfa8141":{"modify":{"is_connected":true,"status":["map",[["sec_since_connect","3"],["sec_since_disconnect","4"],["state","ACTIVE"]]],*"role":"master"*}},"333dc741-daa2-472c-9c9d-8337dead0318":{"modify":{"is_connected":true,"status":["map",[["sec_since_connect","3"],["sec_since_disconnect","4"],["state","ACTIVE"]]],*"role":"master"*}},"2ab2e756-cc3a-47d6-9421-1b69ae035be0":{"modify":{"is_connected":true,"status":["map",[["sec_since_connect","3"],["sec_since_disconnect","4"],["state","ACTIVE"]]],*"role":"master"*}},"c210e14b-84b2-4dde-96a4-f55c11e1cb17":{"modify":{"is_connected":true,"status":["map",[["sec_since_connect","3"],["sec_since_disconnect","4"],["state","ACTIVE"]]],*"role":"master"*}}},"Interface":{"49a488ce-5335-4d25-a0f7-0c652c774fae":{"modify":{"statistics":["map",[["tx_bytes",7742],["tx_packets",98]]]}},"49955bd4-9353-4eb4-bf6a-008a3f087c4c":{"modify":{"statistics":["map",[["tx_bytes",7900],["tx_packets",100]]]}},"9b64ef6c-0625-4a0b-b7e8-ed6e7587582f":{"modify":{"statistics":["map",[["rx_bytes",7742],["rx_packets",98]]]}},"7b98e1d4-abcc-4dd5-a092-e6331761a2a3":{"modify":{"statistics":["map",[["rx_bytes",7900],["rx_packets",100]]]}},"84130607-162d-4e29-8f9d-bc67079259dd":{"modify":{"statistics":["map",[["tx_bytes",7900],["tx_packets",100]]]}},"8b31bb89-8206-466f-a3b5-5c57e98ecb27":{"modify":{"statistics":["map",[["tx_bytes",7742],["tx_packets",98]]]}},"a440437f-eaf4-4b46-b2ff-b79743b66321":{"modify":{"statistics":["map",[["tx_bytes",7742],["tx_packets",98]]]}},"b7fea95b-c3b4-44e0-ab41-3f048b3accf7":{"modify":{"statistics":["map",[["rx_bytes",7742],["rx_packets",98]]]]
The roles are defined regarding on the last role, If I define the last
switch as slave, all switches become slave, if i define master, all
switches become master.
==
Info:
ovs-vswitchd (Open vSwitch) 2.7.0
ovs-vsctl (Open vSwitch) 2.7.0
DB Schema 7.14.0
Linux version 3.13.0-116-generic (buildd@lcy01-03) (gcc version 4.8.4
(Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #163-Ubuntu SMP Fri Mar 31 14:13:22
UTC 2017
system@ovs-system:
lookups: hit:18 missed:782 lost:1
flows: 4
masks: hit:1372 total:2 hit/pkt:1.72
port 0: ovs-system (internal)
port 1: s1-eth2
port 2: s1-eth1
port 3: s1 (internal)
port 4: s2-eth2
port 5: s2-eth3
port 6: s2-eth1
port 7: s2 (internal)
port 8: s3-eth2
port 9: s3-eth1
port 10: s3-eth3
port 11: s3 (internal)
port 12: s4-eth1
port 13: s4-eth2
port 14: s4 (internal)
Regards: )
--
Att,
Tulio Ribeiro - LaSIGE.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
