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