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

[Henning Rogge]

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").

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
>
>