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

Added BGP documentation.

Browse source
This commit is contained in:
Martin Mares 2000-05-29 21:03:27 +00:00
parent 56ab03c71f
commit 5459fac61f
1 changed files with 155 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

161
doc/bird.sgml
View file

@ -61,7 +61,7 @@ and Zebra <HTMLURL URL="http://www.zebra.org">), but their capabilities are very
they are very hard to configure and maintain. they are very hard to configure and maintain.
<p>BIRD is an Internet Routing Daemon designed to avoid all of these shortcomings, <p>BIRD is an Internet Routing Daemon designed to avoid all of these shortcomings,
to support all the routing technology used in today's Internet or planned to be to support all the routing technology used in the today's Internet or planned to be
used in near future and to have a clean extensible architecture allowing new routing used in near future and to have a clean extensible architecture allowing new routing
protocols to be incorporated easily. Among other features, BIRD supports: protocols to be incorporated easily. Among other features, BIRD supports:
@ -454,7 +454,7 @@ if 1234 = i then printn "."; else { print "*** FAIL: if 1 else"; }
<sect1>BGP <sect1>BGP
<p>The Border Gateway Protocol is the routing protocol used for backbone <p>The Border Gateway Protocol is the routing protocol used for backbone
level routing in today's Internet. Contrary to other protocols, its convergence level routing in the today's Internet. Contrary to other protocols, its convergence
doesn't rely on all routers following the same rules for route selection, doesn't rely on all routers following the same rules for route selection,
making it possible to implement any routing policy at any router in the making it possible to implement any routing policy at any router in the
network, the only restriction being that if a router advertises a route, network, the only restriction being that if a router advertises a route,
@ -472,16 +472,165 @@ routing table it wishes to export along with complete path information
(a list of AS'es the packet will travel through if it uses that particular (a list of AS'es the packet will travel through if it uses that particular
route) in order to avoid routing loops. route) in order to avoid routing loops.
<p>In BIRD, each instance of BGP corresponds to one neighboring router. <p>BIRD supports all requirements of the BGP4 standard as defined in
This allows to set routing policy and all other parameters differently RFC 1771<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1771.txt">
for each neighbor. including several enhancements from the
latest draft<htmlurl url="ftp://ftp.rfc-editor.org/internet-drafts/draft-ietf-idr-bgp4-09.txt">.
It also supports the community attributes as per
RFC 1997<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc1997.txt">,
capability negotiation draft<htmlurl url="ftp://ftp.rfc-editor.org/internet-drafts/draft-ietf-idr-bgp4-cap-neg-06.txt">.
For IPv6, it uses the standard multiprotocol extensions defined in
RFC 2283<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2283.txt">
including changes described in the
latest draft <htmlurl url="ftp://ftp.rfc-editor.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-05.txt">
and applied to IPv6 according to
RFC 2545<htmlurl url="ftp://ftp.rfc-editor.org/in-notes/rfc2545.txt">.
<sect2>Route selection rules
<p>BGP doesn't have any simple metric, so the rules for selection of an optimal
route among multiple BGP routes with the same preference are a bit more complex
and are implemented according to the following algorithm. First it uses the first
rule, if there are more "best" routes, then it uses the second rule to choose
among them and so on.
<itemize>
<item>Prefer route with the highest local preference attribute.
<item>Prefer route with the shortest AS path.
<item>Prefer IGP origin over EGP and EGP over incomplete.
<item>Prefer the lowest value of the Multiple Exit Discriminator.
<item>Prefer internal routes over external routes.
<item>Prefer route with the lowest value of router ID of the
advertising router.
</itemize>
<sect2>Configuration <sect2>Configuration
<p>Each instance of the BGP corresponds to one neighboring router.
This allows to set routing policy and all other parameters differently
for each neighbor using the following protocol parameters:
<descrip>
<tag>local as <m/number/</tag> Define which AS we are part of. (Note that
contrary to other IP routers, BIRD is able to act as a router located
in multiple AS'es simultaneously, but in such cases you need to tweak
the BGP paths manually in the filters to get consistent behavior.)
This parameter is mandatory.
<tag>neighbor <m/ip/ as <m/number/</tag> Define neighboring router
this instance will be talking to and what AS it's located in. Unless
you use the <cf/multihop/ clause, it must be directly connected to one
of your router's interfaces. This parameter is mandatory.
<tag>multihop <m/number/ via <m/ip/</tag> Configure multihop BGP to a
neighbor which is connected at most <m/number/ hops far and to which
we should route via our direct neighbor with address <m/ip/.
Default: switched off.
<tag>next hop self</tag> Avoid calculation of the Next Hop attribute
and always advertise our own source address (see below) as a next hop.
This needs to be used only
occasionally to circumvent misconfigurations of other routers.
Default: disabled.
<tag>source address <m/ip/</tag> Define local address we should use
for next hop calculation. Default: the address of the local end
of the interface our neighbor is connected to.
<tag>disable after error <m/switch/</tag> When an error is encountered (either
locally or by the other side), disable the instance automatically
and wait for an administrator to solve the problem manually. Default: off.
<tag>hold time <m/number/</tag> Time in seconds to wait for a keepalive
message from the other side before considering the connection stale.
Default: depends on agreement with the neighboring router, we prefer
240 seconds if the other side is willing to accept it.
<tag>startup hold time <m/number/</tag> Value of the hold timer used
before the routers have a chance to exchange OPEN messages and agree
on the real value. Default: 240 seconds.
<tag>keepalive time <m/number/</tag> Delay in seconds between sending
of two consecutive keepalive messages. Default: One third of the hold time.
<tag>connect retry time <m/number/</tag> Time in seconds to wait before
retrying a failed connect attempt. Default: 120 seconds.
<tag>start delay time <m/number/</tag> Delay in seconds between protocol
startup and first attempt to connect. Default: 5 seconds.
<tag>error wait time <m/number/, <m/number/</tag> Minimum and maximum delay in seconds between protocol
failure (either local or reported by the peer) and automatic startup.
Doesn't apply when <cf/disable after error/ is configured. If consecutive
errors happen, the delay is increased exponentially until it reaches the maximum. Default: 60, 300.
<tag>error forget time <m/number/</tag> Maximum time in seconds between two protocol
failures to treat them as a error sequence which makes the <cf/error wait time/
increase exponentially. Default: 300 seconds.
<tag>path metric <m/switch/</tag> Enable comparison of path lengths
when deciding which BGP route is the best one. Default: on.
<tag>default bgp_med <m/number/</tag> Value of the Multiple Exit
Discriminator to be used during route selection when the MED attribute
is missing. Default: infinite.
<tag>default bgp_local_pref <m/number/</tag> Value of the Local Preference
to be used during route selection when the Local Preference attribute
is missing. Default: 0.
</descrip>
<sect2>Attributes <sect2>Attributes
<p>BGP defines several route attributes. Some of them (those marked with `I' in the
table below) are available on internal BGP connections only, some of them (marked
with `O') are optional.
<descrip>
<tag>path <cf/bgp_path/</tag> Sequence of AS numbers describing the AS path
the packet will travel through when forwarded according to this route. On
internal BGP connections it doesn't contain the number of the local AS.
<tag>int <cf/bgp_local_pref/ [I]</tag> Local preference value used for
selection among multiple BGP routes (see the selection rules above). It's
used as an additional metric which is propagated through the whole local AS.
<tag>int <cf/bgp_med/ [IO]</tag> The Multiple Exit Discriminator of the route
which is an optional attribute which is often used within the local AS to
reflect interior distances to various boundary routers. See the route selection
rules above for exact semantics.
<tag>enum <cf/bgp_origin/</tag> Origin of the route: either <cf/ORIGIN_IGP/
if the route has originated in interior routing protocol of an AS or
<cf/ORIGIN_EGP/ if it's been imported from the <tt>EGP</tt> protocol
(nowadays it seems to be obsolete) or <cf/ORIGIN_INCOMPLETE/ if the origin
is unknown.
<tag>ip <cf/bgp_next_hop/</tag> Next hop to be used for forwarding of packets
to this destination. On internal BGP connections, it's an address of the
originating router if it's inside the local AS or a boundary router the
packet will leave the AS through if it's an exterior route, so each BGP
speaker within the AS has a chance to use the shortest interior path
possible to this point.
<tag>void <cf/bgp_atomic_aggr/ [O]</tag> This is an optional attribute
which carries no value, but which sole presence indicates that the route
has been aggregated from multiple routes by some AS on the path from
the originator.
<!-- we don't handle aggregators right since they are of a very obscure type
<tag>bgp_aggregator</tag>
-->
<tag>clist <cf/bgp_community/ [O]</tag> List of community values associated
with the route. Each such value is a pair (represented as a <cf/pair/ data
type inside the filters) of 16-bit integers, the first of them containing a number of the AS which defines
the community and the second one is a per-AS identifier. There are lots
of uses of the community mechanism, but generally they are used to carry
policy information like "don't export to USA peers". As each AS can define
its own routing policy, it's also has a complete freedom about which community
attributes it defines and what their semantics will be.
</descrip>
<sect2>Example <sect2>Example
<p><code>
protocol bgp {
local as 65000; # Use a private AS number
neighbor 62.168.0.130 as 5588; # Our neighbor
multihop 20 via 62.168.0.13; # Which is connected indirectly
export filter { # We use non-trivial export rules
if source = RTS_STATIC then { # Export only static routes
bgp_community.add((65000,5678)); # Assign our community
if bgp_path ~ / 65000 / then # Artificially increase path length
bgp_path.prepend(65000); # by prepending local AS number twice
accept;
}
reject;
};
import all;
source address 62.168.0.1; # Use non-standard source address
}
</code>
<sect1>Device <sect1>Device
<p>The Device protocol is not a real routing protocol as it doesn't generate <p>The Device protocol is not a real routing protocol as it doesn't generate
@ -492,7 +641,7 @@ interfaces from the kernel.
this protocol in the configuration since almost all other protocol this protocol in the configuration since almost all other protocol
require network interfaces to be defined in order to work. require network interfaces to be defined in order to work.
<p>Only configurable thing is interface scan time: <p>The only configurable thing is interface scan time:
<p><descrip> <p><descrip>
<tag>scan time <m/number/</tag> Time in seconds between two scans <tag>scan time <m/number/</tag> Time in seconds between two scans