Annotation of embedaddon/bird/doc/bird-3.html, revision 1.1.1.2
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
1.1.1.2 ! misho 322: part of the output of 'show protocols all' command.
1.1 misho 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.
1.1.1.2 ! misho 326: <P>
! 327: <DT><CODE>
! 328: <A NAME="proto-vrf"></A> vrf "<I>text</I>"|default</CODE><DD><P>Associate the protocol with specific VRF. The protocol will be
! 329: restricted to interfaces assigned to the VRF and will use sockets bound
! 330: to the VRF. A corresponding VRF interface must exist on OS level. For
! 331: kernel protocol, an appropriate table still must be explicitly selected
! 332: by <CODE>table</CODE> option.
! 333: <P>By selecting <CODE>default</CODE>, the protocol is associated with the default
! 334: VRF; i.e., it will be restricted to interfaces not assigned to any
! 335: regular VRF. That is different from not specifying <CODE>vrf</CODE> at all, in
! 336: which case the protocol may use any interface regardless of its VRF
! 337: status.
! 338: <P>Note that for proper VRF support it is necessary to use Linux kernel
! 339: version at least 4.14, older versions have limited VRF implementation.
! 340: Before Linux kernel 5.0, a socket bound to a port in default VRF collide
! 341: with others in regular VRFs.
1.1 misho 342: </DL>
343: <P>
344: <P>There are several options that give sense only with certain protocols:
345: <P>
346: <DL>
347: <DT><CODE>
348: <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
349: given interface-specific options. A set of interfaces specified by one
350: interface option is described using an interface pattern. The interface
351: pattern consists of a sequence of clauses (separated by commas), each
352: clause is a mask specified as a shell-like pattern. Interfaces are
353: matched by their name.
354: <P>An interface matches the pattern if it matches any of its clauses. If
355: the clause begins with <CODE>-</CODE>, matching interfaces are excluded. Patterns
356: are processed left-to-right, thus <CODE>interface "eth0", -"eth*", "*";</CODE>
357: means eth0 and all non-ethernets.
358: <P>Some protocols (namely OSPFv2 and Direct) support extended clauses that
359: may contain a mask, a prefix, or both of them. An interface matches such
360: clause if its name matches the mask (if specified) and its address
361: matches the prefix (if specified). Extended clauses are used when the
362: protocol handles multiple addresses on an interface independently.
363: <P>An interface option can be used more times with different interface-specific
364: options, in that case for given interface the first matching interface
365: option is used.
366: <P>This option is allowed in Babel, BFD, Direct, OSPF, RAdv and RIP
367: protocols, but in OSPF protocol it is used in the <CODE>area</CODE> subsection.
368: <P>Default: none.
369: <P>Examples:
370: <P><CODE>interface "*" { type broadcast; };</CODE> - start the protocol on all
371: interfaces with <CODE>type broadcast</CODE> option.
372: <P><CODE>interface "eth1", "eth4", "eth5" { type ptp; };</CODE> - start the
373: protocol on enumerated interfaces with <CODE>type ptp</CODE> option.
374: <P><CODE>interface -192.168.1.0/24, 192.168.0.0/16;</CODE> - start the protocol
375: on all interfaces that have address from 192.168.0.0/16, but not from
376: 192.168.1.0/24.
377: <P><CODE>interface -192.168.1.0/24, 192.168.0.0/16;</CODE> - start the protocol
378: on all interfaces that have address from 192.168.0.0/16, but not from
379: 192.168.1.0/24.
380: <P><CODE>interface "eth*" 192.168.1.0/24;</CODE> - start the protocol on all
381: ethernet interfaces that have address from 192.168.1.0/24.
382: <P>
383: <DT><CODE>
384: <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
385: the outgoing protocol packets. This may affect how the protocol packets
386: are processed by the network relative to the other network traffic. With
387: <CODE>class</CODE> keyword, the value (0-255) is used for the whole ToS/Class
388: octet (but two bits reserved for ECN are ignored). With <CODE>dscp</CODE>
389: keyword, the value (0-63) is used just for the DS field in the octet.
390: Default value is 0xc0 (DSCP 0x30 - CS6).
391: <P>
392: <DT><CODE>
393: <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
394: protocol packets are processed in the local TX queues. This option is
395: Linux specific. Default value is 7 (highest priority, privileged traffic).
396: <P>
397: <DT><CODE>
398: <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
399: key. Password option can be used more times to specify more passwords.
400: If more passwords are specified, it is a protocol-dependent decision
401: which one is really used. Specifying passwords does not mean that
402: authentication is enabled, authentication can be enabled by separate,
403: protocol-dependent <CODE>authentication</CODE> option.
404: <P>This option is allowed in BFD, OSPF and RIP protocols. BGP has also
405: <CODE>password</CODE> option, but it is slightly different and described
406: separately.
407: Default: none.
408: </DL>
409: <P>
410: <P>Password option can contain section with some (not necessary all) password sub-options:
411: <P>
412: <DL>
413: <DT><CODE>
414: <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
415: on an order of the password item in the interface. For example, second
416: password item in one interface will have default ID 2. ID is used by
417: some routing protocols to identify which password was used to
418: authenticate protocol packets.
419: <P>
420: <DT><CODE>
421: <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.
422: The format of <CODE><I>time</I></CODE> is <CODE>dd-mm-yyyy HH:MM:SS</CODE>.
423: <P>
424: <DT><CODE>
425: <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.
426: <P>
427: <DT><CODE>
428: <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.
429: <P>
430: <DT><CODE>
431: <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.
432: <P>
433: <DT><CODE>
434: <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>.
435: <P>
436: <DT><CODE>
437: <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>.
438: <P>
439: <DT><CODE>
440: <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
441: authentication is enabled. The default value depends on the protocol.
442: For RIP and OSPFv2 it is Keyed-MD5 (for compatibility), for OSPFv3
443: protocol it is HMAC-SHA-256.
444: <P>
445: </DL>
446: <P>
447: <HR>
448: <A HREF="bird-4.html">Next</A>
449: <A HREF="bird-2.html">Previous</A>
450: <A HREF="bird.html#toc3">Contents</A>
451: </BODY>
452: </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