7 :abbr:`BGP` stands for 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` and updated by
10 :rfc:`4271`. :rfc:`2858` adds multiprotocol support to BGP-4.
17 The default configuration file of *bgpd* is :file:`bgpd.conf`. *bgpd* searches
18 the current directory first, followed by |INSTALL_PREFIX_ETC|/bgpd.conf. All of
19 *bgpd*'s commands must be configured in :file:`bgpd.conf` when the integrated
20 config is not being used.
22 *bgpd* specific invocation options are described below. Common options may also
23 be specified (:ref:`common-invocation-options`).
27 .. option:: -p, --bgp_port <port>
29 Set the bgp protocol's port number. When port number is 0, that means do not
32 .. option:: -l, --listenon
34 Specify specific IP addresses for bgpd to listen on, rather than its default
35 of ``0.0.0.0`` / ``::``. This can be useful to constrain bgpd to an internal
36 address, or to run multiple bgpd processes on one host. Multiple addresses
39 In the following example, bgpd is started listening for connections on the
40 addresses 100.0.1.2 and fd00::2:2. The options -d (runs in daemon mode) and
41 -f (uses specific configuration file) are also used in this example as we
42 are likely to run multiple bgpd instances, each one with different
43 configurations, when using -l option.
45 Note that this option implies the --no_kernel option, and no learned routes will be installed into the linux kernel.
49 # /usr/lib/frr/bgpd -d -f /some-folder/bgpd.conf -l 100.0.1.2 -l fd00::2:2
51 .. option:: -n, --no_kernel
53 Do not install learned routes into the linux kernel. This option is useful
54 for a route-reflector environment or if you are running multiple bgp
55 processes in the same namespace. This option is different than the --no_zebra
56 option in that a ZAPI connection is made.
58 This option can also be toggled during runtime by using the
59 ``[no] bgp no-rib`` commands in VTY shell.
61 Note that this option will persist after saving the configuration during
62 runtime, unless unset by the ``no bgp no-rib`` command in VTY shell prior to
63 a configuration write operation.
65 .. option:: -S, --skip_runas
67 Skip the normal process of checking capabilities and changing user and group
70 .. option:: -e, --ecmp
72 Run BGP with a limited ecmp capability, that is different than what BGP
73 was compiled with. The value specified must be greater than 0 and less
74 than or equal to the MULTIPATH_NUM specified on compilation.
76 .. option:: -Z, --no_zebra
78 Do not communicate with zebra at all. This is different than the --no_kernel
79 option in that we do not even open a ZAPI connection to the zebra process.
81 .. option:: -s, --socket_size
83 When opening tcp connections to our peers, set the socket send buffer
84 size that the kernel will use for the peers socket. This option
85 is only really useful at a very large scale. Experimentation should
86 be done to see if this is helping or not at the scale you are running
92 .. option:: -I, --int_num
94 Set zclient id. This is required when using Zebra label manager in proxy mode.
96 .. _bgp-basic-concepts:
101 .. _bgp-autonomous-systems:
108 An AS is a connected group of one or more IP prefixes run by one or more
109 network operators which has a SINGLE and CLEARLY DEFINED routing policy.
111 Each AS has an identifying number associated with it called an :abbr:`ASN
112 (Autonomous System Number)`. This is a two octet value ranging in value from 1
113 to 65535. The AS numbers 64512 through 65535 are defined as private AS numbers.
114 Private AS numbers must not be advertised on the global Internet.
116 The :abbr:`ASN (Autonomous System Number)` is one of the essential elements of
117 BGP. BGP is a distance vector routing protocol, and the AS-Path framework
118 provides distance vector metric and loop detection to BGP.
120 .. seealso:: :rfc:`1930`
122 .. _bgp-address-families:
127 Multiprotocol extensions enable BGP to carry routing information for multiple
128 network layer protocols. BGP supports an Address Family Identifier (AFI) for
129 IPv4 and IPv6. Support is also provided for multiple sets of per-AFI
130 information via the BGP Subsequent Address Family Identifier (SAFI). FRR
131 supports SAFIs for unicast information, labeled information (:rfc:`3107` and
132 :rfc:`8277`), and Layer 3 VPN information (:rfc:`4364` and :rfc:`4659`).
134 .. _bgp-route-selection:
139 The route selection process used by FRR's BGP implementation uses the following
140 decision criterion, starting at the top of the list and going towards the
141 bottom until one of the factors can be used.
145 Prefer higher local weight routes to lower routes.
147 2. **Local preference check**
149 Prefer higher local preference routes to lower.
151 3. **Local route check**
153 Prefer local routes (statics, aggregates, redistributed) to received routes.
155 4. **AS path length check**
157 Prefer shortest hop-count AS_PATHs.
161 Prefer the lowest origin type route. That is, prefer IGP origin routes to
162 EGP, to Incomplete routes.
166 Where routes with a MED were received from the same AS, prefer the route
167 with the lowest MED. :ref:`bgp-med`.
169 7. **External check**
171 Prefer the route received from an external, eBGP peer over routes received
172 from other types of peers.
174 8. **IGP cost check**
176 Prefer the route with the lower IGP cost.
178 9. **Multi-path check**
180 If multi-pathing is enabled, then check whether the routes not yet
181 distinguished in preference may be considered equal. If
182 :clicmd:`bgp bestpath as-path multipath-relax` is set, all such routes are
183 considered equal, otherwise routes received via iBGP with identical AS_PATHs
184 or routes received from eBGP neighbours in the same AS are considered equal.
186 10. **Already-selected external check**
188 Where both routes were received from eBGP peers, then prefer the route
189 which is already selected. Note that this check is not applied if
190 :clicmd:`bgp bestpath compare-routerid` is configured. This check can
191 prevent some cases of oscillation.
193 11. **Router-ID check**
195 Prefer the route with the lowest `router-ID`. If the route has an
196 `ORIGINATOR_ID` attribute, through iBGP reflection, then that router ID is
197 used, otherwise the `router-ID` of the peer the route was received from is
200 12. **Cluster-List length check**
202 The route with the shortest cluster-list length is used. The cluster-list
203 reflects the iBGP reflection path the route has taken.
207 Prefer the route received from the peer with the higher transport layer
208 address, as a last-resort tie-breaker.
210 .. _bgp-capability-negotiation:
212 Capability Negotiation
213 ----------------------
215 When adding IPv6 routing information exchange feature to BGP. There were some
216 proposals. :abbr:`IETF (Internet Engineering Task Force)`
217 :abbr:`IDR (Inter Domain Routing)` adopted a proposal called Multiprotocol
218 Extension for BGP. The specification is described in :rfc:`2283`. The protocol
219 does not define new protocols. It defines new attributes to existing BGP. When
220 it is used exchanging IPv6 routing information it is called BGP-4+. When it is
221 used for exchanging multicast routing information it is called MBGP.
223 *bgpd* supports Multiprotocol Extension for BGP. So if a remote peer supports
224 the protocol, *bgpd* can exchange IPv6 and/or multicast routing information.
226 Traditional BGP did not have the feature to detect a remote peer's
227 capabilities, e.g. whether it can handle prefix types other than IPv4 unicast
228 routes. This was a big problem using Multiprotocol Extension for BGP in an
229 operational network. :rfc:`2842` adopted a feature called Capability
230 Negotiation. *bgpd* use this Capability Negotiation to detect the remote peer's
231 capabilities. If a peer is only configured as an IPv4 unicast neighbor, *bgpd*
232 does not send these Capability Negotiation packets (at least not unless other
233 optional BGP features require capability negotiation).
235 By default, FRR will bring up peering with minimal common capability for the
236 both sides. For example, if the local router has unicast and multicast
237 capabilities and the remote router only has unicast capability the local router
238 will establish the connection with unicast only capability. When there are no
239 common capabilities, FRR sends Unsupported Capability error and then resets the
242 .. _bgp-router-configuration:
244 BGP Router Configuration
245 ========================
250 First of all you must configure BGP router with the :clicmd:`router bgp ASN`
251 command. The AS number is an identifier for the autonomous system. The BGP
252 protocol uses the AS number for detecting whether the BGP connection is
253 internal or external.
255 .. clicmd:: router bgp ASN
257 Enable a BGP protocol process with the specified ASN. After
258 this statement you can input any `BGP Commands`.
260 .. clicmd:: bgp router-id A.B.C.D
262 This command specifies the router-ID. If *bgpd* connects to *zebra* it gets
263 interface and address information. In that case default router ID value is
264 selected as the largest IP Address of the interfaces. When `router zebra` is
265 not enabled *bgpd* can't get interface information so `router-id` is set to
266 0.0.0.0. So please set router-id by hand.
269 .. _bgp-multiple-autonomous-systems:
271 Multiple Autonomous Systems
272 ---------------------------
274 FRR's BGP implementation is capable of running multiple autonomous systems at
275 once. Each configured AS corresponds to a :ref:`zebra-vrf`. In the past, to get
276 the same functionality the network administrator had to run a new *bgpd*
277 process; using VRFs allows multiple autonomous systems to be handled in a
280 When using multiple autonomous systems, all router config blocks after the
281 first one must specify a VRF to be the target of BGP's route selection. This
282 VRF must be unique within respect to all other VRFs being used for the same
283 purpose, i.e. two different autonomous systems cannot use the same VRF.
284 However, the same AS can be used with different VRFs.
288 The separated nature of VRFs makes it possible to peer a single *bgpd*
289 process to itself, on one machine. Note that this can be done fully within
290 BGP without a corresponding VRF in the kernel or Zebra, which enables some
291 practical use cases such as :ref:`route reflectors <bgp-route-reflector>`
294 Configuration of additional autonomous systems, or of a router that targets a
295 specific VRF, is accomplished with the following command:
297 .. clicmd:: router bgp ASN vrf VRFNAME
299 ``VRFNAME`` is matched against VRFs configured in the kernel. When ``vrf
300 VRFNAME`` is not specified, the BGP protocol process belongs to the default
303 An example configuration with multiple autonomous systems might look like this:
308 neighbor 10.0.0.1 remote-as 20
309 neighbor 10.0.0.2 remote-as 30
311 router bgp 2 vrf blue
312 neighbor 10.0.0.3 remote-as 40
313 neighbor 10.0.0.4 remote-as 50
316 neighbor 10.0.0.5 remote-as 60
317 neighbor 10.0.0.6 remote-as 70
320 .. seealso:: :ref:`bgp-vrf-route-leaking`
321 .. seealso:: :ref:`zebra-vrf`
329 In addition to supporting multiple autonomous systems, FRR's BGP implementation
330 also supports *views*.
332 BGP views are almost the same as normal BGP processes, except that routes
333 selected by BGP are not installed into the kernel routing table. Each BGP view
334 provides an independent set of routing information which is only distributed
335 via BGP. Multiple views can be supported, and BGP view information is always
336 independent from other routing protocols and Zebra/kernel routes. BGP views use
337 the core instance (i.e., default VRF) for communication with peers.
339 .. clicmd:: router bgp AS-NUMBER view NAME
341 Make a new BGP view. You can use an arbitrary word for the ``NAME``. Routes
342 selected by the view are not installed into the kernel routing table.
344 With this command, you can setup Route Server like below.
350 neighbor 10.0.0.1 remote-as 2
351 neighbor 10.0.0.2 remote-as 3
354 neighbor 10.0.0.3 remote-as 4
355 neighbor 10.0.0.4 remote-as 5
357 .. clicmd:: show [ip] bgp view NAME
359 Display the routing table of BGP view ``NAME``.
365 .. clicmd:: bgp bestpath as-path confed
367 This command specifies that the length of confederation path sets and
368 sequences should should be taken into account during the BGP best path
371 .. clicmd:: bgp bestpath as-path multipath-relax
373 This command specifies that BGP decision process should consider paths
374 of equal AS_PATH length candidates for multipath computation. Without
375 the knob, the entire AS_PATH must match for multipath computation.
377 .. clicmd:: bgp bestpath compare-routerid
379 Ensure that when comparing routes where both are equal on most metrics,
380 including local-pref, AS_PATH length, IGP cost, MED, that the tie is broken
383 If this option is enabled, then the already-selected check, where
384 already selected eBGP routes are preferred, is skipped.
386 If a route has an `ORIGINATOR_ID` attribute because it has been reflected,
387 that `ORIGINATOR_ID` will be used. Otherwise, the router-ID of the peer the
388 route was received from will be used.
390 The advantage of this is that the route-selection (at this point) will be
391 more deterministic. The disadvantage is that a few or even one lowest-ID
392 router may attract all traffic to otherwise-equal paths because of this
393 check. It may increase the possibility of MED or IGP oscillation, unless
394 other measures were taken to avoid these. The exact behaviour will be
395 sensitive to the iBGP and reflection topology.
397 .. clicmd:: bgp bestpath peer-type multipath-relax
399 This command specifies that BGP decision process should consider paths
400 from all peers for multipath computation. If this option is enabled,
401 paths learned from any of eBGP, iBGP, or confederation neighbors will
402 be multipath if they are otherwise considered equal cost.
406 Administrative Distance Metrics
407 -------------------------------
409 .. clicmd:: distance bgp (1-255) (1-255) (1-255)
411 This command change distance value of BGP. The arguments are the distance
412 values for for external routes, internal routes and local routes
415 .. clicmd:: distance (1-255) A.B.C.D/M
417 .. clicmd:: distance (1-255) A.B.C.D/M WORD
419 Sets the administrative distance for a particular route.
421 .. _bgp-requires-policy:
423 Require policy on EBGP
424 -------------------------------
426 .. clicmd:: bgp ebgp-requires-policy
428 This command requires incoming and outgoing filters to be applied
429 for eBGP sessions as part of RFC-8212 compliance. Without the incoming
430 filter, no routes will be accepted. Without the outgoing filter, no
431 routes will be announced.
433 This is enabled by default for the traditional configuration and
434 turned off by default for datacenter configuration.
436 When you enable/disable this option you MUST clear the session.
438 When the incoming or outgoing filter is missing you will see
439 "(Policy)" sign under ``show bgp summary``:
443 exit1# show bgp summary
445 IPv4 Unicast Summary:
446 BGP router identifier 10.10.10.1, local AS number 65001 vrf-id 0
448 RIB entries 7, using 1344 bytes of memory
449 Peers 2, using 43 KiB of memory
451 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt
452 192.168.0.2 4 65002 8 10 0 0 0 00:03:09 5 (Policy)
453 fe80:1::2222 4 65002 9 11 0 0 0 00:03:09 (Policy) (Policy)
455 Additionally a `show bgp neighbor` command would indicate in the `For address family:`
460 exit1# show bgp neighbor
462 For address family: IPv4 Unicast
463 Update group 1, subgroup 1
464 Packet Queue length 0
465 Inbound soft reconfiguration allowed
466 Community attribute sent to this neighbor(all)
467 Inbound updates discarded due to missing policy
468 Outbound updates discarded due to missing policy
471 Reject routes with AS_SET or AS_CONFED_SET types
472 ------------------------------------------------
474 .. clicmd:: bgp reject-as-sets
476 This command enables rejection of incoming and outgoing routes having AS_SET or AS_CONFED_SET type.
478 Suppress duplicate updates
479 --------------------------
481 .. clicmd:: bgp suppress-duplicates
483 For example, BGP routers can generate multiple identical announcements with
484 empty community attributes if stripped at egress. This is an undesired behavior.
485 Suppress duplicate updates if the route actually not changed.
488 Disable checking if nexthop is connected on EBGP sessions
489 ---------------------------------------------------------
491 .. clicmd:: bgp disable-ebgp-connected-route-check
493 This command is used to disable the connection verification process for EBGP peering sessions
494 that are reachable by a single hop but are configured on a loopback interface or otherwise
495 configured with a non-directly connected IP address.
497 .. _bgp-route-flap-dampening:
502 .. clicmd:: bgp dampening [(1-45) [(1-20000) (1-20000) (1-255)]]
504 This command enables (with optionally specified dampening parameters) or
505 disables route-flap dampening for all routes of a BGP instance.
507 .. clicmd:: neighbor PEER dampening [(1-45) [(1-20000) (1-20000) (1-255)]]
509 This command enables (with optionally specified dampening parameters) or
510 disables route-flap dampening for all routes learned from a BGP peer.
512 .. clicmd:: neighbor GROUP dampening [(1-45) [(1-20000) (1-20000) (1-255)]]
514 This command enables (with optionally specified dampening parameters) or
515 disables route-flap dampening for all routes learned from peers of a peer
519 Half-life time for the penalty in minutes (default value: 15).
522 Value to start reusing a route (default value: 750).
525 Value to start suppressing a route (default value: 2000).
528 Maximum duration to suppress a stable route in minutes (default value:
531 The route-flap damping algorithm is compatible with :rfc:`2439`. The use of
532 these commands is not recommended nowadays.
534 At the moment, route-flap dampening is not working per VRF and is working only
535 for IPv4 unicast and multicast.
537 With different parameter sets configurable for BGP instances, peer groups and
538 peers, the active dampening profile for a route is chosen on the fly,
539 allowing for various changes in configuration (i.e. peer group memberships)
540 during runtime. The parameter sets are taking precedence in the following
547 The negating commands do not allow to exclude a peer/peer group from a peer
548 group/BGP instances configuration.
551 https://www.ripe.net/publications/docs/ripe-378
555 Multi-Exit Discriminator
556 ------------------------
558 The BGP :abbr:`MED (Multi-Exit Discriminator)` attribute has properties which
559 can cause subtle convergence problems in BGP. These properties and problems
560 have proven to be hard to understand, at least historically, and may still not
561 be widely understood. The following attempts to collect together and present
562 what is known about MED, to help operators and FRR users in designing and
563 configuring their networks.
565 The BGP :abbr:`MED` attribute is intended to allow one AS to indicate its
566 preferences for its ingress points to another AS. The MED attribute will not be
567 propagated on to another AS by the receiving AS - it is 'non-transitive' in the
570 E.g., if AS X and AS Y have 2 different BGP peering points, then AS X might set
571 a MED of 100 on routes advertised at one and a MED of 200 at the other. When AS
572 Y selects between otherwise equal routes to or via AS X, AS Y should prefer to
573 take the path via the lower MED peering of 100 with AS X. Setting the MED
574 allows an AS to influence the routing taken to it within another, neighbouring
577 In this use of MED it is not really meaningful to compare the MED value on
578 routes where the next AS on the paths differs. E.g., if AS Y also had a route
579 for some destination via AS Z in addition to the routes from AS X, and AS Z had
580 also set a MED, it wouldn't make sense for AS Y to compare AS Z's MED values to
581 those of AS X. The MED values have been set by different administrators, with
582 different frames of reference.
584 The default behaviour of BGP therefore is to not compare MED values across
585 routes received from different neighbouring ASes. In FRR this is done by
586 comparing the neighbouring, left-most AS in the received AS_PATHs of the routes
587 and only comparing MED if those are the same.
589 Unfortunately, this behaviour of MED, of sometimes being compared across routes
590 and sometimes not, depending on the properties of those other routes, means MED
591 can cause the order of preference over all the routes to be undefined. That is,
592 given routes A, B, and C, if A is preferred to B, and B is preferred to C, then
593 a well-defined order should mean the preference is transitive (in the sense of
594 orders [#med-transitivity-rant]_) and that A would be preferred to C.
596 However, when MED is involved this need not be the case. With MED it is
597 possible that C is actually preferred over A. So A is preferred to B, B is
598 preferred to C, but C is preferred to A. This can be true even where BGP
599 defines a deterministic 'most preferred' route out of the full set of A,B,C.
600 With MED, for any given set of routes there may be a deterministically
601 preferred route, but there need not be any way to arrange them into any order
602 of preference. With unmodified MED, the order of preference of routes literally
605 That MED can induce non-transitive preferences over routes can cause issues.
606 Firstly, it may be perceived to cause routing table churn locally at speakers;
607 secondly, and more seriously, it may cause routing instability in iBGP
608 topologies, where sets of speakers continually oscillate between different
611 The first issue arises from how speakers often implement routing decisions.
612 Though BGP defines a selection process that will deterministically select the
613 same route as best at any given speaker, even with MED, that process requires
614 evaluating all routes together. For performance and ease of implementation
615 reasons, many implementations evaluate route preferences in a pair-wise fashion
616 instead. Given there is no well-defined order when MED is involved, the best
617 route that will be chosen becomes subject to implementation details, such as
618 the order the routes are stored in. That may be (locally) non-deterministic,
619 e.g.: it may be the order the routes were received in.
621 This indeterminism may be considered undesirable, though it need not cause
622 problems. It may mean additional routing churn is perceived, as sometimes more
623 updates may be produced than at other times in reaction to some event .
625 This first issue can be fixed with a more deterministic route selection that
626 ensures routes are ordered by the neighbouring AS during selection.
627 :clicmd:`bgp deterministic-med`. This may reduce the number of updates as routes
628 are received, and may in some cases reduce routing churn. Though, it could
629 equally deterministically produce the largest possible set of updates in
630 response to the most common sequence of received updates.
632 A deterministic order of evaluation tends to imply an additional overhead of
633 sorting over any set of n routes to a destination. The implementation of
634 deterministic MED in FRR scales significantly worse than most sorting
635 algorithms at present, with the number of paths to a given destination. That
636 number is often low enough to not cause any issues, but where there are many
637 paths, the deterministic comparison may quickly become increasingly expensive
640 Deterministic local evaluation can *not* fix the second, more major, issue of
641 MED however. Which is that the non-transitive preference of routes MED can
642 cause may lead to routing instability or oscillation across multiple speakers
643 in iBGP topologies. This can occur with full-mesh iBGP, but is particularly
644 problematic in non-full-mesh iBGP topologies that further reduce the routing
645 information known to each speaker. This has primarily been documented with iBGP
646 :ref:`route-reflection <bgp-route-reflector>` topologies. However, any
647 route-hiding technologies potentially could also exacerbate oscillation with MED.
649 This second issue occurs where speakers each have only a subset of routes, and
650 there are cycles in the preferences between different combinations of routes -
651 as the undefined order of preference of MED allows - and the routes are
652 distributed in a way that causes the BGP speakers to 'chase' those cycles. This
653 can occur even if all speakers use a deterministic order of evaluation in route
656 E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X, and from
657 speaker 3 in AS Y; while speaker 5 in AS A might receive that route from
658 speaker 1 in AS Y. AS Y might set a MED of 200 at speaker 1, and 100 at speaker
659 3. I.e, using ASN:ID:MED to label the speakers:
665 X:2------|--A:4-------A:5--|-Y:1:200
671 Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs), then based
672 on the RFC4271 decision process speaker 4 will choose X:2 over Y:3:100, based
673 on the lower ID of 2. Speaker 4 advertises X:2 to speaker 5. Speaker 5 will
674 continue to prefer Y:1:200 based on the ID, and advertise this to speaker 4.
675 Speaker 4 will now have the full set of routes, and the Y:1:200 it receives
676 from 5 will beat X:2, but when speaker 4 compares Y:1:200 to Y:3:100 the MED
677 check now becomes active as the ASes match, and now Y:3:100 is preferred.
678 Speaker 4 therefore now advertises Y:3:100 to 5, which will also agrees that
679 Y:3:100 is preferred to Y:1:200, and so withdraws the latter route from 4.
680 Speaker 4 now has only X:2 and Y:3:100, and X:2 beats Y:3:100, and so speaker 4
681 implicitly updates its route to speaker 5 to X:2. Speaker 5 sees that Y:1:200
682 beats X:2 based on the ID, and advertises Y:1:200 to speaker 4, and the cycle
685 The root cause is the lack of a clear order of preference caused by how MED
686 sometimes is and sometimes is not compared, leading to this cycle in the
687 preferences between the routes:
692 /---> X:2 ---beats---> Y:3:100 --\\
695 \\---beats--- Y:1:200 <---beats---/
699 This particular type of oscillation in full-mesh iBGP topologies can be
700 avoided by speakers preferring already selected, external routes rather than
701 choosing to update to new a route based on a post-MED metric (e.g. router-ID),
702 at the cost of a non-deterministic selection process. FRR implements this, as
703 do many other implementations, so long as it is not overridden by setting
704 :clicmd:`bgp bestpath compare-routerid`, and see also
705 :ref:`bgp-route-selection`.
707 However, more complex and insidious cycles of oscillation are possible with
708 iBGP route-reflection, which are not so easily avoided. These have been
709 documented in various places. See, e.g.:
711 - [bgp-route-osci-cond]_
712 - [stable-flexible-ibgp]_
713 - [ibgp-correctness]_
715 for concrete examples and further references.
717 There is as of this writing *no* known way to use MED for its original purpose;
718 *and* reduce routing information in iBGP topologies; *and* be sure to avoid the
719 instability problems of MED due the non-transitive routing preferences it can
720 induce; in general on arbitrary networks.
722 There may be iBGP topology specific ways to reduce the instability risks, even
723 while using MED, e.g.: by constraining the reflection topology and by tuning
724 IGP costs between route-reflector clusters, see :rfc:`3345` for details. In the
725 near future, the Add-Path extension to BGP may also solve MED oscillation while
726 still allowing MED to be used as intended, by distributing "best-paths per
727 neighbour AS". This would be at the cost of distributing at least as many
728 routes to all speakers as a full-mesh iBGP would, if not more, while also
729 imposing similar CPU overheads as the "Deterministic MED" feature at each
732 More generally, the instability problems that MED can introduce on more
733 complex, non-full-mesh, iBGP topologies may be avoided either by:
735 - Setting :clicmd:`bgp always-compare-med`, however this allows MED to be compared
736 across values set by different neighbour ASes, which may not produce
737 coherent desirable results, of itself.
738 - Effectively ignoring MED by setting MED to the same value (e.g.: 0) using
739 :clicmd:`set metric METRIC` on all received routes, in combination with
740 setting :clicmd:`bgp always-compare-med` on all speakers. This is the simplest
741 and most performant way to avoid MED oscillation issues, where an AS is happy
742 not to allow neighbours to inject this problematic metric.
744 As MED is evaluated after the AS_PATH length check, another possible use for
745 MED is for intra-AS steering of routes with equal AS_PATH length, as an
746 extension of the last case above. As MED is evaluated before IGP metric, this
747 can allow cold-potato routing to be implemented to send traffic to preferred
748 hand-offs with neighbours, rather than the closest hand-off according to the
751 Note that even if action is taken to address the MED non-transitivity issues,
752 other oscillations may still be possible. E.g., on IGP cost if iBGP and IGP
753 topologies are at cross-purposes with each other - see the Flavel and Roughan
754 paper above for an example. Hence the guideline that the iBGP topology should
755 follow the IGP topology.
757 .. clicmd:: bgp deterministic-med
759 Carry out route-selection in way that produces deterministic answers
760 locally, even in the face of MED and the lack of a well-defined order of
761 preference it can induce on routes. Without this option the preferred route
762 with MED may be determined largely by the order that routes were received
765 Setting this option will have a performance cost that may be noticeable when
766 there are many routes for each destination. Currently in FRR it is
767 implemented in a way that scales poorly as the number of routes per
768 destination increases.
770 The default is that this option is not set.
772 Note that there are other sources of indeterminism in the route selection
773 process, specifically, the preference for older and already selected routes
774 from eBGP peers, :ref:`bgp-route-selection`.
776 .. clicmd:: bgp always-compare-med
778 Always compare the MED on routes, even when they were received from
779 different neighbouring ASes. Setting this option makes the order of
780 preference of routes more defined, and should eliminate MED induced
783 If using this option, it may also be desirable to use
784 :clicmd:`set metric METRIC` to set MED to 0 on routes received from external
787 This option can be used, together with :clicmd:`set metric METRIC` to use
788 MED as an intra-AS metric to steer equal-length AS_PATH routes to, e.g.,
792 .. _bgp-graceful-restart:
797 BGP graceful restart functionality as defined in
798 `RFC-4724 <https://tools.ietf.org/html/rfc4724/>`_ defines the mechanisms that
799 allows BGP speaker to continue to forward data packets along known routes
800 while the routing protocol information is being restored.
803 Usually, when BGP on a router restarts, all the BGP peers detect that the
804 session went down and then came up. This "down/up" transition results in a
805 "routing flap" and causes BGP route re-computation, generation of BGP routing
806 updates, and unnecessary churn to the forwarding tables.
808 The following functionality is provided by graceful restart:
810 1. The feature allows the restarting router to indicate to the helping peer the
811 routes it can preserve in its forwarding plane during control plane restart
812 by sending graceful restart capability in the OPEN message sent during
813 session establishment.
814 2. The feature allows helping router to advertise to all other peers the routes
815 received from the restarting router which are preserved in the forwarding
816 plane of the restarting router during control plane restart.
823 (R1)-----------------------------------------------------------------(R2)
825 1. BGP Graceful Restart Capability exchanged between R1 & R2.
827 <--------------------------------------------------------------------->
829 2. Kill BGP Process at R1.
831 ---------------------------------------------------------------------->
833 3. R2 Detects the above BGP Restart & verifies BGP Restarting
836 4. Start BGP Process at R1.
838 5. Re-establish the BGP session between R1 & R2.
840 <--------------------------------------------------------------------->
842 6. R2 Send initial route updates, followed by End-Of-Rib.
844 <----------------------------------------------------------------------
846 7. R1 was waiting for End-Of-Rib from R2 & which has been received
849 8. R1 now runs BGP Best-Path algorithm. Send Initial BGP Update,
850 followed by End-Of Rib
852 <--------------------------------------------------------------------->
855 .. _bgp-GR-preserve-forwarding-state:
857 BGP-GR Preserve-Forwarding State
858 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
860 BGP OPEN message carrying optional capabilities for Graceful Restart has
861 8 bit “Flags for Address Family” for given AFI and SAFI. This field contains
862 bit flags relating to routes that were advertised with the given AFI and SAFI.
871 The most significant bit is defined as the Forwarding State (F) bit, which
872 can be used to indicate whether the forwarding state for routes that were
873 advertised with the given AFI and SAFI has indeed been preserved during the
874 previous BGP restart. When set (value 1), the bit indicates that the
875 forwarding state has been preserved.
876 The remaining bits are reserved and MUST be set to zero by the sender and
877 ignored by the receiver.
879 .. clicmd:: bgp graceful-restart preserve-fw-state
881 FRR gives us the option to enable/disable the "F" flag using this specific
882 vty command. However, it doesn't have the option to enable/disable
883 this flag only for specific AFI/SAFI i.e. when this command is used, it
884 applied to all the supported AFI/SAFI combinations for this peer.
886 .. _bgp-end-of-rib-message:
888 End-of-RIB (EOR) message
889 ^^^^^^^^^^^^^^^^^^^^^^^^
891 An UPDATE message with no reachable Network Layer Reachability Information
892 (NLRI) and empty withdrawn NLRI is specified as the End-of-RIB marker that can
893 be used by a BGP speaker to indicate to its peer the completion of the initial
894 routing update after the session is established.
896 For the IPv4 unicast address family, the End-of-RIB marker is an UPDATE message
897 with the minimum length. For any other address family, it is an UPDATE message
898 that contains only the MP_UNREACH_NLRI attribute with no withdrawn routes for
901 Although the End-of-RIB marker is specified for the purpose of BGP graceful
902 restart, it is noted that the generation of such a marker upon completion of
903 the initial update would be useful for routing convergence in general, and thus
904 the practice is recommended.
906 .. _bgp-route-selection-deferral-timer:
908 Route Selection Deferral Timer
909 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
911 Specifies the time the restarting router defers the route selection process
914 Restarting Router : The usage of route election deferral timer is specified
915 in https://tools.ietf.org/html/rfc4724#section-4.1
917 Once the session between the Restarting Speaker and the Receiving Speaker is
918 re-established, the Restarting Speaker will receive and process BGP messages
921 However, it MUST defer route selection for an address family until it either.
923 1. Receives the End-of-RIB marker from all its peers (excluding the ones with
924 the "Restart State" bit set in the received capability and excluding the ones
925 that do not advertise the graceful restart capability).
926 2. The Selection_Deferral_Timer timeout.
928 .. clicmd:: bgp graceful-restart select-defer-time (0-3600)
930 This is command, will set deferral time to value specified.
933 .. clicmd:: bgp graceful-restart rib-stale-time (1-3600)
935 This is command, will set the time for which stale routes are kept in RIB.
937 .. clicmd:: bgp graceful-restart stalepath-time (1-4095)
939 This is command, will set the max time (in seconds) to hold onto
940 restarting peer's stale paths.
942 It also controls Enhanced Route-Refresh timer.
944 If this command is configured and the router does not receive a Route-Refresh EoRR
945 message, the router removes the stale routes from the BGP table after the timer
946 expires. The stale path timer is started when the router receives a Route-Refresh
949 .. _bgp-per-peer-graceful-restart:
951 BGP Per Peer Graceful Restart
952 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
954 Ability to enable and disable graceful restart, helper and no GR at all mode
955 functionality at peer level.
957 So bgp graceful restart can be enabled at modes global BGP level or at per
958 peer level. There are two FSM, one for BGP GR global mode and other for peer
961 Default global mode is helper and default peer per mode is inherit from global.
962 If per peer mode is configured, the GR mode of this particular peer will
963 override the global mode.
965 .. _bgp-GR-global-mode-cmd:
967 BGP GR Global Mode Commands
968 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
970 .. clicmd:: bgp graceful-restart
972 This command will enable BGP graceful restart ifunctionality at the global
975 .. clicmd:: bgp graceful-restart disable
977 This command will disable both the functionality graceful restart and helper
981 .. _bgp-GR-peer-mode-cmd:
983 BGP GR Peer Mode Commands
984 ^^^^^^^^^^^^^^^^^^^^^^^^^
986 .. clicmd:: neighbor A.B.C.D graceful-restart
988 This command will enable BGP graceful restart ifunctionality at the peer
991 .. clicmd:: neighbor A.B.C.D graceful-restart-helper
993 This command will enable BGP graceful restart helper only functionality
996 .. clicmd:: neighbor A.B.C.D graceful-restart-disable
998 This command will disable the entire BGP graceful restart functionality
1004 Administrative Shutdown
1005 -----------------------
1007 .. clicmd:: bgp shutdown [message MSG...]
1009 Administrative shutdown of all peers of a bgp instance. Drop all BGP peers,
1010 but preserve their configurations. The peers are notified in accordance with
1011 `RFC 8203 <https://tools.ietf.org/html/rfc8203/>`_ by sending a
1012 ``NOTIFICATION`` message with error code ``Cease`` and subcode
1013 ``Administrative Shutdown`` prior to terminating connections. This global
1014 shutdown is independent of the neighbor shutdown, meaning that individually
1015 shut down peers will not be affected by lifting it.
1017 An optional shutdown message `MSG` can be specified.
1025 .. clicmd:: network A.B.C.D/M
1027 This command adds the announcement network.
1032 address-family ipv4 unicast
1036 This configuration example says that network 10.0.0.0/8 will be
1037 announced to all neighbors. Some vendors' routers don't advertise
1038 routes if they aren't present in their IGP routing tables; `bgpd`
1039 doesn't care about IGP routes when announcing its routes.
1042 .. clicmd:: bgp network import-check
1044 This configuration modifies the behavior of the network statement.
1045 If you have this configured the underlying network must exist in
1046 the rib. If you have the [no] form configured then BGP will not
1047 check for the networks existence in the rib. For versions 7.3 and
1048 before frr defaults for datacenter were the network must exist,
1049 traditional did not check for existence. For versions 7.4 and beyond
1050 both traditional and datacenter the network must exist.
1052 .. _bgp-ipv6-support:
1057 .. clicmd:: neighbor A.B.C.D activate
1059 This configuration modifies whether to enable an address family for a
1060 specific neighbor. By default only the IPv4 unicast address family is
1066 address-family ipv6 unicast
1067 neighbor 2001:0DB8::1 activate
1068 network 2001:0DB8:5009::/64
1071 This configuration example says that network 2001:0DB8:5009::/64 will be
1072 announced and enables the neighbor 2001:0DB8::1 to receive this announcement.
1074 By default, only the IPv4 unicast address family is announced to all
1075 neighbors. Using the 'no bgp default ipv4-unicast' configuration overrides
1076 this default so that all address families need to be enabled explicitly.
1081 no bgp default ipv4-unicast
1082 neighbor 10.10.10.1 remote-as 2
1083 neighbor 2001:0DB8::1 remote-as 3
1084 address-family ipv4 unicast
1085 neighbor 10.10.10.1 activate
1086 network 192.168.1.0/24
1088 address-family ipv6 unicast
1089 neighbor 2001:0DB8::1 activate
1090 network 2001:0DB8:5009::/64
1093 This configuration demonstrates how the 'no bgp default ipv4-unicast' might
1094 be used in a setup with two upstreams where each of the upstreams should only
1095 receive either IPv4 or IPv6 annocuments.
1097 Using the ``bgp default ipv6-unicast`` configuration, IPv6 unicast
1098 address family is enabled by default for all new neighbors.
1101 .. _bgp-route-aggregation:
1106 .. _bgp-route-aggregation-ipv4:
1108 Route Aggregation-IPv4 Address Family
1109 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1111 .. clicmd:: aggregate-address A.B.C.D/M
1113 This command specifies an aggregate address.
1115 .. clicmd:: aggregate-address A.B.C.D/M route-map NAME
1117 Apply a route-map for an aggregated prefix.
1119 .. clicmd:: aggregate-address A.B.C.D/M origin <egp|igp|incomplete>
1121 Override ORIGIN for an aggregated prefix.
1123 .. clicmd:: aggregate-address A.B.C.D/M as-set
1125 This command specifies an aggregate address. Resulting routes include
1128 .. clicmd:: aggregate-address A.B.C.D/M summary-only
1130 This command specifies an aggregate address. Aggregated routes will
1133 .. clicmd:: aggregate-address A.B.C.D/M matching-MED-only
1135 Configure the aggregated address to only be created when the routes MED
1136 match, otherwise no aggregated route will be created.
1138 .. clicmd:: aggregate-address A.B.C.D/M suppress-map NAME
1140 Similar to `summary-only`, but will only suppress more specific routes that
1141 are matched by the selected route-map.
1144 This configuration example sets up an ``aggregate-address`` under the ipv4
1150 address-family ipv4 unicast
1151 aggregate-address 10.0.0.0/8
1152 aggregate-address 20.0.0.0/8 as-set
1153 aggregate-address 40.0.0.0/8 summary-only
1154 aggregate-address 50.0.0.0/8 route-map aggr-rmap
1158 .. _bgp-route-aggregation-ipv6:
1160 Route Aggregation-IPv6 Address Family
1161 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1163 .. clicmd:: aggregate-address X:X::X:X/M
1165 This command specifies an aggregate address.
1167 .. clicmd:: aggregate-address X:X::X:X/M route-map NAME
1169 Apply a route-map for an aggregated prefix.
1171 .. clicmd:: aggregate-address X:X::X:X/M origin <egp|igp|incomplete>
1173 Override ORIGIN for an aggregated prefix.
1175 .. clicmd:: aggregate-address X:X::X:X/M as-set
1177 This command specifies an aggregate address. Resulting routes include
1180 .. clicmd:: aggregate-address X:X::X:X/M summary-only
1182 This command specifies an aggregate address. Aggregated routes will
1185 .. clicmd:: aggregate-address X:X::X:X/M matching-MED-only
1187 Configure the aggregated address to only be created when the routes MED
1188 match, otherwise no aggregated route will be created.
1190 .. clicmd:: aggregate-address X:X::X:X/M suppress-map NAME
1192 Similar to `summary-only`, but will only suppress more specific routes that
1193 are matched by the selected route-map.
1196 This configuration example sets up an ``aggregate-address`` under the ipv6
1202 address-family ipv6 unicast
1203 aggregate-address 10::0/64
1204 aggregate-address 20::0/64 as-set
1205 aggregate-address 40::0/64 summary-only
1206 aggregate-address 50::0/64 route-map aggr-rmap
1210 .. _bgp-redistribute-to-bgp:
1215 Redistribution configuration should be placed under the ``address-family``
1216 section for the specific AF to redistribute into. Protocol availability for
1217 redistribution is determined by BGP AF; for example, you cannot redistribute
1218 OSPFv3 into ``address-family ipv4 unicast`` as OSPFv3 supports IPv6.
1220 .. clicmd:: redistribute <babel|connected|eigrp|isis|kernel|openfabric|ospf|ospf6|rip|ripng|sharp|static|table> [metric (0-4294967295)] [route-map WORD]
1222 Redistribute routes from other protocols into BGP.
1224 .. clicmd:: redistribute vnc-direct
1226 Redistribute VNC direct (not via zebra) routes to BGP process.
1228 .. clicmd:: bgp update-delay MAX-DELAY
1230 .. clicmd:: bgp update-delay MAX-DELAY ESTABLISH-WAIT
1232 This feature is used to enable read-only mode on BGP process restart or when
1233 a BGP process is cleared using 'clear ip bgp \*'. Note that this command is
1234 configured at the global level and applies to all bgp instances/vrfs. It
1235 cannot be used at the same time as the "update-delay" command described below,
1236 which is entered in each bgp instance/vrf desired to delay update installation
1237 and advertisements. The global and per-vrf approaches to defining update-delay
1238 are mutually exclusive.
1240 When applicable, read-only mode would begin as soon as the first peer reaches
1241 Established status and a timer for max-delay seconds is started. During this
1242 mode BGP doesn't run any best-path or generate any updates to its peers. This
1243 mode continues until:
1245 1. All the configured peers, except the shutdown peers, have sent explicit EOR
1246 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
1247 Established is considered an implicit-EOR.
1248 If the establish-wait optional value is given, then BGP will wait for
1249 peers to reach established from the beginning of the update-delay till the
1250 establish-wait period is over, i.e. the minimum set of established peers for
1251 which EOR is expected would be peers established during the establish-wait
1252 window, not necessarily all the configured neighbors.
1253 2. max-delay period is over.
1255 On hitting any of the above two conditions, BGP resumes the decision process
1256 and generates updates to its peers.
1258 Default max-delay is 0, i.e. the feature is off by default.
1261 .. clicmd:: update-delay MAX-DELAY
1263 .. clicmd:: update-delay MAX-DELAY ESTABLISH-WAIT
1265 This feature is used to enable read-only mode on BGP process restart or when
1266 a BGP process is cleared using 'clear ip bgp \*'. Note that this command is
1267 configured under the specific bgp instance/vrf that the feaure is enabled for.
1268 It cannot be used at the same time as the global "bgp update-delay" described
1269 above, which is entered at the global level and applies to all bgp instances.
1270 The global and per-vrf approaches to defining update-delay are mutually
1273 When applicable, read-only mode would begin as soon as the first peer reaches
1274 Established status and a timer for max-delay seconds is started. During this
1275 mode BGP doesn't run any best-path or generate any updates to its peers. This
1276 mode continues until:
1278 1. All the configured peers, except the shutdown peers, have sent explicit EOR
1279 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
1280 Established is considered an implicit-EOR.
1281 If the establish-wait optional value is given, then BGP will wait for
1282 peers to reach established from the beginning of the update-delay till the
1283 establish-wait period is over, i.e. the minimum set of established peers for
1284 which EOR is expected would be peers established during the establish-wait
1285 window, not necessarily all the configured neighbors.
1286 2. max-delay period is over.
1288 On hitting any of the above two conditions, BGP resumes the decision process
1289 and generates updates to its peers.
1291 Default max-delay is 0, i.e. the feature is off by default.
1293 .. clicmd:: table-map ROUTE-MAP-NAME
1295 This feature is used to apply a route-map on route updates from BGP to
1296 Zebra. All the applicable match operations are allowed, such as match on
1297 prefix, next-hop, communities, etc. Set operations for this attach-point are
1298 limited to metric and next-hop only. Any operation of this feature does not
1299 affect BGPs internal RIB.
1301 Supported for ipv4 and ipv6 address families. It works on multi-paths as
1302 well, however, metric setting is based on the best-path only.
1309 .. _bgp-defining-peers:
1314 .. clicmd:: neighbor PEER remote-as ASN
1316 Creates a new neighbor whose remote-as is ASN. PEER can be an IPv4 address
1317 or an IPv6 address or an interface to use for the connection.
1322 neighbor 10.0.0.1 remote-as 2
1324 In this case my router, in AS-1, is trying to peer with AS-2 at 10.0.0.1.
1326 This command must be the first command used when configuring a neighbor. If
1327 the remote-as is not specified, *bgpd* will complain like this: ::
1329 can't find neighbor 10.0.0.1
1331 .. clicmd:: neighbor PEER remote-as internal
1333 Create a peer as you would when you specify an ASN, except that if the
1334 peers ASN is different than mine as specified under the :clicmd:`router bgp ASN`
1335 command the connection will be denied.
1337 .. clicmd:: neighbor PEER remote-as external
1339 Create a peer as you would when you specify an ASN, except that if the
1340 peers ASN is the same as mine as specified under the :clicmd:`router bgp ASN`
1341 command the connection will be denied.
1343 .. clicmd:: bgp listen range <A.B.C.D/M|X:X::X:X/M> peer-group PGNAME
1345 Accept connections from any peers in the specified prefix. Configuration
1346 from the specified peer-group is used to configure these peers.
1350 When using BGP listen ranges, if the associated peer group has TCP MD5
1351 authentication configured, your kernel must support this on prefixes. On
1352 Linux, this support was added in kernel version 4.14. If your kernel does
1353 not support this feature you will get a warning in the log file, and the
1354 listen range will only accept connections from peers without MD5 configured.
1356 Additionally, we have observed that when using this option at scale (several
1357 hundred peers) the kernel may hit its option memory limit. In this situation
1358 you will see error messages like:
1360 ``bgpd: sockopt_tcp_signature: setsockopt(23): Cannot allocate memory``
1362 In this case you need to increase the value of the sysctl
1363 ``net.core.optmem_max`` to allow the kernel to allocate the necessary option
1366 .. clicmd:: bgp listen limit <1-65535>
1368 Define the maximum number of peers accepted for one BGP instance. This
1369 limit is set to 100 by default. Increasing this value will really be
1370 possible if more file descriptors are available in the BGP process. This
1371 value is defined by the underlying system (ulimit value), and can be
1372 overriden by `--limit-fds`. More information is available in chapter
1373 (:ref:`common-invocation-options`).
1375 .. clicmd:: coalesce-time (0-4294967295)
1377 The time in milliseconds that BGP will delay before deciding what peers
1378 can be put into an update-group together in order to generate a single
1379 update for them. The default time is 1000.
1381 .. _bgp-configuring-peers:
1386 .. clicmd:: neighbor PEER shutdown [message MSG...] [rtt (1-65535) [count (1-255)]]
1388 Shutdown the peer. We can delete the neighbor's configuration by
1389 ``no neighbor PEER remote-as ASN`` but all configuration of the neighbor
1390 will be deleted. When you want to preserve the configuration, but want to
1391 drop the BGP peer, use this syntax.
1393 Optionally you can specify a shutdown message `MSG`.
1395 Also, you can specify optionally ``rtt`` in milliseconds to automatically
1396 shutdown the peer if round-trip-time becomes higher than defined.
1398 Additional ``count`` parameter is the number of keepalive messages to count
1399 before shutdown the peer if round-trip-time becomes higher than defined.
1401 .. clicmd:: neighbor PEER disable-connected-check
1403 Allow peerings between directly connected eBGP peers using loopback
1406 .. clicmd:: neighbor PEER ebgp-multihop
1408 Specifying ``ebgp-multihop`` allows sessions with eBGP neighbors to
1409 establish when they are multiple hops away. When the neighbor is not
1410 directly connected and this knob is not enabled, the session will not
1413 If the peer's IP address is not in the RIB and is reachable via the
1414 default route, then you have to enable ``ip nht resolve-via-default``.
1416 .. clicmd:: neighbor PEER description ...
1418 Set description of the peer.
1420 .. clicmd:: neighbor PEER version VERSION
1422 Set up the neighbor's BGP version. `version` can be `4`, `4+` or `4-`. BGP
1423 version `4` is the default value used for BGP peering. BGP version `4+`
1424 means that the neighbor supports Multiprotocol Extensions for BGP-4. BGP
1425 version `4-` is similar but the neighbor speaks the old Internet-Draft
1426 revision 00's Multiprotocol Extensions for BGP-4. Some routing software is
1427 still using this version.
1429 .. clicmd:: neighbor PEER interface IFNAME
1431 When you connect to a BGP peer over an IPv6 link-local address, you have to
1432 specify the IFNAME of the interface used for the connection. To specify
1433 IPv4 session addresses, see the ``neighbor PEER update-source`` command
1436 This command is deprecated and may be removed in a future release. Its use
1439 .. clicmd:: neighbor PEER interface remote-as <internal|external|ASN>
1441 Configure an unnumbered BGP peer. ``PEER`` should be an interface name. The
1442 session will be established via IPv6 link locals. Use ``internal`` for iBGP
1443 and ``external`` for eBGP sessions, or specify an ASN if you wish.
1445 .. clicmd:: neighbor PEER next-hop-self [all]
1447 This command specifies an announced route's nexthop as being equivalent to
1448 the address of the bgp router if it is learned via eBGP. If the optional
1449 keyword `all` is specified the modification is done also for routes learned
1452 .. clicmd:: neighbor PEER attribute-unchanged [{as-path|next-hop|med}]
1454 This command specifies attributes to be left unchanged for advertisements
1455 sent to a peer. Use this to leave the next-hop unchanged in ipv6
1456 configurations, as the route-map directive to leave the next-hop unchanged
1457 is only available for ipv4.
1459 .. clicmd:: neighbor PEER update-source <IFNAME|ADDRESS>
1461 Specify the IPv4 source address to use for the :abbr:`BGP` session to this
1462 neighbour, may be specified as either an IPv4 address directly or as an
1463 interface name (in which case the *zebra* daemon MUST be running in order
1464 for *bgpd* to be able to retrieve interface state).
1469 neighbor foo update-source 192.168.0.1
1470 neighbor bar update-source lo0
1473 .. clicmd:: neighbor PEER default-originate
1475 *bgpd*'s default is to not announce the default route (0.0.0.0/0) even if it
1476 is in routing table. When you want to announce default routes to the peer,
1479 .. clicmd:: neighbor PEER port PORT
1481 .. clicmd:: neighbor PEER password PASSWORD
1483 Set a MD5 password to be used with the tcp socket that is being used
1484 to connect to the remote peer. Please note if you are using this
1485 command with a large number of peers on linux you should consider
1486 modifying the `net.core.optmem_max` sysctl to a larger value to
1487 avoid out of memory errors from the linux kernel.
1489 .. clicmd:: neighbor PEER send-community
1491 .. clicmd:: neighbor PEER weight WEIGHT
1493 This command specifies a default `weight` value for the neighbor's routes.
1495 .. clicmd:: neighbor PEER maximum-prefix NUMBER [force]
1497 Sets a maximum number of prefixes we can receive from a given peer. If this
1498 number is exceeded, the BGP session will be destroyed.
1500 In practice, it is generally preferable to use a prefix-list to limit what
1501 prefixes are received from the peer instead of using this knob. Tearing down
1502 the BGP session when a limit is exceeded is far more destructive than merely
1503 rejecting undesired prefixes. The prefix-list method is also much more
1504 granular and offers much smarter matching criterion than number of received
1505 prefixes, making it more suited to implementing policy.
1507 If ``force`` is set, then ALL prefixes are counted for maximum instead of
1508 accepted only. This is useful for cases where an inbound filter is applied,
1509 but you want maximum-prefix to act on ALL (including filtered) prefixes. This
1510 option requires `soft-reconfiguration inbound` to be enabled for the peer.
1512 .. clicmd:: neighbor PEER maximum-prefix-out NUMBER
1514 Sets a maximum number of prefixes we can send to a given peer.
1516 Since sent prefix count is managed by update-groups, this option
1517 creates a separate update-group for outgoing updates.
1519 .. clicmd:: neighbor PEER local-as AS-NUMBER [no-prepend] [replace-as]
1521 Specify an alternate AS for this BGP process when interacting with the
1522 specified peer. With no modifiers, the specified local-as is prepended to
1523 the received AS_PATH when receiving routing updates from the peer, and
1524 prepended to the outgoing AS_PATH (after the process local AS) when
1525 transmitting local routes to the peer.
1527 If the no-prepend attribute is specified, then the supplied local-as is not
1528 prepended to the received AS_PATH.
1530 If the replace-as attribute is specified, then only the supplied local-as is
1531 prepended to the AS_PATH when transmitting local-route updates to this peer.
1533 Note that replace-as can only be specified if no-prepend is.
1535 This command is only allowed for eBGP peers.
1537 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> as-override
1539 Override AS number of the originating router with the local AS number.
1541 Usually this configuration is used in PEs (Provider Edge) to replace
1542 the incoming customer AS number so the connected CE (Customer Edge)
1543 can use the same AS number as the other customer sites. This allows
1544 customers of the provider network to use the same AS number across
1547 This command is only allowed for eBGP peers.
1549 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> allowas-in [<(1-10)|origin>]
1551 Accept incoming routes with AS path containing AS number with the same value
1552 as the current system AS.
1554 This is used when you want to use the same AS number in your sites, but you
1555 can't connect them directly. This is an alternative to
1556 `neighbor WORD as-override`.
1558 The parameter `(1-10)` configures the amount of accepted occurences of the
1559 system AS number in AS path.
1561 The parameter `origin` configures BGP to only accept routes originated with
1562 the same AS number as the system.
1564 This command is only allowed for eBGP peers.
1566 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> addpath-tx-all-paths
1568 Configure BGP to send all known paths to neighbor in order to preserve multi
1569 path capabilities inside a network.
1571 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> addpath-tx-bestpath-per-AS
1573 Configure BGP to send best known paths to neighbor in order to preserve multi
1574 path capabilities inside a network.
1576 .. clicmd:: neighbor PEER ttl-security hops NUMBER
1578 This command enforces Generalized TTL Security Mechanism (GTSM), as
1579 specified in RFC 5082. With this command, only neighbors that are the
1580 specified number of hops away will be allowed to become neighbors. This
1581 command is mutually exclusive with *ebgp-multihop*.
1583 .. clicmd:: neighbor PEER capability extended-nexthop
1585 Allow bgp to negotiate the extended-nexthop capability with it's peer.
1586 If you are peering over a v6 LL address then this capability is turned
1587 on automatically. If you are peering over a v6 Global Address then
1588 turning on this command will allow BGP to install v4 routes with
1589 v6 nexthops if you do not have v4 configured on interfaces.
1591 .. clicmd:: bgp fast-external-failover
1593 This command causes bgp to not take down ebgp peers immediately
1594 when a link flaps. `bgp fast-external-failover` is the default
1595 and will not be displayed as part of a `show run`. The no form
1596 of the command turns off this ability.
1598 .. clicmd:: bgp default ipv4-unicast
1600 This command allows the user to specify that v4 peering is turned
1601 on by default or not. This command defaults to on and is not displayed.
1602 The `no bgp default ipv4-unicast` form of the command is displayed.
1604 .. clicmd:: bgp default ipv6-unicast
1606 This command allows the user to specify that v6 peering is turned
1607 on by default or not. This command defaults to off and is not displayed.
1608 The `bgp default ipv6-unicast` form of the command is displayed.
1610 .. clicmd:: bgp default show-hostname
1612 This command shows the hostname of the peer in certain BGP commands
1613 outputs. It's easier to troubleshoot if you have a number of BGP peers.
1615 .. clicmd:: bgp default show-nexthop-hostname
1617 This command shows the hostname of the next-hop in certain BGP commands
1618 outputs. It's easier to troubleshoot if you have a number of BGP peers
1619 and a number of routes to check.
1621 .. clicmd:: neighbor PEER advertisement-interval (0-600)
1623 Setup the minimum route advertisement interval(mrai) for the
1624 peer in question. This number is between 0 and 600 seconds,
1625 with the default advertisement interval being 0.
1627 .. clicmd:: neighbor PEER timers (0-65535) (0-65535)
1629 Set keepalive and hold timers for a neighbor. The first value is keepalive
1630 and the second is hold time.
1632 .. clicmd:: neighbor PEER connect (1-65535)
1634 Set connect timer for a neighbor. The connect timer controls how long BGP
1635 waits between connection attempts to a neighbor.
1637 .. clicmd:: neighbor PEER timers delayopen (1-240)
1639 This command allows the user enable the
1640 `RFC 4271 <https://tools.ietf.org/html/rfc4271/>` DelayOpenTimer with the
1641 specified interval or disable it with the negating command for the peer. By
1642 default, the DelayOpenTimer is disabled. The timer interval may be set to a
1643 duration of 1 to 240 seconds.
1645 Displaying Information about Peers
1646 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1648 .. clicmd:: show bgp <afi> <safi> neighbors WORD bestpath-routes [json] [wide]
1650 For the given neighbor, WORD, that is specified list the routes selected
1651 by BGP as having the best path.
1653 .. _bgp-peer-filtering:
1658 .. clicmd:: neighbor PEER distribute-list NAME [in|out]
1660 This command specifies a distribute-list for the peer. `direct` is
1663 .. clicmd:: neighbor PEER prefix-list NAME [in|out]
1665 .. clicmd:: neighbor PEER filter-list NAME [in|out]
1667 .. clicmd:: neighbor PEER route-map NAME [in|out]
1669 Apply a route-map on the neighbor. `direct` must be `in` or `out`.
1671 .. clicmd:: bgp route-reflector allow-outbound-policy
1673 By default, attribute modification via route-map policy out is not reflected
1674 on reflected routes. This option allows the modifications to be reflected as
1675 well. Once enabled, it affects all reflected routes.
1677 .. clicmd:: neighbor PEER sender-as-path-loop-detection
1679 Enable the detection of sender side AS path loops and filter the
1680 bad routes before they are sent.
1682 This setting is disabled by default.
1689 Peer groups are used to help improve scaling by generating the same
1690 update information to all members of a peer group. Note that this means
1691 that the routes generated by a member of a peer group will be sent back
1692 to that originating peer with the originator identifier attribute set to
1693 indicated the originating peer. All peers not associated with a
1694 specific peer group are treated as belonging to a default peer group,
1695 and will share updates.
1697 .. clicmd:: neighbor WORD peer-group
1699 This command defines a new peer group.
1701 .. clicmd:: neighbor PEER peer-group PGNAME
1703 This command bind specific peer to peer group WORD.
1705 .. clicmd:: neighbor PEER solo
1707 This command is used to indicate that routes advertised by the peer
1708 should not be reflected back to the peer. This command only is only
1709 meaningful when there is a single peer defined in the peer-group.
1711 .. clicmd:: show [ip] bgp peer-group [json]
1713 This command displays configured BGP peer-groups.
1717 exit1-debian-9# show bgp peer-group
1719 BGP peer-group test1, remote AS 65001
1720 Peer-group type is external
1721 Configured address-families: IPv4 Unicast; IPv6 Unicast;
1722 1 IPv4 listen range(s)
1724 2 IPv6 listen range(s)
1728 192.168.200.1 Active
1731 BGP peer-group test2
1732 Peer-group type is external
1733 Configured address-families: IPv4 Unicast;
1735 Optional ``json`` parameter is used to display JSON output.
1743 "addressFamiliesConfigured":[
1773 "addressFamiliesConfigured":[
1779 Capability Negotiation
1780 ^^^^^^^^^^^^^^^^^^^^^^
1782 .. clicmd:: neighbor PEER strict-capability-match
1785 Strictly compares remote capabilities and local capabilities. If
1786 capabilities are different, send Unsupported Capability error then reset
1789 You may want to disable sending Capability Negotiation OPEN message optional
1790 parameter to the peer when remote peer does not implement Capability
1791 Negotiation. Please use *dont-capability-negotiate* command to disable the
1794 .. clicmd:: neighbor PEER dont-capability-negotiate
1796 Suppress sending Capability Negotiation as OPEN message optional parameter
1797 to the peer. This command only affects the peer is configured other than
1798 IPv4 unicast configuration.
1800 When remote peer does not have capability negotiation feature, remote peer
1801 will not send any capabilities at all. In that case, bgp configures the peer
1802 with configured capabilities.
1804 You may prefer locally configured capabilities more than the negotiated
1805 capabilities even though remote peer sends capabilities. If the peer is
1806 configured by *override-capability*, *bgpd* ignores received capabilities
1807 then override negotiated capabilities with configured values.
1809 Additionally the operator should be reminded that this feature fundamentally
1810 disables the ability to use widely deployed BGP features. BGP unnumbered,
1811 hostname support, AS4, Addpath, Route Refresh, ORF, Dynamic Capabilities,
1812 and graceful restart.
1814 .. clicmd:: neighbor PEER override-capability
1817 Override the result of Capability Negotiation with local configuration.
1818 Ignore remote peer's capability value.
1820 .. _bgp-as-path-access-lists:
1822 AS Path Access Lists
1823 --------------------
1825 AS path access list is user defined AS path.
1827 .. clicmd:: bgp as-path access-list WORD [seq (0-4294967295)] permit|deny LINE
1829 This command defines a new AS path access list.
1833 .. _bgp-bogon-filter-example:
1835 Bogon ASN filter policy configuration example
1836 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1840 bgp as-path access-list 99 permit _0_
1841 bgp as-path access-list 99 permit _23456_
1842 bgp as-path access-list 99 permit _1310[0-6][0-9]_|_13107[0-1]_
1843 bgp as-path access-list 99 seq 20 permit ^65
1845 .. _bgp-using-as-path-in-route-map:
1847 Using AS Path in Route Map
1848 --------------------------
1850 .. clicmd:: match as-path WORD
1852 For a given as-path, WORD, match it on the BGP as-path given for the prefix
1853 and if it matches do normal route-map actions. The no form of the command
1854 removes this match from the route-map.
1856 .. clicmd:: set as-path prepend AS-PATH
1858 Prepend the given string of AS numbers to the AS_PATH of the BGP path's NLRI.
1859 The no form of this command removes this set operation from the route-map.
1861 .. clicmd:: set as-path prepend last-as NUM
1863 Prepend the existing last AS number (the leftmost ASN) to the AS_PATH.
1864 The no form of this command removes this set operation from the route-map.
1866 .. _bgp-communities-attribute:
1868 Communities Attribute
1869 ---------------------
1871 The BGP communities attribute is widely used for implementing policy routing.
1872 Network operators can manipulate BGP communities attribute based on their
1873 network policy. BGP communities attribute is defined in :rfc:`1997` and
1874 :rfc:`1998`. It is an optional transitive attribute, therefore local policy can
1875 travel through different autonomous system.
1877 The communities attribute is a set of communities values. Each community value
1878 is 4 octet long. The following format is used to define the community value.
1881 This format represents 4 octet communities value. ``AS`` is high order 2
1882 octet in digit format. ``VAL`` is low order 2 octet in digit format. This
1883 format is useful to define AS oriented policy value. For example,
1884 ``7675:80`` can be used when AS 7675 wants to pass local policy value 80 to
1888 ``internet`` represents well-known communities value 0.
1890 ``graceful-shutdown``
1891 ``graceful-shutdown`` represents well-known communities value
1892 ``GRACEFUL_SHUTDOWN`` ``0xFFFF0000`` ``65535:0``. :rfc:`8326` implements
1893 the purpose Graceful BGP Session Shutdown to reduce the amount of
1894 lost traffic when taking BGP sessions down for maintenance. The use
1895 of the community needs to be supported from your peers side to
1896 actually have any effect.
1899 ``accept-own`` represents well-known communities value ``ACCEPT_OWN``
1900 ``0xFFFF0001`` ``65535:1``. :rfc:`7611` implements a way to signal
1901 to a router to accept routes with a local nexthop address. This
1902 can be the case when doing policing and having traffic having a
1903 nexthop located in another VRF but still local interface to the
1904 router. It is recommended to read the RFC for full details.
1906 ``route-filter-translated-v4``
1907 ``route-filter-translated-v4`` represents well-known communities value
1908 ``ROUTE_FILTER_TRANSLATED_v4`` ``0xFFFF0002`` ``65535:2``.
1911 ``route-filter-v4`` represents well-known communities value
1912 ``ROUTE_FILTER_v4`` ``0xFFFF0003`` ``65535:3``.
1914 ``route-filter-translated-v6``
1915 ``route-filter-translated-v6`` represents well-known communities value
1916 ``ROUTE_FILTER_TRANSLATED_v6`` ``0xFFFF0004`` ``65535:4``.
1919 ``route-filter-v6`` represents well-known communities value
1920 ``ROUTE_FILTER_v6`` ``0xFFFF0005`` ``65535:5``.
1923 ``llgr-stale`` represents well-known communities value ``LLGR_STALE``
1924 ``0xFFFF0006`` ``65535:6``.
1925 Assigned and intended only for use with routers supporting the
1926 Long-lived Graceful Restart Capability as described in
1927 [Draft-IETF-uttaro-idr-bgp-persistence]_.
1928 Routers receiving routes with this community may (depending on
1929 implementation) choose allow to reject or modify routes on the
1930 presence or absence of this community.
1933 ``no-llgr`` represents well-known communities value ``NO_LLGR``
1934 ``0xFFFF0007`` ``65535:7``.
1935 Assigned and intended only for use with routers supporting the
1936 Long-lived Graceful Restart Capability as described in
1937 [Draft-IETF-uttaro-idr-bgp-persistence]_.
1938 Routers receiving routes with this community may (depending on
1939 implementation) choose allow to reject or modify routes on the
1940 presence or absence of this community.
1942 ``accept-own-nexthop``
1943 ``accept-own-nexthop`` represents well-known communities value
1944 ``accept-own-nexthop`` ``0xFFFF0008`` ``65535:8``.
1945 [Draft-IETF-agrewal-idr-accept-own-nexthop]_ describes
1946 how to tag and label VPN routes to be able to send traffic between VRFs
1947 via an internal layer 2 domain on the same PE device. Refer to
1948 [Draft-IETF-agrewal-idr-accept-own-nexthop]_ for full details.
1951 ``blackhole`` represents well-known communities value ``BLACKHOLE``
1952 ``0xFFFF029A`` ``65535:666``. :rfc:`7999` documents sending prefixes to
1953 EBGP peers and upstream for the purpose of blackholing traffic.
1954 Prefixes tagged with the this community should normally not be
1955 re-advertised from neighbors of the originating network. Upon receiving
1956 ``BLACKHOLE`` community from a BGP speaker, ``NO_ADVERTISE`` community
1957 is added automatically.
1960 ``no-export`` represents well-known communities value ``NO_EXPORT``
1961 ``0xFFFFFF01``. All routes carry this value must not be advertised to
1962 outside a BGP confederation boundary. If neighboring BGP peer is part of BGP
1963 confederation, the peer is considered as inside a BGP confederation
1964 boundary, so the route will be announced to the peer.
1967 ``no-advertise`` represents well-known communities value ``NO_ADVERTISE``
1968 ``0xFFFFFF02``. All routes carry this value must not be advertise to other
1972 ``local-AS`` represents well-known communities value ``NO_EXPORT_SUBCONFED``
1973 ``0xFFFFFF03``. All routes carry this value must not be advertised to
1974 external BGP peers. Even if the neighboring router is part of confederation,
1975 it is considered as external BGP peer, so the route will not be announced to
1979 ``no-peer`` represents well-known communities value ``NOPEER``
1980 ``0xFFFFFF04`` ``65535:65284``. :rfc:`3765` is used to communicate to
1981 another network how the originating network want the prefix propagated.
1983 When the communities attribute is received duplicate community values in the
1984 attribute are ignored and value is sorted in numerical order.
1986 .. [Draft-IETF-uttaro-idr-bgp-persistence] <https://tools.ietf.org/id/draft-uttaro-idr-bgp-persistence-04.txt>
1987 .. [Draft-IETF-agrewal-idr-accept-own-nexthop] <https://tools.ietf.org/id/draft-agrewal-idr-accept-own-nexthop-00.txt>
1989 .. _bgp-community-lists:
1993 Community lists are user defined lists of community attribute values. These
1994 lists can be used for matching or manipulating the communities attribute in
1997 There are two types of community list:
2000 This type accepts an explicit value for the attribute.
2003 This type accepts a regular expression. Because the regex must be
2004 interpreted on each use expanded community lists are slower than standard
2007 .. clicmd:: bgp community-list standard NAME permit|deny COMMUNITY
2009 This command defines a new standard community list. ``COMMUNITY`` is
2010 communities value. The ``COMMUNITY`` is compiled into community structure.
2011 We can define multiple community list under same name. In that case match
2012 will happen user defined order. Once the community list matches to
2013 communities attribute in BGP updates it return permit or deny by the
2014 community list definition. When there is no matched entry, deny will be
2015 returned. When ``COMMUNITY`` is empty it matches to any routes.
2017 .. clicmd:: bgp community-list expanded NAME permit|deny COMMUNITY
2019 This command defines a new expanded community list. ``COMMUNITY`` is a
2020 string expression of communities attribute. ``COMMUNITY`` can be a regular
2021 expression (:ref:`bgp-regular-expressions`) to match the communities
2022 attribute in BGP updates. The expanded community is only used to filter,
2026 It is recommended to use the more explicit versions of this command.
2028 .. clicmd:: bgp community-list NAME permit|deny COMMUNITY
2030 When the community list type is not specified, the community list type is
2031 automatically detected. If ``COMMUNITY`` can be compiled into communities
2032 attribute, the community list is defined as a standard community list.
2033 Otherwise it is defined as an expanded community list. This feature is left
2034 for backward compatibility. Use of this feature is not recommended.
2036 Note that all community lists share the same namespace, so it's not
2037 necessary to specify ``standard`` or ``expanded``; these modifiers are
2040 .. clicmd:: show bgp community-list [NAME detail]
2042 Displays community list information. When ``NAME`` is specified the
2043 specified community list's information is shown.
2047 # show bgp community-list
2048 Named Community standard list CLIST
2049 permit 7675:80 7675:100 no-export
2051 Named Community expanded list EXPAND
2054 # show bgp community-list CLIST detail
2055 Named Community standard list CLIST
2056 permit 7675:80 7675:100 no-export
2060 .. _bgp-numbered-community-lists:
2062 Numbered Community Lists
2063 ^^^^^^^^^^^^^^^^^^^^^^^^
2065 When number is used for BGP community list name, the number has
2066 special meanings. Community list number in the range from 1 and 99 is
2067 standard community list. Community list number in the range from 100
2068 to 199 is expanded community list. These community lists are called
2069 as numbered community lists. On the other hand normal community lists
2070 is called as named community lists.
2072 .. clicmd:: bgp community-list (1-99) permit|deny COMMUNITY
2074 This command defines a new community list. The argument to (1-99) defines
2075 the list identifier.
2077 .. clicmd:: bgp community-list (100-199) permit|deny COMMUNITY
2079 This command defines a new expanded community list. The argument to
2080 (100-199) defines the list identifier.
2082 .. _bgp-using-communities-in-route-map:
2084 Using Communities in Route Maps
2085 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2087 In :ref:`route-map` we can match on or set the BGP communities attribute. Using
2088 this feature network operator can implement their network policy based on BGP
2089 communities attribute.
2091 The following commands can be used in route maps:
2093 .. clicmd:: match community WORD exact-match [exact-match]
2095 This command perform match to BGP updates using community list WORD. When
2096 the one of BGP communities value match to the one of communities value in
2097 community list, it is match. When `exact-match` keyword is specified, match
2098 happen only when BGP updates have completely same communities value
2099 specified in the community list.
2101 .. clicmd:: set community <none|COMMUNITY> additive
2103 This command sets the community value in BGP updates. If the attribute is
2104 already configured, the newly provided value replaces the old one unless the
2105 ``additive`` keyword is specified, in which case the new value is appended
2106 to the existing value.
2108 If ``none`` is specified as the community value, the communities attribute
2111 It is not possible to set an expanded community list.
2113 .. clicmd:: set comm-list WORD delete
2115 This command remove communities value from BGP communities attribute. The
2116 ``word`` is community list name. When BGP route's communities value matches
2117 to the community list ``word``, the communities value is removed. When all
2118 of communities value is removed eventually, the BGP update's communities
2119 attribute is completely removed.
2121 .. _bgp-communities-example:
2123 Example Configuration
2124 ^^^^^^^^^^^^^^^^^^^^^
2126 The following configuration is exemplary of the most typical usage of BGP
2127 communities attribute. In the example, AS 7675 provides an upstream Internet
2128 connection to AS 100. When the following configuration exists in AS 7675, the
2129 network operator of AS 100 can set local preference in AS 7675 network by
2130 setting BGP communities attribute to the updates.
2135 neighbor 192.168.0.1 remote-as 100
2136 address-family ipv4 unicast
2137 neighbor 192.168.0.1 route-map RMAP in
2140 bgp community-list 70 permit 7675:70
2141 bgp community-list 70 deny
2142 bgp community-list 80 permit 7675:80
2143 bgp community-list 80 deny
2144 bgp community-list 90 permit 7675:90
2145 bgp community-list 90 deny
2147 route-map RMAP permit 10
2149 set local-preference 70
2151 route-map RMAP permit 20
2153 set local-preference 80
2155 route-map RMAP permit 30
2157 set local-preference 90
2160 The following configuration announces ``10.0.0.0/8`` from AS 100 to AS 7675.
2161 The route has communities value ``7675:80`` so when above configuration exists
2162 in AS 7675, the announced routes' local preference value will be set to 80.
2168 neighbor 192.168.0.2 remote-as 7675
2169 address-family ipv4 unicast
2170 neighbor 192.168.0.2 route-map RMAP out
2173 ip prefix-list PLIST permit 10.0.0.0/8
2175 route-map RMAP permit 10
2176 match ip address prefix-list PLIST
2177 set community 7675:80
2180 The following configuration is an example of BGP route filtering using
2181 communities attribute. This configuration only permit BGP routes which has BGP
2182 communities value ``0:80`` or ``0:90``. The network operator can set special
2183 internal communities value at BGP border router, then limit the BGP route
2184 announcements into the internal network.
2189 neighbor 192.168.0.1 remote-as 100
2190 address-family ipv4 unicast
2191 neighbor 192.168.0.1 route-map RMAP in
2194 bgp community-list 1 permit 0:80 0:90
2196 route-map RMAP permit in
2200 The following example filters BGP routes which have a community value of
2201 ``1:1``. When there is no match community-list returns ``deny``. To avoid
2202 filtering all routes, a ``permit`` line is set at the end of the
2208 neighbor 192.168.0.1 remote-as 100
2209 address-family ipv4 unicast
2210 neighbor 192.168.0.1 route-map RMAP in
2213 bgp community-list standard FILTER deny 1:1
2214 bgp community-list standard FILTER permit
2216 route-map RMAP permit 10
2217 match community FILTER
2220 The communities value keyword ``internet`` has special meanings in standard
2221 community lists. In the below example ``internet`` matches all BGP routes even
2222 if the route does not have communities attribute at all. So community list
2223 ``INTERNET`` is the same as ``FILTER`` in the previous example.
2227 bgp community-list standard INTERNET deny 1:1
2228 bgp community-list standard INTERNET permit internet
2231 The following configuration is an example of communities value deletion. With
2232 this configuration the community values ``100:1`` and ``100:2`` are removed
2233 from BGP updates. For communities value deletion, only ``permit``
2234 community-list is used. ``deny`` community-list is ignored.
2239 neighbor 192.168.0.1 remote-as 100
2240 address-family ipv4 unicast
2241 neighbor 192.168.0.1 route-map RMAP in
2244 bgp community-list standard DEL permit 100:1 100:2
2246 route-map RMAP permit 10
2247 set comm-list DEL delete
2250 .. _bgp-extended-communities-attribute:
2252 Extended Communities Attribute
2253 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2255 BGP extended communities attribute is introduced with MPLS VPN/BGP technology.
2256 MPLS VPN/BGP expands capability of network infrastructure to provide VPN
2257 functionality. At the same time it requires a new framework for policy routing.
2258 With BGP Extended Communities Attribute we can use Route Target or Site of
2259 Origin for implementing network policy for MPLS VPN/BGP.
2261 BGP Extended Communities Attribute is similar to BGP Communities Attribute. It
2262 is an optional transitive attribute. BGP Extended Communities Attribute can
2263 carry multiple Extended Community value. Each Extended Community value is
2266 BGP Extended Communities Attribute provides an extended range compared with BGP
2267 Communities Attribute. Adding to that there is a type field in each value to
2268 provides community space structure.
2270 There are two format to define Extended Community value. One is AS based format
2271 the other is IP address based format.
2274 This is a format to define AS based Extended Community value. ``AS`` part
2275 is 2 octets Global Administrator subfield in Extended Community value.
2276 ``VAL`` part is 4 octets Local Administrator subfield. ``7675:100``
2277 represents AS 7675 policy value 100.
2280 This is a format to define IP address based Extended Community value.
2281 ``IP-Address`` part is 4 octets Global Administrator subfield. ``VAL`` part
2282 is 2 octets Local Administrator subfield.
2284 .. _bgp-extended-community-lists:
2286 Extended Community Lists
2287 ^^^^^^^^^^^^^^^^^^^^^^^^
2289 .. clicmd:: bgp extcommunity-list standard NAME permit|deny EXTCOMMUNITY
2291 This command defines a new standard extcommunity-list. `extcommunity` is
2292 extended communities value. The `extcommunity` is compiled into extended
2293 community structure. We can define multiple extcommunity-list under same
2294 name. In that case match will happen user defined order. Once the
2295 extcommunity-list matches to extended communities attribute in BGP updates
2296 it return permit or deny based upon the extcommunity-list definition. When
2297 there is no matched entry, deny will be returned. When `extcommunity` is
2298 empty it matches to any routes.
2300 .. clicmd:: bgp extcommunity-list expanded NAME permit|deny LINE
2302 This command defines a new expanded extcommunity-list. `line` is a string
2303 expression of extended communities attribute. `line` can be a regular
2304 expression (:ref:`bgp-regular-expressions`) to match an extended communities
2305 attribute in BGP updates.
2307 Note that all extended community lists shares a single name space, so it's
2308 not necessary to specify their type when creating or destroying them.
2310 .. clicmd:: show bgp extcommunity-list [NAME detail]
2312 This command displays current extcommunity-list information. When `name` is
2313 specified the community list's information is shown.
2316 .. _bgp-extended-communities-in-route-map:
2318 BGP Extended Communities in Route Map
2319 """""""""""""""""""""""""""""""""""""
2321 .. clicmd:: match extcommunity WORD
2323 .. clicmd:: set extcommunity rt EXTCOMMUNITY
2325 This command set Route Target value.
2327 .. clicmd:: set extcommunity soo EXTCOMMUNITY
2329 This command set Site of Origin value.
2331 .. clicmd:: set extcommunity bandwidth <(1-25600) | cumulative | num-multipaths> [non-transitive]
2333 This command sets the BGP link-bandwidth extended community for the prefix
2334 (best path) for which it is applied. The link-bandwidth can be specified as
2335 an ``explicit value`` (specified in Mbps), or the router can be told to use
2336 the ``cumulative bandwidth`` of all multipaths for the prefix or to compute
2337 it based on the ``number of multipaths``. The link bandwidth extended
2338 community is encoded as ``transitive`` unless the set command explicitly
2339 configures it as ``non-transitive``.
2341 .. seealso:: :ref:`wecmp_linkbw`
2343 Note that the extended expanded community is only used for `match` rule, not for
2346 .. _bgp-large-communities-attribute:
2348 Large Communities Attribute
2349 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
2351 The BGP Large Communities attribute was introduced in Feb 2017 with
2354 The BGP Large Communities Attribute is similar to the BGP Communities Attribute
2355 except that it has 3 components instead of two and each of which are 4 octets
2356 in length. Large Communities bring additional functionality and convenience
2357 over traditional communities, specifically the fact that the ``GLOBAL`` part
2358 below is now 4 octets wide allowing seamless use in networks using 4-byte ASNs.
2360 ``GLOBAL:LOCAL1:LOCAL2``
2361 This is the format to define Large Community values. Referencing :rfc:`8195`
2362 the values are commonly referred to as follows:
2364 - The ``GLOBAL`` part is a 4 octet Global Administrator field, commonly used
2365 as the operators AS number.
2366 - The ``LOCAL1`` part is a 4 octet Local Data Part 1 subfield referred to as
2368 - The ``LOCAL2`` part is a 4 octet Local Data Part 2 field and referred to
2369 as the parameter subfield.
2371 As an example, ``65551:1:10`` represents AS 65551 function 1 and parameter
2372 10. The referenced RFC above gives some guidelines on recommended usage.
2374 .. _bgp-large-community-lists:
2376 Large Community Lists
2377 """""""""""""""""""""
2379 Two types of large community lists are supported, namely `standard` and
2382 .. clicmd:: bgp large-community-list standard NAME permit|deny LARGE-COMMUNITY
2384 This command defines a new standard large-community-list. `large-community`
2385 is the Large Community value. We can add multiple large communities under
2386 same name. In that case the match will happen in the user defined order.
2387 Once the large-community-list matches the Large Communities attribute in BGP
2388 updates it will return permit or deny based upon the large-community-list
2389 definition. When there is no matched entry, a deny will be returned. When
2390 `large-community` is empty it matches any routes.
2392 .. clicmd:: bgp large-community-list expanded NAME permit|deny LINE
2394 This command defines a new expanded large-community-list. Where `line` is a
2395 string matching expression, it will be compared to the entire Large
2396 Communities attribute as a string, with each large-community in order from
2397 lowest to highest. `line` can also be a regular expression which matches
2398 this Large Community attribute.
2400 Note that all community lists share the same namespace, so it's not
2401 necessary to specify ``standard`` or ``expanded``; these modifiers are
2404 .. clicmd:: show bgp large-community-list
2406 .. clicmd:: show bgp large-community-list NAME detail
2408 This command display current large-community-list information. When
2409 `name` is specified the community list information is shown.
2411 .. clicmd:: show ip bgp large-community-info
2413 This command displays the current large communities in use.
2415 .. _bgp-large-communities-in-route-map:
2417 Large Communities in Route Map
2418 """"""""""""""""""""""""""""""
2420 .. clicmd:: match large-community LINE [exact-match]
2422 Where `line` can be a simple string to match, or a regular expression. It
2423 is very important to note that this match occurs on the entire
2424 large-community string as a whole, where each large-community is ordered
2425 from lowest to highest. When `exact-match` keyword is specified, match
2426 happen only when BGP updates have completely same large communities value
2427 specified in the large community list.
2429 .. clicmd:: set large-community LARGE-COMMUNITY
2431 .. clicmd:: set large-community LARGE-COMMUNITY LARGE-COMMUNITY
2433 .. clicmd:: set large-community LARGE-COMMUNITY additive
2435 These commands are used for setting large-community values. The first
2436 command will overwrite any large-communities currently present.
2437 The second specifies two large-communities, which overwrites the current
2438 large-community list. The third will add a large-community value without
2439 overwriting other values. Multiple large-community values can be specified.
2441 Note that the large expanded community is only used for `match` rule, not for
2449 *bgpd* supports :abbr:`L3VPN (Layer 3 Virtual Private Networks)` :abbr:`VRFs
2450 (Virtual Routing and Forwarding)` for IPv4 :rfc:`4364` and IPv6 :rfc:`4659`.
2451 L3VPN routes, and their associated VRF MPLS labels, can be distributed to VPN
2452 SAFI neighbors in the *default*, i.e., non VRF, BGP instance. VRF MPLS labels
2453 are reached using *core* MPLS labels which are distributed using LDP or BGP
2454 labeled unicast. *bgpd* also supports inter-VRF route leaking.
2457 .. _bgp-vrf-route-leaking:
2462 BGP routes may be leaked (i.e. copied) between a unicast VRF RIB and the VPN
2463 SAFI RIB of the default VRF for use in MPLS-based L3VPNs. Unicast routes may
2464 also be leaked between any VRFs (including the unicast RIB of the default BGP
2465 instanced). A shortcut syntax is also available for specifying leaking from one
2466 VRF to another VRF using the default instance's VPN RIB as the intemediary. A
2467 common application of the VRF-VRF feature is to connect a customer's private
2468 routing domain to a provider's VPN service. Leaking is configured from the
2469 point of view of an individual VRF: ``import`` refers to routes leaked from VPN
2470 to a unicast VRF, whereas ``export`` refers to routes leaked from a unicast VRF
2476 Routes exported from a unicast VRF to the VPN RIB must be augmented by two
2479 - an :abbr:`RD (Route Distinguisher)`
2480 - an :abbr:`RTLIST (Route-target List)`
2482 Configuration for these exported routes must, at a minimum, specify these two
2485 Routes imported from the VPN RIB to a unicast VRF are selected according to
2486 their RTLISTs. Routes whose RTLIST contains at least one route-target in
2487 common with the configured import RTLIST are leaked. Configuration for these
2488 imported routes must specify an RTLIST to be matched.
2490 The RD, which carries no semantic value, is intended to make the route unique
2491 in the VPN RIB among all routes of its prefix that originate from all the
2492 customers and sites that are attached to the provider's VPN service.
2493 Accordingly, each site of each customer is typically assigned an RD that is
2494 unique across the entire provider network.
2496 The RTLIST is a set of route-target extended community values whose purpose is
2497 to specify route-leaking policy. Typically, a customer is assigned a single
2498 route-target value for import and export to be used at all customer sites. This
2499 configuration specifies a simple topology wherein a customer has a single
2500 routing domain which is shared across all its sites. More complex routing
2501 topologies are possible through use of additional route-targets to augment the
2502 leaking of sets of routes in various ways.
2504 When using the shortcut syntax for vrf-to-vrf leaking, the RD and RT are
2507 General configuration
2508 ^^^^^^^^^^^^^^^^^^^^^
2510 Configuration of route leaking between a unicast VRF RIB and the VPN SAFI RIB
2511 of the default VRF is accomplished via commands in the context of a VRF
2514 .. clicmd:: rd vpn export AS:NN|IP:nn
2516 Specifies the route distinguisher to be added to a route exported from the
2517 current unicast VRF to VPN.
2519 .. clicmd:: rt vpn import|export|both RTLIST...
2521 Specifies the route-target list to be attached to a route (export) or the
2522 route-target list to match against (import) when exporting/importing between
2523 the current unicast VRF and VPN.
2525 The RTLIST is a space-separated list of route-targets, which are BGP
2526 extended community values as described in
2527 :ref:`bgp-extended-communities-attribute`.
2529 .. clicmd:: label vpn export (0..1048575)|auto
2531 Enables an MPLS label to be attached to a route exported from the current
2532 unicast VRF to VPN. If the value specified is ``auto``, the label value is
2533 automatically assigned from a pool maintained by the Zebra daemon. If Zebra
2534 is not running, or if this command is not configured, automatic label
2535 assignment will not complete, which will block corresponding route export.
2537 .. clicmd:: nexthop vpn export A.B.C.D|X:X::X:X
2539 Specifies an optional nexthop value to be assigned to a route exported from
2540 the current unicast VRF to VPN. If left unspecified, the nexthop will be set
2541 to 0.0.0.0 or 0:0::0:0 (self).
2543 .. clicmd:: route-map vpn import|export MAP
2545 Specifies an optional route-map to be applied to routes imported or exported
2546 between the current unicast VRF and VPN.
2548 .. clicmd:: import|export vpn
2550 Enables import or export of routes between the current unicast VRF and VPN.
2552 .. clicmd:: import vrf VRFNAME
2554 Shortcut syntax for specifying automatic leaking from vrf VRFNAME to
2555 the current VRF using the VPN RIB as intermediary. The RD and RT
2556 are auto derived and should not be specified explicitly for either the
2557 source or destination VRF's.
2559 This shortcut syntax mode is not compatible with the explicit
2560 `import vpn` and `export vpn` statements for the two VRF's involved.
2561 The CLI will disallow attempts to configure incompatible leaking
2567 Ethernet Virtual Network - EVPN
2568 -------------------------------
2570 .. _bgp-evpn-advertise-pip:
2575 In a EVPN symmetric routing MLAG deployment, all EVPN routes advertised
2576 with anycast-IP as next-hop IP and anycast MAC as the Router MAC (RMAC - in
2577 BGP EVPN Extended-Community).
2578 EVPN picks up the next-hop IP from the VxLAN interface's local tunnel IP and
2579 the RMAC is obtained from the MAC of the L3VNI's SVI interface.
2580 Note: Next-hop IP is used for EVPN routes whether symmetric routing is
2581 deployed or not but the RMAC is only relevant for symmetric routing scenario.
2583 Current behavior is not ideal for Prefix (type-5) and self (type-2)
2584 routes. This is because the traffic from remote VTEPs routed sub optimally
2585 if they land on the system where the route does not belong.
2587 The advertise-pip feature advertises Prefix (type-5) and self (type-2)
2588 routes with system's individual (primary) IP as the next-hop and individual
2589 (system) MAC as Router-MAC (RMAC), while leaving the behavior unchanged for
2592 To support this feature there needs to have ability to co-exist a
2593 (system-MAC, system-IP) pair with a (anycast-MAC, anycast-IP) pair with the
2594 ability to terminate VxLAN-encapsulated packets received for either pair on
2595 the same L3VNI (i.e associated VLAN). This capability is need per tenant
2598 To derive the system-MAC and the anycast MAC, there needs to have a
2599 separate/additional MAC-VLAN interface corresponding to L3VNI’s SVI.
2600 The SVI interface’s MAC address can be interpreted as system-MAC
2601 and MAC-VLAN interface's MAC as anycast MAC.
2603 To derive system-IP and anycast-IP, the default BGP instance's router-id is used
2604 as system-IP and the VxLAN interface’s local tunnel IP as the anycast-IP.
2606 User has an option to configure the system-IP and/or system-MAC value if the
2607 auto derived value is not preferred.
2609 Note: By default, advertise-pip feature is enabled and user has an option to
2610 disable the feature via configuration CLI. Once the feature is disable under
2611 bgp vrf instance or MAC-VLAN interface is not configured, all the routes follow
2612 the same behavior of using same next-hop and RMAC values.
2614 .. clicmd:: advertise-pip [ip <addr> [mac <addr>]]
2616 Enables or disables advertise-pip feature, specifiy system-IP and/or system-MAC
2622 All-Active Multihoming is used for redundancy and load sharing. Servers
2623 are attached to two or more PEs and the links are bonded (link-aggregation).
2624 This group of server links is referred to as an Ethernet Segment.
2628 An Ethernet Segment can be configured by specifying a system-MAC and a
2629 local discriminatior against the bond interface on the PE (via zebra) -
2631 .. clicmd:: evpn mh es-id (1-16777215)
2633 .. clicmd:: evpn mh es-sys-mac X:X:X:X:X:X
2635 The sys-mac and local discriminator are used for generating a 10-byte,
2636 Type-3 Ethernet Segment ID.
2638 Type-1 (EAS-per-ES and EAD-per-EVI) routes are used to advertise the locally
2639 attached ESs and to learn off remote ESs in the network. Local Type-2/MAC-IP
2640 routes are also advertised with a destination ESI allowing for MAC-IP syncing
2641 between Ethernet Segment peers.
2642 Reference: RFC 7432, RFC 8365
2644 EVPN-MH is intended as a replacement for MLAG or Anycast VTEPs. In
2645 multihoming each PE has an unique VTEP address which requires the introduction
2646 of a new dataplane construct, MAC-ECMP. Here a MAC/FDB entry can point to a
2647 list of remote PEs/VTEPs.
2651 Type-4 (ESR) routes are used for Designated Forwarder (DF) election. DFs
2652 forward BUM traffic received via the overlay network. This implementation
2653 uses a preference based DF election specified by draft-ietf-bess-evpn-pref-df.
2654 The DF preference is configurable per-ES (via zebra) -
2656 .. clicmd:: evpn mh es-df-pref (1-16777215)
2658 BUM traffic is rxed via the overlay by all PEs attached to a server but
2659 only the DF can forward the de-capsulated traffic to the access port. To
2660 accomodate that non-DF filters are installed in the dataplane to drop
2663 Similarly traffic received from ES peers via the overlay cannot be forwarded
2664 to the server. This is split-horizon-filtering with local bias.
2668 Some vendors do not send EAD-per-EVI routes. To interop with them we
2669 need to relax the dependency on EAD-per-EVI routes and activate a remote
2670 ES-PE based on just the EAD-per-ES route.
2672 Note that by default we advertise and expect EAD-per-EVI routes.
2674 .. clicmd:: disable-ead-evi-rx
2676 .. clicmd:: disable-ead-evi-tx
2680 As the primary purpose of EVPN-MH is redundancy keeping the failover efficient
2681 is a recurring theme in the implementation. Following sub-features have
2682 been introduced for the express purpose of efficient ES failovers.
2684 - Layer-2 Nexthop Groups and MAC-ECMP via L2NHG.
2686 - Host routes (for symmetric IRB) via L3NHG.
2687 On dataplanes that support layer3 nexthop groups the feature can be turned
2688 on via the following BGP config -
2690 .. clicmd:: use-es-l3nhg
2692 - Local ES (MAC/Neigh) failover via ES-redirect.
2693 On dataplanes that do not have support for ES-redirect the feature can be
2694 turned off via the following zebra config -
2696 .. clicmd:: evpn mh redirect-off
2698 Uplink/Core tracking
2699 """"""""""""""""""""
2700 When all the underlay links go down the PE no longer has access to the VxLAN
2701 +overlay. To prevent blackholing of traffic the server/ES links are
2702 protodowned on the PE. A link can be setup for uplink tracking via the
2703 following zebra configuration -
2705 .. clicmd:: evpn mh uplink
2707 Proxy advertisements
2708 """"""""""""""""""""
2709 To handle hitless upgrades support for proxy advertisement has been added
2710 as specified by draft-rbickhart-evpn-ip-mac-proxy-adv. This allows a PE
2711 (say PE1) to proxy advertise a MAC-IP rxed from an ES peer (say PE2). When
2712 the ES peer (PE2) goes down PE1 continues to advertise hosts learnt from PE2
2713 for a holdtime during which it attempts to establish local reachability of
2714 the host. This holdtime is configurable via the following zebra commands -
2716 .. clicmd:: evpn mh neigh-holdtime (0-86400)
2718 .. clicmd:: evpn mh mac-holdtime (0-86400)
2722 When a switch is rebooted we wait for a brief period to allow the underlay
2723 and EVPN network to converge before enabling the ESs. For this duration the
2724 ES bonds are held protodown. The startup delay is configurable via the
2725 following zebra command -
2727 .. clicmd:: evpn mh startup-delay (0-3600)
2729 +Support with VRF network namespace backend
2730 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2731 It is possible to separate overlay networks contained in VXLAN interfaces from
2732 underlay networks by using VRFs. VRF-lite and VRF-netns backends can be used for
2733 that. In the latter case, it is necessary to set both bridge and vxlan interface
2734 in the same network namespace, as below example illustrates:
2736 .. code-block:: shell
2740 ip link add name vxlan101 type vxlan id 101 dstport 4789 dev eth0 local 10.1.1.1
2741 ip link set dev vxlan101 netns vrf1
2742 ip netns exec vrf1 ip link set dev lo up
2743 ip netns exec vrf1 brctl addbr bridge101
2744 ip netns exec vrf1 brctl addif bridge101 vxlan101
2746 This makes it possible to separate not only layer 3 networks like VRF-lite networks.
2747 Also, VRF netns based make possible to separate layer 2 networks on separate VRF
2750 .. _bgp-conditional-advertisement:
2752 BGP Conditional Advertisement
2753 -----------------------------
2754 The BGP conditional advertisement feature uses the ``non-exist-map`` or the
2755 ``exist-map`` and the ``advertise-map`` keywords of the neighbor advertise-map
2756 command in order to track routes by the route prefix.
2759 1. If a route prefix is not present in the output of non-exist-map command,
2760 then advertise the route specified by the advertise-map command.
2762 2. If a route prefix is present in the output of non-exist-map command,
2763 then do not advertise the route specified by the addvertise-map command.
2766 1. If a route prefix is present in the output of exist-map command,
2767 then advertise the route specified by the advertise-map command.
2769 2. If a route prefix is not present in the output of exist-map command,
2770 then do not advertise the route specified by the advertise-map command.
2772 This feature is useful when some prefixes are advertised to one of its peers
2773 only if the information from the other peer is not present (due to failure in
2774 peering session or partial reachability etc).
2776 The conditional BGP announcements are sent in addition to the normal
2777 announcements that a BGP router sends to its peer.
2779 The conditional advertisement process is triggered by the BGP scanner process,
2780 which runs every 60 seconds. This means that the maximum time for the conditional
2781 advertisement to take effect is 60 seconds. The conditional advertisement can take
2782 effect depending on when the tracked route is removed from the BGP table and
2783 when the next instance of the BGP scanner occurs.
2785 .. clicmd:: neighbor A.B.C.D advertise-map NAME [exist-map|non-exist-map] NAME
2787 This command enables BGP scanner process to monitor routes specified by
2788 exist-map or non-exist-map command in BGP table and conditionally advertises
2789 the routes specified by advertise-map command.
2791 Sample Configuration
2792 ^^^^^^^^^^^^^^^^^^^^^
2796 ip address 10.10.10.2/24
2799 ip address 10.10.20.2/24
2802 ip address 203.0.113.1/32
2805 bgp log-neighbor-changes
2806 no bgp ebgp-requires-policy
2807 neighbor 10.10.10.1 remote-as 1
2808 neighbor 10.10.20.3 remote-as 3
2810 address-family ipv4 unicast
2811 neighbor 10.10.10.1 soft-reconfiguration inbound
2812 neighbor 10.10.20.3 soft-reconfiguration inbound
2813 neighbor 10.10.20.3 advertise-map ADV-MAP non-exist-map EXIST-MAP
2816 ip prefix-list DEFAULT seq 5 permit 192.0.2.5/32
2817 ip prefix-list DEFAULT seq 10 permit 192.0.2.1/32
2818 ip prefix-list EXIST seq 5 permit 10.10.10.10/32
2819 ip prefix-list DEFAULT-ROUTE seq 5 permit 0.0.0.0/0
2820 ip prefix-list IP1 seq 5 permit 10.139.224.0/20
2822 bgp community-list standard DC-ROUTES seq 5 permit 64952:3008
2823 bgp community-list standard DC-ROUTES seq 10 permit 64671:501
2824 bgp community-list standard DC-ROUTES seq 15 permit 64950:3009
2825 bgp community-list standard DEFAULT-ROUTE seq 5 permit 65013:200
2827 route-map ADV-MAP permit 10
2828 match ip address prefix-list IP1
2830 route-map ADV-MAP permit 20
2831 match community DC-ROUTES
2833 route-map EXIST-MAP permit 10
2834 match community DEFAULT-ROUTE
2835 match ip address prefix-list DEFAULT-ROUTE
2841 When default route is present in R2'2 BGP table, 10.139.224.0/20 and 192.0.2.1/32 are not advertised to R3.
2845 Router2# show ip bgp
2846 BGP table version is 20, local router ID is 203.0.113.1, vrf id 0
2847 Default local pref 100, local AS 2
2848 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
2849 i internal, r RIB-failure, S Stale, R Removed
2850 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
2851 Origin codes: i - IGP, e - EGP, ? - incomplete
2852 RPKI validation codes: V valid, I invalid, N Not found
2854 Network Next Hop Metric LocPrf Weight Path
2855 *> 0.0.0.0/0 10.10.10.1 0 0 1 i
2856 *> 10.139.224.0/20 10.10.10.1 0 0 1 ?
2857 *> 192.0.2.1/32 10.10.10.1 0 0 1 i
2858 *> 192.0.2.5/32 10.10.10.1 0 0 1 i
2860 Displayed 4 routes and 4 total paths
2861 Router2# show ip bgp neighbors 10.10.20.3
2863 !--- Output suppressed.
2865 For address family: IPv4 Unicast
2866 Update group 7, subgroup 7
2867 Packet Queue length 0
2868 Inbound soft reconfiguration allowed
2869 Community attribute sent to this neighbor(all)
2870 Condition NON_EXIST, Condition-map *EXIST-MAP, Advertise-map *ADV-MAP, status: Withdraw
2873 !--- Output suppressed.
2875 Router2# show ip bgp neighbors 10.10.20.3 advertised-routes
2876 BGP table version is 20, local router ID is 203.0.113.1, vrf id 0
2877 Default local pref 100, local AS 2
2878 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
2879 i internal, r RIB-failure, S Stale, R Removed
2880 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
2881 Origin codes: i - IGP, e - EGP, ? - incomplete
2882 RPKI validation codes: V valid, I invalid, N Not found
2884 Network Next Hop Metric LocPrf Weight Path
2885 *> 0.0.0.0/0 0.0.0.0 0 1 i
2886 *> 192.0.2.5/32 0.0.0.0 0 1 i
2888 Total number of prefixes 2
2890 When default route is not present in R2'2 BGP table, 10.139.224.0/20 and 192.0.2.1/32 are advertised to R3.
2894 Router2# show ip bgp
2895 BGP table version is 21, local router ID is 203.0.113.1, vrf id 0
2896 Default local pref 100, local AS 2
2897 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
2898 i internal, r RIB-failure, S Stale, R Removed
2899 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
2900 Origin codes: i - IGP, e - EGP, ? - incomplete
2901 RPKI validation codes: V valid, I invalid, N Not found
2903 Network Next Hop Metric LocPrf Weight Path
2904 *> 10.139.224.0/20 10.10.10.1 0 0 1 ?
2905 *> 192.0.2.1/32 10.10.10.1 0 0 1 i
2906 *> 192.0.2.5/32 10.10.10.1 0 0 1 i
2908 Displayed 3 routes and 3 total paths
2910 Router2# show ip bgp neighbors 10.10.20.3
2912 !--- Output suppressed.
2914 For address family: IPv4 Unicast
2915 Update group 7, subgroup 7
2916 Packet Queue length 0
2917 Inbound soft reconfiguration allowed
2918 Community attribute sent to this neighbor(all)
2919 Condition NON_EXIST, Condition-map *EXIST-MAP, Advertise-map *ADV-MAP, status: Advertise
2922 !--- Output suppressed.
2924 Router2# show ip bgp neighbors 10.10.20.3 advertised-routes
2925 BGP table version is 21, local router ID is 203.0.113.1, vrf id 0
2926 Default local pref 100, local AS 2
2927 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
2928 i internal, r RIB-failure, S Stale, R Removed
2929 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
2930 Origin codes: i - IGP, e - EGP, ? - incomplete
2931 RPKI validation codes: V valid, I invalid, N Not found
2933 Network Next Hop Metric LocPrf Weight Path
2934 *> 10.139.224.0/20 0.0.0.0 0 1 ?
2935 *> 192.0.2.1/32 0.0.0.0 0 1 i
2936 *> 192.0.2.5/32 0.0.0.0 0 1 i
2938 Total number of prefixes 3
2946 .. clicmd:: show debug
2948 Show all enabled debugs.
2950 .. clicmd:: show bgp listeners
2952 Display Listen sockets and the vrf that created them. Useful for debugging of when
2953 listen is not working and this is considered a developer debug statement.
2955 .. clicmd:: debug bgp bfd
2957 Enable or disable debugging for BFD events. This will show BFD integration
2958 library messages and BGP BFD integration messages that are mostly state
2959 transitions and validation problems.
2961 .. clicmd:: debug bgp neighbor-events
2963 Enable or disable debugging for neighbor events. This provides general
2964 information on BGP events such as peer connection / disconnection, session
2965 establishment / teardown, and capability negotiation.
2967 .. clicmd:: debug bgp updates
2969 Enable or disable debugging for BGP updates. This provides information on
2970 BGP UPDATE messages transmitted and received between local and remote
2973 .. clicmd:: debug bgp keepalives
2975 Enable or disable debugging for BGP keepalives. This provides information on
2976 BGP KEEPALIVE messages transmitted and received between local and remote
2979 .. clicmd:: debug bgp bestpath <A.B.C.D/M|X:X::X:X/M>
2981 Enable or disable debugging for bestpath selection on the specified prefix.
2983 .. clicmd:: debug bgp nht
2985 Enable or disable debugging of BGP nexthop tracking.
2987 .. clicmd:: debug bgp update-groups
2989 Enable or disable debugging of dynamic update groups. This provides general
2990 information on group creation, deletion, join and prune events.
2992 .. clicmd:: debug bgp zebra
2994 Enable or disable debugging of communications between *bgpd* and *zebra*.
2996 Dumping Messages and Routing Tables
2997 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2999 .. clicmd:: dump bgp all PATH [INTERVAL]
3001 .. clicmd:: dump bgp all-et PATH [INTERVAL]
3004 Dump all BGP packet and events to `path` file.
3005 If `interval` is set, a new file will be created for echo `interval` of
3006 seconds. The path `path` can be set with date and time formatting
3007 (strftime). The type ‘all-et’ enables support for Extended Timestamp Header
3008 (:ref:`packet-binary-dump-format`).
3010 .. clicmd:: dump bgp updates PATH [INTERVAL]
3012 .. clicmd:: dump bgp updates-et PATH [INTERVAL]
3015 Dump only BGP updates messages to `path` file.
3016 If `interval` is set, a new file will be created for echo `interval` of
3017 seconds. The path `path` can be set with date and time formatting
3018 (strftime). The type ‘updates-et’ enables support for Extended Timestamp
3019 Header (:ref:`packet-binary-dump-format`).
3021 .. clicmd:: dump bgp routes-mrt PATH
3023 .. clicmd:: dump bgp routes-mrt PATH INTERVAL
3026 Dump whole BGP routing table to `path`. This is heavy process. The path
3027 `path` can be set with date and time formatting (strftime). If `interval` is
3028 set, a new file will be created for echo `interval` of seconds.
3030 Note: the interval variable can also be set using hours and minutes: 04h20m00.
3033 .. _bgp-other-commands:
3038 The following are available in the top level *enable* mode:
3040 .. clicmd:: clear bgp \*
3044 .. clicmd:: clear bgp ipv4|ipv6 \*
3046 Clear all peers with this address-family activated.
3048 .. clicmd:: clear bgp ipv4|ipv6 unicast \*
3050 Clear all peers with this address-family and sub-address-family activated.
3052 .. clicmd:: clear bgp ipv4|ipv6 PEER
3054 Clear peers with address of X.X.X.X and this address-family activated.
3056 .. clicmd:: clear bgp ipv4|ipv6 unicast PEER
3058 Clear peer with address of X.X.X.X and this address-family and sub-address-family activated.
3060 .. clicmd:: clear bgp ipv4|ipv6 PEER soft|in|out
3062 Clear peer using soft reconfiguration in this address-family.
3064 .. clicmd:: clear bgp ipv4|ipv6 unicast PEER soft|in|out
3066 Clear peer using soft reconfiguration in this address-family and sub-address-family.
3068 The following are available in the ``router bgp`` mode:
3070 .. clicmd:: write-quanta (1-64)
3072 BGP message Tx I/O is vectored. This means that multiple packets are written
3073 to the peer socket at the same time each I/O cycle, in order to minimize
3074 system call overhead. This value controls how many are written at a time.
3075 Under certain load conditions, reducing this value could make peer traffic
3076 less 'bursty'. In practice, leave this settings on the default (64) unless
3077 you truly know what you are doing.
3079 .. clicmd:: read-quanta (1-10)
3081 Unlike Tx, BGP Rx traffic is not vectored. Packets are read off the wire one
3082 at a time in a loop. This setting controls how many iterations the loop runs
3083 for. As with write-quanta, it is best to leave this setting on the default.
3085 The following command is available in ``config`` mode as well as in the
3086 ``router bgp`` mode:
3088 .. clicmd:: bgp graceful-shutdown
3090 The purpose of this command is to initiate BGP Graceful Shutdown which
3091 is described in :rfc:`8326`. The use case for this is to minimize or
3092 eliminate the amount of traffic loss in a network when a planned
3093 maintenance activity such as software upgrade or hardware replacement
3094 is to be performed on a router. The feature works by re-announcing
3095 routes to eBGP peers with the GRACEFUL_SHUTDOWN community included.
3096 Peers are then expected to treat such paths with the lowest preference.
3097 This happens automatically on a receiver running FRR; with other
3098 routing protocol stacks, an inbound policy may have to be configured.
3099 In FRR, triggering graceful shutdown also results in announcing a
3100 LOCAL_PREF of 0 to iBGP peers.
3102 Graceful shutdown can be configured per BGP instance or globally for
3103 all of BGP. These two options are mutually exclusive. The no form of
3104 the command causes graceful shutdown to be stopped, and routes will
3105 be re-announced without the GRACEFUL_SHUTDOWN community and/or with
3106 the usual LOCAL_PREF value. Note that if this option is saved to
3107 the startup configuration, graceful shutdown will remain in effect
3108 across restarts of *bgpd* and will need to be explicitly disabled.
3110 .. _bgp-displaying-bgp-information:
3112 Displaying BGP Information
3113 ==========================
3115 The following four commands display the IPv6 and IPv4 routing tables, depending
3116 on whether or not the ``ip`` keyword is used.
3117 Actually, :clicmd:`show ip bgp` command was used on older `Quagga` routing
3118 daemon project, while :clicmd:`show bgp` command is the new format. The choice
3119 has been done to keep old format with IPv4 routing table, while new format
3120 displays IPv6 routing table.
3122 .. clicmd:: show ip bgp [all] [wide|json [detail]]
3124 .. clicmd:: show ip bgp A.B.C.D [json]
3126 .. clicmd:: show bgp [all] [wide|json [detail]]
3128 .. clicmd:: show bgp X:X::X:X [json]
3130 These commands display BGP routes. When no route is specified, the default
3131 is to display all BGP routes.
3135 BGP table version is 0, local router ID is 10.1.1.1
3136 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
3137 Origin codes: i - IGP, e - EGP, ? - incomplete
3139 Network Next Hop Metric LocPrf Weight Path
3140 \*> 1.1.1.1/32 0.0.0.0 0 32768 i
3142 Total number of prefixes 1
3144 If ``wide`` option is specified, then the prefix table's width is increased
3145 to fully display the prefix and the nexthop.
3147 This is especially handy dealing with IPv6 prefixes and
3148 if :clicmd:`[no] bgp default show-nexthop-hostname` is enabled.
3150 If ``all`` option is specified, ``ip`` keyword is ignored, show bgp all and
3151 show ip bgp all commands display routes for all AFIs and SAFIs.
3153 If ``json`` option is specified, output is displayed in JSON format.
3155 If ``detail`` option is specified after ``json``, more verbose JSON output
3158 Some other commands provide additional options for filtering the output.
3160 .. clicmd:: show [ip] bgp regexp LINE
3162 This command displays BGP routes using AS path regular expression
3163 (:ref:`bgp-regular-expressions`).
3165 .. clicmd:: show [ip] bgp [all] summary [wide] [json]
3167 Show a bgp peer summary for the specified address family.
3169 The old command structure :clicmd:`show ip bgp` may be removed in the future
3170 and should no longer be used. In order to reach the other BGP routing tables
3171 other than the IPv6 routing table given by :clicmd:`show bgp`, the new command
3172 structure is extended with :clicmd:`show bgp [afi] [safi]`.
3174 ``wide`` option gives more output like ``LocalAS`` and extended ``Desc`` to
3179 exit1# show ip bgp summary wide
3181 IPv4 Unicast Summary:
3182 BGP router identifier 192.168.100.1, local AS number 65534 vrf-id 0
3184 RIB entries 5, using 920 bytes of memory
3185 Peers 1, using 27 KiB of memory
3187 Neighbor V AS LocalAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
3188 192.168.0.2 4 65030 123 15 22 0 0 0 00:07:00 0 1 us-east1-rs1.frrouting.org
3190 Total number of neighbors 1
3193 .. clicmd:: show bgp [afi] [safi] [all] [wide|json]
3195 .. clicmd:: show bgp [<ipv4|ipv6> <unicast|multicast|vpn|labeled-unicast|flowspec> | l2vpn evpn]
3197 These commands display BGP routes for the specific routing table indicated by
3198 the selected afi and the selected safi. If no afi and no safi value is given,
3199 the command falls back to the default IPv6 routing table.
3201 .. clicmd:: show bgp l2vpn evpn route [type <macip|2|multicast|3|es|4|prefix|5>]
3203 EVPN prefixes can also be filtered by EVPN route type.
3205 .. clicmd:: show bgp [afi] [safi] [all] summary [json]
3207 Show a bgp peer summary for the specified address family, and subsequent
3210 .. clicmd:: show bgp [afi] [safi] [all] summary failed [json]
3212 Show a bgp peer summary for peers that are not succesfully exchanging routes
3213 for the specified address family, and subsequent address-family.
3215 .. clicmd:: show bgp [afi] [safi] [all] summary established [json]
3217 Show a bgp peer summary for peers that are succesfully exchanging routes
3218 for the specified address family, and subsequent address-family.
3220 .. clicmd:: show bgp [afi] [safi] [neighbor [PEER] [routes|advertised-routes|received-routes] [json]
3222 This command shows information on a specific BGP peer of the relevant
3223 afi and safi selected.
3225 The ``routes`` keyword displays only routes in this address-family's BGP
3226 table that were received by this peer and accepted by inbound policy.
3228 The ``advertised-routes`` keyword displays only the routes in this
3229 address-family's BGP table that were permitted by outbound policy and
3230 advertised to to this peer.
3232 The ``received-routes`` keyword displays all routes belonging to this
3233 address-family (prior to inbound policy) that were received by this peer.
3235 .. clicmd:: show bgp [afi] [safi] [all] dampening dampened-paths [wide|json]
3237 Display paths suppressed due to dampening of the selected afi and safi
3240 .. clicmd:: show bgp [afi] [safi] [all] dampening flap-statistics [wide|json]
3242 Display flap statistics of routes of the selected afi and safi selected.
3244 .. clicmd:: show bgp [afi] [safi] [all] version (1-4294967295) [wide|json]
3246 Display prefixes with matching version numbers. The version number and
3247 above having prefixes will be listed here.
3249 It helps to identify which prefixes were installed at some point.
3251 Here is an example of how to check what prefixes were installed starting
3252 with an arbitrary version::
3256 ~# vtysh -c 'show bgp ipv4 unicast json' | jq '.tableVersion'
3258 ~# vtysh -c 'show ip bgp version 9 json' | jq -r '.routes | keys[]'
3260 ~# vtysh -c 'show ip bgp version 8 json' | jq -r '.routes | keys[]'
3264 .. clicmd:: show bgp [afi] [safi] statistics
3266 Display statistics of routes of the selected afi and safi.
3268 .. clicmd:: show bgp statistics-all
3270 Display statistics of routes of all the afi and safi.
3272 .. clicmd:: show [ip] bgp [afi] [safi] [all] cidr-only [wide|json]
3274 Display routes with non-natural netmasks.
3276 .. clicmd:: show [ip] bgp [afi] [safi] [all] neighbors A.B.C.D [advertised-routes|received-routes|filtered-routes] [json|wide]
3278 Display the routes advertised to a BGP neighbor or received routes
3279 from neighbor or filtered routes received from neighbor based on the
3282 If ``wide`` option is specified, then the prefix table's width is increased
3283 to fully display the prefix and the nexthop.
3285 This is especially handy dealing with IPv6 prefixes and
3286 if :clicmd:`[no] bgp default show-nexthop-hostname` is enabled.
3288 If ``all`` option is specified, ``ip`` keyword is ignored and,
3289 routes displayed for all AFIs and SAFIs.
3290 if afi is specified, with ``all`` option, routes will be displayed for
3291 each SAFI in the selcted AFI
3293 If ``json`` option is specified, output is displayed in JSON format.
3295 .. _bgp-display-routes-by-community:
3297 Displaying Routes by Community Attribute
3298 ----------------------------------------
3300 The following commands allow displaying routes based on their community
3303 .. clicmd:: show [ip] bgp <ipv4|ipv6> [all] community [wide|json]
3305 .. clicmd:: show [ip] bgp <ipv4|ipv6> [all] community COMMUNITY [wide|json]
3307 .. clicmd:: show [ip] bgp <ipv4|ipv6> [all] community COMMUNITY exact-match [wide|json]
3309 These commands display BGP routes which have the community attribute.
3310 attribute. When ``COMMUNITY`` is specified, BGP routes that match that
3311 community are displayed. When `exact-match` is specified, it display only
3312 routes that have an exact match.
3314 .. clicmd:: show [ip] bgp <ipv4|ipv6> community-list WORD
3316 .. clicmd:: show [ip] bgp <ipv4|ipv6> community-list WORD exact-match
3318 These commands display BGP routes for the address family specified that
3319 match the specified community list. When `exact-match` is specified, it
3320 displays only routes that have an exact match.
3322 If ``wide`` option is specified, then the prefix table's width is increased
3323 to fully display the prefix and the nexthop.
3325 This is especially handy dealing with IPv6 prefixes and
3326 if :clicmd:`[no] bgp default show-nexthop-hostname` is enabled.
3328 If ``all`` option is specified, ``ip`` keyword is ignored and,
3329 routes displayed for all AFIs and SAFIs.
3330 if afi is specified, with ``all`` option, routes will be displayed for
3331 each SAFI in the selcted AFI
3333 If ``json`` option is specified, output is displayed in JSON format.
3335 .. clicmd:: show bgp labelpool <chunks|inuse|ledger|requests|summary> [json]
3337 These commands display information about the BGP labelpool used for
3338 the association of MPLS labels with routes for L3VPN and Labeled Unicast
3340 If ``chunks`` option is specified, output shows the current list of label
3341 chunks granted to BGP by Zebra, indicating the start and end label in
3344 If ``inuse`` option is specified, output shows the current inuse list of
3345 label to prefix mappings
3347 If ``ledger`` option is specified, output shows ledger list of all
3348 label requests made per prefix
3350 If ``requests`` option is specified, output shows current list of label
3351 requests which have not yet been fulfilled by the labelpool
3353 If ``summary`` option is specified, output is a summary of the counts for
3354 the chunks, inuse, ledger and requests list along with the count of
3355 outstanding chunk requests to Zebra and the nummber of zebra reconnects
3358 If ``json`` option is specified, output is displayed in JSON format.
3360 .. _bgp-display-routes-by-lcommunity:
3362 Displaying Routes by Large Community Attribute
3363 ----------------------------------------------
3365 The following commands allow displaying routes based on their
3366 large community attribute.
3368 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community
3370 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY
3372 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY exact-match
3374 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY json
3376 These commands display BGP routes which have the large community attribute.
3377 attribute. When ``LARGE-COMMUNITY`` is specified, BGP routes that match that
3378 large community are displayed. When `exact-match` is specified, it display
3379 only routes that have an exact match. When `json` is specified, it display
3380 routes in json format.
3382 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community-list WORD
3384 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community-list WORD exact-match
3386 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community-list WORD json
3388 These commands display BGP routes for the address family specified that
3389 match the specified large community list. When `exact-match` is specified,
3390 it displays only routes that have an exact match. When `json` is specified,
3391 it display routes in json format.
3393 .. _bgp-display-routes-by-as-path:
3396 Displaying Routes by AS Path
3397 ----------------------------
3399 .. clicmd:: show bgp ipv4|ipv6 regexp LINE
3401 This commands displays BGP routes that matches a regular
3402 expression `line` (:ref:`bgp-regular-expressions`).
3404 .. clicmd:: show [ip] bgp ipv4 vpn
3406 .. clicmd:: show [ip] bgp ipv6 vpn
3408 Print active IPV4 or IPV6 routes advertised via the VPN SAFI.
3410 .. clicmd:: show bgp ipv4 vpn summary
3412 .. clicmd:: show bgp ipv6 vpn summary
3414 Print a summary of neighbor connections for the specified AFI/SAFI combination.
3416 Displaying Routes by Route Distinguisher
3417 ----------------------------------------
3419 .. clicmd:: show bgp [<ipv4|ipv6> vpn | l2vpn evpn [route]] rd <all|RD>
3421 For L3VPN and EVPN address-families, routes can be displayed on a per-RD
3422 (Route Distinguisher) basis or for all RD's.
3424 .. clicmd:: show bgp l2vpn evpn rd <all|RD> [overlay | tags]
3426 Use the ``overlay`` or ``tags`` keywords to display the overlay/tag
3427 information about the EVPN prefixes in the selected Route Distinguisher.
3429 .. clicmd:: show bgp l2vpn evpn route rd <all|RD> mac <MAC> [ip <MAC>] [json]
3431 For EVPN Type 2 (macip) routes, a MAC address (and optionally an IP address)
3432 can be supplied to the command to only display matching prefixes in the
3435 Displaying Update Group Information
3436 -----------------------------------
3438 .. clicmd:: show bgp update-groups [advertise-queue|advertised-routes|packet-queue]
3440 Display Information about each individual update-group being used.
3441 If SUBGROUP-ID is specified only display about that particular group. If
3442 advertise-queue is specified the list of routes that need to be sent
3443 to the peers in the update-group is displayed, advertised-routes means
3444 the list of routes we have sent to the peers in the update-group and
3445 packet-queue specifies the list of packets in the queue to be sent.
3447 .. clicmd:: show bgp update-groups statistics
3449 Display Information about update-group events in FRR.
3451 .. _bgp-route-reflector:
3456 BGP routers connected inside the same AS through BGP belong to an internal
3457 BGP session, or IBGP. In order to prevent routing table loops, IBGP does not
3458 advertise IBGP-learned routes to other routers in the same session. As such,
3459 IBGP requires a full mesh of all peers. For large networks, this quickly becomes
3460 unscalable. Introducing route reflectors removes the need for the full-mesh.
3462 When route reflectors are configured, these will reflect the routes announced
3463 by the peers configured as clients. A route reflector client is configured
3466 .. clicmd:: neighbor PEER route-reflector-client
3469 To avoid single points of failure, multiple route reflectors can be configured.
3471 A cluster is a collection of route reflectors and their clients, and is used
3472 by route reflectors to avoid looping.
3474 .. clicmd:: bgp cluster-id A.B.C.D
3476 .. clicmd:: bgp no-rib
3478 To set and unset the BGP daemon ``-n`` / ``--no_kernel`` options during runtime
3479 to disable BGP route installation to the RIB (Zebra), the ``[no] bgp no-rib``
3480 commands can be used;
3482 Please note that setting the option during runtime will withdraw all routes in
3483 the daemons RIB from Zebra and unsetting it will announce all routes in the
3484 daemons RIB to Zebra. If the option is passed as a command line argument when
3485 starting the daemon and the configuration gets saved, the option will persist
3486 unless removed from the configuration with the negating command prior to the
3487 configuration write operation.
3489 .. clicmd:: bgp send-extra-data zebra
3491 This Command turns off the ability of BGP to send extra data to zebra.
3492 In this case it's the AS-Path being used for the path. The default behavior
3493 in BGP is to send this data and to turn it off enter the no form of the command.
3494 If extra data was sent to zebra, and this command is turned on there is no
3495 effort to clean up this data in the rib.
3497 .. _bgp-suppress-fib:
3499 Suppressing routes not installed in FIB
3500 =======================================
3502 The FRR implementation of BGP advertises prefixes learnt from a peer to other
3503 peers even if the routes do not get installed in the FIB. There can be
3504 scenarios where the hardware tables in some of the routers (along the path from
3505 the source to destination) is full which will result in all routes not getting
3506 installed in the FIB. If these routes are advertised to the downstream routers
3507 then traffic will start flowing and will be dropped at the intermediate router.
3509 The solution is to provide a configurable option to check for the FIB install
3510 status of the prefixes and advertise to peers if the prefixes are successfully
3511 installed in the FIB. The advertisement of the prefixes are suppressed if it is
3512 not installed in FIB.
3514 The following conditions apply will apply when checking for route installation
3517 1. The advertisement or suppression of routes based on FIB install status
3518 applies only for newly learnt routes from peer (routes which are not in
3520 2. If the route received from peer already exists in BGP local RIB and route
3521 attributes have changed (best path changed), the old path is deleted and
3522 new path is installed in FIB. The FIB install status will not have any
3523 effect. Therefore only when the route is received first time the checks
3525 3. The feature will not apply for routes learnt through other means like
3526 redistribution to bgp from other protocols. This is applicable only to
3528 4. If a route is installed in FIB and then gets deleted from the dataplane,
3529 then routes will not be withdrawn from peers. This will be considered as
3531 5. The feature will slightly increase the time required to advertise the routes
3532 to peers since the route install status needs to be received from the FIB
3533 6. If routes are received by the peer before the configuration is applied, then
3534 the bgp sessions need to be reset for the configuration to take effect.
3535 7. If the route which is already installed in dataplane is removed for some
3536 reason, sending withdraw message to peers is not currently supported.
3538 .. clicmd:: bgp suppress-fib-pending
3540 This command is applicable at the global level and at an individual
3541 bgp level. If applied at the global level all bgp instances will
3542 wait for fib installation before announcing routes and there is no
3543 way to turn it off for a particular bgp vrf.
3550 You can set different routing policy for a peer. For example, you can set
3551 different filter for a peer.
3557 neighbor 10.0.0.1 remote-as 2
3558 address-family ipv4 unicast
3559 neighbor 10.0.0.1 distribute-list 1 in
3563 neighbor 10.0.0.1 remote-as 2
3564 address-family ipv4 unicast
3565 neighbor 10.0.0.1 distribute-list 2 in
3568 This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view 2.
3569 When the update is inserted into view 1, distribute-list 1 is applied. On the
3570 other hand, when the update is inserted into view 2, distribute-list 2 is
3574 .. _bgp-regular-expressions:
3576 BGP Regular Expressions
3577 =======================
3579 BGP regular expressions are based on :t:`POSIX 1003.2` regular expressions. The
3580 following description is just a quick subset of the POSIX regular expressions.
3584 Matches any single character.
3587 Matches 0 or more occurrences of pattern.
3590 Matches 1 or more occurrences of pattern.
3593 Match 0 or 1 occurrences of pattern.
3596 Matches the beginning of the line.
3599 Matches the end of the line.
3602 The ``_`` character has special meanings in BGP regular expressions. It
3603 matches to space and comma , and AS set delimiter ``{`` and ``}`` and AS
3604 confederation delimiter ``(`` and ``)``. And it also matches to the
3605 beginning of the line and the end of the line. So ``_`` can be used for AS
3606 value boundaries match. This character technically evaluates to
3610 .. _bgp-configuration-examples:
3612 Miscellaneous Configuration Examples
3613 ====================================
3615 Example of a session to an upstream, advertising only one prefix to it.
3620 bgp router-id 10.236.87.1
3621 neighbor upstream peer-group
3622 neighbor upstream remote-as 64515
3623 neighbor upstream capability dynamic
3624 neighbor 10.1.1.1 peer-group upstream
3625 neighbor 10.1.1.1 description ACME ISP
3627 address-family ipv4 unicast
3628 network 10.236.87.0/24
3629 neighbor upstream prefix-list pl-allowed-adv out
3632 ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
3633 ip prefix-list pl-allowed-adv seq 10 deny any
3635 A more complex example including upstream, peer and customer sessions
3636 advertising global prefixes and NO_EXPORT prefixes and providing actions for
3637 customer routes based on community values. Extensive use is made of route-maps
3638 and the 'call' feature to support selective advertising of prefixes. This
3639 example is intended as guidance only, it has NOT been tested and almost
3640 certainly contains silly mistakes, if not serious flaws.
3645 bgp router-id 10.236.87.1
3646 neighbor upstream capability dynamic
3647 neighbor cust capability dynamic
3648 neighbor peer capability dynamic
3649 neighbor 10.1.1.1 remote-as 64515
3650 neighbor 10.1.1.1 peer-group upstream
3651 neighbor 10.2.1.1 remote-as 64516
3652 neighbor 10.2.1.1 peer-group upstream
3653 neighbor 10.3.1.1 remote-as 64517
3654 neighbor 10.3.1.1 peer-group cust-default
3655 neighbor 10.3.1.1 description customer1
3656 neighbor 10.4.1.1 remote-as 64518
3657 neighbor 10.4.1.1 peer-group cust
3658 neighbor 10.4.1.1 description customer2
3659 neighbor 10.5.1.1 remote-as 64519
3660 neighbor 10.5.1.1 peer-group peer
3661 neighbor 10.5.1.1 description peer AS 1
3662 neighbor 10.6.1.1 remote-as 64520
3663 neighbor 10.6.1.1 peer-group peer
3664 neighbor 10.6.1.1 description peer AS 2
3666 address-family ipv4 unicast
3667 network 10.123.456.0/24
3668 network 10.123.456.128/25 route-map rm-no-export
3669 neighbor upstream route-map rm-upstream-out out
3670 neighbor cust route-map rm-cust-in in
3671 neighbor cust route-map rm-cust-out out
3672 neighbor cust send-community both
3673 neighbor peer route-map rm-peer-in in
3674 neighbor peer route-map rm-peer-out out
3675 neighbor peer send-community both
3676 neighbor 10.3.1.1 prefix-list pl-cust1-network in
3677 neighbor 10.4.1.1 prefix-list pl-cust2-network in
3678 neighbor 10.5.1.1 prefix-list pl-peer1-network in
3679 neighbor 10.6.1.1 prefix-list pl-peer2-network in
3682 ip prefix-list pl-default permit 0.0.0.0/0
3684 ip prefix-list pl-upstream-peers permit 10.1.1.1/32
3685 ip prefix-list pl-upstream-peers permit 10.2.1.1/32
3687 ip prefix-list pl-cust1-network permit 10.3.1.0/24
3688 ip prefix-list pl-cust1-network permit 10.3.2.0/24
3690 ip prefix-list pl-cust2-network permit 10.4.1.0/24
3692 ip prefix-list pl-peer1-network permit 10.5.1.0/24
3693 ip prefix-list pl-peer1-network permit 10.5.2.0/24
3694 ip prefix-list pl-peer1-network permit 192.168.0.0/24
3696 ip prefix-list pl-peer2-network permit 10.6.1.0/24
3697 ip prefix-list pl-peer2-network permit 10.6.2.0/24
3698 ip prefix-list pl-peer2-network permit 192.168.1.0/24
3699 ip prefix-list pl-peer2-network permit 192.168.2.0/24
3700 ip prefix-list pl-peer2-network permit 172.16.1/24
3702 bgp as-path access-list seq 5 asp-own-as permit ^$
3703 bgp as-path access-list seq 10 asp-own-as permit _64512_
3705 ! #################################################################
3706 ! Match communities we provide actions for, on routes receives from
3707 ! customers. Communities values of <our-ASN>:X, with X, have actions:
3709 ! 100 - blackhole the prefix
3710 ! 200 - set no_export
3711 ! 300 - advertise only to other customers
3712 ! 400 - advertise only to upstreams
3713 ! 500 - set no_export when advertising to upstreams
3714 ! 2X00 - set local_preference to X00
3716 ! blackhole the prefix of the route
3717 bgp community-list standard cm-blackhole permit 64512:100
3719 ! set no-export community before advertising
3720 bgp community-list standard cm-set-no-export permit 64512:200
3722 ! advertise only to other customers
3723 bgp community-list standard cm-cust-only permit 64512:300
3725 ! advertise only to upstreams
3726 bgp community-list standard cm-upstream-only permit 64512:400
3728 ! advertise to upstreams with no-export
3729 bgp community-list standard cm-upstream-noexport permit 64512:500
3731 ! set local-pref to least significant 3 digits of the community
3732 bgp community-list standard cm-prefmod-100 permit 64512:2100
3733 bgp community-list standard cm-prefmod-200 permit 64512:2200
3734 bgp community-list standard cm-prefmod-300 permit 64512:2300
3735 bgp community-list standard cm-prefmod-400 permit 64512:2400
3736 bgp community-list expanded cme-prefmod-range permit 64512:2...
3738 ! Informational communities
3740 ! 3000 - learned from upstream
3741 ! 3100 - learned from customer
3742 ! 3200 - learned from peer
3744 bgp community-list standard cm-learnt-upstream permit 64512:3000
3745 bgp community-list standard cm-learnt-cust permit 64512:3100
3746 bgp community-list standard cm-learnt-peer permit 64512:3200
3748 ! ###################################################################
3749 ! Utility route-maps
3751 ! These utility route-maps generally should not used to permit/deny
3752 ! routes, i.e. they do not have meaning as filters, and hence probably
3753 ! should be used with 'on-match next'. These all finish with an empty
3754 ! permit entry so as not interfere with processing in the caller.
3756 route-map rm-no-export permit 10
3757 set community additive no-export
3758 route-map rm-no-export permit 20
3760 route-map rm-blackhole permit 10
3761 description blackhole, up-pref and ensure it cannot escape this AS
3762 set ip next-hop 127.0.0.1
3763 set local-preference 10
3764 set community additive no-export
3765 route-map rm-blackhole permit 20
3767 ! Set local-pref as requested
3768 route-map rm-prefmod permit 10
3769 match community cm-prefmod-100
3770 set local-preference 100
3771 route-map rm-prefmod permit 20
3772 match community cm-prefmod-200
3773 set local-preference 200
3774 route-map rm-prefmod permit 30
3775 match community cm-prefmod-300
3776 set local-preference 300
3777 route-map rm-prefmod permit 40
3778 match community cm-prefmod-400
3779 set local-preference 400
3780 route-map rm-prefmod permit 50
3782 ! Community actions to take on receipt of route.
3783 route-map rm-community-in permit 10
3784 description check for blackholing, no point continuing if it matches.
3785 match community cm-blackhole
3787 route-map rm-community-in permit 20
3788 match community cm-set-no-export
3791 route-map rm-community-in permit 30
3792 match community cme-prefmod-range
3794 route-map rm-community-in permit 40
3796 ! #####################################################################
3797 ! Community actions to take when advertising a route.
3798 ! These are filtering route-maps,
3800 ! Deny customer routes to upstream with cust-only set.
3801 route-map rm-community-filt-to-upstream deny 10
3802 match community cm-learnt-cust
3803 match community cm-cust-only
3804 route-map rm-community-filt-to-upstream permit 20
3806 ! Deny customer routes to other customers with upstream-only set.
3807 route-map rm-community-filt-to-cust deny 10
3808 match community cm-learnt-cust
3809 match community cm-upstream-only
3810 route-map rm-community-filt-to-cust permit 20
3812 ! ###################################################################
3813 ! The top-level route-maps applied to sessions. Further entries could
3814 ! be added obviously..
3817 route-map rm-cust-in permit 10
3818 call rm-community-in
3820 route-map rm-cust-in permit 20
3821 set community additive 64512:3100
3822 route-map rm-cust-in permit 30
3824 route-map rm-cust-out permit 10
3825 call rm-community-filt-to-cust
3827 route-map rm-cust-out permit 20
3829 ! Upstream transit ASes
3830 route-map rm-upstream-out permit 10
3831 description filter customer prefixes which are marked cust-only
3832 call rm-community-filt-to-upstream
3834 route-map rm-upstream-out permit 20
3835 description only customer routes are provided to upstreams/peers
3836 match community cm-learnt-cust
3839 ! outbound policy is same as for upstream
3840 route-map rm-peer-out permit 10
3841 call rm-upstream-out
3843 route-map rm-peer-in permit 10
3844 set community additive 64512:3200
3847 Example of how to set up a 6-Bone connection.
3851 ! bgpd configuration
3852 ! ==================
3854 ! MP-BGP configuration
3857 bgp router-id 10.0.0.1
3858 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as `as-number`
3861 network 3ffe:506::/32
3862 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
3863 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
3864 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as `as-number`
3865 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
3868 ipv6 access-list all permit any
3870 ! Set output nexthop address.
3872 route-map set-nexthop permit 10
3873 match ipv6 address all
3874 set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
3875 set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
3881 .. include:: routeserver.rst
3883 .. include:: rpki.rst
3885 .. include:: wecmp_linkbw.rst
3887 .. include:: flowspec.rst
3889 .. [#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)
3890 .. [bgp-route-osci-cond] McPherson, D. and Gill, V. and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", IETF RFC3345
3891 .. [stable-flexible-ibgp] Flavel, A. and M. Roughan, "Stable and flexible iBGP", ACM SIGCOMM 2009
3892 .. [ibgp-correctness] Griffin, T. and G. Wilfong, "On the correctness of IBGP configuration", ACM SIGCOMM 2002