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