<!doctype birddoc system>
<!--
- BIRD documentation
+ BIRD 2.0 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
<book>
-<title>BIRD User's Guide
+<title>BIRD 2.0 User's Guide
<author>
Ondrej Filip <it/<feela@network.cz>/,
Pavel Machek <it/<pavel@ucw.cz>/,
Martin Mares <it/<mj@ucw.cz>/,
+Maria Matejka <it/<mq@jmq.cz>/,
Ondrej Zajicek <it/<santiago@crfreenet.org>/
</author>
<item>both IPv4 and IPv6 protocols
<item>multiple routing tables
<item>the Border Gateway Protocol (BGPv4)
- <item>the Routing Information Protocol (RIPv2)
+ <item>the Routing Information Protocol (RIPv2, RIPng)
<item>the Open Shortest Path First protocol (OSPFv2, OSPFv3)
+ <item>the Babel Routing Protocol
<item>the Router Advertisements for IPv6 hosts
<item>a virtual protocol for exchange of routes between different
routing tables on a single host
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 ...).
-
+<p>BIRD 1.x supported either IPv4 or IPv6 protocol, but had to be compiled separately
+for each one. BIRD~2 supports both of them with a possibility of further extension.
+BIRD~2 supports Linux at least 3.16, FreeBSD 10, NetBSD 7.0, and OpenBSD 5.8.
+Anyway, it will probably work well also on older systems.
<sect>Installing BIRD
<label id="install">
</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
+options. The most important ones are: <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>.
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.
+ enable debug messages to stderr, 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-debug-file">-D <m/filename of debug log/</tag>
+ enable debug messages to given file.
<tag><label id="argv-foreground">-f</tag>
run bird in foreground.
the config file and create the control socket and the CAP_NET_* capabilities.
-<chapt>About routing tables
+<chapt>Architecture
+<label id="architecture">
+
+<sect>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:
+<p>The heart of BIRD is a routing table. BIRD has several independent routing tables;
+each of them contains routes of exactly one <m/nettype/ (see below). There are two
+default tables -- <cf/master4/ for IPv4 routes and <cf/master6/ for IPv6 routes.
+Other tables must be explicitly configured.
+
+<p>
+These routing tables are not kernel forwarding tables. No forwarding is done by
+BIRD. If you want to forward packets using the routes in BIRD tables, you may
+use the Kernel protocol (see below) to synchronize them with kernel FIBs.
+
+<p>
+Every nettype defines a (kind of) primary key on routes. Every route source can
+supply one route for every possible primary key; new route announcement replaces
+the old route from the same source, keeping other routes intact. BIRD always
+chooses the best route for each primary key among the known routes and keeps the
+others as suboptimal. When the best route is retracted, BIRD re-runs the best
+route selection algorithm to find the current best route.
+
+<p>
+The global best route selection algorithm is (roughly) as follows:
<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)
+ <item>Preferences of the routes are compared.
+ <item>Source protocol instance preferences are compared.
+ <item>If source protocols are the same (e.g. BGP vs. BGP), the protocol's route selection algorithm is invoked.
+ <item>If source protocols are different (e.g. BGP vs. OSPF), result of the algorithm is undefined.
</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
+<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
advantage is that routes are shown sorted in <cf/show route/, minor disadvantage
is that it is slightly more computationally expensive.
+<sect>Routes and network types
+<label id="routes">
+
+<p>BIRD works with several types of routes. Some of them are typical IP routes,
+others are better described as forwarding rules. We call them all routes,
+regardless of this difference.
+
+<p>Every route consists of several attributes (read more about them in the
+<ref id="route-attributes" name="Route attributes"> section); the common for all
+routes are:
+
+<itemize>
+ <item>IP address of router which told us about this route
+ <item>Source protocol instance
+ <item>Route preference
+ <item>Optional attributes defined by protocols
+</itemize>
+
+<p>Other attributes depend on nettypes. Some of them are part of the primary key, these are marked (PK).
+
+<sect1>IPv4 and IPv6 routes
+<label id="ip-routes">
+
+<p>The traditional routes. Configuration keywords are <cf/ipv4/ and <cf/ipv6/.
+
+<itemize>
+ <item>(PK) Route destination (IP prefix together with its length)
+ <item>Route next hops (see below)
+</itemize>
+
+<sect1>IPv6 source-specific routes
+<label id="ip-sadr-routes">
+
+<p>The IPv6 routes containing both destination and source prefix. They are used
+for source-specific routing (SSR), also called source-address dependent routing
+(SADR), see <rfc id="8043">. Currently limited mostly to the Babel protocol.
+Configuration keyword is <cf/ipv6 sadr/.
+
+<itemize>
+ <item>(PK) Route destination (IP prefix together with its length)
+ <item>(PK) Route source (IP prefix together with its length)
+ <item>Route next hops (see below)
+</itemize>
+
+<sect1>VPN IPv4 and IPv6 routes
+<label id="vpn-routes">
+
+<p>Routes for IPv4 and IPv6 with VPN Route Distinguisher (<rfc id="4364">).
+Configuration keywords are <cf/vpn4/ and <cf/vpn6/.
+
+<itemize>
+ <item>(PK) Route destination (IP prefix together with its length)
+ <item>(PK) Route distinguisher (according to <rfc id="4364">)
+ <item>Route next hops
+</itemize>
+
+<sect1>Route Origin Authorization for IPv4 and IPv6
+<label id="roa-routes">
+
+<p>These entries can be used to validate route origination of BGP routes.
+A ROA entry specifies prefixes which could be originated by an AS number.
+Their keywords are <cf/roa4/ and <cf/roa6/.
+
+<itemize>
+ <item>(PK) IP prefix together with its length
+ <item>(PK) Matching prefix maximal length
+ <item>(PK) AS number
+</itemize>
+
+<sect1>Flowspec for IPv4 and IPv6
+<label id="flow-routes">
+
+<p>Flowspec rules are a form of firewall and traffic flow control rules
+distributed mostly via BGP. These rules may help the operators stop various
+network attacks in the beginning before eating up the whole bandwidth.
+Configuration keywords are <cf/flow4/ and <cf/flow6/.
+
+<itemize>
+ <item>(PK) IP prefix together with its length
+ <item>(PK) Flow definition data
+ <item>Flow action (encoded internally as BGP communities according to <rfc id="5575">)
+</itemize>
+
+<sect1>MPLS switching rules
+<label id="mpls-routes">
+
+<p>This nettype is currently a stub before implementing more support of <rfc id="3031">.
+BIRD currently does not support any label distribution protocol nor any label assignment method.
+Only the Kernel, Pipe and Static protocols can use MPLS tables.
+Configuration keyword is <cf/mpls/.
+
+<itemize>
+ <item>(PK) MPLS label
+ <item>Route next hops
+</itemize>
+
+<sect1>Route next hops
+<label id="route-next-hop">
+
+<p>This is not a nettype. The route next hop is a complex attribute common for many
+nettypes as you can see before. Every next hop has its assigned device
+(either assumed from its IP address or set explicitly). It may have also
+an IP address and an MPLS stack (one or both independently).
+Maximal MPLS stack depth is set (in compile time) to 8 labels.
+
+<p>Every route (when eligible to have a next hop) can have more than one next hop.
+In that case, every next hop has also its weight.
+
+<sect>Protocols and channels
+<label id="protocols-concept">
+
+<p>BIRD protocol is an abstract class of producers and consumers of the routes.
+Each protocol may run in multiple instances and bind on one side to route
+tables via channels, on the other side to specified listen sockets (BGP),
+interfaces (Babel, OSPF, RIP), APIs (Kernel, Direct), or nothing (Static, Pipe).
+
+<p>There are also two protocols that do not have any channels -- BFD and Device.
+Both of them are kind of service for other protocols.
+
+<p>Each protocol is connected to a routing table through a channel. Some protocols
+support only one channel (OSPF, RIP), some protocols support more channels (BGP, Direct).
+Each channel has two filters which can accept, reject and modify the routes.
+An <it/export/ filter is applied to routes passed from the routing table to the protocol,
+an <it/import/ filter is applied to routes in the opposite direction.
<sect>Graceful restart
<label id="graceful-restart">
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'").
+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. <cf/R123/, <cf/myfilter/, <cf/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.
+<cf/'1:strange-name'/, <cf/'-NAME-'/, <cf/'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.
+routing tables with OS kernel, learns network interfaces and runs RIP on all
+network interfaces found.
<code>
protocol kernel {
+ ipv4 {
+ export all; # Default is export none
+ };
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;
+ ipv4 {
+ import all;
+ export all;
+ };
interface "*";
}
</code>
<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:
+ <tag><label id="opt-include">include "<m/filename/";</tag>
+ This statement causes inclusion of a new file. The <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 can
+ be used anywhere in the config file, even inside other options, but
+ always on the beginning of line. In the following example, the first
+ semicolon belongs to the <cf/include/, the second to <cf/ipv6 table/.
+ If the <file/tablename.conf/ contains exactly one token (the name of the
+ table), this construction is correct:
+<code>
+ipv6 table
+include "tablename.conf";;
+</code>
+
+ <tag><label id="opt-log">log "<m/filename/" [<m/limit/ "<m/backup/"] | 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/.../] }</cf> etc.) into selected destination - a file
+ specified as a filename string (with optional log rotation information),
+ 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.
+
+ Logging directly to file supports basic log rotation -- there is an
+ optional log file limit and a backup filename, when log file reaches the
+ limit, the current log file is renamed to the backup filename and a new
+ log file is created.
+
You may specify more than one <cf/log/ line to establish logging to
- multiple destinations. Default: log everything to the system log.
+ multiple destinations. Default: log everything to the system log, or
+ to the debug output if debugging is enabled by <cf/-d//<cf/-D/
+ command-line option.
<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
<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>
+ <tag><label id="opt-template">template rip|ospf|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
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-attribute">attribute <m/type/ <m/name/</tag>
+ Define a custom route attribute. You can set and get it in filters like
+ any other route atribute. This feature is intended for marking routes
+ in import filters for export filtering purposes instead of locally
+ assigned BGP communities which have to be deleted in export filters.
+
<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.
+ router, usually one of router's IPv4 addresses. Default: the lowest
+ IPv4 address of a non-loopback interface.
<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.
+ Set BIRD's router ID based on an IPv4 address of an interface specified by
+ an interface pattern.
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
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"/.
+ <it/man strftime/ for details). It is extended to support sub-second
+ time part with variable precision (up to microseconds) using "%f"
+ conversion code (e.g., "%T.%3f" is hh:mm:ss.sss time). <m/limit/ and
+ "<m/format2/" allow to specify the second format string for times in
+ past deeper than <m/limit/ seconds.
+
+ There are several 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"/. Similarly, <cf/iso long ms/ and <cf/iso long us/ are ISO 8601
+ date/time formats with millisecond or microsecond precision.
<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"/.
+ format (YYYY-MM-DD) for far times. This is a shorthand for <cf/"%T"
+ 72000 "%F"/. And there are also <cf/iso short ms/ and <cf/iso short us/
+ high-precision variants of that.
- 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
+ By default, BIRD uses the <cf/iso short ms/ format for <cf/route/ and
+ <cf/protocol/ times, and the <cf/iso long ms/ 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-table"><m/nettype/ table <m/name/ [sorted]</tag>
+ Create a new routing table. The default routing tables <cf/master4/ and
+ <cf/master6/ are 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-eval">eval <m/expr/</tag>
- Evaluates given filter expression. It is used by us for testing of filters.
+ Evaluates given filter expression. It is used by the developers for testing of filters.
</descrip>
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.
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.
+ part of the output of 'show protocols all' command.
+
+ <tag><label id="proto-vrf">vrf "<m/text/"</tag>
+ Associate the protocol with specific VRF. The protocol will be
+ restricted to interfaces assigned to the VRF and will use sockets bound
+ to the VRF. Appropriate VRF interface must exist on OS level. For kernel
+ protocol, an appropriate table still must be explicitly selected by
+ <cf/table/ option. Note that for proper VRF support it is necessary to
+ use Linux kernel version at least 4.14, older versions have limited VRF
+ implementation.
+
+ <tag><label id="proto-channel"><m/channel name/ [{<m/channel config/}]</tag>
+ Every channel must be explicitly stated. See the protocol-specific
+ configuration for the list of supported channel names. See the
+ <ref id="channel-opts" name="channel configuration section"> for channel
+ definition.
</descrip>
<p>There are several options that give sense only with certain protocols:
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.
+ This option is allowed in Babel, BFD, Device, Direct, OSPF, RAdv and RIP
+ protocols. In OSPF protocol it is used in the <cf/area/ subsection.
Default: none.
</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>).
+<sect>Channel options
+<label id="channel-opts">
- <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>).
+<p>Every channel belongs to a protocol and is configured inside its block. The
+minimal channel config is empty, then it uses default values. The name of the
+channel implies its nettype. Channel definitions can be inherited from protocol
+templates. Multiple definitions of the same channel are forbidden, but channels
+inherited from templates can be updated by new definitions.
- <tag><label id="flow-dport">dport <m/numbers-match/</tag>
- Set a mating destination port numbers (e.g. <cf>dport 49151</cf>).
+<descrip>
+ <tag><label id="proto-table">table <m/name/</tag>
+ Specify a table to which the channel is connected. Default: the first
+ table of given nettype.
- <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="proto-preference">preference <m/expr/</tag>
+ Sets the preference of routes generated by the protocol and imported
+ through this channel. Default: protocol dependent.
- <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="proto-import">import all | none | filter <m/name/ | filter { <m/filter commands/ } | where <m/boolean filter expression/</tag>
+ Specify a filter to be used for filtering routes coming from the
+ protocol to the routing table. <cf/all/ is for keeping all routes,
+ <cf/none/ is for dropping all routes. Default: <cf/all/ (except for
+ EBGP).
- <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="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/
+ (except for EBGP).
- <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>). The maximum length of mask is 12 bits
- (0xfff).
+ <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="flow-length">length <m/numbers-match/</tag>
- Set a matching packet length (e.g. <cf>length > 1500;</cf>)
+ <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="flow-dscp">dscp <m/numbers-match/</tag>
- Set a matching DiffServ Code Point number (e.g. <cf>length > 1500;</cf>).
+ <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="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>).
+ <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/.
</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;
+<p>This is a trivial example of RIP configured for IPv6 on all interfaces:
+<code>
+protocol rip ng {
+ ipv6;
+ interface "*";
}
</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>).
+<p>This is a non-trivial example.
+<code>
+protocol rip ng {
+ ipv6 {
+ table mytable6;
+ import filter { ... };
+ export filter { ... };
+ import limit 50;
+ };
+ interface "*";
+}
+</code>
- <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>).
+<p>And this is even more complicated example using templates.
+<code>
+template bgp {
+ local 198.51.100.14 as 65000;
- <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>
+ ipv4 {
+ table mytable4;
+ import filter { ... };
+ export none;
+ };
+ ipv6 {
+ table mytable6;
+ import filter { ... };
+ export none;
+ };
+}
-<p><code>
-protocol static {
- flow6;
+protocol bgp from {
+ neighbor 198.51.100.130 as 64496;
- 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;
+ # IPv4 channel is inherited as-is, while IPv6
+ # channel is adjusted by export filter option
+ ipv6 {
+ export filter { ... };
+ };
}
</code>
+
<chapt>Remote control
<label id="remote-control">
and protocol status, possibly giving verbose information, if <cf/all/ is
specified.
+ <!-- TODO: Move these protocol-specific remote control commands to the protocol sections -->
<tag><label id="cli-show-ospf-iface">show ospf interface [<m/name/] ["<m/interface/"]</tag>
Show detailed information about OSPF interfaces.
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-mrt-dump">mrt dump table <m/name/|"<m/pattern/" to "<m/filename/" [filter <m/f/|where <m/c/]</tag>
+ Dump content of a routing table to a specified file in MRT table dump
+ format. See <ref id="mrt" name="MRT protocol"> for details.
+
<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,
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; this may be checked by <cf>.is_ip4</cf> which returns <cf/bool/.
- 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
+ This type can hold a single IP address. The IPv4 addresses are stored as
+ IPv4-Mapped IPv6 addresses so one data type for both of them is used.
+ Whether the address is IPv4 or not may be checked by <cf>.is_ip4</cf>
+ which returns <cf/bool/. 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>
operator <cf/.type/. The type may be:
<cf/NET_IP4/ and <cf/NET_IP6/ prefixes hold an IP prefix. The 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 IP prefixes: <cf/.ip/ which extracts the IP address from
- the pair, and <cf/.len/, which separates prefix length from the pair.
+ are written as <cf><m/ipaddress//<m/pxlen/</cf>. There are two special
+ operators on these: <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.
+ <cf/NET_IP6_SADR/ nettype holds both destination and source IPv6
+ prefix. The literals are written as <cf><m/ipaddress//<m/pxlen/ from
+ <m/ipaddress//<m/pxlen/</cf>, where the first part is the destination
+ prefix and the second art is the source prefix. They support the same
+ operators as IP prefixes, but just for the destination part.
+
<cf/NET_VPN4/ and <cf/NET_VPN6/ prefixes hold an IP prefix with VPN
Route Distinguisher (<rfc id="4364">). They support the same special
operators as IP prefixes, and also <cf/.rd/ which extracts the Route
<cf/NET_FLOW4/ and <cf/NET_FLOW6/ hold an IP prefix together with a
flowspec rule. Filters currently don't support flowspec parsing.
+ <cf/NET_MPLS/ holds a single MPLS label and its handling is currently
+ not implemented.
+
+ <tag><label id="type-vpnrd">vpnrd</tag>
+ This is a route distinguisher according to <rfc id="4364">. There are
+ three kinds of RD's: <cf><m/asn/:<m/32bit int/</cf>, <cf><m/asn4/:<m/16bit int/</cf>
+ and <cf><m/IPv4 address/:<m/32bit int/</cf>
+
<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
<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>.
+ It is possible to mix IPv4 and IPv6 prefixes/addresses in a prefix/ip set
+ but its behavior may change between versions without any warning; don't do
+ it unless you are more than sure what you are doing. (Really, don't do it.)
+
<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
<cf><m/P/.len</cf> returns the length of path <m/P/.
+ <cf><m/P/.empty</cf> makes the path <m/P/ empty.
+
<cf>prepend(<m/P/,<m/A/)</cf> prepends ASN <m/A/ to path <m/P/ and
returns the result.
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
<cf><m/C/.len</cf> returns the length of clist <m/C/.
+ <cf><m/C/.empty</cf> makes the list <m/C/ empty.
+
<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
<p>The filter language supports common integer operators <cf>(+,-,*,/)</cf>,
parentheses <cf/(a*(b+c))/, comparison <cf/(a=b, a!=b, a<b, a>=b)/.
-Logical operations include unary not (<cf/!/), and (<cf/&&/) and or
+Logical operations include unary not (<cf/!/), and (<cf/&&/), and or
(<cf/||/). Special operators include (<cf/˜/,
<cf/!˜/) 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
<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/;
+<p>Syntax of a condition is: <cf>if <M>boolean expression</M> then <m/commandT/;
+else <m/commandF/;</cf> and you can use <cf>{ <m/command1/; <m/command2/;
<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.
+omitted. If the <cf><m>boolean expression</m></cf> is true, <m/commandT/ is
+executed, otherwise <m/commandF/ 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/ ; [
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.
+rule are attributes of bgppath and *clist types, where undefined value is
+regarded as empty bgppath/*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.)
+ The network prefix or anything else the route is talking about. The
+ primary key of the routing table. Read-only. (See the <ref id="routes"
+ name="chapter about routes">.)
<tag><label id="rta-scope"><m/enum/ scope</tag>
The scope of the route. Possible values: <cf/SCOPE_HOST/ for routes
<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,
<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.
+ them, so <cf/ifname/ returns an empty string for such routes. Setting it
+ would also change route to a direct one (remove gateway).
<tag><label id="rta-ifindex"><m/int/ ifindex</tag>
Index of the outgoing interface. System wide index of the interface. May
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.
+ compare internal distances to boundary routers (see below).
</descrip>
-<p>There also exist some protocol-specific attributes which are described in the
+<p>There also exist protocol-specific attributes which are described in the
corresponding protocol sections.
in its default configuration, though some configuration is possible and in some
cases desirable.
-<p>While the Babel protocol is dual stack (i.e., can carry both IPv4 and IPv6
-routes over the same IPv6 transport), BIRD presently implements only the IPv6
-subset of the protocol. No Babel extensions are implemented, but the BIRD
-implementation can coexist with implementations using the extensions (and will
-just ignore extension messages).
+<p>The Babel protocol is dual stack; i.e., it can carry both IPv4 and IPv6
+routes over the same IPv6 transport. For sending and receiving Babel packets,
+only a link-local IPv6 address is needed.
-<p>The Babel protocol implementation in BIRD is currently in alpha stage.
+<p>BIRD implements an extension for IPv6 source-specific routing (SSR or SADR),
+but must be configured accordingly to use it. SADR-enabled Babel router can
+interoperate with non-SADR Babel router, but the later would ignore routes
+with specific (non-zero) source prefix.
<sect1>Configuration
<label id="babel-config">
-<p>Babel supports no global configuration options apart from those common to all
-other protocols, but supports the following per-interface configuration options:
+<p>The Babel protocol support both IPv4 and IPv6 channels; both can be
+configured simultaneously. It can also be configured with <ref
+id="ip-sadr-routes" name="IPv6 SADR"> channel instead of regular IPv6
+channel, in such case SADR support is enabled. Babel supports no global
+configuration options apart from those common to all other protocols, but
+supports the following per-interface configuration options:
<code>
protocol babel [<name>] {
+ ipv4 { <channel config> };
+ ipv6 [sadr] { <channel config> };
+ randomize router id <switch>;
interface <interface pattern> {
type <wired|wireless>;
rxcost <number>;
- hello interval <number>;
- update interval <number>;
+ limit <number>;
+ hello interval <time>;
+ update interval <time>;
port <number>;
tx class|dscp <number>;
tx priority <number>;
rx buffer <number>;
tx length <number>;
check link <switch>;
+ next hop ipv4 <address>;
+ next hop ipv6 <address>;
};
}
</code>
<descrip>
+ <tag><label id="babel-channel">ipv4 | ipv6 [sadr] <m/channel config/</tag>
+ The supported channels are IPv4, IPv6, and IPv6 SADR.
+
+ <tag><label id="babel-random-router-id">randomize router id <m/switch/</tag>
+ If enabled, Bird will randomize the top 32 bits of its router ID whenever
+ the protocol instance starts up. If a Babel node restarts, it loses its
+ sequence number, which can cause its routes to be rejected by peers until
+ the state is cleared out by other nodes in the network (which can take on
+ the order of minutes). Enabling this option causes Bird to pick a random
+ router ID every time it starts up, which avoids this problem at the cost
+ of not having stable router IDs in the network. Default: no.
+
<tag><label id="babel-type">type wired|wireless </tag>
- This option specifies the interface type: Wired or wireless. Wired
- interfaces are considered more reliable, and so the default hello
- interval is higher, and a neighbour is considered unreachable after only
- a small number of "hello" packets are lost. On wireless interfaces,
- hello packets are sent more often, and the ETX link quality estimation
- technique is used to compute the metrics of routes discovered over this
- interface. This technique will gradually degrade the metric of routes
- when packets are lost rather than the more binary up/down mechanism of
- wired type links. Default: <cf/wired/.
+ This option specifies the interface type: Wired or wireless. On wired
+ interfaces a neighbor is considered unreachable after a small number of
+ Hello packets are lost, as described by <cf/limit/ option. On wireless
+ interfaces the ETX link quality estimation technique is used to compute
+ the metrics of routes discovered over this interface. This technique will
+ gradually degrade the metric of routes when packets are lost rather than
+ the more binary up/down mechanism of wired type links. Default:
+ <cf/wired/.
<tag><label id="babel-rxcost">rxcost <m/num/</tag>
- This specifies the RX cost of the interface. The route metrics will be
- computed from this value with a mechanism determined by the interface
- <cf/type/. Default: 96 for wired interfaces, 256 for wireless.
-
- <tag><label id="babel-hello">hello interval <m/num/</tag>
- Interval at which periodic "hello" messages are sent on this interface,
- in seconds. Default: 4 seconds.
-
- <tag><label id="babel-update">update interval <m/num/</tag>
- Interval at which periodic (full) updates are sent. Default: 4 times the
- hello interval.
+ This option specifies the nominal RX cost of the interface. The effective
+ neighbor costs for route metrics will be computed from this value with a
+ mechanism determined by the interface <cf/type/. Note that in contrast to
+ other routing protocols like RIP or OSPF, the <cf/rxcost/ specifies the
+ cost of RX instead of TX, so it affects primarily neighbors' route
+ selection and not local route selection. Default: 96 for wired interfaces,
+ 256 for wireless.
+
+ <tag><label id="babel-limit">limit <m/num/</tag>
+ BIRD keeps track of received Hello messages from each neighbor to
+ establish neighbor reachability. For wired type interfaces, this option
+ specifies how many of last 16 hellos have to be correctly received in
+ order to neighbor is assumed to be up. The option is ignored on wireless
+ type interfaces, where gradual cost degradation is used instead of sharp
+ limit. Default: 12.
+
+ <tag><label id="babel-hello">hello interval <m/time/ s|ms</tag>
+ Interval at which periodic Hello messages are sent on this interface,
+ with time units. Default: 4 seconds.
+
+ <tag><label id="babel-update">update interval <m/time/ s|ms</tag>
+ Interval at which periodic (full) updates are sent, with time
+ units. Default: 4 times the hello interval.
<tag><label id="babel-port">port <m/number/</tag>
This option selects an UDP port to operate on. The default is to operate
routes received from them are withdrawn. It is possible that some
hardware drivers or platforms do not implement this feature. Default:
yes.
+
+ <tag><label id="babel-next-hop-ipv4">next hop ipv4 <m/address/</tag>
+ Set the next hop address advertised for IPv4 routes advertised on this
+ interface. Default: the preferred IPv4 address of the interface.
+
+ <tag><label id="babel-next-hop-ipv6">next hop ipv6 <m/address/</tag>
+ Set the next hop address advertised for IPv6 routes advertised on this
+ interface. If not set, the same link-local address that is used as the
+ source for Babel packets will be used. In normal operation, it should not
+ be necessary to set this option.
</descrip>
<sect1>Attributes
# configured on local interfaces, plus re-distribute all routes received
# from other babel peers.
- export where (source = RTS_DEVICE) || (source = RTS_BABEL);
+ ipv4 {
+ export where (source = RTS_DEVICE) || (source = RTS_BABEL);
+ };
+ ipv6 {
+ export where (source = RTS_DEVICE) || (source = RTS_BABEL);
+ };
}
</code>
+<sect1>Known issues
+<label id="babel-issues">
+
+<p>When retracting a route, Babel generates an unreachable route for a little
+while (according to RFC). The interaction of this behavior with other protocols
+is not well tested and strange things may happen.
+
<sect>BFD
<label id="bfd">
advanced features like the echo mode or authentication are not implemented), IP
transport for BFD as defined in <rfc id="5881"> and <rfc id="5883"> and
interaction with client protocols as defined in <rfc id="5882">.
-
-<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.
+We currently support at most one protocol instance.
<p>BFD packets are sent with a dynamic source port number. Linux systems use by
default a bit different dynamic port range than the IANA approved one
computation.
<tag>password "<M>text</M>"</tag>
- Specifies a password used for authentication. See <ref id="dsc-pass"
+ Specifies a password used for authentication. See <ref id="proto-pass"
name="password"> common option for detailed description. Note that
password option <cf/algorithm/ is not available in BFD protocol. The
algorithm is selected by <cf/authentication/ option for all passwords.
the packet will travel through if it uses the particular route) in order to
avoid routing loops.
-<sect1>Supported standards:
+<sect1>Supported standards
<label id="bgp-standards">
+<p>
<itemize>
<item> <rfc id="4271"> - Border Gateway Protocol 4 (BGP)
<item> <rfc id="1997"> - BGP Communities Attribute
<item> <rfc id="7911"> - Advertisement of Multiple Paths in BGP
<item> <rfc id="7947"> - Internet Exchange BGP Route Server
<item> <rfc id="8092"> - BGP Large Communities Attribute
+<item> <rfc id="8203"> - BGP Administrative Shutdown Communication
+<item> <rfc id="8212"> - Default EBGP Route Propagation Behavior without Policies
</itemize>
<sect1>Route selection rules
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.
-<sect1>Configuration
-<label id="bgp-config">
+<sect1>Protocol configuration
+<label id="bgp-proto-config">
<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:
<descrip>
- <tag><label id="bgp-local">local [<m/ip/] as <m/number/</tag>
+ <tag><label id="bgp-local">local [<m/ip/] [port <m/number/] [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
- parameter is mandatory.
+ address, equivalent to the <cf/source address/ option (see below).
+ Optional <cf/port/ argument specifies the local BGP port instead of
+ standard port 179. The parameter may be used multiple times with
+ different sub-options (e.g., both <cf/local 10.0.0.1 as 65000;/ and
+ <cf/local 10.0.0.1; local as 65000;/ are valid). This parameter is
+ mandatory.
<tag><label id="bgp-neighbor">neighbor [<m/ip/] [port <m/number/] [as <m/number/]</tag>
Define neighboring router this instance will be talking to and what AS
it is located in. In case the neighbor is in the same AS as we are, we
automatically switch to iBGP. Optionally, the remote port may also be
- specified. The parameter may be used multiple times with different
- sub-options (e.g., both <cf/neighbor 10.0.0.1 as 65000;/ and
- <cf/neighbor 10.0.0.1; neighbor as 65000;/ are valid). This parameter is
- mandatory.
+ specified. Like <cf/local/ parameter, this parameter may also be used
+ multiple times with different sub-options. This parameter is mandatory.
<tag><label id="bgp-iface">interface <m/string/</tag>
Define interface we should use for link-local BGP IPv6 sessions.
Interface can also be specified as a part of <cf/neighbor address/
- (e.g., <cf/neighbor fe80::1234%eth0 as 65000;/). It is an error to use
- this parameter for non link-local sessions.
+ (e.g., <cf/neighbor fe80::1234%eth0 as 65000;/). The option may also be
+ used for non link-local sessions when it is necessary to explicitly
+ specify an interface, but only for direct (not multihop) sessions.
<tag><label id="bgp-direct">direct</tag>
Specify that the neighbor is directly connected. The IP address of the
the number of hops is 2. Default: enabled for iBGP.
<tag><label id="bgp-source-address">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
- end of the interface our neighbor is connected to.
+ Define local address we should use as a source address for the BGP
+ session. Default: the address of the local end of the interface our
+ neighbor is connected to.
<tag><label id="bgp-strict-bind">strict bind <m/switch/</tag>
Specify whether BGP listening socket should be bound to a specific local
same address family and using the same local port) should have set
<cf/strict bind/, or none of them. Default: disabled.
- <tag><label id="bgp-next-hop-self">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><label id="bgp-next-hop-keep">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><label id="bgp-missing-lladdr">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><label id="bgp-gateway">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/. Note that there is just one level of indirection in
- recursive mode - the route obtained by the lookup must not be recursive
- itself, to prevent mutually recursive routes.
-
- 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-table-sorted" name="sorted tables">. Default:
- <cf/direct/ for direct sessions, <cf/recursive/ for multihop sessions.
-
- <tag><label id="bgp-igp-table">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.
-
<tag><label id="bgp-check-link">check link <M>switch</M></tag>
BGP could use hardware link state into consideration. If enabled,
BIRD tracks the link state of the associated interface and when link
disappears (e.g. an ethernet cable is unplugged), the BGP session is
immediately shut down. Note that this option cannot be used with
- multihop BGP. Default: disabled.
+ multihop BGP. Default: enabled for direct BGP, disabled otherwise.
- <tag><label id="bgp-bfd">bfd <M>switch</M></tag>
+ <tag><label id="bgp-bfd">bfd <M>switch</M>|graceful</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="bfd" name="BFD"> section for details. Default: disabled.
+ failure. When a neighbor failure is detected, the BGP session is
+ restarted. Optionally, it can be configured (by <cf/graceful/ argument)
+ to trigger graceful restart instead of regular restart. Note that BFD
+ protocol also has to be configured, see <ref id="bfd" name="BFD">
+ section for details. Default: disabled.
<tag><label id="bgp-ttl-security">ttl security <m/switch/</tag>
Use GTSM (<rfc id="5082"> - the generalized TTL security mechanism). GTSM
example does not prepend its AS number to AS PATH attribute and
keeps MED attribute). Default: disabled.
- <tag><label id="bgp-secondary">secondary <m/switch/</tag>
- Usually, if an export filter rejects a selected route, no other route is
- propagated for that network. This option allows to try the next route in
- order until one that is accepted is found or all routes for that network
- are rejected. This can be used for route servers that need to propagate
- different tables to each client but do not want to have these tables
- explicitly (to conserve memory). This option requires that the connected
- routing table is <ref id="dsc-table-sorted" name="sorted">. Default: off.
-
- <tag><label id="bgp-add-paths">add paths <m/switch/|rx|tx</tag>
- Standard BGP can propagate only one path (route) per destination network
- (usually the selected one). This option controls the add-path protocol
- extension, which allows to advertise any number of paths to a
- destination. Note that to be active, add-path has to be enabled on both
- sides of the BGP session, but it could be enabled separately for RX and
- TX direction. When active, all available routes accepted by the export
- filter are advertised to the neighbor. Default: off.
+ <tag><label id="bgp-allow-local-pref">allow bgp_local_pref <m/switch/</tag>
+ A standard BGP implementation do not send the Local Preference attribute
+ to eBGP neighbors and ignore this attribute if received from eBGP
+ neighbors, as per <rfc id="4271">. When this option is enabled on an
+ eBGP session, this attribute will be sent to and accepted from the peer,
+ which is useful for example if you have a setup like in <rfc id="7938">.
+ The option does not affect iBGP sessions. Default: off.
<tag><label id="bgp-allow-local-as">allow local as [<m/number/]</tag>
BGP prevents routing loops by rejecting received routes with the local
<tag><label id="bgp-graceful-restart">graceful restart <m/switch/|aware</tag>
When a BGP speaker restarts or crashes, neighbors will discard all
received paths from the speaker, which disrupts packet forwarding even
- when the forwarding plane of the speaker remains intact. <rfc
- id="4724"> specifies an optional graceful restart mechanism to
- alleviate this issue. This option controls the mechanism. It has three
- states: Disabled, when no support is provided. Aware, when the graceful
- restart support is announced and the support for restarting neighbors
- is provided, but no local graceful restart is allowed (i.e.
- receiving-only role). Enabled, when the full graceful restart
- support is provided (i.e. both restarting and receiving role). Note
- that proper support for local graceful restart requires also
- configuration of other protocols. Default: aware.
+ when the forwarding plane of the speaker remains intact. <rfc id="4724">
+ specifies an optional graceful restart mechanism to alleviate this
+ issue. This option controls the mechanism. It has three states:
+ Disabled, when no support is provided. Aware, when the graceful restart
+ support is announced and the support for restarting neighbors is
+ provided, but no local graceful restart is allowed (i.e. receiving-only
+ role). Enabled, when the full graceful restart support is provided
+ (i.e. both restarting and receiving role). Restarting role could be also
+ configured per-channel. Note that proper support for local graceful
+ restart requires also configuration of other protocols. Default: aware.
<tag><label id="bgp-graceful-restart-time">graceful restart time <m/number/</tag>
The restart time is announced in the BGP graceful restart capability
re-establish after a restart before deleting stale routes. Default:
120 seconds.
+ <tag><label id="bgp-long-lived-graceful-restart">long lived graceful restart <m/switch/|aware</tag>
+ The long-lived graceful restart is an extension of the traditional
+ <ref id="bgp-graceful-restart" name="BGP graceful restart">, where stale
+ routes are kept even after the <ref id="bgp-graceful-restart-time"
+ name="restart time"> expires for additional long-lived stale time, but
+ they are marked with the LLGR_STALE community, depreferenced, and
+ withdrawn from routers not supporting LLGR. Like traditional BGP
+ graceful restart, it has three states: disabled, aware (receiving-only),
+ and enabled. Note that long-lived graceful restart requires at least
+ aware level of traditional BGP graceful restart. Default: aware, unless
+ graceful restart is disabled.
+
+ <tag><label id="bgp-long-lived-stale-time">long lived stale time <m/number/</tag>
+ The long-lived stale time is announced in the BGP long-lived graceful
+ restart capability and specifies how long the neighbor would keep stale
+ routes depreferenced during long-lived graceful restart until either the
+ session is re-stablished and synchronized or the stale time expires and
+ routes are removed. Default: 3600 seconds.
+
<tag><label id="bgp-interpret-communities">interpret communities <m/switch/</tag>
<rfc id="1997"> demands that BGP speaker should process well-known
communities like no-export (65535, 65281) or no-advertise (65535,
disable the instance automatically and wait for an administrator to fix
the problem manually. Default: off.
+ <tag><label id="bgp-disable-after-cease">disable after cease <m/switch/|<m/set-of-flags/</tag>
+ When a Cease notification is received, disable the instance
+ automatically and wait for an administrator to fix the problem manually.
+ When used with <m/switch/ argument, it means handle every Cease subtype
+ with the exception of <cf/connection collision/. Default: off.
+
+ The <m/set-of-flags/ allows to narrow down relevant Cease subtypes. The
+ syntax is <cf>{<m/flag/ [, <m/.../] }</cf>, where flags are: <cf/cease/,
+ <cf/prefix limit hit/, <cf/administrative shutdown/,
+ <cf/peer deconfigured/, <cf/administrative reset/,
+ <cf/connection rejected/, <cf/configuration change/,
+ <cf/connection collision/, <cf/out of resources/.
+
<tag><label id="bgp-hold-time">hold time <m/number/</tag>
Time in seconds to wait for a Keepalive message from the other side
before considering the connection stale. Default: depends on agreement
<tag><label id="bgp-igp-metric">igp metric <m/switch/</tag>
Enable comparison of internal distances to boundary routers during best
- route selection. Default: on.
+ route selection. Default: on.
<tag><label id="bgp-prefer-older">prefer older <m/switch/</tag>
Standard route selection algorithm breaks ties by comparing router IDs.
Value of the Multiple Exit Discriminator to be used during route
selection when the MED attribute is missing. Default: 0.
- <tag><label id="bgp-default-local-pref">default bgp_local_pref <m/number/</tag>
- A default value for the Local Preference attribute. It is used when
- a new Local Preference attribute is attached to a route by the BGP
- protocol itself (for example, if a route is received through eBGP and
- therefore does not have such attribute). Default: 100 (0 in pre-1.2.0
- versions of BIRD).
+ <tag><label id="bgp-default-local-pref">default bgp_local_pref <m/number/</tag>
+ A default value for the Local Preference attribute. It is used when
+ a new Local Preference attribute is attached to a route by the BGP
+ protocol itself (for example, if a route is received through eBGP and
+ therefore does not have such attribute). Default: 100 (0 in pre-1.2.0
+ versions of BIRD).
+</descrip>
+
+<sect1>Channel configuration
+<label id="bgp-channel-config">
+
+<p>BGP supports several AFIs and SAFIs over one connection. Every AFI/SAFI
+announced to the peer corresponds to one channel. The table of supported AFI/SAFIs
+together with their appropriate channels follows.
+
+<table loc="h">
+<tabular ca="l|l|l|r|r">
+ <bf/Channel name/ | <bf/Table nettype/ | <bf/IGP table allowed/ | <bf/AFI/ | <bf/SAFI/
+@<hline>
+ <cf/ipv4/ | <cf/ipv4/ | <cf/ipv4/ and <cf/ipv6/ | 1 | 1
+@ <cf/ipv6/ | <cf/ipv6/ | <cf/ipv4/ and <cf/ipv6/ | 2 | 1
+@ <cf/ipv4 multicast/ | <cf/ipv4/ | <cf/ipv4/ and <cf/ipv6/ | 1 | 2
+@ <cf/ipv6 multicast/ | <cf/ipv6/ | <cf/ipv4/ and <cf/ipv6/ | 2 | 2
+@ <cf/ipv4 mpls/ | <cf/ipv4/ | <cf/ipv4/ and <cf/ipv6/ | 1 | 4
+@ <cf/ipv6 mpls/ | <cf/ipv6/ | <cf/ipv4/ and <cf/ipv6/ | 2 | 4
+@ <cf/vpn4 mpls/ | <cf/vpn4/ | <cf/ipv4/ and <cf/ipv6/ | 1 | 128
+@ <cf/vpn6 mpls/ | <cf/vpn6/ | <cf/ipv4/ and <cf/ipv6/ | 2 | 128
+@ <cf/vpn4 multicast/ | <cf/vpn4/ | <cf/ipv4/ and <cf/ipv6/ | 1 | 129
+@ <cf/vpn6 multicast/ | <cf/vpn6/ | <cf/ipv4/ and <cf/ipv6/ | 2 | 129
+@ <cf/flow4/ | <cf/flow4/ | --- | 1 | 133
+@ <cf/flow6/ | <cf/flow6/ | --- | 2 | 133
+</tabular>
+</table>
+
+<p>Due to <rfc id="8212">, external BGP protocol requires explicit configuration
+of import and export policies (in contrast to other protocols, where default
+policies of <cf/import all/ and <cf/export none/ are used in absence of explicit
+configuration). Note that blanket policies like <cf/all/ or <cf/none/ can still
+be used in explicit configuration.
+
+<p>BGP channels have additional config options (together with the common ones):
+
+<descrip>
+ <tag><label id="bgp-next-hop-keep">next hop keep <m/switch/|ibgp|ebgp</tag>
+ Do not modify the Next Hop attribute and advertise the current one
+ unchanged even in cases where our own local address should be used
+ instead. This is necessary when the BGP speaker does not forward network
+ traffic (route servers and some route reflectors) and also can be useful
+ in some other cases (e.g. multihop EBGP sessions). Can be enabled for
+ all routes, or just for routes received from IBGP / EBGP neighbors.
+ Default: disabled for regular BGP, enabled for route servers,
+ <cf/ibgp/ for route reflectors.
+
+ <tag><label id="bgp-next-hop-self">next hop self <m/switch/|ibgp|ebgp</tag>
+ Always advertise our own local address as a next hop, even in cases
+ where the current Next Hop attribute should be used unchanged. This is
+ sometimes used for routes propagated from EBGP to IBGP when IGP routing
+ does not cover inter-AS links, therefore IP addreses of EBGP neighbors
+ are not resolvable through IGP. Can be enabled for all routes, or just
+ for routes received from IBGP / EBGP neighbors. Default: disabled.
+
+ <tag><label id="bgp-next-hop-address">next hop address <m/ip/</tag>
+ Specify which address to use when our own local address should be
+ announced in the Next Hop attribute. Default: the source address of the
+ BGP session (if acceptable), or the preferred address of an associated
+ interface.
+
+ <tag><label id="bgp-missing-lladdr">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><label id="bgp-gateway">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/. Note that there is just one level of indirection in
+ recursive mode - the route obtained by the lookup must not be recursive
+ itself, to prevent mutually recursive routes.
+
+ 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-table-sorted" name="sorted tables">. Default:
+ <cf/direct/ for direct sessions, <cf/recursive/ for multihop sessions.
+
+ <tag><label id="bgp-igp-table">igp table <m/name/</tag>
+ Specifies a table that is used as an IGP routing table. The type of this
+ table must be as allowed in the table above. This option is allowed once
+ for every allowed table type. Default: the same as the main table
+ the channel is connected to (if eligible).
+
+ <tag><label id="bgp-import-table">import table <m/switch/</tag>
+ A BGP import table contains all received routes from given BGP neighbor,
+ before application of import filters. It is also called <em/Adj-RIB-In/
+ in BGP terminology. BIRD BGP by default operates without import tables,
+ in which case received routes are just processed by import filters,
+ accepted ones are stored in the master table, and the rest is forgotten.
+ Enabling <cf/import table/ allows to store unprocessed routes, which can
+ be examined later by <cf/show route/, and can be used to reconfigure
+ import filters without full route refresh. Default: off.
+
+ <tag><label id="bgp-secondary">secondary <m/switch/</tag>
+ Usually, if an export filter rejects a selected route, no other route is
+ propagated for that network. This option allows to try the next route in
+ order until one that is accepted is found or all routes for that network
+ are rejected. This can be used for route servers that need to propagate
+ different tables to each client but do not want to have these tables
+ explicitly (to conserve memory). This option requires that the connected
+ routing table is <ref id="dsc-table-sorted" name="sorted">. Default: off.
+
+ <tag><label id="bgp-extended-next-hop">extended next hop <m/switch/</tag>
+ BGP expects that announced next hops have the same address family as
+ associated network prefixes. This option provides an extension to use
+ IPv4 next hops with IPv6 prefixes and vice versa. For IPv4 / VPNv4
+ channels, the behavior is controlled by the Extended Next Hop Encoding
+ capability, as described in <rfc id="5549">. For IPv6 / VPNv6 channels,
+ just IPv4-mapped IPv6 addresses are used, as described in
+ <rfc id="4798"> and <rfc id="4659">. Default: off.
+
+ <tag><label id="bgp-add-paths">add paths <m/switch/|rx|tx</tag>
+ Standard BGP can propagate only one path (route) per destination network
+ (usually the selected one). This option controls the add-path protocol
+ extension, which allows to advertise any number of paths to a
+ destination. Note that to be active, add-path has to be enabled on both
+ sides of the BGP session, but it could be enabled separately for RX and
+ TX direction. When active, all available routes accepted by the export
+ filter are advertised to the neighbor. Default: off.
+
+ <tag><label id="bgp-graceful-restart-c">graceful restart <m/switch/</tag>
+ Although BGP graceful restart is configured mainly by protocol-wide
+ <ref id="bgp-graceful-restart" name="options">, it is possible to
+ configure restarting role per AFI/SAFI pair by this channel option.
+ The option is ignored if graceful restart is disabled by protocol-wide
+ option. Default: off in aware mode, on in full mode.
+
+ <tag><label id="bgp-long-lived-graceful-restart-c">long lived graceful restart <m/switch/</tag>
+ BGP long-lived graceful restart is configured mainly by protocol-wide
+ <ref id="bgp-long-lived-graceful-restart" name="options">, but the
+ restarting role can be set per AFI/SAFI pair by this channel option.
+ The option is ignored if long-lived graceful restart is disabled by
+ protocol-wide option. Default: off in aware mode, on in full mode.
+
+ <tag><label id="bgp-long-lived-stale-time-c">long lived stale time <m/number/</tag>
+ Like previous graceful restart channel options, this option allows to
+ set <ref id="bgp-long-lived-stale-time" name="long lived stale time">
+ per AFI/SAFI pair instead of per protocol. Default: set by protocol-wide
+ option.
</descrip>
<sect1>Attributes
some of them (marked with `<tt/O/') are optional.
<descrip>
- <tag><label id="rta-bgp-path">bgppath bgp_path/</tag>
+ <tag><label id="rta-bgp-path">bgppath bgp_path</tag>
Sequence of AS numbers describing the AS path the packet will travel
through when forwarded according to the particular route. In case of
internal BGP it doesn't contain the number of the local AS.
- <tag><label id="rta-bgp-local-pref">int bgp_local_pref/ [I]</tag>
+ <tag><label id="rta-bgp-local-pref">int bgp_local_pref [I]</tag>
Local preference value used for selection among multiple BGP routes (see
the selection rules above). It's used as an additional metric which is
propagated through the whole local AS.
- <tag><label id="rta-bgp-med">int bgp_med/ [O]</tag>
+ <tag><label id="rta-bgp-med">int bgp_med [O]</tag>
The Multiple Exit Discriminator of the route is an optional attribute
which is used on external (inter-AS) links to convey to an adjacent AS
the optimal entry point into the local AS. The received attribute is
external BGP instance. See <rfc id="4451"> for further discussion of
BGP MED attribute.
- <tag><label id="rta-bgp-origin">enum bgp_origin/</tag>
+ <tag><label id="rta-bgp-origin">enum bgp_origin</tag>
Origin of the route: either <cf/ORIGIN_IGP/ if the route has originated
in an interior routing protocol or <cf/ORIGIN_EGP/ if it's been imported
from the <tt>EGP</tt> protocol (nowadays it seems to be obsolete) or
<cf/ORIGIN_INCOMPLETE/ if the origin is unknown.
- <tag><label id="rta-bgp-next-hop">ip bgp_next_hop/</tag>
+ <tag><label id="rta-bgp-next-hop">ip bgp_next_hop</tag>
Next hop to be used for forwarding of packets to this destination. On
internal BGP connections, it's an address of the originating router if
it's inside the local AS or a boundary router the packet will leave the
AS through if it's an exterior route, so each BGP speaker within the AS
has a chance to use the shortest interior path possible to this point.
- <tag><label id="rta-bgp-atomic-aggr">void bgp_atomic_aggr/ [O]</tag>
+ <tag><label id="rta-bgp-atomic-aggr">void bgp_atomic_aggr [O]</tag>
This is an optional attribute which carries no value, but the sole
presence of which indicates that the route has been aggregated from
multiple routes by some router on the path from the originator.
<!-- we don't handle aggregators right since they are of a very obscure type
<tag>bgp_aggregator</tag>
-->
- <tag><label id="rta-bgp-community">clist bgp_community/ [O]</tag>
+ <tag><label id="rta-bgp-community">clist bgp_community [O]</tag>
List of community values associated with the route. Each such value is a
pair (represented as a <cf/pair/ data type inside the filters) of 16-bit
integers, the first of them containing the number of the AS which
freedom about which community attributes it defines and what will their
semantics be.
- <tag><label id="rta-bgp-ext-community">eclist bgp_ext_community/ [O]</tag>
+ <tag><label id="rta-bgp-ext-community">eclist bgp_ext_community [O]</tag>
List of extended community values associated with the route. Extended
communities have similar usage as plain communities, but they have an
extended range (to allow 4B ASNs) and a nontrivial structure with a type
field. Individual community values are represented using an <cf/ec/ data
type inside the filters.
- <tag><label id="rta-bgp-large-community">lclist <cf/bgp_large_community/ [O]</tag>
+ <tag><label id="rta-bgp-large-community">lclist bgp_large_community [O]</tag>
List of large community values associated with the route. Large BGP
communities is another variant of communities, but contrary to extended
communities they behave very much the same way as regular communities,
Individual community values are represented using an <cf/lc/ data type
inside the filters.
- <tag><label id="rta-bgp-originator-id">quad bgp_originator_id/ [I, O]</tag>
+ <tag><label id="rta-bgp-originator-id">quad bgp_originator_id [I, O]</tag>
This attribute is created by the route reflector when reflecting the
route and contains the router ID of the originator of the route in the
local AS.
- <tag><label id="rta-bgp-cluster-list">clist bgp_cluster_list/ [I, O]</tag>
+ <tag><label id="rta-bgp-cluster-list">clist bgp_cluster_list [I, O]</tag>
This attribute contains a list of cluster IDs of route reflectors. Each
route reflector prepends its cluster ID when reflecting the route.
</descrip>
<p><code>
protocol bgp {
- local as 65000; # Use a private AS number
+ local 198.51.100.14 as 65000; # Use a private AS number
neighbor 198.51.100.130 as 64496; # Our neighbor ...
multihop; # ... which is connected indirectly
- export filter { # We use non-trivial export rules
- if source = RTS_STATIC then { # Export only static routes
- # Assign our community
- bgp_community.add((65000,64501));
- # Artificially increase path length
- # by advertising local AS number twice
- if bgp_path ~ [= 65000 =] then
- bgp_path.prepend(65000);
- accept;
- }
- reject;
+ ipv4 {
+ export filter { # We use non-trivial export rules
+ if source = RTS_STATIC then { # Export only static routes
+ # Assign our community
+ bgp_community.add((65000,64501));
+ # Artificially increase path length
+ # by advertising local AS number twice
+ if bgp_path ~ [= 65000 =] then
+ bgp_path.prepend(65000);
+ accept;
+ }
+ reject;
+ };
+ import all;
+ next hop self; # advertise this router as next hop
+ igp table myigptable4; # IGP table for routes with IPv4 nexthops
+ igp table myigptable6; # IGP table for routes with IPv6 nexthops
+ };
+ ipv6 {
+ export filter mylargefilter; # We use a named filter
+ import all;
+ missing lladdr self;
+ igp table myigptable4; # IGP table for routes with IPv4 nexthops
+ igp table myigptable6; # IGP table for routes with IPv6 nexthops
+ };
+ ipv4 multicast {
+ import all;
+ export filter someotherfilter;
+ table mymulticasttable4; # Another IPv4 table, dedicated for multicast
+ igp table myigptable4;
};
- import all;
- source address 198.51.100.14; # Use a non-standard source address
}
</code>
<p>The Device protocol is not a real routing protocol. It doesn't generate any
routes and it only serves as a module for getting information about network
-interfaces from the kernel.
+interfaces from the kernel. This protocol supports no channel.
<p>Except for very unusual circumstances, you probably should include this
protocol in the configuration since almost all other protocols require network
<label id="device-config">
<p><descrip>
-
<tag><label id="device-scan-time">scan time <m/number/</tag>
Time in seconds between two scans of the network interface list. On
systems where we are notified about interface status changes
list only in order to avoid confusion by lost notification messages,
so the default time is set to a large value.
- <tag><label id="device-primary">primary [ "<m/mask/" ] <m/prefix/</tag>
- If a network interface has more than one network address, BIRD has to
- choose one of them as a primary one. By default, BIRD chooses the
- lexicographically smallest address as the primary one.
-
- This option allows to specify which network address should be chosen as
- a primary one. Network addresses that match <m/prefix/ are preferred to
- non-matching addresses. If more <cf/primary/ options are used, the first
- one has the highest preference. If "<m/mask/" is specified, then such
- <cf/primary/ option is relevant only to matching network interfaces.
-
- In all cases, an address marked by operating system as secondary cannot
- be chosen as the primary one.
+ <tag><label id="device-iface">interface <m/pattern/ [, <m/.../]</tag>
+ By default, the Device protocol handles all interfaces without any
+ configuration. Interface definitions allow to specify optional
+ parameters for specific interfaces. See <ref id="proto-iface"
+ name="interface"> common option for detailed description. Currently only
+ one interface option is available:
+
+ <tag><label id="device-preferred">preferred <m/ip/</tag>
+ If a network interface has more than one IP address, BIRD chooses one of
+ them as a preferred one. Preferred IP address is used as source address
+ for packets or announced next hop by routing protocols. Precisely, BIRD
+ chooses one preferred IPv4 address, one preferred IPv6 address and one
+ preferred link-local IPv6 address. By default, BIRD chooses the first
+ found IP address as the preferred one.
+
+ This option allows to specify which IP address should be preferred. May
+ be used multiple times for different address classes (IPv4, IPv6, IPv6
+ link-local). In all cases, an address marked by operating system as
+ secondary cannot be chosen as the primary one.
</descrip>
<p>As the Device protocol doesn't generate any routes, it cannot have
<p><code>
protocol device {
scan time 10; # Scan the interfaces often
- primary "eth0" 192.168.1.1;
- primary 192.168.0.0/16;
+ interface "eth0" {
+ preferred 192.168.1.1;
+ preferred 2001:db8:1:10::1;
+ };
}
</code>
<p>The Direct protocol is a simple generator of device routes for all the
directly connected networks according to the list of interfaces provided by the
-kernel via the Device protocol.
+kernel via the Device protocol. The Direct protocol supports both IPv4 and IPv6
+channels; both can be configured simultaneously. It can also be configured with
+<ref id="ip-sadr-routes" name="IPv6 SADR"> channel instead of regular IPv6
+channel in order to be used together with SADR-enabled Babel protocol.
<p>The question is whether it is a good idea to have such device routes in BIRD
routing table. OS kernel usually handles device routes for directly connected
networks by itself so we don't need (and don't want) to export these routes to
the kernel protocol. OSPF protocol creates device routes for its interfaces
-itself and BGP protocol is usually used for exporting aggregate routes. Although
-there are some use cases that use the direct protocol (like abusing eBGP as an
-IGP routing protocol), in most cases it is not needed to have these device
-routes in BIRD routing table and to use the direct protocol.
-
-<p>There is one notable case when you definitely want to use the direct protocol
--- running BIRD on BSD systems. Having high priority device routes for directly
-connected networks from the direct protocol protects kernel device routes from
-being overwritten or removed by IGP routes during some transient network
-conditions, because a lower priority IGP route for the same network is not
-exported to the kernel routing table. This is an issue on BSD systems only, as
-on Linux systems BIRD cannot change non-BIRD route in the kernel routing table.
+itself and BGP protocol is usually used for exporting aggregate routes. But the
+Direct protocol is necessary for distance-vector protocols like RIP or Babel to
+announce local networks.
<p>There are just few configuration options for the Direct protocol:
<p><code>
protocol direct {
+ ipv4;
+ ipv6;
interface "-arc*", "*"; # Exclude the ARCnets
}
</code>
on the <cf/learn/ switch, such routes are either ignored or accepted to our
table).
-<p>Unfortunately, there is one thing that makes the routing table synchronization
-a bit more complicated. In the kernel routing table there are also device routes
-for directly connected networks. These routes are usually managed by OS itself
-(as a part of IP address configuration) and we don't want to touch that. They
-are completely ignored during the scan of the kernel tables and also the export
-of device routes from BIRD tables to kernel routing tables is restricted to
-prevent accidental interference. This restriction can be disabled using
-<cf/device routes/ switch.
+<p>Note that routes created by OS kernel itself, namely direct routes
+representing IP subnets of associated interfaces, are not imported even with
+<cf/learn/ enabled. You can use <ref id="direct" name="Direct protocol"> to
+generate these direct routes.
<p>If your OS supports only a single routing table, you can configure only one
instance of the Kernel protocol. If it supports multiple tables (in order to
(gateway) in an export filter of a kernel protocol does not work. Both
limitations can be overcome using another routing table and the pipe protocol.
+<p>The Kernel protocol supports both IPv4 and IPv6 channels; only one channel
+can be configured in each protocol instance. On Linux, it also supports <ref
+id="ip-sadr-routes" name="IPv6 SADR"> and <ref id="mpls-routes" name="MPLS">
+channels.
+
<sect1>Configuration
<label id="krt-config">
routing daemons or by the system administrator. This is possible only on
systems which support identification of route authorship.
- <tag><label id="krt-device-routes">device routes <m/switch/</tag>
- Enable export of device routes to the kernel routing table. By default,
- such routes are rejected (with the exception of explicitly configured
- device routes from the static protocol) regardless of the export filter
- to protect device routes in kernel routing table (managed by OS itself)
- from accidental overwriting or erasing.
-
<tag><label id="krt-kernel-table">kernel table <m/number/</tag>
Select which kernel table should this particular instance of the Kernel
protocol work with. Available only on systems supporting multiple
these attributes:
<descrip>
- <tag><label id="rta-krt-source">int krt_source/</tag>
+ <tag><label id="rta-krt-source">int krt_source</tag>
The original source of the imported kernel route. The value is
system-dependent. On Linux, it is a value of the protocol field of the
route. See /etc/iproute2/rt_protos for common values. On BSD, it is
based on STATIC and PROTOx flags. The attribute is read-only.
- <tag><label id="rta-krt-metric">int krt_metric/</tag> (Linux)
+ <tag><label id="rta-krt-metric">int krt_metric</tag> (Linux)
The kernel metric of the route. When multiple same routes are in a
kernel routing table, the Linux kernel chooses one with lower metric.
Note that preferred way to set kernel metric is to use protocol option
<cf/metric/, unless per-route metric values are needed.
- <tag><label id="rta-krt-prefsrc">ip krt_prefsrc/</tag> (Linux)
+ <tag><label id="rta-krt-prefsrc">ip krt_prefsrc</tag> (Linux)
The preferred source address. Used in source address selection for
outgoing packets. Has to be one of the IP addresses of the router.
- <tag><label id="rta-krt-realm">int krt_realm/</tag> (Linux)
+ <tag><label id="rta-krt-realm">int krt_realm</tag> (Linux)
The realm of the route. Can be used for traffic classification.
- <tag><label id="rta-krt-scope">int krt_scope/</tag> (Linux IPv4)
+ <tag><label id="rta-krt-scope">int krt_scope</tag> (Linux IPv4)
The scope of the route. Valid values are 0-254, although Linux kernel
may reject some values depending on route type and nexthop. It is
supposed to represent `indirectness' of the route, where nexthops of
learn; # Learn alien routes from the kernel
persist; # Don't remove routes on bird shutdown
scan time 10; # Scan kernel routing table every 10 seconds
- import all;
- export all;
+ ipv4 {
+ import all;
+ export all;
+ };
}
protocol kernel { # Secondary routing table
- table auxtable;
kernel table 100;
- export all;
+ ipv4 {
+ table auxtable;
+ export all;
+ };
+}
+</code>
+
+
+<sect>MRT
+<label id="mrt">
+
+<sect1>Introduction
+<label id="mrt-intro">
+
+<p>The MRT protocol is a component responsible for handling the Multi-Threaded
+Routing Toolkit (MRT) routing information export format, which is mainly used
+for collecting and analyzing of routing information from BGP routers. The MRT
+protocol can be configured to do periodic dumps of routing tables, created MRT
+files can be analyzed later by other tools. Independent MRT table dumps can also
+be requested from BIRD client. There is also a feature to save incoming BGP
+messages in MRT files, but it is controlled by <ref id="proto-mrtdump"
+name="mrtdump"> options independently of MRT protocol, although that might
+change in the future.
+
+BIRD implements the main MRT format specification as defined in <rfc id="6396">
+and the ADD_PATH extension (<rfc id="8050">).
+
+<sect1>Configuration
+<label id="mrt-config">
+
+<p>MRT configuration consists of several statements describing routing table
+dumps. Multiple independent periodic dumps can be done as multiple MRT protocol
+instances. The MRT protocol does not use channels. There are two mandatory
+statements: <cf/filename/ and <cf/period/.
+
+The behavior can be modified by following configuration parameters:
+
+<descrip>
+ <tag><label id="mrt-table">table <m/name/ | "<m/pattern/"</tag>
+ Specify a routing table (or a set of routing tables described by a
+ wildcard pattern) that are to be dumped by the MRT protocol instance.
+ Default: the master table.
+
+ <tag><label id="mrt-filter">filter { <m/filter commands/ }</tag>
+ The MRT protocol allows to specify a filter that is applied to routes as
+ they are dumped. Rejected routes are ignored and not saved to the MRT
+ dump file. Default: no filter.
+
+ <tag><label id="mrt-where">where <m/filter expression/</tag>
+ An alternative way to specify a filter for the MRT protocol.
+
+ <tag><label id="mrt-filename">filename "<m/filename/"</tag>
+ Specify a filename for MRT dump files. The filename may contain time
+ format sequences with <it/strftime(3)/ notation (see <it/man strftime/
+ for details), there is also a sequence "%N" that is expanded to the name
+ of dumped table. Therefore, each periodic dump of each table can be
+ saved to a different file. Mandatory, see example below.
+
+ <tag><label id="mrt-period">period <m/number/</tag>
+ Specify the time interval (in seconds) between periodic dumps.
+ Mandatory.
+
+ <tag><label id="mrt-always-add-path">always add path <m/switch/</tag>
+ The MRT format uses special records (specified in <rfc id="8050">) for
+ routes received using BGP ADD_PATH extension to keep Path ID, while
+ other routes use regular records. This has advantage of better
+ compatibility with tools that do not know special records, but it loses
+ information about which route is the best route. When this option is
+ enabled, both ADD_PATH and non-ADD_PATH routes are stored in ADD_PATH
+ records and order of routes for network is preserved. Default: disabled.
+</descrip>
+
+<sect1>Example
+<label id="mrt-exam">
+
+<p><code>
+protocol mrt {
+ table "tab*";
+ where source = RTS_BGP;
+ filename "/var/log/bird/%N_%F_%T.mrt";
+ period 300;
}
</code>
definitions of interfaces. Definition of interface may contain many switches and
constant definitions and list of neighbors on nonbroadcast networks.
+<p>OSPFv2 needs one IPv4 channel. OSPFv3 needs either one IPv6 channel, or one
+IPv4 channel (<rfc id="5838">). Therefore, it is possible to use OSPFv3 for both
+IPv4 and Pv6 routing, but it is necessary to have two protocol instances anyway.
+If no channel is configured, appropriate channel is defined with default
+parameters.
+
<code>
protocol ospf [v2|v3] <name> {
rfc1583compat <switch>;
+ rfc5838 <switch>;
instance id <num>;
stub router <switch>;
tick <num>;
This option controls compatibility of routing table calculation with
<rfc id="1583">. Default value is no.
+ <tag><label id="ospf-rfc5838">rfc5838 <m/switch/</tag>
+ Basic OSPFv3 is limited to IPv6 unicast routing. The <rfc id="5838">
+ extension defines support for more address families (IPv4, IPv6, both
+ unicast and multicast). The extension is enabled by default, but can be
+ disabled if necessary, as it restricts the range of available instance
+ IDs. Default value is yes.
+
<tag><label id="ospf-instance-id">instance id <m/num/</tag>
When multiple OSPF protocol instances are active on the same links, they
should use different instance IDs to distinguish their packets. Although
it could be done on per-interface basis, it is often preferred to set
one instance ID to whole OSPF domain/topology (e.g., when multiple
instances are used to represent separate logical topologies on the same
- physical network). This option specifies the default instance ID for all
- interfaces of the OSPF instance. Note that this option, if used, must
- precede interface definitions. Default value is 0.
+ physical network). This option specifies the instance ID for all
+ interfaces of the OSPF instance, but can be overridden by
+ <cf/interface/ option. Default value is 0 unless OSPFv3-AF extended
+ address families are used, see <rfc id="5838"> for that case.
<tag><label id="ospf-stub-router">stub router <M>switch</M></tag>
This option configures the router to be a stub router, i.e., a router
(equal-cost multipath) routes. Such routes are used when there are
several directions to the destination, each with the same (computed)
cost. This option also allows to specify a limit on maximum number of
- nexthops in one route. By default, ECMP is disabled. If enabled,
- default value of the limit is 16.
+ nexthops in one route. By default, ECMP is enabled if supported by
+ Kernel. Default value of the limit is 16.
<tag><label id="ospf-merge-external">merge external <M>switch</M></tag>
This option specifies whether OSPF should merge external routes from
Specifies interval in seconds between retransmissions of unacknowledged
updates. Default value is 5.
+ <tag><label id="ospf-transmit-delay">transmit delay <M>num</M></tag>
+ Specifies estimated transmission delay of link state updates send over
+ the interface. The value is added to LSA age of LSAs propagated through
+ it. Default value is 1.
+
<tag><label id="ospf-priority">priority <M>num</M></tag>
On every multiple access network (e.g., the Ethernet) Designated Router
and Backup Designated router are elected. These routers have some special
<m/dead/ seconds, it will consider the neighbor down. If both directives
<cf/dead count/ and <cf/dead/ are used, <cf/dead/ has precedence.
- <tag><label id="ospf-secondary">secondary <M>switch</M></tag>
- On BSD systems, older versions of BIRD supported OSPFv2 only for the
- primary IP address of an interface, other IP ranges on the interface
- were handled as stub networks. Since v1.4.1, regular operation on
- secondary IP addresses is supported, but disabled by default for
- compatibility. This option allows to enable it. The option is a
- transitional measure, will be removed in the next major release as the
- behavior will be changed. On Linux systems, the option is irrelevant, as
- operation on non-primary addresses is already the regular behavior.
-
<tag><label id="ospf-rx-buffer">rx buffer <M>num</M></tag>
This option allows to specify the size of buffers used for packet
processing. The buffer size should be bigger than maximal size of any
are immediately considered unreachable and only the address of the iface
(instead of whole network prefix) is propagated. It is possible that
some hardware drivers or platforms do not implement this feature.
- Default value is no.
+ Default value is yes.
<tag><label id="ospf-bfd">bfd <M>switch</M></tag>
OSPF could use BFD protocol as an advisory mechanism for neighbor
with internal <cf/metric/, a <cf/metric of type 2/ is always longer than any
<cf/metric of type 1/ or any <cf/internal metric/. <cf/Internal metric/ or
<cf/metric of type 1/ is stored in attribute <cf/ospf_metric1/, <cf/metric type
-2/ is stored in attribute <cf/ospf_metric2/. If you specify both metrics only
-metric1 is used.
+2/ is stored in attribute <cf/ospf_metric2/.
+
+When both metrics are specified then <cf/metric of type 2/ is used. This is
+relevant e.g. when a type 2 external route is propagated from one OSPF domain to
+another and <cf/ospf_metric1/ is an internal distance to the original ASBR,
+while <cf/ospf_metric2/ stores the type 2 metric. Note that in such cases if
+<cf/ospf_metric1/ is non-zero then <cf/ospf_metric2/ is increased by one to
+ensure monotonicity of metric, as internal distance is reset to zero when an
+external route is announced.
<p>Each external route can also carry attribute <cf/ospf_tag/ which is a 32-bit
integer which is used when exporting routes to other protocols; otherwise, it
<p><code>
protocol ospf MyOSPF {
- rfc1583compat yes;
- tick 2;
- export filter {
- if source = RTS_BGP then {
- ospf_metric1 = 100;
- accept;
- }
- reject;
+ ipv4 {
+ export filter {
+ if source = RTS_BGP then {
+ ospf_metric1 = 100;
+ accept;
+ }
+ reject;
+ };
};
area 0.0.0.0 {
interface "eth*" {
}
</code>
+<sect>Perf
+<label id="perf">
+
+<sect1>Introduction
+<label id="perf-intro">
+
+<p>The Perf protocol is a generator of fake routes together with a time measurement
+framework. Its purpose is to check BIRD performance and to benchmark filters.
+
+<p>Import mode of this protocol runs in several steps. In each step, it generates 2^x routes,
+imports them into the appropriate table and withdraws them. The exponent x is configurable.
+It runs the benchmark several times for the same x, then it increases x by one
+until it gets too high, then it stops.
+
+<p>Export mode of this protocol repeats route refresh from table and measures how long it takes.
+
+<p>Output data is logged on info level. There is a Perl script <cf>proto/perf/parse.pl</cf>
+which may be handy to parse the data and draw some plots.
+
+<p>Implementation of this protocol is experimental. Use with caution and do not keep
+any instance of Perf in production configs for long time. The config interface is also unstable
+and may change in future versions without warning.
+
+<sect1>Configuration
+<label id="perf-config">
+
+<p><descrip>
+ <tag><label id="perf-mode">mode import|export</tag>
+ Set perf mode. Default: import
+
+ <tag><label id="perf-repeat">repeat <m/number/</tag>
+ Run this amount of iterations of the benchmark for every amount step. Default: 4
+
+ <tag><label id="perf-from">exp from <m/number/</tag>
+ Begin benchmarking on this exponent for number of generated routes in one step.
+ Default: 10
+
+ <tag><label id="perf-to">exp to <m/number/</tag>
+ Stop benchmarking on this exponent. Default: 20
+
+ <tag><label id="perf-threshold-min">threshold min <m/time/</tag>
+ If a run for the given exponent took less than this time for route import,
+ increase the exponent immediately. Default: 1 ms
+
+ <tag><label id="perf-threshold-max">threshold max <m/time/</tag>
+ If every run for the given exponent took at least this time for route import,
+ stop benchmarking. Default: 500 ms
+</descrip>
<sect>Pipe
<label id="pipe">
connected to using the <cf/table/ configuration keyword) to the secondary one
(declared using <cf/peer table/) and vice versa, depending on what's allowed by
the filters. Export filters control export of routes from the primary table to
-the secondary one, import filters control the opposite direction.
-
-<p>The Pipe protocol may work in the transparent mode mode or in the opaque
-mode. In the transparent mode, the Pipe protocol retransmits all routes from
-one table to the other table, retaining their original source and attributes.
-If import and export filters are set to accept, then both tables would have
-the same content. The transparent mode is the default mode.
+the secondary one, import filters control the opposite direction. Both tables
+must be of the same nettype.
-<p>In the opaque mode, the Pipe protocol retransmits optimal route from one
-table to the other table in a similar way like other protocols send and receive
-routes. Retransmitted route will have the source set to the Pipe protocol, which
-may limit access to protocol specific route attributes. This mode is mainly for
-compatibility, it is not suggested for new configs. The mode can be changed by
-<tt/mode/ option.
+<p>The Pipe protocol retransmits all routes from one table to the other table,
+retaining their original source and attributes. If import and export filters
+are set to accept, then both tables would have the same content.
<p>The primary use of multiple routing tables and the Pipe protocol is for
policy routing, where handling of a single packet doesn't depend only on its
<sect1>Configuration
<label id="pipe-config">
+<p>Essentially, the Pipe protocol is just a channel connected to a table on both
+sides. Therefore, the configuration block for <cf/protocol pipe/ shall directly
+include standard channel config options; see the example below.
+
<p><descrip>
<tag><label id="pipe-peer-table">peer table <m/table/</tag>
Defines secondary routing table to connect to. The primary one is
selected by the <cf/table/ keyword.
-
- <tag><label id="pipe-mode">mode opaque|transparent</tag>
- Specifies the mode for the pipe to work in. Default is transparent.
</descrip>
<sect1>Attributes
to reflect the AS boundary crossing.
<code>
-table as1; # Define the tables
-table as2;
+ipv4 table as1; # Define the tables
+ipv4 table as2;
protocol kernel kern1 { # Synchronize them with the kernel
- table as1;
+ ipv4 { table as1; export all; };
kernel table 1;
}
protocol kernel kern2 {
- table as2;
+ ipv4 { table as2; export all; };
kernel table 2;
}
protocol bgp bgp1 { # The outside connections
- table as1;
+ ipv4 { table as1; import all; export all; };
local as 1;
neighbor 192.168.0.1 as 1001;
- export all;
- import all;
}
protocol bgp bgp2 {
- table as2;
+ ipv4 { table as2; import all; export all; };
local as 2;
neighbor 10.0.0.1 as 1002;
- export all;
- import all;
}
protocol pipe { # The Pipe
networks. These packets contain basic information about a local network (e.g. a
list of network prefixes), which allows network hosts to autoconfigure network
addresses and choose a default route. BIRD implements router behavior as defined
-in <rfc id="4861"> and also the DNS extensions from <rfc id="6106">.
+in <rfc id="4861">, router preferences and specific routes (<rfc id="4191">),
+and DNS extensions (<rfc id="6106">).
+
+<p>The RAdv protocols supports just IPv6 channel.
<sect1>Configuration
<label id="radv-config">
definitions may also be interface-specific when used inside interface
options. By default, interface uses both global and interface-specific
options, but that can be changed by <cf/rdnss local/ option.
-dsc-iface
+
<tag><label id="radv-dnssl">dnssl { <m/options/ }</tag>
DNSSL definitions allow to specify a list of advertised DNS search
domains together with their options. Like <cf/rdnss/ above, multiple
default router. <cf/preferred lifetime/ and <cf/valid lifetime/ could
also be configured as <cf/sensitive/ for a prefix, which would cause
autoconfigured IPs to be deprecated or even removed.
+
+ <tag><label id="radv-propagate-routes">propagate routes <m/switch/</tag>
+ This option controls propagation of more specific routes, as defined in
+ <rfc id="4191">. If enabled, all routes exported to the RAdv protocol,
+ with the exception of the trigger prefix, are added to advertisments as
+ additional options. The lifetime and preference of advertised routes can
+ be set individually by <cf/ra_lifetime/ and <cf/ra_preference/ route
+ attributes, or per interface by <cf/route lifetime/ and
+ <cf/route preference/ options. Default: disabled.
+
+ Note that the RFC discourages from sending more than 17 routes and
+ recommends the routes to be configured manually.
</descrip>
<p>Interface specific options:
hosts. Valid values are 0-255, 0 means unspecified. Default: 64
<tag><label id="radv-iface-default-lifetime">default lifetime <m/expr/ [sensitive <m/switch/]</tag>
- This option specifies the time (in seconds) how long (after the receipt
+ This option specifies the time (in seconds) how long (since the receipt
of RA) hosts may use the router as a default router. 0 means do not use
as a default router. For <cf/sensitive/ option, see <ref id="radv-trigger" name="trigger">.
Default: 3 * <cf/max ra interval/, <cf/sensitive/ yes.
- <tag><label id="radv-iface-default-preference-low">default preference low|medium|high</tag>
+ <tag><label id="radv-iface-default-preference">default preference low|medium|high</tag>
This option specifies the Default Router Preference value to advertise
to hosts. Default: medium.
+ <tag><label id="radv-iface-route-lifetime">route lifetime <m/expr/ [sensitive <m/switch/]</tag>
+ This option specifies the default value of advertised lifetime for
+ specific routes; i.e., the time (in seconds) for how long (since the
+ receipt of RA) hosts should consider these routes valid. A special value
+ 0xffffffff represents infinity. The lifetime can be overriden on a per
+ route basis by the <ref id="rta-ra-lifetime" name="ra_lifetime"> route
+ attribute. Default: 3 * <cf/max ra interval/, <cf/sensitive/ no.
+
+ For the <cf/sensitive/ option, see <ref id="radv-trigger" name="trigger">.
+ If <cf/sensitive/ is enabled, even the routes with the <cf/ra_lifetime/
+ attribute become sensitive to the trigger.
+
+ <tag><label id="radv-iface-route-preference">route preference low|medium|high</tag>
+ This option specifies the default value of advertised route preference
+ for specific routes. The value can be overriden on a per route basis by
+ the <ref id="rta-ra-preference" name="ra_preference"> route attribute.
+ Default: medium.
+
+ <tag><label id="radv-prefix-linger-time">prefix linger time <m/expr/</tag>
+ When a prefix or a route disappears, it is advertised for some time with
+ zero lifetime, to inform clients it is no longer valid. This option
+ specifies the time (in seconds) for how long prefixes are advertised
+ that way. Default: 3 * <cf/max ra interval/.
+
+ <tag><label id="radv-route-linger-time">route linger time <m/expr/</tag>
+ When a prefix or a route disappears, it is advertised for some time with
+ zero lifetime, to inform clients it is no longer valid. This option
+ specifies the time (in seconds) for how long routes are advertised
+ that way. Default: 3 * <cf/max ra interval/.
+
<tag><label id="radv-iface-rdnss-local">rdnss local <m/switch/</tag>
Use only local (interface-specific) RDNSS definitions for this
interface. Otherwise, both global and local definitions are used. Could
option above. Default: no.
</descrip>
-
<p>Prefix specific options
<descrip>
<cf/sensitive/ no.
</descrip>
-
<p>RDNSS specific options:
<descrip>
valid DNS servers. Default: 3 * <cf/max ra interval/.
</descrip>
-
<p>DNSSL specific options:
<descrip>
RDNSS <cf/lifetime/ option above. Default: 3 * <cf/max ra interval/.
</descrip>
+<sect1>Attributes
+<label id="radv-attr">
+
+<p>RAdv defines two route attributes:
+
+<descrip>
+ <tag><label id="rta-ra-preference">enum ra_preference</tag>
+ The preference of the route. The value can be <it/RA_PREF_LOW/,
+ <it/RA_PREF_MEDIUM/ or <it/RA_PREF_HIGH/. If the attribute is not set,
+ the <ref id="radv-iface-route-preference" name="route preference">
+ option is used.
+
+ <tag><label id="rta-ra-lifetime">int ra_lifetime</tag>
+ The advertised lifetime of the route, in seconds. The special value of
+ 0xffffffff represents infinity. If the attribute is not set, the
+ <ref id="radv-iface-route-lifetime" name="route lifetime">
+ option is used.
+</descrip>
<sect1>Example
<label id="radv-exam">
<p><code>
+ipv6 table radv_routes; # Manually configured routes go here
+
+protocol static {
+ ipv6 { table radv_routes; };
+
+ route 2001:0DB8:4000::/48 unreachable;
+ route 2001:0DB8:4010::/48 unreachable;
+
+ route 2001:0DB8:4020::/48 unreachable {
+ ra_preference = RA_PREF_HIGH;
+ ra_lifetime = 3600;
+ };
+}
+
protocol radv {
+ propagate routes yes; # Propagate the routes from the radv_routes table
+ ipv6 { table radv_routes; export all; };
+
interface "eth2" {
max ra interval 5; # Fast failover with more routers
managed yes; # Using DHCPv6 on eth2
protocol instance can be configured by using <cf/rip ng/ instead of just
<cf/rip/ as a protocol type.
+<p>RIP needs one IPv4 channel. RIPng needs one IPv6 channel. If no channel is
+configured, appropriate channel is defined with default parameters.
+
<code>
protocol rip [ng] [<name>] {
infinity <number>;
(equal-cost multipath) routes. Such routes are used when there are
several directions to the destination, each with the same (computed)
cost. This option also allows to specify a limit on maximum number of
- nexthops in one route. By default, ECMP is disabled. If enabled,
- default value of the limit is 16.
+ nexthops in one route. By default, ECMP is enabled if supported by
+ Kernel. Default value of the limit is 16.
<tag><label id="rip-iface">interface <m/pattern/ [, <m/.../] { <m/options/ }</tag>
Interface definitions specify a set of interfaces on which the
unplugged), neighbors are immediately considered unreachable and all
routes received from them are withdrawn. It is possible that some
hardware drivers or platforms do not implement this feature.
- Default: no.
+ Default: yes.
</descrip>
<sect1>Attributes
<p>RIP defines two route attributes:
<descrip>
- <tag>int <cf/rip_metric/</tag>
+ <tag><label id="rta-rip-metric">int rip_metric</tag>
RIP metric of the route (ranging from 0 to <cf/infinity/). When routes
from different RIP instances are available and all of them have the same
preference, BIRD prefers the route with lowest <cf/rip_metric/. When a
non-RIP route is exported to RIP, the default metric is 1.
- <tag><label id="rta-rip-tag">int rip_tag/</tag>
+ <tag><label id="rta-rip-tag">int rip_tag</tag>
RIP route tag: a 16-bit number which can be used to carry additional
information with the route (for example, an originating AS number in
case of external routes). When a non-RIP route is exported to RIP, the
<p><code>
protocol rip {
- debug all;
- port 1520;
- period 12;
- garbage time 60;
- interface "eth0" { metric 3; mode multicast; };
- interface "eth*" { metric 2; mode broadcast; };
- authentication cryptographic;
- password "secret-shared-key" { algorithm hmac sha256; };
- import filter { print "importing"; accept; };
- export filter { print "exporting"; accept; };
+ ipv4 {
+ import all;
+ export all;
+ };
+ interface "eth*" {
+ metric 2;
+ port 1520;
+ mode multicast;
+ update time 12;
+ timeout time 60;
+ authentication cryptographic;
+ password "secret" { algorithm hmac sha256; };
+ };
}
</code>
+
<sect>RPKI
+<label id="rpki">
<sect1>Introduction
<p>The Resource Public Key Infrastructure (RPKI) is mechanism for origin
validation of BGP routes (RFC 6480). BIRD supports only so-called RPKI-based
origin validation. There is implemented RPKI to Router (RPKI-RTR) protocol (RFC
-6810). It uses some of the RPKI data to allow a router to verify that the
+6810). It uses some of the RPKI data to allow a router to verify that the
autonomous system announcing an IP address prefix is in fact authorized to do
so. This is not crypto checked so can be violated. But it should prevent the
vast majority of accidental hijackings on the Internet today, e.g. the famous
routes.
<sect1>Supported transports
+<p>
<itemize>
<item>Unprotected transport over TCP uses a port 323. The cache server
and BIRD router should be on the same trusted and controlled network
}
</code>
-<p>Alse note that you have to specify ROA table into which will be imported
-routes from a cache server. If you want to import only IPv4 prefixes you have
-to specify only roa4 table. Similarly with IPv6 prefixes only. If you want to
-fetch both IPv4 and even IPv6 ROAs you have to specify both types of ROA
-tables.
+<p>Alse note that you have to specify the ROA channel. If you want to import
+only IPv4 prefixes you have to specify only roa4 channel. Similarly with IPv6
+prefixes only. If you want to fetch both IPv4 and even IPv6 ROAs you have to
+specify both channels.
<sect2>RPKI protocol options
-
+<p>
<descrip>
<tag>remote <m/ip/ | "<m/hostname/" [port <m/num/]</tag> Specifies
a destination address of the cache server. Can be specified by an IP
</descrip>
<sect3>SSH transport options
+<p>
<descrip>
<tag>bird private key "<m>/path/to/id_rsa</m>"</tag>
A path to the BIRD's private SSH key for authentication.
protocol rpki {
debug all;
-
+
roa4 { table r4; };
roa6 { table r6; };
# Please, do not use rpki-validator.realmv6.org in production
remote "rpki-validator.realmv6.org" port 8282;
-
+
retry keep 5;
refresh keep 30;
expire 600;
}
-filter peer_in {
- if (roa_check(r4, net, bgp_path.last) = ROA_INVALID ||
- roa_check(r6, net, bgp_path.last) = ROA_INVALID) then
+filter peer_in_v4 {
+ if (roa_check(r4, net, bgp_path.last) = ROA_INVALID) then
{
print "Ignore invalid ROA ", net, " for ASN ", bgp_path.last;
reject;
debug all;
local as 65000;
neighbor 192.168.2.1 as 65001;
- import filter peer_in;
+ ipv4 {
+ import filter peer_in_v4;
+ export none;
+ };
}
</code>
<sect2>SSHv2 transport encryption
+<p>
<code>
roa4 table r4;
roa6 table r6;
protocol rpki {
debug all;
-
+
roa4 { table r4; };
roa6 { table r6; };
-
+
remote 127.0.0.1 port 2345;
transport ssh {
bird private key "/home/birdgeek/.ssh/id_rsa";
remote public key "/home/birdgeek/.ssh/known_hosts";
user "birdgeek";
};
-
+
# Default interval values
}
</code>
-
<sect>Static
<label id="static">
specific destination for them and you don't want to send them out through the
default route to prevent routing loops).
-<p>There are four types of static routes: `classical' routes telling to forward
-packets to a neighboring router (single path or multipath, possibly weighted),
-device routes specifying forwarding to hosts on a directly connected network,
-recursive routes computing their nexthops by doing route table lookups for a
-given IP, and special routes (sink, blackhole etc.) which specify a special
-action to be done instead of forwarding the packet.
-
-<p>When the particular destination is not available (the interface is down or
-the next hop of the route is not a neighbor at the moment), Static just
-uninstalls the route from the table it is connected to and adds it again as soon
-as the destination becomes adjacent again.
-
<p>There are three classes of definitions in Static protocol configuration --
global options, static route definitions, and per-route options. Usually, the
definition of the protocol contains mainly a list of static routes.
+Static routes have no specific attributes.
<p>Global options:
<p>Route definitions (each may also contain a block of per-route options):
-<descrip>
- <tag><label id="static-route-via-ip">route <m/prefix/ via <m/ip/ [mpls <m/num/[/<m/num/[/<m/num/[...]]]]</tag>
- Static single path route through a neighboring router. For link-local next hops,
- interface can be specified as a part of the address (e.g.,
- <cf/via fe80::1234%eth0/). MPLS labels should be specified in outer-first order.
+<sect1>Regular routes; MPLS switching rules
- <tag><label id="static-route-via-mpath">route <m/prefix/ via <m/ip/ [mpls <m/num/[/<m/num/[/<m/num/[...]]]] [weight <m/num/] [bfd <m/switch/] [via ...]</tag>
- Static multipath route. Contains several nexthops (gateways), possibly
- with their weights and MPLS labels.
+<p>There exist several types of routes; keep in mind that <m/prefix/ syntax is
+<ref id="type-prefix" name="dependent on network type">.
- <tag><label id="static-route-via-iface">route <m/prefix/ via <m/"interface"/</tag>
- Static device route through an interface to hosts on a directly
- connected network.
+<descrip>
+ <tag>route <m/prefix/ via <m/ip/|<m/"interface"/ [mpls <m/num/[/<m/num/[/<m/num/[...]]]]</tag>
+ Next hop routes may bear one or more <ref id="route-next-hop" name="next hops">.
+ Every next hop is preceded by <cf/via/ and configured as shown.
- <tag><label id="static-route-recursive">route <m/prefix/ recursive <m/ip/</tag>
- Static recursive route, its nexthop depends on a route table lookup for
- given IP address.
+ <tag>route <m/prefix/ recursive <m/ip/ [mpls <m/num/[/<m/num/[/<m/num/[...]]]]</tag>
+ Recursive nexthop resolves the given IP in the configured IGP table and
+ uses that route's next hop. The MPLS stacks are concatenated; on top is
+ the IGP's nexthop stack and on bottom is this route's stack.
- <tag><label id="static-route-drop">route <m/prefix/ blackhole|unreachable|prohibit</tag>
+ <tag>route <m/prefix/ blackhole|unreachable|prohibit</tag>
Special routes specifying to silently drop the packet, return it as
unreachable or return it as administratively prohibited. First two
targets are also known as <cf/drop/ and <cf/reject/.
</descrip>
-<p>Per-route options:
+<p>When the particular destination is not available (the interface is down or
+the next hop of the route is not a neighbor at the moment), Static just
+uninstalls the route from the table it is connected to and adds it again as soon
+as the destination becomes adjacent again.
+
+<sect1>Route Origin Authorization
+
+<p>The ROA config is just <cf>route <m/prefix/ max <m/int/ as <m/int/</cf> with no nexthop.
+
+<sect1>Flowspec
+<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/.
+
+<sect2>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>). The maximum length of mask is 12 bits
+ (0xfff).
+
+ <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;
+ };
+}
+</code>
+
+<sect2>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 { table myflow6; };
+
+ 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;
+ };
+}
+</code>
+<sect1>Per-route options
+<p>
<descrip>
<tag><label id="static-route-bfd">bfd <m/switch/</tag>
The Static protocol could use BFD protocol for next hop liveness
exported to the OSPF protocol.
</descrip>
-<p>Static routes have no specific attributes.
-
-<p>Example static config might look like this:
+<sect1>Example static config
<p><code>
protocol static {
- table testable; # Connect to a non-default routing table
+ ipv4 { table testable; }; # Connect to a non-default routing table
check link; # Advertise routes only if link is up
route 0.0.0.0/0 via 198.51.100.130; # Default route
- route 10.0.0.0/8 multipath # Multipath route
+ route 10.0.0.0/8 # Multipath route
via 198.51.100.10 weight 2
via 198.51.100.20 bfd # BFD-controlled next hop
via 192.0.2.1;
<itemize>
<item>Opaque LSA's
<item>Route aggregation and flap dampening
-<item>Multipath routes
<item>Multicast routing protocols
<item>Ports to other systems
</itemize>
projects / thirdparty / bird.git / blobdiff