[OLSR-users] Anyone tried two nodes with internet connection?

Rajesh Narayanan (spam-protected)
Fri Jan 12 01:36:45 CET 2007


hmmm.. from reading your email (over and over again)  looks to me that the
OLSR might be behaving correctly. But the expected behavior is not helping
me since the static routes are not touched (as olsr does not touch them).

My frustration is that how do I make the pings route through the OLSR-route
since my static route does not work as I removed the cable (linkA)??

So what I really need is a redundancy behavior really which is not supported
by the dyn-gw plugin right now. Correct?

Thanks,
Rajesh.


On 1/11/07, Rajesh Narayanan <(spam-protected)> wrote:
>
>
> No problem (English is not my native language and perhaps I'm only silly
> > - or dumb - right now): You put two LinkSys (or PCs or whatever you
> > have) running OLSRD as your "dedicated border routers" inbetween the
> > rest of the mesh network and your uplink. And these have - in the most
> > simple/extreme case - exactly two interfaces (these maybe "only"
> > ethernet interfaces but anyone will do):
> > -) one to your uplink
> > -) one to the next OLSR router in the mesh network
>
>
> yes the network is like shown below:
>
>
> 10.33.176.1            192.168.50.53          192.168.50.54
> 10.103.0.224
> UplinkA <------> Linksys(vodka3) <  - - - - - - >
> LinksysB(vodka4)<----------->UplinkB
>
> linkA                                                             linkB
>
> CONFIGURATION BEFORE ANYTHING IS STARTED
>
> --------------------------------------------------------------------------------
> VODKA3:
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 10.33.176.0     0.0.0.0         255.255.255.0   U     0      0        0
> vlan1
> 192.168.50.0    0.0.0.0         255.255.255.0   U     0      0        0
> eth1
> 192.168.66.0    0.0.0.0         255.255.255.0   U     0      0        0
> vlan0
> 0.0.0.0         10.33.176.1     0.0.0.0         UG    0      0        0
> vlan1
>
> olsrd.conf (snippet):
> Hna4 {
>         0.0.0.0         0.0.0.0
> }
>
> LoadPlugin "olsrd_dyn_gw.so.0.4"
> {
>         PlParam "Ping"          "10.193.244.15" #this is reachable via
> VLAN1 or def gateway
> }
>
> VODKA4
> (spam-protected):~# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 192.168.50.0    0.0.0.0         255.255.255.0   U     0      0        0
> eth1
> 10.103.0.0      0.0.0.0         255.255.255.0   U     0      0        0
> vlan1
> 192.168.66.0    0.0.0.0         255.255.255.0   U     0      0        0
> vlan0
> 0.0.0.0         10.103.0.224    0.0.0.0         UG    0      0        0
> vlan1
>
> olsrd.conf (snippet):
> Hna4 {
>         0.0.0.0         0.0.0.0
> }
>
> LoadPlugin "olsrd_dyn_gw.so.0.4"
> {
>         PlParam "Ping"          "10.103.0.224"
> }
>
>
> ROUTE TABLES WHEN OLSRD STARTED ON VODKA3 and VODKA4
>
> ---------------------------------------------------------------------------------------------------------
> VODKA3:
> (spam-protected):~# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 192.168.50.54   0.0.0.0         255.255.255.255 UH    1      0        0
> eth1
> 10.33.176.0     0.0.0.0         255.255.255.0   U     0      0        0
> vlan1
> 192.168.50.0    0.0.0.0         255.255.255.0   U     0      0        0
> eth1
> 192.168.66.0    0.0.0.0         255.255.255.0   U     0      0        0
> vlan0
> 0.0.0.0         10.33.176.1     0.0.0.0         UG    0      0        0
> vlan1  (#Def route)
> 0.0.0.0         192.168.50.54   0.0.0.0         UG    1      0        0
> eth1 (#OLSR added route)
>
>
> VODKA4:
> (spam-protected):~# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 192.168.50.53   0.0.0.0         255.255.255.255 UH    1      0        0
> eth1
> 192.168.50.0    0.0.0.0         255.255.255.0   U     0      0        0
> eth1
> 10.103.0.0      0.0.0.0         255.255.255.0   U     0      0        0
> vlan1
> 192.168.66.0    0.0.0.0         255.255.255.0   U     0      0        0
> vlan0
> 0.0.0.0         10.103.0.224    0.0.0.0         UG    0      0        0
> vlan1 (#Def route)
> 0.0.0.0         192.168.50.53   0.0.0.0         UG    1      0        0
> eth1 (#olsr added route)
>
> WHEN I PING GOOGLE.COM FROM VODKA3
> ---------------------------------------------------------------------
> VODKA3
> (spam-protected):~# ping www.google.com
> PING www.l.google.com (72.14.221.103): 56 data bytes
> 64 bytes from 72.14.221.103: icmp_seq=0 ttl=238 time=176.2 ms
> 64 bytes from 72.14.221.103: icmp_seq=1 ttl=238 time=169.7 ms
> 64 bytes from 72.14.221.103: icmp_seq=2 ttl=238 time=170.8 ms
> 64 bytes from 72.14.221.103: icmp_seq=3 ttl=238 time=171.3 ms
> 64 bytes from 72.14.221.103: icmp_seq=4 ttl=238 time=169.5 ms
> 64 bytes from 72.14.221.103: icmp_seq=5 ttl=238 time=170.6 ms
>
> VODKA4
> (spam-protected):~# ping www.google.com
> PING www.l.google.com (66.102.7.99): 56 data bytes
> 64 bytes from 66.102.7.99: icmp_seq=0 ttl=248 time=10.8 ms
> 64 bytes from 66.102.7.99: icmp_seq=1 ttl=248 time=10.8 ms
> 64 bytes from 66.102.7.99: icmp_seq=2 ttl=248 time=10.6 ms
> 64 bytes from 66.102.7.99: icmp_seq=3 ttl=248 time=10.7 ms
> 64 bytes from 66.102.7.99: icmp_seq=4 ttl=248 time=11.1 ms
> 64 bytes from 66.102.7.99: icmp_seq=5 ttl=248 time=15.8 ms
>
>
> ROUTE TABLES WHEN I REMOVE THE LINKA
> -----------------------------------------------------------------------
> VODKA3
> (spam-protected):~# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 192.168.50.54   0.0.0.0         255.255.255.255 UH    1      0        0
> eth1
> 10.33.176.0     0.0.0.0         255.255.255.0   U     0      0        0
> vlan1
> 192.168.50.0    0.0.0.0         255.255.255.0   U     0      0        0
> eth1
> 192.168.66.0    0.0.0.0         255.255.255.0   U     0      0        0
> vlan0
> 0.0.0.0         10.33.176.1     0.0.0.0         UG    0      0        0
> vlan1 (#Def route STILL THERE!!)
> 0.0.0.0         192.168.50.54   0.0.0.0         UG    1      0        0
> eth1
>
> VODKA4
> (spam-protected):~# route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 192.168.50.53   0.0.0.0         255.255.255.255 UH    1      0        0
> eth1
> 192.168.50.0    0.0.0.0         255.255.255.0   U     0      0        0
> eth1
> 10.103.0.0      0.0.0.0         255.255.255.0   U     0      0        0
> vlan1
> 192.168.66.0    0.0.0.0         255.255.255.0   U     0      0        0
> vlan0
> 0.0.0.0         10.103.0.224    0.0.0.0         UG    0      0        0
> vlan1
> (#OLSR added route gets removed. correct behavior)
>
> BUT NOW IF I TRY TO PING GOOGLE.COM
> -------------------------------------------------------------------
> VODKA3
> (spam-protected):~# ping www.google.com
> ### No response (nameservice failure, im not running nameservice daemon so
> it does not matter.. anyway, so i hit ctrl-c and tried pinging the IP
> address instead.
>
> (spam-protected):~# ping 72.14.221.103
> PING 72.14.221.103 (72.14.221.103): 56 data bytes
>
> --- 72.14.221.103 ping statistics ---
> 11 packets transmitted, 0 packets received, 100% packet loss
>
> VODKA4
> (spam-protected):~# ping www.google.com
> PING www.l.google.com (66.102.7.99): 56 data bytes
> 64 bytes from 66.102.7.99: icmp_seq=0 ttl=248 time=13.5 ms
> 64 bytes from 66.102.7.99: icmp_seq=1 ttl=248 time=14.4 ms
> 64 bytes from 66.102.7.99: icmp_seq=2 ttl=248 time=11.2 ms
> 64 bytes from 66.102.7.99: icmp_seq=3 ttl=248 time=11.1 ms
> 64 bytes from 66.102.7.99: icmp_seq=4 ttl=248 time=23.3 ms
>
>
> ISSUE
> -----------
> Just as you stated below, the default route in Vodka3 should have been
> removed by the olsrd dyn-gw plugin but it does not get removed.
>
> Thanks,
> Rajesh.
>
>
>
> [...]
> > >         The other solution (see Andreas email) is to add (low
> > >         priority) host
> > >         routes to known-outside ping targets - the ones which are used
> > >         to decide
> > >         if we have an uplink or not.
> > >
> > > **********  this does not help. The issue is with the static route
> > > that gets added when the uplink is discovered. Once its discovered and
> > > the static default route gets added, no amount of dancing with olsrd
> > > or the dyn-gw parameters will be useful.
> >
> > The low priority host routes are to be added statically and - thus - are
> >
> > not touched/chaned/removed by OLSRD.
> > So it should work like:
> > - Everything is up and running - the static low prio static host routes
> >   and default route are in place. `ping checks` work (and no one cares
> >   which route is actually responsible).
> > - The uplink fails because the ping's fail (e.g. someone pulls the
> >   cable). OLSRDs dyn_gw plugin removes the default route. Naturally this
> >   change propagates through the mesh network.
> > - If the cable is plugged in again, the ping's will work again since
> >   we have these static low prio static host routes. Via the dyn_gw
> >   plugin we get a default route again which is also propagated through
> >   OLSRD.
> > And the static low prio host routes do not interfere with the OLSR
> > because OLSRD propagates only routes learned via OLSR or HNA-announcte
> > (or configured).
> > Or do I miss something?
> >
> >         Bernd
> > --
> > Firmix Software GmbH                   http://www.firmix.at/
> > mobil: +43 664 4416156                 fax: +43 1 7890849-55
> >           Embedded Linux Development and Services
> >
> >
> > _______________________________________________
> > olsr-users mailing list
> > (spam-protected)
> > https://www.olsr.org/mailman/listinfo/olsr-users
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20070111/632f22c6/attachment.html>


More information about the Olsr-users mailing list