7 :abbr:`BGP` stands for a Border Gateway Protocol. The lastest BGP version is 4.
8 It is referred as BGP-4. BGP-4 is one of the Exterior Gateway Protocols and
9 de-fact standard of Inter Domain routing protocol. BGP-4 is described in
12 Many extensions have been added to :rfc:`1771`. :rfc:`2858` provides
13 multiprotocol support to BGP-4.
20 Default configuration file of *bgpd* is :file:`bgpd.conf`. *bgpd* searches the
21 current directory first then |INSTALL_PREFIX_ETC|/bgpd.conf. All of bgpd's
22 command must be configured in :file:`bgpd.conf`.
24 *bgpd* specific invocation options are described below. Common options may also
25 be specified (:ref:`common-invocation-options`).
29 .. option:: -p, --bgp_port <port>
31 Set the bgp protocol's port number. When port number is 0, that means do not
34 .. option:: -r, --retain
36 When program terminates, retain BGP routes added by zebra.
38 .. option:: -l, --listenon
40 Specify a specific IP address for bgpd to listen on, rather than its
41 default of INADDR_ANY / IN6ADDR_ANY. This can be useful to constrain bgpd
42 to an internal address, or to run multiple bgpd processes on one host.
50 First of all you must configure BGP router with *router bgp* command. To
51 configure BGP router, you need AS number. AS number is an identification of
52 autonomous system. BGP protocol uses the AS number for detecting whether the
53 BGP connection is internal one or external one.
55 .. index:: router bgp ASN
56 .. clicmd:: router bgp ASN
58 Enable a BGP protocol process with the specified ASN. After
59 this statement you can input any `BGP Commands`. You can not
60 create different BGP process under different ASN without
61 specifying `multiple-instance` (:ref:`multiple-instance`).
63 .. index:: no router bgp ASN
64 .. clicmd:: no router bgp ASN
66 Destroy a BGP protocol process with the specified ASN.
68 .. index:: bgp router-id A.B.C.D
69 .. clicmd:: bgp router-id A.B.C.D
71 This command specifies the router-ID. If *bgpd* connects to *zebra* it gets
72 interface and address information. In that case default router ID value is
73 selected as the largest IP Address of the interfaces. When `router zebra` is
74 not enabled *bgpd* can't get interface information so `router-id` is set to
75 0.0.0.0. So please set router-id by hand.
82 .. index:: distance bgp (1-255) (1-255) (1-255)
83 .. clicmd:: distance bgp (1-255) (1-255) (1-255)
85 This command change distance value of BGP. Each argument is distance value
86 for external routes, internal routes and local routes.
88 .. index:: distance (1-255) A.B.C.D/M
89 .. clicmd:: distance (1-255) A.B.C.D/M
91 .. index:: distance (1-255) A.B.C.D/M word
92 .. clicmd:: distance (1-255) A.B.C.D/M word
94 .. _bgp-decision-process:
99 The decision process FRR BGP uses to select routes is as follows:
102 Prefer higher local weight routes to lower routes.
104 2. *Local preference check*
105 Prefer higher local preference routes to lower.
107 3. *Local route check*
108 Prefer local routes (statics, aggregates, redistributed) to received routes.
110 4. *AS path length check*
111 Prefer shortest hop-count AS_PATHs.
114 Prefer the lowest origin type route. That is, prefer IGP origin routes to
115 EGP, to Incomplete routes.
118 Where routes with a MED were received from the same AS, prefer the route
119 with the lowest MED. :ref:`bgp-med`.
122 Prefer the route received from an external, eBGP peer over routes received
123 from other types of peers.
126 Prefer the route with the lower IGP cost.
128 9. *Multi-path check*
129 If multi-pathing is enabled, then check whether the routes not yet
130 distinguished in preference may be considered equal. If
131 :clicmd:`bgp bestpath as-path multipath-relax` is set, all such routes are
132 considered equal, otherwise routes received via iBGP with identical AS_PATHs
133 or routes received from eBGP neighbours in the same AS are considered equal.
135 10. *Already-selected external check*
136 Where both routes were received from eBGP peers, then prefer the route
137 which is already selected. Note that this check is not applied if
138 :clicmd:`bgp bestpath compare-routerid` is configured. This check can
139 prevent some cases of oscillation.
141 11. *Router-ID check*
142 Prefer the route with the lowest `router-ID`. If the route has an
143 `ORIGINATOR_ID` attribute, through iBGP reflection, then that router ID is
144 used, otherwise the `router-ID` of the peer the route was received from is
147 12. *Cluster-List length check*
148 The route with the shortest cluster-list length is used. The cluster-list
149 reflects the iBGP reflection path the route has taken.
152 Prefer the route received from the peer with the higher transport layer
153 address, as a last-resort tie-breaker.
156 .. index:: bgp bestpath as-path confed
157 .. clicmd:: bgp bestpath as-path confed
159 This command specifies that the length of confederation path sets and
160 sequences should should be taken into account during the BGP best path
163 .. index:: bgp bestpath as-path multipath-relax
164 .. clicmd:: bgp bestpath as-path multipath-relax
166 This command specifies that BGP decision process should consider paths
167 of equal AS_PATH length candidates for multipath computation. Without
168 the knob, the entire AS_PATH must match for multipath computation.
170 .. clicmd:: bgp bestpath compare-routerid
172 Ensure that when comparing routes where both are equal on most metrics,
173 including local-pref, AS_PATH length, IGP cost, MED, that the tie is broken
176 If this option is enabled, then the already-selected check, where
177 already selected eBGP routes are preferred, is skipped.
179 If a route has an `ORIGINATOR_ID` attribute because it has been reflected,
180 that `ORIGINATOR_ID` will be used. Otherwise, the router-ID of the peer the
181 route was received from will be used.
183 The advantage of this is that the route-selection (at this point) will be
184 more deterministic. The disadvantage is that a few or even one lowest-ID
185 router may attract all trafic to otherwise-equal paths because of this
186 check. It may increase the possibility of MED or IGP oscillation, unless
187 other measures were taken to avoid these. The exact behaviour will be
188 sensitive to the iBGP and reflection topology.
191 .. _bgp-route-flap-dampening:
193 BGP route flap dampening
194 ------------------------
196 .. clicmd:: bgp dampening (1-45) (1-20000) (1-20000) (1-255)
198 This command enables BGP route-flap dampening and specifies dampening parameters.
201 Half-life time for the penalty
204 Value to start reusing a route
207 Value to start suppressing a route
210 Maximum duration to suppress a stable route
212 The route-flap damping algorithm is compatible with :rfc:`2439`. The use of
213 this command is not recommended nowadays.
217 `http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378 <http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378>`_
224 The BGP :abbr:`MED (Multi Exit Discriminator)` attribute has properties which
225 can cause subtle convergence problems in BGP. These properties and problems
226 have proven to be hard to understand, at least historically, and may still not
227 be widely understood. The following attempts to collect together and present
228 what is known about MED, to help operators and FRR users in designing and
229 configuring their networks.
231 The BGP :abbr:`MED` attribute is intended to allow one AS to indicate its
232 preferences for its ingress points to another AS. The MED attribute will not be
233 propagated on to another AS by the receiving AS - it is 'non-transitive' in the
236 E.g., if AS X and AS Y have 2 different BGP peering points, then AS X might set
237 a MED of 100 on routes advertised at one and a MED of 200 at the other. When AS
238 Y selects between otherwise equal routes to or via AS X, AS Y should prefer to
239 take the path via the lower MED peering of 100 with AS X. Setting the MED
240 allows an AS to influence the routing taken to it within another, neighbouring
243 In this use of MED it is not really meaningful to compare the MED value on
244 routes where the next AS on the paths differs. E.g., if AS Y also had a route
245 for some destination via AS Z in addition to the routes from AS X, and AS Z had
246 also set a MED, it wouldn't make sense for AS Y to compare AS Z's MED values to
247 those of AS X. The MED values have been set by different administrators, with
248 different frames of reference.
250 The default behaviour of BGP therefore is to not compare MED values across
251 routes received from different neighbouring ASes. In FRR this is done by
252 comparing the neighbouring, left-most AS in the received AS_PATHs of the routes
253 and only comparing MED if those are the same.
255 Unfortunately, this behaviour of MED, of sometimes being compared across routes
256 and sometimes not, depending on the properties of those other routes, means MED
257 can cause the order of preference over all the routes to be undefined. That is,
258 given routes A, B, and C, if A is preferred to B, and B is preferred to C, then
259 a well-defined order should mean the preference is transitive (in the sense of
260 orders [#med-transitivity-rant]_) and that A would be preferred to C.
262 However, when MED is involved this need not be the case. With MED it is
263 possible that C is actually preferred over A. So A is preferred to B, B is
264 preferred to C, but C is preferred to A. This can be true even where BGP
265 defines a deterministic 'most preferred' route out of the full set of A,B,C.
266 With MED, for any given set of routes there may be a deterministically
267 preferred route, but there need not be any way to arrange them into any order
268 of preference. With unmodified MED, the order of preference of routes literally
271 That MED can induce non-transitive preferences over routes can cause issues.
272 Firstly, it may be perceived to cause routing table churn locally at speakers;
273 secondly, and more seriously, it may cause routing instability in iBGP
274 topologies, where sets of speakers continually oscillate between different
277 The first issue arises from how speakers often implement routing decisions.
278 Though BGP defines a selection process that will deterministically select the
279 same route as best at any given speaker, even with MED, that process requires
280 evaluating all routes together. For performance and ease of implementation
281 reasons, many implementations evaluate route preferences in a pair-wise fashion
282 instead. Given there is no well-defined order when MED is involved, the best
283 route that will be chosen becomes subject to implementation details, such as
284 the order the routes are stored in. That may be (locally) non-deterministic,
285 e.g.: it may be the order the routes were received in.
287 This indeterminism may be considered undesirable, though it need not cause
288 problems. It may mean additional routing churn is perceived, as sometimes more
289 updates may be produced than at other times in reaction to some event .
291 This first issue can be fixed with a more deterministic route selection that
292 ensures routes are ordered by the neighbouring AS during selection.
293 :clicmd:`bgp deterministic-med`. This may reduce the number of updates as routes
294 are received, and may in some cases reduce routing churn. Though, it could
295 equally deterministically produce the largest possible set of updates in
296 response to the most common sequence of received updates.
298 A deterministic order of evaluation tends to imply an additional overhead of
299 sorting over any set of n routes to a destination. The implementation of
300 deterministic MED in FRR scales significantly worse than most sorting
301 algorithms at present, with the number of paths to a given destination. That
302 number is often low enough to not cause any issues, but where there are many
303 paths, the deterministic comparison may quickly become increasingly expensive
306 Deterministic local evaluation can *not* fix the second, more major, issue of
307 MED however. Which is that the non-transitive preference of routes MED can
308 cause may lead to routing instability or oscillation across multiple speakers
309 in iBGP topologies. This can occur with full-mesh iBGP, but is particularly
310 problematic in non-full-mesh iBGP topologies that further reduce the routing
311 information known to each speaker. This has primarily been documented with iBGP
312 route-reflection topologies. However, any route-hiding technologies potentially
313 could also exacerbate oscillation with MED.
315 This second issue occurs where speakers each have only a subset of routes, and
316 there are cycles in the preferences between different combinations of routes -
317 as the undefined order of preference of MED allows - and the routes are
318 distributed in a way that causes the BGP speakers to 'chase' those cycles. This
319 can occur even if all speakers use a deterministic order of evaluation in route
322 E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X, and from
323 speaker 3 in AS Y; while speaker 5 in AS A might receive that route from
324 speaker 1 in AS Y. AS Y might set a MED of 200 at speaker 1, and 100 at speaker
325 3. I.e, using ASN:ID:MED to label the speakers:
331 X:2------|--A:4-------A:5--|-Y:1:200
337 Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs), then based
338 on the RFC4271 decision process speaker 4 will choose X:2 over Y:3:100, based
339 on the lower ID of 2. Speaker 4 advertises X:2 to speaker 5. Speaker 5 will
340 continue to prefer Y:1:200 based on the ID, and advertise this to speaker 4.
341 Speaker 4 will now have the full set of routes, and the Y:1:200 it receives
342 from 5 will beat X:2, but when speaker 4 compares Y:1:200 to Y:3:100 the MED
343 check now becomes active as the ASes match, and now Y:3:100 is preferred.
344 Speaker 4 therefore now advertises Y:3:100 to 5, which will also agrees that
345 Y:3:100 is preferred to Y:1:200, and so withdraws the latter route from 4.
346 Speaker 4 now has only X:2 and Y:3:100, and X:2 beats Y:3:100, and so speaker 4
347 implicitly updates its route to speaker 5 to X:2. Speaker 5 sees that Y:1:200
348 beats X:2 based on the ID, and advertises Y:1:200 to speaker 4, and the cycle
351 The root cause is the lack of a clear order of preference caused by how MED
352 sometimes is and sometimes is not compared, leading to this cycle in the
353 preferences between the routes:
358 /---> X:2 ---beats---> Y:3:100 --\\
361 \\---beats--- Y:1:200 <---beats---/
365 This particular type of oscillation in full-mesh iBGP topologies can be
366 avoided by speakers preferring already selected, external routes rather than
367 choosing to update to new a route based on a post-MED metric (e.g. router-ID),
368 at the cost of a non-deterministic selection process. FRR implements this, as
369 do many other implementations, so long as it is not overridden by setting
370 :clicmd:`bgp bestpath compare-routerid`, and see also
371 :ref:`bgp-decision-process`.
373 However, more complex and insidious cycles of oscillation are possible with
374 iBGP route-reflection, which are not so easily avoided. These have been
375 documented in various places. See, e.g.:
377 - [bgp-route-osci-cond]_
378 - [stable-flexible-ibgp]_
379 - [ibgp-correctness]_
381 for concrete examples and further references.
383 There is as of this writing *no* known way to use MED for its original purpose;
384 *and* reduce routing information in iBGP topologies; *and* be sure to avoid the
385 instability problems of MED due the non-transitive routing preferences it can
386 induce; in general on arbitrary networks.
388 There may be iBGP topology specific ways to reduce the instability risks, even
389 while using MED, e.g.: by constraining the reflection topology and by tuning
390 IGP costs between route-reflector clusters, see :rfc:`3345` for details. In the
391 near future, the Add-Path extension to BGP may also solve MED oscillation while
392 still allowing MED to be used as intended, by distributing "best-paths per
393 neighbour AS". This would be at the cost of distributing at least as many
394 routes to all speakers as a full-mesh iBGP would, if not more, while also
395 imposing similar CPU overheads as the "Deterministic MED" feature at each
398 More generally, the instability problems that MED can introduce on more
399 complex, non-full-mesh, iBGP topologies may be avoided either by:
401 - Setting :clicmd:`bgp always-compare-med`, however this allows MED to be compared
402 across values set by different neighbour ASes, which may not produce
403 coherent desirable results, of itself.
404 - Effectively ignoring MED by setting MED to the same value (e.g.: 0) using
405 :clicmd:`set metric METRIC` on all received routes, in combination with
406 setting :clicmd:`bgp always-compare-med` on all speakers. This is the simplest
407 and most performant way to avoid MED oscillation issues, where an AS is happy
408 not to allow neighbours to inject this problematic metric.
410 As MED is evaluated after the AS_PATH length check, another possible use for
411 MED is for intra-AS steering of routes with equal AS_PATH length, as an
412 extension of the last case above. As MED is evaluated before IGP metric, this
413 can allow cold-potato routing to be implemented to send traffic to preferred
414 hand-offs with neighbours, rather than the closest hand-off according to the
417 Note that even if action is taken to address the MED non-transitivity issues,
418 other oscillations may still be possible. E.g., on IGP cost if iBGP and IGP
419 topologies are at cross-purposes with each other - see the Flavel and Roughan
420 paper above for an example. Hence the guideline that the iBGP topology should
421 follow the IGP topology.
423 .. index:: bgp deterministic-med
424 .. clicmd:: bgp deterministic-med
426 Carry out route-selection in way that produces deterministic answers
427 locally, even in the face of MED and the lack of a well-defined order of
428 preference it can induce on routes. Without this option the preferred route
429 with MED may be determined largely by the order that routes were received
432 Setting this option will have a performance cost that may be noticeable when
433 there are many routes for each destination. Currently in FRR it is
434 implemented in a way that scales poorly as the number of routes per
435 destination increases.
437 The default is that this option is not set.
439 Note that there are other sources of indeterminism in the route selection
440 process, specifically, the preference for older and already selected routes
441 from eBGP peers, :ref:`bgp-decision-process`.
443 .. index:: bgp always-compare-med
444 .. clicmd:: bgp always-compare-med
446 Always compare the MED on routes, even when they were received from
447 different neighbouring ASes. Setting this option makes the order of
448 preference of routes more defined, and should eliminate MED induced
451 If using this option, it may also be desirable to use
452 :clicmd:`set metric METRIC` to set MED to 0 on routes received from external
455 This option can be used, together with :clicmd:`set metric METRIC` to use
456 MED as an intra-AS metric to steer equal-length AS_PATH routes to, e.g.,
470 .. index:: network A.B.C.D/M
471 .. clicmd:: network A.B.C.D/M
473 This command adds the announcement network.
478 address-family ipv4 unicast
482 This configuration example says that network 10.0.0.0/8 will be
483 announced to all neighbors. Some vendors' routers don't advertise
484 routes if they aren't present in their IGP routing tables; `bgpd`
485 doesn't care about IGP routes when announcing its routes.
487 .. index:: no network A.B.C.D/M
488 .. clicmd:: no network A.B.C.D/M
491 .. _route-aggregation:
496 .. index:: aggregate-address A.B.C.D/M
497 .. clicmd:: aggregate-address A.B.C.D/M
499 This command specifies an aggregate address.
501 .. index:: aggregate-address A.B.C.D/M as-set
502 .. clicmd:: aggregate-address A.B.C.D/M as-set
504 This command specifies an aggregate address. Resulting routes include
507 .. index:: aggregate-address A.B.C.D/M summary-only
508 .. clicmd:: aggregate-address A.B.C.D/M summary-only
510 This command specifies an aggregate address. Aggreated routes will
513 .. index:: no aggregate-address A.B.C.D/M
514 .. clicmd:: no aggregate-address A.B.C.D/M
518 .. _redistribute-to-bgp:
523 .. index:: redistribute kernel
524 .. clicmd:: redistribute kernel
526 Redistribute kernel route to BGP process.
528 .. index:: redistribute static
529 .. clicmd:: redistribute static
531 Redistribute static route to BGP process.
533 .. index:: redistribute connected
534 .. clicmd:: redistribute connected
536 Redistribute connected route to BGP process.
538 .. index:: redistribute rip
539 .. clicmd:: redistribute rip
541 Redistribute RIP route to BGP process.
543 .. index:: redistribute ospf
544 .. clicmd:: redistribute ospf
546 Redistribute OSPF route to BGP process.
548 .. index:: redistribute vpn
549 .. clicmd:: redistribute vpn
551 Redistribute VNC routes to BGP process.
553 .. index:: update-delay MAX-DELAY
554 .. clicmd:: update-delay MAX-DELAY
556 .. index:: update-delay MAX-DELAY ESTABLISH-WAIT
557 .. clicmd:: update-delay MAX-DELAY ESTABLISH-WAIT
559 This feature is used to enable read-only mode on BGP process restart or when
560 BGP process is cleared using 'clear ip bgp \*'. When applicable, read-only
561 mode would begin as soon as the first peer reaches Established status and a
562 timer for max-delay seconds is started.
564 During this mode BGP doesn't run any best-path or generate any updates to its
565 peers. This mode continues until:
567 1. All the configured peers, except the shutdown peers, have sent explicit EOR
568 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
569 Established is considered an implicit-EOR.
570 If the establish-wait optional value is given, then BGP will wait for
571 peers to reach established from the begining of the update-delay till the
572 establish-wait period is over, i.e. the minimum set of established peers for
573 which EOR is expected would be peers established during the establish-wait
574 window, not necessarily all the configured neighbors.
575 2. max-delay period is over.
577 On hitting any of the above two conditions, BGP resumes the decision process
578 and generates updates to its peers.
580 Default max-delay is 0, i.e. the feature is off by default.
582 .. index:: table-map ROUTE-MAP-NAME
583 .. clicmd:: table-map ROUTE-MAP-NAME
585 This feature is used to apply a route-map on route updates from BGP to
586 Zebra. All the applicable match operations are allowed, such as match on
587 prefix, next-hop, communities, etc. Set operations for this attach-point are
588 limited to metric and next-hop only. Any operation of this feature does not
589 affect BGPs internal RIB.
591 Supported for ipv4 and ipv6 address families. It works on multi-paths as
592 well, however, metric setting is based on the best-path only.
604 .. index:: neighbor PEER remote-as ASN
605 .. clicmd:: neighbor PEER remote-as ASN
607 Creates a new neighbor whose remote-as is ASN. PEER can be an IPv4 address
608 or an IPv6 address or an interface to use for the connection.
613 neighbor 10.0.0.1 remote-as 2
615 In this case my router, in AS-1, is trying to peer with AS-2 at 10.0.0.1.
617 This command must be the first command used when configuring a neighbor. If
618 the remote-as is not specified, *bgpd* will complain like this: ::
620 can't find neighbor 10.0.0.1
622 .. index:: neighbor PEER remote-as internal
623 .. clicmd:: neighbor PEER remote-as internal
625 Create a peer as you would when you specify an ASN, except that if the
626 peers ASN is different than mine as specified under the :clicmd:`router bgp ASN`
627 command the connection will be denied.
629 .. index:: neighbor PEER remote-as external
630 .. clicmd:: neighbor PEER remote-as external
632 Create a peer as you would when you specify an ASN, except that if the
633 peers ASN is the same as mine as specified under the :clicmd:`router bgp ASN`
634 command the connection will be denied.
636 .. _bgp-peer-commands:
641 In a `router bgp` clause there are neighbor specific configurations
644 .. index:: neighbor PEER shutdown
645 .. clicmd:: neighbor PEER shutdown
647 .. index:: no neighbor PEER shutdown
648 .. clicmd:: no neighbor PEER shutdown
650 Shutdown the peer. We can delete the neighbor's configuration by
651 ``no neighbor PEER remote-as ASN`` but all configuration of the neighbor
652 will be deleted. When you want to preserve the configuration, but want to
653 drop the BGP peer, use this syntax.
655 .. index:: neighbor PEER ebgp-multihop
656 .. clicmd:: neighbor PEER ebgp-multihop
658 .. index:: no neighbor PEER ebgp-multihop
659 .. clicmd:: no neighbor PEER ebgp-multihop
662 .. index:: neighbor PEER description ...
663 .. clicmd:: neighbor PEER description ...
666 .. index:: no neighbor PEER description ...
667 .. clicmd:: no neighbor PEER description ...
669 Set description of the peer.
671 .. index:: neighbor PEER version VERSION
672 .. clicmd:: neighbor PEER version VERSION
674 Set up the neighbor's BGP version. `version` can be `4`, `4+` or `4-`. BGP
675 version `4` is the default value used for BGP peering. BGP version `4+`
676 means that the neighbor supports Multiprotocol Extensions for BGP-4. BGP
677 version `4-` is similar but the neighbor speaks the old Internet-Draft
678 revision 00's Multiprotocol Extensions for BGP-4. Some routing software is
679 still using this version.
681 .. index:: neighbor PEER interface IFNAME
682 .. clicmd:: neighbor PEER interface IFNAME
685 .. index:: no neighbor PEER interface IFNAME
686 .. clicmd:: no neighbor PEER interface IFNAME
688 When you connect to a BGP peer over an IPv6 link-local address, you have to
689 specify the IFNAME of the interface used for the connection. To specify
690 IPv4 session addresses, see the ``neighbor PEER update-source`` command
693 This command is deprecated and may be removed in a future release. Its use
696 .. index:: neighbor PEER next-hop-self [all]
697 .. clicmd:: neighbor PEER next-hop-self [all]
700 .. index:: no neighbor PEER next-hop-self [all]
701 .. clicmd:: no neighbor PEER next-hop-self [all]
703 This command specifies an announced route's nexthop as being equivalent to
704 the address of the bgp router if it is learned via eBGP. If the optional
705 keyword `all` is specified the modifiation is done also for routes learned
708 .. index:: neighbor PEER update-source <IFNAME|ADDRESS>
709 .. clicmd:: neighbor PEER update-source <IFNAME|ADDRESS>
712 .. index:: no neighbor PEER update-source
713 .. clicmd:: no neighbor PEER update-source
715 Specify the IPv4 source address to use for the :abbr:`BGP` session to this
716 neighbour, may be specified as either an IPv4 address directly or as an
717 interface name (in which case the *zebra* daemon MUST be running in order
718 for *bgpd* to be able to retrieve interface state).
723 neighbor foo update-source 192.168.0.1
724 neighbor bar update-source lo0
727 .. index:: neighbor PEER default-originate
728 .. clicmd:: neighbor PEER default-originate
730 .. index:: no neighbor PEER default-originate
731 .. clicmd:: no neighbor PEER default-originate
733 *bgpd*'s default is to not announce the default route (0.0.0.0/0) even if it
734 is in routing table. When you want to announce default routes to the peer,
737 .. index:: neighbor PEER port PORT
738 .. clicmd:: neighbor PEER port PORT
740 .. index:: neighbor PEER send-community
741 .. clicmd:: neighbor PEER send-community
743 .. index:: neighbor PEER weight WEIGHT
744 .. clicmd:: neighbor PEER weight WEIGHT
747 .. index:: no neighbor PEER weight WEIGHT
748 .. clicmd:: no neighbor PEER weight WEIGHT
750 This command specifies a default `weight` value for the neighbor's routes.
752 .. index:: neighbor PEER maximum-prefix NUMBER
753 .. clicmd:: neighbor PEER maximum-prefix NUMBER
756 .. index:: no neighbor PEER maximum-prefix NUMBER
757 .. clicmd:: no neighbor PEER maximum-prefix NUMBER
760 .. index:: neighbor PEER local-as AS-NUMBER
761 .. clicmd:: neighbor PEER local-as AS-NUMBER
764 .. index:: neighbor PEER local-as AS-NUMBER no-prepend
765 .. clicmd:: neighbor PEER local-as AS-NUMBER no-prepend
768 .. index:: neighbor PEER local-as AS-NUMBER no-prepend replace-as
769 .. clicmd:: neighbor PEER local-as AS-NUMBER no-prepend replace-as
772 .. index:: no neighbor PEER local-as
773 .. clicmd:: no neighbor PEER local-as
775 Specify an alternate AS for this BGP process when interacting with the
776 specified peer. With no modifiers, the specified local-as is prepended to
777 the received AS_PATH when receiving routing updates from the peer, and
778 prepended to the outgoing AS_PATH (after the process local AS) when
779 transmitting local routes to the peer.
781 If the no-prepend attribute is specified, then the supplied local-as is not
782 prepended to the received AS_PATH.
784 If the replace-as attribute is specified, then only the supplied local-as is
785 prepended to the AS_PATH when transmitting local-route updates to this peer.
787 Note that replace-as can only be specified if no-prepend is.
789 This command is only allowed for eBGP peers.
791 .. index:: neighbor PEER ttl-security hops NUMBER
792 .. clicmd:: neighbor PEER ttl-security hops NUMBER
795 .. index:: no neighbor PEER ttl-security hops NUMBER
796 .. clicmd:: no neighbor PEER ttl-security hops NUMBER
798 This command enforces Generalized TTL Security Mechanism (GTSM), as
799 specified in RFC 5082. With this command, only neighbors that are the
800 specified number of hops away will be allowed to become neighbors. This
801 command is mututally exclusive with *ebgp-multihop*.
808 .. index:: neighbor PEER distribute-list NAME [in|out]
809 .. clicmd:: neighbor PEER distribute-list NAME [in|out]
811 This command specifies a distribute-list for the peer. `direct` is
814 .. index:: neighbor PEER prefix-list NAME [in|out]
815 .. clicmd:: neighbor PEER prefix-list NAME [in|out]
817 .. index:: neighbor PEER filter-list NAME [in|out]
818 .. clicmd:: neighbor PEER filter-list NAME [in|out]
820 .. index:: neighbor PEER route-map NAME [in|out]
821 .. clicmd:: neighbor PEER route-map NAME [in|out]
823 Apply a route-map on the neighbor. `direct` must be `in` or `out`.
825 .. index:: bgp route-reflector allow-outbound-policy
826 .. clicmd:: bgp route-reflector allow-outbound-policy
828 By default, attribute modification via route-map policy out is not reflected
829 on reflected routes. This option allows the modifications to be reflected as
830 well. Once enabled, it affects all reflected routes.
837 .. index:: neighbor WORD peer-group
838 .. clicmd:: neighbor WORD peer-group
840 This command defines a new peer group.
842 .. index:: neighbor PEER peer-group WORD
843 .. clicmd:: neighbor PEER peer-group WORD
845 This command bind specific peer to peer group WORD.
847 .. _bgp-address-family:
852 Multiprotocol BGP enables BGP to carry routing information for multiple Network
853 Layer protocols. BGP supports multiple Address Family Identifier (AFI), namely
854 IPv4 and IPv6. Support is also provided for multiple sets of per-AFI
855 information via Subsequent Address Family Identifiers (SAFI). In addition to
856 unicast information, VPN information :rfc:`4364` and :rfc:`4659`, and
857 Encapsulation attribute :rfc:`5512` is supported.
859 .. index:: show ip bgp ipv4 vpn
860 .. clicmd:: show ip bgp ipv4 vpn
862 .. index:: show ipv6 bgp ipv6 vpn
863 .. clicmd:: show ipv6 bgp ipv6 vpn
865 Print active IPV4 or IPV6 routes advertised via the VPN SAFI.
867 .. index:: show bgp ipv4 vpn summary
868 .. clicmd:: show bgp ipv4 vpn summary
870 .. index:: show bgp ipv6 vpn summary
871 .. clicmd:: show bgp ipv6 vpn summary
873 Print a summary of neighbor connections for the specified AFI/SAFI combination.
875 .. _autonomous-system:
880 The :abbr:`AS (Autonomous System)` number is one of the essential element of
881 BGP. BGP is a distance vector routing protocol, and the AS-Path framework
882 provides distance vector metric and loop detection to BGP. :rfc:`1930` provides
883 some background on the concepts of an AS.
885 The AS number is a two octet value, ranging in value from 1 to 65535. The AS
886 numbers 64512 through 65535 are defined as private AS numbers. Private AS
887 numbers must not to be advertised in the global Internet.
889 .. _display-bgp-routes-by-as-path:
891 Display BGP Routes by AS Path
892 -----------------------------
894 To show BGP routes which has specific AS path information `show ip bgp` command
897 .. index:: show bgp ipv4|ipv6 regexp LINE
898 .. clicmd:: show bgp ipv4|ipv6 regexp LINE
900 This commands displays BGP routes that matches a regular
901 expression `line` (:ref:`bgp-regular-expressions`).
903 .. _as-path-access-list:
908 AS path access list is user defined AS path.
910 .. index:: ip as-path access-list WORD permit|deny LINE
911 .. clicmd:: ip as-path access-list WORD permit|deny LINE
913 This command defines a new AS path access list.
915 .. index:: no ip as-path access-list WORD
916 .. clicmd:: no ip as-path access-list WORD
918 .. index:: no ip as-path access-list WORD permit|deny LINE
919 .. clicmd:: no ip as-path access-list WORD permit|deny LINE
921 .. _using-as-path-in-route-map:
923 Using AS Path in Route Map
924 --------------------------
926 .. index:: match as-path WORD
927 .. clicmd:: match as-path WORD
930 .. index:: set as-path prepend AS-PATH
931 .. clicmd:: set as-path prepend AS-PATH
933 Prepend the given string of AS numbers to the AS_PATH.
935 .. index:: set as-path prepend last-as NUM
936 .. clicmd:: set as-path prepend last-as NUM
938 Prepend the existing last AS number (the leftmost ASN) to the AS_PATH.
940 .. _private-as-numbers:
945 .. _bgp-communities-attribute:
947 BGP Communities Attribute
948 =========================
950 BGP communities attribute is widely used for implementing policy routing.
951 Network operators can manipulate BGP communities attribute based on their
952 network policy. BGP communities attribute is defined in :rfc:`1997` and
953 :rfc:`1998`. It is an optional transitive attribute, therefore local policy can
954 travel through different autonomous system.
956 Communities attribute is a set of communities values. Each communities value is
957 4 octet long. The following format is used to define communities value.
961 This format represents 4 octet communities value. ``AS`` is high order 2
962 octet in digit format. ``VAL`` is low order 2 octet in digit format. This
963 format is useful to define AS oriented policy value. For example,
964 ``7675:80`` can be used when AS 7675 wants to pass local policy value 80 to
968 `internet` represents well-known communities value 0.
971 ``no-export`` represents well-known communities value ``NO_EXPORT``
972 ``0xFFFFFF01``. All routes carry this value must not be advertised to
973 outside a BGP confederation boundary. If neighboring BGP peer is part of BGP
974 confederation, the peer is considered as inside a BGP confederation
975 boundary, so the route will be announced to the peer.
978 ``no-advertise`` represents well-known communities value ``NO_ADVERTISE``
979 ``0xFFFFFF02``. All routes carry this value must not be advertise to other
983 ``local-AS`` represents well-known communities value ``NO_EXPORT_SUBCONFED``
984 ``0xFFFFFF03``. All routes carry this value must not be advertised to
985 external BGP peers. Even if the neighboring router is part of confederation,
986 it is considered as external BGP peer, so the route will not be announced to
989 When BGP communities attribute is received, duplicated communities value in the
990 communities attribute is ignored and each communities values are sorted in
993 .. _bgp-community-lists:
998 BGP community list is a user defined BGP communites attribute list. BGP
999 community list can be used for matching or manipulating BGP communities
1000 attribute in updates.
1002 There are two types of community list. One is standard community list and
1003 another is expanded community list. Standard community list defines communities
1004 attribute. Expanded community list defines communities attribute string with
1005 regular expression. Standard community list is compiled into binary format when
1006 user define it. Standard community list will be directly compared to BGP
1007 communities attribute in BGP updates. Therefore the comparison is faster than
1008 expanded community list.
1010 .. index:: ip community-list standard NAME permit|deny COMMUNITY
1011 .. clicmd:: ip community-list standard NAME permit|deny COMMUNITY
1013 This command defines a new standard community list. COMUNITY is
1014 communities value. The COMUNITY is compiled into community structure. We
1015 can define multiple community list under same name. In that case match will
1016 happen user defined order. Once the community list matches to communities
1017 attribute in BGP updates it return permit or deny by the community list
1018 definition. When there is no matched entry, deny will be returned. When
1019 COMUNITY is empty it matches to any routes.
1021 .. index:: ip community-list expanded NAME permit|deny LINE
1022 .. clicmd:: ip community-list expanded NAME permit|deny LINE
1024 This command defines a new expanded community list. COMUNITY is a
1025 string expression of communities attribute. COMUNITY can be a
1026 regular expression (:ref:`bgp-regular-expressions`) to match
1027 the communities attribute in BGP updates.
1029 .. index:: no ip community-list NAME
1030 .. clicmd:: no ip community-list NAME
1032 .. index:: no ip community-list standard NAME
1033 .. clicmd:: no ip community-list standard NAME
1035 .. index:: no ip community-list expanded NAME
1036 .. clicmd:: no ip community-list expanded NAME
1038 These commands delete community lists specified by NAME. All of
1039 community lists shares a single name space. So community lists can be
1040 removed simpley specifying community lists name.
1042 .. index:: show ip community-list
1043 .. clicmd:: show ip community-list
1045 .. index:: show ip community-list NAME
1046 .. clicmd:: show ip community-list NAME
1048 This command displays current community list information. When NAME is
1049 specified the specified community list's information is shown.
1053 # show ip community-list
1054 Named Community standard list CLIST
1055 permit 7675:80 7675:100 no-export
1057 Named Community expanded list EXPAND
1060 # show ip community-list CLIST
1061 Named Community standard list CLIST
1062 permit 7675:80 7675:100 no-export
1066 .. _numbered-bgp-community-lists:
1068 Numbered BGP Community Lists
1069 ----------------------------
1071 When number is used for BGP community list name, the number has
1072 special meanings. Community list number in the range from 1 and 99 is
1073 standard community list. Community list number in the range from 100
1074 to 199 is expanded community list. These community lists are called
1075 as numbered community lists. On the other hand normal community lists
1076 is called as named community lists.
1078 .. index:: ip community-list (1-99) permit|deny COMMUNITY
1079 .. clicmd:: ip community-list (1-99) permit|deny COMMUNITY
1081 This command defines a new community list. (1-99) is standard
1082 community list number. Community list name within this range defines
1083 standard community list. When `community` is empty it matches to
1086 .. index:: ip community-list (100-199) permit|deny COMMUNITY
1087 .. clicmd:: ip community-list (100-199) permit|deny COMMUNITY
1089 This command defines a new community list. (100-199) is expanded
1090 community list number. Community list name within this range defines
1091 expanded community list.
1093 .. index:: ip community-list NAME permit|deny COMMUNITY
1094 .. clicmd:: ip community-list NAME permit|deny COMMUNITY
1096 When community list type is not specifed, the community list type is
1097 automatically detected. If COMMUNITY can be compiled into communities
1098 attribute, the community list is defined as a standard community list.
1099 Otherwise it is defined as an expanded community list. This feature is left
1100 for backward compability. Use of this feature is not recommended.
1102 .. _bgp-community-in-route-map:
1104 BGP Community in Route Map
1105 --------------------------
1107 In Route Map (:ref:`route-map`), we can match or set BGP
1108 communities attribute. Using this feature network operator can
1109 implement their network policy based on BGP communities attribute.
1111 Following commands can be used in Route Map.
1113 .. index:: match community WORD
1114 .. clicmd:: match community WORD
1116 .. index:: match community WORD exact-match
1117 .. clicmd:: match community WORD exact-match
1119 This command perform match to BGP updates using community list WORD. When
1120 the one of BGP communities value match to the one of communities value in
1121 community list, it is match. When `exact-match` keyword is spcified, match
1122 happen only when BGP updates have completely same communities value
1123 specified in the community list.
1125 .. index:: set community none
1126 .. clicmd:: set community none
1128 .. index:: set community COMMUNITY
1129 .. clicmd:: set community COMMUNITY
1131 .. index:: set community COMMUNITY additive
1132 .. clicmd:: set community COMMUNITY additive
1134 This command manipulate communities value in BGP updates. When
1135 `none` is specified as communities value, it removes entire
1136 communities attribute from BGP updates. When `community` is not
1137 `none`, specified communities value is set to BGP updates. If
1138 BGP updates already has BGP communities value, the existing BGP
1139 communities value is replaced with specified `community` value.
1140 When `additive` keyword is specified, `community` is appended
1141 to the existing communities value.
1143 .. index:: set comm-list WORD delete
1144 .. clicmd:: set comm-list WORD delete
1146 This command remove communities value from BGP communities attribute.
1147 The `word` is community list name. When BGP route's communities
1148 value matches to the community list `word`, the communities value
1149 is removed. When all of communities value is removed eventually, the
1150 BGP update's communities attribute is completely removed.
1152 .. _display-bgp-routes-by-community:
1154 Display BGP Routes by Community
1155 -------------------------------
1157 To show BGP routes which has specific BGP communities attribute,
1158 `show bgp {ipv4|ipv6}` command can be used. The
1159 `community` and `community-list` subcommand can be used.
1161 .. index:: show bgp ipv4|ipv6 community
1162 .. clicmd:: show bgp ipv4|ipv6 community
1164 .. index:: show bgp ipv4|ipv6 community COMMUNITY
1165 .. clicmd:: show bgp ipv4|ipv6 community COMMUNITY
1167 .. index:: show bgp ipv4|ipv6 community COMMUNITY exact-match
1168 .. clicmd:: show bgp ipv4|ipv6 community COMMUNITY exact-match
1170 `show bgp {ipv4|ipv6} community` displays BGP routes which has communities
1171 attribute. Where the address family can be IPv4 or IPv6 among others. When
1172 `community` is specified, BGP routes that matches `community` value is
1173 displayed. For this command, `internet` keyword can't be used for
1174 `community` value. When `exact-match` is specified, it display only
1175 routes that have an exact match.
1177 .. index:: show bgp ipv4|ipv6 community-list WORD
1178 .. clicmd:: show bgp ipv4|ipv6 community-list WORD
1180 .. index:: show bgp ipv4|ipv6 community-list WORD exact-match
1181 .. clicmd:: show bgp ipv4|ipv6 community-list WORD exact-match
1183 This commands display BGP routes for the address family specified that matches
1184 community list `word`. When `exact-match` is specified, display only
1185 routes that have an exact match.
1187 .. _using-bgp-communities-attribute:
1189 Using BGP Communities Attribute
1190 -------------------------------
1192 Following configuration is the most typical usage of BGP communities
1193 attribute. AS 7675 provides upstream Internet connection to AS 100.
1194 When following configuration exists in AS 7675, AS 100 networks
1195 operator can set local preference in AS 7675 network by setting BGP
1196 communities attribute to the updates.
1202 neighbor 192.168.0.1 remote-as 100
1203 address-family ipv4 unicast
1204 neighbor 192.168.0.1 route-map RMAP in
1207 ip community-list 70 permit 7675:70
1208 ip community-list 70 deny
1209 ip community-list 80 permit 7675:80
1210 ip community-list 80 deny
1211 ip community-list 90 permit 7675:90
1212 ip community-list 90 deny
1214 route-map RMAP permit 10
1216 set local-preference 70
1218 route-map RMAP permit 20
1220 set local-preference 80
1222 route-map RMAP permit 30
1224 set local-preference 90
1227 Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675.
1228 The route has communities value 7675:80 so when above configuration
1229 exists in AS 7675, announced route's local preference will be set to
1236 neighbor 192.168.0.2 remote-as 7675
1237 address-family ipv4 unicast
1238 neighbor 192.168.0.2 route-map RMAP out
1241 ip prefix-list PLIST permit 10.0.0.0/8
1243 route-map RMAP permit 10
1244 match ip address prefix-list PLIST
1245 set community 7675:80
1248 Following configuration is an example of BGP route filtering using
1249 communities attribute. This configuration only permit BGP routes
1250 which has BGP communities value 0:80 or 0:90. Network operator can
1251 put special internal communities value at BGP border router, then
1252 limit the BGP routes announcement into the internal network.
1257 neighbor 192.168.0.1 remote-as 100
1258 address-family ipv4 unicast
1259 neighbor 192.168.0.1 route-map RMAP in
1262 ip community-list 1 permit 0:80 0:90
1264 route-map RMAP permit in
1268 Following exmaple filter BGP routes which has communities value 1:1.
1269 When there is no match community-list returns deny. To avoid
1270 filtering all of routes, we need to define permit any at last.
1275 neighbor 192.168.0.1 remote-as 100
1276 address-family ipv4 unicast
1277 neighbor 192.168.0.1 route-map RMAP in
1280 ip community-list standard FILTER deny 1:1
1281 ip community-list standard FILTER permit
1283 route-map RMAP permit 10
1284 match community FILTER
1287 Communities value keyword `internet` has special meanings in
1288 standard community lists. In below example `internet` act as
1289 match any. It matches all of BGP routes even if the route does not
1290 have communities attribute at all. So community list ``INTERNET``
1291 is same as above example's ``FILTER``.
1295 ip community-list standard INTERNET deny 1:1
1296 ip community-list standard INTERNET permit internet
1299 Following configuration is an example of communities value deletion.
1300 With this configuration communities value 100:1 and 100:2 is removed
1301 from BGP updates. For communities value deletion, only `permit`
1302 community-list is used. `deny` community-list is ignored.
1307 neighbor 192.168.0.1 remote-as 100
1308 address-family ipv4 unicast
1309 neighbor 192.168.0.1 route-map RMAP in
1312 ip community-list standard DEL permit 100:1 100:2
1314 route-map RMAP permit 10
1315 set comm-list DEL delete
1318 .. _bgp-extended-communities-attribute:
1320 BGP Extended Communities Attribute
1321 ==================================
1323 BGP extended communities attribute is introduced with MPLS VPN/BGP technology.
1324 MPLS VPN/BGP expands capability of network infrastructure to provide VPN
1325 functionality. At the same time it requires a new framework for policy routing.
1326 With BGP Extended Communities Attribute we can use Route Target or Site of
1327 Origin for implementing network policy for MPLS VPN/BGP.
1329 BGP Extended Communities Attribute is similar to BGP Communities Attribute. It
1330 is an optional transitive attribute. BGP Extended Communities Attribute can
1331 carry multiple Extended Community value. Each Extended Community value is
1334 BGP Extended Communities Attribute provides an extended range compared with BGP
1335 Communities Attribute. Adding to that there is a type field in each value to
1336 provides community space structure.
1338 There are two format to define Extended Community value. One is AS based format
1339 the other is IP address based format.
1342 This is a format to define AS based Extended Community value.
1343 `AS` part is 2 octets Global Administrator subfield in Extended
1344 Community value. `VAL` part is 4 octets Local Administrator
1345 subfield. `7675:100` represents AS 7675 policy value 100.
1348 This is a format to define IP address based Extended Community value.
1349 `IP-Address` part is 4 octets Global Administrator subfield.
1350 `VAL` part is 2 octets Local Administrator subfield.
1351 `10.0.0.1:100` represents
1353 .. _bgp-extended-community-lists:
1355 BGP Extended Community Lists
1356 ----------------------------
1358 Expanded Community Lists is a user defined BGP Expanded Community
1361 .. index:: ip extcommunity-list standard NAME permit|deny EXTCOMMUNITY
1362 .. clicmd:: ip extcommunity-list standard NAME permit|deny EXTCOMMUNITY
1364 This command defines a new standard extcommunity-list. `extcommunity` is
1365 extended communities value. The `extcommunity` is compiled into extended
1366 community structure. We can define multiple extcommunity-list under same
1367 name. In that case match will happen user defined order. Once the
1368 extcommunity-list matches to extended communities attribute in BGP updates
1369 it return permit or deny based upon the extcommunity-list definition. When
1370 there is no matched entry, deny will be returned. When `extcommunity` is
1371 empty it matches to any routes.
1373 .. index:: ip extcommunity-list expanded NAME permit|deny LINE
1374 .. clicmd:: ip extcommunity-list expanded NAME permit|deny LINE
1376 This command defines a new expanded extcommunity-list. `line` is a string
1377 expression of extended communities attribute. `line` can be a regular
1378 expression (:ref:`bgp-regular-expressions`) to match an extended communities
1379 attribute in BGP updates.
1381 .. index:: no ip extcommunity-list NAME
1382 .. clicmd:: no ip extcommunity-list NAME
1384 .. index:: no ip extcommunity-list standard NAME
1385 .. clicmd:: no ip extcommunity-list standard NAME
1387 .. index:: no ip extcommunity-list expanded NAME
1388 .. clicmd:: no ip extcommunity-list expanded NAME
1390 These commands delete extended community lists specified by `name`. All of
1391 extended community lists shares a single name space. So extended community
1392 lists can be removed simpley specifying the name.
1394 .. index:: show ip extcommunity-list
1395 .. clicmd:: show ip extcommunity-list
1397 .. index:: show ip extcommunity-list NAME
1398 .. clicmd:: show ip extcommunity-list NAME
1400 This command displays current extcommunity-list information. When `name` is
1401 specified the community list's information is shown.::
1403 # show ip extcommunity-list
1406 .. _bgp-extended-communities-in-route-map:
1408 BGP Extended Communities in Route Map
1409 -------------------------------------
1411 .. index:: match extcommunity WORD
1412 .. clicmd:: match extcommunity WORD
1415 .. index:: set extcommunity rt EXTCOMMUNITY
1416 .. clicmd:: set extcommunity rt EXTCOMMUNITY
1418 This command set Route Target value.
1420 .. index:: set extcommunity soo EXTCOMMUNITY
1421 .. clicmd:: set extcommunity soo EXTCOMMUNITY
1423 This command set Site of Origin value.
1425 .. _bgp-large-communities-attribute:
1427 BGP Large Communities Attribute
1428 ===============================
1430 The BGP Large Communities attribute was introduced in Feb 2017 with
1433 The BGP Large Communities Attribute is similar to the BGP Communities
1434 Attribute except that it has 3 components instead of two and each of
1435 which are 4 octets in length. Large Communities bring additional
1436 functionality and convenience over traditional communities, specifically
1437 the fact that the `GLOBAL` part below is now 4 octets wide allowing
1438 AS4 operators seamless use.
1441 *GLOBAL:LOCAL1:LOCAL2*
1442 This is the format to define Large Community values. Referencing
1443 :t:`RFC8195, Use of BGP Large Communities` the values are commonly
1444 referred to as follows.
1445 The `GLOBAL` part is a 4 octet Global Administrator field, common
1446 use of this field is the operators AS number.
1447 The `LOCAL1` part is a 4 octet Local Data Part 1 subfield referred
1449 The `LOCAL2` part is a 4 octet Local Data Part 2 field and referred
1450 to as the parameter subfield. `65551:1:10` represents AS 65551
1451 function 1 and parameter 10.
1452 The referenced RFC above gives some guidelines on recommended usage.
1454 .. _bgp-large-community-lists:
1456 BGP Large Community Lists
1457 -------------------------
1459 Two types of large community lists are supported, namely `standard` and
1462 .. index:: ip large-community-list standard NAME permit|deny LARGE-COMMUNITY
1463 .. clicmd:: ip large-community-list standard NAME permit|deny LARGE-COMMUNITY
1465 This command defines a new standard large-community-list. `large-community`
1466 is the Large Community value. We can add multiple large communities under
1467 same name. In that case the match will happen in the user defined order.
1468 Once the large-community-list matches the Large Communities attribute in BGP
1469 updates it will return permit or deny based upon the large-community-list
1470 definition. When there is no matched entry, a deny will be returned. When
1471 `large-community` is empty it matches any routes.
1473 .. index:: ip large-community-list expanded NAME permit|deny LINE
1474 .. clicmd:: ip large-community-list expanded NAME permit|deny LINE
1476 This command defines a new expanded large-community-list. Where `line` is a
1477 string matching expression, it will be compared to the entire Large
1478 Communities attribute as a string, with each large-community in order from
1479 lowest to highest. `line` can also be a regular expression which matches
1480 this Large Community attribute.
1482 .. index:: no ip large-community-list NAME
1483 .. clicmd:: no ip large-community-list NAME
1485 .. index:: no ip large-community-list standard NAME
1486 .. clicmd:: no ip large-community-list standard NAME
1488 .. index:: no ip large-community-list expanded NAME
1489 .. clicmd:: no ip large-community-list expanded NAME
1491 These commands delete Large Community lists specified by `name`. All Large
1492 Community lists share a single namespace. This means Large Community lists
1493 can be removed by simply specifying the name.
1495 .. index:: show ip large-community-list
1496 .. clicmd:: show ip large-community-list
1498 .. index:: show ip large-community-list NAME
1499 .. clicmd:: show ip large-community-list NAME
1501 This command display current large-community-list information. When
1502 `name` is specified the community list information is shown.
1504 .. index:: show ip bgp large-community-info
1505 .. clicmd:: show ip bgp large-community-info
1507 This command displays the current large communities in use.
1509 .. _bgp-large-communities-in-route-map:
1511 BGP Large Communities in Route Map
1512 ----------------------------------
1514 .. index:: match large-community LINE
1515 .. clicmd:: match large-community LINE
1517 Where `line` can be a simple string to match, or a regular expression. It
1518 is very important to note that this match occurs on the entire
1519 large-community string as a whole, where each large-community is ordered
1520 from lowest to highest.
1522 .. index:: set large-community LARGE-COMMUNITY
1523 .. clicmd:: set large-community LARGE-COMMUNITY
1525 .. index:: set large-community LARGE-COMMUNITY LARGE-COMMUNITY
1526 .. clicmd:: set large-community LARGE-COMMUNITY LARGE-COMMUNITY
1528 .. index:: set large-community LARGE-COMMUNITY additive
1529 .. clicmd:: set large-community LARGE-COMMUNITY additive
1531 These commands are used for setting large-community values. The first
1532 command will overwrite any large-communities currently present.
1533 The second specifies two large-communities, which overwrites the current
1534 large-community list. The third will add a large-community value without
1535 overwriting other values. Multiple large-community values can be specified.
1543 Bgpd supports multiple VRF instances via the *router bgp* command:
1545 .. index:: router bgp ASN vrf VRFNAME
1546 .. clicmd:: router bgp ASN vrf VRFNAME
1548 VRFNAME is matched against VRFs configured in the kernel. When no *vrf VRFNAME*
1549 is specified, the BGP protocol process belongs to the default VRF.
1551 BGP routes may be leaked (i.e., copied) between a unicast VRF RIB and the VPN
1552 safi RIB of the default VRF (leaking is also permitted between the unicast RIB
1553 of the default VRF and VPN). A common application of this feature is to
1554 connect a customer's private routing domain to a provider's VPN service.
1555 Leaking is configured from the point of view of an individual VRF: ``import``
1556 refers to routes leaked from VPN to a unicast VRF, whereas ``export`` refers to
1557 routes leaked from a unicast VRF to VPN.
1562 Routes exported from a unicast VRF to the VPN RIB must be augmented by two
1565 - an :abbr:`RD (Route Distinguisher)`
1566 - an :abbr:`RTLIST (Route-target List)`
1568 Configuration for these exported routes must, at a minimum, specify these two
1571 Routes imported from the VPN RIB to a unicast VRF are selected according to
1572 their RTLISTs. Routes whose RTLIST contains at least one route-target in
1573 common with the configured import RTLIST are leaked. Configuration for these
1574 imported routes must specify an RTLIST to be matched.
1576 The RD, which carries no semantic value, is intended to make the route unique
1577 in the VPN RIB among all routes of its prefix that originate from all the
1578 customers and sites that are attached to the provider's VPN service.
1579 Accordingly, each site of each customer is typically assigned an RD that is
1580 unique across the entire provider network.
1582 The RTLIST is a set of route-target extended community values whose purpose is
1583 to specify route-leaking policy. Typically, a customer is assigned a single
1584 route-target value for import and export to be used at all customer sites. This
1585 configuration specifies a simple topology wherein a customer has a single
1586 routing domain which is shared across all its sites. More complex routing
1587 topologies are possible through use of additional route-targets to augment the
1588 leaking of sets of routes in various ways.
1593 Configuration of route leaking between a unicast VRF RIB and the VPN safi RIB
1594 of the default VRF is accomplished via commands in the context of a VRF
1597 .. index:: rd vpn export AS:NN|IP:nn
1598 .. clicmd:: rd vpn export AS:NN|IP:nn
1600 Specifies the route distinguisher to be added to a route exported from the
1601 current unicast VRF to VPN.
1603 .. index:: no rd vpn export [AS:NN|IP:nn]
1604 .. clicmd:: no rd vpn export [AS:NN|IP:nn]
1606 Deletes any previously-configured export route distinguisher.
1608 .. index:: rt vpn import|export|both RTLIST...
1609 .. clicmd:: rt vpn import|export|both RTLIST...
1611 Specifies the route-target list to be attached to a route (export) or the
1612 route-target list to match against (import) when exporting/importing between
1613 the current unicast VRF and VPN.
1615 The RTLIST is a space-separated list of route-targets, which are BGP
1616 extended community values as described in
1617 :ref:`bgp-extended-communities-attribute`.
1619 .. index:: no rt vpn import|export|both [RTLIST...]
1620 .. clicmd:: no rt vpn import|export|both [RTLIST...]
1622 Deletes any previously-configured import or export route-target list.
1624 .. index:: label vpn export (0..1048575)
1625 .. clicmd:: label vpn export (0..1048575)
1627 Specifies an optional MPLS label to be attached to a route exported from the
1628 current unicast VRF to VPN.
1630 .. index:: no label vpn export [(0..1048575)]
1631 .. clicmd:: no label vpn export [(0..1048575)]
1633 Deletes any previously-configured export label.
1635 .. index:: nexthop vpn export A.B.C.D|X:X::X:X
1636 .. clicmd:: nexthop vpn export A.B.C.D|X:X::X:X
1638 Specifies an optional nexthop value to be assigned to a route exported from
1639 the current unicast VRF to VPN. If left unspecified, the nexthop will be set
1640 to 0.0.0.0 or 0:0::0:0 (self).
1642 .. index:: no nexthop vpn export [A.B.C.D|X:X::X:X]
1643 .. clicmd:: no nexthop vpn export [A.B.C.D|X:X::X:X]
1645 Deletes any previously-configured export nexthop.
1647 .. index:: route-map vpn import|export MAP
1648 .. clicmd:: route-map vpn import|export MAP
1650 Specifies an optional route-map to be applied to routes imported or exported
1651 betwen the current unicast VRF and VPN.
1653 .. index:: no route-map vpn import|export [MAP]
1654 .. clicmd:: no route-map vpn import|export [MAP]
1656 Deletes any previously-configured import or export route-map.
1658 .. index:: import|export vpn
1659 .. clicmd:: import|export vpn
1661 Enables import or export of routes betwen the current unicast VRF and VPN.
1663 .. index:: no import|export vpn
1664 .. clicmd:: no import|export vpn
1666 Disables import or export of routes betwen the current unicast VRF and VPN.
1669 .. _displaying-bgp-information:
1671 Displaying BGP information
1672 ==========================
1675 .. _showing-bgp-information:
1677 Showing BGP information
1678 -----------------------
1680 .. index:: show ip bgp
1681 .. clicmd:: show ip bgp
1683 .. index:: show ip bgp A.B.C.D
1684 .. clicmd:: show ip bgp A.B.C.D
1686 .. index:: show ip bgp X:X::X:X
1687 .. clicmd:: show ip bgp X:X::X:X
1689 This command displays BGP routes. When no route is specified it
1690 display all of IPv4 BGP routes.
1694 BGP table version is 0, local router ID is 10.1.1.1
1695 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
1696 Origin codes: i - IGP, e - EGP, ? - incomplete
1698 Network Next Hop Metric LocPrf Weight Path
1699 \*> 1.1.1.1/32 0.0.0.0 0 32768 i
1701 Total number of prefixes 1
1704 .. index:: show ip bgp regexp LINE
1705 .. clicmd:: show ip bgp regexp LINE
1707 This command displays BGP routes using AS path regular expression
1708 (:ref:`bgp-regular-expressions`).
1710 .. index:: show ip bgp community COMMUNITY
1711 .. clicmd:: show ip bgp community COMMUNITY
1713 .. index:: show ip bgp community COMMUNITY exact-match
1714 .. clicmd:: show ip bgp community COMMUNITY exact-match
1716 This command displays BGP routes using `community`
1717 (:ref:`display-bgp-routes-by-community`).
1719 .. index:: show ip bgp community-list WORD
1720 .. clicmd:: show ip bgp community-list WORD
1722 .. index:: show ip bgp community-list WORD exact-match
1723 .. clicmd:: show ip bgp community-list WORD exact-match
1725 This command displays BGP routes using community list
1726 (:ref:`display-bgp-routes-by-community`).
1728 .. index:: show bgp ipv4|ipv6 summary
1729 .. clicmd:: show bgp ipv4|ipv6 summary
1731 Show a bgp peer summary for the specified address family.
1733 .. index:: show bgp ipv4|ipv6 neighbor [PEER]
1734 .. clicmd:: show bgp ipv4|ipv6 neighbor [PEER]
1736 This command shows information on a specific BGP `peer`.
1738 .. index:: show bgp ipv4|ipv6 dampening dampened-paths
1739 .. clicmd:: show bgp ipv4|ipv6 dampening dampened-paths
1741 Display paths suppressed due to dampening.
1743 .. index:: show bgp ipv4|ipv6 dampening flap-statistics
1744 .. clicmd:: show bgp ipv4|ipv6 dampening flap-statistics
1746 Display flap statistics of routes.
1748 .. _other-bgp-commands:
1753 .. index:: clear bgp ipv4|ipv6 \*
1754 .. clicmd:: clear bgp ipv4|ipv6 \*
1756 Clear all address family peers.
1758 .. index:: clear bgp ipv4|ipv6 PEER
1759 .. clicmd:: clear bgp ipv4|ipv6 PEER
1761 Clear peers which have addresses of X.X.X.X
1763 .. index:: clear bgp ipv4|ipv6 PEER soft in
1764 .. clicmd:: clear bgp ipv4|ipv6 PEER soft in
1766 Clear peer using soft reconfiguration.
1768 .. index:: show debug
1769 .. clicmd:: show debug
1771 .. index:: debug event
1772 .. clicmd:: debug event
1774 .. index:: debug update
1775 .. clicmd:: debug update
1777 .. index:: debug keepalive
1778 .. clicmd:: debug keepalive
1780 .. index:: no debug event
1781 .. clicmd:: no debug event
1783 .. index:: no debug update
1784 .. clicmd:: no debug update
1786 .. index:: no debug keepalive
1787 .. clicmd:: no debug keepalive
1790 .. _capability-negotiation:
1792 Capability Negotiation
1793 ======================
1795 When adding IPv6 routing information exchange feature to BGP. There were some
1796 proposals. :abbr:`IETF (Internet Engineering Task Force)`
1797 :abbr:`IDR (Inter Domain Routing)` adopted a proposal called Multiprotocol
1798 Extension for BGP. The specification is described in :rfc:`2283`. The protocol
1799 does not define new protocols. It defines new attributes to existing BGP. When
1800 it is used exchanging IPv6 routing information it is called BGP-4+. When it is
1801 used for exchanging multicast routing information it is called MBGP.
1803 *bgpd* supports Multiprotocol Extension for BGP. So if a remote peer supports
1804 the protocol, *bgpd* can exchange IPv6 and/or multicast routing information.
1806 Traditional BGP did not have the feature to detect a remote peer's
1807 capabilities, e.g. whether it can handle prefix types other than IPv4 unicast
1808 routes. This was a big problem using Multiprotocol Extension for BGP in an
1809 operational network. :rfc:`2842` adopted a feature called Capability
1810 Negotiation. *bgpd* use this Capability Negotiation to detect the remote peer's
1811 capabilities. If a peer is only configured as an IPv4 unicast neighbor, *bgpd*
1812 does not send these Capability Negotiation packets (at least not unless other
1813 optional BGP features require capability negotation).
1815 By default, FRR will bring up peering with minimal common capability for the
1816 both sides. For example, if the local router has unicast and multicast
1817 capabilities and the remote router only has unicast capability the local router
1818 will establish the connection with unicast only capability. When there are no
1819 common capabilities, FRR sends Unsupported Capability error and then resets the
1822 If you want to completely match capabilities with remote peer. Please use
1823 *strict-capability-match* command.
1825 .. index:: neighbor PEER strict-capability-match
1826 .. clicmd:: neighbor PEER strict-capability-match
1828 .. index:: no neighbor PEER strict-capability-match
1829 .. clicmd:: no neighbor PEER strict-capability-match
1831 Strictly compares remote capabilities and local capabilities. If
1832 capabilities are different, send Unsupported Capability error then reset
1835 You may want to disable sending Capability Negotiation OPEN message optional
1836 parameter to the peer when remote peer does not implement Capability
1837 Negotiation. Please use *dont-capability-negotiate* command to disable the
1840 .. index:: neighbor PEER dont-capability-negotiate
1841 .. clicmd:: neighbor PEER dont-capability-negotiate
1843 .. index:: no neighbor PEER dont-capability-negotiate
1844 .. clicmd:: no neighbor PEER dont-capability-negotiate
1846 Suppress sending Capability Negotiation as OPEN message optional parameter
1847 to the peer. This command only affects the peer is configured other than
1848 IPv4 unicast configuration.
1850 When remote peer does not have capability negotiation feature, remote peer
1851 will not send any capabilities at all. In that case, bgp configures the peer
1852 with configured capabilities.
1854 You may prefer locally configured capabilities more than the negotiated
1855 capabilities even though remote peer sends capabilities. If the peer is
1856 configured by *override-capability*, *bgpd* ignores received capabilities
1857 then override negotiated capabilities with configured values.
1859 .. index:: neighbor PEER override-capability
1860 .. clicmd:: neighbor PEER override-capability
1862 .. index:: no neighbor PEER override-capability
1863 .. clicmd:: no neighbor PEER override-capability
1865 Override the result of Capability Negotiation with local configuration.
1866 Ignore remote peer's capability value.
1868 .. _route-reflector:
1873 .. index:: bgp cluster-id A.B.C.D
1874 .. clicmd:: bgp cluster-id A.B.C.D
1876 .. index:: neighbor PEER route-reflector-client
1877 .. clicmd:: neighbor PEER route-reflector-client
1879 .. index:: no neighbor PEER route-reflector-client
1880 .. clicmd:: no neighbor PEER route-reflector-client
1888 At an Internet Exchange point, many ISPs are connected to each other by the
1889 "full mesh method". As with internal BGP full mesh formation, this method has a
1892 This scaling problem is well known. Route Server is a method to resolve the
1893 problem. Each ISP's BGP router only peers to Route Server. Route Server serves
1894 as BGP information exchange to other BGP routers. By applying this method,
1895 numbers of BGP connections is reduced from O(n*(n-1)/2) to O(n).
1897 Unlike a normal BGP router, Route Server must have several routing tables for
1898 managing different routing policies for each BGP speaker. We call the routing
1899 tables as different "views". *bgpd* can work as normal BGP router or Route
1900 Server or both at the same time.
1902 .. _multiple-instance:
1907 To enable multiple view function of *bgpd*, you must turn on multiple instance
1910 .. index:: bgp multiple-instance
1911 .. clicmd:: bgp multiple-instance
1913 Enable BGP multiple instance feature. After this feature is enabled,
1914 you can make multiple BGP instances or multiple BGP views.
1916 .. index:: no bgp multiple-instance
1917 .. clicmd:: no bgp multiple-instance
1919 Disable BGP multiple instance feature. You can not disable this feature
1920 when BGP multiple instances or views exist.
1922 When you want to make configuration more Cisco like one,
1924 .. index:: bgp config-type cisco
1925 .. clicmd:: bgp config-type cisco
1927 Cisco compatible BGP configuration output.
1929 When bgp config-type cisco is specified,
1931 ``no synchronization`` is displayed.
1932 ``no auto-summary`` is displayed.
1934 The ``network`` and ``aggregate-address`` arguments are displayed as::
1938 FRR: network 10.0.0.0/8
1939 Cisco: network 10.0.0.0
1941 FRR: aggregate-address 192.168.0.0/24
1942 Cisco: aggregate-address 192.168.0.0 255.255.255.0
1944 Community attribute handling is also different. If no configuration is
1945 specified community attribute and extended community attribute are sent to the
1946 neighbor. If a user manually disables the feature, the community attribute is
1947 not sent to the neighbor. When ``bgp config-type cisco`` is specified, the
1948 community attribute is not sent to the neighbor by default. To send the
1949 community attribute user has to specify *neighbor A.B.C.D send-community*
1956 neighbor 10.0.0.1 remote-as 1
1957 address-family ipv4 unicast
1958 no neighbor 10.0.0.1 send-community
1962 neighbor 10.0.0.1 remote-as 1
1963 address-family ipv4 unicast
1964 neighbor 10.0.0.1 send-community
1969 .. index:: bgp config-type zebra
1970 .. clicmd:: bgp config-type zebra
1972 FRR style BGP configuration. This is default.
1974 .. _bgp-instance-and-view:
1976 BGP instance and view
1977 ---------------------
1979 BGP instance is a normal BGP process. The result of route selection goes to the
1980 kernel routing table. You can setup different AS at the same time when BGP
1981 multiple instance feature is enabled.
1983 .. index:: router bgp AS-NUMBER
1984 .. clicmd:: router bgp AS-NUMBER
1986 Make a new BGP instance. You can use an arbitrary word for the `name`.
1990 bgp multiple-instance
1993 neighbor 10.0.0.1 remote-as 2
1994 neighbor 10.0.0.2 remote-as 3
1997 neighbor 10.0.0.3 remote-as 4
1998 neighbor 10.0.0.4 remote-as 5
2001 BGP view is almost same as normal BGP process. The result of route selection
2002 does not go to the kernel routing table. BGP view is only for exchanging BGP
2003 routing information.
2005 .. index:: router bgp AS-NUMBER view NAME
2006 .. clicmd:: router bgp AS-NUMBER view NAME
2008 Make a new BGP view. You can use arbitrary word for the `name`. This view's
2009 route selection result does not go to the kernel routing table.
2011 With this command, you can setup Route Server like below.
2015 bgp multiple-instance
2018 neighbor 10.0.0.1 remote-as 2
2019 neighbor 10.0.0.2 remote-as 3
2022 neighbor 10.0.0.3 remote-as 4
2023 neighbor 10.0.0.4 remote-as 5
2031 You can set different routing policy for a peer. For example, you can set
2032 different filter for a peer.
2036 bgp multiple-instance
2039 neighbor 10.0.0.1 remote-as 2
2040 address-family ipv4 unicast
2041 neighbor 10.0.0.1 distribute-list 1 in
2045 neighbor 10.0.0.1 remote-as 2
2046 address-family ipv4 unicast
2047 neighbor 10.0.0.1 distribute-list 2 in
2051 This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view 2.
2052 When the update is inserted into view 1, distribute-list 1 is applied. On the
2053 other hand, when the update is inserted into view 2, distribute-list 2 is
2056 .. _viewing-the-view:
2061 To display routing table of BGP view, you must specify view name.
2063 .. index:: show ip bgp view NAME
2064 .. clicmd:: show ip bgp view NAME
2066 Display routing table of BGP view ``NAME``.
2068 .. _bgp-regular-expressions:
2070 BGP Regular Expressions
2071 =======================
2073 BGP regular expressions are based on `POSIX 1003.2` regular expressions. The
2074 following description is just a quick subset of the `POSIX` regular
2075 expressions. Adding to that, the special character '_' is added.
2079 Matches any single character.
2082 Matches 0 or more occurrences of pattern.
2085 Matches 1 or more occurrences of pattern.
2088 Match 0 or 1 occurrences of pattern.
2091 Matches the beginning of the line.
2094 Matches the end of the line.
2097 Character `_` has special meanings in BGP regular expressions. It matches
2098 to space and comma , and AS set delimiter { and } and AS confederation
2099 delimiter `(` and `)`. And it also matches to the beginning of the line and
2100 the end of the line. So `_` can be used for AS value boundaries match. This
2101 character technically evaluates to `(^|[,{}() ]|$)`.
2103 .. _how-to-set-up-a-6-bone-connection:
2105 How to set up a 6-Bone connection
2106 =================================
2110 ! bgpd configuration
2111 ! ==================
2113 ! MP-BGP configuration
2116 bgp router-id 10.0.0.1
2117 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as `as-number`
2120 network 3ffe:506::/32
2121 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
2122 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
2123 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as `as-number`
2124 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
2127 ipv6 access-list all permit any
2129 ! Set output nexthop address.
2131 route-map set-nexthop permit 10
2132 match ipv6 address all
2133 set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
2134 set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
2140 .. _dump-bgp-packets-and-table:
2142 Dump BGP packets and table
2143 ==========================
2145 .. index:: dump bgp all PATH [INTERVAL]
2146 .. clicmd:: dump bgp all PATH [INTERVAL]
2148 .. index:: dump bgp all-et PATH [INTERVAL]
2149 .. clicmd:: dump bgp all-et PATH [INTERVAL]
2151 .. index:: no dump bgp all [PATH] [INTERVAL]
2152 .. clicmd:: no dump bgp all [PATH] [INTERVAL]
2154 Dump all BGP packet and events to `path` file.
2155 If `interval` is set, a new file will be created for echo `interval` of
2156 seconds. The path `path` can be set with date and time formatting
2157 (strftime). The type ‘all-et’ enables support for Extended Timestamp Header
2158 (:ref:`packet-binary-dump-format`).
2160 .. index:: dump bgp updates PATH [INTERVAL]
2161 .. clicmd:: dump bgp updates PATH [INTERVAL]
2163 .. index:: dump bgp updates-et PATH [INTERVAL]
2164 .. clicmd:: dump bgp updates-et PATH [INTERVAL]
2166 .. index:: no dump bgp updates [PATH] [INTERVAL]
2167 .. clicmd:: no dump bgp updates [PATH] [INTERVAL]
2169 Dump only BGP updates messages to `path` file.
2170 If `interval` is set, a new file will be created for echo `interval` of
2171 seconds. The path `path` can be set with date and time formatting
2172 (strftime). The type ‘updates-et’ enables support for Extended Timestamp
2173 Header (:ref:`packet-binary-dump-format`).
2175 .. index:: dump bgp routes-mrt PATH
2176 .. clicmd:: dump bgp routes-mrt PATH
2178 .. index:: dump bgp routes-mrt PATH INTERVAL
2179 .. clicmd:: dump bgp routes-mrt PATH INTERVAL
2181 .. index:: no dump bgp route-mrt [PATH] [INTERVAL]
2182 .. clicmd:: no dump bgp route-mrt [PATH] [INTERVAL]
2184 Dump whole BGP routing table to `path`. This is heavy process. The path
2185 `path` can be set with date and time formatting (strftime). If `interval` is
2186 set, a new file will be created for echo `interval` of seconds.
2188 Note: the interval variable can also be set using hours and minutes: 04h20m00.
2190 .. _bgp-configuration-examples:
2192 BGP Configuration Examples
2193 ==========================
2195 Example of a session to an upstream, advertising only one prefix to it.
2200 bgp router-id 10.236.87.1
2201 neighbor upstream peer-group
2202 neighbor upstream remote-as 64515
2203 neighbor upstream capability dynamic
2204 neighbor 10.1.1.1 peer-group upstream
2205 neighbor 10.1.1.1 description ACME ISP
2207 address-family ipv4 unicast
2208 network 10.236.87.0/24
2209 neighbor upstream prefix-list pl-allowed-adv out
2212 ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
2213 ip prefix-list pl-allowed-adv seq 10 deny any
2215 A more complex example. With upstream, peer and customer sessions. Advertising
2216 global prefixes and NO_EXPORT prefixes and providing actions for customer
2217 routes based on community values. Extensive use of route-maps and the 'call'
2218 feature to support selective advertising of prefixes. This example is intended
2219 as guidance only, it has NOT been tested and almost certainly containts silly
2220 mistakes, if not serious flaws.
2225 bgp router-id 10.236.87.1
2226 neighbor upstream capability dynamic
2227 neighbor cust capability dynamic
2228 neighbor peer capability dynamic
2229 neighbor 10.1.1.1 remote-as 64515
2230 neighbor 10.1.1.1 peer-group upstream
2231 neighbor 10.2.1.1 remote-as 64516
2232 neighbor 10.2.1.1 peer-group upstream
2233 neighbor 10.3.1.1 remote-as 64517
2234 neighbor 10.3.1.1 peer-group cust-default
2235 neighbor 10.3.1.1 description customer1
2236 neighbor 10.4.1.1 remote-as 64518
2237 neighbor 10.4.1.1 peer-group cust
2238 neighbor 10.4.1.1 description customer2
2239 neighbor 10.5.1.1 remote-as 64519
2240 neighbor 10.5.1.1 peer-group peer
2241 neighbor 10.5.1.1 description peer AS 1
2242 neighbor 10.6.1.1 remote-as 64520
2243 neighbor 10.6.1.1 peer-group peer
2244 neighbor 10.6.1.1 description peer AS 2
2246 address-family ipv4 unicast
2247 network 10.123.456.0/24
2248 network 10.123.456.128/25 route-map rm-no-export
2249 neighbor upstream route-map rm-upstream-out out
2250 neighbor cust route-map rm-cust-in in
2251 neighbor cust route-map rm-cust-out out
2252 neighbor cust send-community both
2253 neighbor peer route-map rm-peer-in in
2254 neighbor peer route-map rm-peer-out out
2255 neighbor peer send-community both
2256 neighbor 10.3.1.1 prefix-list pl-cust1-network in
2257 neighbor 10.4.1.1 prefix-list pl-cust2-network in
2258 neighbor 10.5.1.1 prefix-list pl-peer1-network in
2259 neighbor 10.6.1.1 prefix-list pl-peer2-network in
2262 ip prefix-list pl-default permit 0.0.0.0/0
2264 ip prefix-list pl-upstream-peers permit 10.1.1.1/32
2265 ip prefix-list pl-upstream-peers permit 10.2.1.1/32
2267 ip prefix-list pl-cust1-network permit 10.3.1.0/24
2268 ip prefix-list pl-cust1-network permit 10.3.2.0/24
2270 ip prefix-list pl-cust2-network permit 10.4.1.0/24
2272 ip prefix-list pl-peer1-network permit 10.5.1.0/24
2273 ip prefix-list pl-peer1-network permit 10.5.2.0/24
2274 ip prefix-list pl-peer1-network permit 192.168.0.0/24
2276 ip prefix-list pl-peer2-network permit 10.6.1.0/24
2277 ip prefix-list pl-peer2-network permit 10.6.2.0/24
2278 ip prefix-list pl-peer2-network permit 192.168.1.0/24
2279 ip prefix-list pl-peer2-network permit 192.168.2.0/24
2280 ip prefix-list pl-peer2-network permit 172.16.1/24
2282 ip as-path access-list asp-own-as permit ^$
2283 ip as-path access-list asp-own-as permit _64512_
2285 ! #################################################################
2286 ! Match communities we provide actions for, on routes receives from
2287 ! customers. Communities values of <our-ASN>:X, with X, have actions:
2289 ! 100 - blackhole the prefix
2290 ! 200 - set no_export
2291 ! 300 - advertise only to other customers
2292 ! 400 - advertise only to upstreams
2293 ! 500 - set no_export when advertising to upstreams
2294 ! 2X00 - set local_preference to X00
2296 ! blackhole the prefix of the route
2297 ip community-list standard cm-blackhole permit 64512:100
2299 ! set no-export community before advertising
2300 ip community-list standard cm-set-no-export permit 64512:200
2302 ! advertise only to other customers
2303 ip community-list standard cm-cust-only permit 64512:300
2305 ! advertise only to upstreams
2306 ip community-list standard cm-upstream-only permit 64512:400
2308 ! advertise to upstreams with no-export
2309 ip community-list standard cm-upstream-noexport permit 64512:500
2311 ! set local-pref to least significant 3 digits of the community
2312 ip community-list standard cm-prefmod-100 permit 64512:2100
2313 ip community-list standard cm-prefmod-200 permit 64512:2200
2314 ip community-list standard cm-prefmod-300 permit 64512:2300
2315 ip community-list standard cm-prefmod-400 permit 64512:2400
2316 ip community-list expanded cme-prefmod-range permit 64512:2...
2318 ! Informational communities
2320 ! 3000 - learned from upstream
2321 ! 3100 - learned from customer
2322 ! 3200 - learned from peer
2324 ip community-list standard cm-learnt-upstream permit 64512:3000
2325 ip community-list standard cm-learnt-cust permit 64512:3100
2326 ip community-list standard cm-learnt-peer permit 64512:3200
2328 ! ###################################################################
2329 ! Utility route-maps
2331 ! These utility route-maps generally should not used to permit/deny
2332 ! routes, i.e. they do not have meaning as filters, and hence probably
2333 ! should be used with 'on-match next'. These all finish with an empty
2334 ! permit entry so as not interfere with processing in the caller.
2336 route-map rm-no-export permit 10
2337 set community additive no-export
2338 route-map rm-no-export permit 20
2340 route-map rm-blackhole permit 10
2341 description blackhole, up-pref and ensure it cant escape this AS
2342 set ip next-hop 127.0.0.1
2343 set local-preference 10
2344 set community additive no-export
2345 route-map rm-blackhole permit 20
2347 ! Set local-pref as requested
2348 route-map rm-prefmod permit 10
2349 match community cm-prefmod-100
2350 set local-preference 100
2351 route-map rm-prefmod permit 20
2352 match community cm-prefmod-200
2353 set local-preference 200
2354 route-map rm-prefmod permit 30
2355 match community cm-prefmod-300
2356 set local-preference 300
2357 route-map rm-prefmod permit 40
2358 match community cm-prefmod-400
2359 set local-preference 400
2360 route-map rm-prefmod permit 50
2362 ! Community actions to take on receipt of route.
2363 route-map rm-community-in permit 10
2364 description check for blackholing, no point continuing if it matches.
2365 match community cm-blackhole
2367 route-map rm-community-in permit 20
2368 match community cm-set-no-export
2371 route-map rm-community-in permit 30
2372 match community cme-prefmod-range
2374 route-map rm-community-in permit 40
2376 ! #####################################################################
2377 ! Community actions to take when advertising a route.
2378 ! These are filtering route-maps,
2380 ! Deny customer routes to upstream with cust-only set.
2381 route-map rm-community-filt-to-upstream deny 10
2382 match community cm-learnt-cust
2383 match community cm-cust-only
2384 route-map rm-community-filt-to-upstream permit 20
2386 ! Deny customer routes to other customers with upstream-only set.
2387 route-map rm-community-filt-to-cust deny 10
2388 match community cm-learnt-cust
2389 match community cm-upstream-only
2390 route-map rm-community-filt-to-cust permit 20
2392 ! ###################################################################
2393 ! The top-level route-maps applied to sessions. Further entries could
2394 ! be added obviously..
2397 route-map rm-cust-in permit 10
2398 call rm-community-in
2400 route-map rm-cust-in permit 20
2401 set community additive 64512:3100
2402 route-map rm-cust-in permit 30
2404 route-map rm-cust-out permit 10
2405 call rm-community-filt-to-cust
2407 route-map rm-cust-out permit 20
2409 ! Upstream transit ASes
2410 route-map rm-upstream-out permit 10
2411 description filter customer prefixes which are marked cust-only
2412 call rm-community-filt-to-upstream
2414 route-map rm-upstream-out permit 20
2415 description only customer routes are provided to upstreams/peers
2416 match community cm-learnt-cust
2419 ! outbound policy is same as for upstream
2420 route-map rm-peer-out permit 10
2421 call rm-upstream-out
2423 route-map rm-peer-in permit 10
2424 set community additive 64512:3200
2426 .. include:: routeserver.rst
2428 .. include:: rpki.rst
2431 .. [#med-transitivity-rant] For some set of objects to have an order, there *must* be some binary ordering relation that is defined for *every* combination of those objects, and that relation *must* be transitive. I.e.:, if the relation operator is <, and if a < b and b < c then that relation must carry over and it *must* be that a < c for the objects to have an order. The ordering relation may allow for equality, i.e. a < b and b < a may both be true amd imply that a and b are equal in the order and not distinguished by it, in which case the set has a partial order. Otherwise, if there is an order, all the objects have a distinct place in the order and the set has a total order)
2432 .. [bgp-route-osci-cond] McPherson, D. and Gill, V. and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", IETF RFC3345
2433 .. [stable-flexible-ibgp] Flavel, A. and M. Roughan, "Stable and flexible iBGP", ACM SIGCOMM 2009
2434 .. [ibgp-correctness] Griffin, T. and G. Wilfong, "On the correctness of IBGP configuration", ACM SIGCOMM 2002