|
version 1.1.1.1, 2017/08/22 12:33:54
|
version 1.1.1.2, 2021/03/17 19:50:23
|
|
Line 724 checks their headers and framing and passes complete p
|
Line 724 checks their headers and framing and passes complete p
|
| <H3>Arguments</H3> |
<H3>Arguments</H3> |
| <P> |
<P> |
| <DL> |
<DL> |
| <DT><I>struct bgp_proto *</I> <B>p</B><DD><P>BGP instance | <DT><I>struct bgp_proto *</I> <B>p</B><DD><P>BGP instance (or NULL) |
| <DT><I>byte *</I> <B>w</B><DD><P>buffer |
<DT><I>byte *</I> <B>w</B><DD><P>buffer |
| <DT><I>ea_list *</I> <B>attrs</B><DD><P>a list of extended attributes |
<DT><I>ea_list *</I> <B>attrs</B><DD><P>a list of extended attributes |
| <DT><I>int</I> <B>remains</B><DD><P>remaining space in the buffer |
<DT><I>int</I> <B>remains</B><DD><P>remaining space in the buffer |
|
Line 755 and converts it to its BGP representation (a part of a
|
Line 755 and converts it to its BGP representation (a part of a
|
| its consistency and converts it to a list of BIRD route attributes represented |
its consistency and converts it to a list of BIRD route attributes represented |
| by a <I>rta</I>. |
by a <I>rta</I>. |
| |
|
| <H2><A NAME="ss5.4">5.4</A> <A HREF="prog.html#toc5.4">Open Shortest Path First (OSPF)</A> | <H2><A NAME="ss5.4">5.4</A> <A HREF="prog.html#toc5.4">Multi-Threaded Routing Toolkit (MRT) protocol</A> |
| </H2> |
</H2> |
| |
|
| <P> |
<P> |
| |
<P>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. |
| |
<P>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 (<B>peer_hash</B>) to find peer index based on BGP protocol key |
| |
attributes. |
| |
<P>One thing worth documenting is the locking. During processing, the currently |
| |
processed table (<B>table</B> field in the state structure) is locked and also the |
| |
explicitly named table is locked (<B>table_ptr</B> field in the state structure) if |
| |
specified. Between dumps no table is locked. Also the current config is |
| |
locked (by <B>config_add_obstacle()</B>) during table dumps as some data (strings, |
| |
filters) are shared from the config and the running table dump may be |
| |
interrupted by reconfiguration. |
| |
<P>Supported standards: |
| |
- RFC 6396 - MRT format standard |
| |
- RFC 8050 - ADD_PATH extension |
| |
<P> |
| |
<P> |
| |
<H2><A NAME="ss5.5">5.5</A> <A HREF="prog.html#toc5.5">Open Shortest Path First (OSPF)</A> |
| |
</H2> |
| |
|
| |
<P> |
| <P>The OSPF protocol is quite complicated and its complex implemenation is split |
<P>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 |
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 |
communication with the core (e.g., reconfiguration hooks, shutdown and |
|
Line 1216 of the buffer.
|
Line 1246 of the buffer.
|
| It's based on Dijkstra's shortest path tree algorithms. |
It's based on Dijkstra's shortest path tree algorithms. |
| This function is invoked from <B>ospf_disp()</B>. |
This function is invoked from <B>ospf_disp()</B>. |
| |
|
| <H2><A NAME="ss5.5">5.5</A> <A HREF="prog.html#toc5.5">Pipe</A> | <H2><A NAME="ss5.6">5.6</A> <A HREF="prog.html#toc5.6">Pipe</A> |
| </H2> |
</H2> |
| |
|
| <P> |
<P> |
|
Line 1239 are used as export filters in ahooks 2 and 1. Route li
|
Line 1269 are used as export filters in ahooks 2 and 1. Route li
|
| handled similarly, but on the import side of ahooks. |
handled similarly, but on the import side of ahooks. |
| <P> |
<P> |
| <P> |
<P> |
| <H2><A NAME="ss5.6">5.6</A> <A HREF="prog.html#toc5.6">Routing Information Protocol (RIP)</A> | <H2><A NAME="ss5.7">5.7</A> <A HREF="prog.html#toc5.7">Routing Information Protocol (RIP)</A> |
| </H2> |
</H2> |
| |
|
| <P> |
<P> |
|
Line 1419 transmitted. Note that there may be at most one active
|
Line 1449 transmitted. Note that there may be at most one active
|
| interface, the function will terminate the old active session before |
interface, the function will terminate the old active session before |
| activating the new one. |
activating the new one. |
| |
|
| <H2><A NAME="ss5.7">5.7</A> <A HREF="prog.html#toc5.7">Router Advertisements</A> | <H2><A NAME="ss5.8">5.8</A> <A HREF="prog.html#toc5.8">Router Advertisements</A> |
| </H2> |
</H2> |
| |
|
| <P> |
<P> |
| <P>The RAdv protocol is implemented in two files: <CODE>radv.c</CODE> containing | <P>The RAdv protocol is implemented in two files: <CODE>radv.c</CODE> containing the |
| the interface with BIRD core and the protocol logic and <CODE>packets.c</CODE> | interface with BIRD core and the protocol logic and <CODE>packets.c</CODE> handling low |
| handling low level protocol stuff (RX, TX and packet formats). | level protocol stuff (RX, TX and packet formats). The protocol does not |
| The protocol does not export any routes. | export any routes. |
| <P>The RAdv is structured in the usual way - for each handled interface | <P>The RAdv is structured in the usual way - for each handled interface there is |
| there is a structure <I>radv_iface</I> that contains a state related to | a structure <I>radv_iface</I> that contains a state related to that interface |
| that interface together with its resources (a socket, a timer). | together with its resources (a socket, a timer). There is also a prepared RA |
| There is also a prepared RA stored in a TX buffer of the socket | stored in a TX buffer of the socket associated with an iface. These iface |
| associated with an iface. These iface structures are created | structures are created and removed according to iface events from BIRD core |
| and removed according to iface events from BIRD core handled by | handled by <B>radv_if_notify()</B> callback. |
| <B>radv_if_notify()</B> callback. | <P>The main logic of RAdv consists of two functions: <B>radv_iface_notify()</B>, which |
| <P>The main logic of RAdv consists of two functions: | processes asynchronous events (specified by RA_EV_* codes), and <B>radv_timer()</B>, |
| <B>radv_iface_notify()</B>, which processes asynchronous events (specified | which triggers sending RAs and computes the next timeout. |
| by RA_EV_* codes), and <B>radv_timer()</B>, which triggers sending RAs and | <P>The RAdv protocol could receive routes (through <B>radv_import_control()</B> and |
| computes the next timeout. | <B>radv_rt_notify()</B>), but only the configured trigger route is tracked (in |
| <P>The RAdv protocol could receive routes (through | <I>active</I> var). When a radv protocol is reconfigured, the connected routing |
| <B>radv_import_control()</B> and <B>radv_rt_notify()</B>), but only the | table is examined (in <B>radv_check_active()</B>) to have proper <I>active</I> value in |
| configured trigger route is tracked (in <I>active</I> var). When a radv | case of the specified trigger prefix was changed. |
| protocol is reconfigured, the connected routing table is examined | |
| (in <B>radv_check_active()</B>) to have proper <I>active</I> value in case of | |
| the specified trigger prefix was changed. | |
| <P>Supported standards: |
<P>Supported standards: |
| - RFC 4861 - main RA standard |
- RFC 4861 - main RA standard |
| |
- RFC 4191 - Default Router Preferences and More-Specific Routes |
| - RFC 6106 - DNS extensions (RDDNS, DNSSL) |
- RFC 6106 - DNS extensions (RDDNS, DNSSL) |
| - RFC 4191 (partial) - Default Router Preference |
|
| <P> |
<P> |
| <P> |
<P> |
| <H2><A NAME="ss5.8">5.8</A> <A HREF="prog.html#toc5.8">Static</A> | <H2><A NAME="ss5.9">5.9</A> <A HREF="prog.html#toc5.9">Static</A> |
| </H2> |
</H2> |
| |
|
| <P> |
<P> |
|
Line 1477 difference between the lists of static routes and it j
|
Line 1504 difference between the lists of static routes and it j
|
| newly added routes and removes the obsolete ones. |
newly added routes and removes the obsolete ones. |
| <P> |
<P> |
| <P> |
<P> |
| <H2><A NAME="ss5.9">5.9</A> <A HREF="prog.html#toc5.9">Direct</A> | <H2><A NAME="ss5.10">5.10</A> <A HREF="prog.html#toc5.10">Direct</A> |
| </H2> |
</H2> |
| |
|
| <P> |
<P> |
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to prog-5.html CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / bird / doc