gistfile1.txt

The HaDiNet network interconnects roughly 1000 student rooms, currently using a single LAN. This network will now be upgraded to give each user a separate /29 IP subnet routed to his room. In the case that users require larger subnets, it should be easy to route another subnet to a room. Therefore, management software is required to configure the network.

Currently, the HaDiNet uses a star topology, with the core switch situated in the K3 building and other routers connected to it with 1Gbit fiber links. However, interconnection of the edges of this star is planned. Soon, all switches will be able to route IP packets. Essentially, they are giant routers with enormous backblane and routing capacity (at least to me, being a network newbie, it's pretty impressive).

In a perfect world, the central management software would put each room into a separate VLAN, attach the router closest to the actual room to that VLAN (basically, let the switch that the port leading to the room is on also be the gateway router for that VLAN) and insert a route into its routing table indicating that this network is "connected" (wich happens automatically when the swithc is configured as a gateway for that network). To enable not only subnets that this switch is a gateway for to talk to eachother, the switch has to distribute the routes to its connected room subnets to the other switches. It uses OSPF to talk to the other switches (as I invision this right now, all that is requires is a single backbone area, a very simple OSPF deployment really). Now, every switch knows its locally connected subnets and for each of the other room subnets knows which switch they are directly connected to. The "core switch" is a pure layer 2 switching device in this model.

Now, the reality is more complicated. All but three of the routers are OSPF-capable. However, these three routers also somehow have to make their connected room subnets known to the other routers, without using OSPF. The solution is to convert the core switch (that in the OSPF-only model merely interconnects the edge routers) to a layer 3 router. This router is OSPF enabled. When configuring a subnet on one of the non-OSPF edge routers, the centralized management software now also inserts a new entry into the static routing table of the core router, indicating that the next hop to that room subnet is the edge router "directly connected" to that room. The core router then distributes that route to the OSPF-capable edge routers, causing them to insert an entry into their routing table indicating the core router as the next hop to that room subnet. Now, when a packet is sent to that subnet, instead of routing it directly to the correct edge router, the packet is first routed to the core router which then forwards it to the correct non-OSPF-enabled edge router. It should be mentioned that the core router only supports up to 256 static routes which means that a maximum of 256 rooms can be configured using this "trick". Distributing the licenses to the larger switches and leaving the small switches with fewer connected rooms without OSPF capability allows the HaDiNet to stay well below this limit.

Non-OSPF-enabled edge routers somewhat stupid: They simply route all their traffic to the core router, which knows the routes to all the other subnets (either through a statically configured route to a non-OSPF-enabled router or a route learnt through OSPF). Obviously, traffic between rooms connected to the same switch never leaves the switch and is delivered using a "connected" route in the internal routing table.