mirrors/bird
mirrors/bird
0
0
Fork 0
mirror of https://gitlab.nic.cz/labs/bird.git synced 2024-11-18 00:58:42 +00:00
Code Releases Activity
fe662dfd78
bird/sysdep/unix/krt.h

107 lines
2.6 KiB
C
Raw Normal View History

Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 12:50:43 +00:00
/*
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
* BIRD -- UNIX Kernel Route Syncer
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 12:50:43 +00:00
*
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
* (c) 1998--1999 Martin Mares <mj@ucw.cz>
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 12:50:43 +00:00
*
* Can be freely distributed and used under the terms of the GNU GPL.
*/
#ifndef _BIRD_KRT_H_
#define _BIRD_KRT_H_
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
struct krt_config;
struct krt_proto;
Moved to a much more systematic way of configuring kernel protocols. 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.
1999-03-26 21:44:38 +00:00
struct kif_config;
struct kif_proto;
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 12:50:43 +00:00
#include "lib/krt-scan.h"
#include "lib/krt-set.h"
Hopefully finished kernel syncer (krt) rewrite: o Interface syncing is now a part of krt and it can have configurable parameters. Actually, the only one is scan rate now :) o Kernel routing table syncing is now synchronized with interface syncing (we need the most recent version of the interface list to prevent lots of routes to non-existent destinations from appearing). Instead of its own timer, we just check if it's route scan time after each iface list scan. o Syncing of device routes implemented. o CONFIG_AUTO_ROUTES should control syncing of automatic device routes. o Rewrote krt_remove_route() to really remove routes :) o Better diagnostics. o Fixed a couple of bugs.
1998-12-08 18:37:58 +00:00
#include "lib/krt-iface.h"
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 12:50:43 +00:00
KRF_* flags moved to krt.h as they are internal to kernel syncer, fib->pad0,pad1 renamed to x0,x1 and in case of struct net x0 is reserved for kernel syncing as well.
1998-12-07 10:15:42 +00:00
/* Flags stored in net->n.flags */
Rewritten kernel syncer. Now uses the rta trickery I've introduced yesterday and does things "the right way". Few things are still missing (device routes etc.), I'll add them later in the evening.
1998-12-08 16:20:13 +00:00
#define KRF_CREATE 0 /* Not seen in kernel table */
KRF_* flags moved to krt.h as they are internal to kernel syncer, fib->pad0,pad1 renamed to x0,x1 and in case of struct net x0 is reserved for kernel syncing as well.
1998-12-07 10:15:42 +00:00
#define KRF_SEEN 1 /* Seen in kernel table during last scan */
#define KRF_UPDATE 2 /* Need to update this entry */
Rewritten kernel syncer. Now uses the rta trickery I've introduced yesterday and does things "the right way". Few things are still missing (device routes etc.), I'll add them later in the evening.
1998-12-08 16:20:13 +00:00
#define KRF_DELETE 3 /* Should be deleted */
#define KRF_LEARN 4 /* We should learn this route */
KRF_* flags moved to krt.h as they are internal to kernel syncer, fib->pad0,pad1 renamed to x0,x1 and in case of struct net x0 is reserved for kernel syncing as well.
1998-12-07 10:15:42 +00:00
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
/* krt.c */
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 12:50:43 +00:00
extern struct protocol proto_unix_kernel;
Synced kernel interface to new interface.
1999-02-05 21:38:50 +00:00
struct krt_config {
struct proto_config c;
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
struct krt_set_params set;
struct krt_scan_params scan;
struct krt_if_params iface;
int persist; /* Keep routes when we exit */
Moved to a much more systematic way of configuring kernel protocols. 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.
1999-03-26 21:44:38 +00:00
int scan_time; /* How often we re-scan routes */
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
int learn; /* Learn routes from other sources */
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 12:50:43 +00:00
};
Synced kernel interface to new interface.
1999-02-05 21:38:50 +00:00
struct krt_proto {
struct proto p;
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
struct krt_set_status set;
struct krt_scan_status scan;
struct krt_if_status iface;
Synced kernel interface to new interface.
1999-02-05 21:38:50 +00:00
};
extern struct proto_config *cf_krt;
Kernel syncer is now configurable. It will probably need some more options, but at least basic tuning is possible now.
1998-12-06 17:40:42 +00:00
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
#define KRT_CF ((struct krt_config *)p->p.cf)
void krt_got_route(struct krt_proto *p, struct rte *e);
KRT: Implemented asynchronous route / interface state notifications (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.
1999-03-04 18:36:18 +00:00
void krt_got_route_async(struct krt_proto *p, struct rte *e, int new);
/* Values for rte->u.krt_sync.src */
#define KRT_SRC_UNKNOWN -1 /* Nobody knows */
#define KRT_SRC_BIRD 0 /* Our route (not passed in async mode) */
#define KRT_SRC_REDIRECT 1 /* Redirect route, delete it */
#define KRT_SRC_ALIEN 2 /* Route installed by someone else */
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
Moved to a much more systematic way of configuring kernel protocols. 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.
1999-03-26 21:44:38 +00:00
extern struct protocol proto_unix_iface;
struct kif_config {
struct proto_config c;
struct krt_if_params iface;
int scan_time; /* How often we re-scan interfaces */
};
struct kif_proto {
struct proto p;
struct krt_if_status iface;
};
extern struct proto_config *cf_kif;
#define KIF_CF ((struct kif_config *)p->p.cf)
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 12:50:43 +00:00
/* krt-scan.c */
Synced kernel interface to new interface.
1999-02-05 21:38:50 +00:00
void krt_scan_preconfig(struct krt_config *);
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 12:50:43 +00:00
void krt_scan_start(struct krt_proto *);
void krt_scan_shutdown(struct krt_proto *);
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
void krt_scan_fire(struct krt_proto *);
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 12:50:43 +00:00
/* krt-set.c */
Synced kernel interface to new interface.
1999-02-05 21:38:50 +00:00
void krt_set_preconfig(struct krt_config *);
void krt_set_start(struct krt_proto *);
When shutting down, remove all routes (except for RTS_INHERIT and RTS_DEVICE routes) from kernel routing tables unless the "persist" switch is set.
1999-02-13 20:46:03 +00:00
void krt_set_shutdown(struct krt_proto *);
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 12:50:43 +00:00
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
int krt_capable(rte *e);
void krt_set_notify(struct proto *x, net *net, rte *new, rte *old);
Use traditional Unix route/iface interface only when CONFIG_NETLINK is not defined. Also moved declarations of Unix iface logic to krt.h.
1999-03-01 19:05:58 +00:00
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
/* krt-iface.c */
Use traditional Unix route/iface interface only when CONFIG_NETLINK is not defined. Also moved declarations of Unix iface logic to krt.h.
1999-03-01 19:05:58 +00:00
Moved to a much more systematic way of configuring kernel protocols. 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.
1999-03-26 21:44:38 +00:00
void krt_if_preconfig(struct kif_config *);
void krt_if_start(struct kif_proto *);
void krt_if_shutdown(struct kif_proto *);
Hopefully finished kernel syncer (krt) rewrite: o Interface syncing is now a part of krt and it can have configurable parameters. Actually, the only one is scan rate now :) o Kernel routing table syncing is now synchronized with interface syncing (we need the most recent version of the interface list to prevent lots of routes to non-existent destinations from appearing). Instead of its own timer, we just check if it's route scan time after each iface list scan. o Syncing of device routes implemented. o CONFIG_AUTO_ROUTES should control syncing of automatic device routes. o Rewrote krt_remove_route() to really remove routes :) o Better diagnostics. o Fixed a couple of bugs.
1998-12-08 18:37:58 +00:00
Moved to a much more systematic way of configuring kernel protocols. 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.
1999-03-26 21:44:38 +00:00
void krt_if_scan(struct kif_proto *);
void krt_if_io_init(void);
Rewrote the kernel syncer. The old layering was horrible. 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.
1999-03-03 19:49:56 +00:00
Since almost every UNIX system requires different techniques for reading the kernel routing table as opposed to modifying it which is approximately the same on non-netlink systems, I've split the kernel routing table routines to read and write parts. To be implemented later ;-)
1998-10-18 12:50:43 +00:00
#endif
Copy Permalink