INR

Introduction

This page houses all documents that are produces as for the INR class. Feel free to do with them whatever you want.

Assignments

Assignment for Friday, March 18, 2005:

OSPF
For this excercise I have set up three OSPF routers with three area's. One router is a BR and the other two are ABR`s. The main network (area 0) consists of the 10.0.0.0/24 area and the two border area's are 192.168.0.0/24 and 192.168.1.0/24. The config file used for this is this one. The OSPF config files are:area 0, area 1 and area 2
After starting hostA, hostB and monitorHost with the VNE tool, I used the config command to list the command to start the hub and the tree routers. These are started and configured outside the VNE tool as it is unstable. I have made four log files:

The election process of OSPF uses HELO packets to elect a BDR and DR. First the priority will be used to elect a BDR and DR. The highest priority will be the DR, the runner up will be BDR. In case of a tie, the highest ID wins. The ID will be generated using the highest IP address available on each router.

Addition:
I analyzed a fifth log log file with ethereal (asci version available here). We firstly see traffic to the AllSPFRouters multicast address, which is just HELLO traffic.

	14:27:20.591013 IP (tos 0xc0, ttl   1, id 1263, offset 0, flags [none], length: 64) 10.0.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, Hello (1), length: 44
	Router-ID: 10.0.0.1, Backbone Area, Authentication Type: none (0)
	Options: [External]
	  Hello Timer: 10s, Dead Timer 40s, Mask: 255.0.0.0, Priority: 1

After a while, neigbors have discovered each other

	14:27:40.951892 IP (tos 0xc0, ttl   1, id 1267, offset 0, flags [none], length: 72) 10.0.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, Hello (1), length: 52
        Router-ID: 10.0.0.1, Backbone Area, Authentication Type: none (0)
        Options: [External]
        Hello Timer: 10s, Dead Timer 40s, Mask: 255.0.0.0, Priority: 1
        Neighbor List:
        10.0.0.2
        10.0.0.3

Then, router 10.0.0.1 decides that 10.0.0.3 is the designated router and the backup router

	4:27:50.971204 IP (tos 0xc0, ttl   1, id 1269, offset 0, flags [none], length: 72) 10.0.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, Hello (1), length: 52
        Router-ID: 10.0.0.1, Backbone Area, Authentication Type: none (0)
        Options: [External]
          Hello Timer: 10s, Dead Timer 40s, Mask: 255.0.0.0, Priority: 1
          Designated Router 10.0.0.3, Backup Designated Router 10.0.0.3
          Neighbor List:
            10.0.0.2
            10.0.0.3

DB descriptions fly round...

	14:27:51.993683 IP (tos 0xc0, ttl   1, id 16914, offset 0, flags [none], length: 52) 10.0.0.1 > 10.0.0.2: OSPFv2, Database Description (2), length: 32
        Router-ID: 10.0.0.1, Backbone Area, Authentication Type: none (0)
        Options: [External], DD Flags: [Init, More, Master]

The backup router has been elected..

	14:28:00.991484 IP (tos 0xc0, ttl   1, id 1271, offset 0, flags [none], length: 72) 10.0.0.1 > OSPF-ALL.MCAST.NET: OSPFv2, Hello (1), length: 52
        Router-ID: 10.0.0.1, Backbone Area, Authentication Type: none (0)
        Options: [External]
          Hello Timer: 10s, Dead Timer 40s, Mask: 255.0.0.0, Priority: 1
          Designated Router 10.0.0.3, Backup Designated Router 10.0.0.2
          Neighbor List:
            10.0.0.2
            10.0.0.3

A LS request has been made:

	14:28:12.040695 IP (tos 0xc0, ttl   1, id 16922, offset 0, flags [none], length: 56) 10.0.0.1 > 10.0.0.2: OSPFv2, LS-Request (3), length: 36
        Router-ID: 10.0.0.1, Backbone Area, Authentication Type: none (0)
          Advertising Router: 10.0.0.2, Router LSA (1), LSA-ID: 10.0.0.2

