A1: No. The reservation should be for those parts where you actually need to commit (bind) actual resources. You can either do that through advanced reservations (see sidebar) or the RLI will pop up a dialogue box that allows you to do it when you commit. But if the testbed is very busy, it is best to make an advanced reservation.
A2:
+ You can not log into an ONL host unless you have an ONL account. This means that you must have either registered for an account through the ONL Web page or you received a predefined login name as part of a course/tutorial (and an email).
+ You can only ssh into onl03.arl.wustl.edu from outside of the testbed.
+ You can only ssh into hosts other than onl03 that have been commited to you; i.e., wait for the experiment commit to finish first.
A3:
+ Are you pinging from the correct host; i.e., usually not onl03?
+ Are you pinging to the correct host?
+ Have you installed routes in both the forward and reverse directions? (The brute force method: 'Topology => Generate default routes' will generate default routes on all ports) (Note: This should not be necessary if you are using a predefined configuration file unless your instructor says that you need to define routes.)
A4: Yes, the RLI changes every once in a while. And it does complain if the version is old enough. We usually announce new versions to those using ONL as part of a course. The procedure for getting the RLI.jar file is the same as it has always been. You have two options:
1) Through HTTP: Click the "Get RLI.jar" link in the "Getting Started" page to download it from the Web. [[ If the resulting file is not the one above, then perhaps you need to flush your browser cache ... this should not be necessary unless you have a long lived www connection ]]
2) From onl03: The HTTP version is really obtained from onl03.arl.wustl.edu:~onl/export/RLI.jar. So, you can SSH into onl03 and copy it from ~onl/export/RLI.jar.
A5: Normally, this should not happen. But occassionally, an NSP or host can fail to properly initialize. If the NSP initialization fails, then close the experiment (File => Close) and try again. In rare cases when there are catastrophic hardware problems, all NSPs can end up in the repair state leaving no available NSPs. This situation can not be resolved until the staff fixes the underlying problem. If a single host or link fails, you can continue to use the NSP if you don't need that particular part of the setup. An email about the failure is sent to our staff, but the NSP is not placed in the repair state.
A6: The reservation is not considered to be in use until you commit. Do not ignore the message because indeed your reservation will be canceled because all reservations left unused for the first 30 minutes of the reservation period will be canceled. Some advice:
1) Make the beginning time of the reservation for when you think you will commit; and
2) Do a File => Commit even if you are not done with the network topology.
After the first commit, we assume that you have arrived for your reservation and we will not bother you anymore until near the end of the reservation period when you will get a warning message. But the RLI will pop up a dialogue box that asks if you want to extend your reservation period. If it is possible, the reservation will be extended. Even if the reservation is not extended, you can continue to work as long as no one else makes a reservation that will require your NSP.
A7: Nothing. Email is automatically sent to our staff, and someone will look into the problem. But since reservations are now overbooked, we have to look at the NSP, fix the problem and put it back into service before there are sufficient resources. Sometimes the problem can be quickly resolved, but it depends on the nature of the problem.
Last Update: Thu, Feb 2, 2006 (1210 PM)