1. 25 Mar, 2019 1 commit
  2. 22 Nov, 2017 1 commit
  3. 21 Nov, 2017 1 commit
  4. 12 Sep, 2017 1 commit
  5. 09 Aug, 2017 1 commit
    • Leigh Stoller's avatar
      Various changes to MLE support, related to issue #317: · 57def35b
      Leigh Stoller authored
      1. We now allow lans to be implemented by a path. We did not allow this
         before, cause some of the sanity checking code was a pain to
         implement for lans. Well, no more sanity checking, the user is
         responsible for doing things correctly (after all, they are doing
         experiments with their own switches!).
      
      2. We now allow topologies with more then one switch to be wired
         together. The wires between switches are marked as "trunk" wires,
         which informs the configuration generation code in libosload_switch
         to create the trunks and do the little tagged/untagged magic that is
         required on procurve switches. The same information is used to mark
         the the logical wires between switches as trunks.
      
         Aside: this stuff needs some work; we have spanning tree on by
         default, which causes the trunks to not work correctly. When I turn
         that off, things start working. So need some help from others who now
         about spanning tree stuff.
      
      3. Serious kludging in the Interface and Port libraries related to
         choice of primary keys in the wires table. In order to insert a
         logical wire (or interface) that represents a connection setup by the
         apcon, we have to overload the primary key since the node_id1 side of
         the logical wires is the same as the physical wire to the apcon. We
         have to have overload the node_id2 side too, but that is really just
         a problem when wiring two switches together. Anyway, the kludge just
         maps card1 to a different id, and the Port library unmaps it. It will
         do for now, but really need logical wires to be done better then
         this.
      57def35b
  6. 03 Oct, 2016 1 commit
  7. 03 Mar, 2016 1 commit
  8. 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
  9. 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
  10. 31 Aug, 2015 1 commit
  11. 25 Mar, 2015 1 commit
  12. 12 Feb, 2015 1 commit
  13. 24 Oct, 2014 1 commit
  14. 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
  15. 12 Mar, 2014 1 commit
  16. 04 Mar, 2014 1 commit
  17. 18 Dec, 2013 1 commit
  18. 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
  19. 27 Aug, 2013 1 commit
  20. 22 Aug, 2013 1 commit
  21. 20 Jun, 2013 1 commit
  22. 22 Mar, 2013 1 commit
  23. 04 Mar, 2013 1 commit
  24. 28 Feb, 2013 1 commit
  25. 19 Feb, 2013 2 commits
  26. 03 Jan, 2013 1 commit
  27. 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
  28. 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
  29. 31 Oct, 2012 1 commit
  30. 30 Oct, 2012 1 commit
  31. 24 Oct, 2012 1 commit
  32. 04 Oct, 2012 1 commit
  33. 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
  34. 04 Sep, 2012 1 commit
  35. 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
  36. 01 Aug, 2012 1 commit
  37. 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