[Olsr-dev] [RFC] problems with multiple interfaces on the same medium + proposed solution
Conrad Lara
(spam-protected)
Fri Jan 6 21:41:42 CET 2017
---- Ferry Huberts <(spam-protected)> wrote:
>
>
> 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.
>
I agree it is an old version and will give the latest mainline a test, but if this issue only occurs in master I would believe that would make this a regression flaw in hello message parsing and shouldn't we instead look at placing the code there instead of changing how we broadcast hello's by removing data that has historically been broadcasted over the network?
Here is a sample tcpdump from mine (stil on 0.6.6.1) where it shows the symmetric symmetric, and unknown symmetric, and yet a link works perfectly.
12:34:20.083461 IP (tos 0xc0, ttl 64, id 64800, offset 0, flags [DF], proto UDP (17), length 104)
172.28.175.97.698 > 255.255.255.255.698: OLSRv4, seq 0x1c2b, length 76
Hello-LQ Message (0xc9), originator 172.31.175.97, ttl 1, hop 0
vtime 576.000s, msg-seq 0x910e, length 48
hello-time 6.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.29.175.61, link-quality 0.00%, neighbor-link-quality 0.00%
neighbor 172.31.175.61, link-quality 0.00%, neighbor-link-quality 0.00%
TC-LQ Message (0xca), originator 172.31.175.97, ttl 255, hop 0
vtime 288.000s, msg-seq 0x910f, length 24
advertised neighbor seq 0x003d
neighbor 172.31.175.61, link-quality 0.00%, neighbor-link-quality 0.00%
>
> >
> > 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
More information about the Olsr-dev
mailing list