Annotation of embedaddon/bird/doc/bird-3.html, revision 1.1.1.1

1.1       misho       1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
                      2: <HTML>
                      3: <HEAD>
                      4:  <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 1.0.9">
                      5:  <TITLE>BIRD User's Guide: Configuration</TITLE>
                      6:  <LINK HREF="bird-4.html" REL=next>
                      7:  <LINK HREF="bird-2.html" REL=previous>
                      8:  <LINK HREF="bird.html#toc3" REL=contents>
                      9: </HEAD>
                     10: <BODY>
                     11: <A HREF="bird-4.html">Next</A>
                     12: <A HREF="bird-2.html">Previous</A>
                     13: <A HREF="bird.html#toc3">Contents</A>
                     14: <HR>
                     15: <H2><A NAME="config"></A> <A NAME="s3">3.</A> <A HREF="bird.html#toc3">Configuration</A></H2>
                     16: 
                     17: <H2><A NAME="config-intro"></A> <A NAME="ss3.1">3.1</A> <A HREF="bird.html#toc3.1">Introduction</A>
                     18: </H2>
                     19: 
                     20: <P>BIRD is configured using a text configuration file. Upon startup, BIRD reads
                     21: <I>prefix</I><CODE>/etc/bird.conf</CODE> (unless the <CODE>-c</CODE> command line option
                     22: is given). Configuration may be changed at user's request: if you modify the
                     23: config file and then signal BIRD with <CODE>SIGHUP</CODE>, it will adjust to the new
                     24: config. Then there's the client which allows you to talk with BIRD in an
                     25: extensive way.
                     26: <P>
                     27: <P>In the config, everything on a line after <CODE>#</CODE> or inside <CODE>/* */</CODE> is
                     28: a comment, whitespace characters are treated as a single space. If there's a
                     29: variable number of options, they are grouped using the <CODE>{ }</CODE> brackets. Each
                     30: option is terminated by a <CODE>;</CODE>. Configuration is case sensitive. There are two
                     31: ways how to name symbols (like protocol names, filter names, constants etc.). You
                     32: can either use a simple string starting with a letter followed by any
                     33: combination of letters and numbers (e.g. "R123", "myfilter", "bgp5") or you can
                     34: enclose the name into apostrophes (<CODE>'</CODE>) and than you can use any combination
                     35: of numbers, letters. hyphens, dots and colons (e.g. "'1:strange-name'",
                     36: "'-NAME-'", "'cool::name'").
                     37: <P>
                     38: <P>Here is an example of a simple config file. It enables synchronization of
                     39: routing tables with OS kernel, scans for new network interfaces every 10 seconds
                     40: and runs RIP on all network interfaces found.
                     41: <P>
                     42: <HR>
                     43: <PRE>
                     44: protocol kernel {
                     45:         persist;                # Don't remove routes on BIRD shutdown
                     46:         scan time 20;           # Scan kernel routing table every 20 seconds
                     47:         export all;             # Default is export none
                     48: }
                     49: 
                     50: protocol device {
                     51:         scan time 10;           # Scan interfaces every 10 seconds
                     52: }
                     53: 
                     54: protocol rip {
                     55:         export all;
                     56:         import all;
                     57:         interface "*";
                     58: }
                     59: </PRE>
                     60: <HR>
                     61: <P>
                     62: <P>
                     63: <H2><A NAME="global-opts"></A> <A NAME="ss3.2">3.2</A> <A HREF="bird.html#toc3.2">Global options</A>
                     64: </H2>
                     65: 
                     66: <P>
                     67: <DL>
                     68: <DT><CODE>
                     69: <A NAME="opt-include"></A> include "<I>filename</I>"</CODE><DD><P>This statement causes inclusion of a new file. <I>Filename</I> could also
                     70: be a wildcard, in that case matching files are included in alphabetic
                     71: order. The maximal depth is 8. Note that this statement could be used
                     72: anywhere in the config file, not just as a top-level option.
                     73: <P>
                     74: <DT><CODE>
                     75: <A NAME="opt-log"></A> log "<I>filename</I>"|syslog [name <I>name</I>]|stderr all|{ <I>list of classes</I> }</CODE><DD><P>Set logging of messages having the given class (either <CODE>all</CODE> or
                     76: <CODE>{ error|trace [, <I>...</I>] }</CODE> etc.) into selected destination (a file specified
                     77: as a filename string, syslog with optional name argument, or the stderr
                     78: output). Classes are:
                     79: <CODE>info</CODE>, <CODE>warning</CODE>, <CODE>error</CODE> and <CODE>fatal</CODE> for messages about local problems,
                     80: <CODE>debug</CODE> for debugging messages,
                     81: <CODE>trace</CODE> when you want to know what happens in the network,
                     82: <CODE>remote</CODE> for messages about misbehavior of remote machines,
                     83: <CODE>auth</CODE> about authentication failures,
                     84: <CODE>bug</CODE> for internal BIRD bugs.
                     85: You may specify more than one <CODE>log</CODE> line to establish logging to
                     86: multiple destinations. Default: log everything to the system log.
                     87: <P>
                     88: <DT><CODE>
                     89: <A NAME="opt-debug-protocols"></A> debug protocols all|off|{ states|routes|filters|interfaces|events|packets [, <I>...</I>] }</CODE><DD><P>Set global defaults of protocol debugging options. See <CODE>debug</CODE> in the
                     90: following section. Default: off.
                     91: <P>
                     92: <DT><CODE>
                     93: <A NAME="opt-debug-commands"></A> debug commands <I>number</I></CODE><DD><P>Control logging of client connections (0 for no logging, 1 for logging
                     94: of connects and disconnects, 2 and higher for logging of all client
                     95: commands). Default: 0.
                     96: <P>
                     97: <DT><CODE>
                     98: <A NAME="opt-debug-latency"></A> debug latency <I>switch</I></CODE><DD><P>Activate tracking of elapsed time for internal events. Recent events
                     99: could be examined using <CODE>dump events</CODE> command. Default: off.
                    100: <P>
                    101: <DT><CODE>
                    102: <A NAME="opt-debug-latency-limit"></A> debug latency limit <I>time</I></CODE><DD><P>If <CODE>debug latency</CODE> is enabled, this option allows to specify a limit
                    103: for elapsed time. Events exceeding the limit are logged. Default: 1 s.
                    104: <P>
                    105: <DT><CODE>
                    106: <A NAME="opt-watchdog-warn"></A> watchdog warning <I>time</I></CODE><DD><P>Set time limit for I/O loop cycle. If one iteration took more time to
                    107: complete, a warning is logged. Default: 5 s.
                    108: <P>
                    109: <DT><CODE>
                    110: <A NAME="opt-watchdog-timeout"></A> watchdog timeout <I>time</I></CODE><DD><P>Set time limit for I/O loop cycle. If the limit is breached, BIRD is
                    111: killed by abort signal. The timeout has effective granularity of
                    112: seconds, zero means disabled. Default: disabled (0).
                    113: <P>
                    114: <DT><CODE>
                    115: <A NAME="opt-mrtdump"></A> mrtdump "<I>filename</I>"</CODE><DD><P>Set MRTdump file name. This option must be specified to allow MRTdump
                    116: feature. Default: no dump file.
                    117: <P>
                    118: <DT><CODE>
                    119: <A NAME="opt-mrtdump-protocols"></A> mrtdump protocols all|off|{ states|messages [, <I>...</I>] }</CODE><DD><P>Set global defaults of MRTdump options. See <CODE>mrtdump</CODE> in the
                    120: following section. Default: off.
                    121: <P>
                    122: <DT><CODE>
                    123: <A NAME="opt-filter"></A> filter <I>name local variables</I>{ <I>commands</I> }</CODE><DD><P>Define a filter. You can learn more about filters in the following
                    124: chapter.
                    125: <P>
                    126: <DT><CODE>
                    127: <A NAME="opt-function"></A> function <I>name</I> (<I>parameters</I>) <I>local variables</I> { <I>commands</I> }</CODE><DD><P>Define a function. You can learn more about functions in the following chapter.
                    128: <P>
                    129: <DT><CODE>
                    130: <A NAME="opt-protocol"></A> protocol rip|ospf|bgp|<I>...</I> [<I>name</I> [from <I>name2</I>]] { <I>protocol options</I> }</CODE><DD><P>Define a protocol instance called <CODE><I>name</I></CODE> (or with a name like
                    131: "rip5" generated automatically if you don't specify any
                    132: <CODE><I>name</I></CODE>). You can learn more about configuring protocols in
                    133: their own chapters. When <CODE>from <I>name2</I></CODE> expression is used,
                    134: initial protocol options are taken from protocol or template
                    135: <CODE><I>name2</I></CODE> You can run more than one instance of most protocols
                    136: (like RIP or BGP). By default, no instances are configured.
                    137: <P>
                    138: <DT><CODE>
                    139: <A NAME="opt-template"></A> template rip|bgp|<I>...</I> [<I>name</I> [from <I>name2</I>]] { <I>protocol options</I> }</CODE><DD><P>Define a protocol template instance called <I>name</I> (or with a name like
                    140: "bgp1" generated automatically if you don't specify any <I>name</I>).
                    141: Protocol templates can be used to group common options when many
                    142: similarly configured protocol instances are to be defined. Protocol
                    143: instances (and other templates) can use templates by using <CODE>from</CODE>
                    144: expression and the name of the template. At the moment templates (and
                    145: <CODE>from</CODE> expression) are not implemented for OSPF protocol.
                    146: <P>
                    147: <DT><CODE>
                    148: <A NAME="opt-define"></A> define <I>constant</I> = <I>expression</I></CODE><DD><P>Define a constant. You can use it later in every place you could use a
                    149: value of the same type. Besides, there are some predefined numeric
                    150: constants based on /etc/iproute2/rt_* files. A list of defined constants
                    151: can be seen (together with other symbols) using 'show symbols' command.
                    152: <P>
                    153: <DT><CODE>
                    154: <A NAME="opt-router-id"></A> router id <I>IPv4 address</I></CODE><DD><P>Set BIRD's router ID. It's a world-wide unique identification of your
                    155: router, usually one of router's IPv4 addresses. Default: in IPv4
                    156: version, the lowest IP address of a non-loopback interface. In IPv6
                    157: version, this option is mandatory.
                    158: <P>
                    159: <DT><CODE>
                    160: <A NAME="opt-router-id-from"></A> router id from [-] [ "<I>mask</I>" ] [ <I>prefix</I> ] [, <I>...</I>]</CODE><DD><P>Set BIRD's router ID based on an IP address of an interface specified by
                    161: an interface pattern. The option is applicable for IPv4 version only.
                    162: See 
                    163: <A HREF="#proto-iface">interface</A> section for detailed
                    164: description of interface patterns with extended clauses.
                    165: <P>
                    166: <DT><CODE>
                    167: <A NAME="opt-listen-bgp"></A> listen bgp [address <I>address</I>] [port <I>port</I>] [dual]</CODE><DD><P>This option allows to specify address and port where BGP protocol should
                    168: listen. It is global option as listening socket is common to all BGP
                    169: instances. Default is to listen on all addresses (0.0.0.0) and port 179.
                    170: In IPv6 mode, option <CODE>dual</CODE> can be used to specify that BGP socket
                    171: should accept both IPv4 and IPv6 connections (but even in that case,
                    172: BIRD would accept IPv6 routes only). Such behavior was default in older
                    173: versions of BIRD.
                    174: <P>
                    175: <DT><CODE>
                    176: <A NAME="opt-graceful-restart"></A> graceful restart wait <I>number</I></CODE><DD><P>During graceful restart recovery, BIRD waits for convergence of routing
                    177: protocols. This option allows to specify a timeout for the recovery to
                    178: prevent waiting indefinitely if some protocols cannot converge. Default:
                    179: 240 seconds.
                    180: <P>
                    181: <DT><CODE>
                    182: <A NAME="opt-timeformat"></A> timeformat route|protocol|base|log "<I>format1</I>" [<I>limit</I> "<I>format2</I>"]</CODE><DD><P>This option allows to specify a format of date/time used by BIRD. The
                    183: first argument specifies for which purpose such format is used.
                    184: <CODE>route</CODE> is a format used in 'show route' command output,
                    185: <CODE>protocol</CODE> is used in 'show protocols' command output, <CODE>base</CODE> is
                    186: used for other commands and <CODE>log</CODE> is used in a log file.
                    187: <P>"<I>format1</I>" is a format string using <I>strftime(3)</I> notation (see
                    188: <I>man strftime</I> for details). <I>limit> and "<I>format2</I>" allow to
                    189: specify the second format string for times in past deeper than <I>limit</I>
                    190: seconds. There are few shorthands: <CODE>iso long</CODE> is a ISO 8601 date</I>time
                    191: format (YYYY-MM-DD hh:mm:ss) that can be also specified using <CODE>"%F %T"</CODE>.
                    192: <CODE>iso short</CODE> is a variant of ISO 8601 that uses just the time format
                    193: (hh:mm:ss) for near times (up to 20 hours in the past) and the date
                    194: format (YYYY-MM-DD) for far times. This is a shorthand for
                    195: <CODE>"%T" 72000 "%F"</CODE>.
                    196: <P>By default, BIRD uses the <CODE>iso short</CODE> format for <CODE>route</CODE> and
                    197: <CODE>protocol</CODE> times, and the <CODE>iso long</CODE> format for <CODE>base</CODE> and
                    198: <CODE>log</CODE> times.
                    199: <P>In pre-1.4.0 versions, BIRD used an short, ad-hoc format for <CODE>route</CODE>
                    200: and <CODE>protocol</CODE> times, and a <CODE>iso long</CODE> similar format (DD-MM-YYYY
                    201: hh:mm:ss) for <CODE>base</CODE> and <CODE>log</CODE>. These timeformats could be set by
                    202: <CODE>old short</CODE> and <CODE>old long</CODE> compatibility shorthands.
                    203: <P>
                    204: <DT><CODE>
                    205: <A NAME="opt-table"></A> table <I>name</I> [sorted]</CODE><DD><P>Create a new routing table. The default routing table is created
                    206: implicitly, other routing tables have to be added by this command.
                    207: Option <CODE>sorted</CODE> can be used to enable sorting of routes, see
                    208: <A HREF="bird-2.html#dsc-table-sorted">sorted table</A> description for details.
                    209: <P>
                    210: <DT><CODE>
                    211: <A NAME="opt-roa-table"></A> roa table <I>name</I> [ { <I>roa table options ...</I> } ]</CODE><DD><P>Create a new ROA (Route Origin Authorization) table. ROA tables can be
                    212: used to validate route origination of BGP routes. A ROA table contains
                    213: ROA entries, each consist of a network prefix, a max prefix length and
                    214: an AS number. A ROA entry specifies prefixes which could be originated
                    215: by that AS number. ROA tables could be filled with data from RPKI (<A HREF="http://www.rfc-editor.org/info/rfc6480">RFC 6480</A>) or from public databases like Whois. ROA tables are
                    216: examined by <CODE>roa_check()</CODE> operator in filters.
                    217: <P>Currently, there is just one option, <CODE>roa <I>prefix</I> max <I>num</I> as
                    218: <I>num</I></CODE>, which can be used to populate the ROA table with static
                    219: ROA entries. The option may be used multiple times. Other entries can be
                    220: added dynamically by <CODE>add roa</CODE> command.
                    221: <P>
                    222: <DT><CODE>
                    223: <A NAME="opt-eval"></A> eval <I>expr</I></CODE><DD><P>Evaluates given filter expression. It is used by us for   testing of filters.
                    224: </DL>
                    225: <P>
                    226: <P>
                    227: <H2><A NAME="protocol-opts"></A> <A NAME="ss3.3">3.3</A> <A HREF="bird.html#toc3.3">Protocol options</A>
                    228: </H2>
                    229: 
                    230: <P>For each protocol instance, you can configure a bunch of options. Some of
                    231: them (those described in this section) are generic, some are specific to the
                    232: protocol (see sections talking about the protocols).
                    233: <P>
                    234: <P>Several options use a <I>switch</I> argument. It can be either <CODE>on</CODE>,
                    235: <CODE>yes</CODE> or a numeric expression with a non-zero value for the option to be
                    236: enabled or <CODE>off</CODE>, <CODE>no</CODE> or a numeric expression evaluating to zero to
                    237: disable it. An empty <I>switch</I> is equivalent to <CODE>on</CODE> ("silence means
                    238: agreement").
                    239: <P>
                    240: <DL>
                    241: <DT><CODE>
                    242: <A NAME="proto-preference"></A> preference <I>expr</I></CODE><DD><P>Sets the preference of routes generated by this protocol. Default:
                    243: protocol dependent.
                    244: <P>
                    245: <DT><CODE>
                    246: <A NAME="proto-disabled"></A> disabled <I>switch</I></CODE><DD><P>Disables the protocol. You can change the disable/enable status from the
                    247: command line interface without needing to touch the configuration.
                    248: Disabled protocols are not activated. Default: protocol is enabled.
                    249: <P>
                    250: <DT><CODE>
                    251: <A NAME="proto-debug"></A> debug all|off|{ states|routes|filters|interfaces|events|packets [, <I>...</I>] }</CODE><DD><P>Set protocol debugging options. If asked, each protocol is capable of
                    252: writing trace messages about its work to the log (with category
                    253: <CODE>trace</CODE>). You can either request printing of <CODE>all</CODE> trace messages
                    254: or only of the types selected: <CODE>states</CODE> for protocol state changes
                    255: (protocol going up, down, starting, stopping etc.), <CODE>routes</CODE> for
                    256: routes exchanged with the routing table, <CODE>filters</CODE> for details on
                    257: route filtering, <CODE>interfaces</CODE> for interface change events sent to the
                    258: protocol, <CODE>events</CODE> for events internal to the protocol and <CODE>packets</CODE>
                    259: for packets sent and received by the protocol. Default: off.
                    260: <P>
                    261: <DT><CODE>
                    262: <A NAME="proto-mrtdump"></A> mrtdump all|off|{ states|messages [, <I>...</I>] }</CODE><DD><P>Set protocol MRTdump flags. MRTdump is a standard binary format for
                    263: logging information from routing protocols and daemons. These flags
                    264: control what kind of information is logged from the protocol to the
                    265: MRTdump file (which must be specified by global <CODE>mrtdump</CODE> option, see
                    266: the previous section). Although these flags are similar to flags of
                    267: <CODE>debug</CODE> option, their meaning is different and protocol-specific. For
                    268: BGP protocol, <CODE>states</CODE> logs BGP state changes and <CODE>messages</CODE> logs
                    269: received BGP messages. Other protocols does not support MRTdump yet.
                    270: <P>
                    271: <DT><CODE>
                    272: <A NAME="proto-router-id"></A> router id <I>IPv4 address</I></CODE><DD><P>This option can be used to override global router id for a given
                    273: protocol. Default: uses global router id.
                    274: <P>
                    275: <DT><CODE>
                    276: <A NAME="proto-import"></A> import all | none | filter <I>name</I> | filter { <I>filter commands</I> } | where <I>filter expression</I></CODE><DD><P>Specify a filter to be used for filtering routes coming from the
                    277: protocol to the routing table. <CODE>all</CODE> is shorthand for <CODE>where true</CODE>
                    278: and <CODE>none</CODE> is shorthand for <CODE>where false</CODE>. Default: <CODE>all</CODE>.
                    279: <P>
                    280: <DT><CODE>
                    281: <A NAME="proto-export"></A> export <I>filter</I></CODE><DD><P>This is similar to the <CODE>import</CODE> keyword, except that it works in
                    282: the direction from the routing table to the protocol. Default: <CODE>none</CODE>.
                    283: <P>
                    284: <DT><CODE>
                    285: <A NAME="proto-import-keep-filtered"></A> import keep filtered <I>switch</I></CODE><DD><P>Usually, if an import filter rejects a route, the route is forgotten.
                    286: When this option is active, these routes are kept in the routing table,
                    287: but they are hidden and not propagated to other protocols. But it is
                    288: possible to show them using <CODE>show route filtered</CODE>. Note that this
                    289: option does not work for the pipe protocol. Default: off.
                    290: <P>
                    291: <DT><CODE>
                    292: <A NAME="proto-import-limit"></A> import limit [<I>number</I> | off ] [action warn | block | restart | disable]</CODE><DD><P>Specify an import route limit (a maximum number of routes imported from
                    293: the protocol) and optionally the action to be taken when the limit is
                    294: hit. Warn action just prints warning log message. Block action discards
                    295: new routes coming from the protocol. Restart and disable actions shut
                    296: the protocol down like appropriate commands. Disable is the default
                    297: action if an action is not explicitly specified. Note that limits are
                    298: reset during protocol reconfigure, reload or restart. Default: <CODE>off</CODE>.
                    299: <P>
                    300: <DT><CODE>
                    301: <A NAME="proto-receive-limit"></A> receive limit [<I>number</I> | off ] [action warn | block | restart | disable]</CODE><DD><P>Specify an receive route limit (a maximum number of routes received from
                    302: the protocol and remembered). It works almost identically to <CODE>import
                    303: limit</CODE> option, the only difference is that if <CODE>import keep
                    304: filtered</CODE> option is active, filtered routes are counted towards the
                    305: limit and blocked routes are forgotten, as the main purpose of the
                    306: receive limit is to protect routing tables from overflow. Import limit,
                    307: on the contrary, counts accepted routes only and routes blocked by the
                    308: limit are handled like filtered routes. Default: <CODE>off</CODE>.
                    309: <P>
                    310: <DT><CODE>
                    311: <A NAME="proto-export-limit"></A> export limit [ <I>number</I> | off ] [action warn | block | restart | disable]</CODE><DD><P>Specify an export route limit, works similarly to the <CODE>import
                    312: limit</CODE> option, but for the routes exported to the protocol. This
                    313: option is experimental, there are some problems in details of its
                    314: behavior -- the number of exported routes can temporarily exceed the
                    315: limit without triggering it during protocol reload, exported routes
                    316: counter ignores route blocking and block action also blocks route
                    317: updates of already accepted routes -- and these details will probably
                    318: change in the future. Default: <CODE>off</CODE>.
                    319: <P>
                    320: <DT><CODE>
                    321: <A NAME="proto-description"></A> description "<I>text</I>"</CODE><DD><P>This is an optional description of the protocol. It is displayed as a
                    322: part of the output of 'show route all' command.
                    323: <P>
                    324: <DT><CODE>
                    325: <A NAME="proto-table"></A> table <I>name</I></CODE><DD><P>Connect this protocol to a non-default routing table.
                    326: </DL>
                    327: <P>
                    328: <P>There are several options that give sense only with certain protocols:
                    329: <P>
                    330: <DL>
                    331: <DT><CODE>
                    332: <A NAME="proto-iface"></A> interface [-] [ "<I>mask</I>" ] [ <I>prefix</I> ] [, <I>...</I>] [ { <I>option</I>; [<I>...</I>] } ]</CODE><DD><P>Specifies a set of interfaces on which the protocol is activated with
                    333: given interface-specific options. A set of interfaces specified by one
                    334: interface option is described using an interface pattern. The interface
                    335: pattern consists of a sequence of clauses (separated by commas), each
                    336: clause is a mask specified as a shell-like pattern. Interfaces are
                    337: matched by their name.
                    338: <P>An interface matches the pattern if it matches any of its clauses. If
                    339: the clause begins with <CODE>-</CODE>, matching interfaces are excluded. Patterns
                    340: are processed left-to-right, thus <CODE>interface "eth0", -"eth*", "*";</CODE>
                    341: means eth0 and all non-ethernets.
                    342: <P>Some protocols (namely OSPFv2 and Direct) support extended clauses that
                    343: may contain a mask, a prefix, or both of them. An interface matches such
                    344: clause if its name matches the mask (if specified) and its address
                    345: matches the prefix (if specified). Extended clauses are used when the
                    346: protocol handles multiple addresses on an interface independently.
                    347: <P>An interface option can be used more times with different interface-specific
                    348: options, in that case for given interface the first matching interface
                    349: option is used.
                    350: <P>This option is allowed in Babel, BFD, Direct, OSPF, RAdv and RIP
                    351: protocols, but in OSPF protocol it is used in the <CODE>area</CODE> subsection.
                    352: <P>Default: none.
                    353: <P>Examples:
                    354: <P><CODE>interface "*" { type broadcast; };</CODE> - start the protocol on all
                    355: interfaces with <CODE>type broadcast</CODE> option.
                    356: <P><CODE>interface "eth1", "eth4", "eth5" { type ptp; };</CODE> - start the
                    357: protocol on enumerated interfaces with <CODE>type ptp</CODE> option.
                    358: <P><CODE>interface -192.168.1.0/24, 192.168.0.0/16;</CODE> - start the protocol
                    359: on all interfaces that have address from 192.168.0.0/16, but not from
                    360: 192.168.1.0/24.
                    361: <P><CODE>interface -192.168.1.0/24, 192.168.0.0/16;</CODE> - start the protocol
                    362: on all interfaces that have address from 192.168.0.0/16, but not from
                    363: 192.168.1.0/24.
                    364: <P><CODE>interface "eth*" 192.168.1.0/24;</CODE> - start the protocol on all
                    365: ethernet interfaces that have address from 192.168.1.0/24.
                    366: <P>
                    367: <DT><CODE>
                    368: <A NAME="proto-tx-class"></A> tx class|dscp <I>num</I></CODE><DD><P>This option specifies the value of ToS/DS/Class field in IP headers of
                    369: the outgoing protocol packets. This may affect how the protocol packets
                    370: are processed by the network relative to the other network traffic. With
                    371: <CODE>class</CODE> keyword, the value (0-255) is used for the whole ToS/Class
                    372: octet (but two bits reserved for ECN are ignored). With <CODE>dscp</CODE>
                    373: keyword, the value (0-63) is used just for the DS field in the octet.
                    374: Default value is 0xc0 (DSCP 0x30 - CS6).
                    375: <P>
                    376: <DT><CODE>
                    377: <A NAME="proto-tx-priority"></A> tx priority <I>num</I></CODE><DD><P>This option specifies the local packet priority. This may affect how the
                    378: protocol packets are processed in the local TX queues. This option is
                    379: Linux specific. Default value is 7 (highest priority, privileged traffic).
                    380: <P>
                    381: <DT><CODE>
                    382: <A NAME="proto-pass"></A> password "<I>password</I>" [ { <I>password options</I> } ]</CODE><DD><P>Specifies a password that can be used by the protocol as a shared secret
                    383: key. Password option can be used more times to specify more passwords.
                    384: If more passwords are specified, it is a protocol-dependent decision
                    385: which one is really used. Specifying passwords does not mean that
                    386: authentication is enabled, authentication can be enabled by separate,
                    387: protocol-dependent <CODE>authentication</CODE> option.
                    388: <P>This option is allowed in BFD, OSPF and RIP protocols. BGP has also
                    389: <CODE>password</CODE> option, but it is slightly different and described
                    390: separately.
                    391: Default: none.
                    392: </DL>
                    393: <P>
                    394: <P>Password option can contain section with some (not necessary all) password sub-options:
                    395: <P>
                    396: <DL>
                    397: <DT><CODE>
                    398: <A NAME="proto-pass-id"></A> id <I>num</I></CODE><DD><P>ID of the password, (1-255). If it is not used, BIRD will choose ID based
                    399: on an order of the password item in the interface. For example, second
                    400: password item in one interface will have default ID 2. ID is used by
                    401: some routing protocols to identify which password was used to
                    402: authenticate protocol packets.
                    403: <P>
                    404: <DT><CODE>
                    405: <A NAME="proto-pass-gen-from"></A> generate from "<I>time</I>"</CODE><DD><P>The start time of the usage of the password for packet signing.
                    406: The format of <CODE><I>time</I></CODE> is <CODE>dd-mm-yyyy HH:MM:SS</CODE>.
                    407: <P>
                    408: <DT><CODE>
                    409: <A NAME="proto-pass-gen-to"></A> generate to "<I>time</I>"</CODE><DD><P>The last time of the usage of the password for packet signing.
                    410: <P>
                    411: <DT><CODE>
                    412: <A NAME="proto-pass-accept-from"></A> accept from "<I>time</I>"</CODE><DD><P>The start time of the usage of the password for packet verification.
                    413: <P>
                    414: <DT><CODE>
                    415: <A NAME="proto-pass-accept-to"></A> accept to "<I>time</I>"</CODE><DD><P>The last time of the usage of the password for packet verification.
                    416: <P>
                    417: <DT><CODE>
                    418: <A NAME="proto-pass-from"></A> from "<I>time</I>"</CODE><DD><P>Shorthand for setting both <CODE>generate from</CODE> and <CODE>accept from</CODE>.
                    419: <P>
                    420: <DT><CODE>
                    421: <A NAME="proto-pass-to"></A> to "<I>time</I>"</CODE><DD><P>Shorthand for setting both <CODE>generate to</CODE> and <CODE>accept to</CODE>.
                    422: <P>
                    423: <DT><CODE>
                    424: <A NAME="proto-pass-algorithm"></A> algorithm ( keyed md5 | keyed sha1 | hmac sha1 | hmac sha256 | hmac sha384 | hmac sha512 )</CODE><DD><P>The message authentication algorithm for the password when cryptographic
                    425: authentication is enabled. The default value depends on the protocol.
                    426: For RIP and OSPFv2 it is Keyed-MD5 (for compatibility), for OSPFv3
                    427: protocol it is HMAC-SHA-256.
                    428: <P>
                    429: </DL>
                    430: <P>
                    431: <HR>
                    432: <A HREF="bird-4.html">Next</A>
                    433: <A HREF="bird-2.html">Previous</A>
                    434: <A HREF="bird.html#toc3">Contents</A>
                    435: </BODY>
                    436: </HTML>

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>