bird.sgml 147 KB
Newer Older
1
<!doctype birddoc system>
2 3

<!--
Pavel Machek's avatar
Pavel Machek committed
4
	BIRD documentation
5

6 7 8
This documentation can have 4 forms: sgml (this is master copy), html, ASCII
text and dvi/postscript (generated from sgml using sgmltools). You should always
edit master copy.
9

10 11 12 13
This is a slightly modified linuxdoc dtd. Anything in <descrip> tags is
considered definition of configuration primitives, <cf> is fragment of
configuration within normal text, <m> is "meta" information within fragment of
configuration - something in config which is not keyword.
14

15
    (set-fill-column 80)
16 17 18 19 20

    Copyright 1999,2000 Pavel Machek <pavel@ucw.cz>, distribute under GPL version 2 or later.

 -->

21
<book>
22

23
<title>BIRD User's Guide
24
<author>
25 26
Ondrej Filip <it/&lt;feela@network.cz&gt;/,
Pavel Machek <it/&lt;pavel@ucw.cz&gt;/,
27 28
Martin Mares <it/&lt;mj@ucw.cz&gt;/,
Ondrej Zajicek <it/&lt;santiago@crfreenet.org&gt;/
29
</author>
30 31

<abstract>
32
This document contains user documentation for the BIRD Internet Routing Daemon project.
33 34 35 36 37 38 39
</abstract>

<!-- Table of contents -->
<toc>

<!-- Begin the document -->

40

41
<chapt>Introduction
42

43
<sect>What is BIRD
44

45
<p><label id="intro">
46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78
The name `BIRD' is actually an acronym standing for `BIRD Internet Routing
Daemon'. Let's take a closer look at the meaning of the name:

