Jerry/bird
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity

Doc: Add tag for links to RFCs

Browse source
This commit is contained in:
Pavel Tvrdik 2016-09-29 18:08:40 +02:00
parent 9c20a8b7ae
commit 7935b9d212
4 changed files with 118 additions and 133 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

236
doc/bird.sgml
View file

@ -73,8 +73,8 @@ running on background which does the dynamic part of Internet routing, that is
it communicates with the other routers, calculates routing tables and sends them it communicates with the other routers, calculates routing tables and sends them
to the OS kernel which does the actual packet forwarding. There already exist to the OS kernel which does the actual packet forwarding. There already exist
other such routing daemons: routed (RIP only), GateD (non-free), other such routing daemons: routed (RIP only), GateD (non-free),
Zebra <HTMLURL URL="http://www.zebra.org"> and <HTMLURL URL="http://www.zebra.org" name="Zebra"> and
MRTD <HTMLURL URL="http://sourceforge.net/projects/mrt">, <HTMLURL URL="http://sourceforge.net/projects/mrt" name="MRTD">,
but their capabilities are limited and they are relatively hard to configure but their capabilities are limited and they are relatively hard to configure
and maintain. and maintain.
@ -485,9 +485,9 @@ protocol rip {
used to validate route origination of BGP routes. A ROA table contains used to validate route origination of BGP routes. A ROA table contains
ROA entries, each consist of a network prefix, a max prefix length and ROA entries, each consist of a network prefix, a max prefix length and
an AS number. A ROA entry specifies prefixes which could be originated an AS number. A ROA entry specifies prefixes which could be originated
by that AS number. ROA tables could be filled with data from RPKI (RFC by that AS number. ROA tables could be filled with data from RPKI (<rfc
6480) or from public databases like Whois. ROA tables are examined by id="6480">) or from public databases like Whois. ROA tables are
<cf/roa_check()/ operator in filters. examined by <cf/roa_check()/ operator in filters.
Currently, there is just one option, <cf>roa <m/prefix/ max <m/num/ as Currently, there is just one option, <cf>roa <m/prefix/ max <m/num/ as
<m/num/</cf>, which can be used to populate the ROA table with static <m/num/</cf>, which can be used to populate the ROA table with static
@ -1270,9 +1270,9 @@ clist) or on clist and pair/quad set (returning true if there is an element of
the clist that is also a member of the pair/quad set). the clist that is also a member of the pair/quad set).
<p>There is one operator related to ROA infrastructure - <cf/roa_check()/. It <p>There is one operator related to ROA infrastructure - <cf/roa_check()/. It
examines a ROA table and does RFC 6483 route origin validation for a given examines a ROA table and does <rfc id="6483"> route origin validation for a
network prefix. The basic usage is <cf>roa_check(<m/table/)</cf>, which checks given network prefix. The basic usage is <cf>roa_check(<m/table/)</cf>, which
current route (which should be from BGP to have AS_PATH argument) in the checks current route (which should be from BGP to have AS_PATH argument) in the
specified ROA table and returns ROA_UNKNOWN if there is no relevant ROA, specified ROA table and returns ROA_UNKNOWN if there is no relevant ROA,
ROA_VALID if there is a matching ROA, or ROA_INVALID if there are some relevant ROA_VALID if there is a matching ROA, or ROA_INVALID if there are some relevant
ROAs but none of them match. There is also an extended variant ROAs but none of them match. There is also an extended variant
@ -1434,11 +1434,12 @@ corresponding protocol sections.
<sect1>Introduction <sect1>Introduction
<label id="babel-intro"> <label id="babel-intro">
<p>The Babel protocol (RFC6126) is a loop-avoiding distance-vector routing <p>The Babel protocol
protocol that is robust and efficient both in ordinary wired networks and in (<rfc id="6126">) is a loop-avoiding distance-vector routing protocol that is
wireless mesh networks. Babel is conceptually very simple in its operation and robust and efficient both in ordinary wired networks and in wireless mesh
"just works" in its default configuration, though some configuration is possible networks. Babel is conceptually very simple in its operation and "just works"
and in some cases desirable. in its default configuration, though some configuration is possible and in some
cases desirable.
<p>While the Babel protocol is dual stack (i.e., can carry both IPv4 and IPv6 <p>While the Babel protocol is dual stack (i.e., can carry both IPv4 and IPv6
routes over the same IPv6 transport), BIRD presently implements only the IPv6 routes over the same IPv6 transport), BIRD presently implements only the IPv6
@ -1580,14 +1581,10 @@ addresses and associated interfaces. When a session changes its state, these
protocols are notified and act accordingly (e.g. break an OSPF adjacency when protocols are notified and act accordingly (e.g. break an OSPF adjacency when
the BFD session went down). the BFD session went down).
<p>BIRD implements basic BFD behavior as defined in <p>BIRD implements basic BFD behavior as defined in <rfc id="5880"> (some
RFC 5880<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5880.txt"> advanced features like the echo mode or authentication are not implemented), IP
(some advanced features like the echo mode or authentication are not implemented), transport for BFD as defined in <rfc id="5881"> and <rfc id="5883"> and
IP transport for BFD as defined in interaction with client protocols as defined in <rfc id="5882">.
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 <p>Note that BFD implementation in BIRD is currently a new feature in
development, expect some rough edges and possible UI and configuration changes development, expect some rough edges and possible UI and configuration changes
@ -1764,31 +1761,16 @@ the packet will travel through if it uses the particular route) in order to
avoid routing loops. avoid routing loops.
<p>BIRD supports all requirements of the BGP4 standard as defined in <p>BIRD supports all requirements of the BGP4 standard as defined in
RFC 4271<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4271.txt"> <rfc id="4271"> It also supports the community attributes (<rfc id="1997">),
It also supports the community attributes capability negotiation (<rfc id="5492">), MD5 password authentication (<rfc
(RFC 1997<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1997.txt">), id="2385">), extended communities (<rfc id="4360">), route reflectors (<rfc
capability negotiation id="4456">), graceful restart (<rfc id="4724">), multiprotocol extensions
(RFC 5492<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5492.txt">), (<rfc id="4760">), 4B AS numbers (<rfc id="4893">), and 4B AS numbers in
MD5 password authentication extended communities (<rfc id="5668">).
(RFC 2385<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2385.txt">),
extended communities
(RFC 4360<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4360.txt">),
route reflectors
(RFC 4456<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4456.txt">),
graceful restart
(RFC 4724<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4724.txt">),
multiprotocol extensions
(RFC 4760<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4760.txt">),
4B AS numbers
(RFC 4893<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4893.txt">),
and 4B AS numbers in extended communities
(RFC 5668<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5668.txt">).
For IPv6, it uses the standard multiprotocol extensions defined in For IPv6, it uses the standard multiprotocol extensions defined in
RFC 4760<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4760.txt"> <rfc id="4760"> and applied to IPv6 according to <rfc id="2545">.
and applied to IPv6 according to
RFC 2545<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2545.txt">.
<sect1>Route selection rules <sect1>Route selection rules
<label id="bgp-route-select-rules"> <label id="bgp-route-select-rules">
@ -1938,20 +1920,20 @@ using the following configuration parameters:
<ref id="bfd" name="BFD"> section for details. Default: disabled. <ref id="bfd" name="BFD"> section for details. Default: disabled.
<tag><label id="bgp-ttl-security">ttl security <m/switch/</tag> <tag><label id="bgp-ttl-security">ttl security <m/switch/</tag>
Use GTSM (RFC 5082 - the generalized TTL security mechanism). GTSM Use GTSM (<rfc id="5082"> - the generalized TTL security mechanism). GTSM
protects against spoofed packets by ignoring doc/bird.sgmlreceived packets with a protects against spoofed packets by ignoring received packets with a
smaller than expected TTL. To work properly, GTSM have to be enabled on smaller than expected TTL. To work properly, GTSM have to be enabled on
both sides of a BGP session. If both <cf/ttl security/ and <cf/multihop/ both sides of a BGP session. If both <cf/ttl security/ and
options are enabled, <cf/multihop/ option should specify proper hop <cf/multihop/ options are enabled, <cf/multihop/ option should specify
value to compute expected TTL. Kernel support required: Linux: 2.6.34+ proper hop value to compute expected TTL. Kernel support required:
(IPv4), 2.6.35+ (IPv6), BSD: since long ago, IPv4 only. Note that full Linux: 2.6.34+ (IPv4), 2.6.35+ (IPv6), BSD: since long ago, IPv4 only.
(ICMP protection, for example) RFC 5082 support is provided by Linux Note that full (ICMP protection, for example) <rfc id="5082"> support is
only. Default: disabled. provided by Linux only. Default: disabled.
<tag><label id="bgp-pass">password <m/string/</tag> <tag><label id="bgp-pass">password <m/string/</tag>
Use this password for MD5 authentication of BGP sessions (RFC 2385). Use this password for MD5 authentication of BGP sessions (<rfc id="2385">). When
When used on BSD systems, see also <cf/setkey/ option below. Default: used on BSD systems, see also <cf/setkey/ option below. Default: no
no authentication. authentication.
<tag><label id="bgp-setkey">setkey <m/switch/</tag> <tag><label id="bgp-setkey">setkey <m/switch/</tag>
On BSD systems, keys for TCP MD5 authentication are stored in the global On BSD systems, keys for TCP MD5 authentication are stored in the global
@ -1966,7 +1948,7 @@ using the following configuration parameters:
<tag><label id="bgp-passive">passive <m/switch/</tag> <tag><label id="bgp-passive">passive <m/switch/</tag>
Standard BGP behavior is both initiating outgoing connections and Standard BGP behavior is both initiating outgoing connections and
accepting incoming connections. In passive modoc/bird.sgmlde, outgoing connections accepting incoming connections. In passive mode, outgoing connections
are not initiated. Default: off. are not initiated. Default: off.
<tag><label id="bgp-rr-client">rr client</tag> <tag><label id="bgp-rr-client">rr client</tag>
@ -1985,11 +1967,11 @@ using the following configuration parameters:
Be a route server and treat the neighbor as a route server client. Be a route server and treat the neighbor as a route server client.
A route server is used as a replacement for full mesh EBGP routing in A route server is used as a replacement for full mesh EBGP routing in
Internet exchange points in a similar way to route reflectors used in Internet exchange points in a similar way to route reflectors used in
IBGP routing. BIRD does not implement obsoleted RFC 1863, but uses IBGP routing. BIRD does not implement obsoleted <rfc id="1863">, but
ad-hoc implementation, which behaves like plain EBGP but reduces uses ad-hoc implementation, which behaves like plain EBGP but reduces
modifications to advertised route attributes to be transparent (for modifications to advertised route attributes to be transparent (for
example does not prepend its AS number to AS PATH attribute and keeps example does not prepend its AS number to AS PATH attribute and
MED attribute). Default: disabled. keeps MED attribute). Default: disabled.
<tag><label id="bgp-secondary">secondary <m/switch/</tag> <tag><label id="bgp-secondary">secondary <m/switch/</tag>
Usually, if an export filter rejects a selected route, no other route is Usually, if an export filter rejects a selected route, no other route is
@ -2023,27 +2005,28 @@ using the following configuration parameters:
to keep BGP speakers synchronized. Sometimes (e.g., if BGP speaker to keep BGP speakers synchronized. Sometimes (e.g., if BGP speaker
changes its import filter, or if there is suspicion of inconsistency) it changes its import filter, or if there is suspicion of inconsistency) it
is necessary to do a new complete route exchange. BGP protocol extension is necessary to do a new complete route exchange. BGP protocol extension
Route Refresh (RFC 2918) allows BGP speaker to request re-advertisement Route Refresh (<rfc id="2918">) allows BGP speaker to request
of all routes from its neighbor. BGP protocol extension Enhanced Route re-advertisement of all routes from its neighbor. BGP protocol
Refresh (RFC 7313) specifies explicit begin and end for such exchanges, extension Enhanced Route Refresh (<rfc id="7313">) specifies explicit
therefore the receiver can remove stale routes that were not advertised begin and end for such exchanges, therefore the receiver can remove
during the exchange. This option specifies whether BIRD advertises these stale routes that were not advertised during the exchange. This option
capabilities and supports related procedures. Note that even when specifies whether BIRD advertises these capabilities and supports
disabled, BIRD can send route refresh requests. Default: on. related procedures. Note that even when disabled, BIRD can send route
refresh requests. Default: on.
<tag><label id="bgp-graceful-restart">graceful restart <m/switch/|aware</tag> <tag><label id="bgp-graceful-restart">graceful restart <m/switch/|aware</tag>
When a BGP speaker restarts or crashes, neighbors will discard all When a BGP speaker restarts or crashes, neighbors will discard all
received paths from the speaker, which disrupts packet forwarding even received paths from the speaker, which disrupts packet forwarding even
when the forwarding plane of the speaker remains intact. RFC 4724 when the forwarding plane of the speaker remains intact. <rfc
specifies an optional graceful restart mechanism to alleviate this id="4724"> specifies an optional graceful restart mechanism to
issue. This option controls the mechanism. It has three states: alleviate this issue. This option controls the mechanism. It has three
Disabled, when no support is provided. Aware, when the graceful restart states: Disabled, when no support is provided. Aware, when the graceful
support is announced and the support for restarting neighbors is restart support is announced and the support for restarting neighbors
provided, but no local graceful restart is allowed (i.e. receiving-only is provided, but no local graceful restart is allowed (i.e.
role). Enabled, when the full graceful restart support is provided receiving-only role). Enabled, when the full graceful restart
(i.e. both restarting and receiving role). Note that proper support for support is provided (i.e. both restarting and receiving role). Note
local graceful restart requires also configuration of other protocols. that proper support for local graceful restart requires also
Default: aware. configuration of other protocols. Default: aware.
<tag><label id="bgp-graceful-restart-time">graceful restart time <m/number/</tag> <tag><label id="bgp-graceful-restart-time">graceful restart time <m/number/</tag>
The restart time is announced in the BGP graceful restart capability The restart time is announced in the BGP graceful restart capability
@ -2052,15 +2035,15 @@ using the following configuration parameters:
120 seconds. 120 seconds.
<tag><label id="bgp-interpret-communities">interpret communities <m/switch/</tag> <tag><label id="bgp-interpret-communities">interpret communities <m/switch/</tag>
RFC 1997 demands that BGP speaker should process well-known communities <rfc id="1997"> demands that BGP speaker should process well-known
like no-export (65535, 65281) or no-advertise (65535, 65282). For communities like no-export (65535, 65281) or no-advertise (65535,
example, received route carrying a no-adverise community should not be 65282). For example, received route carrying a no-adverise community
advertised to any of its neighbors. If this option is enabled (which is should not be advertised to any of its neighbors. If this option is
by default), BIRD has such behavior automatically (it is evaluated when enabled (which is by default), BIRD has such behavior automatically (it
a route is exported to the BGP protocol just before the export filter). is evaluated when a route is exported to the BGP protocol just before
Otherwise, this integrated processing of well-known communities is the export filter). Otherwise, this integrated processing of
disabled. In that case, similar behavior can be implemented in the well-known communities is disabled. In that case, similar behavior can
export filter. Default: on. be implemented in the export filter. Default: on.
<tag><label id="bgp-enable-as4">enable as4 <m/switch/</tag> <tag><label id="bgp-enable-as4">enable as4 <m/switch/</tag>
BGP protocol was designed to use 2B AS numbers and was extended later to BGP protocol was designed to use 2B AS numbers and was extended later to
@ -2085,10 +2068,10 @@ using the following configuration parameters:
<tag><label id="bgp-advertise-ipv4">advertise ipv4 <m/switch/</tag> <tag><label id="bgp-advertise-ipv4">advertise ipv4 <m/switch/</tag>
Advertise IPv4 multiprotocol capability. This is not a correct behavior Advertise IPv4 multiprotocol capability. This is not a correct behavior
according to the strict interpretation of RFC 4760, but it is widespread according to the strict interpretation of <rfc id="4760">, but it is
and required by some BGP implementations (Cisco and Quagga). This option widespread and required by some BGP implementations (Cisco and Quagga).
is relevant to IPv4 mode with enabled capability advertisement This option is relevant to IPv4 mode with enabled capability
only. Default: on. advertisement only. Default: on.
<tag><label id="bgp-route-limit">route limit <m/number/</tag> <tag><label id="bgp-route-limit">route limit <m/number/</tag>
The maximal number of routes that may be imported from the protocol. If The maximal number of routes that may be imported from the protocol. If
@ -2152,16 +2135,16 @@ using the following configuration parameters:
BGP route selection algorithm is often viewed as a comparison between BGP route selection algorithm is often viewed as a comparison between
individual routes (e.g. if a new route appears and is better than the individual routes (e.g. if a new route appears and is better than the
current best one, it is chosen as the new best one). But the proper current best one, it is chosen as the new best one). But the proper
route selection, as specified by RFC 4271, cannot be fully implemented route selection, as specified by <rfc id="4271">, cannot be fully
in that way. The problem is mainly in handling the MED attribute. BIRD, implemented in that way. The problem is mainly in handling the MED
by default, uses an simplification based on individual route comparison, attribute. BIRD, by default, uses an simplification based on individual
which in some cases may lead to temporally dependent behavior (i.e. the route comparison, which in some cases may lead to temporally dependent
selection is dependent on the order in which routes appeared). This behavior (i.e. the selection is dependent on the order in which routes
option enables a different (and slower) algorithm implementing proper appeared). This option enables a different (and slower) algorithm
RFC 4271 route selection, which is deterministic. Alternative way how to implementing proper <rfc id="4271"> route selection, which is
get deterministic behavior is to use <cf/med metric/ option. This option deterministic. Alternative way how to get deterministic behavior is to
is incompatible with <ref id="dsc-table-sorted" name="sorted tables">. use <cf/med metric/ option. This option is incompatible with <ref
Default: off. id="dsc-table-sorted" name="sorted tables">. Default: off.
<tag><label id="bgp-igp-metric">igp metric <m/switch/</tag> <tag><label id="bgp-igp-metric">igp metric <m/switch/</tag>
Enable comparison of internal distances to boundary routers during best Enable comparison of internal distances to boundary routers during best
@ -2170,7 +2153,7 @@ using the following configuration parameters:
<tag><label id="bgp-prefer-older">prefer older <m/switch/</tag> <tag><label id="bgp-prefer-older">prefer older <m/switch/</tag>
Standard route selection algorithm breaks ties by comparing router IDs. Standard route selection algorithm breaks ties by comparing router IDs.
This changes the behavior to prefer older routes (when both are external This changes the behavior to prefer older routes (when both are external
and from different peer). For details, see RFC 5004. Default: off. and from different peer). For details, see <rfc id="5004">. Default: off.
<tag><label id="bgp-default-med">default bgp_med <m/number/</tag> <tag><label id="bgp-default-med">default bgp_med <m/number/</tag>
Value of the Multiple Exit Discriminator to be used during route Value of the Multiple Exit Discriminator to be used during route
@ -2210,8 +2193,8 @@ some of them (marked with `<tt/O/') are optional.
when a route is exported to an external BGP instance to ensure that the when a route is exported to an external BGP instance to ensure that the
attribute received from a neighboring AS is not propagated to other attribute received from a neighboring AS is not propagated to other
neighboring ASes. A new value might be set in the export filter of an neighboring ASes. A new value might be set in the export filter of an
external BGP instance. See RFC 4451<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4451.txt"> external BGP instance. See <rfc id="4451"> for further discussion of
for further discussion of BGP MED attribute. BGP MED attribute.
<tag><label id="rta-bgp-origin">enum bgp_origin/</tag> <tag><label id="rta-bgp-origin">enum bgp_origin/</tag>
Origin of the route: either <cf/ORIGIN_IGP/ if the route has originated Origin of the route: either <cf/ORIGIN_IGP/ if the route has originated
@ -2580,15 +2563,13 @@ protocol kernel { # Secondary routing table
<label id="ospf-intro"> <label id="ospf-intro">
<p>Open Shortest Path First (OSPF) is a quite complex interior gateway <p>Open Shortest Path First (OSPF) is a quite complex interior gateway
protocol. The current IPv4 version (OSPFv2) is defined in RFC 2328 protocol. The current IPv4 version (OSPFv2) is defined in <rfc id="2328"> and
<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2328.txt"> the current IPv6 version (OSPFv3) is defined in <rfc id="5340"> It's a link
and the current IPv6 version (OSPFv3) is defined in RFC 5340 state (a.k.a. shortest path first) protocol -- each router maintains a database
<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc5340.txt"> describing the autonomous system's topology. Each participating router has an
It's a link state (a.k.a. shortest path first) protocol -- each router maintains identical copy of the database and all routers run the same algorithm
a database describing the autonomous system's topology. Each participating calculating a shortest path tree with themselves as a root. OSPF chooses the
router has an identical copy of the database and all routers run the same least cost path as the best path.
algorithm calculating a shortest path tree with themselves as a root. OSPF
chooses the least cost path as the best path.
<p>In OSPF, the autonomous system can be split to several areas in order to <p>In OSPF, the autonomous system can be split to several areas in order to
reduce the amount of resources consumed for exchanging the routing information reduce the amount of resources consumed for exchanging the routing information
@ -2708,8 +2689,7 @@ protocol ospf &lt;name&gt; {
<descrip> <descrip>
<tag><label id="ospf-rfc1583compat">rfc1583compat <M>switch</M></tag> <tag><label id="ospf-rfc1583compat">rfc1583compat <M>switch</M></tag>
This option controls compatibility of routing table calculation with This option controls compatibility of routing table calculation with
RFC 1583 <htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1583.txt">. <rfc id="1583">. Default value is no.
Default value is no.
<tag><label id="ospf-instance-id">instance id <m/num/</tag> <tag><label id="ospf-instance-id">instance id <m/num/</tag>
When multiple OSPF protocol instances are active on the same links, they When multiple OSPF protocol instances are active on the same links, they
@ -2726,9 +2706,8 @@ protocol ospf &lt;name&gt; {
that participates in the OSPF topology but does not allow transit that participates in the OSPF topology but does not allow transit
traffic. In OSPFv2, this is implemented by advertising maximum metric traffic. In OSPFv2, this is implemented by advertising maximum metric
for outgoing links. In OSPFv3, the stub router behavior is announced by for outgoing links. In OSPFv3, the stub router behavior is announced by
clearing the R-bit in the router LSA. See RFC 6987 clearing the R-bit in the router LSA. See <rfc id="6987"> for details.
<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc6987.txt"> for Default value is no.
details. Default value is no.
<tag><label id="ospf-tick">tick <M>num</M></tag> <tag><label id="ospf-tick">tick <M>num</M></tag>
The routing table calculation and clean-up of areas' databases is not The routing table calculation and clean-up of areas' databases is not
@ -2839,10 +2818,9 @@ protocol ospf &lt;name&gt; {
You can specify alternative instance ID for the interface definition, You can specify alternative instance ID for the interface definition,
therefore it is possible to have several instances of that interface therefore it is possible to have several instances of that interface
with different options or even in different areas. For OSPFv2, with different options or even in different areas. For OSPFv2, instance
instance ID support is an extension (RFC 6549 ID support is an extension (<rfc id="6549">) and is supposed to be set
<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc6549.txt">) and is per-protocol. For OSPFv3, it is an integral feature.
supposed to be set per-protocol. For OSPFv3, it is an integral feature.
<tag><label id="ospf-virtual-link">virtual link <M>id</M> [instance <m/num/]</tag> <tag><label id="ospf-virtual-link">virtual link <M>id</M> [instance <m/num/]</tag>
Virtual link to router with the router id. Virtual link acts as a Virtual link to router with the router id. Virtual link acts as a
@ -3266,9 +3244,7 @@ time intervals or as an answer to a request) advertisement packets to connected
networks. These packets contain basic information about a local network (e.g. a networks. These packets contain basic information about a local network (e.g. a
list of network prefixes), which allows network hosts to autoconfigure network list of network prefixes), which allows network hosts to autoconfigure network
addresses and choose a default route. BIRD implements router behavior as defined addresses and choose a default route. BIRD implements router behavior as defined
in RFC 4861<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc4861.txt"> in <rfc id="4861"> and also the DNS extensions from <rfc id="6106">.
and also the DNS extensions from
RFC 6106<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc6106.txt">.
<sect1>Configuration <sect1>Configuration
<label id="radv-config"> <label id="radv-config">
@ -3523,12 +3499,9 @@ counting to infinity is necessary, because it is slow. Due to infinity being 16,
you can't use RIP on networks where maximal distance is higher than 15 you can't use RIP on networks where maximal distance is higher than 15
hosts. hosts.
<p>BIRD supports RIPv1 <p>BIRD supports RIPv1 (<rfc id="1058">), RIPv2 (<rfc id="2453">), RIPng (<rfc
(RFC 1058<htmlurl url="http://www.rfc-editor.org/rfc/rfc1058.txt">), id="2080">), and RIP cryptographic authentication (SHA-1 not implemented)
RIPv2 (RFC 2453<htmlurl url="http://www.rfc-editor.org/rfc/rfc2453.txt">), (<rfc id="4822">).
RIPng (RFC 2080<htmlurl url="http://www.rfc-editor.org/rfc/rfc2080.txt">),
and RIP cryptographic authentication (SHA-1 not implemented)
(RFC 4822<htmlurl url="http://www.rfc-editor.org/rfc/rfc4822.txt">).
<p>RIP is a very simple protocol, and it has a lot of shortcomings. Slow <p>RIP is a very simple protocol, and it has a lot of shortcomings. Slow
convergence, big network load and inability to handle larger networks makes it convergence, big network load and inability to handle larger networks makes it
@ -3707,8 +3680,9 @@ protocol rip [&lt;name&gt;] {
compatibility with neighbors regardless of whether they use ttl compatibility with neighbors regardless of whether they use ttl
security. security.
For RIPng, TTL security is a standard behavior (required by RFC 2080) For RIPng, TTL security is a standard behavior (required by <rfc
and therefore default value is yes. For IPv4 RIP, default value is no. id="2080">) and therefore default value is yes. For IPv4 RIP, default
value is no.
<tag><label id="rip-iface-tx-class">tx class|dscp|priority <m/number/</tag> <tag><label id="rip-iface-tx-class">tx class|dscp|priority <m/number/</tag>
These options specify the ToS/DiffServ/Traffic class/Priority of the These options specify the ToS/DiffServ/Traffic class/Priority of the

4
doc/sbase/dist/birddoc/html/mapping vendored
View file

@ -205,6 +205,10 @@
<htmlurl> "<A HREF=\"[URL]\">[NAME]</A>" <htmlurl> "<A HREF=\"[URL]\">[NAME]</A>"
</htmlurl> </htmlurl>
<rfc> "<A HREF=\"http://www.rfc-editor.org/info/rfc[ID]\">RFC [ID]</A>"
</rfc>
% ref modified to have an optional name field % ref modified to have an optional name field
<ref> + "<@@ref>[ID]\n" <ref> + "<@@ref>[ID]\n"
"[NAME]</A>\n" "[NAME]</A>\n"

3
doc/sbase/dist/birddoc/latex2e/mapping vendored
View file

@ -238,6 +238,9 @@
<htmlurl> "\\href{[URL]}{[NAME]}" <htmlurl> "\\href{[URL]}{[NAME]}"
</htmlurl> </htmlurl>
<rfc> "\\href{http://www.rfc-editor.org/info/rfc[ID]}{RFC [ID]}"
</rfc>
<x> <x>
</x> </x>

6
doc/sbase/dtd/birddoc.dtd
View file

@ -99,7 +99,7 @@ anywhere else. <pavel@ucw.cz>
<!-- url added by HG; htmlurl added by esr --> <!-- url added by HG; htmlurl added by esr -->
<!entity % xref <!entity % xref
" label|ref|pageref|cite|url|htmlurl|ncite " > " label|ref|pageref|cite|url|htmlurl|rfc|ncite " >
<!entity % inline <!entity % inline
" (#pcdata | f| x| %emph; |sq| %xref | %index | file )* " > " (#pcdata | f| x| %emph; |sq| %xref | %index | file )* " >
@ -501,6 +501,10 @@ anywhere else. <pavel@ucw.cz>
url cdata #required url cdata #required
name cdata "&urlnam" > name cdata "&urlnam" >
<!element rfc - o empty>
<!attlist rfc
id cdata #required>
<!element pageref - o empty> <!element pageref - o empty>
<!attlist pageref <!attlist pageref
id cdata #required> id cdata #required>