]>
Commit | Line | Data |
---|---|---|
fbaf39e9 | 1 | @c -*-texinfo-*- |
2 | @c @value{COPYRIGHT_STR} | |
438f5286 | 3 | @c See file frr.texi for copying conditions. |
fbaf39e9 | 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 | ||
438f5286 DS |
8 | @node Configuring Frr as a Route Server |
9 | @chapter Configuring Frr as a Route Server | |
fbaf39e9 | 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 | ||
438f5286 | 18 | We will first describe briefly the Route Server model implemented by Frr. |
fbaf39e9 | 19 | We will explain the commands that have been added for configuring that |
438f5286 | 20 | model. And finally we will show a full example of Frr configured as Route |
fbaf39e9 | 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 | ||
ab2416a0 PJ |
36 | @itemize @bullet |
37 | @item | |
38 | When an announcement is received from some peer, the `In' filters | |
fbaf39e9 | 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 | ||
ab2416a0 PJ |
43 | @item |
44 | The announcements that pass the `In' filters go into the | |
fbaf39e9 | 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 | ||
ab2416a0 PJ |
51 | @item |
52 | The routes which are inserted in the Loc-RIB are | |
fbaf39e9 | 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 | |
ab2416a0 | 63 | @image{fig-normal-processing,400pt,,Normal announcement processing} |
fbaf39e9 | 64 | @caption{Announcement processing inside a ``normal'' BGP speaker} |
65 | @end float | |
66 | ||
67 | @float Figure,fig:full-mesh | |
ab2416a0 | 68 | @image{fig_topologies_full,120pt,,Full Mesh BGP Topology} |
fbaf39e9 | 69 | @caption{Full Mesh} |
70 | @end float | |
71 | ||
72 | @float Figure,fig:route-server | |
ab2416a0 | 73 | @image{fig_topologies_rs,120pt,,Route Server BGP Topology} |
fbaf39e9 | 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 | ||
ab2416a0 PJ |
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. | |
fbaf39e9 | 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} | |
ab2416a0 PJ |
103 | @itemize @bullet |
104 | @item | |
105 | Maintain a separated Routing Information Base (Loc-RIB) | |
fbaf39e9 | 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 | ||
ab2416a0 PJ |
110 | @item |
111 | Whenever it receives an announcement from a RS-client, | |
fbaf39e9 | 112 | it must consider it for the Loc-RIBs of the other RS-clients. |
113 | ||
114 | @anchor{Route-server path filter process} | |
ab2416a0 | 115 | @itemize @bullet |
fbaf39e9 | 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 | |
fbaf39e9 | 132 | @end itemize |
fbaf39e9 | 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 | ||
438f5286 | 151 | The announcement processing model implemented by Frr is shown in |
fbaf39e9 | 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 | ||
ab2416a0 PJ |
156 | @itemize @bullet |
157 | @item | |
158 | Announcements coming from a normal BGP peer are also | |
fbaf39e9 | 159 | considered for the Loc-RIBs of all the RS-clients. But |
160 | logically they do not pass through any export policy. | |
161 | ||
ab2416a0 PJ |
162 | @item |
163 | Those peers that are configured as RS-clients do not | |
fbaf39e9 | 164 | receive any announce from the `Main' Loc-RIB. |
165 | ||
ab2416a0 PJ |
166 | @item |
167 | Apart from import and export policies, | |
fbaf39e9 | 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 | |
ab2416a0 | 176 | @image{fig-rs-processing,450pt,,Route Server Processing Model} |
fbaf39e9 | 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 | ||
438f5286 | 183 | Now we will describe the commands that have been added to frr |
fbaf39e9 | 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 | ||
438f5286 | 192 | Actually this command is not new, it already existed in standard Frr. It |
fbaf39e9 | 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 | ||
438f5286 | 238 | Finally we are going to show how to configure a Frr daemon to act as a |
fbaf39e9 | 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 | ||
f912cb4f | 264 | @exampleindent 0 |
fbaf39e9 | 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. |