[BACK]Return to bird-2.html CVS log [TXT] [DIR] Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / bird / doc
File:  [ELWIX - Embedded LightWeight unIX -] / embedaddon / bird / doc / bird-2.html
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Tue Aug 22 12:33:54 2017 UTC (6 years, 11 months ago) by misho
Branches: bird, MAIN
CVS tags: v1_6_8p3, v1_6_3p0, v1_6_3, HEAD
bird 1.6.3

    1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
    2: <HTML>
    3: <HEAD>
    4:  <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 1.0.9">
    5:  <TITLE>BIRD User's Guide: About routing tables</TITLE>
    6:  <LINK HREF="bird-3.html" REL=next>
    7:  <LINK HREF="bird-1.html" REL=previous>
    8:  <LINK HREF="bird.html#toc2" REL=contents>
    9: </HEAD>
   10: <BODY>
   11: <A HREF="bird-3.html">Next</A>
   12: <A HREF="bird-1.html">Previous</A>
   13: <A HREF="bird.html#toc2">Contents</A>
   14: <HR>
   15: <H2><A NAME="routing-tables"></A> <A NAME="s2">2.</A> <A HREF="bird.html#toc2">About routing tables</A></H2>
   16: 
   17: <P>BIRD has one or more routing tables which may or may not be synchronized with
   18: OS kernel and which may or may not be synchronized with each other (see the Pipe
   19: protocol). Each routing table contains a list of known routes. Each route
   20: consists of:
   21: <P>
   22: <UL>
   23: <LI>network prefix this route is for (network address and prefix
   24: length -- the number of bits forming the network part of the
   25: address; also known as a netmask)</LI>
   26: <LI>preference of this route</LI>
   27: <LI>IP address of router which told us about this route</LI>
   28: <LI>IP address of router we should forward the packets to using this
   29: route</LI>
   30: <LI>other attributes common to all routes</LI>
   31: <LI>dynamic attributes defined by protocols which may or may not be
   32: present (typically protocol metrics)</LI>
   33: </UL>
   34: <P>Routing table maintains multiple entries for a network, but at most one entry
   35: for one network and one protocol. The entry with the highest preference is used
   36: for routing (we will call such an entry the <I>selected route</I>). If there are
   37: more entries with the same preference and they are from the same protocol, the
   38: protocol decides (typically according to metrics). If they aren't, an internal
   39: ordering is used to break the tie. You can get the list of route attributes in
   40: the Route attributes section.
   41: <P>
   42: <P>Each protocol is connected to a routing table through two filters which can
   43: accept, reject and modify the routes. An <I>export</I> filter checks routes passed
   44: from the routing table to the protocol, an <I>import</I> filter checks routes in
   45: the opposite direction. When the routing table gets a route from a protocol, it
   46: recalculates the selected route and broadcasts it to all protocols connected to
   47: the table. The protocols typically send the update to other routers in the
   48: network. Note that although most protocols are interested in receiving just
   49: selected routes, some protocols (e.g. the <CODE>Pipe</CODE> protocol) receive and
   50: process all entries in routing tables (accepted by filters).
   51: <P>
   52: <P>
   53: <A NAME="dsc-table-sorted"></A> Usually, a routing table just chooses a selected route
   54: from a list of entries for one network. But if the <CODE>sorted</CODE> option is
   55: activated, these lists of entries are kept completely sorted (according to
   56: preference or some protocol-dependent metric). This is needed for some features
   57: of some protocols (e.g. <CODE>secondary</CODE> option of BGP protocol, which allows to
   58: accept not just a selected route, but the first route (in the sorted list) that
   59: is accepted by filters), but it is incompatible with some other features (e.g.
   60: <CODE>deterministic med</CODE> option of BGP protocol, which activates a way of choosing
   61: selected route that cannot be described using comparison and ordering). Minor
   62: advantage is that routes are shown sorted in <CODE>show route</CODE>, minor disadvantage
   63: is that it is slightly more computationally expensive.
   64: <P>
   65: <P>
   66: <H2><A NAME="graceful-restart"></A> <A NAME="ss2.1">2.1</A> <A HREF="bird.html#toc2.1">Graceful restart</A>
   67: </H2>
   68: 
   69: <P>When BIRD is started after restart or crash, it repopulates routing tables in
   70: an uncoordinated manner, like after clean start. This may be impractical in some
   71: cases, because if the forwarding plane (i.e. kernel routing tables) remains
   72: intact, then its synchronization with BIRD would temporarily disrupt packet
   73: forwarding until protocols converge. Graceful restart is a mechanism that could
   74: help with this issue. Generally, it works by starting protocols and letting them
   75: repopulate routing tables while deferring route propagation until protocols
   76: acknowledge their convergence. Note that graceful restart behavior have to be
   77: configured for all relevant protocols and requires protocol-specific support
   78: (currently implemented for Kernel and BGP protocols), it is activated for
   79: particular boot by option <CODE>-R</CODE>.
   80: <P>
   81: <P>
   82: <HR>
   83: <A HREF="bird-3.html">Next</A>
   84: <A HREF="bird-1.html">Previous</A>
   85: <A HREF="bird.html#toc2">Contents</A>
   86: </BODY>
   87: </HTML>
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>