1. 03 Mar, 2016 1 commit
  2. 29 Oct, 2015 1 commit
    • Kirk Webb's avatar
      Add support for OpenFlow to Force10 snmpit module. · 84c3cfb2
      Kirk Webb authored
      Adding this support required a change to the createVlan() API call,
      which is why this commit touches so many modules. Optional/supplementary
      arguments to createVlan() are now passed as a fourth hash reference
      argument.
      
      This supplementary hash is used to inform device modules that a vlan to
      be created is to be associated with an OpenFlow instance.  Only the
      snmpit_force10 makes use of this information at this time. FTOS requires
      that openflow-enabled vlans be declared as such at creation time. However,
      snmpit's default control flow creates vlans first, then associates them
      with OF instances (if requested).  This is why the supplementary argument
      (OF hint) to createVlan() is needed here.
      
      OpenFlow configuration actions must all be performed via the
      existing Expect-based CLI interface to FTOS. Yuck.
      84c3cfb2
  3. 22 Oct, 2015 2 commits
    • Kirk Webb's avatar
      Disable OpenFlow when removing stale vlans in SyncVlansFromTables() · fee57b6e
      Kirk Webb authored
      If OF is specified for a vlan, and the sync operation is going to
      remove it because it is stale, try to disable OF before removal.
      fee57b6e
    • Kirk Webb's avatar
      Rework how OpenFlow setup is handled on the front-end · cda9ed7a
      Kirk Webb authored
      Previously OF would be setup after vlan creation, but before checking to
      see if all switches in scope actually support it.  This would lead to
      failures where the vlan was created and logged in the DB, but snmpit
      failed to setup OF, and so exit with a failure.  This in turn causes
      swap-in to fail, and leaves stale state on the switches and in the DB.
      
      Now when OF is requested for a vlan in an experiment, we first check
      to see if it is supported, then proceed.  We error out early before
      any OF-enabled vlan is created.
      cda9ed7a
  4. 31 Aug, 2015 1 commit
  5. 25 Mar, 2015 1 commit
  6. 12 Feb, 2015 1 commit
  7. 24 Oct, 2014 1 commit
  8. 04 Jun, 2014 1 commit
    • Leigh Stoller's avatar
      Add --setvlanontrunks, --resetvlanontrunks, and --clearvlanontrunks. All of · eaebe4d2
      Leigh Stoller authored
      these do the obvious. Takes a list of lanids (not vlanids). So yesterday
      when I did the switchover from the 1Gb to the 10Gb link I did this:
      
        snmpit_test -i procurveA -i procurve1 --clearvlanontrunks 1225665 1270247 ...
      
      which removed the vlans from the trunk ports on procurve1 and procurveA.
      Then I changed the wires table, and then I did:
      
        snmpit_test -i procurveA -i procurve1 --setvlanontrunks 1225665 1270247 ...
      
      which added the vlans to the new trunk ports. Nifty.
      eaebe4d2
  9. 12 Mar, 2014 1 commit
  10. 04 Mar, 2014 1 commit
  11. 18 Dec, 2013 1 commit
  12. 05 Sep, 2013 1 commit
    • Leigh Stoller's avatar
      Add option to check for and prune stale vlans from switch fabric. · 77f31539
      Leigh 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
  13. 27 Aug, 2013 1 commit
  14. 22 Aug, 2013 1 commit
  15. 20 Jun, 2013 1 commit
  16. 22 Mar, 2013 1 commit
  17. 04 Mar, 2013 1 commit
  18. 28 Feb, 2013 1 commit
  19. 19 Feb, 2013 2 commits
  20. 03 Jan, 2013 1 commit
  21. 02 Jan, 2013 2 commits
    • Mike Hibler's avatar
      Make it work for elabinelab swapmod. · 3c2416f2
      Mike Hibler authored
      Apparently, on a swap modify, RemoteDeleteVlan gets called with an array
      of vlan names rather than vlan objects. Needed to fix a couple of places
      in the ELABINELAB path where this was not considered (the "regular" path
      does handle this case).
      
      While everything appears to work correctly now (i.e., inner DB state is
      correct, outer vlans are set up correctly on switch), someone who knows
      the code should double check this!
      3c2416f2
    • Leigh Stoller's avatar
      8b49625f
  22. 28 Nov, 2012 1 commit
    • Leigh Stoller's avatar
      Fix a bug I introduced a couple of months ago that was causing · b2322b88
      Leigh Stoller authored
      swapmod to leave behind vlans on the switch. As a side effect,
      add a "class" field to the vlans table so that we can determine if a
      stale vlan is a control or experimental vlan (since we now support
      building experimental vlans on the control stack, so the stack no
      longer tells us what kind of vlan it is).
      b2322b88
  23. 31 Oct, 2012 1 commit
  24. 30 Oct, 2012 1 commit
  25. 24 Oct, 2012 1 commit
  26. 04 Oct, 2012 1 commit
  27. 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
  28. 04 Sep, 2012 1 commit
  29. 27 Aug, 2012 1 commit
    • Leigh Stoller's avatar
      Add support for experimental networks on the control network. · df048b11
      Leigh 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
  30. 01 Aug, 2012 1 commit
  31. 11 Jul, 2012 1 commit
    • Leigh Stoller's avatar
      Bug fix for handling shared vlans and trunked ports. · 52143046
      Leigh 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
  32. 26 Jun, 2012 3 commits
  33. 25 Jun, 2012 1 commit
  34. 04 Jun, 2012 1 commit
  35. 30 Nov, 2011 1 commit