[Olsr-dev] [RFC] problems with multiple interfaces on the same medium + proposed solution

[Teco Boot]

> Op 6 jan. 2017, om 11:23 heeft Ferry Huberts <(spam-protected)> het volgende geschreven:
> 
> Below we describe a problem we encountered with olsrd and we explicitly
> ask any interested party to read this and provide feedback. Especially so
> because we will also propose a solution which will make changes to the
> way HELLO messages are generated and sent.
> 
> Ok, now into it...
> 
> A while ago we noticed that neighbours of nodes with multiple interfaces
> on the same medium report infinite costs on their links to those nodes.
> 
> Below is the setup in which we noticed the problem, which is 100%
> reproducible.
> 
>       wlan0                                                 wlan0
>       172.31.175.97/16                           172.31.175.61/16
>    (((*))) ------------------------------------------------- (((*)))
>       |                                                         |
>       |                                                         |
>       |                                                         |
>   ____|___   172.29.175.97/15   ________  172.29.175.61/15  ____|____
>  |         |-eth1.2580---------|        |--------eth1.2580-|         |
>  | Node 97 |                   | Switch |                  | Node 61 |
>  |_________|-eth2.2580---------|________|                  |_________|
>              172.28.175.97/15
> 
> 
> In this setup node 97 will report normal link costs for its (wired) links
> to node 61 (see the first table below), while node 61 will report infinite
> link costs for both its (wired) links to node 97 (see the second table
> below).
> 
>  Table: Links (node 97)
>  Local IP       Remote IP       Hyst.   LQ      NLQ     Cost
>  172.29.175.97  172.29.175.61   0.000   1.000   1.000   0.100
>  172.28.175.97  172.29.175.61   0.000   1.000   1.000   0.100
>  172.31.175.97  172.31.175.61   0.000   1.000   1.000   1.000
> 
>  Table: Links (node 61)
>  Local IP       Remote IP       Hyst.   LQ      NLQ     Cost
>  172.29.175.61  172.29.175.97   0.000   1.000   0.000   INFINITE
>  172.29.175.61  172.28.175.97   0.000   1.000   0.000   INFINITE
>  172.31.175.61  172.31.175.97   0.000   1.000   1.000   1.000
> 
> 
> Checking the HELLO messages on node 61 that are received from node 97
> we see the following:
> 
>  [node 61] # tcpdump -vni eth1.2580 udp port 698
>  tcpdump: listening on eth1.2580, link-type EN10MB (Ethernet), capture size 262144 bytes
>  06:21:23.528204 IP (tos 0xc0, ttl 1, id 42455, offset 0, flags [DF], proto UDP (17), length 80)
>      172.28.175.97.698 > 255.255.255.255.698: OLSRv4, seq 0xf7c0, length 52
>     Hello-LQ Message (0xc9), originator 172.31.175.97, ttl 1, hop 0
>       vtime 3.000s, msg-seq 0x533d, length 48
>       hello-time 1.000s, MPR willingness 3
>         link-type Symmetric, neighbor-type Symmetric, len 12
>           neighbor 172.29.175.61, link-quality 0.00%, neighbor-link-quality 0.00%
>         link-type Unspecified, neighbor-type Symmetric, len 20
>           neighbor 172.31.175.61, link-quality 0.00%, neighbor-link-quality 0.00%
>           neighbor 172.29.175.61, link-quality 0.00%, neighbor-link-quality 0.00%
> 
> 
> Node 61 receives HELLO messages from node 97 that report (among others):
> 1- a  SYMMETRIC   link-type to node 61 (172.29.175.61)
> 2- an UNSPECIFIED link-type to node 61 (172.29.175.61)
> 
> Clearly, this is 'confusing' and the root cause of why node 61 reports
> infinite costs for the links, as show above.
> 
> We pose that in a HELLO message the same neighbour should NEVER be reported
> with conflicting information.
> 
> 
> Proposed solution:
> 
> 1- NEVER report a neighbour more than once in a HELLO message

This needs some rewording. 'neighbor' could be a node (e.g. main address)
or be an 'interface address of a neighbor'. Here, the latter is meant.


> 2- Use the 'best' values for a neighbour that is reported in a HELLO
>   message

This 'best' needs some explanation: it is 'best fits', or 'neighbor state for this 
interface'. The neighbor with link-type UNSPECIFIED could in reality be quite good 
link, ETX=1 or ETHER. But this is learned via another interface. Such is not the 
simple scenario as above, where cables are used and link is up or down, and 
interfaces would have the same type (e.g. ETHER).


> 
> 1- Requires that we de-duplicate neighbours when constructing a HELLO
>   message.
> 
> 2- Requires - when a neighbour is already present in the HELLO message
>   that is under construction - that we determine the 'best' values and
>   overwrite those in the neighbour that is already present if those
>   are worse.

Again, 'best' and 'worse' are not words that exactly define what has to be done.
It is the link-type of 'this interface' that shall be passed.


> 
> We have a quick-and-dirty patch implementing this proposed solution and it
> works well. We are currently cleaning up that patch.
> 
> 
> We're explicitly soliciting feedback on this approach.

I've looked at the problem and solution. Stripping the 'duplicate/in error'
approach is OK for me. A patch is needed.

I did not check the Q&D patch.

Teco


> 
> 
> 
> Greetings,
> 
> Iwan, Teco and Ferry