OSPF stable?

[Skaught]

Lonnie Said:
"Sure we tried it as well, and found as you did, that it is flakey. I thought the point was to not be flakey, and therefore you must use neighbour statements for OSPF when using Atheros."

So if we use neighbour statements it is 100% stable? Even if the clock is not right? (as the NTP cannot update until the routes are all working)

[lonnie]

Nothing is 100% stable. Surely you know that by now and I wonder why you would even ask such a thing.

The posting said that neighbour statements takes the flakiness out of neighbour issues. Nothing more, nothing less. Of course neighbour statements will not fix any NTP issues. Surely you already knew that or should have figured it out and I question why you would ask such a thing.

There is no magic here. You address issues with targeted solutions. There is no magic silver bullet that fixes all known issues.

[bairdc]

No, it isn't 100% stable. I've got neighbor statements on all my Atheros links because I've found that it is extremely flaky if you don't have them. However, having the neighbor statements doesn't resolve the problem entirely.

Craig

[bminish]

Lonnie Said:
"Sure we tried it as well, and found as you did, that it is flakey. I thought the point was to not be flakey, and therefore you must use neighbour statements for OSPF when using Atheros."

So if we use neighbour statements it is 100% stable? Even if the clock is not right? (as the NTP cannot update until the routes are all working)


It's not stable, there is at least one outstanding issue that causes OSPF to loose awareness of directly attached Atheros interfaces following a reboot or 'apply changes'

Also do NOT use NTP since it will cause a clock jump when it updates the time and this will do all sorts of unpredictable things to your routing. OSPF does not care about real world time nor does it exchange real world time with it's neighbours.
It uses the system clock to keep track of how old information is in the link state database. Any jumps in the system clock will cause problems here.

running ntpd on a linux box with a battery backed hardware clock is an entirely different story, ntpd avoids clock jumps by 'drifting' the clock back towards the correct time over a long period of time.

Also the default staros OSPF config has a bunch of redistribute statements on by default, remove these (unless you have an explicit need for one of them of course) redistribute kernel is particularly problematic.

.brendan