A LS up is sent:

	14:28:18.946606 IP (tos 0xc0, ttl   1, id 16923, offset 0, flags [none], length: 84) 10.0.0.1 > 10.0.0.2: OSPFv2, LS-Update (4), length: 64
        Router-ID: 10.0.0.1, Backbone Area, Authentication Type: none (0), 1 LSA
          LSA #1
          Advertising Router: 10.0.0.1, seq 0x80000003, age 7s, length: 16
          Router LSA (1), LSA-ID: 10.0.0.1
            Options: [External]
          Router LSA Options: [ABR]
            Neighbor Network-ID: 10.0.0.2, Interface Address: 10.0.0.1, tos 0, metric: 10

A LS ACK is sent

	14:28:18.946637 IP (tos 0xc0, ttl   1, id 16924, offset 0, flags [none], length: 84) 10.0.0.1 > 10.0.0.2: OSPFv2, LS-Ack (5), length: 64
        Router-ID: 10.0.0.1, Backbone Area, Authentication Type: none (0)
          Advertising Router: 10.0.0.2, seq 0x80000003, age 4s, length: 16
          Router LSA (1), LSA-ID: 10.0.0.2
            Options: [External]
         Advertising Router: 10.0.0.1, seq 0x80000001, age 65s, length: 8
            Summary LSA (3), LSA-ID: 192.168.0.0
         Options: [External]

Assignment for Friday, March 11, 2005:

RIP
For this excersise I threw VNE overboard and used a python script. (I borrowed an example from last year)
The files I used are: the rip perl script, the RIP config file for router 1 RIPV1, the RIP config file for router 2 RIPV1 and the RIP config file for router 3 RIPV1

As we can clearly see, the RIPV1 protocoll also routes the 172.16.0.0/16 range, which is none existant! Shame on the protocoll!

Router 1

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.16.1.0      *               255.255.255.0   U     0      0        0 eth0
	172.16.0.0      10.0.0.2        255.255.0.0     UG    2      0        0 eth1
	10.0.0.0        *               255.0.0.0       U     0      0        0 eth1

Router 2

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.16.2.0      *               255.255.255.0   U     0      0        0 eth0
	172.16.0.0      10.0.0.1        255.255.0.0     UG    2      0        0 eth1
	10.0.0.0

Router 3

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.16.2.0      *               255.255.255.0   U     0      0        0 eth1
	172.16.1.0      *               255.255.255.0   U     0      0        0 eth0
	172.16.0.0      172.16.2.2      255.255.0.0     UG    3      0        0 eth1
	10.0.0.0        172.16.2.2      255.0.0.0       UG    2      0        0 eth1

Now, let`s try that again with the RIPV2 config files: the RIP config file for router 1 RIPV2, the RIP config file for router 2 RIPV2 and the RIP config file for router 3 RIPV2

Router 1

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.16.2.0      10.0.0.2        255.255.255.0   UG    2      0        0 eth1
	172.16.1.0      *               255.255.255.0   U     0      0        0 eth0
	10.0.0.0        *               255.0.0.0       U     0      0        0 eth1

Router 2

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.16.2.0      *               255.255.255.0   U     0      0        0 eth0
	172.16.1.0      10.0.0.1        255.255.255.0   UG    2      0        0 eth1
	10.0.0.0        *               255.0.0.0       U     0      0        0 eth1

Router 3

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.16.2.0      *               255.255.255.0   U     0      0        0 eth1
	172.16.1.0      *               255.255.255.0   U     0      0        0 eth0
	10.0.0.0        172.16.1.1      255.0.0.0       UG    2      0        0 eth0

Wahoo! Go RIPV2!

Now then, up to the topology with four routers and a host. Here`s the rip perl script, the RIP config file for router 1 RIPV1, the RIP config file for router 2 RIPV1, the RIP config file for router 3 RIPV1 and the RIP config file for router 4 RIPV1

The routing tables with RIPV1 look like:

Router 1

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.17.16.0     *               255.255.240.0   U     0      0        0 eth0
	172.17.0.0      10.0.0.2        255.255.0.0     UG    2      0        0 eth1
	10.0.0.0        *               255.0.0.0       U     0      0        0 eth

