From: Dave Taht <dave.taht@gmail.com>
To: cerowrt-devel@lists.bufferbloat.net
Subject: [Cerowrt-devel] Fwd: [Babel-users] ANNOUNCE: source-specific routing in Babel
Date: Thu, 27 Jun 2013 14:05:09 -0700 [thread overview]
Message-ID: <CAA93jw4uXHBkq=SMiJO70kSDB2K0_Zh3t5d8pyoLyJnOp3zWEg@mail.gmail.com> (raw)
In-Reply-To: <7ibo6rtjoo.wl%jch@pps.univ-paris-diderot.fr>
yea!
---------- Forwarded message ----------
From: Matthieu Boutier <boutier@pps.univ-paris-diderot.fr>
Date: Thu, Jun 27, 2013 at 12:52 PM
Subject: [Babel-users] ANNOUNCE: source-specific routing in Babel
To: babel-users@lists.alioth.debian.org
Cc: Markus Stenberg <markus.stenberg@iki.fi>, fred@cisco.com
Dear all,
We are pleased to announce a first implementation of Babel-S,
a variant of Babel able to distribute source-specific routes. The
code is available using
git clone -b source-specific
git://git.wifi.pps.univ-paris-diderot.fr/babels.git
with a web inteface on
http://git.wifi.pps.univ-paris-diderot.fr/?p=babels.git
and a backup on
https://github.com/boutier/babeld
Motivation
==========
Consider the case of a multihomed network (a network connected to two
ISPs). If the network is using provider-specific addresses, a packet
needs to be routed to the right ISP depending on its *source* address.
This is in contrast to traditional routing, which only considers the
*destination* when making a routing decision.
ISP A ISP B
\ /
packets \ / packets
sourced \ / sourced
from A \ / from B
end node
Markus Stenberg has recently published a prototype of source-specific
routing for OSPF[1]. Babel-S is our attempt at a production-quality
implementation of source-specific routing within the Babel routing
protocol[2].
Implementation details
======================
In the presence of source-specific routing, a route is identified by
a pair (D, S) where D is a destination prefix and S is a sourcer
prefix. In the general case, there is a possibile ambiguity between
two routes.
For example, in our experimental network there is a default
source-specific route
(0.0.0.0/0, 192.168.4.0/24)
^ ^
| |
dest source
and a non-source-specific route
(192.168.4.42/32, 0.0.0.0/0)
A packet that is both sourced from 192.168.4.0/24 and destined to
192.168.4.42 is ambiguous. As was explained to us by Fred Baker, in
this case the destination should "win" -- the packet should follow the
non-source-specific route.
Unfortunately, the one Linux kernel API that works is the "rule"
system, which doesn't implement this semantics naturally. For this
reason, we are inserting extra "disambiguation" routes for the
intersection
(192.168.4.42/32, 192.168.4.0/24)
The exact algorithm is somewhat involved, and will be described at
some later point. Enjoy the code in route.c in case you're interested.
Limitations
===========
- There are some limitations wrt. routes found in the kernel that were
not installed by babeld.
- Requests for source-specific routes are broken (we're working on
it); this could cause starvation in some very unlikely cases.
- The number of kernel tables used by the daemon cannot be configured yet.
Usage
=====
Without any special configuration, Babel-S reannounces source-specific
routes received from other Babel peers and installs them in the
kernel. In order to introduce source-specific routes in the network,
some routers should redistribute their routes as source-specific.
This is done via the "source-prefix" configuration option.
For example, to redistribute his routes with the source
192.168.4.0/24, a router will be configured with:
source-prefix 192.168.4.0/24
By default, Babel-S will use the routing tables 10 to 19 and the
rules' priorities 100 to 109. You can see kernel rules and tables
using the ip command:
ip rule show
ip route show table 10
Babel-S defines in total 5 new configuration 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 Boutier and Juliusz Chroboczek
[1] https://github.com/fingon/hnet-core
[2] http://www.pps.univ-paris-diderot.fr/~jch/software/babel/
_______________________________________________
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
parent reply other threads:[~2013-06-27 21:05 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <7ibo6rtjoo.wl%jch@pps.univ-paris-diderot.fr>]
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
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA93jw4uXHBkq=SMiJO70kSDB2K0_Zh3t5d8pyoLyJnOp3zWEg@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
/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