Internet on FIRE

<!doctype birddoc system>

<!--

	BIRD documentation

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.

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.

    (set-fill-column 80)

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

 -->

<book>

<title>BIRD User's Guide

<author>

Ondrej Filip <it/&lt;feela@network.cz&gt;/,

Pavel Machek <it/&lt;pavel@ucw.cz&gt;/,

Martin Mares <it/&lt;mj@ucw.cz&gt;/,

Ondrej Zajicek <it/&lt;santiago@crfreenet.org&gt;/

</author>

<abstract>

This document contains user documentation for the BIRD Internet Routing Daemon project.

</abstract>

<!-- Table of contents -->

<toc>

<!-- Begin the document -->

<chapt>Introduction

<label id="intro">

<sect>What is BIRD

<label id="what-is-bird">

<p>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),

<HTMLURL URL="http://www.zebra.org" name="Zebra"> and

<HTMLURL URL="http://sourceforge.net/projects/mrt" name="MRTD">,

but their capabilities are limited and they are relatively hard to configure

and maintain.

<p>BIRD is an Internet Routing Daemon designed to avoid all of these shortcomings,

to support all the routing technology used in the today's Internet or planned to

be used in near future and to have a clean extensible architecture allowing new

routing protocols to be incorporated easily. Among other features, BIRD

supports:

<itemize>

	<item>both IPv4 and IPv6 protocols

	<item>multiple routing tables

	<item>the Border Gateway Protocol (BGPv4)

	<item>the Routing Information Protocol (RIPv2)

	<item>the Open Shortest Path First protocol (OSPFv2, OSPFv3)

	<item>the Router Advertisements for IPv6 hosts

	<item>a virtual protocol for exchange of routes between different

		routing tables on a single host

	<item>a command-line interface allowing on-line control and inspection

		of status of the daemon

	<item>soft reconfiguration (no need to use complex online commands to

		change the configuration, just edit the configuration file and

		notify BIRD to re-read it and it will smoothly switch itself to

		the new configuration, not disturbing routing protocols unless

		they are affected by the configuration changes)

	<item>a powerful language for route filtering

</itemize>

<p>BIRD has been developed at the Faculty of Math and Physics, Charles

University, Prague, Czech Republic as a student project. It can be freely

distributed under the terms of the GNU General Public License.

<p>BIRD has been designed to work on all UNIX-like systems. It has been

developed and tested under Linux 2.0 to 2.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.

<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 ...).

<sect>Installing BIRD

<label id="install">

<p>On a recent UNIX system with GNU development tools (GCC, binutils, m4, make)

and Perl, installing BIRD should be as easy as:

<code>

	./configure

	make

	make install

	vi /usr/local/etc/bird.conf

	bird

</code>

<p>You can use <tt>./configure --help</tt> to get a list of configure

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>.

<sect>Running BIRD

<label id="argv">

<p>You can pass several command-line options to bird:

<descrip>

	<tag><label id="argv-config">-c <m/config name/</tag>

	use given configuration file instead of <it/prefix/<file>/etc/bird.conf</file>.

	<tag><label id="argv-debug">-d</tag>

	enable debug messages and run bird in foreground.

	<tag><label id="argv-log-file">-D <m/filename of debug log/</tag>

	log debugging information to given file instead of stderr.

	<tag><label id="argv-foreground">-f</tag>

	run bird in foreground.

	<tag><label id="argv-group">-g <m/group/</tag>

	use that group ID, see the next section for details.

	<tag><label id="argv-help">-h, --help</tag>

	display command-line options to bird.

	<tag><label id="argv-local">-l</tag>

	look for a configuration file and a communication socket in the current

	working directory instead of in default system locations. However, paths

	specified by options <cf/-c/, <cf/-s/ have higher priority.

	<tag><label id="argv-parse">-p</tag>

	just parse the config file and exit. Return value is zero if the config

	file is valid, nonzero if there are some errors.

	<tag><label id="argv-pid">-P <m/name of PID file/</tag>

	create a PID file with given filename.

	<tag><label id="argv-recovery">-R</tag>

	apply graceful restart recovery after start.

	<tag><label id="argv-socket">-s <m/name of communication socket/</tag>

	use given filename for a socket for communications with the client,

	default is <it/prefix/<file>/var/run/bird.ctl</file>.

	<tag><label id="argv-user">-u <m/user/</tag>

	drop privileges and use that user ID, see the next section for details.

	<tag><label id="argv-version">--version</tag>

	display bird version.

