diff options
Diffstat (limited to 'doc/bird.sgml')
| -rw-r--r-- | doc/bird.sgml | 195 |
1 files changed, 192 insertions, 3 deletions
diff --git a/doc/bird.sgml b/doc/bird.sgml index 3cd80c32..3bc0e453 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -1244,6 +1244,178 @@ undefined value is regarded as empty clist for most purposes. <chapt>Protocols +<sect><label id="sect-bfd">BFD + +<sect1>Introduction + +<p>Bidirectional Forwarding Detection (BFD) is not a routing protocol itself, it +is an independent tool providing liveness and failure detection. Routing +protocols like OSPF and BGP use integrated periodic "hello" messages to monitor +liveness of neighbors, but detection times of these mechanisms are high (e.g. 40 +seconds by default in OSPF, could be set down to several seconds). BFD offers +universal, fast and low-overhead mechanism for failure detection, which could be +attached to any routing protocol in an advisory role. + +<p>BFD consists of mostly independent BFD sessions. Each session monitors an +unicast bidirectional path between two BFD-enabled routers. This is done by +periodically sending control packets in both directions. BFD does not handle +neighbor discovery, BFD sessions are created on demand by request of other +protocols (like OSPF or BGP), which supply appropriate information like IP +addresses and associated interfaces. When a session changes its state, these +protocols are notified and act accordingly (e.g. break an OSPF adjacency when +the BFD session went down). + +<p>BIRD implements basic BFD behavior as defined in +RFC 5880<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5880.txt"> +(some advanced features like the echo mode or authentication are not implemented), +IP transport for BFD as defined in +RFC 5881<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5881.txt"> and +RFC 5883<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5883.txt"> +and interaction with client protocols as defined in +RFC 5882<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5882.txt">. + +<p>Note that BFD implementation in BIRD is currently a new feature in +development, expect some rough edges and possible UI and configuration changes +in the future. Also note that we currently support at most one protocol instance. + +<sect1>Configuration + +<p>BFD configuration consists mainly of multiple definitions of interfaces. +Most BFD config options are session specific. When a new session is requested +and dynamically created, it is configured from one of these definitions. For +sessions to directly connected neighbors, <cf/interface/ definitions are chosen +based on the interface associated with the session, while <cf/multihop/ +definition is used for multihop sessions. If no definition is relevant, the +session is just created with the default configuration. Therefore, an empty BFD +configuration is often sufficient. + +<p>Note that to use BFD for other protocols like OSPF or BGP, these protocols +also have to be configured to request BFD sessions, usually by <cf/bfd/ option. + +<p>Some of BFD session options require <m/time/ value, which has to be specified +with the appropriate unit: <m/num/ <cf/s/|<cf/ms/|<cf/us/. Although microseconds +are allowed as units, practical minimum values are usually in order of tens of +milliseconds. + +<code> +protocol bfd [<name>] { + interface <interface pattern> { + interval <time>; + min rx interval <time>; + min tx interval <time>; + idle tx interval <time>; + multiplier <num>; + passive <switch>; + }; + multihop { + interval <time>; + min rx interval <time>; + min tx interval <time>; + idle tx interval <time>; + multiplier <num>; + passive <switch>; + }; + neighbor <ip> [dev "<interface>"] [local <ip>] [multihop <switch>]; +} +</code> + +<descrip> + <tag>interface <m/pattern [, ...]/ { <m/options/ }</tag> + Interface definitions allow to specify options for sessions associated + with such interfaces and also may contain interface specific options. + See <ref id="dsc-iface" name="interface"> common option for a detailed + description of interface patterns. Note that contrary to the behavior of + <cf/interface/ definitions of other protocols, BFD protocol would accept + sessions (in default configuration) even on interfaces not covered by + such definitions. + + <tag>multihop { <m/options/ }</tag> + Multihop definitions allow to specify options for multihop BFD sessions, + in the same manner as <cf/interface/ definitions are used for directly + connected sessions. Currently only one such definition (for all multihop + sessions) could be used. + + <tag>neighbor <m/ip/ [dev "<m/interface/"] [local <m/ip/] [multihop <m/switch/]</tag> + BFD sessions are usually created on demand as requested by other + protocols (like OSPF or BGP). This option allows to explicitly add + a BFD session to the specified neighbor regardless of such requests. + + The session is identified by the IP address of the neighbor, with + optional specification of used interface and local IP. By default + the neighbor must be directly connected, unless the the session is + configured as multihop. Note that local IP must be specified for + multihop sessions. +</descrip> + +<p>Session specific options (part of <cf/interface/ and <cf/multihop/ definitions): + +<descrip> + <tag>interval <m/time/</tag> + BFD ensures availability of the forwarding path associated with the + session by periodically sending BFD control packets in both + directions. The rate of such packets is controlled by two options, + <cf/min rx interval/ and <cf/min tx interval/ (see below). This option + is just a shorthand to set both of these options together. + + <tag>min rx interval <m/time/</tag> + This option specifies the minimum RX interval, which is announced to the + neighbor and used there to limit the neighbor's rate of generated BFD + control packets. Default: 10 ms. + + <tag>min tx interval <m/time/</tag> + This option specifies the desired TX interval, which controls the rate + of generated BFD control packets (together with <cf/min rx interval/ + announced by the neighbor). Note that this value is used only if the BFD + session is up, otherwise the value of <cf/idle tx interval/ is used + instead. Default: 100 ms. + + <tag>idle tx interval <m/time/</tag> + In order to limit unnecessary traffic in cases where a neighbor is not + available or not running BFD, the rate of generated BFD control packets + is lower when the BFD session is not up. This option specifies the + desired TX interval in such cases instead of <cf/min tx interval/. + Default: 1 s. + + <tag>multiplier <m/num/</tag> + Failure detection time for BFD sessions is based on established rate of + BFD control packets (<cf>min rx/tx interval</cf>) multiplied by this + multiplier, which is essentially (ignoring jitter) a number of missed + packets after which the session is declared down. Note that rates and + multipliers could be different in each direction of a BFD session. + Default: 5. + + <tag>passive <m/switch/</tag> + Generally, both BFD session endpoinds try to establish the session by + sending control packets to the other side. This option allows to enable + passive mode, which means that the router does not send BFD packets + until it has received one from the other side. Default: disabled. +</descrip> + +<sect1>Example + +<p><code> +protocol bfd { + interface "eth*" { + min rx interval 20 ms; + min tx interval 50 ms; + idle tx interval 300 ms; + }; + interface "gre*" { + interval 200 ms; + multiplier 10; + passive; + }; + multihop { + interval 200 ms; + multiplier 10; + }; + + neighbor 192.168.1.10; + neighbor 192.168.2.2 dev "eth2"; + neighbor 192.168.10.1 local 192.168.1.1 multihop; +} +</code> + <sect>BGP <p>The Border Gateway Protocol is the routing protocol used for backbone @@ -1258,8 +1430,8 @@ AS). Each AS is a part of the network with common management and common routing policy. It is identified by a unique 16-bit number (ASN). Routers within each AS usually exchange AS-internal routing information with each other using an interior gateway protocol (IGP, -such as OSPF or RIP). Boundary routers at the border of -the AS communicate global (inter-AS) network reachability information with +such as OSPF or RIP). Boundary routers at the border of the AS +communicate global (inter-AS) network reachability information with their neighbors in the neighboring AS'es via exterior BGP (eBGP) and redistribute received information to other routers in the AS via interior BGP (iBGP). @@ -1412,7 +1584,15 @@ for each neighbor using the following configuration parameters: <tag>igp table <m/name/</tag> Specifies a table that is used as an IGP routing table. Default: the same as the table BGP is connected to. - + + <tag>bfd <M>switch</M></tag> + BGP could use BFD protocol as an advisory mechanism for neighbor + liveness and failure detection. If enabled, BIRD setups a BFD session + for the BGP neighbor and tracks its liveness by it. This has an + advantage of an order of magnitude lower detection times in case of + failure. Note that BFD protocol also has to be configured, see + <ref id="sect-bfd" name="BFD"> section for details. Default: disabled. + <tag>ttl security <m/switch/</tag> Use GTSM (RFC 5082 - the generalized TTL security mechanism). GTSM protects against spoofed packets by ignoring received packets with a smaller @@ -1986,6 +2166,7 @@ protocol ospf <name> { real broadcast <switch>; ptp netmask <switch>; check link <switch>; + bfd <switch>; ecmp weight <num>; ttl security [<switch>; | tx only] tx class|dscp <num>; @@ -2260,6 +2441,14 @@ protocol ospf <name> { prefix) is propagated. It is possible that some hardware drivers or platforms do not implement this feature. Default value is no. + <tag>bfd <M>switch</M></tag> + OSPF could use BFD protocol as an advisory mechanism for neighbor + liveness and failure detection. If enabled, BIRD setups a BFD session + for each OSPF neighbor and tracks its liveness by it. This has an + advantage of an order of magnitude lower detection times in case of + failure. Note that BFD protocol also has to be configured, see + <ref id="sect-bfd" name="BFD"> section for details. Default value is no. + <tag>ttl security [<m/switch/ | tx only]</tag> TTL security is a feature that protects routing protocols from remote spoofed packets by using TTL 255 instead of TTL 1 |