embedaddon/quagga/doc/routeserver.texi - view

File: [ELWIX - Embedded LightWeight unIX -] / embedaddon / quagga / doc / routeserver.texi
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Tue Feb 21 17:26:11 2012 UTC (12 years, 4 months ago) by misho
Branches: quagga, MAIN
CVS tags: v1_0_20160315, v0_99_22p0, v0_99_22, v0_99_21, v0_99_20_1, v0_99_20, HEAD

quagga

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.