<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/09/2014 03:10 PM, Henning Rogge
wrote:<br>
</div>
<blockquote
cite="mid:CAGnRvuq+aM5dOE+qjwzG0wwPAGrAswOzDwYTOOhH2rJg3bVnWw@mail.gmail.com"
type="cite">
<pre wrap="">Okay,
I just found the problem... I messed up the merge of the MPR code and
activated it by default.
Please try the most recent commit from the repository (it includes the
/nhdp neighbor update). Now you should NOT get the mpr plugin included
into the executable by default (check with "olsrd2 --version").</pre>
</blockquote>
<br>
Yeah.. it's working now. Thanks.<br>
<br>
After excluding 'mpr' plugin, every node is getting route to the
other nodes. One thing I noticed is, every node is selecting the
neighbors as MPRs. So, I assume that MPR optimization will be done
by the 'mpr' plugin only.<br>
<br>
<b>Note:</b> I have done the above test with the code committed upto
05th June (inclusive). If I include the commits from 06th June, I am
getting the following runtime error.<br>
<br>
Cannot find loader for parameter 'Debug'<br>
Error, unknown config io '/root/olsrd2.conf'.<br>
<br>
<br>
Regards,<br>
Vignesh<br>
<br>
<blockquote
cite="mid:CAGnRvuq+aM5dOE+qjwzG0wwPAGrAswOzDwYTOOhH2rJg3bVnWw@mail.gmail.com"
type="cite">
<pre wrap="">
Henning
On Mon, Jun 9, 2014 at 11:32 AM, Vigneswaran R <a class="moz-txt-link-rfc2396E" href="mailto:vignesh@atc.tcs.com"><vignesh@atc.tcs.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 06/09/2014 02:11 PM, Henning Rogge wrote:
I wrote a patch to include the MPRs into the "nhdp neighbor" telnet
command of OLSRd2, but I don't have a testing setup at home.
If you want you can test it.
Thanks for your quick reply and the patch was very helpful.
Below is the output of running the "nhdp neighbor" on all the routers.
On R1
=====
Neighbor: symmetric flood-MPR=yes flood-MPRS=no
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=no
Address: 10.1.2.1
Address: 10.1.2.2
What I understand from the above is, R2 is selected as a Flooding as well as
Routing MPR for R1. However, R2 hasn't selected R1 as routing or flooding
MPR.
On R2
=====
Neighbor: symmetric flood-MPR=no flood-MPRS=yes
Metric 'mpr' (0): routing-MPR=no, routing-MPR=yes
Address: 10.1.1.1
Neighbor: symmetric flood-MPR=yes flood-MPRS=no
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=yes
Address: 10.1.3.1
Address: 10.1.3.2
Here the additional information is, R3 is selected as a Flooding as well as
routing MPR for R2. However, R3 selected R2 only as routing MPR; not as
flooding MPR. I think, this is the problem.
On R3
=====
Neighbor: symmetric flood-MPR=no flood-MPRS=yes
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=yes
Address: 10.1.2.1
Address: 10.1.2.2
Neighbor: symmetric flood-MPR=no flood-MPRS=no
Metric 'mpr' (0): routing-MPR=no, routing-MPR=yes
Address: 10.1.4.1
Address: 10.1.4.2
Here, the additional information is, R4 is not selected as a Flooding or
Routing MPR for R3. However, R4 selected R3 as its Routing MPR; not flooding
MPR. I think, this is fine (as R4 doesn't have to create TC to be
forwarded).
On R4
=====
Neighbor: symmetric flood-MPR=no flood-MPRS=no
Metric 'mpr' (0): routing-MPR=yes, routing-MPR=no
Address: 10.1.3.1
Address: 10.1.3.2
Nothing new here.
Regards,
Vignesh
Henning
On Mon, Jun 9, 2014 at 8:49 AM, Vigneswaran R <a class="moz-txt-link-rfc2396E" href="mailto:vignesh@atc.tcs.com"><vignesh@atc.tcs.com></a> wrote:
On 06/09/2014 12:09 PM, Henning Rogge wrote:
Just a thought I had,
did you try to use the "MPR plugin" ? I ask because its quite new and
needs a lot more testing.
No. I haven't.
Also, I verified the logs and couldn't find any TC messages (Message type:
1) generated by R1 or R4 (the end nodes).
Is there any way to query the olsrd2 daemon about MPR related information?
Regards,
Vignesh
Henning
On Sat, Jun 7, 2014 at 4:02 AM, vignesh <a class="moz-txt-link-rfc2396E" href="mailto:vignesh@atc.tcs.com"><vignesh@atc.tcs.com></a> wrote:
On 2014-06-06 18:41, Henning Rogge wrote:
Hi,
just to make sure, you can see all four nodes producing TC messages?
I remember only R2 and R3 produced TC. However, I will recheck the logs
on
Monday.
(I have under the impression that only ROUTING MPRs will generate TC, and
in
this topology, R2, R3 may be the MPRs for its neighbours).
Maybe I have to replicate this setup when I am back at work on
Tuesday, I have no clue what is going on.
Ok. At this point what I suspect is, R3 is not selecting R2 as MPR. So,
the
TC message generated by R3 (which contains information about R4 also) is
not
reaching R1. So, R1 is not getting route for R4. Could you please tell
how
to verify the above from the logs? Esp. how to see information about
MPRs?
R1 <---> R2 <---> R3 <---> R4
If you would like to look into the logs I can compress the logs and send
you. Thanks.
Regards,
Vignesh
Henning
On Fri, Jun 6, 2014 at 2:38 PM, Vigneswaran R <a class="moz-txt-link-rfc2396E" href="mailto:vignesh@atc.tcs.com"><vignesh@atc.tcs.com></a>
wrote:
On 06/06/2014 02:58 PM, Vigneswaran R wrote:
On 06/06/2014 02:23 PM, Vigneswaran R wrote:
On 06/06/2014 01:01 PM, Henning Rogge wrote:
On Fri, Jun 6, 2014 at 9:39 AM, Bastian Bittorf
<a class="moz-txt-link-rfc2396E" href="mailto:bittorf@bluebottle.com"><bittorf@bluebottle.com></a>
wrote:
* Vigneswaran R <a class="moz-txt-link-rfc2396E" href="mailto:vignesh@atc.tcs.com"><vignesh@atc.tcs.com></a> [06.06.2014 09:37]:
Could you please help in debugging these problems? Thanks.
can you show is you commandline or config? bye, bastian
The output of "ip addr" on every node would also help.
Command Line:
./olsrd2 -l olsrd2.conf
Configuration file contents:
[interface=eth0]
[interface=eth1]
Exception: On R1, only eth1 included.
IP Addr: (pfa the complete output)
R1: eth0: 1.0.0.2/24 (non-olsr), eth1: 10.1.1.1/32
R2: eth0: 10.1.2.1/32, eth1: 10.1.2.2/32
R3: eth0: 10.1.3.1/32, eth1: 10.1.3.2/32
R4: eth0: 10.1.4.1/32, eth1: 10.1.4.2/32
(I am using /32 mask for testing. However, I got the same problem with
/8
mask also).
Please let me know if any other information is required.
PFA the output of the following command on all the nodes. Please see
whether
this helps.
echo "nhdp neighlink" | nc 127.0.0.1 2009
Restarted olsrd2 with debug=all and observed the following from the
collected logs,
1. R1 received TC messages originated from R2 (10.1.2.1) only.
-- Shouldn't it get TC from 10.1.3.1 also? I think, this is the
reason
why
R1 is not getting route for R4.
2. R2 received TC messages originated from R3 (10.1.3.1) only.
-- I think, this is fine for the 4 nodes topology.
3. R3 received TC messages originated from R2 (10.1.2.1) only.
-- this is also fine for the same reason.
4. R4 received TC messages originated from both R2 (10.1.2.1) and R3
(10.1.3.1).
If you want me to post specific portions of the log files, please
suggest.
Regards,
Vignesh
Regards,
Vignesh
--
Olsr-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Olsr-dev@lists.olsr.org">Olsr-dev@lists.olsr.org</a>
<a class="moz-txt-link-freetext" href="https://lists.olsr.org/mailman/listinfo/olsr-dev">https://lists.olsr.org/mailman/listinfo/olsr-dev</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>