Hi,

I wanted to have a switch connected to a clustered controller. I used mininet 
2.2.1 and ovs 2.3.2 and 2.5.0 and opendayligh as a controller.
What I want to complain about is that "role" of the controller is not as I 
expected and I thionk it is a bug.

Commands sequence
--------------------------------
sudo mn --topo linear,1 --switch ovsk,protocols=OpenFlow13      -this is to 
create a bridge
ovs-vsctl set-controller s1 tcp:10.25.2.12:6654 tcp:10.25.2.13:6654 
tcp:10.25.2.14:6654        -this is just to set controllers, because I want 
them to be connect to cthe controller in certain order, so I use invalid port

then I use commands like
ovs-vsctl set Controller 6f5ce39e-06df-459e-be53-1c6feb2e5f23 
target="tcp\:10.25.2.13\:6653"
to connect to all 3 nodes of the controller in owder I want


Db information  -  got by ovs-ctl list Controller
-------------------------

1) after set-controller command; I removed empty values

_uuid               : 95ee77de-294f-47bc-990d-a947bcb50b76
...
is_connected        : false
...
role                : []
status              : {}
target              : "tcp:10.25.2.12:6654"

_uuid               : e093e062-7c53-4c41-8465-53005c0c9d61
...
is_connected        : false
...
role                : []
status              : {}
target              : "tcp:10.25.2.13:6654"

_uuid               : 6612ed5b-8640-4d0d-9e8d-ee860f839220
connection_mode     : []
...
is_connected        : false
...
role                : []
status              : {}
target              : "tcp:10.25.2.14:6654"


2) the I connected one controller (10.25.2.12), we see that it's role is 
"master"; wireshark pca show that controller sent relo request for master to 
10.25.2.12

_uuid               : 95ee77de-294f-47bc-990d-a947bcb50b76
...
is_connected        : true
...
role                : master
status              : {sec_since_connect="5", state=ACTIVE}
target              : "tcp:10.25.2.12:6653"

uuid               : e093e062-7c53-4c41-8465-53005c0c9d61
...
is_connected        : false
...
role                : other
status              : {last_error="Permission denied", state=BACKOFF}
target              : "tcp:10.25.2.13:6654"

_uuid               : 6612ed5b-8640-4d0d-9e8d-ee860f839220
...
is_connected        : false
...
role                : other
status              : {last_error="Permission denied", state=BACKOFF}
target              : "tcp:10.25.2.14:6654"


3) then I enabled other 2 controllers , wireshark pcap shows that controller 
sent role requests for slave for 10.25.2.13 and 14; but ovsdb shows that master 
is 10.25.2.13 and  is connectedfew seconds more that 10.25.2.14 even if both 
were "enabled" in the same time.

_uuid               : 95ee77de-294f-47bc-990d-a947bcb50b76
...
is_connected        : true
...
role                : slave
status              : {sec_since_connect="6", state=ACTIVE}
target              : "tcp:10.25.2.12:6653"

_uuid               : e093e062-7c53-4c41-8465-53005c0c9d61
...
is_connected        : true
...
role                : master
status              : {sec_since_connect="15", state=ACTIVE}
target              : "tcp:10.25.2.13:6653"

_uuid               : 6612ed5b-8640-4d0d-9e8d-ee860f839220
...
is_connected        : true
...
role                : slave
status              : {sec_since_connect="5", state=ACTIVE}
target              : "tcp:10.25.2.14:6653"


I would expect controller 10.25.2.12 to be master and connected 15 sec ; and 
10.25.2.13 and 10.25.2.14 connected 5-6 sec and be slaves.

Is something wrong with my approach or is it a bug in openvswitch?
Is role parameter reliable?


It does not happen always, may be in 50% of cases.

Regards,
Peter Gubka


_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
  • [ovs-discuss] con... Peter Gubka -X (pgubka - PANTHEON TECHNOLOGIES at Cisco)
    • Re: [ovs-dis... Ben Pfaff
      • Re: [ovs... Peter Gubka -X (pgubka - PANTHEON TECHNOLOGIES at Cisco)
        • Re: ... Ben Pfaff
          • ... Peter Gubka -X (pgubka - PANTHEON TECHNOLOGIES at Cisco)
            • ... Ben Pfaff
              • ... Peter Gubka -X (pgubka - PANTHEON TECHNOLOGIES at Cisco)
              • ... Peter Gubka -X (pgubka - PANTHEON TECHNOLOGIES at Cisco)
                • ... Ben Pfaff
                • ... Peter Gubka -X (pgubka - PANTHEON TECHNOLOGIES at Cisco)

Reply via email to