[Olsr-dev] Patch Orgy Syncup
Sven-Ola Tuecke
(spam-protected)
Fri Aug 24 21:20:46 CEST 2007
Hi,
this "extra Hyst" is a special feat for _me_. Which is Off by default. It
works, but _only_ for default routes (which create some kind of "sink" in
the topo graph) only only if used with brains.
The rest (especially the statement "Link state routing depends on synced
info on all nodes") is ACKed. One of the immanent probs of olsrd also. Too
much packet loss keeps the nodes out of sync - partly fixed by flooding the
neighbourhood with a lot of LQ_TC's (look for "Fisheye" if you need ideas)
// Sven-Ola
Juliusz Chroboczek wrote:
>> | > b) Small Hysteresis on HNA4 0/0 to prevent routing flaps especially
>> | > when ETX(a) slowly grows and ETX(b) slowly shrinks there is a 5
>> | > minute "flaptime" for such a route.
>
>> | Could you describe how that works? I'm worried it might create
>> | routing loops.
>
>> i share your concerns - there is one other protocol which uses
>> kind damping tequnique which is BGP. for exactly the same reason
>> (routing loops) it is prohibited to damp internal paths ...
>
> It's slightly different. BGP is a hierarchical protocol, and the
> prohibition of intra-AS flap damping is due to the requirement for
> routes to be consistent within the AS.
>
> This doesn't apply to OLSR, which is a flat protocol. The problem is
> that OLSR is a link-state protocol, and such protocols absolutely
> require that topology information and path computation be consistent
> across the routing domain. So hysteresis for link costs should be
> okay (as long as everyone has the same idea of a given link cost), but
> hysteresis on shortest path computation will break. But I'm not
> excluding that Sven-Ola is doing something smart to work around the
> problem.
>
> (OSPF partly works around the issue by using hierarchical routing, but
> I doubt that's what Sven-Ola is doing.)
>
>> one of the things what we would like to do for olsr-ng is
>> to work on that problem too - rather than damping routes
>> we'd like to to setup a GRE tunnel to the node offering the 0/0
>> route.
>
>> now "stickyness" to a certain default gw is easy and does not
>> create routing loops.
>
> Yes, that should work. Although my personal preference would be to
> use a protocol that is robust in the face of inconsistent information.
>
> That's getting off-topic for this list -- is there a better place to
> discuss it (in English)?
>
> Juliusz
>
More information about the Olsr-dev
mailing list