From 5a203dac615369806dc6eee0418ea39c597bea41 Mon Sep 17 00:00:00 2001 From: Pavel Machek Date: Thu, 8 Jun 2000 10:24:42 +0000 Subject: [PATCH] Docs updates. --- doc/bird.sgml | 309 +++++++++++++++++++++++++++++++------------------- 1 file changed, 194 insertions(+), 115 deletions(-) diff --git a/doc/bird.sgml b/doc/bird.sgml index 9e364f66..5949fea9 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -176,8 +176,6 @@ protocols. Introduction - -

BIRD is configured using a text configuration file. Upon startup, BIRD reads $prefix/bird.conf (unless the - debug protocols all|off|{ states, routes, filters, interfaces, events, packets } - Set global default of protocol debugging options. + Set global defaults of protocol debugging options. See debug commands + Control logging of client connections (0 for no logging, 1 for + logging of connects and disconnects, 2 and higher for logging of + all client commands). Default: 0. filter Define a filter. You can learn more about filters - in the following chapter. + in the following chapter. function Define a function. You can learn more about functions in the following chapter. @@ -240,12 +241,12 @@ protocol rip { protocol rip|ospf|bgp|... protocol options } Define a protocol instance called (or with a name like "rip5" generated automatically, if you don't specify ). You can learn more about configuring protocols in their own chapters. You can run more than one instance of - most protocols (like RIP or BGP). + most protocols (like RIP or BGP). By default, no instances are configured. define Define a constant. You can use it later in every place you could use a simple integer or IP address. - router id Set BIRD's router ID. It's a world-wide unique identification of your router, usually one of router's IPv4 addresses. + router id 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. table Create a new routing table. The default routing table is created implicitly, other routing tables have @@ -257,22 +258,39 @@ protocol rip { Protocol options -

Each routing protocol has its own set of options (see the corresponding sections). These options are common to all protocols: +

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

Several options use a argument. It can be either + is equivalent to - preference Sets the preference of routes generated by this protocol. + preference Sets the preference of routes generated by this protocol. Default: protocol dependent. - disabled Disables the protocol. You can change the disable/enable status from the command - line interface without needing to touch the configuration. Disabled protocol is not activated. + disabled Disables the protocol. You can change the disable/enable status from the command + line interface without needing to touch the configuration. Disabled protocols are not activated. Default: protocol is enabled. - debug Similar to global debug all|off|{ states, routes, filters, interfaces, events, packets } + Set protocol debugging options. If asked, each protocol is capable of + writing trace messages about its work to the log (with category + import { Specify a filter to be used for filtering routes coming from protocol to the routing table. Default: import all | none | filter + Specify a filter to be used for filtering routes coming from protocol to the routing table. export This is similar to import keyword, except that it - works in direction from the routing table to the protocol. Default: table Connect this protocol to a non-default routing table. @@ -283,7 +301,7 @@ protocol rip { passwords { password " Specifies passwords to be used with this protocol. Passive is time from which the password is not used for sending, but it is recognized on reception. is dd-mm-yy HH:MM:SS. + certain protocols. Format of is dd-mm-yyyy HH:MM:SS. interface " Specifies which interfaces this protocol is active on, and allows you to set options on @@ -291,14 +309,14 @@ protocol rip { "*" { mode broadcast; }; will start the protocol on all interfaces with mode broadcast; option. If first character of mask is -Client +Remote control

You can use the command-line client birdc to talk with -a running BIRD. Communication is done using Here is very brief list of supported functions: +

Here is a brief list of supported functions: - dump resources|sockets|interfaces|neighbors|attributs|routes|protocols - Send requested information to a standard logging facility. + dump resources|sockets|interfaces|neighbors|attributes|routes|protocols + Dump contents of internal data structures to the debugging output. - show status|protocols [all]|interfaces [summary]|symbols - Show requested information on client. + show status + Show router status, that is bird version, uptime and time from last reconfiguration. - show route [ - Show contents of the routing table, possibly filtered by the filter. If you put on the line, only routes to given destination are shown. You can also make list more verbose by using show protocols [all] + Show list of protocols along with tables they are connected to and status, possibly giving verbose information. + + show ospf [interface|neighbors] [ + Show detailed information about OSPF protocol, possibly giving a verbose list of interfaces and neighbors. The show static [ + Show detailed information about static routes. The enable|disable|restart - Enable/disable or restart given protocol. + show interfaces [summary] + Show list of interfaces. For each interface, print its type, state, MTU and addresses assigned. + + show symbols + Show list of symbols defined in the configuration (names of protocols, routing tables etc.). + + show route [ + Show contents of a routing table (by default of the main one), + i.e. routes, their metrics and (in case the You can specify a for , you'll get + the entry which will be used for forwarding of packets to the given + destination. By default, all routes for each network are printed with + the selected one at the top, unless You can also ask for printing only routes processed and accepted by + a given filter (filter or filter { or matching a given condition (where ). + The The enable|disable|restart + Enable, disable or restart given protocol instance, instances matching the or configure [" + Reload configuration from a given file. + + debug .mask(num) + is either an IPv4 or IPv6 address. IP addresses are written in the standard notation (.mask(num) on values of type ip. It masks out all but first num bits from ip - address. So + address. So ipaddress/pxlen, or @@ -466,16 +524,15 @@ incompatible with each other (that is to prevent you from shooting in the foot). path ˜ /2 3 5 ?/ syntax). Matching is - done using shell-like patterns: /* which is start of comment.) For example, + path ˜ /2 3 5 ?/ syntax). The masks + resemble wildcard patterns as used by UNIX shells. Autonomous + system numbers match themselves, /* starts a comment). For example: /4 3 2 1/ ~ /? 4 3 ?/ is true, but - /4 3 2 1/ ~ /? 4 5 ?/ is false. + /4 3 2 1/ ~ /? 4 5 ?/ is false. defined( attribute ) operator. Network the route is talking about. Read-only. (See the section about routing tables.) - Address scope of the network ( Preference of the route. (See section about routing tables.) @@ -551,10 +608,10 @@ defined using the defined( attribute ) operator. what protocol has told me about this route. Possible values: - Route type ( - Type of destination the packets should be sent to (

There also exist some protocol-specific attributes, which are described in protocol sections. @@ -583,22 +640,22 @@ defined using the defined( attribute ) operator. BGP

The Border Gateway Protocol is the routing protocol used for backbone -level routing in the today's Internet. Contrary to other protocols, its convergence +level routing in the today's Internet. Contrary to the other protocols, its convergence doesn't rely on all routers following the same rules for route selection, making it possible to implement any routing policy at any router in the network, the only restriction being that if a router advertises a route, it must accept and forward packets according to it.

BGP works in terms of autonomous systems (often abbreviated as AS). Each -AS is a part of the network with common management and common routing policy. -Routers within each AS usually communicate using either a interior routing +AS is a part of the network with common management and common routing policy. It is identified by a unique 16-bit number. +Routers within each AS usually communicate with each other using either a interior routing protocol (such as OSPF or RIP) or an interior variant of BGP (called iBGP). Boundary routers at the border of the AS communicate with their peers in the neighboring AS'es via exterior BGP (eBGP).

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

BIRD supports all requirements of the BGP4 standard as defined in @@ -608,11 +665,11 @@ latest draft, capability negotiation defined in -RFC 2842, +RFC 2842. For IPv6, it uses the standard multiprotocol extensions defined in RFC 2283 including changes described in the -latest draft +latest draft and applied to IPv6 according to RFC 2545. @@ -620,25 +677,25 @@ RFC 2545.

BGP doesn't have any simple metric, so the rules for selection of an optimal route among multiple BGP routes with the same preference are a bit more complex -and are implemented according to the following algorithm. First it uses the first +and they are implemented according to the following algorithm. It starts the first rule, if there are more "best" routes, then it uses the second rule to choose among them and so on. - Prefer route with the highest local preference attribute. + Prefer route with the highest Local Preference attribute. Prefer route with the shortest AS path. Prefer IGP origin over EGP and EGP over incomplete. Prefer the lowest value of the Multiple Exit Discriminator. - Prefer internal routes over external routes. - Prefer route with the lowest value of router ID of the + Prefer internal routes over external ones. + Prefer the route with the lowest value of router ID of the advertising router. Configuration

Each instance of the BGP corresponds to one neighboring router. -This allows to set routing policy and all other parameters differently -for each neighbor using the following protocol parameters: +This allows to set routing policy and all the other parameters differently +for each neighbor using the following configuration parameters: local as Define which AS we are part of. (Note that @@ -646,51 +703,66 @@ for each neighbor using the following protocol parameters: in multiple AS'es simultaneously, but in such cases you need to tweak the BGP paths manually in the filters to get consistent behavior.) This parameter is mandatory. + neighbor Define neighboring router this instance will be talking to and what AS it's located in. Unless you use the multihop Configure multihop BGP to a neighbor which is connected at most next hop self Avoid calculation of the Next Hop attribute and always advertise our own source address (see below) as a next hop. This needs to be used only occasionally to circumvent misconfigurations of other routers. Default: disabled. + source address Define local address we should use for next hop calculation. Default: the address of the local end of the interface our neighbor is connected to. + disable after error When an error is encountered (either locally or by the other side), disable the instance automatically - and wait for an administrator to solve the problem manually. Default: off. - hold time Time in seconds to wait for a keepalive + and wait for an administrator to fix the problem manually. Default: off. + + hold time Time in seconds to wait for a Keepalive message from the other side before considering the connection stale. Default: depends on agreement with the neighboring router, we prefer 240 seconds if the other side is willing to accept it. + startup hold time Value of the hold timer used - before the routers have a chance to exchange OPEN messages and agree + before the routers have a chance to exchange open messages and agree on the real value. Default: 240 seconds. + keepalive time Delay in seconds between sending - of two consecutive keepalive messages. Default: One third of the hold time. + of two consecutive Keepalive messages. Default: One third of the hold time. + connect retry time Time in seconds to wait before - retrying a failed connect attempt. Default: 120 seconds. + retrying a failed attempt to connect. Default: 120 seconds. + start delay time Delay in seconds between protocol - startup and first attempt to connect. Default: 5 seconds. - error wait time Minimum and maximum delay in seconds between protocol - failure (either local or reported by the peer) and automatic startup. + startup and the first attempt to connect. Default: 5 seconds. + + error wait time Minimum and maximum delay in seconds between a protocol + failure (either local or reported by the peer) and automatic restart. Doesn't apply when error forget time Maximum time in seconds between two protocol failures to treat them as a error sequence which makes the path metric Enable comparison of path lengths when deciding which BGP route is the best one. Default: on. + default bgp_med Value of the Multiple Exit Discriminator to be used during route selection when the MED attribute is missing. Default: infinite. + default bgp_local_pref Value of the Local Preference to be used during route selection when the Local Preference attribute is missing. Default: 0. @@ -698,47 +770,53 @@ for each neighbor using the following protocol parameters: Attributes -

BGP defines several route attributes. Some of them (those marked with `I' in the +

BGP defines several route attributes. Some of them (those marked with ` bgppath Sequence of AS numbers describing the AS path - the packet will travel through when forwarded according to this route. On - internal BGP connections it doesn't contain the number of the local AS. + 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. + int 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. + int The Multiple Exit Discriminator of the route is an optional attribute which is often used within the local AS to reflect interior distances to various boundary routers. See the route selection rules above for exact semantics. - enum Origin of the route: either EGP protocol - (nowadays it seems to be obsolete) or enum Origin of the route: either EGP protocol + (nowadays it seems to be obsolete) or ip 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. + void This is an optional attribute - which carries no value, but which sole presence indicates that the route - has been aggregated from multiple routes by some AS on the path from + 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. + clist List of community values associated with the route. Each such value is a pair (represented as a Example @@ -746,14 +824,14 @@ with `O') are optional.

protocol bgp { local as 65000; # Use a private AS number - neighbor 62.168.0.130 as 5588; # Our neighbor - multihop 20 via 62.168.0.13; # Which is connected indirectly + neighbor 62.168.0.130 as 5588; # Our neighbor... + multihop 20 via 62.168.0.13; # ... 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,5678)); # Artificially increase path length - # by prepending local AS number twice + # by advertising local AS number twice if bgp_path ~ / 65000 / then bgp_path.prepend(65000); accept; @@ -761,19 +839,19 @@ protocol bgp { reject; }; import all; - source address 62.168.0.1; # Use non-standard source address + source address 62.168.0.1; # Use a non-standard source address } Device -

The Device protocol is not a real routing protocol as it doesn't generate -any routes and only serves as a module for getting information about network +

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.

Except for very unusual circumstances, you probably should include -this protocol in the configuration since almost all other protocol -require network interfaces to be defined in order to work. +this protocol in the configuration since almost all other protocols +require network interfaces to be defined for them to work with.

The only configurable thing is interface scan time: @@ -781,8 +859,8 @@ require network interfaces to be defined in order to work. scan time Time in seconds between two scans of the network interface list. On systems where we are notified about interface status changes asynchronously (such as newer versions of - Linux), we need to scan the list only to avoid confusion by lost - notifications, so the default time is set to a large value. + Linux), we need to scan the list only in order to avoid confusion by lost + notification messages, so the default time is set to a large value.

As the Device protocol doesn't generate any routes, it cannot have @@ -802,10 +880,10 @@ by the kernel via the Device protocol.

It's highly recommended to include this protocol in your configuration unless you want to use BIRD as a route server or a route reflector, that is -on a machine which doesn't forward packets and only participates in +on a machine which doesn't forward packets itself and only participates in distribution of routing information. -

Only configurable thing about direct is what interfaces it watches: +

The only configurable thing about direct is what interfaces it watches:

interface By default, the Direct @@ -829,17 +907,17 @@ protocol direct { Kernel

The Kernel protocol is not a real routing protocol. Instead of communicating -with other routers in the network, it performs synchronization of BIRD's routing -tables with OS kernel. Basically, it sends all routing table updates to the kernel +the with other routers in the network, it performs synchronization of BIRD's routing +tables with the OS kernel. Basically, it sends all routing table updates to the kernel and from time to time it scans the kernel tables to see whether some routes have disappeared (for example due to unnoticed up/down transition of an interface) or whether an `alien' route has been added by someone else (depending on the -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 -allow policy routing), you can run as many instances as you want, but each of +allow policy routing; such an OS is for example Linux 2.2), you can run as many instances as you want, but each of them must be connected to a different BIRD routing table and to a different kernel table. @@ -848,7 +926,7 @@ kernel table.

persist Tell BIRD to leave all its routes in the routing tables when it exits (instead of cleaning them up). - scan time Time in seconds between two scans of the + scan time Time in seconds between two consecutive scans of the kernel routing table. learn Enable learning of routes added to the kernel routing tables by other routing daemons or by the system administrator. @@ -859,6 +937,7 @@ kernel table. only on systems supporting multiple routing tables. +

The Kernel protocol doesn't define any route attributes.

A simple configuration can look this way:

@@ -886,8 +965,6 @@ protocol kernel { # Secondary routing table } -

The Kernel protocol doesn't define any route attributes. - OSPF Introduction @@ -1025,10 +1102,10 @@ protocol ospf <name> { lacking this password are ignored. This authentication mechanism is very weak. - password text + password "text" An 8-byte password used for authentication. - neighbors + neighbors { A set of neighbors to which Hello messages on nonbroadcast networks are to be sent. @@ -1094,21 +1171,21 @@ protocol ospf MyOSPF { Introduction

The Pipe protocol serves as a link between two routing tables, allowing routes to be -passed from a table declared as primary (i.e., the one the pipe is connected using the +passed from a table declared as primary (i.e., the one the pipe is connected to using the The primary use of multiple routing tables and the pipe protocol is for policy routing, +

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 destination address, but also on its source address, source interface, protocol type and other similar parameters. -In many systems (Linux 2.2 being a good example) the kernel allows to enforce routing policies +In many systems (Linux 2.2 being a good example), the kernel allows to enforce routing policies by defining routing rules which choose one of several routing tables to be used for a packet according to its parameters. Setting of these rules is outside the scope of BIRD's work -(you can use the Configuration @@ -1136,7 +1213,7 @@ and similarly for the second AS. Thus we have split our router to two logical ro each one acting on its own routing table, having its own routing protocols on its own interfaces. In order to use the other AS's routes for backup purposes, we can pass the routes between the tables through a Pipe protocol while decreasing their preferences -and correcting their BGP paths to reflect AS boundary crossing. +and correcting their BGP paths to reflect the AS boundary crossing. table as1; # Define the tables @@ -1222,12 +1299,12 @@ because there are no good implementations of OSPFv3. packets are not authenticated at all, passwords { } - section. + section. Default: none. honor always|neighbor|never specifies when should requests for dumping routing table be honored. (Always, when sent from a host on a directly connected network or never.) Routing table updates are honored only from - neighbors, that is not configurable. + neighbors, that is not configurable. Default: never.

There are two options that can be specified per-interface. First is metric, with @@ -1271,10 +1348,11 @@ other than equally configured BIRD. I have warned you. int RIP metric of the route (ranging from 0 to int 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). + in case of external routes). When importing a non-RIP route, the tag defaults to 0. Example @@ -1360,12 +1438,13 @@ relevant reading; you can get them from +LocalWords: proto wildcard +--> \ No newline at end of file