doc/user/routeserver.rst

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