paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 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 | |
Paul Jakma | ab2416a | 2006-04-03 21:24:27 +0000 | [diff] [blame] | 36 | @itemize @bullet |
| 37 | @item |
| 38 | When an announcement is received from some peer, the `In' filters |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 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 | |
Paul Jakma | ab2416a | 2006-04-03 21:24:27 +0000 | [diff] [blame] | 43 | @item |
| 44 | The announcements that pass the `In' filters go into the |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 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 | |
Paul Jakma | ab2416a | 2006-04-03 21:24:27 +0000 | [diff] [blame] | 51 | @item |
| 52 | The routes which are inserted in the Loc-RIB are |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 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 |
Paul Jakma | 974511e | 2017-03-08 22:01:37 +0000 | [diff] [blame^] | 63 | @center @image{fig-normal-processing,400pt,,Normal announcement processing} |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 64 | @caption{Announcement processing inside a ``normal'' BGP speaker} |
| 65 | @end float |
| 66 | |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 67 | Of course we want that the routing tables obtained in each of the routers |
| 68 | are the same when using the route server than when not. But as a consequence |
| 69 | of having a single BGP peering (against the route server), the BGP speakers |
| 70 | can no longer distinguish from/to which peer each announce comes/goes. |
| 71 | @anchor{filter-delegation}This means that the routers connected to the route |
| 72 | server are not able to apply by themselves the same input/output filters |
| 73 | as in the full mesh scenario, so they have to delegate those functions to |
| 74 | the route server. |
| 75 | |
Paul Jakma | ab2416a | 2006-04-03 21:24:27 +0000 | [diff] [blame] | 76 | Even more, the ``best path'' selection must be also performed inside |
| 77 | the route server on behalf of its clients. The reason is that if, after |
| 78 | applying the filters of the announcer and the (potential) receiver, the |
| 79 | route server decides to send to some client two or more different |
| 80 | announcements referred to the same destination, the client will only |
| 81 | retain the last one, considering it as an implicit withdrawal of the |
| 82 | previous announcements for the same destination. This is the expected |
| 83 | behavior of a BGP speaker as defined in @cite{RFC1771}, and even though |
| 84 | there are some proposals of mechanisms that permit multiple paths for |
| 85 | the same destination to be sent through a single BGP peering, none are |
| 86 | currently supported by most existing BGP implementations. |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 87 | |
| 88 | As a consequence a route server must maintain additional information and |
| 89 | perform additional tasks for a RS-client that those necessary for common BGP |
| 90 | peerings. Essentially a route server must: |
| 91 | |
| 92 | @anchor{Route Server tasks} |
Paul Jakma | ab2416a | 2006-04-03 21:24:27 +0000 | [diff] [blame] | 93 | @itemize @bullet |
| 94 | @item |
| 95 | Maintain a separated Routing Information Base (Loc-RIB) |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 96 | for each peer configured as RS-client, containing the routes |
| 97 | selected as a result of the ``Best Path Selection'' process |
| 98 | that is performed on behalf of that RS-client. |
| 99 | |
Paul Jakma | ab2416a | 2006-04-03 21:24:27 +0000 | [diff] [blame] | 100 | @item |
| 101 | Whenever it receives an announcement from a RS-client, |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 102 | it must consider it for the Loc-RIBs of the other RS-clients. |
| 103 | |
| 104 | @anchor{Route-server path filter process} |
Paul Jakma | ab2416a | 2006-04-03 21:24:27 +0000 | [diff] [blame] | 105 | @itemize @bullet |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 106 | @item |
| 107 | This means that for each of them the route server must pass the |
| 108 | announcement through the appropriate `Out' filter of the |
| 109 | announcer. |
| 110 | |
| 111 | @item |
| 112 | Then through the appropriate `In' filter of |
| 113 | the potential receiver. |
| 114 | |
| 115 | @item |
| 116 | Only if the announcement is accepted by both filters it will be passed |
| 117 | to the ``Best Path Selection'' process. |
| 118 | |
| 119 | @item |
| 120 | Finally, it might go into the Loc-RIB of the receiver. |
| 121 | @end itemize |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 122 | @end itemize |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 123 | |
| 124 | When we talk about the ``appropriate'' filter, both the announcer and the |
| 125 | receiver of the route must be taken into account. Suppose that the route |
| 126 | server receives an announcement from client A, and the route server is |
| 127 | considering it for the Loc-RIB of client B. The filters that should be |
| 128 | applied are the same that would be used in the full mesh scenario, i.e., |
| 129 | first the `Out' filter of router A for announcements going to router B, and |
| 130 | then the `In' filter of router B for announcements coming from router A. |
| 131 | |
| 132 | We call ``Export Policy'' of a RS-client to the set of `Out' filters that |
| 133 | the 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 |
| 135 | if there was no route server. |
| 136 | |
| 137 | It is also common to demand from a route server that it does not |
| 138 | modify some BGP attributes (next-hop, as-path and MED) that are usually |
| 139 | modified by standard BGP speakers before announcing a route. |
| 140 | |
| 141 | The 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) |
| 143 | with normal BGP peers (A). There are some details that worth additional |
| 144 | comments: |
| 145 | |
Paul Jakma | ab2416a | 2006-04-03 21:24:27 +0000 | [diff] [blame] | 146 | @itemize @bullet |
| 147 | @item |
| 148 | Announcements coming from a normal BGP peer are also |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 149 | considered for the Loc-RIBs of all the RS-clients. But |
| 150 | logically they do not pass through any export policy. |
| 151 | |
Paul Jakma | ab2416a | 2006-04-03 21:24:27 +0000 | [diff] [blame] | 152 | @item |
| 153 | Those peers that are configured as RS-clients do not |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 154 | receive any announce from the `Main' Loc-RIB. |
| 155 | |
Paul Jakma | ab2416a | 2006-04-03 21:24:27 +0000 | [diff] [blame] | 156 | @item |
| 157 | Apart from import and export policies, |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 158 | `In' and `Out' filters can also be set for RS-clients. `In' |
| 159 | filters might be useful when the route server has also normal |
| 160 | BGP peers. On the other hand, `Out' filters for RS-clients are |
| 161 | probably unnecessary, but we decided not to remove them as |
| 162 | they do not hurt anybody (they can always be left empty). |
| 163 | @end itemize |
| 164 | |
| 165 | @float Figure,fig:rs-processing |
Paul Jakma | 974511e | 2017-03-08 22:01:37 +0000 | [diff] [blame^] | 166 | @center @image{fig-rs-processing,430pt,,Route Server Processing Model} |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 167 | @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 | |
| 173 | Now we will describe the commands that have been added to quagga |
| 174 | in 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} {} |
| 179 | This 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 | |
| 182 | Actually this command is not new, it already existed in standard Quagga. It |
| 183 | enables the transparent mode for the specified peer. This means that some |
| 184 | BGP attributes (as-path, next-hop and MED) of the routes announced to that |
| 185 | peer are not modified. |
| 186 | |
| 187 | With the route server patch, this command, apart from setting the |
| 188 | transparent 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 |
| 190 | that moment, every announcement received by the route server will be also |
| 191 | considered 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@}} {} |
| 195 | This set of commands can be used to specify the route-map that |
| 196 | represents the Import or Export policy of a peer which is |
| 197 | configured 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@}} {} |
| 201 | This is a new @emph{match} statement for use in route-maps, enabling them to |
| 202 | describe import/export policies. As we said before, an import/export policy |
| 203 | represents a set of input/output filters of the RS-client. This statement |
| 204 | makes possible that a single route-map represents the full set of filters |
| 205 | that a BGP speaker would use for its different peers in a non-RS scenario. |
| 206 | |
| 207 | The @emph{match peer} statement has different semantics whether it is used |
| 208 | inside an import or an export route-map. In the first case the statement |
| 209 | matches if the address of the peer who sends the announce is the same that |
| 210 | the address specified by @{A.B.C.D|X:X::X:X@}. For export route-maps it |
| 211 | matches when @{A.B.C.D|X:X::X:X@} is the address of the RS-Client into whose |
| 212 | Loc-RIB the announce is going to be inserted (how the same export policy is |
| 213 | applied before different Loc-RIBs is shown in @ref{fig:rs-processing}.). |
| 214 | @end deffn |
| 215 | |
| 216 | @deffn {Route-map Command} {call @var{WORD}} {} |
| 217 | This command (also used inside a route-map) jumps into a different |
| 218 | route-map, whose name is specified by @var{WORD}. When the called |
| 219 | route-map finishes, depending on its result the original route-map |
| 220 | continues or not. Apart from being useful for making import/export |
| 221 | route-maps easier to write, this command can also be used inside |
| 222 | any 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 | |
| 228 | Finally we are going to show how to configure a Quagga daemon to act as a |
| 229 | Route Server. For this purpose we are going to present a scenario without |
| 230 | route server, and then we will show how to use the configurations of the BGP |
| 231 | routers to generate the configuration of the route server. |
| 232 | |
| 233 | All the configuration files shown in this section have been taken |
| 234 | from 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 | |
| 247 | We will suppose that our initial scenario is an exchange point with three |
| 248 | BGP capable routers, named RA, RB and RC. Each of the BGP speakers generates |
| 249 | some routes (with the @var{network} command), and establishes BGP peerings |
| 250 | against the other two routers. These peerings have In and Out route-maps |
| 251 | configured, named like ``PEER-X-IN'' or ``PEER-X-OUT''. For example the |
| 252 | configuration file for router RA could be the following: |
| 253 | |
Paul Jakma | f912cb4 | 2006-07-27 23:30:16 +0000 | [diff] [blame] | 254 | @exampleindent 0 |
paul | fbaf39e | 2004-11-15 00:45:44 +0000 | [diff] [blame] | 255 | @example |
| 256 | #Configuration for router 'RA' |
| 257 | ! |
| 258 | hostname RA |
| 259 | password **** |
| 260 | ! |
| 261 | router 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 | ! |
| 283 | ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64 |
| 284 | ipv6 prefix-list COMMON-PREFIXES seq 10 deny any |
| 285 | ! |
| 286 | ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64 |
| 287 | ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any |
| 288 | ! |
| 289 | ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64 |
| 290 | ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any |
| 291 | ! |
| 292 | ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64 |
| 293 | ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any |
| 294 | ! |
| 295 | route-map PEER-B-IN permit 10 |
| 296 | match ipv6 address prefix-list COMMON-PREFIXES |
| 297 | set metric 100 |
| 298 | route-map PEER-B-IN permit 20 |
| 299 | match ipv6 address prefix-list PEER-B-PREFIXES |
| 300 | set community 65001:11111 |
| 301 | ! |
| 302 | route-map PEER-C-IN permit 10 |
| 303 | match ipv6 address prefix-list COMMON-PREFIXES |
| 304 | set metric 200 |
| 305 | route-map PEER-C-IN permit 20 |
| 306 | match ipv6 address prefix-list PEER-C-PREFIXES |
| 307 | set community 65001:22222 |
| 308 | ! |
| 309 | route-map PEER-B-OUT permit 10 |
| 310 | match ipv6 address prefix-list PEER-A-PREFIXES |
| 311 | ! |
| 312 | route-map PEER-C-OUT permit 10 |
| 313 | match ipv6 address prefix-list PEER-A-PREFIXES |
| 314 | ! |
| 315 | line 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 | |
| 322 | To convert the initial scenario into one with route server, first we must |
| 323 | modify the configuration of routers RA, RB and RC. Now they must not peer |
| 324 | between them, but only with the route server. For example, RA's |
| 325 | configuration would turn into: |
| 326 | |
| 327 | @example |
| 328 | # Configuration for router 'RA' |
| 329 | ! |
| 330 | hostname RA |
| 331 | password **** |
| 332 | ! |
| 333 | router 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 | ! |
| 347 | line vty |
| 348 | ! |
| 349 | @end example |
| 350 | |
| 351 | Which is logically much simpler than its initial configuration, as it now |
| 352 | maintains only one BGP peering and all the filters (route-maps) have |
| 353 | disappeared. |
| 354 | |
| 355 | @node Configuration of the Route Server itself |
| 356 | @subsection Configuration of the Route Server itself |
| 357 | |
| 358 | As 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 |
| 360 | route filtering. To achieve that, the In and Out filters from the RA, RB and |
| 361 | RC configurations must be converted into Import and Export policies in the |
| 362 | route server. |
| 363 | |
| 364 | This is a fragment of the route server configuration (we only show |
| 365 | the policies for client RA): |
| 366 | |
| 367 | @example |
| 368 | # Configuration for Route Server ('RS') |
| 369 | ! |
| 370 | hostname RS |
| 371 | password ix |
| 372 | ! |
| 373 | bgp multiple-instance |
| 374 | ! |
| 375 | router 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 | ! |
| 401 | ipv6 prefix-list COMMON-PREFIXES seq 5 permit 2001:0DB8:0000::/48 ge 64 le 64 |
| 402 | ipv6 prefix-list COMMON-PREFIXES seq 10 deny any |
| 403 | ! |
| 404 | ipv6 prefix-list PEER-A-PREFIXES seq 5 permit 2001:0DB8:AAAA::/48 ge 64 le 64 |
| 405 | ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any |
| 406 | ! |
| 407 | ipv6 prefix-list PEER-B-PREFIXES seq 5 permit 2001:0DB8:BBBB::/48 ge 64 le 64 |
| 408 | ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any |
| 409 | ! |
| 410 | ipv6 prefix-list PEER-C-PREFIXES seq 5 permit 2001:0DB8:CCCC::/48 ge 64 le 64 |
| 411 | ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any |
| 412 | ! |
| 413 | route-map RSCLIENT-A-IMPORT permit 10 |
| 414 | match peer 2001:0DB8::B |
| 415 | call A-IMPORT-FROM-B |
| 416 | route-map RSCLIENT-A-IMPORT permit 20 |
| 417 | match peer 2001:0DB8::C |
| 418 | call A-IMPORT-FROM-C |
| 419 | ! |
| 420 | route-map A-IMPORT-FROM-B permit 10 |
| 421 | match ipv6 address prefix-list COMMON-PREFIXES |
| 422 | set metric 100 |
| 423 | route-map A-IMPORT-FROM-B permit 20 |
| 424 | match ipv6 address prefix-list PEER-B-PREFIXES |
| 425 | set community 65001:11111 |
| 426 | ! |
| 427 | route-map A-IMPORT-FROM-C permit 10 |
| 428 | match ipv6 address prefix-list COMMON-PREFIXES |
| 429 | set metric 200 |
| 430 | route-map A-IMPORT-FROM-C permit 20 |
| 431 | match ipv6 address prefix-list PEER-C-PREFIXES |
| 432 | set community 65001:22222 |
| 433 | ! |
| 434 | route-map RSCLIENT-A-EXPORT permit 10 |
| 435 | match peer 2001:0DB8::B |
| 436 | match ipv6 address prefix-list PEER-A-PREFIXES |
| 437 | route-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 | |
| 446 | If you compare the initial configuration of RA with the route server |
| 447 | configuration above, you can see how easy it is to generate the Import and |
| 448 | Export policies for RA from the In and Out route-maps of RA's original |
| 449 | configuration. |
| 450 | |
| 451 | When there was no route server, RA maintained two peerings, one with RB and |
| 452 | another with RC. Each of this peerings had an In route-map configured. To |
| 453 | build the Import route-map for client RA in the route server, simply add |
| 454 | route-map entries following this scheme: |
| 455 | |
| 456 | @example |
| 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 | @end example |
| 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 @var{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 | @node Further considerations about Import and Export route-maps |
| 480 | @subsection Further considerations about Import and Export route-maps |
| 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 | |
| 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 | ... |
| 496 | route-map PEER-B-IN permit 10 |
| 497 | match ipv6 address prefix-list COMMON-PREFIXES |
| 498 | set local-preference 100 |
| 499 | route-map PEER-B-IN permit 20 |
| 500 | match ipv6 address prefix-list PEER-B-PREFIXES |
| 501 | set community 65001:11111 |
| 502 | @end example |
| 503 | |
| 504 | It is posible to write a single route-map which is equivalent to |
| 505 | the three filters (the community-list, the prefix-list and the |
| 506 | route-map). That route-map can then be used inside the Import |
| 507 | policy 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 | ... |
| 514 | route-map RSCLIENT-A-IMPORT permit 10 |
| 515 | match peer 2001:0DB8::B |
| 516 | call A-IMPORT-FROM-B |
| 517 | ... |
| 518 | ... |
| 519 | ! |
| 520 | route-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 |
| 524 | route-map A-IMPORT-FROM-B deny 2 |
| 525 | route-map A-IMPORT-FROM-B permit 10 |
| 526 | match ipv6 address prefix-list COMMON-PREFIXES |
| 527 | set local-preference 100 |
| 528 | route-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 | |
| 536 | The 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 |
| 538 | A-IMPORT-FROM-B (sequence number 1) matches if and only if both |
| 539 | the prefix-list LIST-1 and the filter-list LIST-2 match. If that |
| 540 | happens, due to the ``on-match goto 10'' statement the next |
| 541 | route-map entry to be processed will be number 10, and as of that |
| 542 | point route-map A-IMPORT-FROM-B is identical to PEER-B-IN. If |
| 543 | the first entry does not match, `on-match goto 10'' will be |
| 544 | ignored and the next processed entry will be number 2, which will |
| 545 | deny the route. |
| 546 | |
| 547 | Thus, the result is the same that with the three original filters, |
| 548 | i.e., if either LIST-1 or LIST-2 rejects the route, it does not |
| 549 | reach the route-map PEER-B-IN. In case both LIST-1 and LIST-2 |
| 550 | accept the route, it passes to PEER-B-IN, which can reject, accept |
| 551 | or modify the route. |