7 :abbr:`BGP` stands for a Border Gateway Protocol. The latest BGP version is 4.
8 BGP-4 is one of the Exterior Gateway Protocols and the de facto standard
9 interdomain routing protocol. BGP-4 is described in :rfc:`1771`.
11 Many extensions have been added to :rfc:`1771`. :rfc:`2858` adds multiprotocol
19 Default configuration file of *bgpd* is :file:`bgpd.conf`. *bgpd* searches the
20 current directory first then |INSTALL_PREFIX_ETC|/bgpd.conf. All of bgpd's
21 command must be configured in :file:`bgpd.conf`.
23 *bgpd* specific invocation options are described below. Common options may also
24 be specified (:ref:`common-invocation-options`).
28 .. option:: -p, --bgp_port <port>
30 Set the bgp protocol's port number. When port number is 0, that means do not
33 .. option:: -l, --listenon
35 Specify a specific IP address for bgpd to listen on, rather than its
36 default of INADDR_ANY / IN6ADDR_ANY. This can be useful to constrain bgpd
37 to an internal address, or to run multiple bgpd processes on one host.
45 First of all you must configure BGP router with *router bgp* command. To
46 configure BGP router, you need AS number. AS number is an identification of
47 autonomous system. BGP protocol uses the AS number for detecting whether the
48 BGP connection is internal one or external one.
50 .. index:: router bgp ASN
51 .. clicmd:: router bgp ASN
53 Enable a BGP protocol process with the specified ASN. After
54 this statement you can input any `BGP Commands`.
56 .. index:: no router bgp ASN
57 .. clicmd:: no router bgp ASN
59 Destroy a BGP protocol process with the specified ASN.
61 .. index:: bgp router-id A.B.C.D
62 .. clicmd:: bgp router-id A.B.C.D
64 This command specifies the router-ID. If *bgpd* connects to *zebra* it gets
65 interface and address information. In that case default router ID value is
66 selected as the largest IP Address of the interfaces. When `router zebra` is
67 not enabled *bgpd* can't get interface information so `router-id` is set to
68 0.0.0.0. So please set router-id by hand.
75 .. index:: distance bgp (1-255) (1-255) (1-255)
76 .. clicmd:: distance bgp (1-255) (1-255) (1-255)
78 This command change distance value of BGP. Each argument is distance value
79 for external routes, internal routes and local routes.
81 .. index:: distance (1-255) A.B.C.D/M
82 .. clicmd:: distance (1-255) A.B.C.D/M
84 .. index:: distance (1-255) A.B.C.D/M word
85 .. clicmd:: distance (1-255) A.B.C.D/M word
87 .. _bgp-decision-process:
92 The decision process FRR BGP uses to select routes is as follows:
95 Prefer higher local weight routes to lower routes.
97 2. *Local preference check*
98 Prefer higher local preference routes to lower.
100 3. *Local route check*
101 Prefer local routes (statics, aggregates, redistributed) to received routes.
103 4. *AS path length check*
104 Prefer shortest hop-count AS_PATHs.
107 Prefer the lowest origin type route. That is, prefer IGP origin routes to
108 EGP, to Incomplete routes.
111 Where routes with a MED were received from the same AS, prefer the route
112 with the lowest MED. :ref:`bgp-med`.
115 Prefer the route received from an external, eBGP peer over routes received
116 from other types of peers.
119 Prefer the route with the lower IGP cost.
121 9. *Multi-path check*
122 If multi-pathing is enabled, then check whether the routes not yet
123 distinguished in preference may be considered equal. If
124 :clicmd:`bgp bestpath as-path multipath-relax` is set, all such routes are
125 considered equal, otherwise routes received via iBGP with identical AS_PATHs
126 or routes received from eBGP neighbours in the same AS are considered equal.
128 10. *Already-selected external check*
129 Where both routes were received from eBGP peers, then prefer the route
130 which is already selected. Note that this check is not applied if
131 :clicmd:`bgp bestpath compare-routerid` is configured. This check can
132 prevent some cases of oscillation.
134 11. *Router-ID check*
135 Prefer the route with the lowest `router-ID`. If the route has an
136 `ORIGINATOR_ID` attribute, through iBGP reflection, then that router ID is
137 used, otherwise the `router-ID` of the peer the route was received from is
140 12. *Cluster-List length check*
141 The route with the shortest cluster-list length is used. The cluster-list
142 reflects the iBGP reflection path the route has taken.
145 Prefer the route received from the peer with the higher transport layer
146 address, as a last-resort tie-breaker.
149 .. index:: bgp bestpath as-path confed
150 .. clicmd:: bgp bestpath as-path confed
152 This command specifies that the length of confederation path sets and
153 sequences should should be taken into account during the BGP best path
156 .. index:: bgp bestpath as-path multipath-relax
157 .. clicmd:: bgp bestpath as-path multipath-relax
159 This command specifies that BGP decision process should consider paths
160 of equal AS_PATH length candidates for multipath computation. Without
161 the knob, the entire AS_PATH must match for multipath computation.
163 .. clicmd:: bgp bestpath compare-routerid
165 Ensure that when comparing routes where both are equal on most metrics,
166 including local-pref, AS_PATH length, IGP cost, MED, that the tie is broken
169 If this option is enabled, then the already-selected check, where
170 already selected eBGP routes are preferred, is skipped.
172 If a route has an `ORIGINATOR_ID` attribute because it has been reflected,
173 that `ORIGINATOR_ID` will be used. Otherwise, the router-ID of the peer the
174 route was received from will be used.
176 The advantage of this is that the route-selection (at this point) will be
177 more deterministic. The disadvantage is that a few or even one lowest-ID
178 router may attract all traffic to otherwise-equal paths because of this
179 check. It may increase the possibility of MED or IGP oscillation, unless
180 other measures were taken to avoid these. The exact behaviour will be
181 sensitive to the iBGP and reflection topology.
184 .. _bgp-route-flap-dampening:
186 BGP route flap dampening
187 ------------------------
189 .. clicmd:: bgp dampening (1-45) (1-20000) (1-20000) (1-255)
191 This command enables BGP route-flap dampening and specifies dampening parameters.
194 Half-life time for the penalty
197 Value to start reusing a route
200 Value to start suppressing a route
203 Maximum duration to suppress a stable route
205 The route-flap damping algorithm is compatible with :rfc:`2439`. The use of
206 this command is not recommended nowadays.
210 `http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378 <http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378>`_
217 The BGP :abbr:`MED (Multi Exit Discriminator)` attribute has properties which
218 can cause subtle convergence problems in BGP. These properties and problems
219 have proven to be hard to understand, at least historically, and may still not
220 be widely understood. The following attempts to collect together and present
221 what is known about MED, to help operators and FRR users in designing and
222 configuring their networks.
224 The BGP :abbr:`MED` attribute is intended to allow one AS to indicate its
225 preferences for its ingress points to another AS. The MED attribute will not be
226 propagated on to another AS by the receiving AS - it is 'non-transitive' in the
229 E.g., if AS X and AS Y have 2 different BGP peering points, then AS X might set
230 a MED of 100 on routes advertised at one and a MED of 200 at the other. When AS
231 Y selects between otherwise equal routes to or via AS X, AS Y should prefer to
232 take the path via the lower MED peering of 100 with AS X. Setting the MED
233 allows an AS to influence the routing taken to it within another, neighbouring
236 In this use of MED it is not really meaningful to compare the MED value on
237 routes where the next AS on the paths differs. E.g., if AS Y also had a route
238 for some destination via AS Z in addition to the routes from AS X, and AS Z had
239 also set a MED, it wouldn't make sense for AS Y to compare AS Z's MED values to
240 those of AS X. The MED values have been set by different administrators, with
241 different frames of reference.
243 The default behaviour of BGP therefore is to not compare MED values across
244 routes received from different neighbouring ASes. In FRR this is done by
245 comparing the neighbouring, left-most AS in the received AS_PATHs of the routes
246 and only comparing MED if those are the same.
248 Unfortunately, this behaviour of MED, of sometimes being compared across routes
249 and sometimes not, depending on the properties of those other routes, means MED
250 can cause the order of preference over all the routes to be undefined. That is,
251 given routes A, B, and C, if A is preferred to B, and B is preferred to C, then
252 a well-defined order should mean the preference is transitive (in the sense of
253 orders [#med-transitivity-rant]_) and that A would be preferred to C.
255 However, when MED is involved this need not be the case. With MED it is
256 possible that C is actually preferred over A. So A is preferred to B, B is
257 preferred to C, but C is preferred to A. This can be true even where BGP
258 defines a deterministic 'most preferred' route out of the full set of A,B,C.
259 With MED, for any given set of routes there may be a deterministically
260 preferred route, but there need not be any way to arrange them into any order
261 of preference. With unmodified MED, the order of preference of routes literally
264 That MED can induce non-transitive preferences over routes can cause issues.
265 Firstly, it may be perceived to cause routing table churn locally at speakers;
266 secondly, and more seriously, it may cause routing instability in iBGP
267 topologies, where sets of speakers continually oscillate between different
270 The first issue arises from how speakers often implement routing decisions.
271 Though BGP defines a selection process that will deterministically select the
272 same route as best at any given speaker, even with MED, that process requires
273 evaluating all routes together. For performance and ease of implementation
274 reasons, many implementations evaluate route preferences in a pair-wise fashion
275 instead. Given there is no well-defined order when MED is involved, the best
276 route that will be chosen becomes subject to implementation details, such as
277 the order the routes are stored in. That may be (locally) non-deterministic,
278 e.g.: it may be the order the routes were received in.
280 This indeterminism may be considered undesirable, though it need not cause
281 problems. It may mean additional routing churn is perceived, as sometimes more
282 updates may be produced than at other times in reaction to some event .
284 This first issue can be fixed with a more deterministic route selection that
285 ensures routes are ordered by the neighbouring AS during selection.
286 :clicmd:`bgp deterministic-med`. This may reduce the number of updates as routes
287 are received, and may in some cases reduce routing churn. Though, it could
288 equally deterministically produce the largest possible set of updates in
289 response to the most common sequence of received updates.
291 A deterministic order of evaluation tends to imply an additional overhead of
292 sorting over any set of n routes to a destination. The implementation of
293 deterministic MED in FRR scales significantly worse than most sorting
294 algorithms at present, with the number of paths to a given destination. That
295 number is often low enough to not cause any issues, but where there are many
296 paths, the deterministic comparison may quickly become increasingly expensive
299 Deterministic local evaluation can *not* fix the second, more major, issue of
300 MED however. Which is that the non-transitive preference of routes MED can
301 cause may lead to routing instability or oscillation across multiple speakers
302 in iBGP topologies. This can occur with full-mesh iBGP, but is particularly
303 problematic in non-full-mesh iBGP topologies that further reduce the routing
304 information known to each speaker. This has primarily been documented with iBGP
305 route-reflection topologies. However, any route-hiding technologies potentially
306 could also exacerbate oscillation with MED.
308 This second issue occurs where speakers each have only a subset of routes, and
309 there are cycles in the preferences between different combinations of routes -
310 as the undefined order of preference of MED allows - and the routes are
311 distributed in a way that causes the BGP speakers to 'chase' those cycles. This
312 can occur even if all speakers use a deterministic order of evaluation in route
315 E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X, and from
316 speaker 3 in AS Y; while speaker 5 in AS A might receive that route from
317 speaker 1 in AS Y. AS Y might set a MED of 200 at speaker 1, and 100 at speaker
318 3. I.e, using ASN:ID:MED to label the speakers:
324 X:2------|--A:4-------A:5--|-Y:1:200
330 Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs), then based
331 on the RFC4271 decision process speaker 4 will choose X:2 over Y:3:100, based
332 on the lower ID of 2. Speaker 4 advertises X:2 to speaker 5. Speaker 5 will
333 continue to prefer Y:1:200 based on the ID, and advertise this to speaker 4.
334 Speaker 4 will now have the full set of routes, and the Y:1:200 it receives
335 from 5 will beat X:2, but when speaker 4 compares Y:1:200 to Y:3:100 the MED
336 check now becomes active as the ASes match, and now Y:3:100 is preferred.
337 Speaker 4 therefore now advertises Y:3:100 to 5, which will also agrees that
338 Y:3:100 is preferred to Y:1:200, and so withdraws the latter route from 4.
339 Speaker 4 now has only X:2 and Y:3:100, and X:2 beats Y:3:100, and so speaker 4
340 implicitly updates its route to speaker 5 to X:2. Speaker 5 sees that Y:1:200
341 beats X:2 based on the ID, and advertises Y:1:200 to speaker 4, and the cycle
344 The root cause is the lack of a clear order of preference caused by how MED
345 sometimes is and sometimes is not compared, leading to this cycle in the
346 preferences between the routes:
351 /---> X:2 ---beats---> Y:3:100 --\\
354 \\---beats--- Y:1:200 <---beats---/
358 This particular type of oscillation in full-mesh iBGP topologies can be
359 avoided by speakers preferring already selected, external routes rather than
360 choosing to update to new a route based on a post-MED metric (e.g. router-ID),
361 at the cost of a non-deterministic selection process. FRR implements this, as
362 do many other implementations, so long as it is not overridden by setting
363 :clicmd:`bgp bestpath compare-routerid`, and see also
364 :ref:`bgp-decision-process`.
366 However, more complex and insidious cycles of oscillation are possible with
367 iBGP route-reflection, which are not so easily avoided. These have been
368 documented in various places. See, e.g.:
370 - [bgp-route-osci-cond]_
371 - [stable-flexible-ibgp]_
372 - [ibgp-correctness]_
374 for concrete examples and further references.
376 There is as of this writing *no* known way to use MED for its original purpose;
377 *and* reduce routing information in iBGP topologies; *and* be sure to avoid the
378 instability problems of MED due the non-transitive routing preferences it can
379 induce; in general on arbitrary networks.
381 There may be iBGP topology specific ways to reduce the instability risks, even
382 while using MED, e.g.: by constraining the reflection topology and by tuning
383 IGP costs between route-reflector clusters, see :rfc:`3345` for details. In the
384 near future, the Add-Path extension to BGP may also solve MED oscillation while
385 still allowing MED to be used as intended, by distributing "best-paths per
386 neighbour AS". This would be at the cost of distributing at least as many
387 routes to all speakers as a full-mesh iBGP would, if not more, while also
388 imposing similar CPU overheads as the "Deterministic MED" feature at each
391 More generally, the instability problems that MED can introduce on more
392 complex, non-full-mesh, iBGP topologies may be avoided either by:
394 - Setting :clicmd:`bgp always-compare-med`, however this allows MED to be compared
395 across values set by different neighbour ASes, which may not produce
396 coherent desirable results, of itself.
397 - Effectively ignoring MED by setting MED to the same value (e.g.: 0) using
398 :clicmd:`set metric METRIC` on all received routes, in combination with
399 setting :clicmd:`bgp always-compare-med` on all speakers. This is the simplest
400 and most performant way to avoid MED oscillation issues, where an AS is happy
401 not to allow neighbours to inject this problematic metric.
403 As MED is evaluated after the AS_PATH length check, another possible use for
404 MED is for intra-AS steering of routes with equal AS_PATH length, as an
405 extension of the last case above. As MED is evaluated before IGP metric, this
406 can allow cold-potato routing to be implemented to send traffic to preferred
407 hand-offs with neighbours, rather than the closest hand-off according to the
410 Note that even if action is taken to address the MED non-transitivity issues,
411 other oscillations may still be possible. E.g., on IGP cost if iBGP and IGP
412 topologies are at cross-purposes with each other - see the Flavel and Roughan
413 paper above for an example. Hence the guideline that the iBGP topology should
414 follow the IGP topology.
416 .. index:: bgp deterministic-med
417 .. clicmd:: bgp deterministic-med
419 Carry out route-selection in way that produces deterministic answers
420 locally, even in the face of MED and the lack of a well-defined order of
421 preference it can induce on routes. Without this option the preferred route
422 with MED may be determined largely by the order that routes were received
425 Setting this option will have a performance cost that may be noticeable when
426 there are many routes for each destination. Currently in FRR it is
427 implemented in a way that scales poorly as the number of routes per
428 destination increases.
430 The default is that this option is not set.
432 Note that there are other sources of indeterminism in the route selection
433 process, specifically, the preference for older and already selected routes
434 from eBGP peers, :ref:`bgp-decision-process`.
436 .. index:: bgp always-compare-med
437 .. clicmd:: bgp always-compare-med
439 Always compare the MED on routes, even when they were received from
440 different neighbouring ASes. Setting this option makes the order of
441 preference of routes more defined, and should eliminate MED induced
444 If using this option, it may also be desirable to use
445 :clicmd:`set metric METRIC` to set MED to 0 on routes received from external
448 This option can be used, together with :clicmd:`set metric METRIC` to use
449 MED as an intra-AS metric to steer equal-length AS_PATH routes to, e.g.,
463 .. index:: network A.B.C.D/M
464 .. clicmd:: network A.B.C.D/M
466 This command adds the announcement network.
471 address-family ipv4 unicast
475 This configuration example says that network 10.0.0.0/8 will be
476 announced to all neighbors. Some vendors' routers don't advertise
477 routes if they aren't present in their IGP routing tables; `bgpd`
478 doesn't care about IGP routes when announcing its routes.
480 .. index:: no network A.B.C.D/M
481 .. clicmd:: no network A.B.C.D/M
484 .. _route-aggregation:
489 .. index:: aggregate-address A.B.C.D/M
490 .. clicmd:: aggregate-address A.B.C.D/M
492 This command specifies an aggregate address.
494 .. index:: aggregate-address A.B.C.D/M as-set
495 .. clicmd:: aggregate-address A.B.C.D/M as-set
497 This command specifies an aggregate address. Resulting routes include
500 .. index:: aggregate-address A.B.C.D/M summary-only
501 .. clicmd:: aggregate-address A.B.C.D/M summary-only
503 This command specifies an aggregate address. Aggregated routes will
506 .. index:: no aggregate-address A.B.C.D/M
507 .. clicmd:: no aggregate-address A.B.C.D/M
511 .. _redistribute-to-bgp:
516 .. index:: redistribute kernel
517 .. clicmd:: redistribute kernel
519 Redistribute kernel route to BGP process.
521 .. index:: redistribute static
522 .. clicmd:: redistribute static
524 Redistribute static route to BGP process.
526 .. index:: redistribute connected
527 .. clicmd:: redistribute connected
529 Redistribute connected route to BGP process.
531 .. index:: redistribute rip
532 .. clicmd:: redistribute rip
534 Redistribute RIP route to BGP process.
536 .. index:: redistribute ospf
537 .. clicmd:: redistribute ospf
539 Redistribute OSPF route to BGP process.
541 .. index:: redistribute vpn
542 .. clicmd:: redistribute vpn
544 Redistribute VNC routes to BGP process.
546 .. index:: update-delay MAX-DELAY
547 .. clicmd:: update-delay MAX-DELAY
549 .. index:: update-delay MAX-DELAY ESTABLISH-WAIT
550 .. clicmd:: update-delay MAX-DELAY ESTABLISH-WAIT
552 This feature is used to enable read-only mode on BGP process restart or when
553 BGP process is cleared using 'clear ip bgp \*'. When applicable, read-only
554 mode would begin as soon as the first peer reaches Established status and a
555 timer for max-delay seconds is started.
557 During this mode BGP doesn't run any best-path or generate any updates to its
558 peers. This mode continues until:
560 1. All the configured peers, except the shutdown peers, have sent explicit EOR
561 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
562 Established is considered an implicit-EOR.
563 If the establish-wait optional value is given, then BGP will wait for
564 peers to reach established from the beginning of the update-delay till the
565 establish-wait period is over, i.e. the minimum set of established peers for
566 which EOR is expected would be peers established during the establish-wait
567 window, not necessarily all the configured neighbors.
568 2. max-delay period is over.
570 On hitting any of the above two conditions, BGP resumes the decision process
571 and generates updates to its peers.
573 Default max-delay is 0, i.e. the feature is off by default.
575 .. index:: table-map ROUTE-MAP-NAME
576 .. clicmd:: table-map ROUTE-MAP-NAME
578 This feature is used to apply a route-map on route updates from BGP to
579 Zebra. All the applicable match operations are allowed, such as match on
580 prefix, next-hop, communities, etc. Set operations for this attach-point are
581 limited to metric and next-hop only. Any operation of this feature does not
582 affect BGPs internal RIB.
584 Supported for ipv4 and ipv6 address families. It works on multi-paths as
585 well, however, metric setting is based on the best-path only.
597 .. index:: neighbor PEER remote-as ASN
598 .. clicmd:: neighbor PEER remote-as ASN
600 Creates a new neighbor whose remote-as is ASN. PEER can be an IPv4 address
601 or an IPv6 address or an interface to use for the connection.
606 neighbor 10.0.0.1 remote-as 2
608 In this case my router, in AS-1, is trying to peer with AS-2 at 10.0.0.1.
610 This command must be the first command used when configuring a neighbor. If
611 the remote-as is not specified, *bgpd* will complain like this: ::
613 can't find neighbor 10.0.0.1
615 .. index:: neighbor PEER remote-as internal
616 .. clicmd:: neighbor PEER remote-as internal
618 Create a peer as you would when you specify an ASN, except that if the
619 peers ASN is different than mine as specified under the :clicmd:`router bgp ASN`
620 command the connection will be denied.
622 .. index:: neighbor PEER remote-as external
623 .. clicmd:: neighbor PEER remote-as external
625 Create a peer as you would when you specify an ASN, except that if the
626 peers ASN is the same as mine as specified under the :clicmd:`router bgp ASN`
627 command the connection will be denied.
629 .. _bgp-peer-commands:
634 In a `router bgp` clause there are neighbor specific configurations
637 .. index:: neighbor PEER shutdown
638 .. clicmd:: neighbor PEER shutdown
640 .. index:: no neighbor PEER shutdown
641 .. clicmd:: no neighbor PEER shutdown
643 Shutdown the peer. We can delete the neighbor's configuration by
644 ``no neighbor PEER remote-as ASN`` but all configuration of the neighbor
645 will be deleted. When you want to preserve the configuration, but want to
646 drop the BGP peer, use this syntax.
648 .. index:: neighbor PEER ebgp-multihop
649 .. clicmd:: neighbor PEER ebgp-multihop
651 .. index:: no neighbor PEER ebgp-multihop
652 .. clicmd:: no neighbor PEER ebgp-multihop
655 .. index:: neighbor PEER description ...
656 .. clicmd:: neighbor PEER description ...
659 .. index:: no neighbor PEER description ...
660 .. clicmd:: no neighbor PEER description ...
662 Set description of the peer.
664 .. index:: neighbor PEER version VERSION
665 .. clicmd:: neighbor PEER version VERSION
667 Set up the neighbor's BGP version. `version` can be `4`, `4+` or `4-`. BGP
668 version `4` is the default value used for BGP peering. BGP version `4+`
669 means that the neighbor supports Multiprotocol Extensions for BGP-4. BGP
670 version `4-` is similar but the neighbor speaks the old Internet-Draft
671 revision 00's Multiprotocol Extensions for BGP-4. Some routing software is
672 still using this version.
674 .. index:: neighbor PEER interface IFNAME
675 .. clicmd:: neighbor PEER interface IFNAME
678 .. index:: no neighbor PEER interface IFNAME
679 .. clicmd:: no neighbor PEER interface IFNAME
681 When you connect to a BGP peer over an IPv6 link-local address, you have to
682 specify the IFNAME of the interface used for the connection. To specify
683 IPv4 session addresses, see the ``neighbor PEER update-source`` command
686 This command is deprecated and may be removed in a future release. Its use
689 .. index:: neighbor PEER next-hop-self [all]
690 .. clicmd:: neighbor PEER next-hop-self [all]
693 .. index:: no neighbor PEER next-hop-self [all]
694 .. clicmd:: no neighbor PEER next-hop-self [all]
696 This command specifies an announced route's nexthop as being equivalent to
697 the address of the bgp router if it is learned via eBGP. If the optional
698 keyword `all` is specified the modification is done also for routes learned
701 .. index:: neighbor PEER update-source <IFNAME|ADDRESS>
702 .. clicmd:: neighbor PEER update-source <IFNAME|ADDRESS>
705 .. index:: no neighbor PEER update-source
706 .. clicmd:: no neighbor PEER update-source
708 Specify the IPv4 source address to use for the :abbr:`BGP` session to this
709 neighbour, may be specified as either an IPv4 address directly or as an
710 interface name (in which case the *zebra* daemon MUST be running in order
711 for *bgpd* to be able to retrieve interface state).
716 neighbor foo update-source 192.168.0.1
717 neighbor bar update-source lo0
720 .. index:: neighbor PEER default-originate
721 .. clicmd:: neighbor PEER default-originate
723 .. index:: no neighbor PEER default-originate
724 .. clicmd:: no neighbor PEER default-originate
726 *bgpd*'s default is to not announce the default route (0.0.0.0/0) even if it
727 is in routing table. When you want to announce default routes to the peer,
730 .. index:: neighbor PEER port PORT
731 .. clicmd:: neighbor PEER port PORT
733 .. index:: neighbor PEER send-community
734 .. clicmd:: neighbor PEER send-community
736 .. index:: neighbor PEER weight WEIGHT
737 .. clicmd:: neighbor PEER weight WEIGHT
740 .. index:: no neighbor PEER weight WEIGHT
741 .. clicmd:: no neighbor PEER weight WEIGHT
743 This command specifies a default `weight` value for the neighbor's routes.
745 .. index:: neighbor PEER maximum-prefix NUMBER
746 .. clicmd:: neighbor PEER maximum-prefix NUMBER
749 .. index:: no neighbor PEER maximum-prefix NUMBER
750 .. clicmd:: no neighbor PEER maximum-prefix NUMBER
753 .. index:: neighbor PEER local-as AS-NUMBER
754 .. clicmd:: neighbor PEER local-as AS-NUMBER
757 .. index:: neighbor PEER local-as AS-NUMBER no-prepend
758 .. clicmd:: neighbor PEER local-as AS-NUMBER no-prepend
761 .. index:: neighbor PEER local-as AS-NUMBER no-prepend replace-as
762 .. clicmd:: neighbor PEER local-as AS-NUMBER no-prepend replace-as
765 .. index:: no neighbor PEER local-as
766 .. clicmd:: no neighbor PEER local-as
768 Specify an alternate AS for this BGP process when interacting with the
769 specified peer. With no modifiers, the specified local-as is prepended to
770 the received AS_PATH when receiving routing updates from the peer, and
771 prepended to the outgoing AS_PATH (after the process local AS) when
772 transmitting local routes to the peer.
774 If the no-prepend attribute is specified, then the supplied local-as is not
775 prepended to the received AS_PATH.
777 If the replace-as attribute is specified, then only the supplied local-as is
778 prepended to the AS_PATH when transmitting local-route updates to this peer.
780 Note that replace-as can only be specified if no-prepend is.
782 This command is only allowed for eBGP peers.
784 .. index:: neighbor PEER ttl-security hops NUMBER
785 .. clicmd:: neighbor PEER ttl-security hops NUMBER
788 .. index:: no neighbor PEER ttl-security hops NUMBER
789 .. clicmd:: no neighbor PEER ttl-security hops NUMBER
791 This command enforces Generalized TTL Security Mechanism (GTSM), as
792 specified in RFC 5082. With this command, only neighbors that are the
793 specified number of hops away will be allowed to become neighbors. This
794 command is mutually exclusive with *ebgp-multihop*.
801 .. index:: neighbor PEER distribute-list NAME [in|out]
802 .. clicmd:: neighbor PEER distribute-list NAME [in|out]
804 This command specifies a distribute-list for the peer. `direct` is
807 .. index:: neighbor PEER prefix-list NAME [in|out]
808 .. clicmd:: neighbor PEER prefix-list NAME [in|out]
810 .. index:: neighbor PEER filter-list NAME [in|out]
811 .. clicmd:: neighbor PEER filter-list NAME [in|out]
813 .. index:: neighbor PEER route-map NAME [in|out]
814 .. clicmd:: neighbor PEER route-map NAME [in|out]
816 Apply a route-map on the neighbor. `direct` must be `in` or `out`.
818 .. index:: bgp route-reflector allow-outbound-policy
819 .. clicmd:: bgp route-reflector allow-outbound-policy
821 By default, attribute modification via route-map policy out is not reflected
822 on reflected routes. This option allows the modifications to be reflected as
823 well. Once enabled, it affects all reflected routes.
830 .. index:: neighbor WORD peer-group
831 .. clicmd:: neighbor WORD peer-group
833 This command defines a new peer group.
835 .. index:: neighbor PEER peer-group WORD
836 .. clicmd:: neighbor PEER peer-group WORD
838 This command bind specific peer to peer group WORD.
840 .. _bgp-address-family:
845 Multiprotocol BGP enables BGP to carry routing information for multiple Network
846 Layer protocols. BGP supports multiple Address Family Identifier (AFI), namely
847 IPv4 and IPv6. Support is also provided for multiple sets of per-AFI
848 information via Subsequent Address Family Identifiers (SAFI). In addition to
849 unicast information, VPN information :rfc:`4364` and :rfc:`4659`, and
850 Encapsulation attribute :rfc:`5512` is supported.
852 .. index:: show ip bgp ipv4 vpn
853 .. clicmd:: show ip bgp ipv4 vpn
855 .. index:: show ipv6 bgp ipv6 vpn
856 .. clicmd:: show ipv6 bgp ipv6 vpn
858 Print active IPV4 or IPV6 routes advertised via the VPN SAFI.
860 .. index:: show bgp ipv4 vpn summary
861 .. clicmd:: show bgp ipv4 vpn summary
863 .. index:: show bgp ipv6 vpn summary
864 .. clicmd:: show bgp ipv6 vpn summary
866 Print a summary of neighbor connections for the specified AFI/SAFI combination.
868 .. _autonomous-system:
873 The :abbr:`AS (Autonomous System)` number is one of the essential element of
874 BGP. BGP is a distance vector routing protocol, and the AS-Path framework
875 provides distance vector metric and loop detection to BGP. :rfc:`1930` provides
876 some background on the concepts of an AS.
878 The AS number is a two octet value, ranging in value from 1 to 65535. The AS
879 numbers 64512 through 65535 are defined as private AS numbers. Private AS
880 numbers must not to be advertised in the global Internet.
882 .. _display-bgp-routes-by-as-path:
884 Display BGP Routes by AS Path
885 -----------------------------
887 To show BGP routes which has specific AS path information `show ip bgp` command
890 .. index:: show bgp ipv4|ipv6 regexp LINE
891 .. clicmd:: show bgp ipv4|ipv6 regexp LINE
893 This commands displays BGP routes that matches a regular
894 expression `line` (:ref:`bgp-regular-expressions`).
896 .. _as-path-access-list:
901 AS path access list is user defined AS path.
903 .. index:: ip as-path access-list WORD permit|deny LINE
904 .. clicmd:: ip as-path access-list WORD permit|deny LINE
906 This command defines a new AS path access list.
908 .. index:: no ip as-path access-list WORD
909 .. clicmd:: no ip as-path access-list WORD
911 .. index:: no ip as-path access-list WORD permit|deny LINE
912 .. clicmd:: no ip as-path access-list WORD permit|deny LINE
914 .. _using-as-path-in-route-map:
916 Using AS Path in Route Map
917 --------------------------
919 .. index:: match as-path WORD
920 .. clicmd:: match as-path WORD
923 .. index:: set as-path prepend AS-PATH
924 .. clicmd:: set as-path prepend AS-PATH
926 Prepend the given string of AS numbers to the AS_PATH.
928 .. index:: set as-path prepend last-as NUM
929 .. clicmd:: set as-path prepend last-as NUM
931 Prepend the existing last AS number (the leftmost ASN) to the AS_PATH.
933 .. _private-as-numbers:
938 .. _bgp-communities-attribute:
940 BGP Communities Attribute
941 =========================
943 BGP communities attribute is widely used for implementing policy routing.
944 Network operators can manipulate BGP communities attribute based on their
945 network policy. BGP communities attribute is defined in :rfc:`1997` and
946 :rfc:`1998`. It is an optional transitive attribute, therefore local policy can
947 travel through different autonomous system.
949 Communities attribute is a set of communities values. Each communities value is
950 4 octet long. The following format is used to define communities value.
954 This format represents 4 octet communities value. ``AS`` is high order 2
955 octet in digit format. ``VAL`` is low order 2 octet in digit format. This
956 format is useful to define AS oriented policy value. For example,
957 ``7675:80`` can be used when AS 7675 wants to pass local policy value 80 to
961 `internet` represents well-known communities value 0.
964 ``no-export`` represents well-known communities value ``NO_EXPORT``
965 ``0xFFFFFF01``. All routes carry this value must not be advertised to
966 outside a BGP confederation boundary. If neighboring BGP peer is part of BGP
967 confederation, the peer is considered as inside a BGP confederation
968 boundary, so the route will be announced to the peer.
971 ``no-advertise`` represents well-known communities value ``NO_ADVERTISE``
972 ``0xFFFFFF02``. All routes carry this value must not be advertise to other
976 ``local-AS`` represents well-known communities value ``NO_EXPORT_SUBCONFED``
977 ``0xFFFFFF03``. All routes carry this value must not be advertised to
978 external BGP peers. Even if the neighboring router is part of confederation,
979 it is considered as external BGP peer, so the route will not be announced to
982 When BGP communities attribute is received, duplicated communities value in the
983 communities attribute is ignored and each communities values are sorted in
986 .. _bgp-community-lists:
991 BGP community list is a user defined BGP communities attribute list. BGP
992 community list can be used for matching or manipulating BGP communities
993 attribute in updates.
995 There are two types of community list. One is standard community list and
996 another is expanded community list. Standard community list defines communities
997 attribute. Expanded community list defines communities attribute string with
998 regular expression. Standard community list is compiled into binary format when
999 user define it. Standard community list will be directly compared to BGP
1000 communities attribute in BGP updates. Therefore the comparison is faster than
1001 expanded community list.
1003 .. index:: ip community-list standard NAME permit|deny COMMUNITY
1004 .. clicmd:: ip community-list standard NAME permit|deny COMMUNITY
1006 This command defines a new standard community list. COMUNITY is
1007 communities value. The COMUNITY is compiled into community structure. We
1008 can define multiple community list under same name. In that case match will
1009 happen user defined order. Once the community list matches to communities
1010 attribute in BGP updates it return permit or deny by the community list
1011 definition. When there is no matched entry, deny will be returned. When
1012 COMUNITY is empty it matches to any routes.
1014 .. index:: ip community-list expanded NAME permit|deny LINE
1015 .. clicmd:: ip community-list expanded NAME permit|deny LINE
1017 This command defines a new expanded community list. COMUNITY is a
1018 string expression of communities attribute. COMUNITY can be a
1019 regular expression (:ref:`bgp-regular-expressions`) to match
1020 the communities attribute in BGP updates.
1022 .. index:: no ip community-list NAME
1023 .. clicmd:: no ip community-list NAME
1025 .. index:: no ip community-list standard NAME
1026 .. clicmd:: no ip community-list standard NAME
1028 .. index:: no ip community-list expanded NAME
1029 .. clicmd:: no ip community-list expanded NAME
1031 These commands delete community lists specified by NAME. All of
1032 community lists shares a single name space. So community lists can be
1033 removed simply specifying community lists name.
1035 .. index:: show ip community-list
1036 .. clicmd:: show ip community-list
1038 .. index:: show ip community-list NAME
1039 .. clicmd:: show ip community-list NAME
1041 This command displays current community list information. When NAME is
1042 specified the specified community list's information is shown.
1046 # show ip community-list
1047 Named Community standard list CLIST
1048 permit 7675:80 7675:100 no-export
1050 Named Community expanded list EXPAND
1053 # show ip community-list CLIST
1054 Named Community standard list CLIST
1055 permit 7675:80 7675:100 no-export
1059 .. _numbered-bgp-community-lists:
1061 Numbered BGP Community Lists
1062 ----------------------------
1064 When number is used for BGP community list name, the number has
1065 special meanings. Community list number in the range from 1 and 99 is
1066 standard community list. Community list number in the range from 100
1067 to 199 is expanded community list. These community lists are called
1068 as numbered community lists. On the other hand normal community lists
1069 is called as named community lists.
1071 .. index:: ip community-list (1-99) permit|deny COMMUNITY
1072 .. clicmd:: ip community-list (1-99) permit|deny COMMUNITY
1074 This command defines a new community list. (1-99) is standard
1075 community list number. Community list name within this range defines
1076 standard community list. When `community` is empty it matches to
1079 .. index:: ip community-list (100-199) permit|deny COMMUNITY
1080 .. clicmd:: ip community-list (100-199) permit|deny COMMUNITY
1082 This command defines a new community list. (100-199) is expanded
1083 community list number. Community list name within this range defines
1084 expanded community list.
1086 .. index:: ip community-list NAME permit|deny COMMUNITY
1087 .. clicmd:: ip community-list NAME permit|deny COMMUNITY
1089 When community list type is not specified, the community list type is
1090 automatically detected. If COMMUNITY can be compiled into communities
1091 attribute, the community list is defined as a standard community list.
1092 Otherwise it is defined as an expanded community list. This feature is left
1093 for backward compatibility. Use of this feature is not recommended.
1095 .. _bgp-community-in-route-map:
1097 BGP Community in Route Map
1098 --------------------------
1100 In Route Map (:ref:`route-map`), we can match or set BGP
1101 communities attribute. Using this feature network operator can
1102 implement their network policy based on BGP communities attribute.
1104 Following commands can be used in Route Map.
1106 .. index:: match community WORD
1107 .. clicmd:: match community WORD
1109 .. index:: match community WORD exact-match
1110 .. clicmd:: match community WORD exact-match
1112 This command perform match to BGP updates using community list WORD. When
1113 the one of BGP communities value match to the one of communities value in
1114 community list, it is match. When `exact-match` keyword is specified, match
1115 happen only when BGP updates have completely same communities value
1116 specified in the community list.
1118 .. index:: set community none
1119 .. clicmd:: set community none
1121 .. index:: set community COMMUNITY
1122 .. clicmd:: set community COMMUNITY
1124 .. index:: set community COMMUNITY additive
1125 .. clicmd:: set community COMMUNITY additive
1127 This command manipulate communities value in BGP updates. When
1128 `none` is specified as communities value, it removes entire
1129 communities attribute from BGP updates. When `community` is not
1130 `none`, specified communities value is set to BGP updates. If
1131 BGP updates already has BGP communities value, the existing BGP
1132 communities value is replaced with specified `community` value.
1133 When `additive` keyword is specified, `community` is appended
1134 to the existing communities value.
1136 .. index:: set comm-list WORD delete
1137 .. clicmd:: set comm-list WORD delete
1139 This command remove communities value from BGP communities attribute.
1140 The `word` is community list name. When BGP route's communities
1141 value matches to the community list `word`, the communities value
1142 is removed. When all of communities value is removed eventually, the
1143 BGP update's communities attribute is completely removed.
1145 .. _display-bgp-routes-by-community:
1147 Display BGP Routes by Community
1148 -------------------------------
1150 To show BGP routes which has specific BGP communities attribute,
1151 `show bgp {ipv4|ipv6}` command can be used. The
1152 `community` and `community-list` subcommand can be used.
1154 .. index:: show bgp ipv4|ipv6 community
1155 .. clicmd:: show bgp ipv4|ipv6 community
1157 .. index:: show bgp ipv4|ipv6 community COMMUNITY
1158 .. clicmd:: show bgp ipv4|ipv6 community COMMUNITY
1160 .. index:: show bgp ipv4|ipv6 community COMMUNITY exact-match
1161 .. clicmd:: show bgp ipv4|ipv6 community COMMUNITY exact-match
1163 `show bgp {ipv4|ipv6} community` displays BGP routes which has communities
1164 attribute. Where the address family can be IPv4 or IPv6 among others. When
1165 `community` is specified, BGP routes that matches `community` value is
1166 displayed. For this command, `internet` keyword can't be used for
1167 `community` value. When `exact-match` is specified, it display only
1168 routes that have an exact match.
1170 .. index:: show bgp ipv4|ipv6 community-list WORD
1171 .. clicmd:: show bgp ipv4|ipv6 community-list WORD
1173 .. index:: show bgp ipv4|ipv6 community-list WORD exact-match
1174 .. clicmd:: show bgp ipv4|ipv6 community-list WORD exact-match
1176 This commands display BGP routes for the address family specified that matches
1177 community list `word`. When `exact-match` is specified, display only
1178 routes that have an exact match.
1180 .. _using-bgp-communities-attribute:
1182 Using BGP Communities Attribute
1183 -------------------------------
1185 Following configuration is the most typical usage of BGP communities
1186 attribute. AS 7675 provides upstream Internet connection to AS 100.
1187 When following configuration exists in AS 7675, AS 100 networks
1188 operator can set local preference in AS 7675 network by setting BGP
1189 communities attribute to the updates.
1195 neighbor 192.168.0.1 remote-as 100
1196 address-family ipv4 unicast
1197 neighbor 192.168.0.1 route-map RMAP in
1200 ip community-list 70 permit 7675:70
1201 ip community-list 70 deny
1202 ip community-list 80 permit 7675:80
1203 ip community-list 80 deny
1204 ip community-list 90 permit 7675:90
1205 ip community-list 90 deny
1207 route-map RMAP permit 10
1209 set local-preference 70
1211 route-map RMAP permit 20
1213 set local-preference 80
1215 route-map RMAP permit 30
1217 set local-preference 90
1220 Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675.
1221 The route has communities value 7675:80 so when above configuration
1222 exists in AS 7675, announced route's local preference will be set to
1229 neighbor 192.168.0.2 remote-as 7675
1230 address-family ipv4 unicast
1231 neighbor 192.168.0.2 route-map RMAP out
1234 ip prefix-list PLIST permit 10.0.0.0/8
1236 route-map RMAP permit 10
1237 match ip address prefix-list PLIST
1238 set community 7675:80
1241 Following configuration is an example of BGP route filtering using
1242 communities attribute. This configuration only permit BGP routes
1243 which has BGP communities value 0:80 or 0:90. Network operator can
1244 put special internal communities value at BGP border router, then
1245 limit the BGP routes announcement into the internal network.
1250 neighbor 192.168.0.1 remote-as 100
1251 address-family ipv4 unicast
1252 neighbor 192.168.0.1 route-map RMAP in
1255 ip community-list 1 permit 0:80 0:90
1257 route-map RMAP permit in
1261 Following example filter BGP routes which has communities value 1:1.
1262 When there is no match community-list returns deny. To avoid
1263 filtering all of routes, we need to define permit any at last.
1268 neighbor 192.168.0.1 remote-as 100
1269 address-family ipv4 unicast
1270 neighbor 192.168.0.1 route-map RMAP in
1273 ip community-list standard FILTER deny 1:1
1274 ip community-list standard FILTER permit
1276 route-map RMAP permit 10
1277 match community FILTER
1280 Communities value keyword `internet` has special meanings in
1281 standard community lists. In below example `internet` act as
1282 match any. It matches all of BGP routes even if the route does not
1283 have communities attribute at all. So community list ``INTERNET``
1284 is same as above example's ``FILTER``.
1288 ip community-list standard INTERNET deny 1:1
1289 ip community-list standard INTERNET permit internet
1292 Following configuration is an example of communities value deletion.
1293 With this configuration communities value 100:1 and 100:2 is removed
1294 from BGP updates. For communities value deletion, only `permit`
1295 community-list is used. `deny` community-list is ignored.
1300 neighbor 192.168.0.1 remote-as 100
1301 address-family ipv4 unicast
1302 neighbor 192.168.0.1 route-map RMAP in
1305 ip community-list standard DEL permit 100:1 100:2
1307 route-map RMAP permit 10
1308 set comm-list DEL delete
1311 .. _bgp-extended-communities-attribute:
1313 BGP Extended Communities Attribute
1314 ==================================
1316 BGP extended communities attribute is introduced with MPLS VPN/BGP technology.
1317 MPLS VPN/BGP expands capability of network infrastructure to provide VPN
1318 functionality. At the same time it requires a new framework for policy routing.
1319 With BGP Extended Communities Attribute we can use Route Target or Site of
1320 Origin for implementing network policy for MPLS VPN/BGP.
1322 BGP Extended Communities Attribute is similar to BGP Communities Attribute. It
1323 is an optional transitive attribute. BGP Extended Communities Attribute can
1324 carry multiple Extended Community value. Each Extended Community value is
1327 BGP Extended Communities Attribute provides an extended range compared with BGP
1328 Communities Attribute. Adding to that there is a type field in each value to
1329 provides community space structure.
1331 There are two format to define Extended Community value. One is AS based format
1332 the other is IP address based format.
1335 This is a format to define AS based Extended Community value.
1336 `AS` part is 2 octets Global Administrator subfield in Extended
1337 Community value. `VAL` part is 4 octets Local Administrator
1338 subfield. `7675:100` represents AS 7675 policy value 100.
1341 This is a format to define IP address based Extended Community value.
1342 `IP-Address` part is 4 octets Global Administrator subfield.
1343 `VAL` part is 2 octets Local Administrator subfield.
1344 `10.0.0.1:100` represents
1346 .. _bgp-extended-community-lists:
1348 BGP Extended Community Lists
1349 ----------------------------
1351 Expanded Community Lists is a user defined BGP Expanded Community
1354 .. index:: ip extcommunity-list standard NAME permit|deny EXTCOMMUNITY
1355 .. clicmd:: ip extcommunity-list standard NAME permit|deny EXTCOMMUNITY
1357 This command defines a new standard extcommunity-list. `extcommunity` is
1358 extended communities value. The `extcommunity` is compiled into extended
1359 community structure. We can define multiple extcommunity-list under same
1360 name. In that case match will happen user defined order. Once the
1361 extcommunity-list matches to extended communities attribute in BGP updates
1362 it return permit or deny based upon the extcommunity-list definition. When
1363 there is no matched entry, deny will be returned. When `extcommunity` is
1364 empty it matches to any routes.
1366 .. index:: ip extcommunity-list expanded NAME permit|deny LINE
1367 .. clicmd:: ip extcommunity-list expanded NAME permit|deny LINE
1369 This command defines a new expanded extcommunity-list. `line` is a string
1370 expression of extended communities attribute. `line` can be a regular
1371 expression (:ref:`bgp-regular-expressions`) to match an extended communities
1372 attribute in BGP updates.
1374 .. index:: no ip extcommunity-list NAME
1375 .. clicmd:: no ip extcommunity-list NAME
1377 .. index:: no ip extcommunity-list standard NAME
1378 .. clicmd:: no ip extcommunity-list standard NAME
1380 .. index:: no ip extcommunity-list expanded NAME
1381 .. clicmd:: no ip extcommunity-list expanded NAME
1383 These commands delete extended community lists specified by `name`. All of
1384 extended community lists shares a single name space. So extended community
1385 lists can be removed simply specifying the name.
1387 .. index:: show ip extcommunity-list
1388 .. clicmd:: show ip extcommunity-list
1390 .. index:: show ip extcommunity-list NAME
1391 .. clicmd:: show ip extcommunity-list NAME
1393 This command displays current extcommunity-list information. When `name` is
1394 specified the community list's information is shown.::
1396 # show ip extcommunity-list
1399 .. _bgp-extended-communities-in-route-map:
1401 BGP Extended Communities in Route Map
1402 -------------------------------------
1404 .. index:: match extcommunity WORD
1405 .. clicmd:: match extcommunity WORD
1408 .. index:: set extcommunity rt EXTCOMMUNITY
1409 .. clicmd:: set extcommunity rt EXTCOMMUNITY
1411 This command set Route Target value.
1413 .. index:: set extcommunity soo EXTCOMMUNITY
1414 .. clicmd:: set extcommunity soo EXTCOMMUNITY
1416 This command set Site of Origin value.
1418 .. _bgp-large-communities-attribute:
1420 BGP Large Communities Attribute
1421 ===============================
1423 The BGP Large Communities attribute was introduced in Feb 2017 with
1426 The BGP Large Communities Attribute is similar to the BGP Communities
1427 Attribute except that it has 3 components instead of two and each of
1428 which are 4 octets in length. Large Communities bring additional
1429 functionality and convenience over traditional communities, specifically
1430 the fact that the `GLOBAL` part below is now 4 octets wide allowing
1431 AS4 operators seamless use.
1434 *GLOBAL:LOCAL1:LOCAL2*
1435 This is the format to define Large Community values. Referencing
1436 :t:`RFC8195, Use of BGP Large Communities` the values are commonly
1437 referred to as follows.
1438 The `GLOBAL` part is a 4 octet Global Administrator field, common
1439 use of this field is the operators AS number.
1440 The `LOCAL1` part is a 4 octet Local Data Part 1 subfield referred
1442 The `LOCAL2` part is a 4 octet Local Data Part 2 field and referred
1443 to as the parameter subfield. `65551:1:10` represents AS 65551
1444 function 1 and parameter 10.
1445 The referenced RFC above gives some guidelines on recommended usage.
1447 .. _bgp-large-community-lists:
1449 BGP Large Community Lists
1450 -------------------------
1452 Two types of large community lists are supported, namely `standard` and
1455 .. index:: ip large-community-list standard NAME permit|deny LARGE-COMMUNITY
1456 .. clicmd:: ip large-community-list standard NAME permit|deny LARGE-COMMUNITY
1458 This command defines a new standard large-community-list. `large-community`
1459 is the Large Community value. We can add multiple large communities under
1460 same name. In that case the match will happen in the user defined order.
1461 Once the large-community-list matches the Large Communities attribute in BGP
1462 updates it will return permit or deny based upon the large-community-list
1463 definition. When there is no matched entry, a deny will be returned. When
1464 `large-community` is empty it matches any routes.
1466 .. index:: ip large-community-list expanded NAME permit|deny LINE
1467 .. clicmd:: ip large-community-list expanded NAME permit|deny LINE
1469 This command defines a new expanded large-community-list. Where `line` is a
1470 string matching expression, it will be compared to the entire Large
1471 Communities attribute as a string, with each large-community in order from
1472 lowest to highest. `line` can also be a regular expression which matches
1473 this Large Community attribute.
1475 .. index:: no ip large-community-list NAME
1476 .. clicmd:: no ip large-community-list NAME
1478 .. index:: no ip large-community-list standard NAME
1479 .. clicmd:: no ip large-community-list standard NAME
1481 .. index:: no ip large-community-list expanded NAME
1482 .. clicmd:: no ip large-community-list expanded NAME
1484 These commands delete Large Community lists specified by `name`. All Large
1485 Community lists share a single namespace. This means Large Community lists
1486 can be removed by simply specifying the name.
1488 .. index:: show ip large-community-list
1489 .. clicmd:: show ip large-community-list
1491 .. index:: show ip large-community-list NAME
1492 .. clicmd:: show ip large-community-list NAME
1494 This command display current large-community-list information. When
1495 `name` is specified the community list information is shown.
1497 .. index:: show ip bgp large-community-info
1498 .. clicmd:: show ip bgp large-community-info
1500 This command displays the current large communities in use.
1502 .. _bgp-large-communities-in-route-map:
1504 BGP Large Communities in Route Map
1505 ----------------------------------
1507 .. index:: match large-community LINE
1508 .. clicmd:: match large-community LINE
1510 Where `line` can be a simple string to match, or a regular expression. It
1511 is very important to note that this match occurs on the entire
1512 large-community string as a whole, where each large-community is ordered
1513 from lowest to highest.
1515 .. index:: set large-community LARGE-COMMUNITY
1516 .. clicmd:: set large-community LARGE-COMMUNITY
1518 .. index:: set large-community LARGE-COMMUNITY LARGE-COMMUNITY
1519 .. clicmd:: set large-community LARGE-COMMUNITY LARGE-COMMUNITY
1521 .. index:: set large-community LARGE-COMMUNITY additive
1522 .. clicmd:: set large-community LARGE-COMMUNITY additive
1524 These commands are used for setting large-community values. The first
1525 command will overwrite any large-communities currently present.
1526 The second specifies two large-communities, which overwrites the current
1527 large-community list. The third will add a large-community value without
1528 overwriting other values. Multiple large-community values can be specified.
1536 BPGD supports multiple VRF instances via the *router bgp* command:
1538 .. index:: router bgp ASN vrf VRFNAME
1539 .. clicmd:: router bgp ASN vrf VRFNAME
1541 VRFNAME is matched against VRFs configured in the kernel. When no *vrf VRFNAME*
1542 is specified, the BGP protocol process belongs to the default VRF.
1544 With VRF, you can isolate networking information. Having BGP VRF allows you to
1545 have several BGP instances on the same system process. This solution solves
1546 scalabiliy issues where the network administrator had previously to run separately
1547 several BGP processes on each namespace. Now, not only BGP VRF solves this, but
1548 also this method applies to both kind of VRFs backend: default VRF from Linux kernel
1549 or network namespaces. Also, having separate BGP instances does not imply that the
1550 AS number has to be different. For internal purposes, it is possible to do iBGP
1551 peering from two differents network namespaces.
1553 BGP routes may be leaked (i.e., copied) between a unicast VRF RIB and the VPN
1554 safi RIB of the default VRF (leaking is also permitted between the unicast RIB
1555 of the default VRF and VPN). A shortcut syntax is also available for
1556 specifying leaking from one vrf to another vrf using the VPN RIB as
1557 the intemediary. A common application of the VPN-VRF feature is to
1558 connect a customer's private routing domain to a provider's VPN service.
1559 Leaking is configured from the point of view of an individual VRF: ``import``
1560 refers to routes leaked from VPN to a unicast VRF, whereas ``export`` refers to
1561 routes leaked from a unicast VRF to VPN.
1566 Routes exported from a unicast VRF to the VPN RIB must be augmented by two
1569 - an :abbr:`RD (Route Distinguisher)`
1570 - an :abbr:`RTLIST (Route-target List)`
1572 Configuration for these exported routes must, at a minimum, specify these two
1575 Routes imported from the VPN RIB to a unicast VRF are selected according to
1576 their RTLISTs. Routes whose RTLIST contains at least one route-target in
1577 common with the configured import RTLIST are leaked. Configuration for these
1578 imported routes must specify an RTLIST to be matched.
1580 The RD, which carries no semantic value, is intended to make the route unique
1581 in the VPN RIB among all routes of its prefix that originate from all the
1582 customers and sites that are attached to the provider's VPN service.
1583 Accordingly, each site of each customer is typically assigned an RD that is
1584 unique across the entire provider network.
1586 The RTLIST is a set of route-target extended community values whose purpose is
1587 to specify route-leaking policy. Typically, a customer is assigned a single
1588 route-target value for import and export to be used at all customer sites. This
1589 configuration specifies a simple topology wherein a customer has a single
1590 routing domain which is shared across all its sites. More complex routing
1591 topologies are possible through use of additional route-targets to augment the
1592 leaking of sets of routes in various ways.
1594 When using the shortcut syntax for vrf-to-vrf leaking, the RD and RT are
1600 Configuration of route leaking between a unicast VRF RIB and the VPN safi RIB
1601 of the default VRF is accomplished via commands in the context of a VRF
1604 .. index:: rd vpn export AS:NN|IP:nn
1605 .. clicmd:: rd vpn export AS:NN|IP:nn
1607 Specifies the route distinguisher to be added to a route exported from the
1608 current unicast VRF to VPN.
1610 .. index:: no rd vpn export [AS:NN|IP:nn]
1611 .. clicmd:: no rd vpn export [AS:NN|IP:nn]
1613 Deletes any previously-configured export route distinguisher.
1615 .. index:: rt vpn import|export|both RTLIST...
1616 .. clicmd:: rt vpn import|export|both RTLIST...
1618 Specifies the route-target list to be attached to a route (export) or the
1619 route-target list to match against (import) when exporting/importing between
1620 the current unicast VRF and VPN.
1622 The RTLIST is a space-separated list of route-targets, which are BGP
1623 extended community values as described in
1624 :ref:`bgp-extended-communities-attribute`.
1626 .. index:: no rt vpn import|export|both [RTLIST...]
1627 .. clicmd:: no rt vpn import|export|both [RTLIST...]
1629 Deletes any previously-configured import or export route-target list.
1631 .. index:: label vpn export (0..1048575)|auto
1632 .. clicmd:: label vpn export (0..1048575)|auto
1634 Specifies an optional MPLS label to be attached to a route exported from the
1635 current unicast VRF to VPN. If label is specified as ``auto``, the label
1636 value is automatically assigned from a pool maintained by the zebra
1637 daemon. If zebra is not running, automatic label assignment will not
1638 complete, which will block corresponding route export.
1640 .. index:: no label vpn export [(0..1048575)|auto]
1641 .. clicmd:: no label vpn export [(0..1048575)|auto]
1643 Deletes any previously-configured export label.
1645 .. index:: nexthop vpn export A.B.C.D|X:X::X:X
1646 .. clicmd:: nexthop vpn export A.B.C.D|X:X::X:X
1648 Specifies an optional nexthop value to be assigned to a route exported from
1649 the current unicast VRF to VPN. If left unspecified, the nexthop will be set
1650 to 0.0.0.0 or 0:0::0:0 (self).
1652 .. index:: no nexthop vpn export [A.B.C.D|X:X::X:X]
1653 .. clicmd:: no nexthop vpn export [A.B.C.D|X:X::X:X]
1655 Deletes any previously-configured export nexthop.
1657 .. index:: route-map vpn import|export MAP
1658 .. clicmd:: route-map vpn import|export MAP
1660 Specifies an optional route-map to be applied to routes imported or exported
1661 between the current unicast VRF and VPN.
1663 .. index:: no route-map vpn import|export [MAP]
1664 .. clicmd:: no route-map vpn import|export [MAP]
1666 Deletes any previously-configured import or export route-map.
1668 .. index:: import|export vpn
1669 .. clicmd:: import|export vpn
1671 Enables import or export of routes between the current unicast VRF and VPN.
1673 .. index:: no import|export vpn
1674 .. clicmd:: no import|export vpn
1676 Disables import or export of routes between the current unicast VRF and VPN.
1678 .. index:: import vrf VRFNAME
1679 .. clicmd:: import vrf VRFNAME
1681 Shortcut syntax for specifying automatic leaking from vrf VRFNAME to
1682 the current VRF using the VPN RIB as intermediary. The RD and RT
1683 are auto derived and should not be specified explicitly for either the
1684 source or destination VRF's.
1686 This shortcut syntax mode is not compatible with the explicit
1687 `import vpn` and `export vpn` statements for the two VRF's involved.
1688 The CLI will disallow attempts to configure incompatible leaking
1691 .. index:: no import vrf VRFNAME
1692 .. clicmd:: no import vrf VRFNAME
1694 Disables automatic leaking from vrf VRFNAME to the current VRF using
1695 the VPN RIB as intermediary.
1697 .. _displaying-bgp-information:
1699 Displaying BGP information
1700 ==========================
1703 .. _showing-bgp-information:
1705 Showing BGP information
1706 -----------------------
1708 .. index:: show ip bgp
1709 .. clicmd:: show ip bgp
1711 .. index:: show ip bgp A.B.C.D
1712 .. clicmd:: show ip bgp A.B.C.D
1714 .. index:: show ip bgp X:X::X:X
1715 .. clicmd:: show ip bgp X:X::X:X
1717 This command displays BGP routes. When no route is specified it
1718 display all of IPv4 BGP routes.
1722 BGP table version is 0, local router ID is 10.1.1.1
1723 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
1724 Origin codes: i - IGP, e - EGP, ? - incomplete
1726 Network Next Hop Metric LocPrf Weight Path
1727 \*> 1.1.1.1/32 0.0.0.0 0 32768 i
1729 Total number of prefixes 1
1732 .. index:: show ip bgp regexp LINE
1733 .. clicmd:: show ip bgp regexp LINE
1735 This command displays BGP routes using AS path regular expression
1736 (:ref:`bgp-regular-expressions`).
1738 .. index:: show ip bgp community COMMUNITY
1739 .. clicmd:: show ip bgp community COMMUNITY
1741 .. index:: show ip bgp community COMMUNITY exact-match
1742 .. clicmd:: show ip bgp community COMMUNITY exact-match
1744 This command displays BGP routes using `community`
1745 (:ref:`display-bgp-routes-by-community`).
1747 .. index:: show ip bgp community-list WORD
1748 .. clicmd:: show ip bgp community-list WORD
1750 .. index:: show ip bgp community-list WORD exact-match
1751 .. clicmd:: show ip bgp community-list WORD exact-match
1753 This command displays BGP routes using community list
1754 (:ref:`display-bgp-routes-by-community`).
1756 .. index:: show bgp ipv4|ipv6 summary
1757 .. clicmd:: show bgp ipv4|ipv6 summary
1759 Show a bgp peer summary for the specified address family.
1761 .. index:: show bgp ipv4|ipv6 neighbor [PEER]
1762 .. clicmd:: show bgp ipv4|ipv6 neighbor [PEER]
1764 This command shows information on a specific BGP `peer`.
1766 .. index:: show bgp ipv4|ipv6 dampening dampened-paths
1767 .. clicmd:: show bgp ipv4|ipv6 dampening dampened-paths
1769 Display paths suppressed due to dampening.
1771 .. index:: show bgp ipv4|ipv6 dampening flap-statistics
1772 .. clicmd:: show bgp ipv4|ipv6 dampening flap-statistics
1774 Display flap statistics of routes.
1776 .. _other-bgp-commands:
1781 .. index:: clear bgp ipv4|ipv6 \*
1782 .. clicmd:: clear bgp ipv4|ipv6 \*
1784 Clear all address family peers.
1786 .. index:: clear bgp ipv4|ipv6 PEER
1787 .. clicmd:: clear bgp ipv4|ipv6 PEER
1789 Clear peers which have addresses of X.X.X.X
1791 .. index:: clear bgp ipv4|ipv6 PEER soft in
1792 .. clicmd:: clear bgp ipv4|ipv6 PEER soft in
1794 Clear peer using soft reconfiguration.
1796 .. index:: show debug
1797 .. clicmd:: show debug
1799 .. index:: debug event
1800 .. clicmd:: debug event
1802 .. index:: debug update
1803 .. clicmd:: debug update
1805 .. index:: debug keepalive
1806 .. clicmd:: debug keepalive
1808 .. index:: no debug event
1809 .. clicmd:: no debug event
1811 .. index:: no debug update
1812 .. clicmd:: no debug update
1814 .. index:: no debug keepalive
1815 .. clicmd:: no debug keepalive
1818 .. _capability-negotiation:
1820 Capability Negotiation
1821 ======================
1823 When adding IPv6 routing information exchange feature to BGP. There were some
1824 proposals. :abbr:`IETF (Internet Engineering Task Force)`
1825 :abbr:`IDR (Inter Domain Routing)` adopted a proposal called Multiprotocol
1826 Extension for BGP. The specification is described in :rfc:`2283`. The protocol
1827 does not define new protocols. It defines new attributes to existing BGP. When
1828 it is used exchanging IPv6 routing information it is called BGP-4+. When it is
1829 used for exchanging multicast routing information it is called MBGP.
1831 *bgpd* supports Multiprotocol Extension for BGP. So if a remote peer supports
1832 the protocol, *bgpd* can exchange IPv6 and/or multicast routing information.
1834 Traditional BGP did not have the feature to detect a remote peer's
1835 capabilities, e.g. whether it can handle prefix types other than IPv4 unicast
1836 routes. This was a big problem using Multiprotocol Extension for BGP in an
1837 operational network. :rfc:`2842` adopted a feature called Capability
1838 Negotiation. *bgpd* use this Capability Negotiation to detect the remote peer's
1839 capabilities. If a peer is only configured as an IPv4 unicast neighbor, *bgpd*
1840 does not send these Capability Negotiation packets (at least not unless other
1841 optional BGP features require capability negotiation).
1843 By default, FRR will bring up peering with minimal common capability for the
1844 both sides. For example, if the local router has unicast and multicast
1845 capabilities and the remote router only has unicast capability the local router
1846 will establish the connection with unicast only capability. When there are no
1847 common capabilities, FRR sends Unsupported Capability error and then resets the
1850 If you want to completely match capabilities with remote peer. Please use
1851 *strict-capability-match* command.
1853 .. index:: neighbor PEER strict-capability-match
1854 .. clicmd:: neighbor PEER strict-capability-match
1856 .. index:: no neighbor PEER strict-capability-match
1857 .. clicmd:: no neighbor PEER strict-capability-match
1859 Strictly compares remote capabilities and local capabilities. If
1860 capabilities are different, send Unsupported Capability error then reset
1863 You may want to disable sending Capability Negotiation OPEN message optional
1864 parameter to the peer when remote peer does not implement Capability
1865 Negotiation. Please use *dont-capability-negotiate* command to disable the
1868 .. index:: neighbor PEER dont-capability-negotiate
1869 .. clicmd:: neighbor PEER dont-capability-negotiate
1871 .. index:: no neighbor PEER dont-capability-negotiate
1872 .. clicmd:: no neighbor PEER dont-capability-negotiate
1874 Suppress sending Capability Negotiation as OPEN message optional parameter
1875 to the peer. This command only affects the peer is configured other than
1876 IPv4 unicast configuration.
1878 When remote peer does not have capability negotiation feature, remote peer
1879 will not send any capabilities at all. In that case, bgp configures the peer
1880 with configured capabilities.
1882 You may prefer locally configured capabilities more than the negotiated
1883 capabilities even though remote peer sends capabilities. If the peer is
1884 configured by *override-capability*, *bgpd* ignores received capabilities
1885 then override negotiated capabilities with configured values.
1887 .. index:: neighbor PEER override-capability
1888 .. clicmd:: neighbor PEER override-capability
1890 .. index:: no neighbor PEER override-capability
1891 .. clicmd:: no neighbor PEER override-capability
1893 Override the result of Capability Negotiation with local configuration.
1894 Ignore remote peer's capability value.
1896 .. _route-reflector:
1901 .. index:: bgp cluster-id A.B.C.D
1902 .. clicmd:: bgp cluster-id A.B.C.D
1904 .. index:: neighbor PEER route-reflector-client
1905 .. clicmd:: neighbor PEER route-reflector-client
1907 .. index:: no neighbor PEER route-reflector-client
1908 .. clicmd:: no neighbor PEER route-reflector-client
1916 At an Internet Exchange point, many ISPs are connected to each other by the
1917 "full mesh method". As with internal BGP full mesh formation, this method has a
1920 This scaling problem is well known. Route Server is a method to resolve the
1921 problem. Each ISP's BGP router only peers to Route Server. Route Server serves
1922 as BGP information exchange to other BGP routers. By applying this method,
1923 numbers of BGP connections is reduced from O(n*(n-1)/2) to O(n).
1925 Unlike a normal BGP router, Route Server must have several routing tables for
1926 managing different routing policies for each BGP speaker. We call the routing
1927 tables as different "views". *bgpd* can work as normal BGP router or Route
1928 Server or both at the same time.
1930 .. _multiple-instance:
1935 The multiple instances feature of *bgpd* is by default turned on. This command
1936 is deprecated and will be removed in a future version of FRR. If you do not
1937 want multiple instances, do not configure them from the cli. Please note
1938 that some commands auto-generate a second instance.
1940 .. index:: bgp multiple-instance
1941 .. clicmd:: bgp multiple-instance
1943 Enable BGP multiple instance feature. This is the default
1944 configuration and this cli will not be displayed. This command
1945 is deprecated and will be removed in the future.
1947 .. index:: no bgp multiple-instance
1948 .. clicmd:: no bgp multiple-instance
1950 Disable BGP multiple instance feature. You can not disable this feature
1951 when BGP multiple instances or views exist. This command
1952 is deprecated and will be removed in the future.
1954 When you want to make configuration more Cisco like one,
1956 .. index:: bgp config-type cisco
1957 .. clicmd:: bgp config-type cisco
1959 Cisco compatible BGP configuration output. This command is deprecated
1960 and will be removed in a future version of FRR. Please transition
1961 to using the appropriate bgp commands to affect your behavior.
1963 When bgp config-type cisco is specified,
1965 ``no synchronization`` is displayed. This command does nothing and
1966 is for display purposes only.
1967 ``no auto-summary`` is displayed.
1969 The ``network`` and ``aggregate-address`` arguments are displayed as::
1973 FRR: network 10.0.0.0/8
1974 Cisco: network 10.0.0.0
1976 FRR: aggregate-address 192.168.0.0/24
1977 Cisco: aggregate-address 192.168.0.0 255.255.255.0
1979 Community attribute handling is also different. If no configuration is
1980 specified community attribute and extended community attribute are sent to the
1981 neighbor. If a user manually disables the feature, the community attribute is
1982 not sent to the neighbor. When ``bgp config-type cisco`` is specified, the
1983 community attribute is not sent to the neighbor by default. To send the
1984 community attribute user has to specify *neighbor A.B.C.D send-community*
1991 neighbor 10.0.0.1 remote-as 1
1992 address-family ipv4 unicast
1993 no neighbor 10.0.0.1 send-community
1997 neighbor 10.0.0.1 remote-as 1
1998 address-family ipv4 unicast
1999 neighbor 10.0.0.1 send-community
2004 .. index:: bgp config-type zebra
2005 .. clicmd:: bgp config-type zebra
2007 FRR style BGP configuration. This is default. This command is deprecated
2008 and will be removed in the future.
2010 .. _bgp-instance-and-view:
2012 BGP instance and view
2013 ---------------------
2015 BGP instance is a normal BGP process. The result of route selection goes to the
2016 kernel routing table. You can setup different AS at the same time when BGP
2017 multiple instance feature is enabled.
2019 .. index:: router bgp AS-NUMBER
2020 .. clicmd:: router bgp AS-NUMBER
2022 Make a new BGP instance. You can use an arbitrary word for the `name`.
2026 bgp multiple-instance
2029 neighbor 10.0.0.1 remote-as 2
2030 neighbor 10.0.0.2 remote-as 3
2033 neighbor 10.0.0.3 remote-as 4
2034 neighbor 10.0.0.4 remote-as 5
2037 BGP view is almost same as normal BGP process. The result of route selection
2038 does not go to the kernel routing table. BGP view is only for exchanging BGP
2039 routing information.
2041 .. index:: router bgp AS-NUMBER view NAME
2042 .. clicmd:: router bgp AS-NUMBER view NAME
2044 Make a new BGP view. You can use arbitrary word for the `name`. This view's
2045 route selection result does not go to the kernel routing table.
2047 With this command, you can setup Route Server like below.
2051 bgp multiple-instance
2054 neighbor 10.0.0.1 remote-as 2
2055 neighbor 10.0.0.2 remote-as 3
2058 neighbor 10.0.0.3 remote-as 4
2059 neighbor 10.0.0.4 remote-as 5
2067 You can set different routing policy for a peer. For example, you can set
2068 different filter for a peer.
2072 bgp multiple-instance
2075 neighbor 10.0.0.1 remote-as 2
2076 address-family ipv4 unicast
2077 neighbor 10.0.0.1 distribute-list 1 in
2081 neighbor 10.0.0.1 remote-as 2
2082 address-family ipv4 unicast
2083 neighbor 10.0.0.1 distribute-list 2 in
2087 This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view 2.
2088 When the update is inserted into view 1, distribute-list 1 is applied. On the
2089 other hand, when the update is inserted into view 2, distribute-list 2 is
2092 .. _viewing-the-view:
2097 To display routing table of BGP view, you must specify view name.
2099 .. index:: show ip bgp view NAME
2100 .. clicmd:: show ip bgp view NAME
2102 Display routing table of BGP view ``NAME``.
2104 .. _bgp-regular-expressions:
2106 BGP Regular Expressions
2107 =======================
2109 BGP regular expressions are based on `POSIX 1003.2` regular expressions. The
2110 following description is just a quick subset of the `POSIX` regular
2111 expressions. Adding to that, the special character '_' is added.
2115 Matches any single character.
2118 Matches 0 or more occurrences of pattern.
2121 Matches 1 or more occurrences of pattern.
2124 Match 0 or 1 occurrences of pattern.
2127 Matches the beginning of the line.
2130 Matches the end of the line.
2133 Character `_` has special meanings in BGP regular expressions. It matches
2134 to space and comma , and AS set delimiter { and } and AS confederation
2135 delimiter `(` and `)`. And it also matches to the beginning of the line and
2136 the end of the line. So `_` can be used for AS value boundaries match. This
2137 character technically evaluates to `(^|[,{}() ]|$)`.
2139 .. _how-to-set-up-a-6-bone-connection:
2141 How to set up a 6-Bone connection
2142 =================================
2146 ! bgpd configuration
2147 ! ==================
2149 ! MP-BGP configuration
2152 bgp router-id 10.0.0.1
2153 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as `as-number`
2156 network 3ffe:506::/32
2157 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
2158 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
2159 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as `as-number`
2160 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
2163 ipv6 access-list all permit any
2165 ! Set output nexthop address.
2167 route-map set-nexthop permit 10
2168 match ipv6 address all
2169 set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
2170 set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
2176 .. _dump-bgp-packets-and-table:
2178 Dump BGP packets and table
2179 ==========================
2181 .. index:: dump bgp all PATH [INTERVAL]
2182 .. clicmd:: dump bgp all PATH [INTERVAL]
2184 .. index:: dump bgp all-et PATH [INTERVAL]
2185 .. clicmd:: dump bgp all-et PATH [INTERVAL]
2187 .. index:: no dump bgp all [PATH] [INTERVAL]
2188 .. clicmd:: no dump bgp all [PATH] [INTERVAL]
2190 Dump all BGP packet and events to `path` file.
2191 If `interval` is set, a new file will be created for echo `interval` of
2192 seconds. The path `path` can be set with date and time formatting
2193 (strftime). The type ‘all-et’ enables support for Extended Timestamp Header
2194 (:ref:`packet-binary-dump-format`).
2196 .. index:: dump bgp updates PATH [INTERVAL]
2197 .. clicmd:: dump bgp updates PATH [INTERVAL]
2199 .. index:: dump bgp updates-et PATH [INTERVAL]
2200 .. clicmd:: dump bgp updates-et PATH [INTERVAL]
2202 .. index:: no dump bgp updates [PATH] [INTERVAL]
2203 .. clicmd:: no dump bgp updates [PATH] [INTERVAL]
2205 Dump only BGP updates messages to `path` file.
2206 If `interval` is set, a new file will be created for echo `interval` of
2207 seconds. The path `path` can be set with date and time formatting
2208 (strftime). The type ‘updates-et’ enables support for Extended Timestamp
2209 Header (:ref:`packet-binary-dump-format`).
2211 .. index:: dump bgp routes-mrt PATH
2212 .. clicmd:: dump bgp routes-mrt PATH
2214 .. index:: dump bgp routes-mrt PATH INTERVAL
2215 .. clicmd:: dump bgp routes-mrt PATH INTERVAL
2217 .. index:: no dump bgp route-mrt [PATH] [INTERVAL]
2218 .. clicmd:: no dump bgp route-mrt [PATH] [INTERVAL]
2220 Dump whole BGP routing table to `path`. This is heavy process. The path
2221 `path` can be set with date and time formatting (strftime). If `interval` is
2222 set, a new file will be created for echo `interval` of seconds.
2224 Note: the interval variable can also be set using hours and minutes: 04h20m00.
2226 .. _bgp-configuration-examples:
2228 BGP Configuration Examples
2229 ==========================
2231 Example of a session to an upstream, advertising only one prefix to it.
2236 bgp router-id 10.236.87.1
2237 neighbor upstream peer-group
2238 neighbor upstream remote-as 64515
2239 neighbor upstream capability dynamic
2240 neighbor 10.1.1.1 peer-group upstream
2241 neighbor 10.1.1.1 description ACME ISP
2243 address-family ipv4 unicast
2244 network 10.236.87.0/24
2245 neighbor upstream prefix-list pl-allowed-adv out
2248 ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
2249 ip prefix-list pl-allowed-adv seq 10 deny any
2251 A more complex example. With upstream, peer and customer sessions. Advertising
2252 global prefixes and NO_EXPORT prefixes and providing actions for customer
2253 routes based on community values. Extensive use of route-maps and the 'call'
2254 feature to support selective advertising of prefixes. This example is intended
2255 as guidance only, it has NOT been tested and almost certainly contains silly
2256 mistakes, if not serious flaws.
2261 bgp router-id 10.236.87.1
2262 neighbor upstream capability dynamic
2263 neighbor cust capability dynamic
2264 neighbor peer capability dynamic
2265 neighbor 10.1.1.1 remote-as 64515
2266 neighbor 10.1.1.1 peer-group upstream
2267 neighbor 10.2.1.1 remote-as 64516
2268 neighbor 10.2.1.1 peer-group upstream
2269 neighbor 10.3.1.1 remote-as 64517
2270 neighbor 10.3.1.1 peer-group cust-default
2271 neighbor 10.3.1.1 description customer1
2272 neighbor 10.4.1.1 remote-as 64518
2273 neighbor 10.4.1.1 peer-group cust
2274 neighbor 10.4.1.1 description customer2
2275 neighbor 10.5.1.1 remote-as 64519
2276 neighbor 10.5.1.1 peer-group peer
2277 neighbor 10.5.1.1 description peer AS 1
2278 neighbor 10.6.1.1 remote-as 64520
2279 neighbor 10.6.1.1 peer-group peer
2280 neighbor 10.6.1.1 description peer AS 2
2282 address-family ipv4 unicast
2283 network 10.123.456.0/24
2284 network 10.123.456.128/25 route-map rm-no-export
2285 neighbor upstream route-map rm-upstream-out out
2286 neighbor cust route-map rm-cust-in in
2287 neighbor cust route-map rm-cust-out out
2288 neighbor cust send-community both
2289 neighbor peer route-map rm-peer-in in
2290 neighbor peer route-map rm-peer-out out
2291 neighbor peer send-community both
2292 neighbor 10.3.1.1 prefix-list pl-cust1-network in
2293 neighbor 10.4.1.1 prefix-list pl-cust2-network in
2294 neighbor 10.5.1.1 prefix-list pl-peer1-network in
2295 neighbor 10.6.1.1 prefix-list pl-peer2-network in
2298 ip prefix-list pl-default permit 0.0.0.0/0
2300 ip prefix-list pl-upstream-peers permit 10.1.1.1/32
2301 ip prefix-list pl-upstream-peers permit 10.2.1.1/32
2303 ip prefix-list pl-cust1-network permit 10.3.1.0/24
2304 ip prefix-list pl-cust1-network permit 10.3.2.0/24
2306 ip prefix-list pl-cust2-network permit 10.4.1.0/24
2308 ip prefix-list pl-peer1-network permit 10.5.1.0/24
2309 ip prefix-list pl-peer1-network permit 10.5.2.0/24
2310 ip prefix-list pl-peer1-network permit 192.168.0.0/24
2312 ip prefix-list pl-peer2-network permit 10.6.1.0/24
2313 ip prefix-list pl-peer2-network permit 10.6.2.0/24
2314 ip prefix-list pl-peer2-network permit 192.168.1.0/24
2315 ip prefix-list pl-peer2-network permit 192.168.2.0/24
2316 ip prefix-list pl-peer2-network permit 172.16.1/24
2318 ip as-path access-list asp-own-as permit ^$
2319 ip as-path access-list asp-own-as permit _64512_
2321 ! #################################################################
2322 ! Match communities we provide actions for, on routes receives from
2323 ! customers. Communities values of <our-ASN>:X, with X, have actions:
2325 ! 100 - blackhole the prefix
2326 ! 200 - set no_export
2327 ! 300 - advertise only to other customers
2328 ! 400 - advertise only to upstreams
2329 ! 500 - set no_export when advertising to upstreams
2330 ! 2X00 - set local_preference to X00
2332 ! blackhole the prefix of the route
2333 ip community-list standard cm-blackhole permit 64512:100
2335 ! set no-export community before advertising
2336 ip community-list standard cm-set-no-export permit 64512:200
2338 ! advertise only to other customers
2339 ip community-list standard cm-cust-only permit 64512:300
2341 ! advertise only to upstreams
2342 ip community-list standard cm-upstream-only permit 64512:400
2344 ! advertise to upstreams with no-export
2345 ip community-list standard cm-upstream-noexport permit 64512:500
2347 ! set local-pref to least significant 3 digits of the community
2348 ip community-list standard cm-prefmod-100 permit 64512:2100
2349 ip community-list standard cm-prefmod-200 permit 64512:2200
2350 ip community-list standard cm-prefmod-300 permit 64512:2300
2351 ip community-list standard cm-prefmod-400 permit 64512:2400
2352 ip community-list expanded cme-prefmod-range permit 64512:2...
2354 ! Informational communities
2356 ! 3000 - learned from upstream
2357 ! 3100 - learned from customer
2358 ! 3200 - learned from peer
2360 ip community-list standard cm-learnt-upstream permit 64512:3000
2361 ip community-list standard cm-learnt-cust permit 64512:3100
2362 ip community-list standard cm-learnt-peer permit 64512:3200
2364 ! ###################################################################
2365 ! Utility route-maps
2367 ! These utility route-maps generally should not used to permit/deny
2368 ! routes, i.e. they do not have meaning as filters, and hence probably
2369 ! should be used with 'on-match next'. These all finish with an empty
2370 ! permit entry so as not interfere with processing in the caller.
2372 route-map rm-no-export permit 10
2373 set community additive no-export
2374 route-map rm-no-export permit 20
2376 route-map rm-blackhole permit 10
2377 description blackhole, up-pref and ensure it cant escape this AS
2378 set ip next-hop 127.0.0.1
2379 set local-preference 10
2380 set community additive no-export
2381 route-map rm-blackhole permit 20
2383 ! Set local-pref as requested
2384 route-map rm-prefmod permit 10
2385 match community cm-prefmod-100
2386 set local-preference 100
2387 route-map rm-prefmod permit 20
2388 match community cm-prefmod-200
2389 set local-preference 200
2390 route-map rm-prefmod permit 30
2391 match community cm-prefmod-300
2392 set local-preference 300
2393 route-map rm-prefmod permit 40
2394 match community cm-prefmod-400
2395 set local-preference 400
2396 route-map rm-prefmod permit 50
2398 ! Community actions to take on receipt of route.
2399 route-map rm-community-in permit 10
2400 description check for blackholing, no point continuing if it matches.
2401 match community cm-blackhole
2403 route-map rm-community-in permit 20
2404 match community cm-set-no-export
2407 route-map rm-community-in permit 30
2408 match community cme-prefmod-range
2410 route-map rm-community-in permit 40
2412 ! #####################################################################
2413 ! Community actions to take when advertising a route.
2414 ! These are filtering route-maps,
2416 ! Deny customer routes to upstream with cust-only set.
2417 route-map rm-community-filt-to-upstream deny 10
2418 match community cm-learnt-cust
2419 match community cm-cust-only
2420 route-map rm-community-filt-to-upstream permit 20
2422 ! Deny customer routes to other customers with upstream-only set.
2423 route-map rm-community-filt-to-cust deny 10
2424 match community cm-learnt-cust
2425 match community cm-upstream-only
2426 route-map rm-community-filt-to-cust permit 20
2428 ! ###################################################################
2429 ! The top-level route-maps applied to sessions. Further entries could
2430 ! be added obviously..
2433 route-map rm-cust-in permit 10
2434 call rm-community-in
2436 route-map rm-cust-in permit 20
2437 set community additive 64512:3100
2438 route-map rm-cust-in permit 30
2440 route-map rm-cust-out permit 10
2441 call rm-community-filt-to-cust
2443 route-map rm-cust-out permit 20
2445 ! Upstream transit ASes
2446 route-map rm-upstream-out permit 10
2447 description filter customer prefixes which are marked cust-only
2448 call rm-community-filt-to-upstream
2450 route-map rm-upstream-out permit 20
2451 description only customer routes are provided to upstreams/peers
2452 match community cm-learnt-cust
2455 ! outbound policy is same as for upstream
2456 route-map rm-peer-out permit 10
2457 call rm-upstream-out
2459 route-map rm-peer-in permit 10
2460 set community additive 64512:3200
2462 .. include:: routeserver.rst
2464 .. include:: rpki.rst
2467 .. [#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 and 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)
2468 .. [bgp-route-osci-cond] McPherson, D. and Gill, V. and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", IETF RFC3345
2469 .. [stable-flexible-ibgp] Flavel, A. and M. Roughan, "Stable and flexible iBGP", ACM SIGCOMM 2009
2470 .. [ibgp-correctness] Griffin, T. and G. Wilfong, "On the correctness of IBGP configuration", ACM SIGCOMM 2002