OSPFArchitecture
Whilst the Melbourne Wireless network is in it's current form - small clusters of connected computers - city wide routing isn't really a problem. It's fine to just use static routes, and add/remove them as needed.
However, as soon as these clusters start to link (which will be happening soon), we're going to start running into problems. Nodes will go up and down, routes will change, and connecting over any distance will be impossible.
For this reason, the WGRoutingAddressing working group has looked at a bunch of routing protocols to find which one suits our needs best, and OSPFv2 has come out as the best of a bad lot.
I say bad lot, since there really isn't any mesh routing protocol that is mature, stable, and scalable to a city size, so the remaining options are designed for a network as complex as ours will be.
OSPF was chosen as it has the following key attributes:
- supports CIDR
- efficient routing information distribution
- link state based protocol does not suffer problems like distance vector based
- features such as areas allow for hierarchy within the IGP
Note: Melbourne Wireless has reserved the IP address ranges 172.16.80.0/20 and 10.10.0.0/16 as described in address allocation. As a result these addresses are used as an example.
HELP: If, after reading this page you need some help with your OSPF setup, check out Help
So how does it work?!
Melbourne has been divided up into - initially - 11 geographic areas. We have left ip space to create more areas in the future if need be.
To join the network, every node must choose a region to place themselves in. This isn't as simple as where you are on the map, as it's based on netwrok conectivity. Obviously this will be roughly geographic (since nodes near each other will connect to eachother), but you may find that geographically your in one area, but you have better LOS to a neighbouring area - in which case choose the area you have better LOS to.
As well as choosing an Area, each node must decide what OSPF mode it is going to run in. This is where things start to get a bti complicated!
So straight away, your either not running OSPF (a regular node), or you are (a routing node)
Regular Nodes
none
The most basic OSPF mode, is none. Initially, we expect most nodes will fit this mode. Quite obviously, this means your not running OSPF (either because you don't know how, or don't need to, or whatever). Routes for these nodes will be static, so they will probably have 1 connection upstream, and the node they're connected to will be their default route.
The upstream node is then responsible for handling how your traffic gets to where its supposed to go, and you don't really care how that happens.
There could conceivably be a chain of nodes, all with default routes upstream to a single node that then runs OSPF, and this would work fine. As long as everyone down the chain sets their defult route upstream, and all traffic eventually reaches the node running OSPF.
Like all nodes, this node is entitled to a block of 16 ip addresses from 10.10.x.x, to be used how they see fit.
Routing Nodes
internal area router
An internal area server is a server that routes traffic around the inside of an area. (der..)
It would more than likely have at least 2-3 p2p links with other internal area routers, and most importantly, it tells each of its neighbouring routers what ip addresses it can see. This happens on a fairly regular basis, so if someone driving by happens to connect, or a new node goes operational, they will be able to connect to and from distant nodes.
Besides is allotment of 16 10.10.x.x addresses, this node type, as well as the other routing nodes, will be assigned _1_ address from 172.16.80/20 for each p2p interface that links to another routing node.
area border router
Ok. So if i try to connect to another node in Area 4, the interal area routers will handle it and make sure my data gets to where its going - but what about if i want to connect to somebody in a different area?
Area border routers are very similar to internal routers, but they bridge 2 or more areas. They know that all IPs from a given area fall into a certain range, and will redirect the traffic accordingly.
Again, like internal area routers, they get their own 10.10.x.x block, and a single address from 172.16.80/20 for interfaces that link to other routing nodes.
Importantly, although area border routers are located in an area, and all their interfaces that link to internal area routers area use that area, an interface that links to another area border router, be it another area border router inside the home area, or in another area, are assigned area 0.
These links are referred to as backbone links.
Anytime your data has to travel across several areas, once it enters the backbone from an area border router in your area, it must stay on it until it gets to the destination area. For this reason, the backbone links need to be as fat and reliable as possible - see Bandwidth for more discussion on this issue
system border routers
these aren't all that different to area border routers, except that they link to networks that aren't a part of MelbWireless. For example, another Community Wireless group, or whatever. (providing the address space doesnt clash with ours).
The routes to these other networks can be discovered via any protocol, and are then boradcast onto the MelbWireless network using OSPF.
Addressing is the same as for area border routers, and the same rules apply for classing links as backbones. Any interface that links to another system border router or an area border router is classed as a backbone, and is a part of Area 0.
Version 1 (current) modified Mon, 26 Jul 2021 12:49:29 +0000 by
graybeard [EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]