Router 2

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.17.40.0     *               255.255.248.0   U     0      0        0 eth0
	172.17.0.0      10.0.0.1        255.255.0.0     UG    2      0        0 eth1
	10.0.0.0        *               255.0.0.0       U     0      0        0 eth1

Router 3

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.17.52.0     *               255.255.252.0   U     0      0        0 eth0
	172.17.0.0      10.0.0.1        255.255.0.0     UG    2      0        0 eth1
	10.0.0.0        *               255.0.0.0       U     0      0        0 eth1

Router 4

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.17.64.0     *               255.255.255.0   U     0      0        0 eth0
	172.17.0.0      10.0.0.3        255.255.0.0     UG    2      0        0 eth1
	10.0.0.0        *               255.0.0.0       U     0      0        0 eth1

As we can see, the routers just throw all the data in the 172.17.0.0/16 range to another router advertising a part of this range. Shame on RIPV1 again!
Below is a traceroute from the monitor host, using 10.0.0.1 as default router:

Traceroute to 172.17.40.2

	root@host1[17]:/ $traceroute 172.17.40.2
	traceroute to 172.17.40.2 (172.17.40.2), 30 hops max, 40 byte packets
	1  10.0.0.1 (10.0.0.1)  0.8 ms  0.638 ms  0.635 ms
	2  172.17.40.2 (172.17.40.2)  1.13 ms  1.508 ms  0.934 ms

