[Olsr-users] Managing Local Default Route offered as HNA 0.0.0.0 when healthy versus OLSR learned default route from mesh

[Sven-Ola Tuecke]

Hey,

you describe more or less the algo from the freifunk firmware. The reason 
why dyngwplain plugin and policy routing table number exist in olsrd. You 
may search for "policyrt" in these scripts:

http://ff-firmware.cvs.sourceforge.net/ff-firmware/ff-devel/freifunk-olsrd/usr/sbin/cron.minutely?view=markup
and
http://ff-firmware.cvs.sourceforge.net/ff-firmware/ff-devel/freifunk-olsrd/etc/init.d/S53olsrd?view=markup

// Sven-Ola

"Eric Malkowski" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
> Hi all-
>
> I wanted to run an idea by everyone -- may have already been discussed
> in the past, but couldn't find anything, here goes:
>
> I've got a box with wired enet as internet (DHCP or static IP w/ fixed
> default route not added by OLSR) and 2.4 ghz for people to get on and
> 5.8 ghz ad-hoc to rest of mesh - so the typical 3 interfaces one wired,
> two wireless AP and backhaul.
>
> With OLSR dyn_gw plugin, if the wired internet fails the pings, OLSR
> will install a default route from the mesh yielding 2 default routes.
> Problem is the wired default route is favored over the OLSR installed
> default route (zero metric versus non-zero olsr default route metric),
> so people on the 2.4 ghz of this same box don't get internet access
> because they keep trying to take the wired internet rather than the
> better default route from the mesh.  If other nodes on the mesh were
> using this box that lost it's internet, they're OK because they'll seek
> some other node w/ internet HNA -- i.e. nodes in the mesh w/ no internet
> backhaul (empty eth0 connection) just pick whoever has internet to offer
> from nodes running dyn_gw plugin.
>
> My plan to fix this - curious if you guys think it will work:
>
> - Switch to dyn_gw_plain plugin
> - Use "ip route and ip rule" commands to add a 2nd routing table with
> default route out eth0 internet connection.  ip rule will add a rule for
> traffic that uses internet eth0 connection source IP to always takes the
> wired internet connection via this extra routing table.  Other traffic
> is subject to normal "main" routing table
> - The "main" routing table will initially have no default route -- thus
> dyn_gw_plain will not inject in the mesh any default route to "offer"
> other nodes, but rather OLSR will learn a default route from the mesh if
> one is available -- that's fine.
> - Setup a script that uses ping of known internet IPs like normal dyn_gw
> plugin and it uses the source IP of the wired internet eth0 connection
> so the pings always use the extra routing table since ip rule directs
> the traffic there.  When the pings see the internet is good, it can do
> "route add default gw x.x.x.x" so the main routing table gets a non-olsr
> default route when local internet connection is determined "good".
> - dyn_gw_plain will "notice" the non-olsr default route and add it as an
> HNA 0.0.0.0 for the mesh and use the default route - if a OLSR installed
> default route to another node in the mesh that was in use, it should go
> away in favor of the local internet route -- I've seen this behavior
> with dyn_gw, but haven't experimented with dyn_gw_plain yet -- expecting
> that part is the same.
> - The separate ping script continues in the background (it's the only
> thing using the extra routing table).  If it determines the gateway to
> be "dead" by failing to get responses, he can simply delete the non-olsr
> default route he added and thus dyn_gw_plain will "notice" once again
> the gateway is dead, stop HNA 0.0.0.0 and eventually learn a peer node
> in the mesh default route to use until the local wired connection is
> determined good once again by the ping script.
> - The above cycle goes on forever.
> - This would allow people on the 2.4 ghz ath0 network to take the local
> internet connection when it's up, and switch in a reasonable amount of
> time if the local internet dies and OLSR learns a default route from the
> mesh.  It's perfectly acceptable for an in-progress download to die
> during the switch -- it's light surfing going on on this setup.  If the
> box is acting as local DNS server (w/ BIND in my case), name lookups
> will take the internet local eth0 when it's good, or take the mesh
> default route when local internet is bad -- it solves name resolution
> problems so they go either direction based on active default route.  The
> ping script doesn't need to resolve names - like the dyn_gw plugin, I
> plan to use just IP addresses of known internet sites that should be
> responsive when local internet connection is healthy
>
> I've used this type of strategy for multiple ISP connections i.e. my
> work has a Soekris net5501 that is our firewall / gateway etc. and we've
> got a business Cable internet connection that does 24 megabit burst, and
> then a T1 at 1 megabit phone/data setup.  I've got multiple routing
> tables and pings so if the cable goes down, we switch to T1 default
> route in the main routing table.  If the Cable comes backup, we "favor"
> the cable interface since it's faster.  When traffic goes out either
> connection, the traffic is NATed etc.  I've found it's best to do all
> data out Cable if available and T1 only if cable is down rather than
> equal cost multipath on both since when the T1 is picked, that
> particular flow gets slow speed and people who get the cable at the
> moment they go out, it's very fast.  It's 100% one or the other based on
> link status instead of multip-path.  It works great.   I'm trying to do
> something similar w/ OLSR and local default gateway monitoring to
> automate as internet backhauls go up and down.  It also has the benefit
> where if we ant to force a node to stop using it's local backhaul, we
> can simply unplug the link and wait for OLSR to rip out the HNA 0.0.0.0
> and pick up a default route from the mesh.
>
> Any thoughts?  I'd be interested in hearing about anyone else's
> solutions for this type of goal.
>
> If people really like what I've come up with, I'll be happy to post my
> scripts and such for others to enjoy.  I'm planning on testing this
> weekend unless someone tells me of a fundamental problem with my
> strategy described above.
>
> Thanks.
>
> -Eric
>
>
> -- 
> Olsr-users mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-users