Time Server

[Equis]

Hello

I have OSPF that works well untill I reboot one Wrap
After that OSPF stops untill & reboot most wraps in the network.

I was thinking this my be a time problem as the wraps can't see the time server till they have routes, so wraps have way different times (A chicken and the egg thing)

I was thinking of adding static routes on my backhaul only so all wraps can see time server at my NOC
Then I would let OSPF handle all other routes & the default route

Does this sound like it work work?

Thanks

:)

On thinking more, perhaps I could just have static routes to my time server and nothing else?

[bminish]

Hello

I have OSPF that works well untill I reboot one Wrap
After that OSPF stops untill & reboot most wraps in the network.

I was thinking this my be a time problem as the wraps can't see the time server till they have routes, so wraps have way different times (A chicken and the egg thing)

I was thinking of adding static routes on my backhaul only so all wraps can see time server at my NOC
Then I would let OSPF handle all other routes & the default route

Does this sound like it work work?

Thanks

:)

On thinking more, perhaps I could just have static routes to my time server and nothing else?


Why use the timeserver at all?
Clock jumps do bad things to OSPF and enabling NTP will break things on occasion.

How exactly have you configured OSPF and which version of quagga are you using?
The default staros OSPF configuration is fundamentally broken and that may have a part in it too

If you don't need OSPF then you probably should not run it at all, there is a serious bug with OSPF in staros V2. take a look at the bug related thread

.brendan

[tony]

What would you have changed in the default OSPF configuration? This is the first time I've heard about it being broken.

Thanks!

[Equis]

Hello,

I use thing because WRAPs have not battery, on reboot time is wrong.

I need OSPF for my network (badly) I'm using the latest V2.

It seems sort of to work well untill a reboot.

I will be replacing my WRAP's for War's or something else anyway.

My setup is default with added networks

Thanks :-)

[Equis]

What would you have changed in the default OSPF configuration? This is the first time I've heard about it being broken.

Thanks!


Hi Tony,

I thought it was a known bug in V2?

It does work most of the time, just a reboot breaks it sometimes

[bminish]

What would you have changed in the default OSPF configuration? This is the first time I've heard about it being broken.

Thanks!

Take out the redistributes, all of them. In particular redistribute kernel can cause issues. Only add back the redistributes that you are sure you need

We covered all this very well over a year ago when we first showed how to get OSPF working. I also recommended these changes to Lonnie on a couple of occasions as being a good idea for future releases
.brendan

[Equis]

No Worries, Will do

The Redistribute Connected can stay? what does that mean?
It sounds like it means the networks that are directly connected to the interface but I remember you (I think) telling me that you still have to add the network statements.

Thanks for all your help :)

[bminish]

Hello,

I use thing because WRAPs have not battery, on reboot time is wrong.

OSPF does not care a whit about what time it is in the outside world, it does however use the system clock for keeping track of the age of the routing database since it is keeping track of time over periods of minutes. If the Clock just runs and is running at a rate that is within a few percent of real time you will have no issues, OSPF only uses time locally

If you enable NTP the following happens.
routers get happy and exchange routes, routing comes up. then NTP sets clock which results in a clock jump of years. OSPF goes funny, routes break again

recent Quagga versions usually recover quite quickly from jumps into the future, jumps backwards are another story since you end up with negative ages in the link state database.
The Zebra routing daemon is much less forgiving of clock jumps and will usually die badly with any clock jump. Older versions of staros use zebra


I need OSPF for my network (badly) I'm using the latest V2.
It seems sort of to work well untill a reboot.

there are other bugs, please see the bug thread to see if the symptoms match (OSPF loosing awareness of directly attached atheros interfaces on occasion)


I will be replacing my WRAP's for War's or something else anyway.

Lonnie is laying all blame with the Quagga developers, I take it that this means that it's broke in V3 as well then.


My setup is default with added networks

please be more specific, copy in some configs and I'll take a look tomorrow

.brendan

[tony]

Thanks Brendon. The defaults are not really intended to be used as-is, however the redistribute items should be removed from the defaults as you say. I will ensure this is done for both V2 and V3 releases.

[tony]

Lonnie is laying all blame with the Quagga developers, I take it that this means that it's broke in V3 as well then.

Lonnie is referring to the Quagga-isms, such as bad time keeping, and other things that can kick a person in the butt on occasion. The v2 Atheros has no multicast support, and as such, OSPF needs to be setup with explicit neighbors for those interfaces. V3 does not have these problems, and OSPF works quite well through it.

[Equis]

Lonnie is referring to the Quagga-isms, such as bad time keeping, and other things that can kick a person in the butt on occasion. The v2 Atheros has no multicast support, and as such, OSPF needs to be setup with explicit neighbors for those interfaces. V3 does not have these problems, and OSPF works quite well through it.

