1 <!doctype birddoc system>
6 This documentation can have 4 forms: sgml (this is master copy), html,
7 ASCII text and dvi/postscript (generated from sgml using
8 sgmltools). You should always edit master copy.
10 This is a slightly modified linuxdoc dtd. Anything in <descrip> tags is considered definition of
11 configuration primitives, <cf> is fragment of configuration within normal text, <m> is
12 "meta" information within fragment of configuration - something in config which is not keyword.
16 Copyright 1999,2000 Pavel Machek <pavel@ucw.cz>, distribute under GPL version 2 or later.
22 <title>BIRD User's Guide
24 Ondrej Filip <it/<feela@network.cz>/,
25 Pavel Machek <it/<pavel@ucw.cz>/,
26 Martin Mares <it/<mj@ucw.cz>/,
27 Ondrej Zajicek <it/<santiago@crfreenet.org>/
31 This document contains user documentation for the BIRD Internet Routing Daemon project.
34 <!-- Table of contents -->
37 <!-- Begin the document -->
44 The name `BIRD' is actually an acronym standing for `BIRD Internet Routing Daemon'.
45 Let's take a closer look at the meaning of the name:
47 <p><em/BIRD/: Well, we think we have already explained that. It's an acronym standing
48 for `BIRD Internet Routing Daemon', you remember, don't you? :-)
50 <p><em/Internet Routing/: It's a program (well, a daemon, as you are going to discover in a moment)
51 which works as a dynamic router in an Internet type network (that is, in a network running either
52 the IPv4 or the IPv6 protocol). Routers are devices which forward packets between interconnected
53 networks in order to allow hosts not connected directly to the same local area network to
54 communicate with each other. They also communicate with the other routers in the Internet to discover
55 the topology of the network which allows them to find optimal (in terms of some metric) rules for
56 forwarding of packets (which are called routing tables) and to adapt themselves to the
57 changing conditions such as outages of network links, building of new connections and so on. Most of
58 these routers are costly dedicated devices running obscure firmware which is hard to configure and
59 not open to any changes (on the other hand, their special hardware design allows them to keep up with lots of high-speed network interfaces, better than general-purpose computer does). Fortunately, most operating systems of the UNIX family allow an ordinary
60 computer to act as a router and forward packets belonging to the other hosts, but only according to
61 a statically configured table.
63 <p>A <em/Routing Daemon/ is in UNIX terminology a non-interactive program running on
64 background which does the dynamic part of Internet routing, that is it communicates
65 with the other routers, calculates routing tables and sends them to the OS kernel
66 which does the actual packet forwarding. There already exist other such routing
67 daemons: routed (RIP only), GateD (non-free), Zebra<HTMLURL URL="http://www.zebra.org">
68 and MRTD<HTMLURL URL="http://sourceforge.net/projects/mrt">, but their capabilities are
69 limited and they are relatively hard to configure and maintain.
71 <p>BIRD is an Internet Routing Daemon designed to avoid all of these shortcomings,
72 to support all the routing technology used in the today's Internet or planned to be
73 used in near future and to have a clean extensible architecture allowing new routing
74 protocols to be incorporated easily. Among other features, BIRD supports:
77 <item>both IPv4 and IPv6 protocols
78 <item>multiple routing tables
79 <item>the Border Gateway Protocol (BGPv4)
80 <item>the Routing Information Protocol (RIPv2)
81 <item>the Open Shortest Path First protocol (OSPFv2, OSPFv3)
82 <item>the Router Advertisements for IPv6 hosts
83 <item>a virtual protocol for exchange of routes between different routing tables on a single host
84 <item>a command-line interface allowing on-line control and inspection
85 of status of the daemon
86 <item>soft reconfiguration (no need to use complex online commands
87 to change the configuration, just edit the configuration file
88 and notify BIRD to re-read it and it will smoothly switch itself
89 to the new configuration, not disturbing routing protocols
90 unless they are affected by the configuration changes)
91 <item>a powerful language for route filtering
94 <p>BIRD has been developed at the Faculty of Math and Physics, Charles University, Prague,
95 Czech Republic as a student project. It can be freely distributed under the terms of the GNU General
98 <p>BIRD has been designed to work on all UNIX-like systems. It has
99 been developed and tested under Linux 2.0 to 2.6, and then ported to
100 FreeBSD, NetBSD and OpenBSD, porting to other systems (even non-UNIX
101 ones) should be relatively easy due to its highly modular
104 <p>BIRD supports either IPv4 or IPv6 protocol, but have to be compiled
105 separately for each one. Therefore, a dualstack router would run two
106 instances of BIRD (one for IPv4 and one for IPv6), with completely
107 separate setups (configuration files, tools ...).
109 <sect>Installing BIRD
111 <p>On a recent UNIX system with GNU development tools (GCC, binutils, m4, make) and Perl, installing BIRD should be as easy as:
117 vi /usr/local/etc/bird.conf
121 <p>You can use <tt>./configure --help</tt> to get a list of configure
122 options. The most important ones are:
123 <tt/--enable-ipv6/ which enables building of an IPv6 version of BIRD,
124 <tt/--with-protocols=/ to produce a slightly smaller BIRD executable by configuring out routing protocols you don't use, and
125 <tt/--prefix=/ to install BIRD to a place different from.
126 <file>/usr/local</file>.
130 <p>You can pass several command-line options to bird:
133 <tag>-c <m/config name/</tag>
134 use given configuration file instead of <it/prefix/<file>/etc/bird.conf</file>.
137 enable debug messages and run bird in foreground.
139 <tag>-D <m/filename of debug log/</tag>
140 log debugging information to given file instead of stderr.
143 just parse the config file and exit. Return value is zero if the config file is valid,
144 nonzero if there are some errors.
146 <tag>-s <m/name of communication socket/</tag>
147 use given filename for a socket for communications with the client, default is <it/prefix/<file>/var/run/bird.ctl</file>.
149 <tag>-u <m/user/</tag>
150 drop privileges and use that user ID, see the next section for details.
152 <tag>-g <m/group/</tag>
153 use that group ID, see the next section for details.
156 <p>BIRD writes messages about its work to log files or syslog (according to config).
160 <p>BIRD, as a routing daemon, uses several privileged operations (like
161 setting routing table and using raw sockets). Traditionally, BIRD is
162 executed and runs with root privileges, which may be prone to security
163 problems. The recommended way is to use a privilege restriction
164 (options <cf/-u/, <cf/-g/). In that case BIRD is executed with root
165 privileges, but it changes its user and group ID to an unprivileged
166 ones, while using Linux capabilities to retain just required
167 privileges (capabilities CAP_NET_*). Note that the control socket is
168 created before the privileges are dropped, but the config file is read
169 after that. The privilege restriction is not implemented in BSD port
172 <p>A nonprivileged user (as an argument to <cf/-u/ options) may be the
173 user <cf/nobody/, but it is suggested to use a new dedicated user
174 account (like <cf/bird/). The similar considerations apply for
175 the group option, but there is one more condition -- the users
176 in the same group can use <file/birdc/ to control BIRD.
178 <p>Finally, there is a possibility to use external tools to run BIRD in
179 an environment with restricted privileges. This may need some
180 configuration, but it is generally easy -- BIRD needs just the
181 standard library, privileges to read the config file and create the
182 control socket and the CAP_NET_* capabilities.
184 <chapt>About routing tables
186 <p>BIRD has one or more routing tables which may or may not be
187 synchronized with OS kernel and which may or may not be synchronized with
188 each other (see the Pipe protocol). Each routing table contains a list of
189 known routes. Each route consists of:
192 <item>network prefix this route is for (network address and prefix length -- the number of bits forming the network part of the address; also known as a netmask)
193 <item>preference of this route
194 <item>IP address of router which told us about this route
195 <item>IP address of router we should forward the packets to
197 <item>other attributes common to all routes
198 <item>dynamic attributes defined by protocols which may or
199 may not be present (typically protocol metrics)
202 Routing table maintains multiple entries
203 for a network, but at most one entry for one network and one
204 protocol. The entry with the highest preference is used for routing (we
205 will call such an entry the <it/selected route/). If
206 there are more entries with the same preference and they are from the same
207 protocol, the protocol decides (typically according to metrics). If they aren't,
208 an internal ordering is used to break the tie. You can
209 get the list of route attributes in the Route attributes section.
211 <p>Each protocol is connected to a routing table through two filters
212 which can accept, reject and modify the routes. An <it/export/
213 filter checks routes passed from the routing table to the protocol,
214 an <it/import/ filter checks routes in the opposite direction.
215 When the routing table gets a route from a protocol, it recalculates
216 the selected route and broadcasts it to all protocols connected to
217 the table. The protocols typically send the update to other routers
224 <p>BIRD is configured using a text configuration file. Upon startup, BIRD reads <it/prefix/<file>/etc/bird.conf</file> (unless the
225 <tt/-c/ command line option is given). Configuration may be changed at user's request: if you modify
226 the config file and then signal BIRD with <tt/SIGHUP/, it will adjust to the new
227 config. Then there's the client
228 which allows you to talk with BIRD in an extensive way.
230 <p>In the config, everything on a line after <cf/#/ or inside <cf>/*
231 */</cf> is a comment, whitespace characters are treated as a single space. If there's a variable number of options, they are grouped using
232 the <cf/{ }/ brackets. Each option is terminated by a <cf/;/. Configuration
235 <p>Here is an example of a simple config file. It enables
236 synchronization of routing tables with OS kernel, scans for
237 new network interfaces every 10 seconds and runs RIP on all network interfaces found.
242 persist; # Don't remove routes on BIRD shutdown
243 scan time 20; # Scan kernel routing table every 20 seconds
244 export all; # Default is export none
248 scan time 10; # Scan interfaces every 10 seconds
262 <tag>include "<m/filename/"</tag>
263 This statement causes inclusion of a new file. The maximal depth is set to 5.
265 <tag>log "<m/filename/"|syslog [name <m/name/]|stderr all|{ <m/list of classes/ }</tag>
266 Set logging of messages having the given class (either <cf/all/ or <cf/{
267 error, trace }/ etc.) into selected destination (a file specified as a filename string,
268 syslog with optional name argument, or the stderr output). Classes are:
269 <cf/info/, <cf/warning/, <cf/error/ and <cf/fatal/ for messages about local problems,
270 <cf/debug/ for debugging messages,
271 <cf/trace/ when you want to know what happens in the network,
272 <cf/remote/ for messages about misbehavior of remote machines,
273 <cf/auth/ about authentication failures,
274 <cf/bug/ for internal BIRD bugs. You may specify more than one <cf/log/ line to establish logging to multiple
275 destinations. Default: log everything to the system log.
277 <tag>debug protocols all|off|{ states, routes, filters, interfaces, events, packets }</tag>
278 Set global defaults of protocol debugging options. See <cf/debug/ in the following section. Default: off.
280 <tag>debug commands <m/number/</tag>
281 Control logging of client connections (0 for no logging, 1 for
282 logging of connects and disconnects, 2 and higher for logging of
283 all client commands). Default: 0.
285 <tag>mrtdump "<m/filename/"</tag>
286 Set MRTdump file name. This option must be specified to allow MRTdump feature.
287 Default: no dump file.
289 <tag>mrtdump protocols all|off|{ states, messages }</tag>
290 Set global defaults of MRTdump options. See <cf/mrtdump/ in the following section.
293 <tag>filter <m/name local variables/{ <m/commands/ }</tag> Define a filter. You can learn more about filters
294 in the following chapter.
296 <tag>function <m/name/ (<m/parameters/) <m/local variables/ { <m/commands/ }</tag> Define a function. You can learn more
297 about functions in the following chapter.
299 <tag>protocol rip|ospf|bgp|... [<m/name/ [from <m/name2/]] { <m>protocol options</m> }</tag>
300 Define a protocol instance called <cf><m/name/</cf> (or with a name like "rip5" generated
301 automatically if you don't specify any <cf><m/name/</cf>). You can learn more about
302 configuring protocols in their own chapters. When <cf>from <m/name2/</cf> expression is
303 used, initial protocol options are taken from protocol or template <cf><m/name2/</cf>
304 You can run more than one instance of most protocols (like RIP or BGP). By default, no
305 instances are configured.
307 <tag>template rip|bgp|... [<m/name/ [from <m/name2/]] { <m>protocol options</m> }</tag>
308 Define a protocol template instance called <cf><m/name/</cf> (or with a name like "bgp1"
309 generated automatically if you don't specify any <cf><m/name/</cf>). Protocol templates can
310 be used to group common options when many similarly configured protocol instances are to be
311 defined. Protocol instances (and other templates) can use templates by using <cf/from/
312 expression and the name of the template. At the moment templates (and <cf/from/ expression)
313 are not implemented for OSPF protocol.
315 <tag>define <m/constant/ = (<m/expression/)|<m/number/|<m/IP address/</tag>
316 Define a constant. You can use it later in every place you could use a simple integer or an IP address.
317 Besides, there are some predefined numeric constants based on /etc/iproute2/rt_* files.
318 A list of defined constants can be seen (together with other symbols) using 'show symbols' command.
320 <tag>router id <m/IPv4 address/</tag> Set BIRD's router ID. It's a world-wide unique identification of your router, usually one of router's IPv4 addresses. Default: in IPv4 version, the lowest IP address of a non-loopback interface. In IPv6 version, this option is mandatory.
322 <tag>listen bgp [address <m/address/] [port <m/port/] [dual]</tag>
323 This option allows to specify address and port where BGP
324 protocol should listen. It is global option as listening
325 socket is common to all BGP instances. Default is to listen on
326 all addresses (0.0.0.0) and port 179. In IPv6 mode, option
327 <cf/dual/ can be used to specify that BGP socket should accept
328 both IPv4 and IPv6 connections (but even in that case, BIRD
329 would accept IPv6 routes only). Such behavior was default in
330 older versions of BIRD.
332 <tag>timeformat route|protocol|base|log "<m/format1/" [<m/limit/ "<m/format2/"]</tag>
333 This option allows to specify a format of date/time used by
334 BIRD. The first argument specifies for which purpose such
335 format is used. <cf/route/ is a format used in 'show route'
336 command output, <cf/protocol/ is used in 'show protocols'
337 command output, <cf/base/ is used for other commands and
338 <cf/log/ is used in a log file.
340 "<m/format1/" is a format string using <it/strftime(3)/
341 notation (see <it/man strftime/ for details). <m/limit> and
342 "<m/format2/" allow to specify the second format string for
343 times in past deeper than <m/limit/ seconds. There are two
344 shorthands: <cf/iso long/ is a ISO 8601 date/time format
345 (YYYY-MM-DD hh:mm:ss) that can be also specified using <cf/"%F
346 %T"/. <cf/iso short/ is a variant of ISO 8601 that uses just
347 the time format (hh:mm:ss) for near times (up to 20 hours in
348 the past) and the date format (YYYY-MM-DD) for far times. This
349 is a shorthand for <cf/"%T" 72000 "%F"/.
351 By default, BIRD uses an short, ad-hoc format for <cf/route/
352 and <cf/protocol/ times, and a <cf/iso long/ similar format
353 (DD-MM-YYYY hh:mm:ss) for <cf/base/ and <cf/log/. These
354 defaults are here for a compatibility with older versions
355 and might change in the future.
357 <tag>table <m/name/</tag> Create a new routing table. The default
358 routing table is created implicitly, other routing tables have
359 to be added by this command.
361 <tag>eval <m/expr/</tag> Evaluates given filter expression. It
362 is used by us for testing of filters.
365 <sect>Protocol options
367 <p>For each protocol instance, you can configure a bunch of options.
368 Some of them (those described in this section) are generic, some are
369 specific to the protocol (see sections talking about the protocols).
371 <p>Several options use a <cf><m/switch/</cf> argument. It can be either
372 <cf/on/, <cf/yes/ or a numeric expression with a non-zero value for the
373 option to be enabled or <cf/off/, <cf/no/ or a numeric expression evaluating
374 to zero to disable it. An empty <cf><m/switch/</cf> is equivalent to <cf/on/
375 ("silence means agreement").
378 <tag>preference <m/expr/</tag> Sets the preference of routes generated by this protocol. Default: protocol dependent.
380 <tag>disabled <m/switch/</tag> Disables the protocol. You can change the disable/enable status from the command
381 line interface without needing to touch the configuration. Disabled protocols are not activated. Default: protocol is enabled.
383 <tag>debug all|off|{ states, routes, filters, interfaces, events, packets }</tag>
384 Set protocol debugging options. If asked, each protocol is capable of
385 writing trace messages about its work to the log (with category
386 <cf/trace/). You can either request printing of <cf/all/ trace messages
387 or only of the types selected: <cf/states/ for protocol state changes
388 (protocol going up, down, starting, stopping etc.),
389 <cf/routes/ for routes exchanged with the routing table,
390 <cf/filters/ for details on route filtering,
391 <cf/interfaces/ for interface change events sent to the protocol,
392 <cf/events/ for events internal to the protocol and
393 <cf/packets/ for packets sent and received by the protocol. Default: off.
395 <tag>mrtdump all|off|{ states, messages }</tag>
397 Set protocol MRTdump flags. MRTdump is a standard binary
398 format for logging information from routing protocols and
399 daemons. These flags control what kind of information is
400 logged from the protocol to the MRTdump file (which must be
401 specified by global <cf/mrtdump/ option, see the previous
402 section). Although these flags are similar to flags of
403 <cf/debug/ option, their meaning is different and
404 protocol-specific. For BGP protocol, <cf/states/ logs BGP
405 state changes and <cf/messages/ logs received BGP messages.
406 Other protocols does not support MRTdump yet.
408 <tag>router id <m/IPv4 address/</tag> This option can be used
409 to override global router id for a given protocol. Default:
410 uses global router id.
412 <tag>import all | none | filter <m/name/ | filter { <m/filter commands/ } | where <m/filter expression/</tag>
413 Specify a filter to be used for filtering routes coming from the protocol to the routing table. <cf/all/ is shorthand for <cf/where true/ and <cf/none/ is shorthand for <cf/where false/. Default: <cf/all/.
415 <tag>export <m/filter/</tag> This is similar to the <cf>import</cf> keyword, except that it
416 works in the direction from the routing table to the protocol. Default: <cf/none/.
418 <tag>description "<m/text/"</tag> This is an optional
419 description of the protocol. It is displayed as a part of the
420 output of 'show route all' command.
422 <tag>table <m/name/</tag> Connect this protocol to a non-default routing table.
425 <p>There are several options that give sense only with certain protocols:
428 <tag><label id="dsc-iface">interface [-] [ "<m/mask/" ] [ <m/prefix/ ] [, ...] [ { <m/option/ ; [...] } ]</tag>
430 Specifies a set of interfaces on which the protocol is activated with
431 given interface-specific options. A set of interfaces specified by one
432 interface option is described using an interface pattern. The
433 interface pattern consists of a sequence of clauses (separated by
434 commas), each clause may contain a mask, a prefix, or both of them. An
435 interface matches the clause if its name matches the mask (if
436 specified) and its address matches the prefix (if specified). Mask is
437 specified as shell-like pattern. For IPv6, the prefix part of a clause
438 is generally ignored and interfaces are matched just by their name.
440 An interface matches the pattern if it matches any of its
441 clauses. If the clause begins with <cf/-/, matching interfaces are
442 excluded. Patterns are parsed left-to-right, thus
443 <cf/interface "eth0", -"eth*", "*";/ means eth0 and all
446 An interface option can be used more times with different
447 interfaces-specific options, in that case for given interface
448 the first matching interface option is used.
450 This option is allowed in Direct, OSPF, RIP and RAdv protocols,
451 but in OSPF protocol it is used in <cf/area/ subsection.
457 <cf>interface "*" { type broadcast; };</cf> - start the protocol on all interfaces with
458 <cf>type broadcast</cf> option.
460 <cf>interface "eth1", "eth4", "eth5" { type ptp; };</cf> - start the protocol
461 on enumerated interfaces with <cf>type ptp</cf> option.
463 <cf>interface -192.168.1.0/24, 192.168.0.0/16;</cf> - start the protocol on all
464 interfaces that have address from 192.168.0.0/16, but not
467 <cf>interface -192.168.1.0/24, 192.168.0.0/16;</cf> - start the protocol on all
468 interfaces that have address from 192.168.0.0/16, but not
471 <cf>interface "eth*" 192.168.1.0/24;</cf> - start the protocol on all
472 ethernet interfaces that have address from 192.168.1.0/24.
474 <tag><label id="dsc-pass">password "<m/password/" [ { id <m/num/; generate from <m/time/; generate to <m/time/; accept from <m/time/; accept to <m/time/; } ]</tag>
475 Specifies a password that can be used by the protocol. Password option can
476 be used more times to specify more passwords. If more passwords are
477 specified, it is a protocol-dependent decision which one is really
478 used. Specifying passwords does not mean that authentication is
479 enabled, authentication can be enabled by separate, protocol-dependent
480 <cf/authentication/ option.
482 This option is allowed in OSPF and RIP protocols. BGP has also
483 <cf/password/ option, but it is slightly different and described
489 <p>Password option can contain section with some (not necessary all) password sub-options:
492 <tag>id <M>num</M></tag>
493 ID of the password, (0-255). If it's not used, BIRD will choose
494 ID based on an order of the password item in the interface. For
495 example, second password item in one interface will have default
496 ID 2. ID is used by some routing protocols to identify which
497 password was used to authenticate protocol packets.
499 <tag>generate from "<m/time/"</tag>
500 The start time of the usage of the password for packet signing.
501 The format of <cf><m/time/</cf> is <tt>dd-mm-yyyy HH:MM:SS</tt>.
503 <tag>generate to "<m/time/"</tag>
504 The last time of the usage of the password for packet signing.
506 <tag>accept from "<m/time/"</tag>
507 The start time of the usage of the password for packet verification.
509 <tag>accept to "<m/time/"</tag>
510 The last time of the usage of the password for packet verification.
513 <chapt>Remote control
515 <p>You can use the command-line client <file>birdc</file> to talk with
516 a running BIRD. Communication is done using a <file/bird.ctl/ UNIX
517 domain socket (unless changed with the <tt/-s/ option given to both
518 the server and the client). The commands can perform simple actions
519 such as enabling/disabling of protocols, telling BIRD to show various
520 information, telling it to show routing table filtered by filter, or
521 asking BIRD to reconfigure. Press <tt/?/ at any time to get online
522 help. Option <tt/-r/ can be used to enable a restricted mode of BIRD
523 client, which allows just read-only commands (<cf/show .../). Option
524 <tt/-v/ can be passed to the client, to make it dump numeric return
525 codes along with the messages. You do not necessarily need to use
526 <file/birdc/ to talk to BIRD, your own applications could do that, too
527 -- the format of communication between BIRD and <file/birdc/ is stable
528 (see the programmer's documentation).
530 Many commands have the <m/name/ of the protocol instance as an argument.
531 This argument can be omitted if there exists only a single instance.
533 <p>Here is a brief list of supported functions:
536 <tag>dump resources|sockets|interfaces|neighbors|attributes|routes|protocols</tag>
537 Dump contents of internal data structures to the debugging output.
539 <tag>show status</tag>
540 Show router status, that is BIRD version, uptime and time from last reconfiguration.
542 <tag>show protocols [all]</tag>
543 Show list of protocol instances along with tables they are connected to and protocol status, possibly giving verbose information, if <cf/all/ is specified.
545 <tag>show ospf interface [<m/name/] ["<m/interface/"]</tag>
546 Show detailed information about OSPF interfaces.
548 <tag>show ospf neighbors [<m/name/] ["<m/interface/"]</tag>
549 Show a list of OSPF neighbors and a state of adjacency to them.
551 <tag>show ospf state [all] [<m/name/]</tag>
552 Show detailed information about OSPF areas based on a content
553 of the link-state database. It shows network topology, stub
554 networks, aggregated networks and routers from other areas and
555 external routes. The command shows information about reachable
556 network nodes, use option <cf/all/ to show information about
557 all network nodes in the link-state database.
559 <tag>show ospf topology [all] [<m/name/]</tag>
560 Show a topology of OSPF areas based on a content of the
561 link-state database. It is just a stripped-down version of
564 <tag>show static [<m/name/]</tag>
565 Show detailed information about static routes.
567 <tag>show interfaces [summary]</tag>
568 Show the list of interfaces. For each interface, print its type, state, MTU and addresses assigned.
570 <tag>show symbols</tag>
571 Show the list of symbols defined in the configuration (names of protocols, routing tables etc.).
573 <tag>show route [[for] <m/prefix/|<m/IP/] [table <m/sym/] [filter <m/f/|where <m/c/] [(export|preexport) <m/p/] [protocol <m/p/] [<m/options/]</tag>
574 Show contents of a routing table (by default of the main one),
575 that is routes, their metrics and (in case the <cf/all/ switch is given)
576 all their attributes.
578 <p>You can specify a <m/prefix/ if you want to print routes for a
579 specific network. If you use <cf>for <m/prefix or IP/</cf>, you'll get
580 the entry which will be used for forwarding of packets to the given
581 destination. By default, all routes for each network are printed with
582 the selected one at the top, unless <cf/primary/ is given in which case
583 only the selected route is shown.
585 <p>You can also ask for printing only routes processed and accepted by
586 a given filter (<cf>filter <m/name/</cf> or <cf>filter { <m/filter/ }
587 </cf> or matching a given condition (<cf>where <m/condition/</cf>).
588 The <cf/export/ and <cf/preexport/ switches ask for printing of entries
589 that are exported to the specified protocol. With <cf/preexport/, the
590 export filter of the protocol is skipped.
592 <p>You can also select just routes added by a specific protocol.
593 <cf>protocol <m/p/</cf>.
595 <p>The <cf/stats/ switch requests showing of route statistics (the
596 number of networks, number of routes before and after filtering). If
597 you use <cf/count/ instead, only the statistics will be printed.
599 <tag>configure [soft] ["<m/config file/"]</tag>
600 Reload configuration from a given file. BIRD will smoothly
601 switch itself to the new configuration, protocols are
602 reconfigured if possible, restarted otherwise. Changes in
603 filters usually lead to restart of affected protocols. If
604 <cf/soft/ option is used, changes in filters does not cause
605 BIRD to restart affected protocols, therefore already accepted
606 routes (according to old filters) would be still propagated,
607 but new routes would be processed according to the new
610 <tag>enable|disable|restart <m/name/|"<m/pattern/"|all</tag>
611 Enable, disable or restart a given protocol instance, instances matching the <cf><m/pattern/</cf> or <cf/all/ instances.
613 <tag>reload [in|out] <m/name/|"<m/pattern/"|all</tag>
615 Reload a given protocol instance, that means re-import routes
616 from the protocol instance and re-export preferred routes to
617 the instance. If <cf/in/ or <cf/out/ options are used, the
618 command is restricted to one direction (re-import or
621 This command is useful if appropriate filters have changed but
622 the protocol instance was not restarted (or reloaded),
623 therefore it still propagates the old set of routes. For example
624 when <cf/configure soft/ command was used to change filters.
626 Re-export always succeeds, but re-import is protocol-dependent
627 and might fail (for example, if BGP neighbor does not support
628 route-refresh extension). In that case, re-export is also
629 skipped. Note that for the pipe protocol, both directions are
630 always reloaded together (<cf/in/ or <cf/out/ options are
631 ignored in that case).
636 <tag>debug <m/protocol/|<m/pattern/|all all|off|{ states | routes | filters | events | packets }</tag>
637 Control protocol debugging.
644 <p>BIRD contains a simple programming language. (No, it can't yet read mail :-). There are
645 two objects in this language: filters and functions. Filters are interpreted by BIRD core when a route is
646 being passed between protocols and routing tables. The filter language contains control structures such
647 as if's and switches, but it allows no loops. An example of a filter using many features can be found in <file>filter/test.conf</file>.
649 <p>Filter gets the route, looks at its attributes and
650 modifies some of them if it wishes. At the end, it decides whether to
651 pass the changed route through (using <cf/accept/) or whether to <cf/reject/ it. A simple filter looks
658 if defined( rip_metric ) then
664 if rip_metric > 10 then
665 reject "RIP metric is too big";
671 <p>As you can see, a filter has a header, a list of local variables, and a body. The header consists of
672 the <cf/filter/ keyword followed by a (unique) name of filter. The list of local variables consists of
673 <cf><M>type name</M>;</cf> pairs where each pair defines one local variable. The body consists of
674 <cf> { <M>statements</M> }</cf>. Each <m/statement/ is terminated by a <cf/;/. You can group
675 several statements to a single compound statement by using braces (<cf>{ <M>statements</M> }</cf>) which is useful if
676 you want to make a bigger block of code conditional.
678 <p>BIRD supports functions, so that you don't have to repeat the same blocks of code over and
679 over. Functions can have zero or more parameters and they can have local variables. Recursion is not allowed. Function definitions
689 function with_parameters (int parameter)
695 <p>Unlike in C, variables are declared after the <cf/function/ line, but before the first <cf/{/. You can't declare
696 variables in nested blocks. Functions are called like in C: <cf>name();
697 with_parameters(5);</cf>. Function may return values using the <cf>return <m/[expr]/</cf>
698 command. Returning a value exits from current function (this is similar to C).
700 <p>Filters are declared in a way similar to functions except they can't have explicit
701 parameters. They get a route table entry as an implicit parameter, it is also passed automatically
702 to any functions called. The filter must terminate with either
703 <cf/accept/ or <cf/reject/ statement. If there's a runtime error in filter, the route
706 <p>A nice trick to debug filters is to use <cf>show route filter
707 <m/name/</cf> from the command line client. An example session might look
711 pavel@bug:~/bird$ ./birdc -s bird.ctl
714 10.0.0.0/8 dev eth0 [direct1 23:21] (240)
715 195.113.30.2/32 dev tunl1 [direct1 23:21] (240)
716 127.0.0.0/8 dev lo [direct1 23:21] (240)
718 show route [<prefix>] [table <t>] [filter <f>] [all] [primary]...
719 bird> show route filter { if 127.0.0.5 ˜ net then accept; }
720 127.0.0.0/8 dev lo [direct1 23:21] (240)
726 <p>Each variable and each value has certain type. Booleans, integers and enums are
727 incompatible with each other (that is to prevent you from shooting in the foot).
730 <tag/bool/ This is a boolean type, it can have only two values, <cf/true/ and
731 <cf/false/. Boolean is the only type you can use in <cf/if/
734 <tag/int/ This is a general integer type, you can expect it to store signed values from -2000000000
735 to +2000000000. Overflows are not checked. You can use <cf/0x1234/ syntax to write hexadecimal values.
737 <tag/pair/ This is a pair of two short integers. Each component can have values from 0 to
738 65535. Literals of this type are written as <cf/(1234,5678)/. The same syntax can also be
739 used to construct a pair from two arbitrary integer expressions (for example <cf/(1+2,a)/).
741 <tag/quad/ This is a dotted quad of numbers used to represent
742 router IDs (and others). Each component can have a value
743 from 0 to 255. Literals of this type are written like IPv4
746 <tag/string/ This is a string of characters. There are no ways to modify strings in
747 filters. You can pass them between functions, assign them to variables of type <cf/string/, print
748 such variables, but you can't concatenate two strings. String literals
749 are written as <cf/"This is a string constant"/.
751 <tag/ip/ This type can hold a single IP address. Depending on the compile-time configuration of BIRD you are using, it
752 is either an IPv4 or IPv6 address. IP addresses are written in the standard notation (<cf/10.20.30.40/ or <cf/fec0:3:4::1/). You can apply special operator <cf>.mask(<M>num</M>)</cf>
753 on values of type ip. It masks out all but first <cf><M>num</M></cf> bits from the IP
754 address. So <cf/1.2.3.4.mask(8) = 1.0.0.0/ is true.
756 <tag/prefix/ This type can hold a network prefix consisting of IP address and prefix length. Prefix literals are written as
757 <cf><M>ipaddress</M>/<M>pxlen</M></cf>, or
758 <cf><m>ipaddress</m>/<m>netmask</m></cf>. There are two special
759 operators on prefixes:
760 <cf/.ip/ which extracts the IP address from the pair, and <cf/.len/, which separates prefix
761 length from the pair. So <cf>1.2.0.0/16.pxlen = 16</cf> is true.
763 <tag/ec/ This is a specialized type used to represent BGP
764 extended community values. It is essentially a 64bit value,
765 literals of this type are usually written as <cf>(<m/kind/,
766 <m/key/, <m/value/)</cf>, where <cf/kind/ is a kind of
767 extended community (e.g. <cf/rt/ / <cf/ro/ for a route
768 target / route origin communities), the format and possible
769 values of <cf/key/ and <cf/value/ are usually integers, but
770 it depends on the used kind. Similarly to pairs, ECs can be
771 constructed using expressions for <cf/key/ and
772 <cf/value/ parts, (e.g. <cf/(ro, myas, 3*10)/, where
773 <cf/myas/ is an integer variable).
775 <tag/int|pair|quad|ip|prefix|ec|enum set/
776 Filters recognize four types of sets. Sets are similar to strings: you can pass them around
777 but you can't modify them. Literals of type <cf>int set</cf> look like <cf>
778 [ 1, 2, 5..7 ]</cf>. As you can see, both simple values and ranges are permitted in
781 For pair sets, expressions like <cf/(123,*)/ can be used to denote ranges (in
782 that case <cf/(123,0)..(123,65535)/). You can also use <cf/(123,5..100)/ for range
783 <cf/(123,5)..(123,100)/. You can also use <cf/*/ and <cf/a..b/ expressions
784 in the first part of a pair, note that such expressions are translated to a set
785 of intervals, which may be memory intensive. E.g. <cf/(*,4..20)/ is translated to
786 <cf/(0,4..20), (1,4..20), (2,4..20), ... (65535, 4..20)/.
788 EC sets use similar expressions like pair sets, e.g. <cf/(rt, 123, 10..20)/
789 or <cf/(ro, 123, *)/. Expressions requiring the translation (like <cf/(rt, *, 3)/)
790 are not allowed (as they usually have 4B range for ASNs).
792 You can also use expressions for int, pair and EC set values. However it must
793 be possible to evaluate these expressions before daemon boots. So you can use
794 only constants inside them. E.g.
802 odds = [ one, 2+1, 6-one, 2*2*2-1, 9, 11 ];
803 ps = [ (1,one+one), (3,4)..(4,8), (5,*), (6,3..6), (7..9,*) ];
804 es = [ (rt, myas, 3*10), (rt, myas+one, 0..16*16*16-1), (ro, myas+2, *) ];
807 Sets of prefixes are special: their literals does not allow ranges, but allows
808 prefix patterns that are written as <cf><M>ipaddress</M>/<M>pxlen</M>{<M>low</M>,<M>high</M>}</cf>.
809 Prefix <cf><m>ip1</m>/<m>len1</m></cf> matches prefix pattern <cf><m>ip2</m>/<m>len2</m>{<m>l</m>,<m>h</m>}</cf> if
810 the first <cf>min(len1, len2)</cf> bits of <cf/ip1/ and <cf/ip2/ are identical and <cf>len1 <= ip1 <= len2</cf>.
811 A valid prefix pattern has to satisfy <cf>low <= high</cf>, but <cf/pxlen/ is not constrained by <cf/low/
812 or <cf/high/. Obviously, a prefix matches a prefix set literal if it matches any prefix pattern in the
815 There are also two shorthands for prefix patterns: <cf><m>address</m>/<m/len/+</cf> is a shorthand for
816 <cf><m>address</m>/<m/len/{<m/len/,<m/maxlen/}</cf> (where <cf><m>maxlen</m></cf> is 32 for IPv4 and 128 for IPv6),
817 that means network prefix <cf><m>address</m>/<m/len/</cf> and all its subnets. <cf><m>address</m>/<m/len/-</cf>
818 is a shorthand for <cf><m>address</m>/<m/len/{0,<m/len/}</cf>, that means network prefix <cf><m>address</m>/<m/len/</cf>
819 and all its supernets (network prefixes that contain it).
821 For example, <cf>[ 1.0.0.0/8, 2.0.0.0/8+, 3.0.0.0/8-, 4.0.0.0/8{16,24} ]</cf> matches
822 prefix <cf>1.0.0.0/8</cf>, all subprefixes of <cf>2.0.0.0/8</cf>, all superprefixes of <cf>3.0.0.0/8</cf> and prefixes
823 <cf/4.X.X.X/ whose prefix length is 16 to 24. <cf>[ 0.0.0.0/0{20,24} ]</cf> matches all prefixes (regardless of
824 IP address) whose prefix length is 20 to 24, <cf>[ 1.2.3.4/32- ]</cf> matches any prefix that contains IP address
825 <cf>1.2.3.4</cf>. <cf>1.2.0.0/16 ˜ [ 1.0.0.0/8{15,17} ]</cf> is true,
826 but <cf>1.0.0.0/16 ˜ [ 1.0.0.0/8- ]</cf> is false.
828 Cisco-style patterns like <cf>10.0.0.0/8 ge 16 le 24</cf> can be expressed
829 in BIRD as <cf>10.0.0.0/8{16,24}</cf>, <cf>192.168.0.0/16 le 24</cf> as
830 <cf>192.168.0.0/16{16,24}</cf> and <cf>192.168.0.0/16 ge 24</cf> as
831 <cf>192.168.0.0/16{24,32}</cf>.
834 Enumeration types are fixed sets of possibilities. You can't define your own
835 variables of such type, but some route attributes are of enumeration
836 type. Enumeration types are incompatible with each other.
839 BGP path is a list of autonomous system numbers. You can't write literals of this type.
840 There are several special operators on bgppaths:
842 <cf><m/P/.first</cf> returns the first ASN (the neighbor ASN) in path <m/P/.
844 <cf><m/P/.last</cf> returns the last ASN (the source ASN) in path <m/P/.
846 Both <cf/first/ and <cf/last/ return zero if there is no appropriate ASN,
847 for example if the path contains an AS set element as the first (or the last) part.
849 <cf><m/P/.len</cf> returns the length of path <m/P/.
851 <cf>prepend(<m/P/,<m/A/)</cf> prepends ASN <m/A/ to path <m/P/ and returns the result.
852 Statement <cf><m/P/ = prepend(<m/P/, <m/A/);</cf> can be shortened to
853 <cf><m/P/.prepend(<m/A/);</cf> if <m/P/ is appropriate route attribute
854 (for example <cf/bgp_path/).
857 BGP masks are patterns used for BGP path matching
858 (using <cf>path ˜ [= 2 3 5 * =]</cf> syntax). The masks
859 resemble wildcard patterns as used by UNIX shells. Autonomous
860 system numbers match themselves, <cf/*/ matches any (even empty)
861 sequence of arbitrary AS numbers and <cf/?/ matches one arbitrary AS number.
862 For example, if <cf>bgp_path</cf> is 4 3 2 1, then:
863 <tt>bgp_path ˜ [= * 4 3 * =]</tt> is true, but
864 <tt>bgp_path ˜ [= * 4 5 * =]</tt> is false.
865 BGP mask expressions can also contain integer expressions enclosed in parenthesis
866 and integer variables, for example <tt>[= * 4 (1+2) a =]</tt>.
867 There is also old syntax that uses / .. / instead of [= .. =] and ? instead of *.
870 Clist is similar to a set, except that unlike other sets, it
871 can be modified. The type is used for community list (a set
872 of pairs) and for cluster list (a set of quads). There exist
873 no literals of this type. There are three special operators on
876 <cf>add(<m/C/,<m/P/)</cf> adds pair (or quad) <m/P/ to clist
877 <m/C/ and returns the result. If item <m/P/ is already in
878 clist <m/C/, it does nothing. <m/P/ may also be a clist,
879 in that case all its members are added; i.e., it works as clist union.
881 <cf>delete(<m/C/,<m/P/)</cf> deletes pair (or quad)
882 <m/P/ from clist <m/C/ and returns the result. If clist
883 <m/C/ does not contain item <m/P/, it does nothing.
884 <m/P/ may also be a pair (or quad) set, in that case the
885 operator deletes all items from clist <m/C/ that are also
886 members of set <m/P/. Moreover, <m/P/ may also be a clist,
887 which works analogously; i.e., it works as clist difference.
889 <cf>filter(<m/C/,<m/P/)</cf> deletes all items from clist
890 <m/C/ that are not members of pair (or quad) set <m/P/.
891 I.e., <cf/filter/ do the same as <cf/delete/ with inverted
892 set <m/P/. <m/P/ may also be a clist, which works analogously;
893 i.e., it works as clist intersection.
895 Statement <cf><m/C/ = add(<m/C/, <m/P/);</cf> can be shortened to
896 <cf><m/C/.add(<m/P/);</cf> if <m/C/ is appropriate route
897 attribute (for example <cf/bgp_community/). Similarly for
898 <cf/delete/ and <cf/filter/.
901 Eclist is a data type used for BGP extended community lists.
902 Eclists are very similar to clists, but they are sets of ECs
903 instead of pairs. The same operations (like <cf/add/,
904 <cf/delete/, or <cf/˜/ membership operator) can be
905 used to modify or test eclists, with ECs instead of pairs as
911 <p>The filter language supports common integer operators <cf>(+,-,*,/)</cf>, parentheses <cf/(a*(b+c))/, comparison
912 <cf/(a=b, a!=b, a<b, a>=b)/. Logical operations include unary not (<cf/!/), and (<cf/&&/) and or (<cf/||/).
913 Special operators include <cf/˜/ for "is element of a set" operation - it can be
914 used on element and set of elements of the same type (returning true if element is contained in the given set), or
915 on two strings (returning true if first string matches a shell-like pattern stored in second string) or on IP and prefix (returning true if IP is within the range defined by that prefix), or on
916 prefix and prefix (returning true if first prefix is more specific than second one) or on bgppath and bgpmask (returning true if the path matches the mask) or on number and bgppath (returning true if the number is in the path) or on pair/quad and clist (returning true if the pair/quad is element of the clist) or on clist and pair/quad set (returning true if there is an element of the clist that is also a member of the pair/quad set).
919 <sect>Control structures
921 <p>Filters support two control structures: conditions and case switches.
923 <p>Syntax of a condition is: <cf>if
924 <M>boolean expression</M> then <M>command1</M>; else <M>command2</M>;</cf> and you can use <cf>{
925 <M>command_1</M>; <M>command_2</M>; <M>...</M> }</cf> instead of either command. The <cf>else</cf>
926 clause may be omitted. If the <cf><m>boolean expression</m></cf> is true, <cf><m>command1</m></cf> is executed, otherwise <cf><m>command2</m></cf> is executed.
928 <p>The <cf>case</cf> is similar to case from Pascal. Syntax is <cf>case <m/expr/ { else: |
929 <m/num_or_prefix [ .. num_or_prefix]/: <m/statement/ ; [ ... ] }</cf>. The expression after
930 <cf>case</cf> can be of any type which can be on the left side of the ˜ operator and anything that could
931 be a member of a set is allowed before <cf/:/. Multiple commands are allowed without <cf/{}/ grouping.
932 If <cf><m/expr/</cf> matches one of the <cf/:/ clauses, statements between it and next <cf/:/ statement are executed. If <cf><m/expr/</cf> matches neither of the <cf/:/ clauses, the statements after <cf/else:/ are executed.
934 <p>Here is example that uses <cf/if/ and <cf/case/ structures:
938 2: print "two"; print "I can do more commands without {}";
939 3 .. 5: print "three to five";
940 else: print "something else";
943 if 1234 = i then printn "."; else {
945 print "You need {} around multiple commands";
949 <sect>Route attributes
951 <p>A filter is implicitly passed a route, and it can access its
952 attributes just like it accesses variables. Attempts to access undefined
953 attribute result in a runtime error; you can check if an attribute is
954 defined by using the <cf>defined( <m>attribute</m> )</cf> operator.
955 One notable exception to this rule are attributes of clist type, where
956 undefined value is regarded as empty clist for most purposes.
959 <tag><m/prefix/ net</tag>
960 Network the route is talking about. Read-only. (See the chapter about routing tables.)
962 <tag><m/enum/ scope</tag>
963 The scope of the route. Possible values: <cf/SCOPE_HOST/ for
964 routes local to this host, <cf/SCOPE_LINK/ for those specific
965 for a physical link, <cf/SCOPE_SITE/ and
966 <cf/SCOPE_ORGANIZATION/ for private routes and
967 <cf/SCOPE_UNIVERSE/ for globally visible routes. This
968 attribute is not interpreted by BIRD and can be used to mark
969 routes in filters. The default value for new routes is
972 <tag><m/int/ preference</tag>
973 Preference of the route. Valid values are 0-65535. (See the chapter about routing tables.)
975 <tag><m/ip/ from</tag>
976 The router which the route has originated from. Read-only.
979 Next hop packets routed using this route should be forwarded to.
981 <tag><m/string/ proto</tag>
982 The name of the protocol which the route has been imported from. Read-only.
984 <tag><m/enum/ source</tag>
985 what protocol has told me about this route. Possible values: <cf/RTS_DUMMY/, <cf/RTS_STATIC/, <cf/RTS_INHERIT/, <cf/RTS_DEVICE/, <cf/RTS_STATIC_DEVICE/, <cf/RTS_REDIRECT/, <cf/RTS_RIP/, <cf/RTS_OSPF/, <cf/RTS_OSPF_IA/, <cf/RTS_OSPF_EXT1/, <cf/RTS_OSPF_EXT2/, <cf/RTS_BGP/, <cf/RTS_PIPE/.
987 <tag><m/enum/ cast</tag>
989 Route type (Currently <cf/RTC_UNICAST/ for normal routes,
990 <cf/RTC_BROADCAST/, <cf/RTC_MULTICAST/, <cf/RTC_ANYCAST/ will
991 be used in the future for broadcast, multicast and anycast
994 <tag><m/enum/ dest</tag>
995 Type of destination the packets should be sent to (<cf/RTD_ROUTER/ for forwarding to a neighboring router, <cf/RTD_DEVICE/ for routing to a directly-connected network, <cf/RTD_BLACKHOLE/ for packets to be silently discarded, <cf/RTD_UNREACHABLE/, <cf/RTD_PROHIBIT/ for packets that should be returned with ICMP host unreachable / ICMP administratively prohibited messages). Read-only.
997 <tag><m/int/ igp_metric</tag>
998 The optional attribute that can be used to specify a distance
999 to the network for routes that do not have a native protocol
1000 metric attribute (like <cf/ospf_metric1/ for OSPF routes). It
1001 is used mainly by BGP to compare internal distances to boundary
1002 routers (see below). It is also used when the route is exported
1003 to OSPF as a default value for OSPF type 1 metric.
1006 <p>There also exist some protocol-specific attributes which are described in the corresponding protocol sections.
1008 <sect>Other statements
1010 <p>The following statements are available:
1013 <tag><m/variable/ = <m/expr/</tag> Set variable to a given value.
1015 <tag>accept|reject [ <m/expr/ ]</tag> Accept or reject the route, possibly printing <cf><m>expr</m></cf>.
1017 <tag>return <m/expr/</tag> Return <cf><m>expr</m></cf> from the current function, the function ends at this point.
1019 <tag>print|printn <m/expr/ [<m/, expr.../]</tag>
1020 Prints given expressions; useful mainly while debugging
1021 filters. The <cf/printn/ variant does not terminate the line.
1024 Terminates BIRD. Useful when debugging the filter interpreter.
1031 <p>The Border Gateway Protocol is the routing protocol used for backbone
1032 level routing in the today's Internet. Contrary to the other protocols, its convergence
1033 doesn't rely on all routers following the same rules for route selection,
1034 making it possible to implement any routing policy at any router in the
1035 network, the only restriction being that if a router advertises a route,
1036 it must accept and forward packets according to it.
1038 <p>BGP works in terms of autonomous systems (often abbreviated as
1039 AS). Each AS is a part of the network with common management and
1040 common routing policy. It is identified by a unique 16-bit number
1041 (ASN). Routers within each AS usually exchange AS-internal routing
1042 information with each other using an interior gateway protocol (IGP,
1043 such as OSPF or RIP). Boundary routers at the border of
1044 the AS communicate global (inter-AS) network reachability information with
1045 their neighbors in the neighboring AS'es via exterior BGP (eBGP) and
1046 redistribute received information to other routers in the AS via
1047 interior BGP (iBGP).
1049 <p>Each BGP router sends to its neighbors updates of the parts of its
1050 routing table it wishes to export along with complete path information
1051 (a list of AS'es the packet will travel through if it uses the particular
1052 route) in order to avoid routing loops.
1054 <p>BIRD supports all requirements of the BGP4 standard as defined in
1055 RFC 4271<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4271.txt">
1056 It also supports the community attributes
1057 (RFC 1997<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1997.txt">),
1058 capability negotiation
1059 (RFC 3392<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc3392.txt">),
1060 MD5 password authentication
1061 (RFC 2385<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2385.txt">),
1062 extended communities
1063 (RFC 4360<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4360.txt">),
1065 (RFC 4456<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4456.txt">),
1066 multiprotocol extensions
1067 (RFC 4760<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4760.txt">),
1069 (RFC 4893<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4893.txt">),
1070 and 4B AS numbers in extended communities
1071 (RFC 5668<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5668.txt">).
1074 For IPv6, it uses the standard multiprotocol extensions defined in
1075 RFC 2283<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2283.txt">
1076 including changes described in the
1077 latest draft<htmlurl url="ftp://ftp.rfc-editor.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-05.txt">
1078 and applied to IPv6 according to
1079 RFC 2545<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2545.txt">.
1081 <sect1>Route selection rules
1083 <p>BGP doesn't have any simple metric, so the rules for selection of an optimal
1084 route among multiple BGP routes with the same preference are a bit more complex
1085 and they are implemented according to the following algorithm. It starts the first
1086 rule, if there are more "best" routes, then it uses the second rule to choose
1087 among them and so on.
1090 <item>Prefer route with the highest Local Preference attribute.
1091 <item>Prefer route with the shortest AS path.
1092 <item>Prefer IGP origin over EGP and EGP origin over incomplete.
1093 <item>Prefer the lowest value of the Multiple Exit Discriminator.
1094 <item>Prefer routes received via eBGP over ones received via iBGP.
1095 <item>Prefer routes with lower internal distance to a boundary router.
1096 <item>Prefer the route with the lowest value of router ID of the
1100 <sect1>IGP routing table
1102 <p>BGP is mainly concerned with global network reachability and with
1103 routes to other autonomous systems. When such routes are redistributed
1104 to routers in the AS via BGP, they contain IP addresses of a boundary
1105 routers (in route attribute NEXT_HOP). BGP depends on existing IGP
1106 routing table with AS-internal routes to determine immediate next hops
1107 for routes and to know their internal distances to boundary routers
1108 for the purpose of BGP route selection. In BIRD, there is usually
1109 one routing table used for both IGP routes and BGP routes.
1111 <sect1>Configuration
1113 <p>Each instance of the BGP corresponds to one neighboring router.
1114 This allows to set routing policy and all the other parameters differently
1115 for each neighbor using the following configuration parameters:
1118 <tag>local [<m/ip/] as <m/number/</tag> Define which AS we
1119 are part of. (Note that contrary to other IP routers, BIRD is
1120 able to act as a router located in multiple AS'es
1121 simultaneously, but in such cases you need to tweak the BGP
1122 paths manually in the filters to get consistent behavior.)
1123 Optional <cf/ip/ argument specifies a source address,
1124 equivalent to the <cf/source address/ option (see below).
1125 This parameter is mandatory.
1127 <tag>neighbor <m/ip/ as <m/number/</tag> Define neighboring router
1128 this instance will be talking to and what AS it's located in. Unless
1129 you use the <cf/multihop/ clause, it must be directly connected to one
1130 of your router's interfaces. In case the neighbor is in the same AS
1131 as we are, we automatically switch to iBGP. This parameter is mandatory.
1133 <tag>multihop [<m/number/]</tag> Configure multihop BGP
1134 session to a neighbor that isn't directly connected.
1135 Accurately, this option should be used if the configured
1136 neighbor IP address does not match with any local network
1137 subnets. Such IP address have to be reachable through system
1138 routing table. For multihop BGP it is recommended to
1139 explicitly configure <cf/source address/ to have it
1140 stable. Optional <cf/number/ argument can be used to specify
1141 the number of hops (used for TTL). Note that the number of
1142 networks (edges) in a path is counted, i.e. if two BGP
1143 speakers are separated by one router, the number of hops is
1144 2. Default: switched off.
1146 <tag>source address <m/ip/</tag> Define local address we
1147 should use for next hop calculation and as a source address
1148 for the BGP session. Default: the address of the local
1149 end of the interface our neighbor is connected to.
1151 <tag>next hop self</tag> Avoid calculation of the Next Hop
1152 attribute and always advertise our own source address as a
1153 next hop. This needs to be used only occasionally to
1154 circumvent misconfigurations of other routers. Default:
1157 <tag>missing lladdr self|drop|ignore</tag>Next Hop attribute
1158 in BGP-IPv6 sometimes contains just the global IPv6 address,
1159 but sometimes it has to contain both global and link-local
1160 IPv6 addresses. This option specifies what to do if BIRD have
1161 to send both addresses but does not know link-local address.
1162 This situation might happen when routes from other protocols
1163 are exported to BGP, or when improper updates are received
1164 from BGP peers. <cf/self/ means that BIRD advertises its own
1165 local address instead. <cf/drop/ means that BIRD skips that
1166 prefixes and logs error. <cf/ignore/ means that BIRD ignores
1167 the problem and sends just the global address (and therefore
1168 forms improper BGP update). Default: <cf/self/, unless BIRD
1169 is configured as a route server (option <cf/rs client/), in
1170 that case default is <cf/ignore/, because route servers usually
1171 do not forward packets themselves.
1173 <tag>gateway direct|recursive</tag>For received routes, their
1174 <cf/gw/ (immediate next hop) attribute is computed from
1175 received <cf/bgp_next_hop/ attribute. This option specifies
1176 how it is computed. Direct mode means that the IP address from
1177 <cf/bgp_next_hop/ is used if it is directly reachable,
1178 otherwise the neighbor IP address is used. Recursive mode
1179 means that the gateway is computed by an IGP routing table
1180 lookup for the IP address from <cf/bgp_next_hop/. Recursive
1181 mode is the behavior specified by the BGP standard. Direct
1182 mode is simpler, does not require any routes in a routing
1183 table, and was used in older versions of BIRD, but does not
1184 handle well nontrivial iBGP setups and multihop. Default:
1185 <cf/direct/ for singlehop eBGP, <cf/recursive/ otherwise.
1187 <tag>igp table <m/name/</tag> Specifies a table that is used
1188 as an IGP routing table. Default: the same as the table BGP is
1191 <tag>ttl security <m/switch/</tag> Use GTSM (RFC 5082 - the
1192 generalized TTL security mechanism). GTSM protects against
1193 spoofed packets by ignoring received packets with a smaller
1194 than expected TTL. To work properly, GTSM have to be enabled
1195 on both sides of a BGP session. If both <cf/ttl security/ and
1196 <cf/multihop/ options are enabled, <cf/multihop/ option should
1197 specify proper hop value to compute expected TTL. Kernel
1198 support required: Linux: 2.6.34+ (IPv4), 2.6.35+ (IPv6), BSD:
1199 since long ago, IPv4 only. Note that full (ICMP protection,
1200 for example) RFC 5082 support is provided by Linux
1201 only. Default: disabled.
1203 <tag>password <m/string/</tag> Use this password for MD5 authentication
1204 of BGP sessions. Default: no authentication. Password has to be set by
1205 external utility (e.g. setkey(8)) on BSD systems.
1207 <tag>passive <m/switch/</tag> Standard BGP behavior is both
1208 initiating outgoing connections and accepting incoming
1209 connections. In passive mode, outgoing connections are not
1210 initiated. Default: off.
1212 <tag>rr client</tag> Be a route reflector and treat the neighbor as
1213 a route reflection client. Default: disabled.
1215 <tag>rr cluster id <m/IPv4 address/</tag> Route reflectors use cluster id
1216 to avoid route reflection loops. When there is one route reflector in a cluster
1217 it usually uses its router id as a cluster id, but when there are more route
1218 reflectors in a cluster, these need to be configured (using this option) to
1219 use a common cluster id. Clients in a cluster need not know their cluster
1220 id and this option is not allowed for them. Default: the same as router id.
1222 <tag>rs client</tag> Be a route server and treat the neighbor
1223 as a route server client. A route server is used as a
1224 replacement for full mesh EBGP routing in Internet exchange
1225 points in a similar way to route reflectors used in IBGP routing.
1226 BIRD does not implement obsoleted RFC 1863, but uses ad-hoc implementation,
1227 which behaves like plain EBGP but reduces modifications to advertised route
1228 attributes to be transparent (for example does not prepend its AS number to
1229 AS PATH attribute and keeps MED attribute). Default: disabled.
1231 <tag>enable route refresh <m/switch/</tag> When BGP speaker
1232 changes its import filter, it has to re-examine all routes
1233 received from its neighbor against the new filter. As these
1234 routes might not be available, there is a BGP protocol
1235 extension Route Refresh (specified in RFC 2918) that allows
1236 BGP speaker to request re-advertisement of all routes from its
1237 neighbor. This option specifies whether BIRD advertises this
1238 capability and accepts such requests. Even when disabled, BIRD
1239 can send route refresh requests. Default: on.
1241 <tag>interpret communities <m/switch/</tag> RFC 1997 demands
1242 that BGP speaker should process well-known communities like
1243 no-export (65535, 65281) or no-advertise (65535, 65282). For
1244 example, received route carrying a no-adverise community
1245 should not be advertised to any of its neighbors. If this
1246 option is enabled (which is by default), BIRD has such
1247 behavior automatically (it is evaluated when a route is
1248 exported to the BGP protocol just before the export filter).
1249 Otherwise, this integrated processing of well-known
1250 communities is disabled. In that case, similar behavior can be
1251 implemented in the export filter. Default: on.
1253 <tag>enable as4 <m/switch/</tag> BGP protocol was designed to use 2B AS numbers
1254 and was extended later to allow 4B AS number. BIRD supports 4B AS extension,
1255 but by disabling this option it can be persuaded not to advertise it and
1256 to maintain old-style sessions with its neighbors. This might be useful for
1257 circumventing bugs in neighbor's implementation of 4B AS extension.
1258 Even when disabled (off), BIRD behaves internally as AS4-aware BGP router.
1261 <tag>capabilities <m/switch/</tag> Use capability advertisement
1262 to advertise optional capabilities. This is standard behavior
1263 for newer BGP implementations, but there might be some older
1264 BGP implementations that reject such connection attempts.
1265 When disabled (off), features that request it (4B AS support)
1266 are also disabled. Default: on, with automatic fallback to
1267 off when received capability-related error.
1269 <tag>advertise ipv4 <m/switch/</tag> Advertise IPv4 multiprotocol capability.
1270 This is not a correct behavior according to the strict interpretation
1271 of RFC 4760, but it is widespread and required by some BGP
1272 implementations (Cisco and Quagga). This option is relevant
1273 to IPv4 mode with enabled capability advertisement only. Default: on.
1275 <tag>route limit <m/number/</tag> The maximal number of routes
1276 that may be imported from the protocol. If the route limit is
1277 exceeded, the connection is closed with error. Default: no limit.
1279 <tag>disable after error <m/switch/</tag> When an error is encountered (either
1280 locally or by the other side), disable the instance automatically
1281 and wait for an administrator to fix the problem manually. Default: off.
1283 <tag>hold time <m/number/</tag> Time in seconds to wait for a Keepalive
1284 message from the other side before considering the connection stale.
1285 Default: depends on agreement with the neighboring router, we prefer
1286 240 seconds if the other side is willing to accept it.
1288 <tag>startup hold time <m/number/</tag> Value of the hold timer used
1289 before the routers have a chance to exchange open messages and agree
1290 on the real value. Default: 240 seconds.
1292 <tag>keepalive time <m/number/</tag> Delay in seconds between sending
1293 of two consecutive Keepalive messages. Default: One third of the hold time.
1295 <tag>connect retry time <m/number/</tag> Time in seconds to wait before
1296 retrying a failed attempt to connect. Default: 120 seconds.
1298 <tag>start delay time <m/number/</tag> Delay in seconds between protocol
1299 startup and the first attempt to connect. Default: 5 seconds.
1301 <tag>error wait time <m/number/,<m/number/</tag> Minimum and maximum delay in seconds between a protocol
1302 failure (either local or reported by the peer) and automatic restart.
1303 Doesn't apply when <cf/disable after error/ is configured. If consecutive
1304 errors happen, the delay is increased exponentially until it reaches the maximum. Default: 60, 300.
1306 <tag>error forget time <m/number/</tag> Maximum time in seconds between two protocol
1307 failures to treat them as a error sequence which makes the <cf/error wait time/
1308 increase exponentially. Default: 300 seconds.
1310 <tag>path metric <m/switch/</tag> Enable comparison of path lengths
1311 when deciding which BGP route is the best one. Default: on.
1313 <tag>med metric <m/switch/</tag> Enable comparison of MED
1314 attributes (during best route selection) even between routes
1315 received from different ASes. This may be useful if all MED
1316 attributes contain some consistent metric, perhaps enforced in
1317 import filters of AS boundary routers. If this option is
1318 disabled, MED attributes are compared only if routes are
1319 received from the same AS (which is the standard behavior).
1322 <tag>deterministic med <m/switch/</tag> BGP route selection
1323 algorithm is often viewed as a comparison between individual
1324 routes (e.g. if a new route appears and is better than the
1325 current best one, it is chosen as the new best one). But the
1326 proper route selection, as specified by RFC 4271, cannot be
1327 fully implemented in that way. The problem is mainly in
1328 handling the MED attribute. BIRD, by default, uses an
1329 simplification based on individual route comparison, which in
1330 some cases may lead to temporally dependent behavior (i.e. the
1331 selection is dependent on the order in which routes appeared).
1332 This option enables a different (and slower) algorithm
1333 implementing proper RFC 4271 route selection, which is
1334 deterministic. Alternative way how to get deterministic
1335 behavior is to use <cf/med metric/ option. Default: off.
1337 <tag>igp metric <m/switch/</tag> Enable comparison of internal
1338 distances to boundary routers during best route selection. Default: on.
1340 <tag>prefer older <m/switch/</tag> Standard route selection algorithm
1341 breaks ties by comparing router IDs. This changes the behavior
1342 to prefer older routes (when both are external and from different
1343 peer). For details, see RFC 5004. Default: off.
1345 <tag>default bgp_med <m/number/</tag> Value of the Multiple Exit
1346 Discriminator to be used during route selection when the MED attribute
1347 is missing. Default: 0.
1349 <tag>default bgp_local_pref <m/number/</tag> A default value
1350 for the Local Preference attribute. It is used when a new
1351 Local Preference attribute is attached to a route by the BGP
1352 protocol itself (for example, if a route is received through
1353 eBGP and therefore does not have such attribute). Default: 100
1354 (0 in pre-1.2.0 versions of BIRD).
1359 <p>BGP defines several route attributes. Some of them (those marked with `<tt/I/' in the
1360 table below) are available on internal BGP connections only, some of them (marked
1361 with `<tt/O/') are optional.
1364 <tag>bgppath <cf/bgp_path/</tag> Sequence of AS numbers describing the AS path
1365 the packet will travel through when forwarded according to the particular route.
1366 In case of internal BGP it doesn't contain the number of the local AS.
1368 <tag>int <cf/bgp_local_pref/ [I]</tag> Local preference value used for
1369 selection among multiple BGP routes (see the selection rules above). It's
1370 used as an additional metric which is propagated through the whole local AS.
1372 <tag>int <cf/bgp_med/ [O]</tag> The Multiple Exit Discriminator of the route
1373 is an optional attribute which is used on external (inter-AS) links to
1374 convey to an adjacent AS the optimal entry point into the local AS.
1375 The received attribute is also propagated over internal BGP links.
1376 The attribute value is zeroed when a route is exported to an external BGP
1377 instance to ensure that the attribute received from a neighboring AS is
1378 not propagated to other neighboring ASes. A new value might be set in
1379 the export filter of an external BGP instance.
1380 See RFC 4451<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4451.txt">
1381 for further discussion of BGP MED attribute.
1383 <tag>enum <cf/bgp_origin/</tag> Origin of the route: either <cf/ORIGIN_IGP/
1384 if the route has originated in an interior routing protocol or
1385 <cf/ORIGIN_EGP/ if it's been imported from the <tt>EGP</tt> protocol
1386 (nowadays it seems to be obsolete) or <cf/ORIGIN_INCOMPLETE/ if the origin
1389 <tag>ip <cf/bgp_next_hop/</tag> Next hop to be used for forwarding of packets
1390 to this destination. On internal BGP connections, it's an address of the
1391 originating router if it's inside the local AS or a boundary router the
1392 packet will leave the AS through if it's an exterior route, so each BGP
1393 speaker within the AS has a chance to use the shortest interior path
1394 possible to this point.
1396 <tag>void <cf/bgp_atomic_aggr/ [O]</tag> This is an optional attribute
1397 which carries no value, but the sole presence of which indicates that the route
1398 has been aggregated from multiple routes by some router on the path from
1401 <!-- we don't handle aggregators right since they are of a very obscure type
1402 <tag>bgp_aggregator</tag>
1404 <tag>clist <cf/bgp_community/ [O]</tag> List of community values associated
1405 with the route. Each such value is a pair (represented as a <cf/pair/ data
1406 type inside the filters) of 16-bit integers, the first of them containing the number of the AS which defines
1407 the community and the second one being a per-AS identifier. There are lots
1408 of uses of the community mechanism, but generally they are used to carry
1409 policy information like "don't export to USA peers". As each AS can define
1410 its own routing policy, it also has a complete freedom about which community
1411 attributes it defines and what will their semantics be.
1413 <tag>eclist <cf/bgp_ext_community/ [O]</tag> List of extended community
1414 values associated with the route. Extended communities have similar usage
1415 as plain communities, but they have an extended range (to allow 4B ASNs)
1416 and a nontrivial structure with a type field. Individual community values are
1417 represented using an <cf/ec/ data type inside the filters.
1419 <tag>quad <cf/bgp_originator_id/ [I, O]</tag> This attribute is created by the
1420 route reflector when reflecting the route and contains the router ID of the
1421 originator of the route in the local AS.
1423 <tag>clist <cf/bgp_cluster_list/ [I, O]</tag> This attribute contains a list
1424 of cluster IDs of route reflectors. Each route reflector prepends its
1425 cluster ID when reflecting the route.
1432 local as 65000; # Use a private AS number
1433 neighbor 198.51.100.130 as 64496; # Our neighbor ...
1434 multihop; # ... which is connected indirectly
1435 export filter { # We use non-trivial export rules
1436 if source = RTS_STATIC then { # Export only static routes
1437 # Assign our community
1438 bgp_community.add((65000,64501));
1439 # Artificially increase path length
1440 # by advertising local AS number twice
1441 if bgp_path ~ [= 65000 =] then
1442 bgp_path.prepend(65000);
1448 source address 198.51.100.14; # Use a non-standard source address
1454 <p>The Device protocol is not a real routing protocol. It doesn't generate
1455 any routes and it only serves as a module for getting information about network
1456 interfaces from the kernel.
1458 <p>Except for very unusual circumstances, you probably should include
1459 this protocol in the configuration since almost all other protocols
1460 require network interfaces to be defined for them to work with.
1462 <sect1>Configuration
1465 <tag>scan time <m/number/</tag> Time in seconds between two scans
1466 of the network interface list. On systems where we are notified about
1467 interface status changes asynchronously (such as newer versions of
1468 Linux), we need to scan the list only in order to avoid confusion by lost
1469 notification messages, so the default time is set to a large value.
1471 <tag>primary [ "<m/mask/" ] <m/prefix/</tag>
1472 If a network interface has more than one network address, BIRD
1473 has to choose one of them as a primary one. By default, BIRD
1474 chooses the lexicographically smallest address as the primary
1477 This option allows to specify which network address should be
1478 chosen as a primary one. Network addresses that match
1479 <m/prefix/ are preferred to non-matching addresses. If more
1480 <cf/primary/ options are used, the first one has the highest
1481 preference. If "<m/mask/" is specified, then such
1482 <cf/primary/ option is relevant only to matching network
1485 In all cases, an address marked by operating system as
1486 secondary cannot be chosen as the primary one.
1489 <p>As the Device protocol doesn't generate any routes, it cannot have
1490 any attributes. Example configuration looks like this:
1494 scan time 10; # Scan the interfaces often
1495 primary "eth0" 192.168.1.1;
1496 primary 192.168.0.0/16;
1502 <p>The Direct protocol is a simple generator of device routes for all the
1503 directly connected networks according to the list of interfaces provided
1504 by the kernel via the Device protocol.
1506 <p>The question is whether it is a good idea to have such device
1507 routes in BIRD routing table. OS kernel usually handles device routes
1508 for directly connected networks by itself so we don't need (and don't
1509 want) to export these routes to the kernel protocol. OSPF protocol
1510 creates device routes for its interfaces itself and BGP protocol is
1511 usually used for exporting aggregate routes. Although there are some
1512 use cases that use the direct protocol (like abusing eBGP as an IGP
1513 routing protocol), in most cases it is not needed to have these device
1514 routes in BIRD routing table and to use the direct protocol.
1516 <p>The only configurable thing about direct is what interfaces it watches:
1519 <tag>interface <m/pattern [, ...]/</tag> By default, the Direct
1520 protocol will generate device routes for all the interfaces
1521 available. If you want to restrict it to some subset of interfaces
1522 (for example if you're using multiple routing tables for policy
1523 routing and some of the policy domains don't contain all interfaces),
1524 just use this clause.
1527 <p>Direct device routes don't contain any specific attributes.
1529 <p>Example config might look like this:
1533 interface "-arc*", "*"; # Exclude the ARCnets
1539 <p>The Kernel protocol is not a real routing protocol. Instead of communicating
1540 with other routers in the network, it performs synchronization of BIRD's routing
1541 tables with the OS kernel. Basically, it sends all routing table updates to the kernel
1542 and from time to time it scans the kernel tables to see whether some routes have
1543 disappeared (for example due to unnoticed up/down transition of an interface)
1544 or whether an `alien' route has been added by someone else (depending on the
1545 <cf/learn/ switch, such routes are either ignored or accepted to our
1548 <p>Unfortunately, there is one thing that makes the routing table
1549 synchronization a bit more complicated. In the kernel routing table
1550 there are also device routes for directly connected networks. These
1551 routes are usually managed by OS itself (as a part of IP address
1552 configuration) and we don't want to touch that. They are completely
1553 ignored during the scan of the kernel tables and also the export of
1554 device routes from BIRD tables to kernel routing tables is restricted
1555 to prevent accidental interference. This restriction can be disabled using
1556 <cf/device routes/ switch.
1558 <p>If your OS supports only a single routing table, you can configure
1559 only one instance of the Kernel protocol. If it supports multiple
1560 tables (in order to allow policy routing; such an OS is for example
1561 Linux), you can run as many instances as you want, but each of them
1562 must be connected to a different BIRD routing table and to a different
1565 <p>Because the kernel protocol is partially integrated with the
1566 connected routing table, there are two limitations - it is not
1567 possible to connect more kernel protocols to the same routing table
1568 and changing route attributes (even the kernel ones) in an export
1569 filter of a kernel protocol does not work. Both limitations can be
1570 overcome using another routing table and the pipe protocol.
1572 <sect1>Configuration
1575 <tag>persist <m/switch/</tag> Tell BIRD to leave all its routes in the
1576 routing tables when it exits (instead of cleaning them up).
1577 <tag>scan time <m/number/</tag> Time in seconds between two consecutive scans of the
1578 kernel routing table.
1579 <tag>learn <m/switch/</tag> Enable learning of routes added to the kernel
1580 routing tables by other routing daemons or by the system administrator.
1581 This is possible only on systems which support identification of route
1584 <tag>device routes <m/switch/</tag> Enable export of device
1585 routes to the kernel routing table. By default, such routes
1586 are rejected (with the exception of explicitly configured
1587 device routes from the static protocol) regardless of the
1588 export filter to protect device routes in kernel routing table
1589 (managed by OS itself) from accidental overwriting or erasing.
1591 <tag>kernel table <m/number/</tag> Select which kernel table should
1592 this particular instance of the Kernel protocol work with. Available
1593 only on systems supporting multiple routing tables.
1598 <p>The Kernel protocol defines several attributes. These attributes
1599 are translated to appropriate system (and OS-specific) route attributes.
1600 We support these attributes:
1603 <tag>ip <cf/krt_prefsrc/</tag> (Linux) The preferred source address.
1604 Used in source address selection for outgoing packets. Have to
1605 be one of IP addresses of the router.
1607 <tag>int <cf/krt_realm/</tag> (Linux) The realm of the route. Can be
1608 used for traffic classification.
1613 <p>A simple configuration can look this way:
1621 <p>Or for a system with two routing tables:
1624 protocol kernel { # Primary routing table
1625 learn; # Learn alien routes from the kernel
1626 persist; # Don't remove routes on bird shutdown
1627 scan time 10; # Scan kernel routing table every 10 seconds
1632 protocol kernel { # Secondary routing table
1643 <p>Open Shortest Path First (OSPF) is a quite complex interior gateway
1644 protocol. The current IPv4 version (OSPFv2) is defined in RFC
1645 2328<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2328.txt"> and
1646 the current IPv6 version (OSPFv3) is defined in RFC 5340<htmlurl
1647 url="ftp://ftp.rfc-editor.org/in-notes/rfc5340.txt"> It's a link state
1648 (a.k.a. shortest path first) protocol -- each router maintains a
1649 database describing the autonomous system's topology. Each participating
1650 router has an identical copy of the database and all routers run the
1651 same algorithm calculating a shortest path tree with themselves as a
1652 root. OSPF chooses the least cost path as the best path.
1654 <p>In OSPF, the autonomous system can be split to several areas in order
1655 to reduce the amount of resources consumed for exchanging the routing
1656 information and to protect the other areas from incorrect routing data.
1657 Topology of the area is hidden to the rest of the autonomous system.
1659 <p>Another very important feature of OSPF is that
1660 it can keep routing information from other protocols (like Static or BGP)
1661 in its link state database as external routes. Each external route can
1662 be tagged by the advertising router, making it possible to pass additional
1663 information between routers on the boundary of the autonomous system.
1665 <p>OSPF quickly detects topological changes in the autonomous system (such
1666 as router interface failures) and calculates new loop-free routes after a short
1667 period of convergence. Only a minimal amount of
1668 routing traffic is involved.
1670 <p>Each router participating in OSPF routing periodically sends Hello messages
1671 to all its interfaces. This allows neighbors to be discovered dynamically.
1672 Then the neighbors exchange theirs parts of the link state database and keep it
1673 identical by flooding updates. The flooding process is reliable and ensures
1674 that each router detects all changes.
1676 <sect1>Configuration
1678 <p>In the main part of configuration, there can be multiple definitions of
1679 OSPF areas, each with a different id. These definitions includes many other
1680 switches and multiple definitions of interfaces. Definition of interface
1681 may contain many switches and constant definitions and list of neighbors
1682 on nonbroadcast networks.
1685 protocol ospf <name> {
1686 rfc1583compat <switch>;
1688 ecmp <switch> [limit <num>];
1692 summary <switch>;
1693 default nssa <switch>;
1694 default cost <num>;
1695 default cost2 <num>;
1696 translator <switch>;
1697 translator stability <num>;
1701 <prefix> hidden;
1705 <prefix> hidden;
1706 <prefix> tag <num>;
1708 stubnet <prefix>;
1709 stubnet <prefix> {
1710 hidden <switch>;
1711 summary <switch>;
1714 interface <interface pattern> {
1716 stub <switch>;
1719 retransmit <num>;
1720 priority <num>;
1722 dead count <num>;
1724 rx buffer [normal|large|<num>];
1725 type [broadcast|bcast|pointopoint|ptp|
1726 nonbroadcast|nbma|pointomultipoint|ptmp];
1727 strict nonbroadcast <switch>;
1728 check link <switch>;
1729 ecmp weight <num>;
1730 authentication [none|simple|cryptographic];
1731 password "<text>";
1732 password "<text>" {
1734 generate from "<date>";
1735 generate to "<date>";
1736 accept from "<date>";
1737 accept to "<date>";
1741 <ip> eligible;
1744 virtual link <id> {
1746 retransmit <num>;
1748 dead count <num>;
1750 authentication [none|simple|cryptographic];
1751 password "<text>";
1758 <tag>rfc1583compat <M>switch</M></tag>
1759 This option controls compatibility of routing table
1760 calculation with RFC 1583<htmlurl
1761 url="ftp://ftp.rfc-editor.org/in-notes/rfc1583.txt">. Default
1764 <tag>tick <M>num</M></tag>
1765 The routing table calculation and clean-up of areas' databases
1766 is not performed when a single link state
1767 change arrives. To lower the CPU utilization, it's processed later
1768 at periodical intervals of <m/num/ seconds. The default value is 1.
1770 <tag>ecmp <M>switch</M> [limit <M>number</M>]</tag>
1771 This option specifies whether OSPF is allowed to generate
1772 ECMP (equal-cost multipath) routes. Such routes are used when
1773 there are several directions to the destination, each with
1774 the same (computed) cost. This option also allows to specify
1775 a limit on maximal number of nexthops in one route. By
1776 default, ECMP is disabled. If enabled, default value of the
1779 <tag>area <M>id</M></tag>
1780 This defines an OSPF area with given area ID (an integer or an IPv4
1781 address, similarly to a router ID). The most important area is
1782 the backbone (ID 0) to which every other area must be connected.
1785 This option configures the area to be a stub area. External
1786 routes are not flooded into stub areas. Also summary LSAs can be
1787 limited in stub areas (see option <cf/summary/).
1788 By default, the area is not a stub area.
1791 This option configures the area to be a NSSA (Not-So-Stubby
1792 Area). NSSA is a variant of a stub area which allows a
1793 limited way of external route propagation. Global external
1794 routes are not propagated into a NSSA, but an external route
1795 can be imported into NSSA as a (area-wide) NSSA-LSA (and
1796 possibly translated and/or aggregated on area boundary).
1797 By default, the area is not NSSA.
1799 <tag>summary <M>switch</M></tag>
1800 This option controls propagation of summary LSAs into stub or
1801 NSSA areas. If enabled, summary LSAs are propagated as usual,
1802 otherwise just the default summary route (0.0.0.0/0) is
1803 propagated (this is sometimes called totally stubby area). If
1804 a stub area has more area boundary routers, propagating
1805 summary LSAs could lead to more efficient routing at the cost
1806 of larger link state database. Default value is no.
1808 <tag>default nssa <M>switch</M></tag>
1809 When <cf/summary/ option is enabled, default summary route is
1810 no longer propagated to the NSSA. In that case, this option
1811 allows to originate default route as NSSA-LSA to the NSSA.
1812 Default value is no.
1814 <tag>default cost <M>num</M></tag>
1815 This option controls the cost of a default route propagated to
1816 stub and NSSA areas. Default value is 1000.
1818 <tag>default cost2 <M>num</M></tag>
1819 When a default route is originated as NSSA-LSA, its cost
1820 can use either type 1 or type 2 metric. This option allows
1821 to specify the cost of a default route in type 2 metric.
1822 By default, type 1 metric (option <cf/default cost/) is used.
1824 <tag>translator <M>switch</M></tag>
1825 This option controls translation of NSSA-LSAs into external
1826 LSAs. By default, one translator per NSSA is automatically
1827 elected from area boundary routers. If enabled, this area
1828 boundary router would unconditionally translate all NSSA-LSAs
1829 regardless of translator election. Default value is no.
1831 <tag>translator stability <M>num</M></tag>
1832 This option controls the translator stability interval (in
1833 seconds). When the new translator is elected, the old one
1834 keeps translating until the interval is over. Default value
1837 <tag>networks { <m/set/ }</tag>
1838 Definition of area IP ranges. This is used in summary LSA origination.
1839 Hidden networks are not propagated into other areas.
1841 <tag>external { <m/set/ }</tag>
1842 Definition of external area IP ranges for NSSAs. This is used
1843 for NSSA-LSA translation. Hidden networks are not translated
1844 into external LSAs. Networks can have configured route tag.
1846 <tag>stubnet <m/prefix/ { <m/options/ }</tag>
1847 Stub networks are networks that are not transit networks
1848 between OSPF routers. They are also propagated through an
1849 OSPF area as a part of a link state database. By default,
1850 BIRD generates a stub network record for each primary network
1851 address on each OSPF interface that does not have any OSPF
1852 neighbors, and also for each non-primary network address on
1853 each OSPF interface. This option allows to alter a set of
1854 stub networks propagated by this router.
1856 Each instance of this option adds a stub network with given
1857 network prefix to the set of propagated stub network, unless
1858 option <cf/hidden/ is used. It also suppresses default stub
1859 networks for given network prefix. When option
1860 <cf/summary/ is used, also default stub networks that are
1861 subnetworks of given stub network are suppressed. This might
1862 be used, for example, to aggregate generated stub networks.
1864 <tag>interface <M>pattern</M></tag>
1865 Defines that the specified interfaces belong to the area being defined.
1866 See <ref id="dsc-iface" name="interface"> common option for detailed description.
1868 <tag>virtual link <M>id</M></tag>
1869 Virtual link to router with the router id. Virtual link acts as a
1870 point-to-point interface belonging to backbone. The actual area is
1871 used as transport area. This item cannot be in the backbone.
1873 <tag>cost <M>num</M></tag>
1874 Specifies output cost (metric) of an interface. Default value is 10.
1876 <tag>stub <M>switch</M></tag>
1877 If set to interface it does not listen to any packet and does not send
1878 any hello. Default value is no.
1880 <tag>hello <M>num</M></tag>
1881 Specifies interval in seconds between sending of Hello messages. Beware, all
1882 routers on the same network need to have the same hello interval.
1883 Default value is 10.
1885 <tag>poll <M>num</M></tag>
1886 Specifies interval in seconds between sending of Hello messages for
1887 some neighbors on NBMA network. Default value is 20.
1889 <tag>retransmit <M>num</M></tag>
1890 Specifies interval in seconds between retransmissions of unacknowledged updates.
1893 <tag>priority <M>num</M></tag>
1894 On every multiple access network (e.g., the Ethernet) Designed Router
1895 and Backup Designed router are elected. These routers have some
1896 special functions in the flooding process. Higher priority increases
1897 preferences in this election. Routers with priority 0 are not
1898 eligible. Default value is 1.
1900 <tag>wait <M>num</M></tag>
1901 After start, router waits for the specified number of seconds between starting
1902 election and building adjacency. Default value is 40.
1904 <tag>dead count <M>num</M></tag>
1905 When the router does not receive any messages from a neighbor in
1906 <m/dead count/*<m/hello/ seconds, it will consider the neighbor down.
1908 <tag>dead <M>num</M></tag>
1909 When the router does not receive any messages from a neighbor in
1910 <m/dead/ seconds, it will consider the neighbor down. If both directives
1911 <m/dead count/ and <m/dead/ are used, <m/dead/ has precendence.
1913 <tag>rx buffer <M>num</M></tag>
1914 This sets the size of buffer used for receiving packets. The buffer should
1915 be bigger than maximal size of any packets. Value NORMAL (default)
1916 means 2*MTU, value LARGE means maximal allowed packet - 65535.
1918 <tag>type broadcast|bcast</tag>
1919 BIRD detects a type of a connected network automatically, but
1920 sometimes it's convenient to force use of a different type
1921 manually. On broadcast networks (like ethernet), flooding
1922 and Hello messages are sent using multicasts (a single packet
1923 for all the neighbors). A designated router is elected and it
1924 is responsible for synchronizing the link-state databases and
1925 originating network LSAs. This network type cannot be used on
1926 physically NBMA networks and on unnumbered networks (networks
1927 without proper IP prefix).
1929 <tag>type pointopoint|ptp</tag>
1930 Point-to-point networks connect just 2 routers together. No
1931 election is performed and no network LSA is originated, which
1932 makes it simpler and faster to establish. This network type
1933 is useful not only for physically PtP ifaces (like PPP or
1934 tunnels), but also for broadcast networks used as PtP links.
1935 This network type cannot be used on physically NBMA networks.
1937 <tag>type nonbroadcast|nbma</tag>
1938 On NBMA networks, the packets are sent to each neighbor
1939 separately because of lack of multicast capabilities.
1940 Like on broadcast networks, a designated router is elected,
1941 which plays a central role in propagation of LSAs.
1942 This network type cannot be used on unnumbered networks.
1944 <tag>type pointomultipoint|ptmp</tag>
1945 This is another network type designed to handle NBMA
1946 networks. In this case the NBMA network is treated as a
1947 collection of PtP links. This is useful if not every pair of
1948 routers on the NBMA network has direct communication, or if
1949 the NBMA network is used as an (possibly unnumbered) PtP
1952 <tag>strict nonbroadcast <M>switch</M></tag>
1953 If set, don't send hello to any undefined neighbor. This switch
1954 is ignored on other than NBMA or PtMP networks. Default value is no.
1956 <tag>check link <M>switch</M></tag>
1957 If set, a hardware link state (reported by OS) is taken into
1958 consideration. When a link disappears (e.g. an ethernet cable is
1959 unplugged), neighbors are immediately considered unreachable
1960 and only the address of the iface (instead of whole network
1961 prefix) is propagated. It is possible that some hardware
1962 drivers or platforms do not implement this feature. Default value is no.
1964 <tag>ecmp weight <M>num</M></tag>
1965 When ECMP (multipath) routes are allowed, this value specifies
1966 a relative weight used for nexthops going through the iface.
1967 Allowed values are 1-256. Default value is 1.
1969 <tag>authentication none</tag>
1970 No passwords are sent in OSPF packets. This is the default value.
1972 <tag>authentication simple</tag>
1973 Every packet carries 8 bytes of password. Received packets
1974 lacking this password are ignored. This authentication mechanism is
1977 <tag>authentication cryptographic</tag>
1978 16-byte long MD5 digest is appended to every packet. For the digest
1979 generation 16-byte long passwords are used. Those passwords are
1980 not sent via network, so this mechanism is quite secure.
1981 Packets can still be read by an attacker.
1983 <tag>password "<M>text</M>"</tag>
1984 An 8-byte or 16-byte password used for authentication.
1985 See <ref id="dsc-pass" name="password"> common option for detailed description.
1987 <tag>neighbors { <m/set/ } </tag>
1988 A set of neighbors to which Hello messages on NBMA or PtMP
1989 networks are to be sent. For NBMA networks, some of them
1990 could be marked as eligible.
1996 <p>OSPF defines four route attributes. Each internal route has a <cf/metric/.
1997 Metric is ranging from 1 to infinity (65535).
1998 External routes use <cf/metric type 1/ or <cf/metric type 2/.
1999 A <cf/metric of type 1/ is comparable with internal <cf/metric/, a
2000 <cf/metric of type 2/ is always longer
2001 than any <cf/metric of type 1/ or any <cf/internal metric/.
2002 <cf/Internal metric/ or <cf/metric of type 1/ is stored in attribute
2003 <cf/ospf_metric1/, <cf/metric type 2/ is stored in attribute <cf/ospf_metric2/.
2004 If you specify both metrics only metric1 is used.
2006 Each external route can also carry attribute <cf/ospf_tag/ which is a
2007 32-bit integer which is used when exporting routes to other protocols;
2008 otherwise, it doesn't affect routing inside the OSPF domain at all.
2009 The fourth attribute <cf/ospf_router_id/ is a router ID of the router
2010 advertising that route/network. This attribute is read-only. Default
2011 is <cf/ospf_metric2 = 10000/ and <cf/ospf_tag = 0/.
2018 protocol ospf MyOSPF {
2022 if source = RTS_BGP then {
2034 authentication simple;
2039 authentication cryptographic;
2042 generate to "22-04-2003 11:00:06";
2043 accept from "17-01-2001 12:01:05";
2047 generate to "22-07-2005 17:03:21";
2048 accept from "22-02-2001 11:34:06";
2061 172.16.2.0/24 hidden;
2063 interface "-arc0" , "arc*" {
2065 authentication none;
2066 strict nonbroadcast yes;
2071 192.168.120.1 eligible;
2084 <p>The Pipe protocol serves as a link between two routing tables, allowing routes to be
2085 passed from a table declared as primary (i.e., the one the pipe is connected to using the
2086 <cf/table/ configuration keyword) to the secondary one (declared using <cf/peer table/)
2087 and vice versa, depending on what's allowed by the filters. Export filters control export
2088 of routes from the primary table to the secondary one, import filters control the opposite
2091 <p>The Pipe protocol may work in the transparent mode mode or in the opaque mode.
2092 In the transparent mode, the Pipe protocol retransmits all routes from
2093 one table to the other table, retaining their original source and
2094 attributes. If import and export filters are set to accept, then both
2095 tables would have the same content. The transparent mode is the default mode.
2097 <p>In the opaque mode, the Pipe protocol retransmits optimal route
2098 from one table to the other table in a similar way like other
2099 protocols send and receive routes. Retransmitted route will have the
2100 source set to the Pipe protocol, which may limit access to protocol
2101 specific route attributes. This mode is mainly for compatibility, it
2102 is not suggested for new configs. The mode can be changed by
2105 <p>The primary use of multiple routing tables and the Pipe protocol is for policy routing,
2106 where handling of a single packet doesn't depend only on its destination address, but also
2107 on its source address, source interface, protocol type and other similar parameters.
2108 In many systems (Linux being a good example), the kernel allows to enforce routing policies
2109 by defining routing rules which choose one of several routing tables to be used for a packet
2110 according to its parameters. Setting of these rules is outside the scope of BIRD's work
2111 (on Linux, you can use the <tt/ip/ command), but you can create several routing tables in BIRD,
2112 connect them to the kernel ones, use filters to control which routes appear in which tables
2113 and also you can employ the Pipe protocol for exporting a selected subset of one table to
2116 <sect1>Configuration
2119 <tag>peer table <m/table/</tag> Defines secondary routing table to connect to. The
2120 primary one is selected by the <cf/table/ keyword.
2122 <tag>mode opaque|transparent</tag> Specifies the mode for the pipe to work in. Default is opaque.
2127 <p>The Pipe protocol doesn't define any route attributes.
2131 <p>Let's consider a router which serves as a boundary router of two different autonomous
2132 systems, each of them connected to a subset of interfaces of the router, having its own
2133 exterior connectivity and wishing to use the other AS as a backup connectivity in case
2134 of outage of its own exterior line.
2136 <p>Probably the simplest solution to this situation is to use two routing tables (we'll
2137 call them <cf/as1/ and <cf/as2/) and set up kernel routing rules, so that packets having
2138 arrived from interfaces belonging to the first AS will be routed according to <cf/as1/
2139 and similarly for the second AS. Thus we have split our router to two logical routers,
2140 each one acting on its own routing table, having its own routing protocols on its own
2141 interfaces. In order to use the other AS's routes for backup purposes, we can pass
2142 the routes between the tables through a Pipe protocol while decreasing their preferences
2143 and correcting their BGP paths to reflect the AS boundary crossing.
2146 table as1; # Define the tables
2149 protocol kernel kern1 { # Synchronize them with the kernel
2154 protocol kernel kern2 {
2159 protocol bgp bgp1 { # The outside connections
2162 neighbor 192.168.0.1 as 1001;
2170 neighbor 10.0.0.1 as 1002;
2175 protocol pipe { # The Pipe
2179 if net ~ [ 1.0.0.0/8+] then { # Only AS1 networks
2180 if preference>10 then preference = preference-10;
2181 if source=RTS_BGP then bgp_path.prepend(1);
2187 if net ~ [ 2.0.0.0/8+] then { # Only AS2 networks
2188 if preference>10 then preference = preference-10;
2189 if source=RTS_BGP then bgp_path.prepend(2);
2201 <p>The RAdv protocol is an implementation of Router Advertisements,
2202 which are used in the IPv6 stateless autoconfiguration. IPv6 routers
2203 send (in irregular time intervals or as an answer to a request)
2204 advertisement packets to connected networks. These packets contain
2205 basic information about a local network (e.g. a list of network
2206 prefixes), which allows network hosts to autoconfigure network
2207 addresses and choose a default route. BIRD implements router behavior
2208 as defined in RFC 4861<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4861.txt">.
2210 <sect1>Configuration
2212 <p>There are two classes of definitions in RAdv configuration --
2213 interface definitions and prefix definitions:
2216 <tag>interface <m/pattern [, ...]/ { <m/options/ }</tag>
2217 Interface definitions specify a set of interfaces on which the
2218 protocol is activated and contain interface specific options.
2219 See <ref id="dsc-iface" name="interface"> common options for
2220 detailed description.
2222 <tag>prefix <m/prefix/ { <m/options/ }</tag>
2223 Prefix definitions allows to modify a list of advertised
2224 prefixes. By default, the advertised prefixes are the same as
2225 the network prefixes assigned to the interface. For each
2226 network prefix, the matching prefix definition is found and
2227 its options are used. If no matching prefix definition is
2228 found, the prefix is used with default options.
2230 Prefix definitions can be either global or interface-specific.
2231 The second ones are part of interface options. The prefix
2232 definition matching is done in the first-match style, when
2233 interface-specific definitions are processed before global
2234 definitions. As expected, the prefix definition is matching if
2235 the network prefix is a subnet of the prefix in prefix
2239 <p>Interface specific options:
2242 <tag>max ra interval <m/expr/</tag>
2243 Unsolicited router advertisements are sent in irregular time
2244 intervals. This option specifies the maximum length of these
2245 intervals, in seconds. Valid values are 4-1800. Default: 600
2247 <tag>min ra interval <m/expr/</tag>
2248 This option specifies the minimum length of that intervals, in
2249 seconds. Must be at least 3 and at most 3/4 * max ra interval.
2250 Default: about 1/3 * max ra interval.
2252 <tag>min delay <m/expr/</tag>
2253 The minimum delay between two consecutive router advertisements,
2254 in seconds. Default: 3
2256 <tag>managed <m/switch/</tag>
2257 This option specifies whether hosts should use DHCPv6 for
2258 IP address configuration. Default: no
2260 <tag>other config <m/switch/</tag>
2261 This option specifies whether hosts should use DHCPv6 to
2262 receive other configuration information. Default: no
2264 <tag>link mtu <m/expr/</tag>
2265 This option specifies which value of MTU should be used by
2266 hosts. 0 means unspecified. Default: 0
2268 <tag>reachable time <m/expr/</tag>
2269 This option specifies the time (in milliseconds) how long
2270 hosts should assume a neighbor is reachable (from the last
2271 confirmation). Maximum is 3600000, 0 means unspecified.
2274 <tag>retrans timer <m/expr/</tag>
2275 This option specifies the time (in milliseconds) how long
2276 hosts should wait before retransmitting Neighbor Solicitation
2277 messages. 0 means unspecified. Default 0.
2279 <tag>current hop limit <m/expr/</tag>
2280 This option specifies which value of Hop Limit should be used
2281 by hosts. Valid values are 0-255, 0 means unspecified. Default: 64
2283 <tag>default lifetime <m/expr/</tag>
2284 This option specifies the time (in seconds) how long (after
2285 the receipt of RA) hosts may use the router as a default
2286 router. 0 means do not use as a default router. Default: 3 *
2291 <p>Prefix specific options:
2294 <tag>onlink <m/switch/</tag>
2295 This option specifies whether hosts may use the advertised
2296 prefix for onlink determination. Default: yes
2298 <tag>autonomous <m/switch/</tag>
2299 This option specifies whether hosts may use the advertised
2300 prefix for stateless autoconfiguration. Default: yes
2302 <tag>valid lifetime <m/expr/</tag>
2303 This option specifies the time (in seconds) how long (after
2304 the receipt of RA) the prefix information is valid, i.e.,
2305 autoconfigured IP addresses can be assigned and hosts with
2306 that IP addresses are considered directly reachable. 0 means
2307 the prefix is no longer valid. Default: 86400 (1 day)
2309 <tag>preferred lifetime <m/expr/</tag>
2310 This option specifies the time (in seconds) how long (after
2311 the receipt of RA) IP addresses generated from the prefix
2312 using stateless autoconfiguration remain preferred. Default:
2321 max ra interval 5; # Fast failover with more routers
2322 managed yes; # Using DHCPv6 on eth2
2324 autonomous off; # So do not autoconfigure any IP
2328 interface "eth*"; # No need for any other options
2330 prefix 2001:0DB8:1234::/48 {
2331 preferred lifetime 0; # Deprecated address range
2334 prefix 2001:0DB8:2000::/48 {
2335 autonomous off; # Do not autoconfigure
2344 <p>The RIP protocol (also sometimes called Rest In Pieces) is a simple protocol, where each router broadcasts (to all its neighbors)
2345 distances to all networks it can reach. When a router hears distance to another network, it increments
2346 it and broadcasts it back. Broadcasts are done in regular intervals. Therefore, if some network goes
2347 unreachable, routers keep telling each other that its distance is the original distance plus 1 (actually, plus
2348 interface metric, which is usually one). After some time, the distance reaches infinity (that's 15 in
2349 RIP) and all routers know that network is unreachable. RIP tries to minimize situations where
2350 counting to infinity is necessary, because it is slow. Due to infinity being 16, you can't use
2351 RIP on networks where maximal distance is higher than 15 hosts. You can read more about RIP at <HTMLURL
2352 URL="http://www.ietf.org/html.charters/rip-charter.html" name="http://www.ietf.org/html.charters/rip-charter.html">. Both IPv4
2353 (RFC 1723<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1723.txt">)
2354 and IPv6 (RFC 2080<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2080.txt">) versions of RIP are supported by BIRD, historical RIPv1 (RFC 1058<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1058.txt">)is
2355 not currently supported. RIPv4 MD5 authentication (RFC 2082<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2082.txt">) is supported.
2357 <p>RIP is a very simple protocol, and it has a lot of shortcomings. Slow
2358 convergence, big network load and inability to handle larger networks
2359 makes it pretty much obsolete. (It is still usable on very small networks.)
2361 <sect1>Configuration
2363 <p>In addition to options common for all to other protocols, RIP supports the following ones:
2366 <tag/authentication none|plaintext|md5/ selects authentication method to be used. <cf/none/ means that
2367 packets are not authenticated at all, <cf/plaintext/ means that a plaintext password is embedded
2368 into each packet, and <cf/md5/ means that packets are authenticated using a MD5 cryptographic
2369 hash. If you set authentication to not-none, it is a good idea to add <cf>password</cf>
2370 section. Default: none.
2372 <tag>honor always|neighbor|never </tag>specifies when should requests for dumping routing table
2373 be honored. (Always, when sent from a host on a directly connected
2374 network or never.) Routing table updates are honored only from
2375 neighbors, that is not configurable. Default: never.
2378 <p>There are two options that can be specified per-interface. First is <cf>metric</cf>, with
2379 default one. Second is <cf>mode multicast|broadcast|quiet|nolisten|version1</cf>, it selects mode for
2380 rip to work in. If nothing is specified, rip runs in multicast mode. <cf>version1</cf> is
2381 currently equivalent to <cf>broadcast</cf>, and it makes RIP talk to a broadcast address even
2382 through multicast mode is possible. <cf>quiet</cf> option means that RIP will not transmit
2383 any periodic messages to this interface and <cf>nolisten</cf> means that RIP will send to this
2384 interface but not listen to it.
2386 <p>The following options generally override behavior specified in RFC. If you use any of these
2387 options, BIRD will no longer be RFC-compliant, which means it will not be able to talk to anything
2388 other than equally configured BIRD. I have warned you.
2391 <tag>port <M>number</M></tag>
2392 selects IP port to operate on, default 520. (This is useful when testing BIRD, if you
2393 set this to an address >1024, you will not need to run bird with UID==0).
2395 <tag>infinity <M>number</M></tag>
2396 selects the value of infinity, default is 16. Bigger values will make protocol convergence
2399 <tag>period <M>number</M>
2400 </tag>specifies the number of seconds between periodic updates. Default is 30 seconds. A lower
2401 number will mean faster convergence but bigger network
2402 load. Do not use values lower than 10.
2404 <tag>timeout time <M>number</M>
2405 </tag>specifies how old route has to be to be considered unreachable. Default is 4*<cf/period/.
2407 <tag>garbage time <M>number</M>
2408 </tag>specifies how old route has to be to be discarded. Default is 10*<cf/period/.
2413 <p>RIP defines two route attributes:
2416 <tag>int <cf/rip_metric/</tag> RIP metric of the route (ranging from 0 to <cf/infinity/).
2417 When routes from different RIP instances are available and all of them have the same
2418 preference, BIRD prefers the route with lowest <cf/rip_metric/.
2419 When importing a non-RIP route, the metric defaults to 5.
2421 <tag>int <cf/rip_tag/</tag> RIP route tag: a 16-bit number which can be used
2422 to carry additional information with the route (for example, an originating AS number
2423 in case of external routes). When importing a non-RIP route, the tag defaults to 0.
2429 protocol rip MyRIP_test {
2434 interface "eth0" { metric 3; mode multicast; };
2435 interface "eth*" { metric 2; mode broadcast; };
2437 authentication none;
2438 import filter { print "importing"; accept; };
2439 export filter { print "exporting"; accept; };
2445 <p>The Static protocol doesn't communicate with other routers in the network,
2446 but instead it allows you to define routes manually. This is often used for
2447 specifying how to forward packets to parts of the network which don't use
2448 dynamic routing at all and also for defining sink routes (i.e., those
2449 telling to return packets as undeliverable if they are in your IP block,
2450 you don't have any specific destination for them and you don't want to send
2451 them out through the default route to prevent routing loops).
2453 <p>There are five types of static routes: `classical' routes telling
2454 to forward packets to a neighboring router, multipath routes
2455 specifying several (possibly weighted) neighboring routers, device
2456 routes specifying forwarding to hosts on a directly connected network,
2457 recursive routes computing their nexthops by doing route table lookups
2458 for a given IP and special routes (sink, blackhole etc.) which specify
2459 a special action to be done instead of forwarding the packet.
2461 <p>When the particular destination is not available (the interface is down or
2462 the next hop of the route is not a neighbor at the moment), Static just
2463 uninstalls the route from the table it is connected to and adds it again as soon
2464 as the destination becomes adjacent again.
2466 <p>The Static protocol does not have many configuration options. The
2467 definition of the protocol contains mainly a list of static routes:
2470 <tag>route <m/prefix/ via <m/ip/</tag> Static route through
2471 a neighboring router.
2472 <tag>route <m/prefix/ multipath via <m/ip/ [weight <m/num/] [via ...]</tag>
2473 Static multipath route. Contains several nexthops (gateways), possibly
2475 <tag>route <m/prefix/ via <m/"interface"/</tag> Static device
2476 route through an interface to hosts on a directly connected network.
2477 <tag>route <m/prefix/ recursive <m/ip/</tag> Static recursive route,
2478 its nexthop depends on a route table lookup for given IP address.
2479 <tag>route <m/prefix/ drop|reject|prohibit</tag> Special routes
2480 specifying to drop the packet, return it as unreachable or return
2481 it as administratively prohibited.
2483 <tag>check link <m/switch/</tag>
2484 If set, hardware link states of network interfaces are taken
2485 into consideration. When link disappears (e.g. ethernet cable
2486 is unplugged), static routes directing to that interface are
2487 removed. It is possible that some hardware drivers or
2488 platforms do not implement this feature. Default: off.
2490 <tag>igp table <m/name/</tag> Specifies a table that is used
2491 for route table lookups of recursive routes. Default: the
2492 same table as the protocol is connected to.
2495 <p>Static routes have no specific attributes.
2497 <p>Example static config might look like this:
2501 table testable; # Connect to a non-default routing table
2502 route 0.0.0.0/0 via 198.51.100.130; # Default route
2503 route 10.0.0.0/8 multipath # Multipath route
2504 via 198.51.100.10 weight 2
2507 route 203.0.113.0/24 reject; # Sink route
2508 route 10.2.0.0/24 via "arc0"; # Secondary network
2516 <p>Although BIRD supports all the commonly used routing protocols,
2517 there are still some features which would surely deserve to be
2518 implemented in future versions of BIRD:
2522 <item>Route aggregation and flap dampening
2523 <item>Multipath routes
2524 <item>Multicast routing protocols
2525 <item>Ports to other systems
2528 <sect>Getting more help
2530 <p>If you use BIRD, you're welcome to join the bird-users mailing list
2531 (<HTMLURL URL="mailto:bird-users@bird.network.cz" name="bird-users@bird.network.cz">)
2532 where you can share your experiences with the other users and consult
2533 your problems with the authors. To subscribe to the list, just send a
2534 <tt/subscribe bird-users/ command in a body of a mail to
2535 (<HTMLURL URL="mailto:majordomo@bird.network.cz" name="majordomo@bird.network.cz">).
2536 The home page of BIRD can be found at <HTMLURL URL="http://bird.network.cz/" name="http://bird.network.cz/">.
2538 <p>BIRD is a relatively young system and it probably contains some
2539 bugs. You can report any problems to the bird-users list and the authors
2540 will be glad to solve them, but before you do so,
2541 please make sure you have read the available documentation and that you are running the latest version (available at <HTMLURL
2542 URL="ftp://bird.network.cz/pub/bird" name="bird.network.cz:/pub/bird">). (Of course, a patch
2543 which fixes the bug is always welcome as an attachment.)
2545 <p>If you want to understand what is going inside, Internet standards are
2546 a good and interesting reading. You can get them from <HTMLURL URL="ftp://ftp.rfc-editor.org/" name="ftp.rfc-editor.org"> (or a nicely sorted version from <HTMLURL URL="ftp://atrey.karlin.mff.cuni.cz/pub/rfc" name="atrey.karlin.mff.cuni.cz:/pub/rfc">).
2553 LocalWords: GPL IPv GateD BGPv RIPv OSPFv Linux sgml html dvi sgmltools Pavel
2554 LocalWords: linuxdoc dtd descrip config conf syslog stderr auth ospf bgp Mbps
2555 LocalWords: router's eval expr num birdc ctl UNIX if's enums bool int ip GCC
2556 LocalWords: len ipaddress pxlen netmask enum bgppath bgpmask clist gw md eth
2557 LocalWords: RTS printn quitbird iBGP AS'es eBGP RFC multiprotocol IGP Machek
2558 LocalWords: EGP misconfigurations keepalive pref aggr aggregator BIRD's RTC
2559 LocalWords: OS'es AS's multicast nolisten misconfigured UID blackhole MRTD MTU
2560 LocalWords: uninstalls ethernets IP binutils ANYCAST anycast dest RTD ICMP rfc
2561 LocalWords: compat multicasts nonbroadcast pointopoint loopback sym stats
2562 LocalWords: Perl SIGHUP dd mm yy HH MM SS EXT IA UNICAST multihop Discriminator txt
2563 LocalWords: proto wildcard Ondrej Filip