</descrip>

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

<sect>Privileges

<label id="privileges">

<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>An unprivileged 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.

<chapt>About routing tables

<label id="routing-tables">

<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:

<itemize>

	<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)

	<item>preference of this route

	<item>IP address of router which told us about this route

	<item>IP address of router we should forward the packets to using this

		route

	<item>other attributes common to all routes

	<item>dynamic attributes defined by protocols which may or may not be

		present (typically protocol metrics)

</itemize>

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-table-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.

<sect>Graceful restart

<label id="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/.

<chapt>Configuration

<label id="config">

<sect>Introduction

<label id="config-intro">

<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, constants 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.

<code>

protocol kernel {

	persist;		# Don't remove routes on BIRD shutdown

	scan time 20;		# Scan kernel routing table every 20 seconds

	export all;		# Default is export none

}

protocol device {

	scan time 10;		# Scan interfaces every 10 seconds

}

protocol rip {

	export all;

	import all;

	interface "*";

}

</code>

<sect>Global options

<label id="global-opts">

<p><descrip>

	<tag><label id="opt-include">include "<m/filename/"</tag>

	This statement causes inclusion of a new file. <m/Filename/ could also

	be a wildcard, in that case matching files are included in alphabetic

	order. The maximal depth is 8. Note that this statement could be used

	anywhere in the config file, not just as a top-level option.

	<tag><label id="opt-log">log "<m/filename/"|syslog [name <m/name/]|stderr all|{ <m/list of classes/ }</tag>

	Set logging of messages having the given class (either <cf/all/ or

	<cf/{ error|trace [, <m/.../] }/ etc.) into selected destination (a file specified

	as a filename string, syslog with optional name argument, or the stderr

	output). Classes are:

	<cf/info/, <cf/warning/, <cf/error/ and <cf/fatal/ for messages about local problems,

	<cf/debug/ for debugging messages,

	<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,

	<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.

	<tag><label id="opt-debug-protocols">debug protocols all|off|{ states|routes|filters|interfaces|events|packets [, <m/.../] }</tag>

	Set global defaults of protocol debugging options. See <cf/debug/ in the

	following section. Default: off.

	<tag><label id="opt-debug-commands">debug commands <m/number/</tag>

	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.

	<tag><label id="opt-debug-latency">debug latency <m/switch/</tag>

	Activate tracking of elapsed time for internal events. Recent events

	could be examined using <cf/dump events/ command. Default: off.

	<tag><label id="opt-debug-latency-limit">debug latency limit <m/time/</tag>

	If <cf/debug latency/ is enabled, this option allows to specify a limit

	for elapsed time. Events exceeding the limit are logged. Default: 1 s.

	<tag><label id="opt-watchdog-warn">watchdog warning <m/time/</tag>

	Set time limit for I/O loop cycle. If one iteration took more time to

	complete, a warning is logged. Default: 5 s.

	<tag><label id="opt-watchdog-timeout">watchdog timeout <m/time/</tag>

	Set time limit for I/O loop cycle. If the limit is breached, BIRD is

	killed by abort signal. The timeout has effective granularity of

	seconds, zero means disabled. Default: disabled (0).

	<tag><label id="opt-mrtdump">mrtdump "<m/filename/"</tag>

	Set MRTdump file name. This option must be specified to allow MRTdump

	feature. Default: no dump file.

	<tag><label id="opt-mrtdump-protocols">mrtdump protocols all|off|{ states|messages [, <m/.../] }</tag>

	Set global defaults of MRTdump options. See <cf/mrtdump/ in the

	following section. Default: off.

	<tag><label id="opt-filter">filter <m/name local variables/{ <m/commands/ }</tag>

	Define a filter. You can learn more about filters in the following

	chapter.

	<tag><label id="opt-function">function <m/name/ (<m/parameters/) <m/local variables/ { <m/commands/ }</tag>

	Define a function. You can learn more about functions in the following chapter.

	<tag><label id="opt-protocol">protocol rip|ospf|bgp|<m/.../ [<m/name/ [from <m/name2/]] { <m>protocol options</m> }</tag>

	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.

	<tag><label id="opt-template">template rip|bgp|<m/.../ [<m/name/ [from <m/name2/]] { <m>protocol options</m> }</tag>

	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.

	<tag><label id="opt-define">define <m/constant/ = <m/expression/</tag>

	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.

	<tag><label id="opt-router-id">router id <m/IPv4 address/</tag>

	Set BIRD's router ID. It's a world-wide unique identification of your

	router, usually one of router's IPv4 addresses. Default: in IPv4

	version, the lowest IP address of a non-loopback interface. In IPv6

	version, this option is mandatory.

	<tag><label id="opt-router-id-from">router id from [-] [ "<m/mask/" ] [ <m/prefix/ ] [, <m/.../]</tag>

	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="proto-iface" name="interface"> section for detailed

	description of interface patterns with extended clauses.

	<tag><label id="opt-listen-bgp">listen bgp [address <m/address/] [port <m/port/] [dual]</tag>

	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.

	<tag><label id="opt-graceful-restart">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.

	<tag><label id="opt-timeformat">timeformat route|protocol|base|log "<m/format1/" [<m/limit/ "<m/format2/"]</tag>

	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"/.

	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.

	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.

	<tag><label id="opt-table">table <m/name/ [sorted]</tag>

	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-table-sorted" name="sorted table"> description for details.

	<tag><label id="opt-roa-table">roa table <m/name/ [ { <m/roa table options .../ } ]</tag>

	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

	id="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.

	<tag><label id="opt-eval">eval <m/expr/</tag>

	Evaluates given filter expression. It is used by us for	testing of filters.

