embedaddon/bird/doc/prog-5.html - view

File: [ELWIX - Embedded LightWeight unIX -] / embedaddon / bird / doc / prog-5.html
Revision 1.1.1.2 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Wed Mar 17 19:50:23 2021 UTC (3 years, 7 months ago) by misho
Branches: bird, MAIN
CVS tags: v1_6_8p3, HEAD

bird 1.6.8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 1.0.9"> <TITLE>BIRD Programmer's Documentation: Protocols</TITLE> <LINK HREF="prog-6.html" REL=next> <LINK HREF="prog-4.html" REL=previous> <LINK HREF="prog.html#toc5" REL=contents> </HEAD> <BODY> <A HREF="prog-6.html">Next</A> <A HREF="prog-4.html">Previous</A> <A HREF="prog.html#toc5">Contents</A> <HR> <H2><A NAME="s5">5.</A> <A HREF="prog.html#toc5">Protocols</A></H2> <H2><A NAME="ss5.1">5.1</A> <A HREF="prog.html#toc5.1">The Babel protocol</A> </H2>  Babel (RFC6126) is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. The Babel protocol keeps state for each neighbour in a babel_neighbor struct, tracking received Hello and I Heard You (IHU) messages. A babel_interface struct keeps hello and update times for each interface, and a separate hello seqno is maintained for each interface. For each prefix, Babel keeps track of both the possible routes (with next hop and router IDs), as well as the feasibility distance for each prefix and router id. The prefix itself is tracked in a babel_entry struct, while the possible routes for the prefix are tracked as babel_route entries and the feasibility distance is maintained through babel_source structures. The main route selection is done in babel_select_route(). This is called when an entry is updated by receiving updates from the network or when modified by internal timers. It performs feasibility checks on the available routes for the prefix and selects the one with the lowest metric to be announced to the core.  <HR><H3>Function</H3> void babel_announce_rte (struct babel_proto * p, struct babel_entry * e) -- announce selected route to the core  <H3>Arguments</H3>  <DL> <DT>struct babel_proto * p<DD>Babel protocol instance <DT>struct babel_entry * e<DD>Babel route entry to announce </DL> <H3>Description</H3> This function announces a Babel entry to the core if it has a selected incoming path, and retracts it otherwise. If the selected entry has infinite metric, the route is announced as unreachable. <HR><H3>Function</H3> void babel_select_route (struct babel_entry * e) -- select best route for given route entry  <H3>Arguments</H3>  <DL> <DT>struct babel_entry * e<DD>Babel entry to select the best route for </DL> <H3>Description</H3> Select the best feasible route for a given prefix among the routes received from peers, and propagate it to the nest. This just selects the feasible route with the lowest metric. If no feasible route is available for a prefix that previously had a route selected, a seqno request is sent to try to get a valid route. In the meantime, the route is marked as infeasible in the nest (to blackhole packets going to it, as per the RFC). If no feasible route is available, and no previous route is selected, the route is removed from the nest entirely. <HR><H3>Function</H3> void babel_send_update (struct babel_iface * ifa, bird_clock_t changed) -- send route table updates  <H3>Arguments</H3>  <DL> <DT>struct babel_iface * ifa<DD>Interface to transmit on <DT>bird_clock_t changed<DD>Only send entries changed since this time </DL> <H3>Description</H3> This function produces update TLVs for all entries changed since the time indicated by the changed parameter and queues them for transmission on the selected interface. During the process, the feasibility distance for each transmitted entry is updated. <HR><H3>Function</H3> void babel_handle_update (union babel_msg * m, struct babel_iface * ifa) -- handle incoming route updates  <H3>Arguments</H3>  <DL> <DT>union babel_msg * m<DD>Incoming update TLV <DT>struct babel_iface * ifa<DD>Interface the update was received on </DL> <H3>Description</H3> This function is called as a handler for update TLVs and handles the updating and maintenance of route entries in Babel's internal routing cache. The handling follows the actions described in the Babel RFC, and at the end of each update handling, babel_select_route() is called on the affected entry to optionally update the selected routes and propagate them to the core. <HR><H3>Function</H3> void babel_iface_timer (timer * t) -- Babel interface timer handler  <H3>Arguments</H3>  <DL> <DT>timer * t<DD>Timer </DL> <H3>Description</H3> This function is called by the per-interface timer and triggers sending of periodic Hello's and both triggered and periodic updates. Periodic Hello's and updates are simply handled by setting the next_{hello,regular} variables on the interface, and triggering an update (and resetting the variable) whenever 'now' exceeds that value. For triggered updates, babel_trigger_iface_update() will set the want_triggered field on the interface to a timestamp value. If this is set (and the next_triggered time has passed; this is a rate limiting mechanism), babel_send_update() will be called with this timestamp as the second parameter. This causes updates to be send consisting of only the routes that have changed since the time saved in want_triggered. Mostly when an update is triggered, the route being modified will be set to the value of 'now' at the time of the trigger; the >= comparison for selecting which routes to send in the update will make sure this is included. <HR><H3>Function</H3> void babel_timer (timer * t) -- global timer hook  <H3>Arguments</H3>  <DL> <DT>timer * t<DD>Timer </DL> <H3>Description</H3> This function is called by the global protocol instance timer and handles expiration of routes and neighbours as well as pruning of the seqno request cache. <HR><H3>Function</H3> uint babel_write_queue (struct babel_iface * ifa, list * queue) -- Write a TLV queue to a transmission buffer  <H3>Arguments</H3>  <DL> <DT>struct babel_iface * ifa<DD>Interface holding the transmission buffer <DT>list * queue<DD>TLV queue to write (containing internal-format TLVs) </DL> <H3>Description</H3> This function writes a packet to the interface transmission buffer with as many TLVs from the queue as will fit in the buffer. It returns the number of bytes written (NOT counting the packet header). The function is called by babel_send_queue() and babel_send_unicast() to construct packets for transmission, and uses per-TLV helper functions to convert the internal-format TLVs to their wire representations. The TLVs in the queue are freed after they are written to the buffer. <HR><H3>Function</H3> void babel_send_unicast (union babel_msg * msg, struct babel_iface * ifa, ip_addr dest) -- send a single TLV via unicast to a destination  <H3>Arguments</H3>  <DL> <DT>union babel_msg * msg<DD>TLV to send <DT>struct babel_iface * ifa<DD>Interface to send via <DT>ip_addr dest<DD>Destination of the TLV </DL> <H3>Description</H3> This function is used to send a single TLV via unicast to a designated receiver. This is used for replying to certain incoming requests, and for sending unicast requests to refresh routes before they expire. <HR><H3>Function</H3> void babel_enqueue (union babel_msg * msg, struct babel_iface * ifa) -- enqueue a TLV for transmission on an interface  <H3>Arguments</H3>  <DL> <DT>union babel_msg * msg<DD>TLV to enqueue (in internal TLV format) <DT>struct babel_iface * ifa<DD>Interface to enqueue to </DL> <H3>Description</H3> This function is called to enqueue a TLV for subsequent transmission on an interface. The transmission event is triggered whenever a TLV is enqueued; this ensures that TLVs will be transmitted in a timely manner, but that TLVs which are enqueued in rapid succession can be transmitted together in one packet. <HR><H3>Function</H3> void babel_process_packet (struct babel_pkt_header * pkt, int len, ip_addr saddr, struct babel_iface * ifa) -- process incoming data packet  <H3>Arguments</H3>  <DL> <DT>struct babel_pkt_header * pkt<DD>Pointer to the packet data <DT>int len<DD>Length of received packet <DT>ip_addr saddr<DD>Address of packet sender <DT>struct babel_iface * ifa<DD>Interface packet was received on. </DL> <H3>Description</H3> This function is the main processing hook of incoming Babel packets. It checks that the packet header is well-formed, then processes the TLVs contained in the packet. This is done in two passes: First all TLVs are parsed into the internal TLV format. If a TLV parser fails, processing of the rest of the packet is aborted. After the parsing step, the TLV handlers are called for each parsed TLV in order. <H2><A NAME="ss5.2">5.2</A> <A HREF="prog.html#toc5.2">Bidirectional Forwarding Detection</A> </H2>  The BFD protocol is implemented in three files: <CODE>bfd.c</CODE> containing the protocol logic and the protocol glue with BIRD core, <CODE>packets.c</CODE> handling BFD packet processing, RX, TX and protocol sockets. <CODE>io.c</CODE> then contains generic code for the event loop, threads and event sources (sockets, microsecond timers). This generic code will be merged to the main BIRD I/O code in the future. The BFD implementation uses a separate thread with an internal event loop for handling the protocol logic, which requires high-res and low-latency timing, so it is not affected by the rest of BIRD, which has several low-granularity hooks in the main loop, uses second-based timers and cannot offer good latency. The core of BFD protocol (the code related to BFD sessions, interfaces and packets) runs in the BFD thread, while the rest (the code related to BFD requests, BFD neighbors and the protocol glue) runs in the main thread. BFD sessions are represented by structure bfd_session that contains a state related to the session and two timers (TX timer for periodic packets and hold timer for session timeout). These sessions are allocated from session_slab and are accessible by two hash tables, session_hash_id (by session ID) and session_hash_ip (by IP addresses of neighbors). Slab and both hashes are in the main protocol structure bfd_proto. The protocol logic related to BFD sessions is implemented in internal functions bfd_session_*(), which are expected to be called from the context of BFD thread, and external functions bfd_add_session(), bfd_remove_session() and bfd_reconfigure_session(), which form an interface to the BFD core for the rest and are expected to be called from the context of main thread. Each BFD session has an associated BFD interface, represented by structure bfd_iface. A BFD interface contains a socket used for TX (the one for RX is shared in bfd_proto), an interface configuration and reference counter. Compared to interface structures of other protocols, these structures are not created and removed based on interface notification events, but according to the needs of BFD sessions. When a new session is created, it requests a proper BFD interface by function bfd_get_iface(), which either finds an existing one in iface_list (from bfd_proto) or allocates a new one. When a session is removed, an associated iface is discharged by bfd_free_iface(). BFD requests are the external API for the other protocols. When a protocol wants a BFD session, it calls bfd_request_session(), which creates a structure bfd_request containing approprite information and an notify hook. This structure is a resource associated with the caller's resource pool. When a BFD protocol is available, a BFD request is submitted to the protocol, an appropriate BFD session is found or created and the request is attached to the session. When a session changes state, all attached requests (and related protocols) are notified. Note that BFD requests do not depend on BFD protocol running. When the BFD protocol is stopped or removed (or not available from beginning), related BFD requests are stored in bfd_wait_list, where waits for a new protocol. BFD neighbors are just a way to statically configure BFD sessions without requests from other protocol. Structures bfd_neighbor are part of BFD configuration (like static routes in the static protocol). BFD neighbors are handled by BFD protocol like it is a BFD client -- when a BFD neighbor is ready, the protocol just creates a BFD request like any other protocol. The protocol uses a new generic event loop (structure birdloop) from <CODE>io.c</CODE>, which supports sockets, timers and events like the main loop. Timers (structure timer2) are new microsecond based timers, while sockets and events are the same. A birdloop is associated with a thread (field thread) in which event hooks are executed. Most functions for setting event sources (like sk_start() or tm2_start()) must be called from the context of that thread. Birdloop allows to temporarily acquire the context of that thread for the main thread by calling birdloop_enter() and then birdloop_leave(), which also ensures mutual exclusion with all event hooks. Note that resources associated with a birdloop (like timers) should be attached to the independent resource pool, detached from the main resource tree. There are two kinds of interaction between the BFD core (running in the BFD thread) and the rest of BFD (running in the main thread). The first kind are configuration calls from main thread to the BFD thread (like bfd_add_session()). These calls are synchronous and use birdloop_enter() mechanism for mutual exclusion. The second kind is a notification about session changes from the BFD thread to the main thread. This is done in an asynchronous way, sesions with pending notifications are linked (in the BFD thread) to notify_list in bfd_proto, and then bfd_notify_hook() in the main thread is activated using bfd_notify_kick() and a pipe. The hook then processes scheduled sessions and calls hooks from associated BFD requests. This notify_list (and state fields in structure bfd_session) is protected by a spinlock in bfd_proto and functions bfd_lock_sessions() / bfd_unlock_sessions(). There are few data races (accessing p->p.debug from TRACE() from the BFD thread and accessing some some private fields of bfd_session from bfd_show_sessions() from the main thread, but these are harmless (i hope). TODO: document functions and access restrictions for fields in BFD structures. Supported standards: - RFC 5880 - main BFD standard - RFC 5881 - BFD for IP links - RFC 5882 - generic application of BFD - RFC 5883 - BFD for multihop paths   <H2><A NAME="ss5.3">5.3</A> <A HREF="prog.html#toc5.3">Border Gateway Protocol</A> </H2>  The BGP protocol is implemented in three parts: <CODE>bgp.c</CODE> which takes care of the connection and most of the interface with BIRD core, <CODE>packets.c</CODE> handling both incoming and outgoing BGP packets and <CODE>attrs.c</CODE> containing functions for manipulation with BGP attribute lists. As opposed to the other existing routing daemons, BIRD has a sophisticated core architecture which is able to keep all the information needed by BGP in the primary routing table, therefore no complex data structures like a central BGP table are needed. This increases memory footprint of a BGP router with many connections, but not too much and, which is more important, it makes BGP much easier to implement. Each instance of BGP (corresponding to a single BGP peer) is described by a bgp_proto structure to which are attached individual connections represented by bgp_connection (usually, there exists only one connection, but during BGP session setup, there can be more of them). The connections are handled according to the BGP state machine defined in the RFC with all the timers and all the parameters configurable. In incoming direction, we listen on the connection's socket and each time we receive some input, we pass it to bgp_rx(). It decodes packet headers and the markers and passes complete packets to bgp_rx_packet() which distributes the packet according to its type. In outgoing direction, we gather all the routing updates and sort them to buckets (bgp_bucket) according to their attributes (we keep a hash table for fast comparison of rta's and a fib which helps us to find if we already have another route for the same destination queued for sending, so that we can replace it with the new one immediately instead of sending both updates). There also exists a special bucket holding all the route withdrawals which cannot be queued anywhere else as they don't have any attributes. If we have any packet to send (due to either new routes or the connection tracking code wanting to send a Open, Keepalive or Notification message), we call bgp_schedule_packet() which sets the corresponding bit in a packet_to_send bit field in bgp_conn and as soon as the transmit socket buffer becomes empty, we call bgp_fire_tx(). It inspects state of all the packet type bits and calls the corresponding bgp_create_xx() functions, eventually rescheduling the same packet type if we have more data of the same type to send. The processing of attributes consists of two functions: bgp_decode_attrs() for checking of the attribute blocks and translating them to the language of BIRD's extended attributes and bgp_encode_attrs() which does the converse. Both functions are built around a bgp_attr_table array describing all important characteristics of all known attributes. Unknown transitive attributes are attached to the route as EAF_TYPE_OPAQUE byte streams. BGP protocol implements graceful restart in both restarting (local restart) and receiving (neighbor restart) roles. The first is handled mostly by the graceful restart code in the nest, BGP protocol just handles capabilities, sets gr_wait and locks graceful restart until end-of-RIB mark is received. The second is implemented by internal restart of the BGP state to BS_IDLE and protocol state to PS_START, but keeping the protocol up from the core point of view and therefore maintaining received routes. Routing table refresh cycle (rt_refresh_begin(), rt_refresh_end()) is used for removing stale routes after reestablishment of BGP session during graceful restart.  <HR><H3>Function</H3> int bgp_open (struct bgp_proto * p) -- open a BGP instance  <H3>Arguments</H3>  <DL> <DT>struct bgp_proto * p<DD>BGP instance </DL> <H3>Description</H3> This function allocates and configures shared BGP resources. Should be called as the last step during initialization (when lock is acquired and neighbor is ready). When error, state changed to PS_DOWN, -1 is returned and caller should return immediately. <HR><H3>Function</H3> void bgp_close (struct bgp_proto * p, int apply_md5) -- close a BGP instance  <H3>Arguments</H3>  <DL> <DT>struct bgp_proto * p<DD>BGP instance <DT>int apply_md5<DD>0 to disable unsetting MD5 auth </DL> <H3>Description</H3> This function frees and deconfigures shared BGP resources. apply_md5 is set to 0 when bgp_close is called as a cleanup from failed bgp_open(). <HR><H3>Function</H3> void bgp_start_timer (timer * t, int value) -- start a BGP timer  <H3>Arguments</H3>  <DL> <DT>timer * t<DD>timer <DT>int value<DD>time to fire (0 to disable the timer) </DL> <H3>Description</H3> This functions calls tm_start() on t with time value and the amount of randomization suggested by the BGP standard. Please use it for all BGP timers. <HR><H3>Function</H3> void bgp_close_conn (struct bgp_conn * conn) -- close a BGP connection  <H3>Arguments</H3>  <DL> <DT>struct bgp_conn * conn<DD>connection to close </DL> <H3>Description</H3> This function takes a connection described by the bgp_conn structure, closes its socket and frees all resources associated with it. <HR><H3>Function</H3> void bgp_update_startup_delay (struct bgp_proto * p) -- update a startup delay  <H3>Arguments</H3>  <DL> <DT>struct bgp_proto * p<DD>BGP instance </DL> <H3>Description</H3> This function updates a startup delay that is used to postpone next BGP connect. It also handles disable_after_error and might stop BGP instance when error happened and disable_after_error is on. It should be called when BGP protocol error happened. <HR><H3>Function</H3> void bgp_handle_graceful_restart (struct bgp_proto * p) -- handle detected BGP graceful restart  <H3>Arguments</H3>  <DL> <DT>struct bgp_proto * p<DD>BGP instance </DL> <H3>Description</H3> This function is called when a BGP graceful restart of the neighbor is detected (when the TCP connection fails or when a new TCP connection appears). The function activates processing of the restart - starts routing table refresh cycle and activates BGP restart timer. The protocol state goes back to PS_START, but changing BGP state back to BS_IDLE is left for the caller. <HR><H3>Function</H3> void bgp_graceful_restart_done (struct bgp_proto * p) -- finish active BGP graceful restart  <H3>Arguments</H3>  <DL> <DT>struct bgp_proto * p<DD>BGP instance </DL> <H3>Description</H3> This function is called when the active BGP graceful restart of the neighbor should be finished - either successfully (the neighbor sends all paths and reports end-of-RIB on the new session) or unsuccessfully (the neighbor does not support BGP graceful restart on the new session). The function ends routing table refresh cycle and stops BGP restart timer. <HR><H3>Function</H3> void bgp_graceful_restart_timeout (timer * t) -- timeout of graceful restart 'restart timer'  <H3>Arguments</H3>  <DL> <DT>timer * t<DD>timer </DL> <H3>Description</H3> This function is a timeout hook for gr_timer, implementing BGP restart time limit for reestablisment of the BGP session after the graceful restart. When fired, we just proceed with the usual protocol restart. <HR><H3>Function</H3> void bgp_refresh_begin (struct bgp_proto * p) -- start incoming enhanced route refresh sequence  <H3>Arguments</H3>  <DL> <DT>struct bgp_proto * p<DD>BGP instance </DL> <H3>Description</H3> This function is called when an incoming enhanced route refresh sequence is started by the neighbor, demarcated by the BoRR packet. The function updates the load state and starts the routing table refresh cycle. Note that graceful restart also uses routing table refresh cycle, but RFC 7313 and load states ensure that these two sequences do not overlap. <HR><H3>Function</H3> void bgp_refresh_end (struct bgp_proto * p) -- finish incoming enhanced route refresh sequence  <H3>Arguments</H3>  <DL> <DT>struct bgp_proto * p<DD>BGP instance </DL> <H3>Description</H3> This function is called when an incoming enhanced route refresh sequence is finished by the neighbor, demarcated by the EoRR packet. The function updates the load state and ends the routing table refresh cycle. Routes not received during the sequence are removed by the nest. <HR><H3>Function</H3> void bgp_connect (struct bgp_proto * p) -- initiate an outgoing connection  <H3>Arguments</H3>  <DL> <DT>struct bgp_proto * p<DD>BGP instance </DL> <H3>Description</H3> The bgp_connect() function creates a new bgp_conn and initiates a TCP connection to the peer. The rest of connection setup is governed by the BGP state machine as described in the standard. <HR><H3>Function</H3> struct bgp_proto * bgp_find_proto (sock * sk) -- find existing proto for incoming connection  <H3>Arguments</H3>  <DL> <DT>sock * sk<DD>TCP socket </DL> <HR><H3>Function</H3> int bgp_incoming_connection (sock * sk, uint dummy UNUSED) -- handle an incoming connection  <H3>Arguments</H3>  <DL> <DT>sock * sk<DD>TCP socket <DT>uint dummy UNUSED<DD>-- undescribed -- </DL> <H3>Description</H3> This function serves as a socket hook for accepting of new BGP connections. It searches a BGP instance corresponding to the peer which has connected and if such an instance exists, it creates a bgp_conn structure, attaches it to the instance and either sends an Open message or (if there already is an active connection) it closes the new connection by sending a Notification message. <HR><H3>Function</H3> void bgp_error (struct bgp_conn * c, unsigned code, unsigned subcode, byte * data, int len) -- report a protocol error  <H3>Arguments</H3>  <DL> <DT>struct bgp_conn * c<DD>connection <DT>unsigned code<DD>error code (according to the RFC) <DT>unsigned subcode<DD>error sub-code <DT>byte * data<DD>data to be passed in the Notification message <DT>int len<DD>length of the data </DL> <H3>Description</H3> bgp_error() sends a notification packet to tell the other side that a protocol error has occurred (including the data considered erroneous if possible) and closes the connection. <HR><H3>Function</H3> void bgp_store_error (struct bgp_proto * p, struct bgp_conn * c, u8 class, u32 code) -- store last error for status report  <H3>Arguments</H3>  <DL> <DT>struct bgp_proto * p<DD>BGP instance <DT>struct bgp_conn * c<DD>connection <DT>u8 class<DD>error class (BE_xxx constants) <DT>u32 code<DD>error code (class specific) </DL> <H3>Description</H3> bgp_store_error() decides whether given error is interesting enough and store that error to last_error variables of p <HR><H3>Function</H3> int bgp_fire_tx (struct bgp_conn * conn) -- transmit packets  <H3>Arguments</H3>  <DL> <DT>struct bgp_conn * conn<DD>connection </DL> <H3>Description</H3> Whenever the transmit buffers of the underlying TCP connection are free and we have any packets queued for sending, the socket functions call bgp_fire_tx() which takes care of selecting the highest priority packet queued (Notification > Keepalive > Open > Update), assembling its header and body and sending it to the connection. <HR><H3>Function</H3> void bgp_schedule_packet (struct bgp_conn * conn, int type) -- schedule a packet for transmission  <H3>Arguments</H3>  <DL> <DT>struct bgp_conn * conn<DD>connection <DT>int type<DD>packet type </DL> <H3>Description</H3> Schedule a packet of type type to be sent as soon as possible. <HR><H3>Function</H3> const char * bgp_error_dsc (unsigned code, unsigned subcode) -- return BGP error description  <H3>Arguments</H3>  <DL> <DT>unsigned code<DD>BGP error code <DT>unsigned subcode<DD>BGP error subcode </DL> <H3>Description</H3> bgp_error_dsc() returns error description for BGP errors which might be static string or given temporary buffer. <HR><H3>Function</H3> void bgp_rx_packet (struct bgp_conn * conn, byte * pkt, unsigned len) -- handle a received packet  <H3>Arguments</H3>  <DL> <DT>struct bgp_conn * conn<DD>BGP connection <DT>byte * pkt<DD>start of the packet <DT>unsigned len<DD>packet size </DL> <H3>Description</H3> bgp_rx_packet() takes a newly received packet and calls the corresponding packet handler according to the packet type. <HR><H3>Function</H3> int bgp_rx (sock * sk, uint size) -- handle received data  <H3>Arguments</H3>  <DL> <DT>sock * sk<DD>socket <DT>uint size<DD>amount of data received </DL> <H3>Description</H3> bgp_rx() is called by the socket layer whenever new data arrive from the underlying TCP connection. It assembles the data fragments to packets, checks their headers and framing and passes complete packets to bgp_rx_packet(). <HR><H3>Function</H3> uint bgp_encode_attrs (struct bgp_proto * p, byte * w, ea_list * attrs, int remains) -- encode BGP attributes  <H3>Arguments</H3>  <DL> <DT>struct bgp_proto * p<DD>BGP instance (or NULL) <DT>byte * w<DD>buffer <DT>ea_list * attrs<DD>a list of extended attributes <DT>int remains<DD>remaining space in the buffer </DL> <H3>Description</H3> The bgp_encode_attrs() function takes a list of extended attributes and converts it to its BGP representation (a part of an Update message). <H3>Result</H3> Length of the attribute block generated or -1 if not enough space. <HR><H3>Function</H3> struct rta * bgp_decode_attrs (struct bgp_conn * conn, byte * attr, uint len, struct linpool * pool, int mandatory) -- check and decode BGP attributes  <H3>Arguments</H3>  <DL> <DT>struct bgp_conn * conn<DD>connection <DT>byte * attr<DD>start of attribute block <DT>uint len<DD>length of attribute block <DT>struct linpool * pool<DD>linear pool to make all the allocations in <DT>int mandatory<DD>1 iff presence of mandatory attributes has to be checked </DL> <H3>Description</H3> This function takes a BGP attribute block (a part of an Update message), checks its consistency and converts it to a list of BIRD route attributes represented by a rta. <H2><A NAME="ss5.4">5.4</A> <A HREF="prog.html#toc5.4">Multi-Threaded Routing Toolkit (MRT) protocol</A> </H2>  The MRT protocol is implemented in just one file: <CODE>mrt.c</CODE>. It contains of several parts: Generic functions for preparing MRT messages in a buffer, functions for MRT table dump (called from timer or CLI), functions for MRT BGP4MP dump (called from BGP), and the usual protocol glue. For the MRT table dump, the key structure is struct mrt_table_dump_state, which contains all necessary data and created when the MRT dump cycle is started for the duration of the MRT dump. The MBGP4MP dump is currently not bound to MRT protocol instance and uses the config->mrtdump_file fd. The protocol is simple, just periodically scans routing table and export it to a file. It does not use the regular update mechanism, but a direct access in order to handle iteration through multiple routing tables. The table dump needs to dump all peers first and then use indexes to address the peers, we use a hash table (peer_hash) to find peer index based on BGP protocol key attributes. One thing worth documenting is the locking. During processing, the currently processed table (table field in the state structure) is locked and also the explicitly named table is locked (table_ptr field in the state structure) if specified. Between dumps no table is locked. Also the current config is locked (by config_add_obstacle()) during table dumps as some data (strings, filters) are shared from the config and the running table dump may be interrupted by reconfiguration. Supported standards: - RFC 6396 - MRT format standard - RFC 8050 - ADD_PATH extension   <H2><A NAME="ss5.5">5.5</A> <A HREF="prog.html#toc5.5">Open Shortest Path First (OSPF)</A> </H2>  The OSPF protocol is quite complicated and its complex implemenation is split to many files. In <CODE>ospf.c</CODE>, you will find mainly the interface for communication with the core (e.g., reconfiguration hooks, shutdown and initialisation and so on). File <CODE>iface.c</CODE> contains the interface state machine and functions for allocation and deallocation of OSPF's interface data structures. Source <CODE>neighbor.c</CODE> includes the neighbor state machine and functions for election of Designated Router and Backup Designated router. In <CODE>packet.c</CODE>, you will find various functions for sending and receiving generic OSPF packets. There are also routines for authentication and checksumming. In <CODE>hello.c</CODE>, there are routines for sending and receiving of hello packets as well as functions for maintaining wait times and the inactivity timer. Files <CODE>lsreq.c</CODE>, <CODE>lsack.c</CODE>, <CODE>dbdes.c</CODE> contain functions for sending and receiving of link-state requests, link-state acknowledgements and database descriptions respectively. In <CODE>lsupd.c</CODE>, there are functions for sending and receiving of link-state updates and also the flooding algorithm. Source <CODE>topology.c</CODE> is a place where routines for searching LSAs in the link-state database, adding and deleting them reside, there also are functions for originating of various types of LSAs (router LSA, net LSA, external LSA). File <CODE>rt.c</CODE> contains routines for calculating the routing table. <CODE>lsalib.c</CODE> is a set of various functions for working with the LSAs (endianity conversions, calculation of checksum etc.). One instance of the protocol is able to hold LSA databases for multiple OSPF areas, to exchange routing information between multiple neighbors and to calculate the routing tables. The core structure is ospf_proto to which multiple ospf_area and ospf_iface structures are connected. ospf_proto is also connected to top_hash_graph which is a dynamic hashing structure that describes the link-state database. It allows fast search, addition and deletion. Each LSA is kept in two pieces: header and body. Both of them are kept in the endianity of the CPU. In OSPFv2 specification, it is implied that there is one IP prefix for each physical network/interface (unless it is an ptp link). But in modern systems, there might be more independent IP prefixes associated with an interface. To handle this situation, we have one ospf_iface for each active IP prefix (instead for each active iface); This behaves like virtual interface for the purpose of OSPF. If we receive packet, we associate it with a proper virtual interface mainly according to its source address. OSPF keeps one socket per ospf_iface. This allows us (compared to one socket approach) to evade problems with a limit of multicast groups per socket and with sending multicast packets to appropriate interface in a portable way. The socket is associated with underlying physical iface and should not receive packets received on other ifaces (unfortunately, this is not true on BSD). Generally, one packet can be received by more sockets (for example, if there are more ospf_iface on one physical iface), therefore we explicitly filter received packets according to src/dst IP address and received iface. Vlinks are implemented using particularly degenerate form of ospf_iface, which has several exceptions: it does not have its iface or socket (it copies these from 'parent' ospf_iface) and it is present in iface list even when down (it is not freed in ospf_iface_down()). The heart beat of ospf is ospf_disp(). It is called at regular intervals (ospf_proto->tick). It is responsible for aging and flushing of LSAs in the database, updating topology information in LSAs and for routing table calculation. To every ospf_iface, we connect one or more ospf_neighbor's -- a structure containing many timers and queues for building adjacency and for exchange of routing messages. BIRD's OSPF implementation respects RFC2328 in every detail, but some of internal algorithms do differ. The RFC recommends making a snapshot of the link-state database when a new adjacency is forming and sending the database description packets based on the information in this snapshot. The database can be quite large in some networks, so rather we walk through a slist structure which allows us to continue even if the actual LSA we were working with is deleted. New LSAs are added at the tail of this slist. We also do not keep a separate OSPF routing table, because the core helps us by being able to recognize when a route is updated to an identical one and it suppresses the update automatically. Due to this, we can flush all the routes we have recalculated and also those we have deleted to the core's routing table and the core will take care of the rest. This simplifies the process and conserves memory. Supported standards: - RFC 2328 - main OSPFv2 standard - RFC 5340 - main OSPFv3 standard - RFC 3101 - OSPFv2 NSSA areas - RFC 6549 - OSPFv2 multi-instance extensions - RFC 6987 - OSPF stub router advertisement  <HR><H3>Function</H3> void ospf_disp (timer * timer) -- invokes routing table calculation, aging and also area_disp()  <H3>Arguments</H3>  <DL> <DT>timer * timer<DD>timer usually called every ospf_proto->tick second, timer->data point to ospf_proto </DL> <HR><H3>Function</H3> int ospf_import_control (struct proto * P, rte ** new, ea_list ** attrs, struct linpool * pool) -- accept or reject new route from nest's routing table  <H3>Arguments</H3>  <DL> <DT>struct proto * P<DD>OSPF protocol instance <DT>rte ** new<DD>the new route <DT>ea_list ** attrs<DD>list of attributes <DT>struct linpool * pool<DD>pool for allocation of attributes </DL> <H3>Description</H3> Its quite simple. It does not accept our own routes and leaves the decision on import to the filters. <HR><H3>Function</H3> int ospf_shutdown (struct proto * P) -- Finish of OSPF instance  <H3>Arguments</H3>  <DL> <DT>struct proto * P<DD>OSPF protocol instance </DL> <H3>Description</H3> RFC does not define any action that should be taken before router shutdown. To make my neighbors react as fast as possible, I send them hello packet with empty neighbor list. They should start their neighbor state machine with event NEIGHBOR_1WAY. <HR><H3>Function</H3> int ospf_reconfigure (struct proto * P, struct proto_config * c) -- reconfiguration hook  <H3>Arguments</H3>  <DL> <DT>struct proto * P<DD>current instance of protocol (with old configuration) <DT>struct proto_config * c<DD>new configuration requested by user </DL> <H3>Description</H3> This hook tries to be a little bit intelligent. Instance of OSPF will survive change of many constants like hello interval, password change, addition or deletion of some neighbor on nonbroadcast network, cost of interface, etc. <HR><H3>Function</H3> struct top_hash_entry * ospf_install_lsa (struct ospf_proto * p, struct ospf_lsa_header * lsa, u32 type, u32 domain, void * body) -- install new LSA into database  <H3>Arguments</H3>  <DL> <DT>struct ospf_proto * p<DD>OSPF protocol instance <DT>struct ospf_lsa_header * lsa<DD>LSA header <DT>u32 type<DD>type of LSA <DT>u32 domain<DD>domain of LSA <DT>void * body<DD>pointer to LSA body </DL> <H3>Description</H3> This function ensures installing new LSA received in LS update into LSA database. Old instance is replaced. Several actions are taken to detect if new routing table calculation is necessary. This is described in 13.2 of RFC 2328. This function is for received LSA only, locally originated LSAs are installed by ospf_originate_lsa(). The LSA body in body is expected to be mb_allocated by the caller and its ownership is transferred to the LSA entry structure. <HR><H3>Function</H3> void ospf_advance_lsa (struct ospf_proto * p, struct top_hash_entry * en, struct ospf_lsa_header * lsa, u32 type, u32 domain, void * body) -- handle received unexpected self-originated LSA  <H3>Arguments</H3>  <DL> <DT>struct ospf_proto * p<DD>OSPF protocol instance <DT>struct top_hash_entry * en<DD>current LSA entry or NULL <DT>struct ospf_lsa_header * lsa<DD>new LSA header <DT>u32 type<DD>type of LSA <DT>u32 domain<DD>domain of LSA <DT>void * body<DD>pointer to LSA body </DL> <H3>Description</H3> This function handles received unexpected self-originated LSA (lsa, body) by either advancing sequence number of the local LSA instance (en) and propagating it, or installing the received LSA and immediately flushing it (if there is no local LSA; i.e., en is NULL or MaxAge). The LSA body in body is expected to be mb_allocated by the caller and its ownership is transferred to the LSA entry structure or it is freed. <HR><H3>Function</H3> struct top_hash_entry * ospf_originate_lsa (struct ospf_proto * p, struct ospf_new_lsa * lsa) -- originate new LSA  <H3>Arguments</H3>  <DL> <DT>struct ospf_proto * p<DD>OSPF protocol instance <DT>struct ospf_new_lsa * lsa<DD>New LSA specification </DL> <H3>Description</H3> This function prepares a new LSA, installs it into the LSA database and floods it. If the new LSA cannot be originated now (because the old instance was originated within MinLSInterval, or because the LSA seqnum is currently wrapping), the origination is instead scheduled for later. If the new LSA is equivalent to the current LSA, the origination is skipped. In all cases, the corresponding LSA entry is returned. The new LSA is based on the LSA specification (lsa) and the LSA body from lsab buffer of p, which is emptied after the call. The opposite of this function is ospf_flush_lsa(). <HR><H3>Function</H3> void ospf_flush_lsa (struct ospf_proto * p, struct top_hash_entry * en) -- flush LSA from OSPF domain  <H3>Arguments</H3>  <DL> <DT>struct ospf_proto * p<DD>OSPF protocol instance <DT>struct top_hash_entry * en<DD>LSA entry to flush </DL> <H3>Description</H3> This function flushes en from the OSPF domain by setting its age to LSA_MAXAGE and flooding it. That also triggers subsequent events in LSA lifecycle leading to removal of the LSA from the LSA database (e.g. the LSA content is freed when flushing is acknowledged by neighbors). The function does nothing if the LSA is already being flushed. LSA entries are not immediately removed when being flushed, the caller may assume that en still exists after the call. The function is the opposite of ospf_originate_lsa() and is supposed to do the right thing even in cases of postponed origination. <HR><H3>Function</H3> void ospf_update_lsadb (struct ospf_proto * p) -- update LSA database  <H3>Arguments</H3>  <DL> <DT>struct ospf_proto * p<DD>OSPF protocol instance </DL> <H3>Description</H3> This function is periodicaly invoked from ospf_disp(). It does some periodic or postponed processing related to LSA entries. It originates postponed LSAs scheduled by ospf_originate_lsa(), It continues in flushing processes started by ospf_flush_lsa(). It also periodically refreshs locally originated LSAs -- when the current instance is older LSREFRESHTIME, a new instance is originated. Finally, it also ages stored LSAs and flushes ones that reached LSA_MAXAGE. The RFC 2328 says that a router should periodically check checksums of all stored LSAs to detect hardware problems. This is not implemented. <HR><H3>Function</H3> void ospf_originate_ext_lsa (struct ospf_proto * p, struct ospf_area * oa, ort * nf, u8 mode, u32 metric, u32 ebit, ip_addr fwaddr, u32 tag, int pbit) -- new route received from nest and filters  <H3>Arguments</H3>  <DL> <DT>struct ospf_proto * p<DD>OSPF protocol instance <DT>struct ospf_area * oa<DD>ospf_area for which LSA is originated <DT>ort * nf<DD>network prefix and mask <DT>u8 mode<DD>the mode of the LSA (LSA_M_EXPORT or LSA_M_RTCALC) <DT>u32 metric<DD>the metric of a route <DT>u32 ebit<DD>E-bit for route metric (bool) <DT>ip_addr fwaddr<DD>the forwarding address <DT>u32 tag<DD>the route tag <DT>int pbit<DD>P-bit for NSSA LSAs (bool), ignored for external LSAs </DL> <H3>Description</H3> If I receive a message that new route is installed, I try to originate an external LSA. If oa is an NSSA area, NSSA-LSA is originated instead. oa should not be a stub area. src does not specify whether the LSA is external or NSSA, but it specifies the source of origination - the export from ospf_rt_notify(), or the NSSA-EXT translation. <HR><H3>Function</H3> struct top_graph * ospf_top_new (struct ospf_proto *p UNUSED4 UNUSED6, pool * pool) -- allocated new topology database  <H3>Arguments</H3>  <DL> <DT>struct ospf_proto *p UNUSED4 UNUSED6<DD>-- undescribed -- <DT>pool * pool<DD>pool for allocation </DL> <H3>Description</H3> This dynamically hashed structure is used for keeping LSAs. Mainly it is used for the LSA database of the OSPF protocol, but also for LSA retransmission and request lists of OSPF neighbors. <HR><H3>Function</H3> void ospf_neigh_chstate (struct ospf_neighbor * n, u8 state) -- handles changes related to new or lod state of neighbor  <H3>Arguments</H3>  <DL> <DT>struct ospf_neighbor * n<DD>OSPF neighbor <DT>u8 state<DD>new state </DL> <H3>Description</H3> Many actions have to be taken acording to a change of state of a neighbor. It starts rxmt timers, call interface state machine etc. <HR><H3>Function</H3> void ospf_neigh_sm (struct ospf_neighbor * n, int event) -- ospf neighbor state machine  <H3>Arguments</H3>  <DL> <DT>struct ospf_neighbor * n<DD>neighor <DT>int event<DD>actual event </DL> <H3>Description</H3> This part implements the neighbor state machine as described in 10.3 of RFC 2328. The only difference is that state NEIGHBOR_ATTEMPT is not used. We discover neighbors on nonbroadcast networks in the same way as on broadcast networks. The only difference is in sending hello packets. These are sent to IPs listed in ospf_iface->nbma_list . <HR><H3>Function</H3> void ospf_dr_election (struct ospf_iface * ifa) -- (Backup) Designed Router election  <H3>Arguments</H3>  <DL> <DT>struct ospf_iface * ifa<DD>actual interface </DL> <H3>Description</H3> When the wait timer fires, it is time to elect (Backup) Designated Router. Structure describing me is added to this list so every electing router has the same list. Backup Designated Router is elected before Designated Router. This process is described in 9.4 of RFC 2328. The function is supposed to be called only from ospf_iface_sm() as a part of the interface state machine. <HR><H3>Function</H3> void ospf_iface_chstate (struct ospf_iface * ifa, u8 state) -- handle changes of interface state  <H3>Arguments</H3>  <DL> <DT>struct ospf_iface * ifa<DD>OSPF interface <DT>u8 state<DD>new state </DL> <H3>Description</H3> Many actions must be taken according to interface state changes. New network LSAs must be originated, flushed, new multicast sockets to listen for messages for ALLDROUTERS have to be opened, etc. <HR><H3>Function</H3> void ospf_iface_sm (struct ospf_iface * ifa, int event) -- OSPF interface state machine  <H3>Arguments</H3>  <DL> <DT>struct ospf_iface * ifa<DD>OSPF interface <DT>int event<DD>event comming to state machine </DL> <H3>Description</H3> This fully respects 9.3 of RFC 2328 except we have slightly different handling of DOWN and LOOP state. We remove intefaces that are DOWN. DOWN state is used when an interface is waiting for a lock. LOOP state is used when an interface does not have a link. <HR><H3>Function</H3> int ospf_rx_hook (sock * sk, uint len) <H3>Arguments</H3>  <DL> <DT>sock * sk<DD>socket we received the packet. <DT>uint len<DD>size of the packet </DL> <H3>Description</H3> This is the entry point for messages from neighbors. Many checks (like authentication, checksums, size) are done before the packet is passed to non generic functions. <HR><H3>Function</H3> int lsa_validate (struct ospf_lsa_header * lsa, u32 lsa_type, int ospf2, void * body) -- check whether given LSA is valid  <H3>Arguments</H3>  <DL> <DT>struct ospf_lsa_header * lsa<DD>LSA header <DT>u32 lsa_type<DD>one of LSA_T_xxx <DT>int ospf2<DD>true means OSPF version 2, false means OSPF version 3 <DT>void * body<DD>pointer to LSA body </DL> <H3>Description</H3> Checks internal structure of given LSA body (minimal length, consistency). Returns true if valid. <HR><H3>Function</H3> void ospf_send_dbdes (struct ospf_proto * p, struct ospf_neighbor * n) -- transmit database description packet  <H3>Arguments</H3>  <DL> <DT>struct ospf_proto * p<DD>OSPF protocol instance <DT>struct ospf_neighbor * n<DD>neighbor </DL> <H3>Description</H3> Sending of a database description packet is described in 10.8 of RFC 2328. Reception of each packet is acknowledged in the sequence number of another. When I send a packet to a neighbor I keep a copy in a buffer. If the neighbor does not reply, I don't create a new packet but just send the content of the buffer. <HR><H3>Function</H3> void ospf_rt_spf (struct ospf_proto * p) -- calculate internal routes  <H3>Arguments</H3>  <DL> <DT>struct ospf_proto * p<DD>OSPF protocol instance </DL> <H3>Description</H3> Calculation of internal paths in an area is described in 16.1 of RFC 2328. It's based on Dijkstra's shortest path tree algorithms. This function is invoked from ospf_disp(). <H2><A NAME="ss5.6">5.6</A> <A HREF="prog.html#toc5.6">Pipe</A> </H2>  The Pipe protocol is very simple. It just connects to two routing tables using proto_add_announce_hook() and whenever it receives a rt_notify() about a change in one of the tables, it converts it to a rte_update() in the other one. To avoid pipe loops, Pipe keeps a `being updated' flag in each routing table. A pipe has two announce hooks, the first connected to the main table, the second connected to the peer table. When a new route is announced on the main table, it gets checked by an export filter in ahook 1, and, after that, it is announced to the peer table via rte_update(), an import filter in ahook 2 is called. When a new route is announced in the peer table, an export filter in ahook2 and an import filter in ahook 1 are used. Oviously, there is no need in filtering the same route twice, so both import filters are set to accept, while user configured 'import' and 'export' filters are used as export filters in ahooks 2 and 1. Route limits are handled similarly, but on the import side of ahooks.   <H2><A NAME="ss5.7">5.7</A> <A HREF="prog.html#toc5.7">Routing Information Protocol (RIP)</A> </H2>  The RIP protocol is implemented in two files: <CODE>rip.c</CODE> containing the protocol logic, route management and the protocol glue with BIRD core, and <CODE>packets.c</CODE> handling RIP packet processing, RX, TX and protocol sockets. Each instance of RIP is described by a structure rip_proto, which contains an internal RIP routing table, a list of protocol interfaces and the main timer responsible for RIP routing table cleanup. RIP internal routing table contains incoming and outgoing routes. For each network (represented by structure rip_entry) there is one outgoing route stored directly in rip_entry and an one-way linked list of incoming routes (structures rip_rte). The list contains incoming routes from different RIP neighbors, but only routes with the lowest metric are stored (i.e., all stored incoming routes have the same metric). Note that RIP itself does not select outgoing route, that is done by the core routing table. When a new incoming route is received, it is propagated to the RIP table by rip_update_rte() and possibly stored in the list of incoming routes. Then the change may be propagated to the core by rip_announce_rte(). The core selects the best route and propagate it to RIP by rip_rt_notify(), which updates outgoing route part of rip_entry and possibly triggers route propagation by rip_trigger_update(). RIP interfaces are represented by structures rip_iface. A RIP interface contains a per-interface socket, a list of associated neighbors, interface configuration, and state information related to scheduled interface events and running update sessions. RIP interfaces are added and removed based on core interface notifications. There are two RIP interface events - regular updates and triggered updates. Both are managed from the RIP interface timer (rip_iface_timer()). Regular updates are called at fixed interval and propagate the whole routing table, while triggered updates are scheduled by rip_trigger_update() due to some routing table change and propagate only the routes modified since the time they were scheduled. There are also unicast-destined requested updates, but these are sent directly as a reaction to received RIP request message. The update session is started by rip_send_table(). There may be at most one active update session per interface, as the associated state (including the fib iterator) is stored directly in rip_iface structure. RIP neighbors are represented by structures rip_neighbor. Compared to neighbor handling in other routing protocols, RIP does not have explicit neighbor discovery and adjacency maintenance, which makes the rip_neighbor related code a bit peculiar. RIP neighbors are interlinked with core neighbor structures (neighbor) and use core neighbor notifications to ensure that RIP neighbors are timely removed. RIP neighbors are added based on received route notifications and removed based on core neighbor and RIP interface events. RIP neighbors are linked by RIP routes and use counter to track the number of associated routes, but when these RIP routes timeout, associated RIP neighbor is still alive (with zero counter). When RIP neighbor is removed but still has some associated routes, it is not freed, just changed to detached state (core neighbors and RIP ifaces are unlinked), then during the main timer cleanup phase the associated routes are removed and the rip_neighbor structure is finally freed. Supported standards: - RFC 1058 - RIPv1 - RFC 2453 - RIPv2 - RFC 2080 - RIPng - RFC 4822 - RIP cryptographic authentication  <HR><H3>Function</H3> void rip_announce_rte (struct rip_proto * p, struct rip_entry * en) -- announce route from RIP routing table to the core  <H3>Arguments</H3>  <DL> <DT>struct rip_proto * p<DD>RIP instance <DT>struct rip_entry * en<DD>related network </DL> <H3>Description</H3> The function takes a list of incoming routes from en, prepare appropriate rte for the core and propagate it by rte_update(). <HR><H3>Function</H3> void rip_update_rte (struct rip_proto * p, ip_addr * prefix, int pxlen, struct rip_rte * new) -- enter a route update to RIP routing table  <H3>Arguments</H3>  <DL> <DT>struct rip_proto * p<DD>RIP instance <DT>ip_addr * prefix<DD>network prefix <DT>int pxlen<DD>network prefix length <DT>struct rip_rte * new<DD>a rip_rte representing the new route </DL> <H3>Description</H3> The function is called by the RIP packet processing code whenever it receives a reachable route. The appropriate routing table entry is found and the list of incoming routes is updated. Eventually, the change is also propagated to the core by rip_announce_rte(). Note that for unreachable routes, rip_withdraw_rte() should be called instead of rip_update_rte(). <HR><H3>Function</H3> void rip_withdraw_rte (struct rip_proto * p, ip_addr * prefix, int pxlen, struct rip_neighbor * from) -- enter a route withdraw to RIP routing table  <H3>Arguments</H3>  <DL> <DT>struct rip_proto * p<DD>RIP instance <DT>ip_addr * prefix<DD>network prefix <DT>int pxlen<DD>network prefix length <DT>struct rip_neighbor * from<DD>a rip_neighbor propagating the withdraw </DL> <H3>Description</H3> The function is called by the RIP packet processing code whenever it receives an unreachable route. The incoming route for given network from nbr from is removed. Eventually, the change is also propagated by rip_announce_rte(). <HR><H3>Function</H3> void rip_timer (timer * t) -- RIP main timer hook  <H3>Arguments</H3>  <DL> <DT>timer * t<DD>timer </DL> <H3>Description</H3> The RIP main timer is responsible for routing table maintenance. Invalid or expired routes (rip_rte) are removed and garbage collection of stale routing table entries (rip_entry) is done. Changes are propagated to core tables, route reload is also done here. Note that garbage collection uses a maximal GC time, while interfaces maintain an illusion of per-interface GC times in rip_send_response(). Keeping incoming routes and the selected outgoing route are two independent functions, therefore after garbage collection some entries now considered invalid (RIP_ENTRY_DUMMY) still may have non-empty list of incoming routes, while some valid entries (representing an outgoing route) may have that list empty. The main timer is not scheduled periodically but it uses the time of the current next event and the minimal interval of any possible event to compute the time of the next run. <HR><H3>Function</H3> void rip_iface_timer (timer * t) -- RIP interface timer hook  <H3>Arguments</H3>  <DL> <DT>timer * t<DD>timer </DL> <H3>Description</H3> RIP interface timers are responsible for scheduling both regular and triggered updates. Fixed, delay-independent period is used for regular updates, while minimal separating interval is enforced for triggered updates. The function also ensures that a new update is not started when the old one is still running. <HR><H3>Function</H3> void rip_send_table (struct rip_proto * p, struct rip_iface * ifa, ip_addr addr, bird_clock_t changed) -- RIP interface timer hook  <H3>Arguments</H3>  <DL> <DT>struct rip_proto * p<DD>RIP instance <DT>struct rip_iface * ifa<DD>RIP interface <DT>ip_addr addr<DD>destination IP address <DT>bird_clock_t changed<DD>time limit for triggered updates </DL> <H3>Description</H3> The function activates an update session and starts sending routing update packets (using rip_send_response()). The session may be finished during the call or may continue in rip_tx_hook() until all appropriate routes are transmitted. Note that there may be at most one active update session per interface, the function will terminate the old active session before activating the new one. <H2><A NAME="ss5.8">5.8</A> <A HREF="prog.html#toc5.8">Router Advertisements</A> </H2>  The RAdv protocol is implemented in two files: <CODE>radv.c</CODE> containing the interface with BIRD core and the protocol logic and <CODE>packets.c</CODE> handling low level protocol stuff (RX, TX and packet formats). The protocol does not export any routes. The RAdv is structured in the usual way - for each handled interface there is a structure radv_iface that contains a state related to that interface together with its resources (a socket, a timer). There is also a prepared RA stored in a TX buffer of the socket associated with an iface. These iface structures are created and removed according to iface events from BIRD core handled by radv_if_notify() callback. The main logic of RAdv consists of two functions: radv_iface_notify(), which processes asynchronous events (specified by RA_EV_* codes), and radv_timer(), which triggers sending RAs and computes the next timeout. The RAdv protocol could receive routes (through radv_import_control() and radv_rt_notify()), but only the configured trigger route is tracked (in active var). When a radv protocol is reconfigured, the connected routing table is examined (in radv_check_active()) to have proper active value in case of the specified trigger prefix was changed. Supported standards: - RFC 4861 - main RA standard - RFC 4191 - Default Router Preferences and More-Specific Routes - RFC 6106 - DNS extensions (RDDNS, DNSSL)   <H2><A NAME="ss5.9">5.9</A> <A HREF="prog.html#toc5.9">Static</A> </H2>  The Static protocol is implemented in a straightforward way. It keeps two lists of static routes: one containing interface routes and one holding the remaining ones. Interface routes are inserted and removed according to interface events received from the core via the if_notify() hook. Routes pointing to a neighboring router use a sticky node in the neighbor cache to be notified about gaining or losing the neighbor. Special routes like black holes or rejects are inserted all the time. Multipath routes are tricky. Because these routes depends on several neighbors we need to integrate that to the neighbor notification handling, we use dummy static_route nodes, one for each nexthop. Therefore, a multipath route consists of a master static_route node (of dest RTD_MULTIPATH), which specifies prefix and is used in most circumstances, and a list of dummy static_route nodes (of dest RTD_NONE), which stores info about nexthops and are connected to neighbor entries and neighbor notifications. Dummy nodes are chained using mp_next, they aren't in other_routes list, and abuse some fields (masklen, if_name) for other purposes. The only other thing worth mentioning is that when asked for reconfiguration, Static not only compares the two configurations, but it also calculates difference between the lists of static routes and it just inserts the newly added routes and removes the obsolete ones.   <H2><A NAME="ss5.10">5.10</A> <A HREF="prog.html#toc5.10">Direct</A> </H2>  The Direct protocol works by converting all ifa_notify() events it receives to rte_update() calls for the corresponding network.    <HR> <A HREF="prog-6.html">Next</A> <A HREF="prog-4.html">Previous</A> <A HREF="prog.html#toc5">Contents</A> </BODY> </HTML>