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.
404 .. clicmd:: maximum-paths (1-128)
406 Sets the maximum-paths value used for ecmp calculations for this
407 bgp instance in EBGP. The maximum value listed, 128, can be limited by
408 the ecmp cli for bgp or if the daemon was compiled with a lower
409 ecmp value. This value can also be set in ipv4/ipv6 unicast/labeled
410 unicast to only affect those particular afi/safi's.
412 .. clicmd:: maximum-paths ibgp (1-128) [equal-cluster-length]
414 Sets the maximum-paths value used for ecmp calculations for this
415 bgp instance in IBGP. The maximum value listed, 128, can be limited by
416 the ecmp cli for bgp or if the daemon was compiled with a lower
417 ecmp value. This value can also be set in ipv4/ipv6 unicast/labeled
418 unicast to only affect those particular afi/safi's.
422 Administrative Distance Metrics
423 -------------------------------
425 .. clicmd:: distance bgp (1-255) (1-255) (1-255)
427 This command changes distance value of BGP. The arguments are the distance
428 values for external routes, internal routes and local routes
431 .. clicmd:: distance (1-255) A.B.C.D/M
433 .. clicmd:: distance (1-255) A.B.C.D/M WORD
435 Sets the administrative distance for a particular route.
437 .. _bgp-requires-policy:
439 Require policy on EBGP
440 -------------------------------
442 .. clicmd:: bgp ebgp-requires-policy
444 This command requires incoming and outgoing filters to be applied
445 for eBGP sessions as part of RFC-8212 compliance. Without the incoming
446 filter, no routes will be accepted. Without the outgoing filter, no
447 routes will be announced.
449 This is enabled by default for the traditional configuration and
450 turned off by default for datacenter configuration.
452 When you enable/disable this option you MUST clear the session.
454 When the incoming or outgoing filter is missing you will see
455 "(Policy)" sign under ``show bgp summary``:
459 exit1# show bgp summary
461 IPv4 Unicast Summary (VRF default):
462 BGP router identifier 10.10.10.1, local AS number 65001 vrf-id 0
464 RIB entries 7, using 1344 bytes of memory
465 Peers 2, using 43 KiB of memory
467 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
468 192.168.0.2 4 65002 8 10 0 0 0 00:03:09 5 (Policy) N/A
469 fe80:1::2222 4 65002 9 11 0 0 0 00:03:09 (Policy) (Policy) N/A
471 Additionally a `show bgp neighbor` command would indicate in the `For address family:`
476 exit1# show bgp neighbor
478 For address family: IPv4 Unicast
479 Update group 1, subgroup 1
480 Packet Queue length 0
481 Inbound soft reconfiguration allowed
482 Community attribute sent to this neighbor(all)
483 Inbound updates discarded due to missing policy
484 Outbound updates discarded due to missing policy
487 Reject routes with AS_SET or AS_CONFED_SET types
488 ------------------------------------------------
490 .. clicmd:: bgp reject-as-sets
492 This command enables rejection of incoming and outgoing routes having AS_SET or AS_CONFED_SET type.
494 Suppress duplicate updates
495 --------------------------
497 .. clicmd:: bgp suppress-duplicates
499 For example, BGP routers can generate multiple identical announcements with
500 empty community attributes if stripped at egress. This is an undesired behavior.
501 Suppress duplicate updates if the route actually not changed.
504 Disable checking if nexthop is connected on EBGP sessions
505 ---------------------------------------------------------
507 .. clicmd:: bgp disable-ebgp-connected-route-check
509 This command is used to disable the connection verification process for EBGP peering sessions
510 that are reachable by a single hop but are configured on a loopback interface or otherwise
511 configured with a non-directly connected IP address.
513 .. _bgp-route-flap-dampening:
518 .. clicmd:: bgp dampening (1-45) (1-20000) (1-20000) (1-255)
520 This command enables BGP route-flap dampening and specifies dampening parameters.
523 Half-life time for the penalty
526 Value to start reusing a route
529 Value to start suppressing a route
532 Maximum duration to suppress a stable route
534 The route-flap damping algorithm is compatible with :rfc:`2439`. The use of
535 this command is not recommended nowadays.
537 At the moment, route-flap dampening is not working per VRF and is working only
538 for IPv4 unicast and multicast.
541 https://www.ripe.net/publications/docs/ripe-378
545 Multi-Exit Discriminator
546 ------------------------
548 The BGP :abbr:`MED (Multi-Exit Discriminator)` attribute has properties which
549 can cause subtle convergence problems in BGP. These properties and problems
550 have proven to be hard to understand, at least historically, and may still not
551 be widely understood. The following attempts to collect together and present
552 what is known about MED, to help operators and FRR users in designing and
553 configuring their networks.
555 The BGP :abbr:`MED` attribute is intended to allow one AS to indicate its
556 preferences for its ingress points to another AS. The MED attribute will not be
557 propagated on to another AS by the receiving AS - it is 'non-transitive' in the
560 E.g., if AS X and AS Y have 2 different BGP peering points, then AS X might set
561 a MED of 100 on routes advertised at one and a MED of 200 at the other. When AS
562 Y selects between otherwise equal routes to or via AS X, AS Y should prefer to
563 take the path via the lower MED peering of 100 with AS X. Setting the MED
564 allows an AS to influence the routing taken to it within another, neighbouring
567 In this use of MED it is not really meaningful to compare the MED value on
568 routes where the next AS on the paths differs. E.g., if AS Y also had a route
569 for some destination via AS Z in addition to the routes from AS X, and AS Z had
570 also set a MED, it wouldn't make sense for AS Y to compare AS Z's MED values to
571 those of AS X. The MED values have been set by different administrators, with
572 different frames of reference.
574 The default behaviour of BGP therefore is to not compare MED values across
575 routes received from different neighbouring ASes. In FRR this is done by
576 comparing the neighbouring, left-most AS in the received AS_PATHs of the routes
577 and only comparing MED if those are the same.
579 Unfortunately, this behaviour of MED, of sometimes being compared across routes
580 and sometimes not, depending on the properties of those other routes, means MED
581 can cause the order of preference over all the routes to be undefined. That is,
582 given routes A, B, and C, if A is preferred to B, and B is preferred to C, then
583 a well-defined order should mean the preference is transitive (in the sense of
584 orders [#med-transitivity-rant]_) and that A would be preferred to C.
586 However, when MED is involved this need not be the case. With MED it is
587 possible that C is actually preferred over A. So A is preferred to B, B is
588 preferred to C, but C is preferred to A. This can be true even where BGP
589 defines a deterministic 'most preferred' route out of the full set of A,B,C.
590 With MED, for any given set of routes there may be a deterministically
591 preferred route, but there need not be any way to arrange them into any order
592 of preference. With unmodified MED, the order of preference of routes literally
595 That MED can induce non-transitive preferences over routes can cause issues.
596 Firstly, it may be perceived to cause routing table churn locally at speakers;
597 secondly, and more seriously, it may cause routing instability in iBGP
598 topologies, where sets of speakers continually oscillate between different
601 The first issue arises from how speakers often implement routing decisions.
602 Though BGP defines a selection process that will deterministically select the
603 same route as best at any given speaker, even with MED, that process requires
604 evaluating all routes together. For performance and ease of implementation
605 reasons, many implementations evaluate route preferences in a pair-wise fashion
606 instead. Given there is no well-defined order when MED is involved, the best
607 route that will be chosen becomes subject to implementation details, such as
608 the order the routes are stored in. That may be (locally) non-deterministic,
609 e.g.: it may be the order the routes were received in.
611 This indeterminism may be considered undesirable, though it need not cause
612 problems. It may mean additional routing churn is perceived, as sometimes more
613 updates may be produced than at other times in reaction to some event .
615 This first issue can be fixed with a more deterministic route selection that
616 ensures routes are ordered by the neighbouring AS during selection.
617 :clicmd:`bgp deterministic-med`. This may reduce the number of updates as routes
618 are received, and may in some cases reduce routing churn. Though, it could
619 equally deterministically produce the largest possible set of updates in
620 response to the most common sequence of received updates.
622 A deterministic order of evaluation tends to imply an additional overhead of
623 sorting over any set of n routes to a destination. The implementation of
624 deterministic MED in FRR scales significantly worse than most sorting
625 algorithms at present, with the number of paths to a given destination. That
626 number is often low enough to not cause any issues, but where there are many
627 paths, the deterministic comparison may quickly become increasingly expensive
630 Deterministic local evaluation can *not* fix the second, more major, issue of
631 MED however. Which is that the non-transitive preference of routes MED can
632 cause may lead to routing instability or oscillation across multiple speakers
633 in iBGP topologies. This can occur with full-mesh iBGP, but is particularly
634 problematic in non-full-mesh iBGP topologies that further reduce the routing
635 information known to each speaker. This has primarily been documented with iBGP
636 :ref:`route-reflection <bgp-route-reflector>` topologies. However, any
637 route-hiding technologies potentially could also exacerbate oscillation with MED.
639 This second issue occurs where speakers each have only a subset of routes, and
640 there are cycles in the preferences between different combinations of routes -
641 as the undefined order of preference of MED allows - and the routes are
642 distributed in a way that causes the BGP speakers to 'chase' those cycles. This
643 can occur even if all speakers use a deterministic order of evaluation in route
646 E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X, and from
647 speaker 3 in AS Y; while speaker 5 in AS A might receive that route from
648 speaker 1 in AS Y. AS Y might set a MED of 200 at speaker 1, and 100 at speaker
649 3. I.e, using ASN:ID:MED to label the speakers:
655 X:2------|--A:4-------A:5--|-Y:1:200
661 Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs), then based
662 on the RFC4271 decision process speaker 4 will choose X:2 over Y:3:100, based
663 on the lower ID of 2. Speaker 4 advertises X:2 to speaker 5. Speaker 5 will
664 continue to prefer Y:1:200 based on the ID, and advertise this to speaker 4.
665 Speaker 4 will now have the full set of routes, and the Y:1:200 it receives
666 from 5 will beat X:2, but when speaker 4 compares Y:1:200 to Y:3:100 the MED
667 check now becomes active as the ASes match, and now Y:3:100 is preferred.
668 Speaker 4 therefore now advertises Y:3:100 to 5, which will also agrees that
669 Y:3:100 is preferred to Y:1:200, and so withdraws the latter route from 4.
670 Speaker 4 now has only X:2 and Y:3:100, and X:2 beats Y:3:100, and so speaker 4
671 implicitly updates its route to speaker 5 to X:2. Speaker 5 sees that Y:1:200
672 beats X:2 based on the ID, and advertises Y:1:200 to speaker 4, and the cycle
675 The root cause is the lack of a clear order of preference caused by how MED
676 sometimes is and sometimes is not compared, leading to this cycle in the
677 preferences between the routes:
682 /---> X:2 ---beats---> Y:3:100 --\\
685 \\---beats--- Y:1:200 <---beats---/
689 This particular type of oscillation in full-mesh iBGP topologies can be
690 avoided by speakers preferring already selected, external routes rather than
691 choosing to update to new a route based on a post-MED metric (e.g. router-ID),
692 at the cost of a non-deterministic selection process. FRR implements this, as
693 do many other implementations, so long as it is not overridden by setting
694 :clicmd:`bgp bestpath compare-routerid`, and see also
695 :ref:`bgp-route-selection`.
697 However, more complex and insidious cycles of oscillation are possible with
698 iBGP route-reflection, which are not so easily avoided. These have been
699 documented in various places. See, e.g.:
701 - [bgp-route-osci-cond]_
702 - [stable-flexible-ibgp]_
703 - [ibgp-correctness]_
705 for concrete examples and further references.
707 There is as of this writing *no* known way to use MED for its original purpose;
708 *and* reduce routing information in iBGP topologies; *and* be sure to avoid the
709 instability problems of MED due the non-transitive routing preferences it can
710 induce; in general on arbitrary networks.
712 There may be iBGP topology specific ways to reduce the instability risks, even
713 while using MED, e.g.: by constraining the reflection topology and by tuning
714 IGP costs between route-reflector clusters, see :rfc:`3345` for details. In the
715 near future, the Add-Path extension to BGP may also solve MED oscillation while
716 still allowing MED to be used as intended, by distributing "best-paths per
717 neighbour AS". This would be at the cost of distributing at least as many
718 routes to all speakers as a full-mesh iBGP would, if not more, while also
719 imposing similar CPU overheads as the "Deterministic MED" feature at each
722 More generally, the instability problems that MED can introduce on more
723 complex, non-full-mesh, iBGP topologies may be avoided either by:
725 - Setting :clicmd:`bgp always-compare-med`, however this allows MED to be compared
726 across values set by different neighbour ASes, which may not produce
727 coherent desirable results, of itself.
728 - Effectively ignoring MED by setting MED to the same value (e.g.: 0) using
729 :clicmd:`set metric METRIC` on all received routes, in combination with
730 setting :clicmd:`bgp always-compare-med` on all speakers. This is the simplest
731 and most performant way to avoid MED oscillation issues, where an AS is happy
732 not to allow neighbours to inject this problematic metric.
734 As MED is evaluated after the AS_PATH length check, another possible use for
735 MED is for intra-AS steering of routes with equal AS_PATH length, as an
736 extension of the last case above. As MED is evaluated before IGP metric, this
737 can allow cold-potato routing to be implemented to send traffic to preferred
738 hand-offs with neighbours, rather than the closest hand-off according to the
741 Note that even if action is taken to address the MED non-transitivity issues,
742 other oscillations may still be possible. E.g., on IGP cost if iBGP and IGP
743 topologies are at cross-purposes with each other - see the Flavel and Roughan
744 paper above for an example. Hence the guideline that the iBGP topology should
745 follow the IGP topology.
747 .. clicmd:: bgp deterministic-med
749 Carry out route-selection in way that produces deterministic answers
750 locally, even in the face of MED and the lack of a well-defined order of
751 preference it can induce on routes. Without this option the preferred route
752 with MED may be determined largely by the order that routes were received
755 Setting this option will have a performance cost that may be noticeable when
756 there are many routes for each destination. Currently in FRR it is
757 implemented in a way that scales poorly as the number of routes per
758 destination increases.
760 The default is that this option is not set.
762 Note that there are other sources of indeterminism in the route selection
763 process, specifically, the preference for older and already selected routes
764 from eBGP peers, :ref:`bgp-route-selection`.
766 .. clicmd:: bgp always-compare-med
768 Always compare the MED on routes, even when they were received from
769 different neighbouring ASes. Setting this option makes the order of
770 preference of routes more defined, and should eliminate MED induced
773 If using this option, it may also be desirable to use
774 :clicmd:`set metric METRIC` to set MED to 0 on routes received from external
777 This option can be used, together with :clicmd:`set metric METRIC` to use
778 MED as an intra-AS metric to steer equal-length AS_PATH routes to, e.g.,
782 .. _bgp-graceful-restart:
787 BGP graceful restart functionality as defined in
788 `RFC-4724 <https://tools.ietf.org/html/rfc4724/>`_ defines the mechanisms that
789 allows BGP speaker to continue to forward data packets along known routes
790 while the routing protocol information is being restored.
793 Usually, when BGP on a router restarts, all the BGP peers detect that the
794 session went down and then came up. This "down/up" transition results in a
795 "routing flap" and causes BGP route re-computation, generation of BGP routing
796 updates, and unnecessary churn to the forwarding tables.
798 The following functionality is provided by graceful restart:
800 1. The feature allows the restarting router to indicate to the helping peer the
801 routes it can preserve in its forwarding plane during control plane restart
802 by sending graceful restart capability in the OPEN message sent during
803 session establishment.
804 2. The feature allows helping router to advertise to all other peers the routes
805 received from the restarting router which are preserved in the forwarding
806 plane of the restarting router during control plane restart.
813 (R1)-----------------------------------------------------------------(R2)
815 1. BGP Graceful Restart Capability exchanged between R1 & R2.
817 <--------------------------------------------------------------------->
819 2. Kill BGP Process at R1.
821 ---------------------------------------------------------------------->
823 3. R2 Detects the above BGP Restart & verifies BGP Restarting
826 4. Start BGP Process at R1.
828 5. Re-establish the BGP session between R1 & R2.
830 <--------------------------------------------------------------------->
832 6. R2 Send initial route updates, followed by End-Of-Rib.
834 <----------------------------------------------------------------------
836 7. R1 was waiting for End-Of-Rib from R2 & which has been received
839 8. R1 now runs BGP Best-Path algorithm. Send Initial BGP Update,
840 followed by End-Of Rib
842 <--------------------------------------------------------------------->
845 .. _bgp-GR-preserve-forwarding-state:
847 BGP-GR Preserve-Forwarding State
848 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
850 BGP OPEN message carrying optional capabilities for Graceful Restart has
851 8 bit “Flags for Address Family” for given AFI and SAFI. This field contains
852 bit flags relating to routes that were advertised with the given AFI and SAFI.
861 The most significant bit is defined as the Forwarding State (F) bit, which
862 can be used to indicate whether the forwarding state for routes that were
863 advertised with the given AFI and SAFI has indeed been preserved during the
864 previous BGP restart. When set (value 1), the bit indicates that the
865 forwarding state has been preserved.
866 The remaining bits are reserved and MUST be set to zero by the sender and
867 ignored by the receiver.
869 .. clicmd:: bgp graceful-restart preserve-fw-state
871 FRR gives us the option to enable/disable the "F" flag using this specific
872 vty command. However, it doesn't have the option to enable/disable
873 this flag only for specific AFI/SAFI i.e. when this command is used, it
874 applied to all the supported AFI/SAFI combinations for this peer.
876 .. _bgp-end-of-rib-message:
878 End-of-RIB (EOR) message
879 ^^^^^^^^^^^^^^^^^^^^^^^^
881 An UPDATE message with no reachable Network Layer Reachability Information
882 (NLRI) and empty withdrawn NLRI is specified as the End-of-RIB marker that can
883 be used by a BGP speaker to indicate to its peer the completion of the initial
884 routing update after the session is established.
886 For the IPv4 unicast address family, the End-of-RIB marker is an UPDATE message
887 with the minimum length. For any other address family, it is an UPDATE message
888 that contains only the MP_UNREACH_NLRI attribute with no withdrawn routes for
891 Although the End-of-RIB marker is specified for the purpose of BGP graceful
892 restart, it is noted that the generation of such a marker upon completion of
893 the initial update would be useful for routing convergence in general, and thus
894 the practice is recommended.
896 .. _bgp-route-selection-deferral-timer:
898 Route Selection Deferral Timer
899 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
901 Specifies the time the restarting router defers the route selection process
904 Restarting Router : The usage of route election deferral timer is specified
905 in https://tools.ietf.org/html/rfc4724#section-4.1
907 Once the session between the Restarting Speaker and the Receiving Speaker is
908 re-established, the Restarting Speaker will receive and process BGP messages
911 However, it MUST defer route selection for an address family until it either.
913 1. Receives the End-of-RIB marker from all its peers (excluding the ones with
914 the "Restart State" bit set in the received capability and excluding the ones
915 that do not advertise the graceful restart capability).
916 2. The Selection_Deferral_Timer timeout.
918 .. clicmd:: bgp graceful-restart select-defer-time (0-3600)
920 This is command, will set deferral time to value specified.
923 .. clicmd:: bgp graceful-restart rib-stale-time (1-3600)
925 This is command, will set the time for which stale routes are kept in RIB.
927 .. clicmd:: bgp graceful-restart stalepath-time (1-4095)
929 This is command, will set the max time (in seconds) to hold onto
930 restarting peer's stale paths.
932 It also controls Enhanced Route-Refresh timer.
934 If this command is configured and the router does not receive a Route-Refresh EoRR
935 message, the router removes the stale routes from the BGP table after the timer
936 expires. The stale path timer is started when the router receives a Route-Refresh
939 .. _bgp-per-peer-graceful-restart:
941 BGP Per Peer Graceful Restart
942 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
944 Ability to enable and disable graceful restart, helper and no GR at all mode
945 functionality at peer level.
947 So bgp graceful restart can be enabled at modes global BGP level or at per
948 peer level. There are two FSM, one for BGP GR global mode and other for peer
951 Default global mode is helper and default peer per mode is inherit from global.
952 If per peer mode is configured, the GR mode of this particular peer will
953 override the global mode.
955 .. _bgp-GR-global-mode-cmd:
957 BGP GR Global Mode Commands
958 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
960 .. clicmd:: bgp graceful-restart
962 This command will enable BGP graceful restart functionality at the global
965 .. clicmd:: bgp graceful-restart disable
967 This command will disable both the functionality graceful restart and helper
971 .. _bgp-GR-peer-mode-cmd:
973 BGP GR Peer Mode Commands
974 ^^^^^^^^^^^^^^^^^^^^^^^^^
976 .. clicmd:: neighbor A.B.C.D graceful-restart
978 This command will enable BGP graceful restart functionality at the peer
981 .. clicmd:: neighbor A.B.C.D graceful-restart-helper
983 This command will enable BGP graceful restart helper only functionality
986 .. clicmd:: neighbor A.B.C.D graceful-restart-disable
988 This command will disable the entire BGP graceful restart functionality
992 Long-lived Graceful Restart
993 ---------------------------
995 Currently, only restarter mode is supported. This capability is advertised only
996 if graceful restart capability is negotiated.
998 .. clicmd:: bgp long-lived-graceful-restart stale-time (1-4294967295)
1000 Specifies the maximum time to wait before purging long-lived stale routes for
1003 Default is 0, which means the feature is off by default. Only graceful
1004 restart takes into account.
1008 Administrative Shutdown
1009 -----------------------
1011 .. clicmd:: bgp shutdown [message MSG...]
1013 Administrative shutdown of all peers of a bgp instance. Drop all BGP peers,
1014 but preserve their configurations. The peers are notified in accordance with
1015 `RFC 8203 <https://tools.ietf.org/html/rfc8203/>`_ by sending a
1016 ``NOTIFICATION`` message with error code ``Cease`` and subcode
1017 ``Administrative Shutdown`` prior to terminating connections. This global
1018 shutdown is independent of the neighbor shutdown, meaning that individually
1019 shut down peers will not be affected by lifting it.
1021 An optional shutdown message `MSG` can be specified.
1029 .. clicmd:: network A.B.C.D/M
1031 This command adds the announcement network.
1036 address-family ipv4 unicast
1040 This configuration example says that network 10.0.0.0/8 will be
1041 announced to all neighbors. Some vendors' routers don't advertise
1042 routes if they aren't present in their IGP routing tables; `bgpd`
1043 doesn't care about IGP routes when announcing its routes.
1046 .. clicmd:: bgp network import-check
1048 This configuration modifies the behavior of the network statement.
1049 If you have this configured the underlying network must exist in
1050 the rib. If you have the [no] form configured then BGP will not
1051 check for the networks existence in the rib. For versions 7.3 and
1052 before frr defaults for datacenter were the network must exist,
1053 traditional did not check for existence. For versions 7.4 and beyond
1054 both traditional and datacenter the network must exist.
1056 .. _bgp-ipv6-support:
1061 .. clicmd:: neighbor A.B.C.D activate
1063 This configuration modifies whether to enable an address family for a
1064 specific neighbor. By default only the IPv4 unicast address family is
1070 address-family ipv6 unicast
1071 neighbor 2001:0DB8::1 activate
1072 network 2001:0DB8:5009::/64
1075 This configuration example says that network 2001:0DB8:5009::/64 will be
1076 announced and enables the neighbor 2001:0DB8::1 to receive this announcement.
1078 By default, only the IPv4 unicast address family is announced to all
1079 neighbors. Using the 'no bgp default ipv4-unicast' configuration overrides
1080 this default so that all address families need to be enabled explicitly.
1085 no bgp default ipv4-unicast
1086 neighbor 10.10.10.1 remote-as 2
1087 neighbor 2001:0DB8::1 remote-as 3
1088 address-family ipv4 unicast
1089 neighbor 10.10.10.1 activate
1090 network 192.168.1.0/24
1092 address-family ipv6 unicast
1093 neighbor 2001:0DB8::1 activate
1094 network 2001:0DB8:5009::/64
1097 This configuration demonstrates how the 'no bgp default ipv4-unicast' might
1098 be used in a setup with two upstreams where each of the upstreams should only
1099 receive either IPv4 or IPv6 announcements.
1101 Using the ``bgp default ipv6-unicast`` configuration, IPv6 unicast
1102 address family is enabled by default for all new neighbors.
1105 .. _bgp-route-aggregation:
1110 .. _bgp-route-aggregation-ipv4:
1112 Route Aggregation-IPv4 Address Family
1113 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1115 .. clicmd:: aggregate-address A.B.C.D/M
1117 This command specifies an aggregate address.
1119 In order to advertise an aggregated prefix, a more specific (longer) prefix
1120 MUST exist in the BGP table. For example, if you want to create an
1121 ``aggregate-address 10.0.0.0/24``, you should make sure you have something
1122 like ``10.0.0.5/32`` or ``10.0.0.0/26``, or any other smaller prefix in the
1123 BGP table. The routing information table (RIB) is not enough, you have to
1124 redistribute them into the BGP table.
1126 .. clicmd:: aggregate-address A.B.C.D/M route-map NAME
1128 Apply a route-map for an aggregated prefix.
1130 .. clicmd:: aggregate-address A.B.C.D/M origin <egp|igp|incomplete>
1132 Override ORIGIN for an aggregated prefix.
1134 .. clicmd:: aggregate-address A.B.C.D/M as-set
1136 This command specifies an aggregate address. Resulting routes include
1139 .. clicmd:: aggregate-address A.B.C.D/M summary-only
1141 This command specifies an aggregate address.
1143 Longer prefixes advertisements of more specific routes to all neighbors are suppressed.
1145 .. clicmd:: aggregate-address A.B.C.D/M matching-MED-only
1147 Configure the aggregated address to only be created when the routes MED
1148 match, otherwise no aggregated route will be created.
1150 .. clicmd:: aggregate-address A.B.C.D/M suppress-map NAME
1152 Similar to `summary-only`, but will only suppress more specific routes that
1153 are matched by the selected route-map.
1156 This configuration example sets up an ``aggregate-address`` under the ipv4
1162 address-family ipv4 unicast
1163 aggregate-address 10.0.0.0/8
1164 aggregate-address 20.0.0.0/8 as-set
1165 aggregate-address 40.0.0.0/8 summary-only
1166 aggregate-address 50.0.0.0/8 route-map aggr-rmap
1170 .. _bgp-route-aggregation-ipv6:
1172 Route Aggregation-IPv6 Address Family
1173 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1175 .. clicmd:: aggregate-address X:X::X:X/M
1177 This command specifies an aggregate address.
1179 .. clicmd:: aggregate-address X:X::X:X/M route-map NAME
1181 Apply a route-map for an aggregated prefix.
1183 .. clicmd:: aggregate-address X:X::X:X/M origin <egp|igp|incomplete>
1185 Override ORIGIN for an aggregated prefix.
1187 .. clicmd:: aggregate-address X:X::X:X/M as-set
1189 This command specifies an aggregate address. Resulting routes include
1192 .. clicmd:: aggregate-address X:X::X:X/M summary-only
1194 This command specifies an aggregate address.
1196 Longer prefixes advertisements of more specific routes to all neighbors are suppressed
1198 .. clicmd:: aggregate-address X:X::X:X/M matching-MED-only
1200 Configure the aggregated address to only be created when the routes MED
1201 match, otherwise no aggregated route will be created.
1203 .. clicmd:: aggregate-address X:X::X:X/M suppress-map NAME
1205 Similar to `summary-only`, but will only suppress more specific routes that
1206 are matched by the selected route-map.
1209 This configuration example sets up an ``aggregate-address`` under the ipv6
1215 address-family ipv6 unicast
1216 aggregate-address 10::0/64
1217 aggregate-address 20::0/64 as-set
1218 aggregate-address 40::0/64 summary-only
1219 aggregate-address 50::0/64 route-map aggr-rmap
1223 .. _bgp-redistribute-to-bgp:
1228 Redistribution configuration should be placed under the ``address-family``
1229 section for the specific AF to redistribute into. Protocol availability for
1230 redistribution is determined by BGP AF; for example, you cannot redistribute
1231 OSPFv3 into ``address-family ipv4 unicast`` as OSPFv3 supports IPv6.
1233 .. clicmd:: redistribute <babel|connected|eigrp|isis|kernel|openfabric|ospf|ospf6|rip|ripng|sharp|static|table> [metric (0-4294967295)] [route-map WORD]
1235 Redistribute routes from other protocols into BGP.
1237 .. clicmd:: redistribute vnc-direct
1239 Redistribute VNC direct (not via zebra) routes to BGP process.
1241 .. clicmd:: bgp update-delay MAX-DELAY
1243 .. clicmd:: bgp update-delay MAX-DELAY ESTABLISH-WAIT
1245 This feature is used to enable read-only mode on BGP process restart or when
1246 a BGP process is cleared using 'clear ip bgp \*'. Note that this command is
1247 configured at the global level and applies to all bgp instances/vrfs. It
1248 cannot be used at the same time as the "update-delay" command described below,
1249 which is entered in each bgp instance/vrf desired to delay update installation
1250 and advertisements. The global and per-vrf approaches to defining update-delay
1251 are mutually exclusive.
1253 When applicable, read-only mode would begin as soon as the first peer reaches
1254 Established status and a timer for max-delay seconds is started. During this
1255 mode BGP doesn't run any best-path or generate any updates to its peers. This
1256 mode continues until:
1258 1. All the configured peers, except the shutdown peers, have sent explicit EOR
1259 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
1260 Established is considered an implicit-EOR.
1261 If the establish-wait optional value is given, then BGP will wait for
1262 peers to reach established from the beginning of the update-delay till the
1263 establish-wait period is over, i.e. the minimum set of established peers for
1264 which EOR is expected would be peers established during the establish-wait
1265 window, not necessarily all the configured neighbors.
1266 2. max-delay period is over.
1268 On hitting any of the above two conditions, BGP resumes the decision process
1269 and generates updates to its peers.
1271 Default max-delay is 0, i.e. the feature is off by default.
1274 .. clicmd:: update-delay MAX-DELAY
1276 .. clicmd:: update-delay MAX-DELAY ESTABLISH-WAIT
1278 This feature is used to enable read-only mode on BGP process restart or when
1279 a BGP process is cleared using 'clear ip bgp \*'. Note that this command is
1280 configured under the specific bgp instance/vrf that the feature is enabled for.
1281 It cannot be used at the same time as the global "bgp update-delay" described
1282 above, which is entered at the global level and applies to all bgp instances.
1283 The global and per-vrf approaches to defining update-delay are mutually
1286 When applicable, read-only mode would begin as soon as the first peer reaches
1287 Established status and a timer for max-delay seconds is started. During this
1288 mode BGP doesn't run any best-path or generate any updates to its peers. This
1289 mode continues until:
1291 1. All the configured peers, except the shutdown peers, have sent explicit EOR
1292 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
1293 Established is considered an implicit-EOR.
1294 If the establish-wait optional value is given, then BGP will wait for
1295 peers to reach established from the beginning of the update-delay till the
1296 establish-wait period is over, i.e. the minimum set of established peers for
1297 which EOR is expected would be peers established during the establish-wait
1298 window, not necessarily all the configured neighbors.
1299 2. max-delay period is over.
1301 On hitting any of the above two conditions, BGP resumes the decision process
1302 and generates updates to its peers.
1304 Default max-delay is 0, i.e. the feature is off by default.
1306 .. clicmd:: table-map ROUTE-MAP-NAME
1308 This feature is used to apply a route-map on route updates from BGP to
1309 Zebra. All the applicable match operations are allowed, such as match on
1310 prefix, next-hop, communities, etc. Set operations for this attach-point are
1311 limited to metric and next-hop only. Any operation of this feature does not
1312 affect BGPs internal RIB.
1314 Supported for ipv4 and ipv6 address families. It works on multi-paths as
1315 well, however, metric setting is based on the best-path only.
1322 .. _bgp-defining-peers:
1327 .. clicmd:: neighbor PEER remote-as ASN
1329 Creates a new neighbor whose remote-as is ASN. PEER can be an IPv4 address
1330 or an IPv6 address or an interface to use for the connection.
1335 neighbor 10.0.0.1 remote-as 2
1337 In this case my router, in AS-1, is trying to peer with AS-2 at 10.0.0.1.
1339 This command must be the first command used when configuring a neighbor. If
1340 the remote-as is not specified, *bgpd* will complain like this: ::
1342 can't find neighbor 10.0.0.1
1344 .. clicmd:: neighbor PEER remote-as internal
1346 Create a peer as you would when you specify an ASN, except that if the
1347 peers ASN is different than mine as specified under the :clicmd:`router bgp ASN`
1348 command the connection will be denied.
1350 .. clicmd:: neighbor PEER remote-as external
1352 Create a peer as you would when you specify an ASN, except that if the
1353 peers ASN is the same as mine as specified under the :clicmd:`router bgp ASN`
1354 command the connection will be denied.
1356 .. clicmd:: bgp listen range <A.B.C.D/M|X:X::X:X/M> peer-group PGNAME
1358 Accept connections from any peers in the specified prefix. Configuration
1359 from the specified peer-group is used to configure these peers.
1363 When using BGP listen ranges, if the associated peer group has TCP MD5
1364 authentication configured, your kernel must support this on prefixes. On
1365 Linux, this support was added in kernel version 4.14. If your kernel does
1366 not support this feature you will get a warning in the log file, and the
1367 listen range will only accept connections from peers without MD5 configured.
1369 Additionally, we have observed that when using this option at scale (several
1370 hundred peers) the kernel may hit its option memory limit. In this situation
1371 you will see error messages like:
1373 ``bgpd: sockopt_tcp_signature: setsockopt(23): Cannot allocate memory``
1375 In this case you need to increase the value of the sysctl
1376 ``net.core.optmem_max`` to allow the kernel to allocate the necessary option
1379 .. clicmd:: bgp listen limit <1-65535>
1381 Define the maximum number of peers accepted for one BGP instance. This
1382 limit is set to 100 by default. Increasing this value will really be
1383 possible if more file descriptors are available in the BGP process. This
1384 value is defined by the underlying system (ulimit value), and can be
1385 overridden by `--limit-fds`. More information is available in chapter
1386 (:ref:`common-invocation-options`).
1388 .. clicmd:: coalesce-time (0-4294967295)
1390 The time in milliseconds that BGP will delay before deciding what peers
1391 can be put into an update-group together in order to generate a single
1392 update for them. The default time is 1000.
1394 .. _bgp-configuring-peers:
1399 .. clicmd:: neighbor PEER shutdown [message MSG...] [rtt (1-65535) [count (1-255)]]
1401 Shutdown the peer. We can delete the neighbor's configuration by
1402 ``no neighbor PEER remote-as ASN`` but all configuration of the neighbor
1403 will be deleted. When you want to preserve the configuration, but want to
1404 drop the BGP peer, use this syntax.
1406 Optionally you can specify a shutdown message `MSG`.
1408 Also, you can specify optionally ``rtt`` in milliseconds to automatically
1409 shutdown the peer if round-trip-time becomes higher than defined.
1411 Additional ``count`` parameter is the number of keepalive messages to count
1412 before shutdown the peer if round-trip-time becomes higher than defined.
1414 .. clicmd:: neighbor PEER disable-connected-check
1416 Allow peerings between directly connected eBGP peers using loopback
1419 .. clicmd:: neighbor PEER disable-link-bw-encoding-ieee
1421 By default bandwidth in extended communities is carried encoded as IEEE
1422 floating-point format, which is according to the draft.
1424 Older versions have the implementation where extended community bandwidth
1425 value is carried encoded as uint32. To enable backward compatibility we
1426 need to disable IEEE floating-point encoding option per-peer.
1428 .. clicmd:: neighbor PEER extended-optional-parameters
1430 Force Extended Optional Parameters Length format to be used for OPEN messages.
1432 By default, it's disabled. If the standard optional parameters length is
1433 higher than one-octet (255), then extended format is enabled automatically.
1435 For testing purposes, extended format can be enabled with this command.
1437 .. clicmd:: neighbor PEER ebgp-multihop
1439 Specifying ``ebgp-multihop`` allows sessions with eBGP neighbors to
1440 establish when they are multiple hops away. When the neighbor is not
1441 directly connected and this knob is not enabled, the session will not
1444 If the peer's IP address is not in the RIB and is reachable via the
1445 default route, then you have to enable ``ip nht resolve-via-default``.
1447 .. clicmd:: neighbor PEER description ...
1449 Set description of the peer.
1451 .. clicmd:: neighbor PEER interface IFNAME
1453 When you connect to a BGP peer over an IPv6 link-local address, you have to
1454 specify the IFNAME of the interface used for the connection. To specify
1455 IPv4 session addresses, see the ``neighbor PEER update-source`` command
1458 .. clicmd:: neighbor PEER interface remote-as <internal|external|ASN>
1460 Configure an unnumbered BGP peer. ``PEER`` should be an interface name. The
1461 session will be established via IPv6 link locals. Use ``internal`` for iBGP
1462 and ``external`` for eBGP sessions, or specify an ASN if you wish.
1464 .. clicmd:: neighbor PEER next-hop-self [force]
1466 This command specifies an announced route's nexthop as being equivalent to
1467 the address of the bgp router if it is learned via eBGP. This will also
1468 bypass third-party next-hops in favor of the local bgp address. If the
1469 optional keyword ``force`` is specified the modification is done also for
1470 routes learned via iBGP.
1472 .. clicmd:: neighbor PEER attribute-unchanged [{as-path|next-hop|med}]
1474 This command specifies attributes to be left unchanged for advertisements
1475 sent to a peer. Use this to leave the next-hop unchanged in ipv6
1476 configurations, as the route-map directive to leave the next-hop unchanged
1477 is only available for ipv4.
1479 .. clicmd:: neighbor PEER update-source <IFNAME|ADDRESS>
1481 Specify the IPv4 source address to use for the :abbr:`BGP` session to this
1482 neighbour, may be specified as either an IPv4 address directly or as an
1483 interface name (in which case the *zebra* daemon MUST be running in order
1484 for *bgpd* to be able to retrieve interface state).
1489 neighbor foo update-source 192.168.0.1
1490 neighbor bar update-source lo0
1493 .. clicmd:: neighbor PEER default-originate [route-map WORD]
1495 *bgpd*'s default is to not announce the default route (0.0.0.0/0) even if it
1496 is in routing table. When you want to announce default routes to the peer,
1499 If ``route-map`` keyword is specified, then the default route will be
1500 originated only if route-map conditions are met. For example, announce
1501 the default route only if ``10.10.10.10/32`` route exists and set an
1502 arbitrary community for a default route.
1507 address-family ipv4 unicast
1508 neighbor 192.168.255.1 default-originate route-map default
1510 ip prefix-list p1 seq 5 permit 10.10.10.10/32
1512 route-map default permit 10
1513 match ip address prefix-list p1
1514 set community 123:123
1517 .. clicmd:: neighbor PEER port PORT
1519 .. clicmd:: neighbor PEER password PASSWORD
1521 Set a MD5 password to be used with the tcp socket that is being used
1522 to connect to the remote peer. Please note if you are using this
1523 command with a large number of peers on linux you should consider
1524 modifying the `net.core.optmem_max` sysctl to a larger value to
1525 avoid out of memory errors from the linux kernel.
1527 .. clicmd:: neighbor PEER send-community
1529 .. clicmd:: neighbor PEER weight WEIGHT
1531 This command specifies a default `weight` value for the neighbor's routes.
1533 .. clicmd:: neighbor PEER maximum-prefix NUMBER [force]
1535 Sets a maximum number of prefixes we can receive from a given peer. If this
1536 number is exceeded, the BGP session will be destroyed.
1538 In practice, it is generally preferable to use a prefix-list to limit what
1539 prefixes are received from the peer instead of using this knob. Tearing down
1540 the BGP session when a limit is exceeded is far more destructive than merely
1541 rejecting undesired prefixes. The prefix-list method is also much more
1542 granular and offers much smarter matching criterion than number of received
1543 prefixes, making it more suited to implementing policy.
1545 If ``force`` is set, then ALL prefixes are counted for maximum instead of
1546 accepted only. This is useful for cases where an inbound filter is applied,
1547 but you want maximum-prefix to act on ALL (including filtered) prefixes. This
1548 option requires `soft-reconfiguration inbound` to be enabled for the peer.
1550 .. clicmd:: neighbor PEER maximum-prefix-out NUMBER
1552 Sets a maximum number of prefixes we can send to a given peer.
1554 Since sent prefix count is managed by update-groups, this option
1555 creates a separate update-group for outgoing updates.
1557 .. clicmd:: neighbor PEER local-as AS-NUMBER [no-prepend] [replace-as]
1559 Specify an alternate AS for this BGP process when interacting with the
1560 specified peer. With no modifiers, the specified local-as is prepended to
1561 the received AS_PATH when receiving routing updates from the peer, and
1562 prepended to the outgoing AS_PATH (after the process local AS) when
1563 transmitting local routes to the peer.
1565 If the no-prepend attribute is specified, then the supplied local-as is not
1566 prepended to the received AS_PATH.
1568 If the replace-as attribute is specified, then only the supplied local-as is
1569 prepended to the AS_PATH when transmitting local-route updates to this peer.
1571 Note that replace-as can only be specified if no-prepend is.
1573 This command is only allowed for eBGP peers.
1575 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> as-override
1577 Override AS number of the originating router with the local AS number.
1579 Usually this configuration is used in PEs (Provider Edge) to replace
1580 the incoming customer AS number so the connected CE (Customer Edge)
1581 can use the same AS number as the other customer sites. This allows
1582 customers of the provider network to use the same AS number across
1585 This command is only allowed for eBGP peers.
1587 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> allowas-in [<(1-10)|origin>]
1589 Accept incoming routes with AS path containing AS number with the same value
1590 as the current system AS.
1592 This is used when you want to use the same AS number in your sites, but you
1593 can't connect them directly. This is an alternative to
1594 `neighbor WORD as-override`.
1596 The parameter `(1-10)` configures the amount of accepted occurrences of the
1597 system AS number in AS path.
1599 The parameter `origin` configures BGP to only accept routes originated with
1600 the same AS number as the system.
1602 This command is only allowed for eBGP peers.
1604 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> addpath-tx-all-paths
1606 Configure BGP to send all known paths to neighbor in order to preserve multi
1607 path capabilities inside a network.
1609 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> addpath-tx-bestpath-per-AS
1611 Configure BGP to send best known paths to neighbor in order to preserve multi
1612 path capabilities inside a network.
1614 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> disable-addpath-rx
1616 Do not accept additional paths from this neighbor.
1618 .. clicmd:: neighbor PEER ttl-security hops NUMBER
1620 This command enforces Generalized TTL Security Mechanism (GTSM), as
1621 specified in RFC 5082. With this command, only neighbors that are the
1622 specified number of hops away will be allowed to become neighbors. This
1623 command is mutually exclusive with *ebgp-multihop*.
1625 .. clicmd:: neighbor PEER capability extended-nexthop
1627 Allow bgp to negotiate the extended-nexthop capability with it's peer.
1628 If you are peering over a v6 LL address then this capability is turned
1629 on automatically. If you are peering over a v6 Global Address then
1630 turning on this command will allow BGP to install v4 routes with
1631 v6 nexthops if you do not have v4 configured on interfaces.
1633 .. clicmd:: bgp fast-external-failover
1635 This command causes bgp to not take down ebgp peers immediately
1636 when a link flaps. `bgp fast-external-failover` is the default
1637 and will not be displayed as part of a `show run`. The no form
1638 of the command turns off this ability.
1640 .. clicmd:: bgp default ipv4-unicast
1642 This command allows the user to specify that the IPv4 Unicast address
1643 family is turned on by default or not. This command defaults to on
1644 and is not displayed.
1645 The `no bgp default ipv4-unicast` form of the command is displayed.
1647 .. clicmd:: bgp default ipv4-multicast
1649 This command allows the user to specify that the IPv4 Multicast address
1650 family is turned on by default or not. This command defaults to off
1651 and is not displayed.
1652 The `bgp default ipv4-multicast` form of the command is displayed.
1654 .. clicmd:: bgp default ipv4-vpn
1656 This command allows the user to specify that the IPv4 MPLS VPN address
1657 family is turned on by default or not. This command defaults to off
1658 and is not displayed.
1659 The `bgp default ipv4-vpn` form of the command is displayed.
1661 .. clicmd:: bgp default ipv4-flowspec
1663 This command allows the user to specify that the IPv4 Flowspec address
1664 family is turned on by default or not. This command defaults to off
1665 and is not displayed.
1666 The `bgp default ipv4-flowspec` form of the command is displayed.
1668 .. clicmd:: bgp default ipv6-unicast
1670 This command allows the user to specify that the IPv6 Unicast address
1671 family is turned on by default or not. This command defaults to off
1672 and is not displayed.
1673 The `bgp default ipv6-unicast` form of the command is displayed.
1675 .. clicmd:: bgp default ipv6-multicast
1677 This command allows the user to specify that the IPv6 Multicast address
1678 family is turned on by default or not. This command defaults to off
1679 and is not displayed.
1680 The `bgp default ipv6-multicast` form of the command is displayed.
1682 .. clicmd:: bgp default ipv6-vpn
1684 This command allows the user to specify that the IPv6 MPLS VPN address
1685 family is turned on by default or not. This command defaults to off
1686 and is not displayed.
1687 The `bgp default ipv6-vpn` form of the command is displayed.
1689 .. clicmd:: bgp default ipv6-flowspec
1691 This command allows the user to specify that the IPv6 Flowspec address
1692 family is turned on by default or not. This command defaults to off
1693 and is not displayed.
1694 The `bgp default ipv6-flowspec` form of the command is displayed.
1696 .. clicmd:: bgp default l2vpn-evpn
1698 This command allows the user to specify that the L2VPN EVPN address
1699 family is turned on by default or not. This command defaults to off
1700 and is not displayed.
1701 The `bgp default l2vpn-evpn` form of the command is displayed.
1703 .. clicmd:: bgp default show-hostname
1705 This command shows the hostname of the peer in certain BGP commands
1706 outputs. It's easier to troubleshoot if you have a number of BGP peers.
1708 .. clicmd:: bgp default show-nexthop-hostname
1710 This command shows the hostname of the next-hop in certain BGP commands
1711 outputs. It's easier to troubleshoot if you have a number of BGP peers
1712 and a number of routes to check.
1714 .. clicmd:: neighbor PEER advertisement-interval (0-600)
1716 Setup the minimum route advertisement interval(mrai) for the
1717 peer in question. This number is between 0 and 600 seconds,
1718 with the default advertisement interval being 0.
1720 .. clicmd:: neighbor PEER timers (0-65535) (0-65535)
1722 Set keepalive and hold timers for a neighbor. The first value is keepalive
1723 and the second is hold time.
1725 .. clicmd:: neighbor PEER timers connect (1-65535)
1727 Set connect timer for a neighbor. The connect timer controls how long BGP
1728 waits between connection attempts to a neighbor.
1730 .. clicmd:: neighbor PEER timers delayopen (1-240)
1732 This command allows the user enable the
1733 `RFC 4271 <https://tools.ietf.org/html/rfc4271/>` DelayOpenTimer with the
1734 specified interval or disable it with the negating command for the peer. By
1735 default, the DelayOpenTimer is disabled. The timer interval may be set to a
1736 duration of 1 to 240 seconds.
1738 .. clicmd:: bgp minimum-holdtime (1-65535)
1740 This command allows user to prevent session establishment with BGP peers
1741 with lower holdtime less than configured minimum holdtime.
1742 When this command is not set, minimum holdtime does not work.
1744 Displaying Information about Peers
1745 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1747 .. clicmd:: show bgp <afi> <safi> neighbors WORD bestpath-routes [json] [wide]
1749 For the given neighbor, WORD, that is specified list the routes selected
1750 by BGP as having the best path.
1752 .. _bgp-peer-filtering:
1757 .. clicmd:: neighbor PEER distribute-list NAME [in|out]
1759 This command specifies a distribute-list for the peer. `direct` is
1762 .. clicmd:: neighbor PEER prefix-list NAME [in|out]
1764 .. clicmd:: neighbor PEER filter-list NAME [in|out]
1766 .. clicmd:: neighbor PEER route-map NAME [in|out]
1768 Apply a route-map on the neighbor. `direct` must be `in` or `out`.
1770 .. clicmd:: bgp route-reflector allow-outbound-policy
1772 By default, attribute modification via route-map policy out is not reflected
1773 on reflected routes. This option allows the modifications to be reflected as
1774 well. Once enabled, it affects all reflected routes.
1776 .. clicmd:: neighbor PEER sender-as-path-loop-detection
1778 Enable the detection of sender side AS path loops and filter the
1779 bad routes before they are sent.
1781 This setting is disabled by default.
1788 Peer groups are used to help improve scaling by generating the same
1789 update information to all members of a peer group. Note that this means
1790 that the routes generated by a member of a peer group will be sent back
1791 to that originating peer with the originator identifier attribute set to
1792 indicated the originating peer. All peers not associated with a
1793 specific peer group are treated as belonging to a default peer group,
1794 and will share updates.
1796 .. clicmd:: neighbor WORD peer-group
1798 This command defines a new peer group.
1800 .. clicmd:: neighbor PEER peer-group PGNAME
1802 This command bind specific peer to peer group WORD.
1804 .. clicmd:: neighbor PEER solo
1806 This command is used to indicate that routes advertised by the peer
1807 should not be reflected back to the peer. This command only is only
1808 meaningful when there is a single peer defined in the peer-group.
1810 .. clicmd:: show [ip] bgp peer-group [json]
1812 This command displays configured BGP peer-groups.
1816 exit1-debian-9# show bgp peer-group
1818 BGP peer-group test1, remote AS 65001
1819 Peer-group type is external
1820 Configured address-families: IPv4 Unicast; IPv6 Unicast;
1821 1 IPv4 listen range(s)
1823 2 IPv6 listen range(s)
1827 192.168.200.1 Active
1830 BGP peer-group test2
1831 Peer-group type is external
1832 Configured address-families: IPv4 Unicast;
1834 Optional ``json`` parameter is used to display JSON output.
1842 "addressFamiliesConfigured":[
1872 "addressFamiliesConfigured":[
1878 Capability Negotiation
1879 ^^^^^^^^^^^^^^^^^^^^^^
1881 .. clicmd:: neighbor PEER strict-capability-match
1884 Strictly compares remote capabilities and local capabilities. If
1885 capabilities are different, send Unsupported Capability error then reset
1888 You may want to disable sending Capability Negotiation OPEN message optional
1889 parameter to the peer when remote peer does not implement Capability
1890 Negotiation. Please use *dont-capability-negotiate* command to disable the
1893 .. clicmd:: neighbor PEER dont-capability-negotiate
1895 Suppress sending Capability Negotiation as OPEN message optional parameter
1896 to the peer. This command only affects the peer is configured other than
1897 IPv4 unicast configuration.
1899 When remote peer does not have capability negotiation feature, remote peer
1900 will not send any capabilities at all. In that case, bgp configures the peer
1901 with configured capabilities.
1903 You may prefer locally configured capabilities more than the negotiated
1904 capabilities even though remote peer sends capabilities. If the peer is
1905 configured by *override-capability*, *bgpd* ignores received capabilities
1906 then override negotiated capabilities with configured values.
1908 Additionally the operator should be reminded that this feature fundamentally
1909 disables the ability to use widely deployed BGP features. BGP unnumbered,
1910 hostname support, AS4, Addpath, Route Refresh, ORF, Dynamic Capabilities,
1911 and graceful restart.
1913 .. clicmd:: neighbor PEER override-capability
1916 Override the result of Capability Negotiation with local configuration.
1917 Ignore remote peer's capability value.
1919 .. _bgp-as-path-access-lists:
1921 AS Path Access Lists
1922 --------------------
1924 AS path access list is user defined AS path.
1926 .. clicmd:: bgp as-path access-list WORD [seq (0-4294967295)] permit|deny LINE
1928 This command defines a new AS path access list.
1930 .. clicmd:: show bgp as-path-access-list [json]
1932 Display all BGP AS Path access lists.
1934 If the ``json`` option is specified, output is displayed in JSON format.
1936 .. clicmd:: show bgp as-path-access-list WORD [json]
1938 Display the specified BGP AS Path access list.
1940 If the ``json`` option is specified, output is displayed in JSON format.
1942 .. _bgp-bogon-filter-example:
1944 Bogon ASN filter policy configuration example
1945 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1949 bgp as-path access-list 99 permit _0_
1950 bgp as-path access-list 99 permit _23456_
1951 bgp as-path access-list 99 permit _1310[0-6][0-9]_|_13107[0-1]_
1952 bgp as-path access-list 99 seq 20 permit ^65
1954 .. _bgp-using-as-path-in-route-map:
1956 Using AS Path in Route Map
1957 --------------------------
1959 .. clicmd:: match as-path WORD
1961 For a given as-path, WORD, match it on the BGP as-path given for the prefix
1962 and if it matches do normal route-map actions. The no form of the command
1963 removes this match from the route-map.
1965 .. clicmd:: set as-path prepend AS-PATH
1967 Prepend the given string of AS numbers to the AS_PATH of the BGP path's NLRI.
1968 The no form of this command removes this set operation from the route-map.
1970 .. clicmd:: set as-path prepend last-as NUM
1972 Prepend the existing last AS number (the leftmost ASN) to the AS_PATH.
1973 The no form of this command removes this set operation from the route-map.
1975 .. _bgp-communities-attribute:
1977 Communities Attribute
1978 ---------------------
1980 The BGP communities attribute is widely used for implementing policy routing.
1981 Network operators can manipulate BGP communities attribute based on their
1982 network policy. BGP communities attribute is defined in :rfc:`1997` and
1983 :rfc:`1998`. It is an optional transitive attribute, therefore local policy can
1984 travel through different autonomous system.
1986 The communities attribute is a set of communities values. Each community value
1987 is 4 octet long. The following format is used to define the community value.
1990 This format represents 4 octet communities value. ``AS`` is high order 2
1991 octet in digit format. ``VAL`` is low order 2 octet in digit format. This
1992 format is useful to define AS oriented policy value. For example,
1993 ``7675:80`` can be used when AS 7675 wants to pass local policy value 80 to
1997 ``internet`` represents well-known communities value 0.
1999 ``graceful-shutdown``
2000 ``graceful-shutdown`` represents well-known communities value
2001 ``GRACEFUL_SHUTDOWN`` ``0xFFFF0000`` ``65535:0``. :rfc:`8326` implements
2002 the purpose Graceful BGP Session Shutdown to reduce the amount of
2003 lost traffic when taking BGP sessions down for maintenance. The use
2004 of the community needs to be supported from your peers side to
2005 actually have any effect.
2008 ``accept-own`` represents well-known communities value ``ACCEPT_OWN``
2009 ``0xFFFF0001`` ``65535:1``. :rfc:`7611` implements a way to signal
2010 to a router to accept routes with a local nexthop address. This
2011 can be the case when doing policing and having traffic having a
2012 nexthop located in another VRF but still local interface to the
2013 router. It is recommended to read the RFC for full details.
2015 ``route-filter-translated-v4``
2016 ``route-filter-translated-v4`` represents well-known communities value
2017 ``ROUTE_FILTER_TRANSLATED_v4`` ``0xFFFF0002`` ``65535:2``.
2020 ``route-filter-v4`` represents well-known communities value
2021 ``ROUTE_FILTER_v4`` ``0xFFFF0003`` ``65535:3``.
2023 ``route-filter-translated-v6``
2024 ``route-filter-translated-v6`` represents well-known communities value
2025 ``ROUTE_FILTER_TRANSLATED_v6`` ``0xFFFF0004`` ``65535:4``.
2028 ``route-filter-v6`` represents well-known communities value
2029 ``ROUTE_FILTER_v6`` ``0xFFFF0005`` ``65535:5``.
2032 ``llgr-stale`` represents well-known communities value ``LLGR_STALE``
2033 ``0xFFFF0006`` ``65535:6``.
2034 Assigned and intended only for use with routers supporting the
2035 Long-lived Graceful Restart Capability as described in
2036 [Draft-IETF-uttaro-idr-bgp-persistence]_.
2037 Routers receiving routes with this community may (depending on
2038 implementation) choose allow to reject or modify routes on the
2039 presence or absence of this community.
2042 ``no-llgr`` represents well-known communities value ``NO_LLGR``
2043 ``0xFFFF0007`` ``65535:7``.
2044 Assigned and intended only for use with routers supporting the
2045 Long-lived Graceful Restart Capability as described in
2046 [Draft-IETF-uttaro-idr-bgp-persistence]_.
2047 Routers receiving routes with this community may (depending on
2048 implementation) choose allow to reject or modify routes on the
2049 presence or absence of this community.
2051 ``accept-own-nexthop``
2052 ``accept-own-nexthop`` represents well-known communities value
2053 ``accept-own-nexthop`` ``0xFFFF0008`` ``65535:8``.
2054 [Draft-IETF-agrewal-idr-accept-own-nexthop]_ describes
2055 how to tag and label VPN routes to be able to send traffic between VRFs
2056 via an internal layer 2 domain on the same PE device. Refer to
2057 [Draft-IETF-agrewal-idr-accept-own-nexthop]_ for full details.
2060 ``blackhole`` represents well-known communities value ``BLACKHOLE``
2061 ``0xFFFF029A`` ``65535:666``. :rfc:`7999` documents sending prefixes to
2062 EBGP peers and upstream for the purpose of blackholing traffic.
2063 Prefixes tagged with the this community should normally not be
2064 re-advertised from neighbors of the originating network. Upon receiving
2065 ``BLACKHOLE`` community from a BGP speaker, ``NO_ADVERTISE`` community
2066 is added automatically.
2069 ``no-export`` represents well-known communities value ``NO_EXPORT``
2070 ``0xFFFFFF01``. All routes carry this value must not be advertised to
2071 outside a BGP confederation boundary. If neighboring BGP peer is part of BGP
2072 confederation, the peer is considered as inside a BGP confederation
2073 boundary, so the route will be announced to the peer.
2076 ``no-advertise`` represents well-known communities value ``NO_ADVERTISE``
2077 ``0xFFFFFF02``. All routes carry this value must not be advertise to other
2081 ``local-AS`` represents well-known communities value ``NO_EXPORT_SUBCONFED``
2082 ``0xFFFFFF03``. All routes carry this value must not be advertised to
2083 external BGP peers. Even if the neighboring router is part of confederation,
2084 it is considered as external BGP peer, so the route will not be announced to
2088 ``no-peer`` represents well-known communities value ``NOPEER``
2089 ``0xFFFFFF04`` ``65535:65284``. :rfc:`3765` is used to communicate to
2090 another network how the originating network want the prefix propagated.
2092 When the communities attribute is received duplicate community values in the
2093 attribute are ignored and value is sorted in numerical order.
2095 .. [Draft-IETF-uttaro-idr-bgp-persistence] <https://tools.ietf.org/id/draft-uttaro-idr-bgp-persistence-04.txt>
2096 .. [Draft-IETF-agrewal-idr-accept-own-nexthop] <https://tools.ietf.org/id/draft-agrewal-idr-accept-own-nexthop-00.txt>
2098 .. _bgp-community-lists:
2102 Community lists are user defined lists of community attribute values. These
2103 lists can be used for matching or manipulating the communities attribute in
2106 There are two types of community list:
2109 This type accepts an explicit value for the attribute.
2112 This type accepts a regular expression. Because the regex must be
2113 interpreted on each use expanded community lists are slower than standard
2116 .. clicmd:: bgp community-list standard NAME permit|deny COMMUNITY
2118 This command defines a new standard community list. ``COMMUNITY`` is
2119 communities value. The ``COMMUNITY`` is compiled into community structure.
2120 We can define multiple community list under same name. In that case match
2121 will happen user defined order. Once the community list matches to
2122 communities attribute in BGP updates it return permit or deny by the
2123 community list definition. When there is no matched entry, deny will be
2124 returned. When ``COMMUNITY`` is empty it matches to any routes.
2126 .. clicmd:: bgp community-list expanded NAME permit|deny COMMUNITY
2128 This command defines a new expanded community list. ``COMMUNITY`` is a
2129 string expression of communities attribute. ``COMMUNITY`` can be a regular
2130 expression (:ref:`bgp-regular-expressions`) to match the communities
2131 attribute in BGP updates. The expanded community is only used to filter,
2135 It is recommended to use the more explicit versions of this command.
2137 .. clicmd:: bgp community-list NAME permit|deny COMMUNITY
2139 When the community list type is not specified, the community list type is
2140 automatically detected. If ``COMMUNITY`` can be compiled into communities
2141 attribute, the community list is defined as a standard community list.
2142 Otherwise it is defined as an expanded community list. This feature is left
2143 for backward compatibility. Use of this feature is not recommended.
2145 Note that all community lists share the same namespace, so it's not
2146 necessary to specify ``standard`` or ``expanded``; these modifiers are
2149 .. clicmd:: show bgp community-list [NAME detail]
2151 Displays community list information. When ``NAME`` is specified the
2152 specified community list's information is shown.
2156 # show bgp community-list
2157 Named Community standard list CLIST
2158 permit 7675:80 7675:100 no-export
2160 Named Community expanded list EXPAND
2163 # show bgp community-list CLIST detail
2164 Named Community standard list CLIST
2165 permit 7675:80 7675:100 no-export
2169 .. _bgp-numbered-community-lists:
2171 Numbered Community Lists
2172 ^^^^^^^^^^^^^^^^^^^^^^^^
2174 When number is used for BGP community list name, the number has
2175 special meanings. Community list number in the range from 1 and 99 is
2176 standard community list. Community list number in the range from 100
2177 to 500 is expanded community list. These community lists are called
2178 as numbered community lists. On the other hand normal community lists
2179 is called as named community lists.
2181 .. clicmd:: bgp community-list (1-99) permit|deny COMMUNITY
2183 This command defines a new community list. The argument to (1-99) defines
2184 the list identifier.
2186 .. clicmd:: bgp community-list (100-500) permit|deny COMMUNITY
2188 This command defines a new expanded community list. The argument to
2189 (100-500) defines the list identifier.
2191 .. _bgp-community-alias:
2196 BGP community aliases are useful to quickly identify what communities are set
2197 for a specific prefix in a human-readable format. Especially handy for a huge
2198 amount of communities. Accurately defined aliases can help you faster spot
2201 .. clicmd:: bgp community alias NAME ALIAS
2203 This command creates an alias name for a community that will be used
2204 later in various CLI outputs in a human-readable format.
2208 ~# vtysh -c 'show run' | grep 'bgp community alias'
2209 bgp community alias 65001:14 community-1
2210 bgp community alias 65001:123:1 lcommunity-1
2212 ~# vtysh -c 'show ip bgp 172.16.16.1/32'
2213 BGP routing table entry for 172.16.16.1/32, version 21
2214 Paths: (2 available, best #2, table default)
2215 Advertised to non peer-group peers:
2217 192.168.0.2 from 192.168.0.2 (172.16.16.1)
2218 Origin incomplete, metric 0, valid, external, best (Neighbor IP)
2219 Community: 65001:12 65001:13 community-1 65001:65534
2220 Large Community: lcommunity-1 65001:123:2
2221 Last update: Fri Apr 16 12:51:27 2021
2223 .. clicmd:: show bgp [afi] [safi] [all] alias WORD [wide|json]
2225 Display prefixes with matching BGP community alias.
2227 .. _bgp-using-communities-in-route-map:
2229 Using Communities in Route Maps
2230 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2232 In :ref:`route-map` we can match on or set the BGP communities attribute. Using
2233 this feature network operator can implement their network policy based on BGP
2234 communities attribute.
2236 The following commands can be used in route maps:
2238 .. clicmd:: match alias WORD
2240 This command performs match to BGP updates using community alias WORD. When
2241 the one of BGP communities value match to the one of community alias value in
2242 community alias, it is match.
2244 .. clicmd:: match community WORD exact-match [exact-match]
2246 This command perform match to BGP updates using community list WORD. When
2247 the one of BGP communities value match to the one of communities value in
2248 community list, it is match. When `exact-match` keyword is specified, match
2249 happen only when BGP updates have completely same communities value
2250 specified in the community list.
2252 .. clicmd:: set community <none|COMMUNITY> additive
2254 This command sets the community value in BGP updates. If the attribute is
2255 already configured, the newly provided value replaces the old one unless the
2256 ``additive`` keyword is specified, in which case the new value is appended
2257 to the existing value.
2259 If ``none`` is specified as the community value, the communities attribute
2262 It is not possible to set an expanded community list.
2264 .. clicmd:: set comm-list WORD delete
2266 This command remove communities value from BGP communities attribute. The
2267 ``word`` is community list name. When BGP route's communities value matches
2268 to the community list ``word``, the communities value is removed. When all
2269 of communities value is removed eventually, the BGP update's communities
2270 attribute is completely removed.
2272 .. _bgp-communities-example:
2274 Example Configuration
2275 ^^^^^^^^^^^^^^^^^^^^^
2277 The following configuration is exemplary of the most typical usage of BGP
2278 communities attribute. In the example, AS 7675 provides an upstream Internet
2279 connection to AS 100. When the following configuration exists in AS 7675, the
2280 network operator of AS 100 can set local preference in AS 7675 network by
2281 setting BGP communities attribute to the updates.
2286 neighbor 192.168.0.1 remote-as 100
2287 address-family ipv4 unicast
2288 neighbor 192.168.0.1 route-map RMAP in
2291 bgp community-list 70 permit 7675:70
2292 bgp community-list 70 deny
2293 bgp community-list 80 permit 7675:80
2294 bgp community-list 80 deny
2295 bgp community-list 90 permit 7675:90
2296 bgp community-list 90 deny
2298 route-map RMAP permit 10
2300 set local-preference 70
2302 route-map RMAP permit 20
2304 set local-preference 80
2306 route-map RMAP permit 30
2308 set local-preference 90
2311 The following configuration announces ``10.0.0.0/8`` from AS 100 to AS 7675.
2312 The route has communities value ``7675:80`` so when above configuration exists
2313 in AS 7675, the announced routes' local preference value will be set to 80.
2319 neighbor 192.168.0.2 remote-as 7675
2320 address-family ipv4 unicast
2321 neighbor 192.168.0.2 route-map RMAP out
2324 ip prefix-list PLIST permit 10.0.0.0/8
2326 route-map RMAP permit 10
2327 match ip address prefix-list PLIST
2328 set community 7675:80
2331 The following configuration is an example of BGP route filtering using
2332 communities attribute. This configuration only permit BGP routes which has BGP
2333 communities value ``0:80`` or ``0:90``. The network operator can set special
2334 internal communities value at BGP border router, then limit the BGP route
2335 announcements into the internal network.
2340 neighbor 192.168.0.1 remote-as 100
2341 address-family ipv4 unicast
2342 neighbor 192.168.0.1 route-map RMAP in
2345 bgp community-list 1 permit 0:80 0:90
2347 route-map RMAP permit in
2351 The following example filters BGP routes which have a community value of
2352 ``1:1``. When there is no match community-list returns ``deny``. To avoid
2353 filtering all routes, a ``permit`` line is set at the end of the
2359 neighbor 192.168.0.1 remote-as 100
2360 address-family ipv4 unicast
2361 neighbor 192.168.0.1 route-map RMAP in
2364 bgp community-list standard FILTER deny 1:1
2365 bgp community-list standard FILTER permit
2367 route-map RMAP permit 10
2368 match community FILTER
2371 The communities value keyword ``internet`` has special meanings in standard
2372 community lists. In the below example ``internet`` matches all BGP routes even
2373 if the route does not have communities attribute at all. So community list
2374 ``INTERNET`` is the same as ``FILTER`` in the previous example.
2378 bgp community-list standard INTERNET deny 1:1
2379 bgp community-list standard INTERNET permit internet
2382 The following configuration is an example of communities value deletion. With
2383 this configuration the community values ``100:1`` and ``100:2`` are removed
2384 from BGP updates. For communities value deletion, only ``permit``
2385 community-list is used. ``deny`` community-list is ignored.
2390 neighbor 192.168.0.1 remote-as 100
2391 address-family ipv4 unicast
2392 neighbor 192.168.0.1 route-map RMAP in
2395 bgp community-list standard DEL permit 100:1 100:2
2397 route-map RMAP permit 10
2398 set comm-list DEL delete
2401 .. _bgp-extended-communities-attribute:
2403 Extended Communities Attribute
2404 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2406 BGP extended communities attribute is introduced with MPLS VPN/BGP technology.
2407 MPLS VPN/BGP expands capability of network infrastructure to provide VPN
2408 functionality. At the same time it requires a new framework for policy routing.
2409 With BGP Extended Communities Attribute we can use Route Target or Site of
2410 Origin for implementing network policy for MPLS VPN/BGP.
2412 BGP Extended Communities Attribute is similar to BGP Communities Attribute. It
2413 is an optional transitive attribute. BGP Extended Communities Attribute can
2414 carry multiple Extended Community value. Each Extended Community value is
2417 BGP Extended Communities Attribute provides an extended range compared with BGP
2418 Communities Attribute. Adding to that there is a type field in each value to
2419 provides community space structure.
2421 There are two format to define Extended Community value. One is AS based format
2422 the other is IP address based format.
2425 This is a format to define AS based Extended Community value. ``AS`` part
2426 is 2 octets Global Administrator subfield in Extended Community value.
2427 ``VAL`` part is 4 octets Local Administrator subfield. ``7675:100``
2428 represents AS 7675 policy value 100.
2431 This is a format to define IP address based Extended Community value.
2432 ``IP-Address`` part is 4 octets Global Administrator subfield. ``VAL`` part
2433 is 2 octets Local Administrator subfield.
2435 .. _bgp-extended-community-lists:
2437 Extended Community Lists
2438 ^^^^^^^^^^^^^^^^^^^^^^^^
2440 .. clicmd:: bgp extcommunity-list standard NAME permit|deny EXTCOMMUNITY
2442 This command defines a new standard extcommunity-list. `extcommunity` is
2443 extended communities value. The `extcommunity` is compiled into extended
2444 community structure. We can define multiple extcommunity-list under same
2445 name. In that case match will happen user defined order. Once the
2446 extcommunity-list matches to extended communities attribute in BGP updates
2447 it return permit or deny based upon the extcommunity-list definition. When
2448 there is no matched entry, deny will be returned. When `extcommunity` is
2449 empty it matches to any routes.
2451 .. clicmd:: bgp extcommunity-list expanded NAME permit|deny LINE
2453 This command defines a new expanded extcommunity-list. `line` is a string
2454 expression of extended communities attribute. `line` can be a regular
2455 expression (:ref:`bgp-regular-expressions`) to match an extended communities
2456 attribute in BGP updates.
2458 Note that all extended community lists shares a single name space, so it's
2459 not necessary to specify their type when creating or destroying them.
2461 .. clicmd:: show bgp extcommunity-list [NAME detail]
2463 This command displays current extcommunity-list information. When `name` is
2464 specified the community list's information is shown.
2467 .. _bgp-extended-communities-in-route-map:
2469 BGP Extended Communities in Route Map
2470 """""""""""""""""""""""""""""""""""""
2472 .. clicmd:: match extcommunity WORD
2474 .. clicmd:: set extcommunity none
2476 This command resets the extended community value in BGP updates. If the attribute is
2477 already configured or received from the peer, the attribute is discarded and set to
2478 none. This is useful if you need to strip incoming extended communities.
2480 .. clicmd:: set extcommunity rt EXTCOMMUNITY
2482 This command set Route Target value.
2484 .. clicmd:: set extcommunity soo EXTCOMMUNITY
2486 This command set Site of Origin value.
2488 .. clicmd:: set extcommunity bandwidth <(1-25600) | cumulative | num-multipaths> [non-transitive]
2490 This command sets the BGP link-bandwidth extended community for the prefix
2491 (best path) for which it is applied. The link-bandwidth can be specified as
2492 an ``explicit value`` (specified in Mbps), or the router can be told to use
2493 the ``cumulative bandwidth`` of all multipaths for the prefix or to compute
2494 it based on the ``number of multipaths``. The link bandwidth extended
2495 community is encoded as ``transitive`` unless the set command explicitly
2496 configures it as ``non-transitive``.
2498 .. seealso:: :ref:`wecmp_linkbw`
2500 Note that the extended expanded community is only used for `match` rule, not for
2503 .. _bgp-large-communities-attribute:
2505 Large Communities Attribute
2506 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
2508 The BGP Large Communities attribute was introduced in Feb 2017 with
2511 The BGP Large Communities Attribute is similar to the BGP Communities Attribute
2512 except that it has 3 components instead of two and each of which are 4 octets
2513 in length. Large Communities bring additional functionality and convenience
2514 over traditional communities, specifically the fact that the ``GLOBAL`` part
2515 below is now 4 octets wide allowing seamless use in networks using 4-byte ASNs.
2517 ``GLOBAL:LOCAL1:LOCAL2``
2518 This is the format to define Large Community values. Referencing :rfc:`8195`
2519 the values are commonly referred to as follows:
2521 - The ``GLOBAL`` part is a 4 octet Global Administrator field, commonly used
2522 as the operators AS number.
2523 - The ``LOCAL1`` part is a 4 octet Local Data Part 1 subfield referred to as
2525 - The ``LOCAL2`` part is a 4 octet Local Data Part 2 field and referred to
2526 as the parameter subfield.
2528 As an example, ``65551:1:10`` represents AS 65551 function 1 and parameter
2529 10. The referenced RFC above gives some guidelines on recommended usage.
2531 .. _bgp-large-community-lists:
2533 Large Community Lists
2534 """""""""""""""""""""
2536 Two types of large community lists are supported, namely `standard` and
2539 .. clicmd:: bgp large-community-list standard NAME permit|deny LARGE-COMMUNITY
2541 This command defines a new standard large-community-list. `large-community`
2542 is the Large Community value. We can add multiple large communities under
2543 same name. In that case the match will happen in the user defined order.
2544 Once the large-community-list matches the Large Communities attribute in BGP
2545 updates it will return permit or deny based upon the large-community-list
2546 definition. When there is no matched entry, a deny will be returned. When
2547 `large-community` is empty it matches any routes.
2549 .. clicmd:: bgp large-community-list expanded NAME permit|deny LINE
2551 This command defines a new expanded large-community-list. Where `line` is a
2552 string matching expression, it will be compared to the entire Large
2553 Communities attribute as a string, with each large-community in order from
2554 lowest to highest. `line` can also be a regular expression which matches
2555 this Large Community attribute.
2557 Note that all community lists share the same namespace, so it's not
2558 necessary to specify ``standard`` or ``expanded``; these modifiers are
2561 .. clicmd:: show bgp large-community-list
2563 .. clicmd:: show bgp large-community-list NAME detail
2565 This command display current large-community-list information. When
2566 `name` is specified the community list information is shown.
2568 .. clicmd:: show ip bgp large-community-info
2570 This command displays the current large communities in use.
2572 .. _bgp-large-communities-in-route-map:
2574 Large Communities in Route Map
2575 """"""""""""""""""""""""""""""
2577 .. clicmd:: match large-community LINE [exact-match]
2579 Where `line` can be a simple string to match, or a regular expression. It
2580 is very important to note that this match occurs on the entire
2581 large-community string as a whole, where each large-community is ordered
2582 from lowest to highest. When `exact-match` keyword is specified, match
2583 happen only when BGP updates have completely same large communities value
2584 specified in the large community list.
2586 .. clicmd:: set large-community LARGE-COMMUNITY
2588 .. clicmd:: set large-community LARGE-COMMUNITY LARGE-COMMUNITY
2590 .. clicmd:: set large-community LARGE-COMMUNITY additive
2592 These commands are used for setting large-community values. The first
2593 command will overwrite any large-communities currently present.
2594 The second specifies two large-communities, which overwrites the current
2595 large-community list. The third will add a large-community value without
2596 overwriting other values. Multiple large-community values can be specified.
2598 Note that the large expanded community is only used for `match` rule, not for
2606 *bgpd* supports :abbr:`L3VPN (Layer 3 Virtual Private Networks)` :abbr:`VRFs
2607 (Virtual Routing and Forwarding)` for IPv4 :rfc:`4364` and IPv6 :rfc:`4659`.
2608 L3VPN routes, and their associated VRF MPLS labels, can be distributed to VPN
2609 SAFI neighbors in the *default*, i.e., non VRF, BGP instance. VRF MPLS labels
2610 are reached using *core* MPLS labels which are distributed using LDP or BGP
2611 labeled unicast. *bgpd* also supports inter-VRF route leaking.
2614 .. _bgp-vrf-route-leaking:
2619 BGP routes may be leaked (i.e. copied) between a unicast VRF RIB and the VPN
2620 SAFI RIB of the default VRF for use in MPLS-based L3VPNs. Unicast routes may
2621 also be leaked between any VRFs (including the unicast RIB of the default BGP
2622 instanced). A shortcut syntax is also available for specifying leaking from one
2623 VRF to another VRF using the default instance's VPN RIB as the intermediary. A
2624 common application of the VRF-VRF feature is to connect a customer's private
2625 routing domain to a provider's VPN service. Leaking is configured from the
2626 point of view of an individual VRF: ``import`` refers to routes leaked from VPN
2627 to a unicast VRF, whereas ``export`` refers to routes leaked from a unicast VRF
2633 Routes exported from a unicast VRF to the VPN RIB must be augmented by two
2636 - an :abbr:`RD (Route Distinguisher)`
2637 - an :abbr:`RTLIST (Route-target List)`
2639 Configuration for these exported routes must, at a minimum, specify these two
2642 Routes imported from the VPN RIB to a unicast VRF are selected according to
2643 their RTLISTs. Routes whose RTLIST contains at least one route-target in
2644 common with the configured import RTLIST are leaked. Configuration for these
2645 imported routes must specify an RTLIST to be matched.
2647 The RD, which carries no semantic value, is intended to make the route unique
2648 in the VPN RIB among all routes of its prefix that originate from all the
2649 customers and sites that are attached to the provider's VPN service.
2650 Accordingly, each site of each customer is typically assigned an RD that is
2651 unique across the entire provider network.
2653 The RTLIST is a set of route-target extended community values whose purpose is
2654 to specify route-leaking policy. Typically, a customer is assigned a single
2655 route-target value for import and export to be used at all customer sites. This
2656 configuration specifies a simple topology wherein a customer has a single
2657 routing domain which is shared across all its sites. More complex routing
2658 topologies are possible through use of additional route-targets to augment the
2659 leaking of sets of routes in various ways.
2661 When using the shortcut syntax for vrf-to-vrf leaking, the RD and RT are
2664 General configuration
2665 ^^^^^^^^^^^^^^^^^^^^^
2667 Configuration of route leaking between a unicast VRF RIB and the VPN SAFI RIB
2668 of the default VRF is accomplished via commands in the context of a VRF
2671 .. clicmd:: rd vpn export AS:NN|IP:nn
2673 Specifies the route distinguisher to be added to a route exported from the
2674 current unicast VRF to VPN.
2676 .. clicmd:: rt vpn import|export|both RTLIST...
2678 Specifies the route-target list to be attached to a route (export) or the
2679 route-target list to match against (import) when exporting/importing between
2680 the current unicast VRF and VPN.
2682 The RTLIST is a space-separated list of route-targets, which are BGP
2683 extended community values as described in
2684 :ref:`bgp-extended-communities-attribute`.
2686 .. clicmd:: label vpn export (0..1048575)|auto
2688 Enables an MPLS label to be attached to a route exported from the current
2689 unicast VRF to VPN. If the value specified is ``auto``, the label value is
2690 automatically assigned from a pool maintained by the Zebra daemon. If Zebra
2691 is not running, or if this command is not configured, automatic label
2692 assignment will not complete, which will block corresponding route export.
2694 .. clicmd:: nexthop vpn export A.B.C.D|X:X::X:X
2696 Specifies an optional nexthop value to be assigned to a route exported from
2697 the current unicast VRF to VPN. If left unspecified, the nexthop will be set
2698 to 0.0.0.0 or 0:0::0:0 (self).
2700 .. clicmd:: route-map vpn import|export MAP
2702 Specifies an optional route-map to be applied to routes imported or exported
2703 between the current unicast VRF and VPN.
2705 .. clicmd:: import|export vpn
2707 Enables import or export of routes between the current unicast VRF and VPN.
2709 .. clicmd:: import vrf VRFNAME
2711 Shortcut syntax for specifying automatic leaking from vrf VRFNAME to
2712 the current VRF using the VPN RIB as intermediary. The RD and RT
2713 are auto derived and should not be specified explicitly for either the
2714 source or destination VRF's.
2716 This shortcut syntax mode is not compatible with the explicit
2717 `import vpn` and `export vpn` statements for the two VRF's involved.
2718 The CLI will disallow attempts to configure incompatible leaking
2726 .. clicmd:: segment-routing srv6
2728 Use SRv6 backend with BGP L3VPN, and go to its configuration node.
2730 .. clicmd:: locator NAME
2732 Specify the SRv6 locator to be used for SRv6 L3VPN. The Locator name must
2733 be set in zebra, but user can set it in any order.
2737 Ethernet Virtual Network - EVPN
2738 -------------------------------
2740 Note: When using EVPN features and if you have a large number of hosts, make
2741 sure to adjust the size of the arp neighbor cache to avoid neighbor table
2742 overflow and/or excessive garbage collection. On Linux, the size of the table
2743 and garbage collection frequency can be controlled via the following
2744 sysctl configurations:
2746 .. code-block:: shell
2748 net.ipv4.neigh.default.gc_thresh1
2749 net.ipv4.neigh.default.gc_thresh2
2750 net.ipv4.neigh.default.gc_thresh3
2752 net.ipv6.neigh.default.gc_thresh1
2753 net.ipv6.neigh.default.gc_thresh2
2754 net.ipv6.neigh.default.gc_thresh3
2756 For more information, see ``man 7 arp``.
2758 .. _bgp-evpn-advertise-pip:
2763 In a EVPN symmetric routing MLAG deployment, all EVPN routes advertised
2764 with anycast-IP as next-hop IP and anycast MAC as the Router MAC (RMAC - in
2765 BGP EVPN Extended-Community).
2766 EVPN picks up the next-hop IP from the VxLAN interface's local tunnel IP and
2767 the RMAC is obtained from the MAC of the L3VNI's SVI interface.
2768 Note: Next-hop IP is used for EVPN routes whether symmetric routing is
2769 deployed or not but the RMAC is only relevant for symmetric routing scenario.
2771 Current behavior is not ideal for Prefix (type-5) and self (type-2)
2772 routes. This is because the traffic from remote VTEPs routed sub optimally
2773 if they land on the system where the route does not belong.
2775 The advertise-pip feature advertises Prefix (type-5) and self (type-2)
2776 routes with system's individual (primary) IP as the next-hop and individual
2777 (system) MAC as Router-MAC (RMAC), while leaving the behavior unchanged for
2780 To support this feature there needs to have ability to co-exist a
2781 (system-MAC, system-IP) pair with a (anycast-MAC, anycast-IP) pair with the
2782 ability to terminate VxLAN-encapsulated packets received for either pair on
2783 the same L3VNI (i.e associated VLAN). This capability is needed per tenant
2786 To derive the system-MAC and the anycast MAC, there must be a
2787 separate/additional MAC-VLAN interface corresponding to L3VNI’s SVI.
2788 The SVI interface’s MAC address can be interpreted as system-MAC
2789 and MAC-VLAN interface's MAC as anycast MAC.
2791 To derive system-IP and anycast-IP, the default BGP instance's router-id is used
2792 as system-IP and the VxLAN interface’s local tunnel IP as the anycast-IP.
2794 User has an option to configure the system-IP and/or system-MAC value if the
2795 auto derived value is not preferred.
2797 Note: By default, advertise-pip feature is enabled and user has an option to
2798 disable the feature via configuration CLI. Once the feature is disabled under
2799 bgp vrf instance or MAC-VLAN interface is not configured, all the routes follow
2800 the same behavior of using same next-hop and RMAC values.
2802 .. clicmd:: advertise-pip [ip <addr> [mac <addr>]]
2804 Enables or disables advertise-pip feature, specify system-IP and/or system-MAC
2807 EVPN advertise-svi-ip
2808 ^^^^^^^^^^^^^^^^^^^^^
2809 Typically, the SVI IP address is reused on VTEPs across multiple racks. However,
2810 if you have unique SVI IP addresses that you want to be reachable you can use the
2811 advertise-svi-ip option. This option advertises the SVI IP/MAC address as a type-2
2812 route and eliminates the need for any flooding over VXLAN to reach the IP from a
2815 .. clicmd:: advertise-svi-ip
2817 Note that you should not enable both the advertise-svi-ip and the advertise-default-gw
2820 .. _bgp-evpn-overlay-index-gateway-ip:
2822 EVPN Overlay Index Gateway IP
2823 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2824 Draft https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-11
2825 explains the use of overlay indexes for recursive route resolution for EVPN
2828 We support gateway IP overlay index.
2829 A gateway IP, advertised with EVPN prefix route, is used to find an EVPN MAC/IP
2830 route with its IP field same as the gateway IP. This MAC/IP entry provides the
2831 nexthop VTEP and the tunnel information required for the VxLAN encapsulation.
2837 . +--------+ BGP +--------+ BGP +--------+ +--------+
2838 SN1 | | IPv4 | | EVPN | | | |
2839 ======+ Host1 +------+ PE1 +------+ PE2 +------+ Host2 +
2841 +--------+ +--------+ +--------+ +--------+
2843 Consider above topology where prefix SN1 is connected behind host1. Host1
2844 advertises SN1 to PE1 over BGP IPv4 session. PE1 advertises SN1 to PE2 using
2845 EVPN type-5 route with host1 IP as the gateway IP. PE1 also advertises
2846 Host1 MAC/IP as type-2 route which is used to resolve host1 gateway IP.
2848 PE2 receives this type-5 route and imports it into the vrf based on route
2849 targets. BGP prefix imported into the vrf uses gateway IP as its BGP nexthop.
2850 This route is installed into zebra if following conditions are satisfied:
2852 1. Gateway IP nexthop is L3 reachable.
2853 2. PE2 has received EVPN type-2 route with IP field set to gateway IP.
2855 Topology requirements:
2857 1. This feature is supported for asymmetric routing model only. While
2858 sending packets to SN1, ingress PE (PE2) performs routing and
2859 egress PE (PE1) performs only bridging.
2860 2. This feature supports only traditional(non vlan-aware) bridge model. Bridge
2861 interface associated with L2VNI is an L3 interface. i.e., this interface is
2862 configured with an address in the L2VNI subnet. Note that the gateway IP
2863 should also have an address in the same subnet.
2864 3. As this feature works in asymmetric routing model, all L2VNIs and corresponding
2865 VxLAN and bridge interfaces should be present at all the PEs.
2866 4. L3VNI configuration is required to generate and import EVPN type-5 routes.
2867 L3VNI VxLAN and bridge interfaces also should be present.
2869 A PE can use one of the following two mechanisms to advertise an EVPN type-5
2870 route with gateway IP.
2872 1. CLI to add gateway IP while generating EVPN type-5 route from a BGP IPv4/IPv6
2875 .. clicmd:: advertise <ipv4|ipv6> unicast [gateway-ip]
2877 When this CLI is configured for a BGP vrf under L2VPN EVPN address family, EVPN
2878 type-5 routes are generated for BGP prefixes in the vrf. Nexthop of the BGP
2879 prefix becomes the gateway IP of the corresponding type-5 route.
2881 If the above command is configured without the "gateway-ip" keyword, type-5
2882 routes are generated without overlay index.
2884 2. Add gateway IP to EVPN type-5 route using a route-map:
2886 .. clicmd:: set evpn gateway-ip <ipv4|ipv6> <addr>
2888 When route-map with above set clause is applied as outbound policy in BGP, it
2889 will set the gateway-ip in EVPN type-5 NLRI.
2891 Example configuration:
2896 neighbor 192.168.0.1 remote-as 101
2898 address-family ipv4 l2vpn evpn
2899 neighbor 192.168.0.1 route-map RMAP out
2902 route-map RMAP permit 10
2903 set evpn gateway-ip 10.0.0.1
2904 set evpn gateway-ip 10::1
2906 A PE that receives a type-5 route with gateway IP overlay index should have
2907 "enable-resolve-overlay-index" configuration enabled to recursively resolve the
2908 overlay index nexthop and install the prefix into zebra.
2910 .. clicmd:: enable-resolve-overlay-index
2912 Example configuration:
2917 bgp router-id 192.168.100.1
2918 no bgp ebgp-requires-policy
2919 neighbor 10.0.1.2 remote-as 65002
2921 address-family l2vpn evpn
2922 neighbor 10.0.1.2 activate
2924 enable-resolve-overlay-index
2931 All-Active Multihoming is used for redundancy and load sharing. Servers
2932 are attached to two or more PEs and the links are bonded (link-aggregation).
2933 This group of server links is referred to as an Ethernet Segment.
2937 An Ethernet Segment can be configured by specifying a system-MAC and a
2938 local discriminator against the bond interface on the PE (via zebra) -
2940 .. clicmd:: evpn mh es-id (1-16777215)
2942 .. clicmd:: evpn mh es-sys-mac X:X:X:X:X:X
2944 The sys-mac and local discriminator are used for generating a 10-byte,
2945 Type-3 Ethernet Segment ID.
2947 Type-1 (EAS-per-ES and EAD-per-EVI) routes are used to advertise the locally
2948 attached ESs and to learn off remote ESs in the network. Local Type-2/MAC-IP
2949 routes are also advertised with a destination ESI allowing for MAC-IP syncing
2950 between Ethernet Segment peers.
2951 Reference: RFC 7432, RFC 8365
2953 EVPN-MH is intended as a replacement for MLAG or Anycast VTEPs. In
2954 multihoming each PE has an unique VTEP address which requires the introduction
2955 of a new dataplane construct, MAC-ECMP. Here a MAC/FDB entry can point to a
2956 list of remote PEs/VTEPs.
2960 Type-4 (ESR) routes are used for Designated Forwarder (DF) election. DFs
2961 forward BUM traffic received via the overlay network. This implementation
2962 uses a preference based DF election specified by draft-ietf-bess-evpn-pref-df.
2963 The DF preference is configurable per-ES (via zebra) -
2965 .. clicmd:: evpn mh es-df-pref (1-16777215)
2967 BUM traffic is rxed via the overlay by all PEs attached to a server but
2968 only the DF can forward the de-capsulated traffic to the access port. To
2969 accommodate that non-DF filters are installed in the dataplane to drop
2972 Similarly traffic received from ES peers via the overlay cannot be forwarded
2973 to the server. This is split-horizon-filtering with local bias.
2977 Some vendors do not send EAD-per-EVI routes. To interop with them we
2978 need to relax the dependency on EAD-per-EVI routes and activate a remote
2979 ES-PE based on just the EAD-per-ES route.
2981 Note that by default we advertise and expect EAD-per-EVI routes.
2983 .. clicmd:: disable-ead-evi-rx
2985 .. clicmd:: disable-ead-evi-tx
2989 As the primary purpose of EVPN-MH is redundancy keeping the failover efficient
2990 is a recurring theme in the implementation. Following sub-features have
2991 been introduced for the express purpose of efficient ES failovers.
2993 - Layer-2 Nexthop Groups and MAC-ECMP via L2NHG.
2995 - Host routes (for symmetric IRB) via L3NHG.
2996 On dataplanes that support layer3 nexthop groups the feature can be turned
2997 on via the following BGP config -
2999 .. clicmd:: use-es-l3nhg
3001 - Local ES (MAC/Neigh) failover via ES-redirect.
3002 On dataplanes that do not have support for ES-redirect the feature can be
3003 turned off via the following zebra config -
3005 .. clicmd:: evpn mh redirect-off
3007 Uplink/Core tracking
3008 """"""""""""""""""""
3009 When all the underlay links go down the PE no longer has access to the VxLAN
3010 +overlay. To prevent blackholing of traffic the server/ES links are
3011 protodowned on the PE. A link can be setup for uplink tracking via the
3012 following zebra configuration -
3014 .. clicmd:: evpn mh uplink
3016 Proxy advertisements
3017 """"""""""""""""""""
3018 To handle hitless upgrades support for proxy advertisement has been added
3019 as specified by draft-rbickhart-evpn-ip-mac-proxy-adv. This allows a PE
3020 (say PE1) to proxy advertise a MAC-IP rxed from an ES peer (say PE2). When
3021 the ES peer (PE2) goes down PE1 continues to advertise hosts learnt from PE2
3022 for a holdtime during which it attempts to establish local reachability of
3023 the host. This holdtime is configurable via the following zebra commands -
3025 .. clicmd:: evpn mh neigh-holdtime (0-86400)
3027 .. clicmd:: evpn mh mac-holdtime (0-86400)
3031 When a switch is rebooted we wait for a brief period to allow the underlay
3032 and EVPN network to converge before enabling the ESs. For this duration the
3033 ES bonds are held protodown. The startup delay is configurable via the
3034 following zebra command -
3036 .. clicmd:: evpn mh startup-delay (0-3600)
3038 Support with VRF network namespace backend
3039 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3040 It is possible to separate overlay networks contained in VXLAN interfaces from
3041 underlay networks by using VRFs. VRF-lite and VRF-netns backends can be used for
3042 that. In the latter case, it is necessary to set both bridge and vxlan interface
3043 in the same network namespace, as below example illustrates:
3045 .. code-block:: shell
3049 ip link add name vxlan101 type vxlan id 101 dstport 4789 dev eth0 local 10.1.1.1
3050 ip link set dev vxlan101 netns vrf1
3051 ip netns exec vrf1 ip link set dev lo up
3052 ip netns exec vrf1 brctl addbr bridge101
3053 ip netns exec vrf1 brctl addif bridge101 vxlan101
3055 This makes it possible to separate not only layer 3 networks like VRF-lite networks.
3056 Also, VRF netns based make possible to separate layer 2 networks on separate VRF
3059 .. _bgp-conditional-advertisement:
3061 BGP Conditional Advertisement
3062 -----------------------------
3063 The BGP conditional advertisement feature uses the ``non-exist-map`` or the
3064 ``exist-map`` and the ``advertise-map`` keywords of the neighbor advertise-map
3065 command in order to track routes by the route prefix.
3068 1. If a route prefix is not present in the output of non-exist-map command,
3069 then advertise the route specified by the advertise-map command.
3071 2. If a route prefix is present in the output of non-exist-map command,
3072 then do not advertise the route specified by the addvertise-map command.
3075 1. If a route prefix is present in the output of exist-map command,
3076 then advertise the route specified by the advertise-map command.
3078 2. If a route prefix is not present in the output of exist-map command,
3079 then do not advertise the route specified by the advertise-map command.
3081 This feature is useful when some prefixes are advertised to one of its peers
3082 only if the information from the other peer is not present (due to failure in
3083 peering session or partial reachability etc).
3085 The conditional BGP announcements are sent in addition to the normal
3086 announcements that a BGP router sends to its peer.
3088 The conditional advertisement process is triggered by the BGP scanner process,
3089 which runs every 60 by default. This means that the maximum time for the
3090 conditional advertisement to take effect is the value of the process timer.
3092 As an optimization, while the process always runs on each timer expiry, it
3093 determines whether or not the conditional advertisement policy or the routing
3094 table has changed; if neither have changed, no processing is necessary and the
3095 scanner exits early.
3097 .. clicmd:: neighbor A.B.C.D advertise-map NAME [exist-map|non-exist-map] NAME
3099 This command enables BGP scanner process to monitor routes specified by
3100 exist-map or non-exist-map command in BGP table and conditionally advertises
3101 the routes specified by advertise-map command.
3103 .. clicmd:: bgp conditional-advertisement timer (5-240)
3105 Set the period to rerun the conditional advertisement scanner process. The
3106 default is 60 seconds.
3108 Sample Configuration
3109 ^^^^^^^^^^^^^^^^^^^^^
3113 ip address 10.10.10.2/24
3116 ip address 10.10.20.2/24
3119 ip address 203.0.113.1/32
3122 bgp log-neighbor-changes
3123 no bgp ebgp-requires-policy
3124 neighbor 10.10.10.1 remote-as 1
3125 neighbor 10.10.20.3 remote-as 3
3127 address-family ipv4 unicast
3128 neighbor 10.10.10.1 soft-reconfiguration inbound
3129 neighbor 10.10.20.3 soft-reconfiguration inbound
3130 neighbor 10.10.20.3 advertise-map ADV-MAP non-exist-map EXIST-MAP
3133 ip prefix-list DEFAULT seq 5 permit 192.0.2.5/32
3134 ip prefix-list DEFAULT seq 10 permit 192.0.2.1/32
3135 ip prefix-list EXIST seq 5 permit 10.10.10.10/32
3136 ip prefix-list DEFAULT-ROUTE seq 5 permit 0.0.0.0/0
3137 ip prefix-list IP1 seq 5 permit 10.139.224.0/20
3139 bgp community-list standard DC-ROUTES seq 5 permit 64952:3008
3140 bgp community-list standard DC-ROUTES seq 10 permit 64671:501
3141 bgp community-list standard DC-ROUTES seq 15 permit 64950:3009
3142 bgp community-list standard DEFAULT-ROUTE seq 5 permit 65013:200
3144 route-map ADV-MAP permit 10
3145 match ip address prefix-list IP1
3147 route-map ADV-MAP permit 20
3148 match community DC-ROUTES
3150 route-map EXIST-MAP permit 10
3151 match community DEFAULT-ROUTE
3152 match ip address prefix-list DEFAULT-ROUTE
3158 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.
3162 Router2# show ip bgp
3163 BGP table version is 20, local router ID is 203.0.113.1, vrf id 0
3164 Default local pref 100, local AS 2
3165 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
3166 i internal, r RIB-failure, S Stale, R Removed
3167 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
3168 Origin codes: i - IGP, e - EGP, ? - incomplete
3169 RPKI validation codes: V valid, I invalid, N Not found
3171 Network Next Hop Metric LocPrf Weight Path
3172 *> 0.0.0.0/0 10.10.10.1 0 0 1 i
3173 *> 10.139.224.0/20 10.10.10.1 0 0 1 ?
3174 *> 192.0.2.1/32 10.10.10.1 0 0 1 i
3175 *> 192.0.2.5/32 10.10.10.1 0 0 1 i
3177 Displayed 4 routes and 4 total paths
3178 Router2# show ip bgp neighbors 10.10.20.3
3180 !--- Output suppressed.
3182 For address family: IPv4 Unicast
3183 Update group 7, subgroup 7
3184 Packet Queue length 0
3185 Inbound soft reconfiguration allowed
3186 Community attribute sent to this neighbor(all)
3187 Condition NON_EXIST, Condition-map *EXIST-MAP, Advertise-map *ADV-MAP, status: Withdraw
3190 !--- Output suppressed.
3192 Router2# show ip bgp neighbors 10.10.20.3 advertised-routes
3193 BGP table version is 20, local router ID is 203.0.113.1, vrf id 0
3194 Default local pref 100, local AS 2
3195 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
3196 i internal, r RIB-failure, S Stale, R Removed
3197 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
3198 Origin codes: i - IGP, e - EGP, ? - incomplete
3199 RPKI validation codes: V valid, I invalid, N Not found
3201 Network Next Hop Metric LocPrf Weight Path
3202 *> 0.0.0.0/0 0.0.0.0 0 1 i
3203 *> 192.0.2.5/32 0.0.0.0 0 1 i
3205 Total number of prefixes 2
3207 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.
3211 Router2# show ip bgp
3212 BGP table version is 21, local router ID is 203.0.113.1, vrf id 0
3213 Default local pref 100, local AS 2
3214 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
3215 i internal, r RIB-failure, S Stale, R Removed
3216 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
3217 Origin codes: i - IGP, e - EGP, ? - incomplete
3218 RPKI validation codes: V valid, I invalid, N Not found
3220 Network Next Hop Metric LocPrf Weight Path
3221 *> 10.139.224.0/20 10.10.10.1 0 0 1 ?
3222 *> 192.0.2.1/32 10.10.10.1 0 0 1 i
3223 *> 192.0.2.5/32 10.10.10.1 0 0 1 i
3225 Displayed 3 routes and 3 total paths
3227 Router2# show ip bgp neighbors 10.10.20.3
3229 !--- Output suppressed.
3231 For address family: IPv4 Unicast
3232 Update group 7, subgroup 7
3233 Packet Queue length 0
3234 Inbound soft reconfiguration allowed
3235 Community attribute sent to this neighbor(all)
3236 Condition NON_EXIST, Condition-map *EXIST-MAP, Advertise-map *ADV-MAP, status: Advertise
3239 !--- Output suppressed.
3241 Router2# show ip bgp neighbors 10.10.20.3 advertised-routes
3242 BGP table version is 21, local router ID is 203.0.113.1, vrf id 0
3243 Default local pref 100, local AS 2
3244 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
3245 i internal, r RIB-failure, S Stale, R Removed
3246 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
3247 Origin codes: i - IGP, e - EGP, ? - incomplete
3248 RPKI validation codes: V valid, I invalid, N Not found
3250 Network Next Hop Metric LocPrf Weight Path
3251 *> 10.139.224.0/20 0.0.0.0 0 1 ?
3252 *> 192.0.2.1/32 0.0.0.0 0 1 i
3253 *> 192.0.2.5/32 0.0.0.0 0 1 i
3255 Total number of prefixes 3
3263 .. clicmd:: show debug
3265 Show all enabled debugs.
3267 .. clicmd:: show bgp listeners
3269 Display Listen sockets and the vrf that created them. Useful for debugging of when
3270 listen is not working and this is considered a developer debug statement.
3272 .. clicmd:: debug bgp bfd
3274 Enable or disable debugging for BFD events. This will show BFD integration
3275 library messages and BGP BFD integration messages that are mostly state
3276 transitions and validation problems.
3278 .. clicmd:: debug bgp neighbor-events
3280 Enable or disable debugging for neighbor events. This provides general
3281 information on BGP events such as peer connection / disconnection, session
3282 establishment / teardown, and capability negotiation.
3284 .. clicmd:: debug bgp updates
3286 Enable or disable debugging for BGP updates. This provides information on
3287 BGP UPDATE messages transmitted and received between local and remote
3290 .. clicmd:: debug bgp keepalives
3292 Enable or disable debugging for BGP keepalives. This provides information on
3293 BGP KEEPALIVE messages transmitted and received between local and remote
3296 .. clicmd:: debug bgp bestpath <A.B.C.D/M|X:X::X:X/M>
3298 Enable or disable debugging for bestpath selection on the specified prefix.
3300 .. clicmd:: debug bgp nht
3302 Enable or disable debugging of BGP nexthop tracking.
3304 .. clicmd:: debug bgp update-groups
3306 Enable or disable debugging of dynamic update groups. This provides general
3307 information on group creation, deletion, join and prune events.
3309 .. clicmd:: debug bgp zebra
3311 Enable or disable debugging of communications between *bgpd* and *zebra*.
3313 Dumping Messages and Routing Tables
3314 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3316 .. clicmd:: dump bgp all PATH [INTERVAL]
3318 .. clicmd:: dump bgp all-et PATH [INTERVAL]
3321 Dump all BGP packet and events to `path` file.
3322 If `interval` is set, a new file will be created for echo `interval` of
3323 seconds. The path `path` can be set with date and time formatting
3324 (strftime). The type ‘all-et’ enables support for Extended Timestamp Header
3325 (:ref:`packet-binary-dump-format`).
3327 .. clicmd:: dump bgp updates PATH [INTERVAL]
3329 .. clicmd:: dump bgp updates-et PATH [INTERVAL]
3332 Dump only BGP updates messages to `path` file.
3333 If `interval` is set, a new file will be created for echo `interval` of
3334 seconds. The path `path` can be set with date and time formatting
3335 (strftime). The type ‘updates-et’ enables support for Extended Timestamp
3336 Header (:ref:`packet-binary-dump-format`).
3338 .. clicmd:: dump bgp routes-mrt PATH
3340 .. clicmd:: dump bgp routes-mrt PATH INTERVAL
3343 Dump whole BGP routing table to `path`. This is heavy process. The path
3344 `path` can be set with date and time formatting (strftime). If `interval` is
3345 set, a new file will be created for echo `interval` of seconds.
3347 Note: the interval variable can also be set using hours and minutes: 04h20m00.
3350 .. _bgp-other-commands:
3355 The following are available in the top level *enable* mode:
3357 .. clicmd:: clear bgp \*
3361 .. clicmd:: clear bgp ipv4|ipv6 \*
3363 Clear all peers with this address-family activated.
3365 .. clicmd:: clear bgp ipv4|ipv6 unicast \*
3367 Clear all peers with this address-family and sub-address-family activated.
3369 .. clicmd:: clear bgp ipv4|ipv6 PEER
3371 Clear peers with address of X.X.X.X and this address-family activated.
3373 .. clicmd:: clear bgp ipv4|ipv6 unicast PEER
3375 Clear peer with address of X.X.X.X and this address-family and sub-address-family activated.
3377 .. clicmd:: clear bgp ipv4|ipv6 PEER soft|in|out
3379 Clear peer using soft reconfiguration in this address-family.
3381 .. clicmd:: clear bgp ipv4|ipv6 unicast PEER soft|in|out
3383 Clear peer using soft reconfiguration in this address-family and sub-address-family.
3385 The following are available in the ``router bgp`` mode:
3387 .. clicmd:: write-quanta (1-64)
3389 BGP message Tx I/O is vectored. This means that multiple packets are written
3390 to the peer socket at the same time each I/O cycle, in order to minimize
3391 system call overhead. This value controls how many are written at a time.
3392 Under certain load conditions, reducing this value could make peer traffic
3393 less 'bursty'. In practice, leave this settings on the default (64) unless
3394 you truly know what you are doing.
3396 .. clicmd:: read-quanta (1-10)
3398 Unlike Tx, BGP Rx traffic is not vectored. Packets are read off the wire one
3399 at a time in a loop. This setting controls how many iterations the loop runs
3400 for. As with write-quanta, it is best to leave this setting on the default.
3402 The following command is available in ``config`` mode as well as in the
3403 ``router bgp`` mode:
3405 .. clicmd:: bgp graceful-shutdown
3407 The purpose of this command is to initiate BGP Graceful Shutdown which
3408 is described in :rfc:`8326`. The use case for this is to minimize or
3409 eliminate the amount of traffic loss in a network when a planned
3410 maintenance activity such as software upgrade or hardware replacement
3411 is to be performed on a router. The feature works by re-announcing
3412 routes to eBGP peers with the GRACEFUL_SHUTDOWN community included.
3413 Peers are then expected to treat such paths with the lowest preference.
3414 This happens automatically on a receiver running FRR; with other
3415 routing protocol stacks, an inbound policy may have to be configured.
3416 In FRR, triggering graceful shutdown also results in announcing a
3417 LOCAL_PREF of 0 to iBGP peers.
3419 Graceful shutdown can be configured per BGP instance or globally for
3420 all of BGP. These two options are mutually exclusive. The no form of
3421 the command causes graceful shutdown to be stopped, and routes will
3422 be re-announced without the GRACEFUL_SHUTDOWN community and/or with
3423 the usual LOCAL_PREF value. Note that if this option is saved to
3424 the startup configuration, graceful shutdown will remain in effect
3425 across restarts of *bgpd* and will need to be explicitly disabled.
3427 .. _bgp-displaying-bgp-information:
3429 Displaying BGP Information
3430 ==========================
3432 The following four commands display the IPv6 and IPv4 routing tables, depending
3433 on whether or not the ``ip`` keyword is used.
3434 Actually, :clicmd:`show ip bgp` command was used on older `Quagga` routing
3435 daemon project, while :clicmd:`show bgp` command is the new format. The choice
3436 has been done to keep old format with IPv4 routing table, while new format
3437 displays IPv6 routing table.
3439 .. clicmd:: show ip bgp [all] [wide|json [detail]]
3441 .. clicmd:: show ip bgp A.B.C.D [json]
3443 .. clicmd:: show bgp [all] [wide|json [detail]]
3445 .. clicmd:: show bgp X:X::X:X [json]
3447 These commands display BGP routes. When no route is specified, the default
3448 is to display all BGP routes.
3452 BGP table version is 0, local router ID is 10.1.1.1
3453 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
3454 Origin codes: i - IGP, e - EGP, ? - incomplete
3456 Network Next Hop Metric LocPrf Weight Path
3457 \*> 1.1.1.1/32 0.0.0.0 0 32768 i
3459 Total number of prefixes 1
3461 If ``wide`` option is specified, then the prefix table's width is increased
3462 to fully display the prefix and the nexthop.
3464 This is especially handy dealing with IPv6 prefixes and
3465 if :clicmd:`[no] bgp default show-nexthop-hostname` is enabled.
3467 If ``all`` option is specified, ``ip`` keyword is ignored, show bgp all and
3468 show ip bgp all commands display routes for all AFIs and SAFIs.
3470 If ``json`` option is specified, output is displayed in JSON format.
3472 If ``detail`` option is specified after ``json``, more verbose JSON output
3475 Some other commands provide additional options for filtering the output.
3477 .. clicmd:: show [ip] bgp regexp LINE
3479 This command displays BGP routes using AS path regular expression
3480 (:ref:`bgp-regular-expressions`).
3482 .. clicmd:: show [ip] bgp [all] summary [wide] [json]
3484 Show a bgp peer summary for the specified address family.
3486 The old command structure :clicmd:`show ip bgp` may be removed in the future
3487 and should no longer be used. In order to reach the other BGP routing tables
3488 other than the IPv6 routing table given by :clicmd:`show bgp`, the new command
3489 structure is extended with :clicmd:`show bgp [afi] [safi]`.
3491 ``wide`` option gives more output like ``LocalAS`` and extended ``Desc`` to
3496 exit1# show ip bgp summary wide
3498 IPv4 Unicast Summary (VRF default):
3499 BGP router identifier 192.168.100.1, local AS number 65534 vrf-id 0
3501 RIB entries 5, using 920 bytes of memory
3502 Peers 1, using 27 KiB of memory
3504 Neighbor V AS LocalAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
3505 192.168.0.2 4 65030 123 15 22 0 0 0 00:07:00 0 1 us-east1-rs1.frrouting.org
3507 Total number of neighbors 1
3510 .. clicmd:: show bgp [afi] [safi] [all] [wide|json]
3512 .. clicmd:: show bgp [<ipv4|ipv6> <unicast|multicast|vpn|labeled-unicast|flowspec> | l2vpn evpn]
3514 These commands display BGP routes for the specific routing table indicated by
3515 the selected afi and the selected safi. If no afi and no safi value is given,
3516 the command falls back to the default IPv6 routing table.
3518 .. clicmd:: show bgp l2vpn evpn route [type <macip|2|multicast|3|es|4|prefix|5>]
3520 EVPN prefixes can also be filtered by EVPN route type.
3522 .. clicmd:: show bgp [afi] [safi] [all] summary [json]
3524 Show a bgp peer summary for the specified address family, and subsequent
3527 .. clicmd:: show bgp [afi] [safi] [all] summary failed [json]
3529 Show a bgp peer summary for peers that are not successfully exchanging routes
3530 for the specified address family, and subsequent address-family.
3532 .. clicmd:: show bgp [afi] [safi] [all] summary established [json]
3534 Show a bgp peer summary for peers that are successfully exchanging routes
3535 for the specified address family, and subsequent address-family.
3537 .. clicmd:: show bgp [afi] [safi] [all] summary neighbor [PEER] [json]
3539 Show a bgp summary for the specified peer, address family, and
3540 subsequent address-family. The neighbor filter can be used in combination
3541 with the failed, established filters.
3543 .. clicmd:: show bgp [afi] [safi] [all] summary remote-as <internal|external|ASN> [json]
3545 Show a bgp peer summary for the specified remote-as ASN or type (``internal``
3546 for iBGP and ``external`` for eBGP sessions), address family, and subsequent
3547 address-family. The remote-as filter can be used in combination with the
3548 failed, established filters.
3550 .. clicmd:: show bgp [afi] [safi] [all] summary terse [json]
3552 Shorten the output. Do not show the following information about the BGP
3553 instances: the number of RIB entries, the table version and the used memory.
3554 The ``terse`` option can be used in combination with the remote-as, neighbor,
3555 failed and established filters, and with the ``wide`` option as well.
3557 .. clicmd:: show bgp [afi] [safi] [neighbor [PEER] [routes|advertised-routes|received-routes] [json]
3559 This command shows information on a specific BGP peer of the relevant
3560 afi and safi selected.
3562 The ``routes`` keyword displays only routes in this address-family's BGP
3563 table that were received by this peer and accepted by inbound policy.
3565 The ``advertised-routes`` keyword displays only the routes in this
3566 address-family's BGP table that were permitted by outbound policy and
3567 advertised to to this peer.
3569 The ``received-routes`` keyword displays all routes belonging to this
3570 address-family (prior to inbound policy) that were received by this peer.
3572 .. clicmd:: show bgp [<view|vrf> VIEWVRFNAME] [afi] [safi] neighbors PEER received prefix-filter [json]
3574 Display Address Prefix ORFs received from this peer.
3576 .. clicmd:: show bgp [afi] [safi] [all] dampening dampened-paths [wide|json]
3578 Display paths suppressed due to dampening of the selected afi and safi
3581 .. clicmd:: show bgp [afi] [safi] [all] dampening flap-statistics [wide|json]
3583 Display flap statistics of routes of the selected afi and safi selected.
3585 .. clicmd:: show bgp [afi] [safi] [all] dampening parameters [json]
3587 Display details of configured dampening parameters of the selected afi and
3590 If the ``json`` option is specified, output is displayed in JSON format.
3592 .. clicmd:: show bgp [afi] [safi] [all] version (1-4294967295) [wide|json]
3594 Display prefixes with matching version numbers. The version number and
3595 above having prefixes will be listed here.
3597 It helps to identify which prefixes were installed at some point.
3599 Here is an example of how to check what prefixes were installed starting
3600 with an arbitrary version:
3602 .. code-block:: shell
3604 # vtysh -c 'show bgp ipv4 unicast json' | jq '.tableVersion'
3606 # vtysh -c 'show ip bgp version 9 json' | jq -r '.routes | keys[]'
3608 # vtysh -c 'show ip bgp version 8 json' | jq -r '.routes | keys[]'
3612 .. clicmd:: show bgp [afi] [safi] statistics
3614 Display statistics of routes of the selected afi and safi.
3616 .. clicmd:: show bgp statistics-all
3618 Display statistics of routes of all the afi and safi.
3620 .. clicmd:: show [ip] bgp [afi] [safi] [all] cidr-only [wide|json]
3622 Display routes with non-natural netmasks.
3624 .. clicmd:: show [ip] bgp [afi] [safi] [all] prefix-list WORD [wide|json]
3626 Display routes that match the specified prefix-list.
3628 If ``wide`` option is specified, then the prefix table's width is increased
3629 to fully display the prefix and the nexthop.
3631 If the ``json`` option is specified, output is displayed in JSON format.
3633 .. clicmd:: show [ip] bgp [afi] [safi] [all] filter-list WORD [wide|json]
3635 Display routes that match the specified AS-Path filter-list.
3637 If ``wide`` option is specified, then the prefix table's width is increased
3638 to fully display the prefix and the nexthop.
3640 If the ``json`` option is specified, output is displayed in JSON format.
3642 .. clicmd:: show [ip] bgp [afi] [safi] [all] route-map WORD [wide|json]
3644 Display routes that match the specified route-map.
3646 If ``wide`` option is specified, then the prefix table's width is increased
3647 to fully display the prefix and the nexthop.
3649 If the ``json`` option is specified, output is displayed in JSON format.
3651 .. clicmd:: show [ip] bgp [afi] [safi] [all] <A.B.C.D/M|X:X::X:X/M> longer-prefixes [wide|json]
3653 Displays the specified route and all more specific routes.
3655 If ``wide`` option is specified, then the prefix table's width is increased
3656 to fully display the prefix and the nexthop.
3658 If the ``json`` option is specified, output is displayed in JSON format.
3660 .. clicmd:: show [ip] bgp [afi] [safi] [all] neighbors A.B.C.D [advertised-routes|received-routes|filtered-routes] [json|wide]
3662 Display the routes advertised to a BGP neighbor or received routes
3663 from neighbor or filtered routes received from neighbor based on the
3666 If ``wide`` option is specified, then the prefix table's width is increased
3667 to fully display the prefix and the nexthop.
3669 This is especially handy dealing with IPv6 prefixes and
3670 if :clicmd:`[no] bgp default show-nexthop-hostname` is enabled.
3672 If ``all`` option is specified, ``ip`` keyword is ignored and,
3673 routes displayed for all AFIs and SAFIs.
3674 if afi is specified, with ``all`` option, routes will be displayed for
3675 each SAFI in the selcted AFI
3677 If ``json`` option is specified, output is displayed in JSON format.
3679 .. _bgp-display-routes-by-community:
3681 Displaying Routes by Community Attribute
3682 ----------------------------------------
3684 The following commands allow displaying routes based on their community
3687 .. clicmd:: show [ip] bgp <ipv4|ipv6> [all] community [wide|json]
3689 .. clicmd:: show [ip] bgp <ipv4|ipv6> [all] community COMMUNITY [wide|json]
3691 .. clicmd:: show [ip] bgp <ipv4|ipv6> [all] community COMMUNITY exact-match [wide|json]
3693 These commands display BGP routes which have the community attribute.
3694 attribute. When ``COMMUNITY`` is specified, BGP routes that match that
3695 community are displayed. When `exact-match` is specified, it display only
3696 routes that have an exact match.
3698 .. clicmd:: show [ip] bgp <ipv4|ipv6> community-list WORD [json]
3700 .. clicmd:: show [ip] bgp <ipv4|ipv6> community-list WORD exact-match [json]
3702 These commands display BGP routes for the address family specified that
3703 match the specified community list. When `exact-match` is specified, it
3704 displays only routes that have an exact match.
3706 If ``wide`` option is specified, then the prefix table's width is increased
3707 to fully display the prefix and the nexthop.
3709 This is especially handy dealing with IPv6 prefixes and
3710 if :clicmd:`[no] bgp default show-nexthop-hostname` is enabled.
3712 If ``all`` option is specified, ``ip`` keyword is ignored and,
3713 routes displayed for all AFIs and SAFIs.
3714 if afi is specified, with ``all`` option, routes will be displayed for
3715 each SAFI in the selcted AFI
3717 If ``json`` option is specified, output is displayed in JSON format.
3719 .. clicmd:: show bgp labelpool <chunks|inuse|ledger|requests|summary> [json]
3721 These commands display information about the BGP labelpool used for
3722 the association of MPLS labels with routes for L3VPN and Labeled Unicast
3724 If ``chunks`` option is specified, output shows the current list of label
3725 chunks granted to BGP by Zebra, indicating the start and end label in
3728 If ``inuse`` option is specified, output shows the current inuse list of
3729 label to prefix mappings
3731 If ``ledger`` option is specified, output shows ledger list of all
3732 label requests made per prefix
3734 If ``requests`` option is specified, output shows current list of label
3735 requests which have not yet been fulfilled by the labelpool
3737 If ``summary`` option is specified, output is a summary of the counts for
3738 the chunks, inuse, ledger and requests list along with the count of
3739 outstanding chunk requests to Zebra and the number of zebra reconnects
3742 If ``json`` option is specified, output is displayed in JSON format.
3744 .. _bgp-display-routes-by-lcommunity:
3746 Displaying Routes by Large Community Attribute
3747 ----------------------------------------------
3749 The following commands allow displaying routes based on their
3750 large community attribute.
3752 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community
3754 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY
3756 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY exact-match
3758 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY json
3760 These commands display BGP routes which have the large community attribute.
3761 attribute. When ``LARGE-COMMUNITY`` is specified, BGP routes that match that
3762 large community are displayed. When `exact-match` is specified, it display
3763 only routes that have an exact match. When `json` is specified, it display
3764 routes in json format.
3766 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community-list WORD
3768 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community-list WORD exact-match
3770 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community-list WORD json
3772 These commands display BGP routes for the address family specified that
3773 match the specified large community list. When `exact-match` is specified,
3774 it displays only routes that have an exact match. When `json` is specified,
3775 it display routes in json format.
3777 .. _bgp-display-routes-by-as-path:
3780 Displaying Routes by AS Path
3781 ----------------------------
3783 .. clicmd:: show bgp ipv4|ipv6 regexp LINE
3785 This commands displays BGP routes that matches a regular
3786 expression `line` (:ref:`bgp-regular-expressions`).
3788 .. clicmd:: show [ip] bgp ipv4 vpn
3790 .. clicmd:: show [ip] bgp ipv6 vpn
3792 Print active IPV4 or IPV6 routes advertised via the VPN SAFI.
3794 .. clicmd:: show bgp ipv4 vpn summary
3796 .. clicmd:: show bgp ipv6 vpn summary
3798 Print a summary of neighbor connections for the specified AFI/SAFI combination.
3800 Displaying Routes by Route Distinguisher
3801 ----------------------------------------
3803 .. clicmd:: show bgp [<ipv4|ipv6> vpn | l2vpn evpn [route]] rd <all|RD>
3805 For L3VPN and EVPN address-families, routes can be displayed on a per-RD
3806 (Route Distinguisher) basis or for all RD's.
3808 .. clicmd:: show bgp l2vpn evpn rd <all|RD> [overlay | tags]
3810 Use the ``overlay`` or ``tags`` keywords to display the overlay/tag
3811 information about the EVPN prefixes in the selected Route Distinguisher.
3813 .. clicmd:: show bgp l2vpn evpn route rd <all|RD> mac <MAC> [ip <MAC>] [json]
3815 For EVPN Type 2 (macip) routes, a MAC address (and optionally an IP address)
3816 can be supplied to the command to only display matching prefixes in the
3819 Displaying Update Group Information
3820 -----------------------------------
3822 .. clicmd:: show bgp update-groups [advertise-queue|advertised-routes|packet-queue]
3824 Display Information about each individual update-group being used.
3825 If SUBGROUP-ID is specified only display about that particular group. If
3826 advertise-queue is specified the list of routes that need to be sent
3827 to the peers in the update-group is displayed, advertised-routes means
3828 the list of routes we have sent to the peers in the update-group and
3829 packet-queue specifies the list of packets in the queue to be sent.
3831 .. clicmd:: show bgp update-groups statistics
3833 Display Information about update-group events in FRR.
3835 Segment-Routing IPv6
3836 --------------------
3838 .. clicmd:: show bgp segment-routing srv6
3840 This command displays information about SRv6 L3VPN in bgpd. Specifically,
3841 what kind of Locator is being used, and its Locator chunk information.
3842 And the SID of the SRv6 Function that is actually managed on bgpd.
3843 In the following example, bgpd is using a Locator named loc1, and two SRv6
3844 Functions are managed to perform VPNv6 VRF redirect for vrf10 and vrf20.
3848 router# show bgp segment-routing srv6
3853 - sid: 2001:db8:1:1::100
3855 - sid: 2001:db8:1:1::200
3859 vpn_policy[AFI_IP].tovpn_sid: none
3860 vpn_policy[AFI_IP6].tovpn_sid: none
3862 vpn_policy[AFI_IP].tovpn_sid: none
3863 vpn_policy[AFI_IP6].tovpn_sid: 2001:db8:1:1::100
3865 vpn_policy[AFI_IP].tovpn_sid: none
3866 vpn_policy[AFI_IP6].tovpn_sid: 2001:db8:1:1::200
3869 .. _bgp-route-reflector:
3874 BGP routers connected inside the same AS through BGP belong to an internal
3875 BGP session, or IBGP. In order to prevent routing table loops, IBGP does not
3876 advertise IBGP-learned routes to other routers in the same session. As such,
3877 IBGP requires a full mesh of all peers. For large networks, this quickly becomes
3878 unscalable. Introducing route reflectors removes the need for the full-mesh.
3880 When route reflectors are configured, these will reflect the routes announced
3881 by the peers configured as clients. A route reflector client is configured
3884 .. clicmd:: neighbor PEER route-reflector-client
3887 To avoid single points of failure, multiple route reflectors can be configured.
3889 A cluster is a collection of route reflectors and their clients, and is used
3890 by route reflectors to avoid looping.
3892 .. clicmd:: bgp cluster-id A.B.C.D
3894 .. clicmd:: bgp no-rib
3896 To set and unset the BGP daemon ``-n`` / ``--no_kernel`` options during runtime
3897 to disable BGP route installation to the RIB (Zebra), the ``[no] bgp no-rib``
3898 commands can be used;
3900 Please note that setting the option during runtime will withdraw all routes in
3901 the daemons RIB from Zebra and unsetting it will announce all routes in the
3902 daemons RIB to Zebra. If the option is passed as a command line argument when
3903 starting the daemon and the configuration gets saved, the option will persist
3904 unless removed from the configuration with the negating command prior to the
3905 configuration write operation.
3907 .. clicmd:: bgp send-extra-data zebra
3909 This Command turns off the ability of BGP to send extra data to zebra.
3910 In this case it's the AS-Path being used for the path. The default behavior
3911 in BGP is to send this data and to turn it off enter the no form of the command.
3912 If extra data was sent to zebra, and this command is turned on there is no
3913 effort to clean up this data in the rib.
3915 .. _bgp-suppress-fib:
3917 Suppressing routes not installed in FIB
3918 =======================================
3920 The FRR implementation of BGP advertises prefixes learnt from a peer to other
3921 peers even if the routes do not get installed in the FIB. There can be
3922 scenarios where the hardware tables in some of the routers (along the path from
3923 the source to destination) is full which will result in all routes not getting
3924 installed in the FIB. If these routes are advertised to the downstream routers
3925 then traffic will start flowing and will be dropped at the intermediate router.
3927 The solution is to provide a configurable option to check for the FIB install
3928 status of the prefixes and advertise to peers if the prefixes are successfully
3929 installed in the FIB. The advertisement of the prefixes are suppressed if it is
3930 not installed in FIB.
3932 The following conditions apply will apply when checking for route installation
3935 1. The advertisement or suppression of routes based on FIB install status
3936 applies only for newly learnt routes from peer (routes which are not in
3938 2. If the route received from peer already exists in BGP local RIB and route
3939 attributes have changed (best path changed), the old path is deleted and
3940 new path is installed in FIB. The FIB install status will not have any
3941 effect. Therefore only when the route is received first time the checks
3943 3. The feature will not apply for routes learnt through other means like
3944 redistribution to bgp from other protocols. This is applicable only to
3946 4. If a route is installed in FIB and then gets deleted from the dataplane,
3947 then routes will not be withdrawn from peers. This will be considered as
3949 5. The feature will slightly increase the time required to advertise the routes
3950 to peers since the route install status needs to be received from the FIB
3951 6. If routes are received by the peer before the configuration is applied, then
3952 the bgp sessions need to be reset for the configuration to take effect.
3953 7. If the route which is already installed in dataplane is removed for some
3954 reason, sending withdraw message to peers is not currently supported.
3956 .. clicmd:: bgp suppress-fib-pending
3958 This command is applicable at the global level and at an individual
3959 bgp level. If applied at the global level all bgp instances will
3960 wait for fib installation before announcing routes and there is no
3961 way to turn it off for a particular bgp vrf.
3968 You can set different routing policy for a peer. For example, you can set
3969 different filter for a peer.
3975 neighbor 10.0.0.1 remote-as 2
3976 address-family ipv4 unicast
3977 neighbor 10.0.0.1 distribute-list 1 in
3981 neighbor 10.0.0.1 remote-as 2
3982 address-family ipv4 unicast
3983 neighbor 10.0.0.1 distribute-list 2 in
3986 This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view 2.
3987 When the update is inserted into view 1, distribute-list 1 is applied. On the
3988 other hand, when the update is inserted into view 2, distribute-list 2 is
3992 .. _bgp-regular-expressions:
3994 BGP Regular Expressions
3995 =======================
3997 BGP regular expressions are based on :t:`POSIX 1003.2` regular expressions. The
3998 following description is just a quick subset of the POSIX regular expressions.
4002 Matches any single character.
4005 Matches 0 or more occurrences of pattern.
4008 Matches 1 or more occurrences of pattern.
4011 Match 0 or 1 occurrences of pattern.
4014 Matches the beginning of the line.
4017 Matches the end of the line.
4020 The ``_`` character has special meanings in BGP regular expressions. It
4021 matches to space and comma , and AS set delimiter ``{`` and ``}`` and AS
4022 confederation delimiter ``(`` and ``)``. And it also matches to the
4023 beginning of the line and the end of the line. So ``_`` can be used for AS
4024 value boundaries match. This character technically evaluates to
4028 .. _bgp-configuration-examples:
4030 Miscellaneous Configuration Examples
4031 ====================================
4033 Example of a session to an upstream, advertising only one prefix to it.
4038 bgp router-id 10.236.87.1
4039 neighbor upstream peer-group
4040 neighbor upstream remote-as 64515
4041 neighbor upstream capability dynamic
4042 neighbor 10.1.1.1 peer-group upstream
4043 neighbor 10.1.1.1 description ACME ISP
4045 address-family ipv4 unicast
4046 network 10.236.87.0/24
4047 neighbor upstream prefix-list pl-allowed-adv out
4050 ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
4051 ip prefix-list pl-allowed-adv seq 10 deny any
4053 A more complex example including upstream, peer and customer sessions
4054 advertising global prefixes and NO_EXPORT prefixes and providing actions for
4055 customer routes based on community values. Extensive use is made of route-maps
4056 and the 'call' feature to support selective advertising of prefixes. This
4057 example is intended as guidance only, it has NOT been tested and almost
4058 certainly contains silly mistakes, if not serious flaws.
4063 bgp router-id 10.236.87.1
4064 neighbor upstream capability dynamic
4065 neighbor cust capability dynamic
4066 neighbor peer capability dynamic
4067 neighbor 10.1.1.1 remote-as 64515
4068 neighbor 10.1.1.1 peer-group upstream
4069 neighbor 10.2.1.1 remote-as 64516
4070 neighbor 10.2.1.1 peer-group upstream
4071 neighbor 10.3.1.1 remote-as 64517
4072 neighbor 10.3.1.1 peer-group cust-default
4073 neighbor 10.3.1.1 description customer1
4074 neighbor 10.4.1.1 remote-as 64518
4075 neighbor 10.4.1.1 peer-group cust
4076 neighbor 10.4.1.1 description customer2
4077 neighbor 10.5.1.1 remote-as 64519
4078 neighbor 10.5.1.1 peer-group peer
4079 neighbor 10.5.1.1 description peer AS 1
4080 neighbor 10.6.1.1 remote-as 64520
4081 neighbor 10.6.1.1 peer-group peer
4082 neighbor 10.6.1.1 description peer AS 2
4084 address-family ipv4 unicast
4085 network 10.123.456.0/24
4086 network 10.123.456.128/25 route-map rm-no-export
4087 neighbor upstream route-map rm-upstream-out out
4088 neighbor cust route-map rm-cust-in in
4089 neighbor cust route-map rm-cust-out out
4090 neighbor cust send-community both
4091 neighbor peer route-map rm-peer-in in
4092 neighbor peer route-map rm-peer-out out
4093 neighbor peer send-community both
4094 neighbor 10.3.1.1 prefix-list pl-cust1-network in
4095 neighbor 10.4.1.1 prefix-list pl-cust2-network in
4096 neighbor 10.5.1.1 prefix-list pl-peer1-network in
4097 neighbor 10.6.1.1 prefix-list pl-peer2-network in
4100 ip prefix-list pl-default permit 0.0.0.0/0
4102 ip prefix-list pl-upstream-peers permit 10.1.1.1/32
4103 ip prefix-list pl-upstream-peers permit 10.2.1.1/32
4105 ip prefix-list pl-cust1-network permit 10.3.1.0/24
4106 ip prefix-list pl-cust1-network permit 10.3.2.0/24
4108 ip prefix-list pl-cust2-network permit 10.4.1.0/24
4110 ip prefix-list pl-peer1-network permit 10.5.1.0/24
4111 ip prefix-list pl-peer1-network permit 10.5.2.0/24
4112 ip prefix-list pl-peer1-network permit 192.168.0.0/24
4114 ip prefix-list pl-peer2-network permit 10.6.1.0/24
4115 ip prefix-list pl-peer2-network permit 10.6.2.0/24
4116 ip prefix-list pl-peer2-network permit 192.168.1.0/24
4117 ip prefix-list pl-peer2-network permit 192.168.2.0/24
4118 ip prefix-list pl-peer2-network permit 172.16.1/24
4120 bgp as-path access-list seq 5 asp-own-as permit ^$
4121 bgp as-path access-list seq 10 asp-own-as permit _64512_
4123 ! #################################################################
4124 ! Match communities we provide actions for, on routes receives from
4125 ! customers. Communities values of <our-ASN>:X, with X, have actions:
4127 ! 100 - blackhole the prefix
4128 ! 200 - set no_export
4129 ! 300 - advertise only to other customers
4130 ! 400 - advertise only to upstreams
4131 ! 500 - set no_export when advertising to upstreams
4132 ! 2X00 - set local_preference to X00
4134 ! blackhole the prefix of the route
4135 bgp community-list standard cm-blackhole permit 64512:100
4137 ! set no-export community before advertising
4138 bgp community-list standard cm-set-no-export permit 64512:200
4140 ! advertise only to other customers
4141 bgp community-list standard cm-cust-only permit 64512:300
4143 ! advertise only to upstreams
4144 bgp community-list standard cm-upstream-only permit 64512:400
4146 ! advertise to upstreams with no-export
4147 bgp community-list standard cm-upstream-noexport permit 64512:500
4149 ! set local-pref to least significant 3 digits of the community
4150 bgp community-list standard cm-prefmod-100 permit 64512:2100
4151 bgp community-list standard cm-prefmod-200 permit 64512:2200
4152 bgp community-list standard cm-prefmod-300 permit 64512:2300
4153 bgp community-list standard cm-prefmod-400 permit 64512:2400
4154 bgp community-list expanded cme-prefmod-range permit 64512:2...
4156 ! Informational communities
4158 ! 3000 - learned from upstream
4159 ! 3100 - learned from customer
4160 ! 3200 - learned from peer
4162 bgp community-list standard cm-learnt-upstream permit 64512:3000
4163 bgp community-list standard cm-learnt-cust permit 64512:3100
4164 bgp community-list standard cm-learnt-peer permit 64512:3200
4166 ! ###################################################################
4167 ! Utility route-maps
4169 ! These utility route-maps generally should not used to permit/deny
4170 ! routes, i.e. they do not have meaning as filters, and hence probably
4171 ! should be used with 'on-match next'. These all finish with an empty
4172 ! permit entry so as not interfere with processing in the caller.
4174 route-map rm-no-export permit 10
4175 set community additive no-export
4176 route-map rm-no-export permit 20
4178 route-map rm-blackhole permit 10
4179 description blackhole, up-pref and ensure it cannot escape this AS
4180 set ip next-hop 127.0.0.1
4181 set local-preference 10
4182 set community additive no-export
4183 route-map rm-blackhole permit 20
4185 ! Set local-pref as requested
4186 route-map rm-prefmod permit 10
4187 match community cm-prefmod-100
4188 set local-preference 100
4189 route-map rm-prefmod permit 20
4190 match community cm-prefmod-200
4191 set local-preference 200
4192 route-map rm-prefmod permit 30
4193 match community cm-prefmod-300
4194 set local-preference 300
4195 route-map rm-prefmod permit 40
4196 match community cm-prefmod-400
4197 set local-preference 400
4198 route-map rm-prefmod permit 50
4200 ! Community actions to take on receipt of route.
4201 route-map rm-community-in permit 10
4202 description check for blackholing, no point continuing if it matches.
4203 match community cm-blackhole
4205 route-map rm-community-in permit 20
4206 match community cm-set-no-export
4209 route-map rm-community-in permit 30
4210 match community cme-prefmod-range
4212 route-map rm-community-in permit 40
4214 ! #####################################################################
4215 ! Community actions to take when advertising a route.
4216 ! These are filtering route-maps,
4218 ! Deny customer routes to upstream with cust-only set.
4219 route-map rm-community-filt-to-upstream deny 10
4220 match community cm-learnt-cust
4221 match community cm-cust-only
4222 route-map rm-community-filt-to-upstream permit 20
4224 ! Deny customer routes to other customers with upstream-only set.
4225 route-map rm-community-filt-to-cust deny 10
4226 match community cm-learnt-cust
4227 match community cm-upstream-only
4228 route-map rm-community-filt-to-cust permit 20
4230 ! ###################################################################
4231 ! The top-level route-maps applied to sessions. Further entries could
4232 ! be added obviously..
4235 route-map rm-cust-in permit 10
4236 call rm-community-in
4238 route-map rm-cust-in permit 20
4239 set community additive 64512:3100
4240 route-map rm-cust-in permit 30
4242 route-map rm-cust-out permit 10
4243 call rm-community-filt-to-cust
4245 route-map rm-cust-out permit 20
4247 ! Upstream transit ASes
4248 route-map rm-upstream-out permit 10
4249 description filter customer prefixes which are marked cust-only
4250 call rm-community-filt-to-upstream
4252 route-map rm-upstream-out permit 20
4253 description only customer routes are provided to upstreams/peers
4254 match community cm-learnt-cust
4257 ! outbound policy is same as for upstream
4258 route-map rm-peer-out permit 10
4259 call rm-upstream-out
4261 route-map rm-peer-in permit 10
4262 set community additive 64512:3200
4265 Example of how to set up a 6-Bone connection.
4269 ! bgpd configuration
4270 ! ==================
4272 ! MP-BGP configuration
4275 bgp router-id 10.0.0.1
4276 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as `as-number`
4279 network 3ffe:506::/32
4280 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
4281 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
4282 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as `as-number`
4283 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
4286 ipv6 access-list all permit any
4288 ! Set output nexthop address.
4290 route-map set-nexthop permit 10
4291 match ipv6 address all
4292 set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
4293 set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
4302 TCP provides a mechanism for the user to specify the max segment size.
4303 setsockopt API is used to set the max segment size for TCP session. We
4304 can configure this as part of BGP neighbor configuration.
4306 This document explains how to avoid ICMP vulnerability issues by limiting
4307 TCP max segment size when you are using MTU discovery. Using MTU discovery
4308 on TCP paths is one method of avoiding BGP packet fragmentation.
4310 TCP negotiates a maximum segment size (MSS) value during session connection
4311 establishment between two peers. The MSS value negotiated is primarily based
4312 on the maximum transmission unit (MTU) of the interfaces to which the
4313 communicating peers are directly connected. However, due to variations in
4314 link MTU on the path taken by the TCP packets, some packets in the network
4315 that are well within the MSS value might be fragmented when the packet size
4316 exceeds the link's MTU.
4318 This feature is supported with TCP over IPv4 and TCP over IPv6.
4322 Below configuration can be done in router bgp mode and allows the user to
4323 configure the tcp-mss value per neighbor. The configuration gets applied
4324 only after hard reset is performed on that neighbor. If we configure tcp-mss
4325 on both the neighbors then both neighbors need to be reset.
4327 The configuration takes effect based on below rules, so there is a configured
4328 tcp-mss and a synced tcp-mss value per TCP session.
4330 By default if the configuration is not done then the TCP max segment size is
4331 set to the Maximum Transmission unit (MTU) – (IP/IP6 header size + TCP header
4332 size + ethernet header). For IPv4 its MTU – (20 bytes IP header + 20 bytes TCP
4333 header + 12 bytes ethernet header) and for IPv6 its MTU – (40 bytes IPv6 header
4334 + 20 bytes TCP header + 12 bytes ethernet header).
4336 If the config is done then it reduces 12-14 bytes for the ether header and
4337 uses it after synchronizing in TCP handshake.
4339 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> tcp-mss (1-65535)
4341 When tcp-mss is configured kernel reduces 12-14 bytes for ethernet header.
4342 E.g. if tcp-mss is configured as 150 the synced value will be 138.
4344 Note: configured and synced value is different since TCP module will reduce
4345 12 bytes for ethernet header.
4352 frr# show running-config
4353 Building configuration...
4355 Current configuration:
4358 bgp router-id 192.0.2.1
4359 neighbor 198.51.100.2 remote-as 100
4360 neighbor 198.51.100.2 tcp-mss 150 => new entry
4361 neighbor 2001:DB8::2 remote-as 100
4362 neighbor 2001:DB8::2 tcp-mss 400 => new entry
4369 frr# show bgp neighbors 198.51.100.2
4370 BGP neighbor is 198.51.100.2, remote AS 100, local AS 100, internal link
4372 BGP version 4, remote router ID 192.0.2.2, local router ID 192.0.2.1
4373 BGP state = Established, up for 02:15:28
4374 Last read 00:00:28, Last write 00:00:28
4375 Hold time is 180, keepalive interval is 60 seconds
4376 Configured tcp-mss is 150, synced tcp-mss is 138 => new display
4380 frr# show bgp neighbors 2001:DB8::2
4381 BGP neighbor is 2001:DB8::2, remote AS 100, local AS 100, internal link
4383 BGP version 4, remote router ID 192.0.2.2, local router ID 192.0.2.1
4384 BGP state = Established, up for 02:16:34
4385 Last read 00:00:34, Last write 00:00:34
4386 Hold time is 180, keepalive interval is 60 seconds
4387 Configured tcp-mss is 400, synced tcp-mss is 388 => new display
4389 Show command json output:
4390 -------------------------
4394 frr# show bgp neighbors 2001:DB8::2 json
4399 "nbrInternalLink":true,
4402 "remoteRouterId":"192.0.2.2",
4403 "localRouterId":"192.0.2.1",
4404 "bgpState":"Established",
4405 "bgpTimerUpMsec":8349000,
4406 "bgpTimerUpString":"02:19:09",
4407 "bgpTimerUpEstablishedEpoch":1613054251,
4408 "bgpTimerLastRead":9000,
4409 "bgpTimerLastWrite":9000,
4410 "bgpInUpdateElapsedTimeMsecs":8347000,
4411 "bgpTimerHoldTimeMsecs":180000,
4412 "bgpTimerKeepAliveIntervalMsecs":60000,
4413 "bgpTcpMssConfigured":400, => new entry
4414 "bgpTcpMssSynced":388, => new entry
4418 frr# show bgp neighbors 198.51.100.2 json
4423 "nbrInternalLink":true,
4426 "remoteRouterId":"192.0.2.2",
4427 "localRouterId":"192.0.2.1",
4428 "bgpState":"Established",
4429 "bgpTimerUpMsec":8370000,
4430 "bgpTimerUpString":"02:19:30",
4431 "bgpTimerUpEstablishedEpoch":1613054251,
4432 "bgpTimerLastRead":30000,
4433 "bgpTimerLastWrite":30000,
4434 "bgpInUpdateElapsedTimeMsecs":8368000,
4435 "bgpTimerHoldTimeMsecs":180000,
4436 "bgpTimerKeepAliveIntervalMsecs":60000,
4437 "bgpTcpMssConfigured":150, => new entry
4438 "bgpTcpMssSynced":138, => new entry
4440 .. include:: routeserver.rst
4442 .. include:: rpki.rst
4444 .. include:: wecmp_linkbw.rst
4446 .. include:: flowspec.rst
4448 .. [#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)
4449 .. [bgp-route-osci-cond] McPherson, D. and Gill, V. and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", IETF RFC3345
4450 .. [stable-flexible-ibgp] Flavel, A. and M. Roughan, "Stable and flexible iBGP", ACM SIGCOMM 2009
4451 .. [ibgp-correctness] Griffin, T. and G. Wilfong, "On the correctness of IBGP configuration", ACM SIGCOMM 2002
4453 .. _bgp-fast-convergence:
4455 BGP fast-convergence support
4456 ============================
4457 Whenever BGP peer address becomes unreachable we must bring down the BGP
4458 session immediately. Currently only single-hop EBGP sessions are brought
4459 down immediately.IBGP and multi-hop EBGP sessions wait for hold-timer
4460 expiry to bring down the sessions.
4462 This new configuration option helps user to teardown BGP sessions immediately
4463 whenever peer becomes unreachable.
4465 .. clicmd:: bgp fast-convergence
4467 This configuration is available at the bgp level. When enabled, configuration
4468 is applied to all the neighbors configured in that bgp instance.
4473 neighbor 10.0.0.2 remote-as 64496
4474 neighbor fd00::2 remote-as 64496
4475 bgp fast-convergence
4477 address-family ipv4 unicast
4481 address-family ipv6 unicast
4482 neighbor fd00::2 activate