<p><em/BIRD/: Well, we think we have already explained that. It's an acronym
standing for `BIRD Internet Routing Daemon', you remember, don't you? :-)

<p><em/Internet Routing/: It's a program (well, a daemon, as you are going to
discover in a moment) which works as a dynamic router in an Internet type
network (that is, in a network running either the IPv4 or the IPv6 protocol).
Routers are devices which forward packets between interconnected networks in
order to allow hosts not connected directly to the same local area network to
communicate with each other. They also communicate with the other routers in the
Internet to discover the topology of the network which allows them to find
optimal (in terms of some metric) rules for forwarding of packets (which are
called routing tables) and to adapt themselves to the changing conditions such
as outages of network links, building of new connections and so on. Most of
these routers are costly dedicated devices running obscure firmware which is
hard to configure and not open to any changes (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 computer to act as a
router and forward packets belonging to the other hosts, but only according to a
statically configured table.

<p>A <em/Routing Daemon/ is in UNIX terminology a non-interactive program
running on background which does the dynamic part of Internet routing, that is
it communicates with the other routers, calculates routing tables and sends them
to the OS kernel which does the actual packet forwarding. There already exist
other such routing daemons: routed (RIP only), GateD (non-free),
Zebra <HTMLURL URL="http://www.zebra.org"> and
MRTD <HTMLURL URL="http://sourceforge.net/projects/mrt">,
but their capabilities are limited and they are relatively hard to configure
and maintain.
79 80

<p>BIRD is an Internet Routing Daemon designed to avoid all of these shortcomings,
81 82 83 84
to support all the routing technology used in the today's Internet or planned to
be used in near future and to have a clean extensible architecture allowing new
routing protocols to be incorporated easily. Among other features, BIRD
supports:
85 86 87 88 89

<itemize>
	<item>both IPv4 and IPv6 protocols
	<item>multiple routing tables
	<item>the Border Gateway Protocol (BGPv4)
90
	<item>the Routing Information Protocol (RIPv2)
91
	<item>the Open Shortest Path First protocol (OSPFv2, OSPFv3)
92
	<item>the Router Advertisements for IPv6 hosts
93 94
	<item>a virtual protocol for exchange of routes between different
		routing tables on a single host
95 96
	<item>a command-line interface allowing on-line control and inspection
		of status of the daemon
97 98 99 100 101
	<item>soft reconfiguration (no need to use complex online commands to
		change the configuration, just edit the configuration file and
		notify BIRD to re-read it and it will smoothly switch itself to
		the new configuration, not disturbing routing protocols unless
		they are affected by the configuration changes)
102
	<item>a powerful language for route filtering
103 104
</itemize>

105 106 107 108 109 110 111 112
<p>BIRD has been developed at the Faculty of Math and Physics, Charles
University, Prague, Czech Republic as a student project. It can be freely
distributed under the terms of the GNU General Public License.

<p>BIRD has been designed to work on all UNIX-like systems. It has been
developed and tested under Linux 2.0 to 2.6, and then ported to FreeBSD, NetBSD
and OpenBSD, porting to other systems (even non-UNIX ones) should be relatively
easy due to its highly modular architecture.
113

114 115 116 117
<p>BIRD supports either IPv4 or IPv6 protocol, but have to be compiled separately
for each one. Therefore, a dualstack router would run two instances of BIRD (one
for IPv4 and one for IPv6), with completely separate setups (configuration
files, tools ...).
118

119

120
<sect>Installing BIRD
121

122 123
<p>On a recent UNIX system with GNU development tools (GCC, binutils, m4, make)
and Perl, installing BIRD should be as easy as:
124 125

<code>
126 127 128 129
	./configure
	make
	make install
	vi /usr/local/etc/bird.conf
Pavel Machek's avatar
Pavel Machek committed
130
	bird
131 132
</code>

133
<p>You can use <tt>./configure --help</tt> to get a list of configure
134 135 136 137 138
options. The most important ones are: <tt/--enable-ipv6/ which enables building
of an IPv6 version of BIRD, <tt/--with-protocols=/ to produce a slightly smaller
BIRD executable by configuring out routing protocols you don't use, and
<tt/--prefix=/ to install BIRD to a place different from <file>/usr/local</file>.

139

140
<sect>Running BIRD
141

Pavel Machek's avatar
Pavel Machek committed
142
<p>You can pass several command-line options to bird:
143

Pavel Machek's avatar
Pavel Machek committed
144 145
<descrip>
	<tag>-c <m/config name/</tag>
Martin Mareš's avatar
Martin Mareš committed
146
	use given configuration file instead of <it/prefix/<file>/etc/bird.conf</file>.
Pavel Machek's avatar
Pavel Machek committed
147 148

	<tag>-d</tag>
149
	enable debug messages and run bird in foreground.
Pavel Machek's avatar
Pavel Machek committed
150

151
	<tag>-D <m/filename of debug log/</tag>
152 153 154
	log debugging information to given file instead of stderr.

	<tag>-p</tag>
155 156
	just parse the config file and exit. Return value is zero if the config
	file is valid, nonzero if there are some errors.
Pavel Machek's avatar
Pavel Machek committed
157 158

	<tag>-s <m/name of communication socket/</tag>
159 160
	use given filename for a socket for communications with the client,
	default is <it/prefix/<file>/var/run/bird.ctl</file>.
161 162

	<tag>-P <m/name of PID file/</tag>
163
	create a PID file with given filename.
164 165 166 167 168 169

	<tag>-u <m/user/</tag>
	drop privileges and use that user ID, see the next section for details.

	<tag>-g <m/group/</tag>
	use that group ID, see the next section for details.
170 171 172

	<tag>-f</tag>
	run bird in foreground.
173 174 175

	<tag>-R</tag>
	apply graceful restart recovery after start.
Pavel Machek's avatar
Pavel Machek committed
176
</descrip>
177

178 179
<p>BIRD writes messages about its work to log files or syslog (according to config).

180

181 182
<sect>Privileges

183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202
<p>BIRD, as a routing daemon, uses several privileged operations (like setting
routing table and using raw sockets). Traditionally, BIRD is executed and runs
with root privileges, which may be prone to security problems. The recommended
way is to use a privilege restriction (options <cf/-u/, <cf/-g/). In that case
BIRD is executed with root privileges, but it changes its user and group ID to
an unprivileged ones, while using Linux capabilities to retain just required
privileges (capabilities CAP_NET_*). Note that the control socket is created
before the privileges are dropped, but the config file is read after that. The
privilege restriction is not implemented in BSD port of BIRD.

<p>A nonprivileged user (as an argument to <cf/-u/ options) may be the user
<cf/nobody/, but it is suggested to use a new dedicated user account (like
<cf/bird/). The similar considerations apply for the group option, but there is
one more condition -- the users in the same group can use <file/birdc/ to
control BIRD.

<p>Finally, there is a possibility to use external tools to run BIRD in an
environment with restricted privileges. This may need some configuration, but it
is generally easy -- BIRD needs just the standard library, privileges to read
the config file and create the control socket and the CAP_NET_* capabilities.
203

204

205 206
<chapt>About routing tables

207 208 209 210
<p>BIRD has one or more routing tables which may or may not be synchronized with
OS kernel and which may or may not be synchronized with each other (see the Pipe
protocol). Each routing table contains a list of known routes. Each route
consists of:
211 212

<itemize>
213 214 215
	<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)
216 217
	<item>preference of this route
	<item>IP address of router which told us about this route
218 219
	<item>IP address of router we should forward the packets to using this
		route
220
	<item>other attributes common to all routes
221 222
	<item>dynamic attributes defined by protocols which may or may not be
		present (typically protocol metrics)
223 224
</itemize>

225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254
Routing table maintains multiple entries for a network, but at most one entry
for one network and one protocol. The entry with the highest preference is used
for routing (we will call such an entry the <it/selected route/). If there are
more entries with the same preference and they are from the same protocol, the
protocol decides (typically according to metrics). If they aren't, an internal
ordering is used to break the tie. You can get the list of route attributes in
the Route attributes section.

<p>Each protocol is connected to a routing table through two filters which can
accept, reject and modify the routes. An <it/export/ filter checks routes passed
from the routing table to the protocol, an <it/import/ filter checks routes in
the opposite direction. When the routing table gets a route from a protocol, it
recalculates the selected route and broadcasts it to all protocols connected to
the table. The protocols typically send the update to other routers in the
network. Note that although most protocols are interested in receiving just
selected routes, some protocols (e.g. the <cf/Pipe/ protocol) receive and
process all entries in routing tables (accepted by filters).

<p><label id="dsc-sorted">Usually, a routing table just chooses a selected route
from a list of entries for one network. But if the <cf/sorted/ option is
activated, these lists of entries are kept completely sorted (according to
preference or some protocol-dependent metric). This is needed for some features
of some protocols (e.g. <cf/secondary/ option of BGP protocol, which allows to
accept not just a selected route, but the first route (in the sorted list) that
is accepted by filters), but it is incompatible with some other features (e.g.
<cf/deterministic med/ option of BGP protocol, which activates a way of choosing
selected route that cannot be described using comparison and ordering). Minor
advantage is that routes are shown sorted in <cf/show route/, minor disadvantage
is that it is slightly more computationally expensive.

255

256 257 258 259 260 261 262 263 264 265 266 267 268 269
<sect>Graceful restart

<p>When BIRD is started after restart or crash, it repopulates routing tables in
an uncoordinated manner, like after clean start. This may be impractical in some
cases, because if the forwarding plane (i.e. kernel routing tables) remains
intact, then its synchronization with BIRD would temporarily disrupt packet
forwarding until protocols converge. Graceful restart is a mechanism that could
help with this issue. Generally, it works by starting protocols and letting them
repopulate routing tables while deferring route propagation until protocols
acknowledge their convergence. Note that graceful restart behavior have to be
configured for all relevant protocols and requires protocol-specific support
(currently implemented for Kernel and BGP protocols), it is activated for
particular boot by option <cf/-R/.

270

271
<chapt>Configuration
Pavel Machek's avatar
Pavel Machek committed
272

273
<sect>Introduction
274

275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295
<p>BIRD is configured using a text configuration file. Upon startup, BIRD reads
<it/prefix/<file>/etc/bird.conf</file> (unless the <tt/-c/ command line option
is given). Configuration may be changed at user's request: if you modify the
config file and then signal BIRD with <tt/SIGHUP/, it will adjust to the new
config. Then there's the client which allows you to talk with BIRD in an
extensive way.

<p>In the config, everything on a line after <cf/#/ or inside <cf>/* */</cf> is
a comment, whitespace characters are treated as a single space. If there's a
variable number of options, they are grouped using the <cf/{ }/ brackets. Each
option is terminated by a <cf/;/. Configuration is case sensitive. There are two
ways how to name symbols (like protocol names, filter names, constats etc.). You
can either use a simple string starting with a letter followed by any
combination of letters and numbers (e.g. "R123", "myfilter", "bgp5") or you can
enclose the name into apostrophes (<cf/'/) and than you can use any combination
of numbers, letters. hyphens, dots and colons (e.g. "'1:strange-name'",
"'-NAME-'", "'cool::name'").

<p>Here is an example of a simple config file. It enables synchronization of
routing tables with OS kernel, scans for new network interfaces every 10 seconds
and runs RIP on all network interfaces found.
296

297
<code>
298
protocol kernel {
Pavel Machek's avatar
Pavel Machek committed
299
	persist;		# Don't remove routes on BIRD shutdown
300 301 302 303 304 305 306 307 308 309 310
	scan time 20;		# Scan kernel routing table every 20 seconds
	export all;		# Default is export none
}

protocol device {
	scan time 10;		# Scan interfaces every 10 seconds
}

protocol rip {
	export all;
	import all;
311
	interface "*";
312
}
313
</code>
314

315

316
<sect>Global options
Pavel Machek's avatar
Pavel Machek committed
317

318
<p><descrip>
319
	<tag>include "<m/filename/"</tag> 
320 321 322
	This statement causes inclusion of a new file. <m/Filename/ could also
	be a wildcard. The maximal depth is 5. Note that this statement could be
	used anywhere in the config file, not just as a top-level option.
323

324
	<tag><label id="dsc-log">log "<m/filename/"|syslog [name <m/name/]|stderr all|{ <m/list of classes/ }</tag> 
325 326 327 328
	Set logging of messages having the given class (either <cf/all/ or
	<cf/{ error, trace }/ etc.) into selected destination (a file specified
	as a filename string, syslog with optional name argument, or the stderr
	output). Classes are:
329
	<cf/info/, <cf/warning/, <cf/error/ and <cf/fatal/ for messages about local problems,
330
	<cf/debug/ for debugging messages, 
331 332 333
	<cf/trace/ when you want to know what happens in the network, 
	<cf/remote/ for messages about misbehavior of remote machines, 
	<cf/auth/ about authentication failures,
334 335 336
	<cf/bug/ for internal BIRD bugs.
	You may specify more than one <cf/log/ line to establish logging to
	multiple destinations. Default: log everything to the system log.
337

338
	<tag>debug protocols all|off|{ states, routes, filters, interfaces, events, packets }</tag>
339 340
	Set global defaults of protocol debugging options. See <cf/debug/ in the
	following section. Default: off.
Pavel Machek's avatar
Pavel Machek committed
341 342

	<tag>debug commands <m/number/</tag>
343 344 345
	Control logging of client connections (0 for no logging, 1 for logging
	of connects and disconnects, 2 and higher for logging of all client
	commands). Default: 0.
346

347
	<tag>mrtdump "<m/filename/"</tag>
348 349
	Set MRTdump file name. This option must be specified to allow MRTdump
	feature. Default: no dump file.
350 351

	<tag>mrtdump protocols all|off|{ states, messages }</tag>
352 353
	Set global defaults of MRTdump options. See <cf/mrtdump/ in the
	following section. Default: off.
354

355 356 357
	<tag>filter <m/name local variables/{ <m/commands/ }</tag>
	Define a filter. You can learn more about filters in the following
	chapter.
358

359 360
	<tag>function <m/name/ (<m/parameters/) <m/local variables/ { <m/commands/ }</tag>
	Define a function. You can learn more about functions in the following chapter.
361
 
362
	<tag>protocol rip|ospf|bgp|... [<m/name/ [from <m/name2/]] { <m>protocol options</m> }</tag>
363 364 365 366 367 368 369
	Define a protocol instance called <cf><m/name/</cf> (or with a name like
	"rip5" generated automatically if you don't specify any
	<cf><m/name/</cf>). You can learn more about configuring protocols in
	their own chapters. When <cf>from <m/name2/</cf> expression is used,
	initial protocol options are taken from protocol or template
	<cf><m/name2/</cf> You can run more than one instance of most protocols
	(like RIP or BGP). By default, no instances are configured.
370 371

	<tag>template rip|bgp|... [<m/name/ [from <m/name2/]] { <m>protocol options</m> }</tag>
372 373 374 375 376 377 378
	Define a protocol template instance called <m/name/ (or with a name like
	"bgp1" generated automatically if you don't specify any	<m/name/).
	Protocol templates can be used to group common options when many
	similarly configured protocol instances are to be defined. Protocol
	instances (and other templates) can use templates by using <cf/from/
	expression and the name of the template. At the moment templates (and
	<cf/from/ expression) are not implemented for OSPF protocol.
379

380
	<tag>define <m/constant/ = <m/expression/</tag>
381 382 383 384
	Define a constant. You can use it later in every place you could use a
	value of the same type. Besides, there are some predefined numeric
	constants based on /etc/iproute2/rt_* files. A list of defined constants
	can be seen (together with other symbols) using 'show symbols' command.
385

386
	<tag>router id <m/IPv4 address/</tag>
387 388 389 390
 	Set BIRD's router ID. It's a world-wide unique identification of your
	router, usually one of router's IPv4 addresses. Default: in IPv4
	version, the lowest IP address of a non-loopback interface. In IPv6
	version, this option is mandatory.
391 392

	<tag>router id from [-] [ "<m/mask/" ] [ <m/prefix/ ] [, ...]</tag>
393 394 395
	Set BIRD's router ID based on an IP address of an interface specified by
	an interface pattern. The option is applicable for IPv4 version only.
	See <ref id="dsc-iface" name="interface"> section for detailed
396
	description of interface patterns with extended clauses.
397

398
	<tag>listen bgp [address <m/address/] [port <m/port/] [dual]</tag>
399 400 401 402 403 404 405
	This option allows to specify address and port where BGP protocol should
	listen. It is global option as listening socket is common to all BGP
	instances. Default is to listen on all addresses (0.0.0.0) and port 179.
	In IPv6 mode, option <cf/dual/ can be used to specify that BGP socket
	should accept both IPv4 and IPv6 connections (but even in that case,
	BIRD would accept IPv6 routes only). Such behavior was default in older
	versions of BIRD.
Ondřej Zajíček's avatar
Ondřej Zajíček committed
406

407 408 409 410 411 412
	<tag>graceful restart wait <m/number/</tag>
	During graceful restart recovery, BIRD waits for convergence of routing
	protocols. This option allows to specify a timeout for the recovery to
	prevent waiting indefinitely if some protocols cannot converge. Default:
	240 seconds.

413
	<tag>timeformat route|protocol|base|log "<m/format1/" [<m/limit/ "<m/format2/"]</tag>
414 415 416 417 418 419 420 421 422 423 424 425 426 427 428
	This option allows to specify a format of date/time used by BIRD. The
	first argument specifies for which purpose such format is used.
	<cf/route/ is a format used in 'show route' command output,
	<cf/protocol/ is used in 'show protocols' command output, <cf/base/ is
	used for other commands and <cf/log/ is used in a log file.

	"<m/format1/" is a format string using <it/strftime(3)/ notation (see
	<it/man strftime/ for details). <m/limit> and "<m/format2/" allow to
	specify the second format string for times in past deeper than <m/limit/
 	seconds. There are few shorthands: <cf/iso long/ is a ISO 8601 date/time
	format (YYYY-MM-DD hh:mm:ss) that can be also specified using <cf/"%F %T"/.
	<cf/iso short/ is a variant of ISO 8601 that uses just the time format
	(hh:mm:ss) for near times (up to 20 hours in the past) and the date
	format (YYYY-MM-DD) for far times. This is a shorthand for
	<cf/"%T" 72000 "%F"/.
429

430 431 432 433
	By default, BIRD uses the <cf/iso short/ format for <cf/route/ and
	<cf/protocol/ times, and the <cf/iso long/ format for <cf/base/ and
	<cf/log/ times.

434 435 436 437
	In pre-1.4.0 versions, BIRD used an short, ad-hoc format for <cf/route/
	and <cf/protocol/ times, and a <cf/iso long/ similar format (DD-MM-YYYY
	hh:mm:ss) for <cf/base/ and <cf/log/. These timeformats could be set by
	<cf/old short/ and <cf/old long/ compatibility shorthands.
438

439
	<tag>table <m/name/ [sorted]</tag>
440 441 442 443
	Create a new routing table. The default routing table is created
	implicitly, other routing tables have to be added by this command.
	Option <cf/sorted/ can be used to enable sorting of routes, see
	<ref id="dsc-sorted" name="sorted table"> description for details.
Pavel Machek's avatar
Pavel Machek committed
444

445
	<tag>roa table <m/name/ [ { roa table options ... } ]</tag>
446 447 448 449 450 451 452 453 454 455 456 457
	Create a new ROA (Route Origin Authorization) table. ROA tables can be
	used to validate route origination of BGP routes. A ROA table contains
	ROA entries, each consist of a network prefix, a max prefix length and
	an AS number. A ROA entry specifies prefixes which could be originated
	by that AS number. ROA tables could be filled with data from RPKI (RFC
	6480) or from public databases like Whois. ROA tables are examined by
	<cf/roa_check()/ operator in filters.

	Currently, there is just one option, <cf>roa <m/prefix/ max <m/num/ as
	<m/num/</cf>, which can be used to populate the ROA table with static
	ROA entries. The option may be used multiple times. Other entries can be
	added dynamically by <cf/add roa/ command.
458

Ondřej Zajíček's avatar
Ondřej Zajíček committed
459 460
	<tag>eval <m/expr/</tag>
	Evaluates given filter expression. It is used by us for	testing of filters.
461 462
</descrip>

463

464
<sect>Protocol options
465

466 467 468
<p>For each protocol instance, you can configure a bunch of options. Some of
them (those described in this section) are generic, some are specific to the
protocol (see sections talking about the protocols).
469

470 471 472 473 474
<p>Several options use a <m/switch/ argument. It can be either <cf/on/,
<cf/yes/ or a numeric expression with a non-zero value for the option to be
enabled or <cf/off/, <cf/no/ or a numeric expression evaluating to zero to
disable it. An empty <m/switch/ is equivalent to <cf/on/ ("silence means
agreement").
475

Pavel Machek's avatar
Pavel Machek committed
476
<descrip>
477 478 479
	<tag>preference <m/expr/</tag>
	Sets the preference of routes generated by this protocol. Default:
	protocol dependent.
Pavel Machek's avatar
Pavel Machek committed
480

481 482 483 484
	<tag>disabled <m/switch/</tag>
	Disables the protocol. You can change the disable/enable status from the
	command line interface without needing to touch the configuration.
	Disabled protocols are not activated. Default: protocol is enabled.
Pavel Machek's avatar
Pavel Machek committed
485 486 487 488 489 490

	<tag>debug all|off|{ states, routes, filters, interfaces, events, packets }</tag>
	Set protocol debugging options. If asked, each protocol is capable of
	writing trace messages about its work to the log (with category
	<cf/trace/). You can either request printing of <cf/all/ trace messages
	or only of the types selected: <cf/states/ for protocol state changes
491 492 493 494 495
	(protocol going up, down, starting, stopping etc.), <cf/routes/ for
	routes exchanged with the routing table, <cf/filters/ for details on
	route filtering, <cf/interfaces/ for interface change events sent to the
	protocol, <cf/events/ for events internal to the protocol and <cf/packets/
	for packets sent and received by the protocol. Default: off.
Pavel Machek's avatar
Pavel Machek committed
496

497
	<tag>mrtdump all|off|{ states, messages }</tag>
498 499 500 501 502 503 504 505
	Set protocol MRTdump flags. MRTdump is a standard binary format for
	logging information from routing protocols and daemons. These flags
	control what kind of information is logged from the protocol to the
	MRTdump file (which must be specified by global <cf/mrtdump/ option, see
	the previous section). Although these flags are similar to flags of
	<cf/debug/ option, their meaning is different and protocol-specific. For
	BGP protocol, <cf/states/ logs BGP state changes and <cf/messages/ logs
	received BGP messages. Other protocols does not support MRTdump yet.
506

Ondřej Zajíček's avatar
Ondřej Zajíček committed
507
	<tag>router id <m/IPv4 address/</tag>
508 509
	This option can be used to override global router id for a given
	protocol. Default: uses global router id.
510

Pavel Machek's avatar
Pavel Machek committed
511
	<tag>import all | none | filter <m/name/ | filter { <m/filter commands/ } | where <m/filter expression/</tag> 
512 513 514
	Specify a filter to be used for filtering routes coming from the
	protocol to the routing table. <cf/all/ is shorthand for <cf/where true/
	and <cf/none/ is shorthand for <cf/where false/. Default: <cf/all/.
515

516
	<tag>export <m/filter/</tag>
517 518
	This is similar to the <cf>import</cf> keyword, except that it works in
	the direction from the routing table to the protocol. Default: <cf/none/.
Pavel Machek's avatar
Pavel Machek committed
519

520
	<tag>import keep filtered <m/switch/</tag>
521 522 523 524 525
	Usually, if an import filter rejects a route, the route is forgotten.
	When this option is active, these routes are kept in the routing table,
	but they are hidden and not propagated to other protocols. But it is
	possible to show them using <cf/show route filtered/. Note that this
	option does not work for the pipe protocol. Default: off.
526

527
	<tag><label id="import-limit">import limit [<m/number/ | off ] [action warn | block | restart | disable]</tag>
528 529 530 531 532 533 534
	Specify an import route limit (a maximum number of routes imported from
	the protocol) and optionally the action to be taken when the limit is
	hit. Warn action just prints warning log message. Block action discards
	new routes coming from the protocol. Restart and disable actions shut
	the protocol down like appropriate commands. Disable is the default
	action if an action is not explicitly specified. Note that limits are
	reset during protocol reconfigure, reload or restart. Default: <cf/off/.
535

536
	<tag>receive limit [<m/number/ | off ] [action warn | block | restart | disable]</tag>
537 538 539 540 541 542 543 544
	Specify an receive route limit (a maximum number of routes received from
	the protocol and remembered). It works almost identically to <cf>import
	limit</cf> option, the only difference is that if <cf/import keep
	filtered/ option is active, filtered routes are counted towards the
	limit and blocked routes are forgotten, as the main purpose of the
	receive limit is to protect routing tables from overflow. Import limit,
	on the contrary, counts accepted routes only and routes blocked by the
	limit are handled like filtered routes. Default: <cf/off/.
545

546
	<tag>export limit [ <m/number/ | off ] [action warn | block | restart | disable]</tag>
547 548 549 550 551 552 553 554
	Specify an export route limit, works similarly to the <cf>import
	limit</cf> option, but for the routes exported to the protocol. This
	option is experimental, there are some problems in details of its
	behavior -- the number of exported routes can temporarily exceed the
	limit without triggering it during protocol reload, exported routes
	counter ignores route blocking and block action also blocks route
	updates of already accepted routes -- and these details will probably
	change in the future. Default: <cf/off/.
555

Ondřej Zajíček's avatar
Ondřej Zajíček committed
556
	<tag>description "<m/text/"</tag>
557 558
	This is an optional description of the protocol. It is displayed as a
	part of the output of 'show route all' command.
559

Ondřej Zajíček's avatar
Ondřej Zajíček committed
560 561
	<tag>table <m/name/</tag>
	Connect this protocol to a non-default routing table.
562 563
</descrip>

564
<p>There are several options that give sense only with certain protocols:
565 566

<descrip>
567 568 569
	<tag><label id="dsc-iface">interface [-] [ "<m/mask/" ] [ <m/prefix/ ] [, ...] [ { <m/option/ ; [...] } ]</tag>
	Specifies a set of interfaces on which the protocol is activated with
	given interface-specific options. A set of interfaces specified by one
570 571
	interface option is described using an interface pattern. The interface
	pattern consists of a sequence of clauses (separated by commas), each
572 573
	clause is a mask specified as a shell-like pattern. Interfaces are
	matched by their name.
574 575 576

	An interface matches the pattern if it matches any of its clauses. If
	the clause begins with <cf/-/, matching interfaces are excluded. Patterns
577
	are processed left-to-right, thus <cf/interface "eth0", -"eth*", "*";/
578 579
	means eth0 and all non-ethernets.

580 581 582 583 584 585
	Some protocols (namely OSPFv2 and Direct) support extended clauses that
	may contain a mask, a prefix, or both of them. An interface matches such
	clause if its name matches the mask (if specified) and its address
	matches the prefix (if specified). Extended clauses are used when the
	protocol handles multiple addresses on an interface independently.

586 587 588
	An interface option can be used more times with different interface-specific
	options, in that case for given interface the first matching interface
	option is used.
589
	
590 591
	This option is allowed in BFD, Direct, OSPF, RAdv and RIP protocols, but
	in OSPF protocol it is used in the <cf/area/ subsection.
592 593 594 595 596

	Default: none.

	Examples:

597 598
	<cf>interface "*" { type broadcast; };</cf> - start the protocol on all
	interfaces with <cf>type broadcast</cf> option.
599

600 601
	<cf>interface "eth1", "eth4", "eth5" { type ptp; };</cf> - start the
	protocol on enumerated interfaces with <cf>type ptp</cf> option.
602
	
603 604 605
	<cf>interface -192.168.1.0/24, 192.168.0.0/16;</cf> - start the protocol
	on all interfaces that have address from 192.168.0.0/16, but not from
	192.168.1.0/24.
606

607 608 609
	<cf>interface -192.168.1.0/24, 192.168.0.0/16;</cf> - start the protocol
	on all interfaces that have address from 192.168.0.0/16, but not from
	192.168.1.0/24.
610 611 612 613

	<cf>interface "eth*" 192.168.1.0/24;</cf> - start the protocol on all
	ethernet interfaces that have address from 192.168.1.0/24.

614
	<tag><label id="dsc-prio">tx class|dscp <m/num/</tag>
615 616 617 618 619 620 621
	This option specifies the value of ToS/DS/Class field in IP headers of
	the outgoing protocol packets. This may affect how the protocol packets
	are processed by the network relative to the other network traffic. With
	<cf/class/ keyword, the value (0-255) is used for the whole ToS/Class
	octet (but two bits reserved for ECN are ignored). With	<cf/dscp/
	keyword, the value (0-63) is used just for the DS field in the octet.
	Default value is 0xc0 (DSCP 0x30 - CS6).
622 623

	<tag>tx priority <m/num/</tag>
624 625 626
	This option specifies the local packet priority. This may affect how the
	protocol packets are processed in the local TX queues. This option is
	Linux specific. Default value is 7 (highest priority, privileged traffic).
627

628
	<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>
629 630
	Specifies a password that can be used by the protocol. Password option
	can be used more times to specify more passwords. If more passwords are
631
	specified, it is a protocol-dependent decision which one is really
632 633
	used. Specifying passwords does not mean that authentication is enabled,
	authentication can be enabled by separate, protocol-dependent
634 635 636 637 638 639 640 641 642 643 644 645 646
	<cf/authentication/ option.
	
	This option is allowed in OSPF and RIP protocols. BGP has also
	<cf/password/ option, but it is slightly different and described
	separately.

	Default: none.
</descrip>

<p>Password option can contain section with some (not necessary all) password sub-options:

<descrip>
	<tag>id <M>num</M></tag>
647 648 649 650 651
	ID of the password, (0-255). If it's not used, BIRD will choose ID based
	on an order of the password item in the interface. For example, second
	password item in one interface will have default ID 2. ID is used by
	some routing protocols to identify which password was used to
	authenticate protocol packets.
652 653

	<tag>generate from "<m/time/"</tag>
654 655
	The start time of the usage of the password for packet signing.
	The format of <cf><m/time/</cf> is <tt>dd-mm-yyyy HH:MM:SS</tt>.
656 657

	<tag>generate to "<m/time/"</tag>
658
	The last time of the usage of the password for packet signing.
659 660

	<tag>accept from "<m/time/"</tag>
661
	The start time of the usage of the password for packet verification.
Pavel Machek's avatar
Pavel Machek committed
662

663
	<tag>accept to "<m/time/"</tag>
664
	The last time of the usage of the password for packet verification.
665
</descrip>
666

Pavel Machek's avatar
Pavel Machek committed
667
<chapt>Remote control
668

669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685
<p>You can use the command-line client <file>birdc</file> to talk with a running
BIRD. Communication is done using a <file/bird.ctl/ UNIX domain socket (unless
changed with the <tt/-s/ option given to both the server and the client). The
commands can perform simple actions such as enabling/disabling of protocols,
telling BIRD to show various information, telling it to show routing table
filtered by filter, or asking BIRD to reconfigure. Press <tt/?/ at any time to
get online help. Option <tt/-r/ can be used to enable a restricted mode of BIRD
client, which allows just read-only commands (<cf/show .../). Option <tt/-v/ can
be passed to the client, to make it dump numeric return codes along with the
messages. You do not necessarily need to use <file/birdc/ to talk to BIRD, your
own applications could do that, too -- the format of communication between BIRD
and <file/birdc/ is stable (see the programmer's documentation).

<p>There is also lightweight variant of BIRD client called <file/birdcl/, which
does not support command line editing and history and has minimal dependencies.
This is useful for running BIRD in resource constrained environments, where
Readline library (required for regular BIRD client) is not available.
686 687

<p>Many commands have the <m/name/ of the protocol instance as an argument.
688 689
This argument can be omitted if there exists only a single instance.

Pavel Machek's avatar
Pavel Machek committed
690
<p>Here is a brief list of supported functions:
691 692

<descrip>
Pavel Machek's avatar
Pavel Machek committed
693
	<tag>show status</tag>
694 695
	Show router status, that is BIRD version, uptime and time from last
	reconfiguration.
Pavel Machek's avatar
Pavel Machek committed
696 697

	<tag>show protocols [all]</tag>
698 699 700
	Show list of protocol instances along with tables they are connected to
	and protocol status, possibly giving verbose information, if <cf/all/ is
	specified.
701

702 703 704 705 706 707
	<tag>show ospf interface [<m/name/] ["<m/interface/"]</tag>
	Show detailed information about OSPF interfaces.

	<tag>show ospf neighbors [<m/name/] ["<m/interface/"]</tag>
	Show a list of OSPF neighbors and a state of adjacency to them.

708
	<tag>show ospf state [all] [<m/name/]</tag>
709 710 711 712 713 714
	Show detailed information about OSPF areas based on a content of the
	link-state database. It shows network topology, stub networks,
	aggregated networks and routers from other areas and external routes.
	The command shows information about reachable network nodes, use option
	<cf/all/ to show information about all network nodes in the link-state
	database.
715 716

	<tag>show ospf topology [all] [<m/name/]</tag>
717 718
	Show a topology of OSPF areas based on a content of the link-state
	database. It is just a stripped-down version of 'show ospf state'.
719

720
	<tag>show ospf lsadb [global | area <m/id/ | link] [type <m/num/] [lsid <m/id/] [self | router <m/id/] [<m/name/] </tag>
721 722
	Show contents of an OSPF LSA database. Options could be used to filter
	entries.
723

Pavel Machek's avatar
Pavel Machek committed
724
	<tag>show static [<m/name/]</tag>
725 726
	Show detailed information about static routes.

727 728 729
	<tag>show bfd sessions [<m/name/]</tag>
	Show information about BFD sessions.

Pavel Machek's avatar
Pavel Machek committed
730
	<tag>show interfaces [summary]</tag>
731 732
	Show the list of interfaces. For each interface, print its type, state,
	MTU and addresses assigned.
Pavel Machek's avatar
Pavel Machek committed
733

734
	<tag>show symbols [table|filter|function|protocol|template|roa|<m/symbol/]</tag>
735 736
	Show the list of symbols defined in the configuration (names of
	protocols, routing tables etc.).
Pavel Machek's avatar
Pavel Machek committed
737

738
	<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>
739 740 741
	Show contents of a routing table (by default of the main one or the
	table attached to a respective protocol), that is routes, their metrics
	and (in case the <cf/all/ switch is given) all their attributes.
Pavel Machek's avatar
Pavel Machek committed
742 743 744 745 746 747 748 749 750 751 752

	<p>You can specify a <m/prefix/ if you want to print routes for a
	specific network. If you use <cf>for <m/prefix or IP/</cf>, you'll get
	the entry which will be used for forwarding of packets to the given
	destination. By default, all routes for each network are printed with
	the selected one at the top, unless <cf/primary/ is given in which case
	only the selected route is shown.

	<p>You can also ask for printing only routes processed and accepted by
	a given filter (<cf>filter <m/name/</cf> or <cf>filter { <m/filter/ }
	</cf> or matching a given condition (<cf>where <m/condition/</cf>).
753 754 755
	The <cf/export/ and <cf/preexport/ switches ask for printing of entries
	that are exported to the specified protocol. With <cf/preexport/, the
	export filter of the protocol is skipped.
Pavel Machek's avatar
Pavel Machek committed
756

757 758 759
	<p>You can also select just routes added by a specific protocol.
	<cf>protocol <m/p/</cf>.

760 761 762
	<p>If BIRD is configured to keep filtered routes (see <cf/import keep
	filtered/ option), you can show them instead of routes by using
	<cf/filtered/ switch.
763

Pavel Machek's avatar
Pavel Machek committed
764 765 766 767
	<p>The <cf/stats/ switch requests showing of route statistics (the
	number of networks, number of routes before and after filtering). If
	you use <cf/count/ instead, only the statistics will be printed.

768
	<tag>show roa [<m/prefix/ | in <m/prefix/ | for <m/prefix/] [as <m/num/] [table <m/t/>]</tag>
769 770 771 772 773 774
	Show contents of a ROA table (by default of the first one). You can
	specify a <m/prefix/ to print ROA entries for a specific network. If you
	use <cf>for <m/prefix/</cf>, you'll get all entries relevant for route
	validation of the network prefix; i.e., ROA entries whose prefixes cover
	the network prefix. Or you can use <cf>in <m/prefix/</cf> to get ROA
	entries covered by the network prefix. You could also use <cf/as/ option
775 776 777
	to show just entries for given AS.

	<tag>add roa <m/prefix/ max <m/num/] as <m/num/ [table <m/t/>]</tag>
778 779 780
	Add a new ROA entry to a ROA table. Such entry is called <it/dynamic/
	compared to <it/static/ entries specified in the config file. These
	dynamic entries survive reconfiguration.
781 782

	<tag>delete roa <m/prefix/ max <m/num/] as <m/num/ [table <m/t/>]</tag>
783 784
	Delete the specified ROA entry from a ROA table. Only dynamic ROA
	entries (i.e., the ones added by <cf/add roa/ command) can be deleted.
785 786 787 788

	<tag>flush roa [table <m/t/>]</tag>
	Remove all dynamic ROA entries from a ROA table.

789
	<tag>configure [soft] ["<m/config file/"] [timeout [<m/num/]]</tag>
790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806
	Reload configuration from a given file. BIRD will smoothly switch itself
	to the new configuration, protocols are reconfigured if possible,
	restarted otherwise. Changes in filters usually lead to restart of
	affected protocols.

	If <cf/soft/ option is used, changes in filters does not cause BIRD to
	restart affected protocols, therefore already accepted routes (according
	to old filters) would be still propagated, but new routes would be
	processed according to the new filters.

	If <cf/timeout/ option is used, config timer is activated. The new
	configuration could be either confirmed using <cf/configure confirm/
	command, or it will be reverted to the old one when the config timer
	expires. This is useful for cases when reconfiguration breaks current
	routing and a router becames inaccessible for an administrator. The
	config timeout expiration is equivalent to <cf/configure undo/
	command. The timeout duration could be specified, default is 300 s.
807 808 809 810 811 812

	<tag>configure confirm</tag>
	Deactivate the config undo timer and therefore confirm the current
	configuration.

	<tag>configure undo</tag>
813 814 815 816 817 818
	Undo the last configuration change and smoothly switch back to the
	previous (stored) configuration. If the last configuration change was
	soft, the undo change is also soft. There is only one level of undo, but
	in some specific cases when several reconfiguration requests are given
	immediately in a row and the intermediate ones are skipped then the undo
	also skips them back.
819 820

	<tag>configure check ["<m/config file/"]</tag>
821 822
	Read and parse given config file, but do not use it. useful for checking
	syntactic and some semantic validity of an config file.
823

824
	<tag>enable|disable|restart <m/name/|"<m/pattern/"|all</tag>
825 826
	Enable, disable or restart a given protocol instance, instances matching
	the <cf><m/pattern/</cf> or <cf/all/ instances.
827

828
	<tag>reload [in|out] <m/name/|"<m/pattern/"|all</tag>
829 830 831 832 833 834 835 836 837 838 839 840 841 842 843
	Reload a given protocol instance, that means re-import routes from the
	protocol instance and re-export preferred routes to the instance. If
	<cf/in/ or <cf/out/ options are used, the command is restricted to one
	direction (re-import or re-export).

	This command is useful if appropriate filters have changed but the
	protocol instance was not restarted (or reloaded), therefore it still
	propagates the old set of routes. For example when <cf/configure soft/
	command was used to change filters.

	Re-export always succeeds, but re-import is protocol-dependent and might
	fail (for example, if BGP neighbor does not support route-refresh
	extension). In that case, re-export is also skipped. Note that for the
	pipe protocol, both directions are always reloaded together (<cf/in/ or
	<cf/out/ options are ignored in that case).
844

Pavel Machek's avatar
Pavel Machek committed
845 846
	<tag/down/
	Shut BIRD down.
847

Pavel Machek's avatar
Pavel Machek committed
848
	<tag>debug <m/protocol/|<m/pattern/|all all|off|{ states | routes | filters | events | packets }</tag>
849
	Control protocol debugging.
850 851 852 853 854 855 856 857 858 859

	<tag>dump resources|sockets|interfaces|neighbors|attributes|routes|protocols</tag>
	Dump contents of internal data structures to the debugging output.

	<tag>echo all|off|{ <m/list of log classes/ } [ <m/buffer-size/ ]</tag>
	Control echoing of log messages to the command-line output.
	See <ref id="dsc-log" name="log option"> for a list of log classes.

	<tag>eval <m/expr/</tag>
	Evaluate given expression.
860
</descrip>
861

862

863
<chapt>Filters
864

865
<sect>Introduction
866

867 868 869 870 871 872
<p>BIRD contains a simple programming language. (No, it can't yet read mail :-).
There are two objects in this language: filters and functions. Filters are
interpreted by BIRD core when a route is being passed between protocols and
routing tables. The filter language contains control structures such 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>.
873

874 875 876 877
<p>Filter gets the route, looks at its attributes and modifies some of them if
it wishes. At the end, it decides whether to pass the changed route through
(using <cf/accept/) or whether to <cf/reject/ it. A simple filter looks like
this:
878

879
<code>
880 881 882 883 884 885 886 887 888 889 890 891 892 893
filter not_too_far
int var;
{
	if defined( rip_metric ) then
		var = rip_metric;
	else {
		var = 1;
		rip_metric = 1;
	}
	if rip_metric &gt; 10 then
		reject "RIP metric is too big";
	else
		accept "ok";
}
894
</code>
895

896 897 898 899 900 901 902 903
<p>As you can see, a filter has a header, a list of local variables, and a body.
The header consists of the <cf/filter/ keyword followed by a (unique) name of
filter. The list of local variables consists of <cf><M>type name</M>;</cf>
pairs where each pair defines one local variable. The body consists of <cf>
{ <M>statements</M> }</cf>. Each <m/statement/ is terminated by a <cf/;/. You
can group several statements to a single compound statement by using braces
(<cf>{ <M>statements</M> }</cf>) which is useful if you want to make a bigger
block of code conditional.
904

905 906 907
<p>BIRD supports functions, so that you don't have to repeat the same blocks of
code over and over. Functions can have zero or more parameters and they can have
local variables. Recursion is not allowed. Function definitions look like this:
908 909 910 911 912 913 914 915 916 917 918 919 920 921

<code>
function name ()
int local_variable;
{
	local_variable = 5;
}

function with_parameters (int parameter)
{
	print parameter;
}
</code>

922 923 924 925 926
<p>Unlike in C, variables are declared after the <cf/function/ line, but before
the first <cf/{/. You can't declare variables in nested blocks. Functions are
called like in C: <cf>name(); with_parameters(5);</cf>. Function may return
values using the <cf>return <m/[expr]/</cf> command. Returning a value exits
from current function (this is similar to C).
927

928 929 930 931 932
<p>Filters are declared in a way similar to functions except they can't have
explicit parameters. They get a route table entry as an implicit parameter, it
is also passed automatically to any functions called. The filter must terminate
with either <cf/accept/ or <cf/reject/ statement. If there's a runtime error in
filter, the route is rejected.
933

934 935
<p>A nice trick to debug filters is to use <cf>show route filter <m/name/</cf>
from the command line client. An example session might look like:
Pavel Machek's avatar
Pavel Machek committed
936 937 938 939 940 941 942 943 944

<code>
pavel@bug:~/bird$ ./birdc -s bird.ctl
BIRD 0.0.0 ready.
bird> show route
10.0.0.0/8         dev eth0 [direct1 23:21] (240)
195.113.30.2/32    dev tunl1 [direct1 23:21] (240)
127.0.0.0/8        dev lo [direct1 23:21] (240)
bird> show route ?
945
show route [<prefix>] [table <t>] [filter <f>] [all] [primary]...
Martin Mareš's avatar
Martin Mareš committed
946
bird> show route filter { if 127.0.0.5 &tilde; net then accept; }
Pavel Machek's avatar
Pavel Machek committed
947 948 949 950
127.0.0.0/8        dev lo [direct1 23:21] (240)
bird>
</code>

951

952
<sect>Data types
953

954 955 956
<p>Each variable and each value has certain type. Booleans, integers and enums
are incompatible with each other (that is to prevent you from shooting in the
foot).
957 958

<descrip>
959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016
	<tag/bool/
	This is a boolean type, it can have only two values, <cf/true/ and
	<cf/false/. Boolean is the only type you can use in <cf/if/ statements.

	<tag/int/
	This is a general integer type. It is an unsigned 32bit type; i.e., you
	can expect it to store values from 0 to 4294967295. Overflows are not
	checked. You can use <cf/0x1234/ syntax to write hexadecimal values.

	<tag/pair/
	This is a pair of two short integers. Each component can have values
	from 0 to 65535. Literals of this type are written as <cf/(1234,5678)/.
	The same syntax can also be used to construct a pair from two arbitrary
	integer expressions (for example <cf/(1+2,a)/).

	<tag/quad/
	This is a dotted quad of numbers used to represent router IDs (and
	others). Each component can have a value from 0 to 255. Literals of
	this type are written like IPv4 addresses.

	<tag/string/
	This is a string of characters. There are no ways to modify strings in
	filters. You can pass them between functions, assign them to variables
	of type <cf/string/, print such variables, use standard string
	comparison operations (e.g. <cf/=, !=, &lt;, &gt;, &lt;=, &gt;=/), but
	you can't concatenate two strings. String literals are written as
	<cf/"This is a string constant"/. Additionaly matching <cf/&tilde;/
	operator could be used to match a string value against a shell pattern
	(represented also as a string).

	<tag/ip/
	This type can hold a single IP address. Depending on the compile-time
	configuration of BIRD you are using, it 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> on values of type ip. It masks out all but
	first <cf><M>num</M></cf> bits from the IP address. So
	<cf/1.2.3.4.mask(8) = 1.0.0.0/ is true.

	<tag/prefix/
	This type can hold a network prefix consisting of IP address and prefix
	length. Prefix literals are written as <cf><m/ipaddress//<m/pxlen/</cf>,
	or <cf><m>ipaddress</m>/<m>netmask</m></cf>. There are two special
	operators on prefixes: <cf/.ip/ which extracts the IP address from the
	pair, and <cf/.len/, which separates prefix length from the pair.
	So <cf>1.2.0.0/16.pxlen = 16</cf> is true.

	<tag/ec/

	This is a specialized type used to represent BGP extended community
	values. It is essentially a 64bit value, literals of this type are
	usually written as <cf>(<m/kind/, <m/key/, <m/value/)</cf>, where
	<cf/kind/ is a kind of extended community (e.g. <cf/rt/ / <cf/ro/ for a
	route target / route origin communities), the format and possible values
	of <cf/key/ and <cf/value/ are usually integers, but it depends on the
	used kind. Similarly to pairs, ECs can be constructed using expressions
	for <cf/key/ and <cf/value/ parts, (e.g. <cf/(ro, myas, 3*10)/, where
	<cf/myas/ is an integer variable).
1017
 
1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040
	<tag/int|pair|quad|ip|prefix|ec|enum set/
	Filters recognize four types of sets. Sets are similar to strings: you
	can pass them around but you can't modify them. Literals of type <cf>int
	set</cf> look like <cf> [ 1, 2, 5..7 ]</cf>. As you can see, both simple
	values and ranges are permitted in sets.

	For pair sets, expressions like <cf/(123,*)/ can be used to denote
	ranges (in that case <cf/(123,0)..(123,65535)/). You can also use
	<cf/(123,5..100)/ for range <cf/(123,5)..(123,100)/. You can also use
	<cf/*/ and <cf/a..b/ expressions in the first part of a pair, note that
	such expressions are translated to a set of intervals, which may be
	memory intensive. E.g. <cf/(*,4..20)/ is translated to <cf/(0,4..20),
	(1,4..20), (2,4..20), ... (65535, 4..20)/.

	EC sets use similar expressions like pair sets, e.g. <cf/(rt, 123,
	10..20)/ or <cf/(ro, 123, *)/. Expressions requiring the translation
	(like <cf/(rt, *, 3)/) are not allowed (as they usually have 4B range
	for ASNs).

	You can also use expressions for int, pair and EC set values. However it
	must be possible to evaluate these expressions before daemon boots. So
	you can use only constants inside them. E.g.

1041 1042
	<code>
	 define one=1;
1043
	 define myas=64500;
1044 1045
	 int set odds;
	 pair set ps;
1046
	 ec set es;
1047

1048
	 odds = [ one, 2+1, 6-one, 2*2*2-1, 9, 11 ];
1049
	 ps = [ (1,one+one), (3,4)..(4,8), (5,*), (6,3..6), (7..9,*) ];
1050
	 es = [ (rt, myas, 3*10), (rt, myas+one, 0..16*16*16-1), (ro, myas+2, *) ];
1051
	</code>
1052

1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086
	Sets of prefixes are special: their literals does not allow ranges, but
	allows prefix patterns that are written
	as <cf><M>ipaddress</M>/<M>pxlen</M>{<M>low</M>,<M>high</M>}</cf>.
	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 the
	first <cf>min(len1, len2)</cf> bits of <cf/ip1/ and <cf/ip2/ are
	identical and <cf>len1 &lt;= ip1 &lt;= len2</cf>. A valid prefix pattern
	has to satisfy <cf>low &lt;= high</cf>, but <cf/pxlen/ is not
	constrained by <cf/low/ or <cf/high/. Obviously, a prefix matches a
	prefix set literal if it matches any prefix pattern in the prefix set
	literal.

	There are also two shorthands for prefix patterns: <cf><m/address//<m/len/+</cf>
	is a shorthand for <cf><m/address//<m/len/{<m/len/,<m/maxlen/}</cf>
	(where <cf><m/maxlen/</cf> is 32 for IPv4 and 128 for IPv6), that means
	network prefix <cf><m/address//<m/len/</cf> and all its	subnets.
	<cf><m/address//<m/len/-</cf> is a shorthand for
	<cf><m/address//<m/len/{0,<m/len/}</cf>, that means network prefix
	<cf><m/address//<m/len/</cf> and all its supernets (network prefixes
	that contain it).

	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 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
	<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 IP address) whose prefix length is
	20 to 24, <cf>[ 1.2.3.4/32- ]</cf> matches any prefix that contains IP
	address <cf>1.2.3.4</cf>. <cf>1.2.0.0/16 &tilde; [ 1.0.0.0/8{15,17} ]</cf>
	is true, but <cf>1.0.0.0/16 &tilde; [ 1.0.0.0/8- ]</cf> is false.

	Cisco-style patterns like <cf>10.0.0.0/8 ge 16 le 24</cf> can be expressed
	in BIRD as <cf>10.0.0.0/8{16,24}</cf>, <cf>192.168.0.0/16 le 24</cf> as 
	<cf>192.168.0.0/16{16,24}</cf> and <cf>192.168.0.0/16 ge 24</cf> as
	<cf>192.168.0.0/16{24,32}</cf>.
1087 1088

	<tag/enum/
1089 1090 1091
	Enumeration types are fixed sets of possibilities. You can't define your
	own variables of such type, but some route attributes are of enumeration
	type. Enumeration types are incompatible with each other.
1092 1093

	<tag/bgppath/
1094 1095
	BGP path is a list of autonomous system numbers. You can't write
	literals of this type. There are several special operators on bgppaths:
1096

1097
	<cf><m/P/.first</cf> returns the first ASN (the neighbor ASN) in path <m/P/.
1098

1099
	<cf><m/P/.last</cf> returns the last ASN (the source ASN) in path <m/P/.
1100

1101 1102 1103
	Both <cf/first/ and <cf/last/ return zero if there is no appropriate
	ASN, for example if the path contains an AS set element as the first (or
	the last) part.
1104

1105
	<cf><m/P/.len</cf> returns the length of path <m/P/.
1106

1107 1108
	<cf>prepend(<m/P/,<m/A/)</cf> prepends ASN <m/A/ to path <m/P/ and
	returns the result.
1109

1110 1111 1112 1113
	<cf>delete(<m/P/,<m/A/)</cf> deletes all instances of ASN <m/A/ from
	from path <m/P/ and returns the result. <m/A/ may also be an integer
	set, in that case the operator deletes all ASNs from path <m/P/ that are
	also members of set <m/A/.
1114

1115 1116 1117
	<cf>filter(<m/P/,<m/A/)</cf> deletes all ASNs from path <m/P/ that are
	not members of integer set <m/A/. I.e., <cf/filter/ do the same as
	<cf/delete/ with inverted set <m/A/.
1118

1119 1120 1121
	Statement <cf><m/P/ = prepend(<m/P/, <m/A/);</cf> can be shortened to
	<cf><m/P/.prepend(<m/A/);</cf> if <m/P/ is appropriate route attribute
	(for example <cf/bgp_path/). Similarly for <cf/delete/ and <cf/filter/.
1122

Pavel Machek's avatar
Pavel Machek committed
1123
	<tag/bgpmask/
1124 1125 1126 1127 1128 1129 1130 1131 1132 1133
	BGP masks are patterns used for BGP path matching (using <cf>path
	&tilde; [= 2 3 5 * =]</cf> syntax). The masks resemble wildcard patterns
	as used by UNIX shells. Autonomous system numbers match themselves,
	<cf/*/ matches any (even empty) sequence of arbitrary AS numbers and
	<cf/?/ matches one arbitrary AS number. For example, if <cf>bgp_path</cf> 
 	is 4 3 2 1, then: <tt>bgp_path &tilde; [= * 4 3 * =]</tt> is true,
	but <tt>bgp_path &tilde; [= * 4 5 * =]</tt> is false. BGP mask
	expressions can also contain integer expressions enclosed in parenthesis
	and integer variables, for example <tt>[= * 4 (1+2) a =]</tt>. There is
	also old syntax that uses / .. / instead of [= .. =] and ? instead of *.
1134

1135
	<tag/clist/
1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162
	Clist is similar to a set, except that unlike other sets, it can be
	modified. The type is used for community list (a set of pairs) and for
	cluster list (a set of quads). There exist no literals of this type.
	There are three special operators on clists:

	<cf><m/C/.len</cf> returns the length of clist <m/C/.

	<cf>add(<m/C/,<m/P/)</cf> adds pair (or quad) <m/P/ to clist <m/C/ and
	returns the result. If item <m/P/ is already in clist <m/C/, it does
	nothing. <m/P/ may also be a clist, in that case all its members are
	added; i.e., it works as clist union.

	<cf>delete(<m/C/,<m/P/)</cf> deletes pair (or quad) <m/P/ from clist
	<m/C/ and returns the result. If clist <m/C/ does not contain item
	<m/P/, it does nothing. <m/P/ may also be a pair (or quad) set, in that
	case the operator deletes all items from clist <m/C/ that are also
	members of set <m/P/. Moreover, <m/P/ may also be a clist, which works
	analogously; i.e., it works as clist difference.

	<cf>filter(<m/C/,<m/P/)</cf> deletes all items from clist <m/C/ that are
	not members of pair (or quad) set <m/P/. I.e., <cf/filter/ do the same
	as <cf/delete/ with inverted set <m/P/. <m/P/ may also be a clist, which
	works analogously; i.e., it works as clist intersection.

	Statement <cf><m/C/ = add(<m/C/, <m/P/);</cf> can be shortened to
	<cf><m/C/.add(<m/P/);</cf> if <m/C/ is appropriate route attribute (for
	example <cf/bgp_community/). Similarly for <cf/delete/ and <cf/filter/.
1163 1164

	<tag/eclist/
1165 1166 1167 1168 1169
	Eclist is a data type used for BGP extended community lists. Eclists
	are very similar to clists, but they are sets of ECs instead of pairs.
	The same operations (like <cf/add/, <cf/delete/, or <cf/&tilde;/
	membership operator) can be used to modify or test eclists, with ECs
	instead of pairs as arguments.
1170 1171
</descrip>

1172

1173
<sect>Operators
1174

1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197
<p>The filter language supports common integer operators <cf>(+,-,*,/)</cf>,
parentheses <cf/(a*(b+c))/, comparison <cf/(a=b, a!=b, a&lt;b, a&gt;=b)/.
Logical operations include unary not (<cf/!/), and (<cf/&amp;&amp;/) and or
(<cf/&verbar;&verbar;/). Special operators include <cf/&tilde;/ for "is element
of a set" operation - it can be used on element and set of elements of the same
type (returning true if element is contained in the given set), or 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 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 bgppath and int (number) set (returning true if any
ASN from the path is in the set) 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).

<p>There is one operator related to ROA infrastructure - <cf/roa_check()/. It
examines a ROA table and does RFC 6483 route origin validation for a given
network prefix. The basic usage is <cf>roa_check(<m/table/)</cf>, which checks
current route (which should be from BGP to have AS_PATH argument) in the
specified ROA table and returns ROA_UNKNOWN if there is no relevant ROA,
ROA_VALID if there is a matching ROA, or ROA_INVALID if there are some relevant
1198
ROAs but none of them match. There is also an extended variant
1199 1200
<cf>roa_check(<m/table/, <m/prefix/, <m/asn/)</cf>, which allows to specify a
prefix and an ASN as arguments.
1201

1202

1203
<sect>Control structures
1204

1205 1206
<p>Filters support two control structures: conditions and case switches. 

1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220
<p>Syntax of a condition is: <cf>if <M>boolean expression</M> then <m/command1/;
else <m/command2/;</cf> and you can use <cf>{ <m/command_1/; <m/command_2/;
<M>...</M> }</cf> instead of either command. The <cf>else</cf> clause may be
omitted. If the <cf><m>boolean expression</m></cf> is true, <m/command1/ is
executed, otherwise <m/command2/ is executed.

<p>The <cf>case</cf> is similar to case from Pascal. Syntax is <cf>case
<m/expr/ { else: | <m/num_or_prefix [ .. num_or_prefix]/: <m/statement/ ; [
... ] }</cf>. The expression after <cf>case</cf> can be of any type which can be
on the left side of the &tilde; operator and anything that could be a member of
a set is allowed before <cf/:/. Multiple commands are allowed without <cf/{}/
grouping. 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.
1221

1222
<p>Here is example that uses <cf/if/ and <cf/case/ structures:
Pavel Machek's avatar
Pavel Machek committed
1223 1224 1225 1226 1227 1228

<code>
case arg1 {
	2: print "two"; print "I can do more commands without {}";
	3 .. 5: print "three to five";
	else: print "something else";
1229
}
Pavel Machek's avatar
Pavel Machek committed
1230

Pavel Machek's avatar
Pavel Machek committed
1231 1232 1233 1234
if 1234 = i then printn "."; else { 
  print "not 1234"; 
  print "You need {} around multiple commands"; 
}
Pavel Machek's avatar
Pavel Machek committed
1235 1236
</code>

1237

1238
<sect>Route attributes
1239

1240 1241 1242 1243 1244 1245
<p>A filter is implicitly passed a route, and it can access its attributes just
like it accesses variables. Attempts to access undefined attribute result in a
runtime error; you can check if an attribute is defined by using the
<cf>defined( <m>attribute</m> )</cf> operator. One notable exception to this
rule are attributes of clist type, where undefined value is regarded as empty
clist for most purposes.
1246

1247
<descrip>
Martin Mareš's avatar
Martin Mareš committed
1248
	<tag><m/prefix/ net</tag>
1249 1250
	Network the route is talking about. Read-only. (See the chapter about
	routing tables.)
1251 1252

	<tag><m/enum/ scope</tag>
1253 1254 1255 1256 1257 1258
	The scope of the route. Possible values: <cf/SCOPE_HOST/ for routes
	local to this host, <cf/SCOPE_LINK/ for those specific for a physical
	link, <cf/SCOPE_SITE/ and <cf/SCOPE_ORGANIZATION/ for private routes and
	<cf/SCOPE_UNIVERSE/ for globally visible routes. This attribute is not
	interpreted by BIRD and can be used to mark routes in filters. The
	default value for new routes is <cf/SCOPE_UNIVERSE/.
1259

Martin Mareš's avatar
Martin Mareš committed
1260
	<tag><m/int/ preference</tag>
1261 1262
	Preference of the route. Valid values are 0-65535. (See the chapter
	about routing tables.)
Pavel Machek's avatar
Pavel Machek committed
1263

Martin Mareš's avatar
Martin Mareš committed
1264
	<tag><m/ip/ from</tag>
1265
	The router which the route has originated from.
1266
	
Martin Mareš's avatar
Martin Mareš committed
1267
	<tag><m/ip/ gw</tag>
1268
	Next hop packets routed using this route should be forwarded to.
1269

1270
	<tag><m/string/ proto</tag>
1271 1272
	The name of the protocol which the route has been imported from.
	Read-only.
1273

Martin Mareš's avatar
Martin Mareš committed
1274
	<tag><m/enum/ source</tag>
1275 1276 1277 1278 1279
	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/.
Pavel Machek's avatar
Pavel Machek committed
1280

Martin Mareš's avatar
Martin Mareš committed
1281
	<tag><m/enum/ cast</tag>
1282
	Route type (Currently <cf/RTC_UNICAST/ for normal routes,
1283 1284
	<cf/RTC_BROADCAST/, <cf/RTC_MULTICAST/, <cf/RTC_ANYCAST/ will be used in
	the future for broadcast, multicast and anycast routes). Read-only.
Pavel Machek's avatar
Pavel Machek committed
1285

Martin Mareš's avatar
Martin Mareš committed
1286
	<tag><m/enum/ dest</tag>
1287 1288 1289 1290 1291
	Type of destination the packets should be sent to
	(<cf/RTD_ROUTER/ for forwarding to a neighboring router,
	<cf/RTD_DEVICE/ for routing to a directly-connected network,
	<cf/RTD_MULTIPATH/ for multipath destinations,
	<cf/RTD_BLACKHOLE/ for packets to be silently discarded,
1292 1293 1294 1295
	<cf/RTD_UNREACHABLE/, <cf/RTD_PROHIBIT/ for packets that should be
	returned with ICMP host unreachable / ICMP administratively prohibited
	messages). Can be changed, but only to <cf/RTD_BLACKHOLE/,
	<cf/RTD_UNREACHABLE/ or <cf/RTD_PROHIBIT/.
1296

1297
	<tag><m/string/ ifname</tag>
1298 1299 1300
	Name of the outgoing interface. Sink routes (like blackhole, unreachable
	or prohibit) and multipath routes have no interface associated with
	them, so <cf/ifname/ returns an empty string for such routes. Read-only.
1301 1302

	<tag><m/int/ ifindex</tag>
1303 1304 1305
	Index of the outgoing interface. System wide index of the interface. May
	be used for interface matching, however indexes might change on interface
	creation/removal. Zero is returned for routes with undefined outgoing
1306 1307
	interfaces. Read-only.

1308
	<tag><m/int/ igp_metric</tag>
1309 1310 1311 1312 1313 1314
	The optional attribute that can be used to specify a distance to the
	network for routes that do not have a native protocol metric attribute
	(like <cf/ospf_metric1/ for OSPF routes). It is used mainly by BGP to
	compare internal distances to boundary routers (see below). It is also
	used when the route is exported to OSPF as a default value for OSPF type
	1 metric.
Pavel Machek's avatar
Pavel Machek committed
1315
</descrip>
1316

1317 1318 1319
<p>There also exist some protocol-specific attributes which are described in the
corresponding protocol sections.

1320

1321
<sect>Other statements
1322

1323
<p>The following statements are available:
1324 1325

<descrip>
1326 1327
	<tag><m/variable/ = <m/expr/</tag>
	Set variable to a given value.
1328

1329 1330
	<tag>accept|reject [ <m/expr/ ]</tag>
	Accept or reject the route, possibly printing <cf><m>expr</m></cf>.
1331

1332 1333 1334
	<tag>return <m/expr/</tag>
	Return <cf><m>expr</m></cf> from the current function, the function ends
	at this point.
1335

1336
	<tag>print|printn <m/expr/ [<m/, expr.../]</tag>
1337 1338
	Prints given expressions; useful mainly while debugging filters. The
	<cf/printn/ variant does not terminate the line.
1339 1340

	<tag>quitbird</tag>
1341
	Terminates BIRD. Useful when debugging the filter interpreter.
1342 1343
</descrip>

1344

1345
<chapt>Protocols
1346

1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422
<sect><label id="sect-bfd">BFD

<sect1>Introduction

<p>Bidirectional Forwarding Detection (BFD) is not a routing protocol itself, it
is an independent tool providing liveness and failure detection. Routing
protocols like OSPF and BGP use integrated periodic "hello" messages to monitor
liveness of neighbors, but detection times of these mechanisms are high (e.g. 40
seconds by default in OSPF, could be set down to several seconds). BFD offers
universal, fast and low-overhead mechanism for failure detection, which could be
attached to any routing protocol in an advisory role.

<p>BFD consists of mostly independent BFD sessions. Each session monitors an
unicast bidirectional path between two BFD-enabled routers. This is done by
periodically sending control packets in both directions. BFD does not handle
neighbor discovery, BFD sessions are created on demand by request of other
protocols (like OSPF or BGP), which supply appropriate information like IP
addresses and associated interfaces. When a session changes its state, these
protocols are notified and act accordingly (e.g. break an OSPF adjacency when
the BFD session went down).

<p>BIRD implements basic BFD behavior as defined in
RFC 5880<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5880.txt">
(some advanced features like the echo mode or authentication are not implemented),
IP transport for BFD as defined in
RFC 5881<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5881.txt"> and
RFC 5883<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5883.txt">
and interaction with client protocols as defined in
RFC 5882<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5882.txt">.

<p>Note that BFD implementation in BIRD is currently a new feature in
development, expect some rough edges and possible UI and configuration changes
in the future. Also note that we currently support at most one protocol instance.

<sect1>Configuration

<p>BFD configuration consists mainly of multiple definitions of interfaces.
Most BFD config options are session specific. When a new session is requested
and dynamically created, it is configured from one of these definitions. For
sessions to directly connected neighbors, <cf/interface/ definitions are chosen
based on the interface associated with the session, while <cf/multihop/
definition is used for multihop sessions. If no definition is relevant, the
session is just created with the default configuration. Therefore, an empty BFD
configuration is often sufficient.

<p>Note that to use BFD for other protocols like OSPF or BGP, these protocols
also have to be configured to request BFD sessions, usually by <cf/bfd/ option.

<p>Some of BFD session options require <m/time/ value, which has to be specified
with the appropriate unit: <m/num/ <cf/s/|<cf/ms/|<cf/us/. Although microseconds
are allowed as units, practical minimum values are usually in order of tens of
milliseconds.

<code>
protocol bfd [&lt;name&gt;] {
	interface &lt;interface pattern&gt; {
		interval &lt;time&gt;;
		min rx interval &lt;time&gt;;
		min tx interval &lt;time&gt;;
		idle tx interval &lt;time&gt;;
		multiplier &lt;num&gt;;
		passive &lt;switch&gt;;
	};
	multihop {
		interval &lt;time&gt;;
		min rx interval &lt;time&gt;;
		min tx interval &lt;time&gt;;
		idle tx interval &lt;time&gt;;
		multiplier &lt;num&gt;;
		passive &lt;switch&gt;;
	};
	neighbor &lt;ip&gt; [dev "&lt;interface&gt;"] [local &lt;ip&gt;] [multihop &lt;switch&gt;];
}
</code>

<descrip>
1423
	<tag>interface <m/pattern [, ...]/ { <m/options/ }</tag>
1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443
	Interface definitions allow to specify options for sessions associated
	with such interfaces and also may contain interface specific options.
	See <ref id="dsc-iface" name="interface"> common option for a detailed
	description of interface patterns. Note that contrary to the behavior of
	<cf/interface/ definitions of other protocols, BFD protocol would accept
	sessions (in default configuration) even on interfaces not covered by
	such definitions.

	<tag>multihop { <m/options/ }</tag>
	Multihop definitions allow to specify options for multihop BFD sessions,
	in the same manner as <cf/interface/ definitions are used for directly
	connected sessions. Currently only one such definition (for all multihop
	sessions) could be used.

	<tag>neighbor <m/ip/ [dev "<m/interface/"] [local <m/ip/] [multihop <m/switch/]</tag>
	BFD sessions are usually created on demand as requested by other
	protocols (like OSPF or BGP). This option allows to explicitly add
	a BFD session to the specified neighbor regardless of such requests.
	
	The session is identified by the IP address of the neighbor, with
1444
	optional specification of used interface and local IP. By default
1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518
	the neighbor must be directly connected, unless the the session is
	configured as multihop. Note that local IP must be specified for
	multihop sessions.
</descrip>

<p>Session specific options (part of <cf/interface/ and <cf/multihop/ definitions):

<descrip>
	<tag>interval <m/time/</tag>
	BFD ensures availability of the forwarding path associated with the
	session by periodically sending BFD control packets in both
	directions. The rate of such packets is controlled by two options,
	<cf/min rx interval/ and <cf/min tx interval/ (see below). This option
	is just a shorthand to set both of these options together.

	<tag>min rx interval <m/time/</tag>
	This option specifies the minimum RX interval, which is announced to the
	neighbor and used there to limit the neighbor's rate of generated BFD
	control packets. Default: 10 ms.

	<tag>min tx interval <m/time/</tag>
	This option specifies the desired TX interval, which controls the rate
	of generated BFD control packets (together with <cf/min rx interval/
	announced by the neighbor). Note that this value is used only if the BFD
	session is up, otherwise the value of <cf/idle tx interval/ is used
	instead. Default: 100 ms.

	<tag>idle tx interval <m/time/</tag>
	In order to limit unnecessary traffic in cases where a neighbor is not
	available or not running BFD, the rate of generated BFD control packets
	is lower when the BFD session is not up. This option specifies the
	desired TX interval in such cases instead of <cf/min tx interval/.
	Default: 1 s.

	<tag>multiplier <m/num/</tag>
	Failure detection time for BFD sessions is based on established rate of
	BFD control packets (<cf>min rx/tx interval</cf>) multiplied by this
	multiplier, which is essentially (ignoring jitter) a number of missed
	packets after which the session is declared down. Note that rates and
	multipliers could be different in each direction of a BFD session.
	Default: 5.

	<tag>passive <m/switch/</tag>
	Generally, both BFD session endpoinds try to establish the session by
	sending control packets to the other side. This option allows to enable
	passive mode, which means that the router does not send BFD packets
	until it has received one from the other side. Default: disabled.
</descrip>

<sect1>Example

<p><code>
protocol bfd {
	interface "eth*" {
		min rx interval 20 ms;
		min tx interval 50 ms;
		idle tx interval 300 ms;
	};
	interface "gre*" {
		interval 200 ms;
		multiplier 10;
		passive;
	};
	multihop {
		interval 200 ms;
		multiplier 10;
	};

	neighbor 192.168.1.10;
	neighbor 192.168.2.2 dev "eth2";
	neighbor 192.168.10.1 local 192.168.1.1 multihop;
}
</code>

1519

1520
<sect>BGP
Martin Mareš's avatar
Martin Mareš committed
1521

1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541
<p>The Border Gateway Protocol is the routing protocol used for backbone level
routing in the today's Internet. Contrary to other protocols, its convergence
does not rely on all routers following the same rules for route selection,
making it possible to implement any routing policy at any router in the network,
the only restriction being that if a router advertises a route, it must accept
and forward packets according to it.

<p>BGP works in terms of autonomous systems (often abbreviated as AS). Each AS
is a part of the network with common management and common routing policy. It is
identified by a unique 16-bit number (ASN). Routers within each AS usually
exchange AS-internal routing information with each other using an interior
gateway protocol (IGP, such as OSPF or RIP). Boundary routers at the border of
the AS communicate global (inter-AS) network reachability information with their
neighbors in the neighboring AS'es via exterior BGP (eBGP) and redistribute
received information to other routers in the AS via interior BGP (iBGP).

<p>Each BGP router sends to its neighbors updates of the parts of its routing
table it wishes to export along with complete path information (a list of AS'es
the packet will travel through if it uses the particular route) in order to
avoid routing loops.
1542

Martin Mareš's avatar
Martin Mareš committed
1543
<p>BIRD supports all requirements of the BGP4 standard as defined in
1544 1545 1546 1547 1548 1549 1550
RFC 4271<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4271.txt">
It also supports the community attributes
(RFC 1997<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1997.txt">),
capability negotiation
(RFC 3392<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc3392.txt">),
MD5 password authentication
(RFC 2385<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2385.txt">),
1551 1552
extended communities
(RFC 4360<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4360.txt">),
1553 1554
route reflectors 
(RFC 4456<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4456.txt">),
1555 1556
graceful restart
(RFC 4724<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4724.txt">),
1557 1558
multiprotocol extensions
(RFC 4760<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4760.txt">),
1559 1560 1561 1562
4B AS numbers 
(RFC 4893<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4893.txt">),
and 4B AS numbers in extended communities
(RFC 5668<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5668.txt">).
1563 1564


Martin Mareš's avatar
Martin Mareš committed
1565
For IPv6, it uses the standard multiprotocol extensions defined in
1566
RFC 4760<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4760.txt">
Martin Mareš's avatar
Martin Mareš committed
1567 1568 1569
and applied to IPv6 according to
RFC 2545<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2545.txt">.

1570
<sect1>Route selection rules
Martin Mareš's avatar
Martin Mareš committed
1571 1572 1573

<p>BGP doesn't have any simple metric, so the rules for selection of an optimal
route among multiple BGP routes with the same preference are a bit more complex
1574 1575 1576
and they are implemented according to the following algorithm. It starts the
first rule, if there are more "best" routes, then it uses the second rule to
choose among them and so on.
Martin Mareš's avatar
Martin Mareš committed
1577 1578

<itemize>
Pavel Machek's avatar
Pavel Machek committed
1579
	<item>Prefer route with the highest Local Preference attribute.
Martin Mareš's avatar
Martin Mareš committed
1580
	<item>Prefer route with the shortest AS path.
1581
	<item>Prefer IGP origin over EGP and EGP origin over incomplete.
Martin Mareš's avatar
Martin Mareš committed
1582
	<item>Prefer the lowest value of the Multiple Exit Discriminator.
1583 1584
	<item>Prefer routes received via eBGP over ones received via iBGP.
	<item>Prefer routes with lower internal distance to a boundary router.
Pavel Machek's avatar
Pavel Machek committed
1585
	<item>Prefer the route with the lowest value of router ID of the
Martin Mareš's avatar
Martin Mareš committed
1586 1587
	advertising router.
</itemize>
1588

1589 1590
<sect1>IGP routing table

1591 1592 1593 1594 1595 1596 1597
<p>BGP is mainly concerned with global network reachability and with routes to
other autonomous systems. When such routes are redistributed to routers in the
AS via BGP, they contain IP addresses of a boundary routers (in route attribute
NEXT_HOP). BGP depends on existing IGP routing table with AS-internal routes to
determine immediate next hops for routes and to know their internal distances to
boundary routers for the purpose of BGP route selection. In BIRD, there is
usually one routing table used for both IGP routes and BGP routes.
1598

1599
<sect1>Configuration
1600

1601 1602 1603
<p>Each instance of the BGP corresponds to one neighboring router. This allows
to set routing policy and all the other parameters differently for each neighbor
using the following configuration parameters:
Martin Mareš's avatar
Martin Mareš committed
1604 1605

<descrip>
1606 1607 1608 1609 1610 1611
	<tag>local [<m/ip/] as <m/number/</tag>
	Define which AS we are part of. (Note that contrary to other IP routers,
	BIRD is able to act as a router located in multiple AS'es simultaneously,
	but in such cases you need to tweak the BGP paths manually in the filters
	to get consistent behavior.) Optional <cf/ip/ argument specifies a source
	address, equivalent to the <cf/source address/ option (see below). This
1612 1613
	parameter is mandatory.

1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640
	<tag>neighbor <m/ip/ as <m/number/</tag>
	Define neighboring router this instance will be talking to and what AS
	it's located in. In case the neighbor is in the same AS as we are, we
	automatically switch to iBGP. This parameter is mandatory.

	<tag>direct</tag>
	Specify that the neighbor is directly connected. The IP address of the
	neighbor must be from a directly reachable IP range (i.e. associated
	with one of your router's interfaces), otherwise the BGP session
	wouldn't start but it would wait for such interface to appear. The
	alternative is the <cf/multihop/ option. Default: enabled for eBGP.

	<tag>multihop [<m/number/]</tag>
	Configure multihop BGP session to a neighbor that isn't directly
	connected. Accurately, this option should be used if the configured
	neighbor IP address does not match with any local network subnets. Such
	IP address have to be reachable through system routing table. The
	alternative is the <cf/direct/ option. For multihop BGP it is
	recommended to explicitly configure the source address to have it
	stable. Optional <cf/number/ argument can be used to specify the number
	of hops (used for TTL). Note that the number of networks (edges) in a
	path is counted; i.e., if two BGP speakers are separated by one router,
	the number of hops is 2. Default: enabled for iBGP.

	<tag>source address <m/ip/</tag>
	Define local address we should use for next hop calculation and as a
	source address for the BGP session. Default: the address of the local
1641 1642
	end of the interface our neighbor is connected to.

1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683
	<tag>next hop self</tag>
	Avoid calculation of the Next Hop attribute and always advertise our own
	source address as a next hop. This needs to be used only occasionally to
	circumvent misconfigurations of other routers. Default: disabled.

	<tag>next hop keep</tag>
	Forward the received Next Hop attribute even in situations where the
	local address should be used instead, like when the route is sent to an
	interface with a different subnet. Default: disabled.

	<tag>missing lladdr self|drop|ignore</tag>
	Next Hop attribute in BGP-IPv6 sometimes contains just the global IPv6
	address, but sometimes it has to contain both global and link-local IPv6
	addresses. This option specifies what to do if BIRD have to send both
	addresses but does not know link-local address. This situation might
	happen when routes from other protocols are exported to BGP, or when
	improper updates are received from BGP peers. <cf/self/ means that BIRD
	advertises its own local address instead. <cf/drop/ means that BIRD
	skips that prefixes and logs error. <cf/ignore/ means that BIRD ignores
	the problem and sends just the global address (and therefore forms
	improper BGP update). Default: <cf/self/, unless BIRD is configured as a
	route server (option <cf/rs client/), in that case default is <cf/ignore/,
	because route servers usually do not forward packets themselves.

	<tag>gateway direct|recursive</tag>
	For received routes, their <cf/gw/ (immediate next hop) attribute is
	computed from received <cf/bgp_next_hop/ attribute. This option
	specifies how it is computed. Direct mode means that the IP address from
	<cf/bgp_next_hop/ is used if it is directly reachable, otherwise the
	neighbor IP address is used. Recursive mode means that the gateway is
	computed by an IGP routing table lookup for the IP address from
	<cf/bgp_next_hop/. Recursive mode is the behavior specified by the BGP
	standard. Direct mode is simpler, does not require any routes in a
	routing table, and was used in older versions of BIRD, but does not
	handle well nontrivial iBGP setups and multihop. Recursive mode is
	incompatible with <ref id="dsc-sorted" name="sorted tables">. Default:
	<cf/direct/ for direct sessions, <cf/recursive/ for multihop sessions.

	<tag>igp table <m/name/</tag>
	Specifies a table that is used as an IGP routing table. Default: the
	same as the table BGP is connected to.
1684 1685 1686 1687 1688 1689 1690 1691 1692

	<tag>bfd <M>switch</M></tag>
	BGP could use BFD protocol as an advisory mechanism for neighbor
	liveness and failure detection. If enabled, BIRD setups a BFD session
	for the BGP neighbor and tracks its liveness by it. This has an
	advantage of an order of magnitude lower detection times in case of
	failure. Note that BFD protocol also has to be configured, see
	<ref id="sect-bfd" name="BFD"> section for details. Default: disabled.

1693 1694 1695 1696 1697 1698 1699 1700 1701
	<tag>ttl security <m/switch/</tag>
	Use GTSM (RFC 5082 - the generalized TTL security mechanism). GTSM
	protects against spoofed packets by ignoring received packets with a
	smaller than expected TTL. To work properly, GTSM have to be enabled on
	both sides of a BGP session. If both <cf/ttl security/ and <cf/multihop/
	options are enabled, <cf/multihop/ option should specify proper hop
	value to compute expected TTL. Kernel support required: Linux: 2.6.34+
	(IPv4), 2.6.35+ (IPv6), BSD: since long ago, IPv4 only. Note that full
	(ICMP protection, for example) RFC 5082 support is provided by Linux
1702 1703
	only. Default: disabled.