Don't let example overflow, and new chapter for "about routing tables".
This commit is contained in:
parent
ee4880c82f
commit
a852c139dc
1 changed files with 43 additions and 39 deletions
|
@ -98,42 +98,6 @@ be relatively easy due to its highly modular architecture.
|
||||||
|
|
||||||
<p>This documentation can have 4 forms: sgml (this is master copy), html, ASCII text and dvi/postscript (generated from sgml using sgmltools). You should always edit master copy.
|
<p>This documentation can have 4 forms: sgml (this is master copy), html, ASCII text and dvi/postscript (generated from sgml using sgmltools). You should always edit master copy.
|
||||||
|
|
||||||
<sect>About routing tables
|
|
||||||
|
|
||||||
<p>Bird has one or more routing tables, which may or may not be
|
|
||||||
synchronized with kernel and which may or may not be synchronized with
|
|
||||||
each other (see the Pipe protocol). Each routing table contains list of
|
|
||||||
known routes. Each route consists of:
|
|
||||||
|
|
||||||
<itemize>
|
|
||||||
<item>network this route is for
|
|
||||||
<item>preference of this route (taken from preference of
|
|
||||||
protocol and possibly altered by filters)
|
|
||||||
<item>ip address of router who told us about this route
|
|
||||||
<item>ip address of router we should use for packets routing
|
|
||||||
using this route
|
|
||||||
<item>other attributes common to all routes
|
|
||||||
<item>dynamic attributes defined by protocols, which may or
|
|
||||||
may not be present (typically protocol metric)
|
|
||||||
</itemize>
|
|
||||||
|
|
||||||
Routing table maintains more than
|
|
||||||
one entry for network, but at most one entry for one network and one
|
|
||||||
protocol. The entry with biggest preference is used for routing. If
|
|
||||||
there are more entries with same preference and they are from same
|
|
||||||
protocol, protocol decides (typically according to metrics). If not,
|
|
||||||
internal ordering is used to decide. You can
|
|
||||||
get list of route attributes in "Route attributes" section in
|
|
||||||
filters.
|
|
||||||
|
|
||||||
<p>Protocols are connected to routing tables using filters. Routes
|
|
||||||
that come from network go to the protocol, it then passes them to
|
|
||||||
filters, if import filter accepts route, it gets to main routing
|
|
||||||
table. It is then broadcasted to all other protocols (filtered through
|
|
||||||
their export filters), which typically send it to the network.
|
|
||||||
|
|
||||||
Filters can alter routes passed between routing tables and
|
|
||||||
protocols.
|
|
||||||
|
|
||||||
<sect>Installing BIRD
|
<sect>Installing BIRD
|
||||||
|
|
||||||
|
@ -173,6 +137,43 @@ options. Most important (and not easily guessed) option is
|
||||||
use given filename for socket for communications with bird client, default is <file/bird.ctl/.
|
use given filename for socket for communications with bird client, default is <file/bird.ctl/.
|
||||||
</descrip>
|
</descrip>
|
||||||
|
|
||||||
|
<chapt>About routing tables
|
||||||
|
|
||||||
|
<p>Bird has one or more routing tables, which may or may not be
|
||||||
|
synchronized with kernel and which may or may not be synchronized with
|
||||||
|
each other (see the Pipe protocol). Each routing table contains list of
|
||||||
|
known routes. Each route consists of:
|
||||||
|
|
||||||
|
<itemize>
|
||||||
|
<item>network this route is for
|
||||||
|
<item>preference of this route (taken from preference of
|
||||||
|
protocol and possibly altered by filters)
|
||||||
|
<item>ip address of router who told us about this route
|
||||||
|
<item>ip address of router we should use for packets routing
|
||||||
|
using this route
|
||||||
|
<item>other attributes common to all routes
|
||||||
|
<item>dynamic attributes defined by protocols, which may or
|
||||||
|
may not be present (typically protocol metric)
|
||||||
|
</itemize>
|
||||||
|
|
||||||
|
Routing table maintains more than
|
||||||
|
one entry for network, but at most one entry for one network and one
|
||||||
|
protocol. The entry with biggest preference is used for routing. If
|
||||||
|
there are more entries with same preference and they are from same
|
||||||
|
protocol, protocol decides (typically according to metrics). If not,
|
||||||
|
internal ordering is used to decide. You can
|
||||||
|
get list of route attributes in "Route attributes" section in
|
||||||
|
filters.
|
||||||
|
|
||||||
|
<p>Protocols are connected to routing tables using filters. Routes
|
||||||
|
that come from network go to the protocol, it then passes them to
|
||||||
|
filters, if import filter accepts route, it gets to main routing
|
||||||
|
table. It is then broadcasted to all other protocols (filtered through
|
||||||
|
their export filters), which typically send it to the network.
|
||||||
|
|
||||||
|
Filters can alter routes passed between routing tables and
|
||||||
|
protocols.
|
||||||
|
|
||||||
<chapt>Configuration
|
<chapt>Configuration
|
||||||
|
|
||||||
<sect>Introduction
|
<sect>Introduction
|
||||||
|
@ -741,9 +742,12 @@ protocol bgp {
|
||||||
multihop 20 via 62.168.0.13; # Which is connected indirectly
|
multihop 20 via 62.168.0.13; # Which is connected indirectly
|
||||||
export filter { # We use non-trivial export rules
|
export filter { # We use non-trivial export rules
|
||||||
if source = RTS_STATIC then { # Export only static routes
|
if source = RTS_STATIC then { # Export only static routes
|
||||||
bgp_community.add((65000,5678)); # Assign our community
|
# Assign our community
|
||||||
if bgp_path ~ / 65000 / then # Artificially increase path length
|
bgp_community.add((65000,5678));
|
||||||
bgp_path.prepend(65000); # by prepending local AS number twice
|
# Artificially increase path length
|
||||||
|
# by prepending local AS number twice
|
||||||
|
if bgp_path ~ / 65000 / then
|
||||||
|
bgp_path.prepend(65000);
|
||||||
accept;
|
accept;
|
||||||
}
|
}
|
||||||
reject;
|
reject;
|
||||||
|
|
Loading…
Reference in a new issue