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=0000000000000001 fail_mode=secure
$sudo ovs-vsctl add-br s2 -- set bridge s2
other-config:datapath-id=0000000000000002 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
<tribe...@lasige.di.fc.ul.pt <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
