The NETLAB+ server uses the Internet to simplify administration of remotely accessible router equipment and to reduce the cost of ownership and support. NETLAB+ uses centralized support services to reduce the time, skills and budget necessary to operate and maintain a customized application running on an appliance based server. The Internet makes this possible.
Each NETLAB+ system is part of a centralized network management medium known as Central Support Services. Customers with a current support agreement receive the following services delivered through CSS:
All NETLAB+ systems have uniform hardware, software, and system configurations. Software updates and configurations are maintained through CSS. Using a centralized approach and Internet connectivity, the typical software update cycle is reduced from months to minutes. Uniformity among systems combined with CSS removes the need for operating system level access and manual configuration. All local system administration and configuration is performed through a web interface.
All CSS communication is "demand pull." All requests are initiated (outbound) from the NETLAB+ server. The HTTP protocol is used because it is generally allowed outbound by network security policies.
Each NETLAB+ server uses the Internet to download and upgrade software packages. A package can contain software upgrades, lab updates, security patches, configuration changes, and bug fixes. The software update process can be executed automatically or manually. In automatic mode, NETLAB+ will check for updates. If new packages are available, the NETLAB+ server will download and install each package when the lab is not in use.
Keeping up with security advisories is usually a significant part of a system administrator's job. To simplify this task, NETLAB+ performs integrity checks that:
If a security problem is detected, an alert is sent to CSS for analysis and follow up by NDG. This method allows rapid response to security issues.
NETLAB+ stores all dynamic data in an SQL database. If the administrator enables automated backups, a daily backup of the database is stored on the NDG CSS server. The last 5 backups from each NETLAB+ system are stored on the CSS. In the event of a hardware failure, the database can be restored by NDG on a replacement system or hard drive. Using this method, a NETLAB+ site does not need to develop and maintain a separate backup server and methodology.
Each system provides status reports and alerts to CSS. This strategy provides useful information to support engineers and developers and significantly reduces support call detective work. The direct result is faster problem resolution and better service.
Each NETLAB+ system can keep the date and time synchronized through CSS. This insures that each NETLAB+ system has the correct date and time without administrative action.
Ideally, NETLAB+ should be placed on a public network or DMZ. Since a NETLAB+ system might be installed behind a firewall, many steps have been taken to make NETLAB+ secure and firewall friendly. However, it is likely that some TCP/IP ports will need to be opened through the firewall. These ports are described in section 3.
Connection to a local area network is provided by a 10/100 Ethernet connection. A unique static IP address is required. DHCP cannot be used.
NETLAB+ must have access to an Internet connection. This connection should be at least 500 kilobits per second in both directions. A T1 connection is recommended. Actual bandwidth usage varies based on the number of simultaneous connections and connection types.
NETLAB+ will work with NAT firewalls. 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.
Table 3-1. Protocol Table
| Protocol | Port | Direction | Open In Firewall... |
|---|---|---|---|
| HTTP | tcp 80 | inbound | to provide external access to NETLAB |
| Telnet and VNC | tcp 23 | inbound | to provide external lab access and NDG technical support |
| SSH | tcp 22 | inbound | to provide secure NDG technical support access |
| HTTP | tcp 80 | outbound | required, provides access to CSS and support services |
| DNS | udp 53 | outbound | only if DNS name server is outside the firewall |
| SMTP | tcp 25 | outbound | required, allows NETLABAE to send e-mail |
| Ping | icmp echo | outbound | used for diagnostics only |
Figure 3-1. Protocol Block Diagram
TCP 80: This is the standard HTTP port, used to access the NETLAB+ user interface.
TCP 23: NETLAB+ uses Telnet to access the consoles of routers, firewalls, and switches. A connection is made to the NETLAB server, which in turn is proxied to an asynchronous access server on the NETLAB+ inside network. The VNC protocol is used for keyboard, video, and mouse access on lab PCs. VNC connections are also proxied through the server.
Because CSS plays an important operational role, each NETLAB+ server must be able to communicate with its designated CSS server. NETLAB+ communicates with a CSS server using outbound HTTP on TCP port 80. All requests are initiated from the NETLAB+ server.
Note: there is an administrative option to redirect these requests to an HTTP proxy server. The proxy must be completely transparent. This is not officially supported by NDG. The supported method requires direct access to the Internet on TCP port 80.
NETLAB+ allows configuration of up to 2 DNS server IP addresses. If the DNS server IP addresses configured in NETLAB+ are located inside the firewall and the DNS servers perform recursive queries, it is not necessary to open outbound DNS (UDP port 53).
| Protocol | Port | Direction | Open In Firewall... |
|---|---|---|---|
| HTTP | tcp 80 | inbound | to access the user interface |
| Telnet and VNC | tcp 23 | inbound | to access a lab device |
| SSH | tcp 22 | inbound | to access system internals |