Thanks

I'll do the Neigbour thing and see how I go

Thanks :)

[lonnie]

tsk, tsk. Brendan. You said that 0.99.2 had fixes for your precise problem and that was why you were on me like a dirty shirt for so long to get it put in. By the time we did the new image 0.99.3 was released and you thanked us profusely since there were some more fixes that were sure to have the problem fixed. Did that slip your mind? Or were you just pulling my chain earlier? If, as you say, 0.99.2 and 0.99.3 had fixes then YES, V3 will be better, since it uses 0.99.3

We have the new code which you are not using, so please, no more ragging about OSPF, since you are ragging about the older 0.98.5 release.

OSPF does not care a whit about what time it is in the outside world, it does however use the system clock for keeping track of the age of the routing database since it is keeping track of time over periods of minutes. If the Clock just runs and is running at a rate that is within a few percent of real time you will have no issues, OSPF only uses time locally

If you enable NTP the following happens.
routers get happy and exchange routes, routing comes up. then NTP sets clock which results in a clock jump of years. OSPF goes funny, routes break again

recent Quagga versions usually recover quite quickly from jumps into the future, jumps backwards are another story since you end up with negative ages in the link state database.
The Zebra routing daemon is much less forgiving of clock jumps and will usually die badly with any clock jump. Older versions of staros use zebra


there are other bugs, please see the bug thread to see if the symptoms match (OSPF loosing awareness of directly attached atheros interfaces on occasion)


Lonnie is laying all blame with the Quagga developers, I take it that this means that it's broke in V3 as well then.


please be more specific, copy in some configs and I'll take a look tomorrow

.brendan

[Equis]

Que here to Flame >> .....................................




Joking :)

[bminish]

tsk, tsk. Brendan. You said that 0.99.2 had fixes for your precise problem and that was why you were on me like a dirty shirt for so long to get it put in.

No lonnie,
I said that 99.2 was our best CHANCE of a fix for the issues we were seeing as quagga had undergone a considerable number of changes in the area of link detection.
Since I have never, with any quagga version been able to replicate this issue outside of staros with atheros links, how could I possibly say that 99.2 (or.3) was going, with certainty, resolve the problem.

I also pointed out that by, being on the current devel build of quagga that it would be possible to bring any identified quagga bugs to the quagga developers


By the time we did the new image 0.99.3 was released and you thanked us profusely since there were some more fixes that were sure to have the problem fixed. Did that slip your mind? Or were you just pulling my chain earlier? If, as you say, 0.99.2 and 0.99.3 had fixes then YES, V3 will be better, since it uses 0.99.3

99.3 is better in several regards to 98.5 (Much faster convergence time for one) however it has unfortunately not resolved this issue


We have the new code which you are not using, so please, no more ragging about OSPF, since you are ragging about the older 0.98.5 release.


What are you on about Lonnie? Our ENTIRE OSPF net with the exception of a couple of nodes that are running OSFP and are client facing AP's are on the latest build. We don't generally run OSPF on client facing nodes.
All my back-end systems are running 99.3 on various linux distros.
I have already pointed out WHY an older version more than 1 node away could have no bearing whatsoever with this issue.
I have a couple of nodes that I cannot bring to the latest build because of these builds breaking WPA-PSK authentication with my clients as reported in the build beta thread.
Initially We (and you) thought this was a preamble related issue, it seems that this is not the case.

Instead of attacking me here lonnie how about you get on with working with us to find a solution, that way we all benefit.


.brendan

[bminish]

Lonnie is referring to the Quagga-isms, such as bad time keeping, and other things that can kick a person in the butt on occasion.

The timekeeping issue is not Quagga's fault.
It uses the system clock for keeping track of age in the link state database. It is quite correct to use the system clock for timing events over longer periods of time.
OSPF / quagga does not exchange real time information with it's neighbours, all that it requires is that the local clock runs in an even and linear fashion.

I saw another issue related to this (also reported to you guys many months ago) when running on PC hardware.
When running on a platform that has a battery backed clock, NTP should not be an issue because it should only be making slight changes to the system time.
However we had one box that always went pearshaped.
Turns out that the hardware clock was running slightly fast all the time but that staros was not updating the hardware clock on reboot so when the box came up again it was quite a few minutes into the future, NTP causes a jump backwards in time and OSPF cannot cope with larger jumps backwards in time.
Has this been fixed? I.e does the reboot sequence now update the hardware clock

My advice is that in cases where you have no on board battery backed clock that NTP not be used in conjunction with OSPF.
What do you need NTP for on a router anyway
.brendan

[Equis]

I'll turn off NTP, I thought it may have been needed to send time to other routers but it's not :-)

Thanks for all your help