Hello,
It's now possible to distribute both v4 and v6 on quagga's babeld in quagga
RE-testing-0.99, but the syntax is affected.
The definition of an access/prefix-list doesn't differ: the kind (v4 or v6) is
explicit, e.g. :
access-list toto deny any
ipv6 access-list
With the original babel daemon I was able to hook up machines thusly
ethernet, natted ipv4, native ipv6
| |
R1 ~~ R2 wifi native ipv4 and ipv6
export ipv6 babel routes over the ethernet interface, but not ipv4.
I think it's done with access-list. You must first
options, described in
details in the manual pages. These are:
- source-specific
- first-table-number
- first-rule-priority
- announce-with-default-source-prefix
- install-specific
This is experimental code, likely to change at any time. Any feedback
will be very much welcome.
-- Matthieu
This paper [1] evaluates […] on a real-world
network
No, the toplogy is realistic, but the evaluation is done in simulation.
But there is real-world measurements on the guifi network, and the
simulation depends of these measurements.
« This dissertation presents the characterisation of the
Dear all,
Here is a small demo of source-specific routing in babeld in a multihomed IPv6
environment:
http://www.pps.univ-paris-diderot.fr/~boutier/source-specific-routing.html
This page will be updated with our experiments with MPTCP. Currently, it seems
to work without any routing
Does this extension drive the source-specific tables in kernel?
Yes.
It uses the ip rule API, so it works for IPv4 and IPv6. The subtree API (ip
rule add … from …) should work in Linux 3.11, but only with IPv6. (We use
source-specific in IPv4 with our tunnels.)
Matthieu
Hello,
I believe the right way should be to configure the logger for babeld so that it
could use the appropriate signal. I don't know all loggers, but here is the
default debian logrotate's config file for babeld:
$ cat /etc/logrotate.d/babeld
/var/log/babeld.log {
weekly
rotate 8
Hello,
the ipv6-subtrees fix has been in linux since 3.10.12
You're right, I've pushed a patch for this, it seems to work. Note that the
code is not really simplified, since we keep it for v4.
Links recall:
git clone -b source-specific
Hi,
Laptop A:
eth0 10.20.30.1/24
wlan0 20.0.1.2/24
Laptop B:
eth0 10.20.30.2/24
wlan0 20.0.6.6/24
sudo babeld -C 'redistribute ip 20.0.0.0/8 allow' -C 'redistribute local
deny' -h 0.5 eth0 wlan0
In the manpages, you will found:
If action is not specified, it defaults to
Dear all,
There is many changes in the source-sensitive version of babeld
since the last announce. Recall that the code is available at:
git clone -b source-specific
git://git.wifi.pps.univ-paris-diderot.fr/babels.git
http://git.wifi.pps.univ-paris-diderot.fr/?p=babels.git
Hi,
Ad-hoc networks do not provide transitive connectivity
i.e. if A can see B, B can see C and A cannot see C directly, there will be
no automatic route from A to C via B.
That is correct. Ad-hoc is a specific mode of 802.11 (Wi-Fi), which
operates at layer 2 and does not deal at all
But on few occasions, it inserts negative routes with Flag set to !H and
metric set to -1 for hosts which are in direct range of each other.
I don't know what is !, perhaps unreachable. This seems (for the moment)
quite normal : you're moving, so the metric changes (it will increase at some
Hello,
Before beginning the tests in real life, i would like to know if anyone of
you could make it work properly and share its configuration (my thoughts are
about the need to use, or to not use, a bridge interface br0) :
- Bridge : What is the recommended configuration refering bridging
I would like to enhance the parameter:
hello interval
update interval
resend delay
link quality
in commande-line (without configuring the babeld.conf file).
A config file line can be passed through the command-line, using the -C option.
For example :
babeld -C interface eth0
(You will
I try to make an hop with 2 wireless card but it doesn't work. Howerver, when
i try with the prototoc OLSRD, the hop is made.
Is there a parameter to add or to suppress ?
I believe babeld has installed the routes, since we can read something like
change route 192.168.2.1/32-873cc90 prefix
Hi,
We wrote a conference paper on source-sensitive routing, which you will found
there:
http://hal-univ-diderot.archives-ouvertes.fr/hal-00947234
http://fr.arxiv.org/abs/1403.0445
Matthieu
___
Babel-users mailing list
Dear all,
The quagga version of babeld is now up-to-date with 1.5.0. You can configure it
with similar commands. Just remark that as the configuration file is read as a
succession of commands (order is important), having babel max-rtt-penalty != 0
does NOT imply babel enable-timestamps.
Le 27 juin 2014 à 20:39, Juliusz Chroboczek a écrit :
the two captures are at: http://snapon.lab.bufferbloat.net/~cero2/babcap/
There's nothing obviously wrong. Here's an example of a source-specific
TLV (the one at time 06:20.362230 in the wifi capture):
0d 16 02 20 00 00 06 40 65 8a
what about putting the latest version in the public git?
Done. (forced update)
Matthieu
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
Ah, there's an SS-aware version of tcpdump? Cool. Where do I get a copy?
On *your* web page !
http://git.wifi.pps.univ-paris-diderot.fr/?p=tcpdump-babels.git;a=summary
Matthieu
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
Dear all,
Here is the source-sensitive packet's format I used in my implementation.
Before the code be merged in babeld, it may be interesting to have comments.
(By the way, note the latest version of babels is on the highly subject to
rebasing ss-tables branch of my public repositories.
If the Flags field contains any flags, then the resulting parser state
will be different for original and source-specific implementations. This
will break interoperability.
Yes, there is a problem with the compression mechanism for the destination
prefix. The solutions are:
- no
Dear all,
A new *incompatible* version of Babels is available. It is incompatible because
we have changed the Source Specific Update TLV's format.
The source-sensitive branch of my public repositories has been forced-updated.
All branches are rebased on the 1.5.1 version. Please update all
Matthieu, I cannot find the Source Omitted field any longer. Did you
remove it?
Yes, it's not a mistake. The Idea is that you will sort your TLVs by
lexicographic (dst, src) in a Babel packet.
Usually, the source prefix will not begin the same than the destination
prefix cached:
-
Suppose my network has prefixes 2001:bad:c0ff:ee::/64 and 2001:0dd:f00d:1/64.
Then I'll see:
1. 64 routes towards both prefixes, typically /128;
2. default routes from both /64.
If I place the source-specific after the right /128, I can compress the
source prefix.
so you earn 14 bytes
I have a feeling that the code has not settled down enough for
anyones' taste,
Matthieu will probably tell you more, but I'm under the impression that
his current tree is stable. I've done some work reviewing his code, but
I'm a little too busy writing stuff up.
I haven't any complains,
Hi,
we are investigating some strange behaviour with native source specific
routes (i.e. not with multiple routing tables): it seems cached routes may make
things go wrong. Here are the details.
I have two default routes:
default from 2001:41d0:1:f100::/56 via fe80::4e72:b9ff:fe43:7608
this basically logjammed on this issue. Either procd needed to be modified to
be able to
send an arbitrary signal, or babel changed to take sighup as a reload.
Or using an indirection: script for procd systems which launch Babel and
capture sighups… :p
(well, at least it keeps Babel safe!)
Hi Denis,
a recent build of tcpdump can decode everything you mention except the
source-specific bits
Attached is a patch for the source-specific decoder.
Matthieu
0001-Babel-add-decoder-for-source-specific-extension.patch
Description: Binary data
Is there anywhere a good reference to netlink?
iproute2, libnl, kernel sources ?
If I understand it correctly you just need to set the routes with
NLM_F_CREATE | NLM_F_REPLACE to get the atomic replacement.
-DEFINES = $(PLATFORM_DEFINES) -DVERSION=\$(VERSION)\
+DEFINES =
Phh... this is a good question... I would guess YES, otherwise the
whole source-specific routing would not work.
Ok course, I was confused.
-const int has_atomic_replacement = has_ipv6_subtrees; /* Dave says that
if a
+const int has_atomic_replacement = has_ipv6_subtrees
I think the unique key for the route is destination, routing table
and metric. The metric part is important, if you put the routing
protocol path cost into the route, atomic replacement will not work.
Interesting (so the previous patch is wrong). Did you know about the
source part? (RTA_SRC)
If you work with atomic route replacement even putting ALL of them
into a netlink message (or as many as you can fit in) works.
What I understand is that we can't (in general) work with atomic
*next-hop* replacement (interface index and metric may change).
I proposed a workaround where instead
Hi!
root@GW:~# ip route
192.168.3.0/24 http://192.168.3.0/24 dev eth0.1 proto kernel scope link
src 192.168.3.1
192.168.3.135 via 192.168.3.135 dev eth0.1 proto babel onlink
192.168.4.0/24 http://192.168.4.0/24 via 192.168.3.135 dev eth0.1 proto
babel onlink
192.168.4.1 via
The default route into its own table is used for more complex setups
where you have different kinds of internet uplinks (e.g. the normal
one for your traffic, a VPN for mesh traffic)
We solved that particular problem in our network with source-specific
routing.
or where you don't want
to
- We keep the "export-table" option for compatibility reasons.
- It overrides the selection of source-specific tables. Not sure if it
is the right thing to do.
Thanks to Jernej Kos for its review.
---
babeld.man | 6 ++
configuration.c | 29
> I just started working on a patch that adds export filters and the
> "table" action as Juliusz suggested.
Arf, sorry, I was also doing one (attached).
Matthieu
0001-Add-filter-to-choose-the-export-routing-table.patch
Description: Binary data
___
---
babeld.man | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/babeld.man b/babeld.man
index 6a082f2..1991811 100644
--- a/babeld.man
+++ b/babeld.man
@@ -115,7 +115,7 @@ Use the given kernel routing table for routes inserted by
.BR babeld .
.TP
.BI \-T " table"
-Export
> Oh, nice! :-) BTW, why is the routing table index a char? Based on
> ip-route man page, the routing table indices are not limited to 255, but
> go up to 2^31. I know that in practice one wouldn't have so many routing
> tables, but anyway.
Good point!
(the "reason" is that I copied the line
0001-Fix-BSD-compilation.patch
Description: Binary data
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
> Matthieu, do you understand why that is? Is there a way to optimise away
> conflict_solution in the easy case?
I think so. Will fix it. I may call you before.
Matthieu
___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
>> Matthieu, do you understand why that is? Is there a way to optimise away
>> conflict_solution in the easy case?
>
> I think so. Will fix it.
The attached patch should solve the problem. As a conflict need a specific
route, the first now loop iterates on specific routes only. If there is
> #ifdef DEBUG, or if(debug_level >= 2) ?
Well, I was not sure about this one. The problem with debug_level is that it
produces too verbose output, it's not just "checks". I was rather thinking
about having a test-mode version of babeld, which let the clean babeld-code
as-is, and add some
> It did not fix the 3.10 kernel based c1.
>
> So autodetection is broken on the c2 & c1 kernels
"Autodetection" is just based on the kernel version (via uname). So it's
normal it doesn't change anything on c1 (3.10 < 3.11). And it's normal too
that you need to use it on c2 (3.14 > 3.11, but
> Why don't you write to the netdev list to ask what's a reliable way to
> detect IPv6_SUBTREES?
Yes, I'm asking myself if the Dave's "invalid argument" are for source-specific
routes. In which case it answers the question. Will test it.
Matthieu
> I put a babel debug 3 log up at:
>
> http://www.taht.net/~d/babeld_pi3.log
Strange, there is no more "kernel_route(ADD): invalid argument" lines. Is it
really the same node, with the same options ?
So you should have all the right routes in the FIB, no ?
Matthieu
PS: sorry for your flash
> add rule: Function not implemented
> and kernel_route(ADD): Function not implemented
That's true. Did you know if there is any support for source-specific routing?
I read before that FreeBSD supports multiple tables... but also that the
number of these tables must be set at compilation
---
interface.h | 2 +-
kernel.h | 2 +-
kernel_netlink.c | 7 +++--
kernel_socket.c | 2 +-
message.c| 92
route.c | 19 ++--
rule.c | 2 +-
util.h | 6
8 files changed,
Default source prefixes were encoded with src_plen == 0, even in v4. This
leads to some bugs (comparison between prefixes), and may be confusing for
long term maintenance. Now, the condition to know if a route is source-
specific is handled by the new is_default() function, applied to the source
> Do you think this is serious enough to justify releasing 1.7.2?
No, it only adds additional v6 rules: associated tables remains empty.
> Matthieu, could you please tell me when the bug was introduced, so I can
> put it in the changelog?
... so, it's quite unclear. The symptoms appear between
> #3 0x76e4bb80 in malloc_printerr (action=1,
>str=0x76efba6c "double free or corruption (fasttop)", ptr=)
>at malloc.c:4996
> #5 0x0001a35c in update_route (id=, prefix=,
>plen=, src_prefix=, src_plen=0 '\000',
>seqno=17136, refmetric=96, interval=1600, neigh=0xc5d9d8,
>
> I guess I'm confused.
You should not… it's just a bug. Patch attached. Thank's for the report.
Explanations in the patch.
Matthieu
0001-Fix-bug-allowing-the-comparison-of-v4-and-v6-prefixe.patch
Description: Binary data
___
Babel-users mailing
Hi Lorenzo,
> Is this the right place where to ask?
Yes.
> how to get the routing table entry matching a given prefix...
You must iterate over all the routing entries with "route streams" and search
the one you want (or write your own function). For example:
struct babel_route *rt =
Hi,
> Something else?
> ***
>
> Other ideas?
Perhaps. Let the new Hello be:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4|Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
And define 2 new sub-TLVs:
1.
Hello,
I've got around 40 patches to be merged in my dev branch.
I've implemented the Chouasne algorithm in my c-alg branch.
I've implemented another an extension in my path-feasible branch.
This extension is briefly documented in the ext-path.txt file. It
introduces a flexible mechanism to
> I still do find (1) wasteful.
I really would like to feel your intuition. From my point of view:
- either you'll have very few some-specific routes, in which case the
waste is negligible (isn't it the case of multihomed networks ?),
- or you'll have so much some-specific routes that
Hello,
Here is my code for source-specific extension of Babel using sub-TLV.
https://github.com/boutier/babeld/tree/dev
* Packet format
The sub-TLV format is [ type | length | src-plen | src-prefix]. For now,
I use the value 250 for the sub-tlv source prefix.
* Source-specific wildcard
> Does this mean whatever we decide for wildcard requests applies to
> wildcard updates as well?
That seems logical, but that's not what I propose.
When a node requests a full dump, it requests only the routes it
understand, not really a full dump. Sending a full dump may include
unsolicited
Hi,
A first step could be to remove the "-g" from CFLAGS. Default is "-Os -g".
On my desktop computer (debian 64bits, gcc), commit 9be552feda7f:
$ make clean > /dev/null; make CFLAGS="-Os -g" > /dev/null; du -h babeld
460Kbabeld
$ make clean > /dev/null; make CFLAGS="-Os" > /dev/null; du
59 matches
Mail list logo