From 5459fac61f3a645c636bdf32c140f4d7083034d2 Mon Sep 17 00:00:00 2001 From: Martin Mares Date: Mon, 29 May 2000 21:03:27 +0000 Subject: Added BGP documentation. --- doc/bird.sgml | 161 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 155 insertions(+), 6 deletions(-) (limited to 'doc') diff --git a/doc/bird.sgml b/doc/bird.sgml index a366957..4cfcd33 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -61,7 +61,7 @@ and Zebra ), but their capabilities are very they are very hard to configure and maintain.

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 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"; } BGP

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, 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, @@ -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 route) in order to avoid routing loops. -

In BIRD, each instance of BGP corresponds to one neighboring router. -This allows to set routing policy and all other parameters differently -for each neighbor. +

BIRD supports all requirements of the BGP4 standard as defined in +RFC 1771 +including several enhancements from the +latest draft. +It also supports the community attributes as per +RFC 1997, +capability negotiation draft. +For IPv6, it uses the standard multiprotocol extensions defined in +RFC 2283 +including changes described in the +latest draft +and applied to IPv6 according to +RFC 2545. + +Route selection rules + +

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. + + + Prefer route with the highest local preference attribute. + Prefer route with the shortest AS path. + Prefer IGP origin over EGP and EGP over incomplete. + Prefer the lowest value of the Multiple Exit Discriminator. + Prefer internal routes over external routes. + Prefer route with the lowest value of router ID of the + advertising router. + Configuration +

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: + + + local as 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. + neighbor Define neighboring router + this instance will be talking to and what AS it's located in. Unless + you use the multihop Configure multihop BGP to a + neighbor which is connected at most next hop self 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. + source address 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. + disable after error 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. + hold time 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. + startup hold time 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. + keepalive time Delay in seconds between sending + of two consecutive keepalive messages. Default: One third of the hold time. + connect retry time Time in seconds to wait before + retrying a failed connect attempt. Default: 120 seconds. + start delay time Delay in seconds between protocol + startup and first attempt to connect. Default: 5 seconds. + error wait time Minimum and maximum delay in seconds between protocol + failure (either local or reported by the peer) and automatic startup. + Doesn't apply when error forget time Maximum time in seconds between two protocol + failures to treat them as a error sequence which makes the path metric Enable comparison of path lengths + when deciding which BGP route is the best one. Default: on. + default bgp_med Value of the Multiple Exit + Discriminator to be used during route selection when the MED attribute + is missing. Default: infinite. + default bgp_local_pref Value of the Local Preference + to be used during route selection when the Local Preference attribute + is missing. Default: 0. + + Attributes +

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. + + + path 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. + int 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. + int 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. + enum Origin of the route: either EGP protocol + (nowadays it seems to be obsolete) or ip 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. + void 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. + + clist List of community values associated + with the route. Each such value is a pair (represented as a + Example +

+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 +} + + Device

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 require network interfaces to be defined in order to work. -

Only configurable thing is interface scan time: +

The only configurable thing is interface scan time:

scan time Time in seconds between two scans -- cgit v1.2.3