</descrip>

<sect>Protocol options

<label id="protocol-opts">

<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).

<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").

<descrip>

	<tag><label id="proto-preference">preference <m/expr/</tag>

	Sets the preference of routes generated by this protocol. Default:

	protocol dependent.

	<tag><label id="proto-disabled">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.

	<tag><label id="proto-debug">debug all|off|{ states|routes|filters|interfaces|events|packets [, <m/.../] }</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

	(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.

	<tag><label id="proto-mrtdump">mrtdump all|off|{ states|messages [, <m/.../] }</tag>

	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.

	<tag><label id="proto-router-id">router id <m/IPv4 address/</tag>

	This option can be used to override global router id for a given

	protocol. Default: uses global router id.

	<tag><label id="proto-import">import all | none | filter <m/name/ | filter { <m/filter commands/ } | where <m/filter expression/</tag>

	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/.

	<tag><label id="proto-export">export <m/filter/</tag>

	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/.

	<tag><label id="proto-import-keep-filtered">import keep filtered <m/switch/</tag>

	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.

	<tag><label id="proto-import-limit">import limit [<m/number/ | off ] [action warn | block | restart | disable]</tag>

	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/.

	<tag><label id="proto-receive-limit">receive limit [<m/number/ | off ] [action warn | block | restart | disable]</tag>

	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/.

	<tag><label id="proto-export-limit">export limit [ <m/number/ | off ] [action warn | block | restart | disable]</tag>

	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/.

	<tag><label id="proto-description">description "<m/text/"</tag>

	This is an optional description of the protocol. It is displayed as a

	part of the output of 'show route all' command.

	<tag><label id="proto-table">table <m/name/</tag>

	Connect this protocol to a non-default routing table.

</descrip>

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

<descrip>

	<tag><label id="proto-iface">interface [-] [ "<m/mask/" ] [ <m/prefix/ ] [, <m/.../] [ { <m/option/; [<m/.../] } ]</tag>

	Specifies a set of interfaces on which the protocol is activated with

	given interface-specific options. A set of interfaces specified by one

	interface option is described using an interface pattern. The interface

	pattern consists of a sequence of clauses (separated by commas), each

	clause is a mask specified as a shell-like pattern. Interfaces are

	matched by their name.

	An interface matches the pattern if it matches any of its clauses. If

	the clause begins with <cf/-/, matching interfaces are excluded. Patterns

	are processed left-to-right, thus <cf/interface "eth0", -"eth*", "*";/

	means eth0 and all non-ethernets.

	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.

	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.

	This option is allowed in Babel, BFD, Direct, OSPF, RAdv and RIP

	protocols, but in OSPF protocol it is used in the <cf/area/ subsection.

	Default: none.

	Examples:

	<cf>interface "*" { type broadcast; };</cf> - start the protocol on all

	interfaces with <cf>type broadcast</cf> option.

	<cf>interface "eth1", "eth4", "eth5" { type ptp; };</cf> - start the

	protocol on enumerated interfaces with <cf>type ptp</cf> option.

	<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.

	<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.

	<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.

	<tag><label id="proto-tx-class">tx class|dscp <m/num/</tag>

	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).

	<tag><label id="proto-tx-priority">tx priority <m/num/</tag>

	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).

	<tag><label id="proto-pass">password "<m/password/" [ { <m>password options</m> } ]</tag>

	Specifies a password that can be used by the protocol as a shared secret

	key. Password option can be used more times to specify more passwords.

	If more passwords are specified, it is a protocol-dependent decision

	which one is really used. Specifying passwords does not mean that

	authentication is enabled, authentication can be enabled by separate,

	protocol-dependent <cf/authentication/ option.

	This option is allowed in BFD, 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><label id="proto-pass-id">id <M>num</M></tag>

	ID of the password, (1-255). If it is 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.

	<tag><label id="proto-pass-gen-from">generate from "<m/time/"</tag>

	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>.

	<tag><label id="proto-pass-gen-to">generate to "<m/time/"</tag>

	The last time of the usage of the password for packet signing.

	<tag><label id="proto-pass-accept-from">accept from "<m/time/"</tag>

	The start time of the usage of the password for packet verification.

	<tag><label id="proto-pass-accept-to">accept to "<m/time/"</tag>

	The last time of the usage of the password for packet verification.

	<tag><label id="proto-pass-from">from "<m/time/"</tag>

	Shorthand for setting both <cf/generate from/ and <cf/accept from/.

	<tag><label id="proto-pass-to">to "<m/time/"</tag>

	Shorthand for setting both <cf/generate to/ and <cf/accept to/.

	<tag><label id="proto-pass-algorithm">algorithm ( keyed md5 | keyed sha1 | hmac sha1 | hmac sha256 | hmac sha384 | hmac sha512 )</tag>

	The message authentication algorithm for the password when cryptographic

	authentication is enabled. The default value depends on the protocol.

	For RIP and OSPFv2 it is Keyed-MD5 (for compatibility), for OSPFv3

	protocol it is HMAC-SHA-256.

