Please review these FAQs and documentation before contacting technical support.
The leading causes are:
Modern browsers and firewall software allow you to enable these features for an individual site; in this case, the NETLAB+ server address.
Please refer to the requirements page.
A Remote Access Test is performed during each user login. The purpose of the test is to attempt to establish an outbound TCP connection. This connection is necessary for remote device access, and remote PC access and access to chat functions.
This test will fail if a connection using the TCP port(s) defined by the NETLAB+ administrator cannot be established. There are several reasons why the Remote Access Test may fail:
The port test uses Java, as do other components in NETLAB+. It is likely that the timeout within NETLAB+ is related to the Java plug-in. The latest version of Java must be installed and properly configured within your web browser.
Installing the latest version of Java on your machine does not always ensure that it gets properly configured to work in your browser. You can confirm you are running the latest version of Java and that Java is properly configured within your browser by using Sun’s test program.
Examine the results of the test. If the Dancing Duke (as shown in the picture below) animation is not dancing, the latest version of Java is not properly configured within your browser and NETLAB+ will not function.
NETLAB+ uses HTML inline frames. You will receive this error if your personal firewall/security software blocks IFRAMES, or your browser has disabled them.
Please refer to the IFRAMES help page.
If you have a Windows PC, remove your "Start Navigation" sound.
If you are able to access the NETLAB+ server with a web browser, but cannot make a connection to a lab device or PC, a firewall is probably blocking the remote access port. The remote access port must be "open" between your workstation and the NETLAB+ server. The default remote access port is now 2201 (existing systems prior to 2009.R1.beta.2 have a default of 23) The remote access port may be reassigned to a new port or list of port numbers (supported in NETLAB+ software versions 2009.R1 or later). Please see the NETLAB+ Installation Guide for details
Examine the NETLAB+ system log file.
If you see the message #1, but not message #2, NETLAB+ is not seeing the corresponding remote access port connection following the request to connect. The following conditions may cause this:
Possible hardware issues should be referred to the local NETLAB+ system administrator.
Please refer cabling issues to your local NETLAB+ administrator.
Choose one of the following options in your NETLAB+ user profile:
To use a specific Telnet application loaded on a Windows PC, follow these steps and refer to the picture below:
rundll32.exe url.dll,TelnetProtocolHandler %1
HyperTerminal:"C:\PROGRAM FILES\ACCESSORIES\HYPERTERMINAL\HYPERTRM.EXE" /t %1
Note: HyperTerminal will not allow multiple windows to be opened, whereas the default client will. Therefore, the default Windows client is preferred.
NETLAB+ provides a built-in client to connect to PCs in topologies that support them.
Microsoft has not publicly licensed or published the protocol specifications needed to support these remote access technologies.
If your machine or client has hung, the NETLAB+ server may not have received an indication that the client side of a connection has closed. You can force your connections to be dropped using either of these two methods:
Check out the flow chart.
There are currently two ways to load configs without typing them in the routers:
NETLAB+ allows different router types in each equipment pod. When a configuration is saved on one pod, then loaded onto another pod, it is possible that the source router interface names (e.g. Ethernet0, Serial0) are different than the destination router (e.g. FastEthernet0/0, Serial0/0). This situation would normally be handled by manually editing the interface names before loading the configurations on the destination routers. To avoid this time consuming task, NETLAB+ automatically performs this translation if:
To determine the configured router types, click on the "Status" tab during a lab session. To determine the actual router types, use the IOS show version command. If these do not match, the NETLAB+ administrator should correct this using the pod management interface.
Instructors can use the archive feature (MyNETLAB > Archive) to rapidly assess how a student or team arrived at a solution. NETLAB+ records the commands issued on all routers, switches, and firewalls. All activity is analyzed and sorted into a "who", "what", "when" and "where" table format. Each entry is hyperlinked so that output of each command can be easily viewed. Configuration files and device output are also saved with each lab session. The instructor may view this data online, or receive it automatically by e-mail.
Instructors can cancel future reservations or reservations in progress. Currently, instructors who seek immediate access can "bump" someone else off the pod. This feature will be partially limited in a future version. If possible, you should ask the user to terminate his reservation gracefully by having them click the "I'm Done" button on the Lab Access page. This will cause configuration files to be saved, log files to be retained, and the pod to be scrubbed. Any unused 30 minute blocks will be returned to the scheduler after cleanup tasks are completed.
Students can delete future reservations or reservation in progress, as long as they scheduled the lab event. Students cannot delete reservations made by other users.
At this time, you must delete the reservation and make a new one.
No. NETLAB+ is a turn-key server appliance that integrates NDG custom software and over 200 other software packages. The device drivers are specific to the hardware platform.
NDG has worked with Cisco to provide support for the majority of the labs in the CCNA Discovery curriculum. Support for CCNA Discovery was implemented in NETLAB+ version 4.0.25. NETLAB+ supports 22 of the 29 labs included in the CCNA Discovery 2: Working at a Small to Medium Business or ISP course. Please refer to CCNA Discovery 2: Working at a Small to Medium Business or ISP for details on supported lab exercises. NETLAB+ supports 44 of the 48 labs included in the CCNA Discovery 3: Introducing Routing and Switching in the Enterprise course. Please refer to CCNA Discovery 3: Introducing Routing and Switching in the Enterprise for details on supported lab exercises. NETLAB+ supports 29 of the 36 equipment-based labs included in the CCNA Discovery 4: Designing and Supporting Computer Networks course. Please refer to CCNA Discovery 4: Designing and Supporting Computer Networks for details on supported lab exercises.
NDG has worked closely with the Cisco CCNA Security lab team to develop the labs Please see the CCNA Security labs page for details.
Most of the issues that have been reported with SDM have been due to the Java plug-in. Another problem has been reported regarding IE browser security. You must enable "Allow programs to run active content off my Computer" from the Advanced tab.
NDG hosts a demo MAP topology in which the VMs are running Java 1.6.0_01-b06 (Runtime Environment 6, Update 6). We recommend that you do not install any version higher than Update 7 (to be safe). Update 7 seems to be the last safe version.
You may refer to the following links for additional information:
Please review the lab equipment requirements for guidance on selecting courses, topologies, and equipment for your system.
You may find it helpful to bookmark these pages for reference as you choose your lab equipment, install and administer your NETLAB+ system:
Here is an example diagram of how a typical system may be racked. This example contains three (3) Multi-Purpose Academy Pod (MAP) pods and one (1) Network Fundamentals Pod (NFP).
This example shows one of many ways the gear may be racked. There are other ways to rack the gear, as it is a matter of preference. Your setup will vary, depending on the number of control and lab devices you have available.
NETLAB+ integrates with 3rd party virtualization products to provide powerful and cost effective PC support for lab topologies. Our Remote PC Support page includes details and links to pages where downloads of VMware vistualization software are available.
Please refer also to the Remote PC Guide for VMware Implementation Using ESXi versions 4.01 and 4.1 with vCenter
Thank you for your interest in using NETLAB+ to teach the CCNP 6.0 curriculum. Please be assured that NDG recognizes the importance of supporting this curriculum. Beta support of CCNP TSHOOT is available beginning with NETLAB+ version 2010.R2. Beta support of CCNP ROUTE and SWITCH is available beginning with NETLAB+ version 2010.R5.
Beginning with NETLAB+ software version 2010.R2, NETLAB+ provides beta support for the recently released first course of the CCNP v6.0 curriculum, CCNP TSHOOT using the Multi-Purpose Academy Pod (MAP).
There are additional equipment requirements for the MAP pod when using it for CCNP TSHOOT:
Details on the additional equipment requirements for using MAP pod for CCNP TSHOOT.
Beginning with NETLAB+ software version 2010.R5, NETLAB+ provides beta support for the CCNP v6.0 ROUTE course. 100% of the ROUTE labs are supported using the Cuatro Router Pod (CRP) and many of the labs are also supported using the Multi-Purpose Academy Pod (MAP).
Beginning with NETLAB+ software version 2010.R5, NETLAB+ provides beta support for the CCNP v6.0 SWITCH course SWITCH labs are supported using the Cuatro Switch Pod (CSP) with the exception of one lab, which uses the Multi-Purpose Academy Pod (MAP).
Please review the NETLAB+ Product Comparison Table for details on the each product version. Both product versions can be used to deliver a wide range of curriculum content.
NETLAB Academy Edition is discounted upfront with the right to use tied to a required annual software upgrade fee. This model provides a lower cost of ownership and keeps your system current as technology changes. The annual support fee is required for continued usage.
NETLAB Professional Edition is a perpetual license for customers that want the software upgrade service to be optional. NETLAB PE is designed to scale to a higher volume of students and allows custom setups. This model is favorable for organizations that want to capitalize costs upfront.
Many products can be hosted behind a NETLAB+ system for the purpose of remote access via the Internet. What can be automated depends on the base functionality of the equipment. Some devices can be fully automated. Some devices have design limitations that allow for partial automation. Some devices have design limitations that allow no device automation. If the device can be managed via a console port and command line interface (CLI), full or partial automation may be possible. For complete automation, the manufacturer’s design must allow for remote password recovery and image recovery (if desired).
NDG supports a large array of Cisco equipment because 1) of our partnership with the Cisco Networking Academy and 2) the market for Cisco equipment justifies the labor to design automation around remote labs for many devices. NDG will consider automating other devices when an opportunity justifies the labor to automate required devices or when a customer is willing to fund the automation cost with the understanding that the automation driver will be used as a generic driver as needed and deployed by NDG.
You may host any device that is listed as a supported device. If the equipment you wish to use is not listed, there are a couple of options:
A pod is an instance of a supported lab topology, which can be reserved by a user.
Please review the details provided on the product comparison table
A wide variety of topologies are available for your NETLAB+ system including topologies for Cisco Networking Academy courses, the VMware ICM pod for the VMware vsphere ICM course and a selection of general IT topologies. You may also build your own custom topologies.
Please review the supported lab equipment page.
Control Devices are required in order to provide internal connectivity, console access, and managed power to lab devices. Control devices are dynamically managed by NETLAB+ and are not accessible or configurable by end users. Lab devices and control devices are required in order to support Cisco Networking Academy lab content.
Please review the supported control devices page
Please see the pod test help page.
An image that is marked "in use" has been assigned to one or more devices in a pod. To delete the image, you must first eliminate the dependency by assigning a different image to the devices using it. This is accomplished through the pod management interface.
Make sure logins are not disabled. Administrator > Enable / Disable User Logins.
Make sure the pods are online. Administrator > Equipment Pods.
In both cases, the outlets will remain ON until the end of the next lab reservation. To prevent this behavior, power on all control devices and lab equipment, then wait several minutes before powering on the NETLAB+ server.
Since the labs are authored and revised by Cisco, NDG can only make "recommendations". When NDG releases a new pod type, our recommendations are based on the Academy bundles available at the time and known issues pertaining to certain labs. These will change over time as curriculum changes and older equipment is phased out.
When NDG authors new pod documentation, we typically do not recommend any device that is well beyond end-of-life. Unless explicitly stated, such a device may actually work in the context of the current labs. However, it is the responsibility of the customer to verify this if they choose to implement. We therefore recommend you study the labs for the curriculum you are teaching prior to finalizing the equipment you host.
Items listed on the supported device page have driver support in NETLAB, but are not be appropriate for all pods and labs. The recommendations in the pod-specific documentation guides attempt to narrow this list down to an appropriate subset. Therefore, the pod guides should be considered the primary source for equipment recommendations.
Both ports are required for several labs that could not be done on Basic Router Pod Version 1. All entry level routers in the current bundles (Cisco 1841, 2801) support this requirement. NDG will continue to support a mix of both Basic Router Pod version 1 and Basic Router Pod version 2 on the same system to balance greater functionality with lower price points.
The Academy labs serviced by these pod types require administrative rights to the PCs, which is problematic under the Direct/Standalone model. In particular, a user with administrative rights can accidentally or intentionally disable the control NIC and isolate the PC from the equipment pod. third party virtualization products are not subject to this problem.
For further explanation, please refer to a Remote PC Guide in the documentation library.
Version 2 does not replace version 1. Rather, a mix of Version 1 and Version 2 will continue to be supported on the same system to provide a balance between functionality and cost.
Basic Router Pod Version 2 is designed to support more labs (both CCNA and CCNP) and provide greater functionality. This comes with the added expense of third party virtualization software and dual-Ethernet routers.
Basic Router Pod Version 1 supports fewer lab activities and is somewhat limited to CCNA. There are fewer requirements so the cost of implementation may be less.
Based on NDG’s purchasing experience, the typical price for server hardware to support VMware virtual machines is in the range of $1250-$1500 (US). NDG has used both Dell and IBM servers.
It is important to verify that the server you select meets requirements:
Please refer to the Remote PC Support page for details on supported virtualization software.
Please be aware that there is no need to purchase VMware products to implement remote PCs on a NETLAB+ server. You may obtain a free download of VMware ESXi.
When downloading ESXi, it is important to select a version that is compatible with NETLAB+. Please refer to the Remote PC Support page for information on the latest supported versions.
Do not purchase VMware ESX or VMware Workstation products; these products do not currently work with NETLAB+.
If you use VMware Server, you will need a Windows Server operating system to host the VMware Server application. NDG recommends Windows Server 2003, which typically costs $600 - $900 (US). Virtual Machines can run either Windows or Linux operating systems. Some Networking Academy curriculums utilize various Microsoft Windows operating systems, which typically require one license per virtual machine. The MSDN Academic Alliance program (where available) can provide Academic discounts for these products for qualifying institutions.
Cisco WS-C3560V2-24PS switches ("V2" models) do not respond to a console break signal, regardless of "enable break" setting, and therefore do not work with NETLAB+ automation (reference Cisco bug CSCsv92241). Although the bug was reported fixed, the problem still persists on the V2 models as of this writing. Workarounds: use WS-C3560-24PS (non-"V2" version) switches if available, or turn off automation by using the Generic Console Device setting.
NETLAB+ is an appliance. All administrative functions are performed through the console menu or web interfaces.
Please note: accessing or modifying the underlying operating system is not permitted under the license agreement. All internal access and modifications to the NETLAB+ server should only be performed by NDG technical support and official software upgrades.
Please see the Connectivity and Firewall whitepaper.
Ideally, the server should be placed in a rack behind a DMZ. NDG has taken many steps to make the product both secure and firewall friendly. However, a "remote lab" product inherently requires inbound connections. Some customers have opted to establish a separate low cost Internet connection for NETLAB+.
NDG keeps Academy pricing low by maintaining a standard environment and software version across all systems. Therefore, we typically do not modify individual systems. Occasional exceptions are made if the requested change is feasible, can be easily maintained, and/or incorporated into the core product.
A T1 connection is recommended. Bandwidth usage varies based on the number of simultaneous connections and connection types. Use caution with Cable and DSL solutions. Keep in mind that:
Yes. A unique external IP address must be assigned to the NETLAB+ server. A static mapping (or conduit) between the external and internal NETLAB+ IP addresses must be defined. Port Address Translation (PAT) is not supported.
| Port | Usage |
|---|---|
| TCP 80 | Provides HTTP access to the NETLAB+ web interface |
| TCP 2201 (default) |
Remote Access Port for lab equipment access and remote PC access.
|
| TCP 22 (recommended) |
Provides SSH for NDG technical support only. In lieu of SSH, this function can also be performed over the TCP port(s) defined for remote access, by special arrangement. |
| Port | Usage |
|---|---|
| TCP 25 | Allows NETLAB+ to send e-mail to users. This is optional. |
| TCP 80 | Allows the NETLAB+ server to connect to the NDG Central Support Server. This server provides software updates. |
| UDP 53 | The NETLAB+ server makes DNS queries to resolve the address of the support server (nss.netdevgroup.com). |
NETLAB+ is a proxy server. There is no routing between interfaces.
Although not supported by NDG, the following settings are provided:
A supported configuration requires direct outbound access from the NETLAB+ server to the Internet:
No. Access to CSS is required. NETLAB+ uses the Internet based CSS model to make the product easy to maintain at a reasonable cost. For more information, please refer to the CSS whitepaper.
TCP Port 23 (often associated/mistaken with Telnet), is no longer the default port for Terminal and Remote PC Viewer access. The default “Remote Access Port” is now 2201. New systems will use port 2201 out of the box. Existing systems with software prior to 2009.R1.beta.2 will remain 23, but can be changed from the console. The administrator has the capability to change the remote access port, or define more than one remote access port.
As of version 2.21.0, Telnet can provide a console login for sole the purpose of support by NDG. The option must be explicitly enabled by both the local NETLAB+ administrator and by NDG. Telnet can be used where firewalls and/or policy prohibit the use of SSH. Although SSH is not a requirement, it is still the preferred method of NDG support access because SSH provides encryption.
Not at this time. A wide variety of international laws restrict the export and use of encryption software. SSH is only used for technical support access by NDG, and only in countries that permit it.
NETLAB+ provides a read-only TFTP server listening on the inside (private) interface. TFTP is disabled on the outside (public) interface. When NETLAB+ needs to recover a system image on a lab device, control switch port is moved into VLAN 1. After the image is TFTP'd to the device, the port is removed from VLAN 1.
This is not supported for security and technical reasons. You can use a NETLAB+ remote PC to provide this capability if supported by the lab topology.
NETLAB Academy Edition is discounted upfront with the right to use tied to a required annual software upgrade fee. This model provides a lower cost of ownership and keeps your system current as technology changes.
This racking diagram is an example of one way a NETLAB+ system may be racked.
