1. 30 Nov, 2011 4 commits
  2. 29 Nov, 2011 5 commits
    • Leigh B Stoller's avatar
    • Leigh B Stoller's avatar
      Fix bug that was causing reserved vlantags to be left behind, causing · 235db86c
      Leigh B Stoller authored
      snmmpit to fail at seemingly random times. Also add an update script
      to delete the stale tags.
    • David Johnson's avatar
      Support using Linux netem modules for delay and loss shaping. · 35f1deaa
      David Johnson authored
      ... instead of using our custom kernel modules.  I got tired of
      pulling our patches forward and adapting to the packet sched API
      changes in the kernel!  netem is more advanced than our stuff,
      anyway, and should do a fine job.
    • David Johnson's avatar
      Lots of changes: debug; macvlans; details below. · fdf97b51
      David Johnson authored
      I added debug options for each LVM and vzctl call; you can toggle it
      on by touching /vz/.lvmdebug, /vz.save/.lvmdebug, /.lvmdebug, and
      /vz/.vzdebug, /vz.save/.vzdebug, /.vzdebug.  I also added dates to
      debug timestamps for debugging longer-term shared node problems.
      I added support for using macvlan devices instead of openvz veths
      for experiment interfaces.  Basically, you can add macvlan devices
      atop any other ethernet device to "virtualize" it using fake mac
      addresses.  We use them like this: if the virtual link/lan needs to
      leave the vhost on a phys device or vlan device, we attach the macvlan
      devices to the appropriate real device.  If the virtlan is completely
      internal to the vhost, we create a dummy ethernet device and attach
      the macvlan devices to that.
      The difference between macvlan devices and veths is that macvlan
      devices are created only in the root context, and are moved into
      the container context when the vnodes boot.  There is no "root
      context" half -- the device is fully in the container's network
      namespace.  BUT, the underlying device is in the root network
      We use macvlans in "bridge" mode, so that when one macvlan device sends
      a packet, the device driver checks any other macvlan devices attached
      to the underlying physical, vlan, or dummy device, and delivers the packet
      accordingly.  The difference between this fake bridge and a real bridge
      is that the macvlan driver knows the mac of each attached interface,
      and does not have to do any learning whatsoever.  I haven't looked at
      the code, but it should be a very, very simple, fast, and zero-copy
      transmit from one macvlan device onto another.
      This is essentially the same as the planetlab shortbridge, but since
      I haven't looked at the code, I can't say that there aren't more
      opportunities to optimize.  Still, this should hopefully be faster
      than openvz veths.
      Oh, and I also added support for using Linux tc's netem modules
      for doing delay and loss shaping, instead of using our custom
      kernel modules.  I got tired of pulling our patches forward and
      adapting to the packet sched API changes in the kernel!  netem is
      more advanced than our stuff, anyway, and should do a fine job.
    • David Johnson's avatar
  3. 28 Nov, 2011 12 commits
  4. 21 Nov, 2011 6 commits
  5. 19 Nov, 2011 3 commits
  6. 17 Nov, 2011 5 commits
  7. 16 Nov, 2011 4 commits
  8. 15 Nov, 2011 1 commit
    • Mike Hibler's avatar
      Further overhaul of firewall code. NOTE: required bump of tmcd version to 34. · 6a26b246
      Mike Hibler authored
      Firewalls now work with nodes which require a subboss. Had to introduce new
      firewall rules which skipped around the checks that no packets to/from
      node control net IPs should pass through the firewall, if the IP in question
      belongs to a subboss (since subboss is on the node control network). It
      actually checks for all Emulab servers (boss, ops, fs or any subboss),
      so the code should work for an Emulab install which has a non-segmented
      control network in which all servers were in the same subnet as the nodes.
      In addition to the new rules, we also had to pass in additional information
      via "tmcc firewallinfo" giving the IP/MAC of those server nodes that are on
      the node control network. We use this to establish ARP entries on the
      inside network so that nodes can find the servers. Since the existing
      client-side firewall code in libsetup.pm would blow up if it got a line
      that it didn't recognize, I had to bump the tmcd version number and add
      some conditional code to tmcd.c:dofwinfo() to not return the extra info for
      old versions.
      Added a couple of new firewall variables EMULAB_BOSSES and EMULAB_SERVERS
      that are used in the new rules. Fixed the support scripts in firewall/
      to properly initialize these variables.
      IMPORTANT: tmcd looks up boss, ops, fs, and subbosses in the interfaces
      table to find their IPs and MAC addresses. By default, we do not create
      such interface table entries for boss/ops/fs. We have them at Utah for
      other reasons. These entries are only needed if you have a non-segmented
      control network (or a subboss) and you want to firewall such nodes.
      The script to initialize the firewall variables (initfwvars.pl) will
      print out a warning for configurations that are affected and don't have
      the entries.