</descrip>

<sect>Flowspec network type

<label id="flowspec-network-type">

<p>The flow specification are rules for routers and firewalls for filtering

purpose. It is described by <rfc id="5575">. There are 3 types of arguments:

<m/inet4/ or <m/inet6/ prefixes, bitmasks matching expressions and numbers

matching expressions.

Bitmasks matching is written using <m/value/<cf>/</cf><m/mask/ or

<cf/!/<m/value/<cf>/</cf><m/mask/ pairs. It means that <cf/(/<m/data/ <cf/&/

<m/mask/<cf/)/ is or is not equal to <m/value/.

Numbers matching is a matching sequence of numbers and ranges separeted by a

commas (<cf/,/) (e.g. <cf/10,20,30/). Ranges can be written using double dots

<cf/../ notation (e.g. <cf/80..90,120..124/). An alternative notation are

sequence of one or more pairs of relational operators and values separated by

logical operators <cf/&&/ or <cf/||/. Allowed relational operators are <cf/=/,

<cf/!=/, <cf/</, <cf/<=/, <cf/>/, <cf/>=/, <cf/true/ and <cf/false/.

<sect1>IPv4 Flowspec

<p><descrip>

	<tag><label id="flow-dst">dst <m/inet4/</tag>

	Set a matching destination prefix (e.g. <cf>dst 192.168.0.0/16</cf>).

	Only this option is mandatory in IPv4 Flowspec.

	<tag><label id="flow-src">src <m/inet4/</tag>

	Set a matching source prefix (e.g. <cf>src 10.0.0.0/8</cf>).

	<tag><label id="flow-proto">proto <m/numbers-match/</tag>

	Set a matching IP protocol numbers (e.g.  <cf/proto 6/).

	<tag><label id="flow-port">port <m/numbers-match/</tag>

	Set a matching source or destination TCP/UDP port numbers (e.g.

	<cf>port 1..1023,1194,3306</cf>).

	<tag><label id="flow-dport">dport <m/numbers-match/</tag>

	Set a mating destination port numbers (e.g. <cf>dport 49151</cf>).

	<tag><label id="flow-sport">sport <m/numbers-match/</tag>

	Set a matching source port numbers (e.g. <cf>sport = 0</cf>).

	<tag><label id="flow-icmp-type">icmp type <m/numbers-match/</tag>

	Set a matching type field number of an ICMP packet (e.g. <cf>icmp type

	3</cf>)

	<tag><label id="flow-icmp-code">icmp code <m/numbers-match/</tag>

	Set a matching code field number of an ICMP packet (e.g. <cf>icmp code

	1</cf>)

	<tag><label id="flow-tcp-flags">tcp flags <m/bitmask-match/</tag>

	Set a matching bitmask for TCP header flags (aka control bits) (e.g.

	<cf>tcp flags 0x03/0x0f;</cf>).

	<tag><label id="flow-length">length <m/numbers-match/</tag>

	Set a matching packet length (e.g. <cf>length > 1500;</cf>)

	<tag><label id="flow-dscp">dscp <m/numbers-match/</tag>

	Set a matching DiffServ Code Point number (e.g. <cf>length > 1500;</cf>).

	<tag><label id="flow-fragment">fragment <m/fragmentation-type/</tag>

	Set a matching type of packet fragmentation. Allowed fragmentation

	types are <cf/dont_fragment/, <cf/is_fragment/, <cf/first_fragment/,

	<cf/last_fragment/ (e.g. <cf>fragment is_fragment &&

	!dont_fragment</cf>).

