Hi Christof,
> If I am building a network now that utilises source-specific routing, how can
> I best prepare for a migration path?
> Can both versions be run simultaneously? Should I stop building this network
> now and instead switch to some experimental branch that already contains the
>
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
Hi David,
> It's already there
I was speaking about rtgwg-enterprise-pa-multihoming. ;-)
Thanks by the way for your explanations in your two previous
mails. I think this really helps us understand each other.
Cheers,
Matthieu
___
rtgwg mailing list
> Actually, I don't. I can produce cases in which source first gives the wrong
> route, and in which destination first gives the wrong route.
Interesting! (but I'm lost with the example below)
> The only way I see to make doing either one first *always* gives the right
> result is if a small
Thank's Chris, it makes things much more clear.
> With […], I think we are in agreement that the forwarding behavior described
> in rtgwg-enterprise-pa-multihoming Is identical to that described in
> rtgwg-dst-src-routing.
I think so. :-)
> Assuming that the forwarding behaviors are identical,
> I believe the tables could be similarly collapsed giving source address
> higher precedence than destination address. Do you disagree?
mmm, it seems I failed to explain something since that's not the point…
Did you agree that:
1. destination first give the correct behaviour as-is.
2.
Hi,
David, you're right, and as you remark, the draft says:
2.5: « It is also useful to note that the prefixes assigned to the site by
different ISPs will not overlap. »
This hypothesis breaks your example. But, as you, I think that we should
not rely on such hypothesis: it seems
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
> 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
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
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.
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 =
> 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
> #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,
>
> 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
> 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
> 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
> 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
>> 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
> 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
- 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
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
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
Hi Dino,
I want to make one comment about Babel, or more to the point the DUAL
algorithm. I, with one other engineer were the original designers of EIGRP in
the early 90s. We worked with Jose Garcia-Luna from SRI/UCSC on implementing
the DUAL algorithm in EIGRP.
Just be careful about
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
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
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
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)
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!)
Hello,
We made a multipath version of Mosh[1], taking benefit of source-specific
routing. It is built at the application layer over UDP. The following paper
relates our experience:
http://arxiv.org/abs/1502.02402
The source code is available on:
https://github.com/boutier/mosh
Hi,
We wrote a paper about our multipath version of Mosh, that you can find at:
http://arxiv.org/abs/1502.02402
Recall the implementation repository:
https://github.com/boutier/mosh
Best regards,
Matthieu
___
mosh-devel mailing list
You might also need to combine the features of the gateway with the
metric(s) of the path to the gateway.
Its not really useful to select a faster gateway if the path towards
the gateway goes over a slow wifi link.
I do end-to-end measurements in my mosh implementation, so we should
not
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
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,
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
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
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,
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.
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,
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.
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
69 matches
Mail list logo