[Olsr-dev] Removing default route after program termination

Hannes Gredler (spam-protected)
Thu Oct 11 12:47:09 CEST 2007


HNA   0.0.0.0/1 and
HNA 128.0.0.0/1

should be enough ...

/hannes

On Thu, Oct 11, 2007 at 11:58:24AM +0200, Sven-Ola Tuecke wrote:
| Ah - please allow some more sentences. To bring some enlightment to the DAA 
| (Dumbest Admin Avail), I remember once I simply announced Inet via a couple 
| of HNA entries (requires some binary math). Example: Your mesh uses 
| 10.x.x.x, then a rock solid default route annoucement is by these HNA 
| entries:
| 
| HNA 0.0.0.0/5
| HNA 8.0.0.0/7
| HNA 11.0.0.0/8
| HNA 12.0.0.0/6
| HNA 16.0.0.0/4
| HNA 32.0.0.0/3
| HNA 64.0.0.0/2
| HNA 128.0.0.0/1
| 
| Which will overwrite any default route you configure <ggg>
| 
| // Sven-Ola
| 
| ""Sven-Ola Tuecke"" <(spam-protected)> schrieb im Newsbeitrag 
| news:feknhd$898$(spam-protected)
| > Hi Mitar,
| >
| > 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
| > you).
| >
| > * 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
| > alternatives:
| >
| > 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
| >
| > // Sven-Ola
| >
| > "Mitar" <(spam-protected)> schrieb im Newsbeitrag
| > news:(spam-protected)
| >> Hi!
| >>
| >>> 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
| >>> 1).
| >>> 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).
| >>
| >>
| >> Mitar
| >>
| >> -- 
| >> Olsr-dev mailing list
| >> (spam-protected)
| >> http://lists.olsr.org/mailman/listinfo/olsr-dev
| >
| >
| > -- 
| > Olsr-dev mailing list
| > (spam-protected)
| > http://lists.olsr.org/mailman/listinfo/olsr-dev 
| 
| 
| -- 
| Olsr-dev mailing list
| (spam-protected)
| http://lists.olsr.org/mailman/listinfo/olsr-dev
| 




More information about the Olsr-dev mailing list