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

[Ferry Huberts]

'best' shall become clear from the patch once it is cleaned up.


On 06/01/17 19:43, Teco Boot wrote:
>
>> 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
>

-- 
Ferry Huberts