1 .. _configuring-frr-as-a-route-server:
3 Configuring FRR as a Route Server
4 =================================
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`).
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
18 .. _description-of-the-route-server-model:
20 Description of the Route Server model
21 -------------------------------------
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:
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
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.
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.
45 .. _fig-normal-processing:
47 .. figure:: ../figures/fig-normal-processing.png
48 :alt: Normal announcement processing
51 Announcement processing inside a 'normal' BGP speaker
53 .. _fig-topologies-full:
55 .. figure:: ../figures/fig_topologies_full.png
56 :alt: Full Mesh BGP Topology
61 .. _fig-topologies-rs:
63 .. figure:: ../figures/fig_topologies_rs.png
64 :alt: Route Server BGP Topology
67 Route server and clients
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.
74 .. _filter-delegation:
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.
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.
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:
95 .. _route-server-tasks:
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.
102 - Whenever it receives an announcement from a RS-client,
103 it must consider it for the Loc-RIBs of the other RS-clients.
105 - This means that for each of them the route server must pass the
106 announcement through the appropriate `Out` filter of the
109 - Then through the appropriate `In` filter of the potential receiver.
111 - Only if the announcement is accepted by both filters it will be passed
112 to the 'Best Path Selection' process.
114 - Finally, it might go into the Loc-RIB of the receiver.
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.
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
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.
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
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
142 - Those peers that are configured as RS-clients do not receive any announce
143 from the `Main` Loc-RIB.
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).
151 .. _fig-rs-processing:
152 .. figure:: ../figures/fig-rs-processing.png
154 :alt: Route Server Processing Model
156 Announcement processing model implemented by the Route Server
158 .. _commands-for-configuring-a-route-server:
160 Commands for configuring a Route Server
161 ---------------------------------------
163 Now we will describe the commands that have been added to frr
164 in order to support the route server features.
166 .. index:: neighbor PEER-GROUP route-server-client
167 .. clicmd:: neighbor PEER-GROUP route-server-client
169 .. index:: neighbor A.B.C.D route-server-client
170 .. clicmd:: neighbor A.B.C.D route-server-client
172 .. index:: neighbor X:X::X:X route-server-client
173 .. clicmd:: neighbor X:X::X:X route-server-client
175 This command configures the peer given by `peer`, `A.B.C.D` or `X:X::X:X` as
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.
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.
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
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).
196 .. index:: match peer A.B.C.D|X:X::X:X
197 .. clicmd:: match peer A.B.C.D|X:X::X:X
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.
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`.).
214 .. clicmd:: call WORD
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.
223 .. _example-of-route-server-configuration:
225 Example of Route Server Configuration
226 -------------------------------------
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.
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>`_.
237 .. _configuration-of-the-bgp-routers-without-route-server:
239 Configuration of the BGP routers without Route Server
240 -----------------------------------------------------
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:
251 #Configuration for router 'RA'
257 no bgp default ipv4-unicast
258 neighbor 2001:0DB8::B remote-as 65002
259 neighbor 2001:0DB8::C remote-as 65003
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
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
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
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
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
288 route-map PEER-B-IN permit 10
289 match ipv6 address prefix-list COMMON-PREFIXES
291 route-map PEER-B-IN permit 20
292 match ipv6 address prefix-list PEER-B-PREFIXES
293 set community 65001:11111
295 route-map PEER-C-IN permit 10
296 match ipv6 address prefix-list COMMON-PREFIXES
298 route-map PEER-C-IN permit 20
299 match ipv6 address prefix-list PEER-C-PREFIXES
300 set community 65001:22222
302 route-map PEER-B-OUT permit 10
303 match ipv6 address prefix-list PEER-A-PREFIXES
305 route-map PEER-C-OUT permit 10
306 match ipv6 address prefix-list PEER-A-PREFIXES
312 .. _configuration-of-the-bgp-routers-with-route-server:
314 Configuration of the BGP routers with Route Server
315 --------------------------------------------------
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:
324 # Configuration for router 'RA'
330 no bgp default ipv4-unicast
331 neighbor 2001:0DB8::FFFF remote-as 65000
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
339 neighbor 2001:0DB8::FFFF activate
340 neighbor 2001:0DB8::FFFF soft-reconfiguration inbound
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
351 .. _configuration-of-the-route-server-itself:
353 Configuration of the Route Server itself
354 ----------------------------------------
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
362 This is a fragment of the route server configuration (we only show
363 the policies for client RA):
367 # Configuration for Route Server ('RS')
372 bgp multiple-instance
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
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
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
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
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
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
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
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
412 route-map RSCLIENT-A-IMPORT permit 10
413 match peer 2001:0DB8::B
415 route-map RSCLIENT-A-IMPORT permit 20
416 match peer 2001:0DB8::C
419 route-map A-IMPORT-FROM-B permit 10
420 match ipv6 address prefix-list COMMON-PREFIXES
422 route-map A-IMPORT-FROM-B permit 20
423 match ipv6 address prefix-list PEER-B-PREFIXES
424 set community 65001:11111
426 route-map A-IMPORT-FROM-C permit 10
427 match ipv6 address prefix-list COMMON-PREFIXES
429 route-map A-IMPORT-FROM-C permit 20
430 match ipv6 address prefix-list PEER-C-PREFIXES
431 set community 65001:22222
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
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
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:
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>
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
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).
476 The Import and Export policies for RB and RC are not shown, but
477 the process would be identical.
479 Further considerations about Import and Export route-maps
480 ---------------------------------------------------------
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:
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
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
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
512 neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import
516 route-map RSCLIENT-A-IMPORT permit 10
517 match peer 2001:0DB8::B
522 route-map A-IMPORT-FROM-B permit 1
523 match ipv6 address prefix-list LIST-1
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
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.
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.