2 @c This is part of the Frr Manual.
3 @c @value{COPYRIGHT_STR}
5 @c Copyright @copyright{} 2015 Hewlett Packard Enterprise Development LP
6 @c See file frr.texi for copying conditions.
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
16 Many extensions have been added to @cite{RFC1771}. @cite{RFC2858,
17 Multiprotocol Extensions for BGP-4} provides multiprotocol support to
27 * BGP Address Family::
29 * BGP Communities Attribute::
30 * BGP Extended Communities Attribute::
31 * BGP Large Communities Attribute::
32 * Displaying BGP routes::
33 * Capability Negotiation::
36 * How to set up a 6-Bone connection::
37 * Dump BGP packets and table::
38 * BGP Configuration Examples::
44 Default configuration file of @command{bgpd} is @file{bgpd.conf}.
45 @command{bgpd} searches the current directory first then
46 @value{INSTALL_PREFIX_ETC}/bgpd.conf. All of bgpd's command must be
47 configured in @file{bgpd.conf}.
49 @command{bgpd} specific invocation options are described below. Common
50 options may also be specified (@pxref{Common Invocation Options}).
54 @itemx --bgp_port=@var{PORT}
55 Set the bgp protocol's port number.
59 When program terminates, retain BGP routes added by zebra.
63 Specify a specific IP address for bgpd to listen on, rather than its
64 default of INADDR_ANY / IN6ADDR_ANY. This can be useful to constrain bgpd
65 to an internal address, or to run multiple bgpd processes on one host.
72 First of all you must configure BGP router with @command{router bgp}
73 command. To configure BGP router, you need AS number. AS number is an
74 identification of autonomous system. BGP protocol uses the AS number
75 for detecting whether the BGP connection is internal one or external one.
77 @deffn Command {router bgp @var{asn}} {}
78 Enable a BGP protocol process with the specified @var{asn}. After
79 this statement you can input any @code{BGP Commands}. You can not
80 create different BGP process under different @var{asn} without
81 specifying @code{multiple-instance} (@pxref{Multiple instance}).
84 @deffn Command {no router bgp @var{asn}} {}
85 Destroy a BGP protocol process with the specified @var{asn}.
88 @deffn {BGP} {bgp router-id @var{A.B.C.D}} {}
89 This command specifies the router-ID. If @command{bgpd} connects to @command{zebra} it gets
90 interface and address information. In that case default router ID value
91 is selected as the largest IP Address of the interfaces. When
92 @code{router zebra} is not enabled @command{bgpd} can't get interface information
93 so @code{router-id} is set to 0.0.0.0. So please set router-id by hand.
98 * BGP decision process::
99 * BGP route flap dampening::
103 @subsection BGP distance
105 @deffn {BGP} {distance bgp <1-255> <1-255> <1-255>} {}
106 This command change distance value of BGP. Each argument is distance
107 value for external routes, internal routes and local routes.
110 @deffn {BGP} {distance <1-255> @var{A.B.C.D/M}} {}
111 @deffnx {BGP} {distance <1-255> @var{A.B.C.D/M} @var{word}} {}
112 This command set distance value to
115 @node BGP decision process
116 @subsection BGP decision process
118 The decision process Frr BGP uses to select routes is as follows:
121 @item 1. Weight check
122 prefer higher local weight routes to lower routes.
124 @item 2. Local preference check
125 prefer higher local preference routes to lower.
127 @item 3. Local route check
128 Prefer local routes (statics, aggregates, redistributed) to received routes.
130 @item 4. AS path length check
131 Prefer shortest hop-count AS_PATHs.
133 @item 5. Origin check
134 Prefer the lowest origin type route. That is, prefer IGP origin routes to
135 EGP, to Incomplete routes.
138 Where routes with a MED were received from the same AS,
139 prefer the route with the lowest MED. @xref{BGP MED}.
141 @item 7. External check
142 Prefer the route received from an external, eBGP peer
143 over routes received from other types of peers.
145 @item 8. IGP cost check
146 Prefer the route with the lower IGP cost.
148 @item 9. Multi-path check
149 If multi-pathing is enabled, then check whether
150 the routes not yet distinguished in preference may be considered equal. If
151 @ref{bgp bestpath as-path multipath-relax} is set, all such routes are
152 considered equal, otherwise routes received via iBGP with identical AS_PATHs
153 or routes received from eBGP neighbours in the same AS are considered equal.
155 @item 10 Already-selected external check
157 Where both routes were received from eBGP peers, then prefer the route which
158 is already selected. Note that this check is not applied if @ref{bgp
159 bestpath compare-routerid} is configured. This check can prevent some cases
162 @item 11. Router-ID check
163 Prefer the route with the lowest @w{router-ID}. If the
164 route has an @w{ORIGINATOR_ID} attribute, through iBGP reflection, then that
165 router ID is used, otherwise the @w{router-ID} of the peer the route was
166 received from is used.
168 @item 12. Cluster-List length check
169 The route with the shortest cluster-list
170 length is used. The cluster-list reflects the iBGP reflection path the
173 @item 13. Peer address
174 Prefer the route received from the peer with the higher
175 transport layer address, as a last-resort tie-breaker.
179 @deffn {BGP} {bgp bestpath as-path confed} {}
180 This command specifies that the length of confederation path sets and
181 sequences should should be taken into account during the BGP best path
185 @deffn {BGP} {bgp bestpath as-path multipath-relax} {}
186 @anchor{bgp bestpath as-path multipath-relax}
187 This command specifies that BGP decision process should consider paths
188 of equal AS_PATH length candidates for multipath computation. Without
189 the knob, the entire AS_PATH must match for multipath computation.
192 @deffn {BGP} {bgp bestpath compare-routerid} {}
193 @anchor{bgp bestpath compare-routerid}
195 Ensure that when comparing routes where both are equal on most metrics,
196 including local-pref, AS_PATH length, IGP cost, MED, that the tie is broken
199 If this option is enabled, then the already-selected check, where
200 already selected eBGP routes are preferred, is skipped.
202 If a route has an @w{ORIGINATOR_ID} attribute because it has been reflected,
203 that @w{ORIGINATOR_ID} will be used. Otherwise, the router-ID of the peer the
204 route was received from will be used.
206 The advantage of this is that the route-selection (at this point) will be
207 more deterministic. The disadvantage is that a few or even one lowest-ID
208 router may attract all trafic to otherwise-equal paths because of this
209 check. It may increase the possibility of MED or IGP oscillation, unless
210 other measures were taken to avoid these. The exact behaviour will be
211 sensitive to the iBGP and reflection topology.
216 @node BGP route flap dampening
217 @subsection BGP route flap dampening
219 @deffn {BGP} {bgp dampening @var{<1-45>} @var{<1-20000>} @var{<1-20000>} @var{<1-255>}} {}
220 This command enables BGP route-flap dampening and specifies dampening parameters.
223 @item @asis{half-life}
224 Half-life time for the penalty
225 @item @asis{reuse-threshold}
226 Value to start reusing a route
227 @item @asis{suppress-threshold}
228 Value to start suppressing a route
229 @item @asis{max-suppress}
230 Maximum duration to suppress a stable route
233 The route-flap damping algorithm is compatible with @cite{RFC2439}. The use of this command
234 is not recommended nowadays, see @uref{http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378}.
240 The BGP MED (Multi_Exit_Discriminator) attribute has properties which can
241 cause subtle convergence problems in BGP. These properties and problems
242 have proven to be hard to understand, at least historically, and may still
243 not be widely understood. The following attempts to collect together and
244 present what is known about MED, to help operators and Frr users in
245 designing and configuring their networks.
247 The BGP @acronym{MED, Multi_Exit_Discriminator} attribute is intended to
248 allow one AS to indicate its preferences for its ingress points to another
249 AS. The MED attribute will not be propagated on to another AS by the
250 receiving AS - it is `non-transitive' in the BGP sense.
252 E.g., if AS X and AS Y have 2 different BGP peering points, then AS X
253 might set a MED of 100 on routes advertised at one and a MED of 200 at the
254 other. When AS Y selects between otherwise equal routes to or via
255 AS X, AS Y should prefer to take the path via the lower MED peering of 100 with
256 AS X. Setting the MED allows an AS to influence the routing taken to it
257 within another, neighbouring AS.
259 In this use of MED it is not really meaningful to compare the MED value on
260 routes where the next AS on the paths differs. E.g., if AS Y also had a
261 route for some destination via AS Z in addition to the routes from AS X, and
262 AS Z had also set a MED, it wouldn't make sense for AS Y to compare AS Z's
263 MED values to those of AS X. The MED values have been set by different
264 administrators, with different frames of reference.
266 The default behaviour of BGP therefore is to not compare MED values across
267 routes received from different neighbouring ASes. In Frr this is done by
268 comparing the neighbouring, left-most AS in the received AS_PATHs of the
269 routes and only comparing MED if those are the same.
271 @c TeXInfo uses the old, non-UTF-8 capable, pdftex, and so
272 @c doesn't render TeX the unicode precedes character correctly in PDF, etc.
273 @c Using a TeX code on the other hand doesn't work for non-TeX outputs
274 @c (plaintext, e.g.). So, use an output-conditional macro.
288 Unfortunately, this behaviour of MED, of sometimes being compared across
289 routes and sometimes not, depending on the properties of those other routes,
290 means MED can cause the order of preference over all the routes to be
291 undefined. That is, given routes A, B, and C, if A is preferred to B, and B
292 is preferred to C, then a well-defined order should mean the preference is
293 transitive (in the sense of orders @footnote{For some set of objects to have
294 an order, there @emph{must} be some binary ordering relation that is defined
295 for @emph{every} combination of those objects, and that relation @emph{must}
296 be transitive. I.e.@:, if the relation operator is @mprec{}, and if
297 a @mprec{} b and b @mprec{} c then that relation must carry over
298 and it @emph{must} be that a @mprec{} c for the objects to have an
299 order. The ordering relation may allow for equality, i.e.
300 a @mprec{} b and b @mprec{} a may both be true amd imply that
301 a and b are equal in the order and not distinguished by it, in
302 which case the set has a partial order. Otherwise, if there is an order,
303 all the objects have a distinct place in the order and the set has a total
304 order.}) and that A would be preferred to C.
306 However, when MED is involved this need not be the case. With MED it is
307 possible that C is actually preferred over A. So A is preferred to B, B is
308 preferred to C, but C is preferred to A. This can be true even where BGP
309 defines a deterministic ``most preferred'' route out of the full set of
310 A,B,C. With MED, for any given set of routes there may be a
311 deterministically preferred route, but there need not be any way to arrange
312 them into any order of preference. With unmodified MED, the order of
313 preference of routes literally becomes undefined.
315 That MED can induce non-transitive preferences over routes can cause issues.
316 Firstly, it may be perceived to cause routing table churn locally at
317 speakers; secondly, and more seriously, it may cause routing instability in
318 iBGP topologies, where sets of speakers continually oscillate between
321 The first issue arises from how speakers often implement routing decisions.
322 Though BGP defines a selection process that will deterministically select
323 the same route as best at any given speaker, even with MED, that process
324 requires evaluating all routes together. For performance and ease of
325 implementation reasons, many implementations evaluate route preferences in a
326 pair-wise fashion instead. Given there is no well-defined order when MED is
327 involved, the best route that will be chosen becomes subject to
328 implementation details, such as the order the routes are stored in. That
329 may be (locally) non-deterministic, e.g.@: it may be the order the routes
332 This indeterminism may be considered undesirable, though it need not cause
333 problems. It may mean additional routing churn is perceived, as sometimes
334 more updates may be produced than at other times in reaction to some event .
336 This first issue can be fixed with a more deterministic route selection that
337 ensures routes are ordered by the neighbouring AS during selection.
338 @xref{bgp deterministic-med}. This may reduce the number of updates as
339 routes are received, and may in some cases reduce routing churn. Though, it
340 could equally deterministically produce the largest possible set of updates
341 in response to the most common sequence of received updates.
343 A deterministic order of evaluation tends to imply an additional overhead of
344 sorting over any set of n routes to a destination. The implementation of
345 deterministic MED in Frr scales significantly worse than most sorting
346 algorithms at present, with the number of paths to a given destination.
347 That number is often low enough to not cause any issues, but where there are
348 many paths, the deterministic comparison may quickly become increasingly
349 expensive in terms of CPU.
351 Deterministic local evaluation can @emph{not} fix the second, more major,
352 issue of MED however. Which is that the non-transitive preference of routes
353 MED can cause may lead to routing instability or oscillation across multiple
354 speakers in iBGP topologies. This can occur with full-mesh iBGP, but is
355 particularly problematic in non-full-mesh iBGP topologies that further
356 reduce the routing information known to each speaker. This has primarily
357 been documented with iBGP route-reflection topologies. However, any
358 route-hiding technologies potentially could also exacerbate oscillation with
361 This second issue occurs where speakers each have only a subset of routes,
362 and there are cycles in the preferences between different combinations of
363 routes - as the undefined order of preference of MED allows - and the routes
364 are distributed in a way that causes the BGP speakers to 'chase' those
365 cycles. This can occur even if all speakers use a deterministic order of
366 evaluation in route selection.
368 E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X, and
369 from speaker 3 in AS Y; while speaker 5 in AS A might receive that route
370 from speaker 1 in AS Y. AS Y might set a MED of 200 at speaker 1, and 100
371 at speaker 3. I.e, using ASN:ID:MED to label the speakers:
376 X:2------|--A:4-------A:5--|-Y:1:200
382 Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs), then
383 based on the RFC4271 decision process speaker 4 will choose X:2 over
384 Y:3:100, based on the lower ID of 2. Speaker 4 advertises X:2 to speaker 5.
385 Speaker 5 will continue to prefer Y:1:200 based on the ID, and advertise
386 this to speaker 4. Speaker 4 will now have the full set of routes, and the
387 Y:1:200 it receives from 5 will beat X:2, but when speaker 4 compares
388 Y:1:200 to Y:3:100 the MED check now becomes active as the ASes match, and
389 now Y:3:100 is preferred. Speaker 4 therefore now advertises Y:3:100 to 5,
390 which will also agrees that Y:3:100 is preferred to Y:1:200, and so
391 withdraws the latter route from 4. Speaker 4 now has only X:2 and Y:3:100,
392 and X:2 beats Y:3:100, and so speaker 4 implicitly updates its route to
393 speaker 5 to X:2. Speaker 5 sees that Y:1:200 beats X:2 based on the ID,
394 and advertises Y:1:200 to speaker 4, and the cycle continues.
396 The root cause is the lack of a clear order of preference caused by how MED
397 sometimes is and sometimes is not compared, leading to this cycle in the
398 preferences between the routes:
402 /---> X:2 ---beats---> Y:3:100 --\
405 \---beats--- Y:1:200 <---beats---/
409 This particular type of oscillation in full-mesh iBGP topologies can be
410 avoided by speakers preferring already selected, external routes rather than
411 choosing to update to new a route based on a post-MED metric (e.g.
412 router-ID), at the cost of a non-deterministic selection process. Frr
413 implements this, as do many other implementations, so long as it is not
414 overridden by setting @ref{bgp bestpath compare-routerid}, and see also
415 @ref{BGP decision process}, .
417 However, more complex and insidious cycles of oscillation are possible with
418 iBGP route-reflection, which are not so easily avoided. These have been
419 documented in various places. See, e.g., @cite{McPherson, D. and Gill, V.
420 and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation
421 Condition", IETF RFC3345}, and @cite{Flavel, A. and M. Roughan, "Stable
422 and flexible iBGP", ACM SIGCOMM 2009}, and @cite{Griffin, T. and G. Wilfong,
423 "On the correctness of IBGP configuration", ACM SIGCOMM 2002} for concrete
424 examples and further references.
426 There is as of this writing @emph{no} known way to use MED for its original
427 purpose; @emph{and} reduce routing information in iBGP topologies;
428 @emph{and} be sure to avoid the instability problems of MED due the
429 non-transitive routing preferences it can induce; in general on arbitrary
432 There may be iBGP topology specific ways to reduce the instability risks,
433 even while using MED, e.g.@: by constraining the reflection topology and by
434 tuning IGP costs between route-reflector clusters, see RFC3345 for details.
435 In the near future, the Add-Path extension to BGP may also solve MED
436 oscillation while still allowing MED to be used as intended, by distributing
437 "best-paths per neighbour AS". This would be at the cost of distributing at
438 least as many routes to all speakers as a full-mesh iBGP would, if not more,
439 while also imposing similar CPU overheads as the "Deterministic MED" feature
440 at each Add-Path reflector.
442 More generally, the instability problems that MED can introduce on more
443 complex, non-full-mesh, iBGP topologies may be avoided either by:
448 Setting @ref{bgp always-compare-med}, however this allows MED to be compared
449 across values set by different neighbour ASes, which may not produce
450 coherent desirable results, of itself.
453 Effectively ignoring MED by setting MED to the same value (e.g.@: 0) using
454 @ref{routemap set metric} on all received routes, in combination with
455 setting @ref{bgp always-compare-med} on all speakers. This is the simplest
456 and most performant way to avoid MED oscillation issues, where an AS is happy
457 not to allow neighbours to inject this problematic metric.
461 As MED is evaluated after the AS_PATH length check, another possible use for
462 MED is for intra-AS steering of routes with equal AS_PATH length, as an
463 extension of the last case above. As MED is evaluated before IGP metric,
464 this can allow cold-potato routing to be implemented to send traffic to
465 preferred hand-offs with neighbours, rather than the closest hand-off
466 according to the IGP metric.
468 Note that even if action is taken to address the MED non-transitivity
469 issues, other oscillations may still be possible. E.g., on IGP cost if
470 iBGP and IGP topologies are at cross-purposes with each other - see the
471 Flavel and Roughan paper above for an example. Hence the guideline that the
472 iBGP topology should follow the IGP topology.
474 @deffn {BGP} {bgp deterministic-med} {}
475 @anchor{bgp deterministic-med}
477 Carry out route-selection in way that produces deterministic answers
478 locally, even in the face of MED and the lack of a well-defined order of
479 preference it can induce on routes. Without this option the preferred route
480 with MED may be determined largely by the order that routes were received
483 Setting this option will have a performance cost that may be noticeable when
484 there are many routes for each destination. Currently in Frr it is
485 implemented in a way that scales poorly as the number of routes per
486 destination increases.
488 The default is that this option is not set.
491 Note that there are other sources of indeterminism in the route selection
492 process, specifically, the preference for older and already selected routes
493 from eBGP peers, @xref{BGP decision process}.
495 @deffn {BGP} {bgp always-compare-med} {}
496 @anchor{bgp always-compare-med}
498 Always compare the MED on routes, even when they were received from
499 different neighbouring ASes. Setting this option makes the order of
500 preference of routes more defined, and should eliminate MED induced
503 If using this option, it may also be desirable to use @ref{routemap set
504 metric} to set MED to 0 on routes received from external neighbours.
506 This option can be used, together with @ref{routemap set metric} to use MED
507 as an intra-AS metric to steer equal-length AS_PATH routes to, e.g., desired
518 * Route Aggregation::
519 * Redistribute to BGP::
523 @subsection BGP route
525 @deffn {BGP} {network @var{A.B.C.D/M}} {}
526 This command adds the announcement network.
533 This configuration example says that network 10.0.0.0/8 will be
534 announced to all neighbors. Some vendors' routers don't advertise
535 routes if they aren't present in their IGP routing tables; @code{bgpd}
536 doesn't care about IGP routes when announcing its routes.
539 @deffn {BGP} {no network @var{A.B.C.D/M}} {}
542 @node Route Aggregation
543 @subsection Route Aggregation
545 @deffn {BGP} {aggregate-address @var{A.B.C.D/M}} {}
546 This command specifies an aggregate address.
549 @deffn {BGP} {aggregate-address @var{A.B.C.D/M} as-set} {}
550 This command specifies an aggregate address. Resulting routes include
554 @deffn {BGP} {aggregate-address @var{A.B.C.D/M} summary-only} {}
555 This command specifies an aggregate address. Aggreated routes will
559 @deffn {BGP} {no aggregate-address @var{A.B.C.D/M}} {}
562 @node Redistribute to BGP
563 @subsection Redistribute to BGP
565 @deffn {BGP} {redistribute kernel} {}
566 Redistribute kernel route to BGP process.
569 @deffn {BGP} {redistribute static} {}
570 Redistribute static route to BGP process.
573 @deffn {BGP} {redistribute connected} {}
574 Redistribute connected route to BGP process.
577 @deffn {BGP} {redistribute rip} {}
578 Redistribute RIP route to BGP process.
581 @deffn {BGP} {redistribute ospf} {}
582 Redistribute OSPF route to BGP process.
585 @deffn {BGP} {redistribute vpn} {}
586 Redistribute VNC routes to BGP process.
589 @deffn {BGP} {update-delay @var{max-delay}} {}
590 @deffnx {BGP} {update-delay @var{max-delay} @var{establish-wait}} {}
591 This feature is used to enable read-only mode on BGP process restart or when
592 BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode
593 would begin as soon as the first peer reaches Established status and a timer
594 for max-delay seconds is started.
596 During this mode BGP doesn't run any best-path or generate any updates to its
597 peers. This mode continues until:
598 1. All the configured peers, except the shutdown peers, have sent explicit EOR
599 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
600 Established is considered an implicit-EOR.
601 If the establish-wait optional value is given, then BGP will wait for
602 peers to reach established from the begining of the update-delay till the
603 establish-wait period is over, i.e. the minimum set of established peers for
604 which EOR is expected would be peers established during the establish-wait
605 window, not necessarily all the configured neighbors.
606 2. max-delay period is over.
607 On hitting any of the above two conditions, BGP resumes the decision process
608 and generates updates to its peers.
610 Default max-delay is 0, i.e. the feature is off by default.
613 @deffn {BGP} {table-map @var{route-map-name}} {}
614 This feature is used to apply a route-map on route updates from BGP to Zebra.
615 All the applicable match operations are allowed, such as match on prefix,
616 next-hop, communities, etc. Set operations for this attach-point are limited
617 to metric and next-hop only. Any operation of this feature does not affect
620 Supported for ipv4 and ipv6 address families. It works on multi-paths as well,
621 however, metric setting is based on the best-path only.
629 * BGP Peer commands::
634 @subsection Defining Peer
636 @deffn {BGP} {neighbor @var{peer} remote-as @var{asn}} {}
637 Creates a new neighbor whose remote-as is @var{asn}. @var{peer}
638 can be an IPv4 address or an IPv6 address.
642 neighbor 10.0.0.1 remote-as 2
645 In this case my router, in AS-1, is trying to peer with AS-2 at
648 This command must be the first command used when configuring a neighbor.
649 If the remote-as is not specified, @command{bgpd} will complain like this:
651 can't find neighbor 10.0.0.1
655 @node BGP Peer commands
656 @subsection BGP Peer commands
658 In a @code{router bgp} clause there are neighbor specific configurations
661 @deffn {BGP} {neighbor @var{peer} shutdown} {}
662 @deffnx {BGP} {no neighbor @var{peer} shutdown} {}
663 Shutdown the peer. We can delete the neighbor's configuration by
664 @code{no neighbor @var{peer} remote-as @var{as-number}} but all
665 configuration of the neighbor will be deleted. When you want to
666 preserve the configuration, but want to drop the BGP peer, use this
670 @deffn {BGP} {neighbor @var{peer} ebgp-multihop} {}
671 @deffnx {BGP} {no neighbor @var{peer} ebgp-multihop} {}
674 @deffn {BGP} {neighbor @var{peer} description ...} {}
675 @deffnx {BGP} {no neighbor @var{peer} description ...} {}
676 Set description of the peer.
679 @deffn {BGP} {neighbor @var{peer} version @var{version}} {}
680 Set up the neighbor's BGP version. @var{version} can be @var{4},
681 @var{4+} or @var{4-}. BGP version @var{4} is the default value used for
682 BGP peering. BGP version @var{4+} means that the neighbor supports
683 Multiprotocol Extensions for BGP-4. BGP version @var{4-} is similar but
684 the neighbor speaks the old Internet-Draft revision 00's Multiprotocol
685 Extensions for BGP-4. Some routing software is still using this
689 @deffn {BGP} {neighbor @var{peer} interface @var{ifname}} {}
690 @deffnx {BGP} {no neighbor @var{peer} interface @var{ifname}} {}
691 When you connect to a BGP peer over an IPv6 link-local address, you
692 have to specify the @var{ifname} of the interface used for the
693 connection. To specify IPv4 session addresses, see the
694 @code{neighbor @var{peer} update-source} command below.
696 This command is deprecated and may be removed in a future release. Its
697 use should be avoided.
700 @deffn {BGP} {neighbor @var{peer} next-hop-self [all]} {}
701 @deffnx {BGP} {no neighbor @var{peer} next-hop-self [all]} {}
702 This command specifies an announced route's nexthop as being equivalent
703 to the address of the bgp router if it is learned via eBGP.
704 If the optional keyword @code{all} is specified the modifiation is done
705 also for routes learned via iBGP.
708 @deffn {BGP} {neighbor @var{peer} update-source @var{<ifname|address>}} {}
709 @deffnx {BGP} {no neighbor @var{peer} update-source} {}
710 Specify the IPv4 source address to use for the @acronym{BGP} session to this
711 neighbour, may be specified as either an IPv4 address directly or
712 as an interface name (in which case the @command{zebra} daemon MUST be running
713 in order for @command{bgpd} to be able to retrieve interface state).
717 neighbor foo update-source 192.168.0.1
718 neighbor bar update-source lo0
723 @deffn {BGP} {neighbor @var{peer} default-originate} {}
724 @deffnx {BGP} {no neighbor @var{peer} default-originate} {}
725 @command{bgpd}'s default is to not announce the default route (0.0.0.0/0) even it
726 is in routing table. When you want to announce default routes to the
727 peer, use this command.
730 @deffn {BGP} {neighbor @var{peer} port @var{port}} {}
731 @deffnx {BGP} {neighbor @var{peer} port @var{port}} {}
734 @deffn {BGP} {neighbor @var{peer} send-community} {}
735 @deffnx {BGP} {neighbor @var{peer} send-community} {}
738 @deffn {BGP} {neighbor @var{peer} weight @var{weight}} {}
739 @deffnx {BGP} {no neighbor @var{peer} weight @var{weight}} {}
740 This command specifies a default @var{weight} value for the neighbor's
744 @deffn {BGP} {neighbor @var{peer} maximum-prefix @var{number}} {}
745 @deffnx {BGP} {no neighbor @var{peer} maximum-prefix @var{number}} {}
748 @deffn {BGP} {neighbor @var{peer} local-as @var{as-number}} {}
749 @deffnx {BGP} {neighbor @var{peer} local-as @var{as-number} no-prepend} {}
750 @deffnx {BGP} {neighbor @var{peer} local-as @var{as-number} no-prepend replace-as} {}
751 @deffnx {BGP} {no neighbor @var{peer} local-as} {}
752 Specify an alternate AS for this BGP process when interacting with the
753 specified peer. With no modifiers, the specified local-as is prepended to
754 the received AS_PATH when receiving routing updates from the peer, and
755 prepended to the outgoing AS_PATH (after the process local AS) when
756 transmitting local routes to the peer.
758 If the no-prepend attribute is specified, then the supplied local-as is not
759 prepended to the received AS_PATH.
761 If the replace-as attribute is specified, then only the supplied local-as is
762 prepended to the AS_PATH when transmitting local-route updates to this peer.
764 Note that replace-as can only be specified if no-prepend is.
766 This command is only allowed for eBGP peers.
769 @deffn {BGP} {neighbor @var{peer} ttl-security hops @var{number}} {}
770 @deffnx {BGP} {no neighbor @var{peer} ttl-security hops @var{number}} {}
771 This command enforces Generalized TTL Security Mechanism (GTSM), as
772 specified in RFC 5082. With this command, only neighbors that are the
773 specified number of hops away will be allowed to become neighbors. This
774 command is mututally exclusive with @command{ebgp-multihop}.
778 @subsection Peer filtering
780 @deffn {BGP} {neighbor @var{peer} distribute-list @var{name} [in|out]} {}
781 This command specifies a distribute-list for the peer. @var{direct} is
782 @samp{in} or @samp{out}.
785 @deffn {BGP command} {neighbor @var{peer} prefix-list @var{name} [in|out]} {}
788 @deffn {BGP command} {neighbor @var{peer} filter-list @var{name} [in|out]} {}
791 @deffn {BGP} {neighbor @var{peer} route-map @var{name} [in|out]} {}
792 Apply a route-map on the neighbor. @var{direct} must be @code{in} or
796 @deffn {BGP} {bgp route-reflector allow-outbound-policy} {}
797 By default, attribute modification via route-map policy out is not reflected
798 on reflected routes. This option allows the modifications to be reflected as
799 well. Once enabled, it affects all reflected routes.
802 @c -----------------------------------------------------------------------
804 @section BGP Peer Group
806 @deffn {BGP} {neighbor @var{word} peer-group} {}
807 This command defines a new peer group.
810 @deffn {BGP} {neighbor @var{peer} peer-group @var{word}} {}
811 This command bind specific peer to peer group @var{word}.
814 @node BGP Address Family
815 @section BGP Address Family
817 Multiprotocol BGP enables BGP to carry routing information for multiple
818 Network Layer protocols. BGP supports multiple Address Family
819 Identifier (AFI), namely IPv4 and IPv6. Support is also provided for
820 multiple sets of per-AFI information via Subsequent Address Family
821 Identifiers (SAFI). In addition to unicast information, VPN information
822 @cite{RFC4364} and @cite{RFC4659}, and Encapsulation information
823 @cite{RFC5512} is supported.
825 @deffn {Command} {show ip bgp vpnv4 all} {}
826 @deffnx {Command} {show ipv6 bgp vpn all} {}
827 Print active IPV4 or IPV6 routes advertised via the VPN SAFI.
830 @deffn {Command} {show ip bgp encap all} {}
831 @deffnx {Command} {show ipv6 bgp encap all} {}
832 Print active IPV4 or IPV6 routes advertised via the Encapsulation SAFI.
835 @deffn {Command} {show bgp ipv4 encap summary} {}
836 @deffnx {Command} {show bgp ipv4 vpn summary} {}
837 @deffnx {Command} {show bgp ipv6 encap summary} {}
838 @deffnx {Command} {show bgp ipv6 vpn summary} {}
839 Print a summary of neighbor connections for the specified AFI/SAFI combination.
842 @c -----------------------------------------------------------------------
843 @node Autonomous System
844 @section Autonomous System
846 The @acronym{AS,Autonomous System} number is one of the essential
847 element of BGP. BGP is a distance vector routing protocol, and the
848 AS-Path framework provides distance vector metric and loop detection to
849 BGP. @cite{RFC1930, Guidelines for creation, selection, and
850 registration of an Autonomous System (AS)} provides some background on
851 the concepts of an AS.
853 The AS number is a two octet value, ranging in value from 1 to 65535.
854 The AS numbers 64512 through 65535 are defined as private AS numbers.
855 Private AS numbers must not to be advertised in the global Internet.
858 * AS Path Regular Expression::
859 * Display BGP Routes by AS Path::
860 * AS Path Access List::
861 * Using AS Path in Route Map::
862 * Private AS Numbers::
865 @node AS Path Regular Expression
866 @subsection AS Path Regular Expression
868 AS path regular expression can be used for displaying BGP routes and
869 AS path access list. AS path regular expression is based on
870 @code{POSIX 1003.2} regular expressions. Following description is
871 just a subset of @code{POSIX} regular expression. User can use full
872 @code{POSIX} regular expression. Adding to that special character '_'
873 is added for AS path regular expression.
877 Matches any single character.
879 Matches 0 or more occurrences of pattern.
881 Matches 1 or more occurrences of pattern.
883 Match 0 or 1 occurrences of pattern.
885 Matches the beginning of the line.
887 Matches the end of the line.
889 Character @code{_} has special meanings in AS path regular expression.
890 It matches to space and comma , and AS set delimiter @{ and @} and AS
891 confederation delimiter @code{(} and @code{)}. And it also matches to
892 the beginning of the line and the end of the line. So @code{_} can be
893 used for AS value boundaries match. @code{show ip bgp regexp _7675_}
894 matches to all of BGP routes which as AS number include @var{7675}.
897 @node Display BGP Routes by AS Path
898 @subsection Display BGP Routes by AS Path
900 To show BGP routes which has specific AS path information @code{show
901 ip bgp} command can be used.
903 @deffn Command {show ip bgp regexp @var{line}} {}
904 This commands display BGP routes that matches AS path regular
905 expression @var{line}.
908 @node AS Path Access List
909 @subsection AS Path Access List
911 AS path access list is user defined AS path.
913 @deffn {Command} {ip as-path access-list @var{word} @{permit|deny@} @var{line}} {}
914 This command defines a new AS path access list.
917 @deffn {Command} {no ip as-path access-list @var{word}} {}
918 @deffnx {Command} {no ip as-path access-list @var{word} @{permit|deny@} @var{line}} {}
921 @node Using AS Path in Route Map
922 @subsection Using AS Path in Route Map
924 @deffn {Route Map} {match as-path @var{word}} {}
927 @deffn {Route Map} {set as-path prepend @var{as-path}} {}
928 Prepend the given string of AS numbers to the AS_PATH.
931 @deffn {Route Map} {set as-path prepend last-as @var{num}} {}
932 Prepend the existing last AS number (the leftmost ASN) to the AS_PATH.
935 @node Private AS Numbers
936 @subsection Private AS Numbers
938 @c -----------------------------------------------------------------------
939 @node BGP Communities Attribute
940 @section BGP Communities Attribute
942 BGP communities attribute is widely used for implementing policy
943 routing. Network operators can manipulate BGP communities attribute
944 based on their network policy. BGP communities attribute is defined
945 in @cite{RFC1997, BGP Communities Attribute} and
946 @cite{RFC1998, An Application of the BGP Community Attribute
947 in Multi-home Routing}. It is an optional transitive attribute,
948 therefore local policy can travel through different autonomous system.
950 Communities attribute is a set of communities values. Each
951 communities value is 4 octet long. The following format is used to
952 define communities value.
956 This format represents 4 octet communities value. @code{AS} is high
957 order 2 octet in digit format. @code{VAL} is low order 2 octet in
958 digit format. This format is useful to define AS oriented policy
959 value. For example, @code{7675:80} can be used when AS 7675 wants to
960 pass local policy value 80 to neighboring peer.
962 @code{internet} represents well-known communities value 0.
964 @code{no-export} represents well-known communities value @code{NO_EXPORT}@*
965 @r{(0xFFFFFF01)}. All routes carry this value must not be advertised
966 to outside a BGP confederation boundary. If neighboring BGP peer is
967 part of BGP confederation, the peer is considered as inside a BGP
968 confederation boundary, so the route will be announced to the peer.
970 @code{no-advertise} represents well-known communities value
971 @code{NO_ADVERTISE}@*@r{(0xFFFFFF02)}. All routes carry this value
972 must not be advertise to other BGP peers.
974 @code{local-AS} represents well-known communities value
975 @code{NO_EXPORT_SUBCONFED} @r{(0xFFFFFF03)}. All routes carry this
976 value must not be advertised to external BGP peers. Even if the
977 neighboring router is part of confederation, it is considered as
978 external BGP peer, so the route will not be announced to the peer.
981 When BGP communities attribute is received, duplicated communities
982 value in the communities attribute is ignored and each communities
983 values are sorted in numerical order.
986 * BGP Community Lists::
987 * Numbered BGP Community Lists::
988 * BGP Community in Route Map::
989 * Display BGP Routes by Community::
990 * Using BGP Communities Attribute::
993 @node BGP Community Lists
994 @subsection BGP Community Lists
996 BGP community list is a user defined BGP communites attribute list.
997 BGP community list can be used for matching or manipulating BGP
998 communities attribute in updates.
1000 There are two types of community list. One is standard community
1001 list and another is expanded community list. Standard community list
1002 defines communities attribute. Expanded community list defines
1003 communities attribute string with regular expression. Standard
1004 community list is compiled into binary format when user define it.
1005 Standard community list will be directly compared to BGP communities
1006 attribute in BGP updates. Therefore the comparison is faster than
1007 expanded community list.
1009 @deffn Command {ip community-list standard @var{name} @{permit|deny@} @var{community}} {}
1010 This command defines a new standard community list. @var{community}
1011 is communities value. The @var{community} is compiled into community
1012 structure. We can define multiple community list under same name. In
1013 that case match will happen user defined order. Once the
1014 community list matches to communities attribute in BGP updates it
1015 return permit or deny by the community list definition. When there is
1016 no matched entry, deny will be returned. When @var{community} is
1017 empty it matches to any routes.
1020 @deffn Command {ip community-list expanded @var{name} @{permit|deny@} @var{line}} {}
1021 This command defines a new expanded community list. @var{line} is a
1022 string expression of communities attribute. @var{line} can include
1023 regular expression to match communities attribute in BGP updates.
1026 @deffn Command {no ip community-list @var{name}} {}
1027 @deffnx Command {no ip community-list standard @var{name}} {}
1028 @deffnx Command {no ip community-list expanded @var{name}} {}
1029 These commands delete community lists specified by @var{name}. All of
1030 community lists shares a single name space. So community lists can be
1031 removed simpley specifying community lists name.
1034 @deffn {Command} {show ip community-list} {}
1035 @deffnx {Command} {show ip community-list @var{name}} {}
1036 This command display current community list information. When
1037 @var{name} is specified the specified community list's information is
1041 # show ip community-list
1042 Named Community standard list CLIST
1043 permit 7675:80 7675:100 no-export
1045 Named Community expanded list EXPAND
1048 # show ip community-list CLIST
1049 Named Community standard list CLIST
1050 permit 7675:80 7675:100 no-export
1055 @node Numbered BGP Community Lists
1056 @subsection Numbered BGP Community Lists
1058 When number is used for BGP community list name, the number has
1059 special meanings. Community list number in the range from 1 and 99 is
1060 standard community list. Community list number in the range from 100
1061 to 199 is expanded community list. These community lists are called
1062 as numbered community lists. On the other hand normal community lists
1063 is called as named community lists.
1065 @deffn Command {ip community-list <1-99> @{permit|deny@} @var{community}} {}
1066 This command defines a new community list. <1-99> is standard
1067 community list number. Community list name within this range defines
1068 standard community list. When @var{community} is empty it matches to
1072 @deffn Command {ip community-list <100-199> @{permit|deny@} @var{community}} {}
1073 This command defines a new community list. <100-199> is expanded
1074 community list number. Community list name within this range defines
1075 expanded community list.
1078 @deffn Command {ip community-list @var{name} @{permit|deny@} @var{community}} {}
1079 When community list type is not specifed, the community list type is
1080 automatically detected. If @var{community} can be compiled into
1081 communities attribute, the community list is defined as a standard
1082 community list. Otherwise it is defined as an expanded community
1083 list. This feature is left for backward compability. Use of this
1084 feature is not recommended.
1087 @node BGP Community in Route Map
1088 @subsection BGP Community in Route Map
1090 In Route Map (@pxref{Route Map}), we can match or set BGP
1091 communities attribute. Using this feature network operator can
1092 implement their network policy based on BGP communities attribute.
1094 Following commands can be used in Route Map.
1096 @deffn {Route Map} {match community @var{word}} {}
1097 @deffnx {Route Map} {match community @var{word} exact-match} {}
1098 This command perform match to BGP updates using community list
1099 @var{word}. When the one of BGP communities value match to the one of
1100 communities value in community list, it is match. When
1101 @code{exact-match} keyword is spcified, match happen only when BGP
1102 updates have completely same communities value specified in the
1106 @deffn {Route Map} {set community none} {}
1107 @deffnx {Route Map} {set community @var{community}} {}
1108 @deffnx {Route Map} {set community @var{community} additive} {}
1109 This command manipulate communities value in BGP updates. When
1110 @code{none} is specified as communities value, it removes entire
1111 communities attribute from BGP updates. When @var{community} is not
1112 @code{none}, specified communities value is set to BGP updates. If
1113 BGP updates already has BGP communities value, the existing BGP
1114 communities value is replaced with specified @var{community} value.
1115 When @code{additive} keyword is specified, @var{community} is appended
1116 to the existing communities value.
1119 @deffn {Route Map} {set comm-list @var{word} delete} {}
1120 This command remove communities value from BGP communities attribute.
1121 The @var{word} is community list name. When BGP route's communities
1122 value matches to the community list @var{word}, the communities value
1123 is removed. When all of communities value is removed eventually, the
1124 BGP update's communities attribute is completely removed.
1127 @node Display BGP Routes by Community
1128 @subsection Display BGP Routes by Community
1130 To show BGP routes which has specific BGP communities attribute,
1131 @code{show ip bgp} command can be used. The @var{community} value and
1132 community list can be used for @code{show ip bgp} command.
1134 @deffn Command {show ip bgp community} {}
1135 @deffnx Command {show ip bgp community @var{community}} {}
1136 @deffnx Command {show ip bgp community @var{community} exact-match} {}
1137 @code{show ip bgp community} displays BGP routes which has communities
1138 attribute. When @var{community} is specified, BGP routes that matches
1139 @var{community} value is displayed. For this command, @code{internet}
1140 keyword can't be used for @var{community} value. When
1141 @code{exact-match} is specified, it display only routes that have an
1145 @deffn Command {show ip bgp community-list @var{word}} {}
1146 @deffnx Command {show ip bgp community-list @var{word} exact-match} {}
1147 This commands display BGP routes that matches community list
1148 @var{word}. When @code{exact-match} is specified, display only routes
1149 that have an exact match.
1152 @node Using BGP Communities Attribute
1153 @subsection Using BGP Communities Attribute
1155 Following configuration is the most typical usage of BGP communities
1156 attribute. AS 7675 provides upstream Internet connection to AS 100.
1157 When following configuration exists in AS 7675, AS 100 networks
1158 operator can set local preference in AS 7675 network by setting BGP
1159 communities attribute to the updates.
1163 neighbor 192.168.0.1 remote-as 100
1164 neighbor 192.168.0.1 route-map RMAP in
1166 ip community-list 70 permit 7675:70
1167 ip community-list 70 deny
1168 ip community-list 80 permit 7675:80
1169 ip community-list 80 deny
1170 ip community-list 90 permit 7675:90
1171 ip community-list 90 deny
1173 route-map RMAP permit 10
1175 set local-preference 70
1177 route-map RMAP permit 20
1179 set local-preference 80
1181 route-map RMAP permit 30
1183 set local-preference 90
1186 Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675.
1187 The route has communities value 7675:80 so when above configuration
1188 exists in AS 7675, announced route's local preference will be set to
1194 neighbor 192.168.0.2 remote-as 7675
1195 neighbor 192.168.0.2 route-map RMAP out
1197 ip prefix-list PLIST permit 10.0.0.0/8
1199 route-map RMAP permit 10
1200 match ip address prefix-list PLIST
1201 set community 7675:80
1204 Following configuration is an example of BGP route filtering using
1205 communities attribute. This configuration only permit BGP routes
1206 which has BGP communities value 0:80 or 0:90. Network operator can
1207 put special internal communities value at BGP border router, then
1208 limit the BGP routes announcement into the internal network.
1212 neighbor 192.168.0.1 remote-as 100
1213 neighbor 192.168.0.1 route-map RMAP in
1215 ip community-list 1 permit 0:80 0:90
1217 route-map RMAP permit in
1221 Following exmaple filter BGP routes which has communities value 1:1.
1222 When there is no match community-list returns deny. To avoid
1223 filtering all of routes, we need to define permit any at last.
1227 neighbor 192.168.0.1 remote-as 100
1228 neighbor 192.168.0.1 route-map RMAP in
1230 ip community-list standard FILTER deny 1:1
1231 ip community-list standard FILTER permit
1233 route-map RMAP permit 10
1234 match community FILTER
1237 Communities value keyword @code{internet} has special meanings in
1238 standard community lists. In below example @code{internet} act as
1239 match any. It matches all of BGP routes even if the route does not
1240 have communities attribute at all. So community list @code{INTERNET}
1241 is same as above example's @code{FILTER}.
1244 ip community-list standard INTERNET deny 1:1
1245 ip community-list standard INTERNET permit internet
1248 Following configuration is an example of communities value deletion.
1249 With this configuration communities value 100:1 and 100:2 is removed
1250 from BGP updates. For communities value deletion, only @code{permit}
1251 community-list is used. @code{deny} community-list is ignored.
1255 neighbor 192.168.0.1 remote-as 100
1256 neighbor 192.168.0.1 route-map RMAP in
1258 ip community-list standard DEL permit 100:1 100:2
1260 route-map RMAP permit 10
1261 set comm-list DEL delete
1264 @c -----------------------------------------------------------------------
1265 @node BGP Extended Communities Attribute
1266 @section BGP Extended Communities Attribute
1268 BGP extended communities attribute is introduced with MPLS VPN/BGP
1269 technology. MPLS VPN/BGP expands capability of network infrastructure
1270 to provide VPN functionality. At the same time it requires a new
1271 framework for policy routing. With BGP Extended Communities Attribute
1272 we can use Route Target or Site of Origin for implementing network
1273 policy for MPLS VPN/BGP.
1275 BGP Extended Communities Attribute is similar to BGP Communities
1276 Attribute. It is an optional transitive attribute. BGP Extended
1277 Communities Attribute can carry multiple Extended Community value.
1278 Each Extended Community value is eight octet length.
1280 BGP Extended Communities Attribute provides an extended range
1281 compared with BGP Communities Attribute. Adding to that there is a
1282 type field in each value to provides community space structure.
1284 There are two format to define Extended Community value. One is AS
1285 based format the other is IP address based format.
1289 This is a format to define AS based Extended Community value.
1290 @code{AS} part is 2 octets Global Administrator subfield in Extended
1291 Community value. @code{VAL} part is 4 octets Local Administrator
1292 subfield. @code{7675:100} represents AS 7675 policy value 100.
1293 @item IP-Address:VAL
1294 This is a format to define IP address based Extended Community value.
1295 @code{IP-Address} part is 4 octets Global Administrator subfield.
1296 @code{VAL} part is 2 octets Local Administrator subfield.
1297 @code{10.0.0.1:100} represents
1301 * BGP Extended Community Lists::
1302 * BGP Extended Communities in Route Map::
1305 @node BGP Extended Community Lists
1306 @subsection BGP Extended Community Lists
1308 Expanded Community Lists is a user defined BGP Expanded Community
1311 @deffn Command {ip extcommunity-list standard @var{name} @{permit|deny@} @var{extcommunity}} {}
1312 This command defines a new standard extcommunity-list.
1313 @var{extcommunity} is extended communities value. The
1314 @var{extcommunity} is compiled into extended community structure. We
1315 can define multiple extcommunity-list under same name. In that case
1316 match will happen user defined order. Once the extcommunity-list
1317 matches to extended communities attribute in BGP updates it return
1318 permit or deny based upon the extcommunity-list definition. When
1319 there is no matched entry, deny will be returned. When
1320 @var{extcommunity} is empty it matches to any routes.
1323 @deffn Command {ip extcommunity-list expanded @var{name} @{permit|deny@} @var{line}} {}
1324 This command defines a new expanded extcommunity-list. @var{line} is
1325 a string expression of extended communities attribute. @var{line} can
1326 include regular expression to match extended communities attribute in
1330 @deffn Command {no ip extcommunity-list @var{name}} {}
1331 @deffnx Command {no ip extcommunity-list standard @var{name}} {}
1332 @deffnx Command {no ip extcommunity-list expanded @var{name}} {}
1333 These commands delete extended community lists specified by
1334 @var{name}. All of extended community lists shares a single name
1335 space. So extended community lists can be removed simpley specifying
1339 @deffn {Command} {show ip extcommunity-list} {}
1340 @deffnx {Command} {show ip extcommunity-list @var{name}} {}
1341 This command display current extcommunity-list information. When
1342 @var{name} is specified the community list's information is shown.
1345 # show ip extcommunity-list
1349 @node BGP Extended Communities in Route Map
1350 @subsection BGP Extended Communities in Route Map
1352 @deffn {Route Map} {match extcommunity @var{word}} {}
1355 @deffn {Route Map} {set extcommunity rt @var{extcommunity}} {}
1356 This command set Route Target value.
1359 @deffn {Route Map} {set extcommunity soo @var{extcommunity}} {}
1360 This command set Site of Origin value.
1363 @c -----------------------------------------------------------------------
1364 @node BGP Large Communities Attribute
1365 @section BGP Large Communities Attribute
1367 The BGP Large Communities attribute was introduced in Feb 2017 with
1368 @cite{RFC8092, BGP Large Communities Attribute}.
1370 The BGP Large Communities Attribute is similar to the BGP Communities
1371 Attribute except that it has 3 components instead of two and each of
1372 which are 4 octets in length. Large Communities bring additional
1373 functionality and convenience over traditional communities, specifically
1374 the fact that the @code{GLOBAL} part below is now 4 octets wide allowing
1375 AS4 operators seamless use.
1378 @item GLOBAL:LOCAL1:LOCAL2
1379 This is the format to define Large Community values. Referencing
1380 @cite{RFC8195, Use of BGP Large Communities} the values are commonly
1381 referred to as follows.
1382 The @code{GLOBAL} part is a 4 octet Global Administrator field, common
1383 use of this field is the operators AS number.
1384 The @code{LOCAL1} part is a 4 octet Local Data Part 1 subfield referred
1386 The @code{LOCAL2} part is a 4 octet Local Data Part 2 field and referred
1387 to as the parameter subfield. @code{65551:1:10} represents AS 65551
1388 function 1 and parameter 10.
1389 The referenced RFC above gives some guidelines on recommended usage.
1393 * BGP Large Community Lists::
1394 * BGP Large Communities in Route Map::
1397 @node BGP Large Community Lists
1398 @subsection BGP Large Community Lists
1400 Two types of large community lists are supported, namely @code{standard} and
1403 @deffn Command {ip large-community-list standard @var{name} @{permit|deny@} @var{large-community}} {}
1404 This command defines a new standard large-community-list.
1405 @var{large-community} is the Large Community value. We
1406 can add multiple large communities under same name. In that case
1407 the match will happen in the user defined order. Once the large-community-list
1408 matches the Large Communities attribute in BGP updates it will return
1409 permit or deny based upon the large-community-list definition. When
1410 there is no matched entry, a deny will be returned. When @var{large-community}
1411 is empty it matches any routes.
1414 @deffn Command {ip large-community-list expanded @var{name} @{permit|deny@} @var{line}} {}
1415 This command defines a new expanded large-community-list. Where @var{line} is
1416 a string matching expression, it will be compared to the entire Large Communities
1417 attribute as a string, with each large-community in order from lowest to highest.
1418 @var{line} can also be a regular expression which matches this Large
1419 Community attribute.
1422 @deffn Command {no ip large-community-list @var{name}} {}
1423 @deffnx Command {no ip large-community-list standard @var{name}} {}
1424 @deffnx Command {no ip large-community-list expanded @var{name}} {}
1425 These commands delete Large Community lists specified by
1426 @var{name}. All Large Community lists share a single namespace.
1427 This means Large Community lists can be removed by simply specifying the name.
1430 @deffn {Command} {show ip large-community-list} {}
1431 @deffnx {Command} {show ip large-community-list @var{name}} {}
1432 This command display current large-community-list information. When
1433 @var{name} is specified the community list information is shown.
1436 @deffn {Command} {show ip bgp large-community-info} {}
1437 This command displays the current large communities in use.
1440 @node BGP Large Communities in Route Map
1441 @subsection BGP Large Communities in Route Map
1443 @deffn {Route Map} {match large-community @var{line}} {}
1444 Where @var{line} can be a simple string to match, or a regular expression.
1445 It is very important to note that this match occurs on the entire
1446 large-community string as a whole, where each large-community is ordered
1447 from lowest to highest.
1450 @deffn {Route Map} {set large-community @var{large-community}} {}
1451 @deffnx {Route Map} {set large-community @var{large-community} @var{large-community}} {}
1452 @deffnx {Route Map} {set large-community @var{large-community} additive} {}
1453 These commands are used for setting large-community values. The first
1454 command will overwrite any large-communities currently present.
1455 The second specifies two large-communities, which overwrites the current
1456 large-community list. The third will add a large-community value without
1457 overwriting other values. Multiple large-community values can be specified.
1460 @c -----------------------------------------------------------------------
1462 @node Displaying BGP routes
1463 @section Displaying BGP Routes
1467 * More Show IP BGP::
1471 @subsection Show IP BGP
1473 @deffn {Command} {show ip bgp} {}
1474 @deffnx {Command} {show ip bgp @var{A.B.C.D}} {}
1475 @deffnx {Command} {show ip bgp @var{X:X::X:X}} {}
1476 This command displays BGP routes. When no route is specified it
1477 display all of IPv4 BGP routes.
1481 BGP table version is 0, local router ID is 10.1.1.1
1482 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
1483 Origin codes: i - IGP, e - EGP, ? - incomplete
1485 Network Next Hop Metric LocPrf Weight Path
1486 *> 1.1.1.1/32 0.0.0.0 0 32768 i
1488 Total number of prefixes 1
1491 @node More Show IP BGP
1492 @subsection More Show IP BGP
1494 @deffn {Command} {show ip bgp regexp @var{line}} {}
1495 This command display BGP routes using AS path regular expression (@pxref{Display BGP Routes by AS Path}).
1498 @deffn Command {show ip bgp community @var{community}} {}
1499 @deffnx Command {show ip bgp community @var{community} exact-match} {}
1500 This command display BGP routes using @var{community} (@pxref{Display
1501 BGP Routes by Community}).
1504 @deffn Command {show ip bgp community-list @var{word}} {}
1505 @deffnx Command {show ip bgp community-list @var{word} exact-match} {}
1506 This command display BGP routes using community list (@pxref{Display
1507 BGP Routes by Community}).
1510 @deffn {Command} {show ip bgp summary} {}
1513 @deffn {Command} {show ip bgp neighbor [@var{peer}]} {}
1516 @deffn {Command} {clear ip bgp @var{peer}} {}
1517 Clear peers which have addresses of X.X.X.X
1520 @deffn {Command} {clear ip bgp @var{peer} soft in} {}
1521 Clear peer using soft reconfiguration.
1524 @deffn {Command} {show ip bgp dampened-paths} {}
1525 Display paths suppressed due to dampening
1528 @deffn {Command} {show ip bgp flap-statistics} {}
1529 Display flap statistics of routes
1532 @deffn {Command} {show debug} {}
1535 @deffn {Command} {debug event} {}
1538 @deffn {Command} {debug update} {}
1541 @deffn {Command} {debug keepalive} {}
1544 @deffn {Command} {no debug event} {}
1547 @deffn {Command} {no debug update} {}
1550 @deffn {Command} {no debug keepalive} {}
1553 @node Capability Negotiation
1554 @section Capability Negotiation
1556 When adding IPv6 routing information exchange feature to BGP. There
1557 were some proposals. @acronym{IETF,Internet Engineering Task Force}
1558 @acronym{IDR, Inter Domain Routing} @acronym{WG, Working group} adopted
1559 a proposal called Multiprotocol Extension for BGP. The specification
1560 is described in @cite{RFC2283}. The protocol does not define new protocols.
1561 It defines new attributes to existing BGP. When it is used exchanging
1562 IPv6 routing information it is called BGP-4+. When it is used for
1563 exchanging multicast routing information it is called MBGP.
1565 @command{bgpd} supports Multiprotocol Extension for BGP. So if remote
1566 peer supports the protocol, @command{bgpd} can exchange IPv6 and/or
1567 multicast routing information.
1569 Traditional BGP did not have the feature to detect remote peer's
1570 capabilities, e.g. whether it can handle prefix types other than IPv4
1571 unicast routes. This was a big problem using Multiprotocol Extension
1572 for BGP to operational network. @cite{RFC2842, Capabilities
1573 Advertisement with BGP-4} adopted a feature called Capability
1574 Negotiation. @command{bgpd} use this Capability Negotiation to detect
1575 the remote peer's capabilities. If the peer is only configured as IPv4
1576 unicast neighbor, @command{bgpd} does not send these Capability
1577 Negotiation packets (at least not unless other optional BGP features
1578 require capability negotation).
1580 By default, Frr will bring up peering with minimal common capability
1581 for the both sides. For example, local router has unicast and
1582 multicast capabilitie and remote router has unicast capability. In
1583 this case, the local router will establish the connection with unicast
1584 only capability. When there are no common capabilities, Frr sends
1585 Unsupported Capability error and then resets the connection.
1587 If you want to completely match capabilities with remote peer. Please
1588 use @command{strict-capability-match} command.
1590 @deffn {BGP} {neighbor @var{peer} strict-capability-match} {}
1591 @deffnx {BGP} {no neighbor @var{peer} strict-capability-match} {}
1592 Strictly compares remote capabilities and local capabilities. If capabilities
1593 are different, send Unsupported Capability error then reset connection.
1596 You may want to disable sending Capability Negotiation OPEN message
1597 optional parameter to the peer when remote peer does not implement
1598 Capability Negotiation. Please use @command{dont-capability-negotiate}
1599 command to disable the feature.
1601 @deffn {BGP} {neighbor @var{peer} dont-capability-negotiate} {}
1602 @deffnx {BGP} {no neighbor @var{peer} dont-capability-negotiate} {}
1603 Suppress sending Capability Negotiation as OPEN message optional
1604 parameter to the peer. This command only affects the peer is configured
1605 other than IPv4 unicast configuration.
1608 When remote peer does not have capability negotiation feature, remote
1609 peer will not send any capabilities at all. In that case, bgp
1610 configures the peer with configured capabilities.
1612 You may prefer locally configured capabilities more than the negotiated
1613 capabilities even though remote peer sends capabilities. If the peer
1614 is configured by @command{override-capability}, @command{bgpd} ignores
1615 received capabilities then override negotiated capabilities with
1618 @deffn {BGP} {neighbor @var{peer} override-capability} {}
1619 @deffnx {BGP} {no neighbor @var{peer} override-capability} {}
1620 Override the result of Capability Negotiation with local configuration.
1621 Ignore remote peer's capability value.
1624 @node Route Reflector
1625 @section Route Reflector
1627 @deffn {BGP} {bgp cluster-id @var{a.b.c.d}} {}
1630 @deffn {BGP} {neighbor @var{peer} route-reflector-client} {}
1631 @deffnx {BGP} {no neighbor @var{peer} route-reflector-client} {}
1635 @section Route Server
1637 At an Internet Exchange point, many ISPs are connected to each other by
1638 external BGP peering. Normally these external BGP connection are done by
1639 @samp{full mesh} method. As with internal BGP full mesh formation,
1640 this method has a scaling problem.
1642 This scaling problem is well known. Route Server is a method to resolve
1643 the problem. Each ISP's BGP router only peers to Route Server. Route
1644 Server serves as BGP information exchange to other BGP routers. By
1645 applying this method, numbers of BGP connections is reduced from
1646 O(n*(n-1)/2) to O(n).
1648 Unlike normal BGP router, Route Server must have several routing tables
1649 for managing different routing policies for each BGP speaker. We call the
1650 routing tables as different @code{view}s. @command{bgpd} can work as
1651 normal BGP router or Route Server or both at the same time.
1654 * Multiple instance::
1655 * BGP instance and view::
1657 * Viewing the view::
1660 @node Multiple instance
1661 @subsection Multiple instance
1663 To enable multiple view function of @code{bgpd}, you must turn on
1664 multiple instance feature beforehand.
1666 @deffn {Command} {bgp multiple-instance} {}
1667 Enable BGP multiple instance feature. After this feature is enabled,
1668 you can make multiple BGP instances or multiple BGP views.
1671 @deffn {Command} {no bgp multiple-instance} {}
1672 Disable BGP multiple instance feature. You can not disable this feature
1673 when BGP multiple instances or views exist.
1676 When you want to make configuration more Cisco like one,
1678 @deffn {Command} {bgp config-type cisco} {}
1679 Cisco compatible BGP configuration output.
1682 When bgp config-type cisco is specified,
1684 ``no synchronization'' is displayed.
1685 ``no auto-summary'' is displayed.
1687 ``network'' and ``aggregate-address'' argument is displayed as
1690 Frr: network 10.0.0.0/8
1691 Cisco: network 10.0.0.0
1693 Frr: aggregate-address 192.168.0.0/24
1694 Cisco: aggregate-address 192.168.0.0 255.255.255.0
1696 Community attribute handling is also different. If there is no
1697 configuration is specified community attribute and extended community
1698 attribute are sent to neighbor. When user manually disable the
1699 feature community attribute is not sent to the neighbor. In case of
1700 @command{bgp config-type cisco} is specified, community attribute is not
1701 sent to the neighbor by default. To send community attribute user has
1702 to specify @command{neighbor A.B.C.D send-community} command.
1707 neighbor 10.0.0.1 remote-as 1
1708 no neighbor 10.0.0.1 send-community
1711 neighbor 10.0.0.1 remote-as 1
1712 neighbor 10.0.0.1 send-community
1716 @deffn {Command} {bgp config-type zebra} {}
1717 Frr style BGP configuration. This is default.
1720 @node BGP instance and view
1721 @subsection BGP instance and view
1723 BGP instance is a normal BGP process. The result of route selection
1724 goes to the kernel routing table. You can setup different AS at the
1725 same time when BGP multiple instance feature is enabled.
1727 @deffn {Command} {router bgp @var{as-number}} {}
1728 Make a new BGP instance. You can use arbitrary word for the @var{name}.
1733 bgp multiple-instance
1736 neighbor 10.0.0.1 remote-as 2
1737 neighbor 10.0.0.2 remote-as 3
1740 neighbor 10.0.0.3 remote-as 4
1741 neighbor 10.0.0.4 remote-as 5
1745 BGP view is almost same as normal BGP process. The result of
1746 route selection does not go to the kernel routing table. BGP view is
1747 only for exchanging BGP routing information.
1749 @deffn {Command} {router bgp @var{as-number} view @var{name}} {}
1750 Make a new BGP view. You can use arbitrary word for the @var{name}. This
1751 view's route selection result does not go to the kernel routing table.
1754 With this command, you can setup Route Server like below.
1758 bgp multiple-instance
1761 neighbor 10.0.0.1 remote-as 2
1762 neighbor 10.0.0.2 remote-as 3
1765 neighbor 10.0.0.3 remote-as 4
1766 neighbor 10.0.0.4 remote-as 5
1770 @node Routing policy
1771 @subsection Routing policy
1773 You can set different routing policy for a peer. For example, you can
1774 set different filter for a peer.
1778 bgp multiple-instance
1781 neighbor 10.0.0.1 remote-as 2
1782 neighbor 10.0.0.1 distribute-list 1 in
1785 neighbor 10.0.0.1 remote-as 2
1786 neighbor 10.0.0.1 distribute-list 2 in
1790 This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view
1791 2. When the update is inserted into view 1, distribute-list 1 is
1792 applied. On the other hand, when the update is inserted into view 2,
1793 distribute-list 2 is applied.
1795 @node Viewing the view
1796 @subsection Viewing the view
1798 To display routing table of BGP view, you must specify view name.
1800 @deffn {Command} {show ip bgp view @var{name}} {}
1801 Display routing table of BGP view @var{name}.
1804 @node How to set up a 6-Bone connection
1805 @section How to set up a 6-Bone connection
1813 ! Actually there is no need to configure zebra
1819 ! This means that routes go through zebra and into the kernel.
1823 ! MP-BGP configuration
1826 bgp router-id 10.0.0.1
1827 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as @var{as-number}
1830 network 3ffe:506::/32
1831 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
1832 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
1833 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as @var{as-number}
1834 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
1837 ipv6 access-list all permit any
1839 ! Set output nexthop address.
1841 route-map set-nexthop permit 10
1842 match ipv6 address all
1843 set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
1844 set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
1846 ! logfile FILENAME is obsolete. Please use log file FILENAME
1853 @node Dump BGP packets and table
1854 @section Dump BGP packets and table
1856 @deffn Command {dump bgp all @var{path} [@var{interval}]} {}
1857 @deffnx Command {dump bgp all-et @var{path} [@var{interval}]} {}
1858 @deffnx Command {no dump bgp all [@var{path}] [@var{interval}]} {}
1859 Dump all BGP packet and events to @var{path} file.
1860 If @var{interval} is set, a new file will be created for echo @var{interval} of seconds.
1861 The path @var{path} can be set with date and time formatting (strftime).
1862 The type ‘all-et’ enables support for Extended Timestamp Header (@pxref{Packet Binary Dump Format}).
1863 (@pxref{Packet Binary Dump Format})
1866 @deffn Command {dump bgp updates @var{path} [@var{interval}]} {}
1867 @deffnx Command {dump bgp updates-et @var{path} [@var{interval}]} {}
1868 @deffnx Command {no dump bgp updates [@var{path}] [@var{interval}]} {}
1869 Dump only BGP updates messages to @var{path} file.
1870 If @var{interval} is set, a new file will be created for echo @var{interval} of seconds.
1871 The path @var{path} can be set with date and time formatting (strftime).
1872 The type ‘updates-et’ enables support for Extended Timestamp Header (@pxref{Packet Binary Dump Format}).
1875 @deffn Command {dump bgp routes-mrt @var{path}} {}
1876 @deffnx Command {dump bgp routes-mrt @var{path} @var{interval}} {}
1877 @deffnx Command {no dump bgp route-mrt [@var{path}] [@var{interval}]} {}
1878 Dump whole BGP routing table to @var{path}. This is heavy process.
1879 The path @var{path} can be set with date and time formatting (strftime).
1880 If @var{interval} is set, a new file will be created for echo @var{interval} of seconds.
1883 Note: the interval variable can also be set using hours and minutes: 04h20m00.
1886 @node BGP Configuration Examples
1887 @section BGP Configuration Examples
1889 Example of a session to an upstream, advertising only one prefix to it.
1893 bgp router-id 10.236.87.1
1894 network 10.236.87.0/24
1895 neighbor upstream peer-group
1896 neighbor upstream remote-as 64515
1897 neighbor upstream capability dynamic
1898 neighbor upstream prefix-list pl-allowed-adv out
1899 neighbor 10.1.1.1 peer-group upstream
1900 neighbor 10.1.1.1 description ACME ISP
1902 ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
1903 ip prefix-list pl-allowed-adv seq 10 deny any
1907 A more complex example. With upstream, peer and customer sessions.
1908 Advertising global prefixes and NO_EXPORT prefixes and providing
1909 actions for customer routes based on community values. Extensive use of
1910 route-maps and the 'call' feature to support selective advertising of
1911 prefixes. This example is intended as guidance only, it has NOT been
1912 tested and almost certainly containts silly mistakes, if not serious
1917 bgp router-id 10.236.87.1
1918 network 10.123.456.0/24
1919 network 10.123.456.128/25 route-map rm-no-export
1920 neighbor upstream capability dynamic
1921 neighbor upstream route-map rm-upstream-out out
1922 neighbor cust capability dynamic
1923 neighbor cust route-map rm-cust-in in
1924 neighbor cust route-map rm-cust-out out
1925 neighbor cust send-community both
1926 neighbor peer capability dynamic
1927 neighbor peer route-map rm-peer-in in
1928 neighbor peer route-map rm-peer-out out
1929 neighbor peer send-community both
1930 neighbor 10.1.1.1 remote-as 64515
1931 neighbor 10.1.1.1 peer-group upstream
1932 neighbor 10.2.1.1 remote-as 64516
1933 neighbor 10.2.1.1 peer-group upstream
1934 neighbor 10.3.1.1 remote-as 64517
1935 neighbor 10.3.1.1 peer-group cust-default
1936 neighbor 10.3.1.1 description customer1
1937 neighbor 10.3.1.1 prefix-list pl-cust1-network in
1938 neighbor 10.4.1.1 remote-as 64518
1939 neighbor 10.4.1.1 peer-group cust
1940 neighbor 10.4.1.1 prefix-list pl-cust2-network in
1941 neighbor 10.4.1.1 description customer2
1942 neighbor 10.5.1.1 remote-as 64519
1943 neighbor 10.5.1.1 peer-group peer
1944 neighbor 10.5.1.1 prefix-list pl-peer1-network in
1945 neighbor 10.5.1.1 description peer AS 1
1946 neighbor 10.6.1.1 remote-as 64520
1947 neighbor 10.6.1.1 peer-group peer
1948 neighbor 10.6.1.1 prefix-list pl-peer2-network in
1949 neighbor 10.6.1.1 description peer AS 2
1951 ip prefix-list pl-default permit 0.0.0.0/0
1953 ip prefix-list pl-upstream-peers permit 10.1.1.1/32
1954 ip prefix-list pl-upstream-peers permit 10.2.1.1/32
1956 ip prefix-list pl-cust1-network permit 10.3.1.0/24
1957 ip prefix-list pl-cust1-network permit 10.3.2.0/24
1959 ip prefix-list pl-cust2-network permit 10.4.1.0/24
1961 ip prefix-list pl-peer1-network permit 10.5.1.0/24
1962 ip prefix-list pl-peer1-network permit 10.5.2.0/24
1963 ip prefix-list pl-peer1-network permit 192.168.0.0/24
1965 ip prefix-list pl-peer2-network permit 10.6.1.0/24
1966 ip prefix-list pl-peer2-network permit 10.6.2.0/24
1967 ip prefix-list pl-peer2-network permit 192.168.1.0/24
1968 ip prefix-list pl-peer2-network permit 192.168.2.0/24
1969 ip prefix-list pl-peer2-network permit 172.16.1/24
1971 ip as-path access-list asp-own-as permit ^$
1972 ip as-path access-list asp-own-as permit _64512_
1974 ! #################################################################
1975 ! Match communities we provide actions for, on routes receives from
1976 ! customers. Communities values of <our-ASN>:X, with X, have actions:
1978 ! 100 - blackhole the prefix
1979 ! 200 - set no_export
1980 ! 300 - advertise only to other customers
1981 ! 400 - advertise only to upstreams
1982 ! 500 - set no_export when advertising to upstreams
1983 ! 2X00 - set local_preference to X00
1985 ! blackhole the prefix of the route
1986 ip community-list standard cm-blackhole permit 64512:100
1988 ! set no-export community before advertising
1989 ip community-list standard cm-set-no-export permit 64512:200
1991 ! advertise only to other customers
1992 ip community-list standard cm-cust-only permit 64512:300
1994 ! advertise only to upstreams
1995 ip community-list standard cm-upstream-only permit 64512:400
1997 ! advertise to upstreams with no-export
1998 ip community-list standard cm-upstream-noexport permit 64512:500
2000 ! set local-pref to least significant 3 digits of the community
2001 ip community-list standard cm-prefmod-100 permit 64512:2100
2002 ip community-list standard cm-prefmod-200 permit 64512:2200
2003 ip community-list standard cm-prefmod-300 permit 64512:2300
2004 ip community-list standard cm-prefmod-400 permit 64512:2400
2005 ip community-list expanded cme-prefmod-range permit 64512:2...
2007 ! Informational communities
2009 ! 3000 - learned from upstream
2010 ! 3100 - learned from customer
2011 ! 3200 - learned from peer
2013 ip community-list standard cm-learnt-upstream permit 64512:3000
2014 ip community-list standard cm-learnt-cust permit 64512:3100
2015 ip community-list standard cm-learnt-peer permit 64512:3200
2017 ! ###################################################################
2018 ! Utility route-maps
2020 ! These utility route-maps generally should not used to permit/deny
2021 ! routes, i.e. they do not have meaning as filters, and hence probably
2022 ! should be used with 'on-match next'. These all finish with an empty
2023 ! permit entry so as not interfere with processing in the caller.
2025 route-map rm-no-export permit 10
2026 set community additive no-export
2027 route-map rm-no-export permit 20
2029 route-map rm-blackhole permit 10
2030 description blackhole, up-pref and ensure it cant escape this AS
2031 set ip next-hop 127.0.0.1
2032 set local-preference 10
2033 set community additive no-export
2034 route-map rm-blackhole permit 20
2036 ! Set local-pref as requested
2037 route-map rm-prefmod permit 10
2038 match community cm-prefmod-100
2039 set local-preference 100
2040 route-map rm-prefmod permit 20
2041 match community cm-prefmod-200
2042 set local-preference 200
2043 route-map rm-prefmod permit 30
2044 match community cm-prefmod-300
2045 set local-preference 300
2046 route-map rm-prefmod permit 40
2047 match community cm-prefmod-400
2048 set local-preference 400
2049 route-map rm-prefmod permit 50
2051 ! Community actions to take on receipt of route.
2052 route-map rm-community-in permit 10
2053 description check for blackholing, no point continuing if it matches.
2054 match community cm-blackhole
2056 route-map rm-community-in permit 20
2057 match community cm-set-no-export
2060 route-map rm-community-in permit 30
2061 match community cme-prefmod-range
2063 route-map rm-community-in permit 40
2065 ! #####################################################################
2066 ! Community actions to take when advertising a route.
2067 ! These are filtering route-maps,
2069 ! Deny customer routes to upstream with cust-only set.
2070 route-map rm-community-filt-to-upstream deny 10
2071 match community cm-learnt-cust
2072 match community cm-cust-only
2073 route-map rm-community-filt-to-upstream permit 20
2075 ! Deny customer routes to other customers with upstream-only set.
2076 route-map rm-community-filt-to-cust deny 10
2077 match community cm-learnt-cust
2078 match community cm-upstream-only
2079 route-map rm-community-filt-to-cust permit 20
2081 ! ###################################################################
2082 ! The top-level route-maps applied to sessions. Further entries could
2083 ! be added obviously..
2086 route-map rm-cust-in permit 10
2087 call rm-community-in
2089 route-map rm-cust-in permit 20
2090 set community additive 64512:3100
2091 route-map rm-cust-in permit 30
2093 route-map rm-cust-out permit 10
2094 call rm-community-filt-to-cust
2096 route-map rm-cust-out permit 20
2098 ! Upstream transit ASes
2099 route-map rm-upstream-out permit 10
2100 description filter customer prefixes which are marked cust-only
2101 call rm-community-filt-to-upstream
2103 route-map rm-upstream-out permit 20
2104 description only customer routes are provided to upstreams/peers
2105 match community cm-learnt-cust
2108 ! outbound policy is same as for upstream
2109 route-map rm-peer-out permit 10
2110 call rm-upstream-out
2112 route-map rm-peer-in permit 10
2113 set community additive 64512:3200