[Olsr-users] Sticky gateway [was: olsr and streaming]

[ZioPRoTo (Saverio Proto)]

> an other solution is loose source routing, as done by the ninux.org
> people, you set your desired gateway as "next" hop and the packet will
> be forwarded to that gateway, there the final destination ip goes into
> the ip header.
>
> maybe saverio can write more about this approach.

Hello,

I've been told you were talking about this stuff on the list, so I
subscribed today and I read the archives.

Yes, we addressed the problem of multiple gateways at Ninux.org, and
we tried a loose source routing solution.

With loose source routing [0] the source of a IP packet can specify
more than one IP destination address, and the packet will travel
accross this destinations.
To try it your self do for example:
ping ip1 ip2
and your ICMP packet will have a LSSR option, and it will go first to
ip1 and then to ip2.

In our scenario we have users in HNA subnets, and all their traffic
goes throught the OLSR node announcing the HNA that is generally on
the roof. The idea was in the OLSR node on the roof to select a
gateway and to add a Loose Source Routing IP Option [0] to every
packet.
This with some iptables rules injected by the OLSR daemon.

This will make every IP packet go the the gateway before going to his
final destination. For packets travelling on the way back to the user
the option is not needed.

There is no state kept on the gateway, but you have to enable source
routing on every nodes setting to "1" some file in the /proc

We implemented already [1] the Kernel code to add LLSR IP option to
packets going though the node, but it is still missing the code in
OLSR to inject the iptables rules on the gw.

Regarding IP-in-IP tunnels, I like them much better, but for an
implementation problem on Linux they require a state to be kept on the
gateways.
In fact reading the standard I should be able to generate and IP-in-IP
packet, but there is not a kernel handle for that packet !! I tried it
my self on a recent kernel (say something like 2.6.21) and the result
was the kernel handling the packet as TCP and sending me back and ICMP
port not available.
To handle IP-in-IP tunnels you have to configure the other endpoint
and create a tun interface. If somebody patches the Kernel to handle
natively IP-in-IP packet then is possible with minimal effort to
tunnel the packets to the desired gateway only in the uplink path
(asymetric tunneling).
This is a way better because the nodes on the path do not have to be
configured to forward LLSR packets (by default this feature is disable
for security concerns).

Right now we don't have nobody working on this a Ninux.org but we are
willing to help :)

Saverio

[0] - http://www.rfc-editor.org/rfc/rfc791.txt
[1] - https://svn.ninux.org/ninuxdeveloping/browser/xtables-addons