</descrip>

<p><code>

protocol static {

	flow4;

	route flow4 {

		dst 10.0.0.0/8;

		port > 24 && < 30 || 40..50,60..70,80 && >= 90;

		tcp flags 0x03/0x0f;

		length > 1024;

		dscp = 63;

		fragment dont_fragment, is_fragment || !first_fragment;

	} drop;

}

</code>

<sect1>Differences for IPv6 Flowspec

<p>Flowspec IPv6 are same as Flowspec IPv4 with a few exceptions.

<itemize>

	<item>Prefixes <m/inet6/ can be specified not only with prefix length,

	but with prefix <cf/offset/ <m/num/ too (e.g.

	<cf>::1234:5678:9800:0000/101 offset 64</cf>). Offset means to don't

	care of <m/num/ first bits.

	<item>IPv6 Flowspec hasn't mandatory any flowspec component.

	<item>In IPv6 packets, there is a matching the last next header value

	for a matching IP protocol number (e.g. <cf>next header 6</cf>).

	<item>It is not possible to set <cf>dont_fragment</cf> as a type of

	packet fragmentation.

</itemize>

<p><descrip>

	<tag><label id="flow6-dst">dst <m/inet6/ [offset <m/num/]</tag>

	Set a matching destination IPv6 prefix (e.g. <cf>dst

	::1c77:3769:27ad:a11a/128 offset 64</cf>).

	<tag><label id="flow6-src">src <m/inet6/ [offset <m/num/]</tag>

	Set a matching source IPv6 prefix (e.g. <cf>src fe80::/64</cf>).

	<tag><label id="flow6-next-header">next header <m/numbers-match/</tag>

	Set a matching IP protocol numbers (e.g. <cf>next header != 6</cf>).

	<tag><label id="flow6-label">label <m/bitmask-match/</tag>

	Set a 20-bit bitmask for matching Flow Label field in IPv6 packets

	(e.g. <cf>label 0x8e5/0x8e5</cf>).

</descrip>

<p><code>

protocol static {

	flow6;

	route flow6 {

		dst fec0:1122:3344:5566:7788:99aa:bbcc:ddee/128;

		src 0000:0000:0000:0001:1234:5678:9800:0000/101 offset 63;

		next header = 23;

		sport > 24 && < 30 || = 40 || 50,60,70..80;

		dport = 50;

		tcp flags 0x03/0x0f, !0/0xff || 0x33/0x33;

		fragment !is_fragment || !first_fragment;

		label 0xaaaa/0xaaaa && 0x33/0x33;

	} drop;

}

</code>

<chapt>Remote control

<label id="remote-control">

<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.

<p>Many commands have the <m/name/ of the protocol instance as an argument.

This argument can be omitted if there exists only a single instance.

<p>Here is a brief list of supported functions:

