23 Jul
2007
23 Jul
'07
12:07 p.m.
Hi Axel,
this is great and I will try it, but I can not promise to give you
results soon because
the lack of time.
If I have multiple connections between two nodes, is there a way to
setup the quality or
priority of those connection?
Assume I have tree or more nodes connected in a line (A,B,C,D) and
node A and Node D are
connected via backbone tunnel over Internet, the wireless connection
should be used until
the quality falls below a certain level or the number of nodes
exceeded a maximum value. setting up a hysteresis should be possible
to avoid to much
switching of the route.
eth1: A ------- B ------- C ------- D
bbs: A ============================D
Regards
Stephan
24 Jul
24 Jul
5:44 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Freifunk Dresden wrote:
If I have multiple connections between two nodes, is
there a way to
setup the quality or
priority of those connection?
Same goes for Leipzig, we have our vpn[1,2].leipzig.freifunk.net nodes.
I thought about this problem a lot and the simplest solution would be to
simply drop like 9 of 10 batman packets on the outgoing vpn interface.
this is like a olsr multiplicator of 10 with the advantage that it saves
bandwith.
short anecdote about dropping olsr packets:
so, we now have this huge vpn that connects most edges of the mesh to
central olsr nodes. because this are just backup routes, we have to
increase the etx value, no problem with the olsr multiplier option. on
the vpn a packetloss of 0% ist relative normal, so you pump out 5kb/s of
olsr traffic just to say: mmhh, ok, very good connection but i think its
bad anyway. so, if olsr messures the packet loss rate, i could simply
drop 9 of 10 packets and with 0.5kb/s i would have the same effect. if
that is what olsr is supposed to do.
by the way, we have arround 400 GB per month olsr overhead alone, which
is just creazy for a routing protocol overhead.
i ran a couple of tests.
there is a iptables match called nth, so i tested to allow only every
tenth packet. i got a etx of 0.0
strange: i allowed 50% -> etx 0.0
stranger: i allowed 90% -> etx 0.0
there is a percent match. i combined them, i tried percent alone, etc.
olsr depends a lot about which packets get dropped.
you simply can't just drop packets without getting etx 0.0 for at least
periods of 20-30 seconds, which drives you nuts.
batman should work very well with that approach.
kindly regards
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGpZG/y/mkIQp7AD0RAtcUAKDPP/rKGgMt5doPyLdgxcDPm1cO/QCgsQ09
kXCustGVyorDABZKxXlutWk=
=BXOc
-----END PGP SIGNATURE-----
10:54 a.m.
Hi
On Tuesday 24 July 2007 07:44, Daniel Poelzleithner wrote:
Freifunk Dresden wrote:
on a specific interface
a) you man drop received originator messages (OGMs) which does not really
reducing the traffic or
b) suspend the sending of OGMs
However, dropping or suspending should only be applied to OGMs from
non-neighboring nodes, otherwise it also affects the bidirectional link check
which would result in a confusing side-effect, marking even more packets as
invalid.
In parallel it might be beneficial to configure different originator intervals
for particular interfaces. For example for a vpn connection a very large
originator interval (with a small TTL would be sufficient) since its
link-quality is not supposed to change anyway (and causing less traffic to
the vpn).
/axel
If I have multiple connections between two nodes,
is there a way to
setup the quality or
priority of those connection?
Same goes for Leipzig, we have our vpn[1,2].leipzig.freifunk.net nodes.
I thought about this problem a lot and the simplest solution would be to
simply drop like 9 of 10 batman packets on the outgoing vpn interface.
this is like a olsr multiplicator of 10 with the advantage that it saves
bandwith.
3 Sep
3 Sep
4:21 p.m.
Hello,
On Dienstag 24 Juli 2007, Daniel Poelzleithner wrote:
Freifunk Dresden wrote:
> If I have multiple connections between two nodes, is there a way to
> setup the quality or
> priority of those connection?
you can experiment with that using batman-experimental rv555. Try
--send-clones ( /c <value> ) which can be used to increase or decrease the
quality of a link by specifying a probability how often a received OGM should
be rebroadcasted. The default value for this parameter is 100, saying each
OGM will be (re-)broadcasted with a probability of 100%. Applying a value
less than 100 will let the links to a node appear worse than they actually
are. A value larger than 100 will clone packets and send them multiple times
(retending better connectivity to the node than there actually is).
For example:
180 results in 80 % of the OGM to be (re-)broadcasted twice.
30 results in 70% of the OGMs not being (re-)broadcasted at all.
Since --send-clones will change the default value (affecting all interfaces of
a node) there is also an interface-specific variant of this feature: "/c
<value>", which must be applied after the interface name and will only affect
the broadcast-probability for a specific interface.
Another thing is the problem with the bidirectional link check. This check by
default allows a maximum of one OGM from my neighboring link peer to be lost
before the link is temporary considered non-bidirectional or invalid. So, if
70% of the to-be-broadcasted OGMs are intentional not send at all (because
of /c 30) the bidirectinal link check will fail very often. This has the
side-effect that many OGMs from distant nodes will be ignored even more.
This problem can be resolved by also applying the /b <value> (the
interface-specific variant of the --bi-link-timeout) switch to the dropping
interface and giving it a higher value that the default value of two.
So if you have a dsl-vpn-fallback-link (which you only want to use in case of
terrible wireless connectivity) called dsl0. And you have the wireless
interface wlan0, then try: $batmand wlan0 dsl0 /c 40 /b 6
This will suspend 60% of the OGMs from being broadcasted via interface dsl0
and relieves the bidirectional link check at this interface from two to five.
greetings,
axel
and
--bi-link-timeout <value> ( /b <value> )
There are interface-specific switches called /c and /b which must be applied
behind an interface name
Same goes for Leipzig, we have our vpn[1,2].leipzig.freifunk.net nodes.
I thought about this problem a lot and the simplest solution would be to
simply drop like 9 of 10 batman packets on the outgoing vpn interface.
this is like a olsr multiplicator of 10 with the advantage that it saves
bandwith.
short anecdote about dropping olsr packets:
so, we now have this huge vpn that connects most edges of the mesh to
central olsr nodes. because this are just backup routes, we have to
increase the etx value, no problem with the olsr multiplier option. on
the vpn a packetloss of 0% ist relative normal, so you pump out 5kb/s of
olsr traffic just to say: mmhh, ok, very good connection but i think its
bad anyway. so, if olsr messures the packet loss rate, i could simply
drop 9 of 10 packets and with 0.5kb/s i would have the same effect. if
that is what olsr is supposed to do.
by the way, we have arround 400 GB per month olsr overhead alone, which
is just creazy for a routing protocol overhead.
i ran a couple of tests.
there is a iptables match called nth, so i tested to allow only every
tenth packet. i got a etx of 0.0
strange: i allowed 50% -> etx 0.0
stranger: i allowed 90% -> etx 0.0
there is a percent match. i combined them, i tried percent alone, etc.
olsr depends a lot about which packets get dropped.
you simply can't just drop packets without getting etx 0.0 for at least
periods of 20-30 seconds, which drives you nuts.
batman should work very well with that approach.
kindly regards
Daniel
_______________________________________________
B.A.T.M.A.N mailing list
B.A.T.M.A.N(a)open-mesh.net
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
5680
days inactive
5722
days old
b.a.t.m.a.n@lists.open-mesh.org
3 comments
3 participants
participants (3)
-
Axel Neumann -
Daniel Poelzleithner -
Freifunk Dresden