1. 04 Sep, 2003 1 commit
    • Leigh B. Stoller's avatar
      Add variable netmask support to the parser. You can now do this in · 7d524fde
      Leigh B. Stoller authored
      your NS file:
      
      	tb-set-netmask $lan0  "255.255.240.0"
      	tb-set-netmask $link0 "255.255.255.248"
      	tb-set-netmask $link1 "255.255.255.240"
      
      Yep, more rope for the user to hang herself with. Notes:
      
      * You are restricted to 255.255.XXX.XXX. I did not see a reason to
        allow the user that much rope.
      
      * get_subnet can handle 10 or 192.168 addresses so that other sites
        can continue to operate without changing to 10 addresses, although
        they will still be able to change the netmask.
      
      * I've changed the handling for widearea networks to use 192.168, but
        I force the netmask to 255.255.255.248 so that we are not restricted
        to just 255 networks (not that it really matters). To avoid possible
        confusion, the user is not allowed to choose their own IPs for
        widearea networks, and I actually set them to 1.1.x.x, and then
        patch it up later. This is to avoid conflict with existing
        experiments where people may have used tb-set-ip in their NS files.
      
      * There are tmcd and staticroutes and image changes that are required
        to make this all work right!
      7d524fde
  2. 03 Sep, 2003 2 commits
    • Leigh B. Stoller's avatar
      Variable netmask changes (replace NETMASK constant with netmask field · b3d0140d
      Leigh B. Stoller authored
      from the virt_routes table for each lan). I had to add a hash to store
      that for each lan, as well as another has to map a node:port back to
      the lan so I could find the mask (this is needed in the code that adds
      host routes for all the interfaces of a dst, which requires knowing
      the mask. The mask has to carried along in the "packed" structures
      that Shashi is using to save space.
      
      Note, I have not changed the edgenode optimization code, which has a
      255.255.0.0 netmask wired in. The edgenode stuff is turned off, so I
      will wait until I hear from Shashi (and the new images are installed,
      which is required to make that work anyway).
      b3d0140d
    • Leigh B. Stoller's avatar
      3b2cadd2
  3. 02 Sep, 2003 3 commits
  4. 29 Aug, 2003 2 commits
  5. 27 Aug, 2003 7 commits
  6. 26 Aug, 2003 2 commits
  7. 25 Aug, 2003 4 commits
  8. 22 Aug, 2003 9 commits
  9. 19 Aug, 2003 2 commits
    • Austin Clements's avatar
      These are the dslice libraries from Planetlab's SF repository. They · 54d4f6dd
      Austin Clements authored
      are necessary to run the Planetlab manager.
      54d4f6dd
    • Austin Clements's avatar
      This is the Planetlab manager. It includes a combination dslice · e6ce08a1
      Austin Clements authored
      service manager and resource broker that works closely with the
      control flow through the Emulab experiment swap process.  It keeps all
      slice and node data in the DB.  Node allocation automatically unpacks
      and configures the node to come up as an Emulab/Plab node when it is
      booted (later, via vnode_setup).  It also takes care of other
      necessary bits of interfacing with Planetlab, including discovering
      which nodes are available, adding new Plab nodes to the DB, and
      maintaining status information on Plab nodes.
      e6ce08a1
  10. 18 Aug, 2003 2 commits
  11. 17 Aug, 2003 1 commit
    • Shashi Guruprasad's avatar
      > > >An optimization that would be nice, and perhaps this was intended to do this, · cd473380
      Shashi Guruprasad authored
      > > >is to collapse stuff like:
      > > >
      > > >         192.168.3          192.168.2.2        UGSc        0       12  veth6
      > > >         192.168.3.2        192.168.2.2        UGHS        0        9  veth6
      > > >         192.168.3.4        192.168.2.2        UGHS        0       12  veth6
      > > >
      > > >into the single net route.
      
      Found the problem. My code took care of the case where the net route was
      calculated first and if a host route came up for the same subnet with the
      same hop, it would skip adding the host route. However, if the host route
      were added first before the net route, it was a problem. To illustrate the
      problem, the host route to 3.2 is added on FG1 when the net route was
      calculated for node 'A' at 7.0 . At this point however, the net route for
      3.0 hasn't been defined yet coz that'll come later in the route to dst
      'AS1'. Experiment testbed/vroutetest.
      
      The solution is to consider adding host routes only after all net routes
      have been added to the DB. Changes to the code weren't trivial this time.
      Also, when adding host routes, I add the first one as a net route. If
      subsequent host routes have the same hop, they'll get skipped. Otherwise,
      a host route with a longer prefix will take precedence. With all these
      changes, the number of routes in testbed/vroutetest experiment came down
      from 361 (> NxN) to 162 (< NxN) where NxN is 289 . Mike, let me know if
      things are alright after rebooting vnodes in your experiment.
      cd473380
  12. 15 Aug, 2003 1 commit
    • Shashi Guruprasad's avatar
      I found the bug. In one path, the host route calculation was being · 93971eef
      Shashi Guruprasad authored
      skipped.
      
      ----------------
          if ($optimize) {
      	my $newip = inet_ntoa(inet_aton($dstip) & inet_aton($NETMASK));
      
      	if (defined($netroutes{"$src:$newip"})) {
      	    if ($netroutes{"$src:$newip"} ne $hop) {
      		die("*** $0:\n".
      		    "    network route mismatch: $src:$dst:$hop!\n");
      	    }
      	    next;
      ^^^^^^^^^^^^^^^^^^^^^^^^^^
      	}
      
      	$netroutes{"$src:$newip"} = $hop;
      	$type  = "net";
      	$dstip = $newip;
          }
      
      HOSTROUTES:
      ----------------
      
      If a NET route is already defined for a subnet because of a previous route
      (to a different dst on the same LAN), it would skip doing the HOSTROUTES.
      This problem wouldn't occur with links alone in the topology. Looks like
      it was never caught because no one probably tried pinging IPs of all
      interfaces while using LANs. Note that this problem wouldn't occur for
      directly connected neighbors (even if they are on a LAN). The latter is
      the reason why maryland folks didn't encounter this problem.
      
      The bottomline: We need Dave (West)'s automated testing tool!
      
      Fixed, committed and installed.
      
      Mike, I have fixed the routes in your experiment. Just reboot your
      nodes/vnodes.
      
      -Shashi
      
      On Fri, 15 Aug 2003, Mike Hibler wrote:
      
      > I've know we have been round and round this one, but it appears that
      > rtproto Static is not producing routes to all IP addrs listed in the
      > hosts file.  Again, it is nodes with multiple interfaces and we don't
      > have routes to the nodes on all of those interfaces.  I thought we came
      > up with some solution (or at least hack) for this?
      >
      > You can see this in the testbed/vroutetest experiment by logging into
      > say EGG1.vroutetest.testbed.emulab.net and trying to ping "F-3".
      > Note that this is a vnode so you'll have to slogin from ops or, better,
      > use the fine ssh-mime.pl thingee of Leigh's from the web page.
      >
      > Honestly, I tried going back to the mail archive to find last time this
      > came up, but I didn't find anything useful!
      >
      93971eef
  13. 14 Aug, 2003 1 commit
  14. 12 Aug, 2003 1 commit
  15. 11 Aug, 2003 2 commits