<descrip>

	<tag><label id="cli-show-status">show status</tag>

	Show router status, that is BIRD version, uptime and time from last

	reconfiguration.

	<tag><label id="cli-show-interfaces">show interfaces [summary]</tag>

	Show the list of interfaces. For each interface, print its type, state,

	MTU and addresses assigned.

	<tag><label id="cli-show-protocols">show protocols [all]</tag>

	Show list of protocol instances along with tables they are connected to

	and protocol status, possibly giving verbose information, if <cf/all/ is

	specified.

	<tag><label id="cli-show-ospf-iface">show ospf interface [<m/name/] ["<m/interface/"]</tag>

	Show detailed information about OSPF interfaces.

	<tag><label id="cli-show-ospf-neighbors">show ospf neighbors [<m/name/] ["<m/interface/"]</tag>

	Show a list of OSPF neighbors and a state of adjacency to them.

	<tag><label id="cli-show-ospf-state">show ospf state [all] [<m/name/]</tag>

	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.

	<tag><label id="cli-show-ospf-topology">show ospf topology [all] [<m/name/]</tag>

	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'.

	<tag><label id="cli-show-ospf-lsadb">show ospf lsadb [global | area <m/id/ | link] [type <m/num/] [lsid <m/id/] [self | router <m/id/] [<m/name/] </tag>

	Show contents of an OSPF LSA database. Options could be used to filter

	entries.

	<tag><label id="cli-show-rip-interfaces">show rip interfaces [<m/name/] ["<m/interface/"]</tag>

	Show detailed information about RIP interfaces.

	<tag><label id="cli-show-rip-neighbors">show rip neighbors [<m/name/] ["<m/interface/"]</tag>

	Show a list of RIP neighbors and associated state.

	<tag><label id="cli-show-static">show static [<m/name/]</tag>

	Show detailed information about static routes.

	<tag><label id="cli-show-bfd-sessions">show bfd sessions [<m/name/]</tag>

	Show information about BFD sessions.

	<tag><label id="cli-show-symbols">show symbols [table|filter|function|protocol|template|roa|<m/symbol/]</tag>

	Show the list of symbols defined in the configuration (names of

	protocols, routing tables etc.).

	<tag><label id="cli-show-route">show route [[for] <m/prefix/|<m/IP/] [table <m/t/] [filter <m/f/|where <m/c/] [(export|preexport|noexport) <m/p/] [protocol <m/p/] [<m/options/]</tag>

	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.

	<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>).

	The <cf/export/, <cf/preexport/ and <cf/noexport/ switches ask for

	printing of routes that are exported to the specified protocol.

	With <cf/preexport/, the export filter of the protocol is skipped.

	With <cf/noexport/, routes rejected by the export filter are printed

	instead. Note that routes not exported to the protocol for other reasons

	(e.g. secondary routes or routes imported from that protocol) are not

	printed even with <cf/noexport/.

	<p>You can also select just routes added by a specific protocol.

	<cf>protocol <m/p/</cf>.

	<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.

	<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.

	<tag><label id="cli-show-roa">show roa [<m/prefix/ | in <m/prefix/ | for <m/prefix/] [as <m/num/] [table <m/t/]</tag>

	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

	to show just entries for given AS.

	<tag><label id="cli-add-roa">add roa <m/prefix/ max <m/num/ as <m/num/ [table <m/t/]</tag>

	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.

	<tag><label id="cli-delete-roa">delete roa <m/prefix/ max <m/num/ as <m/num/ [table <m/t/]</tag>

	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.

	<tag><label id="cli-flush-roa">flush roa [table <m/t/]</tag>

	Remove all dynamic ROA entries from a ROA table.

	<tag><label id="cli-configure">configure [soft] ["<m/config file/"] [timeout [<m/num/]]</tag>

	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 becomes 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.

	<tag><label id="cli-configure-confirm">configure confirm</tag>

	Deactivate the config undo timer and therefore confirm the current

	configuration.

	<tag><label id="cli-configure-undo">configure undo</tag>

	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.

	<tag><label id="cli-configure-check">configure check ["<m/config file/"]</tag>

	Read and parse given config file, but do not use it. useful for checking

	syntactic and some semantic validity of an config file.

	<tag><label id="cli-enable-disable-restart">enable|disable|restart <m/name/|"<m/pattern/"|all</tag>

	Enable, disable or restart a given protocol instance, instances matching

	the <cf><m/pattern/</cf> or <cf/all/ instances.

	<tag><label id="cli-reload">reload [in|out] <m/name/|"<m/pattern/"|all</tag>

	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).

	<tag><label id="cli-down">down</tag>

	Shut BIRD down.

	<tag><label id="cli-debug">debug <m/protocol/|<m/pattern/|all all|off|{ states|routes|filters|events|packets [, <m/.../] }</tag>

	Control protocol debugging.

	<tag><label id="cli-dump">dump resources|sockets|interfaces|neighbors|attributes|routes|protocols</tag>

	Dump contents of internal data structures to the debugging output.

	<tag><label id="cli-echo">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="opt-log" name="log option"> for a list of log classes.

	<tag><label id="cli-eval">eval <m/expr/</tag>

	Evaluate given expression.

