1. 27 Aug, 2012 2 commits
    • Mike Hibler's avatar
      Fix an obvious typo. · 8f29b66c
      Mike Hibler authored
      8f29b66c
    • Leigh B Stoller's avatar
      Add support for experimental networks on the control network. · df048b11
      Leigh B Stoller authored
      So what if your testbed has a control network but no experimental
      network? In the past you were SOL, but with this commit you can now
      create links and lans on the control network that look just like
      an experimental network link/lan.
      
      To make this work, ptopgen sports a new option (-C) that will put the
      control network links and wires and switches into the ptop file.
      
      libvtop generally operates as normal, but need to arrange for the
      physical ports to be put into dual tag/trunk mode, where the native
      vlan is the Control network. This is done with by setting attributes
      on the lan table entry that indicate dual and what to use for the
      native vlan. snmpit looks for these attributes.
      
      There are a couple of places that use the stack name (Control or
      Experiment) to determine if a vlan is control or experimental. This is
      not longer truu, and so need to use an attribute in the lan table
      entry. 
      
      The last bit of the puzzle is that snmpit has to be careful when
      disabling trunking on these ports. When this happens, all vlans are
      cleard from the ports (by the device layer), including the Control
      network itself, which would make the node unreachable. I had to add
      some special cases to watch for that, and return the ports to the
      control network.
      
      To turn this on, create a ControlNetVlans and enable it. The mapper
      looks for this and passes the -C argument to ptopgen.
      
      Nothing special in the NS file, except you have to turn on vlan
      encapsulation; tb-set-vlan-emulation vlan
      
      No delay nodes, but linkdelays work okay. Works for openvz containers
      as well.
      df048b11
  2. 14 Aug, 2012 1 commit
  3. 08 Aug, 2012 1 commit
    • Leigh B Stoller's avatar
      Bug Fix: Fix how we determine the set of ports to tag/untag. · ad8ed130
      Leigh B Stoller authored
      The basic problem is that when snmpit looks to see what ports it
      should trunk (or untrunk) the equation is more complicated then it
      used to be.
      
      Case 1: In the old days, before shared nodes and shared lans, a node
      and its interfaces were always one-to-one with an experiment. So the
      set of trunks was easily derivable from the reserved table joined with
      the interfaces table.
      
      Case 2: But when we added shared nodes (with vlan encap of course),
      the set of trunk ports is no longer associated with the experiments
      using those ports, but only with the underlying experiment. That is we
      do not mess with the trunking when swapping experiments on shared
      nodes, we only want to add and subtract vlans to those trunked
      ports. So, I added a check against the reserved table. Easy. The ports
      are trunked when the underlying "shared nodes" experiment is swapped
      in, and untrunked when it is swapped out.
      
      Case 3: Then we added shared vlans. Well this is almost the exact
      opposite case. The ports belong to nodes in other experiments, but now
      we *do* want to consider them when turning trunking on and off. The
      underlying experiment that owns the lan (emulab-ops,openflow-vlans)
      does not own any of the ports, but we do want to enable/disable the
      trunking as ports come and go.
      
      Case 4: Last but certainly not least, is a potential bad interaction
      between these #2 and #3! The instageni-connect port is a member of the
      1750 shared vlan (and thus trunking is enabled when the openflow lan
      is created or modified). But that same port is also used in the second
      case above when stitching to the rack; The instageni-connect node is a
      shared node, and we allocate fake VMs on it that serve simply as a
      place to associate the vlans that use that port; we just want to add
      and subtract vlans to the port. ÊThe gist of this is that if someone
      were to remove the port from the shared 1750 vlan, its trunk would get
      turned off, and all of the stitched vlans would stop working.
      
      This bug fix deals with the addition of #3, but I do not have anything
      for #4.  But I can commit this fix with the understanding that
      #4 is a real problem that has to be dealt with.
      ad8ed130
  4. 01 Aug, 2012 1 commit
  5. 31 Jul, 2012 1 commit
  6. 18 Jul, 2012 1 commit
  7. 11 Jul, 2012 1 commit
    • Leigh B Stoller's avatar
      Bug fix for handling shared vlans and trunked ports. · 52143046
      Leigh B Stoller authored
      The code to determine what ports need to be trunked or untrunked was
      blindly picking all ports for the experiment, instead of restricting
      them to those in the vlans being operated on. The result was a missing
      device from the stack.
      52143046
  8. 26 Jun, 2012 1 commit
  9. 13 Jun, 2012 1 commit
  10. 01 Feb, 2012 1 commit
  11. 28 Nov, 2011 1 commit
  12. 07 Oct, 2011 1 commit
    • Leigh B Stoller's avatar
      We now save the switch path that assign computes, into the DB. We then · f61a6288
      Leigh B Stoller authored
      use this path when setting up the vlan, instead of recomputing the set
      of trunks that are need. Assign does a much better job of this, so
      throwing the info away is bad.
      
      But, if there is no switch path, we still have to be careful cause the
      switch infrastructure might have loops, and the existing algorithm did
      not take that into account. And in fact, Utah has loops and this was
      causing grief. I added a simple spanning tree function (Prim's Greedy)
      to calculate a loop free set of trunks.
      
      An added complication is if the vlans are modified on the command
      line, and the there is a switch path in the DB. In this case we have
      to throw that away, and revert to dumb loop free calculation.
      
      Note that we also have to store the switch path in the vlans table,
      since for swapmod/synctables, we need to know how to undo stale vlans
      (which are no longer in the lans table).
      f61a6288
  13. 18 Jul, 2011 1 commit
  14. 20 May, 2011 1 commit
  15. 12 May, 2011 2 commits
  16. 11 May, 2011 1 commit
  17. 10 May, 2011 1 commit
  18. 07 May, 2011 1 commit
  19. 06 May, 2011 2 commits
  20. 04 May, 2011 2 commits
  21. 02 May, 2011 1 commit
  22. 27 Apr, 2011 1 commit
  23. 26 Apr, 2011 3 commits
  24. 25 Apr, 2011 1 commit
  25. 05 Apr, 2011 1 commit
  26. 31 Mar, 2011 1 commit
  27. 29 Mar, 2011 1 commit
  28. 28 Mar, 2011 1 commit
  29. 16 Mar, 2011 1 commit
  30. 09 Mar, 2011 2 commits
  31. 08 Mar, 2011 3 commits