BGP instance +
BGP instance (or NULL)
buffer
a list of extended attributes
remaining space in the buffer @@ -755,10 +755,40 @@ and converts it to its BGP representation (a part of a its consistency and converts it to a list of BIRD route attributes represented by a rta. -
+
The MRT protocol is implemented in just one file: mrt.c. 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 +
+
+
The OSPF protocol is quite complicated and its complex implemenation is split
to many files. In ospf.c, you will find mainly the interface for
communication with the core (e.g., reconfiguration hooks, shutdown and
@@ -1216,7 +1246,7 @@ of the buffer.
It's based on Dijkstra's shortest path tree algorithms.
This function is invoked from ospf_disp().
-
@@ -1239,7 +1269,7 @@ are used as export filters in ahooks 2 and 1. Route li handled similarly, but on the import side of ahooks.
-
@@ -1419,38 +1449,35 @@ transmitted. Note that there may be at most one active interface, the function will terminate the old active session before activating the new one. -
-
The RAdv protocol is implemented in two files: radv.c containing
-the interface with BIRD core and the protocol logic and packets.c
-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. +
The RAdv protocol is implemented in two files: radv.c containing the
+interface with BIRD core and the protocol logic and packets.c 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) -- RFC 4191 (partial) - Default Router Preference
-
@@ -1477,7 +1504,7 @@ difference between the lists of static routes and it j newly added routes and removes the obsolete ones.
-