<div>using the same ip adress on multiple interfaces can lead to strange problems,..<br>(the OLSR protocol requires meshwide unique interface adresses) <br></div><div>at the moment there is a warning afair on startup, an in future olsrd will very probably refuse to start/run on an interface without an unique ip.</div>
<div><br></div><div>do you have 2 links with an identical pair of ip-adresses? (this will lead to routing catastrophes for sure,.. expecially if the 2 links have different lq or nlq values)</div><div><br></div><div>or one node having the same neighbour twice (on 2 interfaces, where the neighbour has the same interface) ?<br>
</div><div><br></div><div>regards Markus</div><br><div class="gmail_quote">On Sun, Jan 10, 2010 at 11:58 PM, Mitar <span dir="ltr"><<a href="mailto:mmitar@gmail.com">mmitar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi!<br>
<br>
We have connected a new node with directional antenna to one of our<br>
nodes (which has an omni antenna) and on this node with omni antenna<br>
VPN uplink currently does not work. Because of this we have discovered<br>
really strange OLSR behaviour.<br>
<br>
The central node is "fri" node (with omni antenna):<br>
<br>
<a href="https://nodes.wlan-lj.net/nodes/node/fri" target="_blank">https://nodes.wlan-lj.net/nodes/node/fri</a><br>
<br>
and it connects to three nodes "gerbiceva-49", "glinska-9" and<br>
"stefanova-15-ii". Or better, those three nodes connect to it with<br>
their directional antennas. "stefanova-15-ii" is this new node which<br>
has rather flapping link because it uses wrong polarisation. The<br>
problem is that those two nodes ("glinska-9" and "fri") are cut off as<br>
the link from "stefanova-15-ii" is flapping. But all this while link<br>
to "gerbiceva-49" is good: I have SSHed to "fri" node from<br>
"gerbiceva-49" node and was able to normally work on it. At the same<br>
time I have let running ping (with default packet size) in both<br>
directions (between "fri" and "gerbiceva-49" nodes) and in few hours<br>
there was just 4% of packet loss in both directions without any<br>
periods of link loss.<br>
<br>
But OLSR is adding and removing route to "fri" node all the time so<br>
from network it is mostly unreachable. (I have to connect to it<br>
directly from "gerbiceva-49" node.)<br>
<br>
Our current mesh topology can be seen here:<br>
<br>
<a href="https://nodes.wlan-lj.net/nodes/topology" target="_blank">https://nodes.wlan-lj.net/nodes/topology</a><br>
<br>
It is strange that sometimes route is removed and then topology is<br>
drawn with "glinska-9" and "fri" nodes in the "air" - not connected to<br>
the rest of the mesh but still drawn. While route between "fri" and<br>
"gerbiceva-49" is not drawn. And at the same time ping normally works<br>
between "fri" and "gerbiceva-49".<br>
<br>
We use OLSR 0.5.6-r7 on nodes with such configuration:<br>
<br>
AllowNoInt yes<br>
UseHysteresis no<br>
LinkQualityFishEye 1<br>
LinkQualityLevel 2<br>
LinkQualityAging 0.1<br>
LinkQualityAlgorithm "etx_ff"<br>
LinkQualityDijkstraLimit 0 9.0<br>
FIBMetric "flat"<br>
Pollrate 0.025<br>
TcRedundancy 2<br>
MprCoverage 3<br>
MinTCVTime 500.0<br>
NatThreshold 0.75<br>
<br>
Interface "wl0"<br>
{<br>
Ip4Broadcast 255.255.255.255<br>
HelloInterval 5.0<br>
HelloValidityTime 40.0<br>
TcInterval 2.0<br>
TcValidityTime 256.0<br>
MidInterval 18.0<br>
MidValidityTime 324.0<br>
HnaInterval 18.0<br>
HnaValidityTime 108.0<br>
}<br>
<br>
And tap0 interface has LinkQualityMult default 0.80 added. And yes, we<br>
have the same IP addresses on all interfaces (so on "gerbiceva-49"<br>
both tap0 and wl0 interface has the same address).<br>
<br>
<br>
Mitar<br>
<font color="#888888"><br>
--<br>
Olsr-users mailing list<br>
<a href="mailto:Olsr-users@lists.olsr.org">Olsr-users@lists.olsr.org</a><br>
<a href="http://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">http://lists.olsr.org/mailman/listinfo/olsr-users</a><br>
<br>
</font></blockquote></div><br>