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 (@pxref{fig:full-mesh}), we can convert it into a centralized scenario where
  15 each of the four establishes a single BGP peering against the Route Server
  16 (@pxref{fig:route-server}).
  17
  18 We will first describe briefly the Route Server model implemented by Quagga.
  19 We will explain the commands that have been added for configuring that
  20 model. And finally we will show a full example of Quagga configured as Route
  21 Server.
  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
  32 First we are going to describe the normal processing that BGP announcements
  33 suffer inside a standard BGP speaker, as shown in @ref{fig:normal-processing},
  34 it consists of three steps:
  35
  36 @itemize @bullet
  37 @item
  38 When an announcement is received from some peer, the `In' filters
  39 configured for that peer are applied to the announcement. These filters can
  40 reject the announcement, accept it unmodified, or accept it with some of its
  41 attributes modified.
  42
  43 @item
  44 The announcements that pass the `In' filters go into the
  45 Best Path Selection process, where they are compared to other
  46 announcements referred to the same destination that have been
  47 received from different peers (in case such other
  48 announcements exist). For each different destination, the announcement
  49 which is selected as the best is inserted into the BGP speaker's Loc-RIB.
  50
  51 @item
  52 The routes which are inserted in the Loc-RIB are
  53 considered for announcement to all the peers (except the one
  54 from which the route came). This is done by passing the routes
  55 in the Loc-RIB through the `Out' filters corresponding to each
  56 peer. These filters can reject the route,
  57 accept it unmodified, or accept it with some of its attributes
  58 modified. Those routes which are accepted by the `Out' filters
  59 of 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
  77 Of course we want that the routing tables obtained in each of the routers
  78 are the same when using the route server than when not. But as a consequence
  79 of having a single BGP peering (against the route server), the BGP speakers
  80 can no longer distinguish from/to which peer each announce comes/goes.
  81 @anchor{filter-delegation}This means that the routers connected to the route
  82 server are not able to apply by themselves the same input/output filters
  83 as in the full mesh scenario, so they have to delegate those functions to
  84 the route server.
  85
  86 Even more, the ``best path'' selection must be also performed inside
  87 the route server on behalf of its clients. The reason is that if, after
  88 applying the filters of the announcer and the (potential) receiver, the
  89 route server decides to send to some client two or more different
  90 announcements referred to the same destination, the client will only
  91 retain the last one, considering it as an implicit withdrawal of the
  92 previous announcements for the same destination. This is the expected
  93 behavior of a BGP speaker as defined in @cite{RFC1771}, and even though
  94 there are some proposals of mechanisms that permit multiple paths for
  95 the same destination to be sent through a single BGP peering, none are
  96 currently supported by most existing BGP implementations.
  97
  98 As a consequence a route server must maintain additional information and
  99 perform additional tasks for a RS-client that those necessary for common BGP
 100 peerings. Essentially a route server must:
 101
 102 @anchor{Route Server tasks}
 103 @itemize @bullet
 104 @item
 105 Maintain a separated Routing Information Base (Loc-RIB)
 106 for each peer configured as RS-client, containing the routes
 107 selected as a result of the ``Best Path Selection'' process
 108 that is performed on behalf of that RS-client.
 109
 110 @item
 111 Whenever it receives an announcement from a RS-client,
 112 it 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
 117 This means that for each of them the route server must pass the
 118 announcement through the appropriate `Out' filter of the
 119 announcer.
 120
 121 @item
 122 Then through the  appropriate `In' filter of
 123 the potential  receiver.
 124
 125 @item
 126 Only if the announcement is accepted by both filters it will be passed
 127 to the ``Best Path Selection'' process.
 128
 129 @item
 130 Finally, it might go into the Loc-RIB of the receiver.
 131 @end itemize
 132 @end itemize
 133
 134 When we talk about the ``appropriate'' filter, both the announcer and the
 135 receiver of the route must be taken into account. Suppose that the route
 136 server receives an announcement from client A, and the route server is
 137 considering it for the Loc-RIB of client B. The filters that should be
 138 applied are the same that would be used in the full mesh scenario, i.e.,
 139 first the `Out' filter of router A for announcements going to router B, and
 140 then the `In' filter of router B for announcements coming from router A.
 141
 142 We call ``Export Policy'' of a RS-client to the set of `Out' filters that
 143 the 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
 145 if there was no route server.
 146
 147 It is also common to demand from a route server that it does not
 148 modify some BGP attributes (next-hop, as-path and MED) that are usually
 149 modified by standard BGP speakers before announcing a route.
 150
 151 The 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)
 153 with normal BGP peers (A). There are some details that worth additional
 154 comments:
 155
 156 @itemize @bullet
 157 @item
 158 Announcements coming from a normal BGP peer are also
 159 considered for the Loc-RIBs of all the RS-clients. But
 160 logically they do not pass through any export policy.
 161
 162 @item
 163 Those peers that are configured as RS-clients do not
 164 receive any announce from the `Main' Loc-RIB.
 165
 166 @item
 167 Apart from import and export policies,
 168 `In' and `Out' filters can also be set for RS-clients. `In'
 169 filters might be useful when the route server has also normal
 170 BGP peers. On the other hand, `Out' filters for RS-clients are
 171 probably unnecessary, but we decided not to remove them as
 172 they 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
 183 Now we will describe the commands that have been added to quagga
 184 in 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} {}
 189 This 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
 192 Actually this command is not new, it already existed in standard Quagga. It
 193 enables the transparent mode for the specified peer. This means that some
 194 BGP attributes (as-path, next-hop and MED) of the routes announced to that
 195 peer are not modified.
 196
 197 With the route server patch, this command, apart from setting the
 198 transparent 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
 200 that moment, every announcement received by the route server will be also
 201 considered 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@}} {}
 205 This set of commands can be used to specify the route-map that
 206 represents the Import or Export policy of a peer which is
 207 configured 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@}} {}
 211 This is a new @emph{match} statement for use in route-maps, enabling them to
 212 describe import/export policies. As we said before, an import/export policy
 213 represents a set of input/output filters of the RS-client. This statement
 214 makes possible that a single route-map represents the full set of filters
 215 that a BGP speaker would use for its different peers in a non-RS scenario.
 216
 217 The @emph{match peer} statement has different semantics whether it is used
 218 inside an import or an export route-map. In the first case the statement
 219 matches if the address of the peer who sends the announce is the same that
 220 the address specified by @{A.B.C.D|X:X::X:X@}. For export route-maps it
 221 matches when @{A.B.C.D|X:X::X:X@} is the address of the RS-Client into whose
 222 Loc-RIB the announce is going to be inserted (how the same export policy is
 223 applied before different Loc-RIBs is shown in @ref{fig:rs-processing}.).
 224 @end deffn
 225
 226 @deffn {Route-map Command} {call @var{WORD}} {}
 227 This command (also used inside a route-map) jumps into a different
 228 route-map, whose name is specified by @var{WORD}. When the called
 229 route-map finishes, depending on its result the original route-map
 230 continues or not. Apart from being useful for making import/export
 231 route-maps easier to write, this command can also be used inside
 232 any 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
 238 Finally we are going to show how to configure a Quagga daemon to act as a
 239 Route Server. For this purpose we are going to present a scenario without
 240 route server, and then we will show how to use the configurations of the BGP
 241 routers to generate the configuration of the route server.
 242
 243 All the configuration files shown in this section have been taken
 244 from 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
 257 We will suppose that our initial scenario is an exchange point with three
 258 BGP capable routers, named RA, RB and RC. Each of the BGP speakers generates
 259 some routes (with the @var{network} command), and establishes BGP peerings
 260 against the other two routers. These peerings have In and Out route-maps
 261 configured, named like ``PEER-X-IN'' or ``PEER-X-OUT''. For example the
 262 configuration file for router RA could be the following:
 263
 264 @exampleindent 0
 265 @example
 266 #Configuration for router 'RA'
 267 !
 268 hostname RA
 269 password ****
 270 !
 271 router 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 !
 293 ipv6 prefix-list COMMON-PREFIXES seq  5 permit 2001:0DB8:0000::/48 ge 64 le 64
 294 ipv6 prefix-list COMMON-PREFIXES seq 10 deny any
 295 !
 296 ipv6 prefix-list PEER-A-PREFIXES seq  5 permit 2001:0DB8:AAAA::/48 ge 64 le 64
 297 ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any
 298 !
 299 ipv6 prefix-list PEER-B-PREFIXES seq  5 permit 2001:0DB8:BBBB::/48 ge 64 le 64
 300 ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any
 301 !
 302 ipv6 prefix-list PEER-C-PREFIXES seq  5 permit 2001:0DB8:CCCC::/48 ge 64 le 64
 303 ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any
 304 !
 305 route-map PEER-B-IN permit 10
 306   match ipv6 address prefix-list COMMON-PREFIXES
 307   set metric 100
 308 route-map PEER-B-IN permit 20
 309   match ipv6 address prefix-list PEER-B-PREFIXES
 310   set community 65001:11111
 311 !
 312 route-map PEER-C-IN permit 10
 313   match ipv6 address prefix-list COMMON-PREFIXES
 314   set metric 200
 315 route-map PEER-C-IN permit 20
 316   match ipv6 address prefix-list PEER-C-PREFIXES
 317   set community 65001:22222
 318 !
 319 route-map PEER-B-OUT permit 10
 320   match ipv6 address prefix-list PEER-A-PREFIXES
 321 !
 322 route-map PEER-C-OUT permit 10
 323   match ipv6 address prefix-list PEER-A-PREFIXES
 324 !
 325 line 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
 332 To convert the initial scenario into one with route server, first we must
 333 modify the configuration of routers RA, RB and RC. Now they must not peer
 334 between them, but only with the route server. For example, RA's
 335 configuration would turn into:
 336
 337 @example
 338 # Configuration for router 'RA'
 339 !
 340 hostname RA
 341 password ****
 342 !
 343 router 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 !
 357 line vty
 358 !
 359 @end example
 360
 361 Which is logically much simpler than its initial configuration, as it now
 362 maintains only one BGP peering and all the filters (route-maps) have
 363 disappeared.
 364
 365 @node Configuration of the Route Server itself
 366 @subsection Configuration of the Route Server itself
 367
 368 As 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
 370 route filtering. To achieve that, the In and Out filters from the RA, RB and
 371 RC configurations must be converted into Import and Export policies in the
 372 route server.
 373
 374 This is a fragment of the route server configuration (we only show
 375 the policies for client RA):
 376
 377 @example
 378 # Configuration for Route Server ('RS')
 379 !
 380 hostname RS
 381 password ix
 382 !
 383 bgp multiple-instance
 384 !
 385 router 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 !
 411 ipv6 prefix-list COMMON-PREFIXES seq  5 permit 2001:0DB8:0000::/48 ge 64 le 64
 412 ipv6 prefix-list COMMON-PREFIXES seq 10 deny any
 413 !
 414 ipv6 prefix-list PEER-A-PREFIXES seq  5 permit 2001:0DB8:AAAA::/48 ge 64 le 64
 415 ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any
 416 !
 417 ipv6 prefix-list PEER-B-PREFIXES seq  5 permit 2001:0DB8:BBBB::/48 ge 64 le 64
 418 ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any
 419 !
 420 ipv6 prefix-list PEER-C-PREFIXES seq  5 permit 2001:0DB8:CCCC::/48 ge 64 le 64
 421 ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any
 422 !
 423 route-map RSCLIENT-A-IMPORT permit 10
 424   match peer 2001:0DB8::B
 425   call A-IMPORT-FROM-B
 426 route-map RSCLIENT-A-IMPORT permit 20
 427   match peer 2001:0DB8::C
 428   call A-IMPORT-FROM-C
 429 !
 430 route-map A-IMPORT-FROM-B permit 10
 431   match ipv6 address prefix-list COMMON-PREFIXES
 432   set metric 100
 433 route-map A-IMPORT-FROM-B permit 20
 434   match ipv6 address prefix-list PEER-B-PREFIXES
 435   set community 65001:11111
 436 !
 437 route-map A-IMPORT-FROM-C permit 10
 438   match ipv6 address prefix-list COMMON-PREFIXES
 439   set metric 200
 440 route-map A-IMPORT-FROM-C permit 20
 441   match ipv6 address prefix-list PEER-C-PREFIXES
 442   set community 65001:22222
 443 !
 444 route-map RSCLIENT-A-EXPORT permit 10
 445   match peer 2001:0DB8::B
 446   match ipv6 address prefix-list PEER-A-PREFIXES
 447 route-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
 456 If you compare the initial configuration of RA with the route server
 457 configuration above, you can see how easy it is to generate the Import and
 458 Export policies for RA from the In and Out route-maps of RA's original
 459 configuration.
 460
 461 When there was no route server, RA maintained two peerings, one with RB and
 462 another with RC. Each of this peerings had an In route-map configured. To
 463 build the Import route-map for client RA in the route server, simply add
 464 route-map entries following this scheme:
 465
 466 @example
 467 route-map <NAME> permit 10
 468     match peer <Peer Address>
 469     call <In Route-Map for this Peer>
 470 route-map <NAME> permit 20
 471     match peer <Another Peer Address>
 472     call <In Route-Map for this Peer>
 473 @end example
 474
 475 This is exactly the process that has been followed to generate the route-map
 476 RSCLIENT-A-IMPORT. The route-maps that are called inside it (A-IMPORT-FROM-B
 477 and A-IMPORT-FROM-C) are exactly the same than the In route-maps from the
 478 original configuration of RA (PEER-B-IN and PEER-C-IN), only the name is
 479 different.
 480
 481 The same could have been done to create the Export policy for RA (route-map
 482 RSCLIENT-A-EXPORT), but in this case the original Out route-maps where so
 483 simple that we decided not to use the @var{call WORD} commands, and we
 484 integrated all in a single route-map (RSCLIENT-A-EXPORT).
 485
 486 The Import and Export policies for RB and RC are not shown, but
 487 the 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
 492 The current version of the route server patch only allows to specify a
 493 route-map for import and export policies, while in a standard BGP speaker
 494 apart from route-maps there are other tools for performing input and output
 495 filtering (access-lists, community-lists, ...). But this does not represent
 496 any limitation, as all kinds of filters can be included in import/export
 497 route-maps. For example suppose that in the non-route-server scenario peer
 498 RA 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     ...
 506 route-map PEER-B-IN permit 10
 507   match ipv6 address prefix-list COMMON-PREFIXES
 508   set local-preference 100
 509 route-map PEER-B-IN permit 20
 510   match ipv6 address prefix-list PEER-B-PREFIXES
 511   set community 65001:11111
 512 @end example
 513
 514 It is posible to write a single route-map which is equivalent to
 515 the three filters (the community-list, the prefix-list and the
 516 route-map). That route-map can then be used inside the Import
 517 policy 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 ...
 524 route-map RSCLIENT-A-IMPORT permit 10
 525   match peer 2001:0DB8::B
 526   call A-IMPORT-FROM-B
 527 ...
 528 ...
 529 !
 530 route-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
 534 route-map A-IMPORT-FROM-B deny 2
 535 route-map A-IMPORT-FROM-B permit 10
 536   match ipv6 address prefix-list COMMON-PREFIXES
 537   set local-preference 100
 538 route-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
 546 The 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
 548 A-IMPORT-FROM-B (sequence number 1) matches if and only if both
 549 the prefix-list LIST-1 and the filter-list LIST-2 match. If that
 550 happens, due to the ``on-match goto 10'' statement the next
 551 route-map entry to be processed will be number 10, and as of that
 552 point route-map A-IMPORT-FROM-B is identical to PEER-B-IN. If
 553 the first entry does not match, `on-match goto 10'' will be
 554 ignored and the next processed entry will be number 2, which will
 555 deny the route.
 556
 557 Thus, the result is the same that with the three original filters,
 558 i.e., if either LIST-1 or LIST-2 rejects the route, it does not
 559 reach the route-map PEER-B-IN. In case both LIST-1 and LIST-2
 560 accept the route, it passes to PEER-B-IN, which can reject, accept
 561 or modify the route.