doc/routeserver.texi

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