[Olsr-dev] Removing default route after program termination
Thu Oct 11 10:40:12 CEST 2007
this is the "I want my internet for me" case. Not possible without policy
routing (which I dont know how to implement with BSD). *With* policy routing
it's easy - just have 2 routing tables (one for the OLSR-Public and one for
* Note: To ensure others have a useable default route, you cannot roll your
own but refuse to HNA. Only works, if you do not forward IP traffic either.
Which is useless until you are definitely an end point. These are your
a) Use other (OLSR-Announced) GW (default point to other mesh node)
b) Offer GW to others (default points to your GW)
c) Use policy routing to distinguish. Use Linux + RtTable and all is fine
"Mitar" <(spam-protected)> schrieb im Newsbeitrag
>> We can deciced by examing the HNA 0/0 situation. If the BSD announces HNA
>> 0/0 (either by manual config entry or by dyngw/dyngwplain, it's scenario
>> Otherwise 2).
> Not really. What if I have Internet access but I do not want to
> announce it to the mesh? The mesh itself has HNA announced but I also
> do not want to use it (as I have my Internet access and I do not want
> to put load on a mesh unnecessary). But I still want to be able to
> access nodes and subnets in a mesh (administration, different services
> provided and all other reasons) and I want to be accessible from the
> mesh so I need OLSR.
> I see two possibilities:
> The hard way: We extend OLSR daemon with routing daemon on BSD which
> properly (the BSD way) work with multiple default routes, simulating
> the routing behavior with different metrics for default routes on
> other OSes.
> The easy way: We ignore that adding a new default route does not do
> anything on BSD, but we take care that the route OLSR removes is
> really a route it added (and not some other default route). This way
> it at least does not break anything.
> Or maybe some configuration switch which would enable user to specify
> which HNA announcements should his/her OLSR daemon ignore (so you
> could ignore also some other announced subnets and of course also
> default route announcements).
> Olsr-dev mailing list
More information about the Olsr-dev