OSPFRevisited

This page exists as a depository for paraphrased conversation from the mailing list, to allow a more permanent record of the discussion.

Background Information & Dan's Suggestion

OSPF is an interior routing protocol. An interior routing protocol is one that is designed to be used within a single Autonomous System. An Autonomous System is a network or group of networks under a common administration and with common routing policies.

The Melbourne Wireless Network has a common routing policy, but it can not be said to be an Autonomous System, because it is not under a common administration. No one person or team of persons has administrative privileges (i.e. root access) to all of the routers on the entire Melbourne Wireless network. To function properly - in a way that is truly scalable, OSPF requires this.

OSPF requires that the network topology grow under the control of an administrative body - which then assigns nodes to a backbone and,
optionally, to other 'areas'. The Melbourne Wireless network grows organically. An administrative body, if there was one, has no real
control as to which nodes and areas will connect to which, and after the network reaches a certain size, assigning nodes to OSPF areas after the fact is messy and impractical - the administrative body would have to make requests to node-owners to change their configuration - and rely on the node-owners to do the changes properly and in a timely manner. This is not a good solution for a network based on volunteers, most of whom are not network engineers.

OSPF has strict requirements - the backbone area must be connected, and all other areas must connect directly to the backbone. However, as we've seen over the past couple of years, the network will grow in ways that don't necessarily meet OSPF requirements.

Through the use of LocFinder we have automated IP and OSPF area allocation, which forms our Routing Policy. But for OSPF to work, a single administrative body would need to control all routers to continuously redefine backbone routers, virtual-links and shortcut-areas, as links between non-backbone-areas appear and disappear. Individual node-owners or Regional Groups are not allowed
the chance to define their own routing policy under such a system. In a community network, they should be allowed this chance - to be Autonomous Systems unto themselves.

I believe we need to use an exterior or 'interautonomous system' routing protocol as the main routing protocol, such as BGP. If and when a true backbone appears, under the control of a single administrative body, it should use an interior routing protocol, such as OSPF alongside iBGP. Region Group clusters can also form their own local backbones and run OSPF or any other routing protocol they deem appropriate as a regional Autonomous System. The use of OSPF areas other than area 0 should probably be discouraged as this adds a layer of administrative complexity, and in any case, a regional AS probably would probably not get big enough to warrant it.

The Melbourne Wireless network would then be seen as a network of many Autonomous Systems, all speaking eBGP to each other at their gateways. This is exactly how the Internet itself functions, and it has shown itself to be highly scalable. Regional Autonomous Systems, or even individual nodes acting as an AS on their own, could view the rest of the network as a "cloud" - ignorance is bliss - and let the exterior routing protocol take care of things. There would be no need for the routers in one AS to know about the link-states (and therefore the network topology) in another AS.

How do we cope with mobile laptops?

Laptops aren't likely to be routing nodes. Short of running some intelligent mesh routing protocol, it would be easiest for mobile devices to instead be plain client nodes that associate with an AP whenever convenient. -- TonyLangdon
DHCP copes with it all, as long as a user doesn't expect to have the same IP address at each location. It is possible we could run a dynamic DNS system if you wanted people to be able to reach you no matter where you were on the network -- DanFlett

What if I don't have a PC/capable AP to do routing?

You could use static routes, which will work fine for a handful of nodes. However, it requires effort to enter and maintain routes -- MarkAitken
You might be able to get away with no routing protocol, especially with all the nodes in the same subnet although this may degrade network performance due to broadcast traffic. However, if you're connecting to the greater MelbWireless Network, you'll probably want a border router running an OSPF daemon to advertise your net's existance. Again, you'd have to use static routes. Small cheap, routers like the WRT54G might be (or in fact, are ) the solution. --DanFlett
When connected to one or two nodes, you can often defer the more complicated routing to upstream nodes. If you have one link, it is your default route. If you have two, setup static routes for each and choose the default. The WRT54G does solve a lot of issues

Other Implementations

Nick Grundy, Hobart Wireless

Down in Hobart we've gone with BGP accross our entire network. We initally tried OSPF about 2 years ago now but it caused major headaches with regards to running stable. Quite a few times we had the ospf daemons silently die but I think that was mostly due to multicast issues.

At the moment we have around 9 or 10 AS on our network a map can be seen External link

here We've been lucky in that our network has grown as a single entity with no disconnected segments. Our assignment of AS is fairly ad-hoc and no where near optiomal due to learning BGP while setting it up but that's what it's all about in our books, experimentation.

From a keeping the shit running point of view BGP makes much more sence. Within a region or whatever you can run ospf/rip/eigrp (if you're made of money

etc but to get back into the main network you need to talk BGP and redistribute your IGP into the EGP. It just so happens that our entire network uses an EGP well iBGP

Config is fairly simple

router bgp 64512
redistribute connected
neighbor 192.168.4.9 remote-as 64516
neighbor 192.168.4.9 soft-reconfiguration inbound
neighbor 192.168.4.22 remote-as 64512
neighbor 192.168.4.22 next-hop-self
neighbor 192.168.4.22 soft-reconfiguration inbound

we set next-hop-self on iBGP sessions because we use /30 point to point links. This came about due to the network starting off as an ad-hoc card to card arangement we could move to adding subnets to aps and assigning like that but it's never happend.

no need to set next-hop-self on eBGP links as that happens automaticly when you cross an AS.

we don't run BGP on every node we only install it on a non endpoint node. ie the site generally has an uplink and an omni and for end users that don't have a second interface we add a static route and redistribute static.

Quite a few of our routers these days are Linksys WRT54G's i think we've gone from 0 to 9 of these units in around 2 months. we use quagga on these units to do all of our routing and interface configuration the only IP that is hard coded into the unit is the LAN interface ip in NVRAM other than that they all come from zebra.conf or via bgp.

Quagga List discussion

Links

Version 2 (old) modified Mon, 26 Jul 2021 12:49:29 +0000 by Dan

[EditText] [Spelling] [Current] [Raw] [Code] [Diff] [Subscribe] [VersionHistory] [Revert] [Delete] [RecentChanges]

Node Statistics
building	132
gathering	193
interested	515
operational	233
testing	214