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

Fri Jan 6 21:26:08 CET 2017

On 06/01/17 21:16, Conrad Lara wrote:
> Is this an OLSRd V2 issue or an OLSRd V1 issue?
>
> I am attempting to replicate this under OLSRd v1 to understand what
> is occurring before expressing an opinion on the proposed solution
> but have been unable to duplicate in my local lab.
>
> Would it be possible to obtain a copy of the config files utilized to
> see if  a configuration difference may be at play here?
>
>
> Here is a sample of the network I created for testing inside of
> VMWARE to evaluate if that may be the root cause as well:
>
> eth1 on both sides: is a vmware network that is isolated to just
> these two hosts (I'm treating this as the wifi link) eth2/3 (node 97)
> and eth2(node 61) are on a shared virtual switch with trunking
> permitted so they are on the same wire. (simulating the two hard
> wired network as shown in the initial diagram)
>
> Mode ether on the eth2 eth3's  and mode mesh on the eth1's  using
> etx_ffeth module for route calcs.
>
> Ubuntu 14.04 running stock available olsr.org -
> 0.6.6.1-git_0000000-hash_41d32a614ae55e881b7c0456c8e3ed54 (built on
> 2013-10-26 05:10:52 on toyol)
>

That olsrd is very very old.

Use master.

>
> Packets appear to be reaching everyone correctly the the correct
> isolation ("wifi" is seeing only the "wifi" packets and the hosts on
> the "hardwire" are seeing the "hardwire" packets)
>
> From "Node 97"
>
> Routes: Destination	Gateway	Metric	ETX	Interface 172.28.175.97
> 172.29.175.97	1	0.100	eth2.2580 172.29.175.97	172.29.175.97	1	0.100
> eth2.2580 172.31.175.97	172.29.175.97	1	0.100	eth2.2580
>
> Links: Local IP	Remote IP	Hysteresis	LinkCost 172.31.175.97
> 172.31.175.61	0.00	(1.000/1.000) 1.000 172.29.175.97	172.29.175.61
> 0.00	(1.000/1.000) 0.100 172.28.175.97	172.29.175.61	0.00
> (1.000/1.000) 0.100
>
>
> eth1 IP: 172.31.175.97 	MASK: 255.255.0.0 	BCAST: 255.255.255.255
> MTU: 1472 	WLAN: No 	STATUS: UP eth2.2580 IP: 172.29.175.97 	MASK:
> 255.254.0.0 	BCAST: 255.255.255.255 MTU: 1472 	WLAN: No 	STATUS: UP
> eth3.2580 IP: 172.28.175.97 	MASK: 255.254.0.0 	BCAST:
> 255.255.255.255 MTU: 1472 	WLAN: No 	STATUS: UP
>
>
> From "Node 61":
>
> Routes: Destination	Gateway	Metric	ETX	Interface 172.28.175.97
> 172.29.175.97	1	0.100	eth2.2580 172.29.175.97	172.29.175.97	1	0.100
> eth2.2580 172.31.175.97	172.29.175.97	1	0.100	eth2.2580
>
> Links: Local IP	Remote IP	Hysteresis	LinkCost 172.31.175.97
> 172.31.175.61	0.00	(1.000/1.000) 1.000 172.29.175.97	172.29.175.61
> 0.00	(1.000/1.000) 0.100 172.28.175.97	172.29.175.61	0.00
> (1.000/1.000) 0.100
>
> eth1 IP: 172.31.175.61 	MASK: 255.255.0.0 	BCAST: 255.255.255.255
> MTU: 1472 	WLAN: No 	STATUS: UP eth2.2580 IP: 172.29.175.61 	MASK:
> 255.254.0.0 	BCAST: 255.255.255.255 MTU: 1472 	WLAN: No 	STATUS: UP
>
>
>
>
> ---- Ferry Huberts <(spam-protected)> wrote:
>> 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 2- Use
> the 'best' values for a neighbour that is reported in a HELLO
> message
>
>
> 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.
>
>
> 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.
>
>
>
> Greetings,
>
> Iwan, Teco and Ferry
>

-- 
Ferry Huberts