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.