1. 14 Jul, 2014 1 commit
  2. 05 Sep, 2013 1 commit
    • Leigh B Stoller's avatar
      Add option to check for and prune stale vlans from switch fabric. · 77f31539
      Leigh B Stoller authored
      Run as follows:
      
      boss> wap perl snmpit_test --prunestalevlans --impotent
      
      which will tell you about them. Remove the --impotent option to
      actually remove them.
      
      Only numbered lans are considered; ones that derive from entries in
      the lans table. Named vlans are skipped since those are generally
      created by hand (often via the switch CLI).
      
      Caveat; vlans left on trunk links are still a bit of problem since
      listvlans returns the other side of the trunk. Needs to be fixed.
      77f31539
  3. 16 Mar, 2013 1 commit
  4. 14 Mar, 2013 1 commit
  5. 13 Mar, 2013 1 commit
  6. 03 Jan, 2013 1 commit
  7. 16 Oct, 2012 1 commit
  8. 24 Sep, 2012 1 commit
    • Eric Eide's avatar
      Replace license symbols with {{{ }}}-enclosed license blocks. · 6df609a9
      Eric Eide authored
      This commit is intended to makes the license status of Emulab and
      ProtoGENI source files more clear.  It replaces license symbols like
      "EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
      blocks that contain actual license statements.
      
      This change was driven by the fact that today, most people acquire and
      track Emulab and ProtoGENI sources via git.
      
      Before the Emulab source code was kept in git, the Flux Research Group
      at the University of Utah would roll distributions by making tar
      files.  As part of that process, the Flux Group would replace the
      license symbols in the source files with actual license statements.
      
      When the Flux Group moved to git, people outside of the group started
      to see the source files with the "unexpanded" symbols.  This meant
      that people acquired source files without actual license statements in
      them.  All the relevant files had Utah *copyright* statements in them,
      but without the expanded *license* statements, the licensing status of
      the source files was unclear.
      
      This commit is intended to clear up that confusion.
      
      Most Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the Affero GNU General Public License, version 3
      (AGPLv3).
      
      Most Utah-copyrighted files related to ProtoGENI are distributed under
      the terms of the GENI Public License, which is a BSD-like open-source
      license.
      
      Some Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the GNU Lesser General Public License, version 2.1
      (LGPL).
      6df609a9
  9. 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
  10. 14 Aug, 2012 2 commits
  11. 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
  12. 01 Aug, 2012 1 commit
  13. 31 Jul, 2012 1 commit
  14. 18 Jul, 2012 1 commit
  15. 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
  16. 26 Jun, 2012 1 commit
  17. 13 Jun, 2012 1 commit
  18. 01 Feb, 2012 1 commit
  19. 28 Nov, 2011 1 commit
  20. 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
  21. 18 Jul, 2011 1 commit
  22. 20 May, 2011 1 commit
  23. 12 May, 2011 2 commits
  24. 11 May, 2011 1 commit
  25. 10 May, 2011 1 commit
  26. 07 May, 2011 1 commit
  27. 06 May, 2011 2 commits
  28. 04 May, 2011 2 commits
  29. 02 May, 2011 1 commit
  30. 27 Apr, 2011 1 commit
  31. 26 Apr, 2011 3 commits
  32. 25 Apr, 2011 1 commit
  33. 05 Apr, 2011 1 commit