Annotation of embedaddon/quagga/doc/bgpd.texi, revision 1.1.1.3
1.1 misho 1: @c -*-texinfo-*-
2: @c This is part of the Quagga Manual.
3: @c @value{COPYRIGHT_STR}
1.1.1.3 ! misho 4: @c Portions:
! 5: @c Copyright @copyright{} 2015 Hewlett Packard Enterprise Development LP
1.1 misho 6: @c See file quagga.texi for copying conditions.
7: @node BGP
8: @chapter BGP
9:
10: @acronym{BGP} stands for a Border Gateway Protocol. The lastest BGP version
11: is 4. It is referred as BGP-4. BGP-4 is one of the Exterior Gateway
12: Protocols and de-fact standard of Inter Domain routing protocol.
13: BGP-4 is described in @cite{RFC1771, A Border Gateway Protocol
14: 4 (BGP-4)}.
15:
16: Many extensions have been added to @cite{RFC1771}. @cite{RFC2858,
17: Multiprotocol Extensions for BGP-4} provides multiprotocol support to
18: BGP-4.
19:
20: @menu
21: * Starting BGP::
22: * BGP router::
1.1.1.3 ! misho 23: * BGP MED::
1.1 misho 24: * BGP network::
25: * BGP Peer::
26: * BGP Peer Group::
27: * BGP Address Family::
28: * Autonomous System::
29: * BGP Communities Attribute::
30: * BGP Extended Communities Attribute::
31: * Displaying BGP routes::
32: * Capability Negotiation::
33: * Route Reflector::
34: * Route Server::
35: * How to set up a 6-Bone connection::
36: * Dump BGP packets and table::
37: * BGP Configuration Examples::
38: @end menu
39:
40: @node Starting BGP
41: @section Starting BGP
42:
43: Default configuration file of @command{bgpd} is @file{bgpd.conf}.
44: @command{bgpd} searches the current directory first then
45: @value{INSTALL_PREFIX_ETC}/bgpd.conf. All of bgpd's command must be
46: configured in @file{bgpd.conf}.
47:
48: @command{bgpd} specific invocation options are described below. Common
49: options may also be specified (@pxref{Common Invocation Options}).
50:
51: @table @samp
52: @item -p @var{PORT}
53: @itemx --bgp_port=@var{PORT}
54: Set the bgp protocol's port number.
55:
56: @item -r
57: @itemx --retain
58: When program terminates, retain BGP routes added by zebra.
1.1.1.3 ! misho 59:
! 60: @item -l
! 61: @itemx --listenon
! 62: Specify a specific IP address for bgpd to listen on, rather than its
! 63: default of INADDR_ANY / IN6ADDR_ANY. This can be useful to constrain bgpd
! 64: to an internal address, or to run multiple bgpd processes on one host.
! 65:
1.1 misho 66: @end table
67:
68: @node BGP router
69: @section BGP router
70:
71: First of all you must configure BGP router with @command{router bgp}
72: command. To configure BGP router, you need AS number. AS number is an
73: identification of autonomous system. BGP protocol uses the AS number
74: for detecting whether the BGP connection is internal one or external one.
75:
76: @deffn Command {router bgp @var{asn}} {}
77: Enable a BGP protocol process with the specified @var{asn}. After
78: this statement you can input any @code{BGP Commands}. You can not
79: create different BGP process under different @var{asn} without
80: specifying @code{multiple-instance} (@pxref{Multiple instance}).
81: @end deffn
82:
83: @deffn Command {no router bgp @var{asn}} {}
84: Destroy a BGP protocol process with the specified @var{asn}.
85: @end deffn
86:
87: @deffn {BGP} {bgp router-id @var{A.B.C.D}} {}
88: This command specifies the router-ID. If @command{bgpd} connects to @command{zebra} it gets
89: interface and address information. In that case default router ID value
90: is selected as the largest IP Address of the interfaces. When
91: @code{router zebra} is not enabled @command{bgpd} can't get interface information
92: so @code{router-id} is set to 0.0.0.0. So please set router-id by hand.
93: @end deffn
94:
95: @menu
96: * BGP distance::
97: * BGP decision process::
98: * BGP route flap dampening::
99: @end menu
100:
101: @node BGP distance
102: @subsection BGP distance
103:
104: @deffn {BGP} {distance bgp <1-255> <1-255> <1-255>} {}
105: This command change distance value of BGP. Each argument is distance
106: value for external routes, internal routes and local routes.
107: @end deffn
108:
109: @deffn {BGP} {distance <1-255> @var{A.B.C.D/M}} {}
110: @deffnx {BGP} {distance <1-255> @var{A.B.C.D/M} @var{word}} {}
111: This command set distance value to
112: @end deffn
113:
114: @node BGP decision process
115: @subsection BGP decision process
116:
1.1.1.3 ! misho 117: The decision process Quagga BGP uses to select routes is as follows:
! 118:
1.1 misho 119: @table @asis
120: @item 1. Weight check
1.1.1.3 ! misho 121: prefer higher local weight routes to lower routes.
1.1 misho 122:
1.1.1.3 ! misho 123: @item 2. Local preference check
! 124: prefer higher local preference routes to lower.
1.1 misho 125:
1.1.1.3 ! misho 126: @item 3. Local route check
! 127: Prefer local routes (statics, aggregates, redistributed) to received routes.
1.1 misho 128:
1.1.1.3 ! misho 129: @item 4. AS path length check
! 130: Prefer shortest hop-count AS_PATHs.
1.1 misho 131:
1.1.1.3 ! misho 132: @item 5. Origin check
! 133: Prefer the lowest origin type route. That is, prefer IGP origin routes to
! 134: EGP, to Incomplete routes.
! 135:
! 136: @item 6. MED check
! 137: Where routes with a MED were received from the same AS,
! 138: prefer the route with the lowest MED. @xref{BGP MED}.
! 139:
! 140: @item 7. External check
! 141: Prefer the route received from an external, eBGP peer
! 142: over routes received from other types of peers.
! 143:
! 144: @item 8. IGP cost check
! 145: Prefer the route with the lower IGP cost.
! 146:
! 147: @item 9. Multi-path check
! 148: If multi-pathing is enabled, then check whether
! 149: the routes not yet distinguished in preference may be considered equal. If
! 150: @ref{bgp bestpath as-path multipath-relax} is set, all such routes are
! 151: considered equal, otherwise routes received via iBGP with identical AS_PATHs
! 152: or routes received from eBGP neighbours in the same AS are considered equal.
! 153:
! 154: @item 10 Already-selected external check
! 155:
! 156: Where both routes were received from eBGP peers, then prefer the route which
! 157: is already selected. Note that this check is not applied if @ref{bgp
! 158: bestpath compare-routerid} is configured. This check can prevent some cases
! 159: of oscillation.
! 160:
! 161: @item 11. Router-ID check
! 162: Prefer the route with the lowest @w{router-ID}. If the
! 163: route has an @w{ORIGINATOR_ID} attribute, through iBGP reflection, then that
! 164: router ID is used, otherwise the @w{router-ID} of the peer the route was
! 165: received from is used.
! 166:
! 167: @item 12. Cluster-List length check
! 168: The route with the shortest cluster-list
! 169: length is used. The cluster-list reflects the iBGP reflection path the
! 170: route has taken.
! 171:
! 172: @item 13. Peer address
! 173: Prefer the route received from the peer with the higher
! 174: transport layer address, as a last-resort tie-breaker.
1.1 misho 175:
176: @end table
177:
178: @deffn {BGP} {bgp bestpath as-path confed} {}
179: This command specifies that the length of confederation path sets and
180: sequences should should be taken into account during the BGP best path
181: decision process.
182: @end deffn
183:
1.1.1.3 ! misho 184: @deffn {BGP} {bgp bestpath as-path multipath-relax} {}
! 185: @anchor{bgp bestpath as-path multipath-relax}
! 186: This command specifies that BGP decision process should consider paths
! 187: of equal AS_PATH length candidates for multipath computation. Without
! 188: the knob, the entire AS_PATH must match for multipath computation.
! 189: @end deffn
! 190:
! 191: @deffn {BGP} {bgp bestpath compare-routerid} {}
! 192: @anchor{bgp bestpath compare-routerid}
! 193:
! 194: Ensure that when comparing routes where both are equal on most metrics,
! 195: including local-pref, AS_PATH length, IGP cost, MED, that the tie is broken
! 196: based on router-ID.
! 197:
! 198: If this option is enabled, then the already-selected check, where
! 199: already selected eBGP routes are preferred, is skipped.
! 200:
! 201: If a route has an @w{ORIGINATOR_ID} attribute because it has been reflected,
! 202: that @w{ORIGINATOR_ID} will be used. Otherwise, the router-ID of the peer the
! 203: route was received from will be used.
! 204:
! 205: The advantage of this is that the route-selection (at this point) will be
! 206: more deterministic. The disadvantage is that a few or even one lowest-ID
! 207: router may attract all trafic to otherwise-equal paths because of this
! 208: check. It may increase the possibility of MED or IGP oscillation, unless
! 209: other measures were taken to avoid these. The exact behaviour will be
! 210: sensitive to the iBGP and reflection topology.
! 211:
! 212: @end deffn
! 213:
! 214:
1.1 misho 215: @node BGP route flap dampening
216: @subsection BGP route flap dampening
217:
218: @deffn {BGP} {bgp dampening @var{<1-45>} @var{<1-20000>} @var{<1-20000>} @var{<1-255>}} {}
219: This command enables BGP route-flap dampening and specifies dampening parameters.
220:
221: @table @asis
222: @item @asis{half-life}
223: Half-life time for the penalty
224: @item @asis{reuse-threshold}
225: Value to start reusing a route
226: @item @asis{suppress-threshold}
227: Value to start suppressing a route
228: @item @asis{max-suppress}
229: Maximum duration to suppress a stable route
230: @end table
231:
232: The route-flap damping algorithm is compatible with @cite{RFC2439}. The use of this command
233: is not recommended nowadays, see @uref{http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378}.
234: @end deffn
235:
1.1.1.3 ! misho 236: @node BGP MED
! 237: @section BGP MED
! 238:
! 239: The BGP MED (Multi_Exit_Discriminator) attribute has properties which can
! 240: cause subtle convergence problems in BGP. These properties and problems
! 241: have proven to be hard to understand, at least historically, and may still
! 242: not be widely understood. The following attempts to collect together and
! 243: present what is known about MED, to help operators and Quagga users in
! 244: designing and configuring their networks.
! 245:
! 246: The BGP @acronym{MED, Multi_Exit_Discriminator} attribute is intended to
! 247: allow one AS to indicate its preferences for its ingress points to another
! 248: AS. The MED attribute will not be propagated on to another AS by the
! 249: receiving AS - it is `non-transitive' in the BGP sense.
! 250:
! 251: E.g., if AS X and AS Y have 2 different BGP peering points, then AS X
! 252: might set a MED of 100 on routes advertised at one and a MED of 200 at the
! 253: other. When AS Y selects between otherwise equal routes to or via
! 254: AS X, AS Y should prefer to take the path via the lower MED peering of 100 with
! 255: AS X. Setting the MED allows an AS to influence the routing taken to it
! 256: within another, neighbouring AS.
! 257:
! 258: In this use of MED it is not really meaningful to compare the MED value on
! 259: routes where the next AS on the paths differs. E.g., if AS Y also had a
! 260: route for some destination via AS Z in addition to the routes from AS X, and
! 261: AS Z had also set a MED, it wouldn't make sense for AS Y to compare AS Z's
! 262: MED values to those of AS X. The MED values have been set by different
! 263: administrators, with different frames of reference.
! 264:
! 265: The default behaviour of BGP therefore is to not compare MED values across
! 266: routes received from different neighbouring ASes. In Quagga this is done by
! 267: comparing the neighbouring, left-most AS in the received AS_PATHs of the
! 268: routes and only comparing MED if those are the same.
! 269:
! 270: @c TeXInfo uses the old, non-UTF-8 capable, pdftex, and so
! 271: @c doesn't render TeX the unicode precedes character correctly in PDF, etc.
! 272: @c Using a TeX code on the other hand doesn't work for non-TeX outputs
! 273: @c (plaintext, e.g.). So, use an output-conditional macro.
! 274:
! 275: @iftex
! 276: @macro mprec{}
! 277: @math{\\prec}
! 278: @end macro
! 279: @end iftex
! 280:
! 281: @ifnottex
! 282: @macro mprec{}
! 283: @math{≺}
! 284: @end macro
! 285: @end ifnottex
! 286:
! 287: Unfortunately, this behaviour of MED, of sometimes being compared across
! 288: routes and sometimes not, depending on the properties of those other routes,
! 289: means MED can cause the order of preference over all the routes to be
! 290: undefined. That is, given routes A, B, and C, if A is preferred to B, and B
! 291: is preferred to C, then a well-defined order should mean the preference is
! 292: transitive (in the sense of orders @footnote{For some set of objects to have
! 293: an order, there @emph{must} be some binary ordering relation that is defined
! 294: for @emph{every} combination of those objects, and that relation @emph{must}
! 295: be transitive. I.e.@:, if the relation operator is @mprec{}, and if
! 296: a @mprec{} b and b @mprec{} c then that relation must carry over
! 297: and it @emph{must} be that a @mprec{} c for the objects to have an
! 298: order. The ordering relation may allow for equality, i.e.
! 299: a @mprec{} b and b @mprec{} a may both be true amd imply that
! 300: a and b are equal in the order and not distinguished by it, in
! 301: which case the set has a partial order. Otherwise, if there is an order,
! 302: all the objects have a distinct place in the order and the set has a total
! 303: order.}) and that A would be preferred to C.
! 304:
! 305: However, when MED is involved this need not be the case. With MED it is
! 306: possible that C is actually preferred over A. So A is preferred to B, B is
! 307: preferred to C, but C is preferred to A. This can be true even where BGP
! 308: defines a deterministic ``most preferred'' route out of the full set of
! 309: A,B,C. With MED, for any given set of routes there may be a
! 310: deterministically preferred route, but there need not be any way to arrange
! 311: them into any order of preference. With unmodified MED, the order of
! 312: preference of routes literally becomes undefined.
! 313:
! 314: That MED can induce non-transitive preferences over routes can cause issues.
! 315: Firstly, it may be perceived to cause routing table churn locally at
! 316: speakers; secondly, and more seriously, it may cause routing instability in
! 317: iBGP topologies, where sets of speakers continually oscillate between
! 318: different paths.
! 319:
! 320: The first issue arises from how speakers often implement routing decisions.
! 321: Though BGP defines a selection process that will deterministically select
! 322: the same route as best at any given speaker, even with MED, that process
! 323: requires evaluating all routes together. For performance and ease of
! 324: implementation reasons, many implementations evaluate route preferences in a
! 325: pair-wise fashion instead. Given there is no well-defined order when MED is
! 326: involved, the best route that will be chosen becomes subject to
! 327: implementation details, such as the order the routes are stored in. That
! 328: may be (locally) non-deterministic, e.g.@: it may be the order the routes
! 329: were received in.
! 330:
! 331: This indeterminism may be considered undesirable, though it need not cause
! 332: problems. It may mean additional routing churn is perceived, as sometimes
! 333: more updates may be produced than at other times in reaction to some event .
! 334:
! 335: This first issue can be fixed with a more deterministic route selection that
! 336: ensures routes are ordered by the neighbouring AS during selection.
! 337: @xref{bgp deterministic-med}. This may reduce the number of updates as
! 338: routes are received, and may in some cases reduce routing churn. Though, it
! 339: could equally deterministically produce the largest possible set of updates
! 340: in response to the most common sequence of received updates.
! 341:
! 342: A deterministic order of evaluation tends to imply an additional overhead of
! 343: sorting over any set of n routes to a destination. The implementation of
! 344: deterministic MED in Quagga scales significantly worse than most sorting
! 345: algorithms at present, with the number of paths to a given destination.
! 346: That number is often low enough to not cause any issues, but where there are
! 347: many paths, the deterministic comparison may quickly become increasingly
! 348: expensive in terms of CPU.
! 349:
! 350: Deterministic local evaluation can @emph{not} fix the second, more major,
! 351: issue of MED however. Which is that the non-transitive preference of routes
! 352: MED can cause may lead to routing instability or oscillation across multiple
! 353: speakers in iBGP topologies. This can occur with full-mesh iBGP, but is
! 354: particularly problematic in non-full-mesh iBGP topologies that further
! 355: reduce the routing information known to each speaker. This has primarily
! 356: been documented with iBGP route-reflection topologies. However, any
! 357: route-hiding technologies potentially could also exacerbate oscillation with
! 358: MED.
! 359:
! 360: This second issue occurs where speakers each have only a subset of routes,
! 361: and there are cycles in the preferences between different combinations of
! 362: routes - as the undefined order of preference of MED allows - and the routes
! 363: are distributed in a way that causes the BGP speakers to 'chase' those
! 364: cycles. This can occur even if all speakers use a deterministic order of
! 365: evaluation in route selection.
! 366:
! 367: E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X, and
! 368: from speaker 3 in AS Y; while speaker 5 in AS A might receive that route
! 369: from speaker 1 in AS Y. AS Y might set a MED of 200 at speaker 1, and 100
! 370: at speaker 3. I.e, using ASN:ID:MED to label the speakers:
! 371:
! 372: @example
! 373:
! 374: /---------------\
! 375: X:2------|--A:4-------A:5--|-Y:1:200
! 376: Y:3:100--|-/ |
! 377: \---------------/
! 378:
! 379: @end example
! 380:
! 381: Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs), then
! 382: based on the RFC4271 decision process speaker 4 will choose X:2 over
! 383: Y:3:100, based on the lower ID of 2. Speaker 4 advertises X:2 to speaker 5.
! 384: Speaker 5 will continue to prefer Y:1:200 based on the ID, and advertise
! 385: this to speaker 4. Speaker 4 will now have the full set of routes, and the
! 386: Y:1:200 it receives from 5 will beat X:2, but when speaker 4 compares
! 387: Y:1:200 to Y:3:100 the MED check now becomes active as the ASes match, and
! 388: now Y:3:100 is preferred. Speaker 4 therefore now advertises Y:3:100 to 5,
! 389: which will also agrees that Y:3:100 is preferred to Y:1:200, and so
! 390: withdraws the latter route from 4. Speaker 4 now has only X:2 and Y:3:100,
! 391: and X:2 beats Y:3:100, and so speaker 4 implicitly updates its route to
! 392: speaker 5 to X:2. Speaker 5 sees that Y:1:200 beats X:2 based on the ID,
! 393: and advertises Y:1:200 to speaker 4, and the cycle continues.
! 394:
! 395: The root cause is the lack of a clear order of preference caused by how MED
! 396: sometimes is and sometimes is not compared, leading to this cycle in the
! 397: preferences between the routes:
! 398:
! 399: @example
! 400:
! 401: /---> X:2 ---beats---> Y:3:100 --\
! 402: | |
! 403: | |
! 404: \---beats--- Y:1:200 <---beats---/
! 405:
! 406: @end example
! 407:
! 408: This particular type of oscillation in full-mesh iBGP topologies can be
! 409: avoided by speakers preferring already selected, external routes rather than
! 410: choosing to update to new a route based on a post-MED metric (e.g.
! 411: router-ID), at the cost of a non-deterministic selection process. Quagga
! 412: implements this, as do many other implementations, so long as it is not
! 413: overridden by setting @ref{bgp bestpath compare-routerid}, and see also
! 414: @ref{BGP decision process}, .
! 415:
! 416: However, more complex and insidious cycles of oscillation are possible with
! 417: iBGP route-reflection, which are not so easily avoided. These have been
! 418: documented in various places. See, e.g., @cite{McPherson, D. and Gill, V.
! 419: and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation
! 420: Condition", IETF RFC3345}, and @cite{Flavel, A. and M. Roughan, "Stable
! 421: and flexible iBGP", ACM SIGCOMM 2009}, and @cite{Griffin, T. and G. Wilfong,
! 422: "On the correctness of IBGP configuration", ACM SIGCOMM 2002} for concrete
! 423: examples and further references.
! 424:
! 425: There is as of this writing @emph{no} known way to use MED for its original
! 426: purpose; @emph{and} reduce routing information in iBGP topologies;
! 427: @emph{and} be sure to avoid the instability problems of MED due the
! 428: non-transitive routing preferences it can induce; in general on arbitrary
! 429: networks.
! 430:
! 431: There may be iBGP topology specific ways to reduce the instability risks,
! 432: even while using MED, e.g.@: by constraining the reflection topology and by
! 433: tuning IGP costs between route-reflector clusters, see RFC3345 for details.
! 434: In the near future, the Add-Path extension to BGP may also solve MED
! 435: oscillation while still allowing MED to be used as intended, by distributing
! 436: "best-paths per neighbour AS". This would be at the cost of distributing at
! 437: least as many routes to all speakers as a full-mesh iBGP would, if not more,
! 438: while also imposing similar CPU overheads as the "Deterministic MED" feature
! 439: at each Add-Path reflector.
! 440:
! 441: More generally, the instability problems that MED can introduce on more
! 442: complex, non-full-mesh, iBGP topologies may be avoided either by:
! 443:
! 444: @itemize
! 445:
! 446: @item
! 447: Setting @ref{bgp always-compare-med}, however this allows MED to be compared
! 448: across values set by different neighbour ASes, which may not produce
! 449: coherent desirable results, of itself.
! 450:
! 451: @item
! 452: Effectively ignoring MED by setting MED to the same value (e.g.@: 0) using
! 453: @ref{routemap set metric} on all received routes, in combination with
! 454: setting @ref{bgp always-compare-med} on all speakers. This is the simplest
! 455: and most performant way to avoid MED oscillation issues, where an AS is happy
! 456: not to allow neighbours to inject this problematic metric.
! 457:
! 458: @end itemize
! 459:
! 460: As MED is evaluated after the AS_PATH length check, another possible use for
! 461: MED is for intra-AS steering of routes with equal AS_PATH length, as an
! 462: extension of the last case above. As MED is evaluated before IGP metric,
! 463: this can allow cold-potato routing to be implemented to send traffic to
! 464: preferred hand-offs with neighbours, rather than the closest hand-off
! 465: according to the IGP metric.
! 466:
! 467: Note that even if action is taken to address the MED non-transitivity
! 468: issues, other oscillations may still be possible. E.g., on IGP cost if
! 469: iBGP and IGP topologies are at cross-purposes with each other - see the
! 470: Flavel and Roughan paper above for an example. Hence the guideline that the
! 471: iBGP topology should follow the IGP topology.
! 472:
! 473: @deffn {BGP} {bgp deterministic-med} {}
! 474: @anchor{bgp deterministic-med}
! 475:
! 476: Carry out route-selection in way that produces deterministic answers
! 477: locally, even in the face of MED and the lack of a well-defined order of
! 478: preference it can induce on routes. Without this option the preferred route
! 479: with MED may be determined largely by the order that routes were received
! 480: in.
! 481:
! 482: Setting this option will have a performance cost that may be noticeable when
! 483: there are many routes for each destination. Currently in Quagga it is
! 484: implemented in a way that scales poorly as the number of routes per
! 485: destination increases.
! 486:
! 487: The default is that this option is not set.
! 488: @end deffn
! 489:
! 490: Note that there are other sources of indeterminism in the route selection
! 491: process, specifically, the preference for older and already selected routes
! 492: from eBGP peers, @xref{BGP decision process}.
! 493:
! 494: @deffn {BGP} {bgp always-compare-med} {}
! 495: @anchor{bgp always-compare-med}
! 496:
! 497: Always compare the MED on routes, even when they were received from
! 498: different neighbouring ASes. Setting this option makes the order of
! 499: preference of routes more defined, and should eliminate MED induced
! 500: oscillations.
! 501:
! 502: If using this option, it may also be desirable to use @ref{routemap set
! 503: metric} to set MED to 0 on routes received from external neighbours.
! 504:
! 505: This option can be used, together with @ref{routemap set metric} to use MED
! 506: as an intra-AS metric to steer equal-length AS_PATH routes to, e.g., desired
! 507: exit points.
! 508: @end deffn
! 509:
! 510:
! 511:
1.1 misho 512: @node BGP network
513: @section BGP network
514:
515: @menu
516: * BGP route::
517: * Route Aggregation::
518: * Redistribute to BGP::
519: @end menu
520:
521: @node BGP route
522: @subsection BGP route
523:
524: @deffn {BGP} {network @var{A.B.C.D/M}} {}
525: This command adds the announcement network.
526: @example
527: @group
528: router bgp 1
529: network 10.0.0.0/8
530: @end group
531: @end example
532: This configuration example says that network 10.0.0.0/8 will be
533: announced to all neighbors. Some vendors' routers don't advertise
534: routes if they aren't present in their IGP routing tables; @code{bgpd}
535: doesn't care about IGP routes when announcing its routes.
536: @end deffn
537:
538: @deffn {BGP} {no network @var{A.B.C.D/M}} {}
539: @end deffn
540:
541: @node Route Aggregation
542: @subsection Route Aggregation
543:
544: @deffn {BGP} {aggregate-address @var{A.B.C.D/M}} {}
545: This command specifies an aggregate address.
546: @end deffn
547:
548: @deffn {BGP} {aggregate-address @var{A.B.C.D/M} as-set} {}
1.1.1.3 ! misho 549: This command specifies an aggregate address. Resulting routes include
1.1 misho 550: AS set.
551: @end deffn
552:
553: @deffn {BGP} {aggregate-address @var{A.B.C.D/M} summary-only} {}
554: This command specifies an aggregate address. Aggreated routes will
555: not be announce.
556: @end deffn
557:
558: @deffn {BGP} {no aggregate-address @var{A.B.C.D/M}} {}
559: @end deffn
560:
561: @node Redistribute to BGP
562: @subsection Redistribute to BGP
563:
564: @deffn {BGP} {redistribute kernel} {}
565: Redistribute kernel route to BGP process.
566: @end deffn
567:
568: @deffn {BGP} {redistribute static} {}
569: Redistribute static route to BGP process.
570: @end deffn
571:
572: @deffn {BGP} {redistribute connected} {}
573: Redistribute connected route to BGP process.
574: @end deffn
575:
576: @deffn {BGP} {redistribute rip} {}
577: Redistribute RIP route to BGP process.
578: @end deffn
579:
580: @deffn {BGP} {redistribute ospf} {}
581: Redistribute OSPF route to BGP process.
582: @end deffn
583:
584: @node BGP Peer
585: @section BGP Peer
586:
587: @menu
588: * Defining Peer::
589: * BGP Peer commands::
590: * Peer filtering::
591: @end menu
592:
593: @node Defining Peer
594: @subsection Defining Peer
595:
596: @deffn {BGP} {neighbor @var{peer} remote-as @var{asn}} {}
597: Creates a new neighbor whose remote-as is @var{asn}. @var{peer}
598: can be an IPv4 address or an IPv6 address.
599: @example
600: @group
601: router bgp 1
602: neighbor 10.0.0.1 remote-as 2
603: @end group
604: @end example
605: In this case my router, in AS-1, is trying to peer with AS-2 at
606: 10.0.0.1.
607:
608: This command must be the first command used when configuring a neighbor.
609: If the remote-as is not specified, @command{bgpd} will complain like this:
610: @example
611: can't find neighbor 10.0.0.1
612: @end example
613: @end deffn
614:
615: @node BGP Peer commands
616: @subsection BGP Peer commands
617:
618: In a @code{router bgp} clause there are neighbor specific configurations
619: required.
620:
621: @deffn {BGP} {neighbor @var{peer} shutdown} {}
622: @deffnx {BGP} {no neighbor @var{peer} shutdown} {}
623: Shutdown the peer. We can delete the neighbor's configuration by
624: @code{no neighbor @var{peer} remote-as @var{as-number}} but all
625: configuration of the neighbor will be deleted. When you want to
626: preserve the configuration, but want to drop the BGP peer, use this
627: syntax.
628: @end deffn
629:
630: @deffn {BGP} {neighbor @var{peer} ebgp-multihop} {}
631: @deffnx {BGP} {no neighbor @var{peer} ebgp-multihop} {}
632: @end deffn
633:
634: @deffn {BGP} {neighbor @var{peer} description ...} {}
635: @deffnx {BGP} {no neighbor @var{peer} description ...} {}
636: Set description of the peer.
637: @end deffn
638:
639: @deffn {BGP} {neighbor @var{peer} version @var{version}} {}
640: Set up the neighbor's BGP version. @var{version} can be @var{4},
641: @var{4+} or @var{4-}. BGP version @var{4} is the default value used for
642: BGP peering. BGP version @var{4+} means that the neighbor supports
643: Multiprotocol Extensions for BGP-4. BGP version @var{4-} is similar but
644: the neighbor speaks the old Internet-Draft revision 00's Multiprotocol
645: Extensions for BGP-4. Some routing software is still using this
646: version.
647: @end deffn
648:
649: @deffn {BGP} {neighbor @var{peer} interface @var{ifname}} {}
650: @deffnx {BGP} {no neighbor @var{peer} interface @var{ifname}} {}
651: When you connect to a BGP peer over an IPv6 link-local address, you
652: have to specify the @var{ifname} of the interface used for the
653: connection. To specify IPv4 session addresses, see the
654: @code{neighbor @var{peer} update-source} command below.
655:
656: This command is deprecated and may be removed in a future release. Its
657: use should be avoided.
658: @end deffn
659:
1.1.1.3 ! misho 660: @deffn {BGP} {neighbor @var{peer} next-hop-self [all]} {}
! 661: @deffnx {BGP} {no neighbor @var{peer} next-hop-self [all]} {}
1.1 misho 662: This command specifies an announced route's nexthop as being equivalent
1.1.1.3 ! misho 663: to the address of the bgp router if it is learned via eBGP.
! 664: If the optional keyword @code{all} is specified the modifiation is done
! 665: also for routes learned via iBGP.
1.1 misho 666: @end deffn
667:
668: @deffn {BGP} {neighbor @var{peer} update-source @var{<ifname|address>}} {}
669: @deffnx {BGP} {no neighbor @var{peer} update-source} {}
670: Specify the IPv4 source address to use for the @acronym{BGP} session to this
671: neighbour, may be specified as either an IPv4 address directly or
672: as an interface name (in which case the @command{zebra} daemon MUST be running
673: in order for @command{bgpd} to be able to retrieve interface state).
674: @example
675: @group
676: router bgp 64555
677: neighbor foo update-source 192.168.0.1
678: neighbor bar update-source lo0
679: @end group
680: @end example
681: @end deffn
682:
683: @deffn {BGP} {neighbor @var{peer} default-originate} {}
684: @deffnx {BGP} {no neighbor @var{peer} default-originate} {}
685: @command{bgpd}'s default is to not announce the default route (0.0.0.0/0) even it
686: is in routing table. When you want to announce default routes to the
687: peer, use this command.
688: @end deffn
689:
690: @deffn {BGP} {neighbor @var{peer} port @var{port}} {}
691: @deffnx {BGP} {neighbor @var{peer} port @var{port}} {}
692: @end deffn
693:
694: @deffn {BGP} {neighbor @var{peer} send-community} {}
695: @deffnx {BGP} {neighbor @var{peer} send-community} {}
696: @end deffn
697:
698: @deffn {BGP} {neighbor @var{peer} weight @var{weight}} {}
699: @deffnx {BGP} {no neighbor @var{peer} weight @var{weight}} {}
700: This command specifies a default @var{weight} value for the neighbor's
701: routes.
702: @end deffn
703:
704: @deffn {BGP} {neighbor @var{peer} maximum-prefix @var{number}} {}
705: @deffnx {BGP} {no neighbor @var{peer} maximum-prefix @var{number}} {}
706: @end deffn
707:
1.1.1.2 misho 708: @deffn {BGP} {neighbor @var{peer} local-as @var{as-number}} {}
709: @deffnx {BGP} {neighbor @var{peer} local-as @var{as-number} no-prepend} {}
710: @deffnx {BGP} {neighbor @var{peer} local-as @var{as-number} no-prepend replace-as} {}
711: @deffnx {BGP} {no neighbor @var{peer} local-as} {}
712: Specify an alternate AS for this BGP process when interacting with the
713: specified peer. With no modifiers, the specified local-as is prepended to
714: the received AS_PATH when receiving routing updates from the peer, and
715: prepended to the outgoing AS_PATH (after the process local AS) when
716: transmitting local routes to the peer.
717:
718: If the no-prepend attribute is specified, then the supplied local-as is not
719: prepended to the received AS_PATH.
720:
721: If the replace-as attribute is specified, then only the supplied local-as is
722: prepended to the AS_PATH when transmitting local-route updates to this peer.
723:
724: Note that replace-as can only be specified if no-prepend is.
725:
726: This command is only allowed for eBGP peers.
727: @end deffn
728:
1.1.1.3 ! misho 729: @deffn {BGP} {neighbor @var{peer} ttl-security hops @var{number}} {}
! 730: @deffnx {BGP} {no neighbor @var{peer} ttl-security hops @var{number}} {}
! 731: This command enforces Generalized TTL Security Mechanism (GTSM), as
! 732: specified in RFC 5082. With this command, only neighbors that are the
! 733: specified number of hops away will be allowed to become neighbors. This
! 734: command is mututally exclusive with @command{ebgp-multihop}.
! 735: @end deffn
! 736:
1.1 misho 737: @node Peer filtering
738: @subsection Peer filtering
739:
740: @deffn {BGP} {neighbor @var{peer} distribute-list @var{name} [in|out]} {}
741: This command specifies a distribute-list for the peer. @var{direct} is
742: @samp{in} or @samp{out}.
743: @end deffn
744:
745: @deffn {BGP command} {neighbor @var{peer} prefix-list @var{name} [in|out]} {}
746: @end deffn
747:
748: @deffn {BGP command} {neighbor @var{peer} filter-list @var{name} [in|out]} {}
749: @end deffn
750:
751: @deffn {BGP} {neighbor @var{peer} route-map @var{name} [in|out]} {}
752: Apply a route-map on the neighbor. @var{direct} must be @code{in} or
753: @code{out}.
754: @end deffn
755:
756: @c -----------------------------------------------------------------------
757: @node BGP Peer Group
758: @section BGP Peer Group
759:
760: @deffn {BGP} {neighbor @var{word} peer-group} {}
761: This command defines a new peer group.
762: @end deffn
763:
764: @deffn {BGP} {neighbor @var{peer} peer-group @var{word}} {}
765: This command bind specific peer to peer group @var{word}.
766: @end deffn
767:
768: @node BGP Address Family
769: @section BGP Address Family
770:
1.1.1.3 ! misho 771: Multiprotocol BGP enables BGP to carry routing information for multiple
! 772: Network Layer protocols. BGP supports multiple Address Family
! 773: Identifier (AFI), namely IPv4 and IPv6. Support is also provided for
! 774: multiple sets of per-AFI information via Subsequent Address Family
! 775: Identifiers (SAFI). In addition to unicast information, VPN information
! 776: @cite{RFC4364} and @cite{RFC4659}, and Encapsulation information
! 777: @cite{RFC5512} is supported.
! 778:
! 779: @deffn {Command} {show ip bgp vpnv4 all} {}
! 780: @deffnx {Command} {show ipv6 bgp vpn all} {}
! 781: Print active IPV4 or IPV6 routes advertised via the VPN SAFI.
! 782: @end deffn
! 783:
! 784: @deffn {Command} {show ip bgp encap all} {}
! 785: @deffnx {Command} {show ipv6 bgp encap all} {}
! 786: Print active IPV4 or IPV6 routes advertised via the Encapsulation SAFI.
! 787: @end deffn
! 788:
! 789: @deffn {Command} {show bgp ipv4 encap summary} {}
! 790: @deffnx {Command} {show bgp ipv4 vpn summary} {}
! 791: @deffnx {Command} {show bgp ipv6 encap summary} {}
! 792: @deffnx {Command} {show bgp ipv6 vpn summary} {}
! 793: Print a summary of neighbor connections for the specified AFI/SAFI combination.
! 794: @end deffn
! 795:
1.1 misho 796: @c -----------------------------------------------------------------------
797: @node Autonomous System
798: @section Autonomous System
799:
800: The @acronym{AS,Autonomous System} number is one of the essential
801: element of BGP. BGP is a distance vector routing protocol, and the
802: AS-Path framework provides distance vector metric and loop detection to
803: BGP. @cite{RFC1930, Guidelines for creation, selection, and
804: registration of an Autonomous System (AS)} provides some background on
805: the concepts of an AS.
806:
807: The AS number is a two octet value, ranging in value from 1 to 65535.
808: The AS numbers 64512 through 65535 are defined as private AS numbers.
809: Private AS numbers must not to be advertised in the global Internet.
810:
811: @menu
812: * AS Path Regular Expression::
813: * Display BGP Routes by AS Path::
814: * AS Path Access List::
815: * Using AS Path in Route Map::
816: * Private AS Numbers::
817: @end menu
818:
819: @node AS Path Regular Expression
820: @subsection AS Path Regular Expression
821:
822: AS path regular expression can be used for displaying BGP routes and
823: AS path access list. AS path regular expression is based on
824: @code{POSIX 1003.2} regular expressions. Following description is
825: just a subset of @code{POSIX} regular expression. User can use full
826: @code{POSIX} regular expression. Adding to that special character '_'
827: is added for AS path regular expression.
828:
829: @table @code
830: @item .
831: Matches any single character.
832: @item *
833: Matches 0 or more occurrences of pattern.
834: @item +
835: Matches 1 or more occurrences of pattern.
836: @item ?
837: Match 0 or 1 occurrences of pattern.
838: @item ^
839: Matches the beginning of the line.
840: @item $
841: Matches the end of the line.
842: @item _
843: Character @code{_} has special meanings in AS path regular expression.
844: It matches to space and comma , and AS set delimiter @{ and @} and AS
845: confederation delimiter @code{(} and @code{)}. And it also matches to
846: the beginning of the line and the end of the line. So @code{_} can be
847: used for AS value boundaries match. @code{show ip bgp regexp _7675_}
848: matches to all of BGP routes which as AS number include @var{7675}.
849: @end table
850:
851: @node Display BGP Routes by AS Path
852: @subsection Display BGP Routes by AS Path
853:
854: To show BGP routes which has specific AS path information @code{show
855: ip bgp} command can be used.
856:
857: @deffn Command {show ip bgp regexp @var{line}} {}
858: This commands display BGP routes that matches AS path regular
859: expression @var{line}.
860: @end deffn
861:
862: @node AS Path Access List
863: @subsection AS Path Access List
864:
865: AS path access list is user defined AS path.
866:
867: @deffn {Command} {ip as-path access-list @var{word} @{permit|deny@} @var{line}} {}
868: This command defines a new AS path access list.
869: @end deffn
870:
871: @deffn {Command} {no ip as-path access-list @var{word}} {}
872: @deffnx {Command} {no ip as-path access-list @var{word} @{permit|deny@} @var{line}} {}
873: @end deffn
874:
875: @node Using AS Path in Route Map
876: @subsection Using AS Path in Route Map
877:
878: @deffn {Route Map} {match as-path @var{word}} {}
879: @end deffn
880:
881: @deffn {Route Map} {set as-path prepend @var{as-path}} {}
1.1.1.3 ! misho 882: Prepend the given string of AS numbers to the AS_PATH.
! 883: @end deffn
! 884:
! 885: @deffn {Route Map} {set as-path prepend last-as @var{num}} {}
! 886: Prepend the existing last AS number (the leftmost ASN) to the AS_PATH.
1.1 misho 887: @end deffn
888:
889: @node Private AS Numbers
890: @subsection Private AS Numbers
891:
892: @c -----------------------------------------------------------------------
893: @node BGP Communities Attribute
894: @section BGP Communities Attribute
895:
896: BGP communities attribute is widely used for implementing policy
897: routing. Network operators can manipulate BGP communities attribute
898: based on their network policy. BGP communities attribute is defined
899: in @cite{RFC1997, BGP Communities Attribute} and
900: @cite{RFC1998, An Application of the BGP Community Attribute
901: in Multi-home Routing}. It is an optional transitive attribute,
902: therefore local policy can travel through different autonomous system.
903:
904: Communities attribute is a set of communities values. Each
905: communities value is 4 octet long. The following format is used to
906: define communities value.
907:
908: @table @code
909: @item AS:VAL
910: This format represents 4 octet communities value. @code{AS} is high
911: order 2 octet in digit format. @code{VAL} is low order 2 octet in
912: digit format. This format is useful to define AS oriented policy
913: value. For example, @code{7675:80} can be used when AS 7675 wants to
914: pass local policy value 80 to neighboring peer.
915: @item internet
916: @code{internet} represents well-known communities value 0.
917: @item no-export
918: @code{no-export} represents well-known communities value @code{NO_EXPORT}@*
919: @r{(0xFFFFFF01)}. All routes carry this value must not be advertised
920: to outside a BGP confederation boundary. If neighboring BGP peer is
921: part of BGP confederation, the peer is considered as inside a BGP
922: confederation boundary, so the route will be announced to the peer.
923: @item no-advertise
924: @code{no-advertise} represents well-known communities value
925: @code{NO_ADVERTISE}@*@r{(0xFFFFFF02)}. All routes carry this value
926: must not be advertise to other BGP peers.
927: @item local-AS
928: @code{local-AS} represents well-known communities value
929: @code{NO_EXPORT_SUBCONFED} @r{(0xFFFFFF03)}. All routes carry this
930: value must not be advertised to external BGP peers. Even if the
931: neighboring router is part of confederation, it is considered as
932: external BGP peer, so the route will not be announced to the peer.
933: @end table
934:
935: When BGP communities attribute is received, duplicated communities
936: value in the communities attribute is ignored and each communities
937: values are sorted in numerical order.
938:
939: @menu
940: * BGP Community Lists::
941: * Numbered BGP Community Lists::
942: * BGP Community in Route Map::
943: * Display BGP Routes by Community::
944: * Using BGP Communities Attribute::
945: @end menu
946:
947: @node BGP Community Lists
948: @subsection BGP Community Lists
949:
950: BGP community list is a user defined BGP communites attribute list.
951: BGP community list can be used for matching or manipulating BGP
952: communities attribute in updates.
953:
954: There are two types of community list. One is standard community
955: list and another is expanded community list. Standard community list
956: defines communities attribute. Expanded community list defines
957: communities attribute string with regular expression. Standard
958: community list is compiled into binary format when user define it.
959: Standard community list will be directly compared to BGP communities
960: attribute in BGP updates. Therefore the comparison is faster than
961: expanded community list.
962:
963: @deffn Command {ip community-list standard @var{name} @{permit|deny@} @var{community}} {}
964: This command defines a new standard community list. @var{community}
965: is communities value. The @var{community} is compiled into community
966: structure. We can define multiple community list under same name. In
967: that case match will happen user defined order. Once the
968: community list matches to communities attribute in BGP updates it
969: return permit or deny by the community list definition. When there is
970: no matched entry, deny will be returned. When @var{community} is
971: empty it matches to any routes.
972: @end deffn
973:
974: @deffn Command {ip community-list expanded @var{name} @{permit|deny@} @var{line}} {}
975: This command defines a new expanded community list. @var{line} is a
976: string expression of communities attribute. @var{line} can include
977: regular expression to match communities attribute in BGP updates.
978: @end deffn
979:
980: @deffn Command {no ip community-list @var{name}} {}
981: @deffnx Command {no ip community-list standard @var{name}} {}
982: @deffnx Command {no ip community-list expanded @var{name}} {}
983: These commands delete community lists specified by @var{name}. All of
984: community lists shares a single name space. So community lists can be
985: removed simpley specifying community lists name.
986: @end deffn
987:
988: @deffn {Command} {show ip community-list} {}
989: @deffnx {Command} {show ip community-list @var{name}} {}
990: This command display current community list information. When
991: @var{name} is specified the specified community list's information is
992: shown.
993:
994: @example
995: # show ip community-list
996: Named Community standard list CLIST
997: permit 7675:80 7675:100 no-export
998: deny internet
999: Named Community expanded list EXPAND
1000: permit :
1001:
1002: # show ip community-list CLIST
1003: Named Community standard list CLIST
1004: permit 7675:80 7675:100 no-export
1005: deny internet
1006: @end example
1007: @end deffn
1008:
1009: @node Numbered BGP Community Lists
1010: @subsection Numbered BGP Community Lists
1011:
1012: When number is used for BGP community list name, the number has
1013: special meanings. Community list number in the range from 1 and 99 is
1014: standard community list. Community list number in the range from 100
1015: to 199 is expanded community list. These community lists are called
1016: as numbered community lists. On the other hand normal community lists
1017: is called as named community lists.
1018:
1019: @deffn Command {ip community-list <1-99> @{permit|deny@} @var{community}} {}
1020: This command defines a new community list. <1-99> is standard
1021: community list number. Community list name within this range defines
1022: standard community list. When @var{community} is empty it matches to
1023: any routes.
1024: @end deffn
1025:
1026: @deffn Command {ip community-list <100-199> @{permit|deny@} @var{community}} {}
1027: This command defines a new community list. <100-199> is expanded
1028: community list number. Community list name within this range defines
1029: expanded community list.
1030: @end deffn
1031:
1032: @deffn Command {ip community-list @var{name} @{permit|deny@} @var{community}} {}
1033: When community list type is not specifed, the community list type is
1034: automatically detected. If @var{community} can be compiled into
1035: communities attribute, the community list is defined as a standard
1036: community list. Otherwise it is defined as an expanded community
1037: list. This feature is left for backward compability. Use of this
1038: feature is not recommended.
1039: @end deffn
1040:
1041: @node BGP Community in Route Map
1042: @subsection BGP Community in Route Map
1043:
1044: In Route Map (@pxref{Route Map}), we can match or set BGP
1045: communities attribute. Using this feature network operator can
1046: implement their network policy based on BGP communities attribute.
1047:
1048: Following commands can be used in Route Map.
1049:
1050: @deffn {Route Map} {match community @var{word}} {}
1051: @deffnx {Route Map} {match community @var{word} exact-match} {}
1052: This command perform match to BGP updates using community list
1053: @var{word}. When the one of BGP communities value match to the one of
1054: communities value in community list, it is match. When
1055: @code{exact-match} keyword is spcified, match happen only when BGP
1056: updates have completely same communities value specified in the
1057: community list.
1058: @end deffn
1059:
1060: @deffn {Route Map} {set community none} {}
1061: @deffnx {Route Map} {set community @var{community}} {}
1062: @deffnx {Route Map} {set community @var{community} additive} {}
1063: This command manipulate communities value in BGP updates. When
1064: @code{none} is specified as communities value, it removes entire
1065: communities attribute from BGP updates. When @var{community} is not
1066: @code{none}, specified communities value is set to BGP updates. If
1067: BGP updates already has BGP communities value, the existing BGP
1068: communities value is replaced with specified @var{community} value.
1069: When @code{additive} keyword is specified, @var{community} is appended
1070: to the existing communities value.
1071: @end deffn
1072:
1073: @deffn {Route Map} {set comm-list @var{word} delete} {}
1074: This command remove communities value from BGP communities attribute.
1075: The @var{word} is community list name. When BGP route's communities
1076: value matches to the community list @var{word}, the communities value
1077: is removed. When all of communities value is removed eventually, the
1078: BGP update's communities attribute is completely removed.
1079: @end deffn
1080:
1081: @node Display BGP Routes by Community
1082: @subsection Display BGP Routes by Community
1083:
1084: To show BGP routes which has specific BGP communities attribute,
1085: @code{show ip bgp} command can be used. The @var{community} value and
1086: community list can be used for @code{show ip bgp} command.
1087:
1088: @deffn Command {show ip bgp community} {}
1089: @deffnx Command {show ip bgp community @var{community}} {}
1090: @deffnx Command {show ip bgp community @var{community} exact-match} {}
1091: @code{show ip bgp community} displays BGP routes which has communities
1092: attribute. When @var{community} is specified, BGP routes that matches
1093: @var{community} value is displayed. For this command, @code{internet}
1094: keyword can't be used for @var{community} value. When
1095: @code{exact-match} is specified, it display only routes that have an
1096: exact match.
1097: @end deffn
1098:
1099: @deffn Command {show ip bgp community-list @var{word}} {}
1100: @deffnx Command {show ip bgp community-list @var{word} exact-match} {}
1101: This commands display BGP routes that matches community list
1102: @var{word}. When @code{exact-match} is specified, display only routes
1103: that have an exact match.
1104: @end deffn
1105:
1106: @node Using BGP Communities Attribute
1107: @subsection Using BGP Communities Attribute
1108:
1109: Following configuration is the most typical usage of BGP communities
1110: attribute. AS 7675 provides upstream Internet connection to AS 100.
1111: When following configuration exists in AS 7675, AS 100 networks
1112: operator can set local preference in AS 7675 network by setting BGP
1113: communities attribute to the updates.
1114:
1115: @example
1116: router bgp 7675
1117: neighbor 192.168.0.1 remote-as 100
1118: neighbor 192.168.0.1 route-map RMAP in
1119: !
1120: ip community-list 70 permit 7675:70
1121: ip community-list 70 deny
1122: ip community-list 80 permit 7675:80
1123: ip community-list 80 deny
1124: ip community-list 90 permit 7675:90
1125: ip community-list 90 deny
1126: !
1127: route-map RMAP permit 10
1128: match community 70
1129: set local-preference 70
1130: !
1131: route-map RMAP permit 20
1132: match community 80
1133: set local-preference 80
1134: !
1135: route-map RMAP permit 30
1136: match community 90
1137: set local-preference 90
1138: @end example
1139:
1140: Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675.
1141: The route has communities value 7675:80 so when above configuration
1142: exists in AS 7675, announced route's local preference will be set to
1143: value 80.
1144:
1145: @example
1146: router bgp 100
1147: network 10.0.0.0/8
1148: neighbor 192.168.0.2 remote-as 7675
1149: neighbor 192.168.0.2 route-map RMAP out
1150: !
1151: ip prefix-list PLIST permit 10.0.0.0/8
1152: !
1153: route-map RMAP permit 10
1154: match ip address prefix-list PLIST
1155: set community 7675:80
1156: @end example
1157:
1158: Following configuration is an example of BGP route filtering using
1159: communities attribute. This configuration only permit BGP routes
1160: which has BGP communities value 0:80 or 0:90. Network operator can
1161: put special internal communities value at BGP border router, then
1162: limit the BGP routes announcement into the internal network.
1163:
1164: @example
1165: router bgp 7675
1166: neighbor 192.168.0.1 remote-as 100
1167: neighbor 192.168.0.1 route-map RMAP in
1168: !
1169: ip community-list 1 permit 0:80 0:90
1170: !
1171: route-map RMAP permit in
1172: match community 1
1173: @end example
1174:
1175: Following exmaple filter BGP routes which has communities value 1:1.
1176: When there is no match community-list returns deny. To avoid
1177: filtering all of routes, we need to define permit any at last.
1178:
1179: @example
1180: router bgp 7675
1181: neighbor 192.168.0.1 remote-as 100
1182: neighbor 192.168.0.1 route-map RMAP in
1183: !
1184: ip community-list standard FILTER deny 1:1
1185: ip community-list standard FILTER permit
1186: !
1187: route-map RMAP permit 10
1188: match community FILTER
1189: @end example
1190:
1191: Communities value keyword @code{internet} has special meanings in
1192: standard community lists. In below example @code{internet} act as
1193: match any. It matches all of BGP routes even if the route does not
1194: have communities attribute at all. So community list @code{INTERNET}
1195: is same as above example's @code{FILTER}.
1196:
1197: @example
1198: ip community-list standard INTERNET deny 1:1
1199: ip community-list standard INTERNET permit internet
1200: @end example
1201:
1202: Following configuration is an example of communities value deletion.
1203: With this configuration communities value 100:1 and 100:2 is removed
1204: from BGP updates. For communities value deletion, only @code{permit}
1205: community-list is used. @code{deny} community-list is ignored.
1206:
1207: @example
1208: router bgp 7675
1209: neighbor 192.168.0.1 remote-as 100
1210: neighbor 192.168.0.1 route-map RMAP in
1211: !
1212: ip community-list standard DEL permit 100:1 100:2
1213: !
1214: route-map RMAP permit 10
1215: set comm-list DEL delete
1216: @end example
1217:
1218: @c -----------------------------------------------------------------------
1219: @node BGP Extended Communities Attribute
1220: @section BGP Extended Communities Attribute
1221:
1222: BGP extended communities attribute is introduced with MPLS VPN/BGP
1223: technology. MPLS VPN/BGP expands capability of network infrastructure
1224: to provide VPN functionality. At the same time it requires a new
1225: framework for policy routing. With BGP Extended Communities Attribute
1226: we can use Route Target or Site of Origin for implementing network
1227: policy for MPLS VPN/BGP.
1228:
1229: BGP Extended Communities Attribute is similar to BGP Communities
1230: Attribute. It is an optional transitive attribute. BGP Extended
1231: Communities Attribute can carry multiple Extended Community value.
1232: Each Extended Community value is eight octet length.
1233:
1234: BGP Extended Communities Attribute provides an extended range
1235: compared with BGP Communities Attribute. Adding to that there is a
1236: type field in each value to provides community space structure.
1237:
1238: There are two format to define Extended Community value. One is AS
1239: based format the other is IP address based format.
1240:
1241: @table @code
1242: @item AS:VAL
1243: This is a format to define AS based Extended Community value.
1244: @code{AS} part is 2 octets Global Administrator subfield in Extended
1245: Community value. @code{VAL} part is 4 octets Local Administrator
1246: subfield. @code{7675:100} represents AS 7675 policy value 100.
1247: @item IP-Address:VAL
1248: This is a format to define IP address based Extended Community value.
1249: @code{IP-Address} part is 4 octets Global Administrator subfield.
1250: @code{VAL} part is 2 octets Local Administrator subfield.
1251: @code{10.0.0.1:100} represents
1252: @end table
1253:
1254: @menu
1255: * BGP Extended Community Lists::
1256: * BGP Extended Communities in Route Map::
1257: @end menu
1258:
1259: @node BGP Extended Community Lists
1260: @subsection BGP Extended Community Lists
1261:
1262: Expanded Community Lists is a user defined BGP Expanded Community
1263: Lists.
1264:
1265: @deffn Command {ip extcommunity-list standard @var{name} @{permit|deny@} @var{extcommunity}} {}
1266: This command defines a new standard extcommunity-list.
1267: @var{extcommunity} is extended communities value. The
1268: @var{extcommunity} is compiled into extended community structure. We
1269: can define multiple extcommunity-list under same name. In that case
1270: match will happen user defined order. Once the extcommunity-list
1271: matches to extended communities attribute in BGP updates it return
1272: permit or deny based upon the extcommunity-list definition. When
1273: there is no matched entry, deny will be returned. When
1274: @var{extcommunity} is empty it matches to any routes.
1275: @end deffn
1276:
1277: @deffn Command {ip extcommunity-list expanded @var{name} @{permit|deny@} @var{line}} {}
1278: This command defines a new expanded extcommunity-list. @var{line} is
1279: a string expression of extended communities attribute. @var{line} can
1280: include regular expression to match extended communities attribute in
1281: BGP updates.
1282: @end deffn
1283:
1284: @deffn Command {no ip extcommunity-list @var{name}} {}
1285: @deffnx Command {no ip extcommunity-list standard @var{name}} {}
1286: @deffnx Command {no ip extcommunity-list expanded @var{name}} {}
1287: These commands delete extended community lists specified by
1288: @var{name}. All of extended community lists shares a single name
1289: space. So extended community lists can be removed simpley specifying
1290: the name.
1291: @end deffn
1292:
1293: @deffn {Command} {show ip extcommunity-list} {}
1294: @deffnx {Command} {show ip extcommunity-list @var{name}} {}
1295: This command display current extcommunity-list information. When
1296: @var{name} is specified the community list's information is shown.
1297:
1298: @example
1299: # show ip extcommunity-list
1300: @end example
1301: @end deffn
1302:
1303: @node BGP Extended Communities in Route Map
1304: @subsection BGP Extended Communities in Route Map
1305:
1306: @deffn {Route Map} {match extcommunity @var{word}} {}
1307: @end deffn
1308:
1309: @deffn {Route Map} {set extcommunity rt @var{extcommunity}} {}
1310: This command set Route Target value.
1311: @end deffn
1312:
1313: @deffn {Route Map} {set extcommunity soo @var{extcommunity}} {}
1314: This command set Site of Origin value.
1315: @end deffn
1316:
1317: @c -----------------------------------------------------------------------
1318: @node Displaying BGP routes
1319: @section Displaying BGP Routes
1320:
1321: @menu
1322: * Show IP BGP::
1323: * More Show IP BGP::
1324: @end menu
1325:
1326: @node Show IP BGP
1327: @subsection Show IP BGP
1328:
1329: @deffn {Command} {show ip bgp} {}
1330: @deffnx {Command} {show ip bgp @var{A.B.C.D}} {}
1331: @deffnx {Command} {show ip bgp @var{X:X::X:X}} {}
1332: This command displays BGP routes. When no route is specified it
1333: display all of IPv4 BGP routes.
1334: @end deffn
1335:
1336: @example
1337: BGP table version is 0, local router ID is 10.1.1.1
1338: Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
1339: Origin codes: i - IGP, e - EGP, ? - incomplete
1340:
1341: Network Next Hop Metric LocPrf Weight Path
1342: *> 1.1.1.1/32 0.0.0.0 0 32768 i
1343:
1344: Total number of prefixes 1
1345: @end example
1346:
1347: @node More Show IP BGP
1348: @subsection More Show IP BGP
1349:
1350: @deffn {Command} {show ip bgp regexp @var{line}} {}
1351: This command display BGP routes using AS path regular expression (@pxref{Display BGP Routes by AS Path}).
1352: @end deffn
1353:
1354: @deffn Command {show ip bgp community @var{community}} {}
1355: @deffnx Command {show ip bgp community @var{community} exact-match} {}
1356: This command display BGP routes using @var{community} (@pxref{Display
1357: BGP Routes by Community}).
1358: @end deffn
1359:
1360: @deffn Command {show ip bgp community-list @var{word}} {}
1361: @deffnx Command {show ip bgp community-list @var{word} exact-match} {}
1362: This command display BGP routes using community list (@pxref{Display
1363: BGP Routes by Community}).
1364: @end deffn
1365:
1366: @deffn {Command} {show ip bgp summary} {}
1367: @end deffn
1368:
1369: @deffn {Command} {show ip bgp neighbor [@var{peer}]} {}
1370: @end deffn
1371:
1372: @deffn {Command} {clear ip bgp @var{peer}} {}
1373: Clear peers which have addresses of X.X.X.X
1374: @end deffn
1375:
1376: @deffn {Command} {clear ip bgp @var{peer} soft in} {}
1377: Clear peer using soft reconfiguration.
1378: @end deffn
1379:
1380: @deffn {Command} {show ip bgp dampened-paths} {}
1381: Display paths suppressed due to dampening
1382: @end deffn
1383:
1384: @deffn {Command} {show ip bgp flap-statistics} {}
1385: Display flap statistics of routes
1386: @end deffn
1387:
1388: @deffn {Command} {show debug} {}
1389: @end deffn
1390:
1391: @deffn {Command} {debug event} {}
1392: @end deffn
1393:
1394: @deffn {Command} {debug update} {}
1395: @end deffn
1396:
1397: @deffn {Command} {debug keepalive} {}
1398: @end deffn
1399:
1400: @deffn {Command} {no debug event} {}
1401: @end deffn
1402:
1403: @deffn {Command} {no debug update} {}
1404: @end deffn
1405:
1406: @deffn {Command} {no debug keepalive} {}
1407: @end deffn
1408:
1409: @node Capability Negotiation
1410: @section Capability Negotiation
1411:
1412: When adding IPv6 routing information exchange feature to BGP. There
1413: were some proposals. @acronym{IETF,Internet Engineering Task Force}
1414: @acronym{IDR, Inter Domain Routing} @acronym{WG, Working group} adopted
1415: a proposal called Multiprotocol Extension for BGP. The specification
1416: is described in @cite{RFC2283}. The protocol does not define new protocols.
1417: It defines new attributes to existing BGP. When it is used exchanging
1418: IPv6 routing information it is called BGP-4+. When it is used for
1419: exchanging multicast routing information it is called MBGP.
1420:
1421: @command{bgpd} supports Multiprotocol Extension for BGP. So if remote
1422: peer supports the protocol, @command{bgpd} can exchange IPv6 and/or
1423: multicast routing information.
1424:
1425: Traditional BGP did not have the feature to detect remote peer's
1426: capabilities, e.g. whether it can handle prefix types other than IPv4
1427: unicast routes. This was a big problem using Multiprotocol Extension
1428: for BGP to operational network. @cite{RFC2842, Capabilities
1429: Advertisement with BGP-4} adopted a feature called Capability
1430: Negotiation. @command{bgpd} use this Capability Negotiation to detect
1431: the remote peer's capabilities. If the peer is only configured as IPv4
1432: unicast neighbor, @command{bgpd} does not send these Capability
1433: Negotiation packets (at least not unless other optional BGP features
1434: require capability negotation).
1435:
1436: By default, Quagga will bring up peering with minimal common capability
1437: for the both sides. For example, local router has unicast and
1438: multicast capabilitie and remote router has unicast capability. In
1439: this case, the local router will establish the connection with unicast
1440: only capability. When there are no common capabilities, Quagga sends
1441: Unsupported Capability error and then resets the connection.
1442:
1443: If you want to completely match capabilities with remote peer. Please
1444: use @command{strict-capability-match} command.
1445:
1446: @deffn {BGP} {neighbor @var{peer} strict-capability-match} {}
1447: @deffnx {BGP} {no neighbor @var{peer} strict-capability-match} {}
1448: Strictly compares remote capabilities and local capabilities. If capabilities
1449: are different, send Unsupported Capability error then reset connection.
1450: @end deffn
1451:
1452: You may want to disable sending Capability Negotiation OPEN message
1453: optional parameter to the peer when remote peer does not implement
1454: Capability Negotiation. Please use @command{dont-capability-negotiate}
1455: command to disable the feature.
1456:
1457: @deffn {BGP} {neighbor @var{peer} dont-capability-negotiate} {}
1458: @deffnx {BGP} {no neighbor @var{peer} dont-capability-negotiate} {}
1459: Suppress sending Capability Negotiation as OPEN message optional
1460: parameter to the peer. This command only affects the peer is configured
1461: other than IPv4 unicast configuration.
1462: @end deffn
1463:
1464: When remote peer does not have capability negotiation feature, remote
1465: peer will not send any capabilities at all. In that case, bgp
1466: configures the peer with configured capabilities.
1467:
1468: You may prefer locally configured capabilities more than the negotiated
1469: capabilities even though remote peer sends capabilities. If the peer
1470: is configured by @command{override-capability}, @command{bgpd} ignores
1471: received capabilities then override negotiated capabilities with
1472: configured values.
1473:
1474: @deffn {BGP} {neighbor @var{peer} override-capability} {}
1475: @deffnx {BGP} {no neighbor @var{peer} override-capability} {}
1476: Override the result of Capability Negotiation with local configuration.
1477: Ignore remote peer's capability value.
1478: @end deffn
1479:
1480: @node Route Reflector
1481: @section Route Reflector
1482:
1483: @deffn {BGP} {bgp cluster-id @var{a.b.c.d}} {}
1484: @end deffn
1485:
1486: @deffn {BGP} {neighbor @var{peer} route-reflector-client} {}
1487: @deffnx {BGP} {no neighbor @var{peer} route-reflector-client} {}
1488: @end deffn
1489:
1490: @node Route Server
1491: @section Route Server
1492:
1493: At an Internet Exchange point, many ISPs are connected to each other by
1494: external BGP peering. Normally these external BGP connection are done by
1495: @samp{full mesh} method. As with internal BGP full mesh formation,
1496: this method has a scaling problem.
1497:
1498: This scaling problem is well known. Route Server is a method to resolve
1499: the problem. Each ISP's BGP router only peers to Route Server. Route
1500: Server serves as BGP information exchange to other BGP routers. By
1501: applying this method, numbers of BGP connections is reduced from
1502: O(n*(n-1)/2) to O(n).
1503:
1504: Unlike normal BGP router, Route Server must have several routing tables
1505: for managing different routing policies for each BGP speaker. We call the
1506: routing tables as different @code{view}s. @command{bgpd} can work as
1507: normal BGP router or Route Server or both at the same time.
1508:
1509: @menu
1510: * Multiple instance::
1511: * BGP instance and view::
1512: * Routing policy::
1513: * Viewing the view::
1514: @end menu
1515:
1516: @node Multiple instance
1517: @subsection Multiple instance
1518:
1519: To enable multiple view function of @code{bgpd}, you must turn on
1520: multiple instance feature beforehand.
1521:
1522: @deffn {Command} {bgp multiple-instance} {}
1523: Enable BGP multiple instance feature. After this feature is enabled,
1524: you can make multiple BGP instances or multiple BGP views.
1525: @end deffn
1526:
1527: @deffn {Command} {no bgp multiple-instance} {}
1528: Disable BGP multiple instance feature. You can not disable this feature
1529: when BGP multiple instances or views exist.
1530: @end deffn
1531:
1532: When you want to make configuration more Cisco like one,
1533:
1534: @deffn {Command} {bgp config-type cisco} {}
1535: Cisco compatible BGP configuration output.
1536: @end deffn
1537:
1538: When bgp config-type cisco is specified,
1539:
1540: ``no synchronization'' is displayed.
1541: ``no auto-summary'' is displayed.
1542:
1543: ``network'' and ``aggregate-address'' argument is displayed as
1544: ``A.B.C.D M.M.M.M''
1545:
1546: Quagga: network 10.0.0.0/8
1547: Cisco: network 10.0.0.0
1548:
1549: Quagga: aggregate-address 192.168.0.0/24
1550: Cisco: aggregate-address 192.168.0.0 255.255.255.0
1551:
1552: Community attribute handling is also different. If there is no
1553: configuration is specified community attribute and extended community
1554: attribute are sent to neighbor. When user manually disable the
1555: feature community attribute is not sent to the neighbor. In case of
1556: @command{bgp config-type cisco} is specified, community attribute is not
1557: sent to the neighbor by default. To send community attribute user has
1558: to specify @command{neighbor A.B.C.D send-community} command.
1559:
1560: @example
1561: !
1562: router bgp 1
1563: neighbor 10.0.0.1 remote-as 1
1564: no neighbor 10.0.0.1 send-community
1565: !
1566: router bgp 1
1567: neighbor 10.0.0.1 remote-as 1
1568: neighbor 10.0.0.1 send-community
1569: !
1570: @end example
1571:
1572: @deffn {Command} {bgp config-type zebra} {}
1573: Quagga style BGP configuration. This is default.
1574: @end deffn
1575:
1576: @node BGP instance and view
1577: @subsection BGP instance and view
1578:
1579: BGP instance is a normal BGP process. The result of route selection
1580: goes to the kernel routing table. You can setup different AS at the
1581: same time when BGP multiple instance feature is enabled.
1582:
1583: @deffn {Command} {router bgp @var{as-number}} {}
1584: Make a new BGP instance. You can use arbitrary word for the @var{name}.
1585: @end deffn
1586:
1587: @example
1588: @group
1589: bgp multiple-instance
1590: !
1591: router bgp 1
1592: neighbor 10.0.0.1 remote-as 2
1593: neighbor 10.0.0.2 remote-as 3
1594: !
1595: router bgp 2
1596: neighbor 10.0.0.3 remote-as 4
1597: neighbor 10.0.0.4 remote-as 5
1598: @end group
1599: @end example
1600:
1601: BGP view is almost same as normal BGP process. The result of
1602: route selection does not go to the kernel routing table. BGP view is
1603: only for exchanging BGP routing information.
1604:
1605: @deffn {Command} {router bgp @var{as-number} view @var{name}} {}
1606: Make a new BGP view. You can use arbitrary word for the @var{name}. This
1607: view's route selection result does not go to the kernel routing table.
1608: @end deffn
1609:
1610: With this command, you can setup Route Server like below.
1611:
1612: @example
1613: @group
1614: bgp multiple-instance
1615: !
1616: router bgp 1 view 1
1617: neighbor 10.0.0.1 remote-as 2
1618: neighbor 10.0.0.2 remote-as 3
1619: !
1620: router bgp 2 view 2
1621: neighbor 10.0.0.3 remote-as 4
1622: neighbor 10.0.0.4 remote-as 5
1623: @end group
1624: @end example
1625:
1626: @node Routing policy
1627: @subsection Routing policy
1628:
1629: You can set different routing policy for a peer. For example, you can
1630: set different filter for a peer.
1631:
1632: @example
1633: @group
1634: bgp multiple-instance
1635: !
1636: router bgp 1 view 1
1637: neighbor 10.0.0.1 remote-as 2
1638: neighbor 10.0.0.1 distribute-list 1 in
1639: !
1640: router bgp 1 view 2
1641: neighbor 10.0.0.1 remote-as 2
1642: neighbor 10.0.0.1 distribute-list 2 in
1643: @end group
1644: @end example
1645:
1646: This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view
1647: 2. When the update is inserted into view 1, distribute-list 1 is
1648: applied. On the other hand, when the update is inserted into view 2,
1649: distribute-list 2 is applied.
1650:
1651: @node Viewing the view
1652: @subsection Viewing the view
1653:
1654: To display routing table of BGP view, you must specify view name.
1655:
1656: @deffn {Command} {show ip bgp view @var{name}} {}
1657: Display routing table of BGP view @var{name}.
1658: @end deffn
1659:
1660: @node How to set up a 6-Bone connection
1661: @section How to set up a 6-Bone connection
1662:
1663:
1664: @example
1665: @group
1666: zebra configuration
1667: ===================
1668: !
1669: ! Actually there is no need to configure zebra
1670: !
1671:
1672: bgpd configuration
1673: ==================
1674: !
1675: ! This means that routes go through zebra and into the kernel.
1676: !
1677: router zebra
1678: !
1679: ! MP-BGP configuration
1680: !
1681: router bgp 7675
1682: bgp router-id 10.0.0.1
1683: neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as @var{as-number}
1684: !
1685: address-family ipv6
1686: network 3ffe:506::/32
1687: neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
1688: neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
1689: neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as @var{as-number}
1690: neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
1691: exit-address-family
1692: !
1693: ipv6 access-list all permit any
1694: !
1695: ! Set output nexthop address.
1696: !
1697: route-map set-nexthop permit 10
1698: match ipv6 address all
1699: set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
1700: set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
1701: !
1702: ! logfile FILENAME is obsolete. Please use log file FILENAME
1703:
1704: log file bgpd.log
1705: !
1706: @end group
1707: @end example
1708:
1709: @node Dump BGP packets and table
1710: @section Dump BGP packets and table
1711:
1.1.1.3 ! misho 1712: @deffn Command {dump bgp all @var{path} [@var{interval}]} {}
! 1713: @deffnx Command {dump bgp all-et @var{path} [@var{interval}]} {}
! 1714: @deffnx Command {no dump bgp all [@var{path}] [@var{interval}]} {}
1.1 misho 1715: Dump all BGP packet and events to @var{path} file.
1.1.1.3 ! misho 1716: If @var{interval} is set, a new file will be created for echo @var{interval} of seconds.
! 1717: The path @var{path} can be set with date and time formatting (strftime).
! 1718: The type ‘all-et’ enables support for Extended Timestamp Header (@pxref{Packet Binary Dump Format}).
! 1719: (@pxref{Packet Binary Dump Format})
1.1 misho 1720: @end deffn
1721:
1.1.1.3 ! misho 1722: @deffn Command {dump bgp updates @var{path} [@var{interval}]} {}
! 1723: @deffnx Command {dump bgp updates-et @var{path} [@var{interval}]} {}
! 1724: @deffnx Command {no dump bgp updates [@var{path}] [@var{interval}]} {}
! 1725: Dump only BGP updates messages to @var{path} file.
! 1726: If @var{interval} is set, a new file will be created for echo @var{interval} of seconds.
! 1727: The path @var{path} can be set with date and time formatting (strftime).
! 1728: The type ‘updates-et’ enables support for Extended Timestamp Header (@pxref{Packet Binary Dump Format}).
1.1 misho 1729: @end deffn
1730:
1.1.1.3 ! misho 1731: @deffn Command {dump bgp routes-mrt @var{path}} {}
! 1732: @deffnx Command {dump bgp routes-mrt @var{path} @var{interval}} {}
! 1733: @deffnx Command {no dump bgp route-mrt [@var{path}] [@var{interval}]} {}
1.1 misho 1734: Dump whole BGP routing table to @var{path}. This is heavy process.
1.1.1.3 ! misho 1735: The path @var{path} can be set with date and time formatting (strftime).
! 1736: If @var{interval} is set, a new file will be created for echo @var{interval} of seconds.
1.1 misho 1737: @end deffn
1.1.1.3 ! misho 1738:
! 1739: Note: the interval variable can also be set using hours and minutes: 04h20m00.
! 1740:
1.1 misho 1741:
1742: @node BGP Configuration Examples
1743: @section BGP Configuration Examples
1744:
1745: Example of a session to an upstream, advertising only one prefix to it.
1746:
1747: @example
1748: router bgp 64512
1749: bgp router-id 10.236.87.1
1750: network 10.236.87.0/24
1751: neighbor upstream peer-group
1752: neighbor upstream remote-as 64515
1753: neighbor upstream capability dynamic
1754: neighbor upstream prefix-list pl-allowed-adv out
1755: neighbor 10.1.1.1 peer-group upstream
1756: neighbor 10.1.1.1 description ACME ISP
1757: !
1758: ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
1759: ip prefix-list pl-allowed-adv seq 10 deny any
1760:
1761: @end example
1762:
1763: A more complex example. With upstream, peer and customer sessions.
1764: Advertising global prefixes and NO_EXPORT prefixes and providing
1765: actions for customer routes based on community values. Extensive use of
1766: route-maps and the 'call' feature to support selective advertising of
1767: prefixes. This example is intended as guidance only, it has NOT been
1768: tested and almost certainly containts silly mistakes, if not serious
1769: flaws.
1770:
1771: @example
1772: router bgp 64512
1773: bgp router-id 10.236.87.1
1774: network 10.123.456.0/24
1775: network 10.123.456.128/25 route-map rm-no-export
1776: neighbor upstream capability dynamic
1777: neighbor upstream route-map rm-upstream-out out
1778: neighbor cust capability dynamic
1779: neighbor cust route-map rm-cust-in in
1780: neighbor cust route-map rm-cust-out out
1781: neighbor cust send-community both
1782: neighbor peer capability dynamic
1783: neighbor peer route-map rm-peer-in in
1784: neighbor peer route-map rm-peer-out out
1785: neighbor peer send-community both
1786: neighbor 10.1.1.1 remote-as 64515
1787: neighbor 10.1.1.1 peer-group upstream
1788: neighbor 10.2.1.1 remote-as 64516
1789: neighbor 10.2.1.1 peer-group upstream
1790: neighbor 10.3.1.1 remote-as 64517
1791: neighbor 10.3.1.1 peer-group cust-default
1792: neighbor 10.3.1.1 description customer1
1793: neighbor 10.3.1.1 prefix-list pl-cust1-network in
1794: neighbor 10.4.1.1 remote-as 64518
1795: neighbor 10.4.1.1 peer-group cust
1796: neighbor 10.4.1.1 prefix-list pl-cust2-network in
1797: neighbor 10.4.1.1 description customer2
1798: neighbor 10.5.1.1 remote-as 64519
1799: neighbor 10.5.1.1 peer-group peer
1800: neighbor 10.5.1.1 prefix-list pl-peer1-network in
1801: neighbor 10.5.1.1 description peer AS 1
1802: neighbor 10.6.1.1 remote-as 64520
1803: neighbor 10.6.1.1 peer-group peer
1804: neighbor 10.6.1.1 prefix-list pl-peer2-network in
1805: neighbor 10.6.1.1 description peer AS 2
1806: !
1807: ip prefix-list pl-default permit 0.0.0.0/0
1808: !
1809: ip prefix-list pl-upstream-peers permit 10.1.1.1/32
1810: ip prefix-list pl-upstream-peers permit 10.2.1.1/32
1811: !
1812: ip prefix-list pl-cust1-network permit 10.3.1.0/24
1813: ip prefix-list pl-cust1-network permit 10.3.2.0/24
1814: !
1815: ip prefix-list pl-cust2-network permit 10.4.1.0/24
1816: !
1817: ip prefix-list pl-peer1-network permit 10.5.1.0/24
1818: ip prefix-list pl-peer1-network permit 10.5.2.0/24
1819: ip prefix-list pl-peer1-network permit 192.168.0.0/24
1820: !
1821: ip prefix-list pl-peer2-network permit 10.6.1.0/24
1822: ip prefix-list pl-peer2-network permit 10.6.2.0/24
1823: ip prefix-list pl-peer2-network permit 192.168.1.0/24
1824: ip prefix-list pl-peer2-network permit 192.168.2.0/24
1825: ip prefix-list pl-peer2-network permit 172.16.1/24
1826: !
1827: ip as-path access-list asp-own-as permit ^$
1828: ip as-path access-list asp-own-as permit _64512_
1829: !
1830: ! #################################################################
1831: ! Match communities we provide actions for, on routes receives from
1832: ! customers. Communities values of <our-ASN>:X, with X, have actions:
1833: !
1834: ! 100 - blackhole the prefix
1835: ! 200 - set no_export
1836: ! 300 - advertise only to other customers
1837: ! 400 - advertise only to upstreams
1838: ! 500 - set no_export when advertising to upstreams
1839: ! 2X00 - set local_preference to X00
1840: !
1841: ! blackhole the prefix of the route
1842: ip community-list standard cm-blackhole permit 64512:100
1843: !
1844: ! set no-export community before advertising
1845: ip community-list standard cm-set-no-export permit 64512:200
1846: !
1847: ! advertise only to other customers
1848: ip community-list standard cm-cust-only permit 64512:300
1849: !
1850: ! advertise only to upstreams
1851: ip community-list standard cm-upstream-only permit 64512:400
1852: !
1853: ! advertise to upstreams with no-export
1854: ip community-list standard cm-upstream-noexport permit 64512:500
1855: !
1856: ! set local-pref to least significant 3 digits of the community
1857: ip community-list standard cm-prefmod-100 permit 64512:2100
1858: ip community-list standard cm-prefmod-200 permit 64512:2200
1859: ip community-list standard cm-prefmod-300 permit 64512:2300
1860: ip community-list standard cm-prefmod-400 permit 64512:2400
1861: ip community-list expanded cme-prefmod-range permit 64512:2...
1862: !
1863: ! Informational communities
1864: !
1865: ! 3000 - learned from upstream
1866: ! 3100 - learned from customer
1867: ! 3200 - learned from peer
1868: !
1869: ip community-list standard cm-learnt-upstream permit 64512:3000
1870: ip community-list standard cm-learnt-cust permit 64512:3100
1871: ip community-list standard cm-learnt-peer permit 64512:3200
1872: !
1873: ! ###################################################################
1874: ! Utility route-maps
1875: !
1876: ! These utility route-maps generally should not used to permit/deny
1877: ! routes, i.e. they do not have meaning as filters, and hence probably
1878: ! should be used with 'on-match next'. These all finish with an empty
1879: ! permit entry so as not interfere with processing in the caller.
1880: !
1881: route-map rm-no-export permit 10
1882: set community additive no-export
1883: route-map rm-no-export permit 20
1884: !
1885: route-map rm-blackhole permit 10
1886: description blackhole, up-pref and ensure it cant escape this AS
1887: set ip next-hop 127.0.0.1
1888: set local-preference 10
1889: set community additive no-export
1890: route-map rm-blackhole permit 20
1891: !
1892: ! Set local-pref as requested
1893: route-map rm-prefmod permit 10
1894: match community cm-prefmod-100
1895: set local-preference 100
1896: route-map rm-prefmod permit 20
1897: match community cm-prefmod-200
1898: set local-preference 200
1899: route-map rm-prefmod permit 30
1900: match community cm-prefmod-300
1901: set local-preference 300
1902: route-map rm-prefmod permit 40
1903: match community cm-prefmod-400
1904: set local-preference 400
1905: route-map rm-prefmod permit 50
1906: !
1907: ! Community actions to take on receipt of route.
1908: route-map rm-community-in permit 10
1909: description check for blackholing, no point continuing if it matches.
1910: match community cm-blackhole
1911: call rm-blackhole
1912: route-map rm-community-in permit 20
1913: match community cm-set-no-export
1914: call rm-no-export
1915: on-match next
1916: route-map rm-community-in permit 30
1917: match community cme-prefmod-range
1918: call rm-prefmod
1919: route-map rm-community-in permit 40
1920: !
1921: ! #####################################################################
1922: ! Community actions to take when advertising a route.
1923: ! These are filtering route-maps,
1924: !
1925: ! Deny customer routes to upstream with cust-only set.
1926: route-map rm-community-filt-to-upstream deny 10
1927: match community cm-learnt-cust
1928: match community cm-cust-only
1929: route-map rm-community-filt-to-upstream permit 20
1930: !
1931: ! Deny customer routes to other customers with upstream-only set.
1932: route-map rm-community-filt-to-cust deny 10
1933: match community cm-learnt-cust
1934: match community cm-upstream-only
1935: route-map rm-community-filt-to-cust permit 20
1936: !
1937: ! ###################################################################
1938: ! The top-level route-maps applied to sessions. Further entries could
1939: ! be added obviously..
1940: !
1941: ! Customers
1942: route-map rm-cust-in permit 10
1943: call rm-community-in
1944: on-match next
1945: route-map rm-cust-in permit 20
1946: set community additive 64512:3100
1947: route-map rm-cust-in permit 30
1948: !
1949: route-map rm-cust-out permit 10
1950: call rm-community-filt-to-cust
1951: on-match next
1952: route-map rm-cust-out permit 20
1953: !
1954: ! Upstream transit ASes
1955: route-map rm-upstream-out permit 10
1956: description filter customer prefixes which are marked cust-only
1957: call rm-community-filt-to-upstream
1958: on-match next
1959: route-map rm-upstream-out permit 20
1960: description only customer routes are provided to upstreams/peers
1961: match community cm-learnt-cust
1962: !
1963: ! Peer ASes
1964: ! outbound policy is same as for upstream
1965: route-map rm-peer-out permit 10
1966: call rm-upstream-out
1967: !
1968: route-map rm-peer-in permit 10
1969: set community additive 64512:3200
1970: @end example
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to bgpd.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