0
0
mirror of https://gitlab.nic.cz/labs/bird.git synced 2024-11-17 08:38:42 +00:00

Added Pipe documentation.

This commit is contained in:
Martin Mares 2000-05-31 10:07:27 +00:00
parent 0884f49223
commit a2a3ced83e

View File

@ -753,6 +753,7 @@ protocol kernel { # Secondary routing table
table auxtable;
kernel table 100;
export all;
}
</code>
<p>The Kernel protocol doesn't define any route attributes.
@ -761,6 +762,105 @@ protocol kernel { # Secondary routing table
<sect1>Pipe
<sect2>Introduction
<p>The Pipe protocol serves as a link between two routing tables, allowing routes to be
passed from a table declared as primary (i.e., the one the pipe is connected using the
<cf/table/ configuration keyword) to the secondary one (declared using <cf/peer table/)
and vice versa, depending on what's allowed by the filters. Export filters control export
of routes from the primary table to the secondary one, import filters control the opposite
direction.
<p>The primary use of multiple routing tables and the pipe protocol is for policy routing
where handling of a single packet doesn't depend only on its destination address, but also
on its source address, source interface, protocol type and other similar parameters.
In many OS'es (Linux 2.2 being a good example) the kernel allows to enforce routing policies
by defining routing rules which choose one of several routing tables to be used for a packet
according to its parameters. Setting of these rules is outside the scope of BIRD's work
(you can use the <tt/ip/ command), but you can create several routing tables in BIRD,
connect them to the kernel ones, use filters to control which routes appear in which tables
and also you can employ the Pipe protocol to export a selected subset of one table in
another one.
<sect2>Configuration
<p><descrip>
<tag>peer table <m/table/</tag> Define secondary routing table to connect to. The
primary one is selected by the <cf/table/ keyword.
</descrip>
<sect2>Attributes
<p>The Pipe protocol doesn't define any route attributes.
<sect2>Example
<p>Let's consider a router which serves as a boundary router of two different autonomous
systems, each of them connected to a subset of interfaces of the router, having its own
exterior connectivity and wishing to use the other AS as a backup connectivity in case
of outage of its own exterior line.
<p>Probably the simplest solution to this situation is to use two routing tables (we'll
call them <cf/as1/ and <cf/as2/) and set up kernel routing rules, so that packets having
arrived from interfaces belonging to the first AS will be routed according to <cf/as1/
and similarly for the second AS. Thus we have split our router to two logical routers,
each one acting on its own routing table, having its own routing protocols on its own
interfaces. In order to use the other AS's routes for backup purposes, we can pass
the routes between the tables through a Pipe protocol while decreasing their preferences
and correcting their BGP paths to reflect AS boundary crossing.
<code>
table as1; # Define the tables
table as2;
protocol kernel kern1 { # Synchronize them with the kernel
table as1;
kernel table 1;
}
protocol kernel kern2 {
table as2;
kernel table 2;
}
protocol bgp bgp1 { # The outside connections
table as1;
local as 1;
neighbor 192.168.0.1 as 1001;
export all;
import all;
}
protocol bgp bgp2 {
table as2;
local as 2;
neighbor 10.0.0.1 as 1002;
export all;
import all;
}
protocol pipe { # The Pipe
table as1;
peer table as2;
export filter {
if net ~ [ 1.0.0.0/8+] then { # Only AS1 networks
if preference>10 then preference = preference-10;
if source=RTS_BGP then bgp_path.prepend(1);
accept;
}
reject;
};
import filter {
if net ~ [ 2.0.0.0/8+] then { # Only AS2 networks
if preference>10 then preference = preference-10;
if source=RTS_BGP then bgp_path.prepend(2);
accept;
}
reject;
};
}
</code>
<sect1>Rip
<sect2>Introduction