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