public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: gtolon@inti.gob.ar
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
Date: Thu, 14 Jun 2012 16:51:01 -0300	[thread overview]
Message-ID: <4FDA40A5.1050008@inti.gob.ar> (raw)
In-Reply-To: <CAHD-aqK_CGbc8u5GuEBJyFzrk2rTHHTw=bAiWjFafAW9xOqWiw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5731 bytes --]

Hi,

     we are interested too in interface alternating, so we made some 
tests to understand how it works. As you can see on the attached 
sketch.png, we connected two pair of routers using their ethernet 
interfaces, E6 with E7, and E8 with E9. All of them have eth0, and an ad 
hoc interface, wlan0-1, managed by batman. E6 and E8 are in channel 11, 
whereas E7 and E9 are in channel 1. Besides we used two other routers, 
E12 and E13, both in channel 11, with their tx power set to just 0 dbm, 
to avoid a direct sight between them.

     Then we sent traffic from E12 to E13. We expected that packets 
travelled from E12 to E6, and that E6 forwarded them to his eth0 to use 
the interface alternating feature, making traffic flow to E7, then E9, 
E8 and finally E13. But instead, we observed that the actual path was 
E12--E6--E8--E13. The resulting routes for each router are attached in a 
text file, and also the graph from the batctl vd dot command.

     After this result, we read again the thread mentioned by Guido, 
specially in this part:

https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006344.html

    And if we understand correctly, the alternation feature works after 
the batman path has been selected. So in our case, E12 looks at his 
table to know where to send a packet to E13, and finds E6. Then E6 
receives the packet and looks in his own table, finding that the best 
path to reach E13 is E8. At this point, the alternating should work, but 
there's only one interface directly connected to E8, so the packet goes 
there, and so on. We think that if E6 and E7 were not two different 
routers running batman-adv but they were two radios of the same 
batman-adv router, and the same for E8 and E9, the alternating would 
work, because the unique router would choose the best path, and then 
would find two possible interfaces to the same next-hop, changing the 
interface.

     We'd like to know if this interpretation is correct, and in that 
case, if it were possible to use interface alternating in a case like 
this, with two routers connected to work together. Thanks!

Gabriel


El 31/03/2012 12:48 a.m., Guido Iribarren escribió:
> On Fri, Mar 30, 2012 at 2:18 PM, dan<dandenson@gmail.com>  wrote:
>
>> ok, this is an option I had considered, but I'm worried that link
>> alternation wont be an option as the radios only have a single radio
>> and the alternate path is through a completely different radio/device
>> connected via ethernet.
> batman-adv makes no difference between ethernet or radio interfaces,
> they are all simply just interfaces that somehow link to other
> batman-adv nodes (with some -or zero- packet loss)
> so link alternation would work the same: if packet comes in through
> radio, and batman-adv can reach the destination through the ethernet
> port (it doesn't matter if that implies hopping through more
> batman-adv nodes) it will prefer sending it through this "alternate"
> path (alternate in the sense it doesn't use the same interface the
> packet came in)
>
>> As far as vlans are concerned, are you saying to have a vlan on the
>> router for each attached picostation and then set the picostations
>> ethernet interface to match that vlan?  Then I can add all the vlans
>> to bat0?
> exactly.
>
>> maybe if you could clarify this for me.  for link alternating, do the
>> two nodes need to be one hop neighbors?
> Nope, not needed. And in fact it is "interface alternation" (subtle difference).
> if packet comes in through interface A, and the final destination is
> reachable through 2 different paths that start at interface A and
> interface B respectively, it will send the packet through interface B
> to avoid reusing interface A.
> It doesn't matter if between interface B and final destination there are N hops.
>
> A long thread earlier this month was particularly clarifying on the subject.
> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006351.html
>
>> according to docs, link alternating works in this scenario, where both
>> links are good:
>> node1_Link1------------node2_Link1
>> node1_Link2------------node2_Link2
>>
>> but what about this:
>> node1_Link1------node3_Link1------node2_Link1
>> node1_Link2------node4_Link2------node2_Link2
>>
>> will node1 and node2 still have link alternation?
> Yes. in addition you might also be interested in interface bonding,
> which is not enabled by default but can be activated after
> understanding a few caveats. it's documented on batctl manpage online.
>
>>   This is basically
>> what the central router + picostations with the picostations running
>> batman-adv would look like
>>
>>
>> supernode1-------picostation1---------picostation1--------supernode2
>> supernode1-------picostation2---------picostation2--------supernode2
>>
>> so supernode2 is then a 3 hop neighbor to supernode1.  So will link
>> alternation work here?  Lets just say that supernode1 has the backhaul
>> and supernode2 has nothing except it's link to supernode1.  Ideally,
>> SN2 gets the faster, dual link connection to SN1.
> If picostations are only connected point-to-point to each other, and
> there are no other clients sending traffic to them (except the
> supernodes), then interface alternating won't take advantage of the
> "faster dual link connection"
> You must use interface bonding to achieve that.
>
> Interface alternating would be useful, for example, if picostation2
> from supernode2 was receiving a radio transmission from a distant
> supernode3 (not pictured) destined at supernode1. Then, instead of
> trying to relay the packets through that same picostation2, it would
> use picostation1 to send them and avoid reusing the same interface.
>
> Cheers!
>
> Guido
>

