Remote bundle for the Cisco academy for the Vision impaired. The Cisco academy for the vision impaired trains Vision impaired students in the operation and maintenance of networking equipment. As the students participate in the lectures from their homes and this is a distance class it was necessary to find a way in which remote students could access routers switches and workstations and learn to administer them. The remote bundle consists of the following components: 16-port telnet to serial device: allows students to telnet into the bundle and connect to up to 16 serially connected devices. Remote power switch: a 16-port remote power switch which can be controlled via serial in order to power up and down routers and switches when necessary. Routers 1 2 and 3: 3 Cisco 2821 routers explained below. 3 Managed Cisco switches: to allow devices in a pod to be networked together. Virtual boxes 1 through 3: 3 servers that run 2 virtual linux workstations a piece to provide 6 workstations in total. 2 wireless access points: to provide students with the experience of configuring wireless devices. 3 usb to serial boxes: 1 per virtual server box to allow virtual workstations to be controlled. 1 vpn control box: a pc with 3 network cards to provide vpn access to the web interfaces of the wireless access points and other virtual workstations when necessary. 1 eagle server box: This simulates an internet cloud for student labs. Design considerations: The remote bundle had to satisfy a number of operational and administrative requirements. Firstly it had to be separated from any production networks in such a way that student exercises would not disrupt network operation or provide a security risk. Secondly it had to be accessible by the vision impaired using assistive technology such as Jaws/Windoweyes. Thirdly: It should be administerable with low bandwidth over dialup lines if necessary for students in developing countries. This ruled out screen sharing software such as remote desktop, vnc etc for students on low bandwidth connections. An out-of-band method of administering the workstations and routers that did not rely on network connectivity was needed. Cisco routers and switchs have an rs-232 console port on them for out-of-band management. Workstations also had to be controllable remotely with the ability to reconfigure network hardware on demand without loosing connectivity to the boxes. Once all of the gear was accounted for, it was decided that there would be insufficient space in a rack for 3 routers, 3 switches, 2 wireless access points, a remote power device, a remote serial device and 6 workstations. In order to reduce the machine count workstations were virtualized. The remote bundle is separated into 3 "pods". Each pod contains 2 virtual work stations, a router, a switch and a wireless access point; except for pod2 which does not contain an access point. Each pod is a small network separated out onto its own broadcast domain. Pods are connected together by using routers and serial cables that link the routers together. Pod2 is considered as the "internet cloud". It has 2 workstations, it also has the eagle server box to provide an internet based webserver and other services for students. The router in this pod provides the clocks for pods 1 and 3. This is because pod2 is meant to simulate an ISP and ISP provides clockrate. One serial port is required for each device in a pod except for the wireless access point. As students need to reconfigure the network hardware on the virtual workstations a method of controling these needed to be found. It was decided that using a virtual serial port on the workstation would be the best way to manage these as Linux has no problems with remote access over a serial console. Serial can also work on low bandwidth links at speeds as slow as 9600bps if necessary. The remote serial access server has 16 ports. This provides 4 ports for each of the 3 pods and one port for management of the switch itself. It also provides a port for the remote control power switch. A port or two is left over for future expansion. Telnet access is provided from the internet into the remote bundle. Passwords are used to restrict student access to a subset of equipment such as machines only in one pod. The remote power switch has 16 IEC power ports which can be used to power up and down routers and switches. This is required when a student needs to perform password recovery labs on the routers or switches. Budget was a consideration in the construction of this setup so wherever possible free and open source software was utilized. Ubuntu 9.10 was the base software on each of the virtual boxes. A standard install of ubuntu 9.10 X64 was done with the latest kernel and development utilities. Vmware server 2.0.1 was installed on the machine. 64-bit was used to provide access to more than 4gb of physical memory, and more than 2gb of virtual memory per virtual machine. Whilst our virtual boxes do not contain more than 4 gigabytes of memory at this stage, using 64-bit Ubuntu as the base OS allows for future growth. Instructions for installing vmware server were found in the ubuntu community documentation. Without this information the kernel modules for vmware refused to compile. Development libraries, kernel source and headers had to be installed. The shell script referenced on the community page was run to patch the vmware installer so it would compile and run under New kernels. Once vmware server and ubuntu were installed, a prototype virtual machine was built containing ubuntu and a basic set of networking utilities. The virtual machines were built using 32-bit ubuntu, and 2gb of diskspace per machine. 128-megabytes of ram were allocated to each machine. The virtual machine was then reconfigured to use a USB to serial interface as its primary console. This machine was then cloned to produce the other workstation images. Before cloning /etc/udev/rules.d/70-persistant-net-generator-rules needed to be removed so that when the cloned machine was booted the ethernet interface came up as eth0. New machine profiles were created in vmware server. The hard disk files were then copied from the prototype machine. Once the clones were booted the hostname was changed along with the mapping for the USB serial port. Com1 on the virtual machine mapped to ttyUSB0 or ttyUSB2 depending if it was the first or second vm on the box. All virtual machines had their ethernet interfaces bridged to the ethernet interface on the virtual box in order that they could communicate with machines in each pod. This also allows a router or access point on the particular pod to hand out dhcp leases which will be used by the workstations. Wireless access points are connected to pods 1 and 3. As the web interfaces of these Linksys routers had to be accessible to students the ip addresses were set to 192.168.12.1 and 192.168.24.1 respectively. Cisco routers: There are 3 Cisco 2821 routers in the pod which are responsible for connecting all of the pods together. Each pod is isolated from the others and can only be reached through a router over serial cables. Routers are wired in a loop but not all interfaces are up and active. Router 1: serial 0/0 connects to router 2 serial 0/0. serial 1/0 connects to router 3 serial 1/1 router 2: serial 0/0 connects to router 1 serial 0/0 serial 1/0 connects to router 3 serial 0/0 Router 2 provides all clock signals. router3: serial 0/0 connects to router 2 serial 1/0 serial 1/0 connects to router 1 serial 1/0. Ethernet ports on each router connect to the corresponding managed switch, i.e. router 1 connects to switch 1, router 2 connects to switch 2 and so on. Vpn setup VPN box: This box has 3 network cards and provides bridged access to devices on the pods to the students. Eth0 connects to the internet. Eth1 and eth2 connect to pods 1 and 3 respectively. If students connect to this box using openvpn http://www.openvpn.net they get direct access to the web interfaces on the access points. Note that we are using the community supported version of openvpn so all config files are edited by hand and there is no web interface for controlling it. The vpn box has ip address 192.168.100.140 and listens on udp ports 1194 and 1195 for each of the 2 bridged vpn connections. The connections bridge to the switches on bundle 1 and 3 respectively. Unless dhcp is configured on the bundle students will have to assign an ip address to the bridge manually. Setting up a student pc to access the vpn: A key will need to be generated for each student pc on the vpn box. Do this by sshing to 192.168.100.140 and running the following commands: as root: cd /etc/openvpn/easy-rsa/2.0 . vars ./build-key studentname studentname should be a unique name for the student that will appear in the log. Note the invokation of vars needs to be ". vars" to set entries in the environment. The student needs to be given a studentname.csr, a studentname.key and the ca.crt file. They also need a config file for both vpn instances. Student documentation will be written up separately.