Cmpt 471 Assignment #2 01-3
Due Dates: For the early group, at the START of class, Wednesday, Oct. 17.
For the mid group, at the START of class, Friday, Oct. 19.
For the late group, at the START of class, Monday, Oct. 22.
Note: This assignment requires a student to use 2 or 3 machines at once. You are NOT to work with other
students on this assignment, but you can cooperate with them (e.g. choose same length netmask) to allow at
least 4 or more students in the lab simultaneously, even with subnetting. This works particularly well if you
choose to do your subnetting on a serial rather than just use all Ethernet links. As a result, some of your scripts
or files may show routes and subnets that are part of some others student’s work that you are cooperating with.
You MUST annotate these by hand to indicate that you are not trying to purport that those configuration lines or
routing table entries are necessary for YOUR experiments in the lab.
Note: It is best to figure out your plan for each part, before going into the lab and just messing around until you
get something working that you like. Ahead of time, reread the lectures on the topic you are going to try in a
particular session. Ahead of time, write entirely out the commands you will need (they may need tweeking in
the lab if you don’t get the machine you want, but this is trivial. What I don’t want is unnecessary reading of
man pages, books, and lecture notes while trying to do the experiments in the lab. Have the necessary files pre-
prepared on a DOS floppy and then use mtools to read them into the FreeBSD machines. Lab time is very
precious so please conserve its use.
In the first exercise of this lab assignment, I want you to set up a relatively snaky route through the lab. For this,
you can change one or two of the workstations into gateways. This is done by editing the file
/proc/sys/net/ipv4/ip_forward to have a single “1” in it rather than a “0”. The /proc files are not really files, but
a pseudo interface right into the kernel. It allows you to see a lot of statistics in the kernel, and to write a few
configuration flags in the kernel. ip_forward is one of the few files that is writable in addition to readable.
Though you can use an editor to change the contents of such writable files, most administrators use a short-cut
towrite into these simple /proc flag files:
echo 1 > /proc/sys/net/ipv4/ip_forward
And echo 0 > /proc/sys/net/ipv4/ip_forward
Note that to read the files you can use the ‘cat’ or ‘more’ commands.
Turning on ip_forward via this method is a temporary solution. Though you will not need it in the assignment,
for your information to change the machine permanently into a gateway, add/change the line:
net.ipv4.ip_forward = 1
to the file /etc/sysctl.conf, which is read every time the machine boots.
Note there is also a permanent way to add routes to the routing table. Create or modify the file
/etc/sysconfig/static-routes so that it has lines like:
eth0 net 172.17.0.0 netmask 255.255.0.0 gw 172.16.1.253
Boot scripts read this line, move the eth0 to the end, and prepend it with “route add –“, then execute it.
To create a snaky route, you can move Ethernet cable destinations, and also add extra or different links to the
configuration in the lab (and if some existing links pose a difficulty, use ifconfig ‘down’ commands to
temporarily disable them. Be careful though as ifconfig up does not restore their routes; if you want the routes
automatically brought up too, use /etc/sysconfig/network/ifup instead.).
In addition, I will put four RS-232 serial cables and 4 null modems in the lab, and also 4 10Base-T cross-over
cables in the lab. These latter cables have a little nylon tag on one end with the character “X” marked on them.
With them you can go machine direct to machine, or router direct to machine, without going through a hub (not
that hubs are bad or to be avoided. Note that you can also use crossed cables to go to the hub but will need to go
to an uncrossed port of the hub!). You can also move the destination of existing uncrossed cables!
Page 1 of 3
If the lab is very busy, you would be wise to complete Part 3 below first, so that you can use serial links here in
Part 1 and thus not use up as many Ethernet cables and Ethernet ports.
Don’t go overboard on snakiness (you’re not cooking spaghetti!) or you will never, before leaving the lab each
visit, be able to put the wiring back the way it was! Basically all I would like to see you use is one extra link
cable, one changed link, one (or more) gateway enables. You will no doubt need to use route add/delete
commands. Also, try and choose an architecture that would allow both you and other students to be working
simultaneously yet almost independently on your own assignments. Once you have the physical links in place,
you can add or reconfigure the interface settings of the machines affected, as necessary. Do NOT subnet (you’ll
do that in the different part of this assignment). Instead, you can create new nets (e.g. 172.19, 172.20, …) if
needed for interfaces at each end of new machine-to-machine direct links. Finally, change the routing tables to
set up the snaky routing. Run ‘script’ and ‘traceroute’, and capture the traceroute command’s output. Be
careful that there is a return route for the paths that traceroute uses, as otherwise you will get nothing back. It is
best, but not compulsory, that the return route retrace the outbound route. Note: “ping –R” shows return routes
for up to 9 hops, but some hosts ignore or discard this option.
I have not given you the password for the router yet, so its interface addresses, masks, and routes are fixed (it
knows about the .16, .17. and .18 networks only). You can however add forward and return routes to the
gateway named ‘january’ and to any other PC in the lab. Also, I have added some static routes to ‘seasons’ so
that you can ping it and get answers back to weird custom network addresses that you have created. On
‘seasons’ the odd number addresses .17, .19, .21, .23 are forwarded to ‘january’ and the even addresses .18, .20,
.22, and .24 are forwarded to the Cisco router. This may be of minor help to you though it is certainly not
required to be used in this assignment.
Stop working about 15 minutes before having to leave the lab so that you can spend that time restoring the
lab to its former state before leaving. Think of it like a chemistry lab; you have to wash up the glasses before
leaving. EACH time before leaving, you MUST, on EVERY machine you messed with (except those still
needed by other students), do a 471restore and reboot (unless this disturbs others using that same machine; in
this case you must manually remove your custom settings). And you MUST put all the wiring back the way it
was. And, you MUST coil NEATLY the now unused extra serial and 10Base-T roll-over (i.e. crossed) cables
and put them away. This is so that students don’t have to go searching among the many other cables near the
hubs to find ones that are not currently attached to anything!
It is critical for us that you draw and submit a diagram of the portion of the network architecture you used,
vividly hand annotating the changed and added routes, and which machine(s) you used as a gateway. Mark the
IP address and interface designator of every interface involved. Highlight your snaky route and direction. Also,
supply VERY WELL ANNOTATED scripts of the routing tables and of “ifconfig -a” for each machine on your
route. Print a copy of the pseudo file /proc/sys/net/ipv4/ip_forward on at least one machine you changed into a
gateway. Last semester we found it very hard to decipher in a time efficient manner all the pages of stuff
submitted without a very good diagram, and very well labeled scripts. You will loose marks if we cannot
quickly grasp your changes and which scripts apply to which machine (hand annotate in big letters the machine
name). Also, it is extremely important that each of your scripts be HIGHLIGHTED to show important routing
table, ifconfig and other settings that have been executed/added/changed by you (and unrelated to you, by other
students sharing the lab). You can do this with a highlighter, or just underline the important lines.
You have to demonstrate the actual set-up and functioning of subnets. You can do this using either serial lines
(see Part 3), or added Ethernet cables (either cross-over or uncrossed). Using serial cables is the least intrusive
to others in the lab, but the early group may want to avoid serial lines until we have covered them in class. If
you are in the mid and later groups, please do part 3 first, or in conjunction with Part 2. It is slightly better
(though not essential) that you add cables for Part 2 rather than using/moving existing links, so as to not disturb
too much of the lab. It is best to not subnet the 172.16 network, as we would like it to be up most of the time
Page 2 of 3
(but with the permission of other students, you can do it if you have too). Instead, subnet say the 172.17
network into two subnets. The ‘standard’ physical part of 172.17 can be one subnet (don’t bother trying to
change the subnet mask on the router; just don’t use the router during this exercise. You can of course change
‘january’, or any other multi-homed machine you are using as a gateway), and the added serial/Ethernet link can
be the other part of the subnet. Or with wiring changes or serial/ethernet wiring additions, create a totally new
net with two subnets. If it helps, you can ‘ifconfig down’ any links whose presence is a problem. If two
students are working in the lab simultaneously, you might need to use a common subnet mask in order to work
closely (you can figure out yourself why this is helpful). Provide a diagram of your network architecture, and on
it show the subnet mask that you chose to use and why you chose that mask. Provide scripts of ‘ifconfig -a’ and
‘netstat -nr’ for each machine you re-configured. Prove using scripted pings, that you can get from each subnet
to some other interface not on either subnet. On the machine with that other interface, prove you can get to
EVERY interface on each subnet.
In this section, you are to set up a dedicate SLIP (or CSLIP) link. Don’t run slattach unless you are root, as it
will fail. Show vividly what you did in a very well annotated lab diagram. Demonstrate with scripts of ifconfig,
and netstat –nerC before and after ping, that the serial line works (i.e. that the number of packets sent over that
link, as shown in the routing table, has increased as a result of a ping).
Note: We are unsure that the slattach and ifconfig commands are all that is needed to get the link up with
hardware flow control, and then back down. As an optional enhancement to this lab (no extra marks) you can
try flooding the serial link. Send lots of large packets carrying all kinds of control characters as fast as you can
over such a serial link, and see if the results get through. You can write your own program to do this, or ftp a
large file, or use a special ping. Ping has some nice features (see the -f, -l, -s, and -p command parameters), and
will tell you how many packets got through. Increase the baud rate specified in the slattach command (modern
serial port chips can handle multiples of 9600 bps, usually up to a maximum of 115200 bps) to try and cause
buffer overrun in the destination. We think the flow control is working, but it would be nice to test this. If it
doesn’t work, it might be the ping program on the source end. When using FreeBSD Unix, we looked at the
source code for ping and we saw that the author sloppily did not check that the socket accepted the last packet
sent before sending another (i.e. source IP stack ran out of send buffer space, and source application failed to
respect or even notice this)! Don’t forget to put EVERYTHING back the way it was before finishing this
exercise. Especially coil the cables and put them so they don’t tangle with each other.
Page 3 of 3