Download CHEETAH Host User`s Guide

A user guide for CHEETAH hosts
There are several Linux end hosts deployed at the CHEETAH network PoPs available for use by
researchers. Users are invited to obtain logins on these machines to test. We provide information
below in the form of a set of FAQs.
1. What can I do with a cheetah login?
A cheetah login allows users to log on to any of the cheetah hosts. Any two hosts can be
interconnected with a dedicated end-to-end GbEthernet circuit. It is useful to test applications,
middleware or transport protocol software that requires such a high-speed dedicated circuit.
Depending on your choice of hosts, you can create local-area or wide-area 1Gb/s dedicated
circuits. You have to be logged into one of the end hosts connected by the dedicated circuit.
On how to set up a circuit, see question below.
2. Where are these hosts located? How do I access them?
Hosts are currently located at the University of Virginia (UVa), North Carolina State
University (NCSU), Oak Ridge National Laboratories (ORNL, also a CHEETAH PoP), City
University of New York (CUNY), MCNC (a CHEETAH PoP), and Atlanta (a CHEETAH
PoP). These hosts have a primary 100Mbps Ethernet card that is connected to the Internet.
Use any SSH client software, such as SecureCRT, to login to these hosts via this primary
Ethernet card. Here is a list of hosts with the IP addresses of their primary NICs. In some
cases, the hosts have been assigned domain names. If a domain name is not available, use its
primary NIC IP address for the SecureCRT login.
Location
CHEETAH
Internet IP address
host name
(primary NIC)
UVa, Charlottesville, VA
mvstu6
128.143.67.213
NCSU, Raleigh, NC
wukong
128.109.45.180
wuneng
128.109.34.22
zelda4
198.124.42.17
zelda5
198.124.42.18
zelda1
130.207.252.131
zelda2
130.207.252.132
zelda3
130.207.252.133
ORNL, Oak Ridge, TN
SOX/SLR, Atlanta, GA
CUNY, New York, NY
3. Can I use telnet or some other login mechanism to log in to the CHEETAH hosts?
No, the only remote login mechanism supported is SSH. Please use SSH client software, such
as SecureCRT, to log in.
4. Once I log in to any one of these machines, how do I create a dedicated 1Gb/s Ethernet circuit
to another one of these CHEETAH hosts?
First, check if there is an existing circuit by
circuit-requestor status
It should return a “CHEETAH link available” message if there is no previously established
circuit.
Next, to set up a circuit, issue the command
circuit-requestor setup destination-host bandwidth (Mbps) [holding-time (minutes)]
where
y destination-host should be cheetah-host-name.cheetah-demo.com or the primary NIC IP
address of a cheetah host. See the table in the answer to question 2 for a list of cheetahhost-names. Note that circuit setup has to be initiated from one of the hosts on the circuit.
Third-party setup is not allowed, in other words, you cannot login to zelda1 and set up a
circuit from zelda2 to wuneng, for example.
y Bandwidth is the desired circuit bandwidth in Mbps.
y Optional holding-time is the desired circuit holding time in minutes. Default holdingtime and Max holding time are 10 minutes and 1 hour respectively. Default holdingtime will be used if a user does not explicitly provide the holding time. A user cannot ask
a holding time longer than Max holding time. When the holding time expires, the circuit
will be automatically released by circuit-requestor.
Upon a successful circuit setup, circuit-requestor will return a Session-id to the user to
uniquely identify the circuit. Session-id will be used later to release or renew the circuit.
Finally, to release the circuit, issue the command
circuit-requestor release session-id
where session-id must match the session-id returned by setup procedure.
5. What should I do if the circuit will expire, while my applications are still running over the
cheetah circuit?
Circuit-requestor will send the user who created the circuit a warning message one minute
earlier before the circuit expires. User can choose to either stop their applications or renew
the circuit with a new holding time.
To renew an existing circuit, issue the command
circuit-requestor renew session-id [new-holding-time (minutes)]
If no new-holding-time is provided, Default holding-time will be used to renew the circuit.
The same Max holding time limitation still applies.
6. How do I know whether circuit setup was successful?
Run the command
ping secondary-NIC-IP-address-of-cheetah-host
To find the IP address of the secondary NIC of cheetah hosts, see the table below.
CHEETAH
Cheetah network IP address
host name
(secondary NIC)
mvstu6
152.48.249.106
wukong
152.48.249.102
wuneng
152.48.249.103
zelda4
10.0.0.14
zelda5
10.0.0.15
zelda1
10.0.0.11
zelda2
10.0.0.12
zelda3
10.0.0.13
7. What are preliminary checks I should execute before requesting dedicated GbE circuits?
a. Type “echo $PATH”. Ensure that /usr/local/bin and /sbin are in your path. If not, add
these to .bash_profile in the PATH line.
b. Next type “ps aux | grep RSVPD” to ensure that the RSVPD daemon is running.
c. Next type “ps aux | grep cheetahd” to ensure that cheetahd daemon is running.
d. Next type “more /etc/resolv.conf” to check that the nameserver of this host has been
set to 128.143.67.213 (which is a CHEETAH host that runs our own DNS server for
the domain name cheetah-demo.org; this is an unregistered name). If this is not the
case, then you should use secondary NIC IP addresses to initiate circuit setup.
e. If any of these preliminary checks fail, send email to [email protected].
8. How do I check to see whether the DNS entry is correct for a CHEETAH host?
When logged in to any CHEETAH host, you can type the following command with the name
of another CHEETAH host to see whether the CHEETAH DNS server has a correct entry.
For example to see if zelda1 is on cheetah, type “host -t TXT zelda1.cheetah-demo.com” for
which you will see the response zelda1.cheetah-demo.com descriptive text "OCS-available"
"10.0.0.11" "00:11:95:C7:28:82". The “OCS-available” indicates that optical connectivity
service is available, i.e., that zelda1 is connected to cheetah and can be reached with a
dedicated GbE circuit.
9. How do I readily find the primary IP address of another CHEETAH end host while logged
into a CHEETAH end host?
An example: To find zelda1’s primary NIC’s IP address type “host zelda1.cheetahdemo.com” and the response provides the IP address. Replace zelda1 with the cheetah-hostname of the required CHEETAH end host. See the table in the answer to question 2 for a list
of cheetah-host-names.
10. How do I readily find the secondary IP address of another CHEETAH end host while logged
into a CHEETAH end host?
An example: To find zelda1’s primary NIC’s IP address type “host –t TXT zelda1.cheetahdemo.com” and the response provides the IP address. The response is zelda1.cheetahdemo.com descriptive text "OCS-available" "10.0.0.11" "00:11:95:C7:28:82". The 10.0.0.11
is the secondary IP address. Replace zelda1 with the cheetah-host-name of the required
CHEETAH end host. See the table in the answer to question 2 for a list of cheetah-hostnames.
11. What exactly happens when the circuit-requestor command is issued?
The circuit-requestor program communicates with the cheetahd daemon running on the end
host. The cheetahd first determines whether the called end host is connected to the
CHEETAH network by issuing a TXT resource record query to its DNS server. The DNS
server has been set on all CHEETAH hosts to be a name server that we are running at UVa
for demonstration purposes. For CHEETAH hosts, the TXT resource record returns an “OCS
available” indication along with the IP address and MAC address of the secondary NIC. After
the circuit is setup, these addresses are used to create entries in the IP routing table and ARP
table at the calling end host. These tables are updated at the called end host by the RSVP-TE
Path message carrying the IP and MAC address of the calling end host’s secondary NIC in
transparent user-specific parameters. See http://cheetah.cs.virginia.edu/documents/dcn/dcndesign.pdf for further details. The cheetahd daemon at the called end host communicates with
the RSVPD daemon running on the same end host. This causes an RSVP-TE Path message to
be generated to the control card of the SN16000 to which this host’s CHEETAH (secondary)
NIC is connected. The SN16000 card runs RSVP-TE. It parses the received Path message,
determines the next-hop switch through which to route the circuit, runs a simple-sum
connection admission control algorithm to check bandwidth availability on the interface
leading to the next-hop switch and provisions the switch fabric. It maps the GbE port to
which the calling end host is connected to a virtually concatenated 21-OC1 signal on an
OC192 interface if the called end host is located at another switch, or to another GbE port if
the called end host is located at the same switch. The I-NNI signaling between SN16000s
within the CHEETAH network is called Broadleaf. This is required only for EthernetSONET-Ethernet circuits. If a pure SONET circuit is created at an SN16000, then GMPLS
overlay model signaling can be used. The Broadleaf solution for the hybrid Ethernet-SONETEthernet circuit consists of 7 OC3 SONET circuits being set up from the egress SN16000 to
the ingress SN16000 within the CHEETAH network. A similar set of actions occur at the
next SN16000 if the call needs to be routed via a second switch. The RSVPD daemon running
at the called end host receives the Path message, alerts the cheetahd daemon about the
incoming call. The latter configures the IP routing table and ARP table at the called end host.
A Resv message is then sent from the called end host back to the SN16000 and through the
CHEETAH network to the calling end host. The successful setup of the circuit is then
announced to the calling user.
12. What is the CHEETAH network topology?
See http://cheetah.cs.virginia.edu/networks/networks.html for further details
Last updated: June 26, 2006
Contact: Malathi Veeraraghavan ([email protected]), Xuan Zheng, Xiuduan Fang.