Annotation of embedaddon/bird/doc/bird-6.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: Protocols</TITLE>
6: <LINK HREF="bird-7.html" REL=next>
7: <LINK HREF="bird-5.html" REL=previous>
8: <LINK HREF="bird.html#toc6" REL=contents>
9: </HEAD>
10: <BODY>
11: <A HREF="bird-7.html">Next</A>
12: <A HREF="bird-5.html">Previous</A>
13: <A HREF="bird.html#toc6">Contents</A>
14: <HR>
15: <H2><A NAME="protocols"></A> <A NAME="s6">6.</A> <A HREF="bird.html#toc6">Protocols</A></H2>
16:
17: <H2><A NAME="babel"></A> <A NAME="ss6.1">6.1</A> <A HREF="bird.html#toc6.1">Babel</A>
18: </H2>
19:
20: <H3><A NAME="babel-intro"></A> Introduction</H3>
21:
22: <P>The Babel protocol
23: (<A HREF="http://www.rfc-editor.org/info/rfc6126">RFC 6126</A>) is a loop-avoiding distance-vector routing protocol that is
24: robust and efficient both in ordinary wired networks and in wireless mesh
25: networks. Babel is conceptually very simple in its operation and "just works"
26: in its default configuration, though some configuration is possible and in some
27: cases desirable.
28: <P>
29: <P>While the Babel protocol is dual stack (i.e., can carry both IPv4 and IPv6
30: routes over the same IPv6 transport), BIRD presently implements only the IPv6
31: subset of the protocol. No Babel extensions are implemented, but the BIRD
32: implementation can coexist with implementations using the extensions (and will
33: just ignore extension messages).
34: <P>
35: <P>The Babel protocol implementation in BIRD is currently in alpha stage.
36: <P>
37: <H3><A NAME="babel-config"></A> Configuration</H3>
38:
39: <P>Babel supports no global configuration options apart from those common to all
40: other protocols, but supports the following per-interface configuration options:
41: <P>
42: <HR>
43: <PRE>
44: protocol babel [<name>] {
45: interface <interface pattern> {
46: type <wired|wireless>;
47: rxcost <number>;
48: hello interval <number>;
49: update interval <number>;
50: port <number>;
51: tx class|dscp <number>;
52: tx priority <number>;
53: rx buffer <number>;
54: tx length <number>;
55: check link <switch>;
56: };
57: }
58: </PRE>
59: <HR>
60: <P>
61: <DL>
62: <DT><CODE>
63: <A NAME="babel-type"></A> type wired|wireless </CODE><DD><P>This option specifies the interface type: Wired or wireless. Wired
64: interfaces are considered more reliable, and so the default hello
65: interval is higher, and a neighbour is considered unreachable after only
66: a small number of "hello" packets are lost. On wireless interfaces,
67: hello packets are sent more often, and the ETX link quality estimation
68: technique is used to compute the metrics of routes discovered over this
69: interface. This technique will gradually degrade the metric of routes
70: when packets are lost rather than the more binary up/down mechanism of
71: wired type links. Default: <CODE>wired</CODE>.
72: <P>
73: <DT><CODE>
74: <A NAME="babel-rxcost"></A> rxcost <I>num</I></CODE><DD><P>This specifies the RX cost of the interface. The route metrics will be
75: computed from this value with a mechanism determined by the interface
76: <CODE>type</CODE>. Default: 96 for wired interfaces, 256 for wireless.
77: <P>
78: <DT><CODE>
79: <A NAME="babel-hello"></A> hello interval <I>num</I></CODE><DD><P>Interval at which periodic "hello" messages are sent on this interface,
80: in seconds. Default: 4 seconds.
81: <P>
82: <DT><CODE>
83: <A NAME="babel-update"></A> update interval <I>num</I></CODE><DD><P>Interval at which periodic (full) updates are sent. Default: 4 times the
84: hello interval.
85: <P>
86: <DT><CODE>
87: <A NAME="babel-port"></A> port <I>number</I></CODE><DD><P>This option selects an UDP port to operate on. The default is to operate
88: on port 6696 as specified in the Babel RFC.
89: <P>
90: <DT><CODE>
91: <A NAME="babel-tx-class"></A> tx class|dscp|priority <I>number</I></CODE><DD><P>These options specify the ToS/DiffServ/Traffic class/Priority of the
92: outgoing Babel packets. See
93: <A HREF="bird-3.html#proto-tx-class">tx class</A> common
94: option for detailed description.
95: <P>
96: <DT><CODE>
97: <A NAME="babel-rx-buffer"></A> rx buffer <I>number</I></CODE><DD><P>This option specifies the size of buffers used for packet processing.
98: The buffer size should be bigger than maximal size of received packets.
99: The default value is the interface MTU, and the value will be clamped to a
100: minimum of 512 bytes + IP packet overhead.
101: <P>
102: <DT><CODE>
103: <A NAME="babel-tx-length"></A> tx length <I>number</I></CODE><DD><P>This option specifies the maximum length of generated Babel packets. To
104: avoid IP fragmentation, it should not exceed the interface MTU value.
105: The default value is the interface MTU value, and the value will be
106: clamped to a minimum of 512 bytes + IP packet overhead.
107: <P>
108: <DT><CODE>
109: <A NAME="babel-check-link"></A> check link <I>switch</I></CODE><DD><P>If set, the hardware link state (as reported by OS) is taken into
110: consideration. When the link disappears (e.g. an ethernet cable is
111: unplugged), neighbors are immediately considered unreachable and all
112: routes received from them are withdrawn. It is possible that some
113: hardware drivers or platforms do not implement this feature. Default:
114: yes.
115: </DL>
116: <P>
117: <H3><A NAME="babel-attr"></A> Attributes</H3>
118:
119: <P>Babel defines just one attribute: the internal babel metric of the route. It
120: is exposed as the <CODE>babel_metric</CODE> attribute and has range from 1 to infinity
121: (65535).
122: <P>
123: <H3><A NAME="babel-exam"></A> Example</H3>
124:
125: <P>
126: <HR>
127: <PRE>
128: protocol babel {
129: interface "eth*" {
130: type wired;
131: };
132: interface "wlan0", "wlan1" {
133: type wireless;
134: hello interval 1;
135: rxcost 512;
136: };
137: interface "tap0";
138:
139: # This matches the default of babeld: redistribute all addresses
140: # configured on local interfaces, plus re-distribute all routes received
141: # from other babel peers.
142:
143: export where (source = RTS_DEVICE) || (source = RTS_BABEL);
144: }
145: </PRE>
146: <HR>
147: <P>
148: <P>
149: <H2><A NAME="bfd"></A> <A NAME="ss6.2">6.2</A> <A HREF="bird.html#toc6.2">BFD</A>
150: </H2>
151:
152: <H3><A NAME="bfd-intro"></A> Introduction</H3>
153:
154: <P>Bidirectional Forwarding Detection (BFD) is not a routing protocol itself, it
155: is an independent tool providing liveness and failure detection. Routing
156: protocols like OSPF and BGP use integrated periodic "hello" messages to monitor
157: liveness of neighbors, but detection times of these mechanisms are high (e.g. 40
158: seconds by default in OSPF, could be set down to several seconds). BFD offers
159: universal, fast and low-overhead mechanism for failure detection, which could be
160: attached to any routing protocol in an advisory role.
161: <P>
162: <P>BFD consists of mostly independent BFD sessions. Each session monitors an
163: unicast bidirectional path between two BFD-enabled routers. This is done by
164: periodically sending control packets in both directions. BFD does not handle
165: neighbor discovery, BFD sessions are created on demand by request of other
166: protocols (like OSPF or BGP), which supply appropriate information like IP
167: addresses and associated interfaces. When a session changes its state, these
168: protocols are notified and act accordingly (e.g. break an OSPF adjacency when
169: the BFD session went down).
170: <P>
171: <P>BIRD implements basic BFD behavior as defined in <A HREF="http://www.rfc-editor.org/info/rfc5880">RFC 5880</A> (some
172: advanced features like the echo mode or authentication are not implemented), IP
173: transport for BFD as defined in <A HREF="http://www.rfc-editor.org/info/rfc5881">RFC 5881</A> and <A HREF="http://www.rfc-editor.org/info/rfc5883">RFC 5883</A> and
174: interaction with client protocols as defined in <A HREF="http://www.rfc-editor.org/info/rfc5882">RFC 5882</A>.
175: <P>
176: <P>Note that BFD implementation in BIRD is currently a new feature in
177: development, expect some rough edges and possible UI and configuration changes
178: in the future. Also note that we currently support at most one protocol instance.
179: <P>
180: <P>BFD packets are sent with a dynamic source port number. Linux systems use by
181: default a bit different dynamic port range than the IANA approved one
182: (49152-65535). If you experience problems with compatibility, please adjust
1.1.1.2 ! misho 183: <CODE>/proc/sys/net/ipv4/ip_local_port_range</CODE>.
1.1 misho 184: <P>
185: <H3><A NAME="bfd-config"></A> Configuration</H3>
186:
187: <P>BFD configuration consists mainly of multiple definitions of interfaces.
188: Most BFD config options are session specific. When a new session is requested
189: and dynamically created, it is configured from one of these definitions. For
190: sessions to directly connected neighbors, <CODE>interface</CODE> definitions are chosen
191: based on the interface associated with the session, while <CODE>multihop</CODE>
192: definition is used for multihop sessions. If no definition is relevant, the
193: session is just created with the default configuration. Therefore, an empty BFD
194: configuration is often sufficient.
195: <P>
196: <P>Note that to use BFD for other protocols like OSPF or BGP, these protocols
197: also have to be configured to request BFD sessions, usually by <CODE>bfd</CODE> option.
198: <P>
1.1.1.2 ! misho 199: <P>A BFD instance not associated with any VRF handles session requests from all
! 200: other protocols, even ones associated with a VRF. Such setup would work for
! 201: single-hop BFD sessions if <CODE>net.ipv4.udp_l3mdev_accept</CODE> sysctl is enabled,
! 202: but does not currently work for multihop sessions. Another approach is to
! 203: configure multiple BFD instances, one for each VRF (including the default VRF).
! 204: Each BFD instance associated with a VRF (regular or default) only handles
! 205: session requests from protocols in the same VRF.
! 206: <P>
1.1 misho 207: <P>Some of BFD session options require <I>time</I> value, which has to be specified
208: with the appropriate unit: <I>num</I> <CODE>s</CODE>|<CODE>ms</CODE>|<CODE>us</CODE>. Although microseconds
209: are allowed as units, practical minimum values are usually in order of tens of
210: milliseconds.
211: <P>
212: <HR>
213: <PRE>
214: protocol bfd [<name>] {
215: interface <interface pattern> {
216: interval <time>;
217: min rx interval <time>;
218: min tx interval <time>;
219: idle tx interval <time>;
220: multiplier <num>;
221: passive <switch>;
222: authentication none;
223: authentication simple;
224: authentication [meticulous] keyed md5|sha1;
225: password "<text>";
226: password "<text>" {
227: id <num>;
228: generate from "<date>";
229: generate to "<date>";
230: accept from "<date>";
231: accept to "<date>";
232: from "<date>";
233: to "<date>";
234: };
235: };
236: multihop {
237: interval <time>;
238: min rx interval <time>;
239: min tx interval <time>;
240: idle tx interval <time>;
241: multiplier <num>;
242: passive <switch>;
243: };
244: neighbor <ip> [dev "<interface>"] [local <ip>] [multihop <switch>];
245: }
246: </PRE>
247: <HR>
248: <P>
249: <DL>
250: <DT><CODE>
251: <A NAME="bfd-iface"></A> interface <I>pattern</I> [, <I>...</I>] { <I>options</I> }</CODE><DD><P>Interface definitions allow to specify options for sessions associated
252: with such interfaces and also may contain interface specific options.
253: See
254: <A HREF="bird-3.html#proto-iface">interface</A> common option for a detailed
255: description of interface patterns. Note that contrary to the behavior of
256: <CODE>interface</CODE> definitions of other protocols, BFD protocol would accept
257: sessions (in default configuration) even on interfaces not covered by
258: such definitions.
259: <P>
260: <DT><CODE>
261: <A NAME="bfd-multihop"></A> multihop { <I>options</I> }</CODE><DD><P>Multihop definitions allow to specify options for multihop BFD sessions,
262: in the same manner as <CODE>interface</CODE> definitions are used for directly
263: connected sessions. Currently only one such definition (for all multihop
264: sessions) could be used.
265: <P>
266: <DT><CODE>
267: <A NAME="bfd-neighbor"></A> neighbor <I>ip</I> [dev "<I>interface</I>"] [local <I>ip</I>] [multihop <I>switch</I>]</CODE><DD><P>BFD sessions are usually created on demand as requested by other
268: protocols (like OSPF or BGP). This option allows to explicitly add
269: a BFD session to the specified neighbor regardless of such requests.
270: <P>The session is identified by the IP address of the neighbor, with
271: optional specification of used interface and local IP. By default
272: the neighbor must be directly connected, unless the session is
273: configured as multihop. Note that local IP must be specified for
274: multihop sessions.
275: </DL>
276: <P>
277: <P>Session specific options (part of <CODE>interface</CODE> and <CODE>multihop</CODE> definitions):
278: <P>
279: <DL>
280: <DT><CODE>
281: <A NAME="bfd-interval"></A> interval <I>time</I></CODE><DD><P>BFD ensures availability of the forwarding path associated with the
282: session by periodically sending BFD control packets in both
283: directions. The rate of such packets is controlled by two options,
284: <CODE>min rx interval</CODE> and <CODE>min tx interval</CODE> (see below). This option
285: is just a shorthand to set both of these options together.
286: <P>
287: <DT><CODE>
288: <A NAME="bfd-min-rx-interval"></A> min rx interval <I>time</I></CODE><DD><P>This option specifies the minimum RX interval, which is announced to the
289: neighbor and used there to limit the neighbor's rate of generated BFD
290: control packets. Default: 10 ms.
291: <P>
292: <DT><CODE>
293: <A NAME="bfd-min-tx-interval"></A> min tx interval <I>time</I></CODE><DD><P>This option specifies the desired TX interval, which controls the rate
294: of generated BFD control packets (together with <CODE>min rx interval</CODE>
295: announced by the neighbor). Note that this value is used only if the BFD
296: session is up, otherwise the value of <CODE>idle tx interval</CODE> is used
297: instead. Default: 100 ms.
298: <P>
299: <DT><CODE>
300: <A NAME="bfd-idle-tx-interval"></A> idle tx interval <I>time</I></CODE><DD><P>In order to limit unnecessary traffic in cases where a neighbor is not
301: available or not running BFD, the rate of generated BFD control packets
302: is lower when the BFD session is not up. This option specifies the
303: desired TX interval in such cases instead of <CODE>min tx interval</CODE>.
304: Default: 1 s.
305: <P>
306: <DT><CODE>
307: <A NAME="bfd-multiplier"></A> multiplier <I>num</I></CODE><DD><P>Failure detection time for BFD sessions is based on established rate of
308: BFD control packets (<CODE>min rx/tx interval</CODE>) multiplied by this
309: multiplier, which is essentially (ignoring jitter) a number of missed
310: packets after which the session is declared down. Note that rates and
311: multipliers could be different in each direction of a BFD session.
312: Default: 5.
313: <P>
314: <DT><CODE>
315: <A NAME="bfd-passive"></A> passive <I>switch</I></CODE><DD><P>Generally, both BFD session endpoints try to establish the session by
316: sending control packets to the other side. This option allows to enable
317: passive mode, which means that the router does not send BFD packets
318: until it has received one from the other side. Default: disabled.
319: <P>
320: <DT><CODE>authentication none</CODE><DD><P>No passwords are sent in BFD packets. This is the default value.
321: <P>
322: <DT><CODE>authentication simple</CODE><DD><P>Every packet carries 16 bytes of password. Received packets lacking this
323: password are ignored. This authentication mechanism is very weak.
324: <P>
325: <DT><CODE>authentication [meticulous] keyed md5|sha1</CODE><DD><P>An authentication code is appended to each packet. The cryptographic
326: algorithm is keyed MD5 or keyed SHA-1. Note that the algorithm is common
327: for all keys (on one interface), in contrast to OSPF or RIP, where it
328: is a per-key option. Passwords (keys) are not sent open via network.
329: <P>The <CODE>meticulous</CODE> variant means that cryptographic sequence numbers
330: are increased for each sent packet, while in the basic variant they are
331: increased about once per second. Generally, the <CODE>meticulous</CODE> variant
332: offers better resistance to replay attacks but may require more
333: computation.
334: <P>
335: <DT><CODE>password "<I>text</I>"</CODE><DD><P>Specifies a password used for authentication. See
1.1.1.2 ! misho 336: <A HREF="bird-3.html#proto-pass">password</A> common option for detailed description. Note that
1.1 misho 337: password option <CODE>algorithm</CODE> is not available in BFD protocol. The
338: algorithm is selected by <CODE>authentication</CODE> option for all passwords.
339: <P>
340: </DL>
341: <P>
342: <H3><A NAME="bfd-exam"></A> Example</H3>
343:
344: <P>
345: <HR>
346: <PRE>
347: protocol bfd {
348: interface "eth*" {
349: min rx interval 20 ms;
350: min tx interval 50 ms;
351: idle tx interval 300 ms;
352: };
353: interface "gre*" {
354: interval 200 ms;
355: multiplier 10;
356: passive;
357: };
358: multihop {
359: interval 200 ms;
360: multiplier 10;
361: };
362:
363: neighbor 192.168.1.10;
364: neighbor 192.168.2.2 dev "eth2";
365: neighbor 192.168.10.1 local 192.168.1.1 multihop;
366: }
367: </PRE>
368: <HR>
369: <P>
370: <P>
371: <H2><A NAME="bgp"></A> <A NAME="ss6.3">6.3</A> <A HREF="bird.html#toc6.3">BGP</A>
372: </H2>
373:
374: <P>The Border Gateway Protocol is the routing protocol used for backbone level
375: routing in the today's Internet. Contrary to other protocols, its convergence
376: does not rely on all routers following the same rules for route selection,
377: making it possible to implement any routing policy at any router in the network,
378: the only restriction being that if a router advertises a route, it must accept
379: and forward packets according to it.
380: <P>
381: <P>BGP works in terms of autonomous systems (often abbreviated as AS). Each AS
382: is a part of the network with common management and common routing policy. It is
383: identified by a unique 16-bit number (ASN). Routers within each AS usually
384: exchange AS-internal routing information with each other using an interior
385: gateway protocol (IGP, such as OSPF or RIP). Boundary routers at the border of
386: the AS communicate global (inter-AS) network reachability information with their
387: neighbors in the neighboring AS'es via exterior BGP (eBGP) and redistribute
388: received information to other routers in the AS via interior BGP (iBGP).
389: <P>
390: <P>Each BGP router sends to its neighbors updates of the parts of its routing
391: table it wishes to export along with complete path information (a list of AS'es
392: the packet will travel through if it uses the particular route) in order to
393: avoid routing loops.
394: <P>
395: <P>BIRD supports all requirements of the BGP4 standard as defined in
396: <A HREF="http://www.rfc-editor.org/info/rfc4271">RFC 4271</A> It also supports the community attributes (<A HREF="http://www.rfc-editor.org/info/rfc1997">RFC 1997</A>),
397: capability negotiation (<A HREF="http://www.rfc-editor.org/info/rfc5492">RFC 5492</A>), MD5 password authentication (<A HREF="http://www.rfc-editor.org/info/rfc2385">RFC 2385</A>), extended communities (<A HREF="http://www.rfc-editor.org/info/rfc4360">RFC 4360</A>), route reflectors (<A HREF="http://www.rfc-editor.org/info/rfc4456">RFC 4456</A>), graceful restart (<A HREF="http://www.rfc-editor.org/info/rfc4724">RFC 4724</A>), multiprotocol extensions
398: (<A HREF="http://www.rfc-editor.org/info/rfc4760">RFC 4760</A>), 4B AS numbers (<A HREF="http://www.rfc-editor.org/info/rfc4893">RFC 4893</A>), and 4B AS numbers in
399: extended communities (<A HREF="http://www.rfc-editor.org/info/rfc5668">RFC 5668</A>).
400: <P>
401: <P>For IPv6, it uses the standard multiprotocol extensions defined in
402: <A HREF="http://www.rfc-editor.org/info/rfc4760">RFC 4760</A> and applied to IPv6 according to <A HREF="http://www.rfc-editor.org/info/rfc2545">RFC 2545</A>.
403: <P>
404: <H3><A NAME="bgp-route-select-rules"></A> Route selection rules</H3>
405:
406: <P>BGP doesn't have any simple metric, so the rules for selection of an optimal
407: route among multiple BGP routes with the same preference are a bit more complex
408: and they are implemented according to the following algorithm. It starts the
409: first rule, if there are more "best" routes, then it uses the second rule to
410: choose among them and so on.
411: <P>
412: <UL>
413: <LI>Prefer route with the highest Local Preference attribute.</LI>
414: <LI>Prefer route with the shortest AS path.</LI>
415: <LI>Prefer IGP origin over EGP and EGP origin over incomplete.</LI>
416: <LI>Prefer the lowest value of the Multiple Exit Discriminator.</LI>
417: <LI>Prefer routes received via eBGP over ones received via iBGP.</LI>
418: <LI>Prefer routes with lower internal distance to a boundary router.</LI>
419: <LI>Prefer the route with the lowest value of router ID of the
420: advertising router.</LI>
421: </UL>
422: <P>
423: <H3><A NAME="bgp-igp-routing-table"></A> IGP routing table</H3>
424:
425: <P>BGP is mainly concerned with global network reachability and with routes to
426: other autonomous systems. When such routes are redistributed to routers in the
427: AS via BGP, they contain IP addresses of a boundary routers (in route attribute
428: NEXT_HOP). BGP depends on existing IGP routing table with AS-internal routes to
429: determine immediate next hops for routes and to know their internal distances to
430: boundary routers for the purpose of BGP route selection. In BIRD, there is
431: usually one routing table used for both IGP routes and BGP routes.
432: <P>
433: <H3><A NAME="bgp-config"></A> Configuration</H3>
434:
435: <P>Each instance of the BGP corresponds to one neighboring router. This allows
436: to set routing policy and all the other parameters differently for each neighbor
437: using the following configuration parameters:
438: <P>
439: <DL>
440: <DT><CODE>
441: <A NAME="bgp-local"></A> local [<I>ip</I>] as <I>number</I></CODE><DD><P>Define which AS we are part of. (Note that contrary to other IP routers,
442: BIRD is able to act as a router located in multiple AS'es simultaneously,
443: but in such cases you need to tweak the BGP paths manually in the filters
444: to get consistent behavior.) Optional <CODE>ip</CODE> argument specifies a source
445: address, equivalent to the <CODE>source address</CODE> option (see below). This
446: parameter is mandatory.
447: <P>
448: <DT><CODE>
449: <A NAME="bgp-neighbor"></A> neighbor [<I>ip</I>] [port <I>number</I>] [as <I>number</I>]</CODE><DD><P>Define neighboring router this instance will be talking to and what AS
450: it is located in. In case the neighbor is in the same AS as we are, we
451: automatically switch to iBGP. Optionally, the remote port may also be
452: specified. The parameter may be used multiple times with different
453: sub-options (e.g., both <CODE>neighbor 10.0.0.1 as 65000;</CODE> and
454: <CODE>neighbor 10.0.0.1; neighbor as 65000;</CODE> are valid). This parameter is
455: mandatory.
456: <P>
457: <DT><CODE>
458: <A NAME="bgp-iface"></A> interface <I>string</I></CODE><DD><P>Define interface we should use for link-local BGP IPv6 sessions.
459: Interface can also be specified as a part of <CODE>neighbor address</CODE>
1.1.1.2 ! misho 460: (e.g., <CODE>neighbor fe80::1234%eth0 as 65000;</CODE>). The option may also be
! 461: used for non link-local sessions when it is necessary to explicitly
! 462: specify an interface, but only for direct (not multihop) sessions.
1.1 misho 463: <P>
464: <DT><CODE>
465: <A NAME="bgp-direct"></A> direct</CODE><DD><P>Specify that the neighbor is directly connected. The IP address of the
466: neighbor must be from a directly reachable IP range (i.e. associated
467: with one of your router's interfaces), otherwise the BGP session
468: wouldn't start but it would wait for such interface to appear. The
469: alternative is the <CODE>multihop</CODE> option. Default: enabled for eBGP.
470: <P>
471: <DT><CODE>
472: <A NAME="bgp-multihop"></A> multihop [<I>number</I>]</CODE><DD><P>Configure multihop BGP session to a neighbor that isn't directly
473: connected. Accurately, this option should be used if the configured
474: neighbor IP address does not match with any local network subnets. Such
475: IP address have to be reachable through system routing table. The
476: alternative is the <CODE>direct</CODE> option. For multihop BGP it is
477: recommended to explicitly configure the source address to have it
478: stable. Optional <CODE>number</CODE> argument can be used to specify the number
479: of hops (used for TTL). Note that the number of networks (edges) in a
480: path is counted; i.e., if two BGP speakers are separated by one router,
481: the number of hops is 2. Default: enabled for iBGP.
482: <P>
483: <DT><CODE>
484: <A NAME="bgp-source-address"></A> source address <I>ip</I></CODE><DD><P>Define local address we should use for next hop calculation and as a
485: source address for the BGP session. Default: the address of the local
486: end of the interface our neighbor is connected to.
487: <P>
488: <DT><CODE>
489: <A NAME="bgp-next-hop-self"></A> next hop self</CODE><DD><P>Avoid calculation of the Next Hop attribute and always advertise our own
490: source address as a next hop. This needs to be used only occasionally to
491: circumvent misconfigurations of other routers. Default: disabled.
492: <P>
493: <DT><CODE>
494: <A NAME="bgp-next-hop-keep"></A> next hop keep</CODE><DD><P>Forward the received Next Hop attribute even in situations where the
495: local address should be used instead, like when the route is sent to an
496: interface with a different subnet. Default: disabled.
497: <P>
498: <DT><CODE>
499: <A NAME="bgp-missing-lladdr"></A> missing lladdr self|drop|ignore</CODE><DD><P>Next Hop attribute in BGP-IPv6 sometimes contains just the global IPv6
500: address, but sometimes it has to contain both global and link-local IPv6
501: addresses. This option specifies what to do if BIRD have to send both
502: addresses but does not know link-local address. This situation might
503: happen when routes from other protocols are exported to BGP, or when
504: improper updates are received from BGP peers. <CODE>self</CODE> means that BIRD
505: advertises its own local address instead. <CODE>drop</CODE> means that BIRD
506: skips that prefixes and logs error. <CODE>ignore</CODE> means that BIRD ignores
507: the problem and sends just the global address (and therefore forms
508: improper BGP update). Default: <CODE>self</CODE>, unless BIRD is configured as a
509: route server (option <CODE>rs client</CODE>), in that case default is <CODE>ignore</CODE>,
510: because route servers usually do not forward packets themselves.
511: <P>
512: <DT><CODE>
513: <A NAME="bgp-gateway"></A> gateway direct|recursive</CODE><DD><P>For received routes, their <CODE>gw</CODE> (immediate next hop) attribute is
514: computed from received <CODE>bgp_next_hop</CODE> attribute. This option
515: specifies how it is computed. Direct mode means that the IP address from
516: <CODE>bgp_next_hop</CODE> is used if it is directly reachable, otherwise the
517: neighbor IP address is used. Recursive mode means that the gateway is
518: computed by an IGP routing table lookup for the IP address from
519: <CODE>bgp_next_hop</CODE>. Note that there is just one level of indirection in
520: recursive mode - the route obtained by the lookup must not be recursive
521: itself, to prevent mutually recursive routes.
522: <P>Recursive mode is the behavior specified by the BGP
523: standard. Direct mode is simpler, does not require any routes in a
524: routing table, and was used in older versions of BIRD, but does not
525: handle well nontrivial iBGP setups and multihop. Recursive mode is
526: incompatible with
527: <A HREF="bird-2.html#dsc-table-sorted">sorted tables</A>. Default:
528: <CODE>direct</CODE> for direct sessions, <CODE>recursive</CODE> for multihop sessions.
529: <P>
530: <DT><CODE>
531: <A NAME="bgp-igp-table"></A> igp table <I>name</I></CODE><DD><P>Specifies a table that is used as an IGP routing table. Default: the
532: same as the table BGP is connected to.
533: <P>
534: <DT><CODE>
535: <A NAME="bgp-check-link"></A> check link <I>switch</I></CODE><DD><P>BGP could use hardware link state into consideration. If enabled,
536: BIRD tracks the link state of the associated interface and when link
537: disappears (e.g. an ethernet cable is unplugged), the BGP session is
538: immediately shut down. Note that this option cannot be used with
539: multihop BGP. Default: disabled.
540: <P>
541: <DT><CODE>
1.1.1.2 ! misho 542: <A NAME="bgp-bfd"></A> bfd <I>switch</I>|graceful</CODE><DD><P>BGP could use BFD protocol as an advisory mechanism for neighbor
1.1 misho 543: liveness and failure detection. If enabled, BIRD setups a BFD session
544: for the BGP neighbor and tracks its liveness by it. This has an
545: advantage of an order of magnitude lower detection times in case of
1.1.1.2 ! misho 546: failure. When a neighbor failure is detected, the BGP session is
! 547: restarted. Optionally, it can be configured (by <CODE>graceful</CODE> argument)
! 548: to trigger graceful restart instead of regular restart. Note that BFD
! 549: protocol also has to be configured, see
! 550: <A HREF="#bfd">BFD</A>
! 551: section for details. Default: disabled.
1.1 misho 552: <P>
553: <DT><CODE>
554: <A NAME="bgp-ttl-security"></A> ttl security <I>switch</I></CODE><DD><P>Use GTSM (<A HREF="http://www.rfc-editor.org/info/rfc5082">RFC 5082</A> - the generalized TTL security mechanism). GTSM
555: protects against spoofed packets by ignoring received packets with a
556: smaller than expected TTL. To work properly, GTSM have to be enabled on
557: both sides of a BGP session. If both <CODE>ttl security</CODE> and
558: <CODE>multihop</CODE> options are enabled, <CODE>multihop</CODE> option should specify
559: proper hop value to compute expected TTL. Kernel support required:
560: Linux: 2.6.34+ (IPv4), 2.6.35+ (IPv6), BSD: since long ago, IPv4 only.
561: Note that full (ICMP protection, for example) <A HREF="http://www.rfc-editor.org/info/rfc5082">RFC 5082</A> support is
562: provided by Linux only. Default: disabled.
563: <P>
564: <DT><CODE>
565: <A NAME="bgp-pass"></A> password <I>string</I></CODE><DD><P>Use this password for MD5 authentication of BGP sessions (<A HREF="http://www.rfc-editor.org/info/rfc2385">RFC 2385</A>). When
566: used on BSD systems, see also <CODE>setkey</CODE> option below. Default: no
567: authentication.
568: <P>
569: <DT><CODE>
570: <A NAME="bgp-setkey"></A> setkey <I>switch</I></CODE><DD><P>On BSD systems, keys for TCP MD5 authentication are stored in the global
571: SA/SP database, which can be accessed by external utilities (e.g.
572: setkey(8)). BIRD configures security associations in the SA/SP database
573: automatically based on <CODE>password</CODE> options (see above), this option
574: allows to disable automatic updates by BIRD when manual configuration by
575: external utilities is preferred. Note that automatic SA/SP database
576: updates are currently implemented only for FreeBSD. Passwords have to be
577: set manually by an external utility on NetBSD and OpenBSD. Default:
578: enabled (ignored on non-FreeBSD).
579: <P>
580: <DT><CODE>
581: <A NAME="bgp-passive"></A> passive <I>switch</I></CODE><DD><P>Standard BGP behavior is both initiating outgoing connections and
582: accepting incoming connections. In passive mode, outgoing connections
583: are not initiated. Default: off.
584: <P>
585: <DT><CODE>
586: <A NAME="bgp-rr-client"></A> rr client</CODE><DD><P>Be a route reflector and treat the neighbor as a route reflection
587: client. Default: disabled.
588: <P>
589: <DT><CODE>
590: <A NAME="bgp-rr-cluster-id"></A> rr cluster id <I>IPv4 address</I></CODE><DD><P>Route reflectors use cluster id to avoid route reflection loops. When
591: there is one route reflector in a cluster it usually uses its router id
592: as a cluster id, but when there are more route reflectors in a cluster,
593: these need to be configured (using this option) to use a common cluster
594: id. Clients in a cluster need not know their cluster id and this option
595: is not allowed for them. Default: the same as router id.
596: <P>
597: <DT><CODE>
598: <A NAME="bgp-rs-client"></A> rs client</CODE><DD><P>Be a route server and treat the neighbor as a route server client.
599: A route server is used as a replacement for full mesh EBGP routing in
600: Internet exchange points in a similar way to route reflectors used in
601: IBGP routing. BIRD does not implement obsoleted <A HREF="http://www.rfc-editor.org/info/rfc1863">RFC 1863</A>, but
602: uses ad-hoc implementation, which behaves like plain EBGP but reduces
603: modifications to advertised route attributes to be transparent (for
604: example does not prepend its AS number to AS PATH attribute and
605: keeps MED attribute). Default: disabled.
606: <P>
607: <DT><CODE>
608: <A NAME="bgp-secondary"></A> secondary <I>switch</I></CODE><DD><P>Usually, if an export filter rejects a selected route, no other route is
609: propagated for that network. This option allows to try the next route in
610: order until one that is accepted is found or all routes for that network
611: are rejected. This can be used for route servers that need to propagate
612: different tables to each client but do not want to have these tables
613: explicitly (to conserve memory). This option requires that the connected
614: routing table is
615: <A HREF="bird-2.html#dsc-table-sorted">sorted</A>. Default: off.
616: <P>
617: <DT><CODE>
618: <A NAME="bgp-add-paths"></A> add paths <I>switch</I>|rx|tx</CODE><DD><P>Standard BGP can propagate only one path (route) per destination network
619: (usually the selected one). This option controls the add-path protocol
620: extension, which allows to advertise any number of paths to a
621: destination. Note that to be active, add-path has to be enabled on both
622: sides of the BGP session, but it could be enabled separately for RX and
623: TX direction. When active, all available routes accepted by the export
624: filter are advertised to the neighbor. Default: off.
625: <P>
626: <DT><CODE>
1.1.1.2 ! misho 627: <A NAME="bgp-allow-local-pref"></A> allow bgp_local_pref <I>switch</I></CODE><DD><P>A standard BGP implementation do not send the Local Preference attribute
! 628: to eBGP neighbors and ignore this attribute if received from eBGP
! 629: neighbors, as per <A HREF="http://www.rfc-editor.org/info/rfc4271">RFC 4271</A>. When this option is enabled on an
! 630: eBGP session, this attribute will be sent to and accepted from the peer,
! 631: which is useful for example if you have a setup like in <A HREF="http://www.rfc-editor.org/info/rfc7938">RFC 7938</A>.
! 632: The option does not affect iBGP sessions. Default: off.
! 633: <P>
! 634: <DT><CODE>
1.1 misho 635: <A NAME="bgp-allow-local-as"></A> allow local as [<I>number</I>]</CODE><DD><P>BGP prevents routing loops by rejecting received routes with the local
636: AS number in the AS path. This option allows to loose or disable the
637: check. Optional <CODE>number</CODE> argument can be used to specify the maximum
638: number of local ASNs in the AS path that is allowed for received
639: routes. When the option is used without the argument, the check is
640: completely disabled and you should ensure loop-free behavior by some
641: other means. Default: 0 (no local AS number allowed).
642: <P>
643: <DT><CODE>
644: <A NAME="bgp-enable-route-refresh"></A> enable route refresh <I>switch</I></CODE><DD><P>After the initial route exchange, BGP protocol uses incremental updates
645: to keep BGP speakers synchronized. Sometimes (e.g., if BGP speaker
646: changes its import filter, or if there is suspicion of inconsistency) it
647: is necessary to do a new complete route exchange. BGP protocol extension
648: Route Refresh (<A HREF="http://www.rfc-editor.org/info/rfc2918">RFC 2918</A>) allows BGP speaker to request
649: re-advertisement of all routes from its neighbor. BGP protocol
650: extension Enhanced Route Refresh (<A HREF="http://www.rfc-editor.org/info/rfc7313">RFC 7313</A>) specifies explicit
651: begin and end for such exchanges, therefore the receiver can remove
652: stale routes that were not advertised during the exchange. This option
653: specifies whether BIRD advertises these capabilities and supports
654: related procedures. Note that even when disabled, BIRD can send route
655: refresh requests. Default: on.
656: <P>
657: <DT><CODE>
658: <A NAME="bgp-graceful-restart"></A> graceful restart <I>switch</I>|aware</CODE><DD><P>When a BGP speaker restarts or crashes, neighbors will discard all
659: received paths from the speaker, which disrupts packet forwarding even
660: when the forwarding plane of the speaker remains intact. <A HREF="http://www.rfc-editor.org/info/rfc4724">RFC 4724</A> specifies an optional graceful restart mechanism to
661: alleviate this issue. This option controls the mechanism. It has three
662: states: Disabled, when no support is provided. Aware, when the graceful
663: restart support is announced and the support for restarting neighbors
664: is provided, but no local graceful restart is allowed (i.e.
665: receiving-only role). Enabled, when the full graceful restart
666: support is provided (i.e. both restarting and receiving role). Note
667: that proper support for local graceful restart requires also
668: configuration of other protocols. Default: aware.
669: <P>
670: <DT><CODE>
671: <A NAME="bgp-graceful-restart-time"></A> graceful restart time <I>number</I></CODE><DD><P>The restart time is announced in the BGP graceful restart capability
672: and specifies how long the neighbor would wait for the BGP session to
673: re-establish after a restart before deleting stale routes. Default:
674: 120 seconds.
675: <P>
676: <DT><CODE>
1.1.1.2 ! misho 677: <A NAME="bgp-long-lived-graceful-restart"></A> long lived graceful restart <I>switch</I>|aware</CODE><DD><P>The long-lived graceful restart is an extension of the traditional
! 678: <A HREF="#bgp-graceful-restart">BGP graceful restart</A>, where stale
! 679: routes are kept even after the
! 680: <A HREF="#bgp-graceful-restart-time">restart time</A> expires for additional long-lived stale time, but
! 681: they are marked with the LLGR_STALE community, depreferenced, and
! 682: withdrawn from routers not supporting LLGR. Like traditional BGP
! 683: graceful restart, it has three states: disabled, aware (receiving-only),
! 684: and enabled. Note that long-lived graceful restart requires at least
! 685: aware level of traditional BGP graceful restart. Default: aware, unless
! 686: graceful restart is disabled.
! 687: <P>
! 688: <DT><CODE>
! 689: <A NAME="bgp-long-lived-stale-time"></A> long lived stale time <I>number</I></CODE><DD><P>The long-lived stale time is announced in the BGP long-lived graceful
! 690: restart capability and specifies how long the neighbor would keep stale
! 691: routes depreferenced during long-lived graceful restart until either the
! 692: session is re-stablished and synchronized or the stale time expires and
! 693: routes are removed. Default: 3600 seconds.
! 694: <P>
! 695: <DT><CODE>
1.1 misho 696: <A NAME="bgp-interpret-communities"></A> interpret communities <I>switch</I></CODE><DD><P><A HREF="http://www.rfc-editor.org/info/rfc1997">RFC 1997</A> demands that BGP speaker should process well-known
697: communities like no-export (65535, 65281) or no-advertise (65535,
698: 65282). For example, received route carrying a no-adverise community
699: should not be advertised to any of its neighbors. If this option is
700: enabled (which is by default), BIRD has such behavior automatically (it
701: is evaluated when a route is exported to the BGP protocol just before
702: the export filter). Otherwise, this integrated processing of
703: well-known communities is disabled. In that case, similar behavior can
704: be implemented in the export filter. Default: on.
705: <P>
706: <DT><CODE>
707: <A NAME="bgp-enable-as4"></A> enable as4 <I>switch</I></CODE><DD><P>BGP protocol was designed to use 2B AS numbers and was extended later to
708: allow 4B AS number. BIRD supports 4B AS extension, but by disabling this
709: option it can be persuaded not to advertise it and to maintain old-style
710: sessions with its neighbors. This might be useful for circumventing bugs
711: in neighbor's implementation of 4B AS extension. Even when disabled
712: (off), BIRD behaves internally as AS4-aware BGP router. Default: on.
713: <P>
714: <DT><CODE>
715: <A NAME="bgp-enable-extended-messages"></A> enable extended messages <I>switch</I></CODE><DD><P>The BGP protocol uses maximum message length of 4096 bytes. This option
716: provides an extension to allow extended messages with length up
717: to 65535 bytes. Default: off.
718: <P>
719: <DT><CODE>
720: <A NAME="bgp-capabilities"></A> capabilities <I>switch</I></CODE><DD><P>Use capability advertisement to advertise optional capabilities. This is
721: standard behavior for newer BGP implementations, but there might be some
722: older BGP implementations that reject such connection attempts. When
723: disabled (off), features that request it (4B AS support) are also
724: disabled. Default: on, with automatic fallback to off when received
725: capability-related error.
726: <P>
727: <DT><CODE>
728: <A NAME="bgp-advertise-ipv4"></A> advertise ipv4 <I>switch</I></CODE><DD><P>Advertise IPv4 multiprotocol capability. This is not a correct behavior
729: according to the strict interpretation of <A HREF="http://www.rfc-editor.org/info/rfc4760">RFC 4760</A>, but it is
730: widespread and required by some BGP implementations (Cisco and Quagga).
731: This option is relevant to IPv4 mode with enabled capability
732: advertisement only. Default: on.
733: <P>
734: <DT><CODE>
735: <A NAME="bgp-route-limit"></A> route limit <I>number</I></CODE><DD><P>The maximal number of routes that may be imported from the protocol. If
736: the route limit is exceeded, the connection is closed with an error.
737: Limit is currently implemented as <CODE>import limit <I>number</I> action
738: restart</CODE>. This option is obsolete and it is replaced by
739: <A HREF="bird-3.html#proto-import-limit">import limit option</A>. Default: no limit.
740: <P>
741: <DT><CODE>
742: <A NAME="bgp-disable-after-error"></A> disable after error <I>switch</I></CODE><DD><P>When an error is encountered (either locally or by the other side),
743: disable the instance automatically and wait for an administrator to fix
744: the problem manually. Default: off.
745: <P>
746: <DT><CODE>
1.1.1.2 ! misho 747: <A NAME="bgp-disable-after-cease"></A> disable after cease <I>switch</I>|<I>set-of-flags</I></CODE><DD><P>When a Cease notification is received, disable the instance
! 748: automatically and wait for an administrator to fix the problem manually.
! 749: When used with <I>switch</I> argument, it means handle every Cease subtype
! 750: with the exception of <CODE>connection collision</CODE>. Default: off.
! 751: <P>The <I>set-of-flags</I> allows to narrow down relevant Cease subtypes. The
! 752: syntax is <CODE>{<I>flag</I> [, <I>...</I>] }</CODE>, where flags are: <CODE>cease</CODE>,
! 753: <CODE>prefix limit hit</CODE>, <CODE>administrative shutdown</CODE>,
! 754: <CODE>peer deconfigured</CODE>, <CODE>administrative reset</CODE>,
! 755: <CODE>connection rejected</CODE>, <CODE>configuration change</CODE>,
! 756: <CODE>connection collision</CODE>, <CODE>out of resources</CODE>.
! 757: <P>
! 758: <DT><CODE>
1.1 misho 759: <A NAME="bgp-hold-time"></A> hold time <I>number</I></CODE><DD><P>Time in seconds to wait for a Keepalive message from the other side
760: before considering the connection stale. Default: depends on agreement
761: with the neighboring router, we prefer 240 seconds if the other side is
762: willing to accept it.
763: <P>
764: <DT><CODE>
765: <A NAME="bgp-startup-hold-time"></A> startup hold time <I>number</I></CODE><DD><P>Value of the hold timer used before the routers have a chance to exchange
766: open messages and agree on the real value. Default: 240 seconds.
767: <P>
768: <DT><CODE>
769: <A NAME="bgp-keepalive-time"></A> keepalive time <I>number</I></CODE><DD><P>Delay in seconds between sending of two consecutive Keepalive messages.
770: Default: One third of the hold time.
771: <P>
772: <DT><CODE>
773: <A NAME="bgp-connect-delay-time"></A> connect delay time <I>number</I></CODE><DD><P>Delay in seconds between protocol startup and the first attempt to
774: connect. Default: 5 seconds.
775: <P>
776: <DT><CODE>
777: <A NAME="bgp-connect-retry-time"></A> connect retry time <I>number</I></CODE><DD><P>Time in seconds to wait before retrying a failed attempt to connect.
778: Default: 120 seconds.
779: <P>
780: <DT><CODE>
781: <A NAME="bgp-error-wait-time"></A> error wait time <I>number</I>,<I>number</I></CODE><DD><P>Minimum and maximum delay in seconds between a protocol failure (either
782: local or reported by the peer) and automatic restart. Doesn't apply
783: when <CODE>disable after error</CODE> is configured. If consecutive errors
784: happen, the delay is increased exponentially until it reaches the
785: maximum. Default: 60, 300.
786: <P>
787: <DT><CODE>
788: <A NAME="bgp-error-forget-time"></A> error forget time <I>number</I></CODE><DD><P>Maximum time in seconds between two protocol failures to treat them as a
789: error sequence which makes <CODE>error wait time</CODE> increase exponentially.
790: Default: 300 seconds.
791: <P>
792: <DT><CODE>
793: <A NAME="bgp-path-metric"></A> path metric <I>switch</I></CODE><DD><P>Enable comparison of path lengths when deciding which BGP route is the
794: best one. Default: on.
795: <P>
796: <DT><CODE>
797: <A NAME="bgp-med-metric"></A> med metric <I>switch</I></CODE><DD><P>Enable comparison of MED attributes (during best route selection) even
798: between routes received from different ASes. This may be useful if all
799: MED attributes contain some consistent metric, perhaps enforced in
800: import filters of AS boundary routers. If this option is disabled, MED
801: attributes are compared only if routes are received from the same AS
802: (which is the standard behavior). Default: off.
803: <P>
804: <DT><CODE>
805: <A NAME="bgp-deterministic-med"></A> deterministic med <I>switch</I></CODE><DD><P>BGP route selection algorithm is often viewed as a comparison between
806: individual routes (e.g. if a new route appears and is better than the
807: current best one, it is chosen as the new best one). But the proper
808: route selection, as specified by <A HREF="http://www.rfc-editor.org/info/rfc4271">RFC 4271</A>, cannot be fully
809: implemented in that way. The problem is mainly in handling the MED
810: attribute. BIRD, by default, uses an simplification based on individual
811: route comparison, which in some cases may lead to temporally dependent
812: behavior (i.e. the selection is dependent on the order in which routes
813: appeared). This option enables a different (and slower) algorithm
814: implementing proper <A HREF="http://www.rfc-editor.org/info/rfc4271">RFC 4271</A> route selection, which is
815: deterministic. Alternative way how to get deterministic behavior is to
816: use <CODE>med metric</CODE> option. This option is incompatible with
817: <A HREF="bird-2.html#dsc-table-sorted">sorted tables</A>. Default: off.
818: <P>
819: <DT><CODE>
820: <A NAME="bgp-igp-metric"></A> igp metric <I>switch</I></CODE><DD><P>Enable comparison of internal distances to boundary routers during best
821: route selection. Default: on.
822: <P>
823: <DT><CODE>
824: <A NAME="bgp-prefer-older"></A> prefer older <I>switch</I></CODE><DD><P>Standard route selection algorithm breaks ties by comparing router IDs.
825: This changes the behavior to prefer older routes (when both are external
826: and from different peer). For details, see <A HREF="http://www.rfc-editor.org/info/rfc5004">RFC 5004</A>. Default: off.
827: <P>
828: <DT><CODE>
829: <A NAME="bgp-default-med"></A> default bgp_med <I>number</I></CODE><DD><P>Value of the Multiple Exit Discriminator to be used during route
830: selection when the MED attribute is missing. Default: 0.
831: <P>
832: <DT><CODE>
833: <A NAME="bgp-default-local-pref"></A> default bgp_local_pref <I>number</I></CODE><DD><P>A default value for the Local Preference attribute. It is used when
834: a new Local Preference attribute is attached to a route by the BGP
835: protocol itself (for example, if a route is received through eBGP and
836: therefore does not have such attribute). Default: 100 (0 in pre-1.2.0
837: versions of BIRD).
838: </DL>
839: <P>
840: <H3><A NAME="bgp-attr"></A> Attributes</H3>
841:
842: <P>BGP defines several route attributes. Some of them (those marked with
843: `<CODE>I</CODE>' in the table below) are available on internal BGP connections only,
844: some of them (marked with `<CODE>O</CODE>') are optional.
845: <P>
846: <DL>
847: <DT><CODE>
1.1.1.2 ! misho 848: <A NAME="rta-bgp-path"></A> bgppath bgp_path</CODE><DD><P>Sequence of AS numbers describing the AS path the packet will travel
1.1 misho 849: through when forwarded according to the particular route. In case of
850: internal BGP it doesn't contain the number of the local AS.
851: <P>
852: <DT><CODE>
1.1.1.2 ! misho 853: <A NAME="rta-bgp-local-pref"></A> int bgp_local_pref [I]</CODE><DD><P>Local preference value used for selection among multiple BGP routes (see
1.1 misho 854: the selection rules above). It's used as an additional metric which is
855: propagated through the whole local AS.
856: <P>
857: <DT><CODE>
1.1.1.2 ! misho 858: <A NAME="rta-bgp-med"></A> int bgp_med [O]</CODE><DD><P>The Multiple Exit Discriminator of the route is an optional attribute
1.1 misho 859: which is used on external (inter-AS) links to convey to an adjacent AS
860: the optimal entry point into the local AS. The received attribute is
861: also propagated over internal BGP links. The attribute value is zeroed
862: when a route is exported to an external BGP instance to ensure that the
863: attribute received from a neighboring AS is not propagated to other
864: neighboring ASes. A new value might be set in the export filter of an
865: external BGP instance. See <A HREF="http://www.rfc-editor.org/info/rfc4451">RFC 4451</A> for further discussion of
866: BGP MED attribute.
867: <P>
868: <DT><CODE>
1.1.1.2 ! misho 869: <A NAME="rta-bgp-origin"></A> enum bgp_origin</CODE><DD><P>Origin of the route: either <CODE>ORIGIN_IGP</CODE> if the route has originated
1.1 misho 870: in an interior routing protocol or <CODE>ORIGIN_EGP</CODE> if it's been imported
871: from the <CODE>EGP</CODE> protocol (nowadays it seems to be obsolete) or
872: <CODE>ORIGIN_INCOMPLETE</CODE> if the origin is unknown.
873: <P>
874: <DT><CODE>
1.1.1.2 ! misho 875: <A NAME="rta-bgp-next-hop"></A> ip bgp_next_hop</CODE><DD><P>Next hop to be used for forwarding of packets to this destination. On
1.1 misho 876: internal BGP connections, it's an address of the originating router if
877: it's inside the local AS or a boundary router the packet will leave the
878: AS through if it's an exterior route, so each BGP speaker within the AS
879: has a chance to use the shortest interior path possible to this point.
880: <P>
881: <DT><CODE>
1.1.1.2 ! misho 882: <A NAME="rta-bgp-atomic-aggr"></A> void bgp_atomic_aggr [O]</CODE><DD><P>This is an optional attribute which carries no value, but the sole
1.1 misho 883: presence of which indicates that the route has been aggregated from
884: multiple routes by some router on the path from the originator.
885: <P>
886: <DT><CODE>
1.1.1.2 ! misho 887: <A NAME="rta-bgp-community"></A> clist bgp_community [O]</CODE><DD><P>List of community values associated with the route. Each such value is a
1.1 misho 888: pair (represented as a <CODE>pair</CODE> data type inside the filters) of 16-bit
889: integers, the first of them containing the number of the AS which
890: defines the community and the second one being a per-AS identifier.
891: There are lots of uses of the community mechanism, but generally they
892: are used to carry policy information like "don't export to USA peers".
893: As each AS can define its own routing policy, it also has a complete
894: freedom about which community attributes it defines and what will their
895: semantics be.
896: <P>
897: <DT><CODE>
1.1.1.2 ! misho 898: <A NAME="rta-bgp-ext-community"></A> eclist bgp_ext_community [O]</CODE><DD><P>List of extended community values associated with the route. Extended
1.1 misho 899: communities have similar usage as plain communities, but they have an
900: extended range (to allow 4B ASNs) and a nontrivial structure with a type
901: field. Individual community values are represented using an <CODE>ec</CODE> data
902: type inside the filters.
903: <P>
904: <DT><CODE>
1.1.1.2 ! misho 905: <A NAME="rta-bgp-large-community"></A> lclist bgp_large_community [O]</CODE><DD><P>List of large community values associated with the route. Large BGP
1.1 misho 906: communities is another variant of communities, but contrary to extended
907: communities they behave very much the same way as regular communities,
908: just larger -- they are uniform untyped triplets of 32bit numbers.
909: Individual community values are represented using an <CODE>lc</CODE> data type
910: inside the filters.
911: <P>
912: <DT><CODE>
1.1.1.2 ! misho 913: <A NAME="rta-bgp-originator-id"></A> quad bgp_originator_id [I, O]</CODE><DD><P>This attribute is created by the route reflector when reflecting the
1.1 misho 914: route and contains the router ID of the originator of the route in the
915: local AS.
916: <P>
917: <DT><CODE>
1.1.1.2 ! misho 918: <A NAME="rta-bgp-cluster-list"></A> clist bgp_cluster_list [I, O]</CODE><DD><P>This attribute contains a list of cluster IDs of route reflectors. Each
1.1 misho 919: route reflector prepends its cluster ID when reflecting the route.
920: </DL>
921: <P>
922: <H3><A NAME="bgp-exam"></A> Example</H3>
923:
924: <P>
925: <HR>
926: <PRE>
927: protocol bgp {
928: local as 65000; # Use a private AS number
929: neighbor 198.51.100.130 as 64496; # Our neighbor ...
930: multihop; # ... which is connected indirectly
931: export filter { # We use non-trivial export rules
932: if source = RTS_STATIC then { # Export only static routes
933: # Assign our community
934: bgp_community.add((65000,64501));
935: # Artificially increase path length
936: # by advertising local AS number twice
937: if bgp_path ~ [= 65000 =] then
938: bgp_path.prepend(65000);
939: accept;
940: }
941: reject;
942: };
943: import all;
944: source address 198.51.100.14; # Use a non-standard source address
945: }
946: </PRE>
947: <HR>
948: <P>
949: <P>
950: <H2><A NAME="device"></A> <A NAME="ss6.4">6.4</A> <A HREF="bird.html#toc6.4">Device</A>
951: </H2>
952:
953: <P>The Device protocol is not a real routing protocol. It doesn't generate any
954: routes and it only serves as a module for getting information about network
955: interfaces from the kernel.
956: <P>
957: <P>Except for very unusual circumstances, you probably should include this
958: protocol in the configuration since almost all other protocols require network
959: interfaces to be defined for them to work with.
960: <P>
961: <H3><A NAME="device-config"></A> Configuration</H3>
962:
963: <P>
964: <DL>
965: <P>
966: <DT><CODE>
967: <A NAME="device-scan-time"></A> scan time <I>number</I></CODE><DD><P>Time in seconds between two scans of the network interface list. On
968: systems where we are notified about interface status changes
969: asynchronously (such as newer versions of Linux), we need to scan the
970: list only in order to avoid confusion by lost notification messages,
971: so the default time is set to a large value.
972: <P>
973: <DT><CODE>
974: <A NAME="device-primary"></A> primary [ "<I>mask</I>" ] <I>prefix</I></CODE><DD><P>If a network interface has more than one network address, BIRD has to
975: choose one of them as a primary one. By default, BIRD chooses the
976: lexicographically smallest address as the primary one.
977: <P>This option allows to specify which network address should be chosen as
978: a primary one. Network addresses that match <I>prefix</I> are preferred to
979: non-matching addresses. If more <CODE>primary</CODE> options are used, the first
980: one has the highest preference. If "<I>mask</I>" is specified, then such
981: <CODE>primary</CODE> option is relevant only to matching network interfaces.
982: <P>In all cases, an address marked by operating system as secondary cannot
983: be chosen as the primary one.
984: </DL>
985: <P>
986: <P>As the Device protocol doesn't generate any routes, it cannot have
987: any attributes. Example configuration looks like this:
988: <P>
989: <P>
990: <HR>
991: <PRE>
992: protocol device {
993: scan time 10; # Scan the interfaces often
994: primary "eth0" 192.168.1.1;
995: primary 192.168.0.0/16;
996: }
997: </PRE>
998: <HR>
999: <P>
1000: <P>
1001: <H2><A NAME="direct"></A> <A NAME="ss6.5">6.5</A> <A HREF="bird.html#toc6.5">Direct</A>
1002: </H2>
1003:
1004: <P>The Direct protocol is a simple generator of device routes for all the
1005: directly connected networks according to the list of interfaces provided by the
1006: kernel via the Device protocol.
1007: <P>
1008: <P>The question is whether it is a good idea to have such device routes in BIRD
1009: routing table. OS kernel usually handles device routes for directly connected
1010: networks by itself so we don't need (and don't want) to export these routes to
1011: the kernel protocol. OSPF protocol creates device routes for its interfaces
1012: itself and BGP protocol is usually used for exporting aggregate routes. Although
1013: there are some use cases that use the direct protocol (like abusing eBGP as an
1014: IGP routing protocol), in most cases it is not needed to have these device
1015: routes in BIRD routing table and to use the direct protocol.
1016: <P>
1017: <P>There is one notable case when you definitely want to use the direct protocol
1018: -- running BIRD on BSD systems. Having high priority device routes for directly
1019: connected networks from the direct protocol protects kernel device routes from
1020: being overwritten or removed by IGP routes during some transient network
1021: conditions, because a lower priority IGP route for the same network is not
1022: exported to the kernel routing table. This is an issue on BSD systems only, as
1023: on Linux systems BIRD cannot change non-BIRD route in the kernel routing table.
1024: <P>
1025: <P>There are just few configuration options for the Direct protocol:
1026: <P>
1027: <P>
1028: <DL>
1029: <DT><CODE>
1030: <A NAME="direct-iface"></A> interface <I>pattern</I> [, <I>...</I>]</CODE><DD><P>By default, the Direct protocol will generate device routes for all the
1031: interfaces available. If you want to restrict it to some subset of
1032: interfaces or addresses (e.g. if you're using multiple routing tables
1033: for policy routing and some of the policy domains don't contain all
1034: interfaces), just use this clause. See
1035: <A HREF="bird-3.html#proto-iface">interface</A>
1036: common option for detailed description. The Direct protocol uses
1037: extended interface clauses.
1038: <P>
1039: <DT><CODE>
1040: <A NAME="direct-check-link"></A> check link <I>switch</I></CODE><DD><P>If enabled, a hardware link state (reported by OS) is taken into
1041: consideration. Routes for directly connected networks are generated only
1042: if link up is reported and they are withdrawn when link disappears
1043: (e.g., an ethernet cable is unplugged). Default value is no.
1044: </DL>
1045: <P>
1046: <P>Direct device routes don't contain any specific attributes.
1047: <P>
1048: <P>Example config might look like this:
1049: <P>
1050: <P>
1051: <HR>
1052: <PRE>
1053: protocol direct {
1054: interface "-arc*", "*"; # Exclude the ARCnets
1055: }
1056: </PRE>
1057: <HR>
1058: <P>
1059: <P>
1060: <H2><A NAME="krt"></A> <A NAME="ss6.6">6.6</A> <A HREF="bird.html#toc6.6">Kernel</A>
1061: </H2>
1062:
1063: <P>The Kernel protocol is not a real routing protocol. Instead of communicating
1064: with other routers in the network, it performs synchronization of BIRD's routing
1065: tables with the OS kernel. Basically, it sends all routing table updates to the
1066: kernel and from time to time it scans the kernel tables to see whether some
1067: routes have disappeared (for example due to unnoticed up/down transition of an
1068: interface) or whether an `alien' route has been added by someone else (depending
1069: on the <CODE>learn</CODE> switch, such routes are either ignored or accepted to our
1070: table).
1071: <P>
1072: <P>Unfortunately, there is one thing that makes the routing table synchronization
1073: a bit more complicated. In the kernel routing table there are also device routes
1074: for directly connected networks. These routes are usually managed by OS itself
1075: (as a part of IP address configuration) and we don't want to touch that. They
1076: are completely ignored during the scan of the kernel tables and also the export
1077: of device routes from BIRD tables to kernel routing tables is restricted to
1078: prevent accidental interference. This restriction can be disabled using
1079: <CODE>device routes</CODE> switch.
1080: <P>
1081: <P>If your OS supports only a single routing table, you can configure only one
1082: instance of the Kernel protocol. If it supports multiple tables (in order to
1083: allow policy routing; such an OS is for example Linux), you can run as many
1084: instances as you want, but each of them must be connected to a different BIRD
1085: routing table and to a different kernel table.
1086: <P>
1087: <P>Because the kernel protocol is partially integrated with the connected
1088: routing table, there are two limitations - it is not possible to connect more
1089: kernel protocols to the same routing table and changing route destination
1090: (gateway) in an export filter of a kernel protocol does not work. Both
1091: limitations can be overcome using another routing table and the pipe protocol.
1092: <P>
1093: <H3><A NAME="krt-config"></A> Configuration</H3>
1094:
1095: <P>
1096: <DL>
1097: <DT><CODE>
1098: <A NAME="krt-persist"></A> persist <I>switch</I></CODE><DD><P>Tell BIRD to leave all its routes in the routing tables when it exits
1099: (instead of cleaning them up).
1100: <P>
1101: <DT><CODE>
1102: <A NAME="krt-scan-time"></A> scan time <I>number</I></CODE><DD><P>Time in seconds between two consecutive scans of the kernel routing
1103: table.
1104: <P>
1105: <DT><CODE>
1106: <A NAME="krt-learn"></A> learn <I>switch</I></CODE><DD><P>Enable learning of routes added to the kernel routing tables by other
1107: routing daemons or by the system administrator. This is possible only on
1108: systems which support identification of route authorship.
1109: <P>
1110: <DT><CODE>
1111: <A NAME="krt-device-routes"></A> device routes <I>switch</I></CODE><DD><P>Enable export of device routes to the kernel routing table. By default,
1112: such routes are rejected (with the exception of explicitly configured
1113: device routes from the static protocol) regardless of the export filter
1114: to protect device routes in kernel routing table (managed by OS itself)
1115: from accidental overwriting or erasing.
1116: <P>
1117: <DT><CODE>
1118: <A NAME="krt-kernel-table"></A> kernel table <I>number</I></CODE><DD><P>Select which kernel table should this particular instance of the Kernel
1119: protocol work with. Available only on systems supporting multiple
1120: routing tables.
1121: <P>
1122: <DT><CODE>
1123: <A NAME="krt-metric"></A> metric <I>number</I></CODE><DD><P>(Linux)
1124: Use specified value as a kernel metric (priority) for all routes sent to
1125: the kernel. When multiple routes for the same network are in the kernel
1126: routing table, the Linux kernel chooses one with lower metric. Also,
1127: routes with different metrics do not clash with each other, therefore
1128: using dedicated metric value is a reliable way to avoid overwriting
1129: routes from other sources (e.g. kernel device routes). Metric 0 has a
1130: special meaning of undefined metric, in which either OS default is used,
1131: or per-route metric can be set using <CODE>krt_metric</CODE> attribute. Default:
1132: 0 (undefined).
1133: <P>
1134: <DT><CODE>
1135: <A NAME="krt-graceful-restart"></A> graceful restart <I>switch</I></CODE><DD><P>Participate in graceful restart recovery. If this option is enabled and
1136: a graceful restart recovery is active, the Kernel protocol will defer
1137: synchronization of routing tables until the end of the recovery. Note
1138: that import of kernel routes to BIRD is not affected.
1139: <P>
1140: <DT><CODE>
1141: <A NAME="krt-merge-paths"></A> merge paths <I>switch</I> [limit <I>number</I>]</CODE><DD><P>Usually, only best routes are exported to the kernel protocol. With path
1142: merging enabled, both best routes and equivalent non-best routes are
1143: merged during export to generate one ECMP (equal-cost multipath) route
1144: for each network. This is useful e.g. for BGP multipath. Note that best
1145: routes are still pivotal for route export (responsible for most
1146: properties of resulting ECMP routes), while exported non-best routes are
1147: responsible just for additional multipath next hops. This option also
1148: allows to specify a limit on maximal number of nexthops in one route. By
1149: default, multipath merging is disabled. If enabled, default value of the
1150: limit is 16.
1151: </DL>
1152: <P>
1153: <H3><A NAME="krt-attr"></A> Attributes</H3>
1154:
1155: <P>The Kernel protocol defines several attributes. These attributes are
1156: translated to appropriate system (and OS-specific) route attributes. We support
1157: these attributes:
1158: <P>
1159: <DL>
1160: <DT><CODE>
1.1.1.2 ! misho 1161: <A NAME="rta-krt-source"></A> int krt_source</CODE><DD><P>The original source of the imported kernel route. The value is
1.1 misho 1162: system-dependent. On Linux, it is a value of the protocol field of the
1163: route. See /etc/iproute2/rt_protos for common values. On BSD, it is
1164: based on STATIC and PROTOx flags. The attribute is read-only.
1165: <P>
1166: <DT><CODE>
1.1.1.2 ! misho 1167: <A NAME="rta-krt-metric"></A> int krt_metric</CODE><DD><P>(Linux)
1.1 misho 1168: The kernel metric of the route. When multiple same routes are in a
1169: kernel routing table, the Linux kernel chooses one with lower metric.
1170: Note that preferred way to set kernel metric is to use protocol option
1171: <CODE>metric</CODE>, unless per-route metric values are needed.
1172: <P>
1173: <DT><CODE>
1.1.1.2 ! misho 1174: <A NAME="rta-krt-prefsrc"></A> ip krt_prefsrc</CODE><DD><P>(Linux)
1.1 misho 1175: The preferred source address. Used in source address selection for
1176: outgoing packets. Has to be one of the IP addresses of the router.
1177: <P>
1178: <DT><CODE>
1.1.1.2 ! misho 1179: <A NAME="rta-krt-realm"></A> int krt_realm</CODE><DD><P>(Linux)
1.1 misho 1180: The realm of the route. Can be used for traffic classification.
1181: <P>
1182: <DT><CODE>
1.1.1.2 ! misho 1183: <A NAME="rta-krt-scope"></A> int krt_scope</CODE><DD><P>(Linux IPv4)
1.1 misho 1184: The scope of the route. Valid values are 0-254, although Linux kernel
1185: may reject some values depending on route type and nexthop. It is
1186: supposed to represent `indirectness' of the route, where nexthops of
1187: routes are resolved through routes with a higher scope, but in current
1188: kernels anything below <I>link</I> (253) is treated as <I>global</I> (0).
1189: When not present, global scope is implied for all routes except device
1190: routes, where link scope is used by default.
1191: </DL>
1192: <P>
1193: <P>In Linux, there is also a plenty of obscure route attributes mostly focused
1194: on tuning TCP performance of local connections. BIRD supports most of these
1195: attributes, see Linux or iproute2 documentation for their meaning. Attributes
1196: <CODE>krt_lock_*</CODE> and <CODE>krt_feature_*</CODE> have type bool, others have type int.
1197: Supported attributes are:
1198: <P><CODE>krt_mtu</CODE>, <CODE>krt_lock_mtu</CODE>, <CODE>krt_window</CODE>, <CODE>krt_lock_window</CODE>,
1199: <CODE>krt_rtt</CODE>, <CODE>krt_lock_rtt</CODE>, <CODE>krt_rttvar</CODE>, <CODE>krt_lock_rttvar</CODE>,
1200: <CODE>krt_sstresh</CODE>, <CODE>krt_lock_sstresh</CODE>, <CODE>krt_cwnd</CODE>, <CODE>krt_lock_cwnd</CODE>,
1201: <CODE>krt_advmss</CODE>, <CODE>krt_lock_advmss</CODE>, <CODE>krt_reordering</CODE>, <CODE>krt_lock_reordering</CODE>,
1202: <CODE>krt_hoplimit</CODE>, <CODE>krt_lock_hoplimit</CODE>, <CODE>krt_rto_min</CODE>, <CODE>krt_lock_rto_min</CODE>,
1203: <CODE>krt_initcwnd</CODE>, <CODE>krt_initrwnd</CODE>, <CODE>krt_quickack</CODE>,
1204: <CODE>krt_feature_ecn</CODE>, <CODE>krt_feature_allfrag</CODE>
1205: <P>
1206: <H3><A NAME="krt-exam"></A> Example</H3>
1207:
1208: <P>A simple configuration can look this way:
1209: <P>
1210: <P>
1211: <HR>
1212: <PRE>
1213: protocol kernel {
1214: export all;
1215: }
1216: </PRE>
1217: <HR>
1218: <P>
1219: <P>Or for a system with two routing tables:
1220: <P>
1221: <P>
1222: <HR>
1223: <PRE>
1224: protocol kernel { # Primary routing table
1225: learn; # Learn alien routes from the kernel
1226: persist; # Don't remove routes on bird shutdown
1227: scan time 10; # Scan kernel routing table every 10 seconds
1228: import all;
1229: export all;
1230: }
1231:
1232: protocol kernel { # Secondary routing table
1233: table auxtable;
1234: kernel table 100;
1235: export all;
1236: }
1237: </PRE>
1238: <HR>
1239: <P>
1240: <P>
1.1.1.2 ! misho 1241: <H2><A NAME="mrt"></A> <A NAME="ss6.7">6.7</A> <A HREF="bird.html#toc6.7">MRT</A>
! 1242: </H2>
! 1243:
! 1244: <H3><A NAME="mrt-intro"></A> Introduction</H3>
! 1245:
! 1246: <P>The MRT protocol is a component responsible for handling the Multi-Threaded
! 1247: Routing Toolkit (MRT) routing information export format, which is mainly used
! 1248: for collecting and analyzing of routing information from BGP routers. The MRT
! 1249: protocol can be configured to do periodic dumps of routing tables, created MRT
! 1250: files can be analyzed later by other tools. Independent MRT table dumps can also
! 1251: be requested from BIRD client. There is also a feature to save incoming BGP
! 1252: messages in MRT files, but it is controlled by
! 1253: <A HREF="bird-3.html#proto-mrtdump">mrtdump</A> options independently of MRT protocol, although that might
! 1254: change in the future.
! 1255: <P>BIRD implements the main MRT format specification as defined in <A HREF="http://www.rfc-editor.org/info/rfc6396">RFC 6396</A>
! 1256: and the ADD_PATH extension (<A HREF="http://www.rfc-editor.org/info/rfc8050">RFC 8050</A>).
! 1257: <P>
! 1258: <H3><A NAME="mrt-config"></A> Configuration</H3>
! 1259:
! 1260: <P>MRT configuration consists of several statements describing routing table
! 1261: dumps. Multiple independent periodic dumps can be done as multiple MRT protocol
! 1262: instances. There are two mandatory statements: <CODE>filename</CODE> and <CODE>period</CODE>.
! 1263: The behavior can be modified by following configuration parameters:
! 1264: <P>
! 1265: <DL>
! 1266: <DT><CODE>
! 1267: <A NAME="mrt-table"></A> table <I>name</I> | "<I>pattern</I>"</CODE><DD><P>Specify a routing table (or a set of routing tables described by a
! 1268: wildcard pattern) that are to be dumped by the MRT protocol instance.
! 1269: Default: the master table.
! 1270: <P>
! 1271: <DT><CODE>
! 1272: <A NAME="mrt-filter"></A> filter { <I>filter commands</I> }</CODE><DD><P>The MRT protocol allows to specify a filter that is applied to routes as
! 1273: they are dumped. Rejected routes are ignored and not saved to the MRT
! 1274: dump file. Default: no filter.
! 1275: <P>
! 1276: <DT><CODE>
! 1277: <A NAME="mrt-where"></A> where <I>filter expression</I></CODE><DD><P>An alternative way to specify a filter for the MRT protocol.
! 1278: <P>
! 1279: <DT><CODE>
! 1280: <A NAME="mrt-filename"></A> filename "<I>filename</I>"</CODE><DD><P>Specify a filename for MRT dump files. The filename may contain time
! 1281: format sequences with <I>strftime(3)</I> notation (see <I>man strftime</I>
! 1282: for details), there is also a sequence "%N" that is expanded to the name
! 1283: of dumped table. Therefore, each periodic dump of each table can be
! 1284: saved to a different file. Mandatory, see example below.
! 1285: <P>
! 1286: <DT><CODE>
! 1287: <A NAME="mrt-period"></A> period <I>number</I></CODE><DD><P>Specify the time interval (in seconds) between periodic dumps.
! 1288: Mandatory.
! 1289: <P>
! 1290: <DT><CODE>
! 1291: <A NAME="mrt-always-add-path"></A> always add path <I>switch</I></CODE><DD><P>The MRT format uses special records (specified in <A HREF="http://www.rfc-editor.org/info/rfc8050">RFC 8050</A>) for
! 1292: routes received using BGP ADD_PATH extension to keep Path ID, while
! 1293: other routes use regular records. This has advantage of better
! 1294: compatibility with tools that do not know special records, but it loses
! 1295: information about which route is the best route. When this option is
! 1296: enabled, both ADD_PATH and non-ADD_PATH routes are stored in ADD_PATH
! 1297: records and order of routes for network is preserved. Default: disabled.
! 1298: </DL>
! 1299: <P>
! 1300: <H3><A NAME="mrt-exam"></A> Example</H3>
! 1301:
! 1302: <P>
! 1303: <HR>
! 1304: <PRE>
! 1305: protocol mrt {
! 1306: table "tab*";
! 1307: where source = RTS_BGP;
! 1308: filename "/var/log/bird/%N_%F_%T.mrt";
! 1309: period 300;
! 1310: }
! 1311: </PRE>
! 1312: <HR>
! 1313: <P>
! 1314: <P>
! 1315: <H2><A NAME="ospf"></A> <A NAME="ss6.8">6.8</A> <A HREF="bird.html#toc6.8">OSPF</A>
1.1 misho 1316: </H2>
1317:
1318: <H3><A NAME="ospf-intro"></A> Introduction</H3>
1319:
1320: <P>Open Shortest Path First (OSPF) is a quite complex interior gateway
1321: protocol. The current IPv4 version (OSPFv2) is defined in <A HREF="http://www.rfc-editor.org/info/rfc2328">RFC 2328</A> and
1322: the current IPv6 version (OSPFv3) is defined in <A HREF="http://www.rfc-editor.org/info/rfc5340">RFC 5340</A> It's a link
1323: state (a.k.a. shortest path first) protocol -- each router maintains a database
1324: describing the autonomous system's topology. Each participating router has an
1325: identical copy of the database and all routers run the same algorithm
1326: calculating a shortest path tree with themselves as a root. OSPF chooses the
1327: least cost path as the best path.
1328: <P>
1329: <P>In OSPF, the autonomous system can be split to several areas in order to
1330: reduce the amount of resources consumed for exchanging the routing information
1331: and to protect the other areas from incorrect routing data. Topology of the area
1332: is hidden to the rest of the autonomous system.
1333: <P>
1334: <P>Another very important feature of OSPF is that it can keep routing information
1335: from other protocols (like Static or BGP) in its link state database as external
1336: routes. Each external route can be tagged by the advertising router, making it
1337: possible to pass additional information between routers on the boundary of the
1338: autonomous system.
1339: <P>
1340: <P>OSPF quickly detects topological changes in the autonomous system (such as
1341: router interface failures) and calculates new loop-free routes after a short
1342: period of convergence. Only a minimal amount of routing traffic is involved.
1343: <P>
1344: <P>Each router participating in OSPF routing periodically sends Hello messages
1345: to all its interfaces. This allows neighbors to be discovered dynamically. Then
1346: the neighbors exchange theirs parts of the link state database and keep it
1347: identical by flooding updates. The flooding process is reliable and ensures that
1348: each router detects all changes.
1349: <P>
1350: <H3><A NAME="ospf-config"></A> Configuration</H3>
1351:
1352: <P>In the main part of configuration, there can be multiple definitions of OSPF
1353: areas, each with a different id. These definitions includes many other switches
1354: and multiple definitions of interfaces. Definition of interface may contain many
1355: switches and constant definitions and list of neighbors on nonbroadcast
1356: networks.
1357: <P>
1358: <HR>
1359: <PRE>
1360: protocol ospf <name> {
1361: rfc1583compat <switch>;
1362: instance id <num>;
1363: stub router <switch>;
1364: tick <num>;
1365: ecmp <switch> [limit <num>];
1366: merge external <switch>;
1367: area <id> {
1368: stub;
1369: nssa;
1370: summary <switch>;
1371: default nssa <switch>;
1372: default cost <num>;
1373: default cost2 <num>;
1374: translator <switch>;
1375: translator stability <num>;
1376:
1377: networks {
1378: <prefix>;
1379: <prefix> hidden;
1380: }
1381: external {
1382: <prefix>;
1383: <prefix> hidden;
1384: <prefix> tag <num>;
1385: }
1386: stubnet <prefix>;
1387: stubnet <prefix> {
1388: hidden <switch>;
1389: summary <switch>;
1390: cost <num>;
1391: }
1392: interface <interface pattern> [instance <num>] {
1393: cost <num>;
1394: stub <switch>;
1395: hello <num>;
1396: poll <num>;
1397: retransmit <num>;
1398: priority <num>;
1399: wait <num>;
1400: dead count <num>;
1401: dead <num>;
1402: secondary <switch>;
1403: rx buffer [normal|large|<num>];
1404: tx length <num>;
1405: type [broadcast|bcast|pointopoint|ptp|
1406: nonbroadcast|nbma|pointomultipoint|ptmp];
1407: link lsa suppression <switch>;
1408: strict nonbroadcast <switch>;
1409: real broadcast <switch>;
1410: ptp netmask <switch>;
1411: check link <switch>;
1412: bfd <switch>;
1413: ecmp weight <num>;
1414: ttl security [<switch>; | tx only]
1415: tx class|dscp <num>;
1416: tx priority <num>;
1417: authentication none|simple|cryptographic;
1418: password "<text>";
1419: password "<text>" {
1420: id <num>;
1421: generate from "<date>";
1422: generate to "<date>";
1423: accept from "<date>";
1424: accept to "<date>";
1425: from "<date>";
1426: to "<date>";
1427: algorithm ( keyed md5 | keyed sha1 | hmac sha1 | hmac sha256 | hmac sha384 | hmac sha512 );
1428: };
1429: neighbors {
1430: <ip>;
1431: <ip> eligible;
1432: };
1433: };
1434: virtual link <id> [instance <num>] {
1435: hello <num>;
1436: retransmit <num>;
1437: wait <num>;
1438: dead count <num>;
1439: dead <num>;
1440: authentication none|simple|cryptographic;
1441: password "<text>";
1442: password "<text>" {
1443: id <num>;
1444: generate from "<date>";
1445: generate to "<date>";
1446: accept from "<date>";
1447: accept to "<date>";
1448: from "<date>";
1449: to "<date>";
1450: algorithm ( keyed md5 | keyed sha1 | hmac sha1 | hmac sha256 | hmac sha384 | hmac sha512 );
1451: };
1452: };
1453: };
1454: }
1455: </PRE>
1456: <HR>
1457: <P>
1458: <DL>
1459: <DT><CODE>
1460: <A NAME="ospf-rfc1583compat"></A> rfc1583compat <I>switch</I></CODE><DD><P>This option controls compatibility of routing table calculation with
1461: <A HREF="http://www.rfc-editor.org/info/rfc1583">RFC 1583</A>. Default value is no.
1462: <P>
1463: <DT><CODE>
1464: <A NAME="ospf-instance-id"></A> instance id <I>num</I></CODE><DD><P>When multiple OSPF protocol instances are active on the same links, they
1465: should use different instance IDs to distinguish their packets. Although
1466: it could be done on per-interface basis, it is often preferred to set
1467: one instance ID to whole OSPF domain/topology (e.g., when multiple
1468: instances are used to represent separate logical topologies on the same
1469: physical network). This option specifies the default instance ID for all
1470: interfaces of the OSPF instance. Note that this option, if used, must
1471: precede interface definitions. Default value is 0.
1472: <P>
1473: <DT><CODE>
1474: <A NAME="ospf-stub-router"></A> stub router <I>switch</I></CODE><DD><P>This option configures the router to be a stub router, i.e., a router
1475: that participates in the OSPF topology but does not allow transit
1476: traffic. In OSPFv2, this is implemented by advertising maximum metric
1477: for outgoing links. In OSPFv3, the stub router behavior is announced by
1478: clearing the R-bit in the router LSA. See <A HREF="http://www.rfc-editor.org/info/rfc6987">RFC 6987</A> for details.
1479: Default value is no.
1480: <P>
1481: <DT><CODE>
1482: <A NAME="ospf-tick"></A> tick <I>num</I></CODE><DD><P>The routing table calculation and clean-up of areas' databases is not
1483: performed when a single link state change arrives. To lower the CPU
1484: utilization, it's processed later at periodical intervals of <I>num</I>
1485: seconds. The default value is 1.
1486: <P>
1487: <DT><CODE>
1488: <A NAME="ospf-ecmp"></A> ecmp <I>switch</I> [limit <I>number</I>]</CODE><DD><P>This option specifies whether OSPF is allowed to generate ECMP
1489: (equal-cost multipath) routes. Such routes are used when there are
1490: several directions to the destination, each with the same (computed)
1491: cost. This option also allows to specify a limit on maximum number of
1492: nexthops in one route. By default, ECMP is disabled. If enabled,
1493: default value of the limit is 16.
1494: <P>
1495: <DT><CODE>
1496: <A NAME="ospf-merge-external"></A> merge external <I>switch</I></CODE><DD><P>This option specifies whether OSPF should merge external routes from
1497: different routers/LSAs for the same destination. When enabled together
1498: with <CODE>ecmp</CODE>, equal-cost external routes will be combined to multipath
1499: routes in the same way as regular routes. When disabled, external routes
1500: from different LSAs are treated as separate even if they represents the
1501: same destination. Default value is no.
1502: <P>
1503: <DT><CODE>
1504: <A NAME="ospf-area"></A> area <I>id</I></CODE><DD><P>This defines an OSPF area with given area ID (an integer or an IPv4
1505: address, similarly to a router ID). The most important area is the
1506: backbone (ID 0) to which every other area must be connected.
1507: <P>
1508: <DT><CODE>
1509: <A NAME="ospf-stub"></A> stub</CODE><DD><P>This option configures the area to be a stub area. External routes are
1510: not flooded into stub areas. Also summary LSAs can be limited in stub
1511: areas (see option <CODE>summary</CODE>). By default, the area is not a stub
1512: area.
1513: <P>
1514: <DT><CODE>
1515: <A NAME="ospf-nssa"></A> nssa</CODE><DD><P>This option configures the area to be a NSSA (Not-So-Stubby Area). NSSA
1516: is a variant of a stub area which allows a limited way of external route
1517: propagation. Global external routes are not propagated into a NSSA, but
1518: an external route can be imported into NSSA as a (area-wide) NSSA-LSA
1519: (and possibly translated and/or aggregated on area boundary). By
1520: default, the area is not NSSA.
1521: <P>
1522: <DT><CODE>
1523: <A NAME="ospf-summary"></A> summary <I>switch</I></CODE><DD><P>This option controls propagation of summary LSAs into stub or NSSA
1524: areas. If enabled, summary LSAs are propagated as usual, otherwise just
1525: the default summary route (0.0.0.0/0) is propagated (this is sometimes
1526: called totally stubby area). If a stub area has more area boundary
1527: routers, propagating summary LSAs could lead to more efficient routing
1528: at the cost of larger link state database. Default value is no.
1529: <P>
1530: <DT><CODE>
1531: <A NAME="ospf-default-nssa"></A> default nssa <I>switch</I></CODE><DD><P>When <CODE>summary</CODE> option is enabled, default summary route is no longer
1532: propagated to the NSSA. In that case, this option allows to originate
1533: default route as NSSA-LSA to the NSSA. Default value is no.
1534: <P>
1535: <DT><CODE>
1536: <A NAME="ospf-default-cost"></A> default cost <I>num</I></CODE><DD><P>This option controls the cost of a default route propagated to stub and
1537: NSSA areas. Default value is 1000.
1538: <P>
1539: <DT><CODE>
1540: <A NAME="ospf-default-cost2"></A> default cost2 <I>num</I></CODE><DD><P>When a default route is originated as NSSA-LSA, its cost can use either
1541: type 1 or type 2 metric. This option allows to specify the cost of a
1542: default route in type 2 metric. By default, type 1 metric (option
1543: <CODE>default cost</CODE>) is used.
1544: <P>
1545: <DT><CODE>
1546: <A NAME="ospf-translator"></A> translator <I>switch</I></CODE><DD><P>This option controls translation of NSSA-LSAs into external LSAs. By
1547: default, one translator per NSSA is automatically elected from area
1548: boundary routers. If enabled, this area boundary router would
1549: unconditionally translate all NSSA-LSAs regardless of translator
1550: election. Default value is no.
1551: <P>
1552: <DT><CODE>
1553: <A NAME="ospf-translator-stability"></A> translator stability <I>num</I></CODE><DD><P>This option controls the translator stability interval (in seconds).
1554: When the new translator is elected, the old one keeps translating until
1555: the interval is over. Default value is 40.
1556: <P>
1557: <DT><CODE>
1558: <A NAME="ospf-networks"></A> networks { <I>set</I> }</CODE><DD><P>Definition of area IP ranges. This is used in summary LSA origination.
1559: Hidden networks are not propagated into other areas.
1560: <P>
1561: <DT><CODE>
1562: <A NAME="ospf-external"></A> external { <I>set</I> }</CODE><DD><P>Definition of external area IP ranges for NSSAs. This is used for
1563: NSSA-LSA translation. Hidden networks are not translated into external
1564: LSAs. Networks can have configured route tag.
1565: <P>
1566: <DT><CODE>
1567: <A NAME="ospf-stubnet"></A> stubnet <I>prefix</I> { <I>options</I> }</CODE><DD><P>Stub networks are networks that are not transit networks between OSPF
1568: routers. They are also propagated through an OSPF area as a part of a
1569: link state database. By default, BIRD generates a stub network record
1570: for each primary network address on each OSPF interface that does not
1571: have any OSPF neighbors, and also for each non-primary network address
1572: on each OSPF interface. This option allows to alter a set of stub
1573: networks propagated by this router.
1574: <P>Each instance of this option adds a stub network with given network
1575: prefix to the set of propagated stub network, unless option <CODE>hidden</CODE>
1576: is used. It also suppresses default stub networks for given network
1577: prefix. When option <CODE>summary</CODE> is used, also default stub networks
1578: that are subnetworks of given stub network are suppressed. This might be
1579: used, for example, to aggregate generated stub networks.
1580: <P>
1581: <DT><CODE>
1582: <A NAME="ospf-iface"></A> interface <I>pattern</I> [instance <I>num</I>]</CODE><DD><P>Defines that the specified interfaces belong to the area being defined.
1583: See
1584: <A HREF="bird-3.html#proto-iface">interface</A> common option for detailed
1585: description. In OSPFv2, extended interface clauses are used, because
1586: each network prefix is handled as a separate virtual interface.
1587: <P>You can specify alternative instance ID for the interface definition,
1588: therefore it is possible to have several instances of that interface
1589: with different options or even in different areas. For OSPFv2, instance
1590: ID support is an extension (<A HREF="http://www.rfc-editor.org/info/rfc6549">RFC 6549</A>) and is supposed to be set
1591: per-protocol. For OSPFv3, it is an integral feature.
1592: <P>
1593: <DT><CODE>
1594: <A NAME="ospf-virtual-link"></A> virtual link <I>id</I> [instance <I>num</I>]</CODE><DD><P>Virtual link to router with the router id. Virtual link acts as a
1595: point-to-point interface belonging to backbone. The actual area is used
1596: as a transport area. This item cannot be in the backbone. Like with
1597: <CODE>interface</CODE> option, you could also use several virtual links to one
1598: destination with different instance IDs.
1599: <P>
1600: <DT><CODE>
1601: <A NAME="ospf-cost"></A> cost <I>num</I></CODE><DD><P>Specifies output cost (metric) of an interface. Default value is 10.
1602: <P>
1603: <DT><CODE>
1604: <A NAME="ospf-stub-iface"></A> stub <I>switch</I></CODE><DD><P>If set to interface it does not listen to any packet and does not send
1605: any hello. Default value is no.
1606: <P>
1607: <DT><CODE>
1608: <A NAME="ospf-hello"></A> hello <I>num</I></CODE><DD><P>Specifies interval in seconds between sending of Hello messages. Beware,
1609: all routers on the same network need to have the same hello interval.
1610: Default value is 10.
1611: <P>
1612: <DT><CODE>
1613: <A NAME="ospf-poll"></A> poll <I>num</I></CODE><DD><P>Specifies interval in seconds between sending of Hello messages for some
1614: neighbors on NBMA network. Default value is 20.
1615: <P>
1616: <DT><CODE>
1617: <A NAME="ospf-retransmit"></A> retransmit <I>num</I></CODE><DD><P>Specifies interval in seconds between retransmissions of unacknowledged
1618: updates. Default value is 5.
1619: <P>
1620: <DT><CODE>
1.1.1.2 ! misho 1621: <A NAME="ospf-transmit-delay"></A> transmit delay <I>num</I></CODE><DD><P>Specifies estimated transmission delay of link state updates send over
! 1622: the interface. The value is added to LSA age of LSAs propagated through
! 1623: it. Default value is 1.
! 1624: <P>
! 1625: <DT><CODE>
1.1 misho 1626: <A NAME="ospf-priority"></A> priority <I>num</I></CODE><DD><P>On every multiple access network (e.g., the Ethernet) Designated Router
1627: and Backup Designated router are elected. These routers have some special
1628: functions in the flooding process. Higher priority increases preferences
1629: in this election. Routers with priority 0 are not eligible. Default
1630: value is 1.
1631: <P>
1632: <DT><CODE>
1633: <A NAME="ospf-wait"></A> wait <I>num</I></CODE><DD><P>After start, router waits for the specified number of seconds between
1634: starting election and building adjacency. Default value is 4*<I>hello</I>.
1635: <P>
1636: <DT><CODE>
1637: <A NAME="ospf-dead-count"></A> dead count <I>num</I></CODE><DD><P>When the router does not receive any messages from a neighbor in
1638: <I>dead count</I>*<I>hello</I> seconds, it will consider the neighbor down.
1639: <P>
1640: <DT><CODE>
1641: <A NAME="ospf-dead"></A> dead <I>num</I></CODE><DD><P>When the router does not receive any messages from a neighbor in
1642: <I>dead</I> seconds, it will consider the neighbor down. If both directives
1643: <CODE>dead count</CODE> and <CODE>dead</CODE> are used, <CODE>dead</CODE> has precedence.
1644: <P>
1645: <DT><CODE>
1646: <A NAME="ospf-secondary"></A> secondary <I>switch</I></CODE><DD><P>On BSD systems, older versions of BIRD supported OSPFv2 only for the
1647: primary IP address of an interface, other IP ranges on the interface
1648: were handled as stub networks. Since v1.4.1, regular operation on
1649: secondary IP addresses is supported, but disabled by default for
1650: compatibility. This option allows to enable it. The option is a
1651: transitional measure, will be removed in the next major release as the
1652: behavior will be changed. On Linux systems, the option is irrelevant, as
1653: operation on non-primary addresses is already the regular behavior.
1654: <P>
1655: <DT><CODE>
1656: <A NAME="ospf-rx-buffer"></A> rx buffer <I>num</I></CODE><DD><P>This option allows to specify the size of buffers used for packet
1657: processing. The buffer size should be bigger than maximal size of any
1658: packets. By default, buffers are dynamically resized as needed, but a
1659: fixed value could be specified. Value <CODE>large</CODE> means maximal allowed
1660: packet size - 65535.
1661: <P>
1662: <DT><CODE>
1663: <A NAME="ospf-tx-length"></A> tx length <I>num</I></CODE><DD><P>Transmitted OSPF messages that contain large amount of information are
1664: segmented to separate OSPF packets to avoid IP fragmentation. This
1665: option specifies the soft ceiling for the length of generated OSPF
1666: packets. Default value is the MTU of the network interface. Note that
1667: larger OSPF packets may still be generated if underlying OSPF messages
1668: cannot be splitted (e.g. when one large LSA is propagated).
1669: <P>
1670: <DT><CODE>
1671: <A NAME="ospf-type-bcast"></A> type broadcast|bcast</CODE><DD><P>BIRD detects a type of a connected network automatically, but sometimes
1672: it's convenient to force use of a different type manually. On broadcast
1673: networks (like ethernet), flooding and Hello messages are sent using
1674: multicasts (a single packet for all the neighbors). A designated router
1675: is elected and it is responsible for synchronizing the link-state
1676: databases and originating network LSAs. This network type cannot be used
1677: on physically NBMA networks and on unnumbered networks (networks without
1678: proper IP prefix).
1679: <P>
1680: <DT><CODE>
1681: <A NAME="ospf-type-ptp"></A> type pointopoint|ptp</CODE><DD><P>Point-to-point networks connect just 2 routers together. No election is
1682: performed and no network LSA is originated, which makes it simpler and
1683: faster to establish. This network type is useful not only for physically
1684: PtP ifaces (like PPP or tunnels), but also for broadcast networks used
1685: as PtP links. This network type cannot be used on physically NBMA
1686: networks.
1687: <P>
1688: <DT><CODE>
1689: <A NAME="ospf-type-nbma"></A> type nonbroadcast|nbma</CODE><DD><P>On NBMA networks, the packets are sent to each neighbor separately
1690: because of lack of multicast capabilities. Like on broadcast networks,
1691: a designated router is elected, which plays a central role in propagation
1692: of LSAs. This network type cannot be used on unnumbered networks.
1693: <P>
1694: <DT><CODE>
1695: <A NAME="ospf-type-ptmp"></A> type pointomultipoint|ptmp</CODE><DD><P>This is another network type designed to handle NBMA networks. In this
1696: case the NBMA network is treated as a collection of PtP links. This is
1697: useful if not every pair of routers on the NBMA network has direct
1698: communication, or if the NBMA network is used as an (possibly
1699: unnumbered) PtP link.
1700: <P>
1701: <DT><CODE>
1702: <A NAME="ospf-link-lsa-suppression"></A> link lsa suppression <I>switch</I></CODE><DD><P>In OSPFv3, link LSAs are generated for each link, announcing link-local
1703: IPv6 address of the router to its local neighbors. These are useless on
1704: PtP or PtMP networks and this option allows to suppress the link LSA
1705: origination for such interfaces. The option is ignored on other than PtP
1706: or PtMP interfaces. Default value is no.
1707: <P>
1708: <DT><CODE>
1709: <A NAME="ospf-strict-nonbroadcast"></A> strict nonbroadcast <I>switch</I></CODE><DD><P>If set, don't send hello to any undefined neighbor. This switch is
1710: ignored on other than NBMA or PtMP interfaces. Default value is no.
1711: <P>
1712: <DT><CODE>
1713: <A NAME="ospf-real-broadcast"></A> real broadcast <I>switch</I></CODE><DD><P>In <CODE>type broadcast</CODE> or <CODE>type ptp</CODE> network configuration, OSPF
1714: packets are sent as IP multicast packets. This option changes the
1715: behavior to using old-fashioned IP broadcast packets. This may be useful
1716: as a workaround if IP multicast for some reason does not work or does
1717: not work reliably. This is a non-standard option and probably is not
1718: interoperable with other OSPF implementations. Default value is no.
1719: <P>
1720: <DT><CODE>
1721: <A NAME="ospf-ptp-netmask"></A> ptp netmask <I>switch</I></CODE><DD><P>In <CODE>type ptp</CODE> network configurations, OSPFv2 implementations should
1722: ignore received netmask field in hello packets and should send hello
1723: packets with zero netmask field on unnumbered PtP links. But some OSPFv2
1724: implementations perform netmask checking even for PtP links. This option
1725: specifies whether real netmask will be used in hello packets on <CODE>type
1726: ptp</CODE> interfaces. You should ignore this option unless you meet some
1727: compatibility problems related to this issue. Default value is no for
1728: unnumbered PtP links, yes otherwise.
1729: <P>
1730: <DT><CODE>
1731: <A NAME="ospf-check-link"></A> check link <I>switch</I></CODE><DD><P>If set, a hardware link state (reported by OS) is taken into consideration.
1732: When a link disappears (e.g. an ethernet cable is unplugged), neighbors
1733: are immediately considered unreachable and only the address of the iface
1734: (instead of whole network prefix) is propagated. It is possible that
1735: some hardware drivers or platforms do not implement this feature.
1736: Default value is no.
1737: <P>
1738: <DT><CODE>
1739: <A NAME="ospf-bfd"></A> bfd <I>switch</I></CODE><DD><P>OSPF could use BFD protocol as an advisory mechanism for neighbor
1740: liveness and failure detection. If enabled, BIRD setups a BFD session
1741: for each OSPF neighbor and tracks its liveness by it. This has an
1742: advantage of an order of magnitude lower detection times in case of
1743: failure. Note that BFD protocol also has to be configured, see
1744: <A HREF="#bfd">BFD</A> section for details. Default value is no.
1745: <P>
1746: <DT><CODE>
1747: <A NAME="ospf-ttl-security"></A> ttl security [<I>switch</I> | tx only]</CODE><DD><P>TTL security is a feature that protects routing protocols from remote
1748: spoofed packets by using TTL 255 instead of TTL 1 for protocol packets
1749: destined to neighbors. Because TTL is decremented when packets are
1750: forwarded, it is non-trivial to spoof packets with TTL 255 from remote
1751: locations. Note that this option would interfere with OSPF virtual
1752: links.
1753: <P>If this option is enabled, the router will send OSPF packets with TTL
1754: 255 and drop received packets with TTL less than 255. If this option si
1755: set to <CODE>tx only</CODE>, TTL 255 is used for sent packets, but is not
1756: checked for received packets. Default value is no.
1757: <P>
1758: <DT><CODE>
1759: <A NAME="ospf-tx-class"></A> tx class|dscp|priority <I>num</I></CODE><DD><P>These options specify the ToS/DiffServ/Traffic class/Priority of the
1760: outgoing OSPF packets. See
1761: <A HREF="bird-3.html#proto-tx-class">tx class</A> common
1762: option for detailed description.
1763: <P>
1764: <DT><CODE>
1765: <A NAME="ospf-ecmp-weight"></A> ecmp weight <I>num</I></CODE><DD><P>When ECMP (multipath) routes are allowed, this value specifies a
1766: relative weight used for nexthops going through the iface. Allowed
1767: values are 1-256. Default value is 1.
1768: <P>
1769: <DT><CODE>
1770: <A NAME="ospf-auth-none"></A> authentication none</CODE><DD><P>No passwords are sent in OSPF packets. This is the default value.
1771: <P>
1772: <DT><CODE>
1773: <A NAME="ospf-auth-simple"></A> authentication simple</CODE><DD><P>Every packet carries 8 bytes of password. Received packets lacking this
1774: password are ignored. This authentication mechanism is very weak.
1775: This option is not available in OSPFv3.
1776: <P>
1777: <DT><CODE>
1778: <A NAME="ospf-auth-cryptographic"></A> authentication cryptographic</CODE><DD><P>An authentication code is appended to every packet. The specific
1779: cryptographic algorithm is selected by option <CODE>algorithm</CODE> for each
1780: key. The default cryptographic algorithm for OSPFv2 keys is Keyed-MD5
1781: and for OSPFv3 keys is HMAC-SHA-256. Passwords are not sent open via
1782: network, so this mechanism is quite secure. Packets can still be read by
1783: an attacker.
1784: <P>
1785: <DT><CODE>
1786: <A NAME="ospf-pass"></A> password "<I>text</I>"</CODE><DD><P>Specifies a password used for authentication. See
1787: <A HREF="bird-3.html#proto-pass">password</A> common option for detailed
1788: description.
1789: <P>
1790: <DT><CODE>
1791: <A NAME="ospf-neighbors"></A> neighbors { <I>set</I> } </CODE><DD><P>A set of neighbors to which Hello messages on NBMA or PtMP networks are
1792: to be sent. For NBMA networks, some of them could be marked as eligible.
1793: In OSPFv3, link-local addresses should be used, using global ones is
1794: possible, but it is nonstandard and might be problematic. And definitely,
1795: link-local and global addresses should not be mixed.
1796: </DL>
1797: <P>
1798: <H3><A NAME="ospf-attr"></A> Attributes</H3>
1799:
1800: <P>OSPF defines four route attributes. Each internal route has a <CODE>metric</CODE>.
1801: <P>
1802: <P>Metric is ranging from 1 to infinity (65535). External routes use
1803: <CODE>metric type 1</CODE> or <CODE>metric type 2</CODE>. A <CODE>metric of type 1</CODE> is comparable
1804: with internal <CODE>metric</CODE>, a <CODE>metric of type 2</CODE> is always longer than any
1805: <CODE>metric of type 1</CODE> or any <CODE>internal metric</CODE>. <CODE>Internal metric</CODE> or
1806: <CODE>metric of type 1</CODE> is stored in attribute <CODE>ospf_metric1</CODE>, <CODE>metric type
1807: 2</CODE> is stored in attribute <CODE>ospf_metric2</CODE>. If you specify both metrics only
1808: metric1 is used.
1809: <P>
1810: <P>Each external route can also carry attribute <CODE>ospf_tag</CODE> which is a 32-bit
1811: integer which is used when exporting routes to other protocols; otherwise, it
1812: doesn't affect routing inside the OSPF domain at all. The fourth attribute
1813: <CODE>ospf_router_id</CODE> is a router ID of the router advertising that route /
1814: network. This attribute is read-only. Default is <CODE>ospf_metric2 = 10000</CODE> and
1815: <CODE>ospf_tag = 0</CODE>.
1816: <P>
1817: <H3><A NAME="ospf-exam"></A> Example</H3>
1818:
1819: <P>
1820: <HR>
1821: <PRE>
1822: protocol ospf MyOSPF {
1823: rfc1583compat yes;
1824: tick 2;
1825: export filter {
1826: if source = RTS_BGP then {
1827: ospf_metric1 = 100;
1828: accept;
1829: }
1830: reject;
1831: };
1832: area 0.0.0.0 {
1833: interface "eth*" {
1834: cost 11;
1835: hello 15;
1836: priority 100;
1837: retransmit 7;
1838: authentication simple;
1839: password "aaa";
1840: };
1841: interface "ppp*" {
1842: cost 100;
1843: authentication cryptographic;
1844: password "abc" {
1845: id 1;
1846: generate to "22-04-2003 11:00:06";
1847: accept from "17-01-2001 12:01:05";
1848: algorithm hmac sha384;
1849: };
1850: password "def" {
1851: id 2;
1852: generate to "22-07-2005 17:03:21";
1853: accept from "22-02-2001 11:34:06";
1854: algorithm hmac sha512;
1855: };
1856: };
1857: interface "arc0" {
1858: cost 10;
1859: stub yes;
1860: };
1861: interface "arc1";
1862: };
1863: area 120 {
1864: stub yes;
1865: networks {
1866: 172.16.1.0/24;
1867: 172.16.2.0/24 hidden;
1868: }
1869: interface "-arc0" , "arc*" {
1870: type nonbroadcast;
1871: authentication none;
1872: strict nonbroadcast yes;
1873: wait 120;
1874: poll 40;
1875: dead count 8;
1876: neighbors {
1877: 192.168.120.1 eligible;
1878: 192.168.120.2;
1879: 192.168.120.10;
1880: };
1881: };
1882: };
1883: }
1884: </PRE>
1885: <HR>
1886: <P>
1887: <P>
1.1.1.2 ! misho 1888: <H2><A NAME="pipe"></A> <A NAME="ss6.9">6.9</A> <A HREF="bird.html#toc6.9">Pipe</A>
1.1 misho 1889: </H2>
1890:
1891: <H3><A NAME="pipe-intro"></A> Introduction</H3>
1892:
1893: <P>The Pipe protocol serves as a link between two routing tables, allowing
1894: routes to be passed from a table declared as primary (i.e., the one the pipe is
1895: connected to using the <CODE>table</CODE> configuration keyword) to the secondary one
1896: (declared using <CODE>peer table</CODE>) and vice versa, depending on what's allowed by
1897: the filters. Export filters control export of routes from the primary table to
1898: the secondary one, import filters control the opposite direction.
1899: <P>
1900: <P>The Pipe protocol may work in the transparent mode mode or in the opaque
1901: mode. In the transparent mode, the Pipe protocol retransmits all routes from
1902: one table to the other table, retaining their original source and attributes.
1903: If import and export filters are set to accept, then both tables would have
1904: the same content. The transparent mode is the default mode.
1905: <P>
1906: <P>In the opaque mode, the Pipe protocol retransmits optimal route from one
1907: table to the other table in a similar way like other protocols send and receive
1908: routes. Retransmitted route will have the source set to the Pipe protocol, which
1909: may limit access to protocol specific route attributes. This mode is mainly for
1910: compatibility, it is not suggested for new configs. The mode can be changed by
1911: <CODE>mode</CODE> option.
1912: <P>
1913: <P>The primary use of multiple routing tables and the Pipe protocol is for
1914: policy routing, where handling of a single packet doesn't depend only on its
1915: destination address, but also on its source address, source interface, protocol
1916: type and other similar parameters. In many systems (Linux being a good example),
1917: the kernel allows to enforce routing policies by defining routing rules which
1918: choose one of several routing tables to be used for a packet according to its
1919: parameters. Setting of these rules is outside the scope of BIRD's work (on
1920: Linux, you can use the <CODE>ip</CODE> command), but you can create several routing
1921: tables in BIRD, connect them to the kernel ones, use filters to control which
1922: routes appear in which tables and also you can employ the Pipe protocol for
1923: exporting a selected subset of one table to another one.
1924: <P>
1925: <H3><A NAME="pipe-config"></A> Configuration</H3>
1926:
1927: <P>
1928: <DL>
1929: <DT><CODE>
1930: <A NAME="pipe-peer-table"></A> peer table <I>table</I></CODE><DD><P>Defines secondary routing table to connect to. The primary one is
1931: selected by the <CODE>table</CODE> keyword.
1932: <P>
1933: <DT><CODE>
1934: <A NAME="pipe-mode"></A> mode opaque|transparent</CODE><DD><P>Specifies the mode for the pipe to work in. Default is transparent.
1935: </DL>
1936: <P>
1937: <H3><A NAME="pipe-attr"></A> Attributes</H3>
1938:
1939: <P>The Pipe protocol doesn't define any route attributes.
1940: <P>
1941: <H3><A NAME="pipe-exam"></A> Example</H3>
1942:
1943: <P>Let's consider a router which serves as a boundary router of two different
1944: autonomous systems, each of them connected to a subset of interfaces of the
1945: router, having its own exterior connectivity and wishing to use the other AS as
1946: a backup connectivity in case of outage of its own exterior line.
1947: <P>
1948: <P>Probably the simplest solution to this situation is to use two routing tables
1949: (we'll call them <CODE>as1</CODE> and <CODE>as2</CODE>) and set up kernel routing rules, so that
1950: packets having arrived from interfaces belonging to the first AS will be routed
1951: according to <CODE>as1</CODE> and similarly for the second AS. Thus we have split our
1952: router to two logical routers, each one acting on its own routing table, having
1953: its own routing protocols on its own interfaces. In order to use the other AS's
1954: routes for backup purposes, we can pass the routes between the tables through a
1955: Pipe protocol while decreasing their preferences and correcting their BGP paths
1956: to reflect the AS boundary crossing.
1957: <P>
1958: <HR>
1959: <PRE>
1960: table as1; # Define the tables
1961: table as2;
1962:
1963: protocol kernel kern1 { # Synchronize them with the kernel
1964: table as1;
1965: kernel table 1;
1966: }
1967:
1968: protocol kernel kern2 {
1969: table as2;
1970: kernel table 2;
1971: }
1972:
1973: protocol bgp bgp1 { # The outside connections
1974: table as1;
1975: local as 1;
1976: neighbor 192.168.0.1 as 1001;
1977: export all;
1978: import all;
1979: }
1980:
1981: protocol bgp bgp2 {
1982: table as2;
1983: local as 2;
1984: neighbor 10.0.0.1 as 1002;
1985: export all;
1986: import all;
1987: }
1988:
1989: protocol pipe { # The Pipe
1990: table as1;
1991: peer table as2;
1992: export filter {
1993: if net ~ [ 1.0.0.0/8+] then { # Only AS1 networks
1994: if preference>10 then preference = preference-10;
1995: if source=RTS_BGP then bgp_path.prepend(1);
1996: accept;
1997: }
1998: reject;
1999: };
2000: import filter {
2001: if net ~ [ 2.0.0.0/8+] then { # Only AS2 networks
2002: if preference>10 then preference = preference-10;
2003: if source=RTS_BGP then bgp_path.prepend(2);
2004: accept;
2005: }
2006: reject;
2007: };
2008: }
2009: </PRE>
2010: <HR>
2011: <P>
2012: <P>
1.1.1.2 ! misho 2013: <H2><A NAME="radv"></A> <A NAME="ss6.10">6.10</A> <A HREF="bird.html#toc6.10">RAdv</A>
1.1 misho 2014: </H2>
2015:
2016: <H3><A NAME="radv-intro"></A> Introduction</H3>
2017:
2018: <P>The RAdv protocol is an implementation of Router Advertisements, which are
2019: used in the IPv6 stateless autoconfiguration. IPv6 routers send (in irregular
2020: time intervals or as an answer to a request) advertisement packets to connected
2021: networks. These packets contain basic information about a local network (e.g. a
2022: list of network prefixes), which allows network hosts to autoconfigure network
2023: addresses and choose a default route. BIRD implements router behavior as defined
1.1.1.2 ! misho 2024: in <A HREF="http://www.rfc-editor.org/info/rfc4861">RFC 4861</A>, router preferences and specific routes (<A HREF="http://www.rfc-editor.org/info/rfc4191">RFC 4191</A>),
! 2025: and DNS extensions (<A HREF="http://www.rfc-editor.org/info/rfc6106">RFC 6106</A>).
1.1 misho 2026: <P>
2027: <H3><A NAME="radv-config"></A> Configuration</H3>
2028:
2029: <P>There are several classes of definitions in RAdv configuration -- interface
2030: definitions, prefix definitions and DNS definitions:
2031: <P>
2032: <DL>
2033: <DT><CODE>
2034: <A NAME="radv-iface"></A> interface <I>pattern</I> [, <I>...</I>] { <I>options</I> }</CODE><DD><P>Interface definitions specify a set of interfaces on which the
2035: protocol is activated and contain interface specific options.
2036: See
2037: <A HREF="bird-3.html#proto-iface">interface</A> common options for
2038: detailed description.
2039: <P>
2040: <DT><CODE>
2041: <A NAME="radv-prefix"></A> prefix <I>prefix</I> { <I>options</I> }</CODE><DD><P>Prefix definitions allow to modify a list of advertised prefixes. By
2042: default, the advertised prefixes are the same as the network prefixes
2043: assigned to the interface. For each network prefix, the matching prefix
2044: definition is found and its options are used. If no matching prefix
2045: definition is found, the prefix is used with default options.
2046: <P>Prefix definitions can be either global or interface-specific. The
2047: second ones are part of interface options. The prefix definition
2048: matching is done in the first-match style, when interface-specific
2049: definitions are processed before global definitions. As expected, the
2050: prefix definition is matching if the network prefix is a subnet of the
2051: prefix in prefix definition.
2052: <P>
2053: <DT><CODE>
2054: <A NAME="radv-rdnss"></A> rdnss { <I>options</I> }</CODE><DD><P>RDNSS definitions allow to specify a list of advertised recursive DNS
2055: servers together with their options. As options are seldom necessary,
2056: there is also a short variant <CODE>rdnss <I>address</I></CODE> that just
2057: specifies one DNS server. Multiple definitions are cumulative. RDNSS
2058: definitions may also be interface-specific when used inside interface
2059: options. By default, interface uses both global and interface-specific
2060: options, but that can be changed by <CODE>rdnss local</CODE> option.
1.1.1.2 ! misho 2061: <P>
1.1 misho 2062: <DT><CODE>
2063: <A NAME="radv-dnssl"></A> dnssl { <I>options</I> }</CODE><DD><P>DNSSL definitions allow to specify a list of advertised DNS search
2064: domains together with their options. Like <CODE>rdnss</CODE> above, multiple
2065: definitions are cumulative, they can be used also as interface-specific
2066: options and there is a short variant <CODE>dnssl <I>domain</I></CODE> that just
2067: specifies one DNS search domain.
2068: <P>
2069: <DT><CODE>
2070: <A NAME="radv-trigger"></A> trigger <I>prefix</I></CODE><DD><P>RAdv protocol could be configured to change its behavior based on
2071: availability of routes. When this option is used, the protocol waits in
2072: suppressed state until a <I>trigger route</I> (for the specified network)
1.1.1.2 ! misho 2073: is exported to the protocol, the protocol also returns to suppressed
1.1 misho 2074: state if the <I>trigger route</I> disappears. Note that route export
2075: depends on specified export filter, as usual. This option could be used,
2076: e.g., for handling failover in multihoming scenarios.
2077: <P>During suppressed state, router advertisements are generated, but with
2078: some fields zeroed. Exact behavior depends on which fields are zeroed,
2079: this can be configured by <CODE>sensitive</CODE> option for appropriate
2080: fields. By default, just <CODE>default lifetime</CODE> (also called <CODE>router
2081: lifetime</CODE>) is zeroed, which means hosts cannot use the router as a
2082: default router. <CODE>preferred lifetime</CODE> and <CODE>valid lifetime</CODE> could
2083: also be configured as <CODE>sensitive</CODE> for a prefix, which would cause
2084: autoconfigured IPs to be deprecated or even removed.
1.1.1.2 ! misho 2085: <P>
! 2086: <DT><CODE>
! 2087: <A NAME="radv-propagate-routes"></A> propagate routes <I>switch</I></CODE><DD><P>This option controls propagation of more specific routes, as defined in
! 2088: <A HREF="http://www.rfc-editor.org/info/rfc4191">RFC 4191</A>. If enabled, all routes exported to the RAdv protocol,
! 2089: with the exception of the trigger prefix, are added to advertisments as
! 2090: additional options. The lifetime and preference of advertised routes can
! 2091: be set individually by <CODE>ra_lifetime</CODE> and <CODE>ra_preference</CODE> route
! 2092: attributes, or per interface by <CODE>route lifetime</CODE> and
! 2093: <CODE>route preference</CODE> options. Default: disabled.
! 2094: <P>Note that the RFC discourages from sending more than 17 routes and
! 2095: recommends the routes to be configured manually.
1.1 misho 2096: </DL>
2097: <P>
2098: <P>Interface specific options:
2099: <P>
2100: <DL>
2101: <DT><CODE>
2102: <A NAME="radv-iface-max-ra-interval"></A> max ra interval <I>expr</I></CODE><DD><P>Unsolicited router advertisements are sent in irregular time intervals.
2103: This option specifies the maximum length of these intervals, in seconds.
2104: Valid values are 4-1800. Default: 600
2105: <P>
2106: <DT><CODE>
2107: <A NAME="radv-iface-min-ra-interval"></A> min ra interval <I>expr</I></CODE><DD><P>This option specifies the minimum length of that intervals, in seconds.
2108: Must be at least 3 and at most 3/4 * <CODE>max ra interval</CODE>. Default:
2109: about 1/3 * <CODE>max ra interval</CODE>.
2110: <P>
2111: <DT><CODE>
2112: <A NAME="radv-iface-min-delay"></A> min delay <I>expr</I></CODE><DD><P>The minimum delay between two consecutive router advertisements, in
2113: seconds. Default: 3
2114: <P>
2115: <DT><CODE>
2116: <A NAME="radv-iface-managed"></A> managed <I>switch</I></CODE><DD><P>This option specifies whether hosts should use DHCPv6 for IP address
2117: configuration. Default: no
2118: <P>
2119: <DT><CODE>
2120: <A NAME="radv-iface-other-config"></A> other config <I>switch</I></CODE><DD><P>This option specifies whether hosts should use DHCPv6 to receive other
2121: configuration information. Default: no
2122: <P>
2123: <DT><CODE>
2124: <A NAME="radv-iface-link-mtu"></A> link mtu <I>expr</I></CODE><DD><P>This option specifies which value of MTU should be used by hosts. 0
2125: means unspecified. Default: 0
2126: <P>
2127: <DT><CODE>
2128: <A NAME="radv-iface-reachable-time"></A> reachable time <I>expr</I></CODE><DD><P>This option specifies the time (in milliseconds) how long hosts should
2129: assume a neighbor is reachable (from the last confirmation). Maximum is
2130: 3600000, 0 means unspecified. Default 0.
2131: <P>
2132: <DT><CODE>
2133: <A NAME="radv-iface-retrans-timer"></A> retrans timer <I>expr</I></CODE><DD><P>This option specifies the time (in milliseconds) how long hosts should
2134: wait before retransmitting Neighbor Solicitation messages. 0 means
2135: unspecified. Default 0.
2136: <P>
2137: <DT><CODE>
2138: <A NAME="radv-iface-current-hop-limit"></A> current hop limit <I>expr</I></CODE><DD><P>This option specifies which value of Hop Limit should be used by
2139: hosts. Valid values are 0-255, 0 means unspecified. Default: 64
2140: <P>
2141: <DT><CODE>
1.1.1.2 ! misho 2142: <A NAME="radv-iface-default-lifetime"></A> default lifetime <I>expr</I> [sensitive <I>switch</I>]</CODE><DD><P>This option specifies the time (in seconds) how long (since the receipt
1.1 misho 2143: of RA) hosts may use the router as a default router. 0 means do not use
2144: as a default router. For <CODE>sensitive</CODE> option, see
2145: <A HREF="#radv-trigger">trigger</A>.
2146: Default: 3 * <CODE>max ra interval</CODE>, <CODE>sensitive</CODE> yes.
2147: <P>
2148: <DT><CODE>
1.1.1.2 ! misho 2149: <A NAME="radv-iface-default-preference"></A> default preference low|medium|high</CODE><DD><P>This option specifies the Default Router Preference value to advertise
1.1 misho 2150: to hosts. Default: medium.
2151: <P>
2152: <DT><CODE>
1.1.1.2 ! misho 2153: <A NAME="radv-iface-route-lifetime"></A> route lifetime <I>expr</I> [sensitive <I>switch</I>]</CODE><DD><P>This option specifies the default value of advertised lifetime for
! 2154: specific routes; i.e., the time (in seconds) for how long (since the
! 2155: receipt of RA) hosts should consider these routes valid. A special value
! 2156: 0xffffffff represents infinity. The lifetime can be overriden on a per
! 2157: route basis by the
! 2158: <A HREF="#rta-ra-lifetime">ra_lifetime</A> route
! 2159: attribute. Default: 3 * <CODE>max ra interval</CODE>, <CODE>sensitive</CODE> no.
! 2160: <P>For the <CODE>sensitive</CODE> option, see
! 2161: <A HREF="#radv-trigger">trigger</A>.
! 2162: If <CODE>sensitive</CODE> is enabled, even the routes with the <CODE>ra_lifetime</CODE>
! 2163: attribute become sensitive to the trigger.
! 2164: <P>
! 2165: <DT><CODE>
! 2166: <A NAME="radv-iface-route-preference"></A> route preference low|medium|high</CODE><DD><P>This option specifies the default value of advertised route preference
! 2167: for specific routes. The value can be overriden on a per route basis by
! 2168: the
! 2169: <A HREF="#rta-ra-preference">ra_preference</A> route attribute.
! 2170: Default: medium.
! 2171: <P>
! 2172: <DT><CODE>
! 2173: <A NAME="radv-prefix-linger-time"></A> prefix linger time <I>expr</I></CODE><DD><P>When a prefix or a route disappears, it is advertised for some time with
! 2174: zero lifetime, to inform clients it is no longer valid. This option
! 2175: specifies the time (in seconds) for how long prefixes are advertised
! 2176: that way. Default: 3 * <CODE>max ra interval</CODE>.
! 2177: <P>
! 2178: <DT><CODE>
! 2179: <A NAME="radv-route-linger-time"></A> route linger time <I>expr</I></CODE><DD><P>When a prefix or a route disappears, it is advertised for some time with
! 2180: zero lifetime, to inform clients it is no longer valid. This option
! 2181: specifies the time (in seconds) for how long routes are advertised
! 2182: that way. Default: 3 * <CODE>max ra interval</CODE>.
! 2183: <P>
! 2184: <DT><CODE>
1.1 misho 2185: <A NAME="radv-iface-rdnss-local"></A> rdnss local <I>switch</I></CODE><DD><P>Use only local (interface-specific) RDNSS definitions for this
2186: interface. Otherwise, both global and local definitions are used. Could
2187: also be used to disable RDNSS for given interface if no local definitons
2188: are specified. Default: no.
2189: <P>
2190: <DT><CODE>
2191: <A NAME="radv-iface-dnssl-local"></A> dnssl local <I>switch</I></CODE><DD><P>Use only local DNSSL definitions for this interface. See <CODE>rdnss local</CODE>
2192: option above. Default: no.
2193: </DL>
2194: <P>
2195: <P>
2196: <P>Prefix specific options
2197: <P>
2198: <DL>
2199: <DT><CODE>
2200: <A NAME="radv-prefix-skip"></A> skip <I>switch</I></CODE><DD><P>This option allows to specify that given prefix should not be
2201: advertised. This is useful for making exceptions from a default policy
2202: of advertising all prefixes. Note that for withdrawing an already
2203: advertised prefix it is more useful to advertise it with zero valid
2204: lifetime. Default: no
2205: <P>
2206: <DT><CODE>
2207: <A NAME="radv-prefix-onlink"></A> onlink <I>switch</I></CODE><DD><P>This option specifies whether hosts may use the advertised prefix for
2208: onlink determination. Default: yes
2209: <P>
2210: <DT><CODE>
2211: <A NAME="radv-prefix-autonomous"></A> autonomous <I>switch</I></CODE><DD><P>This option specifies whether hosts may use the advertised prefix for
2212: stateless autoconfiguration. Default: yes
2213: <P>
2214: <DT><CODE>
2215: <A NAME="radv-prefix-valid-lifetime"></A> valid lifetime <I>expr</I> [sensitive <I>switch</I>]</CODE><DD><P>This option specifies the time (in seconds) how long (after the
2216: receipt of RA) the prefix information is valid, i.e., autoconfigured
2217: IP addresses can be assigned and hosts with that IP addresses are
2218: considered directly reachable. 0 means the prefix is no longer
2219: valid. For <CODE>sensitive</CODE> option, see
2220: <A HREF="#radv-trigger">trigger</A>.
2221: Default: 86400 (1 day), <CODE>sensitive</CODE> no.
2222: <P>
2223: <DT><CODE>
2224: <A NAME="radv-prefix-preferred-lifetime"></A> preferred lifetime <I>expr</I> [sensitive <I>switch</I>]</CODE><DD><P>This option specifies the time (in seconds) how long (after the
2225: receipt of RA) IP addresses generated from the prefix using stateless
2226: autoconfiguration remain preferred. For <CODE>sensitive</CODE> option,
2227: see
2228: <A HREF="#radv-trigger">trigger</A>. Default: 14400 (4 hours),
2229: <CODE>sensitive</CODE> no.
2230: </DL>
2231: <P>
2232: <P>RDNSS specific options:
2233: <P>
2234: <DL>
2235: <DT><CODE>
2236: <A NAME="radv-rdnss-ns"></A> ns <I>address</I></CODE><DD><P>This option specifies one recursive DNS server. Can be used multiple
2237: times for multiple servers. It is mandatory to have at least one
2238: <CODE>ns</CODE> option in <CODE>rdnss</CODE> definition.
2239: <P>
2240: <DT><CODE>
2241: <A NAME="radv-rdnss-lifetime"></A> lifetime [mult] <I>expr</I></CODE><DD><P>This option specifies the time how long the RDNSS information may be
2242: used by clients after the receipt of RA. It is expressed either in
2243: seconds or (when <CODE>mult</CODE> is used) in multiples of <CODE>max ra
2244: interval</CODE>. Note that RDNSS information is also invalidated when
2245: <CODE>default lifetime</CODE> expires. 0 means these addresses are no longer
2246: valid DNS servers. Default: 3 * <CODE>max ra interval</CODE>.
2247: </DL>
2248: <P>
2249: <P>
2250: <P>DNSSL specific options:
2251: <P>
2252: <DL>
2253: <DT><CODE>
2254: <A NAME="radv-dnssl-domain"></A> domain <I>address</I></CODE><DD><P>This option specifies one DNS search domain. Can be used multiple times
2255: for multiple domains. It is mandatory to have at least one <CODE>domain</CODE>
2256: option in <CODE>dnssl</CODE> definition.
2257: <P>
2258: <DT><CODE>
2259: <A NAME="radv-dnssl-lifetime"></A> lifetime [mult] <I>expr</I></CODE><DD><P>This option specifies the time how long the DNSSL information may be
2260: used by clients after the receipt of RA. Details are the same as for
2261: RDNSS <CODE>lifetime</CODE> option above. Default: 3 * <CODE>max ra interval</CODE>.
2262: </DL>
2263: <P>
1.1.1.2 ! misho 2264: <H3><A NAME="radv-attr"></A> Attributes</H3>
! 2265:
! 2266: <P>RAdv defines two route attributes:
! 2267: <P>
! 2268: <DL>
! 2269: <DT><CODE>
! 2270: <A NAME="rta-ra-preference"></A> enum ra_preference</CODE><DD><P>The preference of the route. The value can be <I>RA_PREF_LOW</I>,
! 2271: <I>RA_PREF_MEDIUM</I> or <I>RA_PREF_HIGH</I>. If the attribute is not set,
! 2272: the
! 2273: <A HREF="#radv-iface-route-preference">route preference</A>
! 2274: option is used.
! 2275: <P>
! 2276: <DT><CODE>
! 2277: <A NAME="rta-ra-lifetime"></A> int ra_lifetime</CODE><DD><P>The advertised lifetime of the route, in seconds. The special value of
! 2278: 0xffffffff represents infinity. If the attribute is not set, the
! 2279: <A HREF="#radv-iface-route-lifetime">route lifetime</A>
! 2280: option is used.
! 2281: </DL>
1.1 misho 2282: <P>
2283: <H3><A NAME="radv-exam"></A> Example</H3>
2284:
2285: <P>
2286: <HR>
2287: <PRE>
1.1.1.2 ! misho 2288: table radv_routes; # Manually configured routes go here
! 2289:
! 2290: protocol static {
! 2291: table radv_routes;
! 2292:
! 2293: route 2001:0DB8:4000::/48 unreachable;
! 2294: route 2001:0DB8:4010::/48 unreachable;
! 2295:
! 2296: route 2001:0DB8:4020::/48 unreachable {
! 2297: ra_preference = RA_PREF_HIGH;
! 2298: ra_lifetime = 3600;
! 2299: };
! 2300: }
! 2301:
1.1 misho 2302: protocol radv {
1.1.1.2 ! misho 2303: propagate routes yes; # Propagate the routes from the radv_routes table
! 2304: table radv_routes;
! 2305: export all;
! 2306:
1.1 misho 2307: interface "eth2" {
2308: max ra interval 5; # Fast failover with more routers
2309: managed yes; # Using DHCPv6 on eth2
2310: prefix ::/0 {
2311: autonomous off; # So do not autoconfigure any IP
2312: };
2313: };
2314:
2315: interface "eth*"; # No need for any other options
2316:
2317: prefix 2001:0DB8:1234::/48 {
2318: preferred lifetime 0; # Deprecated address range
2319: };
2320:
2321: prefix 2001:0DB8:2000::/48 {
2322: autonomous off; # Do not autoconfigure
2323: };
2324:
2325: rdnss 2001:0DB8:1234::10; # Short form of RDNSS
2326:
2327: rdnss {
2328: lifetime mult 10;
2329: ns 2001:0DB8:1234::11;
2330: ns 2001:0DB8:1234::12;
2331: };
2332:
2333: dnssl {
2334: lifetime 3600;
2335: domain "abc.com";
2336: domain "xyz.com";
2337: };
2338: }
2339: </PRE>
2340: <HR>
2341: <P>
2342: <P>
1.1.1.2 ! misho 2343: <H2><A NAME="rip"></A> <A NAME="ss6.11">6.11</A> <A HREF="bird.html#toc6.11">RIP</A>
1.1 misho 2344: </H2>
2345:
2346: <H3><A NAME="rip-intro"></A> Introduction</H3>
2347:
2348: <P>The RIP protocol (also sometimes called Rest In Pieces) is a simple protocol,
2349: where each router broadcasts (to all its neighbors) distances to all networks it
2350: can reach. When a router hears distance to another network, it increments it and
2351: broadcasts it back. Broadcasts are done in regular intervals. Therefore, if some
2352: network goes unreachable, routers keep telling each other that its distance is
2353: the original distance plus 1 (actually, plus interface metric, which is usually
2354: one). After some time, the distance reaches infinity (that's 15 in RIP) and all
2355: routers know that network is unreachable. RIP tries to minimize situations where
2356: counting to infinity is necessary, because it is slow. Due to infinity being 16,
2357: you can't use RIP on networks where maximal distance is higher than 15
2358: hosts.
2359: <P>
2360: <P>BIRD supports RIPv1 (<A HREF="http://www.rfc-editor.org/info/rfc1058">RFC 1058</A>), RIPv2 (<A HREF="http://www.rfc-editor.org/info/rfc2453">RFC 2453</A>), RIPng (<A HREF="http://www.rfc-editor.org/info/rfc2080">RFC 2080</A>), and RIP cryptographic authentication (<A HREF="http://www.rfc-editor.org/info/rfc4822">RFC 4822</A>).
2361: <P>
2362: <P>RIP is a very simple protocol, and it has a lot of shortcomings. Slow
2363: convergence, big network load and inability to handle larger networks makes it
2364: pretty much obsolete. It is still usable on very small networks.
2365: <P>
2366: <H3><A NAME="rip-config"></A> Configuration</H3>
2367:
2368: <P>RIP configuration consists mainly of common protocol options and interface
2369: definitions, most RIP options are interface specific.
2370: <P>
2371: <HR>
2372: <PRE>
2373: protocol rip [<name>] {
2374: infinity <number>;
2375: ecmp <switch> [limit <number>];
2376: interface <interface pattern> {
2377: metric <number>;
2378: mode multicast|broadcast;
2379: passive <switch>;
2380: address <ip>;
2381: port <number>;
2382: version 1|2;
2383: split horizon <switch>;
2384: poison reverse <switch>;
2385: check zero <switch>;
2386: update time <number>;
2387: timeout time <number>;
2388: garbage time <number>;
2389: ecmp weight <number>;
2390: ttl security <switch>; | tx only;
2391: tx class|dscp <number>;
2392: tx priority <number>;
2393: rx buffer <number>;
2394: tx length <number>;
2395: check link <switch>;
2396: authentication none|plaintext|cryptographic;
2397: password "<text>";
2398: password "<text>" {
2399: id <num>;
2400: generate from "<date>";
2401: generate to "<date>";
2402: accept from "<date>";
2403: accept to "<date>";
2404: from "<date>";
2405: to "<date>";
2406: algorithm ( keyed md5 | keyed sha1 | hmac sha1 | hmac sha256 | hmac sha384 | hmac sha512 );
2407: };
2408: };
2409: }
2410: </PRE>
2411: <HR>
2412: <P>
2413: <DL>
2414: <DT><CODE>
2415: <A NAME="rip-infinity"></A> infinity <I>number</I></CODE><DD><P>Selects the distance of infinity. Bigger values will make
2416: protocol convergence even slower. The default value is 16.
2417: <P>
2418: <DT><CODE>
2419: <A NAME="rip-ecmp"></A> ecmp <I>switch</I> [limit <I>number</I>]</CODE><DD><P>This option specifies whether RIP is allowed to generate ECMP
2420: (equal-cost multipath) routes. Such routes are used when there are
2421: several directions to the destination, each with the same (computed)
2422: cost. This option also allows to specify a limit on maximum number of
2423: nexthops in one route. By default, ECMP is disabled. If enabled,
2424: default value of the limit is 16.
2425: <P>
2426: <DT><CODE>
2427: <A NAME="rip-iface"></A> interface <I>pattern</I> [, <I>...</I>] { <I>options</I> }</CODE><DD><P>Interface definitions specify a set of interfaces on which the
2428: protocol is activated and contain interface specific options.
2429: See
2430: <A HREF="bird-3.html#proto-iface">interface</A> common options for
2431: detailed description.
2432: </DL>
2433: <P>
2434: <P>Interface specific options:
2435: <P>
2436: <DL>
2437: <DT><CODE>
2438: <A NAME="rip-iface-metric"></A> metric <I>num</I></CODE><DD><P>This option specifies the metric of the interface. When a route is
2439: received from the interface, its metric is increased by this value
2440: before further processing. Valid values are 1-255, but values higher
2441: than infinity has no further meaning. Default: 1.
2442: <P>
2443: <DT><CODE>
2444: <A NAME="rip-iface-mode"></A> mode multicast|broadcast</CODE><DD><P>This option selects the mode for RIP to use on the interface. The
2445: default is multicast mode for RIPv2 and broadcast mode for RIPv1.
2446: RIPng always uses the multicast mode.
2447: <P>
2448: <DT><CODE>
2449: <A NAME="rip-iface-passive"></A> passive <I>switch</I></CODE><DD><P>Passive interfaces receive routing updates but do not transmit any
2450: messages. Default: no.
2451: <P>
2452: <DT><CODE>
2453: <A NAME="rip-iface-address"></A> address <I>ip</I></CODE><DD><P>This option specifies a destination address used for multicast or
2454: broadcast messages, the default is the official RIP (224.0.0.9) or RIPng
2455: (ff02::9) multicast address, or an appropriate broadcast address in the
2456: broadcast mode.
2457: <P>
2458: <DT><CODE>
2459: <A NAME="rip-iface-port"></A> port <I>number</I></CODE><DD><P>This option selects an UDP port to operate on, the default is the
2460: official RIP (520) or RIPng (521) port.
2461: <P>
2462: <DT><CODE>
2463: <A NAME="rip-iface-version"></A> version 1|2</CODE><DD><P>This option selects the version of RIP used on the interface. For RIPv1,
2464: automatic subnet aggregation is not implemented, only classful network
2465: routes and host routes are propagated. Note that BIRD allows RIPv1 to be
2466: configured with features that are defined for RIPv2 only, like
2467: authentication or using multicast sockets. The default is RIPv2 for IPv4
2468: RIP, the option is not supported for RIPng, as no further versions are
2469: defined.
2470: <P>
2471: <DT><CODE>
2472: <A NAME="rip-iface-version-only"></A> version only <I>switch</I></CODE><DD><P>Regardless of RIP version configured for the interface, BIRD accepts
2473: incoming packets of any RIP version. This option restrict accepted
2474: packets to the configured version. Default: no.
2475: <P>
2476: <DT><CODE>
2477: <A NAME="rip-iface-split-horizon"></A> split horizon <I>switch</I></CODE><DD><P>Split horizon is a scheme for preventing routing loops. When split
2478: horizon is active, routes are not regularly propagated back to the
2479: interface from which they were received. They are either not propagated
2480: back at all (plain split horizon) or propagated back with an infinity
2481: metric (split horizon with poisoned reverse). Therefore, other routers
2482: on the interface will not consider the router as a part of an
2483: independent path to the destination of the route. Default: yes.
2484: <P>
2485: <DT><CODE>
2486: <A NAME="rip-iface-poison-reverse"></A> poison reverse <I>switch</I></CODE><DD><P>When split horizon is active, this option specifies whether the poisoned
2487: reverse variant (propagating routes back with an infinity metric) is
2488: used. The poisoned reverse has some advantages in faster convergence,
2489: but uses more network traffic. Default: yes.
2490: <P>
2491: <DT><CODE>
2492: <A NAME="rip-iface-check-zero"></A> check zero <I>switch</I></CODE><DD><P>Received RIPv1 packets with non-zero values in reserved fields should
2493: be discarded. This option specifies whether the check is performed or
2494: such packets are just processed as usual. Default: yes.
2495: <P>
2496: <DT><CODE>
2497: <A NAME="rip-iface-update-time"></A> update time <I>number</I></CODE><DD><P>Specifies the number of seconds between periodic updates. A lower number
2498: will mean faster convergence but bigger network load. Default: 30.
2499: <P>
2500: <DT><CODE>
2501: <A NAME="rip-iface-timeout-time"></A> timeout time <I>number</I></CODE><DD><P>Specifies the time interval (in seconds) between the last received route
2502: announcement and the route expiration. After that, the network is
2503: considered unreachable, but still is propagated with infinity distance.
2504: Default: 180.
2505: <P>
2506: <DT><CODE>
2507: <A NAME="rip-iface-garbage-time"></A> garbage time <I>number</I></CODE><DD><P>Specifies the time interval (in seconds) between the route expiration
2508: and the removal of the unreachable network entry. The garbage interval,
2509: when a route with infinity metric is propagated, is used for both
2510: internal (after expiration) and external (after withdrawal) routes.
2511: Default: 120.
2512: <P>
2513: <DT><CODE>
2514: <A NAME="rip-iface-ecmp-weight"></A> ecmp weight <I>number</I></CODE><DD><P>When ECMP (multipath) routes are allowed, this value specifies a
2515: relative weight used for nexthops going through the iface. Valid
2516: values are 1-256. Default value is 1.
2517: <P>
2518: <DT><CODE>
2519: <A NAME="rip-iface-auth"></A> authentication none|plaintext|cryptographic</CODE><DD><P>Selects authentication method to be used. <CODE>none</CODE> means that packets
2520: are not authenticated at all, <CODE>plaintext</CODE> means that a plaintext
2521: password is embedded into each packet, and <CODE>cryptographic</CODE> means that
2522: packets are authenticated using some cryptographic hash function
2523: selected by option <CODE>algorithm</CODE> for each key. The default
2524: cryptographic algorithm for RIP keys is Keyed-MD5. If you set
2525: authentication to not-none, it is a good idea to add <CODE>password</CODE>
2526: section. Default: none.
2527: <P>
2528: <DT><CODE>
2529: <A NAME="rip-iface-pass"></A> password "<I>text</I>"</CODE><DD><P>Specifies a password used for authentication. See
2530: <A HREF="bird-3.html#proto-pass">password</A> common option for detailed description.
2531: <P>
2532: <DT><CODE>
2533: <A NAME="rip-iface-ttl-security"></A> ttl security [<I>switch</I> | tx only]</CODE><DD><P>TTL security is a feature that protects routing protocols from remote
2534: spoofed packets by using TTL 255 instead of TTL 1 for protocol packets
2535: destined to neighbors. Because TTL is decremented when packets are
2536: forwarded, it is non-trivial to spoof packets with TTL 255 from remote
2537: locations.
2538: <P>If this option is enabled, the router will send RIP packets with TTL 255
2539: and drop received packets with TTL less than 255. If this option si set
2540: to <CODE>tx only</CODE>, TTL 255 is used for sent packets, but is not checked
2541: for received packets. Such setting does not offer protection, but offers
2542: compatibility with neighbors regardless of whether they use ttl
2543: security.
2544: <P>For RIPng, TTL security is a standard behavior (required by <A HREF="http://www.rfc-editor.org/info/rfc2080">RFC 2080</A>) and therefore default value is yes. For IPv4 RIP, default
2545: value is no.
2546: <P>
2547: <DT><CODE>
2548: <A NAME="rip-iface-tx-class"></A> tx class|dscp|priority <I>number</I></CODE><DD><P>These options specify the ToS/DiffServ/Traffic class/Priority of the
2549: outgoing RIP packets. See
2550: <A HREF="bird-3.html#proto-tx-class">tx class</A> common
2551: option for detailed description.
2552: <P>
2553: <DT><CODE>
2554: <A NAME="rip-iface-rx-buffer"></A> rx buffer <I>number</I></CODE><DD><P>This option specifies the size of buffers used for packet processing.
2555: The buffer size should be bigger than maximal size of received packets.
2556: The default value is 532 for IPv4 RIP and interface MTU value for RIPng.
2557: <P>
2558: <DT><CODE>
2559: <A NAME="rip-iface-tx-length"></A> tx length <I>number</I></CODE><DD><P>This option specifies the maximum length of generated RIP packets. To
2560: avoid IP fragmentation, it should not exceed the interface MTU value.
2561: The default value is 532 for IPv4 RIP and interface MTU value for RIPng.
2562: <P>
2563: <DT><CODE>
2564: <A NAME="rip-iface-check-link"></A> check link <I>switch</I></CODE><DD><P>If set, the hardware link state (as reported by OS) is taken into
2565: consideration. When the link disappears (e.g. an ethernet cable is
2566: unplugged), neighbors are immediately considered unreachable and all
2567: routes received from them are withdrawn. It is possible that some
2568: hardware drivers or platforms do not implement this feature.
2569: Default: no.
2570: </DL>
2571: <P>
2572: <H3><A NAME="rip-attr"></A> Attributes</H3>
2573:
2574: <P>RIP defines two route attributes:
2575: <P>
2576: <DL>
2577: <DT><CODE>
1.1.1.2 ! misho 2578: <A NAME="rta-rip-metric"></A> int rip_metric</CODE><DD><P>RIP metric of the route (ranging from 0 to <CODE>infinity</CODE>). When routes
1.1 misho 2579: from different RIP instances are available and all of them have the same
2580: preference, BIRD prefers the route with lowest <CODE>rip_metric</CODE>. When a
2581: non-RIP route is exported to RIP, the default metric is 1.
2582: <P>
2583: <DT><CODE>
1.1.1.2 ! misho 2584: <A NAME="rta-rip-tag"></A> int rip_tag</CODE><DD><P>RIP route tag: a 16-bit number which can be used to carry additional
1.1 misho 2585: information with the route (for example, an originating AS number in
2586: case of external routes). When a non-RIP route is exported to RIP, the
2587: default tag is 0.
2588: </DL>
2589: <P>
2590: <H3><A NAME="rip-exam"></A> Example</H3>
2591:
2592: <P>
2593: <HR>
2594: <PRE>
2595: protocol rip {
1.1.1.2 ! misho 2596: import all;
! 2597: export all;
! 2598: interface "eth*" {
! 2599: metric 2;
! 2600: port 1520;
! 2601: mode multicast;
! 2602: update time 12;
! 2603: timeout time 60;
! 2604: authentication cryptographic;
! 2605: password "secret" { algorithm hmac sha256; };
! 2606: };
1.1 misho 2607: }
2608: </PRE>
2609: <HR>
2610: <P>
2611: <P>
1.1.1.2 ! misho 2612: <H2><A NAME="static"></A> <A NAME="ss6.12">6.12</A> <A HREF="bird.html#toc6.12">Static</A>
1.1 misho 2613: </H2>
2614:
2615: <P>The Static protocol doesn't communicate with other routers in the network,
2616: but instead it allows you to define routes manually. This is often used for
2617: specifying how to forward packets to parts of the network which don't use
2618: dynamic routing at all and also for defining sink routes (i.e., those telling to
2619: return packets as undeliverable if they are in your IP block, you don't have any
2620: specific destination for them and you don't want to send them out through the
2621: default route to prevent routing loops).
2622: <P>
2623: <P>There are five types of static routes: `classical' routes telling to forward
2624: packets to a neighboring router, multipath routes specifying several (possibly
2625: weighted) neighboring routers, device routes specifying forwarding to hosts on a
2626: directly connected network, recursive routes computing their nexthops by doing
2627: route table lookups for a given IP, and special routes (sink, blackhole etc.)
2628: which specify a special action to be done instead of forwarding the packet.
2629: <P>
2630: <P>When the particular destination is not available (the interface is down or
2631: the next hop of the route is not a neighbor at the moment), Static just
2632: uninstalls the route from the table it is connected to and adds it again as soon
2633: as the destination becomes adjacent again.
2634: <P>
2635: <P>There are three classes of definitions in Static protocol configuration --
2636: global options, static route definitions, and per-route options. Usually, the
2637: definition of the protocol contains mainly a list of static routes.
2638: <P>
2639: <P>Global options:
2640: <P>
2641: <DL>
2642: <DT><CODE>
2643: <A NAME="static-check-link"></A> check link <I>switch</I></CODE><DD><P>If set, hardware link states of network interfaces are taken into
2644: consideration. When link disappears (e.g. ethernet cable is unplugged),
2645: static routes directing to that interface are removed. It is possible
2646: that some hardware drivers or platforms do not implement this feature.
2647: Default: off.
2648: <P>
2649: <DT><CODE>
2650: <A NAME="static-igp-table"></A> igp table <I>name</I></CODE><DD><P>Specifies a table that is used for route table lookups of recursive
2651: routes. Default: the same table as the protocol is connected to.
2652: </DL>
2653: <P>
2654: <P>Route definitions (each may also contain a block of per-route options):
2655: <P>
2656: <DL>
2657: <DT><CODE>
2658: <A NAME="static-route-via-ip"></A> route <I>prefix</I> via <I>ip</I></CODE><DD><P>Static route through a neighboring router. For link-local next hops,
2659: interface can be specified as a part of the address (e.g.,
2660: <CODE>via fe80::1234%eth0</CODE>).
2661: <P>
2662: <DT><CODE>
2663: <A NAME="static-route-via-mpath"></A> route <I>prefix</I> multipath via <I>ip</I> [weight <I>num</I>] [bfd <I>switch</I>] [via <I>...</I>]</CODE><DD><P>Static multipath route. Contains several nexthops (gateways), possibly
2664: with their weights.
2665: <P>
2666: <DT><CODE>
2667: <A NAME="static-route-via-iface"></A> route <I>prefix</I> via <I>"interface"</I></CODE><DD><P>Static device route through an interface to hosts on a directly
2668: connected network.
2669: <P>
2670: <DT><CODE>
2671: <A NAME="static-route-recursive"></A> route <I>prefix</I> recursive <I>ip</I></CODE><DD><P>Static recursive route, its nexthop depends on a route table lookup for
2672: given IP address.
2673: <P>
2674: <DT><CODE>
2675: <A NAME="static-route-drop"></A> route <I>prefix</I> blackhole|unreachable|prohibit</CODE><DD><P>Special routes specifying to silently drop the packet, return it as
2676: unreachable or return it as administratively prohibited. First two
2677: targets are also known as <CODE>drop</CODE> and <CODE>reject</CODE>.
2678: </DL>
2679: <P>
2680: <P>Per-route options:
2681: <P>
2682: <DL>
2683: <DT><CODE>
2684: <A NAME="static-route-bfd"></A> bfd <I>switch</I></CODE><DD><P>The Static protocol could use BFD protocol for next hop liveness
2685: detection. If enabled, a BFD session to the route next hop is created
2686: and the static route is BFD-controlled -- the static route is announced
2687: only if the next hop liveness is confirmed by BFD. If the BFD session
2688: fails, the static route is removed. Note that this is a bit different
2689: compared to other protocols, which may use BFD as an advisory mechanism
2690: for fast failure detection but ignores it if a BFD session is not even
2691: established.
2692: <P>This option can be used for static routes with a direct next hop, or
2693: also for for individual next hops in a static multipath route (see
2694: above). Note that BFD protocol also has to be configured, see
2695: <A HREF="#bfd">BFD</A> section for details. Default value is no.
2696: <P>
2697: <DT><CODE>
2698: <A NAME="static-route-filter"></A> <I>filter expression</I></CODE><DD><P>This is a special option that allows filter expressions to be configured
2699: on per-route basis. Can be used multiple times. These expressions are
2700: evaluated when the route is originated, similarly to the import filter
2701: of the static protocol. This is especially useful for configuring route
2702: attributes, e.g., <CODE>ospf_metric1 = 100;</CODE> for a route that will be
2703: exported to the OSPF protocol.
2704: </DL>
2705: <P>
2706: <P>Static routes have no specific attributes.
2707: <P>
2708: <P>Example static config might look like this:
2709: <P>
2710: <P>
2711: <HR>
2712: <PRE>
2713: protocol static {
2714: table testable; # Connect to a non-default routing table
2715: check link; # Advertise routes only if link is up
2716: route 0.0.0.0/0 via 198.51.100.130; # Default route
2717: route 10.0.0.0/8 multipath # Multipath route
2718: via 198.51.100.10 weight 2
2719: via 198.51.100.20 bfd # BFD-controlled next hop
2720: via 192.0.2.1;
2721: route 203.0.113.0/24 unreachable; # Sink route
2722: route 10.2.0.0/24 via "arc0"; # Secondary network
2723: route 192.168.10.0/24 via 198.51.100.100 {
2724: ospf_metric1 = 20; # Set extended attribute
2725: }
2726: route 192.168.10.0/24 via 198.51.100.100 {
2727: ospf_metric2 = 100; # Set extended attribute
2728: ospf_tag = 2; # Set extended attribute
2729: bfd; # BFD-controlled route
2730: }
2731: }
2732: </PRE>
2733: <HR>
2734: <P>
2735: <P>
2736: <HR>
2737: <A HREF="bird-7.html">Next</A>
2738: <A HREF="bird-5.html">Previous</A>
2739: <A HREF="bird.html#toc6">Contents</A>
2740: </BODY>
2741: </HTML>
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to bird-6.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