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
218 in the network. Note that although most protocols are interested
219 in receiving just selected routes, some protocols (e.g. the <cf/Pipe/
220 protocol) receive and process all entries in routing tables (accepted
223 <p><label id="dsc-sorted">Usually, a routing table just chooses a
224 selected route from a list of entries for one network. But if the
225 <cf/sorted/ option is activated, these lists of entries are kept
226 completely sorted (according to preference or some protocol-dependent
229 This is needed for some features of some protocols
230 (e.g. <cf/secondary/ option of BGP protocol, which allows to accept
231 not just a selected route, but the first route (in the sorted list)
232 that is accepted by filters), but it is incompatible with some other
233 features (e.g. <cf/deterministic med/ option of BGP protocol, which
234 activates a way of choosing selected route that cannot be described
235 using comparison and ordering). Minor advantage is that routes are
236 shown sorted in <cf/show route/, minor disadvantage is that it is
237 slightly more computationally expensive.
244 <p>BIRD is configured using a text configuration file. Upon startup, BIRD reads <it/prefix/<file>/etc/bird.conf</file> (unless the
245 <tt/-c/ command line option is given). Configuration may be changed at user's request: if you modify
246 the config file and then signal BIRD with <tt/SIGHUP/, it will adjust to the new
247 config. Then there's the client
248 which allows you to talk with BIRD in an extensive way.
250 <p>In the config, everything on a line after <cf/#/ or inside <cf>/*
251 */</cf> is a comment, whitespace characters are treated as a single space. If there's a variable number of options, they are grouped using
252 the <cf/{ }/ brackets. Each option is terminated by a <cf/;/. Configuration
255 <p>Here is an example of a simple config file. It enables
256 synchronization of routing tables with OS kernel, scans for
257 new network interfaces every 10 seconds and runs RIP on all network interfaces found.
262 persist; # Don't remove routes on BIRD shutdown
263 scan time 20; # Scan kernel routing table every 20 seconds
264 export all; # Default is export none
268 scan time 10; # Scan interfaces every 10 seconds
282 <tag>include "<m/filename/"</tag>
283 This statement causes inclusion of a new file. The maximal depth is set to 5.
285 <tag>log "<m/filename/"|syslog [name <m/name/]|stderr all|{ <m/list of classes/ }</tag>
286 Set logging of messages having the given class (either <cf/all/ or <cf/{
287 error, trace }/ etc.) into selected destination (a file specified as a filename string,
288 syslog with optional name argument, or the stderr output). Classes are:
289 <cf/info/, <cf/warning/, <cf/error/ and <cf/fatal/ for messages about local problems,
290 <cf/debug/ for debugging messages,
291 <cf/trace/ when you want to know what happens in the network,
292 <cf/remote/ for messages about misbehavior of remote machines,
293 <cf/auth/ about authentication failures,
294 <cf/bug/ for internal BIRD bugs. You may specify more than one <cf/log/ line to establish logging to multiple
295 destinations. Default: log everything to the system log.
297 <tag>debug protocols all|off|{ states, routes, filters, interfaces, events, packets }</tag>
298 Set global defaults of protocol debugging options. See <cf/debug/ in the following section. Default: off.
300 <tag>debug commands <m/number/</tag>
301 Control logging of client connections (0 for no logging, 1 for
302 logging of connects and disconnects, 2 and higher for logging of
303 all client commands). Default: 0.
305 <tag>mrtdump "<m/filename/"</tag>
306 Set MRTdump file name. This option must be specified to allow MRTdump feature.
307 Default: no dump file.
309 <tag>mrtdump protocols all|off|{ states, messages }</tag>
310 Set global defaults of MRTdump options. See <cf/mrtdump/ in the following section.
313 <tag>filter <m/name local variables/{ <m/commands/ }</tag> Define a filter. You can learn more about filters
314 in the following chapter.
316 <tag>function <m/name/ (<m/parameters/) <m/local variables/ { <m/commands/ }</tag> Define a function. You can learn more
317 about functions in the following chapter.
319 <tag>protocol rip|ospf|bgp|... [<m/name/ [from <m/name2/]] { <m>protocol options</m> }</tag>
320 Define a protocol instance called <cf><m/name/</cf> (or with a name like "rip5" generated
321 automatically if you don't specify any <cf><m/name/</cf>). You can learn more about
322 configuring protocols in their own chapters. When <cf>from <m/name2/</cf> expression is
323 used, initial protocol options are taken from protocol or template <cf><m/name2/</cf>
324 You can run more than one instance of most protocols (like RIP or BGP). By default, no
325 instances are configured.
327 <tag>template rip|bgp|... [<m/name/ [from <m/name2/]] { <m>protocol options</m> }</tag>
328 Define a protocol template instance called <cf><m/name/</cf> (or with a name like "bgp1"
329 generated automatically if you don't specify any <cf><m/name/</cf>). Protocol templates can
330 be used to group common options when many similarly configured protocol instances are to be
331 defined. Protocol instances (and other templates) can use templates by using <cf/from/
332 expression and the name of the template. At the moment templates (and <cf/from/ expression)
333 are not implemented for OSPF protocol.
335 <tag>define <m/constant/ = (<m/expression/)|<m/number/|<m/IP address/</tag>
336 Define a constant. You can use it later in every place you could use a simple integer or an IP address.
337 Besides, there are some predefined numeric constants based on /etc/iproute2/rt_* files.
338 A list of defined constants can be seen (together with other symbols) using 'show symbols' command.
340 <tag>router id <m/IPv4 address/</tag>
341 Set BIRD's router ID. It's a world-wide unique identification
342 of your router, usually one of router's IPv4 addresses.
343 Default: in IPv4 version, the lowest IP address of a
344 non-loopback interface. In IPv6 version, this option is
347 <tag>router id from [-] [ "<m/mask/" ] [ <m/prefix/ ] [, ...]</tag>
348 Set BIRD's router ID based on an IP address of an interface
349 specified by an interface pattern. The option is applicable
350 for IPv4 version only. See <ref id="dsc-iface" name="interface">
351 section for detailed description of interface patterns.
353 <tag>listen bgp [address <m/address/] [port <m/port/] [dual]</tag>
354 This option allows to specify address and port where BGP
355 protocol should listen. It is global option as listening
356 socket is common to all BGP instances. Default is to listen on
357 all addresses (0.0.0.0) and port 179. In IPv6 mode, option
358 <cf/dual/ can be used to specify that BGP socket should accept
359 both IPv4 and IPv6 connections (but even in that case, BIRD
360 would accept IPv6 routes only). Such behavior was default in
361 older versions of BIRD.
363 <tag>timeformat route|protocol|base|log "<m/format1/" [<m/limit/ "<m/format2/"]</tag>
364 This option allows to specify a format of date/time used by
365 BIRD. The first argument specifies for which purpose such
366 format is used. <cf/route/ is a format used in 'show route'
367 command output, <cf/protocol/ is used in 'show protocols'
368 command output, <cf/base/ is used for other commands and
369 <cf/log/ is used in a log file.
371 "<m/format1/" is a format string using <it/strftime(3)/
372 notation (see <it/man strftime/ for details). <m/limit> and
373 "<m/format2/" allow to specify the second format string for
374 times in past deeper than <m/limit/ seconds. There are two
375 shorthands: <cf/iso long/ is a ISO 8601 date/time format
376 (YYYY-MM-DD hh:mm:ss) that can be also specified using <cf/"%F
377 %T"/. <cf/iso short/ is a variant of ISO 8601 that uses just
378 the time format (hh:mm:ss) for near times (up to 20 hours in
379 the past) and the date format (YYYY-MM-DD) for far times. This
380 is a shorthand for <cf/"%T" 72000 "%F"/.
382 By default, BIRD uses an short, ad-hoc format for <cf/route/
383 and <cf/protocol/ times, and a <cf/iso long/ similar format
384 (DD-MM-YYYY hh:mm:ss) for <cf/base/ and <cf/log/. These
385 defaults are here for a compatibility with older versions
386 and might change in the future.
388 <tag>table <m/name/ [sorted]</tag>
389 Create a new routing table. The default routing table is
390 created implicitly, other routing tables have to be added by
391 this command. Option <cf/sorted/ can be used to enable
392 sorting of routes, see <ref id="dsc-sorted" name="sorted table">
393 description for details.
395 <tag>roa table <m/name/ [ { roa table options ... } ]</tag>
396 Create a new ROA (Route Origin Authorization) table. ROA
397 tables can be used to validate route origination of BGP
398 routes. A ROA table contains ROA entries, each consist of a
399 network prefix, a max prefix length and an AS number. A ROA
400 entry specifies prefixes which could be originated by that AS
401 number. ROA tables could be filled with data from RPKI (RFC
402 6480) or from public databases like Whois. ROA tables are
403 examined by <cf/roa_check()/ operator in filters.
405 Currently, there is just one option,
406 <cf>roa <m/prefix/ max <m/num/ as <m/num/</cf>, which
407 can be used to populate the ROA table with static ROA
408 entries. The option may be used multiple times. Other entries
409 can be added dynamically by <cf/add roa/ command.
411 <tag>eval <m/expr/</tag> Evaluates given filter expression. It
412 is used by us for testing of filters.
415 <sect>Protocol options
417 <p>For each protocol instance, you can configure a bunch of options.
418 Some of them (those described in this section) are generic, some are
419 specific to the protocol (see sections talking about the protocols).
421 <p>Several options use a <cf><m/switch/</cf> argument. It can be either
422 <cf/on/, <cf/yes/ or a numeric expression with a non-zero value for the
423 option to be enabled or <cf/off/, <cf/no/ or a numeric expression evaluating
424 to zero to disable it. An empty <cf><m/switch/</cf> is equivalent to <cf/on/
425 ("silence means agreement").
428 <tag>preference <m/expr/</tag> Sets the preference of routes generated by this protocol. Default: protocol dependent.
430 <tag>disabled <m/switch/</tag> Disables the protocol. You can change the disable/enable status from the command
431 line interface without needing to touch the configuration. Disabled protocols are not activated. Default: protocol is enabled.
433 <tag>debug all|off|{ states, routes, filters, interfaces, events, packets }</tag>
434 Set protocol debugging options. If asked, each protocol is capable of
435 writing trace messages about its work to the log (with category
436 <cf/trace/). You can either request printing of <cf/all/ trace messages
437 or only of the types selected: <cf/states/ for protocol state changes
438 (protocol going up, down, starting, stopping etc.),
439 <cf/routes/ for routes exchanged with the routing table,
440 <cf/filters/ for details on route filtering,
441 <cf/interfaces/ for interface change events sent to the protocol,
442 <cf/events/ for events internal to the protocol and
443 <cf/packets/ for packets sent and received by the protocol. Default: off.
445 <tag>mrtdump all|off|{ states, messages }</tag>
447 Set protocol MRTdump flags. MRTdump is a standard binary
448 format for logging information from routing protocols and
449 daemons. These flags control what kind of information is
450 logged from the protocol to the MRTdump file (which must be
451 specified by global <cf/mrtdump/ option, see the previous
452 section). Although these flags are similar to flags of
453 <cf/debug/ option, their meaning is different and
454 protocol-specific. For BGP protocol, <cf/states/ logs BGP
455 state changes and <cf/messages/ logs received BGP messages.
456 Other protocols does not support MRTdump yet.
458 <tag>router id <m/IPv4 address/</tag> This option can be used
459 to override global router id for a given protocol. Default:
460 uses global router id.
462 <tag>import all | none | filter <m/name/ | filter { <m/filter commands/ } | where <m/filter expression/</tag>
463 Specify a filter to be used for filtering routes coming from
464 the protocol to the routing table. <cf/all/ is shorthand for
465 <cf/where true/ and <cf/none/ is shorthand for
466 <cf/where false/. Default: <cf/all/.
468 <tag>export <m/filter/</tag>
469 This is similar to the <cf>import</cf> keyword, except that it
470 works in the direction from the routing table to the protocol.
473 <tag>import keep filtered <m/bool/</tag>
474 Usually, if an import filter rejects a route, the route is
475 forgotten. When this option is active, these routes are
476 kept in the routing table, but they are hidden and not
477 propagated to other protocols. But it is possible to show them
478 using <cf/show route filtered/. Note that this option does not
479 work for the pipe protocol. Default: off.
481 <tag>import limit [<m/number/ | off ] [action warn | block | restart | disable]</tag>
482 Specify an import route limit (a maximum number of routes
483 imported from the protocol) and optionally the action to be
484 taken when the limit is hit. Warn action just prints warning
485 log message. Block action discards new routes coming from the
486 protocol. Restart and disable actions shut the protocol down
487 like appropriate commands. Disable is the default action if an
488 action is not explicitly specified. Note that limits are reset
489 during protocol reconfigure, reload or restart. Default: <cf/off/.
491 <tag>receive limit [<m/number/ | off ] [action warn | block | restart | disable]</tag>
492 Specify an receive route limit (a maximum number of routes
493 received from the protocol and remembered). It works almost
494 identically to <cf>import limit</cf> option, the only
495 difference is that if <cf/import keep filtered/ option is
496 active, filtered routes are counted towards the limit and
497 blocked routes are forgotten, as the main purpose of the
498 receive limit is to protect routing tables from
499 overflow. Import limit, on the contrary, counts accepted
500 routes only and routes blocked by the limit are handled like
501 filtered routes. Default: <cf/off/.
503 <tag>export limit [ <m/number/ | off ] [action warn | block | restart | disable]</tag>
504 Specify an export route limit, works similarly to
505 the <cf>import limit</cf> option, but for the routes exported
506 to the protocol. This option is experimental, there are some
507 problems in details of its behavior -- the number of exported
508 routes can temporarily exceed the limit without triggering it
509 during protocol reload, exported routes counter ignores route
510 blocking and block action also blocks route updates of already
511 accepted routes -- and these details will probably change in
512 the future. Default: <cf/off/.
514 <tag>description "<m/text/"</tag> This is an optional
515 description of the protocol. It is displayed as a part of the
516 output of 'show route all' command.
518 <tag>table <m/name/</tag> Connect this protocol to a non-default routing table.
521 <p>There are several options that give sense only with certain protocols:
524 <tag><label id="dsc-iface">interface [-] [ "<m/mask/" ] [ <m/prefix/ ] [, ...] [ { <m/option/ ; [...] } ]</tag>
526 Specifies a set of interfaces on which the protocol is activated with
527 given interface-specific options. A set of interfaces specified by one
528 interface option is described using an interface pattern. The
529 interface pattern consists of a sequence of clauses (separated by
530 commas), each clause may contain a mask, a prefix, or both of them. An
531 interface matches the clause if its name matches the mask (if
532 specified) and its address matches the prefix (if specified). Mask is
533 specified as shell-like pattern. For IPv6, the prefix part of a clause
534 is generally ignored and interfaces are matched just by their name.
536 An interface matches the pattern if it matches any of its
537 clauses. If the clause begins with <cf/-/, matching interfaces are
538 excluded. Patterns are parsed left-to-right, thus
539 <cf/interface "eth0", -"eth*", "*";/ means eth0 and all
542 An interface option can be used more times with different
543 interfaces-specific options, in that case for given interface
544 the first matching interface option is used.
546 This option is allowed in Direct, OSPF, RIP and RAdv protocols,
547 but in OSPF protocol it is used in <cf/area/ subsection.
553 <cf>interface "*" { type broadcast; };</cf> - start the protocol on all interfaces with
554 <cf>type broadcast</cf> option.
556 <cf>interface "eth1", "eth4", "eth5" { type ptp; };</cf> - start the protocol
557 on enumerated interfaces with <cf>type ptp</cf> option.
559 <cf>interface -192.168.1.0/24, 192.168.0.0/16;</cf> - start the protocol on all
560 interfaces that have address from 192.168.0.0/16, but not
563 <cf>interface -192.168.1.0/24, 192.168.0.0/16;</cf> - start the protocol on all
564 interfaces that have address from 192.168.0.0/16, but not
567 <cf>interface "eth*" 192.168.1.0/24;</cf> - start the protocol on all
568 ethernet interfaces that have address from 192.168.1.0/24.
570 <tag><label id="dsc-prio">tx class|dscp <m/num/</tag>
571 This option specifies the value of ToS/DS/Class field in IP
572 headers of the outgoing protocol packets. This may affect how the
573 protocol packets are processed by the network relative to the
574 other network traffic. With <cf/class/ keyword, the value
575 (0-255) is used for the whole ToS/Class octet (but two bits
576 reserved for ECN are ignored). With <cf/dscp/ keyword, the
577 value (0-63) is used just for the DS field in the
578 octet. Default value is 0xc0 (DSCP 0x30 - CS6).
580 <tag>tx priority <m/num/</tag>
581 This option specifies the local packet priority. This may
582 affect how the protocol packets are processed in the local TX
583 queues. This option is Linux specific. Default value is 7
584 (highest priority, privileged traffic).
586 <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>
587 Specifies a password that can be used by the protocol. Password option can
588 be used more times to specify more passwords. If more passwords are
589 specified, it is a protocol-dependent decision which one is really
590 used. Specifying passwords does not mean that authentication is
591 enabled, authentication can be enabled by separate, protocol-dependent
592 <cf/authentication/ option.
594 This option is allowed in OSPF and RIP protocols. BGP has also
595 <cf/password/ option, but it is slightly different and described
601 <p>Password option can contain section with some (not necessary all) password sub-options:
604 <tag>id <M>num</M></tag>
605 ID of the password, (0-255). If it's not used, BIRD will choose
606 ID based on an order of the password item in the interface. For
607 example, second password item in one interface will have default
608 ID 2. ID is used by some routing protocols to identify which
609 password was used to authenticate protocol packets.
611 <tag>generate from "<m/time/"</tag>
612 The start time of the usage of the password for packet signing.
613 The format of <cf><m/time/</cf> is <tt>dd-mm-yyyy HH:MM:SS</tt>.
615 <tag>generate to "<m/time/"</tag>
616 The last time of the usage of the password for packet signing.
618 <tag>accept from "<m/time/"</tag>
619 The start time of the usage of the password for packet verification.
621 <tag>accept to "<m/time/"</tag>
622 The last time of the usage of the password for packet verification.
625 <chapt>Remote control
627 <p>You can use the command-line client <file>birdc</file> to talk with
628 a running BIRD. Communication is done using a <file/bird.ctl/ UNIX
629 domain socket (unless changed with the <tt/-s/ option given to both
630 the server and the client). The commands can perform simple actions
631 such as enabling/disabling of protocols, telling BIRD to show various
632 information, telling it to show routing table filtered by filter, or
633 asking BIRD to reconfigure. Press <tt/?/ at any time to get online
634 help. Option <tt/-r/ can be used to enable a restricted mode of BIRD
635 client, which allows just read-only commands (<cf/show .../). Option
636 <tt/-v/ can be passed to the client, to make it dump numeric return
637 codes along with the messages. You do not necessarily need to use
638 <file/birdc/ to talk to BIRD, your own applications could do that, too
639 -- the format of communication between BIRD and <file/birdc/ is stable
640 (see the programmer's documentation).
642 <p>There is also lightweight variant of BIRD client called
643 <file/birdcl/, which does not support command line editing and history
644 and has minimal dependencies. This is useful for running BIRD in
645 resource constrained environments, where Readline library (required
646 for regular BIRD client) is not available.
648 <p>Many commands have the <m/name/ of the protocol instance as an argument.
649 This argument can be omitted if there exists only a single instance.
651 <p>Here is a brief list of supported functions:
654 <tag>dump resources|sockets|interfaces|neighbors|attributes|routes|protocols</tag>
655 Dump contents of internal data structures to the debugging output.
657 <tag>show status</tag>
658 Show router status, that is BIRD version, uptime and time from last reconfiguration.
660 <tag>show protocols [all]</tag>
661 Show list of protocol instances along with tables they are connected to and protocol status, possibly giving verbose information, if <cf/all/ is specified.
663 <tag>show ospf interface [<m/name/] ["<m/interface/"]</tag>
664 Show detailed information about OSPF interfaces.
666 <tag>show ospf neighbors [<m/name/] ["<m/interface/"]</tag>
667 Show a list of OSPF neighbors and a state of adjacency to them.
669 <tag>show ospf state [all] [<m/name/]</tag>
670 Show detailed information about OSPF areas based on a content
671 of the link-state database. It shows network topology, stub
672 networks, aggregated networks and routers from other areas and
673 external routes. The command shows information about reachable
674 network nodes, use option <cf/all/ to show information about
675 all network nodes in the link-state database.
677 <tag>show ospf topology [all] [<m/name/]</tag>
678 Show a topology of OSPF areas based on a content of the
679 link-state database. It is just a stripped-down version of
682 <tag>show ospf lsadb [global | area <m/id/ | link] [type <m/num/] [lsid <m/id/] [self | router <m/id/] [<m/name/] </tag>
683 Show contents of an OSPF LSA database. Options could be used to filter entries.
685 <tag>show static [<m/name/]</tag>
686 Show detailed information about static routes.
688 <tag>show interfaces [summary]</tag>
689 Show the list of interfaces. For each interface, print its type, state, MTU and addresses assigned.
691 <tag>show symbols [table|filter|function|protocol|template|roa|<m/symbol/]</tag>
692 Show the list of symbols defined in the configuration (names of protocols, routing tables etc.).
694 <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>
695 Show contents of a routing table (by default of the main one or
696 the table attached to a respective protocol),
697 that is routes, their metrics and (in case the <cf/all/ switch is given)
698 all their attributes.
700 <p>You can specify a <m/prefix/ if you want to print routes for a
701 specific network. If you use <cf>for <m/prefix or IP/</cf>, you'll get
702 the entry which will be used for forwarding of packets to the given
703 destination. By default, all routes for each network are printed with
704 the selected one at the top, unless <cf/primary/ is given in which case
705 only the selected route is shown.
707 <p>You can also ask for printing only routes processed and accepted by
708 a given filter (<cf>filter <m/name/</cf> or <cf>filter { <m/filter/ }
709 </cf> or matching a given condition (<cf>where <m/condition/</cf>).
710 The <cf/export/ and <cf/preexport/ switches ask for printing of entries
711 that are exported to the specified protocol. With <cf/preexport/, the
712 export filter of the protocol is skipped.
714 <p>You can also select just routes added by a specific protocol.
715 <cf>protocol <m/p/</cf>.
717 <p>If BIRD is configured to keep filtered routes (see <cf/import keep filtered/
718 option), you can show them instead of routes by using <cf/filtered/ switch.
720 <p>The <cf/stats/ switch requests showing of route statistics (the
721 number of networks, number of routes before and after filtering). If
722 you use <cf/count/ instead, only the statistics will be printed.
724 <tag>show roa [<m/prefix/ | in <m/prefix/ | for <m/prefix/] [as <m/num/] [table <m/t/>]</tag>
725 Show contents of a ROA table (by default of the first one).
726 You can specify a <m/prefix/ to print ROA entries for a
727 specific network. If you use <cf>for <m/prefix/</cf>, you'll
728 get all entries relevant for route validation of the network
729 prefix; i.e., ROA entries whose prefixes cover the network
730 prefix. Or you can use <cf>in <m/prefix/</cf> to get ROA entries
731 covered by the network prefix. You could also use <cf/as/ option
732 to show just entries for given AS.
734 <tag>add roa <m/prefix/ max <m/num/] as <m/num/ [table <m/t/>]</tag>
735 Add a new ROA entry to a ROA table. Such entry is called
736 <it/dynamic/ compared to <it/static/ entries specified in the
737 config file. These dynamic entries survive reconfiguration.
739 <tag>delete roa <m/prefix/ max <m/num/] as <m/num/ [table <m/t/>]</tag>
740 Delete the specified ROA entry from a ROA table. Only dynamic
741 ROA entries (i.e., the ones added by <cf/add roa/ command) can
744 <tag>flush roa [table <m/t/>]</tag>
745 Remove all dynamic ROA entries from a ROA table.
747 <tag>configure [soft] ["<m/config file/"] [timeout [<m/num/]]</tag>
748 Reload configuration from a given file. BIRD will smoothly
749 switch itself to the new configuration, protocols are
750 reconfigured if possible, restarted otherwise. Changes in
751 filters usually lead to restart of affected protocols.
753 If <cf/soft/ option is used, changes in filters does not cause
754 BIRD to restart affected protocols, therefore already accepted
755 routes (according to old filters) would be still propagated,
756 but new routes would be processed according to the new
759 If <cf/timeout/ option is used, config timer is activated. The
760 new configuration could be either confirmed using
761 <cf/configure confirm/ command, or it will be reverted to the
762 old one when the config timer expires. This is useful for cases
763 when reconfiguration breaks current routing and a router becames
764 inaccessible for an administrator. The config timeout expiration is
765 equivalent to <cf/configure undo/ command. The timeout duration
766 could be specified, default is 300 s.
768 <tag>configure confirm</tag>
769 Deactivate the config undo timer and therefore confirm the current
772 <tag>configure undo</tag>
773 Undo the last configuration change and smoothly switch back to
774 the previous (stored) configuration. If the last configuration
775 change was soft, the undo change is also soft. There is only
776 one level of undo, but in some specific cases when several
777 reconfiguration requests are given immediately in a row and
778 the intermediate ones are skipped then the undo also skips them back.
780 <tag>configure check ["<m/config file/"]</tag>
781 Read and parse given config file, but do not use it. useful
782 for checking syntactic and some semantic validity of an config
785 <tag>enable|disable|restart <m/name/|"<m/pattern/"|all</tag>
786 Enable, disable or restart a given protocol instance,
787 instances matching the <cf><m/pattern/</cf> or
790 <tag>reload [in|out] <m/name/|"<m/pattern/"|all</tag>
792 Reload a given protocol instance, that means re-import routes
793 from the protocol instance and re-export preferred routes to
794 the instance. If <cf/in/ or <cf/out/ options are used, the
795 command is restricted to one direction (re-import or
798 This command is useful if appropriate filters have changed but
799 the protocol instance was not restarted (or reloaded),
800 therefore it still propagates the old set of routes. For example
801 when <cf/configure soft/ command was used to change filters.
803 Re-export always succeeds, but re-import is protocol-dependent
804 and might fail (for example, if BGP neighbor does not support
805 route-refresh extension). In that case, re-export is also
806 skipped. Note that for the pipe protocol, both directions are
807 always reloaded together (<cf/in/ or <cf/out/ options are
808 ignored in that case).
813 <tag>debug <m/protocol/|<m/pattern/|all all|off|{ states | routes | filters | events | packets }</tag>
814 Control protocol debugging.
821 <p>BIRD contains a simple programming language. (No, it can't yet read mail :-). There are
822 two objects in this language: filters and functions. Filters are interpreted by BIRD core when a route is
823 being passed between protocols and routing tables. The filter language contains control structures such
824 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>.
826 <p>Filter gets the route, looks at its attributes and
827 modifies some of them if it wishes. At the end, it decides whether to
828 pass the changed route through (using <cf/accept/) or whether to <cf/reject/ it. A simple filter looks
835 if defined( rip_metric ) then
841 if rip_metric > 10 then
842 reject "RIP metric is too big";
848 <p>As you can see, a filter has a header, a list of local variables, and a body. The header consists of
849 the <cf/filter/ keyword followed by a (unique) name of filter. The list of local variables consists of
850 <cf><M>type name</M>;</cf> pairs where each pair defines one local variable. The body consists of
851 <cf> { <M>statements</M> }</cf>. Each <m/statement/ is terminated by a <cf/;/. You can group
852 several statements to a single compound statement by using braces (<cf>{ <M>statements</M> }</cf>) which is useful if
853 you want to make a bigger block of code conditional.
855 <p>BIRD supports functions, so that you don't have to repeat the same blocks of code over and
856 over. Functions can have zero or more parameters and they can have local variables. Recursion is not allowed. Function definitions
866 function with_parameters (int parameter)
872 <p>Unlike in C, variables are declared after the <cf/function/ line, but before the first <cf/{/. You can't declare
873 variables in nested blocks. Functions are called like in C: <cf>name();
874 with_parameters(5);</cf>. Function may return values using the <cf>return <m/[expr]/</cf>
875 command. Returning a value exits from current function (this is similar to C).
877 <p>Filters are declared in a way similar to functions except they can't have explicit
878 parameters. They get a route table entry as an implicit parameter, it is also passed automatically
879 to any functions called. The filter must terminate with either
880 <cf/accept/ or <cf/reject/ statement. If there's a runtime error in filter, the route
883 <p>A nice trick to debug filters is to use <cf>show route filter
884 <m/name/</cf> from the command line client. An example session might look
888 pavel@bug:~/bird$ ./birdc -s bird.ctl
891 10.0.0.0/8 dev eth0 [direct1 23:21] (240)
892 195.113.30.2/32 dev tunl1 [direct1 23:21] (240)
893 127.0.0.0/8 dev lo [direct1 23:21] (240)
895 show route [<prefix>] [table <t>] [filter <f>] [all] [primary]...
896 bird> show route filter { if 127.0.0.5 ˜ net then accept; }
897 127.0.0.0/8 dev lo [direct1 23:21] (240)
903 <p>Each variable and each value has certain type. Booleans, integers and enums are
904 incompatible with each other (that is to prevent you from shooting in the foot).
907 <tag/bool/ This is a boolean type, it can have only two values, <cf/true/ and
908 <cf/false/. Boolean is the only type you can use in <cf/if/
911 <tag/int/ This is a general integer type, you can expect it to store signed values from -2000000000
912 to +2000000000. Overflows are not checked. You can use <cf/0x1234/ syntax to write hexadecimal values.
914 <tag/pair/ This is a pair of two short integers. Each component can have values from 0 to
915 65535. Literals of this type are written as <cf/(1234,5678)/. The same syntax can also be
916 used to construct a pair from two arbitrary integer expressions (for example <cf/(1+2,a)/).
918 <tag/quad/ This is a dotted quad of numbers used to represent
919 router IDs (and others). Each component can have a value
920 from 0 to 255. Literals of this type are written like IPv4
923 <tag/string/ This is a string of characters. There are no ways to modify strings in
924 filters. You can pass them between functions, assign them to variables of type <cf/string/, print
925 such variables, but you can't concatenate two strings. String literals
926 are written as <cf/"This is a string constant"/.
928 <tag/ip/ This type can hold a single IP address. Depending on the compile-time configuration of BIRD you are using, it
929 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>
930 on values of type ip. It masks out all but first <cf><M>num</M></cf> bits from the IP
931 address. So <cf/1.2.3.4.mask(8) = 1.0.0.0/ is true.
933 <tag/prefix/ This type can hold a network prefix consisting of IP address and prefix length. Prefix literals are written as
934 <cf><M>ipaddress</M>/<M>pxlen</M></cf>, or
935 <cf><m>ipaddress</m>/<m>netmask</m></cf>. There are two special
936 operators on prefixes:
937 <cf/.ip/ which extracts the IP address from the pair, and <cf/.len/, which separates prefix
938 length from the pair. So <cf>1.2.0.0/16.pxlen = 16</cf> is true.
940 <tag/ec/ This is a specialized type used to represent BGP
941 extended community values. It is essentially a 64bit value,
942 literals of this type are usually written as <cf>(<m/kind/,
943 <m/key/, <m/value/)</cf>, where <cf/kind/ is a kind of
944 extended community (e.g. <cf/rt/ / <cf/ro/ for a route
945 target / route origin communities), the format and possible
946 values of <cf/key/ and <cf/value/ are usually integers, but
947 it depends on the used kind. Similarly to pairs, ECs can be
948 constructed using expressions for <cf/key/ and
949 <cf/value/ parts, (e.g. <cf/(ro, myas, 3*10)/, where
950 <cf/myas/ is an integer variable).
952 <tag/int|pair|quad|ip|prefix|ec|enum set/
953 Filters recognize four types of sets. Sets are similar to strings: you can pass them around
954 but you can't modify them. Literals of type <cf>int set</cf> look like <cf>
955 [ 1, 2, 5..7 ]</cf>. As you can see, both simple values and ranges are permitted in
958 For pair sets, expressions like <cf/(123,*)/ can be used to denote ranges (in
959 that case <cf/(123,0)..(123,65535)/). You can also use <cf/(123,5..100)/ for range
960 <cf/(123,5)..(123,100)/. You can also use <cf/*/ and <cf/a..b/ expressions
961 in the first part of a pair, note that such expressions are translated to a set
962 of intervals, which may be memory intensive. E.g. <cf/(*,4..20)/ is translated to
963 <cf/(0,4..20), (1,4..20), (2,4..20), ... (65535, 4..20)/.
965 EC sets use similar expressions like pair sets, e.g. <cf/(rt, 123, 10..20)/
966 or <cf/(ro, 123, *)/. Expressions requiring the translation (like <cf/(rt, *, 3)/)
967 are not allowed (as they usually have 4B range for ASNs).
969 You can also use expressions for int, pair and EC set values. However it must
970 be possible to evaluate these expressions before daemon boots. So you can use
971 only constants inside them. E.g.
979 odds = [ one, 2+1, 6-one, 2*2*2-1, 9, 11 ];
980 ps = [ (1,one+one), (3,4)..(4,8), (5,*), (6,3..6), (7..9,*) ];
981 es = [ (rt, myas, 3*10), (rt, myas+one, 0..16*16*16-1), (ro, myas+2, *) ];
984 Sets of prefixes are special: their literals does not allow ranges, but allows
985 prefix patterns that are written as <cf><M>ipaddress</M>/<M>pxlen</M>{<M>low</M>,<M>high</M>}</cf>.
986 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
987 the first <cf>min(len1, len2)</cf> bits of <cf/ip1/ and <cf/ip2/ are identical and <cf>len1 <= ip1 <= len2</cf>.
988 A valid prefix pattern has to satisfy <cf>low <= high</cf>, but <cf/pxlen/ is not constrained by <cf/low/
989 or <cf/high/. Obviously, a prefix matches a prefix set literal if it matches any prefix pattern in the
992 There are also two shorthands for prefix patterns: <cf><m>address</m>/<m/len/+</cf> is a shorthand for
993 <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),
994 that means network prefix <cf><m>address</m>/<m/len/</cf> and all its subnets. <cf><m>address</m>/<m/len/-</cf>
995 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>
996 and all its supernets (network prefixes that contain it).
998 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
999 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
1000 <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
1001 IP address) whose prefix length is 20 to 24, <cf>[ 1.2.3.4/32- ]</cf> matches any prefix that contains IP address
1002 <cf>1.2.3.4</cf>. <cf>1.2.0.0/16 ˜ [ 1.0.0.0/8{15,17} ]</cf> is true,
1003 but <cf>1.0.0.0/16 ˜ [ 1.0.0.0/8- ]</cf> is false.
1005 Cisco-style patterns like <cf>10.0.0.0/8 ge 16 le 24</cf> can be expressed
1006 in BIRD as <cf>10.0.0.0/8{16,24}</cf>, <cf>192.168.0.0/16 le 24</cf> as
1007 <cf>192.168.0.0/16{16,24}</cf> and <cf>192.168.0.0/16 ge 24</cf> as
1008 <cf>192.168.0.0/16{24,32}</cf>.
1011 Enumeration types are fixed sets of possibilities. You can't define your own
1012 variables of such type, but some route attributes are of enumeration
1013 type. Enumeration types are incompatible with each other.
1016 BGP path is a list of autonomous system numbers. You can't write literals of this type.
1017 There are several special operators on bgppaths:
1019 <cf><m/P/.first</cf> returns the first ASN (the neighbor ASN) in path <m/P/.
1021 <cf><m/P/.last</cf> returns the last ASN (the source ASN) in path <m/P/.
1023 Both <cf/first/ and <cf/last/ return zero if there is no appropriate ASN,
1024 for example if the path contains an AS set element as the first (or the last) part.
1026 <cf><m/P/.len</cf> returns the length of path <m/P/.
1028 <cf>prepend(<m/P/,<m/A/)</cf> prepends ASN <m/A/ to path <m/P/ and returns the result.
1029 Statement <cf><m/P/ = prepend(<m/P/, <m/A/);</cf> can be shortened to
1030 <cf><m/P/.prepend(<m/A/);</cf> if <m/P/ is appropriate route attribute
1031 (for example <cf/bgp_path/).
1034 BGP masks are patterns used for BGP path matching
1035 (using <cf>path ˜ [= 2 3 5 * =]</cf> syntax). The masks
1036 resemble wildcard patterns as used by UNIX shells. Autonomous
1037 system numbers match themselves, <cf/*/ matches any (even empty)
1038 sequence of arbitrary AS numbers and <cf/?/ matches one arbitrary AS number.
1039 For example, if <cf>bgp_path</cf> is 4 3 2 1, then:
1040 <tt>bgp_path ˜ [= * 4 3 * =]</tt> is true, but
1041 <tt>bgp_path ˜ [= * 4 5 * =]</tt> is false.
1042 BGP mask expressions can also contain integer expressions enclosed in parenthesis
1043 and integer variables, for example <tt>[= * 4 (1+2) a =]</tt>.
1044 There is also old syntax that uses / .. / instead of [= .. =] and ? instead of *.
1047 Clist is similar to a set, except that unlike other sets, it
1048 can be modified. The type is used for community list (a set
1049 of pairs) and for cluster list (a set of quads). There exist
1050 no literals of this type. There are three special operators on
1053 <cf>add(<m/C/,<m/P/)</cf> adds pair (or quad) <m/P/ to clist
1054 <m/C/ and returns the result. If item <m/P/ is already in
1055 clist <m/C/, it does nothing. <m/P/ may also be a clist,
1056 in that case all its members are added; i.e., it works as clist union.
1058 <cf>delete(<m/C/,<m/P/)</cf> deletes pair (or quad)
1059 <m/P/ from clist <m/C/ and returns the result. If clist
1060 <m/C/ does not contain item <m/P/, it does nothing.
1061 <m/P/ may also be a pair (or quad) set, in that case the
1062 operator deletes all items from clist <m/C/ that are also
1063 members of set <m/P/. Moreover, <m/P/ may also be a clist,
1064 which works analogously; i.e., it works as clist difference.
1066 <cf>filter(<m/C/,<m/P/)</cf> deletes all items from clist
1067 <m/C/ that are not members of pair (or quad) set <m/P/.
1068 I.e., <cf/filter/ do the same as <cf/delete/ with inverted
1069 set <m/P/. <m/P/ may also be a clist, which works analogously;
1070 i.e., it works as clist intersection.
1072 Statement <cf><m/C/ = add(<m/C/, <m/P/);</cf> can be shortened to
1073 <cf><m/C/.add(<m/P/);</cf> if <m/C/ is appropriate route
1074 attribute (for example <cf/bgp_community/). Similarly for
1075 <cf/delete/ and <cf/filter/.
1078 Eclist is a data type used for BGP extended community lists.
1079 Eclists are very similar to clists, but they are sets of ECs
1080 instead of pairs. The same operations (like <cf/add/,
1081 <cf/delete/, or <cf/˜/ membership operator) can be
1082 used to modify or test eclists, with ECs instead of pairs as
1088 <p>The filter language supports common integer operators <cf>(+,-,*,/)</cf>, parentheses <cf/(a*(b+c))/, comparison
1089 <cf/(a=b, a!=b, a<b, a>=b)/. Logical operations include unary not (<cf/!/), and (<cf/&&/) and or (<cf/||/).
1090 Special operators include <cf/˜/ for "is element of a set" operation - it can be
1091 used on element and set of elements of the same type (returning true if element is contained in the given set), or
1092 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
1093 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).
1095 <p>There is one operator related to ROA infrastructure -
1096 <cf/roa_check()/. It examines a ROA table and does RFC 6483 route
1097 origin validation for a given network prefix. The basic usage
1098 is <cf>roa_check(<m/table/)</cf>, which checks current route (which
1099 should be from BGP to have AS_PATH argument) in the specified ROA
1100 table and returns ROA_UNKNOWN if there is no relevant ROA, ROA_VALID
1101 if there is a matching ROA, or ROA_INVALID if there are some relevant
1102 ROAs but none of them match. There is also an extended variant
1103 <cf>roa_check(<m/table/, <m/prefix/, <m/asn/)</cf>, which allows to
1104 specify a prefix and an ASN as arguments.
1107 <sect>Control structures
1109 <p>Filters support two control structures: conditions and case switches.
1111 <p>Syntax of a condition is: <cf>if
1112 <M>boolean expression</M> then <M>command1</M>; else <M>command2</M>;</cf> and you can use <cf>{
1113 <M>command_1</M>; <M>command_2</M>; <M>...</M> }</cf> instead of either command. The <cf>else</cf>
1114 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.
1116 <p>The <cf>case</cf> is similar to case from Pascal. Syntax is <cf>case <m/expr/ { else: |
1117 <m/num_or_prefix [ .. num_or_prefix]/: <m/statement/ ; [ ... ] }</cf>. The expression after
1118 <cf>case</cf> can be of any type which can be on the left side of the ˜ operator and anything that could
1119 be a member of a set is allowed before <cf/:/. Multiple commands are allowed without <cf/{}/ grouping.
1120 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.
1122 <p>Here is example that uses <cf/if/ and <cf/case/ structures:
1126 2: print "two"; print "I can do more commands without {}";
1127 3 .. 5: print "three to five";
1128 else: print "something else";
1131 if 1234 = i then printn "."; else {
1133 print "You need {} around multiple commands";
1137 <sect>Route attributes
1139 <p>A filter is implicitly passed a route, and it can access its
1140 attributes just like it accesses variables. Attempts to access undefined
1141 attribute result in a runtime error; you can check if an attribute is
1142 defined by using the <cf>defined( <m>attribute</m> )</cf> operator.
1143 One notable exception to this rule are attributes of clist type, where
1144 undefined value is regarded as empty clist for most purposes.
1147 <tag><m/prefix/ net</tag>
1148 Network the route is talking about. Read-only. (See the chapter about routing tables.)
1150 <tag><m/enum/ scope</tag>
1151 The scope of the route. Possible values: <cf/SCOPE_HOST/ for
1152 routes local to this host, <cf/SCOPE_LINK/ for those specific
1153 for a physical link, <cf/SCOPE_SITE/ and
1154 <cf/SCOPE_ORGANIZATION/ for private routes and
1155 <cf/SCOPE_UNIVERSE/ for globally visible routes. This
1156 attribute is not interpreted by BIRD and can be used to mark
1157 routes in filters. The default value for new routes is
1158 <cf/SCOPE_UNIVERSE/.
1160 <tag><m/int/ preference</tag>
1161 Preference of the route. Valid values are 0-65535. (See the chapter about routing tables.)
1163 <tag><m/ip/ from</tag>
1164 The router which the route has originated from. Read-only.
1166 <tag><m/ip/ gw</tag>
1167 Next hop packets routed using this route should be forwarded to.
1169 <tag><m/string/ proto</tag>
1170 The name of the protocol which the route has been imported from. Read-only.
1172 <tag><m/enum/ source</tag>
1173 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/.
1175 <tag><m/enum/ cast</tag>
1177 Route type (Currently <cf/RTC_UNICAST/ for normal routes,
1178 <cf/RTC_BROADCAST/, <cf/RTC_MULTICAST/, <cf/RTC_ANYCAST/ will
1179 be used in the future for broadcast, multicast and anycast
1182 <tag><m/enum/ dest</tag>
1183 Type of destination the packets should be sent to
1184 (<cf/RTD_ROUTER/ for forwarding to a neighboring router,
1185 <cf/RTD_DEVICE/ for routing to a directly-connected network,
1186 <cf/RTD_MULTIPATH/ for multipath destinations,
1187 <cf/RTD_BLACKHOLE/ for packets to be silently discarded,
1188 <cf/RTD_UNREACHABLE/, <cf/RTD_PROHIBIT/ for packets that
1189 should be returned with ICMP host unreachable / ICMP
1190 administratively prohibited messages). Can be changed, but
1191 only to <cf/RTD_BLACKHOLE/, <cf/RTD_UNREACHABLE/ or
1194 <tag><m/int/ igp_metric</tag>
1195 The optional attribute that can be used to specify a distance
1196 to the network for routes that do not have a native protocol
1197 metric attribute (like <cf/ospf_metric1/ for OSPF routes). It
1198 is used mainly by BGP to compare internal distances to boundary
1199 routers (see below). It is also used when the route is exported
1200 to OSPF as a default value for OSPF type 1 metric.
1203 <p>There also exist some protocol-specific attributes which are described in the corresponding protocol sections.
1205 <sect>Other statements
1207 <p>The following statements are available:
1210 <tag><m/variable/ = <m/expr/</tag> Set variable to a given value.
1212 <tag>accept|reject [ <m/expr/ ]</tag> Accept or reject the route, possibly printing <cf><m>expr</m></cf>.
1214 <tag>return <m/expr/</tag> Return <cf><m>expr</m></cf> from the current function, the function ends at this point.
1216 <tag>print|printn <m/expr/ [<m/, expr.../]</tag>
1217 Prints given expressions; useful mainly while debugging
1218 filters. The <cf/printn/ variant does not terminate the line.
1221 Terminates BIRD. Useful when debugging the filter interpreter.
1228 <p>The Border Gateway Protocol is the routing protocol used for backbone
1229 level routing in the today's Internet. Contrary to the other protocols, its convergence
1230 doesn't rely on all routers following the same rules for route selection,
1231 making it possible to implement any routing policy at any router in the
1232 network, the only restriction being that if a router advertises a route,
1233 it must accept and forward packets according to it.
1235 <p>BGP works in terms of autonomous systems (often abbreviated as
1236 AS). Each AS is a part of the network with common management and
1237 common routing policy. It is identified by a unique 16-bit number
1238 (ASN). Routers within each AS usually exchange AS-internal routing
1239 information with each other using an interior gateway protocol (IGP,
1240 such as OSPF or RIP). Boundary routers at the border of
1241 the AS communicate global (inter-AS) network reachability information with
1242 their neighbors in the neighboring AS'es via exterior BGP (eBGP) and
1243 redistribute received information to other routers in the AS via
1244 interior BGP (iBGP).
1246 <p>Each BGP router sends to its neighbors updates of the parts of its
1247 routing table it wishes to export along with complete path information
1248 (a list of AS'es the packet will travel through if it uses the particular
1249 route) in order to avoid routing loops.
1251 <p>BIRD supports all requirements of the BGP4 standard as defined in
1252 RFC 4271<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4271.txt">
1253 It also supports the community attributes
1254 (RFC 1997<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1997.txt">),
1255 capability negotiation
1256 (RFC 3392<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc3392.txt">),
1257 MD5 password authentication
1258 (RFC 2385<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2385.txt">),
1259 extended communities
1260 (RFC 4360<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4360.txt">),
1262 (RFC 4456<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4456.txt">),
1263 multiprotocol extensions
1264 (RFC 4760<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4760.txt">),
1266 (RFC 4893<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4893.txt">),
1267 and 4B AS numbers in extended communities
1268 (RFC 5668<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5668.txt">).
1271 For IPv6, it uses the standard multiprotocol extensions defined in
1272 RFC 2283<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2283.txt">
1273 including changes described in the
1274 latest draft<htmlurl url="ftp://ftp.rfc-editor.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-05.txt">
1275 and applied to IPv6 according to
1276 RFC 2545<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2545.txt">.
1278 <sect1>Route selection rules
1280 <p>BGP doesn't have any simple metric, so the rules for selection of an optimal
1281 route among multiple BGP routes with the same preference are a bit more complex
1282 and they are implemented according to the following algorithm. It starts the first
1283 rule, if there are more "best" routes, then it uses the second rule to choose
1284 among them and so on.
1287 <item>Prefer route with the highest Local Preference attribute.
1288 <item>Prefer route with the shortest AS path.
1289 <item>Prefer IGP origin over EGP and EGP origin over incomplete.
1290 <item>Prefer the lowest value of the Multiple Exit Discriminator.
1291 <item>Prefer routes received via eBGP over ones received via iBGP.
1292 <item>Prefer routes with lower internal distance to a boundary router.
1293 <item>Prefer the route with the lowest value of router ID of the
1297 <sect1>IGP routing table
1299 <p>BGP is mainly concerned with global network reachability and with
1300 routes to other autonomous systems. When such routes are redistributed
1301 to routers in the AS via BGP, they contain IP addresses of a boundary
1302 routers (in route attribute NEXT_HOP). BGP depends on existing IGP
1303 routing table with AS-internal routes to determine immediate next hops
1304 for routes and to know their internal distances to boundary routers
1305 for the purpose of BGP route selection. In BIRD, there is usually
1306 one routing table used for both IGP routes and BGP routes.
1308 <sect1>Configuration
1310 <p>Each instance of the BGP corresponds to one neighboring router.
1311 This allows to set routing policy and all the other parameters differently
1312 for each neighbor using the following configuration parameters:
1315 <tag>local [<m/ip/] as <m/number/</tag> Define which AS we
1316 are part of. (Note that contrary to other IP routers, BIRD is
1317 able to act as a router located in multiple AS'es
1318 simultaneously, but in such cases you need to tweak the BGP
1319 paths manually in the filters to get consistent behavior.)
1320 Optional <cf/ip/ argument specifies a source address,
1321 equivalent to the <cf/source address/ option (see below).
1322 This parameter is mandatory.
1324 <tag>neighbor <m/ip/ as <m/number/</tag> Define neighboring router
1325 this instance will be talking to and what AS it's located in. Unless
1326 you use the <cf/multihop/ clause, it must be directly connected to one
1327 of your router's interfaces. In case the neighbor is in the same AS
1328 as we are, we automatically switch to iBGP. This parameter is mandatory.
1330 <tag>multihop [<m/number/]</tag> Configure multihop BGP
1331 session to a neighbor that isn't directly connected.
1332 Accurately, this option should be used if the configured
1333 neighbor IP address does not match with any local network
1334 subnets. Such IP address have to be reachable through system
1335 routing table. For multihop BGP it is recommended to
1336 explicitly configure <cf/source address/ to have it
1337 stable. Optional <cf/number/ argument can be used to specify
1338 the number of hops (used for TTL). Note that the number of
1339 networks (edges) in a path is counted, i.e. if two BGP
1340 speakers are separated by one router, the number of hops is
1341 2. Default: switched off.
1343 <tag>source address <m/ip/</tag> Define local address we
1344 should use for next hop calculation and as a source address
1345 for the BGP session. Default: the address of the local
1346 end of the interface our neighbor is connected to.
1348 <tag>next hop self</tag> Avoid calculation of the Next Hop
1349 attribute and always advertise our own source address as a
1350 next hop. This needs to be used only occasionally to
1351 circumvent misconfigurations of other routers. Default:
1354 <tag>next hop keep</tag> Forward the received Next Hop
1355 attribute even in situations where the local address should be
1356 used instead, like when the route is sent to an interface with
1357 a different subnet. Default: disabled.
1359 <tag>missing lladdr self|drop|ignore</tag>Next Hop attribute
1360 in BGP-IPv6 sometimes contains just the global IPv6 address,
1361 but sometimes it has to contain both global and link-local
1362 IPv6 addresses. This option specifies what to do if BIRD have
1363 to send both addresses but does not know link-local address.
1364 This situation might happen when routes from other protocols
1365 are exported to BGP, or when improper updates are received
1366 from BGP peers. <cf/self/ means that BIRD advertises its own
1367 local address instead. <cf/drop/ means that BIRD skips that
1368 prefixes and logs error. <cf/ignore/ means that BIRD ignores
1369 the problem and sends just the global address (and therefore
1370 forms improper BGP update). Default: <cf/self/, unless BIRD
1371 is configured as a route server (option <cf/rs client/), in
1372 that case default is <cf/ignore/, because route servers usually
1373 do not forward packets themselves.
1375 <tag>gateway direct|recursive</tag>For received routes, their
1376 <cf/gw/ (immediate next hop) attribute is computed from
1377 received <cf/bgp_next_hop/ attribute. This option specifies
1378 how it is computed. Direct mode means that the IP address from
1379 <cf/bgp_next_hop/ is used if it is directly reachable,
1380 otherwise the neighbor IP address is used. Recursive mode
1381 means that the gateway is computed by an IGP routing table
1382 lookup for the IP address from <cf/bgp_next_hop/. Recursive
1383 mode is the behavior specified by the BGP standard. Direct
1384 mode is simpler, does not require any routes in a routing
1385 table, and was used in older versions of BIRD, but does not
1386 handle well nontrivial iBGP setups and multihop. Recursive
1387 mode is incompatible with <ref id="dsc-sorted" name="sorted
1388 tables">. Default: <cf/direct/ for singlehop eBGP,
1389 <cf/recursive/ otherwise.
1391 <tag>igp table <m/name/</tag> Specifies a table that is used
1392 as an IGP routing table. Default: the same as the table BGP is
1395 <tag>ttl security <m/switch/</tag> Use GTSM (RFC 5082 - the
1396 generalized TTL security mechanism). GTSM protects against
1397 spoofed packets by ignoring received packets with a smaller
1398 than expected TTL. To work properly, GTSM have to be enabled
1399 on both sides of a BGP session. If both <cf/ttl security/ and
1400 <cf/multihop/ options are enabled, <cf/multihop/ option should
1401 specify proper hop value to compute expected TTL. Kernel
1402 support required: Linux: 2.6.34+ (IPv4), 2.6.35+ (IPv6), BSD:
1403 since long ago, IPv4 only. Note that full (ICMP protection,
1404 for example) RFC 5082 support is provided by Linux
1405 only. Default: disabled.
1407 <tag>password <m/string/</tag> Use this password for MD5 authentication
1408 of BGP sessions. Default: no authentication. Password has to be set by
1409 external utility (e.g. setkey(8)) on BSD systems.
1411 <tag>passive <m/switch/</tag> Standard BGP behavior is both
1412 initiating outgoing connections and accepting incoming
1413 connections. In passive mode, outgoing connections are not
1414 initiated. Default: off.
1416 <tag>rr client</tag> Be a route reflector and treat the neighbor as
1417 a route reflection client. Default: disabled.
1419 <tag>rr cluster id <m/IPv4 address/</tag> Route reflectors use cluster id
1420 to avoid route reflection loops. When there is one route reflector in a cluster
1421 it usually uses its router id as a cluster id, but when there are more route
1422 reflectors in a cluster, these need to be configured (using this option) to
1423 use a common cluster id. Clients in a cluster need not know their cluster
1424 id and this option is not allowed for them. Default: the same as router id.
1426 <tag>rs client</tag> Be a route server and treat the neighbor
1427 as a route server client. A route server is used as a
1428 replacement for full mesh EBGP routing in Internet exchange
1429 points in a similar way to route reflectors used in IBGP routing.
1430 BIRD does not implement obsoleted RFC 1863, but uses ad-hoc implementation,
1431 which behaves like plain EBGP but reduces modifications to advertised route
1432 attributes to be transparent (for example does not prepend its AS number to
1433 AS PATH attribute and keeps MED attribute). Default: disabled.
1435 <tag>secondary <m/switch/</tag> Usually, if an import filter
1436 rejects a selected route, no other route is propagated for
1437 that network. This option allows to try the next route in
1438 order until one that is accepted is found or all routes for
1439 that network are rejected. This can be used for route servers
1440 that need to propagate different tables to each client but do
1441 not want to have these tables explicitly (to conserve memory).
1442 This option requires that the connected routing table is
1443 <ref id="dsc-sorted" name="sorted">. Default: off.
1445 <tag>enable route refresh <m/switch/</tag> When BGP speaker
1446 changes its import filter, it has to re-examine all routes
1447 received from its neighbor against the new filter. As these
1448 routes might not be available, there is a BGP protocol
1449 extension Route Refresh (specified in RFC 2918) that allows
1450 BGP speaker to request re-advertisement of all routes from its
1451 neighbor. This option specifies whether BIRD advertises this
1452 capability and accepts such requests. Even when disabled, BIRD
1453 can send route refresh requests. Default: on.
1455 <tag>interpret communities <m/switch/</tag> RFC 1997 demands
1456 that BGP speaker should process well-known communities like
1457 no-export (65535, 65281) or no-advertise (65535, 65282). For
1458 example, received route carrying a no-adverise community
1459 should not be advertised to any of its neighbors. If this
1460 option is enabled (which is by default), BIRD has such
1461 behavior automatically (it is evaluated when a route is
1462 exported to the BGP protocol just before the export filter).
1463 Otherwise, this integrated processing of well-known
1464 communities is disabled. In that case, similar behavior can be
1465 implemented in the export filter. Default: on.
1467 <tag>enable as4 <m/switch/</tag> BGP protocol was designed to use 2B AS numbers
1468 and was extended later to allow 4B AS number. BIRD supports 4B AS extension,
1469 but by disabling this option it can be persuaded not to advertise it and
1470 to maintain old-style sessions with its neighbors. This might be useful for
1471 circumventing bugs in neighbor's implementation of 4B AS extension.
1472 Even when disabled (off), BIRD behaves internally as AS4-aware BGP router.
1475 <tag>capabilities <m/switch/</tag> Use capability advertisement
1476 to advertise optional capabilities. This is standard behavior
1477 for newer BGP implementations, but there might be some older
1478 BGP implementations that reject such connection attempts.
1479 When disabled (off), features that request it (4B AS support)
1480 are also disabled. Default: on, with automatic fallback to
1481 off when received capability-related error.
1483 <tag>advertise ipv4 <m/switch/</tag> Advertise IPv4 multiprotocol capability.
1484 This is not a correct behavior according to the strict interpretation
1485 of RFC 4760, but it is widespread and required by some BGP
1486 implementations (Cisco and Quagga). This option is relevant
1487 to IPv4 mode with enabled capability advertisement only. Default: on.
1489 <tag>route limit <m/number/</tag> The maximal number of routes
1490 that may be imported from the protocol. If the route limit is
1491 exceeded, the connection is closed with error. Limit is currently implemented as
1492 <cf/import limit number exceed restart/. Default: no limit.
1494 <tag>disable after error <m/switch/</tag> When an error is encountered (either
1495 locally or by the other side), disable the instance automatically
1496 and wait for an administrator to fix the problem manually. Default: off.
1498 <tag>hold time <m/number/</tag> Time in seconds to wait for a Keepalive
1499 message from the other side before considering the connection stale.
1500 Default: depends on agreement with the neighboring router, we prefer
1501 240 seconds if the other side is willing to accept it.
1503 <tag>startup hold time <m/number/</tag> Value of the hold timer used
1504 before the routers have a chance to exchange open messages and agree
1505 on the real value. Default: 240 seconds.
1507 <tag>keepalive time <m/number/</tag> Delay in seconds between sending
1508 of two consecutive Keepalive messages. Default: One third of the hold time.
1510 <tag>connect retry time <m/number/</tag> Time in seconds to wait before
1511 retrying a failed attempt to connect. Default: 120 seconds.
1513 <tag>start delay time <m/number/</tag> Delay in seconds between protocol
1514 startup and the first attempt to connect. Default: 5 seconds.
1516 <tag>error wait time <m/number/,<m/number/</tag> Minimum and maximum delay in seconds between a protocol
1517 failure (either local or reported by the peer) and automatic restart.
1518 Doesn't apply when <cf/disable after error/ is configured. If consecutive
1519 errors happen, the delay is increased exponentially until it reaches the maximum. Default: 60, 300.
1521 <tag>error forget time <m/number/</tag> Maximum time in seconds between two protocol
1522 failures to treat them as a error sequence which makes the <cf/error wait time/
1523 increase exponentially. Default: 300 seconds.
1525 <tag>path metric <m/switch/</tag> Enable comparison of path lengths
1526 when deciding which BGP route is the best one. Default: on.
1528 <tag>med metric <m/switch/</tag> Enable comparison of MED
1529 attributes (during best route selection) even between routes
1530 received from different ASes. This may be useful if all MED
1531 attributes contain some consistent metric, perhaps enforced in
1532 import filters of AS boundary routers. If this option is
1533 disabled, MED attributes are compared only if routes are
1534 received from the same AS (which is the standard behavior).
1537 <tag>deterministic med <m/switch/</tag> BGP route selection
1538 algorithm is often viewed as a comparison between individual
1539 routes (e.g. if a new route appears and is better than the
1540 current best one, it is chosen as the new best one). But the
1541 proper route selection, as specified by RFC 4271, cannot be
1542 fully implemented in that way. The problem is mainly in
1543 handling the MED attribute. BIRD, by default, uses an
1544 simplification based on individual route comparison, which in
1545 some cases may lead to temporally dependent behavior (i.e. the
1546 selection is dependent on the order in which routes appeared).
1547 This option enables a different (and slower) algorithm
1548 implementing proper RFC 4271 route selection, which is
1549 deterministic. Alternative way how to get deterministic
1550 behavior is to use <cf/med metric/ option. This option is
1551 incompatible with <ref id="dsc-sorted" name="sorted tables">.
1554 <tag>igp metric <m/switch/</tag> Enable comparison of internal
1555 distances to boundary routers during best route selection. Default: on.
1557 <tag>prefer older <m/switch/</tag> Standard route selection algorithm
1558 breaks ties by comparing router IDs. This changes the behavior
1559 to prefer older routes (when both are external and from different
1560 peer). For details, see RFC 5004. Default: off.
1562 <tag>default bgp_med <m/number/</tag> Value of the Multiple Exit
1563 Discriminator to be used during route selection when the MED attribute
1564 is missing. Default: 0.
1566 <tag>default bgp_local_pref <m/number/</tag> A default value
1567 for the Local Preference attribute. It is used when a new
1568 Local Preference attribute is attached to a route by the BGP
1569 protocol itself (for example, if a route is received through
1570 eBGP and therefore does not have such attribute). Default: 100
1571 (0 in pre-1.2.0 versions of BIRD).
1576 <p>BGP defines several route attributes. Some of them (those marked with `<tt/I/' in the
1577 table below) are available on internal BGP connections only, some of them (marked
1578 with `<tt/O/') are optional.
1581 <tag>bgppath <cf/bgp_path/</tag> Sequence of AS numbers describing the AS path
1582 the packet will travel through when forwarded according to the particular route.
1583 In case of internal BGP it doesn't contain the number of the local AS.
1585 <tag>int <cf/bgp_local_pref/ [I]</tag> Local preference value used for
1586 selection among multiple BGP routes (see the selection rules above). It's
1587 used as an additional metric which is propagated through the whole local AS.
1589 <tag>int <cf/bgp_med/ [O]</tag> The Multiple Exit Discriminator of the route
1590 is an optional attribute which is used on external (inter-AS) links to
1591 convey to an adjacent AS the optimal entry point into the local AS.
1592 The received attribute is also propagated over internal BGP links.
1593 The attribute value is zeroed when a route is exported to an external BGP
1594 instance to ensure that the attribute received from a neighboring AS is
1595 not propagated to other neighboring ASes. A new value might be set in
1596 the export filter of an external BGP instance.
1597 See RFC 4451<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4451.txt">
1598 for further discussion of BGP MED attribute.
1600 <tag>enum <cf/bgp_origin/</tag> Origin of the route: either <cf/ORIGIN_IGP/
1601 if the route has originated in an interior routing protocol or
1602 <cf/ORIGIN_EGP/ if it's been imported from the <tt>EGP</tt> protocol
1603 (nowadays it seems to be obsolete) or <cf/ORIGIN_INCOMPLETE/ if the origin
1606 <tag>ip <cf/bgp_next_hop/</tag> Next hop to be used for forwarding of packets
1607 to this destination. On internal BGP connections, it's an address of the
1608 originating router if it's inside the local AS or a boundary router the
1609 packet will leave the AS through if it's an exterior route, so each BGP
1610 speaker within the AS has a chance to use the shortest interior path
1611 possible to this point.
1613 <tag>void <cf/bgp_atomic_aggr/ [O]</tag> This is an optional attribute
1614 which carries no value, but the sole presence of which indicates that the route
1615 has been aggregated from multiple routes by some router on the path from
1618 <!-- we don't handle aggregators right since they are of a very obscure type
1619 <tag>bgp_aggregator</tag>
1621 <tag>clist <cf/bgp_community/ [O]</tag> List of community values associated
1622 with the route. Each such value is a pair (represented as a <cf/pair/ data
1623 type inside the filters) of 16-bit integers, the first of them containing the number of the AS which defines
1624 the community and the second one being a per-AS identifier. There are lots
1625 of uses of the community mechanism, but generally they are used to carry
1626 policy information like "don't export to USA peers". As each AS can define
1627 its own routing policy, it also has a complete freedom about which community
1628 attributes it defines and what will their semantics be.
1630 <tag>eclist <cf/bgp_ext_community/ [O]</tag> List of extended community
1631 values associated with the route. Extended communities have similar usage
1632 as plain communities, but they have an extended range (to allow 4B ASNs)
1633 and a nontrivial structure with a type field. Individual community values are
1634 represented using an <cf/ec/ data type inside the filters.
1636 <tag>quad <cf/bgp_originator_id/ [I, O]</tag> This attribute is created by the
1637 route reflector when reflecting the route and contains the router ID of the
1638 originator of the route in the local AS.
1640 <tag>clist <cf/bgp_cluster_list/ [I, O]</tag> This attribute contains a list
1641 of cluster IDs of route reflectors. Each route reflector prepends its
1642 cluster ID when reflecting the route.
1649 local as 65000; # Use a private AS number
1650 neighbor 198.51.100.130 as 64496; # Our neighbor ...
1651 multihop; # ... which is connected indirectly
1652 export filter { # We use non-trivial export rules
1653 if source = RTS_STATIC then { # Export only static routes
1654 # Assign our community
1655 bgp_community.add((65000,64501));
1656 # Artificially increase path length
1657 # by advertising local AS number twice
1658 if bgp_path ~ [= 65000 =] then
1659 bgp_path.prepend(65000);
1665 source address 198.51.100.14; # Use a non-standard source address
1671 <p>The Device protocol is not a real routing protocol. It doesn't generate
1672 any routes and it only serves as a module for getting information about network
1673 interfaces from the kernel.
1675 <p>Except for very unusual circumstances, you probably should include
1676 this protocol in the configuration since almost all other protocols
1677 require network interfaces to be defined for them to work with.
1679 <sect1>Configuration
1682 <tag>scan time <m/number/</tag> Time in seconds between two scans
1683 of the network interface list. On systems where we are notified about
1684 interface status changes asynchronously (such as newer versions of
1685 Linux), we need to scan the list only in order to avoid confusion by lost
1686 notification messages, so the default time is set to a large value.
1688 <tag>primary [ "<m/mask/" ] <m/prefix/</tag>
1689 If a network interface has more than one network address, BIRD
1690 has to choose one of them as a primary one. By default, BIRD
1691 chooses the lexicographically smallest address as the primary
1694 This option allows to specify which network address should be
1695 chosen as a primary one. Network addresses that match
1696 <m/prefix/ are preferred to non-matching addresses. If more
1697 <cf/primary/ options are used, the first one has the highest
1698 preference. If "<m/mask/" is specified, then such
1699 <cf/primary/ option is relevant only to matching network
1702 In all cases, an address marked by operating system as
1703 secondary cannot be chosen as the primary one.
1706 <p>As the Device protocol doesn't generate any routes, it cannot have
1707 any attributes. Example configuration looks like this:
1711 scan time 10; # Scan the interfaces often
1712 primary "eth0" 192.168.1.1;
1713 primary 192.168.0.0/16;
1719 <p>The Direct protocol is a simple generator of device routes for all the
1720 directly connected networks according to the list of interfaces provided
1721 by the kernel via the Device protocol.
1723 <p>The question is whether it is a good idea to have such device
1724 routes in BIRD routing table. OS kernel usually handles device routes
1725 for directly connected networks by itself so we don't need (and don't
1726 want) to export these routes to the kernel protocol. OSPF protocol
1727 creates device routes for its interfaces itself and BGP protocol is
1728 usually used for exporting aggregate routes. Although there are some
1729 use cases that use the direct protocol (like abusing eBGP as an IGP
1730 routing protocol), in most cases it is not needed to have these device
1731 routes in BIRD routing table and to use the direct protocol.
1733 <p>There is one notable case when you definitely want to use the
1734 direct protocol -- running BIRD on BSD systems. Having high priority
1735 device routes for directly connected networks from the direct protocol
1736 protects kernel device routes from being overwritten or removed by IGP
1737 routes during some transient network conditions, because a lower
1738 priority IGP route for the same network is not exported to the kernel
1739 routing table. This is an issue on BSD systems only, as on Linux
1740 systems BIRD cannot change non-BIRD route in the kernel routing table.
1742 <p>The only configurable thing about direct is what interfaces it watches:
1745 <tag>interface <m/pattern [, ...]/</tag> By default, the Direct
1746 protocol will generate device routes for all the interfaces
1747 available. If you want to restrict it to some subset of interfaces
1748 (for example if you're using multiple routing tables for policy
1749 routing and some of the policy domains don't contain all interfaces),
1750 just use this clause.
1753 <p>Direct device routes don't contain any specific attributes.
1755 <p>Example config might look like this:
1759 interface "-arc*", "*"; # Exclude the ARCnets
1765 <p>The Kernel protocol is not a real routing protocol. Instead of communicating
1766 with other routers in the network, it performs synchronization of BIRD's routing
1767 tables with the OS kernel. Basically, it sends all routing table updates to the kernel
1768 and from time to time it scans the kernel tables to see whether some routes have
1769 disappeared (for example due to unnoticed up/down transition of an interface)
1770 or whether an `alien' route has been added by someone else (depending on the
1771 <cf/learn/ switch, such routes are either ignored or accepted to our
1774 <p>Unfortunately, there is one thing that makes the routing table
1775 synchronization a bit more complicated. In the kernel routing table
1776 there are also device routes for directly connected networks. These
1777 routes are usually managed by OS itself (as a part of IP address
1778 configuration) and we don't want to touch that. They are completely
1779 ignored during the scan of the kernel tables and also the export of
1780 device routes from BIRD tables to kernel routing tables is restricted
1781 to prevent accidental interference. This restriction can be disabled using
1782 <cf/device routes/ switch.
1784 <p>If your OS supports only a single routing table, you can configure
1785 only one instance of the Kernel protocol. If it supports multiple
1786 tables (in order to allow policy routing; such an OS is for example
1787 Linux), you can run as many instances as you want, but each of them
1788 must be connected to a different BIRD routing table and to a different
1791 <p>Because the kernel protocol is partially integrated with the
1792 connected routing table, there are two limitations - it is not
1793 possible to connect more kernel protocols to the same routing table
1794 and changing route destination/gateway in an export
1795 filter of a kernel protocol does not work. Both limitations can be
1796 overcome using another routing table and the pipe protocol.
1798 <sect1>Configuration
1801 <tag>persist <m/switch/</tag> Tell BIRD to leave all its routes in the
1802 routing tables when it exits (instead of cleaning them up).
1803 <tag>scan time <m/number/</tag> Time in seconds between two consecutive scans of the
1804 kernel routing table.
1805 <tag>learn <m/switch/</tag> Enable learning of routes added to the kernel
1806 routing tables by other routing daemons or by the system administrator.
1807 This is possible only on systems which support identification of route
1810 <tag>device routes <m/switch/</tag> Enable export of device
1811 routes to the kernel routing table. By default, such routes
1812 are rejected (with the exception of explicitly configured
1813 device routes from the static protocol) regardless of the
1814 export filter to protect device routes in kernel routing table
1815 (managed by OS itself) from accidental overwriting or erasing.
1817 <tag>kernel table <m/number/</tag> Select which kernel table should
1818 this particular instance of the Kernel protocol work with. Available
1819 only on systems supporting multiple routing tables.
1824 <p>The Kernel protocol defines several attributes. These attributes
1825 are translated to appropriate system (and OS-specific) route attributes.
1826 We support these attributes:
1829 <tag>int <cf/krt_source/</tag> The original source of the imported
1830 kernel route. The value is system-dependent. On Linux, it is
1831 a value of the protocol field of the route. See
1832 /etc/iproute2/rt_protos for common values. On BSD, it is
1833 based on STATIC and PROTOx flags. The attribute is read-only.
1835 <tag>int <cf/krt_metric/</tag> The kernel metric of
1836 the route. When multiple same routes are in a kernel routing
1837 table, the Linux kernel chooses one with lower metric.
1839 <tag>ip <cf/krt_prefsrc/</tag> (Linux) The preferred source address.
1840 Used in source address selection for outgoing packets. Have to
1841 be one of IP addresses of the router.
1843 <tag>int <cf/krt_realm/</tag> (Linux) The realm of the route. Can be
1844 used for traffic classification.
1849 <p>A simple configuration can look this way:
1857 <p>Or for a system with two routing tables:
1860 protocol kernel { # Primary routing table
1861 learn; # Learn alien routes from the kernel
1862 persist; # Don't remove routes on bird shutdown
1863 scan time 10; # Scan kernel routing table every 10 seconds
1868 protocol kernel { # Secondary routing table
1879 <p>Open Shortest Path First (OSPF) is a quite complex interior gateway
1880 protocol. The current IPv4 version (OSPFv2) is defined in RFC
1881 2328<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2328.txt"> and
1882 the current IPv6 version (OSPFv3) is defined in RFC 5340<htmlurl
1883 url="ftp://ftp.rfc-editor.org/in-notes/rfc5340.txt"> It's a link state
1884 (a.k.a. shortest path first) protocol -- each router maintains a
1885 database describing the autonomous system's topology. Each participating
1886 router has an identical copy of the database and all routers run the
1887 same algorithm calculating a shortest path tree with themselves as a
1888 root. OSPF chooses the least cost path as the best path.
1890 <p>In OSPF, the autonomous system can be split to several areas in order
1891 to reduce the amount of resources consumed for exchanging the routing
1892 information and to protect the other areas from incorrect routing data.
1893 Topology of the area is hidden to the rest of the autonomous system.
1895 <p>Another very important feature of OSPF is that
1896 it can keep routing information from other protocols (like Static or BGP)
1897 in its link state database as external routes. Each external route can
1898 be tagged by the advertising router, making it possible to pass additional
1899 information between routers on the boundary of the autonomous system.
1901 <p>OSPF quickly detects topological changes in the autonomous system (such
1902 as router interface failures) and calculates new loop-free routes after a short
1903 period of convergence. Only a minimal amount of
1904 routing traffic is involved.
1906 <p>Each router participating in OSPF routing periodically sends Hello messages
1907 to all its interfaces. This allows neighbors to be discovered dynamically.
1908 Then the neighbors exchange theirs parts of the link state database and keep it
1909 identical by flooding updates. The flooding process is reliable and ensures
1910 that each router detects all changes.
1912 <sect1>Configuration
1914 <p>In the main part of configuration, there can be multiple definitions of
1915 OSPF areas, each with a different id. These definitions includes many other
1916 switches and multiple definitions of interfaces. Definition of interface
1917 may contain many switches and constant definitions and list of neighbors
1918 on nonbroadcast networks.
1921 protocol ospf <name> {
1922 rfc1583compat <switch>;
1923 stub router <switch>;
1925 ecmp <switch> [limit <num>];
1929 summary <switch>;
1930 default nssa <switch>;
1931 default cost <num>;
1932 default cost2 <num>;
1933 translator <switch>;
1934 translator stability <num>;
1938 <prefix> hidden;
1942 <prefix> hidden;
1943 <prefix> tag <num>;
1945 stubnet <prefix>;
1946 stubnet <prefix> {
1947 hidden <switch>;
1948 summary <switch>;
1951 interface <interface pattern> [instance <num>] {
1953 stub <switch>;
1956 retransmit <num>;
1957 priority <num>;
1959 dead count <num>;
1961 rx buffer [normal|large|<num>];
1962 type [broadcast|bcast|pointopoint|ptp|
1963 nonbroadcast|nbma|pointomultipoint|ptmp];
1964 strict nonbroadcast <switch>;
1965 real broadcast <switch>;
1966 ptp netmask <switch>;
1967 check link <switch>;
1968 ecmp weight <num>;
1969 authentication [none|simple|cryptographic];
1970 password "<text>";
1971 password "<text>" {
1973 generate from "<date>";
1974 generate to "<date>";
1975 accept from "<date>";
1976 accept to "<date>";
1980 <ip> eligible;
1983 virtual link <id> [instance <num>] {
1985 retransmit <num>;
1987 dead count <num>;
1989 authentication [none|simple|cryptographic];
1990 password "<text>";
1997 <tag>rfc1583compat <M>switch</M></tag>
1998 This option controls compatibility of routing table
1999 calculation with RFC 1583<htmlurl
2000 url="ftp://ftp.rfc-editor.org/in-notes/rfc1583.txt">. Default
2003 <tag>stub router <M>switch</M></tag>
2004 This option configures the router to be a stub router, i.e.,
2005 a router that participates in the OSPF topology but does not
2006 allow transit traffic. In OSPFv2, this is implemented by
2007 advertising maximum metric for outgoing links, as suggested
2008 by RFC 3137<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc3137.txt">.
2009 In OSPFv3, the stub router behavior is announced by clearing
2010 the R-bit in the router LSA. Default value is no.
2012 <tag>tick <M>num</M></tag>
2013 The routing table calculation and clean-up of areas' databases
2014 is not performed when a single link state
2015 change arrives. To lower the CPU utilization, it's processed later
2016 at periodical intervals of <m/num/ seconds. The default value is 1.
2018 <tag>ecmp <M>switch</M> [limit <M>number</M>]</tag>
2019 This option specifies whether OSPF is allowed to generate
2020 ECMP (equal-cost multipath) routes. Such routes are used when
2021 there are several directions to the destination, each with
2022 the same (computed) cost. This option also allows to specify
2023 a limit on maximal number of nexthops in one route. By
2024 default, ECMP is disabled. If enabled, default value of the
2027 <tag>area <M>id</M></tag>
2028 This defines an OSPF area with given area ID (an integer or an IPv4
2029 address, similarly to a router ID). The most important area is
2030 the backbone (ID 0) to which every other area must be connected.
2033 This option configures the area to be a stub area. External
2034 routes are not flooded into stub areas. Also summary LSAs can be
2035 limited in stub areas (see option <cf/summary/).
2036 By default, the area is not a stub area.
2039 This option configures the area to be a NSSA (Not-So-Stubby
2040 Area). NSSA is a variant of a stub area which allows a
2041 limited way of external route propagation. Global external
2042 routes are not propagated into a NSSA, but an external route
2043 can be imported into NSSA as a (area-wide) NSSA-LSA (and
2044 possibly translated and/or aggregated on area boundary).
2045 By default, the area is not NSSA.
2047 <tag>summary <M>switch</M></tag>
2048 This option controls propagation of summary LSAs into stub or
2049 NSSA areas. If enabled, summary LSAs are propagated as usual,
2050 otherwise just the default summary route (0.0.0.0/0) is
2051 propagated (this is sometimes called totally stubby area). If
2052 a stub area has more area boundary routers, propagating
2053 summary LSAs could lead to more efficient routing at the cost
2054 of larger link state database. Default value is no.
2056 <tag>default nssa <M>switch</M></tag>
2057 When <cf/summary/ option is enabled, default summary route is
2058 no longer propagated to the NSSA. In that case, this option
2059 allows to originate default route as NSSA-LSA to the NSSA.
2060 Default value is no.
2062 <tag>default cost <M>num</M></tag>
2063 This option controls the cost of a default route propagated to
2064 stub and NSSA areas. Default value is 1000.
2066 <tag>default cost2 <M>num</M></tag>
2067 When a default route is originated as NSSA-LSA, its cost
2068 can use either type 1 or type 2 metric. This option allows
2069 to specify the cost of a default route in type 2 metric.
2070 By default, type 1 metric (option <cf/default cost/) is used.
2072 <tag>translator <M>switch</M></tag>
2073 This option controls translation of NSSA-LSAs into external
2074 LSAs. By default, one translator per NSSA is automatically
2075 elected from area boundary routers. If enabled, this area
2076 boundary router would unconditionally translate all NSSA-LSAs
2077 regardless of translator election. Default value is no.
2079 <tag>translator stability <M>num</M></tag>
2080 This option controls the translator stability interval (in
2081 seconds). When the new translator is elected, the old one
2082 keeps translating until the interval is over. Default value
2085 <tag>networks { <m/set/ }</tag>
2086 Definition of area IP ranges. This is used in summary LSA origination.
2087 Hidden networks are not propagated into other areas.
2089 <tag>external { <m/set/ }</tag>
2090 Definition of external area IP ranges for NSSAs. This is used
2091 for NSSA-LSA translation. Hidden networks are not translated
2092 into external LSAs. Networks can have configured route tag.
2094 <tag>stubnet <m/prefix/ { <m/options/ }</tag>
2095 Stub networks are networks that are not transit networks
2096 between OSPF routers. They are also propagated through an
2097 OSPF area as a part of a link state database. By default,
2098 BIRD generates a stub network record for each primary network
2099 address on each OSPF interface that does not have any OSPF
2100 neighbors, and also for each non-primary network address on
2101 each OSPF interface. This option allows to alter a set of
2102 stub networks propagated by this router.
2104 Each instance of this option adds a stub network with given
2105 network prefix to the set of propagated stub network, unless
2106 option <cf/hidden/ is used. It also suppresses default stub
2107 networks for given network prefix. When option
2108 <cf/summary/ is used, also default stub networks that are
2109 subnetworks of given stub network are suppressed. This might
2110 be used, for example, to aggregate generated stub networks.
2112 <tag>interface <M>pattern</M> [instance <m/num/]</tag>
2113 Defines that the specified interfaces belong to the area being defined.
2114 See <ref id="dsc-iface" name="interface"> common option for detailed description.
2115 In OSPFv3, you can specify instance ID for that interface
2116 description, so it is possible to have several instances of
2117 that interface with different options or even in different areas.
2119 <tag>virtual link <M>id</M> [instance <m/num/]</tag>
2120 Virtual link to router with the router id. Virtual link acts
2121 as a point-to-point interface belonging to backbone. The
2122 actual area is used as transport area. This item cannot be in
2123 the backbone. In OSPFv3, you could also use several virtual
2124 links to one destination with different instance IDs.
2126 <tag>cost <M>num</M></tag>
2127 Specifies output cost (metric) of an interface. Default value is 10.
2129 <tag>stub <M>switch</M></tag>
2130 If set to interface it does not listen to any packet and does not send
2131 any hello. Default value is no.
2133 <tag>hello <M>num</M></tag>
2134 Specifies interval in seconds between sending of Hello messages. Beware, all
2135 routers on the same network need to have the same hello interval.
2136 Default value is 10.
2138 <tag>poll <M>num</M></tag>
2139 Specifies interval in seconds between sending of Hello messages for
2140 some neighbors on NBMA network. Default value is 20.
2142 <tag>retransmit <M>num</M></tag>
2143 Specifies interval in seconds between retransmissions of unacknowledged updates.
2146 <tag>priority <M>num</M></tag>
2147 On every multiple access network (e.g., the Ethernet) Designed Router
2148 and Backup Designed router are elected. These routers have some
2149 special functions in the flooding process. Higher priority increases
2150 preferences in this election. Routers with priority 0 are not
2151 eligible. Default value is 1.
2153 <tag>wait <M>num</M></tag>
2154 After start, router waits for the specified number of seconds between starting
2155 election and building adjacency. Default value is 40.
2157 <tag>dead count <M>num</M></tag>
2158 When the router does not receive any messages from a neighbor in
2159 <m/dead count/*<m/hello/ seconds, it will consider the neighbor down.
2161 <tag>dead <M>num</M></tag>
2162 When the router does not receive any messages from a neighbor in
2163 <m/dead/ seconds, it will consider the neighbor down. If both directives
2164 <m/dead count/ and <m/dead/ are used, <m/dead/ has precendence.
2166 <tag>rx buffer <M>num</M></tag>
2167 This sets the size of buffer used for receiving packets. The buffer should
2168 be bigger than maximal size of any packets. Value NORMAL (default)
2169 means 2*MTU, value LARGE means maximal allowed packet - 65535.
2171 <tag>type broadcast|bcast</tag>
2172 BIRD detects a type of a connected network automatically, but
2173 sometimes it's convenient to force use of a different type
2174 manually. On broadcast networks (like ethernet), flooding
2175 and Hello messages are sent using multicasts (a single packet
2176 for all the neighbors). A designated router is elected and it
2177 is responsible for synchronizing the link-state databases and
2178 originating network LSAs. This network type cannot be used on
2179 physically NBMA networks and on unnumbered networks (networks
2180 without proper IP prefix).
2182 <tag>type pointopoint|ptp</tag>
2183 Point-to-point networks connect just 2 routers together. No
2184 election is performed and no network LSA is originated, which
2185 makes it simpler and faster to establish. This network type
2186 is useful not only for physically PtP ifaces (like PPP or
2187 tunnels), but also for broadcast networks used as PtP links.
2188 This network type cannot be used on physically NBMA networks.
2190 <tag>type nonbroadcast|nbma</tag>
2191 On NBMA networks, the packets are sent to each neighbor
2192 separately because of lack of multicast capabilities.
2193 Like on broadcast networks, a designated router is elected,
2194 which plays a central role in propagation of LSAs.
2195 This network type cannot be used on unnumbered networks.
2197 <tag>type pointomultipoint|ptmp</tag>
2198 This is another network type designed to handle NBMA
2199 networks. In this case the NBMA network is treated as a
2200 collection of PtP links. This is useful if not every pair of
2201 routers on the NBMA network has direct communication, or if
2202 the NBMA network is used as an (possibly unnumbered) PtP
2205 <tag>strict nonbroadcast <M>switch</M></tag>
2206 If set, don't send hello to any undefined neighbor. This switch
2207 is ignored on other than NBMA or PtMP networks. Default value is no.
2209 <tag>real broadcast <m/switch/</tag>
2210 In <cf/type broadcast/ or <cf/type ptp/ network
2211 configuration, OSPF packets are sent as IP multicast
2212 packets. This option changes the behavior to using
2213 old-fashioned IP broadcast packets. This may be useful as a
2214 workaround if IP multicast for some reason does not work or
2215 does not work reliably. This is a non-standard option and
2216 probably is not interoperable with other OSPF
2217 implementations. Default value is no.
2219 <tag>ptp netmask <m/switch/</tag>
2220 In <cf/type ptp/ network configurations, OSPFv2
2221 implementations should ignore received netmask field in hello
2222 packets and should send hello packets with zero netmask field
2223 on unnumbered PtP links. But some OSPFv2 implementations
2224 perform netmask checking even for PtP links. This option
2225 specifies whether real netmask will be used in hello packets
2226 on <cf/type ptp/ interfaces. You should ignore this option
2227 unless you meet some compatibility problems related to this
2228 issue. Default value is no for unnumbered PtP links, yes
2231 <tag>check link <M>switch</M></tag>
2232 If set, a hardware link state (reported by OS) is taken into
2233 consideration. When a link disappears (e.g. an ethernet cable is
2234 unplugged), neighbors are immediately considered unreachable
2235 and only the address of the iface (instead of whole network
2236 prefix) is propagated. It is possible that some hardware
2237 drivers or platforms do not implement this feature. Default value is no.
2239 <tag>tx class|dscp|priority <m/num/</tag>
2240 These options specify the ToS/DiffServ/Traffic class/Priority
2241 of the outgoing OSPF packets. See <ref id="dsc-prio" name="tx
2242 class"> common option for detailed description.
2244 <tag>ecmp weight <M>num</M></tag>
2245 When ECMP (multipath) routes are allowed, this value specifies
2246 a relative weight used for nexthops going through the iface.
2247 Allowed values are 1-256. Default value is 1.
2249 <tag>authentication none</tag>
2250 No passwords are sent in OSPF packets. This is the default value.
2252 <tag>authentication simple</tag>
2253 Every packet carries 8 bytes of password. Received packets
2254 lacking this password are ignored. This authentication mechanism is
2257 <tag>authentication cryptographic</tag>
2258 16-byte long MD5 digest is appended to every packet. For the digest
2259 generation 16-byte long passwords are used. Those passwords are
2260 not sent via network, so this mechanism is quite secure.
2261 Packets can still be read by an attacker.
2263 <tag>password "<M>text</M>"</tag>
2264 An 8-byte or 16-byte password used for authentication.
2265 See <ref id="dsc-pass" name="password"> common option for detailed description.
2267 <tag>neighbors { <m/set/ } </tag>
2268 A set of neighbors to which Hello messages on NBMA or PtMP
2269 networks are to be sent. For NBMA networks, some of them
2270 could be marked as eligible. In OSPFv3, link-local addresses
2271 should be used, using global ones is possible, but it is
2272 nonstandard and might be problematic. And definitely,
2273 link-local and global addresses should not be mixed.
2279 <p>OSPF defines four route attributes. Each internal route has a <cf/metric/.
2280 Metric is ranging from 1 to infinity (65535).
2281 External routes use <cf/metric type 1/ or <cf/metric type 2/.
2282 A <cf/metric of type 1/ is comparable with internal <cf/metric/, a
2283 <cf/metric of type 2/ is always longer
2284 than any <cf/metric of type 1/ or any <cf/internal metric/.
2285 <cf/Internal metric/ or <cf/metric of type 1/ is stored in attribute
2286 <cf/ospf_metric1/, <cf/metric type 2/ is stored in attribute <cf/ospf_metric2/.
2287 If you specify both metrics only metric1 is used.
2289 Each external route can also carry attribute <cf/ospf_tag/ which is a
2290 32-bit integer which is used when exporting routes to other protocols;
2291 otherwise, it doesn't affect routing inside the OSPF domain at all.
2292 The fourth attribute <cf/ospf_router_id/ is a router ID of the router
2293 advertising that route/network. This attribute is read-only. Default
2294 is <cf/ospf_metric2 = 10000/ and <cf/ospf_tag = 0/.
2301 protocol ospf MyOSPF {
2305 if source = RTS_BGP then {
2317 authentication simple;
2322 authentication cryptographic;
2325 generate to "22-04-2003 11:00:06";
2326 accept from "17-01-2001 12:01:05";
2330 generate to "22-07-2005 17:03:21";
2331 accept from "22-02-2001 11:34:06";
2344 172.16.2.0/24 hidden;
2346 interface "-arc0" , "arc*" {
2348 authentication none;
2349 strict nonbroadcast yes;
2354 192.168.120.1 eligible;
2367 <p>The Pipe protocol serves as a link between two routing tables, allowing routes to be
2368 passed from a table declared as primary (i.e., the one the pipe is connected to using the
2369 <cf/table/ configuration keyword) to the secondary one (declared using <cf/peer table/)
2370 and vice versa, depending on what's allowed by the filters. Export filters control export
2371 of routes from the primary table to the secondary one, import filters control the opposite
2374 <p>The Pipe protocol may work in the transparent mode mode or in the opaque mode.
2375 In the transparent mode, the Pipe protocol retransmits all routes from
2376 one table to the other table, retaining their original source and
2377 attributes. If import and export filters are set to accept, then both
2378 tables would have the same content. The transparent mode is the default mode.
2380 <p>In the opaque mode, the Pipe protocol retransmits optimal route
2381 from one table to the other table in a similar way like other
2382 protocols send and receive routes. Retransmitted route will have the
2383 source set to the Pipe protocol, which may limit access to protocol
2384 specific route attributes. This mode is mainly for compatibility, it
2385 is not suggested for new configs. The mode can be changed by
2388 <p>The primary use of multiple routing tables and the Pipe protocol is for policy routing,
2389 where handling of a single packet doesn't depend only on its destination address, but also
2390 on its source address, source interface, protocol type and other similar parameters.
2391 In many systems (Linux being a good example), the kernel allows to enforce routing policies
2392 by defining routing rules which choose one of several routing tables to be used for a packet
2393 according to its parameters. Setting of these rules is outside the scope of BIRD's work
2394 (on Linux, you can use the <tt/ip/ command), but you can create several routing tables in BIRD,
2395 connect them to the kernel ones, use filters to control which routes appear in which tables
2396 and also you can employ the Pipe protocol for exporting a selected subset of one table to
2399 <sect1>Configuration
2402 <tag>peer table <m/table/</tag> Defines secondary routing table to connect to. The
2403 primary one is selected by the <cf/table/ keyword.
2405 <tag>mode opaque|transparent</tag> Specifies the mode for the pipe to work in. Default is opaque.
2410 <p>The Pipe protocol doesn't define any route attributes.
2414 <p>Let's consider a router which serves as a boundary router of two different autonomous
2415 systems, each of them connected to a subset of interfaces of the router, having its own
2416 exterior connectivity and wishing to use the other AS as a backup connectivity in case
2417 of outage of its own exterior line.
2419 <p>Probably the simplest solution to this situation is to use two routing tables (we'll
2420 call them <cf/as1/ and <cf/as2/) and set up kernel routing rules, so that packets having
2421 arrived from interfaces belonging to the first AS will be routed according to <cf/as1/
2422 and similarly for the second AS. Thus we have split our router to two logical routers,
2423 each one acting on its own routing table, having its own routing protocols on its own
2424 interfaces. In order to use the other AS's routes for backup purposes, we can pass
2425 the routes between the tables through a Pipe protocol while decreasing their preferences
2426 and correcting their BGP paths to reflect the AS boundary crossing.
2429 table as1; # Define the tables
2432 protocol kernel kern1 { # Synchronize them with the kernel
2437 protocol kernel kern2 {
2442 protocol bgp bgp1 { # The outside connections
2445 neighbor 192.168.0.1 as 1001;
2453 neighbor 10.0.0.1 as 1002;
2458 protocol pipe { # The Pipe
2462 if net ~ [ 1.0.0.0/8+] then { # Only AS1 networks
2463 if preference>10 then preference = preference-10;
2464 if source=RTS_BGP then bgp_path.prepend(1);
2470 if net ~ [ 2.0.0.0/8+] then { # Only AS2 networks
2471 if preference>10 then preference = preference-10;
2472 if source=RTS_BGP then bgp_path.prepend(2);
2484 <p>The RAdv protocol is an implementation of Router Advertisements,
2485 which are used in the IPv6 stateless autoconfiguration. IPv6 routers
2486 send (in irregular time intervals or as an answer to a request)
2487 advertisement packets to connected networks. These packets contain
2488 basic information about a local network (e.g. a list of network
2489 prefixes), which allows network hosts to autoconfigure network
2490 addresses and choose a default route. BIRD implements router behavior
2492 RFC 4861<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4861.txt">
2493 and also the DNS extensions from
2494 RFC 6106<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc6106.txt">.
2496 <sect1>Configuration
2498 <p>There are several classes of definitions in RAdv configuration --
2499 interface definitions, prefix definitions and DNS definitions:
2502 <tag>interface <m/pattern [, ...]/ { <m/options/ }</tag>
2503 Interface definitions specify a set of interfaces on which the
2504 protocol is activated and contain interface specific options.
2505 See <ref id="dsc-iface" name="interface"> common options for
2506 detailed description.
2508 <tag>prefix <m/prefix/ { <m/options/ }</tag>
2509 Prefix definitions allow to modify a list of advertised
2510 prefixes. By default, the advertised prefixes are the same as
2511 the network prefixes assigned to the interface. For each
2512 network prefix, the matching prefix definition is found and
2513 its options are used. If no matching prefix definition is
2514 found, the prefix is used with default options.
2516 Prefix definitions can be either global or interface-specific.
2517 The second ones are part of interface options. The prefix
2518 definition matching is done in the first-match style, when
2519 interface-specific definitions are processed before global
2520 definitions. As expected, the prefix definition is matching if
2521 the network prefix is a subnet of the prefix in prefix
2524 <tag>rdnss { <m/options/ }</tag>
2525 RDNSS definitions allow to specify a list of advertised
2526 recursive DNS servers together with their options. As options
2527 are seldom necessary, there is also a short variant <cf>rdnss
2528 <m/address/</cf> that just specifies one DNS server. Multiple
2529 definitions are cumulative. RDNSS definitions may also be
2530 interface-specific when used inside interface options. By
2531 default, interface uses both global and interface-specific
2532 options, but that can be changed by <cf/rdnss local/ option.
2534 <tag>dnssl { <m/options/ }</tag>
2535 DNSSL definitions allow to specify a list of advertised DNS
2536 search domains together with their options. Like <cf/rdnss/
2537 above, multiple definitions are cumulative, they can be used
2538 also as interface-specific options and there is a short
2539 variant <cf>dnssl <m/domain/</cf> that just specifies one DNS
2542 <label id="dsc-trigger"> <tag>trigger <m/prefix/</tag>
2543 RAdv protocol could be configured to change its behavior based
2544 on availability of routes. When this option is used, the
2545 protocol waits in suppressed state until a <it/trigger route/
2546 (for the specified network) is exported to the protocol, the
2547 protocol also returnsd to suppressed state if the
2548 <it/trigger route/ disappears. Note that route export depends
2549 on specified export filter, as usual. This option could be
2550 used, e.g., for handling failover in multihoming scenarios.
2552 During suppressed state, router advertisements are generated,
2553 but with some fields zeroed. Exact behavior depends on which
2554 fields are zeroed, this can be configured by
2555 <cf/sensitive/ option for appropriate fields. By default, just
2556 <cf/default lifetime/ (also called <cf/router lifetime/) is
2557 zeroed, which means hosts cannot use the router as a default
2558 router. <cf/preferred lifetime/ and <cf/valid lifetime/ could
2559 also be configured as <cf/sensitive/ for a prefix, which would
2560 cause autoconfigured IPs to be deprecated or even removed.
2563 <p>Interface specific options:
2566 <tag>max ra interval <m/expr/</tag>
2567 Unsolicited router advertisements are sent in irregular time
2568 intervals. This option specifies the maximum length of these
2569 intervals, in seconds. Valid values are 4-1800. Default: 600
2571 <tag>min ra interval <m/expr/</tag>
2572 This option specifies the minimum length of that intervals, in
2573 seconds. Must be at least 3 and at most 3/4 * <cf/max ra interval/.
2574 Default: about 1/3 * <cf/max ra interval/.
2576 <tag>min delay <m/expr/</tag>
2577 The minimum delay between two consecutive router advertisements,
2578 in seconds. Default: 3
2580 <tag>managed <m/switch/</tag>
2581 This option specifies whether hosts should use DHCPv6 for
2582 IP address configuration. Default: no
2584 <tag>other config <m/switch/</tag>
2585 This option specifies whether hosts should use DHCPv6 to
2586 receive other configuration information. Default: no
2588 <tag>link mtu <m/expr/</tag>
2589 This option specifies which value of MTU should be used by
2590 hosts. 0 means unspecified. Default: 0
2592 <tag>reachable time <m/expr/</tag>
2593 This option specifies the time (in milliseconds) how long
2594 hosts should assume a neighbor is reachable (from the last
2595 confirmation). Maximum is 3600000, 0 means unspecified.
2598 <tag>retrans timer <m/expr/</tag>
2599 This option specifies the time (in milliseconds) how long
2600 hosts should wait before retransmitting Neighbor Solicitation
2601 messages. 0 means unspecified. Default 0.
2603 <tag>current hop limit <m/expr/</tag>
2604 This option specifies which value of Hop Limit should be used
2605 by hosts. Valid values are 0-255, 0 means unspecified. Default: 64
2607 <tag>default lifetime <m/expr/ [sensitive <m/switch/]</tag>
2608 This option specifies the time (in seconds) how long (after
2609 the receipt of RA) hosts may use the router as a default
2610 router. 0 means do not use as a default router. For
2611 <cf/sensitive/ option, see <ref id="dsc-trigger" name="trigger">.
2612 Default: 3 * <cf/max ra interval/, <cf/sensitive/ yes.
2614 <tag>rdnss local <m/switch/</tag>
2615 Use only local (interface-specific) RDNSS definitions for this
2616 interface. Otherwise, both global and local definitions are
2617 used. Could also be used to disable RDNSS for given interface
2618 if no local definitons are specified. Default: no.
2620 <tag>dnssl local <m/switch/</tag>
2621 Use only local DNSSL definitions for this interface. See
2622 <cf/rdnss local/ option above. Default: no.
2626 <p>Prefix specific options:
2629 <tag>skip <m/switch/</tag>
2630 This option allows to specify that given prefix should not be
2631 advertised. This is useful for making exceptions from a
2632 default policy of advertising all prefixes. Note that for
2633 withdrawing an already advertised prefix it is more useful to
2634 advertise it with zero valid lifetime. Default: no
2636 <tag>onlink <m/switch/</tag>
2637 This option specifies whether hosts may use the advertised
2638 prefix for onlink determination. Default: yes
2640 <tag>autonomous <m/switch/</tag>
2641 This option specifies whether hosts may use the advertised
2642 prefix for stateless autoconfiguration. Default: yes
2644 <tag>valid lifetime <m/expr/ [sensitive <m/switch/]</tag>
2645 This option specifies the time (in seconds) how long (after
2646 the receipt of RA) the prefix information is valid, i.e.,
2647 autoconfigured IP addresses can be assigned and hosts with
2648 that IP addresses are considered directly reachable. 0 means
2649 the prefix is no longer valid. For <cf/sensitive/ option, see
2650 <ref id="dsc-trigger" name="trigger">. Default: 86400 (1 day), <cf/sensitive/ no.
2652 <tag>preferred lifetime <m/expr/ [sensitive <m/switch/]</tag>
2653 This option specifies the time (in seconds) how long (after
2654 the receipt of RA) IP addresses generated from the prefix
2655 using stateless autoconfiguration remain preferred. For
2656 <cf/sensitive/ option, see <ref id="dsc-trigger" name="trigger">.
2657 Default: 14400 (4 hours), <cf/sensitive/ no.
2661 <p>RDNSS specific options:
2664 <tag>ns <m/address/</tag>
2665 This option specifies one recursive DNS server. Can be used
2666 multiple times for multiple servers. It is mandatory to have
2667 at least one <cf/ns/ option in <cf/rdnss/ definition.
2669 <tag>lifetime [mult] <m/expr/</tag>
2670 This option specifies the time how long the RDNSS information
2671 may be used by clients after the receipt of RA. It is
2672 expressed either in seconds or (when <cf/mult/ is used) in
2673 multiples of <cf/max ra interval/. Note that RDNSS information
2674 is also invalidated when <cf/default lifetime/ expires. 0
2675 means these addresses are no longer valid DNS servers.
2676 Default: 3 * <cf/max ra interval/.
2680 <p>DNSSL specific options:
2683 <tag>domain <m/address/</tag>
2684 This option specifies one DNS search domain. Can be used
2685 multiple times for multiple domains. It is mandatory to have
2686 at least one <cf/domain/ option in <cf/dnssl/ definition.
2688 <tag>lifetime [mult] <m/expr/</tag>
2689 This option specifies the time how long the DNSSL information
2690 may be used by clients after the receipt of RA. Details are
2691 the same as for RDNSS <cf/lifetime/ option above.
2692 Default: 3 * <cf/max ra interval/.
2701 max ra interval 5; # Fast failover with more routers
2702 managed yes; # Using DHCPv6 on eth2
2704 autonomous off; # So do not autoconfigure any IP
2708 interface "eth*"; # No need for any other options
2710 prefix 2001:0DB8:1234::/48 {
2711 preferred lifetime 0; # Deprecated address range
2714 prefix 2001:0DB8:2000::/48 {
2715 autonomous off; # Do not autoconfigure
2718 rdnss 2001:0DB8:1234::10; # Short form of RDNSS
2722 ns 2001:0DB8:1234::11;
2723 ns 2001:0DB8:1234::12;
2738 <p>The RIP protocol (also sometimes called Rest In Pieces) is a simple protocol, where each router broadcasts (to all its neighbors)
2739 distances to all networks it can reach. When a router hears distance to another network, it increments
2740 it and broadcasts it back. Broadcasts are done in regular intervals. Therefore, if some network goes
2741 unreachable, routers keep telling each other that its distance is the original distance plus 1 (actually, plus
2742 interface metric, which is usually one). After some time, the distance reaches infinity (that's 15 in
2743 RIP) and all routers know that network is unreachable. RIP tries to minimize situations where
2744 counting to infinity is necessary, because it is slow. Due to infinity being 16, you can't use
2745 RIP on networks where maximal distance is higher than 15 hosts. You can read more about RIP at <HTMLURL
2746 URL="http://www.ietf.org/html.charters/rip-charter.html" name="http://www.ietf.org/html.charters/rip-charter.html">. Both IPv4
2747 (RFC 1723<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1723.txt">)
2748 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
2749 not currently supported. RIPv4 MD5 authentication (RFC 2082<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2082.txt">) is supported.
2751 <p>RIP is a very simple protocol, and it has a lot of shortcomings. Slow
2752 convergence, big network load and inability to handle larger networks
2753 makes it pretty much obsolete. (It is still usable on very small networks.)
2755 <sect1>Configuration
2757 <p>In addition to options common for all to other protocols, RIP supports the following ones:
2760 <tag/authentication none|plaintext|md5/ selects authentication method to be used. <cf/none/ means that
2761 packets are not authenticated at all, <cf/plaintext/ means that a plaintext password is embedded
2762 into each packet, and <cf/md5/ means that packets are authenticated using a MD5 cryptographic
2763 hash. If you set authentication to not-none, it is a good idea to add <cf>password</cf>
2764 section. Default: none.
2766 <tag>honor always|neighbor|never </tag>specifies when should requests for dumping routing table
2767 be honored. (Always, when sent from a host on a directly connected
2768 network or never.) Routing table updates are honored only from
2769 neighbors, that is not configurable. Default: never.
2772 <p>There are some options that can be specified per-interface:
2775 <tag>metric <m/num/</tag>
2776 This option specifies the metric of the interface. Valid
2778 <tag>mode multicast|broadcast|quiet|nolisten|version1</tag>
2779 This option selects the mode for RIP to work in. If nothing is
2780 specified, RIP runs in multicast mode. <cf/version1/ is
2781 currently equivalent to <cf/broadcast/, and it makes RIP talk
2782 to a broadcast address even through multicast mode is
2783 possible. <cf/quiet/ option means that RIP will not transmit
2784 any periodic messages to this interface and <cf/nolisten/
2785 means that RIP will send to this interface butnot listen to it.
2787 <tag>tx class|dscp|priority <m/num/</tag>
2788 These options specify the ToS/DiffServ/Traffic class/Priority
2789 of the outgoing RIP packets. See <ref id="dsc-prio" name="tx
2790 class"> common option for detailed description.
2793 <p>The following options generally override behavior specified in RFC. If you use any of these
2794 options, BIRD will no longer be RFC-compliant, which means it will not be able to talk to anything
2795 other than equally configured BIRD. I have warned you.
2798 <tag>port <M>number</M></tag>
2799 selects IP port to operate on, default 520. (This is useful when testing BIRD, if you
2800 set this to an address >1024, you will not need to run bird with UID==0).
2802 <tag>infinity <M>number</M></tag>
2803 selects the value of infinity, default is 16. Bigger values will make protocol convergence
2806 <tag>period <M>number</M>
2807 </tag>specifies the number of seconds between periodic updates. Default is 30 seconds. A lower
2808 number will mean faster convergence but bigger network
2809 load. Do not use values lower than 12.
2811 <tag>timeout time <M>number</M>
2812 </tag>specifies how old route has to be to be considered unreachable. Default is 4*<cf/period/.
2814 <tag>garbage time <M>number</M>
2815 </tag>specifies how old route has to be to be discarded. Default is 10*<cf/period/.
2820 <p>RIP defines two route attributes:
2823 <tag>int <cf/rip_metric/</tag> RIP metric of the route (ranging from 0 to <cf/infinity/).
2824 When routes from different RIP instances are available and all of them have the same
2825 preference, BIRD prefers the route with lowest <cf/rip_metric/.
2826 When importing a non-RIP route, the metric defaults to 5.
2828 <tag>int <cf/rip_tag/</tag> RIP route tag: a 16-bit number which can be used
2829 to carry additional information with the route (for example, an originating AS number
2830 in case of external routes). When importing a non-RIP route, the tag defaults to 0.
2836 protocol rip MyRIP_test {
2841 interface "eth0" { metric 3; mode multicast; };
2842 interface "eth*" { metric 2; mode broadcast; };
2844 authentication none;
2845 import filter { print "importing"; accept; };
2846 export filter { print "exporting"; accept; };
2852 <p>The Static protocol doesn't communicate with other routers in the network,
2853 but instead it allows you to define routes manually. This is often used for
2854 specifying how to forward packets to parts of the network which don't use
2855 dynamic routing at all and also for defining sink routes (i.e., those
2856 telling to return packets as undeliverable if they are in your IP block,
2857 you don't have any specific destination for them and you don't want to send
2858 them out through the default route to prevent routing loops).
2860 <p>There are five types of static routes: `classical' routes telling
2861 to forward packets to a neighboring router, multipath routes
2862 specifying several (possibly weighted) neighboring routers, device
2863 routes specifying forwarding to hosts on a directly connected network,
2864 recursive routes computing their nexthops by doing route table lookups
2865 for a given IP and special routes (sink, blackhole etc.) which specify
2866 a special action to be done instead of forwarding the packet.
2868 <p>When the particular destination is not available (the interface is down or
2869 the next hop of the route is not a neighbor at the moment), Static just
2870 uninstalls the route from the table it is connected to and adds it again as soon
2871 as the destination becomes adjacent again.
2873 <p>The Static protocol does not have many configuration options. The
2874 definition of the protocol contains mainly a list of static routes:
2877 <tag>route <m/prefix/ via <m/ip/</tag> Static route through
2878 a neighboring router.
2879 <tag>route <m/prefix/ multipath via <m/ip/ [weight <m/num/] [via ...]</tag>
2880 Static multipath route. Contains several nexthops (gateways), possibly
2882 <tag>route <m/prefix/ via <m/"interface"/</tag> Static device
2883 route through an interface to hosts on a directly connected network.
2884 <tag>route <m/prefix/ recursive <m/ip/</tag> Static recursive route,
2885 its nexthop depends on a route table lookup for given IP address.
2886 <tag>route <m/prefix/ blackhole|unreachable|prohibit</tag> Special routes
2887 specifying to silently drop the packet, return it as unreachable or return
2888 it as administratively prohibited. First two targets are also known
2889 as <cf/drop/ and <cf/reject/.
2891 <tag>check link <m/switch/</tag>
2892 If set, hardware link states of network interfaces are taken
2893 into consideration. When link disappears (e.g. ethernet cable
2894 is unplugged), static routes directing to that interface are
2895 removed. It is possible that some hardware drivers or
2896 platforms do not implement this feature. Default: off.
2898 <tag>igp table <m/name/</tag> Specifies a table that is used
2899 for route table lookups of recursive routes. Default: the
2900 same table as the protocol is connected to.
2903 <p>Static routes have no specific attributes.
2905 <p>Example static config might look like this:
2909 table testable; # Connect to a non-default routing table
2910 route 0.0.0.0/0 via 198.51.100.130; # Default route
2911 route 10.0.0.0/8 multipath # Multipath route
2912 via 198.51.100.10 weight 2
2915 route 203.0.113.0/24 unreachable; # Sink route
2916 route 10.2.0.0/24 via "arc0"; # Secondary network
2924 <p>Although BIRD supports all the commonly used routing protocols,
2925 there are still some features which would surely deserve to be
2926 implemented in future versions of BIRD:
2930 <item>Route aggregation and flap dampening
2931 <item>Multipath routes
2932 <item>Multicast routing protocols
2933 <item>Ports to other systems
2936 <sect>Getting more help
2938 <p>If you use BIRD, you're welcome to join the bird-users mailing list
2939 (<HTMLURL URL="mailto:bird-users@bird.network.cz" name="bird-users@bird.network.cz">)
2940 where you can share your experiences with the other users and consult
2941 your problems with the authors. To subscribe to the list, just send a
2942 <tt/subscribe bird-users/ command in a body of a mail to
2943 (<HTMLURL URL="mailto:majordomo@bird.network.cz" name="majordomo@bird.network.cz">).
2944 The home page of BIRD can be found at <HTMLURL URL="http://bird.network.cz/" name="http://bird.network.cz/">.
2946 <p>BIRD is a relatively young system and it probably contains some
2947 bugs. You can report any problems to the bird-users list and the authors
2948 will be glad to solve them, but before you do so,
2949 please make sure you have read the available documentation and that you are running the latest version (available at <HTMLURL
2950 URL="ftp://bird.network.cz/pub/bird" name="bird.network.cz:/pub/bird">). (Of course, a patch
2951 which fixes the bug is always welcome as an attachment.)
2953 <p>If you want to understand what is going inside, Internet standards are
2954 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">).
2961 LocalWords: GPL IPv GateD BGPv RIPv OSPFv Linux sgml html dvi sgmltools Pavel
2962 LocalWords: linuxdoc dtd descrip config conf syslog stderr auth ospf bgp Mbps
2963 LocalWords: router's eval expr num birdc ctl UNIX if's enums bool int ip GCC
2964 LocalWords: len ipaddress pxlen netmask enum bgppath bgpmask clist gw md eth
2965 LocalWords: RTS printn quitbird iBGP AS'es eBGP RFC multiprotocol IGP Machek
2966 LocalWords: EGP misconfigurations keepalive pref aggr aggregator BIRD's RTC
2967 LocalWords: OS'es AS's multicast nolisten misconfigured UID blackhole MRTD MTU
2968 LocalWords: uninstalls ethernets IP binutils ANYCAST anycast dest RTD ICMP rfc
2969 LocalWords: compat multicasts nonbroadcast pointopoint loopback sym stats
2970 LocalWords: Perl SIGHUP dd mm yy HH MM SS EXT IA UNICAST multihop Discriminator txt
2971 LocalWords: proto wildcard Ondrej Filip