Annotation of embedaddon/bird/doc/bird-2.html, revision 1.1.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