[Olsr-dev] Missing routes and unexpected routes reg.
Vigneswaran R
(spam-protected)
Mon Jun 9 11:32:45 CEST 2014
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/0ba18ea3/attachment.html>
More information about the Olsr-dev
mailing list