embedaddon/bird/doc/bird-3.html - view

File: [ELWIX - Embedded LightWeight unIX -] / embedaddon / bird / doc / bird-3.html
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Tue Aug 22 12:33:54 2017 UTC (6 years, 10 months ago) by misho
Branches: bird, MAIN
CVS tags: v1_6_3p0, v1_6_3, HEAD

bird 1.6.3

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: BIRD is configured using a text configuration file. Upon startup, BIRD reads 21: prefix<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:  27: 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:  38: 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:  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:  62:  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:  67: <DL> 68: <DT><CODE> 69: <A NAME="opt-include"></A> include "filename"</CODE><DD>This statement causes inclusion of a new file. Filename 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:  74: <DT><CODE> 75: <A NAME="opt-log"></A> log "filename"|syslog [name name]|stderr all|{ list of classes }</CODE><DD>Set logging of messages having the given class (either <CODE>all</CODE> or 76: <CODE>{ error|trace [, ...] }</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:  88: <DT><CODE> 89: <A NAME="opt-debug-protocols"></A> debug protocols all|off|{ states|routes|filters|interfaces|events|packets [, ...] }</CODE><DD>Set global defaults of protocol debugging options. See <CODE>debug</CODE> in the 90: following section. Default: off. 91:  92: <DT><CODE> 93: <A NAME="opt-debug-commands"></A> debug commands number</CODE><DD>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:  97: <DT><CODE> 98: <A NAME="opt-debug-latency"></A> debug latency switch</CODE><DD>Activate tracking of elapsed time for internal events. Recent events 99: could be examined using <CODE>dump events</CODE> command. Default: off. 100:  101: <DT><CODE> 102: <A NAME="opt-debug-latency-limit"></A> debug latency limit time</CODE><DD>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:  105: <DT><CODE> 106: <A NAME="opt-watchdog-warn"></A> watchdog warning time</CODE><DD>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:  109: <DT><CODE> 110: <A NAME="opt-watchdog-timeout"></A> watchdog timeout time</CODE><DD>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:  114: <DT><CODE> 115: <A NAME="opt-mrtdump"></A> mrtdump "filename"</CODE><DD>Set MRTdump file name. This option must be specified to allow MRTdump 116: feature. Default: no dump file. 117:  118: <DT><CODE> 119: <A NAME="opt-mrtdump-protocols"></A> mrtdump protocols all|off|{ states|messages [, ...] }</CODE><DD>Set global defaults of MRTdump options. See <CODE>mrtdump</CODE> in the 120: following section. Default: off. 121:  122: <DT><CODE> 123: <A NAME="opt-filter"></A> filter name local variables{ commands }</CODE><DD>Define a filter. You can learn more about filters in the following 124: chapter. 125:  126: <DT><CODE> 127: <A NAME="opt-function"></A> function name (parameters) local variables { commands }</CODE><DD>Define a function. You can learn more about functions in the following chapter. 128:  129: <DT><CODE> 130: <A NAME="opt-protocol"></A> protocol rip|ospf|bgp|... [name [from name2]] { protocol options }</CODE><DD>Define a protocol instance called <CODE>name</CODE> (or with a name like 131: "rip5" generated automatically if you don't specify any 132: <CODE>name</CODE>). You can learn more about configuring protocols in 133: their own chapters. When <CODE>from name2</CODE> expression is used, 134: initial protocol options are taken from protocol or template 135: <CODE>name2</CODE> You can run more than one instance of most protocols 136: (like RIP or BGP). By default, no instances are configured. 137:  138: <DT><CODE> 139: <A NAME="opt-template"></A> template rip|bgp|... [name [from name2]] { protocol options }</CODE><DD>Define a protocol template instance called name (or with a name like 140: "bgp1" generated automatically if you don't specify any name). 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:  147: <DT><CODE> 148: <A NAME="opt-define"></A> define constant = expression</CODE><DD>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:  153: <DT><CODE> 154: <A NAME="opt-router-id"></A> router id IPv4 address</CODE><DD>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:  159: <DT><CODE> 160: <A NAME="opt-router-id-from"></A> router id from [-] [ "mask" ] [ prefix ] [, ...]</CODE><DD>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:  166: <DT><CODE> 167: <A NAME="opt-listen-bgp"></A> listen bgp [address address] [port port] [dual]</CODE><DD>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:  175: <DT><CODE> 176: <A NAME="opt-graceful-restart"></A> graceful restart wait number</CODE><DD>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:  181: <DT><CODE> 182: <A NAME="opt-timeformat"></A> timeformat route|protocol|base|log "format1" [limit "format2"]</CODE><DD>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: "format1" is a format string using strftime(3) notation (see 188: man strftime for details). limit> and "format2" allow to 189: specify the second format string for times in past deeper than limit 190: seconds. There are few shorthands: <CODE>iso long</CODE> is a ISO 8601 datetime 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: 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: 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:  204: <DT><CODE> 205: <A NAME="opt-table"></A> table name [sorted]</CODE><DD>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:  210: <DT><CODE> 211: <A NAME="opt-roa-table"></A> roa table name [ { roa table options ... } ]</CODE><DD>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: Currently, there is just one option, <CODE>roa prefix max num as 218: num</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:  222: <DT><CODE> 223: <A NAME="opt-eval"></A> eval expr</CODE><DD>Evaluates given filter expression. It is used by us for testing of filters. 224: </DL> 225:  226:  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: 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:  234: Several options use a switch 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 switch is equivalent to <CODE>on</CODE> ("silence means 238: agreement"). 239:  240: <DL> 241: <DT><CODE> 242: <A NAME="proto-preference"></A> preference expr</CODE><DD>Sets the preference of routes generated by this protocol. Default: 243: protocol dependent. 244:  245: <DT><CODE> 246: <A NAME="proto-disabled"></A> disabled switch</CODE><DD>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:  250: <DT><CODE> 251: <A NAME="proto-debug"></A> debug all|off|{ states|routes|filters|interfaces|events|packets [, ...] }</CODE><DD>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:  261: <DT><CODE> 262: <A NAME="proto-mrtdump"></A> mrtdump all|off|{ states|messages [, ...] }</CODE><DD>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:  271: <DT><CODE> 272: <A NAME="proto-router-id"></A> router id IPv4 address</CODE><DD>This option can be used to override global router id for a given 273: protocol. Default: uses global router id. 274:  275: <DT><CODE> 276: <A NAME="proto-import"></A> import all | none | filter name | filter { filter commands } | where filter expression</CODE><DD>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:  280: <DT><CODE> 281: <A NAME="proto-export"></A> export filter</CODE><DD>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:  284: <DT><CODE> 285: <A NAME="proto-import-keep-filtered"></A> import keep filtered switch</CODE><DD>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:  291: <DT><CODE> 292: <A NAME="proto-import-limit"></A> import limit [number | off ] [action warn | block | restart | disable]</CODE><DD>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:  300: <DT><CODE> 301: <A NAME="proto-receive-limit"></A> receive limit [number | off ] [action warn | block | restart | disable]</CODE><DD>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:  310: <DT><CODE> 311: <A NAME="proto-export-limit"></A> export limit [ number | off ] [action warn | block | restart | disable]</CODE><DD>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:  320: <DT><CODE> 321: <A NAME="proto-description"></A> description "text"</CODE><DD>This is an optional description of the protocol. It is displayed as a 322: part of the output of 'show route all' command. 323:  324: <DT><CODE> 325: <A NAME="proto-table"></A> table name</CODE><DD>Connect this protocol to a non-default routing table. 326: </DL> 327:  328: There are several options that give sense only with certain protocols: 329:  330: <DL> 331: <DT><CODE> 332: <A NAME="proto-iface"></A> interface [-] [ "mask" ] [ prefix ] [, ...] [ { option; [...] } ]</CODE><DD>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: 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: 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: 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: 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: Default: none. 353: Examples: 354: <CODE>interface "*" { type broadcast; };</CODE> - start the protocol on all 355: interfaces with <CODE>type broadcast</CODE> option. 356: <CODE>interface "eth1", "eth4", "eth5" { type ptp; };</CODE> - start the 357: protocol on enumerated interfaces with <CODE>type ptp</CODE> option. 358: <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: <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: <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:  367: <DT><CODE> 368: <A NAME="proto-tx-class"></A> tx class|dscp num</CODE><DD>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:  376: <DT><CODE> 377: <A NAME="proto-tx-priority"></A> tx priority num</CODE><DD>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:  381: <DT><CODE> 382: <A NAME="proto-pass"></A> password "password" [ { password options } ]</CODE><DD>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: 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:  394: Password option can contain section with some (not necessary all) password sub-options: 395:  396: <DL> 397: <DT><CODE> 398: <A NAME="proto-pass-id"></A> id num</CODE><DD>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:  404: <DT><CODE> 405: <A NAME="proto-pass-gen-from"></A> generate from "time"</CODE><DD>The start time of the usage of the password for packet signing. 406: The format of <CODE>time</CODE> is <CODE>dd-mm-yyyy HH:MM:SS</CODE>. 407:  408: <DT><CODE> 409: <A NAME="proto-pass-gen-to"></A> generate to "time"</CODE><DD>The last time of the usage of the password for packet signing. 410:  411: <DT><CODE> 412: <A NAME="proto-pass-accept-from"></A> accept from "time"</CODE><DD>The start time of the usage of the password for packet verification. 413:  414: <DT><CODE> 415: <A NAME="proto-pass-accept-to"></A> accept to "time"</CODE><DD>The last time of the usage of the password for packet verification. 416:  417: <DT><CODE> 418: <A NAME="proto-pass-from"></A> from "time"</CODE><DD>Shorthand for setting both <CODE>generate from</CODE> and <CODE>accept from</CODE>. 419:  420: <DT><CODE> 421: <A NAME="proto-pass-to"></A> to "time"</CODE><DD>Shorthand for setting both <CODE>generate to</CODE> and <CODE>accept to</CODE>. 422:  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>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:  429: </DL> 430:  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>