Here are some photos from our first training session (As usual, click for the 1024x768 version - approx 150KB each):

	This is a good example of what your wiring closet should not look like. It only got worse from here. Everything used to be at least as neat as those cables hanging on the right, going round the sides and into the two base 10 HUBs sitting below the patch panels.
	The empty lab. Well, a few extra network cables has been added to the 10 leftmost machines, the wiring closet is just to the left of the image. We've even got a three-homed host *grin* :).
	Doing some planning ... I'm in the background busy cleaning up the network diagram (if one can call it that) from the version which we put together just before. It looks a lot neater now.
	Close up directly after all the network (big blue circles), hubs/switches (red blocks) and machines (black blocks) have been drawn. All machines have names stuck to the screens (NL = Networks Lab), these are the names shown here, except for chimera, which is my notebook. This will be joined up with wireless to the remainder of the campus network should we need an external connection (and even then it won't route due to the fact that will more than likely not be able to resolv to the outside world).
	Another view on the wiring closet. This one is not as impressive though :).
	Even geeks have to eat ok!
	(450 KB) Our network diagram is filling up. At this point all IPs is assigned (theoretically at least), at this point some of the whole thing was actually working. We had most of the "routers" up and had some configured with IPs and the like. So we have wasted a lot of time with configuring the cabling and the HUBs to represent the drawing on the board as close as possible (All wiring was done at this point). We only had one shared switch, the "Planet" switch supplied by Alan. This caused quite a bit of confusion later on...
	The only network card we just could not get running. 8139too. dmesg eventually told us the chip is not responding so we decided to swap it out.
	Yes, some of us actually did get round to doing some work.
	(450KB) And the final network diagram. This is the one to be used for homework.

Important points

Right, so at the end of the day we learned a couple of valuable, if somewhat irrelavent in some cases, things (If you remember something I don't, feel free to drop me a mail):

• Never rsync as root, before 10:00 in the morning in any case. And if you do - make sure someone double checks you. It went something to the effect of "cd /; rsync -rav --delete root@another_machine:/lib/modules/ ./". Hmm, at least that wasn't me. But a big blooper none the less.
• There is no way to reliably control which network card is going to get what names. This is especially true if you are using multiple identical network cards. The rule that we've determined states, the eth? assignments happens based on module load order, and within the same module it depends, probably on the pci id of each network card.
• Always make sure that you have enough switches/HUBs for your network topology. NL24 ended up with two cables running to the same switch. This confused us for a bit since it will actually respond to arp on both interfaces. Right, I guess I'll go figure out how to use arptables (part of ebtables) again. I've used it before, albeit for a much different purpose.
• Routing is a much bigger issue than most people realise. Take this small network for example, if one simply specify a default route for each host, then there is a very likely possibility of routing loops. We considered having everything route clockwise round the network, but soon realised a packet destined for say 196.25.1.1 will just loop around for a total of 255 (max) hops.

Homework

Right, since we only got round to thinking about routing at about 16:30 and there was only three of us left, we decided this should be homework. For each and every host (except chimera - which has routing problems way beyond LPI and that is spesific to the wireless setup at the university), set up a routing table to ensure minimum hop count for any delivery. All packets not destined for any of the networks on the diagram should be delivered to chimera. Take note that any networks within 10.51.10.0/24 that is not allocated should simply result in the packets being dropped. chimera, will be configured to not route, but will log any packet that is received for one of the networks on the diagram that gets passed for routing. The same goes for the 192.168.0.0/16 network, and yes, the double allocation on 192.168.0.0/24 was on purpose.

We don't have any submission rules, so I reckon just mail a pdf file with how the routing table for each machine should look to alan and myself. Well take a look and decide on the best one and then use that. Eventually we'll switch the routers to using routed.

Next week

Same as usual, anyone is welcome. We'll be configuring the routing. If all goes well, this shouldn't take longer than an hour or two (hopefully).

Then we'll just add some machines to each of the networks, we have another 25 unused machines. Luckily the ugly cabling is done, the remainder of the machines goes nicely into the patch panel and since all the switches/hubs is within range of the patch panel this shouldn't take long either. Two or three machines on each network should do the trick (hmm, just though about it, these routing tables can simply have default routes, but it will be more optimal to give them proper routing tables).

Right, then we would like to also configure DNS and NTP (rsync needs to start doing the right thing).

I doubt there will be much time left after that, if there is, we'll pick two of the 192.168.0.0/16 subnet to become DHCPified. We'll use a single DHCP server with a dhrelay.

Till next week.