Network Experiment

This is the primary configuration for the X-Bone. In particular, to do a network experiment, each site must be configured with the following information:

1. Each RD must list all participating OMs as allowed

2. Each RD must list all usernames (from X.509 user certificates) that are allowed

How are the hosts and routers named?

Both hosts and routers retain their original base name (goo.isi.edu's would be 'goo'), and acquire the suffix of the overlay name followed by the X-Bone shared suffix. If your X-Bone is configured as "xbone.univ.edu', and you've deployed an overlay called 'boom', then that host would be known as "goo.boom.xbone.univ.edu'.

The X-Bone provides tools to make selecting an overlay and referring to hosts and routers in an overlay easier. In particular, xb-pick allows you to set the default DNS suffix in a window or for a process. In the above example, you'd set xb-pick to select the 'boom' overlay, and it would set the process's suffix to 'boom.xbone.univ.edu'. Then, inside that window, 'goo' would refer to goo.boom.xbone.univ.edu, as expected.

How do I "keep the streams from crossing" (isolate experiments)?

That depends on what you want to experiment with. The X-Bone already keeps IP traffic on different overlays separated. However, there are cases where more strict separation is required. There are three basic options:

• If you want SECURITY

Use IPSEC'd overlays. IPSEC prevents outside traffic from being accepted (spoofed source) into an overlay, and prevents intermediate hops on a tunnel from accessing the data inside packets.

• If you want to do PERFORMANCE EXPERIMENTS

Set each component (router and host) to participate in ONE overlay at a time (in /etc/xbone/Xbone_daemon.conf set the variable MaxOverlayCount of the XboneNode to 1). Put all components on a switch that has 'full switching capacity' (i.e., can handle full bandwidth between any two nodes at a time). Make sure this is a switch, not a bridge. If you plan to do multicast experiments, make sure the switch 'speaks' IGMP.

• If you want to do CONCURRENT TESTS OF DIFFERENT CONFIGURATIONS

Currently, the X-Bone understands only configurations that have been 'wired' into the code, indicating the operating system (FreeBSD, Linux, Solaris) and the security patches (KAME, NIST). However, it can be useful to be able to select a subset of machines based on some other property, such as "has a new TTCP protocol" or "speaks RSVPv2". In those cases, another way to indicate which machines are required is needed.

The best way to emulate configurations created by users is via configuration of the ACL. Create additional X.509 certificates whose 'user' name matches the configuration needed, and configure the ACLs in /etc/xbone/Xbone_daemon.conf to allow access only to users whose certificates match. E.g., each user asks for a certificate with a set of suffixes. e.g., '-TTCP', '-RSVPv2', etc. User 'joe' would have certificates:

1. joe-TTCP

2. joe-RSVPv2

When user 'joe' wants to do a TTCP experiment, he uses his joe-TTCP certificate. Only nodes configured to allow joe-TTCP would respond to invitations.

• If you want to have MULTIPLE GROUPS OF STUDENTS doing experiments

This too is solved with ACLs. Each group of students deploys RDs with ACLs that allow only their group members. A SINGLE OM suffices.
(Read more on access control lists.)

Teaching networking lab classes

The X-Bone can also be used for teaching networking classes, especially for networking labs.

• How do I keep the student experiments separate?

See above, under "keeping the streams from crossing".

• Where can I get help if needed?

Contact the X-Bone group directly. We are particularly interested in having it used for lab classes, and would be glad to see how we can help you.

VPN deployment

Basically, deploy an overlay with IPSEC and use your applications as usual, using the overlay names of the endpoints.