Annotation of embedaddon/quagga/doc/routeserver.texi, revision 1.1.1.1
1.1 misho 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.
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to routeserver.texi CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / quagga / doc