Annotation of embedaddon/bird/doc/bird-3.html, revision 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>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to bird-3.html CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / bird / doc