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

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

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