| Age | Commit message (Collapse) | Author |
|---|
|
Here is a patch fixing a bug that causes breakage of a local routing
table during shutdown of Bird. The problem was caused by shutdown
of 'device' protocol before shutdown of 'kernel' protocol. When
'device' protocol went down, the route (with local network prefix)
From different protocol (BGP or OSPF) became preferred and installed
to the kernel routing table. Such routes were broken (like
192.168.1.0/24 via 192.168.1.2). I think it is also the cause
of problem reported by Martin Kraus.
The patch disables updating of kernel routing table during shutdown of
Bird. I am not sure whether this is the best way to fix it, I would
prefer to forbid 'kernel' protocol to overwrite routes with
'proto kernel'.
The patch also fixes a problem that during shutdown sometimes routes
created by Bird remained in the kernel routing table.
|
|
|
|
|
|
|
|
correctly disposed of.
|
|
|
|
|
|
|
|
|
|
Except for Filters, RIP and OSPF, the progdocs are complete.
|
|
they cease to exist in our routing tables due to protocols having shut down.
|
|
|
|
Set preferences correctly.
|
|
Please try compiling your code with --enable-warnings to see them. (The
unused parameter warnings are usually bogus, the unused variable ones
are very useful, but gcc is unable to control them separately.)
|
|
turned on, but after some testing I'll gag it.
|
|
they can be made configurable if it turns out to be useful.
|
|
It seems everything still works (except for disable/enable/restart which hangs
sometimes, but it's another story).
|
|
depend on the startup counter hack now and uses a zero-time timer instead
to make itself scheduled after normal protocol startup.
|
|
used for automatic generation of instance names.
protocol->name is the official name
protocol->template is the name template (usually "name%d"),
should be all lowercase.
Updated all protocols to define the templates, checked that their configuration
grammar includes proto_name which generates the name and interns it in the
symbol table.
|
|
|
|
and problems to solve, but the hardest part works.
|
|
export host and link scope routes.
|
|
The changes are just too extensive for lazy me to list them
there, but see the comment at the top of sysdep/unix/krt.c.
The code got a bit more ifdeffy than I'd like, though.
Also fixed a bunch of FIXME's and added a couple of others. :)
|
|
temporary attribute list.
|
|
Make all protocols pass routing table to rte_update and rte_discard.
|
|
|
|
o Now compatible with filtering.
o Learning of kernel routes supported only on CONFIG_SELF_CONSCIOUS
systems (on the others it's impossible to get it semantically correct).
o Learning now stores all of its routes in a separate fib and selects
the ones the kernel really uses for forwarding packets.
o Better treatment of CONFIG_AUTO_ROUTES ports.
o Lots of internal changes.
|
|
|
|
o Nothing is configured automatically. You _need_ to specify
the kernel syncer in config file in order to get it started.
o Syncing has been split to route syncer (protocol "Kernel") and
interface syncer (protocol "Device"), device routes are generated
by protocol "Direct" (now can exist in multiple instances, so that
it will be possible to feed different device routes to different
routing tables once multiple tables get supported).
See doc/bird.conf.example for a living example of these shiny features.
|
|
to the krt_capable mechanism as well.
|
|
(via Netlink). Tweaked kernel synchronization rules a bit. Discovered
locking bug in kernel Netlink :-)
Future plans: Hunt all the bugs and solve all the FIXME's.
|
|
|
|
The new kernel syncer is cleanly split between generic UNIX module
and OS dependent submodules:
- krt.c (the generic part)
- krt-iface (low-level functions for interface handling)
- krt-scan (low-level functions for routing table scanning)
- krt-set (low-level functions for setting of kernel routes)
krt-set and krt-iface are common for all BSD-like Unices, krt-scan is heavily
system dependent (most Unices require /dev/kmem parsing, Linux uses /proc),
Netlink substitues all three modules.
We expect each UNIX port supports kernel routing table scanning, kernel
interface table scanning, kernel route manipulation and possibly also
asynchronous event notifications (new route, interface state change;
not implemented yet) and build the KRT protocol on the top of these
primitive operations.
|
