Changes between Version 19 and Version 20 of FeddUsersGuide

Timestamp:

Jun 10, 2014 10:52:44 AM (10 years ago)

Author:

faber

Comment:

--

FeddUsersGuide

@@ -344 +344 @@
 Download the VM image above and import it into a VMM.  If using [http://virtualbox.org virtualbox], the directions are [http://grok.lsu.edu/article.aspx?articleid=13838 here].  In addition, you will need to forward external connections on port 23231 into the virtual machine.  Instructions for this are [https://www.virtualbox.org/manual/ch06.html#natforward here].
 
+Most VMMs, including virtualbox, configure the guest VM to be assigned [http://en.wikipedia.org/wiki/Private_network IP addresses on a private network]. These addresses cannot be routed in the public Internet, so the VMM translates those addresses using a [http://en.wikipedia.org/wiki/NAT Network Address Translator (NAT)].  This is a common configuration for home networks as well.
+
+Similarly, by default DETERLab assigns experimental nodes the same sort of private addresses. In particular, interfaces visible as part of the federated experiment are drawn from the 10.0.0.0/8 address space and interfaces used access and provide services to the computers in DETERLab are drawn from the 192.168.0.0/16 address space.  
+
+Unfortunately virtualbox uses the 10.0.0.0/8 address space for VMs, which can confuse the routing in DETERlab.  Assign the single interface in the VM an address in the 192.168.0.0/16 address space rather than the 10.0.0.0/24 space.  Directions are [https://www.virtualbox.org/manual/ch09.html#idp59863744 here] to do that in virtualbox. In particular, we recommend using the 192.168.233.0/24 address space to avoid conflicts:
+
+{{{
+$ VBoxManage modifyvm "VM name" --natnet1 "192.168.233/24"
+}}}
+
+
 Start the VM and log into it.  The account on the VM is fedd and the password is fedd.  Do not allow remote logins to this VM unless you change the account's password.
 
@@ -370 +381 @@
 There are some detailed debugging messages that libraries and other dependent software produce that are visible with {{{--debug}}} that are lost during normal logging.
 
-=== Creating the experiment on DETER ===
+=== Creating the Federated Experiment ===
 
 To connect the desktop to a DETER experiment, specify an federated experiment with the desktop as being on testbed "desktop".  Here is an example DETER experiment description of that format:
@@ -417 +428 @@
 }}}
 
-where {{{$EXPNAME}}} is replaced with a short mnemonic name for the combined experiment and {{{$MGMT_IP}}} is the IP address of the node running the federation software.  You can use its DNS name as well.
+where {{{$EXPNAME}}} is replaced with a short mnemonic name for the combined experiment (the example below assumes we used {{{faber-smart5}}}) and {{{$MGMT_IP}}} is the IP address of the node running the federation software.  You can use its DNS name as well.
 
 When that returns, it will return something like:
@@ -485 +496 @@
 If an experimenter tears down the desktop VM before the {{{fedd_terminate.py}}} command is issued, or there is some other problem, the {{{--force}}} flag can be given to make {{{fedd_terminate.py}}} purge all state that the federation system can reach.
 
