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 information::
33 * Capability Negotiation::
36 * BGP Regular Expressions::
37 * How to set up a 6-Bone connection::
38 * Dump BGP packets and table::
39 * BGP Configuration Examples::
45 Default configuration file of @command{bgpd} is @file{bgpd.conf}.
46 @command{bgpd} searches the current directory first then
47 @value{INSTALL_PREFIX_ETC}/bgpd.conf. All of bgpd's command must be
48 configured in @file{bgpd.conf}.
50 @command{bgpd} specific invocation options are described below. Common
51 options may also be specified (@pxref{Common Invocation Options}).
55 @itemx --bgp_port=@var{PORT}
56 Set the bgp protocol's port number.
60 When program terminates, retain BGP routes added by zebra.
64 Specify a specific IP address for bgpd to listen on, rather than its
65 default of INADDR_ANY / IN6ADDR_ANY. This can be useful to constrain bgpd
66 to an internal address, or to run multiple bgpd processes on one host.
73 First of all you must configure BGP router with @command{router bgp}
74 command. To configure BGP router, you need AS number. AS number is an
75 identification of autonomous system. BGP protocol uses the AS number
76 for detecting whether the BGP connection is internal one or external one.
78 @deffn Command {router bgp @var{asn}} {}
79 Enable a BGP protocol process with the specified @var{asn}. After
80 this statement you can input any @code{BGP Commands}. You can not
81 create different BGP process under different @var{asn} without
82 specifying @code{multiple-instance} (@pxref{Multiple instance}).
85 @deffn Command {no router bgp @var{asn}} {}
86 Destroy a BGP protocol process with the specified @var{asn}.
89 @deffn {BGP} {bgp router-id @var{A.B.C.D}} {}
90 This command specifies the router-ID. If @command{bgpd} connects to @command{zebra} it gets
91 interface and address information. In that case default router ID value
92 is selected as the largest IP Address of the interfaces. When
93 @code{router zebra} is not enabled @command{bgpd} can't get interface information
94 so @code{router-id} is set to 0.0.0.0. So please set router-id by hand.
99 * BGP decision process::
100 * BGP route flap dampening::
104 @subsection BGP distance
106 @deffn {BGP} {distance bgp <1-255> <1-255> <1-255>} {}
107 This command change distance value of BGP. Each argument is distance
108 value for external routes, internal routes and local routes.
111 @deffn {BGP} {distance <1-255> @var{A.B.C.D/M}} {}
112 @deffnx {BGP} {distance <1-255> @var{A.B.C.D/M} @var{word}} {}
113 This command set distance value to
116 @node BGP decision process
117 @subsection BGP decision process
119 The decision process Frr BGP uses to select routes is as follows:
122 @item 1. Weight check
123 prefer higher local weight routes to lower routes.
125 @item 2. Local preference check
126 prefer higher local preference routes to lower.
128 @item 3. Local route check
129 Prefer local routes (statics, aggregates, redistributed) to received routes.
131 @item 4. AS path length check
132 Prefer shortest hop-count AS_PATHs.
134 @item 5. Origin check
135 Prefer the lowest origin type route. That is, prefer IGP origin routes to
136 EGP, to Incomplete routes.
139 Where routes with a MED were received from the same AS,
140 prefer the route with the lowest MED. @xref{BGP MED}.
142 @item 7. External check
143 Prefer the route received from an external, eBGP peer
144 over routes received from other types of peers.
146 @item 8. IGP cost check
147 Prefer the route with the lower IGP cost.
149 @item 9. Multi-path check
150 If multi-pathing is enabled, then check whether
151 the routes not yet distinguished in preference may be considered equal. If
152 @ref{bgp bestpath as-path multipath-relax} is set, all such routes are
153 considered equal, otherwise routes received via iBGP with identical AS_PATHs
154 or routes received from eBGP neighbours in the same AS are considered equal.
156 @item 10 Already-selected external check
158 Where both routes were received from eBGP peers, then prefer the route which
159 is already selected. Note that this check is not applied if @ref{bgp
160 bestpath compare-routerid} is configured. This check can prevent some cases
163 @item 11. Router-ID check
164 Prefer the route with the lowest @w{router-ID}. If the
165 route has an @w{ORIGINATOR_ID} attribute, through iBGP reflection, then that
166 router ID is used, otherwise the @w{router-ID} of the peer the route was
167 received from is used.
169 @item 12. Cluster-List length check
170 The route with the shortest cluster-list
171 length is used. The cluster-list reflects the iBGP reflection path the
174 @item 13. Peer address
175 Prefer the route received from the peer with the higher
176 transport layer address, as a last-resort tie-breaker.
180 @deffn {BGP} {bgp bestpath as-path confed} {}
181 This command specifies that the length of confederation path sets and
182 sequences should should be taken into account during the BGP best path
186 @deffn {BGP} {bgp bestpath as-path multipath-relax} {}
187 @anchor{bgp bestpath as-path multipath-relax}
188 This command specifies that BGP decision process should consider paths
189 of equal AS_PATH length candidates for multipath computation. Without
190 the knob, the entire AS_PATH must match for multipath computation.
193 @deffn {BGP} {bgp bestpath compare-routerid} {}
194 @anchor{bgp bestpath compare-routerid}
196 Ensure that when comparing routes where both are equal on most metrics,
197 including local-pref, AS_PATH length, IGP cost, MED, that the tie is broken
200 If this option is enabled, then the already-selected check, where
201 already selected eBGP routes are preferred, is skipped.
203 If a route has an @w{ORIGINATOR_ID} attribute because it has been reflected,
204 that @w{ORIGINATOR_ID} will be used. Otherwise, the router-ID of the peer the
205 route was received from will be used.
207 The advantage of this is that the route-selection (at this point) will be
208 more deterministic. The disadvantage is that a few or even one lowest-ID
209 router may attract all trafic to otherwise-equal paths because of this
210 check. It may increase the possibility of MED or IGP oscillation, unless
211 other measures were taken to avoid these. The exact behaviour will be
212 sensitive to the iBGP and reflection topology.
217 @node BGP route flap dampening
218 @subsection BGP route flap dampening
220 @deffn {BGP} {bgp dampening @var{<1-45>} @var{<1-20000>} @var{<1-20000>} @var{<1-255>}} {}
221 This command enables BGP route-flap dampening and specifies dampening parameters.
224 @item @asis{half-life}
225 Half-life time for the penalty
226 @item @asis{reuse-threshold}
227 Value to start reusing a route
228 @item @asis{suppress-threshold}
229 Value to start suppressing a route
230 @item @asis{max-suppress}
231 Maximum duration to suppress a stable route
234 The route-flap damping algorithm is compatible with @cite{RFC2439}. The use of this command
235 is not recommended nowadays, see @uref{http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378}.
241 The BGP MED (Multi_Exit_Discriminator) attribute has properties which can
242 cause subtle convergence problems in BGP. These properties and problems
243 have proven to be hard to understand, at least historically, and may still
244 not be widely understood. The following attempts to collect together and
245 present what is known about MED, to help operators and Frr users in
246 designing and configuring their networks.
248 The BGP @acronym{MED, Multi_Exit_Discriminator} attribute is intended to
249 allow one AS to indicate its preferences for its ingress points to another
250 AS. The MED attribute will not be propagated on to another AS by the
251 receiving AS - it is `non-transitive' in the BGP sense.
253 E.g., if AS X and AS Y have 2 different BGP peering points, then AS X
254 might set a MED of 100 on routes advertised at one and a MED of 200 at the
255 other. When AS Y selects between otherwise equal routes to or via
256 AS X, AS Y should prefer to take the path via the lower MED peering of 100 with
257 AS X. Setting the MED allows an AS to influence the routing taken to it
258 within another, neighbouring AS.
260 In this use of MED it is not really meaningful to compare the MED value on
261 routes where the next AS on the paths differs. E.g., if AS Y also had a
262 route for some destination via AS Z in addition to the routes from AS X, and
263 AS Z had also set a MED, it wouldn't make sense for AS Y to compare AS Z's
264 MED values to those of AS X. The MED values have been set by different
265 administrators, with different frames of reference.
267 The default behaviour of BGP therefore is to not compare MED values across
268 routes received from different neighbouring ASes. In Frr this is done by
269 comparing the neighbouring, left-most AS in the received AS_PATHs of the
270 routes and only comparing MED if those are the same.
272 @c TeXInfo uses the old, non-UTF-8 capable, pdftex, and so
273 @c doesn't render TeX the unicode precedes character correctly in PDF, etc.
274 @c Using a TeX code on the other hand doesn't work for non-TeX outputs
275 @c (plaintext, e.g.). So, use an output-conditional macro.
289 Unfortunately, this behaviour of MED, of sometimes being compared across
290 routes and sometimes not, depending on the properties of those other routes,
291 means MED can cause the order of preference over all the routes to be
292 undefined. That is, given routes A, B, and C, if A is preferred to B, and B
293 is preferred to C, then a well-defined order should mean the preference is
294 transitive (in the sense of orders @footnote{For some set of objects to have
295 an order, there @emph{must} be some binary ordering relation that is defined
296 for @emph{every} combination of those objects, and that relation @emph{must}
297 be transitive. I.e.@:, if the relation operator is @mprec{}, and if
298 a @mprec{} b and b @mprec{} c then that relation must carry over
299 and it @emph{must} be that a @mprec{} c for the objects to have an
300 order. The ordering relation may allow for equality, i.e.
301 a @mprec{} b and b @mprec{} a may both be true amd imply that
302 a and b are equal in the order and not distinguished by it, in
303 which case the set has a partial order. Otherwise, if there is an order,
304 all the objects have a distinct place in the order and the set has a total
305 order.}) and that A would be preferred to C.
307 However, when MED is involved this need not be the case. With MED it is
308 possible that C is actually preferred over A. So A is preferred to B, B is
309 preferred to C, but C is preferred to A. This can be true even where BGP
310 defines a deterministic ``most preferred'' route out of the full set of
311 A,B,C. With MED, for any given set of routes there may be a
312 deterministically preferred route, but there need not be any way to arrange
313 them into any order of preference. With unmodified MED, the order of
314 preference of routes literally becomes undefined.
316 That MED can induce non-transitive preferences over routes can cause issues.
317 Firstly, it may be perceived to cause routing table churn locally at
318 speakers; secondly, and more seriously, it may cause routing instability in
319 iBGP topologies, where sets of speakers continually oscillate between
322 The first issue arises from how speakers often implement routing decisions.
323 Though BGP defines a selection process that will deterministically select
324 the same route as best at any given speaker, even with MED, that process
325 requires evaluating all routes together. For performance and ease of
326 implementation reasons, many implementations evaluate route preferences in a
327 pair-wise fashion instead. Given there is no well-defined order when MED is
328 involved, the best route that will be chosen becomes subject to
329 implementation details, such as the order the routes are stored in. That
330 may be (locally) non-deterministic, e.g.@: it may be the order the routes
333 This indeterminism may be considered undesirable, though it need not cause
334 problems. It may mean additional routing churn is perceived, as sometimes
335 more updates may be produced than at other times in reaction to some event .
337 This first issue can be fixed with a more deterministic route selection that
338 ensures routes are ordered by the neighbouring AS during selection.
339 @xref{bgp deterministic-med}. This may reduce the number of updates as
340 routes are received, and may in some cases reduce routing churn. Though, it
341 could equally deterministically produce the largest possible set of updates
342 in response to the most common sequence of received updates.
344 A deterministic order of evaluation tends to imply an additional overhead of
345 sorting over any set of n routes to a destination. The implementation of
346 deterministic MED in Frr scales significantly worse than most sorting
347 algorithms at present, with the number of paths to a given destination.
348 That number is often low enough to not cause any issues, but where there are
349 many paths, the deterministic comparison may quickly become increasingly
350 expensive in terms of CPU.
352 Deterministic local evaluation can @emph{not} fix the second, more major,
353 issue of MED however. Which is that the non-transitive preference of routes
354 MED can cause may lead to routing instability or oscillation across multiple
355 speakers in iBGP topologies. This can occur with full-mesh iBGP, but is
356 particularly problematic in non-full-mesh iBGP topologies that further
357 reduce the routing information known to each speaker. This has primarily
358 been documented with iBGP route-reflection topologies. However, any
359 route-hiding technologies potentially could also exacerbate oscillation with
362 This second issue occurs where speakers each have only a subset of routes,
363 and there are cycles in the preferences between different combinations of
364 routes - as the undefined order of preference of MED allows - and the routes
365 are distributed in a way that causes the BGP speakers to 'chase' those
366 cycles. This can occur even if all speakers use a deterministic order of
367 evaluation in route selection.
369 E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X, and
370 from speaker 3 in AS Y; while speaker 5 in AS A might receive that route
371 from speaker 1 in AS Y. AS Y might set a MED of 200 at speaker 1, and 100
372 at speaker 3. I.e, using ASN:ID:MED to label the speakers:
377 X:2------|--A:4-------A:5--|-Y:1:200
383 Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs), then
384 based on the RFC4271 decision process speaker 4 will choose X:2 over
385 Y:3:100, based on the lower ID of 2. Speaker 4 advertises X:2 to speaker 5.
386 Speaker 5 will continue to prefer Y:1:200 based on the ID, and advertise
387 this to speaker 4. Speaker 4 will now have the full set of routes, and the
388 Y:1:200 it receives from 5 will beat X:2, but when speaker 4 compares
389 Y:1:200 to Y:3:100 the MED check now becomes active as the ASes match, and
390 now Y:3:100 is preferred. Speaker 4 therefore now advertises Y:3:100 to 5,
391 which will also agrees that Y:3:100 is preferred to Y:1:200, and so
392 withdraws the latter route from 4. Speaker 4 now has only X:2 and Y:3:100,
393 and X:2 beats Y:3:100, and so speaker 4 implicitly updates its route to
394 speaker 5 to X:2. Speaker 5 sees that Y:1:200 beats X:2 based on the ID,
395 and advertises Y:1:200 to speaker 4, and the cycle continues.
397 The root cause is the lack of a clear order of preference caused by how MED
398 sometimes is and sometimes is not compared, leading to this cycle in the
399 preferences between the routes:
403 /---> X:2 ---beats---> Y:3:100 --\
406 \---beats--- Y:1:200 <---beats---/
410 This particular type of oscillation in full-mesh iBGP topologies can be
411 avoided by speakers preferring already selected, external routes rather than
412 choosing to update to new a route based on a post-MED metric (e.g.
413 router-ID), at the cost of a non-deterministic selection process. Frr
414 implements this, as do many other implementations, so long as it is not
415 overridden by setting @ref{bgp bestpath compare-routerid}, and see also
416 @ref{BGP decision process}, .
418 However, more complex and insidious cycles of oscillation are possible with
419 iBGP route-reflection, which are not so easily avoided. These have been
420 documented in various places. See, e.g., @cite{McPherson, D. and Gill, V.
421 and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation
422 Condition", IETF RFC3345}, and @cite{Flavel, A. and M. Roughan, "Stable
423 and flexible iBGP", ACM SIGCOMM 2009}, and @cite{Griffin, T. and G. Wilfong,
424 "On the correctness of IBGP configuration", ACM SIGCOMM 2002} for concrete
425 examples and further references.
427 There is as of this writing @emph{no} known way to use MED for its original
428 purpose; @emph{and} reduce routing information in iBGP topologies;
429 @emph{and} be sure to avoid the instability problems of MED due the
430 non-transitive routing preferences it can induce; in general on arbitrary
433 There may be iBGP topology specific ways to reduce the instability risks,
434 even while using MED, e.g.@: by constraining the reflection topology and by
435 tuning IGP costs between route-reflector clusters, see RFC3345 for details.
436 In the near future, the Add-Path extension to BGP may also solve MED
437 oscillation while still allowing MED to be used as intended, by distributing
438 "best-paths per neighbour AS". This would be at the cost of distributing at
439 least as many routes to all speakers as a full-mesh iBGP would, if not more,
440 while also imposing similar CPU overheads as the "Deterministic MED" feature
441 at each Add-Path reflector.
443 More generally, the instability problems that MED can introduce on more
444 complex, non-full-mesh, iBGP topologies may be avoided either by:
449 Setting @ref{bgp always-compare-med}, however this allows MED to be compared
450 across values set by different neighbour ASes, which may not produce
451 coherent desirable results, of itself.
454 Effectively ignoring MED by setting MED to the same value (e.g.@: 0) using
455 @ref{routemap set metric} on all received routes, in combination with
456 setting @ref{bgp always-compare-med} on all speakers. This is the simplest
457 and most performant way to avoid MED oscillation issues, where an AS is happy
458 not to allow neighbours to inject this problematic metric.
462 As MED is evaluated after the AS_PATH length check, another possible use for
463 MED is for intra-AS steering of routes with equal AS_PATH length, as an
464 extension of the last case above. As MED is evaluated before IGP metric,
465 this can allow cold-potato routing to be implemented to send traffic to
466 preferred hand-offs with neighbours, rather than the closest hand-off
467 according to the IGP metric.
469 Note that even if action is taken to address the MED non-transitivity
470 issues, other oscillations may still be possible. E.g., on IGP cost if
471 iBGP and IGP topologies are at cross-purposes with each other - see the
472 Flavel and Roughan paper above for an example. Hence the guideline that the
473 iBGP topology should follow the IGP topology.
475 @deffn {BGP} {bgp deterministic-med} {}
476 @anchor{bgp deterministic-med}
478 Carry out route-selection in way that produces deterministic answers
479 locally, even in the face of MED and the lack of a well-defined order of
480 preference it can induce on routes. Without this option the preferred route
481 with MED may be determined largely by the order that routes were received
484 Setting this option will have a performance cost that may be noticeable when
485 there are many routes for each destination. Currently in Frr it is
486 implemented in a way that scales poorly as the number of routes per
487 destination increases.
489 The default is that this option is not set.
492 Note that there are other sources of indeterminism in the route selection
493 process, specifically, the preference for older and already selected routes
494 from eBGP peers, @xref{BGP decision process}.
496 @deffn {BGP} {bgp always-compare-med} {}
497 @anchor{bgp always-compare-med}
499 Always compare the MED on routes, even when they were received from
500 different neighbouring ASes. Setting this option makes the order of
501 preference of routes more defined, and should eliminate MED induced
504 If using this option, it may also be desirable to use @ref{routemap set
505 metric} to set MED to 0 on routes received from external neighbours.
507 This option can be used, together with @ref{routemap set metric} to use MED
508 as an intra-AS metric to steer equal-length AS_PATH routes to, e.g., desired
519 * Route Aggregation::
520 * Redistribute to BGP::
524 @subsection BGP route
526 @deffn {BGP} {network @var{A.B.C.D/M}} {}
527 This command adds the announcement network.
531 address-family ipv4 unicast
536 This configuration example says that network 10.0.0.0/8 will be
537 announced to all neighbors. Some vendors' routers don't advertise
538 routes if they aren't present in their IGP routing tables; @code{bgpd}
539 doesn't care about IGP routes when announcing its routes.
542 @deffn {BGP} {no network @var{A.B.C.D/M}} {}
545 @node Route Aggregation
546 @subsection Route Aggregation
548 @deffn {BGP} {aggregate-address @var{A.B.C.D/M}} {}
549 This command specifies an aggregate address.
552 @deffn {BGP} {aggregate-address @var{A.B.C.D/M} as-set} {}
553 This command specifies an aggregate address. Resulting routes include
557 @deffn {BGP} {aggregate-address @var{A.B.C.D/M} summary-only} {}
558 This command specifies an aggregate address. Aggreated routes will
562 @deffn {BGP} {no aggregate-address @var{A.B.C.D/M}} {}
565 @node Redistribute to BGP
566 @subsection Redistribute to BGP
568 @deffn {BGP} {redistribute kernel} {}
569 Redistribute kernel route to BGP process.
572 @deffn {BGP} {redistribute static} {}
573 Redistribute static route to BGP process.
576 @deffn {BGP} {redistribute connected} {}
577 Redistribute connected route to BGP process.
580 @deffn {BGP} {redistribute rip} {}
581 Redistribute RIP route to BGP process.
584 @deffn {BGP} {redistribute ospf} {}
585 Redistribute OSPF route to BGP process.
588 @deffn {BGP} {redistribute vpn} {}
589 Redistribute VNC routes to BGP process.
592 @deffn {BGP} {update-delay @var{max-delay}} {}
593 @deffnx {BGP} {update-delay @var{max-delay} @var{establish-wait}} {}
594 This feature is used to enable read-only mode on BGP process restart or when
595 BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode
596 would begin as soon as the first peer reaches Established status and a timer
597 for max-delay seconds is started.
599 During this mode BGP doesn't run any best-path or generate any updates to its
600 peers. This mode continues until:
601 1. All the configured peers, except the shutdown peers, have sent explicit EOR
602 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
603 Established is considered an implicit-EOR.
604 If the establish-wait optional value is given, then BGP will wait for
605 peers to reach established from the begining of the update-delay till the
606 establish-wait period is over, i.e. the minimum set of established peers for
607 which EOR is expected would be peers established during the establish-wait
608 window, not necessarily all the configured neighbors.
609 2. max-delay period is over.
610 On hitting any of the above two conditions, BGP resumes the decision process
611 and generates updates to its peers.
613 Default max-delay is 0, i.e. the feature is off by default.
616 @deffn {BGP} {table-map @var{route-map-name}} {}
617 This feature is used to apply a route-map on route updates from BGP to Zebra.
618 All the applicable match operations are allowed, such as match on prefix,
619 next-hop, communities, etc. Set operations for this attach-point are limited
620 to metric and next-hop only. Any operation of this feature does not affect
623 Supported for ipv4 and ipv6 address families. It works on multi-paths as well,
624 however, metric setting is based on the best-path only.
632 * BGP Peer commands::
637 @subsection Defining Peer
639 @deffn {BGP} {neighbor @var{peer} remote-as @var{asn}} {}
640 Creates a new neighbor whose remote-as is @var{asn}. @var{peer}
641 can be an IPv4 address or an IPv6 address.
645 neighbor 10.0.0.1 remote-as 2
648 In this case my router, in AS-1, is trying to peer with AS-2 at
651 This command must be the first command used when configuring a neighbor.
652 If the remote-as is not specified, @command{bgpd} will complain like this:
654 can't find neighbor 10.0.0.1
658 @node BGP Peer commands
659 @subsection BGP Peer commands
661 In a @code{router bgp} clause there are neighbor specific configurations
664 @deffn {BGP} {neighbor @var{peer} shutdown} {}
665 @deffnx {BGP} {no neighbor @var{peer} shutdown} {}
666 Shutdown the peer. We can delete the neighbor's configuration by
667 @code{no neighbor @var{peer} remote-as @var{as-number}} but all
668 configuration of the neighbor will be deleted. When you want to
669 preserve the configuration, but want to drop the BGP peer, use this
673 @deffn {BGP} {neighbor @var{peer} ebgp-multihop} {}
674 @deffnx {BGP} {no neighbor @var{peer} ebgp-multihop} {}
677 @deffn {BGP} {neighbor @var{peer} description ...} {}
678 @deffnx {BGP} {no neighbor @var{peer} description ...} {}
679 Set description of the peer.
682 @deffn {BGP} {neighbor @var{peer} version @var{version}} {}
683 Set up the neighbor's BGP version. @var{version} can be @var{4},
684 @var{4+} or @var{4-}. BGP version @var{4} is the default value used for
685 BGP peering. BGP version @var{4+} means that the neighbor supports
686 Multiprotocol Extensions for BGP-4. BGP version @var{4-} is similar but
687 the neighbor speaks the old Internet-Draft revision 00's Multiprotocol
688 Extensions for BGP-4. Some routing software is still using this
692 @deffn {BGP} {neighbor @var{peer} interface @var{ifname}} {}
693 @deffnx {BGP} {no neighbor @var{peer} interface @var{ifname}} {}
694 When you connect to a BGP peer over an IPv6 link-local address, you
695 have to specify the @var{ifname} of the interface used for the
696 connection. To specify IPv4 session addresses, see the
697 @code{neighbor @var{peer} update-source} command below.
699 This command is deprecated and may be removed in a future release. Its
700 use should be avoided.
703 @deffn {BGP} {neighbor @var{peer} next-hop-self [all]} {}
704 @deffnx {BGP} {no neighbor @var{peer} next-hop-self [all]} {}
705 This command specifies an announced route's nexthop as being equivalent
706 to the address of the bgp router if it is learned via eBGP.
707 If the optional keyword @code{all} is specified the modifiation is done
708 also for routes learned via iBGP.
711 @deffn {BGP} {neighbor @var{peer} update-source @var{<ifname|address>}} {}
712 @deffnx {BGP} {no neighbor @var{peer} update-source} {}
713 Specify the IPv4 source address to use for the @acronym{BGP} session to this
714 neighbour, may be specified as either an IPv4 address directly or
715 as an interface name (in which case the @command{zebra} daemon MUST be running
716 in order for @command{bgpd} to be able to retrieve interface state).
720 neighbor foo update-source 192.168.0.1
721 neighbor bar update-source lo0
726 @deffn {BGP} {neighbor @var{peer} default-originate} {}
727 @deffnx {BGP} {no neighbor @var{peer} default-originate} {}
728 @command{bgpd}'s default is to not announce the default route (0.0.0.0/0) even it
729 is in routing table. When you want to announce default routes to the
730 peer, use this command.
733 @deffn {BGP} {neighbor @var{peer} port @var{port}} {}
734 @deffnx {BGP} {neighbor @var{peer} port @var{port}} {}
737 @deffn {BGP} {neighbor @var{peer} send-community} {}
738 @deffnx {BGP} {neighbor @var{peer} send-community} {}
741 @deffn {BGP} {neighbor @var{peer} weight @var{weight}} {}
742 @deffnx {BGP} {no neighbor @var{peer} weight @var{weight}} {}
743 This command specifies a default @var{weight} value for the neighbor's
747 @deffn {BGP} {neighbor @var{peer} maximum-prefix @var{number}} {}
748 @deffnx {BGP} {no neighbor @var{peer} maximum-prefix @var{number}} {}
751 @deffn {BGP} {neighbor @var{peer} local-as @var{as-number}} {}
752 @deffnx {BGP} {neighbor @var{peer} local-as @var{as-number} no-prepend} {}
753 @deffnx {BGP} {neighbor @var{peer} local-as @var{as-number} no-prepend replace-as} {}
754 @deffnx {BGP} {no neighbor @var{peer} local-as} {}
755 Specify an alternate AS for this BGP process when interacting with the
756 specified peer. With no modifiers, the specified local-as is prepended to
757 the received AS_PATH when receiving routing updates from the peer, and
758 prepended to the outgoing AS_PATH (after the process local AS) when
759 transmitting local routes to the peer.
761 If the no-prepend attribute is specified, then the supplied local-as is not
762 prepended to the received AS_PATH.
764 If the replace-as attribute is specified, then only the supplied local-as is
765 prepended to the AS_PATH when transmitting local-route updates to this peer.
767 Note that replace-as can only be specified if no-prepend is.
769 This command is only allowed for eBGP peers.
772 @deffn {BGP} {neighbor @var{peer} ttl-security hops @var{number}} {}
773 @deffnx {BGP} {no neighbor @var{peer} ttl-security hops @var{number}} {}
774 This command enforces Generalized TTL Security Mechanism (GTSM), as
775 specified in RFC 5082. With this command, only neighbors that are the
776 specified number of hops away will be allowed to become neighbors. This
777 command is mututally exclusive with @command{ebgp-multihop}.
781 @subsection Peer filtering
783 @deffn {BGP} {neighbor @var{peer} distribute-list @var{name} [in|out]} {}
784 This command specifies a distribute-list for the peer. @var{direct} is
785 @samp{in} or @samp{out}.
788 @deffn {BGP command} {neighbor @var{peer} prefix-list @var{name} [in|out]} {}
791 @deffn {BGP command} {neighbor @var{peer} filter-list @var{name} [in|out]} {}
794 @deffn {BGP} {neighbor @var{peer} route-map @var{name} [in|out]} {}
795 Apply a route-map on the neighbor. @var{direct} must be @code{in} or
799 @deffn {BGP} {bgp route-reflector allow-outbound-policy} {}
800 By default, attribute modification via route-map policy out is not reflected
801 on reflected routes. This option allows the modifications to be reflected as
802 well. Once enabled, it affects all reflected routes.
805 @c -----------------------------------------------------------------------
807 @section BGP Peer Group
809 @deffn {BGP} {neighbor @var{word} peer-group} {}
810 This command defines a new peer group.
813 @deffn {BGP} {neighbor @var{peer} peer-group @var{word}} {}
814 This command bind specific peer to peer group @var{word}.
817 @node BGP Address Family
818 @section BGP Address Family
820 Multiprotocol BGP enables BGP to carry routing information for multiple
821 Network Layer protocols. BGP supports multiple Address Family
822 Identifier (AFI), namely IPv4 and IPv6. Support is also provided for
823 multiple sets of per-AFI information via Subsequent Address Family
824 Identifiers (SAFI). In addition to unicast information, VPN information
825 @cite{RFC4364} and @cite{RFC4659}, and Encapsulation information
826 @cite{RFC5512} is supported.
828 @deffn {Command} {show ip bgp vpnv4 all} {}
829 @deffnx {Command} {show ipv6 bgp vpn all} {}
830 Print active IPV4 or IPV6 routes advertised via the VPN SAFI.
833 @deffn {Command} {show ip bgp encap all} {}
834 @deffnx {Command} {show ipv6 bgp encap all} {}
835 Print active IPV4 or IPV6 routes advertised via the Encapsulation SAFI.
838 @deffn {Command} {show bgp ipv4 encap summary} {}
839 @deffnx {Command} {show bgp ipv4 vpn summary} {}
840 @deffnx {Command} {show bgp ipv6 encap summary} {}
841 @deffnx {Command} {show bgp ipv6 vpn summary} {}
842 Print a summary of neighbor connections for the specified AFI/SAFI combination.
845 @c -----------------------------------------------------------------------
846 @node Autonomous System
847 @section Autonomous System
849 The @acronym{AS,Autonomous System} number is one of the essential
850 element of BGP. BGP is a distance vector routing protocol, and the
851 AS-Path framework provides distance vector metric and loop detection to
852 BGP. @cite{RFC1930, Guidelines for creation, selection, and
853 registration of an Autonomous System (AS)} provides some background on
854 the concepts of an AS.
856 The AS number is a two octet value, ranging in value from 1 to 65535.
857 The AS numbers 64512 through 65535 are defined as private AS numbers.
858 Private AS numbers must not to be advertised in the global Internet.
861 * Display BGP Routes by AS Path::
862 * AS Path Access List::
863 * Using AS Path in Route Map::
864 * Private AS Numbers::
867 @node Display BGP Routes by AS Path
868 @subsection Display BGP Routes by AS Path
870 To show BGP routes which has specific AS path information @code{show
871 ip bgp} command can be used.
873 @deffn Command {show bgp @{ipv4|ipv6@} regexp @var{line}} {}
874 This commands displays BGP routes that matches a regular
875 expression @var{line} (@pxref{BGP Regular Expressions}).
878 @node AS Path Access List
879 @subsection AS Path Access List
881 AS path access list is user defined AS path.
883 @deffn {Command} {ip as-path access-list @var{word} @{permit|deny@} @var{line}} {}
884 This command defines a new AS path access list.
887 @deffn {Command} {no ip as-path access-list @var{word}} {}
888 @deffnx {Command} {no ip as-path access-list @var{word} @{permit|deny@} @var{line}} {}
891 @node Using AS Path in Route Map
892 @subsection Using AS Path in Route Map
894 @deffn {Route Map} {match as-path @var{word}} {}
897 @deffn {Route Map} {set as-path prepend @var{as-path}} {}
898 Prepend the given string of AS numbers to the AS_PATH.
901 @deffn {Route Map} {set as-path prepend last-as @var{num}} {}
902 Prepend the existing last AS number (the leftmost ASN) to the AS_PATH.
905 @node Private AS Numbers
906 @subsection Private AS Numbers
908 @c -----------------------------------------------------------------------
909 @node BGP Communities Attribute
910 @section BGP Communities Attribute
912 BGP communities attribute is widely used for implementing policy
913 routing. Network operators can manipulate BGP communities attribute
914 based on their network policy. BGP communities attribute is defined
915 in @cite{RFC1997, BGP Communities Attribute} and
916 @cite{RFC1998, An Application of the BGP Community Attribute
917 in Multi-home Routing}. It is an optional transitive attribute,
918 therefore local policy can travel through different autonomous system.
920 Communities attribute is a set of communities values. Each
921 communities value is 4 octet long. The following format is used to
922 define communities value.
926 This format represents 4 octet communities value. @code{AS} is high
927 order 2 octet in digit format. @code{VAL} is low order 2 octet in
928 digit format. This format is useful to define AS oriented policy
929 value. For example, @code{7675:80} can be used when AS 7675 wants to
930 pass local policy value 80 to neighboring peer.
932 @code{internet} represents well-known communities value 0.
934 @code{no-export} represents well-known communities value @code{NO_EXPORT}@*
935 @r{(0xFFFFFF01)}. All routes carry this value must not be advertised
936 to outside a BGP confederation boundary. If neighboring BGP peer is
937 part of BGP confederation, the peer is considered as inside a BGP
938 confederation boundary, so the route will be announced to the peer.
940 @code{no-advertise} represents well-known communities value
941 @code{NO_ADVERTISE}@*@r{(0xFFFFFF02)}. All routes carry this value
942 must not be advertise to other BGP peers.
944 @code{local-AS} represents well-known communities value
945 @code{NO_EXPORT_SUBCONFED} @r{(0xFFFFFF03)}. All routes carry this
946 value must not be advertised to external BGP peers. Even if the
947 neighboring router is part of confederation, it is considered as
948 external BGP peer, so the route will not be announced to the peer.
951 When BGP communities attribute is received, duplicated communities
952 value in the communities attribute is ignored and each communities
953 values are sorted in numerical order.
956 * BGP Community Lists::
957 * Numbered BGP Community Lists::
958 * BGP Community in Route Map::
959 * Display BGP Routes by Community::
960 * Using BGP Communities Attribute::
963 @node BGP Community Lists
964 @subsection BGP Community Lists
966 BGP community list is a user defined BGP communites attribute list.
967 BGP community list can be used for matching or manipulating BGP
968 communities attribute in updates.
970 There are two types of community list. One is standard community
971 list and another is expanded community list. Standard community list
972 defines communities attribute. Expanded community list defines
973 communities attribute string with regular expression. Standard
974 community list is compiled into binary format when user define it.
975 Standard community list will be directly compared to BGP communities
976 attribute in BGP updates. Therefore the comparison is faster than
977 expanded community list.
979 @deffn Command {ip community-list standard @var{name} @{permit|deny@} @var{community}} {}
980 This command defines a new standard community list. @var{community}
981 is communities value. The @var{community} is compiled into community
982 structure. We can define multiple community list under same name. In
983 that case match will happen user defined order. Once the
984 community list matches to communities attribute in BGP updates it
985 return permit or deny by the community list definition. When there is
986 no matched entry, deny will be returned. When @var{community} is
987 empty it matches to any routes.
990 @deffn Command {ip community-list expanded @var{name} @{permit|deny@} @var{line}} {}
991 This command defines a new expanded community list. @var{line} is a
992 string expression of communities attribute. @var{line} can be a
993 regular expression (@pxref{BGP Regular Expressions}) to match
994 the communities attribute in BGP updates.
997 @deffn Command {no ip community-list @var{name}} {}
998 @deffnx Command {no ip community-list standard @var{name}} {}
999 @deffnx Command {no ip community-list expanded @var{name}} {}
1000 These commands delete community lists specified by @var{name}. All of
1001 community lists shares a single name space. So community lists can be
1002 removed simpley specifying community lists name.
1005 @deffn {Command} {show ip community-list} {}
1006 @deffnx {Command} {show ip community-list @var{name}} {}
1007 This command displays current community list information. When
1008 @var{name} is specified the specified community list's information is
1012 # show ip community-list
1013 Named Community standard list CLIST
1014 permit 7675:80 7675:100 no-export
1016 Named Community expanded list EXPAND
1019 # show ip community-list CLIST
1020 Named Community standard list CLIST
1021 permit 7675:80 7675:100 no-export
1026 @node Numbered BGP Community Lists
1027 @subsection Numbered BGP Community Lists
1029 When number is used for BGP community list name, the number has
1030 special meanings. Community list number in the range from 1 and 99 is
1031 standard community list. Community list number in the range from 100
1032 to 199 is expanded community list. These community lists are called
1033 as numbered community lists. On the other hand normal community lists
1034 is called as named community lists.
1036 @deffn Command {ip community-list <1-99> @{permit|deny@} @var{community}} {}
1037 This command defines a new community list. <1-99> is standard
1038 community list number. Community list name within this range defines
1039 standard community list. When @var{community} is empty it matches to
1043 @deffn Command {ip community-list <100-199> @{permit|deny@} @var{community}} {}
1044 This command defines a new community list. <100-199> is expanded
1045 community list number. Community list name within this range defines
1046 expanded community list.
1049 @deffn Command {ip community-list @var{name} @{permit|deny@} @var{community}} {}
1050 When community list type is not specifed, the community list type is
1051 automatically detected. If @var{community} can be compiled into
1052 communities attribute, the community list is defined as a standard
1053 community list. Otherwise it is defined as an expanded community
1054 list. This feature is left for backward compability. Use of this
1055 feature is not recommended.
1058 @node BGP Community in Route Map
1059 @subsection BGP Community in Route Map
1061 In Route Map (@pxref{Route Map}), we can match or set BGP
1062 communities attribute. Using this feature network operator can
1063 implement their network policy based on BGP communities attribute.
1065 Following commands can be used in Route Map.
1067 @deffn {Route Map} {match community @var{word}} {}
1068 @deffnx {Route Map} {match community @var{word} exact-match} {}
1069 This command perform match to BGP updates using community list
1070 @var{word}. When the one of BGP communities value match to the one of
1071 communities value in community list, it is match. When
1072 @code{exact-match} keyword is spcified, match happen only when BGP
1073 updates have completely same communities value specified in the
1077 @deffn {Route Map} {set community none} {}
1078 @deffnx {Route Map} {set community @var{community}} {}
1079 @deffnx {Route Map} {set community @var{community} additive} {}
1080 This command manipulate communities value in BGP updates. When
1081 @code{none} is specified as communities value, it removes entire
1082 communities attribute from BGP updates. When @var{community} is not
1083 @code{none}, specified communities value is set to BGP updates. If
1084 BGP updates already has BGP communities value, the existing BGP
1085 communities value is replaced with specified @var{community} value.
1086 When @code{additive} keyword is specified, @var{community} is appended
1087 to the existing communities value.
1090 @deffn {Route Map} {set comm-list @var{word} delete} {}
1091 This command remove communities value from BGP communities attribute.
1092 The @var{word} is community list name. When BGP route's communities
1093 value matches to the community list @var{word}, the communities value
1094 is removed. When all of communities value is removed eventually, the
1095 BGP update's communities attribute is completely removed.
1098 @node Display BGP Routes by Community
1099 @subsection Display BGP Routes by Community
1101 To show BGP routes which has specific BGP communities attribute,
1102 @code{show bgp @{ipv4|ipv6@}} command can be used. The
1103 @var{community} and @var{community-list} subcommand can be used.
1105 @deffn Command {show bgp @{ipv4|ipv6@} community} {}
1106 @deffnx Command {show bgp @{ipv4|ipv6@} community @var{community}} {}
1107 @deffnx Command {show bgp @{ipv4|ipv6@} community @var{community} exact-match} {}
1108 @code{show bgp @{ipv4|ipv6@} community} displays BGP routes which has communities
1109 attribute. Where the address family can be IPv4 or IPv6 among others. When
1110 @var{community} is specified, BGP routes that matches @var{community} value is
1111 displayed. For this command, @code{internet} keyword can't be used for
1112 @var{community} value. When @code{exact-match} is specified, it display only
1113 routes that have an exact match.
1116 @deffn Command {show bgp @{ipv4|ipv6@} community-list @var{word}} {}
1117 @deffnx Command {show bgp @{ipv4|ipv6@} community-list @var{word} exact-match} {}
1118 This commands display BGP routes for the address family specified that matches
1119 community list @var{word}. When @code{exact-match} is specified, display only
1120 routes that have an exact match.
1123 @node Using BGP Communities Attribute
1124 @subsection Using BGP Communities Attribute
1126 Following configuration is the most typical usage of BGP communities
1127 attribute. AS 7675 provides upstream Internet connection to AS 100.
1128 When following configuration exists in AS 7675, AS 100 networks
1129 operator can set local preference in AS 7675 network by setting BGP
1130 communities attribute to the updates.
1134 neighbor 192.168.0.1 remote-as 100
1135 address-family ipv4 unicast
1136 neighbor 192.168.0.1 route-map RMAP in
1139 ip community-list 70 permit 7675:70
1140 ip community-list 70 deny
1141 ip community-list 80 permit 7675:80
1142 ip community-list 80 deny
1143 ip community-list 90 permit 7675:90
1144 ip community-list 90 deny
1146 route-map RMAP permit 10
1148 set local-preference 70
1150 route-map RMAP permit 20
1152 set local-preference 80
1154 route-map RMAP permit 30
1156 set local-preference 90
1159 Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675.
1160 The route has communities value 7675:80 so when above configuration
1161 exists in AS 7675, announced route's local preference will be set to
1167 neighbor 192.168.0.2 remote-as 7675
1168 address-family ipv4 unicast
1169 neighbor 192.168.0.2 route-map RMAP out
1172 ip prefix-list PLIST permit 10.0.0.0/8
1174 route-map RMAP permit 10
1175 match ip address prefix-list PLIST
1176 set community 7675:80
1179 Following configuration is an example of BGP route filtering using
1180 communities attribute. This configuration only permit BGP routes
1181 which has BGP communities value 0:80 or 0:90. Network operator can
1182 put special internal communities value at BGP border router, then
1183 limit the BGP routes announcement into the internal network.
1187 neighbor 192.168.0.1 remote-as 100
1188 address-family ipv4 unicast
1189 neighbor 192.168.0.1 route-map RMAP in
1192 ip community-list 1 permit 0:80 0:90
1194 route-map RMAP permit in
1198 Following exmaple filter BGP routes which has communities value 1:1.
1199 When there is no match community-list returns deny. To avoid
1200 filtering all of routes, we need to define permit any at last.
1204 neighbor 192.168.0.1 remote-as 100
1205 address-family ipv4 unicast
1206 neighbor 192.168.0.1 route-map RMAP in
1209 ip community-list standard FILTER deny 1:1
1210 ip community-list standard FILTER permit
1212 route-map RMAP permit 10
1213 match community FILTER
1216 Communities value keyword @code{internet} has special meanings in
1217 standard community lists. In below example @code{internet} act as
1218 match any. It matches all of BGP routes even if the route does not
1219 have communities attribute at all. So community list @code{INTERNET}
1220 is same as above example's @code{FILTER}.
1223 ip community-list standard INTERNET deny 1:1
1224 ip community-list standard INTERNET permit internet
1227 Following configuration is an example of communities value deletion.
1228 With this configuration communities value 100:1 and 100:2 is removed
1229 from BGP updates. For communities value deletion, only @code{permit}
1230 community-list is used. @code{deny} community-list is ignored.
1234 neighbor 192.168.0.1 remote-as 100
1235 address-family ipv4 unicast
1236 neighbor 192.168.0.1 route-map RMAP in
1239 ip community-list standard DEL permit 100:1 100:2
1241 route-map RMAP permit 10
1242 set comm-list DEL delete
1245 @c -----------------------------------------------------------------------
1246 @node BGP Extended Communities Attribute
1247 @section BGP Extended Communities Attribute
1249 BGP extended communities attribute is introduced with MPLS VPN/BGP
1250 technology. MPLS VPN/BGP expands capability of network infrastructure
1251 to provide VPN functionality. At the same time it requires a new
1252 framework for policy routing. With BGP Extended Communities Attribute
1253 we can use Route Target or Site of Origin for implementing network
1254 policy for MPLS VPN/BGP.
1256 BGP Extended Communities Attribute is similar to BGP Communities
1257 Attribute. It is an optional transitive attribute. BGP Extended
1258 Communities Attribute can carry multiple Extended Community value.
1259 Each Extended Community value is eight octet length.
1261 BGP Extended Communities Attribute provides an extended range
1262 compared with BGP Communities Attribute. Adding to that there is a
1263 type field in each value to provides community space structure.
1265 There are two format to define Extended Community value. One is AS
1266 based format the other is IP address based format.
1270 This is a format to define AS based Extended Community value.
1271 @code{AS} part is 2 octets Global Administrator subfield in Extended
1272 Community value. @code{VAL} part is 4 octets Local Administrator
1273 subfield. @code{7675:100} represents AS 7675 policy value 100.
1274 @item IP-Address:VAL
1275 This is a format to define IP address based Extended Community value.
1276 @code{IP-Address} part is 4 octets Global Administrator subfield.
1277 @code{VAL} part is 2 octets Local Administrator subfield.
1278 @code{10.0.0.1:100} represents
1282 * BGP Extended Community Lists::
1283 * BGP Extended Communities in Route Map::
1286 @node BGP Extended Community Lists
1287 @subsection BGP Extended Community Lists
1289 Expanded Community Lists is a user defined BGP Expanded Community
1292 @deffn Command {ip extcommunity-list standard @var{name} @{permit|deny@} @var{extcommunity}} {}
1293 This command defines a new standard extcommunity-list.
1294 @var{extcommunity} is extended communities value. The
1295 @var{extcommunity} is compiled into extended community structure. We
1296 can define multiple extcommunity-list under same name. In that case
1297 match will happen user defined order. Once the extcommunity-list
1298 matches to extended communities attribute in BGP updates it return
1299 permit or deny based upon the extcommunity-list definition. When
1300 there is no matched entry, deny will be returned. When
1301 @var{extcommunity} is empty it matches to any routes.
1304 @deffn Command {ip extcommunity-list expanded @var{name} @{permit|deny@} @var{line}} {}
1305 This command defines a new expanded extcommunity-list. @var{line} is
1306 a string expression of extended communities attribute. @var{line} can
1307 be a regular expression (@pxref{BGP Regular Expressions}) to match an
1308 extended communities attribute in BGP updates.
1311 @deffn Command {no ip extcommunity-list @var{name}} {}
1312 @deffnx Command {no ip extcommunity-list standard @var{name}} {}
1313 @deffnx Command {no ip extcommunity-list expanded @var{name}} {}
1314 These commands delete extended community lists specified by
1315 @var{name}. All of extended community lists shares a single name
1316 space. So extended community lists can be removed simpley specifying
1320 @deffn {Command} {show ip extcommunity-list} {}
1321 @deffnx {Command} {show ip extcommunity-list @var{name}} {}
1322 This command displays current extcommunity-list information. When
1323 @var{name} is specified the community list's information is shown.
1326 # show ip extcommunity-list
1330 @node BGP Extended Communities in Route Map
1331 @subsection BGP Extended Communities in Route Map
1333 @deffn {Route Map} {match extcommunity @var{word}} {}
1336 @deffn {Route Map} {set extcommunity rt @var{extcommunity}} {}
1337 This command set Route Target value.
1340 @deffn {Route Map} {set extcommunity soo @var{extcommunity}} {}
1341 This command set Site of Origin value.
1344 @c -----------------------------------------------------------------------
1345 @node BGP Large Communities Attribute
1346 @section BGP Large Communities Attribute
1348 The BGP Large Communities attribute was introduced in Feb 2017 with
1349 @cite{RFC8092, BGP Large Communities Attribute}.
1351 The BGP Large Communities Attribute is similar to the BGP Communities
1352 Attribute except that it has 3 components instead of two and each of
1353 which are 4 octets in length. Large Communities bring additional
1354 functionality and convenience over traditional communities, specifically
1355 the fact that the @code{GLOBAL} part below is now 4 octets wide allowing
1356 AS4 operators seamless use.
1359 @item GLOBAL:LOCAL1:LOCAL2
1360 This is the format to define Large Community values. Referencing
1361 @cite{RFC8195, Use of BGP Large Communities} the values are commonly
1362 referred to as follows.
1363 The @code{GLOBAL} part is a 4 octet Global Administrator field, common
1364 use of this field is the operators AS number.
1365 The @code{LOCAL1} part is a 4 octet Local Data Part 1 subfield referred
1367 The @code{LOCAL2} part is a 4 octet Local Data Part 2 field and referred
1368 to as the parameter subfield. @code{65551:1:10} represents AS 65551
1369 function 1 and parameter 10.
1370 The referenced RFC above gives some guidelines on recommended usage.
1374 * BGP Large Community Lists::
1375 * BGP Large Communities in Route Map::
1378 @node BGP Large Community Lists
1379 @subsection BGP Large Community Lists
1381 Two types of large community lists are supported, namely @code{standard} and
1384 @deffn Command {ip large-community-list standard @var{name} @{permit|deny@} @var{large-community}} {}
1385 This command defines a new standard large-community-list.
1386 @var{large-community} is the Large Community value. We
1387 can add multiple large communities under same name. In that case
1388 the match will happen in the user defined order. Once the large-community-list
1389 matches the Large Communities attribute in BGP updates it will return
1390 permit or deny based upon the large-community-list definition. When
1391 there is no matched entry, a deny will be returned. When @var{large-community}
1392 is empty it matches any routes.
1395 @deffn Command {ip large-community-list expanded @var{name} @{permit|deny@} @var{line}} {}
1396 This command defines a new expanded large-community-list. Where @var{line} is
1397 a string matching expression, it will be compared to the entire Large Communities
1398 attribute as a string, with each large-community in order from lowest to highest.
1399 @var{line} can also be a regular expression which matches this Large
1400 Community attribute.
1403 @deffn Command {no ip large-community-list @var{name}} {}
1404 @deffnx Command {no ip large-community-list standard @var{name}} {}
1405 @deffnx Command {no ip large-community-list expanded @var{name}} {}
1406 These commands delete Large Community lists specified by
1407 @var{name}. All Large Community lists share a single namespace.
1408 This means Large Community lists can be removed by simply specifying the name.
1411 @deffn {Command} {show ip large-community-list} {}
1412 @deffnx {Command} {show ip large-community-list @var{name}} {}
1413 This command display current large-community-list information. When
1414 @var{name} is specified the community list information is shown.
1417 @deffn {Command} {show ip bgp large-community-info} {}
1418 This command displays the current large communities in use.
1421 @node BGP Large Communities in Route Map
1422 @subsection BGP Large Communities in Route Map
1424 @deffn {Route Map} {match large-community @var{line}} {}
1425 Where @var{line} can be a simple string to match, or a regular expression.
1426 It is very important to note that this match occurs on the entire
1427 large-community string as a whole, where each large-community is ordered
1428 from lowest to highest.
1431 @deffn {Route Map} {set large-community @var{large-community}} {}
1432 @deffnx {Route Map} {set large-community @var{large-community} @var{large-community}} {}
1433 @deffnx {Route Map} {set large-community @var{large-community} additive} {}
1434 These commands are used for setting large-community values. The first
1435 command will overwrite any large-communities currently present.
1436 The second specifies two large-communities, which overwrites the current
1437 large-community list. The third will add a large-community value without
1438 overwriting other values. Multiple large-community values can be specified.
1441 @c -----------------------------------------------------------------------
1443 @node Displaying BGP information
1444 @section Displaying BGP information
1447 * Showing BGP information::
1448 * Other BGP commands::
1451 @node Showing BGP information
1452 @subsection Showing BGP information
1454 @deffn {Command} {show ip bgp} {}
1455 @deffnx {Command} {show ip bgp @var{A.B.C.D}} {}
1456 @deffnx {Command} {show ip bgp @var{X:X::X:X}} {}
1457 This command displays BGP routes. When no route is specified it
1458 display all of IPv4 BGP routes.
1462 BGP table version is 0, local router ID is 10.1.1.1
1463 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
1464 Origin codes: i - IGP, e - EGP, ? - incomplete
1466 Network Next Hop Metric LocPrf Weight Path
1467 *> 1.1.1.1/32 0.0.0.0 0 32768 i
1469 Total number of prefixes 1
1472 @deffn {Command} {show ip bgp regexp @var{line}} {}
1473 This command displays BGP routes using AS path regular expression
1474 (@pxref{BGP Regular Expressions}).
1477 @deffn Command {show ip bgp community @var{community}} {}
1478 @deffnx Command {show ip bgp community @var{community} exact-match} {}
1479 This command displays BGP routes using @var{community} (@pxref{Display
1480 BGP Routes by Community}).
1483 @deffn Command {show ip bgp community-list @var{word}} {}
1484 @deffnx Command {show ip bgp community-list @var{word} exact-match} {}
1485 This command displays BGP routes using community list (@pxref{Display
1486 BGP Routes by Community}).
1489 @deffn {Command} {show bgp @{ipv4|ipv6@} summary} {}
1490 Show a bgp peer summary for the specified address family.
1493 @deffn {Command} {show bgp @{ipv4|ipv6@} neighbor [@var{peer}]} {}
1494 This command shows information on a specific BGP @var{peer}.
1497 @deffn {Command} {show bgp @{ipv4|ipv6@} dampening dampened-paths} {}
1498 Display paths suppressed due to dampening.
1501 @deffn {Command} {show bgp @{ipv4|ipv6@} dampening flap-statistics} {}
1502 Display flap statistics of routes.
1505 @node Other BGP commands
1506 @subsection Other BGP commands
1508 @deffn {Command} {clear bgp @{ipv4|ipv6@} *} {}
1509 Clear all address family peers.
1512 @deffn {Command} {clear bgp @{ipv4|ipv6@} @var{peer}} {}
1513 Clear peers which have addresses of X.X.X.X
1516 @deffn {Command} {clear bgp @{ipv4|ipv6@} @var{peer} soft in} {}
1517 Clear peer using soft reconfiguration.
1520 @deffn {Command} {show debug} {}
1523 @deffn {Command} {debug event} {}
1526 @deffn {Command} {debug update} {}
1529 @deffn {Command} {debug keepalive} {}
1532 @deffn {Command} {no debug event} {}
1535 @deffn {Command} {no debug update} {}
1538 @deffn {Command} {no debug keepalive} {}
1541 @node Capability Negotiation
1542 @section Capability Negotiation
1544 When adding IPv6 routing information exchange feature to BGP. There
1545 were some proposals. @acronym{IETF,Internet Engineering Task Force}
1546 @acronym{IDR, Inter Domain Routing} @acronym{WG, Working group} adopted
1547 a proposal called Multiprotocol Extension for BGP. The specification
1548 is described in @cite{RFC2283}. The protocol does not define new protocols.
1549 It defines new attributes to existing BGP. When it is used exchanging
1550 IPv6 routing information it is called BGP-4+. When it is used for
1551 exchanging multicast routing information it is called MBGP.
1553 @command{bgpd} supports Multiprotocol Extension for BGP. So if remote
1554 peer supports the protocol, @command{bgpd} can exchange IPv6 and/or
1555 multicast routing information.
1557 Traditional BGP did not have the feature to detect remote peer's
1558 capabilities, e.g. whether it can handle prefix types other than IPv4
1559 unicast routes. This was a big problem using Multiprotocol Extension
1560 for BGP to operational network. @cite{RFC2842, Capabilities
1561 Advertisement with BGP-4} adopted a feature called Capability
1562 Negotiation. @command{bgpd} use this Capability Negotiation to detect
1563 the remote peer's capabilities. If the peer is only configured as IPv4
1564 unicast neighbor, @command{bgpd} does not send these Capability
1565 Negotiation packets (at least not unless other optional BGP features
1566 require capability negotation).
1568 By default, Frr will bring up peering with minimal common capability
1569 for the both sides. For example, local router has unicast and
1570 multicast capabilitie and remote router has unicast capability. In
1571 this case, the local router will establish the connection with unicast
1572 only capability. When there are no common capabilities, Frr sends
1573 Unsupported Capability error and then resets the connection.
1575 If you want to completely match capabilities with remote peer. Please
1576 use @command{strict-capability-match} command.
1578 @deffn {BGP} {neighbor @var{peer} strict-capability-match} {}
1579 @deffnx {BGP} {no neighbor @var{peer} strict-capability-match} {}
1580 Strictly compares remote capabilities and local capabilities. If capabilities
1581 are different, send Unsupported Capability error then reset connection.
1584 You may want to disable sending Capability Negotiation OPEN message
1585 optional parameter to the peer when remote peer does not implement
1586 Capability Negotiation. Please use @command{dont-capability-negotiate}
1587 command to disable the feature.
1589 @deffn {BGP} {neighbor @var{peer} dont-capability-negotiate} {}
1590 @deffnx {BGP} {no neighbor @var{peer} dont-capability-negotiate} {}
1591 Suppress sending Capability Negotiation as OPEN message optional
1592 parameter to the peer. This command only affects the peer is configured
1593 other than IPv4 unicast configuration.
1596 When remote peer does not have capability negotiation feature, remote
1597 peer will not send any capabilities at all. In that case, bgp
1598 configures the peer with configured capabilities.
1600 You may prefer locally configured capabilities more than the negotiated
1601 capabilities even though remote peer sends capabilities. If the peer
1602 is configured by @command{override-capability}, @command{bgpd} ignores
1603 received capabilities then override negotiated capabilities with
1606 @deffn {BGP} {neighbor @var{peer} override-capability} {}
1607 @deffnx {BGP} {no neighbor @var{peer} override-capability} {}
1608 Override the result of Capability Negotiation with local configuration.
1609 Ignore remote peer's capability value.
1612 @node Route Reflector
1613 @section Route Reflector
1615 @deffn {BGP} {bgp cluster-id @var{a.b.c.d}} {}
1618 @deffn {BGP} {neighbor @var{peer} route-reflector-client} {}
1619 @deffnx {BGP} {no neighbor @var{peer} route-reflector-client} {}
1623 @section Route Server
1625 At an Internet Exchange point, many ISPs are connected to each other by
1626 external BGP peering. Normally these external BGP connection are done by
1627 @samp{full mesh} method. As with internal BGP full mesh formation,
1628 this method has a scaling problem.
1630 This scaling problem is well known. Route Server is a method to resolve
1631 the problem. Each ISP's BGP router only peers to Route Server. Route
1632 Server serves as BGP information exchange to other BGP routers. By
1633 applying this method, numbers of BGP connections is reduced from
1634 O(n*(n-1)/2) to O(n).
1636 Unlike normal BGP router, Route Server must have several routing tables
1637 for managing different routing policies for each BGP speaker. We call the
1638 routing tables as different @code{view}s. @command{bgpd} can work as
1639 normal BGP router or Route Server or both at the same time.
1642 * Multiple instance::
1643 * BGP instance and view::
1645 * Viewing the view::
1648 @node Multiple instance
1649 @subsection Multiple instance
1651 To enable multiple view function of @code{bgpd}, you must turn on
1652 multiple instance feature beforehand.
1654 @deffn {Command} {bgp multiple-instance} {}
1655 Enable BGP multiple instance feature. After this feature is enabled,
1656 you can make multiple BGP instances or multiple BGP views.
1659 @deffn {Command} {no bgp multiple-instance} {}
1660 Disable BGP multiple instance feature. You can not disable this feature
1661 when BGP multiple instances or views exist.
1664 When you want to make configuration more Cisco like one,
1666 @deffn {Command} {bgp config-type cisco} {}
1667 Cisco compatible BGP configuration output.
1670 When bgp config-type cisco is specified,
1672 ``no synchronization'' is displayed.
1673 ``no auto-summary'' is displayed.
1675 ``network'' and ``aggregate-address'' argument is displayed as
1678 Frr: network 10.0.0.0/8
1679 Cisco: network 10.0.0.0
1681 Frr: aggregate-address 192.168.0.0/24
1682 Cisco: aggregate-address 192.168.0.0 255.255.255.0
1684 Community attribute handling is also different. If there is no
1685 configuration is specified community attribute and extended community
1686 attribute are sent to neighbor. When user manually disable the
1687 feature community attribute is not sent to the neighbor. In case of
1688 @command{bgp config-type cisco} is specified, community attribute is not
1689 sent to the neighbor by default. To send community attribute user has
1690 to specify @command{neighbor A.B.C.D send-community} command.
1695 neighbor 10.0.0.1 remote-as 1
1696 address-family ipv4 unicast
1697 no neighbor 10.0.0.1 send-community
1701 neighbor 10.0.0.1 remote-as 1
1702 address-family ipv4 unicast
1703 neighbor 10.0.0.1 send-community
1708 @deffn {Command} {bgp config-type zebra} {}
1709 Frr style BGP configuration. This is default.
1712 @node BGP instance and view
1713 @subsection BGP instance and view
1715 BGP instance is a normal BGP process. The result of route selection
1716 goes to the kernel routing table. You can setup different AS at the
1717 same time when BGP multiple instance feature is enabled.
1719 @deffn {Command} {router bgp @var{as-number}} {}
1720 Make a new BGP instance. You can use arbitrary word for the @var{name}.
1725 bgp multiple-instance
1728 neighbor 10.0.0.1 remote-as 2
1729 neighbor 10.0.0.2 remote-as 3
1732 neighbor 10.0.0.3 remote-as 4
1733 neighbor 10.0.0.4 remote-as 5
1737 BGP view is almost same as normal BGP process. The result of
1738 route selection does not go to the kernel routing table. BGP view is
1739 only for exchanging BGP routing information.
1741 @deffn {Command} {router bgp @var{as-number} view @var{name}} {}
1742 Make a new BGP view. You can use arbitrary word for the @var{name}. This
1743 view's route selection result does not go to the kernel routing table.
1746 With this command, you can setup Route Server like below.
1750 bgp multiple-instance
1753 neighbor 10.0.0.1 remote-as 2
1754 neighbor 10.0.0.2 remote-as 3
1757 neighbor 10.0.0.3 remote-as 4
1758 neighbor 10.0.0.4 remote-as 5
1762 @node Routing policy
1763 @subsection Routing policy
1765 You can set different routing policy for a peer. For example, you can
1766 set different filter for a peer.
1770 bgp multiple-instance
1773 neighbor 10.0.0.1 remote-as 2
1774 address-family ipv4 unicast
1775 neighbor 10.0.0.1 distribute-list 1 in
1779 neighbor 10.0.0.1 remote-as 2
1780 address-family ipv4 unicast
1781 neighbor 10.0.0.1 distribute-list 2 in
1786 This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view
1787 2. When the update is inserted into view 1, distribute-list 1 is
1788 applied. On the other hand, when the update is inserted into view 2,
1789 distribute-list 2 is applied.
1791 @node Viewing the view
1792 @subsection Viewing the view
1794 To display routing table of BGP view, you must specify view name.
1796 @deffn {Command} {show ip bgp view @var{name}} {}
1797 Display routing table of BGP view @var{name}.
1800 @node BGP Regular Expressions
1801 @section BGP Regular Expressions
1803 BGP regular expressions are based on @code{POSIX 1003.2} regular
1804 expressions. The following description is just a quick subset of the
1805 @code{POSIX} regular expressions. Adding to that, the special character
1810 Matches any single character.
1812 Matches 0 or more occurrences of pattern.
1814 Matches 1 or more occurrences of pattern.
1816 Match 0 or 1 occurrences of pattern.
1818 Matches the beginning of the line.
1820 Matches the end of the line.
1822 Character @code{_} has special meanings in BGP regular expressions.
1823 It matches to space and comma , and AS set delimiter @{ and @} and AS
1824 confederation delimiter @code{(} and @code{)}. And it also matches to
1825 the beginning of the line and the end of the line. So @code{_} can be
1826 used for AS value boundaries match. This character technically evaluates
1827 to @code{(^|[,@{@}() ]|$)}.
1830 @node How to set up a 6-Bone connection
1831 @section How to set up a 6-Bone connection
1839 ! Actually there is no need to configure zebra
1845 ! This means that routes go through zebra and into the kernel.
1849 ! MP-BGP configuration
1852 bgp router-id 10.0.0.1
1853 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as @var{as-number}
1856 network 3ffe:506::/32
1857 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
1858 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
1859 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as @var{as-number}
1860 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
1863 ipv6 access-list all permit any
1865 ! Set output nexthop address.
1867 route-map set-nexthop permit 10
1868 match ipv6 address all
1869 set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
1870 set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
1872 ! logfile FILENAME is obsolete. Please use log file FILENAME
1879 @node Dump BGP packets and table
1880 @section Dump BGP packets and table
1882 @deffn Command {dump bgp all @var{path} [@var{interval}]} {}
1883 @deffnx Command {dump bgp all-et @var{path} [@var{interval}]} {}
1884 @deffnx Command {no dump bgp all [@var{path}] [@var{interval}]} {}
1885 Dump all BGP packet and events to @var{path} file.
1886 If @var{interval} is set, a new file will be created for echo @var{interval} of seconds.
1887 The path @var{path} can be set with date and time formatting (strftime).
1888 The type ‘all-et’ enables support for Extended Timestamp Header (@pxref{Packet Binary Dump Format}).
1889 (@pxref{Packet Binary Dump Format})
1892 @deffn Command {dump bgp updates @var{path} [@var{interval}]} {}
1893 @deffnx Command {dump bgp updates-et @var{path} [@var{interval}]} {}
1894 @deffnx Command {no dump bgp updates [@var{path}] [@var{interval}]} {}
1895 Dump only BGP updates messages to @var{path} file.
1896 If @var{interval} is set, a new file will be created for echo @var{interval} of seconds.
1897 The path @var{path} can be set with date and time formatting (strftime).
1898 The type ‘updates-et’ enables support for Extended Timestamp Header (@pxref{Packet Binary Dump Format}).
1901 @deffn Command {dump bgp routes-mrt @var{path}} {}
1902 @deffnx Command {dump bgp routes-mrt @var{path} @var{interval}} {}
1903 @deffnx Command {no dump bgp route-mrt [@var{path}] [@var{interval}]} {}
1904 Dump whole BGP routing table to @var{path}. This is heavy process.
1905 The path @var{path} can be set with date and time formatting (strftime).
1906 If @var{interval} is set, a new file will be created for echo @var{interval} of seconds.
1909 Note: the interval variable can also be set using hours and minutes: 04h20m00.
1912 @node BGP Configuration Examples
1913 @section BGP Configuration Examples
1915 Example of a session to an upstream, advertising only one prefix to it.
1919 bgp router-id 10.236.87.1
1920 neighbor upstream peer-group
1921 neighbor upstream remote-as 64515
1922 neighbor upstream capability dynamic
1923 neighbor 10.1.1.1 peer-group upstream
1924 neighbor 10.1.1.1 description ACME ISP
1926 address-family ipv4 unicast
1927 network 10.236.87.0/24
1928 neighbor upstream prefix-list pl-allowed-adv out
1931 ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
1932 ip prefix-list pl-allowed-adv seq 10 deny any
1936 A more complex example. With upstream, peer and customer sessions.
1937 Advertising global prefixes and NO_EXPORT prefixes and providing
1938 actions for customer routes based on community values. Extensive use of
1939 route-maps and the 'call' feature to support selective advertising of
1940 prefixes. This example is intended as guidance only, it has NOT been
1941 tested and almost certainly containts silly mistakes, if not serious
1946 bgp router-id 10.236.87.1
1947 neighbor upstream capability dynamic
1948 neighbor cust capability dynamic
1949 neighbor peer capability dynamic
1950 neighbor 10.1.1.1 remote-as 64515
1951 neighbor 10.1.1.1 peer-group upstream
1952 neighbor 10.2.1.1 remote-as 64516
1953 neighbor 10.2.1.1 peer-group upstream
1954 neighbor 10.3.1.1 remote-as 64517
1955 neighbor 10.3.1.1 peer-group cust-default
1956 neighbor 10.3.1.1 description customer1
1957 neighbor 10.4.1.1 remote-as 64518
1958 neighbor 10.4.1.1 peer-group cust
1959 neighbor 10.4.1.1 description customer2
1960 neighbor 10.5.1.1 remote-as 64519
1961 neighbor 10.5.1.1 peer-group peer
1962 neighbor 10.5.1.1 description peer AS 1
1963 neighbor 10.6.1.1 remote-as 64520
1964 neighbor 10.6.1.1 peer-group peer
1965 neighbor 10.6.1.1 description peer AS 2
1967 address-family ipv4 unicast
1968 network 10.123.456.0/24
1969 network 10.123.456.128/25 route-map rm-no-export
1970 neighbor upstream route-map rm-upstream-out out
1971 neighbor cust route-map rm-cust-in in
1972 neighbor cust route-map rm-cust-out out
1973 neighbor cust send-community both
1974 neighbor peer route-map rm-peer-in in
1975 neighbor peer route-map rm-peer-out out
1976 neighbor peer send-community both
1977 neighbor 10.3.1.1 prefix-list pl-cust1-network in
1978 neighbor 10.4.1.1 prefix-list pl-cust2-network in
1979 neighbor 10.5.1.1 prefix-list pl-peer1-network in
1980 neighbor 10.6.1.1 prefix-list pl-peer2-network in
1983 ip prefix-list pl-default permit 0.0.0.0/0
1985 ip prefix-list pl-upstream-peers permit 10.1.1.1/32
1986 ip prefix-list pl-upstream-peers permit 10.2.1.1/32
1988 ip prefix-list pl-cust1-network permit 10.3.1.0/24
1989 ip prefix-list pl-cust1-network permit 10.3.2.0/24
1991 ip prefix-list pl-cust2-network permit 10.4.1.0/24
1993 ip prefix-list pl-peer1-network permit 10.5.1.0/24
1994 ip prefix-list pl-peer1-network permit 10.5.2.0/24
1995 ip prefix-list pl-peer1-network permit 192.168.0.0/24
1997 ip prefix-list pl-peer2-network permit 10.6.1.0/24
1998 ip prefix-list pl-peer2-network permit 10.6.2.0/24
1999 ip prefix-list pl-peer2-network permit 192.168.1.0/24
2000 ip prefix-list pl-peer2-network permit 192.168.2.0/24
2001 ip prefix-list pl-peer2-network permit 172.16.1/24
2003 ip as-path access-list asp-own-as permit ^$
2004 ip as-path access-list asp-own-as permit _64512_
2006 ! #################################################################
2007 ! Match communities we provide actions for, on routes receives from
2008 ! customers. Communities values of <our-ASN>:X, with X, have actions:
2010 ! 100 - blackhole the prefix
2011 ! 200 - set no_export
2012 ! 300 - advertise only to other customers
2013 ! 400 - advertise only to upstreams
2014 ! 500 - set no_export when advertising to upstreams
2015 ! 2X00 - set local_preference to X00
2017 ! blackhole the prefix of the route
2018 ip community-list standard cm-blackhole permit 64512:100
2020 ! set no-export community before advertising
2021 ip community-list standard cm-set-no-export permit 64512:200
2023 ! advertise only to other customers
2024 ip community-list standard cm-cust-only permit 64512:300
2026 ! advertise only to upstreams
2027 ip community-list standard cm-upstream-only permit 64512:400
2029 ! advertise to upstreams with no-export
2030 ip community-list standard cm-upstream-noexport permit 64512:500
2032 ! set local-pref to least significant 3 digits of the community
2033 ip community-list standard cm-prefmod-100 permit 64512:2100
2034 ip community-list standard cm-prefmod-200 permit 64512:2200
2035 ip community-list standard cm-prefmod-300 permit 64512:2300
2036 ip community-list standard cm-prefmod-400 permit 64512:2400
2037 ip community-list expanded cme-prefmod-range permit 64512:2...
2039 ! Informational communities
2041 ! 3000 - learned from upstream
2042 ! 3100 - learned from customer
2043 ! 3200 - learned from peer
2045 ip community-list standard cm-learnt-upstream permit 64512:3000
2046 ip community-list standard cm-learnt-cust permit 64512:3100
2047 ip community-list standard cm-learnt-peer permit 64512:3200
2049 ! ###################################################################
2050 ! Utility route-maps
2052 ! These utility route-maps generally should not used to permit/deny
2053 ! routes, i.e. they do not have meaning as filters, and hence probably
2054 ! should be used with 'on-match next'. These all finish with an empty
2055 ! permit entry so as not interfere with processing in the caller.
2057 route-map rm-no-export permit 10
2058 set community additive no-export
2059 route-map rm-no-export permit 20
2061 route-map rm-blackhole permit 10
2062 description blackhole, up-pref and ensure it cant escape this AS
2063 set ip next-hop 127.0.0.1
2064 set local-preference 10
2065 set community additive no-export
2066 route-map rm-blackhole permit 20
2068 ! Set local-pref as requested
2069 route-map rm-prefmod permit 10
2070 match community cm-prefmod-100
2071 set local-preference 100
2072 route-map rm-prefmod permit 20
2073 match community cm-prefmod-200
2074 set local-preference 200
2075 route-map rm-prefmod permit 30
2076 match community cm-prefmod-300
2077 set local-preference 300
2078 route-map rm-prefmod permit 40
2079 match community cm-prefmod-400
2080 set local-preference 400
2081 route-map rm-prefmod permit 50
2083 ! Community actions to take on receipt of route.
2084 route-map rm-community-in permit 10
2085 description check for blackholing, no point continuing if it matches.
2086 match community cm-blackhole
2088 route-map rm-community-in permit 20
2089 match community cm-set-no-export
2092 route-map rm-community-in permit 30
2093 match community cme-prefmod-range
2095 route-map rm-community-in permit 40
2097 ! #####################################################################
2098 ! Community actions to take when advertising a route.
2099 ! These are filtering route-maps,
2101 ! Deny customer routes to upstream with cust-only set.
2102 route-map rm-community-filt-to-upstream deny 10
2103 match community cm-learnt-cust
2104 match community cm-cust-only
2105 route-map rm-community-filt-to-upstream permit 20
2107 ! Deny customer routes to other customers with upstream-only set.
2108 route-map rm-community-filt-to-cust deny 10
2109 match community cm-learnt-cust
2110 match community cm-upstream-only
2111 route-map rm-community-filt-to-cust permit 20
2113 ! ###################################################################
2114 ! The top-level route-maps applied to sessions. Further entries could
2115 ! be added obviously..
2118 route-map rm-cust-in permit 10
2119 call rm-community-in
2121 route-map rm-cust-in permit 20
2122 set community additive 64512:3100
2123 route-map rm-cust-in permit 30
2125 route-map rm-cust-out permit 10
2126 call rm-community-filt-to-cust
2128 route-map rm-cust-out permit 20
2130 ! Upstream transit ASes
2131 route-map rm-upstream-out permit 10
2132 description filter customer prefixes which are marked cust-only
2133 call rm-community-filt-to-upstream
2135 route-map rm-upstream-out permit 20
2136 description only customer routes are provided to upstreams/peers
2137 match community cm-learnt-cust
2140 ! outbound policy is same as for upstream
2141 route-map rm-peer-out permit 10
2142 call rm-upstream-out
2144 route-map rm-peer-in permit 10
2145 set community additive 64512:3200