[Olsr-dev] Missing routes and unexpected routes reg.

[Vigneswaran R]

On 06/09/2014 03:10 PM, Henning Rogge wrote:
> 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").

Yeah.. it's working now. Thanks.

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.

*Note:* 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.

Cannot find loader for parameter 'Debug'
Error, unknown config io '/root/olsrd2.conf'.


Regards,
Vignesh

>
> Henning
>
> On Mon, Jun 9, 2014 at 11:32 AM, Vigneswaran R <(spam-protected)> wrote:
>> 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 <(spam-protected)> 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 <(spam-protected)> 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 <(spam-protected)>
>> 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
>> <(spam-protected)>
>> wrote:
>>
>> * Vigneswaran R <(spam-protected)> [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
>> (spam-protected)
>> https://lists.olsr.org/mailman/listinfo/olsr-dev
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20140609/7d83123d/attachment.html>