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