-== A More Complex Desktop Topology ==
-
-To connect a more complex ExoGENI topology, we look at routing from a two-node ExoGENI world into the same DETER topology.  The ExoGENI topology looks like this:
-
-[[Image(ExoGENI.png)]]
-
-Node0 is running the fedd and will be accessible as before at hostname "b".  In addition we will make Node1 accessible throughout the DETER topology by its IP address.
-
-When we create the ExoGENI topology we use the AutoIP feature of [https://geni-orca.renci.org/trac/wiki/flukes Flukes] to assign addresses.  By default Flukes puts the addresses on the 172.16.0.0/30 subnet.  We move those addresses to the 10.16.0.0/24 subnet by editing the nodes' properties.  DETER uses the 10.0.0.0/8 network block for experiment interfaces.  It uses the 172.16.0.0/30 net for addressing [http://containers.deterlab.net containers] management interfaces.
-
-When the slice is ready, log in to Node0 and run the {{{init_fedd}}} utility as before.  In addition, add the following lines to {{{/usr/local/etc/fedd/desktop.config}}}:
+== A More Complex Desktop Layout ==
+
+To connect a more complex topology, we route TCP connections from the DETER experiment through the desktop VM to the local network.  This example uses the ISI subnet, 128.9.0.0/16.
+
+
+The desktop is running the VM running fedd and that VM will be accessible as before at hostname "b".  In addition we will make the rest of the subnet accessible throughout the DETER topology by its IP addresses.
+
+
+Log in to the VM and run the {{{init_fedd}}} utility as before.  In addition, add the following lines to {{{/usr/local/etc/fedd/desktop.config}}}:
 
 {{{
 # Export Interfaces (interfaces to run OSPF on/export to DETER).
 # Comma-separated list of interface names
-export_interfaces: eth1
+export_interfaces: eth0
 
 # Export Networks (networks to export to OSPF - these usually correspond 
 # to export_interfaces).  Comma separated
-export_networks: 10.16.0.0/24
-}}}
-
-With those settings, {{{fedd.py}}} will export any routes discovered on {{{eth1}}} and network 10.16.0.0/24 to the ospfd running in DETER.
-
-The simplest way to export a complex ExoGENI topology is to just run ospfd inside the ExoGENI topology.  With these settings, the combined experiment will be able to route throughout the experiment as soon as routing converges.  For this simple topology to work, we log in to Noed1 in exoGENI and add a route to all the DETER nodes through Node0:
-
-{{{
-# ip route add 10.0.0.0/16 via 10.16.0.1
-}}}
-
-Start up fedd.py on Node0 as before and run the same {{{fedd_create.py}}} command on DETER.
-
-In addition to being able to contact Node0 directly, nodes in the DETER experiment now see a route to the 10.16.0.0/24 network:
+export_networks: 128.9.0.0/16
+}}}
+
+With those settings, {{{fedd.py}}} will export any routes discovered on {{{eth0}}} and network 128.9.0.0/16 to the ospfd running in DETER.  Routes to other places will not be exported, nor would routes on other interfaces. (The VM has only the eth0 interface, so the second part is sort of moot.)
+
+Now we need to construct a route to the network we want to export.  This route will be given to the [http://www.nongnu.org/quagga/docs/docs-info.html quagga routing system] and distributed throughout the experiment.  To construct it, we must know the default router for the VM.  To discover it, use the command:
+
+{{{
+$ ip route
+default via 192.168.233.2 dev eth0  proto static 
+[ ... ]
+}}}
+
+That will produce many lines of output, but the important one is the default route line.  If you have constructed a more complex routing layout, you will need to choose the appropriate router, but that is beyond the scope of this example.
+
+Edit {{{/usr/local/etc/fedd/external_networks}}} and put the following line in:
+
+{{{
+ip route 128.9.0.0/16 192.168.233.2
+}}}
+
+This is a route command to the [http://www.nongnu.org/quagga/docs/docs-info.html#Zebra quagga routing system] explaining that the route to the network we want to export into the federated experiment (128.9.0.0./16) can be reached via the default router of the VM (192.168.233.2).  When the federation system builds an experiment, it issues those commands directly.
+
+Start up fedd.py on the desktop VM as before and run the same {{{fedd_create.py}}} command on DETER.
+
+In addition to being able to contact the desktop VM directly, nodes in the DETER experiment now see a route to the 128.9.0.0/16 network:
 
 {{{
 a:~$ ip route
-default via 192.168.1.254 dev eth4 
-10.0.0.0/24 dev eth2  proto kernel  scope link  src 10.0.0.2 
+default via 192.168.1.254 dev eth0 
+10.0.0.0/24 dev eth3  proto kernel  scope link  src 10.0.0.2 
 10.0.1.0/24 via 10.0.4.2 dev eth1  proto zebra  metric 20 
 10.0.2.0/24 via 10.0.4.2 dev eth1  proto zebra  metric 20 
-10.0.3.0/24 dev eth0  proto kernel  scope link  src 10.0.3.1 
+10.0.3.0/24 dev eth4  proto kernel  scope link  src 10.0.3.1 
 10.0.4.0/24 dev eth1  proto kernel  scope link  src 10.0.4.1 
-10.16.0.0/24 via 10.0.3.2 dev eth0  proto zebra  metric 20 
-192.168.0.0/22 dev eth4  proto kernel  scope link  src 192.168.1.188 
-192.168.252.0/22 via 192.168.1.254 dev eth4  proto zebra 
-}}}
-
-That route reaches Node1:
-
-{{{
-a:~$ ping 10.16.0.2
-PING 10.16.0.2 (10.16.0.2) 56(84) bytes of data.
-64 bytes from 10.16.0.2: icmp_req=1 ttl=63 time=139 ms
-64 bytes from 10.16.0.2: icmp_req=2 ttl=63 time=69.9 ms
-64 bytes from 10.16.0.2: icmp_req=3 ttl=63 time=69.4 ms
-}}}
-
-While some attention needs to be paid to routing if routing protocols are not run in ExoGENI, this facility allows a wide range of connectivity between the testbeds.
+128.9.0.0/16 via 10.0.3.2 dev eth4  proto zebra  metric 20 
+192.168.0.0/22 dev eth0  proto kernel  scope link  src 192.168.0.81 
+192.168.252.0/22 via 192.168.1.254 dev eth0  proto zebra 
+}}}
+
+We can collect the ISI home page from the 128.9.0.0/16 network:
+
+{{{
+a:~$ wget www.isi.edu
+--2014-06-10 10:42:34--  http://www.isi.edu/
+Resolving www.isi.edu (www.isi.edu)... 128.9.176.20
+Connecting to www.isi.edu (www.isi.edu)|128.9.176.20|:80... connected.
+HTTP request sent, awaiting response... 302 Found
+Location: http://www.isi.edu/home [following]
+--2014-06-10 10:42:34--  http://www.isi.edu/home
+Reusing existing connection to www.isi.edu:80.
+HTTP request sent, awaiting response... 200 OK
+Cookie coming from www.isi.edu attempted to set domain to www.isi.edu
+Length: unspecified [text/html]
+Saving to: `index.html'
+
+    [ <=>                                   ] 12,294      --.-K/s   in 0.1s    
+
+2014-06-10 10:42:34 (80.7 KB/s) - `index.html' saved [12294]
+}}}
+
+This also works from nodes deeper in the layout, e.g, node "f":
+
+{{{
+f:~$ ip route
+default via 192.168.1.254 dev eth0 
+10.0.0.0/24 via 10.0.2.2 dev eth4  proto zebra  metric 30 
+10.0.1.0/24 via 10.0.2.2 dev eth4  proto zebra  metric 20 
+10.0.2.0/24 dev eth4  proto kernel  scope link  src 10.0.2.1 
+10.0.3.0/24 via 10.0.2.2 dev eth4  proto zebra  metric 30 
+10.0.4.0/24 via 10.0.2.2 dev eth4  proto zebra  metric 20 
+128.9.0.0/16 via 10.0.2.2 dev eth4  proto zebra  metric 20 
+192.168.0.0/22 dev eth0  proto kernel  scope link  src 192.168.0.87 
+192.168.252.0/22 via 192.168.1.254 dev eth0  proto zebra 
+f:~$ wget www.isi.edu
+--2014-06-10 10:44:07--  http://www.isi.edu/
+Resolving www.isi.edu (www.isi.edu)... 128.9.176.20
+Connecting to www.isi.edu (www.isi.edu)|128.9.176.20|:80... connected.
+HTTP request sent, awaiting response... 302 Found
+Location: http://www.isi.edu/home [following]
+--2014-06-10 10:44:07--  http://www.isi.edu/home
+Reusing existing connection to www.isi.edu:80.
+HTTP request sent, awaiting response... 200 OK
+Cookie coming from www.isi.edu attempted to set domain to www.isi.edu
+Length: unspecified [text/html]
+Saving to: `index.html'
+
+    [ <=>                                   ] 12,344      --.-K/s   in 0.09s   
+
+2014-06-10 10:44:07 (128 KB/s) - `index.html' saved [12344]
+}}}
+
+This configuration allows all th enodes in the federated experiment to make outgoing TCP connections into 128.9.0.0/16.  There are actually 2 NATs manipulating packets:
+