[Olsr-dev] Patch for dyn_gw plugin
Wed Feb 3 15:01:49 CET 2010
[Swapped to dyn_gw thread]
You explained my concerns well.
That is why I need more sophisticated validation.
My first thoughts were eliminating d.gw. from ppp, dhcp etc.
And use dyn_gw_plain.
But I need multiple priority d.gw.s anyway, I'll use the following:
PlParam "Interval" "1"
# Last resort default gateway
PlParam "HNA" "0.0.0.0 0.0.0.0"
# Somewhat better default gateway
PlParam "HNA" "0.0.0.0 184.108.40.206"
PlParam "HNA" "220.127.116.11 18.104.22.168"
# Much better default gateway
PlParam "HNA" "0.0.0.0 192.0.0.0"
PlParam "HNA" "22.214.171.124 192.0.0.0"
PlParam "HNA" "126.96.36.199 192.0.0.0"
PlParam "HNA" "192.0.0.0 192.0.0.0"
Not the HNA metric I prefer, but it works.
The d.gw. validation adds the /1 and /2
HNA routes when there seems to be an inet
Now I have to clean up dyn_gw a bit, or add the HNA
parameter in dyn_gw_plain.
>Van: (spam-protected) [mailto:olsr-dev-
>(spam-protected)] Namens Sven-Ola Tuecke
>Verzonden: woensdag 3 februari 2010 13:49
>Onderwerp: Re: [Olsr-dev] BMF in 0.5.6-R8
>as I repeatedly emphasized on: dyn_gw is only usable on edge-nodes (that
>no other mesh user behind). If you have a GW node in the middle and the
>local inet does not work, other users will have trouble to use a backup
>gateway. Example: if GW fails and does not clear failed default route
>UserNode -> GW(faulty) -> 2.GW (no inet for user)
>For that reason (and for doing the necessary policy routing tricks in a
>script) the dyn_gw_plain exists which simply links default route in
>routing table to HNA0/0 announcements.
>On the other hand: dyn_gw is old and unmaintained and may deserve a bit
>cleaning anyhow. Thank you,
More information about the Olsr-dev