bird/nest/proto-hooks.c

317 lines
9.9 KiB
C
Raw Normal View History

2000-06-03 01:24:11 +08:00
/*
* BIRD -- Documentation for Protocol Hooks (dummy source file)
*
* (c) 2000 Martin Mares <mj@ucw.cz>
*
* Can be freely distributed and used under the terms of the GNU GPL.
*/
/**
* DOC: Protocol hooks
*
2000-06-07 21:25:53 +08:00
* Each protocol can provide a rich set of hook functions referred to by pointers
2000-06-03 01:24:11 +08:00
* in either the &proto or &protocol structure. They are called by the core whenever
* it wants the protocol to perform some action or to notify the protocol about
* any change of its environment. All of the hooks can be set to %NULL which means
* to ignore the change or to take a default action.
*/
/**
* preconfig - protocol preconfiguration
* @p: a routing protocol
* @c: new configuration
*
* The preconfig() hook is called before parsing of a new configuration.
*/
void preconfig(struct protocol *p, struct config *c)
{ DUMMY; }
/**
* postconfig - instance post-configuration
* @c: instance configuration
*
* The postconfig() hook is called for each configured instance after
* parsing of the new configuration is finished.
*/
void postconfig(struct proto_config *c)
{ DUMMY; }
/**
* init - initialize an instance
* @c: instance configuration
*
* The init() hook is called by the core to create a protocol instance
* according to supplied protocol configuration.
*
* Result: a pointer to the instance created
*/
struct proto *init(struct proto_config *c)
{ DUMMY; }
/**
* reconfigure - request instance reconfiguration
* @p: an instance
* @c: new configuration
*
* The core calls the reconfigure() hook whenever it wants to ask the
* protocol for switching to a new configuration. If the reconfiguration
* is possible, the hook returns 1. Otherwise, it returns 0 and the core
* will shut down the instance and start a new one with the new configuration.
*
* After the protocol confirms reconfiguration, it must no longer keep any
* references to the old configuration since the memory it's stored in can
* be re-used at any time.
*/
int reconfigure(struct proto *p, struct proto_config *c)
{ DUMMY; }
/**
* dump - dump protocol state
* @p: an instance
*
* This hook dumps the complete state of the instance to the
* debug output.
*/
void dump(struct proto *p)
{ DUMMY; }
/**
* start - request instance startup
* @p: protocol instance
*
* The start() hook is called by the core when it wishes to start
* the instance. Multitable protocols should lock their tables here.
2000-06-03 01:24:11 +08:00
*
* Result: new protocol state
*/
int start(struct proto *p)
{ DUMMY; }
/**
* shutdown - request instance shutdown
* @p: protocol instance
*
* The stop() hook is called by the core when it wishes to shut
* the instance down for some reason.
*
* Returns: new protocol state
*/
int shutdown(struct proto *p)
{ DUMMY; }
/**
* cleanup - request instance cleanup
* @p: protocol instance
*
* The cleanup() hook is called by the core when the protocol became
* hungry/down, i.e. all protocol ahooks and routes are flushed.
* Multitable protocols should unlock their tables here.
*/
void cleanup(struct proto *p)
{ DUMMY; }
2000-06-03 01:24:11 +08:00
/**
* get_status - get instance status
* @p: protocol instance
* @buf: buffer to be filled with the status string
*
* This hook is called by the core if it wishes to obtain an brief one-line user friendly
* representation of the status of the instance to be printed by the <cf/show protocols/
* command.
*/
void get_status(struct proto *p, byte *buf)
{ DUMMY; }
/**
* get_route_info - get route information
* @e: a route entry
* @buf: buffer to be filled with the resulting string
* @attrs: extended attributes of the route
*
* This hook is called to fill the buffer @buf with a brief user friendly
* representation of metrics of a route belonging to this protocol.
*/
void get_route_info(rte *e, byte *buf, ea_list *attrs)
{ DUMMY; }
/**
* get_attr - get attribute information
* @a: an extended attribute
* @buf: buffer to be filled with attribute information
* @buflen: a length of the @buf parameter
2000-06-03 01:24:11 +08:00
*
* The get_attr() hook is called by the core to obtain a user friendly
* representation of an extended route attribute. It can either leave
* the whole conversion to the core (by returning %GA_UNKNOWN), fill
* in only attribute name (and let the core format the attribute value
* automatically according to the type field; by returning %GA_NAME)
* or doing the whole conversion (used in case the value requires extra
* care; return %GA_FULL).
*/
int get_attr(eattr *a, byte *buf, int buflen)
2000-06-03 01:24:11 +08:00
{ DUMMY; }
/**
* if_notify - notify instance about interface changes
* @p: protocol instance
* @flags: interface change flags
* @i: the interface in question
*
* This hook is called whenever any network interface changes its status.
* The change is described by a combination of status bits (%IF_CHANGE_xxx)
* in the @flags parameter.
*/
void if_notify(struct proto *p, unsigned flags, struct iface *i)
{ DUMMY; }
/**
* ifa_notify - notify instance about interface address changes
* @p: protocol instance
* @flags: address change flags
* @a: the interface address
*
* This hook is called to notify the protocol instance about an interface
* acquiring or losing one of its addresses. The change is described by
* a combination of status bits (%IF_CHANGE_xxx) in the @flags parameter.
*/
void ifa_notify(struct proto *p, unsigned flags, struct ifa *a)
{ DUMMY; }
/**
* rt_notify - notify instance about routing table change
* @p: protocol instance
* @channel: notifying channel
2000-06-03 01:24:11 +08:00
* @net: a network entry
2009-06-01 20:07:13 +08:00
* @new: new route for the network
* @old: old route for the network
2000-06-03 01:24:11 +08:00
* @attrs: extended attributes associated with the @new entry
*
* The rt_notify() hook is called to inform the protocol instance about
* changes in the connected routing table @table, that is a route @old
2000-06-03 01:24:11 +08:00
* belonging to network @net being replaced by a new route @new with
* extended attributes @attrs. Either @new or @old or both can be %NULL
* if the corresponding route doesn't exist.
*
2009-06-01 20:07:13 +08:00
* If the type of route announcement is RA_OPTIMAL, it is an
* announcement of optimal route change, @new stores the new optimal
* route and @old stores the old optimal route.
*
* If the type of route announcement is RA_ANY, it is an announcement
* of any route change, @new stores the new route and @old stores the
* old route from the same protocol.
*
* @p->accept_ra_types specifies which kind of route announcements
* protocol wants to receive.
2000-06-03 01:24:11 +08:00
*/
void rt_notify(struct proto *p, net *net, rte *new, rte *old, ea_list *attrs)
{ DUMMY; }
/**
* neigh_notify - notify instance about neighbor status change
* @neigh: a neighbor cache entry
*
* The neigh_notify() hook is called by the neighbor cache whenever
* a neighbor changes its state, that is it gets disconnected or a
* sticky neighbor gets connected.
*/
void neigh_notify(neighbor *neigh)
{ DUMMY; }
/**
Terminology cleanup: The import_control hook is now called preexport. Once upon a time, far far away, there were the old Bird developers discussing what direction of route flow shall be called import and export. They decided to say "import to protocol" and "export to table" when speaking about a protocol. When speaking about a table, they spoke about "importing to table" and "exporting to protocol". The latter terminology was adopted in configuration, then also the bird CLI in commit ea2ae6dd0 started to use it (in year 2009). Now it's 2018 and the terminology is the latter. Import is from protocol to table, export is from table to protocol. Anyway, there was still an import_control hook which executed right before route export. One thing is funny. There are two commits in April 1999 with just two minutes between them. The older announces the final settlement on config terminology, the newer uses the other definition. Let's see their commit messages as the git-log tool shows them (the newer first): commit 9e0e485e50ea74c4f1c5cb65bdfe6ce819c2cee2 Author: Martin Mares <mj@ucw.cz> Date: Mon Apr 5 20:17:59 1999 +0000 Added some new protocol hooks (look at the comments for better explanation): make_tmp_attrs Convert inline attributes to ea_list store_tmp_attrs Convert ea_list to inline attributes import_control Pre-import decisions commit 5056c559c4eb253a4eee10cf35b694faec5265eb Author: Martin Mares <mj@ucw.cz> Date: Mon Apr 5 20:15:31 1999 +0000 Changed syntax of attaching filters to protocols to hopefully the final version: EXPORT <filter-spec> for outbound routes (i.e., those announced by BIRD to the rest of the world). IMPORT <filter-spec> for inbound routes (i.e., those imported by BIRD from the rest of the world). where <filter-spec> is one of: ALL pass all routes NONE drop all routes FILTER <name> use named filter FILTER { <filter> } use explicitly defined filter For all protocols, the default is IMPORT ALL, EXPORT NONE. This includes the kernel protocol, so that you need to add EXPORT ALL to get the previous configuration of kernel syncer (as usually, see doc/bird.conf.example for a bird.conf example :)). Let's say RIP to this almost 19-years-old inconsistency. For now, if you import a route, it is always from protocol to table. If you export a route, it is always from table to protocol. And they lived happily ever after.
2018-02-14 20:42:53 +08:00
* preexport - pre-filtering decisions before route export
* @p: protocol instance the route is going to be exported to
2000-06-03 01:24:11 +08:00
* @e: the route in question
* @attrs: extended attributes of the route
* @pool: linear pool for allocation of all temporary data
*
Terminology cleanup: The import_control hook is now called preexport. Once upon a time, far far away, there were the old Bird developers discussing what direction of route flow shall be called import and export. They decided to say "import to protocol" and "export to table" when speaking about a protocol. When speaking about a table, they spoke about "importing to table" and "exporting to protocol". The latter terminology was adopted in configuration, then also the bird CLI in commit ea2ae6dd0 started to use it (in year 2009). Now it's 2018 and the terminology is the latter. Import is from protocol to table, export is from table to protocol. Anyway, there was still an import_control hook which executed right before route export. One thing is funny. There are two commits in April 1999 with just two minutes between them. The older announces the final settlement on config terminology, the newer uses the other definition. Let's see their commit messages as the git-log tool shows them (the newer first): commit 9e0e485e50ea74c4f1c5cb65bdfe6ce819c2cee2 Author: Martin Mares <mj@ucw.cz> Date: Mon Apr 5 20:17:59 1999 +0000 Added some new protocol hooks (look at the comments for better explanation): make_tmp_attrs Convert inline attributes to ea_list store_tmp_attrs Convert ea_list to inline attributes import_control Pre-import decisions commit 5056c559c4eb253a4eee10cf35b694faec5265eb Author: Martin Mares <mj@ucw.cz> Date: Mon Apr 5 20:15:31 1999 +0000 Changed syntax of attaching filters to protocols to hopefully the final version: EXPORT <filter-spec> for outbound routes (i.e., those announced by BIRD to the rest of the world). IMPORT <filter-spec> for inbound routes (i.e., those imported by BIRD from the rest of the world). where <filter-spec> is one of: ALL pass all routes NONE drop all routes FILTER <name> use named filter FILTER { <filter> } use explicitly defined filter For all protocols, the default is IMPORT ALL, EXPORT NONE. This includes the kernel protocol, so that you need to add EXPORT ALL to get the previous configuration of kernel syncer (as usually, see doc/bird.conf.example for a bird.conf example :)). Let's say RIP to this almost 19-years-old inconsistency. For now, if you import a route, it is always from protocol to table. If you export a route, it is always from table to protocol. And they lived happily ever after.
2018-02-14 20:42:53 +08:00
* The preexport() hook is called as the first step of a exporting
2000-06-03 01:24:11 +08:00
* a route from a routing table to the protocol instance. It can modify
Terminology cleanup: The import_control hook is now called preexport. Once upon a time, far far away, there were the old Bird developers discussing what direction of route flow shall be called import and export. They decided to say "import to protocol" and "export to table" when speaking about a protocol. When speaking about a table, they spoke about "importing to table" and "exporting to protocol". The latter terminology was adopted in configuration, then also the bird CLI in commit ea2ae6dd0 started to use it (in year 2009). Now it's 2018 and the terminology is the latter. Import is from protocol to table, export is from table to protocol. Anyway, there was still an import_control hook which executed right before route export. One thing is funny. There are two commits in April 1999 with just two minutes between them. The older announces the final settlement on config terminology, the newer uses the other definition. Let's see their commit messages as the git-log tool shows them (the newer first): commit 9e0e485e50ea74c4f1c5cb65bdfe6ce819c2cee2 Author: Martin Mares <mj@ucw.cz> Date: Mon Apr 5 20:17:59 1999 +0000 Added some new protocol hooks (look at the comments for better explanation): make_tmp_attrs Convert inline attributes to ea_list store_tmp_attrs Convert ea_list to inline attributes import_control Pre-import decisions commit 5056c559c4eb253a4eee10cf35b694faec5265eb Author: Martin Mares <mj@ucw.cz> Date: Mon Apr 5 20:15:31 1999 +0000 Changed syntax of attaching filters to protocols to hopefully the final version: EXPORT <filter-spec> for outbound routes (i.e., those announced by BIRD to the rest of the world). IMPORT <filter-spec> for inbound routes (i.e., those imported by BIRD from the rest of the world). where <filter-spec> is one of: ALL pass all routes NONE drop all routes FILTER <name> use named filter FILTER { <filter> } use explicitly defined filter For all protocols, the default is IMPORT ALL, EXPORT NONE. This includes the kernel protocol, so that you need to add EXPORT ALL to get the previous configuration of kernel syncer (as usually, see doc/bird.conf.example for a bird.conf example :)). Let's say RIP to this almost 19-years-old inconsistency. For now, if you import a route, it is always from protocol to table. If you export a route, it is always from table to protocol. And they lived happily ever after.
2018-02-14 20:42:53 +08:00
* route attributes and force acceptance or rejection of the route before
* the user-specified filters are run. See rte_announce() for a complete description
2000-06-03 01:24:11 +08:00
* of the route distribution process.
*
* The standard use of this hook is to reject routes having originated
* from the same instance and to set default values of the protocol's metrics.
*
* Result: 1 if the route has to be accepted, -1 if rejected and 0 if it
2000-06-03 01:24:11 +08:00
* should be passed to the filters.
*/
Terminology cleanup: The import_control hook is now called preexport. Once upon a time, far far away, there were the old Bird developers discussing what direction of route flow shall be called import and export. They decided to say "import to protocol" and "export to table" when speaking about a protocol. When speaking about a table, they spoke about "importing to table" and "exporting to protocol". The latter terminology was adopted in configuration, then also the bird CLI in commit ea2ae6dd0 started to use it (in year 2009). Now it's 2018 and the terminology is the latter. Import is from protocol to table, export is from table to protocol. Anyway, there was still an import_control hook which executed right before route export. One thing is funny. There are two commits in April 1999 with just two minutes between them. The older announces the final settlement on config terminology, the newer uses the other definition. Let's see their commit messages as the git-log tool shows them (the newer first): commit 9e0e485e50ea74c4f1c5cb65bdfe6ce819c2cee2 Author: Martin Mares <mj@ucw.cz> Date: Mon Apr 5 20:17:59 1999 +0000 Added some new protocol hooks (look at the comments for better explanation): make_tmp_attrs Convert inline attributes to ea_list store_tmp_attrs Convert ea_list to inline attributes import_control Pre-import decisions commit 5056c559c4eb253a4eee10cf35b694faec5265eb Author: Martin Mares <mj@ucw.cz> Date: Mon Apr 5 20:15:31 1999 +0000 Changed syntax of attaching filters to protocols to hopefully the final version: EXPORT <filter-spec> for outbound routes (i.e., those announced by BIRD to the rest of the world). IMPORT <filter-spec> for inbound routes (i.e., those imported by BIRD from the rest of the world). where <filter-spec> is one of: ALL pass all routes NONE drop all routes FILTER <name> use named filter FILTER { <filter> } use explicitly defined filter For all protocols, the default is IMPORT ALL, EXPORT NONE. This includes the kernel protocol, so that you need to add EXPORT ALL to get the previous configuration of kernel syncer (as usually, see doc/bird.conf.example for a bird.conf example :)). Let's say RIP to this almost 19-years-old inconsistency. For now, if you import a route, it is always from protocol to table. If you export a route, it is always from table to protocol. And they lived happily ever after.
2018-02-14 20:42:53 +08:00
int preexport(struct proto *p, rte **e, ea_list **attrs, struct linpool *pool)
2000-06-03 01:24:11 +08:00
{ DUMMY; }
/**
* rte_recalculate - prepare routes for comparison
2018-02-07 00:43:55 +08:00
* @table: a routing table
* @net: a network entry
* @new: new route for the network
* @old: old route for the network
* @old_best: old best route for the network (may be NULL)
*
* This hook is called when a route change (from @old to @new for a
* @net entry) is propagated to a @table. It may be used to prepare
* routes for comparison by rte_better() in the best route
* selection. @new may or may not be in @net->routes list,
* @old is not there.
*
* Result: 1 if the ordering implied by rte_better() changes enough
* that full best route calculation have to be done, 0 otherwise.
*/
int rte_recalculate(struct rtable *table, struct network *net, struct rte *new, struct rte *old, struct rte *old_best)
{ DUMMY; }
2000-06-03 01:24:11 +08:00
/**
* rte_better - compare metrics of two routes
* @new: the new route
* @old: the original route
*
* This hook gets called when the routing table contains two routes
* for the same network which have originated from different instances
* of a single protocol and it wants to select which one is preferred
* over the other one. Protocols usually decide according to route metrics.
*
* Result: 1 if @new is better (more preferred) than @old, 0 otherwise.
*/
int rte_better(rte *new, rte *old)
{ DUMMY; }
/**
* rte_same - compare two routes
* @e1: route
* @e2: route
*
* The rte_same() hook tests whether the routes @e1 and @e2 belonging
* to the same protocol instance have identical contents. Contents of
* &rta, all the extended attributes and &rte preference are checked
* by the core code, no need to take care of them here.
*
* Result: 1 if @e1 is identical to @e2, 0 otherwise.
*/
int rte_same(rte *e1, rte *e2)
{ DUMMY; }
/**
* rte_insert - notify instance about route insertion
* @n: network
* @e: route
*
* This hook is called whenever a &rte belonging to the instance
* is accepted for insertion to a routing table.
*
* Please avoid using this function in new protocols.
*/
void rte_insert(net *n, rte *e)
{ DUMMY; }
/**
* rte_remove - notify instance about route removal
* @n: network
* @e: route
*
* This hook is called whenever a &rte belonging to the instance
* is removed from a routing table.
*
* Please avoid using this function in new protocols.
*/
void rte_remove(net *n, rte *e)
{ DUMMY; }