</descrip>

<chapt>Filters

<label id="filters">

<sect>Introduction

<label id="filters-intro">

<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>.

<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:

<code>

filter not_too_far

int var;

{

	if defined( rip_metric ) then

		var = rip_metric;

	else {

		var = 1;

		rip_metric = 1;

	}

	if rip_metric > 10 then

		reject "RIP metric is too big";

	else

		accept "ok";

}

</code>

<p>As you can see, 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.

<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:

<code>

function name ()

int local_variable;

{

	local_variable = 5;

}

function with_parameters (int parameter)

{

	print parameter;

}

</code>

<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).

<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.

<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:

<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 ?

show route [<prefix>] [table <t>] [filter <f>] [all] [primary]...

bird> show route filter { if 127.0.0.5 ˜ net then accept; }

127.0.0.0/8        dev lo [direct1 23:21] (240)

bird>

</code>

<sect>Data types

<label id="data-types">

<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).

<descrip>

	<tag><label id="type-bool">bool</tag>

	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><label id="type-int">int</tag>

	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><label id="type-pair">pair</tag>

	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><label id="type-quad">quad</tag>

	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><label id="type-string">string</tag>

	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"/. Additionally matching (<cf/&tilde;,

	!˜/) operators could be used to match a string value against

	a shell pattern (represented also as a string).

	<tag><label id="type-ip">ip</tag>

	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><label id="type-prefix">prefix</tag>

	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.len = 16</cf> is true.

	<tag><label id="type-ec">ec</tag>

	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).

	<tag><label id="type-lc">lc</tag>

	This is a specialized type used to represent BGP large community

	values. It is essentially a triplet of 32bit values, where the first

	value is reserved for the AS number of the issuer, while meaning of

	remaining parts is defined by the issuer. Literals of this type are

	written as <cf/(123, 456, 789)/, with any integer values. Similarly to

	pairs, LCs can be constructed using expressions for its parts, (e.g.

	<cf/(myas, 10+20, 3*10)/, where <cf/myas/ is an integer variable).

	<tag><label id="type-set">int|pair|quad|ip|prefix|ec|lc|enum set</tag>

	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).

	Also LC sets use similar expressions like pair sets. You can use ranges

	and wildcards, but if one field uses that, more specific (later) fields

	must be wildcards. E.g., <cf/(10, 20..30, *)/ or <cf/(10, 20, 30..40)/

	is valid, while <cf/(10, *, 20..30)/ or <cf/(10, 20..30, 40)/ is not

	valid.

	You can also use expressions for int, pair, EC and LC set values.

	However, it must be possible to evaluate these expressions before daemon

	boots. So you can use only constants inside them. E.g.

	<code>

	 define one=1;

	 define myas=64500;

	 int set odds;

	 pair set ps;

	 ec set es;

	 odds = [ one, 2+1, 6-one, 2*2*2-1, 9, 11 ];

	 ps = [ (1,one+one), (3,4)..(4,8), (5,*), (6,3..6), (7..9,*) ];

	 es = [ (rt, myas, 3*10), (rt, myas+one, 0..16*16*16-1), (ro, myas+2, *) ];

	</code>

	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>.

	<tag><label id="type-enum">enum</tag>

	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.

	<tag><label id="type-bgppath">bgppath</tag>

	BGP path is a list of autonomous system numbers. You can't write

	literals of this type. There are several special operators on bgppaths:

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

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

	<cf><m/P/.last_nonaggregated</cf> returns the last ASN in the non-aggregated part of the path <m/P/.

	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. If the path ends with an AS set, <cf/last_nonaggregated/

	may be used to get last ASN before any AS set.

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

	<cf>prepend(<m/P/,<m/A/)</cf> prepends ASN <m/A/ to path <m/P/ and

	returns the result.

	<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/.

	<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/.

	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/.

	<tag><label id="type-bgpmask">bgpmask</tag>

	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>. You can

        also use ranges, for example <tt>[= * 3..5 2 100..200 * =]</tt>.

        There is also old (deprecated) syntax that uses / .. / instead of [= .. =]

        and ? instead of *.

	<tag><label id="type-clist">clist</tag>

	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/.

	<tag><label id="type-eclist">eclist</tag>

	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;/ and

	<cf/!&tilde;/ membership operators) can be used to modify or test

	eclists, with ECs instead of pairs as arguments.

	<tag><label id="type-lclist">lclist/</tag>

	Lclist is a data type used for BGP large community lists. Like eclists,

	lclists are very similar to clists, but they are sets of LCs instead of

	pairs. The same operations (like <cf/add/, <cf/delete/ or <cf/&tilde;/

	and <cf/!&tilde;/ membership operators) can be used to modify or test

	lclists, with LCs instead of pairs as arguments.

