[Olsr-dev] Poor routing performance

[Markus Kittenberger]

On Wed, Nov 10, 2010 at 6:49 PM, Henning Rogge <(spam-protected)>wrote:

>  On Wednesday 10 November 2010 18:42:44 Octav Chipara wrote:
>
> > Hi,
>
> >
>
> > A few questions/suggestions.
>
> >
>
> > 1) I understand the difficulties with managing routes. It seems to me
> that
>
> > a good engineering approach would be to define a range of IP addressed
> for
>
> > which OLSR will be doing the routing. This method will give you an
>
> > opportunity to have multiple routing algorithms managing different
> routes.
>
currently olsrd will route IP/Networks what any node in the mesh might
announce,..

combined with linux routing rules and multiple routing tables, you can get
above,..

for other OS you should not combine olsrd with other daemons,.. *G

OLSRd will only work with the IPs the user defines in the mainIP/HNAs and
> the interface IPs. You could get rid of the interface IPs and just
> mainIP/HNAs.
>

> 2) Does OLSR implementation cache routes within its own code?
it (only) knows his own old route (until is succeeded to write the new,..)
> guess, it really is an issue to have writing to the routing table fail

> > because it could potentially impact the entire network as opposed to just
>
> > the local host. If it does do caching, can we simply keep a bool
> indicating
>
only for shortterm/intermittient problems it helps,..

(and such logic is implemented in olsrd since "ever")

but for persistent problems it will still potentially impact the whole
network permanently,..
(and fillup your syslog (and harddrive) locally)

> if the route update was performed correctly or not.
>
> If no error is in the syslog, then OLSRd never know that something went
> wrong.
>
ACK if there are no syslog errors, the os-specific functions (in your case
in src/bsd/kernel_routes.c) didn't realize they failed,...

(which is very likely for any OS!=linux)

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20101111/9b9ee5ae/attachment.html>