Logical network structure in the DiRT lab

The DiRT group maintains two classes of end-workstations:

This section describes the logical structure of the networks and the logical configuration of the different components of these networks. The details of configuration are in section 2.

For easy reference, here's a list of all of our hostnames and their IP addresses (well, the last octect anyway). The file currently lives at /usr/dirt/config/ip.all

Production machines

Production machines are the ones that need a steady connection to the department network. These are primarily our development machines, mounting NFS partitions, etc. through the department.

Experimental machines

Experimental machines are anything that we don't want connected to the department ethernet. Most of these machines will usually have connectivity to the department via a router, but these machines may also be disconnected from time to time. We have a configuration that offers 12 subnetworks for our experimental machines.

We refer to these subnets by the number of their third octet. The private networks are referred to by the number of their third octet, prefixed with a 'P'. For example, 192.168.137.xx is referred to as the P137 network.

Private Networks (192.168.xx.xx)

These addresses are set aside by "the powers that be" as private IP addresses. We can use these with the understanding that no packet from any of our networks with these addresses ever reaches outside our private network. Other folks use these same addresses on their private networks, too. If two packets with the same IP addresses, but from different machines, ever happened to meet out in the Internet, the anti-matter collision would end the world as we know it today. =)

Routers and Proxy-Arp

Routing

A router is simply a machine with multiple network interface cards (NICs). Each interface is configured based on the network it's attached to. It if is the departmental interface, it is configured like a production machine above. If it is an experimental subnetwork interface, it is configured like an experimental machine above. We use FreeBSD machines as routers. The FreeBSD machines must have a flag set at boot-up in order for the machine to act as a gateway. When a router receives a packet intended for the IP address of another machine, it attempts to send it out over the interface with the appropriate netmask or to the default router, if one is specified. Packets get directed to these routers off of the department network via an evil hack called proxy-arp.

Gateway vs. Router (or, why is routed bad?)

This is my take on the gateway vs. router issue. A router uses routing protocols to constantly update its routing tables based on information it receives from other routers in the Internet. (If you want more info on routing, check out Comer's book, or take a networking class from Don Smith or Bert Dempsey.) A gateway just forwards packets from one of its interfaces to another.

We set a gateway_enable flag in a config file on the FreeBSD machines that we use as routers. There's a router_enable option that we do not use. The gateway_enable option just turns on IP forwarding. The router_enable option turns on routed, which attempts to advertise our routing tables to other machines in the department (and on campus). They (the department and campus) really don't care about how our machines are routing, and it would be bad for them to know. So, we setup IP forwarding via gateway_enable and set static routes on our routers.

Proxy-Arp

Ok, check-list time! In order for an experimental machine to have proper connectivity to the department, it must:

In addition to these "obvious" steps, our departmental configuration has an additional requirement, proxy-arp. The entire UNC campus is currently on a flat network. Everything is 152.2.xx.xx. Because our departmental machines all communicate directly (without a router), they all just find local machines (those in the departmental subnet) via ARP requests. Since our experimental machines are hidden behind a router, they cannot see these ARP messages and thus, cannot answer them. Instead, some other machine must answer on their behalf. Further, the proxy machine doesn't respond with the machine's true hardware address, but with the hardware address of the router that handles that machine's connection to the departmental subnet.

For example, consider goldberg, which handles routing between the department and the 135 subnet, where dot135 is connected. Sam (also directly connected to the departmental network) handles proxy-arp for the 135 and 136 subnets. When a departmental or production machine, such as tyagi broadcasts an arp request for dot135, sam responds with the hardware address of the card connecting goldberg to the department. Tyagi then sends the packets destined for dot135 to goldberg, who routes the packets onto the 135 subnet.

Name to address-mapping:

Each of our machines has (or should have) 15 different entries in the domain name service. Most of them are of the form . That is, poirier on the 136 subnet (152.2.136.57) is poirier136. Finally, the 137 addresses are also in the DNS as the straight hostname (e.g. poirier). The logic for this is that since this is subnet we use for machines that are connected directly to the department network, those should be the unqualified names.

Here's an example of all of the entries for poirier. 

152.2.134.57   = poirier134
152.2.135.57   = poirier135
152.2.136.57   = poirier136
152.2.137.57   = poirier, poirier137
152.2.138.57   = poirier138
152.2.139.57   = poirier139
152.19.160.57  = poirier160
152.19.161.57  = poirier161
152.19.162.57  = poirier162
152.19.163.57  = poirier163
152.19.164.57  = poirier164
152.19.165.57  = poirier165
152.19.166.57  = poirier166
152.19.167.57  = poirier167

Ancient DiRT History: Token rings and ethernets

It may be worth noting that in the past we have used the 134 and 135 subnets for token ring and 136-139 for ethernet. Until now we have only had 6 subnets so all of the addresses were effectively on the "A" subnets as we had no machine addresses with the final octet greater than 127 (0x7f). Some older demos still expect the networks to be set up this way.


Previous document Next document

Other DiRT documents
Author: Mark Parris   Mark's original network logic page, if you're interested in DiRT history.
Updated By: Michele Clark
 Last updated: January 19, 1999