OSPF plodding on

Well, finally starting to get over my cold, and managed to get in early yesterday and today and spend a few hours on OSPF before the day starts.

I am still working on the database exchange process. I almost have it working (well, far end thinks we have done the exchange, so a start).

It is messy, but getting there. Once I have the database exchange sorted, I have to sort the "flooding" logic. This will then mean we have, and maintain, the OSPF link state advertisement database.

There are a few gotchas that I can see. The way entries are withdrawn is, err, fun. You mark them as old (a hour) and ensure everyone has seen that, then remove it. That is not too bad, but it is a problem if you want to change your mind and now announce the entry again. You sort of have to wait for it to all be removed before re-creating it. You are supposed to cater for a 32 bit sequence wrapping as well, in a similar way. There is another related gotcha in that you are not allowed to update an LSA more often that a certain rate. Well, what if you have changes faster than that? You are meant to delay them. That sort of means storing a current version, and a "new version" in the database and a process to pick up that we want to move to a new version after a delay. That sort of crap is horrid - who makes a protocol like that? Just saying in the text of the RFC "delay" sounds so simple doesn't it - but delay means storage and timers and tasks.

I suspect that I will have to have a pending "new version" for any LSA we originate, and a task to pick up when to move to it. Arrrrg!

So, next milestone is full database synchronisation, not just exchange and loading, but flooding (as designated router, backup router and other router).

Once the database synchronisation is sorted there are a couple more jobs to do.

The first is that we have to originate stuff. I am, for now, trying to just originate our own router LSA, which is a single, and relatively simple, LSA for us as a router. Even that is a pain as it has to update on any change to any links, even just designated router changing. We'll have to also originate a network LSA where we are the designated router for a subnet. That should not be a lot more complex.

Then we have to ensure we originate LSAs for external routing, e.g. connected networks like L2TP links, BGP routes, and so on, subject to various filtering logic. The current design makes it very easy for the OSPF subsystem to track any core routing changes, and effectively get events for adding, changing or removing external routing LSAs. Once again the issue of changes being too fast, and withdrawing routes, but that will have to be solved first.

So that is a milestone of maintaining LSAs that we originate.

Finally, after that, we have the simple job (!) of working out shortest path and injecting routes in to the core routing table. To be honest that is not too scary. We have a simple interface for injecting routes and removing them, which then ensures the routes propagate as needed (e.g. via BGP is required) and update the forwarding logic. There is a minor special case for equal path routing, but we have several systems for that in place already for bonding, so taking multiple OSPF targets an routing to them as a set is not a major change.

So, final milestone is working OSPF!

Once we have that we have a single area OSPF router and have loads of testing to do. Making it multi-area may come later, or may fall out of the database work anyway, not sure yet.

All good fun.