VNS was initially developed to solve the problem of how to teach the implementation of internet routers to a large undergraduate networking class. The goal was to provide hands on experience with routing actual internet traffic sent by the student using standard internet clients. Instead of using a simulation environment or setting up a small physical network per student, we developed VNS which emulates network topologies (virtual topologies) that can be integrated with physical networks. All traffic seen by the virtual topologies is forwarded to user-level programs written by the students which can then drop, inspect, and/or modify the packets and re-inject them back into the network.
The VNS is comprised of two components.
The VNS server is a user-level application which runs on a PC that is positioned between the Internet and a number of standard Internet servers which run basic internet services such as HTTP, ftp and ssh. The physical set of the VNS server is shown below.
The server is configured to emulate one or more (up to 2^16) topologies. Each topology consists of one or more virtual hosts (each with one or more virtual interfaces) and their connectivity to each other and to the physical network. A simple topology with a single virtual host is shown below.
The virtual host has three interfaces each one "connected" to a physical interface on the network. The VNS intercepts all traffic between the firewall (Internet) and the application servers. If, by inspecting the source/destination of the packet, the VNS determines the packet can be seen by the virtual host, it will forward the packet to a VNS client (if one exists for this host) over a standard TCP socket so that the client may handle it in user space.
VNS clients are programs that run in user space and connect to the VNS Server via standard TCP sockets. Each client can "reserve" a virtual host on any given topology. If the virtual host is not currently reserved, the server will forward all packets that can be seen by that host to the client. The client may, as well, send packets to the server to inject back into the network specifying which interface to send the packet out of. The client is now functioning effectively as if it were directly on the network with full access to all traffic seen by the virtual host.
The power of VNS is not demonstrated with a single topology consisting of one virtual host. Using the same physical setup as previously shown, VNS can emulate thousands of completely isolated arbitrarily complex topologies. That is, each student in a large class could connect with a VNS client to the VNS server and would only see the traffic destined to his or her topology. Multiple students may, as well, connect to different virtual hosts in the same topology. This is somewhat analogous to virtual memory, that is, using the same physical network, each virtual network is (almost completely) isolated from another and can be arbitrarily large and complex in size. The following figure shows the logical view of VNS hosting three different topologies on the same physical setup.
VNS has been used in the Stanford undergraduate networking course as an environment in which each student built their own Internet router and routed actual traffic initiated by themselves over their own isolated network topology.
The students were given a skeletal, incomplete router that they were to complete and demonstrate that it works by performing traceroutes, pings and downloading some files from a web server and an ftp server via their router. The skeletal router (sr for 'simple router') was a simple VNS client capable of connecting to the VNS server, reserving a virtual host on a given topology and receiving and sending packets from/to that host. Once connected sr would print out a simple message for every packet it received and drop the packet.
A simple topology (similar to the one in figure XXX) was installed on the VNS for each student participating in the assignment. Each topology was given a unique block of IP addresses to assign to each interface. The students had to add the necessary functions to sr, including ARP, ICMP, decrementing the TTL field in the IP header, and IP forwarding so that they could eventually reach the application servers across their virtual topologies.
![[ STANFORD UNIVERSITY ]](images/su.gif)