Since this route accidentally matches (Router1 sends all data it can't route to Router2) this route is fine. But when we try to reach Router3:

Traceroute to 172.17.52.3

	traceroute to 172.17.52.3 (172.17.52.3), 30 hops max, 40 byte packets
	1  10.0.0.1 (10.0.0.1)  1.627 ms  0.907 ms  0.852 ms
	2  10.0.0.2 (10.0.0.2)  2.212 ms  1.094 ms  1.188 ms
	3  10.0.0.1 (10.0.0.1)  1.272 ms  1.114 ms  1.263 ms
	4  10.0.0.2 (10.0.0.2)  1.428 ms  1.422 ms  1.39 ms
	5  * 10.0.0.1 (10.0.0.1)  1.986 ms  1.99 ms
	6  10.0.0.2 (10.0.0.2)  2.196 ms  2.391 ms  2.645 ms
	7  10.0.0.1 (10.0.0.1)  2.357 ms  2.178 ms  2.165 ms
	8  10.0.0.2 (10.0.0.2)  2.369 ms  3.161 ms *
	9  10.0.0.1 (10.0.0.1)  3.453 ms  3.177 ms  3.267 ms
	10  10.0.0.2 (10.0.0.2)  3.497 ms  3.388 ms  3.25 ms
	11  10.0.0.1 (10.0.0.1)  3 ms  3.563 ms *
	12  10.0.0.2 (10.0.0.2)  3.251 ms  3.442 ms *
	13  10.0.0.1 (10.0.0.1)  3.352 ms  3.252 ms *
	14  10.0.0.2 (10.0.0.2)  4.066 ms  3.951 ms  3.861 ms
	15  10.0.0.1 (10.0.0.1)  3.569 ms  4.072 ms  3.857 ms
	etc.

As we could already predict, Router1 messes this up, since it just wants to throw all data to Router2, which in it`s turn throws it back again to Router1. Therfore we have a routing loop! Bottom line: The protocoll doesn't work in this topology.

With RIPV2 the RIP config file for router1 RIPV2, the RIP config file for router 2 RIPV2, the RIP config file for router 3 RIPV2 and the RIP config file for router 4 RIPV2 they look like:

Router 1

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.17.64.0     10.0.0.4        255.255.255.0   UG    2      0        0 eth1
	172.17.52.0     10.0.0.3        255.255.252.0   UG    2      0        0 eth1
	172.17.40.0     10.0.0.2        255.255.248.0   UG    2      0        0 eth1
	172.17.16.0     *               255.255.240.0   U     0      0        0 eth0
	10.0.0.0        *               255.0.0.0       U     0      0        0 eth1

Router 2

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.17.64.0     10.0.0.4        255.255.255.0   UG    2      0        0 eth1
	172.17.52.0     10.0.0.3        255.255.252.0   UG    2      0        0 eth1
	172.17.40.0     *               255.255.248.0   U     0      0        0 eth0
	172.17.16.0     10.0.0.1        255.255.240.0   UG    2      0        0 eth1
	10.0.0.0        *               255.0.0.0       U     0      0        0 eth1

Router 3

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.17.64.0     10.0.0.4        255.255.255.0   UG    2      0        0 eth1
	172.17.52.0     *               255.255.252.0   U     0      0        0 eth0
	172.17.40.0     10.0.0.2        255.255.248.0   UG    2      0        0 eth1
	172.17.16.0     10.0.0.1        255.255.240.0   UG    2      0        0 eth1
	10.0.0.0        *               255.0.0.0       U     0      0        0 eth1

Router 4

	Kernel IP routing table
	Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
	172.17.64.0     *               255.255.255.0   U     0      0        0 eth0
	172.17.52.0     10.0.0.3        255.255.252.0   UG    2      0        0 eth1
	172.17.40.0     10.0.0.2        255.255.248.0   UG    2      0        0 eth1
	172.17.16.0     10.0.0.1        255.255.240.0   UG    2      0        0 eth1
	10.0.0.0        *               255.0.0.0       U     0      0        0 eth1

Here, RIPV2 saves the day again! Since RIPV2 knows subnetting, and not just an A, B or C range, this protocoll is obvious superior to it`s previous version.
Let's try some traceroutes:

Traceroute to 172.17.40.2

	traceroute to 172.17.40.2 (172.17.40.2), 30 hops max, 40 byte packets
	1  10.0.0.1 (10.0.0.1)  1.186 ms  0.643 ms  0.597 ms
	2  172.17.40.2 (172.17.40.2)  1.335 ms  1.006 ms  0.855 ms

This route works fine, now let's try the one that didn't work with RIPV1:

Traceroute to 172.17.52.3

	traceroute to 172.17.52.3 (172.17.52.3), 30 hops max, 40 byte packets
	1  10.0.0.1 (10.0.0.1)  0.909 ms  0.817 ms  0.748 ms
	2  172.17.52.3 (172.17.52.3)  2.419 ms  1.182 ms  1.116 ms

This one also works fine now!

Final thought: As we could clearly see in this excersise, RIPV1 is a protocol that only understands the concepts of a "Type A", "Type B" and "Type C" network. If a part of a smaller network i.e. /23 /19 etc. is advertised on a router, the protocol will think it can send all te data to it, corresponding with the A B or C type network. RIPV2 has knowledge about the CIDR netmarking capabilities and is therefore superior.

Assignment for Friday, March 4, 2005:

Connect an extra host (sniffer) to all networks and run tcpdump. Log the traffic for a specific period.
Analyse the tcpdump and look at the configuration of three bridges in parallel and 3 bridges in triangle shape
Look at the BPDU packets. What timing parameters are used?
What happens at a topology change? What happens when the root bridge fails?

First of all, storing data can by done by mounting the homedir on your host like this:

	mount none /home -t hostfs -o /home/%username%

Here`s the triangle STP config file and here's the parallel STP config file

I will be doing various measurements using the first config. Starting STP on a host can be done by entering:

	brctl stp br0 on

Some logfiles gathered: Log starting up all bridges, a log when bridge1 has failed and a log when bridge2 and bridge3 fight for domination!
Just by grabbing a line we can learn quite a bit:

	802.1d config 8000.fe:fd:0a:00:01:02.8001 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15

The max age is 20
The hello time is 2
The forward delay time is 15

What wee see happening in the logs are the following things:

The first router just keeps transmitting hello
As soon as the next router comes online, they will start a topoligy change
Some paths will be set to blocked state, with the pathcost 100 value
A TOP_CHANGE TOP_CHANGE_ACK is send, confirming the new topology
We have to wait for twice the forward delay time.....
The TC has ended, and forwarding starts

Some other nice snapshots for the album:

STP starting with some topology changes (new bridge is found), first bridge 1 just says hello in the dark, but the moment bridge2 comes alive, a TC takes place

        17:26:03.069893 802.1d config 8000.fe:fd:0a:00:01:02.8001 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15 
	17:26:03.069953 802.1d config 8000.fe:fd:0a:00:01:02.8002 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15 
	17:26:03.070001 802.1d config 8000.fe:fd:0a:00:01:02.8002 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15 
	17:26:03.070255 802.1d config 8000.fe:fd:0a:00:01:02.8002 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15 
	17:26:03.070309 802.1d config 8000.fe:fd:0a:00:01:02.8001 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:26:03.070359 802.1d config 8000.fe:fd:0a:00:01:02.8001 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:26:04.069693 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:02.8001 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:26:04.069926 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:02.8001 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:26:04.889700 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:03.8001 root 8000.fe:fd:0a:00:01:02 pathcost 100 age 1 max 20 hello 2 fdelay 15

Acknowledgements of the topology changes

	17:26:34.059788 802.1d config TOP_CHANGE TOP_CHANGE_ACK 8000.fe:fd:0a:00:01:04.8001 root 8000.fe:fd:0a:00:01:02 pathcost 100 age 1 max 20 hello 2 fdelay 15
	17:26:34.069645 802.1d config TOP_CHANGE TOP_CHANGE_ACK 8000.fe:fd:0a:00:01:02.8001 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15

The root bridge gets shut down and a new one is elected

	17:29:35.069972 802.1d config 8000.fe:fd:0a:00:01:03.8002 root 8000.fe:fd:0a:00:01:02 pathcost 100 age 0 max 20 hello 2 fdelay 15
	17:29:55.050764 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:03.8001 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:29:55.050826 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:03.8001 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:29:55.050882 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:03.8002 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:29:55.051385 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:04.8002 root 8000.fe:fd:0a:00:01:04 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:29:55.051445 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:04.8002 root 8000.fe:fd:0a:00:01:04 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:29:55.051522 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:04.8001 root 8000.fe:fd:0a:00:01:04 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:29:55.051556 802.1d tcn
	17:29:56.049907 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:03.8001 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:29:56.049961 802.1d config TOP_CHANGE TOP_CHANGE_ACK 8000.fe:fd:0a:00:01:03.8002 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:29:56.049996 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:03.8001 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:29:57.049928 802.1d tcn
	17:29:57.049980 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:03.8001 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:29:57.050235 802.1d tcn
	17:29:57.050444 802.1d config TOP_CHANGE 8000.fe:fd:0a:00:01:03.8002 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15

The old root bridge comes back up and fights for power!

	17:31:59.049740 802.1d config 8000.fe:fd:0a:00:01:03.8001 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:31:59.049794 802.1d config 8000.fe:fd:0a:00:01:03.8002 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:31:59.050084 802.1d config 8000.fe:fd:0a:00:01:03.8001 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:32:01.049954 802.1d config 8000.fe:fd:0a:00:01:03.8001 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:32:01.050010 802.1d config 8000.fe:fd:0a:00:01:03.8002 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:32:01.050072 802.1d config 8000.fe:fd:0a:00:01:03.8001 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:32:03.049889 802.1d config 8000.fe:fd:0a:00:01:03.8001 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:32:03.049917 802.1d config 8000.fe:fd:0a:00:01:02.8002 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:32:03.049970 802.1d config 8000.fe:fd:0a:00:01:03.8002 root 8000.fe:fd:0a:00:01:03 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:32:03.069693 802.1d config 8000.fe:fd:0a:00:01:02.8001 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:32:03.070018 802.1d config 8000.fe:fd:0a:00:01:04.8001 root 8000.fe:fd:0a:00:01:02 pathcost 100 age 0 max 20 hello 2 fdelay 15
	17:32:04.049743 802.1d config 8000.fe:fd:0a:00:01:02.8002 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15
	17:32:04.049911 802.1d config 8000.fe:fd:0a:00:01:03.8002 root 8000.fe:fd:0a:00:01:02 pathcost 100 age 1 max 20 hello 2 fdelay 15
	17:32:05.049767 802.1d config 8000.fe:fd:0a:00:01:03.8002 root 8000.fe:fd:0a:00:01:02 pathcost 100 age 1 max 20 hello 2 fdelay 15
	17:32:05.069806 802.1d config 8000.fe:fd:0a:00:01:02.8001 root 8000.fe:fd:0a:00:01:02 pathcost 0 age 0 max 20 hello 2 fdelay 15

Assignment for Friday, February 25, 2005:

I have been busy all day getting Config2 to work, but the configuration is not possible since VNE will not work with it, the host2 interface will be disabled when all connections are enabled. Trying to get it to work, I ran out of time. This was also due to the slow response of our pisa server, which obviously couldn't cope with all of us working at the same time. Config file 1 Config file 2
Later on, I have added these configurations: (Stolen and slightly modified from Arjan Dekker) Config file 3 Config file 4 Config file 5 Config file 6 Config file 7 Config file 8 Config file 9
I also added a config with a Router:Config file 1 with Router

And a config, made by Wouter Borremans and me: here.

Assignment for Friday, February 18, 2005:

I got the UML program working, and tested basic functionality.

User-Mode Linux is a safe, secure way of running Linux versions and Linux processes. Run buggy software, experiment with new Linux kernels or distributions, and poke around in the internals of Linux, all without risking your main Linux setup.
User-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. You can assign your virtual machine only the hardware access you want it to have. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software.

Main documentation @ sourceforce

Assignment for Tuesday, February 15, 2005:

How to apply for IPv4 -- Get it at a local ISP (This ISP is a RIPE member)
How to get IPv6 addres space -- The first way is to become a RIPE member -- The second is to get it from your local ISP
How to apply for your own domain name? -- The TLD`s (top level domains) you can register with an ISP. These ISP`s then register these domains with the TLD authority. This authority is different for each TLD. A .NL domain is managed by SIDN.
How to get your own IPv4 and IPv6 address space for OS3? -- SNB is an educational instance and has SURFnet as hosting provider. SURFnet is a RIPE member, so by contacting SURFnet, they can apply at RIPE for IPv4 and IPv6 address space. For IPv6 space, some extra requirements are set:

You must be an Local Internet Registry with the RIPE NCC;
You can not be an end site;
You must plan to provide IPv6 connectivity to organisations to which it will assign /48s, by advertising that connectivity through its single aggregated address allocation;
You must show that you plan to make 200 or more /48 assignments to End Users' sites within 24 months of receiving the allocated IPv6 address space;
You must submit your request using the RIPE document Initial IPv6 Allocation Request Form in the RIPE NCC Service Region.

Assignment for Friday, February 11, 2005:

Assignment week 1
Since this report was first posted, due to backup issues, I lost the source of the PDF. The lab assistant had some comments which I will address here:

"IANA doesn't oversee the operation of DNS. Correct me if I am wrong." --IANA does do this, but now it is under the ICANN concern:link
"ICANN: Some of the tasks mentioned fall into the responsibility of IANA (which is now a part of ICANN) and some don't." -- This is true because IANA now continues under the ICANN name, it`s tasks will be migrated to the mother organisation.
"IEEE: Could an example be given of a standard which is related to Internet" -- Here is a whole list of standards the IEEE has contributed.
"RIPE: RIPE NCC doesn't administer European domain names. RIPE NCC doesn't only operate in Europe. Correct me if I am wrong." -- RIPE-NCC hands out and manages IP addresses within europe. RIPE on it`s self hands out IP`s for the middle east and pieces of Africa.
"IETF: What is important task of this entity in relation with Internet standards (RFC's) ?" --It is a thinking tank which has verified and approved numerous RFC`s and organizes meeting about new RFC`s. It also has a large community.