ONOS
  1. ONOS
  2. ONOS-3088

starting mininet with traffic before onos cluster causes onos to not discover topology

    Details

    • Type: Bug Bug
    • Status: Closed (View Workflow)
    • Priority: Critical Critical
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.4.0
    • Fix Version/s: None
    • Component/s: None
    • Story Points:
      5
    • Epic Link:
    • Sprint:
      Emu Sprint 1 (9/21-10/9), Emu Sprint 2 (10/12-10/30), Emu Sprint 3 (11/2 - 11/20), Emu Sprint 4 (11/23-12/18), Junco Sprint #1 - Platform, Junco Sprint #2 - Platform

      Description

      I start the mininet first. Then start 3 onos nodes one by one.
      After all the 3 nodes fully setup, the number of the links keep on changing. At very beginning, onos found 80 links, but finally lost all the links. when you use summary in onos CLI, the number of link is 0.

      If I change the sequence, start the 3 onos nodes first, then start mininet, then there is no such issue.

        Activity

        Hide
        Claudine Chiu added a comment -

        Trying to reproduce the issue
        1. For the test case how are you starting mininet? What is the topology and what controller options are you using?
        2. When starting the ONOS instances are you starting each instance and then forming the cluster, or does this only happen after the cluster is formed and configured and you are restarting the nodes?

        Do you still have the onos logs from your most recent attempt (any time after Oct. 8)?

        Show
        Claudine Chiu added a comment - Trying to reproduce the issue 1. For the test case how are you starting mininet? What is the topology and what controller options are you using? 2. When starting the ONOS instances are you starting each instance and then forming the cluster, or does this only happen after the cluster is formed and configured and you are restarting the nodes? Do you still have the onos logs from your most recent attempt (any time after Oct. 8)?
        Hide
        Claudine Chiu added a comment -

        I am having issues reproducing the bug. I tried to replicate the bug – by doing the following:

        1. Mininet is running with the small topology (2 switches, each connected to 2 remote controllers)
        2. ONOS 3-node cluster was previously setup. Started up 3 nodes (one in each VM) with command (bin/onos-service server)
        3. Check the nodes/devices/links etc. in interactive ONOS session (bin/onos)
        4. Shutdown the nodes (system:shutdown in interactive onos session, and occasionally a kill if onos process does not die)
        5. So far, I have not observed the issue reported in the bug report … I’ve done steps 2 to 4 a number of times.

        Could the reason I cannot reproduce the bug be because of the topology I used (2 switches)? If so, can you provide info on which topology you used when you first saw the bug?

        Or maybe the steps above are not right/sufficient?

        Show
        Claudine Chiu added a comment - I am having issues reproducing the bug. I tried to replicate the bug – by doing the following: 1. Mininet is running with the small topology (2 switches, each connected to 2 remote controllers) 2. ONOS 3-node cluster was previously setup. Started up 3 nodes (one in each VM) with command (bin/onos-service server) 3. Check the nodes/devices/links etc. in interactive ONOS session (bin/onos) 4. Shutdown the nodes (system:shutdown in interactive onos session, and occasionally a kill if onos process does not die) 5. So far, I have not observed the issue reported in the bug report … I’ve done steps 2 to 4 a number of times. Could the reason I cannot reproduce the bug be because of the topology I used (2 switches)? If so, can you provide info on which topology you used when you first saw the bug? Or maybe the steps above are not right/sufficient?
        Hide
        Jon Hall added a comment -

        I was able to reproduce it with the following setup:
        1. tree 3,3 topology : "sudo mn --topo tree,3,3 --controller remote,ip=10.128.30.11 --controller remote,ip=10.128.30.12 --controller remote,ip=10.128.30.13" note, you need a recent version of mininet to use the multiple --controller arguments.
        2. once the topology is started, issue "pingall" from the mn cli. The pings fail, but i think the important part is just that there is packets being sent. I am only able to reproduce this if I have traffic across my network as I bring up ONOS.
        3. 3 node ONOS cluster. I started this using the onos cell tools. ONOS_APPS=drivers,openflow,proxyarp,mobility

        There are missing links in ONOS.

        Show
        Jon Hall added a comment - I was able to reproduce it with the following setup: 1. tree 3,3 topology : "sudo mn --topo tree,3,3 --controller remote,ip=10.128.30.11 --controller remote,ip=10.128.30.12 --controller remote,ip=10.128.30.13" note, you need a recent version of mininet to use the multiple --controller arguments. 2. once the topology is started, issue "pingall" from the mn cli. The pings fail, but i think the important part is just that there is packets being sent. I am only able to reproduce this if I have traffic across my network as I bring up ONOS. 3. 3 node ONOS cluster. I started this using the onos cell tools. ONOS_APPS=drivers,openflow,proxyarp,mobility There are missing links in ONOS.
        Hide
        Jon Hall added a comment -

        Will verify this is still a bug

        Show
        Jon Hall added a comment - Will verify this is still a bug
        Hide
        Pier Luigi Ventre added a comment -

        Jon Hall, is this bug still valid ?

        Show
        Pier Luigi Ventre added a comment - Jon Hall , is this bug still valid ?

          People

          • Assignee:
            Jon Hall
            Reporter:
            Pingping Lin
          • Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Agile