Navigation
Standards compliant

valid XHTML 1.0!

valid CSS Level 2!

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:

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
	
What wee see happening in the logs are the following things:
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 3Config file 4Config file 5Config file 6Config file 7Config file 8Config 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.
Main documentation @ sourceforce

Assignment for Tuesday, February 15, 2005:

  1. You must be an Local Internet Registry with the RIPE NCC;
  2. You can not be an end site;
  3. 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;
  4. 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;
  5. 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: