1142 lines
48 KiB
Text
1142 lines
48 KiB
Text
<!doctype birddoc system>
|
|
|
|
<!--
|
|
BIRD documentation
|
|
|
|
This is slightly modified linuxdoc dtd. Anything in <descrip> tags is considered definition of
|
|
configuration primitives, <cf> is fragment of configuration within normal text, <m> is
|
|
"meta" information within fragment of configuration - something in config which is not keyword.
|
|
|
|
(set-fill-column 100)
|
|
|
|
Copyright 1999,2000 Pavel Machek <pavel@ucw.cz>, distribute under GPL version 2 or later.
|
|
|
|
-->
|
|
|
|
<article>
|
|
|
|
<title>BIRD User's Guide
|
|
<author>
|
|
Ondrej Filip <it/<feela@network.cz>/,
|
|
Pavel Machek <it/<pavel@ucw.cz>/,
|
|
Martin Mares <it/<mj@ucw.cz>/
|
|
</author>
|
|
|
|
<abstract>
|
|
This document contains user documentation for the BIRD Internet Routing Daemon project.
|
|
</abstract>
|
|
|
|
<!-- Table of contents -->
|
|
<toc>
|
|
|
|
<!-- Begin the document -->
|
|
|
|
<sect>Introduction
|
|
|
|
<sect1>What is BIRD
|
|
|
|
<p><label id="intro">
|
|
The name `BIRD' is actually an acronym standing for `BIRD Internet Routing Daemon'.
|
|
Let's take a closer look at the meaning of the name:
|
|
|
|
<p><em/BIRD/: Well, we think we have already explained that. It's an acronym standing
|
|
for `BIRD Internet Routing Daemon', you remember, don't you? :-)
|
|
|
|
<p><em/Internet Routing/: It's a program (well, a daemon, as you are going to discover in a moment)
|
|
which works as a dynamic router in an Internet type network (that is, in a network running either
|
|
the IPv4 or the IPv6 protocol). Routers are devices which forward packets between interconnected
|
|
networks in order to allow hosts not connected directly to the same local area network to
|
|
communicate with each other. They also communicate with other routers in the Internet to discover
|
|
the topology of the network which allows them to find optimal (in terms of some metric) rules for
|
|
forwarding of packets (which will be called routes in the rest of this document) and to adapt to the
|
|
changing conditions such as outages of network links, building of new connections and so on. Most of
|
|
these routers are costly dedicated devices running obscure firmware which is hard to configure and
|
|
not open to any changes. (But these costly dedicated beasts are a
|
|
requirement for routing of many fast interfaces - PCclass machine can not keep up with more than 4
|
|
100Mbps interfaces) Fortunately, most operating systems of the UNIX family allow an ordinary
|
|
computer to act as a router and forward packets belonging to the other hosts, but only according to
|
|
a statically configured table.
|
|
|
|
<p>A <em/Routing Daemon/ is in UNIX terminology a non-interactive program running on
|
|
background which does the dynamic part of Internet routing, that is it communicates
|
|
with the other routers, calculates routing tables and sends them to the OS kernel
|
|
which does the actual packet forwarding. There are other such routing daemons: routed (rip only), GateD <HTMLURL URL="http://www.gated.org/">
|
|
(non free) and Zebra <HTMLURL URL="http://www.zebra.org">, but their capabilities are limited and
|
|
they are relatively hard to configure and maintain.
|
|
|
|
<p>BIRD is an Internet Routing Daemon designed to avoid all of these shortcomings,
|
|
to support all the routing technology used in the today's Internet or planned to be
|
|
used in near future and to have a clean extensible architecture allowing new routing
|
|
protocols to be incorporated easily. Among other features, BIRD supports:
|
|
|
|
<itemize>
|
|
<item>both IPv4 and IPv6 protocols
|
|
<item>multiple routing tables
|
|
<item>the Border Gateway Protocol (BGPv4)
|
|
<item>the Routing Interchange Protocol (RIPv2)
|
|
<item>the Open Shortest Path First protocol (OSPFv2)
|
|
<item>a virtual protocol for exchange of routes between internal routing tables
|
|
<item>a command-line interface allowing on-line control and inspection
|
|
of status of the daemon
|
|
<item>soft reconfiguration (no need to use complex online commands
|
|
to change the configuration, just edit the configuration file
|
|
and notify BIRD to re-read it and it will smoothly switch
|
|
to the new configuration, not disturbing routing protocols
|
|
unless they are affected by the configuration changes)
|
|
<item>powerful language for route filtering
|
|
</itemize>
|
|
|
|
<p>BIRD has been developed at the Faculty of Math and Physics, Charles University, Prague,
|
|
Czech Republic as a student project. It can be freely distributed under the terms of the GNU General
|
|
Public License.
|
|
|
|
<p>BIRD has been designed to work on all UNIX-like systems. It has been developed and
|
|
tested under Linux 2.0 to 2.3, but porting to other systems (even non-UNIX ones) should
|
|
be relatively easy due to its highly modular architecture.
|
|
|
|
<sect1>About this documentation
|
|
|
|
<p>This documentation can have 4 forms: sgml (this is master copy), html, ASCII text and dvi/postscript (generated from sgml using sgmltools). You should always edit master copy.
|
|
|
|
<sect1>About routing tables
|
|
|
|
<p>Bird has one or more routing tables, which may or may not be
|
|
synchronized with kernel and which may or may not be synchronized with
|
|
each other (see the Pipe protocol). Each routing table contains list of
|
|
known routes. Each route consists of:
|
|
|
|
<itemize>
|
|
<item>network this route is for
|
|
<item>preference of this route (taken from preference of
|
|
protocol and possibly alterred by filters)
|
|
<item>ip address of router who told us about this route
|
|
<item>ip address of router we should use for packets routing
|
|
using this route
|
|
<item>other attributes common to all routes
|
|
<item>dynamic attributes defined by protocols, which may or
|
|
may not be present (typically protocol metric)
|
|
</itemize>
|
|
|
|
Routing table maintains more than
|
|
one entry for network, but at most one entry for one network and one
|
|
protocol. The entry with biggest preference is used for routing. If
|
|
there are more entries with same preference and they are from same
|
|
protocol, protocol decides (typically according to metrics). If not,
|
|
internal ordering is used to decide. You can
|
|
get list of route attributes in "Route attributes" section in
|
|
filters. Filters can alter routes passed between routing tables and
|
|
protocols.
|
|
|
|
<sect1>Installing BIRD
|
|
|
|
<p>On recent UNIX (with GNU-compatible tools - BIRD relies on GCC extensions)
|
|
system, installing BIRD should be as easy as:
|
|
|
|
<code>
|
|
./configure
|
|
make
|
|
make install
|
|
vi /usr/local/etc/bird.conf
|
|
bird
|
|
</code>
|
|
|
|
<p>You can use <tt>./configure --help</tt> to get list of configure
|
|
options. Most important (and not easily guessed) option is
|
|
<tt/--enable-ipv6/, which enables IpV6 support.
|
|
|
|
<p>You can pass several command-line options to bird:
|
|
|
|
<descrip>
|
|
<tag>-c <m/config name/</tag>
|
|
use given config file instead of <file>bird.conf</file>.
|
|
|
|
<tag>-d</tag>
|
|
enable debugging.
|
|
|
|
<tag>-D <m/filename for debug log/</tag>
|
|
log debugging information to given file.
|
|
|
|
<tag>-s <m/name of communication socket/</tag>
|
|
use given filename for socket for communications with bird client, default is <file/bird.ctl/.
|
|
</descrip>
|
|
|
|
<sect>Configuration
|
|
|
|
<sect1>Introduction
|
|
|
|
<p>BIRD is configured using text configuration file. At startup, BIRD reads <file/bird.conf/ (unless
|
|
<tt/-c/ command line option is given). Configuration may be changed on user request: if you modify
|
|
config file and then signal BIRD with SIGHUP, it will adjust to new
|
|
config. Then there's BIRD client,
|
|
which allows you to talk with BIRD in more extensive way than just telling it to reconfigure. BIRD
|
|
writes messages about its work to log files or syslog (according to config).
|
|
|
|
<p>In config, everything on a line after <cf/#/ or inside <cf>/*
|
|
*/</cf> is a comment, whitespace is ignored, C-style comments <cf>/* comment */</cf> are also
|
|
recognized. If there's variable number of options, they are grouped using
|
|
<cf/{ }/ brackets. Each option is terminated by <cf/;/. Configuration
|
|
is case sensitive.
|
|
|
|
<p>Really simple configuration file might look like this: It enables
|
|
synchronization of routing tables with kernel, scans for
|
|
new network interfaces every 10 seconds and runs RIP on all interfaces found.
|
|
|
|
|
|
<code>
|
|
protocol kernel {
|
|
persist; # Don't remove routes on BIRD shutdown
|
|
scan time 20; # Scan kernel routing table every 20 seconds
|
|
export all; # Default is export none
|
|
}
|
|
|
|
protocol device {
|
|
scan time 10; # Scan interfaces every 10 seconds
|
|
}
|
|
|
|
protocol rip {
|
|
export all;
|
|
import all;
|
|
}
|
|
</code>
|
|
|
|
|
|
<sect1>Global options
|
|
|
|
<p><descrip>
|
|
<tag>log "<m/filename/"|syslog|stderr all|{ <m/list of classes/ }</tag>
|
|
set logging of classes (either all or <cf/{
|
|
error, trace }/ etc.) into selected destination. Classes are:
|
|
<cf/info/, <cf/warning/, <cf/error/, <cf/fatal/ for messages about local problems
|
|
<cf/debug/ for debugging messages,
|
|
<cf/trace/ when you want to know what happens on network,
|
|
<cf/remote/ for messages about misbehavior of remote side,
|
|
<cf/auth/ about authentication failures,
|
|
<cf/bug/ for internal bugs
|
|
of BIRD. You may specify more than one <cf/log/ line to log to multiple
|
|
destinations.
|
|
|
|
<tag>debug protocols all|off|{ states, routes, filters, interfaces, events, packets }</tag>
|
|
sets global default of protocol debugging options.
|
|
|
|
<tag>filter <m/name local variables/{ <m/commands/ }</tag> define filter. You can learn more about filters
|
|
in next chapter.
|
|
|
|
<tag>function <m/name (parameters) local variables/ { <m/commands/ }</tag> define function. You can learn more
|
|
about functions
|
|
in next chapter.
|
|
|
|
<tag>protocol rip|ospf|bgp|... <m/[name]/ { <m>protocol options</m> }</tag> define protocol
|
|
instance, called name (or called something like rip5 if you omit name). You can learn more
|
|
about configuring protocols in their own chapters. You can run more than one instance of
|
|
most protocols (like rip or bgp).
|
|
|
|
<tag>define constant = (<m/expression/)|<m/number/</tag> define constant. You can use it later in every place
|
|
you could use simple integer.
|
|
|
|
<tag>router id <m/IPv4 address/</tag> set router id. Router id needs to be world-wide
|
|
unique. It is usually one of router's IPv4 addresses.
|
|
|
|
<tag>table <m/name/</tag> create new routing table. Default
|
|
routing table is created implicitly, other routing tables have
|
|
to be added by this command.
|
|
|
|
<tag>eval <m/expr/</tag> evaluates given filter expression. It
|
|
is used by us for testing.
|
|
</descrip>
|
|
|
|
<sect1>Protocol options
|
|
|
|
<p>Several options are per-protocol, but all protocols support them. They are described here.
|
|
|
|
<descrip>
|
|
<tag>preference <m/expr/</tag> sets preference of routes generated by this protocol.
|
|
|
|
<tag>disabled</tag> disables given protocol. You can disable/enable protocol from command
|
|
line interface without needing to touch config. Disabled protocol is not activated.
|
|
|
|
<tag>debug <m/setting/</tag> this is similar to global debug setting, except that it only
|
|
affects one protocol. Only messages in selected debugging categories will be written to
|
|
logs.
|
|
|
|
<tag>import <m/filter/</tag> filter can be either either <cf> { <m>filter commands</m>
|
|
}</cf> or <cf>filter <m/name/</cf> or <cf/all/ or <cf/none/. Import filter works in direction from protocol to main
|
|
routing table. All is shorthand for <cf/{ accept; }/ and none is shorthand for <cf/{ reject; }/.
|
|
|
|
<tag>export <m/filter/</tag> This is similar to <cf>export</cf> keyword, except that it
|
|
works in direction from main routing table to protocol.
|
|
|
|
<tag>table <m/name/</tag> Connect this protocol to non-default table.
|
|
</descrip>
|
|
|
|
<p>There are per-protocol options that give sense only with certain protocols.
|
|
|
|
<descrip>
|
|
<tag>passwords { password "<m/password/" from <m/time/ to <m/time/ passive <m/time/ id
|
|
<m/num/ [...] }</tag> specifies passwords to be used with this protocol. Passive time is
|
|
time from which password is not announced, but is recognized on reception. id is password id, as needed by
|
|
certain protocols.
|
|
|
|
<tag>interface "<m/mask/"|<m/prefix/ [ { <m/option/ ; [ ... ] } ]</tag> specifies, which
|
|
interfaces this protocol is active at, and allows you to set options on
|
|
interface-by-interface basis. Mask is specified in shell-like patters, thus <cf>interface
|
|
"*" { mode broadcast; };</cf> will start given protocol on all interfaces, with <cf>mode
|
|
broadcast;</cf> option. If first character of mask is <cf/-/, such interfaces are
|
|
excluded. Masks are parsed left-to-right, thus <cf/interface "-eth0", "*";/ means all but
|
|
ethernets.
|
|
|
|
</descrip>
|
|
|
|
<sect1>Client
|
|
|
|
<p>You can use command-line client <file>birdc</file> to talk with
|
|
running BIRD. Communications is done using <file/bird.ctl/ unix domain
|
|
socket (unless changed with <tt/-s/ option given to both server and
|
|
client). Client can do simple actions such as enabling/disabling
|
|
protocols, telling BIRD to show various information, telling it to
|
|
show routing table filtered by any filter, or telling bird to
|
|
reconfigure. Press <tt/?/ at any time to get online help. Option
|
|
<tt/-v/ can be passed to client, telling it to dump numeric return
|
|
codes. You do not neccessarily need to use BIRDC to talk to BIRD, your
|
|
own application could do that, too -- format of communication between
|
|
BIRD and BIRDC is stable (see programmer's documenation).
|
|
|
|
|
|
<sect>Filters
|
|
|
|
<sect1>Introduction
|
|
|
|
<p>BIRD contains rather simple programming language. (No, it can not yet read mail :-). There are
|
|
two objects in this language: filters and functions. Filters are called by BIRD core when route is
|
|
being passed between protocol and main routing table, and filters may call functions. Functions may
|
|
call other functions, but recursion is not allowed. Filter language contains control structures such
|
|
as if's and switches, but it allows no loops. Filters are
|
|
interpreted. Filter using many features can be found in <file>filter/test.conf</file>.
|
|
|
|
<p>Filter basically gets the route, looks at its attributes and
|
|
modifies some of them if it wishes. At the end, it decides, whether to
|
|
pass change route through (using <cf/accept/), or whether to <cf/reject/ given route. Simple filter looks
|
|
like this:
|
|
|
|
<code>
|
|
filter not_too_far
|
|
int var;
|
|
{
|
|
if defined( rip_metric ) then
|
|
var = rip_metric;
|
|
else {
|
|
var = 1;
|
|
rip_metric = 1;
|
|
}
|
|
if rip_metric > 10 then
|
|
reject "RIP metric is too big";
|
|
else
|
|
accept "ok";
|
|
}
|
|
</code>
|
|
|
|
<p>As you can see, filter has a header, list of local variables, and body. Header consists of
|
|
<cf/filter/ keyword, followed by (unique) name of filter. List of local variables consists of
|
|
pairs <cf><M>type name</M>;</cf>, where each pair defines one local variable. Body consists of
|
|
<cf> { <M>statements</M> }</cf>. Each Statement is terminated by <cf/;/. You can group
|
|
several statements into one by <cf>{ <M>statements</M> }</cf> construction, that is useful if
|
|
you want to make bigger block of code conditional.
|
|
|
|
<p>Bird supports functions, so that you don't have to repeat same blocks of code over and
|
|
over. Functions can have zero or more parameters, and can have local variables. They
|
|
look like this:
|
|
|
|
<code>
|
|
function name ()
|
|
int local_variable;
|
|
{
|
|
local_variable = 5;
|
|
}
|
|
|
|
function with_parameters (int parameter)
|
|
{
|
|
print parameter;
|
|
}
|
|
</code>
|
|
|
|
<p>Unlike C, variables are declared after function line but before first {. You can not declare
|
|
variables in nested blocks. Functions are called like in C: <cf>name();
|
|
with_parameters(5);</cf>. Function may return value using <cf>return <m/[expr]/</cf>
|
|
syntax. Returning value exits from current function (this is similar to C).
|
|
|
|
<p>Filters are declared in similar way to functions, except they can not have explicit
|
|
parameters. They get route table entry as implicit parameter. Route table entry is passed implicitly
|
|
to any functions being called. Filter must terminate with either
|
|
<cf/accept/ or <cf/reject/ statement. If there's runtime error in filter, route
|
|
is rejected.
|
|
|
|
<p>Nice trick to debug filters is using <cf>show route filter
|
|
<m/name/</cf> from command line client. Example session might look
|
|
like:
|
|
|
|
<code>
|
|
pavel@bug:~/bird$ ./birdc -s bird.ctl
|
|
BIRD 0.0.0 ready.
|
|
bird> help
|
|
No such command.
|
|
bird>
|
|
bird> show route
|
|
10.0.0.0/8 dev eth0 [direct1 23:21] (240)
|
|
195.113.30.2/32 dev tunl1 [direct1 23:21] (240)
|
|
127.0.0.0/8 dev lo [direct1 23:21] (240)
|
|
bird> show route ?
|
|
show route [<prefix>] [table <t>] [filter <f>] [all] [primary] [(import|protocol) <p>] [stats] Show routing table
|
|
bird> show route filter { if 127.0.0.5 ~ net then accept; }
|
|
127.0.0.0/8 dev lo [direct1 23:21] (240)
|
|
bird>
|
|
</code>
|
|
|
|
<sect1>Data types
|
|
|
|
<p>Each variable and each value has certain type. Unlike C, booleans, integers and enums are
|
|
incompatible with each other (that is to prevent you from shooting in the foot).
|
|
|
|
<descrip>
|
|
<tag/bool/ this is boolean type, it can have only two values, <cf/true/ and
|
|
<cf/false/. Boolean is not compatible with integer and is the only type you can use in if
|
|
statements.
|
|
|
|
<tag/int/ this is common integer, you can expect it to store signed values from -2000000000
|
|
to +2000000000. Overflows are not checked.
|
|
|
|
<tag/pair/ this is pair of two short integers. Each component can have values from 0 to
|
|
65535. Constant of this type is written as <cf/(1234,5678)/.
|
|
|
|
<tag/string/ this is string of characters. There are no ways to modify strings in
|
|
filters. You can pass them between functions, assign to variable of type string, print
|
|
such variables, but you can not concatenate two strings (for example). String constants
|
|
are written as <cf/"This is a string constant"/.
|
|
|
|
<tag/ip/ this type can hold single ip address. Depending on compile-time configuration of BIRD you are using, it
|
|
can be IPv4 or IPv6 address. IPv4 addresses are written (as you would expect) as
|
|
<cf/1.2.3.4/. You can apply special operator <cf>.mask(<M>num</M>)</cf>
|
|
on values of type ip. It masks out all but first <cf><M>num</M></cf> bits from ip
|
|
address. So <cf/1.2.3.4.mask(8) = 1.0.0.0/ is true.
|
|
|
|
<tag/prefix/ this type can hold ip address and prefix length. Prefixes are written as
|
|
<cf><M>ipaddress</M>/<M>pxlen</M></cf>, or
|
|
<cf><m>ipaddress</m>/<m>netmask</m></cf> There are two special
|
|
operators on prefix:
|
|
<cf/.ip/, which separates ip address from the pair, and <cf/.len/, which separates prefix
|
|
len from the pair. So <cf>1.2.0.0/16.pxlen = 16</cf> is true.
|
|
|
|
<tag/int|ip|prefix|pair|enum set/
|
|
filters know four types of sets. Sets are similar to strings: you can pass them around
|
|
but you can not modify them. Constant of type <cf>set int</cf> looks like <cf>
|
|
[ 1, 2, 5..7 ]</cf>. As you can see, both simple values and ranges are permitted in
|
|
sets. Sets of prefixes are special: you can specify which prefix lengths should match them by
|
|
using <cf>[ 1.0.0.0/8+, 2.0.0.0/8-, 3.0.0.0/8{5,6} ]</cf>. 3.0.0.0/8{5,6} matches
|
|
prefixes 3.X.X.X, whose prefix length is 5 to 6. 3.0.0.0/8+ is shorthand for 3.0.0.0/{0,8},
|
|
3.0.0.0/8- is shorthand for 3.0.0.0/{0,7}. For example,
|
|
<tt>1.2.0.0/16 ~ [ 1.0.0.0/8{ 15 , 17 } ]</tt> is true, but
|
|
<tt>1.0.0.0/8 ~ [ 1.0.0.0/8- ]</tt> is false.
|
|
|
|
<tag/enum/
|
|
enumeration types are halfway-internal in the BIRD. You can't define your own
|
|
variable of enumeration type, but some route attributes are of enumeration
|
|
type. Enumeration types are incompatible with each other, again, for your
|
|
protection.
|
|
|
|
<tag/bgppath/
|
|
bgp path is list of autonomous systems. You can't write constant of this type.
|
|
|
|
<tag/bgpmask/
|
|
bgp mask is mask used for matching bgp paths
|
|
(using <cf>path ~ / 2 3 5 ? / syntax </cf>). Matching is
|
|
done using shell-like pattern: <cf/?/ means
|
|
"any number of any autonomous systems". Pattern for single
|
|
unknown autonomous system is not supported. (We
|
|
did not want to use * because then it becomes too easy to
|
|
write <cf>/*</cf> which is start of comment.) For example,
|
|
<tt>/ 4 3 2 1 / ~ / ? 4 3 ? /</tt> is true, but
|
|
<tt>/ 4 3 2 1 / ~ / ? 4 5 ? /</tt> is false.
|
|
|
|
<tag/clist/
|
|
community list. This is similar to set of pairs,
|
|
except that unlike other sets, it can be modified.
|
|
You can't write constant of this type.
|
|
|
|
</descrip>
|
|
|
|
<sect1>Operations
|
|
|
|
<p>Filter language supports common integer operations <cf>(+,-,*,/)</cf>, parentheses <cf/(a*(b+c))/, comparison
|
|
<cf/(a=b, a!=b, a<b, a>=b)/. Special operators include <cf/˜/ for "in" operation. In operation can be
|
|
used on element and set of that elements, or on ip and prefix, or on
|
|
prefix and prefix or on bgppath and bgpmask or on pair and clist. Its result
|
|
is true if element is in given set or if ip address is inside given prefix. Operator <cf/=/ is used to assign value
|
|
to variable. Logical operations include unary not (<cf/!/), and (<cf/&&/) and or (<cf/||/>).
|
|
|
|
<sect1>Control structures
|
|
|
|
<p>Filters support two control structures: if/then/else and case. Syntax of if/then/else is <cf>if
|
|
<M>expression</M> then <M>command</M>; else <M>command</M>;</cf> and you can use <cf>{
|
|
<M>command_1</M>; <M>command_2</M>; <M>...</M> }</cf> instead of one or both commands. <cf>else</cf>
|
|
clause may be omitted.
|
|
|
|
<p><cf>case</cf> is similar to case from Pascal. Syntax is <cf>case <m/expr/ { else |
|
|
<m/num_or_prefix [ .. num_or_prefix]/ : <m/statement/ ; [ ... ] }</cf>. Expression after
|
|
<cf>case</cf> can be of any type that can be on the left side of ˜ operator, and anything that could
|
|
be member of set is allowed before <cf/:/. Multiple commands are allowed without <cf/{}/ grouping
|
|
and break is implicit before each case. If argument
|
|
matches neither of <cf/:/ clauses, <cf/else:/ clause is used. (Case is actually implemented as set matching,
|
|
internally.)
|
|
|
|
<p>Here is example that uses if and case structures:
|
|
|
|
<code>
|
|
case arg1 {
|
|
2: print "two"; print "I can do more commands without {}";
|
|
3 .. 5: print "three to five";
|
|
else: print "something else";
|
|
}
|
|
|
|
if 1234 = i then printn "."; else { print "not 1234"; print "You need {} around multiple commands"; }
|
|
</code>
|
|
|
|
<sect1>Route attributes
|
|
|
|
<p>Filter is implicitly passed route, and it can access its
|
|
attributes, just like it accesses variables. Access to undefined
|
|
attribute results in runtime error; you can check if attribute is
|
|
defined using <cf>defined( <m>attribute</m> )</cf> syntax.
|
|
|
|
<descrip>
|
|
<tag><m/prefix/ net</tag>
|
|
network this route is talking about. (See section about routing tables)
|
|
|
|
<tag><m/int/ preference</tag>
|
|
preference of this route. (See section about routing tables)
|
|
|
|
<tag><m/ip/ from</tag>
|
|
who told me about this route.
|
|
|
|
<tag><m/ip/ gw</tag>
|
|
what is next hop packets routed using this route should be forwarded to.
|
|
|
|
<tag><m/enum/ source</tag>
|
|
what protocol told me about this route. This can have values such as <cf/RTS_RIP/ or <cf/RTS_OSPF_EXT/.
|
|
|
|
<tag><m/enum/ scope</tag>
|
|
FIXME!
|
|
|
|
<tag><m/enum/ cast</tag>
|
|
FIXME!
|
|
|
|
<tag><m/enum/ dest</tag>
|
|
FIXME!
|
|
</descrip>
|
|
|
|
<p>Plus, there are protocol-specific attributes, which are described in protocol sections.
|
|
|
|
<sect1>Utility functions
|
|
|
|
<p>There are few functions you might find convenient to use:
|
|
|
|
<descrip>
|
|
<tag>accept</tag> accept this route
|
|
|
|
<tag>reject</tag> reject this route
|
|
|
|
<tag>return <m/expr/</tag> return given value from function, function ends at this point.
|
|
|
|
<tag>print|printn <m/expr/ [ <m/, expr .../ ]</tag>
|
|
prints given expressions, useful mainly while debugging
|
|
filters. Printn variant does not go to new line.
|
|
|
|
<tag>quitbird</tag>
|
|
terminates bird. Useful while debugging filter interpreter.
|
|
</descrip>
|
|
|
|
<sect>Protocols
|
|
|
|
<sect1>BGP
|
|
|
|
<p>The Border Gateway Protocol is the routing protocol used for backbone
|
|
level routing in the today's Internet. Contrary to other protocols, its convergence
|
|
doesn't rely on all routers following the same rules for route selection,
|
|
making it possible to implement any routing policy at any router in the
|
|
network, the only restriction being that if a router advertises a route,
|
|
it must accept and forward packets according to it.
|
|
|
|
<p>BGP works in terms of autonomous systems (often abbreviated as AS). Each
|
|
AS is a part of the network with common management and common routing policy.
|
|
Routers within each AS usually communicate using either a interior routing
|
|
protocol (such as OSPF or RIP) or an interior variant of BGP (called iBGP).
|
|
Boundary routers at the border of the AS communicate with their peers
|
|
in the neighboring AS'es via exterior BGP (eBGP).
|
|
|
|
<p>Each BGP router sends to its neighbors updates of the parts of its
|
|
routing table it wishes to export, along with complete path information
|
|
(a list of AS'es the packet will travel through if it uses that particular
|
|
route) in order to avoid routing loops.
|
|
|
|
<p>BIRD supports all requirements of the BGP4 standard as defined in
|
|
RFC 1771<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1771.txt">
|
|
including several enhancements from the
|
|
latest draft<htmlurl url="ftp://ftp.rfc-editor.org/internet-drafts/draft-ietf-idr-bgp4-09.txt">.
|
|
It also supports the community attributes as per
|
|
RFC 1997<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1997.txt">,
|
|
capability negotiation defined in
|
|
RFC 2842<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2842.txt">,
|
|
For IPv6, it uses the standard multiprotocol extensions defined in
|
|
RFC 2283<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2283.txt">
|
|
including changes described in the
|
|
latest draft <htmlurl url="ftp://ftp.rfc-editor.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-05.txt">
|
|
and applied to IPv6 according to
|
|
RFC 2545<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2545.txt">.
|
|
|
|
<sect2>Route selection rules
|
|
|
|
<p>BGP doesn't have any simple metric, so the rules for selection of an optimal
|
|
route among multiple BGP routes with the same preference are a bit more complex
|
|
and are implemented according to the following algorithm. First it uses the first
|
|
rule, if there are more "best" routes, then it uses the second rule to choose
|
|
among them and so on.
|
|
|
|
<itemize>
|
|
<item>Prefer route with the highest local preference attribute.
|
|
<item>Prefer route with the shortest AS path.
|
|
<item>Prefer IGP origin over EGP and EGP over incomplete.
|
|
<item>Prefer the lowest value of the Multiple Exit Discriminator.
|
|
<item>Prefer internal routes over external routes.
|
|
<item>Prefer route with the lowest value of router ID of the
|
|
advertising router.
|
|
</itemize>
|
|
|
|
<sect2>Configuration
|
|
|
|
<p>Each instance of the BGP corresponds to one neighboring router.
|
|
This allows to set routing policy and all other parameters differently
|
|
for each neighbor using the following protocol parameters:
|
|
|
|
<descrip>
|
|
<tag>local as <m/number/</tag> Define which AS we are part of. (Note that
|
|
contrary to other IP routers, BIRD is able to act as a router located
|
|
in multiple AS'es simultaneously, but in such cases you need to tweak
|
|
the BGP paths manually in the filters to get consistent behavior.)
|
|
This parameter is mandatory.
|
|
<tag>neighbor <m/ip/ as <m/number/</tag> Define neighboring router
|
|
this instance will be talking to and what AS it's located in. Unless
|
|
you use the <cf/multihop/ clause, it must be directly connected to one
|
|
of your router's interfaces. In case the neighbor is in the same AS
|
|
as we are, we automatically switch to iBGP. This parameter is mandatory.
|
|
<tag>multihop <m/number/ via <m/ip/</tag> Configure multihop BGP to a
|
|
neighbor which is connected at most <m/number/ hops far and to which
|
|
we should route via our direct neighbor with address <m/ip/.
|
|
Default: switched off.
|
|
<tag>next hop self</tag> Avoid calculation of the Next Hop attribute
|
|
and always advertise our own source address (see below) as a next hop.
|
|
This needs to be used only
|
|
occasionally to circumvent misconfigurations of other routers.
|
|
Default: disabled.
|
|
<tag>source address <m/ip/</tag> Define local address we should use
|
|
for next hop calculation. Default: the address of the local end
|
|
of the interface our neighbor is connected to.
|
|
<tag>disable after error <m/switch/</tag> When an error is encountered (either
|
|
locally or by the other side), disable the instance automatically
|
|
and wait for an administrator to solve the problem manually. Default: off.
|
|
<tag>hold time <m/number/</tag> Time in seconds to wait for a keepalive
|
|
message from the other side before considering the connection stale.
|
|
Default: depends on agreement with the neighboring router, we prefer
|
|
240 seconds if the other side is willing to accept it.
|
|
<tag>startup hold time <m/number/</tag> Value of the hold timer used
|
|
before the routers have a chance to exchange OPEN messages and agree
|
|
on the real value. Default: 240 seconds.
|
|
<tag>keepalive time <m/number/</tag> Delay in seconds between sending
|
|
of two consecutive keepalive messages. Default: One third of the hold time.
|
|
<tag>connect retry time <m/number/</tag> Time in seconds to wait before
|
|
retrying a failed connect attempt. Default: 120 seconds.
|
|
<tag>start delay time <m/number/</tag> Delay in seconds between protocol
|
|
startup and first attempt to connect. Default: 5 seconds.
|
|
<tag>error wait time <m/number/, <m/number/</tag> Minimum and maximum delay in seconds between protocol
|
|
failure (either local or reported by the peer) and automatic startup.
|
|
Doesn't apply when <cf/disable after error/ is configured. If consecutive
|
|
errors happen, the delay is increased exponentially until it reaches the maximum. Default: 60, 300.
|
|
<tag>error forget time <m/number/</tag> Maximum time in seconds between two protocol
|
|
failures to treat them as a error sequence which makes the <cf/error wait time/
|
|
increase exponentially. Default: 300 seconds.
|
|
<tag>path metric <m/switch/</tag> Enable comparison of path lengths
|
|
when deciding which BGP route is the best one. Default: on.
|
|
<tag>default bgp_med <m/number/</tag> Value of the Multiple Exit
|
|
Discriminator to be used during route selection when the MED attribute
|
|
is missing. Default: infinite.
|
|
<tag>default bgp_local_pref <m/number/</tag> Value of the Local Preference
|
|
to be used during route selection when the Local Preference attribute
|
|
is missing. Default: 0.
|
|
</descrip>
|
|
|
|
<sect2>Attributes
|
|
|
|
<p>BGP defines several route attributes. Some of them (those marked with `I' in the
|
|
table below) are available on internal BGP connections only, some of them (marked
|
|
with `O') are optional.
|
|
|
|
<descrip>
|
|
<tag>bgppath <cf/bgp_path/</tag> Sequence of AS numbers describing the AS path
|
|
the packet will travel through when forwarded according to this route. On
|
|
internal BGP connections it doesn't contain the number of the local AS.
|
|
<tag>int <cf/bgp_local_pref/ [I]</tag> Local preference value used for
|
|
selection among multiple BGP routes (see the selection rules above). It's
|
|
used as an additional metric which is propagated through the whole local AS.
|
|
<tag>int <cf/bgp_med/ [IO]</tag> The Multiple Exit Discriminator of the route
|
|
is an optional attribute which is often used within the local AS to
|
|
reflect interior distances to various boundary routers. See the route selection
|
|
rules above for exact semantics.
|
|
<tag>enum <cf/bgp_origin/</tag> Origin of the route: either <cf/ORIGIN_IGP/,
|
|
if the route has originated in interior routing protocol of an AS or
|
|
<cf/ORIGIN_EGP/, if it's been imported from the <tt>EGP</tt> protocol
|
|
(nowadays it seems to be obsolete) or <cf/ORIGIN_INCOMPLETE/, if the origin
|
|
is unknown.
|
|
<tag>ip <cf/bgp_next_hop/</tag> Next hop to be used for forwarding of packets
|
|
to this destination. On internal BGP connections, it's an address of the
|
|
originating router if it's inside the local AS or a boundary router the
|
|
packet will leave the AS through if it's an exterior route, so each BGP
|
|
speaker within the AS has a chance to use the shortest interior path
|
|
possible to this point.
|
|
<tag>void <cf/bgp_atomic_aggr/ [O]</tag> This is an optional attribute
|
|
which carries no value, but which sole presence indicates that the route
|
|
has been aggregated from multiple routes by some AS on the path from
|
|
the originator.
|
|
<!-- we don't handle aggregators right since they are of a very obscure type
|
|
<tag>bgp_aggregator</tag>
|
|
-->
|
|
<tag>clist <cf/bgp_community/ [O]</tag> List of community values associated
|
|
with the route. Each such value is a pair (represented as a <cf/pair/ data
|
|
type inside the filters) of 16-bit integers, the first of them containing a number of the AS which defines
|
|
the community and the second one is a per-AS identifier. There are lots
|
|
of uses of the community mechanism, but generally they are used to carry
|
|
policy information like "don't export to USA peers". As each AS can define
|
|
its own routing policy, it also has a complete freedom about which community
|
|
attributes it defines and what their semantics will be.
|
|
</descrip>
|
|
|
|
<sect2>Example
|
|
|
|
<p><code>
|
|
protocol bgp {
|
|
local as 65000; # Use a private AS number
|
|
neighbor 62.168.0.130 as 5588; # Our neighbor
|
|
multihop 20 via 62.168.0.13; # Which is connected indirectly
|
|
export filter { # We use non-trivial export rules
|
|
if source = RTS_STATIC then { # Export only static routes
|
|
bgp_community.add((65000,5678)); # Assign our community
|
|
if bgp_path ~ / 65000 / then # Artificially increase path length
|
|
bgp_path.prepend(65000); # by prepending local AS number twice
|
|
accept;
|
|
}
|
|
reject;
|
|
};
|
|
import all;
|
|
source address 62.168.0.1; # Use non-standard source address
|
|
}
|
|
</code>
|
|
|
|
<sect1>Device
|
|
|
|
<p>The Device protocol is not a real routing protocol as it doesn't generate
|
|
any routes and only serves as a module for getting information about network
|
|
interfaces from the kernel.
|
|
|
|
<p>Except for very unusual circumstances, you probably should include
|
|
this protocol in the configuration since almost all other protocol
|
|
require network interfaces to be defined in order to work.
|
|
|
|
<p>The only configurable thing is interface scan time:
|
|
|
|
<p><descrip>
|
|
<tag>scan time <m/number/</tag> Time in seconds between two scans
|
|
of the network interface list. On systems where we are notified about
|
|
interface status changes asynchronously (such as newer versions of
|
|
Linux), we need to scan the list only to avoid confusion by lost
|
|
notifications, so the default time is set to a large value.
|
|
</descrip>
|
|
|
|
<p>As the Device protocol doesn't generate any routes, it cannot have
|
|
any attributes. Example configuration looks really simple:
|
|
|
|
<p><code>
|
|
protocol device {
|
|
scan time 10; # Scan the interfaces often
|
|
}
|
|
</code>
|
|
|
|
<sect1>Direct
|
|
|
|
<p>The Direct protocol is a simple generator of device routes for all the
|
|
directly connected networks according to the list of interfaces provided
|
|
by the kernel via the Device protocol.
|
|
|
|
<p>It's highly recommended to include this protocol in your configuration
|
|
unless you want to use BIRD as a route server or a route reflector, that is
|
|
on a machine which doesn't forward packets and only participates in
|
|
distribution of routing information.
|
|
|
|
<p>Only configurable thing about direct is what interfaces it watches:
|
|
|
|
<p><descrip>
|
|
<tag>interface <m/pattern [, ...]/</tag> By default, the Direct
|
|
protocol will generate device routes for all the interfaces
|
|
available. If you want to restrict it to some subset of interfaces
|
|
(for example if you're using multiple routing tables for policy
|
|
routing and some of the policy domains don't contain all interfaces),
|
|
just use this clause.
|
|
</descrip>
|
|
|
|
<p>Direct device routes don't contain any specific attributes.
|
|
|
|
<p>Example config might look like this:
|
|
|
|
<p><code>
|
|
protocol direct {
|
|
interface "-arc*", "*"; # Exclude the ARCnets
|
|
}
|
|
</code>
|
|
|
|
<sect1>Kernel
|
|
|
|
<p>The Kernel protocol is not a real routing protocol. Instead of communicating
|
|
with other routers in the network, it performs synchronization of BIRD's routing
|
|
tables with OS kernel. Basically, it sends all routing table updates to the kernel
|
|
and from time to time it scans the kernel tables to see whether some routes have
|
|
disappeared (for example due to unnoticed up/down transition of an interface)
|
|
or whether an `alien' route has been added by someone else (depending on the
|
|
<cf/learn/ switch, such routes are either deleted or we accept them to our
|
|
table).
|
|
|
|
<p>If your OS supports only a single routing table, you can configure only one
|
|
instance of the Kernel protocol. If it supports multiple tables (in order to
|
|
allow policy routing), you can run as many instances as you want, but each of
|
|
them must be connected to a different BIRD routing table and to a different
|
|
kernel table.
|
|
|
|
<sect2>Configuration
|
|
|
|
<p><descrip>
|
|
<tag>persist <m/switch/</tag> Tell BIRD to leave all its routes in the
|
|
routing tables when it exits (instead of cleaning them up).
|
|
<tag>scan time <m/number/</tag> Time in seconds between two scans of the
|
|
kernel routing table.
|
|
<tag>learn <m/switch/</tag> Enable learning of routes added to the kernel
|
|
routing tables by other routing daemons or by the system administrator.
|
|
This is possible only on systems which support identification of route
|
|
authorship.
|
|
<tag>kernel table <m/number/</tag> Select which kernel table should
|
|
this particular instance of the Kernel protocol work with. Available
|
|
only on systems supporting multiple routing tables.
|
|
</descrip>
|
|
|
|
<p>A simple configuration can look this way:
|
|
|
|
<p><code>
|
|
protocol kernel {
|
|
import all;
|
|
export all;
|
|
}
|
|
</code>
|
|
|
|
<p>Or for a system with two routing tables:
|
|
|
|
<p><code>
|
|
protocol kernel { # Primary routing table
|
|
learn; # Learn alien routes from the kernel
|
|
persist; # Don't remove routes on bird shutdown
|
|
scan time 10; # Scan kernel routing table every 10 seconds
|
|
import all;
|
|
export all;
|
|
}
|
|
|
|
protocol kernel { # Secondary routing table
|
|
table auxtable;
|
|
kernel table 100;
|
|
export all;
|
|
}
|
|
</code>
|
|
|
|
<p>The Kernel protocol doesn't define any route attributes.
|
|
|
|
<sect1>OSPF
|
|
|
|
<sect1>Pipe
|
|
|
|
<sect2>Introduction
|
|
|
|
<p>The Pipe protocol serves as a link between two routing tables, allowing routes to be
|
|
passed from a table declared as primary (i.e., the one the pipe is connected using the
|
|
<cf/table/ configuration keyword) to the secondary one (declared using <cf/peer table/)
|
|
and vice versa, depending on what's allowed by the filters. Export filters control export
|
|
of routes from the primary table to the secondary one, import filters control the opposite
|
|
direction.
|
|
|
|
<p>The primary use of multiple routing tables and the pipe protocol is for policy routing,
|
|
where handling of a single packet doesn't depend only on its destination address, but also
|
|
on its source address, source interface, protocol type and other similar parameters.
|
|
In many systems (Linux 2.2 being a good example) the kernel allows to enforce routing policies
|
|
by defining routing rules which choose one of several routing tables to be used for a packet
|
|
according to its parameters. Setting of these rules is outside the scope of BIRD's work
|
|
(you can use the <tt/ip/ command), but you can create several routing tables in BIRD,
|
|
connect them to the kernel ones, use filters to control which routes appear in which tables
|
|
and also you can employ the Pipe protocol to export a selected subset of one table in
|
|
another one.
|
|
|
|
<sect2>Configuration
|
|
|
|
<p><descrip>
|
|
<tag>peer table <m/table/</tag> Define secondary routing table to connect to. The
|
|
primary one is selected by the <cf/table/ keyword.
|
|
</descrip>
|
|
|
|
<sect2>Attributes
|
|
|
|
<p>The Pipe protocol doesn't define any route attributes.
|
|
|
|
<sect2>Example
|
|
|
|
<p>Let's consider a router which serves as a boundary router of two different autonomous
|
|
systems, each of them connected to a subset of interfaces of the router, having its own
|
|
exterior connectivity and wishing to use the other AS as a backup connectivity in case
|
|
of outage of its own exterior line.
|
|
|
|
<p>Probably the simplest solution to this situation is to use two routing tables (we'll
|
|
call them <cf/as1/ and <cf/as2/) and set up kernel routing rules, so that packets having
|
|
arrived from interfaces belonging to the first AS will be routed according to <cf/as1/
|
|
and similarly for the second AS. Thus we have split our router to two logical routers,
|
|
each one acting on its own routing table, having its own routing protocols on its own
|
|
interfaces. In order to use the other AS's routes for backup purposes, we can pass
|
|
the routes between the tables through a Pipe protocol while decreasing their preferences
|
|
and correcting their BGP paths to reflect AS boundary crossing.
|
|
|
|
<code>
|
|
table as1; # Define the tables
|
|
table as2;
|
|
|
|
protocol kernel kern1 { # Synchronize them with the kernel
|
|
table as1;
|
|
kernel table 1;
|
|
}
|
|
|
|
protocol kernel kern2 {
|
|
table as2;
|
|
kernel table 2;
|
|
}
|
|
|
|
protocol bgp bgp1 { # The outside connections
|
|
table as1;
|
|
local as 1;
|
|
neighbor 192.168.0.1 as 1001;
|
|
export all;
|
|
import all;
|
|
}
|
|
|
|
protocol bgp bgp2 {
|
|
table as2;
|
|
local as 2;
|
|
neighbor 10.0.0.1 as 1002;
|
|
export all;
|
|
import all;
|
|
}
|
|
|
|
protocol pipe { # The Pipe
|
|
table as1;
|
|
peer table as2;
|
|
export filter {
|
|
if net ~ [ 1.0.0.0/8+] then { # Only AS1 networks
|
|
if preference>10 then preference = preference-10;
|
|
if source=RTS_BGP then bgp_path.prepend(1);
|
|
accept;
|
|
}
|
|
reject;
|
|
};
|
|
import filter {
|
|
if net ~ [ 2.0.0.0/8+] then { # Only AS2 networks
|
|
if preference>10 then preference = preference-10;
|
|
if source=RTS_BGP then bgp_path.prepend(2);
|
|
accept;
|
|
}
|
|
reject;
|
|
};
|
|
}
|
|
</code>
|
|
|
|
<sect1>Rip
|
|
|
|
<sect2>Introduction
|
|
|
|
<p>Rip protocol (sometimes called Rest In Pieces) is a simple protocol, where each router broadcasts
|
|
distances to all networks it can reach. When router hears distance to other network, it increments
|
|
it and broadcasts it back. Broadcasts are done in regular intervals. Therefore, if some network goes
|
|
unreachable, routers keep telling each other that distance is old distance plus 1 (actually, plus
|
|
interface metric, which is usually one). After some time, distance reaches infinity (that's 15 in
|
|
rip) and all routers know that network is unreachable. Rip tries to minimize situations where
|
|
counting to infinity is necessary, because it is slow. Due to infinity being 16, you can not use
|
|
rip on networks where maximal distance is bigger than 15 hosts. You can read more about rip at <HTMLURL
|
|
URL="http://www.ietf.org/html.charters/rip-charter.html">. Both IPv4
|
|
and IPv6 versions of rip are supported by BIRD, historical Ripv1 is
|
|
currently not fully supported.
|
|
|
|
<p>Rip is very simple protocol, and it is not too good. Slow
|
|
convergence, big network load and inability to handle bigger networks
|
|
makes it pretty much obsolete in IPv4 world. (It is still usable on
|
|
very small networks, through.) It is widely used in IPv6 world,
|
|
because they are no good implementations of OSPFv3.
|
|
|
|
<sect2>Configuration
|
|
|
|
<p>In addition to options generic to other protocols, rip supports following options:
|
|
|
|
<descrip>
|
|
<tag/authentication none|password|md5/ selects authentication method to use. None means that
|
|
packets are not authenticated at all, password means that plaintext password is embedded
|
|
into each packet, and md5 means that packets are authenticated using md5 cryptographic
|
|
hash. If you set authentication to non-none, it is good idea to add <cf>passwords { }</cf>
|
|
section.
|
|
|
|
<tag>honor always|neighbor|never </tag>specifies, when should be requests for dumping routing table
|
|
honored. (Always, when sent from host on directly connected
|
|
network, or never.) Routing table updates are honored only from
|
|
neighbors, that is not configurable.
|
|
</descrip>
|
|
|
|
<p>There are two options that can be specified per-interface. First is <cf>metric</cf>, with
|
|
default one. Second is <cf>mode multicast|broadcast|quiet|nolisten|version1</cf>, it selects mode for
|
|
rip to work in. If nothing is specified, rip runs in multicast mode. <cf>version1</cf> is
|
|
currently equivalent to <cf>broadcast</cf>, and it makes rip talk at broadcast address even
|
|
through multicast mode is possible. <cf>quiet</cf> option means that rip will not transmit
|
|
periodic messages onto this interface and <cf>nolisten</cf> means that rip will talk to this
|
|
interface but not listen on it.
|
|
|
|
<p>Following options generally override specified behavior from RFC. If you use any of these
|
|
options, BIRD will no longer be RFC-compatible, which means it will not be able to talk to anything
|
|
other than equally misconfigured BIRD. I warned you.
|
|
|
|
<descrip>
|
|
<tag>port <M>number</M></tag>
|
|
selects IP port to operate on, default 520. (This is useful when testing BIRD, if you
|
|
set this to address >1024, you will not need to run bird with UID==0).
|
|
|
|
<tag>infinity <M>number</M></tag>
|
|
select value of infinity, default 16. Bigger values will make protocol convergence
|
|
even slower.
|
|
|
|
<tag>period <M>number</M>
|
|
</tag>specifies number of seconds between periodic updates. Default is 30 seconds. Lower
|
|
number will mean faster convergence but bigger network
|
|
load. Do not use values lower than 10.
|
|
|
|
<tag>timeout time <M>number</M>
|
|
</tag>specifies how old route has to be to be considered unreachable. Default is 4*period.
|
|
|
|
<tag>garbage time <M>number</M>
|
|
</tag>specifies how old route has to be to be discarded. Default is 10*period.
|
|
</descrip>
|
|
|
|
<sect2>Attributes
|
|
|
|
<p>RIP defines two route attributes:
|
|
|
|
<descrip>
|
|
<tag>int <cf/rip_metric/</tag> RIP metric of the route (ranging from 0 to <cf/infinity/).
|
|
When routes from different RIP instances are available and all of them have the same
|
|
preference, BIRD prefers the route with lowest <cf/rip_metric/.
|
|
|
|
<tag>int <cf/rip_tag/</tag> RIP route tag: a 16-bit number which can be used
|
|
to carry additional information with the route (for example, an originating AS number
|
|
in case of external routes).
|
|
</descrip>
|
|
|
|
<sect2>Example
|
|
|
|
<p><code>
|
|
protocol rip MyRIP_test {
|
|
debug all;
|
|
port 1520;
|
|
period 10;
|
|
garbage time 60;
|
|
interface "eth0" { metric 3; mode multicast; } "eth1" { metric 2; mode broadcast; };
|
|
honor neighbor;
|
|
authentication none;
|
|
import filter { print "importing"; accept; };
|
|
export filter { print "exporting"; accept; };
|
|
}
|
|
</code>
|
|
|
|
<sect1>Static
|
|
|
|
<p>The Static protocol doesn't communicate with other routers in the network,
|
|
but instead it allows you to define routes manually. This is often used for
|
|
specifying how to forward packets to parts of the network which don't use
|
|
dynamic routing at all and also for defining sink routes (i.e., those
|
|
telling to return packets as undeliverable if they are in your IP block,
|
|
you don't have any specific destination for them and you don't want to send
|
|
them out through the default route to prevent routing loops).
|
|
|
|
<p>There are three types of static routes: `classical' routes telling to
|
|
forward packets to a neighboring router, device routes specifying forwarding
|
|
to hosts on a directly connected network and special routes (sink, blackhole
|
|
etc.) which specify a special action to be done instead of forwarding the
|
|
packet.
|
|
|
|
<p>When the particular destination is not available (the interface is down or
|
|
the next hop of the route is not a neighbor at the moment), Static just
|
|
uninstalls the route from the table it is connected to and adds it again as soon
|
|
as the destinations becomes adjacent again.
|
|
|
|
<p>The Static protocol has no configuration options. Instead, the
|
|
definition of the protocol contains a list of static routes:
|
|
|
|
<descrip>
|
|
<tag>route <m/prefix/ via <m/ip/</tag> Static route through
|
|
a neighboring router.
|
|
<tag>route <m/prefix/ via <m/"interface"/</tag> Static device
|
|
route through an interface to hosts on a directly connected network.
|
|
<tag>route <m/prefix/ drop|reject|prohibit</tag> Special routes
|
|
specifying to drop the packet, return it as unreachable or return
|
|
it as administratively prohibited.
|
|
</descrip>
|
|
|
|
<p>Static routes have no specific attributes.
|
|
|
|
<p>Example static config might look like this:
|
|
|
|
<p><code>
|
|
protocol static {
|
|
table testable; # Connect to non-default routing table
|
|
route 0.0.0.0/0 via 62.168.0.13; # Default route
|
|
route 62.168.0.0/25 reject; # Sink route
|
|
route 10.2.0.0/24 via "arc0"; # Secondary network
|
|
}
|
|
</code>
|
|
|
|
<sect>Problems
|
|
|
|
<p>BIRD is relatively young system, and probably contains some
|
|
bugs. You can report bugs at <HTMLURL URL="fixme">, but before you do,
|
|
please make sure you have read available documenation, make sure are running latest version (available at <HTMLURL
|
|
URL="fixme">), and that bug was not already reported by someone else
|
|
(mailing list archives are at <HTMLURL URL="fixme">). (Of course, patch
|
|
which fixes the bug along with bug report is always welcome). If you
|
|
want to join the development, join developer's mailing list by sending
|
|
<tt/????/ to <HTMLURL URL="fixme">. You can also get current sources from
|
|
anoncvs at <HTMLURL URL="fixme">. You can find this documentation online
|
|
at <HTMLURL URL="fixme">, main homepage of bird is <HTMLURL URL="fixme">. When
|
|
trying to understand, what is going on, Internet standards are
|
|
relevant reading; you can get them from <HTMLURL URL="fixme">.
|
|
|
|
<p><it/Good luck!/
|
|
|
|
</article>
|
|
|
|
<!--
|
|
LocalWords: GPL IPv GateD BGPv RIPv OSPFv Linux sgml html dvi sgmltools
|
|
LocalWords: linuxdoc dtd descrip config conf syslog stderr auth ospf bgp
|
|
LocalWords: router's eval expr num birdc ctl unix if's enums bool int ip
|
|
LocalWords: len ipaddress pxlen netmask enum bgppath bgpmask clist gw md
|
|
LocalWords: RTS printn quitbird iBGP AS'es eBGP RFC multiprotocol IGP
|
|
LocalWords: EGP misconfigurations keepalive pref aggr aggregator BIRD's
|
|
LocalWords: OS'es AS's multicast nolisten misconfigured UID blackhole
|
|
LocalWords: uninstalls
|
|
-->
|