2004-11-12 Paul Jakma <paul@dishone.st>

[mirror_frr.git] / doc / routeserver.texi

@c -*-texinfo-*-\r
@c @value{COPYRIGHT_STR}\r
@c See file quagga.texi for copying conditions.\r
@c\r
@c This file is a modified version of Jose Luis Rubio's TeX sources \r
@c of his RS-Manual document\r
\r
@node Configuring Quagga as a Route Server\r
@chapter Configuring Quagga as a Route Server\r
\r
The purpose of a Route Server is to centralize the peerings between BGP\r
speakers. For example if we have an exchange point scenario with four BGP\r
speakers, each of which maintaining a BGP peering with the other three\r
(@pxref{fig:full-mesh}), we can convert it into a centralized scenario where\r
each of the four establishes a single BGP peering against the Route Server\r
(@pxref{fig:route-server}).\r
\r
We will first describe briefly the Route Server model implemented by Quagga.\r
We will explain the commands that have been added for configuring that\r
model. And finally we will show a full example of Quagga configured as Route\r
Server.\r
\r
@menu\r
* Description of the Route Server model::\r
* Commands for configuring a Route Server::\r
* Example of Route Server Configuration::\r
@end menu\r
\r
@node Description of the Route Server model\r
@section Description of the Route Server model\r
\r
First we are going to describe the normal processing that BGP announcements\r
suffer inside a standard BGP speaker, as shown in @ref{fig:normal-processing},\r
it consists of three steps:\r
\r
@itemize\r
@item When an announcement is received from some peer, the `In' filters\r
configured for that peer are applied to the announcement. These filters can\r
reject the announcement, accept it unmodified, or accept it with some of its\r
attributes modified.\r
\r
@item The announcements that pass the `In' filters go into the\r
Best Path Selection process, where they are compared to other\r
announcements referred to the same destination that have been\r
received from different peers (in case such other\r
announcements exist). For each different destination, the announcement\r
which is selected as the best is inserted into the BGP speaker's Loc-RIB.\r
\r
@item The routes which are inserted in the Loc-RIB are\r
considered for announcement to all the peers (except the one\r
from which the route came). This is done by passing the routes\r
in the Loc-RIB through the `Out' filters corresponding to each\r
peer. These filters can reject the route,\r
accept it unmodified, or accept it with some of its attributes\r
modified. Those routes which are accepted by the `Out' filters\r
of a peer are announced to that peer.\r
@end itemize\r
\r
@float Figure,fig:normal-processing\r
@image{fig-normal-processing,500pt,,Normal announcement processing,eps}\r
@caption{Announcement processing inside a ``normal'' BGP speaker}\r
@end float\r
\r
@float Figure,fig:full-mesh\r
@image{fig_topologies_full,,,Full Mesh BGP Topology,eps}\r
@caption{Full Mesh}\r
@end float\r
\r
@float Figure,fig:route-server\r
@image{fig_topologies_rs,,,Route Server BGP Topology,eps}\r
@caption{Route Server and clients} \r
@end float\r
\r
Of course we want that the routing tables obtained in each of the routers\r
are the same when using the route server than when not. But as a consequence\r
of having a single BGP peering (against the route server), the BGP speakers\r
can no longer distinguish from/to which peer each announce comes/goes.\r
@anchor{filter-delegation}This means that the routers connected to the route\r
server are not able to apply by themselves the same input/output filters\r
as in the full mesh scenario, so they have to delegate those functions to\r
the route server.\r
\r
Even more, the ``best path'' selection must be also performed inside the route\r
server on behalf of its clients. The reason is that if, after applying the\r
filters of the announcer and the (potential) receiver, the route server\r
decides to send to some client two or more different announcements referred\r
to the same destination, the client will only retain the last one,\r
considering it as an implicit withdrawal of the previous announcements for\r
the same destination. This is the expected behavior of a BGP speaker as\r
defined in @cite{RFC1771}, and even though there are some proposals of\r
mechanisms that permit multiple paths for the same destination to be sent\r
through a single BGP peering, none of them are currently supported by most\r
of the existing BGP implementations.\r
\r
As a consequence a route server must maintain additional information and\r
perform additional tasks for a RS-client that those necessary for common BGP\r
peerings. Essentially a route server must:\r
\r
@anchor{Route Server tasks}\r
@itemize\r
@item Maintain a separated Routing Information Base (Loc-RIB)\r
for each peer configured as RS-client, containing the routes\r
selected as a result of the ``Best Path Selection'' process\r
that is performed on behalf of that RS-client.\r
\r
@item Whenever it receives an announcement from a RS-client,\r
it must consider it for the Loc-RIBs of the other RS-clients.\r
\r
@anchor{Route-server path filter process}\r
@itemize\r
@item\r
This means that for each of them the route server must pass the\r
announcement through the appropriate `Out' filter of the\r
announcer.\r
\r
@item\r
Then through the  appropriate `In' filter of\r
the potential  receiver. \r
\r
@item\r
Only if the announcement is accepted by both filters it will be passed\r
to the ``Best Path Selection'' process.\r
\r
@item\r
Finally, it might go into the Loc-RIB of the receiver.\r
@end itemize\r
@c end of route-server best path process list\r
@end itemize\r
@c end of route-server tasks list\r
\r
When we talk about the ``appropriate'' filter, both the announcer and the\r
receiver of the route must be taken into account. Suppose that the route\r
server receives an announcement from client A, and the route server is\r
considering it for the Loc-RIB of client B. The filters that should be\r
applied are the same that would be used in the full mesh scenario, i.e.,\r
first the `Out' filter of router A for announcements going to router B, and\r
then the `In' filter of router B for announcements coming from router A.\r
\r
We call ``Export Policy'' of a RS-client to the set of `Out' filters that\r
the client would use if there was no route server. The same applies for the\r
``Import Policy'' of a RS-client and the set of `In' filters of the client\r
if there was no route server.\r
\r
It is also common to demand from a route server that it does not\r
modify some BGP attributes (next-hop, as-path and MED) that are usually\r
modified by standard BGP speakers before announcing a route.\r
\r
The announcement processing model implemented by Quagga is shown in\r
@ref{fig:rs-processing}. The figure shows a mixture of RS-clients (B, C and D)\r
with normal BGP peers (A). There are some details that worth additional\r
comments:\r
\r
@itemize\r
@item Announcements coming from a normal BGP peer are also\r
considered for the Loc-RIBs of all the RS-clients. But\r
logically they do not pass through any export policy.\r
\r
@item Those peers that are configured as RS-clients do not\r
receive any announce from the `Main' Loc-RIB.\r
\r
@item Apart from import and export policies,\r
`In' and `Out' filters can also be set for RS-clients. `In'\r
filters might be useful when the route server has also normal\r
BGP peers. On the other hand, `Out' filters for RS-clients are\r
probably unnecessary, but we decided not to remove them as\r
they do not hurt anybody (they can always be left empty).\r
@end itemize\r
\r
@float Figure,fig:rs-processing\r
@image{fig-rs-processing,500pt,,,eps}\r
@caption{Announcement processing model implemented by the Route Server}\r
@end float\r
\r
@node Commands for configuring a Route Server\r
@section Commands for configuring a Route Server\r
\r
Now we will describe the commands that have been added to quagga\r
in order to support the route server features.\r
\r
@deffn {Route-Server} {neighbor @var{peer-group} route-server-client} {}\r
@deffnx {Route-Server} {neighbor @var{A.B.C.D} route-server-client} {}\r
@deffnx {Route-Server} {neighbor @var{X:X::X:X} route-server-client} {}\r
This command configures the peer given by @var{peer}, @var{A.B.C.D} or\r
@var{X:X::X:X} as an RS-client.\r
\r
Actually this command is not new, it already existed in standard Quagga. It\r
enables the transparent mode for the specified peer. This means that some\r
BGP attributes (as-path, next-hop and MED) of the routes announced to that\r
peer are not modified.\r
\r
With the route server patch, this command, apart from setting the\r
transparent mode, creates a new Loc-RIB dedicated to the specified peer\r
(those named `Loc-RIB for X' in @ref{fig:rs-processing}.). Starting from\r
that moment, every announcement received by the route server will be also\r
considered for the new Loc-RIB.\r
@end deffn\r
\r
@deffn {Route-Server} {neigbor @{A.B.C.D|X.X::X.X|peer-group@} route-map WORD @{import|export@}} {}\r
This set of commands can be used to specify the route-map that\r
represents the Import or Export policy of a peer which is\r
configured as a RS-client (with the previous command).\r
@end deffn\r
\r
@deffn {Route-Server} {match peer @{A.B.C.D|X:X::X:X@}} {}\r
This is a new @emph{match} statement for use in route-maps, enabling them to\r
describe import/export policies. As we said before, an import/export policy\r
represents a set of input/output filters of the RS-client. This statement\r
makes possible that a single route-map represents the full set of filters\r
that a BGP speaker would use for its different peers in a non-RS scenario.\r
\r
The @emph{match peer} statement has different semantics whether it is used\r
inside an import or an export route-map. In the first case the statement\r
matches if the address of the peer who sends the announce is the same that\r
the address specified by @{A.B.C.D|X:X::X:X@}. For export route-maps it\r
matches when @{A.B.C.D|X:X::X:X@} is the address of the RS-Client into whose\r
Loc-RIB the announce is going to be inserted (how the same export policy is\r
applied before different Loc-RIBs is shown in @ref{fig:rs-processing}.).\r
@end deffn\r
\r
@deffn {Route-map Command} {call @var{WORD}} {}\r
This command (also used inside a route-map) jumps into a different\r
route-map, whose name is specified by @var{WORD}. When the called\r
route-map finishes, depending on its result the original route-map\r
continues or not. Apart from being useful for making import/export\r
route-maps easier to write, this command can also be used inside\r
any normal (in or out) route-map.\r
@end deffn\r
\r
@node Example of Route Server Configuration\r
@section Example of Route Server Configuration\r
\r
Finally we are going to show how to configure a Quagga daemon to act as a\r
Route Server. For this purpose we are going to present a scenario without\r
route server, and then we will show how to use the configurations of the BGP\r
routers to generate the configuration of the route server.\r
\r
All the configuration files shown in this section have been taken\r
from scenarios which were tested using the VNUML tool\r
@uref{http://www.dit.upm.es/vnuml,VNUML}. \r
\r
@menu\r
* Configuration of the BGP routers without Route Server::\r
* Configuration of the BGP routers with Route Server::\r
* Configuration of the Route Server itself::\r
* Further considerations about Import and Export route-maps::\r
@end menu\r
\r
@node Configuration of the BGP routers without Route Server\r
@subsection Configuration of the BGP routers without Route Server\r
\r
We will suppose that our initial scenario is an exchange point with three\r
BGP capable routers, named RA, RB and RC. Each of the BGP speakers generates\r
some routes (with the @var{network} command), and establishes BGP peerings\r
against the other two routers. These peerings have In and Out route-maps\r
configured, named like ``PEER-X-IN'' or ``PEER-X-OUT''. For example the\r
configuration file for router RA could be the following:\r
\r
@example\r
#Configuration for router 'RA'\r
!\r
hostname RA\r
password ****\r
!\r
router bgp 65001\r
  no bgp default ipv4-unicast\r
  neighbor 2001:0DB8::B remote-as 65002\r
  neighbor 2001:0DB8::C remote-as 65003\r
!\r
  address-family ipv6\r
    network 2001:0DB8:AAAA:1::/64\r
    network 2001:0DB8:AAAA:2::/64\r
    network 2001:0DB8:0000:1::/64\r
    network 2001:0DB8:0000:2::/64\r
\r
    neighbor 2001:0DB8::B activate\r
    neighbor 2001:0DB8::B soft-reconfiguration inbound\r
    neighbor 2001:0DB8::B route-map PEER-B-IN in\r
    neighbor 2001:0DB8::B route-map PEER-B-OUT out\r
\r
    neighbor 2001:0DB8::C activate\r
    neighbor 2001:0DB8::C soft-reconfiguration inbound\r
    neighbor 2001:0DB8::C route-map PEER-C-IN in\r
    neighbor 2001:0DB8::C route-map PEER-C-OUT out\r
  exit-address-family\r
!\r
ipv6 prefix-list COMMON-PREFIXES seq  5 permit 2001:0DB8:0000::/48 ge 64 le 64\r
ipv6 prefix-list COMMON-PREFIXES seq 10 deny any\r
!\r
ipv6 prefix-list PEER-A-PREFIXES seq  5 permit 2001:0DB8:AAAA::/48 ge 64 le 64\r
ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any\r
!\r
ipv6 prefix-list PEER-B-PREFIXES seq  5 permit 2001:0DB8:BBBB::/48 ge 64 le 64\r
ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any\r
!\r
ipv6 prefix-list PEER-C-PREFIXES seq  5 permit 2001:0DB8:CCCC::/48 ge 64 le 64\r
ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any\r
!\r
route-map PEER-B-IN permit 10\r
  match ipv6 address prefix-list COMMON-PREFIXES\r
  set metric 100\r
route-map PEER-B-IN permit 20\r
  match ipv6 address prefix-list PEER-B-PREFIXES\r
  set community 65001:11111\r
!\r
route-map PEER-C-IN permit 10\r
  match ipv6 address prefix-list COMMON-PREFIXES\r
  set metric 200\r
route-map PEER-C-IN permit 20\r
  match ipv6 address prefix-list PEER-C-PREFIXES\r
  set community 65001:22222\r
!\r
route-map PEER-B-OUT permit 10\r
  match ipv6 address prefix-list PEER-A-PREFIXES\r
!\r
route-map PEER-C-OUT permit 10\r
  match ipv6 address prefix-list PEER-A-PREFIXES\r
!\r
line vty\r
!\r
@end example\r
\r
@node Configuration of the BGP routers with Route Server\r
@subsection Configuration of the BGP routers with Route Server\r
\r
To convert the initial scenario into one with route server, first we must\r
modify the configuration of routers RA, RB and RC. Now they must not peer\r
between them, but only with the route server. For example, RA's\r
configuration would turn into:\r
\r
@example\r
# Configuration for router 'RA'\r
!\r
hostname RA\r
password ****\r
!\r
router bgp 65001\r
  no bgp default ipv4-unicast\r
  neighbor 2001:0DB8::FFFF remote-as 65000\r
!\r
  address-family ipv6\r
    network 2001:0DB8:AAAA:1::/64\r
    network 2001:0DB8:AAAA:2::/64\r
    network 2001:0DB8:0000:1::/64\r
    network 2001:0DB8:0000:2::/64\r
\r
    neighbor 2001:0DB8::FFFF activate\r
    neighbor 2001:0DB8::FFFF soft-reconfiguration inbound\r
  exit-address-family\r
!\r
line vty\r
!\r
@end example\r
\r
Which is logically much simpler than its initial configuration, as it now\r
maintains only one BGP peering and all the filters (route-maps) have\r
disappeared.\r
\r
@node Configuration of the Route Server itself\r
@subsection Configuration of the Route Server itself\r
\r
As we said when we described the functions of a route server\r
(@pxref{Description of the Route Server model}), it is in charge of all the\r
route filtering. To achieve that, the In and Out filters from the RA, RB and\r
RC configurations must be converted into Import and Export policies in the\r
route server.\r
\r
This is a fragment of the route server configuration (we only show\r
the policies for client RA):\r
\r
@example\r
# Configuration for Route Server ('RS')\r
!\r
hostname RS\r
password ix\r
!\r
bgp multiple-instance\r
!\r
router bgp 65000 view RS\r
  no bgp default ipv4-unicast\r
  neighbor 2001:0DB8::A  remote-as 65001\r
  neighbor 2001:0DB8::B  remote-as 65002\r
  neighbor 2001:0DB8::C  remote-as 65003\r
!\r
  address-family ipv6\r
    neighbor 2001:0DB8::A activate\r
    neighbor 2001:0DB8::A route-server-client\r
    neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import\r
    neighbor 2001:0DB8::A route-map RSCLIENT-A-EXPORT export\r
    neighbor 2001:0DB8::A soft-reconfiguration inbound\r
\r
    neighbor 2001:0DB8::B activate\r
    neighbor 2001:0DB8::B route-server-client\r
    neighbor 2001:0DB8::B route-map RSCLIENT-B-IMPORT import\r
    neighbor 2001:0DB8::B route-map RSCLIENT-B-EXPORT export\r
    neighbor 2001:0DB8::B soft-reconfiguration inbound\r
\r
    neighbor 2001:0DB8::C activate\r
    neighbor 2001:0DB8::C route-server-client\r
    neighbor 2001:0DB8::C route-map RSCLIENT-C-IMPORT import\r
    neighbor 2001:0DB8::C route-map RSCLIENT-C-EXPORT export\r
    neighbor 2001:0DB8::C soft-reconfiguration inbound\r
  exit-address-family\r
!\r
ipv6 prefix-list COMMON-PREFIXES seq  5 permit 2001:0DB8:0000::/48 ge 64 le 64\r
ipv6 prefix-list COMMON-PREFIXES seq 10 deny any\r
!\r
ipv6 prefix-list PEER-A-PREFIXES seq  5 permit 2001:0DB8:AAAA::/48 ge 64 le 64\r
ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any\r
!\r
ipv6 prefix-list PEER-B-PREFIXES seq  5 permit 2001:0DB8:BBBB::/48 ge 64 le 64\r
ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any\r
!\r
ipv6 prefix-list PEER-C-PREFIXES seq  5 permit 2001:0DB8:CCCC::/48 ge 64 le 64\r
ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any\r
!\r
route-map RSCLIENT-A-IMPORT permit 10\r
  match peer 2001:0DB8::B\r
  call A-IMPORT-FROM-B\r
route-map RSCLIENT-A-IMPORT permit 20\r
  match peer 2001:0DB8::C\r
  call A-IMPORT-FROM-C\r
!\r
route-map A-IMPORT-FROM-B permit 10\r
  match ipv6 address prefix-list COMMON-PREFIXES\r
  set metric 100\r
route-map A-IMPORT-FROM-B permit 20\r
  match ipv6 address prefix-list PEER-B-PREFIXES\r
  set community 65001:11111\r
!\r
route-map A-IMPORT-FROM-C permit 10\r
  match ipv6 address prefix-list COMMON-PREFIXES\r
  set metric 200\r
route-map A-IMPORT-FROM-C permit 20\r
  match ipv6 address prefix-list PEER-C-PREFIXES\r
  set community 65001:22222\r
!\r
route-map RSCLIENT-A-EXPORT permit 10\r
  match peer 2001:0DB8::B\r
  match ipv6 address prefix-list PEER-A-PREFIXES\r
route-map RSCLIENT-A-EXPORT permit 20\r
  match peer 2001:0DB8::C\r
  match ipv6 address prefix-list PEER-A-PREFIXES\r
!\r
...\r
...\r
...\r
@end example\r
\r
If you compare the initial configuration of RA with the route server\r
configuration above, you can see how easy it is to generate the Import and\r
Export policies for RA from the In and Out route-maps of RA's original\r
configuration.\r
\r
When there was no route server, RA maintained two peerings, one with RB and\r
another with RC. Each of this peerings had an In route-map configured. To\r
build the Import route-map for client RA in the route server, simply add\r
route-map entries following this scheme:\r
\r
@example\r
route-map <NAME> permit 10\r
    match peer <Peer Address>\r
    call <In Route-Map for this Peer>\r
route-map <NAME> permit 20\r
    match peer <Another Peer Address>\r
    call <In Route-Map for this Peer>\r
@end example\r
\r
This is exactly the process that has been followed to generate the route-map\r
RSCLIENT-A-IMPORT. The route-maps that are called inside it (A-IMPORT-FROM-B\r
and A-IMPORT-FROM-C) are exactly the same than the In route-maps from the\r
original configuration of RA (PEER-B-IN and PEER-C-IN), only the name is\r
different.\r
\r
The same could have been done to create the Export policy for RA (route-map\r
RSCLIENT-A-EXPORT), but in this case the original Out route-maps where so\r
simple that we decided not to use the @var{call WORD} commands, and we\r
integrated all in a single route-map (RSCLIENT-A-EXPORT).\r
\r
The Import and Export policies for RB and RC are not shown, but\r
the process would be identical.\r
\r
@node Further considerations about Import and Export route-maps\r
@subsection Further considerations about Import and Export route-maps\r
\r
The current version of the route server patch only allows to specify a\r
route-map for import and export policies, while in a standard BGP speaker\r
apart from route-maps there are other tools for performing input and output\r
filtering (access-lists, community-lists, ...). But this does not represent\r
any limitation, as all kinds of filters can be included in import/export\r
route-maps. For example suppose that in the non-route-server scenario peer\r
RA had the following filters configured for input from peer B:\r
\r
@example\r
    neighbor 2001:0DB8::B prefix-list LIST-1 in\r
    neighbor 2001:0DB8::B filter-list LIST-2 in\r
    neighbor 2001:0DB8::B route-map PEER-B-IN in\r
    ...\r
    ...\r
route-map PEER-B-IN permit 10\r
  match ipv6 address prefix-list COMMON-PREFIXES\r
  set local-preference 100\r
route-map PEER-B-IN permit 20\r
  match ipv6 address prefix-list PEER-B-PREFIXES\r
  set community 65001:11111\r
@end example\r
\r
It is posible to write a single route-map which is equivalent to\r
the three filters (the community-list, the prefix-list and the\r
route-map). That route-map can then be used inside the Import\r
policy in the route server. Lets see how to do it:\r
\r
@example\r
    neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import\r
    ...\r
!\r
...\r
route-map RSCLIENT-A-IMPORT permit 10\r
  match peer 2001:0DB8::B\r
  call A-IMPORT-FROM-B\r
...\r
...\r
!\r
route-map A-IMPORT-FROM-B permit 1\r
  match ipv6 address prefix-list LIST-1\r
  match as-path LIST-2\r
  on-match goto 10\r
route-map A-IMPORT-FROM-B deny 2\r
route-map A-IMPORT-FROM-B permit 10\r
  match ipv6 address prefix-list COMMON-PREFIXES\r
  set local-preference 100\r
route-map A-IMPORT-FROM-B permit 20\r
  match ipv6 address prefix-list PEER-B-PREFIXES\r
  set community 65001:11111\r
!\r
...\r
...\r
@end example\r
\r
The route-map A-IMPORT-FROM-B is equivalent to the three filters\r
(LIST-1, LIST-2 and PEER-B-IN). The first entry of route-map\r
A-IMPORT-FROM-B (sequence number 1) matches if and only if both\r
the prefix-list LIST-1 and the filter-list LIST-2 match. If that\r
happens, due to the ``on-match goto 10'' statement the next\r
route-map entry to be processed will be number 10, and as of that\r
point route-map A-IMPORT-FROM-B is identical to PEER-B-IN. If\r
the first entry does not match, `on-match goto 10'' will be\r
ignored and the next processed entry will be number 2, which will\r
deny the route.\r
\r
Thus, the result is the same that with the three original filters,\r
i.e., if either LIST-1 or LIST-2 rejects the route, it does not\r
reach the route-map PEER-B-IN. In case both LIST-1 and LIST-2\r
accept the route, it passes to PEER-B-IN, which can reject, accept\r
or modify the route.\r