[OLSR-users] Routes momentarily disappearing
Thomas Lopatic
(spam-protected)
Mon Jan 9 00:47:23 CET 2006
Hi Karl,
>>So, I'd recommend adding "HelloValidityTime 120.0" to your interface
>>configuration.
>
>
> Thanks for the suggestion Thomas. I updated all my nodes/routers olsrd.conf,
> and did quite a bit of testing, however I'm still having problems with the
> routing table not having a default route.
>
>
> Should i try the same with HnaValidityTime and HnaInterval? Do HnaValidityTime
> and HnaInterval have any effect on nodes that are not announcing an HNA? If i
> change HnaValidityTime and HnaInterval do i only change it on the node with the
> external Internet route? The man page is not too clear on this.
Yup, you might want to increase your HnaValidityTime and your
TcValidityTime. HnaValidityTime is only relevant on nodes that actually
announce an HNA.
The validity times in general work as follows. Each OLSR message
generated by a node contains a validity time that says for how long the
information in the message is at maximum to be regarded up to date. If I
receive an OLSR message from my neighbour stating that the information
is valid for 120 seconds, I'll keep the information for 120 seconds. If
I receive another OLSR message of the same type (e.g. a HELLO) before
that time has passed, the information in the newly received message
supersedes the stored information and again the validity time of the
message says for how long I am to keep the information.
HnaValidityTime specifies the validity time for OLSR HNA messages,
TcValidityTime specifies the validity time for OLSR TC messages, and
HelloValidityTime does so for HELLOs. There's another configuration
option, MidValidityTime, which is considered when generating OLSR MID
messages.
So, HnaValidityTime only makes sense on nodes that actually announce an
HNA, as this is the validity time that is copied into the generated HNA
messages. So, yes, try setting this to 120 as well on your gateway node.
What you might also want to do is to set TcValidityTime also to 120. TC
messages are used to distribute topology information through the
network. A TC message generated by a node A contains all of A's links.
This message is then flooded through the network, so that every network
node sees it. If everybody sends TCs, everybody knows about everybody
else's links, i.e. everybody has the same idea about what the network
looks like, i.e. which links there are and how good they are. Based on
this everybody finds an identical best path from each node to each other
node.
If I receive a TC from a node, I know the links of this node. Again I
consider these links to exist as long as the validity time has not
passed. Once the validity time for a TC from node A has passed without
me receiving another TC from A, I forget about all of A's links, i.e.
for me A and its links do not exist anymore. So, if a number of
successive TCs from node A are lost, I might forget about A and its
links, although A is still there. So, a larger TcValidityTime gives you
more stability.
However, it has to be noted that this stability comes at a price. Your
network is not as dynamic any longer, i.e. it reacts very slowly to
topology changes. Imagine that node A sees node C, but node B doesn't
see node C. A announces in its TC messages "I have a link to C". B
doesn't announce any link to C. Now node C moves geographically, so that
it moves out of A's reach but moves into B's reach. B will immediately
start announcing the link to C and A will stop announcing the link to C.
The network nodes will from then on know about the link between B and C.
However, the network nodes will only forget about A's link to C after
the last announcement of A's link to C has timed out, i.e. after the
validity time for TC messages has passed.
There aren't any "negative" announcements such as "I have lost my link
to C" in OLSR. There are only "positive" announcements ("I have a link
to C") that time out after the associated validity time.
So, larger validity times are good for static networks, i.e. networks
that do not have fast-moving mobile nodes.
-Thomas
More information about the Olsr-users
mailing list