[olsr-dev] Re: [OLSR-users] Same IP address for several interfaces

[Andreas Tønnesen]

Hi,

Here is what I wrote in the original discussion:

<SNIP>
After pondering a bit on the concept of using multiple interface with
the same IP in olsr - it seems the idea of allowing this breaks the
link/neighbor sensing scheme. Links sensing is based on the idea that
every link is made up of one local IP and one remote. Replacing the
local IP with some other mapping to a local interface will work(as done
in the patch), but there is still the case of the remote IP. If we can
no longer be sure the remote IP is uniqe for an interface on the remote
host - the registration and maintainance of links becomes problematic.
I realize that in the given scenario things would probably work out -
but if one imagines a scenario where a node might receive traffic from
mulitple interfaces on a remote host, where the interfaces are using
duplicate IPs, then stuff will get more complicated. So since this non
RFC-compliant "extention" of the protocol will not operate in the
general case I do not think I will include it in the main olsrd code.
Also AFAICS this kind of solution will not work on other OSes where one
cannot bind sockets to devices.
But then again - for the special scenario you are setting up Pawel, your
fix is a solution and perhaps others will be interested in the patch. I
know other people on this list are working on similar projects - is this
something you guys would need? Perhaps you should consider creating a
patched package for WRT systems?

Anyways, you seem to have an interesting project running - and I hope
olsrd will work out for you despite of that anoying, arguing developer
in charge ;-)

</SNIP>


I think this is still valid. The idea is great for your special cases -
but it will not work in the general case and it is not RFC compliant
because the RFC states that IPs are the way to map interfaces on foregin
hosts. If this is to work in the scenario where one might hear HELLOs from
multiple interfaces using the same IP on a neighbor host then one has to
know the ID of the remote interfaces. To do this one has to change the
HELLO messages - needless to say, this breaks RFC3626 compliance...

This is to much of a special case to be included in the olsrd code IMO. My
suggestin is that somone maintains a patch(I'll gladly link to it from
olsr.org) or if you'd like, fork off a project of your own as implied on
one of your earlier mails :-)


- Andreas


> On Wednesday 01 of December 2004 09:59, you wrote:
>> > "So since this non RFC-compliant "extention" of the protocol will
>> > not operate
>> > in the general case I _do not think I will include it in the main
>> olsrd
>> > code_."
>>
>> Can you please explain why is your patch "non RFC-compliant" ?
>
> Well, regarding your mail in general - I'm not OLSR guru (yet :P) and I
> haven't found time yet to read it's RFC, so I won't discuss topic in
> detail.
> I simply needed to deploy setup described by me really fast - I wrote a
> patch
> and showed it to the others - for my setup it works quite reliably, but
> I'll
> definitely improve it as soon as I have some time. I think Andreas should
> say
> something more, possibly answering your questions :).
>
> Bye,
>
> --
> Pawel Foremski
> (spam-protected)
> http://pjf.dotgeek.org/
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users
>


---------
Andreas Tønnesen
http://www.olsr.org