</descrip>

<sect>Operators

<label id="operators">

<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;/,

<cf/!&tilde;/) for "is (not) 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 id="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

ROAs but none of them match. There is also an extended variant

<cf>roa_check(<m/table/, <m/prefix/, <m/asn/)</cf>, which allows to specify a

prefix and an ASN as arguments.

<sect>Control structures

<label id="control-structures">

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

<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 ˜ 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.

<p>Here is example that uses <cf/if/ and <cf/case/ structures:

<code>

case arg1 {

	2: print "two"; print "I can do more commands without {}";

	3 .. 5: print "three to five";

	else: print "something else";

}

if 1234 = i then printn "."; else {

  print "not 1234";

  print "You need {} around multiple commands";

}

</code>

<sect>Route attributes

<label id="route-attributes">

<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.

<descrip>

	<tag><label id="rta-net"><m/prefix/ net</tag>

	Network the route is talking about. Read-only. (See the chapter about

	routing tables.)

	<tag><label id="rta-scope"><m/enum/ scope</tag>

	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/.

	<tag><label id="rta-preference"><m/int/ preference</tag>

	Preference of the route. Valid values are 0-65535. (See the chapter

	about routing tables.)

	<tag><label id="rta-from"><m/ip/ from</tag>

	The router which the route has originated from.

	<tag><label id="rta-gw"><m/ip/ gw</tag>

	Next hop packets routed using this route should be forwarded to.

	<tag><label id="rta-proto"><m/string/ proto</tag>

	The name of the protocol which the route has been imported from.

	Read-only.

	<tag><label id="rta-source"><m/enum/ source</tag>

	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/, <cf/RTS_BABEL/.

	<tag><label id="rta-cast"><m/enum/ cast</tag>

	Route type (Currently <cf/RTC_UNICAST/ for normal routes,

	<cf/RTC_BROADCAST/, <cf/RTC_MULTICAST/, <cf/RTC_ANYCAST/ will be used in

	the future for broadcast, multicast and anycast routes). Read-only.

	<tag><label id="rta-dest"><m/enum/ dest</tag>

	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,

	<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/.

	<tag><label id="rta-ifname"><m/string/ ifname</tag>

	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.

	<tag><label id="rta-ifindex"><m/int/ ifindex</tag>

	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

	interfaces. Read-only.

	<tag><label id="rta-igp-metric"><m/int/ igp_metric</tag>

	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.

</descrip>

<p>There also exist some protocol-specific attributes which are described in the

corresponding protocol sections.

<sect>Other statements

<label id="other-statements">

<p>The following statements are available:

<descrip>

	<tag><label id="assignment"><m/variable/ = <m/expr/</tag>

	Set variable to a given value.

	<tag><label id="filter-accept-reject">accept|reject [ <m/expr/ ]</tag>

	Accept or reject the route, possibly printing <cf><m>expr</m></cf>.

	<tag><label id="return">return <m/expr/</tag>

	Return <cf><m>expr</m></cf> from the current function, the function ends

	at this point.

	<tag><label id="print">print|printn <m/expr/ [<m/, expr.../]</tag>

	Prints given expressions; useful mainly while debugging filters. The

	<cf/printn/ variant does not terminate the line.

	<tag><label id="quitbird">quitbird</tag>

	Terminates BIRD. Useful when debugging the filter interpreter.

</descrip>

<chapt>Protocols

<label id="protocols">

<sect>Babel

<label id="babel">

<sect1>Introduction

<label id="babel-intro">

<p>The Babel protocol

(<rfc id="6126">) is a loop-avoiding distance-vector routing protocol that is

robust and efficient both in ordinary wired networks and in wireless mesh

networks. Babel is conceptually very simple in its operation and "just works"