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.
|
|
It was giving wrong results on /30 networks.
|
|
|
|
|
|
RTPROT_BOOT instead.
Work around that.
|
|
|
|
|
|
|
|
Please note that the only calls which don't add newlines automatically
(i.e., don't print a full line of output) are debug() and DBG().
|
|
Also, provide proper address scopes in struct ifa.
|
|
|
|
Don't moan when netlink reports lost packets.
|
|
|
|
The long resource/routing table dump printed upon startup is gone now
and if you wish to see it, just send bird SIGUSR1 or use the `debug'
commands.
|
|
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.)
|
|
and other non-portable functions on all systems.
|
|
turned on, but after some testing I'll gag it.
|
|
|
|
address, not per interface (hence it's ifa->flags & IA_UNNUMBERED) and
should be set reliably. IF_MULTIACCESS should be fixed now, but it isn't
wise to rely on it on interfaces configured with /30 prefix.
|
|
I'll find a better solution soon.
|
|
|
|
|
|
|
|
|
|
but the core routines are there and seem to be working.
o lib/ipv6.[ch] written
o Lexical analyser recognizes IPv6 addresses and when in IPv6
mode, treats pure IPv4 addresses as router IDs.
o Router ID must be configured manually on IPv6 systems.
o Added SCOPE_ORGANIZATION for org-scoped IPv6 multicasts.
o Fixed few places where ipa_(hton|ntoh) was called as a function
returning converted address.
|
|
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. :)
|
|
Make all protocols pass routing table to rte_update and rte_discard.
|
|
|
|
addresses per interface (needed for example for IPv6 support).
Visible changes:
o struct iface now contains a list of all interface addresses (represented
by struct ifa), iface->addr points to the primary address (if any).
o Interface has IF_UP set iff it's up and it has a primary address.
o IF_UP is now independent on IF_IGNORED (i.e., you need to test IF_IGNORED
in the protocols; I've added this, but please check).
o The if_notify_change hook has been simplified (only one interface pointer
etc.).
o Introduced a ifa_notify_change hook. (For now, only the Direct protocol
does use it -- it's wise to just listen to device routes in all other
protocols.)
o Removed IF_CHANGE_FLAGS notifier flag (it was meaningless anyway).
o Updated all the code except netlink (I'll look at it tomorrow) to match
the new semantics (please look at your code to ensure I did it right).
Things to fix:
o Netlink.
o Make krt-iface interpret "eth0:1"-type aliases as secondary addresses.
|
|
|
|
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.
|
|
and vice versa now.
|
|
documented the remaining ones (sysdep/cf/README).
Available configurations:
o linux-20: Old Linux interface via /proc/net/route (selected by default
on pre-2.1 kernels).
o linux-21: Old Linux interface, but device routes handled by the
kernel (selected by default for 2.1 and newer kernels).
o linux-22: Linux with Netlink (I play with it a lot yet, so it isn't
a default).
o linux-ipv6: Prototype config for IPv6 on Linux. Not functional yet.
|
|
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.
|
|
us a real protocol number in 2.2.4 kernel.
|
|
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.
|
|
To build BIRD with Netlink support, just configure it with
./configure --with-sysconfig=linux-21
After it will be tested well enough, I'll probably make it a default
for 2.2 kernels (and rename it to linux-22 :)).
|
|
|
|
|
|
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.
|