diff options
Diffstat (limited to 'doc/bird.sgml')
| -rw-r--r-- | doc/bird.sgml | 96 |
1 files changed, 81 insertions, 15 deletions
diff --git a/doc/bird.sgml b/doc/bird.sgml index 8594b930..e0b60c81 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -561,7 +561,7 @@ include "tablename.conf";; can be seen (together with other symbols) using 'show symbols' command. <tag><label id="opt-attribute">attribute <m/type/ <m/name/</tag> - Define a custom route attribute. You can set and get it in filters like + Declare a custom route attribute. You can set and get it in filters like any other route atribute. This feature is intended for marking routes in import filters for export filtering purposes instead of locally assigned BGP communities which have to be deleted in export filters. @@ -1159,7 +1159,7 @@ int var; <p>As you can see, a filter has a header, a list of local variables, and a body. The header consists of the <cf/filter/ keyword followed by a (unique) name of filter. The list of local variables consists of <cf><M>type name</M>;</cf> -pairs where each pair defines one local variable. The body consists of <cf> +pairs where each pair declares one local variable. The body consists of <cf> { <M>statements</M> }</cf>. Each <m/statement/ is terminated by a <cf/;/. You can group several statements to a single compound statement by using braces (<cf>{ <M>statements</M> }</cf>) which is useful if you want to make a bigger @@ -1188,7 +1188,7 @@ called like in C: <cf>name(); with_parameters(5);</cf>. Function may return values using the <cf>return <m/[expr]/</cf> command. Returning a value exits from current function (this is similar to C). -<p>Filters are declared in a way similar to functions except they can't have +<p>Filters are defined in a way similar to functions except they can't have explicit parameters. They get a route table entry as an implicit parameter, it is also passed automatically to any functions called. The filter must terminate with either <cf/accept/ or <cf/reject/ statement. If there's a runtime error in @@ -1571,11 +1571,20 @@ if 1234 = i then printn "."; else { <label id="route-attributes"> <p>A filter is implicitly passed a route, and it can access its attributes just -like it accesses variables. Attempts to access undefined attribute result in a -runtime error; you can check if an attribute is defined by using the -<cf>defined( <m>attribute</m> )</cf> operator. One notable exception to this -rule are attributes of bgppath and *clist types, where undefined value is -regarded as empty bgppath/*clist for most purposes. +like it accesses variables. There are common route attributes, protocol-specific +route attributes and custom route attributes. Most common attributes are +mandatory (always defined), while remaining are optional. Attempts to access +undefined attribute result in a runtime error; you can check if an attribute is +defined by using the <cf>defined( <m>attribute</m> )</cf> operator. One notable +exception to this rule are attributes of bgppath and *clist types, where +undefined value is regarded as empty bgppath/*clist for most purposes. + +Attributes can be defined by just setting them in filters. Custom attributes +have to be first declared by <ref id="opt-attribute" name="attribute"> global +option. You can also undefine optional attribute back to non-existence by using +the <cf>unset( <m/attribute/ )</cf> operator. + +Common route attributes are: <descrip> <tag><label id="rta-net"><m/prefix/ net</tag> @@ -1642,8 +1651,8 @@ regarded as empty bgppath/*clist for most purposes. compare internal distances to boundary routers (see below). </descrip> -<p>There also exist protocol-specific attributes which are described in the -corresponding protocol sections. +<p>Protocol-specific route attributes are described in the corresponding +protocol sections. <sect>Other statements @@ -1653,7 +1662,7 @@ corresponding protocol sections. <descrip> <tag><label id="assignment"><m/variable/ = <m/expr/</tag> - Set variable to a given value. + Set variable (or route attribute) to a given value. <tag><label id="filter-accept-reject">accept|reject [ <m/expr/ ]</tag> Accept or reject the route, possibly printing <cf><m>expr</m></cf>. @@ -2186,12 +2195,23 @@ using the following configuration parameters: <cf/local 10.0.0.1; local as 65000;/ are valid). This parameter is mandatory. - <tag><label id="bgp-neighbor">neighbor [<m/ip/] [port <m/number/] [as <m/number/]</tag> + <tag><label id="bgp-neighbor">neighbor [<m/ip/ | range <m/prefix/] [port <m/number/] [as <m/number/] [internal|external]</tag> Define neighboring router this instance will be talking to and what AS it is located in. In case the neighbor is in the same AS as we are, we - automatically switch to iBGP. Optionally, the remote port may also be - specified. Like <cf/local/ parameter, this parameter may also be used - multiple times with different sub-options. This parameter is mandatory. + automatically switch to IBGP. Alternatively, it is possible to specify + just <cf/internal/ or </cf/external/ instead of AS number, in that case + either local AS number, or any external AS number is accepted. + Optionally, the remote port may also be specified. Like <cf/local/ + parameter, this parameter may also be used multiple times with different + sub-options. This parameter is mandatory. + + It is possible to specify network prefix (with <cf/range/ keyword) + instead of explicit neighbor IP address. This enables dynamic BGP + behavior, where the BGP instance listens on BGP port, but new BGP + instances are spawned for incoming BGP connections (if source address + matches the network prefix). It is possible to mix regular BGP instances + with dynamic BGP instances and have multiple dynamic BGP instances with + different ranges. <tag><label id="bgp-iface">interface <m/string/</tag> Define interface we should use for link-local BGP IPv6 sessions. @@ -2224,6 +2244,16 @@ using the following configuration parameters: session. Default: the address of the local end of the interface our neighbor is connected to. + <tag><label id="bgp-dynamic-name">dynamic name "<m/text/"</tag> + Define common prefix of names used for new BGP instances spawned when + dynamic BGP behavior is active. Actual names also contain numberic + index to distinguish individual instances. Default: "dynbgp". + + <tag><label id="bgp-dynamic-name">dynamic name digits <m/number/</tag> + Define minimum number of digits for index in names of spawned dynamic + BGP instances. E.g., if set to 2, then the first name would be + "dynbgp01". Default: 0. + <tag><label id="bgp-strict-bind">strict bind <m/switch/</tag> Specify whether BGP listening socket should be bound to a specific local address (the same as the <cf/source address/) and associated interface, @@ -2565,6 +2595,15 @@ be used in explicit configuration. <p>BGP channels have additional config options (together with the common ones): <descrip> + <tag><label id="bgp-mandatory">mandatory <m/switch/</tag> + When local and neighbor sets of configured AFI/SAFI pairs differ, + capability negotiation ensures that a common subset is used. For + mandatory channels their associated AFI/SAFI must be negotiated + (i.e., also announced by the neighbor), otherwise BGP session + negotiation fails with <it/'Required capability missing'/ error. + Regardless, at least one AFI/SAFI must be negotiated in order to BGP + session be successfully established. Default: off. + <tag><label id="bgp-next-hop-keep">next hop keep <m/switch/|ibgp|ebgp</tag> Do not modify the Next Hop attribute and advertise the current one unchanged even in cases where our own local address should be used @@ -3230,6 +3269,8 @@ protocol ospf [v2|v3] <name> { tick <num>; ecmp <switch> [limit <num>]; merge external <switch>; + graceful restart <switch>|aware; + graceful restart time <num>; area <id> { stub; nssa; @@ -3373,6 +3414,31 @@ protocol ospf [v2|v3] <name> { from different LSAs are treated as separate even if they represents the same destination. Default value is no. + <tag><label id="ospf-graceful-restart">graceful restart <m/switch/|aware</tag> + When an OSPF instance is restarted, neighbors break adjacencies and + recalculate their routing tables, which disrupts packet forwarding even + when the forwarding plane of the restarting router remains intact. + <rfc id="3623"> specifies a graceful restart mechanism to alleviate this + issue. For OSPF graceful restart, restarting router originates + Grace-LSAs, announcing intent to do graceful restart. Neighbors + receiving these LSAs enter helper mode, in which they ignore breakdown + of adjacencies, behave as if nothing is happening and keep old routes. + When adjacencies are reestablished, the restarting router flushes + Grace-LSAs and graceful restart is ended. + + This option controls the graceful restart mechanism. It has three + states: Disabled, when no support is provided. Aware, when graceful + restart helper mode is supported, but no local graceful restart is + allowed (i.e. helper-only role). Enabled, when the full graceful restart + support is provided (i.e. both restarting and helper role). Note that + proper support for local graceful restart requires also configuration of + other protocols. Default: aware. + + <tag><label id="ospf-graceful-restart-time">graceful restart time <m/num/</tag> + The restart time is announced in the Grace-LSA and specifies how long + neighbors should wait for proper end of the graceful restart before + exiting helper mode prematurely. Default: 120 seconds. + <tag><label id="ospf-area">area <M>id</M></tag> This defines an OSPF area with given area ID (an integer or an IPv4 address, similarly to a router ID). The most important area is the |