Annotation of embedaddon/bird/doc/bird-2.html, revision 1.1
1.1 ! misho 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>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to bird-2.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