[-- Attachment #2: sketch.png --]
[-- Type: image/png, Size: 13907 bytes --]

[-- Attachment #3: rutas9 --]
[-- Type: text/plain, Size: 5020 bytes --]

rutas9.png


E6:

[B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/fa:d1:11:24:54:5d (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
       E9-wlan0-1    0.950s   (245)        E8-wlan0-1 [   wlan0-1]:           E7-eth0 (240)        E8-wlan0-1 (245)
       E8-wlan0-1    0.550s   (255)        E8-wlan0-1 [   wlan0-1]:           E7-eth0 (235)       E12-wlan0-1 (235)        E8-wlan0-1 (255)
      E13-wlan0-1    0.570s   (234)        E8-wlan0-1 [   wlan0-1]:           E7-eth0 (216)        E8-wlan0-1 (234)
      E12-wlan0-1    0.780s   (255)       E12-wlan0-1 [   wlan0-1]:       E12-wlan0-1 (255)
          E7-eth0    0.230s   (255)           E7-eth0 [      eth0]:           E7-eth0 (255)
       E7-wlan0-1    0.570s   (255)           E7-eth0 [      eth0]:           E7-eth0 (255)        E8-wlan0-1 (  0)


E7:

[B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/fa:d1:11:24:54:83 (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
       E9-wlan0-1    0.130s   (249)        E9-wlan0-1 [   wlan0-1]:           E6-eth0 (235)        E9-wlan0-1 (249)
       E6-wlan0-1    0.340s   (253)           E6-eth0 [      eth0]:           E6-eth0 (253)        E9-wlan0-1 (208)
       E8-wlan0-1    0.810s   (245)           E6-eth0 [      eth0]:           E6-eth0 (245)        E9-wlan0-1 (236)
      E13-wlan0-1    0.730s   (224)           E6-eth0 [      eth0]:           E6-eth0 (224)        E9-wlan0-1 (218)
      E12-wlan0-1    0.940s   (245)           E6-eth0 [      eth0]:           E6-eth0 (245)        E9-wlan0-1 (197)
          E6-eth0    0.620s   (255)           E6-eth0 [      eth0]:           E6-eth0 (255)


E8:

[B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/fa:d1:11:24:59:a7 (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
       E9-wlan0-1    0.810s   (255)           E9-eth0 [      eth0]:        E6-wlan0-1 (208)           E9-eth0 (255)
          E9-eth0    0.050s   (255)           E9-eth0 [      eth0]:           E9-eth0 (255)
       E6-wlan0-1    0.850s   (221)        E6-wlan0-1 [   wlan0-1]:           E9-eth0 (  0)       E13-wlan0-1 (  0)        E6-wlan0-1 (221)
      E13-wlan0-1    0.410s   (246)       E13-wlan0-1 [   wlan0-1]:        E6-wlan0-1 (192)       E13-wlan0-1 (246)
      E12-wlan0-1    0.410s   (212)        E6-wlan0-1 [   wlan0-1]:           E9-eth0 (  0)        E6-wlan0-1 (212)
       E7-wlan0-1    0.200s   (224)           E9-eth0 [      eth0]:        E6-wlan0-1 (211)           E9-eth0 (224)

E9:

[B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/fa:d1:11:24:5a:95 (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
       E6-wlan0-1    0.370s   (222)        E7-wlan0-1 [   wlan0-1]:        E7-wlan0-1 (222)           E8-eth0 (210)
       E8-wlan0-1    0.920s   (255)           E8-eth0 [      eth0]:        E7-wlan0-1 (215)           E8-eth0 (255)
      E13-wlan0-1    0.840s   (236)           E8-eth0 [      eth0]:        E7-wlan0-1 (199)           E8-eth0 (236)
      E12-wlan0-1    0.920s   (215)        E7-wlan0-1 [   wlan0-1]:        E7-wlan0-1 (215)           E8-eth0 (203)
          E8-eth0    0.970s   (255)           E8-eth0 [      eth0]:           E8-eth0 (255)
       E7-wlan0-1    0.630s   (234)        E7-wlan0-1 [   wlan0-1]:           E8-eth0 (215)        E7-wlan0-1 (234)


E12:

[B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/fa:d1:11:24:54:7f (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
       E9-wlan0-1    0.510s   (235)        E6-wlan0-1 [   wlan0-1]:        E6-wlan0-1 (235)
       E6-wlan0-1    0.770s   (255)        E6-wlan0-1 [   wlan0-1]:        E6-wlan0-1 (255)
       E8-wlan0-1    0.200s   (245)        E6-wlan0-1 [   wlan0-1]:        E6-wlan0-1 (245)        E8-wlan0-1 (  0)
      E13-wlan0-1    0.090s   (225)        E6-wlan0-1 [   wlan0-1]:        E6-wlan0-1 (225)
       E7-wlan0-1    0.090s   (245)        E6-wlan0-1 [   wlan0-1]:        E6-wlan0-1 (245)

E13:

[B.A.T.M.A.N. adv 2012.0.0, MainIF/MAC: wlan0-1/fa:d1:11:24:53:47 (bat0)]
  Originator      last-seen (#/255)           Nexthop [outgoingIF]:   Potential nexthops ...
       E9-wlan0-1    0.460s   (245)        E8-wlan0-1 [   wlan0-1]:        E8-wlan0-1 (245)
       E6-wlan0-1    0.710s   (206)        E8-wlan0-1 [   wlan0-1]:        E8-wlan0-1 (206)        E6-wlan0-1 (  0)
       E8-wlan0-1    0.160s   (250)        E8-wlan0-1 [   wlan0-1]:        E8-wlan0-1 (250)
      E12-wlan0-1    0.270s   (193)        E8-wlan0-1 [   wlan0-1]:        E8-wlan0-1 (193)
       E7-wlan0-1    0.060s   (216)        E8-wlan0-1 [   wlan0-1]:        E8-wlan0-1 (216)


TR E12:

traceroute to E13-wlan0-1 (fa:d1:11:24:53:47), 50 hops max, 20 byte packets
 1: E6-wlan0-1 (fa:d1:11:24:54:5d)  0.791 ms  0.820 ms  0.596 ms
 2: E8-wlan0-1 (fa:d1:11:24:59:a7)  1.889 ms  2.815 ms  1.613 ms
 3: E13-wlan0-1 (fa:d1:11:24:53:47)  2.472 ms  4.252 ms  5.048 ms



[-- Attachment #4: rutas.jpg --]
[-- Type: image/jpeg, Size: 47283 bytes --]

  parent reply	other threads:[~2012-06-14 19:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-30 13:35 [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router? dan
2012-03-30 16:33 ` Guido Iribarren
2012-03-30 17:18   ` dan
2012-03-31  3:48     ` Guido Iribarren
2012-03-31 15:45       ` Dan Denson
2012-03-31 18:11         ` Guido Iribarren
2012-03-31 21:03           ` dan
2012-04-01  1:31             ` Nicolás Echániz
2012-04-01  1:53               ` [B.A.T.M.A.N.] [OT] ruci / Was: " Nicolás Echániz
2012-04-01  2:10                 ` dan
2012-06-14 19:51       ` gtolon [this message]
2012-06-15  9:55         ` [B.A.T.M.A.N.] " Simon Wunderlich
2012-06-18 18:46           ` gtolon
2012-07-13 20:56             ` gtolon
2012-07-14 21:30               ` Guido Iribarren
2012-07-14 21:35                 ` Guido Iribarren
2012-07-17 13:36                   ` gtolon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FDA40A5.1050008@inti.gob.ar \
    --to=gtolon@inti.gob.ar \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox