1. 15 Apr, 2010 1 commit
    • Weibin Sun's avatar
      getUsedOpenflowListenerPorts in snmpit stack modules and devices are changed... · 0e278b7e
      Weibin Sun authored
      getUsedOpenflowListenerPorts in snmpit stack modules and devices are changed to return the ports rather than accept a hash reference. Add the empty OF functions to snmpit_nortel.pm. Print the OF listener string on each involved device. Fix a bug that snmpit.in doesnot print Done when OF operations are finished. The lengths of OF usage lines are reduced to fit the 80-ch width window.
      0e278b7e
  2. 09 Apr, 2010 2 commits
  3. 05 Apr, 2010 1 commit
    • Weibin Sun's avatar
      Openflow OIDs can be used in snmpit_hp now, so the functions can act... · 06c2f12b
      Weibin Sun authored
      Openflow OIDs can be used in snmpit_hp now, so the functions can act correctly. Command line options configuration is changed to use only one vlanname for each OF command. The order of OF support checking and finding VLan is changed so that stack module will find vlan first, then check OF support. Thus there will not be an error msg for OF unsupported even if the vlan is not on the switch.
      06c2f12b
  4. 31 Mar, 2010 1 commit
  5. 15 Jun, 2005 1 commit
  6. 10 Nov, 2004 1 commit
  7. 22 Oct, 2003 1 commit
    • Robert Ricci's avatar
      Change the way the switch modules for snmpit get their configuration · c069a419
      Robert Ricci authored
      information. Rather than pass it all in, which was getting very
      cumbersome, and inconsistent between Cisco and Intel switches, the
      modules query the database themselves (via a new function in
      snmpit_lib.pm).
      
      Also in this commit are two new options for switch stacks - the
      ability to specify minimum and maximum VLAN number to use.
      c069a419
  8. 28 Apr, 2003 1 commit
  9. 12 Feb, 2003 1 commit
  10. 10 Jan, 2003 1 commit
  11. 07 Jul, 2002 1 commit
  12. 17 Jun, 2002 1 commit
    • Robert Ricci's avatar
      Made some functions that previously took only a single port or VLAN · 13381879
      Robert Ricci authored
      take more than one. This can increase efficiency, since, for example,
      we now only have to lock the VLAN edit buffer once when tearing down
      an experiment, instead of once per VLAN. There are still other
      functions (setVlanOnTrunks comes to mind) that could benefit from this
      treatment.
      
      These optimization have been made only for Ciscos - minimal changes
      necessary to keep Intel support working were made, but they will still
      have the same old slow behavior.
      13381879
  13. 23 Jan, 2002 1 commit
    • Robert Ricci's avatar
      Some minor API changes to increase effieciency for Intels. · 9bd1dded
      Robert Ricci authored
      First, the stack-level createVlan() function no longer takes as an
      argument a list of devices the VLAN exists on, since it looks like
      this will never be needed.
      
      In it's place, createVlan() now takes a list of ports, so that it can
      (if so desired) put the ports in the VLAN without a seperate lock and
      unlock.
      
      The snmpit_intel module now uses its 'nested locking' feature to avoid
      additional locking in these cases. Note though, that the way that this
      is done is not safe for multiple switches in a stack. If we ever have
      to support multiple Intels (looks doubtful), this will have to be
      removed, or locking will need to be moved a level up to
      snmpit_intel_stack . Yuck.
      
      For Intels, the removeVlan() function calls removePortsFromVlan()
      itself, again to save locking overhead. The Cisco behavior, however,
      is unchanged, as locking is not expensive, and this would be too
      messy.
      9bd1dded
  14. 17 Jan, 2002 1 commit
  15. 14 Jan, 2002 1 commit
    • Robert Ricci's avatar
      Intel support is now fully functional. This mostly invovled making the · 223fff16
      Robert Ricci authored
      snmpit_intel module conform to the same API as snmpit_cisco.
      
      Intels VLANs are now done per port rather than per MAC. This should give
      experimenters more flexibility on the experimental net, and is more consistent
      with the way that VLANs are done on other switches.
      
      snmpit_intel_stack will need to undergo minor work to support stacks of
      multiple switches.
      223fff16
  16. 07 Jan, 2002 1 commit
  17. 03 Jan, 2002 1 commit
  18. 28 Dec, 2001 1 commit
    • Robert Ricci's avatar
      Initial version of the stack-level abstraction for Intel switches. For not, · e30b66aa
      Robert Ricci authored
      it's mostly just a wrapper around snmpit_intel - this is because, when doing
      MAC-based VLANs, you never have to talk to more than one switch. When we switch
      to doing port-based VLANs with Intels (something we should do soon, but will
      take some experimenting), it will likely become a more full-fledged layer.
      
      Not at all debugged yet - won't be able to do that until we have the
      mini-testbed more funcitonal.
      e30b66aa