1@c -*-texinfo-*- 2@c @value{COPYRIGHT_STR} 3@c See file quagga.texi for copying conditions. 4@c 5@c This file is a modified version of Jose Luis Rubio's TeX sources 6@c of his RS-Manual document 7 8@node Configuring Quagga as a Route Server 9@chapter Configuring Quagga as a Route Server 10 11The purpose of a Route Server is to centralize the peerings between BGP 12speakers. For example if we have an exchange point scenario with four BGP 13speakers, each of which maintaining a BGP peering with the other three 14(@pxref{fig:full-mesh}), we can convert it into a centralized scenario where 15each of the four establishes a single BGP peering against the Route Server 16(@pxref{fig:route-server}). 17 18We will first describe briefly the Route Server model implemented by Quagga. 19We will explain the commands that have been added for configuring that 20model. And finally we will show a full example of Quagga configured as Route 21Server. 22 23@menu 24* Description of the Route Server model:: 25* Commands for configuring a Route Server:: 26* Example of Route Server Configuration:: 27@end menu 28 29@node Description of the Route Server model 30@section Description of the Route Server model 31 32First we are going to describe the normal processing that BGP announcements 33suffer inside a standard BGP speaker, as shown in @ref{fig:normal-processing}, 34it consists of three steps: 35 36@itemize @bullet 37@item 38When an announcement is received from some peer, the `In' filters 39configured for that peer are applied to the announcement. These filters can 40reject the announcement, accept it unmodified, or accept it with some of its 41attributes modified. 42 43@item 44The announcements that pass the `In' filters go into the 45Best Path Selection process, where they are compared to other 46announcements referred to the same destination that have been 47received from different peers (in case such other 48announcements exist). For each different destination, the announcement 49which is selected as the best is inserted into the BGP speaker's Loc-RIB. 50 51@item 52The routes which are inserted in the Loc-RIB are 53considered for announcement to all the peers (except the one 54from which the route came). This is done by passing the routes 55in the Loc-RIB through the `Out' filters corresponding to each 56peer. These filters can reject the route, 57accept it unmodified, or accept it with some of its attributes 58modified. Those routes which are accepted by the `Out' filters 59of a peer are announced to that peer. 60@end itemize 61 62@float Figure,fig:normal-processing 63@image{fig-normal-processing,400pt,,Normal announcement processing} 64@caption{Announcement processing inside a ``normal'' BGP speaker} 65@end float 66 67@float Figure,fig:full-mesh 68@image{fig_topologies_full,120pt,,Full Mesh BGP Topology} 69@caption{Full Mesh} 70@end float 71 72@float Figure,fig:route-server 73@image{fig_topologies_rs,120pt,,Route Server BGP Topology} 74@caption{Route Server and clients} 75@end float 76 77Of course we want that the routing tables obtained in each of the routers 78are the same when using the route server than when not. But as a consequence 79of having a single BGP peering (against the route server), the BGP speakers 80can no longer distinguish from/to which peer each announce comes/goes. 81@anchor{filter-delegation}This means that the routers connected to the route 82server are not able to apply by themselves the same input/output filters 83as in the full mesh scenario, so they have to delegate those functions to 84the route server. 85 86Even more, the ``best path'' selection must be also performed inside 87the route server on behalf of its clients. The reason is that if, after 88applying the filters of the announcer and the (potential) receiver, the 89route server decides to send to some client two or more different 90announcements referred to the same destination, the client will only 91retain the last one, considering it as an implicit withdrawal of the 92previous announcements for the same destination. This is the expected 93behavior of a BGP speaker as defined in @cite{RFC1771}, and even though 94there are some proposals of mechanisms that permit multiple paths for 95the same destination to be sent through a single BGP peering, none are 96currently supported by most existing BGP implementations. 97 98As a consequence a route server must maintain additional information and 99perform additional tasks for a RS-client that those necessary for common BGP 100peerings. Essentially a route server must: 101 102@anchor{Route Server tasks} 103@itemize @bullet 104@item 105Maintain a separated Routing Information Base (Loc-RIB) 106for each peer configured as RS-client, containing the routes 107selected as a result of the ``Best Path Selection'' process 108that is performed on behalf of that RS-client. 109 110@item 111Whenever it receives an announcement from a RS-client, 112it must consider it for the Loc-RIBs of the other RS-clients. 113 114@anchor{Route-server path filter process} 115@itemize @bullet 116@item 117This means that for each of them the route server must pass the 118announcement through the appropriate `Out' filter of the 119announcer. 120 121@item 122Then through the appropriate `In' filter of 123the potential receiver. 124 125@item 126Only if the announcement is accepted by both filters it will be passed 127to the ``Best Path Selection'' process. 128 129@item 130Finally, it might go into the Loc-RIB of the receiver. 131@end itemize 132@end itemize 133 134When we talk about the ``appropriate'' filter, both the announcer and the 135receiver of the route must be taken into account. Suppose that the route 136server receives an announcement from client A, and the route server is 137considering it for the Loc-RIB of client B. The filters that should be 138applied are the same that would be used in the full mesh scenario, i.e., 139first the `Out' filter of router A for announcements going to router B, and 140then the `In' filter of router B for announcements coming from router A. 141 142We call ``Export Policy'' of a RS-client to the set of `Out' filters that 143the client would use if there was no route server. The same applies for the 144``Import Policy'' of a RS-client and the set of `In' filters of the client 145if there was no route server. 146 147It is also common to demand from a route server that it does not 148modify some BGP attributes (next-hop, as-path and MED) that are usually 149modified by standard BGP speakers before announcing a route. 150 151The announcement processing model implemented by Quagga is shown in 152@ref{fig:rs-processing}. The figure shows a mixture of RS-clients (B, C and D) 153with normal BGP peers (A). There are some details that worth additional 154comments: 155 156@itemize @bullet 157@item 158Announcements coming from a normal BGP peer are also 159considered for the Loc-RIBs of all the RS-clients. But 160logically they do not pass through any export policy. 161 162@item 163Those peers that are configured as RS-clients do not 164receive any announce from the `Main' Loc-RIB. 165 166@item 167Apart from import and export policies, 168`In' and `Out' filters can also be set for RS-clients. `In' 169filters might be useful when the route server has also normal 170BGP peers. On the other hand, `Out' filters for RS-clients are 171probably unnecessary, but we decided not to remove them as 172they do not hurt anybody (they can always be left empty). 173@end itemize 174 175@float Figure,fig:rs-processing 176@image{fig-rs-processing,450pt,,Route Server Processing Model} 177@caption{Announcement processing model implemented by the Route Server} 178@end float 179 180@node Commands for configuring a Route Server 181@section Commands for configuring a Route Server 182 183Now we will describe the commands that have been added to quagga 184in order to support the route server features. 185 186@deffn {Route-Server} {neighbor @var{peer-group} route-server-client} {} 187@deffnx {Route-Server} {neighbor @var{A.B.C.D} route-server-client} {} 188@deffnx {Route-Server} {neighbor @var{X:X::X:X} route-server-client} {} 189This command configures the peer given by @var{peer}, @var{A.B.C.D} or 190@var{X:X::X:X} as an RS-client. 191 192Actually this command is not new, it already existed in standard Quagga. It 193enables the transparent mode for the specified peer. This means that some 194BGP attributes (as-path, next-hop and MED) of the routes announced to that 195peer are not modified. 196 197With the route server patch, this command, apart from setting the 198transparent mode, creates a new Loc-RIB dedicated to the specified peer 199(those named `Loc-RIB for X' in @ref{fig:rs-processing}.). Starting from 200that moment, every announcement received by the route server will be also 201considered for the new Loc-RIB. 202@end deffn 203 204@deffn {Route-Server} {neigbor @{A.B.C.D|X.X::X.X|peer-group@} route-map WORD @{import|export@}} {} 205This set of commands can be used to specify the route-map that 206represents the Import or Export policy of a peer which is 207configured as a RS-client (with the previous command). 208@end deffn 209 210@deffn {Route-Server} {match peer @{A.B.C.D|X:X::X:X@}} {} 211This is a new @emph{match} statement for use in route-maps, enabling them to 212describe import/export policies. As we said before, an import/export policy 213represents a set of input/output filters of the RS-client. This statement 214makes possible that a single route-map represents the full set of filters 215that a BGP speaker would use for its different peers in a non-RS scenario. 216 217The @emph{match peer} statement has different semantics whether it is used 218inside an import or an export route-map. In the first case the statement 219matches if the address of the peer who sends the announce is the same that 220the address specified by @{A.B.C.D|X:X::X:X@}. For export route-maps it 221matches when @{A.B.C.D|X:X::X:X@} is the address of the RS-Client into whose 222Loc-RIB the announce is going to be inserted (how the same export policy is 223applied before different Loc-RIBs is shown in @ref{fig:rs-processing}.). 224@end deffn 225 226@deffn {Route-map Command} {call @var{WORD}} {} 227This command (also used inside a route-map) jumps into a different 228route-map, whose name is specified by @var{WORD}. When the called 229route-map finishes, depending on its result the original route-map 230continues or not. Apart from being useful for making import/export 231route-maps easier to write, this command can also be used inside 232any normal (in or out) route-map. 233@end deffn 234 235@node Example of Route Server Configuration 236@section Example of Route Server Configuration 237 238Finally we are going to show how to configure a Quagga daemon to act as a 239Route Server. For this purpose we are going to present a scenario without 240route server, and then we will show how to use the configurations of the BGP 241routers to generate the configuration of the route server. 242 243All the configuration files shown in this section have been taken 244from scenarios which were tested using the VNUML tool 245@uref{http://www.dit.upm.es/vnuml,VNUML}. 246 247@menu 248* Configuration of the BGP routers without Route Server:: 249* Configuration of the BGP routers with Route Server:: 250* Configuration of the Route Server itself:: 251* Further considerations about Import and Export route-maps:: 252@end menu 253 254@node Configuration of the BGP routers without Route Server 255@subsection Configuration of the BGP routers without Route Server 256 257We will suppose that our initial scenario is an exchange point with three 258BGP capable routers, named RA, RB and RC. Each of the BGP speakers generates 259some routes (with the @var{network} command), and establishes BGP peerings 260against the other two routers. These peerings have In and Out route-maps 261configured, named like ``PEER-X-IN'' or ``PEER-X-OUT''. For example the 262configuration file for router RA could be the following: 263 264@exampleindent 0 265@example 266#Configuration for router 'RA' 267! 268hostname RA 269password **** 270! 271router bgp 65001 272 no bgp default ipv4-unicast 273 neighbor 2001:0DB8::B remote-as 65002 274 neighbor 2001:0DB8::C remote-as 65003 275! 276 address-family ipv6 277 network 2001:0DB8:AAAA:1::/64 278 network 2001:0DB8:AAAA:2::/64 279 network 2001:0DB8:0000:1::/64 280 network 2001:0DB8:0000:2::/64 281 282 neighbor 2001:0DB8::B activate 283 neighbor 2001:0DB8::B soft-reconfiguration inbound 284 neighbor 2001:0DB8::B route-map PEER-B-IN in 285 neighbor 2001:0DB8::B route-map PEER-B-OUT out 286 287 neighbor 2001:0DB8::C activate 288 neighbor 2001:0DB8::C soft-reconfiguration inbound 289 neighbor 2001:0DB8::C route-map PEER-C-IN in 290 neighbor 2001:0DB8::C route-map PEER-C-OUT out 291 exit-address-family 292! 293ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64 294ipv6 prefix-list COMMON-PREFIXES seq 10 deny any 295! 296ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64 297ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any 298! 299ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64 300ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any 301! 302ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64 303ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any 304! 305route-map PEER-B-IN permit 10 306 match ipv6 address prefix-list COMMON-PREFIXES 307 set metric 100 308route-map PEER-B-IN permit 20 309 match ipv6 address prefix-list PEER-B-PREFIXES 310 set community 65001:11111 311! 312route-map PEER-C-IN permit 10 313 match ipv6 address prefix-list COMMON-PREFIXES 314 set metric 200 315route-map PEER-C-IN permit 20 316 match ipv6 address prefix-list PEER-C-PREFIXES 317 set community 65001:22222 318! 319route-map PEER-B-OUT permit 10 320 match ipv6 address prefix-list PEER-A-PREFIXES 321! 322route-map PEER-C-OUT permit 10 323 match ipv6 address prefix-list PEER-A-PREFIXES 324! 325line vty 326! 327@end example 328 329@node Configuration of the BGP routers with Route Server 330@subsection Configuration of the BGP routers with Route Server 331 332To convert the initial scenario into one with route server, first we must 333modify the configuration of routers RA, RB and RC. Now they must not peer 334between them, but only with the route server. For example, RA's 335configuration would turn into: 336 337@example 338# Configuration for router 'RA' 339! 340hostname RA 341password **** 342! 343router bgp 65001 344 no bgp default ipv4-unicast 345 neighbor 2001:0DB8::FFFF remote-as 65000 346! 347 address-family ipv6 348 network 2001:0DB8:AAAA:1::/64 349 network 2001:0DB8:AAAA:2::/64 350 network 2001:0DB8:0000:1::/64 351 network 2001:0DB8:0000:2::/64 352 353 neighbor 2001:0DB8::FFFF activate 354 neighbor 2001:0DB8::FFFF soft-reconfiguration inbound 355 exit-address-family 356! 357line vty 358! 359@end example 360 361Which is logically much simpler than its initial configuration, as it now 362maintains only one BGP peering and all the filters (route-maps) have 363disappeared. 364 365@node Configuration of the Route Server itself 366@subsection Configuration of the Route Server itself 367 368As we said when we described the functions of a route server 369(@pxref{Description of the Route Server model}), it is in charge of all the 370route filtering. To achieve that, the In and Out filters from the RA, RB and 371RC configurations must be converted into Import and Export policies in the 372route server. 373 374This is a fragment of the route server configuration (we only show 375the policies for client RA): 376 377@example 378# Configuration for Route Server ('RS') 379! 380hostname RS 381password ix 382! 383bgp multiple-instance 384! 385router bgp 65000 view RS 386 no bgp default ipv4-unicast 387 neighbor 2001:0DB8::A remote-as 65001 388 neighbor 2001:0DB8::B remote-as 65002 389 neighbor 2001:0DB8::C remote-as 65003 390! 391 address-family ipv6 392 neighbor 2001:0DB8::A activate 393 neighbor 2001:0DB8::A route-server-client 394 neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import 395 neighbor 2001:0DB8::A route-map RSCLIENT-A-EXPORT export 396 neighbor 2001:0DB8::A soft-reconfiguration inbound 397 398 neighbor 2001:0DB8::B activate 399 neighbor 2001:0DB8::B route-server-client 400 neighbor 2001:0DB8::B route-map RSCLIENT-B-IMPORT import 401 neighbor 2001:0DB8::B route-map RSCLIENT-B-EXPORT export 402 neighbor 2001:0DB8::B soft-reconfiguration inbound 403 404 neighbor 2001:0DB8::C activate 405 neighbor 2001:0DB8::C route-server-client 406 neighbor 2001:0DB8::C route-map RSCLIENT-C-IMPORT import 407 neighbor 2001:0DB8::C route-map RSCLIENT-C-EXPORT export 408 neighbor 2001:0DB8::C soft-reconfiguration inbound 409 exit-address-family 410! 411ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64 412ipv6 prefix-list COMMON-PREFIXES seq 10 deny any 413! 414ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64 415ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any 416! 417ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64 418ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any 419! 420ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64 421ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any 422! 423route-map RSCLIENT-A-IMPORT permit 10 424 match peer 2001:0DB8::B 425 call A-IMPORT-FROM-B 426route-map RSCLIENT-A-IMPORT permit 20 427 match peer 2001:0DB8::C 428 call A-IMPORT-FROM-C 429! 430route-map A-IMPORT-FROM-B permit 10 431 match ipv6 address prefix-list COMMON-PREFIXES 432 set metric 100 433route-map A-IMPORT-FROM-B permit 20 434 match ipv6 address prefix-list PEER-B-PREFIXES 435 set community 65001:11111 436! 437route-map A-IMPORT-FROM-C permit 10 438 match ipv6 address prefix-list COMMON-PREFIXES 439 set metric 200 440route-map A-IMPORT-FROM-C permit 20 441 match ipv6 address prefix-list PEER-C-PREFIXES 442 set community 65001:22222 443! 444route-map RSCLIENT-A-EXPORT permit 10 445 match peer 2001:0DB8::B 446 match ipv6 address prefix-list PEER-A-PREFIXES 447route-map RSCLIENT-A-EXPORT permit 20 448 match peer 2001:0DB8::C 449 match ipv6 address prefix-list PEER-A-PREFIXES 450! 451... 452... 453... 454@end example 455 456If you compare the initial configuration of RA with the route server 457configuration above, you can see how easy it is to generate the Import and 458Export policies for RA from the In and Out route-maps of RA's original 459configuration. 460 461When there was no route server, RA maintained two peerings, one with RB and 462another with RC. Each of this peerings had an In route-map configured. To 463build the Import route-map for client RA in the route server, simply add 464route-map entries following this scheme: 465 466@example 467route-map <NAME> permit 10 468 match peer <Peer Address> 469 call <In Route-Map for this Peer> 470route-map <NAME> permit 20 471 match peer <Another Peer Address> 472 call <In Route-Map for this Peer> 473@end example 474 475This is exactly the process that has been followed to generate the route-map 476RSCLIENT-A-IMPORT. The route-maps that are called inside it (A-IMPORT-FROM-B 477and A-IMPORT-FROM-C) are exactly the same than the In route-maps from the 478original configuration of RA (PEER-B-IN and PEER-C-IN), only the name is 479different. 480 481The same could have been done to create the Export policy for RA (route-map 482RSCLIENT-A-EXPORT), but in this case the original Out route-maps where so 483simple that we decided not to use the @var{call WORD} commands, and we 484integrated all in a single route-map (RSCLIENT-A-EXPORT). 485 486The Import and Export policies for RB and RC are not shown, but 487the process would be identical. 488 489@node Further considerations about Import and Export route-maps 490@subsection Further considerations about Import and Export route-maps 491 492The current version of the route server patch only allows to specify a 493route-map for import and export policies, while in a standard BGP speaker 494apart from route-maps there are other tools for performing input and output 495filtering (access-lists, community-lists, ...). But this does not represent 496any limitation, as all kinds of filters can be included in import/export 497route-maps. For example suppose that in the non-route-server scenario peer 498RA had the following filters configured for input from peer B: 499 500@example 501 neighbor 2001:0DB8::B prefix-list LIST-1 in 502 neighbor 2001:0DB8::B filter-list LIST-2 in 503 neighbor 2001:0DB8::B route-map PEER-B-IN in 504 ... 505 ... 506route-map PEER-B-IN permit 10 507 match ipv6 address prefix-list COMMON-PREFIXES 508 set local-preference 100 509route-map PEER-B-IN permit 20 510 match ipv6 address prefix-list PEER-B-PREFIXES 511 set community 65001:11111 512@end example 513 514It is posible to write a single route-map which is equivalent to 515the three filters (the community-list, the prefix-list and the 516route-map). That route-map can then be used inside the Import 517policy in the route server. Lets see how to do it: 518 519@example 520 neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import 521 ... 522! 523... 524route-map RSCLIENT-A-IMPORT permit 10 525 match peer 2001:0DB8::B 526 call A-IMPORT-FROM-B 527... 528... 529! 530route-map A-IMPORT-FROM-B permit 1 531 match ipv6 address prefix-list LIST-1 532 match as-path LIST-2 533 on-match goto 10 534route-map A-IMPORT-FROM-B deny 2 535route-map A-IMPORT-FROM-B permit 10 536 match ipv6 address prefix-list COMMON-PREFIXES 537 set local-preference 100 538route-map A-IMPORT-FROM-B permit 20 539 match ipv6 address prefix-list PEER-B-PREFIXES 540 set community 65001:11111 541! 542... 543... 544@end example 545 546The route-map A-IMPORT-FROM-B is equivalent to the three filters 547(LIST-1, LIST-2 and PEER-B-IN). The first entry of route-map 548A-IMPORT-FROM-B (sequence number 1) matches if and only if both 549the prefix-list LIST-1 and the filter-list LIST-2 match. If that 550happens, due to the ``on-match goto 10'' statement the next 551route-map entry to be processed will be number 10, and as of that 552point route-map A-IMPORT-FROM-B is identical to PEER-B-IN. If 553the first entry does not match, `on-match goto 10'' will be 554ignored and the next processed entry will be number 2, which will 555deny the route. 556 557Thus, the result is the same that with the three original filters, 558i.e., if either LIST-1 or LIST-2 rejects the route, it does not 559reach the route-map PEER-B-IN. In case both LIST-1 and LIST-2 560accept the route, it passes to PEER-B-IN, which can reject, accept 561or modify the route. 562