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 If ``bgp bestpath aigp`` is enabled, and both paths that are compared have
152 AIGP attribute, BGP uses AIGP tie-breaking unless both of the paths have the
153 AIGP metric attribute. This means that the AIGP attribute is not evaluated
154 during the best path selection process between two paths when one path does
155 not have the AIGP attribute.
157 3. **Local route check**
159 Prefer local routes (statics, aggregates, redistributed) to received routes.
161 4. **AS path length check**
163 Prefer shortest hop-count AS_PATHs.
167 Prefer the lowest origin type route. That is, prefer IGP origin routes to
168 EGP, to Incomplete routes.
172 Where routes with a MED were received from the same AS, prefer the route
173 with the lowest MED. :ref:`bgp-med`.
175 7. **External check**
177 Prefer the route received from an external, eBGP peer over routes received
178 from other types of peers.
180 8. **IGP cost check**
182 Prefer the route with the lower IGP cost.
184 9. **Multi-path check**
186 If multi-pathing is enabled, then check whether the routes not yet
187 distinguished in preference may be considered equal. If
188 :clicmd:`bgp bestpath as-path multipath-relax` is set, all such routes are
189 considered equal, otherwise routes received via iBGP with identical AS_PATHs
190 or routes received from eBGP neighbours in the same AS are considered equal.
192 10. **Already-selected external check**
194 Where both routes were received from eBGP peers, then prefer the route
195 which is already selected. Note that this check is not applied if
196 :clicmd:`bgp bestpath compare-routerid` is configured. This check can
197 prevent some cases of oscillation.
199 11. **Router-ID check**
201 Prefer the route with the lowest `router-ID`. If the route has an
202 `ORIGINATOR_ID` attribute, through iBGP reflection, then that router ID is
203 used, otherwise the `router-ID` of the peer the route was received from is
206 12. **Cluster-List length check**
208 The route with the shortest cluster-list length is used. The cluster-list
209 reflects the iBGP reflection path the route has taken.
213 Prefer the route received from the peer with the higher transport layer
214 address, as a last-resort tie-breaker.
216 .. _bgp-capability-negotiation:
218 Capability Negotiation
219 ----------------------
221 When adding IPv6 routing information exchange feature to BGP. There were some
222 proposals. :abbr:`IETF (Internet Engineering Task Force)`
223 :abbr:`IDR (Inter Domain Routing)` adopted a proposal called Multiprotocol
224 Extension for BGP. The specification is described in :rfc:`2283`. The protocol
225 does not define new protocols. It defines new attributes to existing BGP. When
226 it is used exchanging IPv6 routing information it is called BGP-4+. When it is
227 used for exchanging multicast routing information it is called MBGP.
229 *bgpd* supports Multiprotocol Extension for BGP. So if a remote peer supports
230 the protocol, *bgpd* can exchange IPv6 and/or multicast routing information.
232 Traditional BGP did not have the feature to detect a remote peer's
233 capabilities, e.g. whether it can handle prefix types other than IPv4 unicast
234 routes. This was a big problem using Multiprotocol Extension for BGP in an
235 operational network. :rfc:`2842` adopted a feature called Capability
236 Negotiation. *bgpd* use this Capability Negotiation to detect the remote peer's
237 capabilities. If a peer is only configured as an IPv4 unicast neighbor, *bgpd*
238 does not send these Capability Negotiation packets (at least not unless other
239 optional BGP features require capability negotiation).
241 By default, FRR will bring up peering with minimal common capability for the
242 both sides. For example, if the local router has unicast and multicast
243 capabilities and the remote router only has unicast capability the local router
244 will establish the connection with unicast only capability. When there are no
245 common capabilities, FRR sends Unsupported Capability error and then resets the
248 .. _bgp-router-configuration:
250 BGP Router Configuration
251 ========================
256 First of all you must configure BGP router with the :clicmd:`router bgp ASN`
257 command. The AS number is an identifier for the autonomous system. The BGP
258 protocol uses the AS number for detecting whether the BGP connection is
259 internal or external.
261 .. clicmd:: router bgp ASN
263 Enable a BGP protocol process with the specified ASN. After
264 this statement you can input any `BGP Commands`.
266 .. clicmd:: bgp router-id A.B.C.D
268 This command specifies the router-ID. If *bgpd* connects to *zebra* it gets
269 interface and address information. In that case default router ID value is
270 selected as the largest IP Address of the interfaces. When `router zebra` is
271 not enabled *bgpd* can't get interface information so `router-id` is set to
272 0.0.0.0. So please set router-id by hand.
275 .. _bgp-multiple-autonomous-systems:
277 Multiple Autonomous Systems
278 ---------------------------
280 FRR's BGP implementation is capable of running multiple autonomous systems at
281 once. Each configured AS corresponds to a :ref:`zebra-vrf`. In the past, to get
282 the same functionality the network administrator had to run a new *bgpd*
283 process; using VRFs allows multiple autonomous systems to be handled in a
286 When using multiple autonomous systems, all router config blocks after the
287 first one must specify a VRF to be the target of BGP's route selection. This
288 VRF must be unique within respect to all other VRFs being used for the same
289 purpose, i.e. two different autonomous systems cannot use the same VRF.
290 However, the same AS can be used with different VRFs.
294 The separated nature of VRFs makes it possible to peer a single *bgpd*
295 process to itself, on one machine. Note that this can be done fully within
296 BGP without a corresponding VRF in the kernel or Zebra, which enables some
297 practical use cases such as :ref:`route reflectors <bgp-route-reflector>`
300 Configuration of additional autonomous systems, or of a router that targets a
301 specific VRF, is accomplished with the following command:
303 .. clicmd:: router bgp ASN vrf VRFNAME
305 ``VRFNAME`` is matched against VRFs configured in the kernel. When ``vrf
306 VRFNAME`` is not specified, the BGP protocol process belongs to the default
309 An example configuration with multiple autonomous systems might look like this:
314 neighbor 10.0.0.1 remote-as 20
315 neighbor 10.0.0.2 remote-as 30
317 router bgp 2 vrf blue
318 neighbor 10.0.0.3 remote-as 40
319 neighbor 10.0.0.4 remote-as 50
322 neighbor 10.0.0.5 remote-as 60
323 neighbor 10.0.0.6 remote-as 70
326 .. seealso:: :ref:`bgp-vrf-route-leaking`
327 .. seealso:: :ref:`zebra-vrf`
335 In addition to supporting multiple autonomous systems, FRR's BGP implementation
336 also supports *views*.
338 BGP views are almost the same as normal BGP processes, except that routes
339 selected by BGP are not installed into the kernel routing table. Each BGP view
340 provides an independent set of routing information which is only distributed
341 via BGP. Multiple views can be supported, and BGP view information is always
342 independent from other routing protocols and Zebra/kernel routes. BGP views use
343 the core instance (i.e., default VRF) for communication with peers.
345 .. clicmd:: router bgp AS-NUMBER view NAME
347 Make a new BGP view. You can use an arbitrary word for the ``NAME``. Routes
348 selected by the view are not installed into the kernel routing table.
350 With this command, you can setup Route Server like below.
356 neighbor 10.0.0.1 remote-as 2
357 neighbor 10.0.0.2 remote-as 3
360 neighbor 10.0.0.3 remote-as 4
361 neighbor 10.0.0.4 remote-as 5
363 .. clicmd:: show [ip] bgp view NAME
365 Display the routing table of BGP view ``NAME``.
371 .. clicmd:: bgp bestpath as-path confed
373 This command specifies that the length of confederation path sets and
374 sequences should should be taken into account during the BGP best path
377 .. clicmd:: bgp bestpath as-path multipath-relax
379 This command specifies that BGP decision process should consider paths
380 of equal AS_PATH length candidates for multipath computation. Without
381 the knob, the entire AS_PATH must match for multipath computation.
383 .. clicmd:: bgp bestpath compare-routerid
385 Ensure that when comparing routes where both are equal on most metrics,
386 including local-pref, AS_PATH length, IGP cost, MED, that the tie is broken
389 If this option is enabled, then the already-selected check, where
390 already selected eBGP routes are preferred, is skipped.
392 If a route has an `ORIGINATOR_ID` attribute because it has been reflected,
393 that `ORIGINATOR_ID` will be used. Otherwise, the router-ID of the peer the
394 route was received from will be used.
396 The advantage of this is that the route-selection (at this point) will be
397 more deterministic. The disadvantage is that a few or even one lowest-ID
398 router may attract all traffic to otherwise-equal paths because of this
399 check. It may increase the possibility of MED or IGP oscillation, unless
400 other measures were taken to avoid these. The exact behaviour will be
401 sensitive to the iBGP and reflection topology.
403 .. clicmd:: bgp bestpath peer-type multipath-relax
405 This command specifies that BGP decision process should consider paths
406 from all peers for multipath computation. If this option is enabled,
407 paths learned from any of eBGP, iBGP, or confederation neighbors will
408 be multipath if they are otherwise considered equal cost.
410 .. clicmd:: bgp bestpath aigp
412 Use the bgp bestpath aigp command to evaluate the AIGP attribute during
413 the best path selection process between two paths that have the AIGP
416 When bgp bestpath aigp is disabled, BGP does not use AIGP tie-breaking
417 rules unless paths have the AIGP attribute.
421 .. clicmd:: maximum-paths (1-128)
423 Sets the maximum-paths value used for ecmp calculations for this
424 bgp instance in EBGP. The maximum value listed, 128, can be limited by
425 the ecmp cli for bgp or if the daemon was compiled with a lower
426 ecmp value. This value can also be set in ipv4/ipv6 unicast/labeled
427 unicast to only affect those particular afi/safi's.
429 .. clicmd:: maximum-paths ibgp (1-128) [equal-cluster-length]
431 Sets the maximum-paths value used for ecmp calculations for this
432 bgp instance in IBGP. The maximum value listed, 128, can be limited by
433 the ecmp cli for bgp or if the daemon was compiled with a lower
434 ecmp value. This value can also be set in ipv4/ipv6 unicast/labeled
435 unicast to only affect those particular afi/safi's.
439 Administrative Distance Metrics
440 -------------------------------
442 .. clicmd:: distance bgp (1-255) (1-255) (1-255)
444 This command changes distance value of BGP. The arguments are the distance
445 values for external routes, internal routes and local routes
448 .. clicmd:: distance (1-255) A.B.C.D/M
450 .. clicmd:: distance (1-255) A.B.C.D/M WORD
452 Sets the administrative distance for a particular route.
454 .. _bgp-requires-policy:
456 Require policy on EBGP
457 -------------------------------
459 .. clicmd:: bgp ebgp-requires-policy
461 This command requires incoming and outgoing filters to be applied
462 for eBGP sessions as part of RFC-8212 compliance. Without the incoming
463 filter, no routes will be accepted. Without the outgoing filter, no
464 routes will be announced.
466 This is enabled by default for the traditional configuration and
467 turned off by default for datacenter configuration.
469 When you enable/disable this option you MUST clear the session.
471 When the incoming or outgoing filter is missing you will see
472 "(Policy)" sign under ``show bgp summary``:
476 exit1# show bgp summary
478 IPv4 Unicast Summary (VRF default):
479 BGP router identifier 10.10.10.1, local AS number 65001 vrf-id 0
481 RIB entries 7, using 1344 bytes of memory
482 Peers 2, using 43 KiB of memory
484 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
485 192.168.0.2 4 65002 8 10 0 0 0 00:03:09 5 (Policy) N/A
486 fe80:1::2222 4 65002 9 11 0 0 0 00:03:09 (Policy) (Policy) N/A
488 Additionally a `show bgp neighbor` command would indicate in the `For address family:`
493 exit1# show bgp neighbor
495 For address family: IPv4 Unicast
496 Update group 1, subgroup 1
497 Packet Queue length 0
498 Inbound soft reconfiguration allowed
499 Community attribute sent to this neighbor(all)
500 Inbound updates discarded due to missing policy
501 Outbound updates discarded due to missing policy
504 Reject routes with AS_SET or AS_CONFED_SET types
505 ------------------------------------------------
507 .. clicmd:: bgp reject-as-sets
509 This command enables rejection of incoming and outgoing routes having AS_SET or AS_CONFED_SET type.
511 Suppress duplicate updates
512 --------------------------
514 .. clicmd:: bgp suppress-duplicates
516 For example, BGP routers can generate multiple identical announcements with
517 empty community attributes if stripped at egress. This is an undesired behavior.
518 Suppress duplicate updates if the route actually not changed.
521 Send Hard Reset CEASE Notification for Administrative Reset
522 -----------------------------------------------------------
524 .. clicmd:: bgp hard-administrative-reset
526 Send Hard Reset CEASE Notification for 'Administrative Reset' events.
528 When disabled, and Graceful Restart Notification capability is exchanged
529 between the peers, Graceful Restart procedures apply, and routes will be
534 Disable checking if nexthop is connected on EBGP sessions
535 ---------------------------------------------------------
537 .. clicmd:: bgp disable-ebgp-connected-route-check
539 This command is used to disable the connection verification process for EBGP peering sessions
540 that are reachable by a single hop but are configured on a loopback interface or otherwise
541 configured with a non-directly connected IP address.
543 .. _bgp-route-flap-dampening:
548 .. clicmd:: bgp dampening (1-45) (1-20000) (1-50000) (1-255)
550 This command enables BGP route-flap dampening and specifies dampening parameters.
553 Half-life time for the penalty
556 Value to start reusing a route
559 Value to start suppressing a route
562 Maximum duration to suppress a stable route
564 The route-flap damping algorithm is compatible with :rfc:`2439`. The use of
565 this command is not recommended nowadays.
567 At the moment, route-flap dampening is not working per VRF and is working only
568 for IPv4 unicast and multicast.
571 https://www.ripe.net/publications/docs/ripe-378
575 Multi-Exit Discriminator
576 ------------------------
578 The BGP :abbr:`MED (Multi-Exit Discriminator)` attribute has properties which
579 can cause subtle convergence problems in BGP. These properties and problems
580 have proven to be hard to understand, at least historically, and may still not
581 be widely understood. The following attempts to collect together and present
582 what is known about MED, to help operators and FRR users in designing and
583 configuring their networks.
585 The BGP :abbr:`MED` attribute is intended to allow one AS to indicate its
586 preferences for its ingress points to another AS. The MED attribute will not be
587 propagated on to another AS by the receiving AS - it is 'non-transitive' in the
590 E.g., if AS X and AS Y have 2 different BGP peering points, then AS X might set
591 a MED of 100 on routes advertised at one and a MED of 200 at the other. When AS
592 Y selects between otherwise equal routes to or via AS X, AS Y should prefer to
593 take the path via the lower MED peering of 100 with AS X. Setting the MED
594 allows an AS to influence the routing taken to it within another, neighbouring
597 In this use of MED it is not really meaningful to compare the MED value on
598 routes where the next AS on the paths differs. E.g., if AS Y also had a route
599 for some destination via AS Z in addition to the routes from AS X, and AS Z had
600 also set a MED, it wouldn't make sense for AS Y to compare AS Z's MED values to
601 those of AS X. The MED values have been set by different administrators, with
602 different frames of reference.
604 The default behaviour of BGP therefore is to not compare MED values across
605 routes received from different neighbouring ASes. In FRR this is done by
606 comparing the neighbouring, left-most AS in the received AS_PATHs of the routes
607 and only comparing MED if those are the same.
609 Unfortunately, this behaviour of MED, of sometimes being compared across routes
610 and sometimes not, depending on the properties of those other routes, means MED
611 can cause the order of preference over all the routes to be undefined. That is,
612 given routes A, B, and C, if A is preferred to B, and B is preferred to C, then
613 a well-defined order should mean the preference is transitive (in the sense of
614 orders [#med-transitivity-rant]_) and that A would be preferred to C.
616 However, when MED is involved this need not be the case. With MED it is
617 possible that C is actually preferred over A. So A is preferred to B, B is
618 preferred to C, but C is preferred to A. This can be true even where BGP
619 defines a deterministic 'most preferred' route out of the full set of A,B,C.
620 With MED, for any given set of routes there may be a deterministically
621 preferred route, but there need not be any way to arrange them into any order
622 of preference. With unmodified MED, the order of preference of routes literally
625 That MED can induce non-transitive preferences over routes can cause issues.
626 Firstly, it may be perceived to cause routing table churn locally at speakers;
627 secondly, and more seriously, it may cause routing instability in iBGP
628 topologies, where sets of speakers continually oscillate between different
631 The first issue arises from how speakers often implement routing decisions.
632 Though BGP defines a selection process that will deterministically select the
633 same route as best at any given speaker, even with MED, that process requires
634 evaluating all routes together. For performance and ease of implementation
635 reasons, many implementations evaluate route preferences in a pair-wise fashion
636 instead. Given there is no well-defined order when MED is involved, the best
637 route that will be chosen becomes subject to implementation details, such as
638 the order the routes are stored in. That may be (locally) non-deterministic,
639 e.g.: it may be the order the routes were received in.
641 This indeterminism may be considered undesirable, though it need not cause
642 problems. It may mean additional routing churn is perceived, as sometimes more
643 updates may be produced than at other times in reaction to some event .
645 This first issue can be fixed with a more deterministic route selection that
646 ensures routes are ordered by the neighbouring AS during selection.
647 :clicmd:`bgp deterministic-med`. This may reduce the number of updates as routes
648 are received, and may in some cases reduce routing churn. Though, it could
649 equally deterministically produce the largest possible set of updates in
650 response to the most common sequence of received updates.
652 A deterministic order of evaluation tends to imply an additional overhead of
653 sorting over any set of n routes to a destination. The implementation of
654 deterministic MED in FRR scales significantly worse than most sorting
655 algorithms at present, with the number of paths to a given destination. That
656 number is often low enough to not cause any issues, but where there are many
657 paths, the deterministic comparison may quickly become increasingly expensive
660 Deterministic local evaluation can *not* fix the second, more major, issue of
661 MED however. Which is that the non-transitive preference of routes MED can
662 cause may lead to routing instability or oscillation across multiple speakers
663 in iBGP topologies. This can occur with full-mesh iBGP, but is particularly
664 problematic in non-full-mesh iBGP topologies that further reduce the routing
665 information known to each speaker. This has primarily been documented with iBGP
666 :ref:`route-reflection <bgp-route-reflector>` topologies. However, any
667 route-hiding technologies potentially could also exacerbate oscillation with MED.
669 This second issue occurs where speakers each have only a subset of routes, and
670 there are cycles in the preferences between different combinations of routes -
671 as the undefined order of preference of MED allows - and the routes are
672 distributed in a way that causes the BGP speakers to 'chase' those cycles. This
673 can occur even if all speakers use a deterministic order of evaluation in route
676 E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X, and from
677 speaker 3 in AS Y; while speaker 5 in AS A might receive that route from
678 speaker 1 in AS Y. AS Y might set a MED of 200 at speaker 1, and 100 at speaker
679 3. I.e, using ASN:ID:MED to label the speakers:
685 X:2------|--A:4-------A:5--|-Y:1:200
691 Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs), then based
692 on the RFC4271 decision process speaker 4 will choose X:2 over Y:3:100, based
693 on the lower ID of 2. Speaker 4 advertises X:2 to speaker 5. Speaker 5 will
694 continue to prefer Y:1:200 based on the ID, and advertise this to speaker 4.
695 Speaker 4 will now have the full set of routes, and the Y:1:200 it receives
696 from 5 will beat X:2, but when speaker 4 compares Y:1:200 to Y:3:100 the MED
697 check now becomes active as the ASes match, and now Y:3:100 is preferred.
698 Speaker 4 therefore now advertises Y:3:100 to 5, which will also agrees that
699 Y:3:100 is preferred to Y:1:200, and so withdraws the latter route from 4.
700 Speaker 4 now has only X:2 and Y:3:100, and X:2 beats Y:3:100, and so speaker 4
701 implicitly updates its route to speaker 5 to X:2. Speaker 5 sees that Y:1:200
702 beats X:2 based on the ID, and advertises Y:1:200 to speaker 4, and the cycle
705 The root cause is the lack of a clear order of preference caused by how MED
706 sometimes is and sometimes is not compared, leading to this cycle in the
707 preferences between the routes:
712 /---> X:2 ---beats---> Y:3:100 --\\
715 \\---beats--- Y:1:200 <---beats---/
719 This particular type of oscillation in full-mesh iBGP topologies can be
720 avoided by speakers preferring already selected, external routes rather than
721 choosing to update to new a route based on a post-MED metric (e.g. router-ID),
722 at the cost of a non-deterministic selection process. FRR implements this, as
723 do many other implementations, so long as it is not overridden by setting
724 :clicmd:`bgp bestpath compare-routerid`, and see also
725 :ref:`bgp-route-selection`.
727 However, more complex and insidious cycles of oscillation are possible with
728 iBGP route-reflection, which are not so easily avoided. These have been
729 documented in various places. See, e.g.:
731 - [bgp-route-osci-cond]_
732 - [stable-flexible-ibgp]_
733 - [ibgp-correctness]_
735 for concrete examples and further references.
737 There is as of this writing *no* known way to use MED for its original purpose;
738 *and* reduce routing information in iBGP topologies; *and* be sure to avoid the
739 instability problems of MED due the non-transitive routing preferences it can
740 induce; in general on arbitrary networks.
742 There may be iBGP topology specific ways to reduce the instability risks, even
743 while using MED, e.g.: by constraining the reflection topology and by tuning
744 IGP costs between route-reflector clusters, see :rfc:`3345` for details. In the
745 near future, the Add-Path extension to BGP may also solve MED oscillation while
746 still allowing MED to be used as intended, by distributing "best-paths per
747 neighbour AS". This would be at the cost of distributing at least as many
748 routes to all speakers as a full-mesh iBGP would, if not more, while also
749 imposing similar CPU overheads as the "Deterministic MED" feature at each
752 More generally, the instability problems that MED can introduce on more
753 complex, non-full-mesh, iBGP topologies may be avoided either by:
755 - Setting :clicmd:`bgp always-compare-med`, however this allows MED to be compared
756 across values set by different neighbour ASes, which may not produce
757 coherent desirable results, of itself.
758 - Effectively ignoring MED by setting MED to the same value (e.g.: 0) using
759 :clicmd:`set metric METRIC` on all received routes, in combination with
760 setting :clicmd:`bgp always-compare-med` on all speakers. This is the simplest
761 and most performant way to avoid MED oscillation issues, where an AS is happy
762 not to allow neighbours to inject this problematic metric.
764 As MED is evaluated after the AS_PATH length check, another possible use for
765 MED is for intra-AS steering of routes with equal AS_PATH length, as an
766 extension of the last case above. As MED is evaluated before IGP metric, this
767 can allow cold-potato routing to be implemented to send traffic to preferred
768 hand-offs with neighbours, rather than the closest hand-off according to the
771 Note that even if action is taken to address the MED non-transitivity issues,
772 other oscillations may still be possible. E.g., on IGP cost if iBGP and IGP
773 topologies are at cross-purposes with each other - see the Flavel and Roughan
774 paper above for an example. Hence the guideline that the iBGP topology should
775 follow the IGP topology.
777 .. clicmd:: bgp deterministic-med
779 Carry out route-selection in way that produces deterministic answers
780 locally, even in the face of MED and the lack of a well-defined order of
781 preference it can induce on routes. Without this option the preferred route
782 with MED may be determined largely by the order that routes were received
785 Setting this option will have a performance cost that may be noticeable when
786 there are many routes for each destination. Currently in FRR it is
787 implemented in a way that scales poorly as the number of routes per
788 destination increases.
790 The default is that this option is not set.
792 Note that there are other sources of indeterminism in the route selection
793 process, specifically, the preference for older and already selected routes
794 from eBGP peers, :ref:`bgp-route-selection`.
796 .. clicmd:: bgp always-compare-med
798 Always compare the MED on routes, even when they were received from
799 different neighbouring ASes. Setting this option makes the order of
800 preference of routes more defined, and should eliminate MED induced
803 If using this option, it may also be desirable to use
804 :clicmd:`set metric METRIC` to set MED to 0 on routes received from external
807 This option can be used, together with :clicmd:`set metric METRIC` to use
808 MED as an intra-AS metric to steer equal-length AS_PATH routes to, e.g.,
812 .. _bgp-graceful-restart:
817 BGP graceful restart functionality as defined in
818 `RFC-4724 <https://tools.ietf.org/html/rfc4724/>`_ defines the mechanisms that
819 allows BGP speaker to continue to forward data packets along known routes
820 while the routing protocol information is being restored.
823 Usually, when BGP on a router restarts, all the BGP peers detect that the
824 session went down and then came up. This "down/up" transition results in a
825 "routing flap" and causes BGP route re-computation, generation of BGP routing
826 updates, and unnecessary churn to the forwarding tables.
828 The following functionality is provided by graceful restart:
830 1. The feature allows the restarting router to indicate to the helping peer the
831 routes it can preserve in its forwarding plane during control plane restart
832 by sending graceful restart capability in the OPEN message sent during
833 session establishment.
834 2. The feature allows helping router to advertise to all other peers the routes
835 received from the restarting router which are preserved in the forwarding
836 plane of the restarting router during control plane restart.
843 (R1)-----------------------------------------------------------------(R2)
845 1. BGP Graceful Restart Capability exchanged between R1 & R2.
847 <--------------------------------------------------------------------->
849 2. Kill BGP Process at R1.
851 ---------------------------------------------------------------------->
853 3. R2 Detects the above BGP Restart & verifies BGP Restarting
856 4. Start BGP Process at R1.
858 5. Re-establish the BGP session between R1 & R2.
860 <--------------------------------------------------------------------->
862 6. R2 Send initial route updates, followed by End-Of-Rib.
864 <----------------------------------------------------------------------
866 7. R1 was waiting for End-Of-Rib from R2 & which has been received
869 8. R1 now runs BGP Best-Path algorithm. Send Initial BGP Update,
870 followed by End-Of Rib
872 <--------------------------------------------------------------------->
875 .. _bgp-GR-preserve-forwarding-state:
877 BGP-GR Preserve-Forwarding State
878 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
880 BGP OPEN message carrying optional capabilities for Graceful Restart has
881 8 bit “Flags for Address Family” for given AFI and SAFI. This field contains
882 bit flags relating to routes that were advertised with the given AFI and SAFI.
891 The most significant bit is defined as the Forwarding State (F) bit, which
892 can be used to indicate whether the forwarding state for routes that were
893 advertised with the given AFI and SAFI has indeed been preserved during the
894 previous BGP restart. When set (value 1), the bit indicates that the
895 forwarding state has been preserved.
896 The remaining bits are reserved and MUST be set to zero by the sender and
897 ignored by the receiver.
899 .. clicmd:: bgp graceful-restart preserve-fw-state
901 FRR gives us the option to enable/disable the "F" flag using this specific
902 vty command. However, it doesn't have the option to enable/disable
903 this flag only for specific AFI/SAFI i.e. when this command is used, it
904 applied to all the supported AFI/SAFI combinations for this peer.
906 .. _bgp-end-of-rib-message:
908 End-of-RIB (EOR) message
909 ^^^^^^^^^^^^^^^^^^^^^^^^
911 An UPDATE message with no reachable Network Layer Reachability Information
912 (NLRI) and empty withdrawn NLRI is specified as the End-of-RIB marker that can
913 be used by a BGP speaker to indicate to its peer the completion of the initial
914 routing update after the session is established.
916 For the IPv4 unicast address family, the End-of-RIB marker is an UPDATE message
917 with the minimum length. For any other address family, it is an UPDATE message
918 that contains only the MP_UNREACH_NLRI attribute with no withdrawn routes for
921 Although the End-of-RIB marker is specified for the purpose of BGP graceful
922 restart, it is noted that the generation of such a marker upon completion of
923 the initial update would be useful for routing convergence in general, and thus
924 the practice is recommended.
926 .. _bgp-route-selection-deferral-timer:
928 Route Selection Deferral Timer
929 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
931 Specifies the time the restarting router defers the route selection process
934 Restarting Router : The usage of route election deferral timer is specified
935 in https://tools.ietf.org/html/rfc4724#section-4.1
937 Once the session between the Restarting Speaker and the Receiving Speaker is
938 re-established, the Restarting Speaker will receive and process BGP messages
941 However, it MUST defer route selection for an address family until it either.
943 1. Receives the End-of-RIB marker from all its peers (excluding the ones with
944 the "Restart State" bit set in the received capability and excluding the ones
945 that do not advertise the graceful restart capability).
946 2. The Selection_Deferral_Timer timeout.
948 .. clicmd:: bgp graceful-restart select-defer-time (0-3600)
950 This is command, will set deferral time to value specified.
953 .. clicmd:: bgp graceful-restart rib-stale-time (1-3600)
955 This is command, will set the time for which stale routes are kept in RIB.
957 .. clicmd:: bgp graceful-restart restart-time (0-4095)
959 Set the time to wait to delete stale routes before a BGP open message
962 Using with Long-lived Graceful Restart capability, this is recommended
963 setting this timer to 0 and control stale routes with
964 ``bgp long-lived-graceful-restart stale-time``.
966 Default value is 120.
968 .. clicmd:: bgp graceful-restart stalepath-time (1-4095)
970 This is command, will set the max time (in seconds) to hold onto
971 restarting peer's stale paths.
973 It also controls Enhanced Route-Refresh timer.
975 If this command is configured and the router does not receive a Route-Refresh EoRR
976 message, the router removes the stale routes from the BGP table after the timer
977 expires. The stale path timer is started when the router receives a Route-Refresh
980 .. clicmd:: bgp graceful-restart notification
982 Indicate Graceful Restart support for BGP NOTIFICATION messages.
984 After changing this parameter, you have to reset the peers in order to advertise
985 N-bit in Graceful Restart capability.
987 Without Graceful-Restart Notification capability (N-bit not set), GR is not
988 activated when receiving CEASE/HOLDTIME expire notifications.
990 When sending ``CEASE/Administrative Reset`` (``clear bgp``), the session is closed
991 and routes are not retained. When N-bit is set and ``bgp hard-administrative-reset``
992 is turned off Graceful-Restart is activated and routes are retained.
996 .. _bgp-per-peer-graceful-restart:
998 BGP Per Peer Graceful Restart
999 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1001 Ability to enable and disable graceful restart, helper and no GR at all mode
1002 functionality at peer level.
1004 So bgp graceful restart can be enabled at modes global BGP level or at per
1005 peer level. There are two FSM, one for BGP GR global mode and other for peer
1008 Default global mode is helper and default peer per mode is inherit from global.
1009 If per peer mode is configured, the GR mode of this particular peer will
1010 override the global mode.
1012 .. _bgp-GR-global-mode-cmd:
1014 BGP GR Global Mode Commands
1015 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
1017 .. clicmd:: bgp graceful-restart
1019 This command will enable BGP graceful restart functionality at the global
1022 .. clicmd:: bgp graceful-restart disable
1024 This command will disable both the functionality graceful restart and helper
1028 .. _bgp-GR-peer-mode-cmd:
1030 BGP GR Peer Mode Commands
1031 ^^^^^^^^^^^^^^^^^^^^^^^^^
1033 .. clicmd:: neighbor A.B.C.D graceful-restart
1035 This command will enable BGP graceful restart functionality at the peer
1038 .. clicmd:: neighbor A.B.C.D graceful-restart-helper
1040 This command will enable BGP graceful restart helper only functionality
1043 .. clicmd:: neighbor A.B.C.D graceful-restart-disable
1045 This command will disable the entire BGP graceful restart functionality
1049 Long-lived Graceful Restart
1050 ---------------------------
1052 Currently, only restarter mode is supported. This capability is advertised only
1053 if graceful restart capability is negotiated.
1055 .. clicmd:: bgp long-lived-graceful-restart stale-time (1-16777215)
1057 Specifies the maximum time to wait before purging long-lived stale routes for
1060 Default is 0, which means the feature is off by default. Only graceful
1061 restart takes into account.
1065 Administrative Shutdown
1066 -----------------------
1068 .. clicmd:: bgp shutdown [message MSG...]
1070 Administrative shutdown of all peers of a bgp instance. Drop all BGP peers,
1071 but preserve their configurations. The peers are notified in accordance with
1072 `RFC 8203 <https://tools.ietf.org/html/rfc8203/>`_ by sending a
1073 ``NOTIFICATION`` message with error code ``Cease`` and subcode
1074 ``Administrative Shutdown`` prior to terminating connections. This global
1075 shutdown is independent of the neighbor shutdown, meaning that individually
1076 shut down peers will not be affected by lifting it.
1078 An optional shutdown message `MSG` can be specified.
1086 .. clicmd:: network A.B.C.D/M
1088 This command adds the announcement network.
1093 address-family ipv4 unicast
1097 This configuration example says that network 10.0.0.0/8 will be
1098 announced to all neighbors. Some vendors' routers don't advertise
1099 routes if they aren't present in their IGP routing tables; `bgpd`
1100 doesn't care about IGP routes when announcing its routes.
1103 .. clicmd:: bgp network import-check
1105 This configuration modifies the behavior of the network statement.
1106 If you have this configured the underlying network must exist in
1107 the rib. If you have the [no] form configured then BGP will not
1108 check for the networks existence in the rib. For versions 7.3 and
1109 before frr defaults for datacenter were the network must exist,
1110 traditional did not check for existence. For versions 7.4 and beyond
1111 both traditional and datacenter the network must exist.
1113 .. _bgp-ipv6-support:
1118 .. clicmd:: neighbor A.B.C.D activate
1120 This configuration modifies whether to enable an address family for a
1121 specific neighbor. By default only the IPv4 unicast address family is
1127 address-family ipv6 unicast
1128 neighbor 2001:0DB8::1 activate
1129 network 2001:0DB8:5009::/64
1132 This configuration example says that network 2001:0DB8:5009::/64 will be
1133 announced and enables the neighbor 2001:0DB8::1 to receive this announcement.
1135 By default, only the IPv4 unicast address family is announced to all
1136 neighbors. Using the 'no bgp default ipv4-unicast' configuration overrides
1137 this default so that all address families need to be enabled explicitly.
1142 no bgp default ipv4-unicast
1143 neighbor 10.10.10.1 remote-as 2
1144 neighbor 2001:0DB8::1 remote-as 3
1145 address-family ipv4 unicast
1146 neighbor 10.10.10.1 activate
1147 network 192.168.1.0/24
1149 address-family ipv6 unicast
1150 neighbor 2001:0DB8::1 activate
1151 network 2001:0DB8:5009::/64
1154 This configuration demonstrates how the 'no bgp default ipv4-unicast' might
1155 be used in a setup with two upstreams where each of the upstreams should only
1156 receive either IPv4 or IPv6 announcements.
1158 Using the ``bgp default ipv6-unicast`` configuration, IPv6 unicast
1159 address family is enabled by default for all new neighbors.
1162 .. _bgp-route-aggregation:
1167 .. _bgp-route-aggregation-ipv4:
1169 Route Aggregation-IPv4 Address Family
1170 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1172 .. clicmd:: aggregate-address A.B.C.D/M
1174 This command specifies an aggregate address.
1176 In order to advertise an aggregated prefix, a more specific (longer) prefix
1177 MUST exist in the BGP table. For example, if you want to create an
1178 ``aggregate-address 10.0.0.0/24``, you should make sure you have something
1179 like ``10.0.0.5/32`` or ``10.0.0.0/26``, or any other smaller prefix in the
1180 BGP table. The routing information table (RIB) is not enough, you have to
1181 redistribute them into the BGP table.
1183 .. clicmd:: aggregate-address A.B.C.D/M route-map NAME
1185 Apply a route-map for an aggregated prefix.
1187 .. clicmd:: aggregate-address A.B.C.D/M origin <egp|igp|incomplete>
1189 Override ORIGIN for an aggregated prefix.
1191 .. clicmd:: aggregate-address A.B.C.D/M as-set
1193 This command specifies an aggregate address. Resulting routes include
1196 .. clicmd:: aggregate-address A.B.C.D/M summary-only
1198 This command specifies an aggregate address.
1200 Longer prefixes advertisements of more specific routes to all neighbors are suppressed.
1202 .. clicmd:: aggregate-address A.B.C.D/M matching-MED-only
1204 Configure the aggregated address to only be created when the routes MED
1205 match, otherwise no aggregated route will be created.
1207 .. clicmd:: aggregate-address A.B.C.D/M suppress-map NAME
1209 Similar to `summary-only`, but will only suppress more specific routes that
1210 are matched by the selected route-map.
1213 This configuration example sets up an ``aggregate-address`` under the ipv4
1219 address-family ipv4 unicast
1220 aggregate-address 10.0.0.0/8
1221 aggregate-address 20.0.0.0/8 as-set
1222 aggregate-address 40.0.0.0/8 summary-only
1223 aggregate-address 50.0.0.0/8 route-map aggr-rmap
1227 .. _bgp-route-aggregation-ipv6:
1229 Route Aggregation-IPv6 Address Family
1230 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1232 .. clicmd:: aggregate-address X:X::X:X/M
1234 This command specifies an aggregate address.
1236 .. clicmd:: aggregate-address X:X::X:X/M route-map NAME
1238 Apply a route-map for an aggregated prefix.
1240 .. clicmd:: aggregate-address X:X::X:X/M origin <egp|igp|incomplete>
1242 Override ORIGIN for an aggregated prefix.
1244 .. clicmd:: aggregate-address X:X::X:X/M as-set
1246 This command specifies an aggregate address. Resulting routes include
1249 .. clicmd:: aggregate-address X:X::X:X/M summary-only
1251 This command specifies an aggregate address.
1253 Longer prefixes advertisements of more specific routes to all neighbors are suppressed
1255 .. clicmd:: aggregate-address X:X::X:X/M matching-MED-only
1257 Configure the aggregated address to only be created when the routes MED
1258 match, otherwise no aggregated route will be created.
1260 .. clicmd:: aggregate-address X:X::X:X/M suppress-map NAME
1262 Similar to `summary-only`, but will only suppress more specific routes that
1263 are matched by the selected route-map.
1266 This configuration example sets up an ``aggregate-address`` under the ipv6
1272 address-family ipv6 unicast
1273 aggregate-address 10::0/64
1274 aggregate-address 20::0/64 as-set
1275 aggregate-address 40::0/64 summary-only
1276 aggregate-address 50::0/64 route-map aggr-rmap
1280 .. _bgp-redistribute-to-bgp:
1285 Redistribution configuration should be placed under the ``address-family``
1286 section for the specific AF to redistribute into. Protocol availability for
1287 redistribution is determined by BGP AF; for example, you cannot redistribute
1288 OSPFv3 into ``address-family ipv4 unicast`` as OSPFv3 supports IPv6.
1290 .. clicmd:: redistribute <babel|connected|eigrp|isis|kernel|openfabric|ospf|ospf6|rip|ripng|sharp|static|table> [metric (0-4294967295)] [route-map WORD]
1292 Redistribute routes from other protocols into BGP.
1294 .. clicmd:: redistribute vnc-direct
1296 Redistribute VNC direct (not via zebra) routes to BGP process.
1298 .. clicmd:: bgp update-delay MAX-DELAY
1300 .. clicmd:: bgp update-delay MAX-DELAY ESTABLISH-WAIT
1302 This feature is used to enable read-only mode on BGP process restart or when
1303 a BGP process is cleared using 'clear ip bgp \*'. Note that this command is
1304 configured at the global level and applies to all bgp instances/vrfs. It
1305 cannot be used at the same time as the "update-delay" command described below,
1306 which is entered in each bgp instance/vrf desired to delay update installation
1307 and advertisements. The global and per-vrf approaches to defining update-delay
1308 are mutually exclusive.
1310 When applicable, read-only mode would begin as soon as the first peer reaches
1311 Established status and a timer for max-delay seconds is started. During this
1312 mode BGP doesn't run any best-path or generate any updates to its peers. This
1313 mode continues until:
1315 1. All the configured peers, except the shutdown peers, have sent explicit EOR
1316 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
1317 Established is considered an implicit-EOR.
1318 If the establish-wait optional value is given, then BGP will wait for
1319 peers to reach established from the beginning of the update-delay till the
1320 establish-wait period is over, i.e. the minimum set of established peers for
1321 which EOR is expected would be peers established during the establish-wait
1322 window, not necessarily all the configured neighbors.
1323 2. max-delay period is over.
1325 On hitting any of the above two conditions, BGP resumes the decision process
1326 and generates updates to its peers.
1328 Default max-delay is 0, i.e. the feature is off by default.
1331 .. clicmd:: update-delay MAX-DELAY
1333 .. clicmd:: update-delay MAX-DELAY ESTABLISH-WAIT
1335 This feature is used to enable read-only mode on BGP process restart or when
1336 a BGP process is cleared using 'clear ip bgp \*'. Note that this command is
1337 configured under the specific bgp instance/vrf that the feature is enabled for.
1338 It cannot be used at the same time as the global "bgp update-delay" described
1339 above, which is entered at the global level and applies to all bgp instances.
1340 The global and per-vrf approaches to defining update-delay are mutually
1343 When applicable, read-only mode would begin as soon as the first peer reaches
1344 Established status and a timer for max-delay seconds is started. During this
1345 mode BGP doesn't run any best-path or generate any updates to its peers. This
1346 mode continues until:
1348 1. All the configured peers, except the shutdown peers, have sent explicit EOR
1349 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
1350 Established is considered an implicit-EOR.
1351 If the establish-wait optional value is given, then BGP will wait for
1352 peers to reach established from the beginning of the update-delay till the
1353 establish-wait period is over, i.e. the minimum set of established peers for
1354 which EOR is expected would be peers established during the establish-wait
1355 window, not necessarily all the configured neighbors.
1356 2. max-delay period is over.
1358 On hitting any of the above two conditions, BGP resumes the decision process
1359 and generates updates to its peers.
1361 Default max-delay is 0, i.e. the feature is off by default.
1363 .. clicmd:: table-map ROUTE-MAP-NAME
1365 This feature is used to apply a route-map on route updates from BGP to
1366 Zebra. All the applicable match operations are allowed, such as match on
1367 prefix, next-hop, communities, etc. Set operations for this attach-point are
1368 limited to metric and next-hop only. Any operation of this feature does not
1369 affect BGPs internal RIB.
1371 Supported for ipv4 and ipv6 address families. It works on multi-paths as
1372 well, however, metric setting is based on the best-path only.
1379 .. _bgp-defining-peers:
1384 .. clicmd:: neighbor PEER remote-as ASN
1386 Creates a new neighbor whose remote-as is ASN. PEER can be an IPv4 address
1387 or an IPv6 address or an interface to use for the connection.
1392 neighbor 10.0.0.1 remote-as 2
1394 In this case my router, in AS-1, is trying to peer with AS-2 at 10.0.0.1.
1396 This command must be the first command used when configuring a neighbor. If
1397 the remote-as is not specified, *bgpd* will complain like this: ::
1399 can't find neighbor 10.0.0.1
1401 .. clicmd:: neighbor PEER remote-as internal
1403 Create a peer as you would when you specify an ASN, except that if the
1404 peers ASN is different than mine as specified under the :clicmd:`router bgp ASN`
1405 command the connection will be denied.
1407 .. clicmd:: neighbor PEER remote-as external
1409 Create a peer as you would when you specify an ASN, except that if the
1410 peers ASN is the same as mine as specified under the :clicmd:`router bgp ASN`
1411 command the connection will be denied.
1413 .. clicmd:: bgp listen range <A.B.C.D/M|X:X::X:X/M> peer-group PGNAME
1415 Accept connections from any peers in the specified prefix. Configuration
1416 from the specified peer-group is used to configure these peers.
1420 When using BGP listen ranges, if the associated peer group has TCP MD5
1421 authentication configured, your kernel must support this on prefixes. On
1422 Linux, this support was added in kernel version 4.14. If your kernel does
1423 not support this feature you will get a warning in the log file, and the
1424 listen range will only accept connections from peers without MD5 configured.
1426 Additionally, we have observed that when using this option at scale (several
1427 hundred peers) the kernel may hit its option memory limit. In this situation
1428 you will see error messages like:
1430 ``bgpd: sockopt_tcp_signature: setsockopt(23): Cannot allocate memory``
1432 In this case you need to increase the value of the sysctl
1433 ``net.core.optmem_max`` to allow the kernel to allocate the necessary option
1436 .. clicmd:: bgp listen limit <1-65535>
1438 Define the maximum number of peers accepted for one BGP instance. This
1439 limit is set to 100 by default. Increasing this value will really be
1440 possible if more file descriptors are available in the BGP process. This
1441 value is defined by the underlying system (ulimit value), and can be
1442 overridden by `--limit-fds`. More information is available in chapter
1443 (:ref:`common-invocation-options`).
1445 .. clicmd:: coalesce-time (0-4294967295)
1447 The time in milliseconds that BGP will delay before deciding what peers
1448 can be put into an update-group together in order to generate a single
1449 update for them. The default time is 1000.
1451 .. _bgp-configuring-peers:
1456 .. clicmd:: neighbor PEER shutdown [message MSG...] [rtt (1-65535) [count (1-255)]]
1458 Shutdown the peer. We can delete the neighbor's configuration by
1459 ``no neighbor PEER remote-as ASN`` but all configuration of the neighbor
1460 will be deleted. When you want to preserve the configuration, but want to
1461 drop the BGP peer, use this syntax.
1463 Optionally you can specify a shutdown message `MSG`.
1465 Also, you can specify optionally ``rtt`` in milliseconds to automatically
1466 shutdown the peer if round-trip-time becomes higher than defined.
1468 Additional ``count`` parameter is the number of keepalive messages to count
1469 before shutdown the peer if round-trip-time becomes higher than defined.
1471 .. clicmd:: neighbor PEER disable-connected-check
1473 Allow peerings between directly connected eBGP peers using loopback
1476 .. clicmd:: neighbor PEER disable-link-bw-encoding-ieee
1478 By default bandwidth in extended communities is carried encoded as IEEE
1479 floating-point format, which is according to the draft.
1481 Older versions have the implementation where extended community bandwidth
1482 value is carried encoded as uint32. To enable backward compatibility we
1483 need to disable IEEE floating-point encoding option per-peer.
1485 .. clicmd:: neighbor PEER extended-optional-parameters
1487 Force Extended Optional Parameters Length format to be used for OPEN messages.
1489 By default, it's disabled. If the standard optional parameters length is
1490 higher than one-octet (255), then extended format is enabled automatically.
1492 For testing purposes, extended format can be enabled with this command.
1494 .. clicmd:: neighbor PEER ebgp-multihop
1496 Specifying ``ebgp-multihop`` allows sessions with eBGP neighbors to
1497 establish when they are multiple hops away. When the neighbor is not
1498 directly connected and this knob is not enabled, the session will not
1501 If the peer's IP address is not in the RIB and is reachable via the
1502 default route, then you have to enable ``ip nht resolve-via-default``.
1504 .. clicmd:: neighbor PEER description ...
1506 Set description of the peer.
1508 .. clicmd:: neighbor PEER interface IFNAME
1510 When you connect to a BGP peer over an IPv6 link-local address, you have to
1511 specify the IFNAME of the interface used for the connection. To specify
1512 IPv4 session addresses, see the ``neighbor PEER update-source`` command
1515 .. clicmd:: neighbor PEER interface remote-as <internal|external|ASN>
1517 Configure an unnumbered BGP peer. ``PEER`` should be an interface name. The
1518 session will be established via IPv6 link locals. Use ``internal`` for iBGP
1519 and ``external`` for eBGP sessions, or specify an ASN if you wish.
1521 .. clicmd:: neighbor PEER next-hop-self [force]
1523 This command specifies an announced route's nexthop as being equivalent to
1524 the address of the bgp router if it is learned via eBGP. This will also
1525 bypass third-party next-hops in favor of the local bgp address. If the
1526 optional keyword ``force`` is specified the modification is done also for
1527 routes learned via iBGP.
1529 .. clicmd:: neighbor PEER attribute-unchanged [{as-path|next-hop|med}]
1531 This command specifies attributes to be left unchanged for advertisements
1532 sent to a peer. Use this to leave the next-hop unchanged in ipv6
1533 configurations, as the route-map directive to leave the next-hop unchanged
1534 is only available for ipv4.
1536 .. clicmd:: neighbor PEER update-source <IFNAME|ADDRESS>
1538 Specify the IPv4 source address to use for the :abbr:`BGP` session to this
1539 neighbour, may be specified as either an IPv4 address directly or as an
1540 interface name (in which case the *zebra* daemon MUST be running in order
1541 for *bgpd* to be able to retrieve interface state).
1546 neighbor foo update-source 192.168.0.1
1547 neighbor bar update-source lo0
1550 .. clicmd:: neighbor PEER default-originate [route-map WORD]
1552 *bgpd*'s default is to not announce the default route (0.0.0.0/0) even if it
1553 is in routing table. When you want to announce default routes to the peer,
1556 If ``route-map`` keyword is specified, then the default route will be
1557 originated only if route-map conditions are met. For example, announce
1558 the default route only if ``10.10.10.10/32`` route exists and set an
1559 arbitrary community for a default route.
1564 address-family ipv4 unicast
1565 neighbor 192.168.255.1 default-originate route-map default
1567 ip prefix-list p1 seq 5 permit 10.10.10.10/32
1569 route-map default permit 10
1570 match ip address prefix-list p1
1571 set community 123:123
1574 .. clicmd:: neighbor PEER port PORT
1576 .. clicmd:: neighbor PEER password PASSWORD
1578 Set a MD5 password to be used with the tcp socket that is being used
1579 to connect to the remote peer. Please note if you are using this
1580 command with a large number of peers on linux you should consider
1581 modifying the `net.core.optmem_max` sysctl to a larger value to
1582 avoid out of memory errors from the linux kernel.
1584 .. clicmd:: neighbor PEER send-community
1586 .. clicmd:: neighbor PEER weight WEIGHT
1588 This command specifies a default `weight` value for the neighbor's routes.
1590 .. clicmd:: neighbor PEER maximum-prefix NUMBER [force]
1592 Sets a maximum number of prefixes we can receive from a given peer. If this
1593 number is exceeded, the BGP session will be destroyed.
1595 In practice, it is generally preferable to use a prefix-list to limit what
1596 prefixes are received from the peer instead of using this knob. Tearing down
1597 the BGP session when a limit is exceeded is far more destructive than merely
1598 rejecting undesired prefixes. The prefix-list method is also much more
1599 granular and offers much smarter matching criterion than number of received
1600 prefixes, making it more suited to implementing policy.
1602 If ``force`` is set, then ALL prefixes are counted for maximum instead of
1603 accepted only. This is useful for cases where an inbound filter is applied,
1604 but you want maximum-prefix to act on ALL (including filtered) prefixes. This
1605 option requires `soft-reconfiguration inbound` to be enabled for the peer.
1607 .. clicmd:: neighbor PEER maximum-prefix-out NUMBER
1609 Sets a maximum number of prefixes we can send to a given peer.
1611 Since sent prefix count is managed by update-groups, this option
1612 creates a separate update-group for outgoing updates.
1614 .. clicmd:: neighbor PEER local-as AS-NUMBER [no-prepend] [replace-as]
1616 Specify an alternate AS for this BGP process when interacting with the
1617 specified peer. With no modifiers, the specified local-as is prepended to
1618 the received AS_PATH when receiving routing updates from the peer, and
1619 prepended to the outgoing AS_PATH (after the process local AS) when
1620 transmitting local routes to the peer.
1622 If the no-prepend attribute is specified, then the supplied local-as is not
1623 prepended to the received AS_PATH.
1625 If the replace-as attribute is specified, then only the supplied local-as is
1626 prepended to the AS_PATH when transmitting local-route updates to this peer.
1628 Note that replace-as can only be specified if no-prepend is.
1630 This command is only allowed for eBGP peers.
1632 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> as-override
1634 Override AS number of the originating router with the local AS number.
1636 Usually this configuration is used in PEs (Provider Edge) to replace
1637 the incoming customer AS number so the connected CE (Customer Edge)
1638 can use the same AS number as the other customer sites. This allows
1639 customers of the provider network to use the same AS number across
1642 This command is only allowed for eBGP peers.
1644 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> allowas-in [<(1-10)|origin>]
1646 Accept incoming routes with AS path containing AS number with the same value
1647 as the current system AS.
1649 This is used when you want to use the same AS number in your sites, but you
1650 can't connect them directly. This is an alternative to
1651 `neighbor WORD as-override`.
1653 The parameter `(1-10)` configures the amount of accepted occurrences of the
1654 system AS number in AS path.
1656 The parameter `origin` configures BGP to only accept routes originated with
1657 the same AS number as the system.
1659 This command is only allowed for eBGP peers.
1661 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> addpath-tx-all-paths
1663 Configure BGP to send all known paths to neighbor in order to preserve multi
1664 path capabilities inside a network.
1666 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> addpath-tx-bestpath-per-AS
1668 Configure BGP to send best known paths to neighbor in order to preserve multi
1669 path capabilities inside a network.
1671 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> disable-addpath-rx
1673 Do not accept additional paths from this neighbor.
1675 .. clicmd:: neighbor PEER ttl-security hops NUMBER
1677 This command enforces Generalized TTL Security Mechanism (GTSM), as
1678 specified in RFC 5082. With this command, only neighbors that are the
1679 specified number of hops away will be allowed to become neighbors. This
1680 command is mutually exclusive with *ebgp-multihop*.
1682 .. clicmd:: neighbor PEER capability extended-nexthop
1684 Allow bgp to negotiate the extended-nexthop capability with it's peer.
1685 If you are peering over a v6 LL address then this capability is turned
1686 on automatically. If you are peering over a v6 Global Address then
1687 turning on this command will allow BGP to install v4 routes with
1688 v6 nexthops if you do not have v4 configured on interfaces.
1690 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> accept-own
1692 Enable handling of self-originated VPN routes containing ``accept-own`` community.
1694 This feature allows you to handle self-originated VPN routes, which a BGP speaker
1695 receives from a route-reflector. A 'self-originated' route is one that was
1696 originally advertised by the speaker itself. As per :rfc:`4271`, a BGP speaker rejects
1697 advertisements that originated the speaker itself. However, the BGP ACCEPT_OWN
1698 mechanism enables a router to accept the prefixes it has advertised, when reflected
1699 from a route-reflector that modifies certain attributes of the prefix.
1701 A special community called ``accept-own`` is attached to the prefix by the
1702 route-reflector, which is a signal to the receiving router to bypass the ORIGINATOR_ID
1703 and NEXTHOP/MP_REACH_NLRI check.
1707 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> graceful-shutdown
1709 Mark all routes from this neighbor as less preferred by setting ``graceful-shutdown``
1710 community, and local-preference to 0.
1712 .. clicmd:: bgp fast-external-failover
1714 This command causes bgp to take down ebgp peers immediately
1715 when a link flaps. `bgp fast-external-failover` is the default
1716 and will not be displayed as part of a `show run`. The no form
1717 of the command turns off this ability.
1719 .. clicmd:: bgp default ipv4-unicast
1721 This command allows the user to specify that the IPv4 Unicast address
1722 family is turned on by default or not. This command defaults to on
1723 and is not displayed.
1724 The `no bgp default ipv4-unicast` form of the command is displayed.
1726 .. clicmd:: bgp default ipv4-multicast
1728 This command allows the user to specify that the IPv4 Multicast address
1729 family is turned on by default or not. This command defaults to off
1730 and is not displayed.
1731 The `bgp default ipv4-multicast` form of the command is displayed.
1733 .. clicmd:: bgp default ipv4-vpn
1735 This command allows the user to specify that the IPv4 MPLS VPN address
1736 family is turned on by default or not. This command defaults to off
1737 and is not displayed.
1738 The `bgp default ipv4-vpn` form of the command is displayed.
1740 .. clicmd:: bgp default ipv4-flowspec
1742 This command allows the user to specify that the IPv4 Flowspec address
1743 family is turned on by default or not. This command defaults to off
1744 and is not displayed.
1745 The `bgp default ipv4-flowspec` form of the command is displayed.
1747 .. clicmd:: bgp default ipv6-unicast
1749 This command allows the user to specify that the IPv6 Unicast address
1750 family is turned on by default or not. This command defaults to off
1751 and is not displayed.
1752 The `bgp default ipv6-unicast` form of the command is displayed.
1754 .. clicmd:: bgp default ipv6-multicast
1756 This command allows the user to specify that the IPv6 Multicast address
1757 family is turned on by default or not. This command defaults to off
1758 and is not displayed.
1759 The `bgp default ipv6-multicast` form of the command is displayed.
1761 .. clicmd:: bgp default ipv6-vpn
1763 This command allows the user to specify that the IPv6 MPLS VPN address
1764 family is turned on by default or not. This command defaults to off
1765 and is not displayed.
1766 The `bgp default ipv6-vpn` form of the command is displayed.
1768 .. clicmd:: bgp default ipv6-flowspec
1770 This command allows the user to specify that the IPv6 Flowspec address
1771 family is turned on by default or not. This command defaults to off
1772 and is not displayed.
1773 The `bgp default ipv6-flowspec` form of the command is displayed.
1775 .. clicmd:: bgp default l2vpn-evpn
1777 This command allows the user to specify that the L2VPN EVPN address
1778 family is turned on by default or not. This command defaults to off
1779 and is not displayed.
1780 The `bgp default l2vpn-evpn` form of the command is displayed.
1782 .. clicmd:: bgp default show-hostname
1784 This command shows the hostname of the peer in certain BGP commands
1785 outputs. It's easier to troubleshoot if you have a number of BGP peers.
1787 .. clicmd:: bgp default show-nexthop-hostname
1789 This command shows the hostname of the next-hop in certain BGP commands
1790 outputs. It's easier to troubleshoot if you have a number of BGP peers
1791 and a number of routes to check.
1793 .. clicmd:: neighbor PEER advertisement-interval (0-600)
1795 Setup the minimum route advertisement interval(mrai) for the
1796 peer in question. This number is between 0 and 600 seconds,
1797 with the default advertisement interval being 0.
1799 .. clicmd:: neighbor PEER timers (0-65535) (0-65535)
1801 Set keepalive and hold timers for a neighbor. The first value is keepalive
1802 and the second is hold time.
1804 .. clicmd:: neighbor PEER timers connect (1-65535)
1806 Set connect timer for a neighbor. The connect timer controls how long BGP
1807 waits between connection attempts to a neighbor.
1809 .. clicmd:: neighbor PEER timers delayopen (1-240)
1811 This command allows the user enable the
1812 `RFC 4271 <https://tools.ietf.org/html/rfc4271/>` DelayOpenTimer with the
1813 specified interval or disable it with the negating command for the peer. By
1814 default, the DelayOpenTimer is disabled. The timer interval may be set to a
1815 duration of 1 to 240 seconds.
1817 .. clicmd:: bgp minimum-holdtime (1-65535)
1819 This command allows user to prevent session establishment with BGP peers
1820 with lower holdtime less than configured minimum holdtime.
1821 When this command is not set, minimum holdtime does not work.
1823 .. clicmd:: bgp tcp-keepalive (1-65535) (1-65535) (1-30)
1825 This command allows user to configure TCP keepalive with new BGP peers.
1826 Each parameter respectively stands for TCP keepalive idle timer (seconds),
1827 interval (seconds), and maximum probes. By default, TCP keepalive is
1830 Displaying Information about Peers
1831 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1833 .. clicmd:: show bgp <afi> <safi> neighbors WORD bestpath-routes [json] [wide]
1835 For the given neighbor, WORD, that is specified list the routes selected
1836 by BGP as having the best path.
1838 .. _bgp-peer-filtering:
1843 .. clicmd:: neighbor PEER distribute-list NAME [in|out]
1845 This command specifies a distribute-list for the peer. `direct` is
1848 .. clicmd:: neighbor PEER prefix-list NAME [in|out]
1850 .. clicmd:: neighbor PEER filter-list NAME [in|out]
1852 .. clicmd:: neighbor PEER route-map NAME [in|out]
1854 Apply a route-map on the neighbor. `direct` must be `in` or `out`.
1856 .. clicmd:: bgp route-reflector allow-outbound-policy
1858 By default, attribute modification via route-map policy out is not reflected
1859 on reflected routes. This option allows the modifications to be reflected as
1860 well. Once enabled, it affects all reflected routes.
1862 .. clicmd:: neighbor PEER sender-as-path-loop-detection
1864 Enable the detection of sender side AS path loops and filter the
1865 bad routes before they are sent.
1867 This setting is disabled by default.
1874 Peer groups are used to help improve scaling by generating the same
1875 update information to all members of a peer group. Note that this means
1876 that the routes generated by a member of a peer group will be sent back
1877 to that originating peer with the originator identifier attribute set to
1878 indicated the originating peer. All peers not associated with a
1879 specific peer group are treated as belonging to a default peer group,
1880 and will share updates.
1882 .. clicmd:: neighbor WORD peer-group
1884 This command defines a new peer group.
1886 .. clicmd:: neighbor PEER peer-group PGNAME
1888 This command bind specific peer to peer group WORD.
1890 .. clicmd:: neighbor PEER solo
1892 This command is used to indicate that routes advertised by the peer
1893 should not be reflected back to the peer. This command only is only
1894 meaningful when there is a single peer defined in the peer-group.
1896 .. clicmd:: show [ip] bgp peer-group [json]
1898 This command displays configured BGP peer-groups.
1902 exit1-debian-9# show bgp peer-group
1904 BGP peer-group test1, remote AS 65001
1905 Peer-group type is external
1906 Configured address-families: IPv4 Unicast; IPv6 Unicast;
1907 1 IPv4 listen range(s)
1909 2 IPv6 listen range(s)
1913 192.168.200.1 Active
1916 BGP peer-group test2
1917 Peer-group type is external
1918 Configured address-families: IPv4 Unicast;
1920 Optional ``json`` parameter is used to display JSON output.
1928 "addressFamiliesConfigured":[
1958 "addressFamiliesConfigured":[
1964 Capability Negotiation
1965 ^^^^^^^^^^^^^^^^^^^^^^
1967 .. clicmd:: neighbor PEER strict-capability-match
1970 Strictly compares remote capabilities and local capabilities. If
1971 capabilities are different, send Unsupported Capability error then reset
1974 You may want to disable sending Capability Negotiation OPEN message optional
1975 parameter to the peer when remote peer does not implement Capability
1976 Negotiation. Please use *dont-capability-negotiate* command to disable the
1979 .. clicmd:: neighbor PEER dont-capability-negotiate
1981 Suppress sending Capability Negotiation as OPEN message optional parameter
1982 to the peer. This command only affects the peer is configured other than
1983 IPv4 unicast configuration.
1985 When remote peer does not have capability negotiation feature, remote peer
1986 will not send any capabilities at all. In that case, bgp configures the peer
1987 with configured capabilities.
1989 You may prefer locally configured capabilities more than the negotiated
1990 capabilities even though remote peer sends capabilities. If the peer is
1991 configured by *override-capability*, *bgpd* ignores received capabilities
1992 then override negotiated capabilities with configured values.
1994 Additionally the operator should be reminded that this feature fundamentally
1995 disables the ability to use widely deployed BGP features. BGP unnumbered,
1996 hostname support, AS4, Addpath, Route Refresh, ORF, Dynamic Capabilities,
1997 and graceful restart.
1999 .. clicmd:: neighbor PEER override-capability
2002 Override the result of Capability Negotiation with local configuration.
2003 Ignore remote peer's capability value.
2005 .. _bgp-as-path-access-lists:
2007 AS Path Access Lists
2008 --------------------
2010 AS path access list is user defined AS path.
2012 .. clicmd:: bgp as-path access-list WORD [seq (0-4294967295)] permit|deny LINE
2014 This command defines a new AS path access list.
2016 .. clicmd:: show bgp as-path-access-list [json]
2018 Display all BGP AS Path access lists.
2020 If the ``json`` option is specified, output is displayed in JSON format.
2022 .. clicmd:: show bgp as-path-access-list WORD [json]
2024 Display the specified BGP AS Path access list.
2026 If the ``json`` option is specified, output is displayed in JSON format.
2028 .. _bgp-bogon-filter-example:
2030 Bogon ASN filter policy configuration example
2031 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2035 bgp as-path access-list 99 permit _0_
2036 bgp as-path access-list 99 permit _23456_
2037 bgp as-path access-list 99 permit _1310[0-6][0-9]_|_13107[0-1]_
2038 bgp as-path access-list 99 seq 20 permit ^65
2040 .. _bgp-using-as-path-in-route-map:
2042 Using AS Path in Route Map
2043 --------------------------
2045 .. clicmd:: match as-path WORD
2047 For a given as-path, WORD, match it on the BGP as-path given for the prefix
2048 and if it matches do normal route-map actions. The no form of the command
2049 removes this match from the route-map.
2051 .. clicmd:: set as-path prepend AS-PATH
2053 Prepend the given string of AS numbers to the AS_PATH of the BGP path's NLRI.
2054 The no form of this command removes this set operation from the route-map.
2056 .. clicmd:: set as-path prepend last-as NUM
2058 Prepend the existing last AS number (the leftmost ASN) to the AS_PATH.
2059 The no form of this command removes this set operation from the route-map.
2061 .. clicmd:: set as-path replace <any|ASN>
2063 Replace a specific AS number to local AS number. ``any`` replaces each
2064 AS number in the AS-PATH with the local AS number.
2066 .. _bgp-communities-attribute:
2068 Communities Attribute
2069 ---------------------
2071 The BGP communities attribute is widely used for implementing policy routing.
2072 Network operators can manipulate BGP communities attribute based on their
2073 network policy. BGP communities attribute is defined in :rfc:`1997` and
2074 :rfc:`1998`. It is an optional transitive attribute, therefore local policy can
2075 travel through different autonomous system.
2077 The communities attribute is a set of communities values. Each community value
2078 is 4 octet long. The following format is used to define the community value.
2081 This format represents 4 octet communities value. ``AS`` is high order 2
2082 octet in digit format. ``VAL`` is low order 2 octet in digit format. This
2083 format is useful to define AS oriented policy value. For example,
2084 ``7675:80`` can be used when AS 7675 wants to pass local policy value 80 to
2088 ``internet`` represents well-known communities value 0.
2090 ``graceful-shutdown``
2091 ``graceful-shutdown`` represents well-known communities value
2092 ``GRACEFUL_SHUTDOWN`` ``0xFFFF0000`` ``65535:0``. :rfc:`8326` implements
2093 the purpose Graceful BGP Session Shutdown to reduce the amount of
2094 lost traffic when taking BGP sessions down for maintenance. The use
2095 of the community needs to be supported from your peers side to
2096 actually have any effect.
2099 ``accept-own`` represents well-known communities value ``ACCEPT_OWN``
2100 ``0xFFFF0001`` ``65535:1``. :rfc:`7611` implements a way to signal
2101 to a router to accept routes with a local nexthop address. This
2102 can be the case when doing policing and having traffic having a
2103 nexthop located in another VRF but still local interface to the
2104 router. It is recommended to read the RFC for full details.
2106 ``route-filter-translated-v4``
2107 ``route-filter-translated-v4`` represents well-known communities value
2108 ``ROUTE_FILTER_TRANSLATED_v4`` ``0xFFFF0002`` ``65535:2``.
2111 ``route-filter-v4`` represents well-known communities value
2112 ``ROUTE_FILTER_v4`` ``0xFFFF0003`` ``65535:3``.
2114 ``route-filter-translated-v6``
2115 ``route-filter-translated-v6`` represents well-known communities value
2116 ``ROUTE_FILTER_TRANSLATED_v6`` ``0xFFFF0004`` ``65535:4``.
2119 ``route-filter-v6`` represents well-known communities value
2120 ``ROUTE_FILTER_v6`` ``0xFFFF0005`` ``65535:5``.
2123 ``llgr-stale`` represents well-known communities value ``LLGR_STALE``
2124 ``0xFFFF0006`` ``65535:6``.
2125 Assigned and intended only for use with routers supporting the
2126 Long-lived Graceful Restart Capability as described in
2127 [Draft-IETF-uttaro-idr-bgp-persistence]_.
2128 Routers receiving routes with this community may (depending on
2129 implementation) choose allow to reject or modify routes on the
2130 presence or absence of this community.
2133 ``no-llgr`` represents well-known communities value ``NO_LLGR``
2134 ``0xFFFF0007`` ``65535:7``.
2135 Assigned and intended only for use with routers supporting the
2136 Long-lived Graceful Restart Capability as described in
2137 [Draft-IETF-uttaro-idr-bgp-persistence]_.
2138 Routers receiving routes with this community may (depending on
2139 implementation) choose allow to reject or modify routes on the
2140 presence or absence of this community.
2142 ``accept-own-nexthop``
2143 ``accept-own-nexthop`` represents well-known communities value
2144 ``accept-own-nexthop`` ``0xFFFF0008`` ``65535:8``.
2145 [Draft-IETF-agrewal-idr-accept-own-nexthop]_ describes
2146 how to tag and label VPN routes to be able to send traffic between VRFs
2147 via an internal layer 2 domain on the same PE device. Refer to
2148 [Draft-IETF-agrewal-idr-accept-own-nexthop]_ for full details.
2151 ``blackhole`` represents well-known communities value ``BLACKHOLE``
2152 ``0xFFFF029A`` ``65535:666``. :rfc:`7999` documents sending prefixes to
2153 EBGP peers and upstream for the purpose of blackholing traffic.
2154 Prefixes tagged with the this community should normally not be
2155 re-advertised from neighbors of the originating network. Upon receiving
2156 ``BLACKHOLE`` community from a BGP speaker, ``NO_ADVERTISE`` community
2157 is added automatically.
2160 ``no-export`` represents well-known communities value ``NO_EXPORT``
2161 ``0xFFFFFF01``. All routes carry this value must not be advertised to
2162 outside a BGP confederation boundary. If neighboring BGP peer is part of BGP
2163 confederation, the peer is considered as inside a BGP confederation
2164 boundary, so the route will be announced to the peer.
2167 ``no-advertise`` represents well-known communities value ``NO_ADVERTISE``
2168 ``0xFFFFFF02``. All routes carry this value must not be advertise to other
2172 ``local-AS`` represents well-known communities value ``NO_EXPORT_SUBCONFED``
2173 ``0xFFFFFF03``. All routes carry this value must not be advertised to
2174 external BGP peers. Even if the neighboring router is part of confederation,
2175 it is considered as external BGP peer, so the route will not be announced to
2179 ``no-peer`` represents well-known communities value ``NOPEER``
2180 ``0xFFFFFF04`` ``65535:65284``. :rfc:`3765` is used to communicate to
2181 another network how the originating network want the prefix propagated.
2183 When the communities attribute is received duplicate community values in the
2184 attribute are ignored and value is sorted in numerical order.
2186 .. [Draft-IETF-uttaro-idr-bgp-persistence] <https://tools.ietf.org/id/draft-uttaro-idr-bgp-persistence-04.txt>
2187 .. [Draft-IETF-agrewal-idr-accept-own-nexthop] <https://tools.ietf.org/id/draft-agrewal-idr-accept-own-nexthop-00.txt>
2189 .. _bgp-community-lists:
2193 Community lists are user defined lists of community attribute values. These
2194 lists can be used for matching or manipulating the communities attribute in
2197 There are two types of community list:
2200 This type accepts an explicit value for the attribute.
2203 This type accepts a regular expression. Because the regex must be
2204 interpreted on each use expanded community lists are slower than standard
2207 .. clicmd:: bgp community-list standard NAME permit|deny COMMUNITY
2209 This command defines a new standard community list. ``COMMUNITY`` is
2210 communities value. The ``COMMUNITY`` is compiled into community structure.
2211 We can define multiple community list under same name. In that case match
2212 will happen user defined order. Once the community list matches to
2213 communities attribute in BGP updates it return permit or deny by the
2214 community list definition. When there is no matched entry, deny will be
2215 returned. When ``COMMUNITY`` is empty it matches to any routes.
2217 .. clicmd:: bgp community-list expanded NAME permit|deny COMMUNITY
2219 This command defines a new expanded community list. ``COMMUNITY`` is a
2220 string expression of communities attribute. ``COMMUNITY`` can be a regular
2221 expression (:ref:`bgp-regular-expressions`) to match the communities
2222 attribute in BGP updates. The expanded community is only used to filter,
2226 It is recommended to use the more explicit versions of this command.
2228 .. clicmd:: bgp community-list NAME permit|deny COMMUNITY
2230 When the community list type is not specified, the community list type is
2231 automatically detected. If ``COMMUNITY`` can be compiled into communities
2232 attribute, the community list is defined as a standard community list.
2233 Otherwise it is defined as an expanded community list. This feature is left
2234 for backward compatibility. Use of this feature is not recommended.
2236 Note that all community lists share the same namespace, so it's not
2237 necessary to specify ``standard`` or ``expanded``; these modifiers are
2240 .. clicmd:: show bgp community-list [NAME detail]
2242 Displays community list information. When ``NAME`` is specified the
2243 specified community list's information is shown.
2247 # show bgp community-list
2248 Named Community standard list CLIST
2249 permit 7675:80 7675:100 no-export
2251 Named Community expanded list EXPAND
2254 # show bgp community-list CLIST detail
2255 Named Community standard list CLIST
2256 permit 7675:80 7675:100 no-export
2260 .. _bgp-numbered-community-lists:
2262 Numbered Community Lists
2263 ^^^^^^^^^^^^^^^^^^^^^^^^
2265 When number is used for BGP community list name, the number has
2266 special meanings. Community list number in the range from 1 and 99 is
2267 standard community list. Community list number in the range from 100
2268 to 500 is expanded community list. These community lists are called
2269 as numbered community lists. On the other hand normal community lists
2270 is called as named community lists.
2272 .. clicmd:: bgp community-list (1-99) permit|deny COMMUNITY
2274 This command defines a new community list. The argument to (1-99) defines
2275 the list identifier.
2277 .. clicmd:: bgp community-list (100-500) permit|deny COMMUNITY
2279 This command defines a new expanded community list. The argument to
2280 (100-500) defines the list identifier.
2282 .. _bgp-community-alias:
2287 BGP community aliases are useful to quickly identify what communities are set
2288 for a specific prefix in a human-readable format. Especially handy for a huge
2289 amount of communities. Accurately defined aliases can help you faster spot
2292 .. clicmd:: bgp community alias NAME ALIAS
2294 This command creates an alias name for a community that will be used
2295 later in various CLI outputs in a human-readable format.
2299 ~# vtysh -c 'show run' | grep 'bgp community alias'
2300 bgp community alias 65001:14 community-1
2301 bgp community alias 65001:123:1 lcommunity-1
2303 ~# vtysh -c 'show ip bgp 172.16.16.1/32'
2304 BGP routing table entry for 172.16.16.1/32, version 21
2305 Paths: (2 available, best #2, table default)
2306 Advertised to non peer-group peers:
2308 192.168.0.2 from 192.168.0.2 (172.16.16.1)
2309 Origin incomplete, metric 0, valid, external, best (Neighbor IP)
2310 Community: 65001:12 65001:13 community-1 65001:65534
2311 Large Community: lcommunity-1 65001:123:2
2312 Last update: Fri Apr 16 12:51:27 2021
2314 .. clicmd:: show bgp [afi] [safi] [all] alias WORD [wide|json]
2316 Display prefixes with matching BGP community alias.
2318 .. _bgp-using-communities-in-route-map:
2320 Using Communities in Route Maps
2321 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2323 In :ref:`route-map` we can match on or set the BGP communities attribute. Using
2324 this feature network operator can implement their network policy based on BGP
2325 communities attribute.
2327 The following commands can be used in route maps:
2329 .. clicmd:: match alias WORD
2331 This command performs match to BGP updates using community alias WORD. When
2332 the one of BGP communities value match to the one of community alias value in
2333 community alias, it is match.
2335 .. clicmd:: match community WORD exact-match [exact-match]
2337 This command perform match to BGP updates using community list WORD. When
2338 the one of BGP communities value match to the one of communities value in
2339 community list, it is match. When `exact-match` keyword is specified, match
2340 happen only when BGP updates have completely same communities value
2341 specified in the community list.
2343 .. clicmd:: set community <none|COMMUNITY> additive
2345 This command sets the community value in BGP updates. If the attribute is
2346 already configured, the newly provided value replaces the old one unless the
2347 ``additive`` keyword is specified, in which case the new value is appended
2348 to the existing value.
2350 If ``none`` is specified as the community value, the communities attribute
2353 It is not possible to set an expanded community list.
2355 .. clicmd:: set comm-list WORD delete
2357 This command remove communities value from BGP communities attribute. The
2358 ``word`` is community list name. When BGP route's communities value matches
2359 to the community list ``word``, the communities value is removed. When all
2360 of communities value is removed eventually, the BGP update's communities
2361 attribute is completely removed.
2363 .. _bgp-communities-example:
2365 Example Configuration
2366 ^^^^^^^^^^^^^^^^^^^^^
2368 The following configuration is exemplary of the most typical usage of BGP
2369 communities attribute. In the example, AS 7675 provides an upstream Internet
2370 connection to AS 100. When the following configuration exists in AS 7675, the
2371 network operator of AS 100 can set local preference in AS 7675 network by
2372 setting BGP communities attribute to the updates.
2377 neighbor 192.168.0.1 remote-as 100
2378 address-family ipv4 unicast
2379 neighbor 192.168.0.1 route-map RMAP in
2382 bgp community-list 70 permit 7675:70
2383 bgp community-list 80 permit 7675:80
2384 bgp community-list 90 permit 7675:90
2386 route-map RMAP permit 10
2388 set local-preference 70
2390 route-map RMAP permit 20
2392 set local-preference 80
2394 route-map RMAP permit 30
2396 set local-preference 90
2399 The following configuration announces ``10.0.0.0/8`` from AS 100 to AS 7675.
2400 The route has communities value ``7675:80`` so when above configuration exists
2401 in AS 7675, the announced routes' local preference value will be set to 80.
2407 neighbor 192.168.0.2 remote-as 7675
2408 address-family ipv4 unicast
2409 neighbor 192.168.0.2 route-map RMAP out
2412 ip prefix-list PLIST permit 10.0.0.0/8
2414 route-map RMAP permit 10
2415 match ip address prefix-list PLIST
2416 set community 7675:80
2419 The following configuration is an example of BGP route filtering using
2420 communities attribute. This configuration only permit BGP routes which has BGP
2421 communities value (``0:80`` and ``0:90``) or ``0:100``. The network operator can
2422 set special internal communities value at BGP border router, then limit the
2423 BGP route announcements into the internal network.
2428 neighbor 192.168.0.1 remote-as 100
2429 address-family ipv4 unicast
2430 neighbor 192.168.0.1 route-map RMAP in
2433 bgp community-list 1 permit 0:80 0:90
2434 bgp community-list 1 permit 0:100
2436 route-map RMAP permit in
2440 The following example filters BGP routes which have a community value of
2441 ``1:1``. When there is no match community-list returns ``deny``. To avoid
2442 filtering all routes, a ``permit`` line is set at the end of the
2448 neighbor 192.168.0.1 remote-as 100
2449 address-family ipv4 unicast
2450 neighbor 192.168.0.1 route-map RMAP in
2453 bgp community-list standard FILTER deny 1:1
2454 bgp community-list standard FILTER permit
2456 route-map RMAP permit 10
2457 match community FILTER
2460 The communities value keyword ``internet`` has special meanings in standard
2461 community lists. In the below example ``internet`` matches all BGP routes even
2462 if the route does not have communities attribute at all. So community list
2463 ``INTERNET`` is the same as ``FILTER`` in the previous example.
2467 bgp community-list standard INTERNET deny 1:1
2468 bgp community-list standard INTERNET permit internet
2471 The following configuration is an example of communities value deletion. With
2472 this configuration the community values ``100:1`` and ``100:2`` are removed
2473 from BGP updates. For communities value deletion, only ``permit``
2474 community-list is used. ``deny`` community-list is ignored.
2479 neighbor 192.168.0.1 remote-as 100
2480 address-family ipv4 unicast
2481 neighbor 192.168.0.1 route-map RMAP in
2484 bgp community-list standard DEL permit 100:1 100:2
2486 route-map RMAP permit 10
2487 set comm-list DEL delete
2490 .. _bgp-extended-communities-attribute:
2492 Extended Communities Attribute
2493 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2495 BGP extended communities attribute is introduced with MPLS VPN/BGP technology.
2496 MPLS VPN/BGP expands capability of network infrastructure to provide VPN
2497 functionality. At the same time it requires a new framework for policy routing.
2498 With BGP Extended Communities Attribute we can use Route Target or Site of
2499 Origin for implementing network policy for MPLS VPN/BGP.
2501 BGP Extended Communities Attribute is similar to BGP Communities Attribute. It
2502 is an optional transitive attribute. BGP Extended Communities Attribute can
2503 carry multiple Extended Community value. Each Extended Community value is
2506 BGP Extended Communities Attribute provides an extended range compared with BGP
2507 Communities Attribute. Adding to that there is a type field in each value to
2508 provides community space structure.
2510 There are two format to define Extended Community value. One is AS based format
2511 the other is IP address based format.
2514 This is a format to define AS based Extended Community value. ``AS`` part
2515 is 2 octets Global Administrator subfield in Extended Community value.
2516 ``VAL`` part is 4 octets Local Administrator subfield. ``7675:100``
2517 represents AS 7675 policy value 100.
2520 This is a format to define IP address based Extended Community value.
2521 ``IP-Address`` part is 4 octets Global Administrator subfield. ``VAL`` part
2522 is 2 octets Local Administrator subfield.
2524 .. _bgp-extended-community-lists:
2526 Extended Community Lists
2527 ^^^^^^^^^^^^^^^^^^^^^^^^
2529 .. clicmd:: bgp extcommunity-list standard NAME permit|deny EXTCOMMUNITY
2531 This command defines a new standard extcommunity-list. `extcommunity` is
2532 extended communities value. The `extcommunity` is compiled into extended
2533 community structure. We can define multiple extcommunity-list under same
2534 name. In that case match will happen user defined order. Once the
2535 extcommunity-list matches to extended communities attribute in BGP updates
2536 it return permit or deny based upon the extcommunity-list definition. When
2537 there is no matched entry, deny will be returned. When `extcommunity` is
2538 empty it matches to any routes.
2540 A special handling for ``internet`` community is applied. It matches
2543 .. clicmd:: bgp extcommunity-list expanded NAME permit|deny LINE
2545 This command defines a new expanded extcommunity-list. `line` is a string
2546 expression of extended communities attribute. `line` can be a regular
2547 expression (:ref:`bgp-regular-expressions`) to match an extended communities
2548 attribute in BGP updates.
2550 Note that all extended community lists shares a single name space, so it's
2551 not necessary to specify their type when creating or destroying them.
2553 .. clicmd:: show bgp extcommunity-list [NAME detail]
2555 This command displays current extcommunity-list information. When `name` is
2556 specified the community list's information is shown.
2559 .. _bgp-extended-communities-in-route-map:
2561 BGP Extended Communities in Route Map
2562 """""""""""""""""""""""""""""""""""""
2564 .. clicmd:: match extcommunity WORD
2566 .. clicmd:: set extcommunity none
2568 This command resets the extended community value in BGP updates. If the attribute is
2569 already configured or received from the peer, the attribute is discarded and set to
2570 none. This is useful if you need to strip incoming extended communities.
2572 .. clicmd:: set extcommunity rt EXTCOMMUNITY
2574 This command set Route Target value.
2576 .. clicmd:: set extcommunity soo EXTCOMMUNITY
2578 This command set Site of Origin value.
2580 .. clicmd:: set extcommunity bandwidth <(1-25600) | cumulative | num-multipaths> [non-transitive]
2582 This command sets the BGP link-bandwidth extended community for the prefix
2583 (best path) for which it is applied. The link-bandwidth can be specified as
2584 an ``explicit value`` (specified in Mbps), or the router can be told to use
2585 the ``cumulative bandwidth`` of all multipaths for the prefix or to compute
2586 it based on the ``number of multipaths``. The link bandwidth extended
2587 community is encoded as ``transitive`` unless the set command explicitly
2588 configures it as ``non-transitive``.
2590 .. seealso:: :ref:`wecmp_linkbw`
2592 Note that the extended expanded community is only used for `match` rule, not for
2595 .. _bgp-large-communities-attribute:
2597 Large Communities Attribute
2598 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
2600 The BGP Large Communities attribute was introduced in Feb 2017 with
2603 The BGP Large Communities Attribute is similar to the BGP Communities Attribute
2604 except that it has 3 components instead of two and each of which are 4 octets
2605 in length. Large Communities bring additional functionality and convenience
2606 over traditional communities, specifically the fact that the ``GLOBAL`` part
2607 below is now 4 octets wide allowing seamless use in networks using 4-byte ASNs.
2609 ``GLOBAL:LOCAL1:LOCAL2``
2610 This is the format to define Large Community values. Referencing :rfc:`8195`
2611 the values are commonly referred to as follows:
2613 - The ``GLOBAL`` part is a 4 octet Global Administrator field, commonly used
2614 as the operators AS number.
2615 - The ``LOCAL1`` part is a 4 octet Local Data Part 1 subfield referred to as
2617 - The ``LOCAL2`` part is a 4 octet Local Data Part 2 field and referred to
2618 as the parameter subfield.
2620 As an example, ``65551:1:10`` represents AS 65551 function 1 and parameter
2621 10. The referenced RFC above gives some guidelines on recommended usage.
2623 .. _bgp-large-community-lists:
2625 Large Community Lists
2626 """""""""""""""""""""
2628 Two types of large community lists are supported, namely `standard` and
2631 .. clicmd:: bgp large-community-list standard NAME permit|deny LARGE-COMMUNITY
2633 This command defines a new standard large-community-list. `large-community`
2634 is the Large Community value. We can add multiple large communities under
2635 same name. In that case the match will happen in the user defined order.
2636 Once the large-community-list matches the Large Communities attribute in BGP
2637 updates it will return permit or deny based upon the large-community-list
2638 definition. When there is no matched entry, a deny will be returned. When
2639 `large-community` is empty it matches any routes.
2641 .. clicmd:: bgp large-community-list expanded NAME permit|deny LINE
2643 This command defines a new expanded large-community-list. Where `line` is a
2644 string matching expression, it will be compared to the entire Large
2645 Communities attribute as a string, with each large-community in order from
2646 lowest to highest. `line` can also be a regular expression which matches
2647 this Large Community attribute.
2649 Note that all community lists share the same namespace, so it's not
2650 necessary to specify ``standard`` or ``expanded``; these modifiers are
2653 .. clicmd:: show bgp large-community-list
2655 .. clicmd:: show bgp large-community-list NAME detail
2657 This command display current large-community-list information. When
2658 `name` is specified the community list information is shown.
2660 .. clicmd:: show ip bgp large-community-info
2662 This command displays the current large communities in use.
2664 .. _bgp-large-communities-in-route-map:
2666 Large Communities in Route Map
2667 """"""""""""""""""""""""""""""
2669 .. clicmd:: match large-community LINE [exact-match]
2671 Where `line` can be a simple string to match, or a regular expression. It
2672 is very important to note that this match occurs on the entire
2673 large-community string as a whole, where each large-community is ordered
2674 from lowest to highest. When `exact-match` keyword is specified, match
2675 happen only when BGP updates have completely same large communities value
2676 specified in the large community list.
2678 .. clicmd:: set large-community LARGE-COMMUNITY
2680 .. clicmd:: set large-community LARGE-COMMUNITY LARGE-COMMUNITY
2682 .. clicmd:: set large-community LARGE-COMMUNITY additive
2684 These commands are used for setting large-community values. The first
2685 command will overwrite any large-communities currently present.
2686 The second specifies two large-communities, which overwrites the current
2687 large-community list. The third will add a large-community value without
2688 overwriting other values. Multiple large-community values can be specified.
2690 Note that the large expanded community is only used for `match` rule, not for
2693 .. _bgp-roles-and-only-to-customers:
2695 BGP Roles and Only to Customers
2696 -------------------------------
2698 BGP roles are defined in :rfc:`9234` and provide an easy way to route leaks
2699 prevention, detection and mitigation.
2701 To enable its mechanics, you must set your local role to reflect your type of
2702 peering relationship with your neighbor. Possible values of ``LOCAL-ROLE`` are:
2710 The local Role value is negotiated with the new BGP Role capability with a
2711 built-in check of the corresponding value. In case of mismatch the new OPEN
2712 Roles Mismatch Notification <2, 11> would be sent.
2714 The correct Role pairs are:
2716 * Provider - Customer
2718 * RS-Server - RS-Client
2720 .. code-block:: shell
2722 ~# vtysh -c 'show bgp neighbor' | grep 'Role'
2723 Local Role: customer
2724 Neighbor Role: provider
2725 Role: advertised and received
2727 If strict-mode is set BGP session won't become established until BGP neighbor
2728 set local Role on its side. This configuration parameter is defined in
2729 :rfc:`9234` and used to enforce corresponding configuration at your
2730 counter-part side. Default value - disabled.
2732 Routes that sent from provider, rs-server, or peer local-role (or if received
2733 by customer, rs-clinet, or peer local-role) will be marked with a new
2734 Only to Customer (OTC) attribute.
2736 Routes with this attribute can only be sent to your neighbor if your
2737 local-role is provider or rs-server. Routes with this attribute can be
2738 received only if your local-role is customer or rs-client.
2740 In case of peer-peer relationship routes can be received only if
2741 OTC value is equal to your neighbor AS number.
2743 All these rules with OTC help to detect and mitigate route leaks and
2744 happened automatically if local-role is set.
2746 .. clicmd:: neighbor PEER local-role LOCAL-ROLE [strict-mode]
2748 This command set your local-role to ``LOCAL-ROLE``:
2749 <provider|rs-server|rs-client|customer|peer>.
2751 This role helps to detect and prevent route leaks.
2753 If ``strict-mode`` is set, your neighbor must send you Capability with the
2754 value of his role (by setting local-role on his side). Otherwise, a Role
2755 Mismatch Notification will be sent.
2762 *bgpd* supports :abbr:`L3VPN (Layer 3 Virtual Private Networks)` :abbr:`VRFs
2763 (Virtual Routing and Forwarding)` for IPv4 :rfc:`4364` and IPv6 :rfc:`4659`.
2764 L3VPN routes, and their associated VRF MPLS labels, can be distributed to VPN
2765 SAFI neighbors in the *default*, i.e., non VRF, BGP instance. VRF MPLS labels
2766 are reached using *core* MPLS labels which are distributed using LDP or BGP
2767 labeled unicast. *bgpd* also supports inter-VRF route leaking.
2770 L3VPN over GRE interfaces
2771 ^^^^^^^^^^^^^^^^^^^^^^^^^
2773 In MPLS-VPN or SRv6-VPN, an L3VPN next-hop entry requires that the path
2774 chosen respectively contains a labelled path or a valid SID IPv6 address.
2775 Otherwise the L3VPN entry will not be installed. It is possible to ignore
2776 that check when the path chosen by the next-hop uses a GRE interface, and
2777 there is a route-map configured at inbound side of ipv4-vpn or ipv6-vpn
2778 address family with following syntax:
2780 .. clicmd:: set l3vpn next-hop encapsulation gre
2782 The incoming BGP L3VPN entry is accepted, provided that the next hop of the
2783 L3VPN entry uses a path that takes the GRE tunnel as outgoing interface. The
2784 remote endpoint should be configured just behind the GRE tunnel; remote
2785 device configuration may vary depending whether it acts at edge endpoint or
2786 not: in any case, the expectation is that incoming MPLS traffic received at
2787 this endpoint should be considered as a valid path for L3VPN.
2789 .. _bgp-vrf-route-leaking:
2794 BGP routes may be leaked (i.e. copied) between a unicast VRF RIB and the VPN
2795 SAFI RIB of the default VRF for use in MPLS-based L3VPNs. Unicast routes may
2796 also be leaked between any VRFs (including the unicast RIB of the default BGP
2797 instanced). A shortcut syntax is also available for specifying leaking from one
2798 VRF to another VRF using the default instance's VPN RIB as the intermediary. A
2799 common application of the VRF-VRF feature is to connect a customer's private
2800 routing domain to a provider's VPN service. Leaking is configured from the
2801 point of view of an individual VRF: ``import`` refers to routes leaked from VPN
2802 to a unicast VRF, whereas ``export`` refers to routes leaked from a unicast VRF
2808 Routes exported from a unicast VRF to the VPN RIB must be augmented by two
2811 - an :abbr:`RD (Route Distinguisher)`
2812 - an :abbr:`RTLIST (Route-target List)`
2814 Configuration for these exported routes must, at a minimum, specify these two
2817 Routes imported from the VPN RIB to a unicast VRF are selected according to
2818 their RTLISTs. Routes whose RTLIST contains at least one route-target in
2819 common with the configured import RTLIST are leaked. Configuration for these
2820 imported routes must specify an RTLIST to be matched.
2822 The RD, which carries no semantic value, is intended to make the route unique
2823 in the VPN RIB among all routes of its prefix that originate from all the
2824 customers and sites that are attached to the provider's VPN service.
2825 Accordingly, each site of each customer is typically assigned an RD that is
2826 unique across the entire provider network.
2828 The RTLIST is a set of route-target extended community values whose purpose is
2829 to specify route-leaking policy. Typically, a customer is assigned a single
2830 route-target value for import and export to be used at all customer sites. This
2831 configuration specifies a simple topology wherein a customer has a single
2832 routing domain which is shared across all its sites. More complex routing
2833 topologies are possible through use of additional route-targets to augment the
2834 leaking of sets of routes in various ways.
2836 When using the shortcut syntax for vrf-to-vrf leaking, the RD and RT are
2839 General configuration
2840 ^^^^^^^^^^^^^^^^^^^^^
2842 Configuration of route leaking between a unicast VRF RIB and the VPN SAFI RIB
2843 of the default VRF is accomplished via commands in the context of a VRF
2846 .. clicmd:: rd vpn export AS:NN|IP:nn
2848 Specifies the route distinguisher to be added to a route exported from the
2849 current unicast VRF to VPN.
2851 .. clicmd:: rt vpn import|export|both RTLIST...
2853 Specifies the route-target list to be attached to a route (export) or the
2854 route-target list to match against (import) when exporting/importing between
2855 the current unicast VRF and VPN.
2857 The RTLIST is a space-separated list of route-targets, which are BGP
2858 extended community values as described in
2859 :ref:`bgp-extended-communities-attribute`.
2861 .. clicmd:: label vpn export (0..1048575)|auto
2863 Enables an MPLS label to be attached to a route exported from the current
2864 unicast VRF to VPN. If the value specified is ``auto``, the label value is
2865 automatically assigned from a pool maintained by the Zebra daemon. If Zebra
2866 is not running, or if this command is not configured, automatic label
2867 assignment will not complete, which will block corresponding route export.
2869 .. clicmd:: nexthop vpn export A.B.C.D|X:X::X:X
2871 Specifies an optional nexthop value to be assigned to a route exported from
2872 the current unicast VRF to VPN. If left unspecified, the nexthop will be set
2873 to 0.0.0.0 or 0:0::0:0 (self).
2875 .. clicmd:: route-map vpn import|export MAP
2877 Specifies an optional route-map to be applied to routes imported or exported
2878 between the current unicast VRF and VPN.
2880 .. clicmd:: import|export vpn
2882 Enables import or export of routes between the current unicast VRF and VPN.
2884 .. clicmd:: import vrf VRFNAME
2886 Shortcut syntax for specifying automatic leaking from vrf VRFNAME to
2887 the current VRF using the VPN RIB as intermediary. The RD and RT
2888 are auto derived and should not be specified explicitly for either the
2889 source or destination VRF's.
2891 This shortcut syntax mode is not compatible with the explicit
2892 `import vpn` and `export vpn` statements for the two VRF's involved.
2893 The CLI will disallow attempts to configure incompatible leaking
2896 .. clicmd:: bgp retain route-target all
2898 It is possible to retain or not VPN prefixes that are not imported by local
2899 VRF configuration. This can be done via the following command in the context
2900 of the global VPNv4/VPNv6 family. This command defaults to on and is not
2902 The `no bgp retain route-target all` form of the command is displayed.
2904 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> soo EXTCOMMUNITY
2906 Without this command, SoO extended community attribute is configured using
2907 an inbound route map that sets the SoO value during the update process.
2908 With the introduction of the new BGP per-neighbor Site-of-Origin (SoO) feature,
2909 two new commands configured in sub-modes under router configuration mode
2910 simplify the SoO value configuration.
2912 If we configure SoO per neighbor at PEs, the SoO community is automatically
2913 added for all routes from the CPEs. Routes are validated and prevented from
2914 being sent back to the same CPE (e.g.: multi-site). This is especially needed
2915 when using ``as-override`` or ``allowas-in`` to prevent routing loops.
2917 .. clicmd:: mpls bgp forwarding
2919 It is possible to permit BGP install VPN prefixes without transport labels,
2920 by issuing the following command under the interface configuration context.
2921 This configuration will install VPN prefixes originated from an e-bgp session,
2922 and with the next-hop directly connected.
2929 .. clicmd:: segment-routing srv6
2931 Use SRv6 backend with BGP L3VPN, and go to its configuration node.
2933 .. clicmd:: locator NAME
2935 Specify the SRv6 locator to be used for SRv6 L3VPN. The Locator name must
2936 be set in zebra, but user can set it in any order.
2938 General configuration
2939 ^^^^^^^^^^^^^^^^^^^^^
2941 Configuration of the SRv6 SID used to advertise a L3VPN for both IPv4 and IPv6
2942 is accomplished via the following command in the context of a VRF:
2944 .. clicmd:: sid vpn per-vrf export (1..1048575)|auto
2946 Enables a SRv6 SID to be attached to a route exported from the current
2947 unicast VRF to VPN. A single SID is used for both IPv4 and IPv6 address
2948 families. If you want to set a SID for only IPv4 address family or IPv6
2949 address family, you need to use the command ``sid vpn export (1..1048575)|auto``
2950 in the context of an address-family. If the value specified is ``auto``,
2951 the SID value is automatically assigned from a pool maintained by the Zebra
2952 daemon. If Zebra is not running, or if this command is not configured, automatic
2953 SID assignment will not complete, which will block corresponding route export.
2957 Ethernet Virtual Network - EVPN
2958 -------------------------------
2960 Note: When using EVPN features and if you have a large number of hosts, make
2961 sure to adjust the size of the arp neighbor cache to avoid neighbor table
2962 overflow and/or excessive garbage collection. On Linux, the size of the table
2963 and garbage collection frequency can be controlled via the following
2964 sysctl configurations:
2966 .. code-block:: shell
2968 net.ipv4.neigh.default.gc_thresh1
2969 net.ipv4.neigh.default.gc_thresh2
2970 net.ipv4.neigh.default.gc_thresh3
2972 net.ipv6.neigh.default.gc_thresh1
2973 net.ipv6.neigh.default.gc_thresh2
2974 net.ipv6.neigh.default.gc_thresh3
2976 For more information, see ``man 7 arp``.
2978 .. _bgp-enabling-evpn:
2983 EVPN should be enabled on the BGP instance corresponding to the VRF acting as
2984 the underlay for the VXLAN tunneling. In most circumstances this will be the
2985 default VRF. The command to enable EVPN for a BGP instance is
2986 ``advertise-all-vni`` which lives under ``address-family l2vpn evpn``:
2992 address-family l2vpn evpn
2995 A more comprehensive configuration example can be found in the :ref:`evpn` page.
2997 .. _bgp-evpn-l3-route-targets:
2999 EVPN L3 Route-Targets
3000 ^^^^^^^^^^^^^^^^^^^^^
3002 .. clicmd:: route-target <import|export|both> <RTLIST|auto>
3004 Modify the route-target set for EVPN advertised type-2/type-5 routes.
3005 RTLIST is a list of any of matching
3006 ``(A.B.C.D:MN|EF:OPQR|GHJK:MN|*:OPQR|*:MN)`` where ``*`` indicates wildcard
3007 matching for the AS number. It will be set to match any AS number. This is
3008 useful in datacenter deployments with Downstream VNI. ``auto`` is used to
3009 retain the autoconfigure that is default behavior for L3 RTs.
3011 .. _bgp-evpn-advertise-pip:
3016 In a EVPN symmetric routing MLAG deployment, all EVPN routes advertised
3017 with anycast-IP as next-hop IP and anycast MAC as the Router MAC (RMAC - in
3018 BGP EVPN Extended-Community).
3019 EVPN picks up the next-hop IP from the VxLAN interface's local tunnel IP and
3020 the RMAC is obtained from the MAC of the L3VNI's SVI interface.
3021 Note: Next-hop IP is used for EVPN routes whether symmetric routing is
3022 deployed or not but the RMAC is only relevant for symmetric routing scenario.
3024 Current behavior is not ideal for Prefix (type-5) and self (type-2)
3025 routes. This is because the traffic from remote VTEPs routed sub optimally
3026 if they land on the system where the route does not belong.
3028 The advertise-pip feature advertises Prefix (type-5) and self (type-2)
3029 routes with system's individual (primary) IP as the next-hop and individual
3030 (system) MAC as Router-MAC (RMAC), while leaving the behavior unchanged for
3033 To support this feature there needs to have ability to co-exist a
3034 (system-MAC, system-IP) pair with a (anycast-MAC, anycast-IP) pair with the
3035 ability to terminate VxLAN-encapsulated packets received for either pair on
3036 the same L3VNI (i.e associated VLAN). This capability is needed per tenant
3039 To derive the system-MAC and the anycast MAC, there must be a
3040 separate/additional MAC-VLAN interface corresponding to L3VNI’s SVI.
3041 The SVI interface’s MAC address can be interpreted as system-MAC
3042 and MAC-VLAN interface's MAC as anycast MAC.
3044 To derive system-IP and anycast-IP, the default BGP instance's router-id is used
3045 as system-IP and the VxLAN interface’s local tunnel IP as the anycast-IP.
3047 User has an option to configure the system-IP and/or system-MAC value if the
3048 auto derived value is not preferred.
3050 Note: By default, advertise-pip feature is enabled and user has an option to
3051 disable the feature via configuration CLI. Once the feature is disabled under
3052 bgp vrf instance or MAC-VLAN interface is not configured, all the routes follow
3053 the same behavior of using same next-hop and RMAC values.
3055 .. clicmd:: advertise-pip [ip <addr> [mac <addr>]]
3057 Enables or disables advertise-pip feature, specify system-IP and/or system-MAC
3060 EVPN advertise-svi-ip
3061 ^^^^^^^^^^^^^^^^^^^^^
3062 Typically, the SVI IP address is reused on VTEPs across multiple racks. However,
3063 if you have unique SVI IP addresses that you want to be reachable you can use the
3064 advertise-svi-ip option. This option advertises the SVI IP/MAC address as a type-2
3065 route and eliminates the need for any flooding over VXLAN to reach the IP from a
3068 .. clicmd:: advertise-svi-ip
3070 Note that you should not enable both the advertise-svi-ip and the advertise-default-gw
3073 .. _bgp-evpn-overlay-index-gateway-ip:
3075 EVPN Overlay Index Gateway IP
3076 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3077 RFC https://datatracker.ietf.org/doc/html/rfc9136 explains the use of overlay
3078 indexes for recursive route resolution for EVPN type-5 route.
3080 We support gateway IP overlay index.
3081 A gateway IP, advertised with EVPN prefix route, is used to find an EVPN MAC/IP
3082 route with its IP field same as the gateway IP. This MAC/IP entry provides the
3083 nexthop VTEP and the tunnel information required for the VxLAN encapsulation.
3089 . +--------+ BGP +--------+ BGP +--------+ +--------+
3090 SN1 | | IPv4 | | EVPN | | | |
3091 ======+ Host1 +------+ PE1 +------+ PE2 +------+ Host2 +
3093 +--------+ +--------+ +--------+ +--------+
3095 Consider above topology where prefix SN1 is connected behind host1. Host1
3096 advertises SN1 to PE1 over BGP IPv4 session. PE1 advertises SN1 to PE2 using
3097 EVPN type-5 route with host1 IP as the gateway IP. PE1 also advertises
3098 Host1 MAC/IP as type-2 route which is used to resolve host1 gateway IP.
3100 PE2 receives this type-5 route and imports it into the vrf based on route
3101 targets. BGP prefix imported into the vrf uses gateway IP as its BGP nexthop.
3102 This route is installed into zebra if following conditions are satisfied:
3104 1. Gateway IP nexthop is L3 reachable.
3105 2. PE2 has received EVPN type-2 route with IP field set to gateway IP.
3107 Topology requirements:
3109 1. This feature is supported for asymmetric routing model only. While
3110 sending packets to SN1, ingress PE (PE2) performs routing and
3111 egress PE (PE1) performs only bridging.
3112 2. This feature supports only traditional(non vlan-aware) bridge model. Bridge
3113 interface associated with L2VNI is an L3 interface. i.e., this interface is
3114 configured with an address in the L2VNI subnet. Note that the gateway IP
3115 should also have an address in the same subnet.
3116 3. As this feature works in asymmetric routing model, all L2VNIs and corresponding
3117 VxLAN and bridge interfaces should be present at all the PEs.
3118 4. L3VNI configuration is required to generate and import EVPN type-5 routes.
3119 L3VNI VxLAN and bridge interfaces also should be present.
3121 A PE can use one of the following two mechanisms to advertise an EVPN type-5
3122 route with gateway IP.
3124 1. CLI to add gateway IP while generating EVPN type-5 route from a BGP IPv4/IPv6
3127 .. clicmd:: advertise <ipv4|ipv6> unicast [gateway-ip]
3129 When this CLI is configured for a BGP vrf under L2VPN EVPN address family, EVPN
3130 type-5 routes are generated for BGP prefixes in the vrf. Nexthop of the BGP
3131 prefix becomes the gateway IP of the corresponding type-5 route.
3133 If the above command is configured without the "gateway-ip" keyword, type-5
3134 routes are generated without overlay index.
3136 2. Add gateway IP to EVPN type-5 route using a route-map:
3138 .. clicmd:: set evpn gateway-ip <ipv4|ipv6> <addr>
3140 When route-map with above set clause is applied as outbound policy in BGP, it
3141 will set the gateway-ip in EVPN type-5 NLRI.
3143 Example configuration:
3148 neighbor 192.168.0.1 remote-as 101
3150 address-family ipv4 l2vpn evpn
3151 neighbor 192.168.0.1 route-map RMAP out
3154 route-map RMAP permit 10
3155 set evpn gateway-ip 10.0.0.1
3156 set evpn gateway-ip 10::1
3158 A PE that receives a type-5 route with gateway IP overlay index should have
3159 "enable-resolve-overlay-index" configuration enabled to recursively resolve the
3160 overlay index nexthop and install the prefix into zebra.
3162 .. clicmd:: enable-resolve-overlay-index
3164 Example configuration:
3169 bgp router-id 192.168.100.1
3170 no bgp ebgp-requires-policy
3171 neighbor 10.0.1.2 remote-as 65002
3173 address-family l2vpn evpn
3174 neighbor 10.0.1.2 activate
3176 enable-resolve-overlay-index
3185 All-Active Multihoming is used for redundancy and load sharing. Servers
3186 are attached to two or more PEs and the links are bonded (link-aggregation).
3187 This group of server links is referred to as an Ethernet Segment.
3191 An Ethernet Segment can be configured by specifying a system-MAC and a
3192 local discriminator or a complete ESINAME against the bond interface on the
3195 .. clicmd:: evpn mh es-id <(1-16777215)|ESINAME>
3197 .. clicmd:: evpn mh es-sys-mac X:X:X:X:X:X
3199 The sys-mac and local discriminator are used for generating a 10-byte,
3200 Type-3 Ethernet Segment ID. ESINAME is a 10-byte, Type-0 Ethernet Segment ID -
3201 "00:AA:BB:CC:DD:EE:FF:GG:HH:II".
3203 Type-1 (EAD-per-ES and EAD-per-EVI) routes are used to advertise the locally
3204 attached ESs and to learn off remote ESs in the network. Local Type-2/MAC-IP
3205 routes are also advertised with a destination ESI allowing for MAC-IP syncing
3206 between Ethernet Segment peers.
3207 Reference: RFC 7432, RFC 8365
3209 EVPN-MH is intended as a replacement for MLAG or Anycast VTEPs. In
3210 multihoming each PE has an unique VTEP address which requires the introduction
3211 of a new dataplane construct, MAC-ECMP. Here a MAC/FDB entry can point to a
3212 list of remote PEs/VTEPs.
3216 Type-4 (ESR) routes are used for Designated Forwarder (DF) election. DFs
3217 forward BUM traffic received via the overlay network. This implementation
3218 uses a preference based DF election specified by draft-ietf-bess-evpn-pref-df.
3219 The DF preference is configurable per-ES (via zebra) -
3221 .. clicmd:: evpn mh es-df-pref (1-16777215)
3223 BUM traffic is rxed via the overlay by all PEs attached to a server but
3224 only the DF can forward the de-capsulated traffic to the access port. To
3225 accommodate that non-DF filters are installed in the dataplane to drop
3228 Similarly traffic received from ES peers via the overlay cannot be forwarded
3229 to the server. This is split-horizon-filtering with local bias.
3233 Some vendors do not send EAD-per-EVI routes. To interop with them we
3234 need to relax the dependency on EAD-per-EVI routes and activate a remote
3235 ES-PE based on just the EAD-per-ES route.
3237 Note that by default we advertise and expect EAD-per-EVI routes.
3239 .. clicmd:: disable-ead-evi-rx
3241 .. clicmd:: disable-ead-evi-tx
3245 As the primary purpose of EVPN-MH is redundancy keeping the failover efficient
3246 is a recurring theme in the implementation. Following sub-features have
3247 been introduced for the express purpose of efficient ES failovers.
3249 - Layer-2 Nexthop Groups and MAC-ECMP via L2NHG.
3251 - Host routes (for symmetric IRB) via L3NHG.
3252 On dataplanes that support layer3 nexthop groups the feature can be turned
3253 on via the following BGP config -
3255 .. clicmd:: use-es-l3nhg
3257 - Local ES (MAC/Neigh) failover via ES-redirect.
3258 On dataplanes that do not have support for ES-redirect the feature can be
3259 turned off via the following zebra config -
3261 .. clicmd:: evpn mh redirect-off
3263 Uplink/Core tracking
3264 """"""""""""""""""""
3265 When all the underlay links go down the PE no longer has access to the VxLAN
3266 +overlay. To prevent blackholing of traffic the server/ES links are
3267 protodowned on the PE. A link can be setup for uplink tracking via the
3268 following zebra configuration -
3270 .. clicmd:: evpn mh uplink
3272 Proxy advertisements
3273 """"""""""""""""""""
3274 To handle hitless upgrades support for proxy advertisement has been added
3275 as specified by draft-rbickhart-evpn-ip-mac-proxy-adv. This allows a PE
3276 (say PE1) to proxy advertise a MAC-IP rxed from an ES peer (say PE2). When
3277 the ES peer (PE2) goes down PE1 continues to advertise hosts learnt from PE2
3278 for a holdtime during which it attempts to establish local reachability of
3279 the host. This holdtime is configurable via the following zebra commands -
3281 .. clicmd:: evpn mh neigh-holdtime (0-86400)
3283 .. clicmd:: evpn mh mac-holdtime (0-86400)
3287 When a switch is rebooted we wait for a brief period to allow the underlay
3288 and EVPN network to converge before enabling the ESs. For this duration the
3289 ES bonds are held protodown. The startup delay is configurable via the
3290 following zebra command -
3292 .. clicmd:: evpn mh startup-delay (0-3600)
3294 EAD-per-ES fragmentation
3295 """"""""""""""""""""""""
3296 The EAD-per-ES route carries the EVI route targets for all the broadcast
3297 domains associated with the ES. Depending on the EVI scale the EAD-per-ES
3298 route maybe fragmented.
3300 The number of EVIs per-EAD route can be configured via the following
3303 .. clicmd:: [no] ead-es-frag evi-limit (1-1000)
3305 Sample Configuration
3306 ^^^^^^^^^^^^^^^^^^^^^
3312 address-family l2vpn evpn
3313 ead-es-frag evi-limit 200
3318 EAD-per-ES route-target
3319 """""""""""""""""""""""
3320 The EAD-per-ES route by default carries all the EVI route targets. Depending
3321 on EVI scale that can result in route fragmentation. In some cases it maybe
3322 necessary to avoid this fragmentation and that can be done via the following
3324 1. Configure a single supplementary BD per-tenant VRF. This SBD needs to
3325 be provisioned on all EVPN PEs associated with the tenant-VRF.
3326 2. Config the SBD's RT as the EAD-per-ES route's export RT.
3328 Sample Configuration
3329 ^^^^^^^^^^^^^^^^^^^^^
3335 address-family l2vpn evpn
3336 ead-es-route-target export 5556:1001
3337 ead-es-route-target export 5556:1004
3338 ead-es-route-target export 5556:1008
3342 Support with VRF network namespace backend
3343 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3344 It is possible to separate overlay networks contained in VXLAN interfaces from
3345 underlay networks by using VRFs. VRF-lite and VRF-netns backends can be used for
3346 that. In the latter case, it is necessary to set both bridge and vxlan interface
3347 in the same network namespace, as below example illustrates:
3349 .. code-block:: shell
3353 ip link add name vxlan101 type vxlan id 101 dstport 4789 dev eth0 local 10.1.1.1
3354 ip link set dev vxlan101 netns vrf1
3355 ip netns exec vrf1 ip link set dev lo up
3356 ip netns exec vrf1 brctl addbr bridge101
3357 ip netns exec vrf1 brctl addif bridge101 vxlan101
3359 This makes it possible to separate not only layer 3 networks like VRF-lite networks.
3360 Also, VRF netns based make possible to separate layer 2 networks on separate VRF
3363 .. _bgp-conditional-advertisement:
3365 BGP Conditional Advertisement
3366 -----------------------------
3367 The BGP conditional advertisement feature uses the ``non-exist-map`` or the
3368 ``exist-map`` and the ``advertise-map`` keywords of the neighbor advertise-map
3369 command in order to track routes by the route prefix.
3372 1. If a route prefix is not present in the output of non-exist-map command,
3373 then advertise the route specified by the advertise-map command.
3375 2. If a route prefix is present in the output of non-exist-map command,
3376 then do not advertise the route specified by the addvertise-map command.
3379 1. If a route prefix is present in the output of exist-map command,
3380 then advertise the route specified by the advertise-map command.
3382 2. If a route prefix is not present in the output of exist-map command,
3383 then do not advertise the route specified by the advertise-map command.
3385 This feature is useful when some prefixes are advertised to one of its peers
3386 only if the information from the other peer is not present (due to failure in
3387 peering session or partial reachability etc).
3389 The conditional BGP announcements are sent in addition to the normal
3390 announcements that a BGP router sends to its peer.
3392 The conditional advertisement process is triggered by the BGP scanner process,
3393 which runs every 60 by default. This means that the maximum time for the
3394 conditional advertisement to take effect is the value of the process timer.
3396 As an optimization, while the process always runs on each timer expiry, it
3397 determines whether or not the conditional advertisement policy or the routing
3398 table has changed; if neither have changed, no processing is necessary and the
3399 scanner exits early.
3401 .. clicmd:: neighbor A.B.C.D advertise-map NAME [exist-map|non-exist-map] NAME
3403 This command enables BGP scanner process to monitor routes specified by
3404 exist-map or non-exist-map command in BGP table and conditionally advertises
3405 the routes specified by advertise-map command.
3407 .. clicmd:: bgp conditional-advertisement timer (5-240)
3409 Set the period to rerun the conditional advertisement scanner process. The
3410 default is 60 seconds.
3412 Sample Configuration
3413 ^^^^^^^^^^^^^^^^^^^^^
3417 ip address 10.10.10.2/24
3420 ip address 10.10.20.2/24
3423 ip address 203.0.113.1/32
3426 bgp log-neighbor-changes
3427 no bgp ebgp-requires-policy
3428 neighbor 10.10.10.1 remote-as 1
3429 neighbor 10.10.20.3 remote-as 3
3431 address-family ipv4 unicast
3432 neighbor 10.10.10.1 soft-reconfiguration inbound
3433 neighbor 10.10.20.3 soft-reconfiguration inbound
3434 neighbor 10.10.20.3 advertise-map ADV-MAP non-exist-map EXIST-MAP
3437 ip prefix-list DEFAULT seq 5 permit 192.0.2.5/32
3438 ip prefix-list DEFAULT seq 10 permit 192.0.2.1/32
3439 ip prefix-list EXIST seq 5 permit 10.10.10.10/32
3440 ip prefix-list DEFAULT-ROUTE seq 5 permit 0.0.0.0/0
3441 ip prefix-list IP1 seq 5 permit 10.139.224.0/20
3443 bgp community-list standard DC-ROUTES seq 5 permit 64952:3008
3444 bgp community-list standard DC-ROUTES seq 10 permit 64671:501
3445 bgp community-list standard DC-ROUTES seq 15 permit 64950:3009
3446 bgp community-list standard DEFAULT-ROUTE seq 5 permit 65013:200
3448 route-map ADV-MAP permit 10
3449 match ip address prefix-list IP1
3451 route-map ADV-MAP permit 20
3452 match community DC-ROUTES
3454 route-map EXIST-MAP permit 10
3455 match community DEFAULT-ROUTE
3456 match ip address prefix-list DEFAULT-ROUTE
3462 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.
3466 Router2# show ip bgp
3467 BGP table version is 20, local router ID is 203.0.113.1, vrf id 0
3468 Default local pref 100, local AS 2
3469 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
3470 i internal, r RIB-failure, S Stale, R Removed
3471 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
3472 Origin codes: i - IGP, e - EGP, ? - incomplete
3473 RPKI validation codes: V valid, I invalid, N Not found
3475 Network Next Hop Metric LocPrf Weight Path
3476 *> 0.0.0.0/0 10.10.10.1 0 0 1 i
3477 *> 10.139.224.0/20 10.10.10.1 0 0 1 ?
3478 *> 192.0.2.1/32 10.10.10.1 0 0 1 i
3479 *> 192.0.2.5/32 10.10.10.1 0 0 1 i
3481 Displayed 4 routes and 4 total paths
3482 Router2# show ip bgp neighbors 10.10.20.3
3484 !--- Output suppressed.
3486 For address family: IPv4 Unicast
3487 Update group 7, subgroup 7
3488 Packet Queue length 0
3489 Inbound soft reconfiguration allowed
3490 Community attribute sent to this neighbor(all)
3491 Condition NON_EXIST, Condition-map *EXIST-MAP, Advertise-map *ADV-MAP, status: Withdraw
3494 !--- Output suppressed.
3496 Router2# show ip bgp neighbors 10.10.20.3 advertised-routes
3497 BGP table version is 20, local router ID is 203.0.113.1, vrf id 0
3498 Default local pref 100, local AS 2
3499 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
3500 i internal, r RIB-failure, S Stale, R Removed
3501 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
3502 Origin codes: i - IGP, e - EGP, ? - incomplete
3503 RPKI validation codes: V valid, I invalid, N Not found
3505 Network Next Hop Metric LocPrf Weight Path
3506 *> 0.0.0.0/0 0.0.0.0 0 1 i
3507 *> 192.0.2.5/32 0.0.0.0 0 1 i
3509 Total number of prefixes 2
3511 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.
3515 Router2# show ip bgp
3516 BGP table version is 21, local router ID is 203.0.113.1, vrf id 0
3517 Default local pref 100, local AS 2
3518 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
3519 i internal, r RIB-failure, S Stale, R Removed
3520 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
3521 Origin codes: i - IGP, e - EGP, ? - incomplete
3522 RPKI validation codes: V valid, I invalid, N Not found
3524 Network Next Hop Metric LocPrf Weight Path
3525 *> 10.139.224.0/20 10.10.10.1 0 0 1 ?
3526 *> 192.0.2.1/32 10.10.10.1 0 0 1 i
3527 *> 192.0.2.5/32 10.10.10.1 0 0 1 i
3529 Displayed 3 routes and 3 total paths
3531 Router2# show ip bgp neighbors 10.10.20.3
3533 !--- Output suppressed.
3535 For address family: IPv4 Unicast
3536 Update group 7, subgroup 7
3537 Packet Queue length 0
3538 Inbound soft reconfiguration allowed
3539 Community attribute sent to this neighbor(all)
3540 Condition NON_EXIST, Condition-map *EXIST-MAP, Advertise-map *ADV-MAP, status: Advertise
3543 !--- Output suppressed.
3545 Router2# show ip bgp neighbors 10.10.20.3 advertised-routes
3546 BGP table version is 21, local router ID is 203.0.113.1, vrf id 0
3547 Default local pref 100, local AS 2
3548 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
3549 i internal, r RIB-failure, S Stale, R Removed
3550 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
3551 Origin codes: i - IGP, e - EGP, ? - incomplete
3552 RPKI validation codes: V valid, I invalid, N Not found
3554 Network Next Hop Metric LocPrf Weight Path
3555 *> 10.139.224.0/20 0.0.0.0 0 1 ?
3556 *> 192.0.2.1/32 0.0.0.0 0 1 i
3557 *> 192.0.2.5/32 0.0.0.0 0 1 i
3559 Total number of prefixes 3
3562 .. _bgp-optimal-route-reflection:
3564 BGP Optimal Route Reflection
3565 ----------------------------
3566 BGP Route Reflectors (RRs) are used to improve network scalability by reducing
3567 or eliminating the need for a full-mesh of IBGP sessions.
3569 When a BGP RR receives multiple paths for the same IP prefix, it typically
3570 selects a single best path to send for all its clients.
3571 If the RR has multiple nearly-equal best paths and the tie-break is determined
3572 by the next-hop cost, the RR advertises the path based on its view of next-hop
3573 costs, which leads to a non-optimal routing.
3574 The advertised route may differ from the path that a client would select
3575 if it had the visibility of the same set of candidate paths and used
3576 its own view of next-hop costs.
3578 Non-optimal advertisements by the RR can be a problem in hot-potato routing.
3579 Hot-potato routing aims to hand off traffic to the next AS using the closest
3580 possible exit point from the local AS.
3581 In this context, the closest exit point implies minimum IGP cost to
3582 reach the BGP next-hop.
3584 The BGP Optimal Route Reflection allows the RR to choose and send a different
3585 best path to a different or a set of RR clients.
3587 A link-state protocol is required. It can be OSPF or IS-IS.
3588 Current implementation of BGP ORR is based on the IGP cost to the BGP next hop,
3589 and not based on some configured policy.
3591 RR runs Shortest Path First (SPF) calculation with the selected
3592 router as the root of the tree and calculates the cost to every other router.
3594 This special SPF calculation with another router as the root, is referred to as
3595 a Reverse SPF (rSPF). This can only be done if the RR learns all the BGP paths
3596 from all the BGP border routers.
3598 There could be as many rSPFs run as there are RR clients.
3599 This will increase the CPU load somewhat on the RR.
3601 Current implementation allows up to three root nodes for the rSPF calculation.
3602 There is no need to configure each RR client as a root and run rSPF.
3603 Current implementation allows to configure three, the primary, the secondary,
3604 and the tertiary root, per set of RR clients, for redundancy purposes.
3605 For the BGP ORR feature to apply to any RR client, that RR client must be
3606 configured to be part of an ORR policy group.
3608 The BGP ORR feature is enabled per address family.
3610 The minimal configuration needed:
3612 1. ORR needs to be enabled for specific groups of BGP neighbors.
3613 2. For each group of BGP neighbors, at least one root needs to be configured.
3614 Optionally, a secondary and tertiary root can be configured.
3615 3. For OSPF, the root routers(RR clients) need additional configuration
3616 to make BGP ORR work.
3617 i.e. The MPLS TE configuration on the root router needs to have the minimal
3618 configuration for MPLS TE enabled so that OSPF advertises the MPLS TE
3619 router ID in an opaque-area LSA (type 10).
3620 Once the RR has an opaque-area LSA with the MPLS TE router-ID matching the
3621 configured root router address, rSPF can run and BGP on the RR can
3622 advertise the optimal route.
3624 .. clicmd:: neighbor A.B.C.D optimal-route-reflection NAME
3626 This command allows the neighbor to be part of the ORR group.
3628 .. clicmd:: optimal-route-reflection orr-1 A.B.C.D [A.B.C.D] [A.B.C.D]
3630 This command creates an ORR group with a mandatory primary root
3631 and optional secondary and/or tertiary roots.
3632 When primary is reachable it will be the active root.
3633 when primary goes down, secondary followed by tertiary takes over
3634 the active root's role.
3635 Always rSPF calculation runs active root as the root.
3636 Which means the RR advertises the path based on active root's
3637 view of next-hop costs.
3639 Sample Configuration
3640 ^^^^^^^^^^^^^^^^^^^^
3642 Sample configuration on Route Reflector
3648 debug bgp optimal-route-reflection
3651 ip address 10.10.68.8/24
3656 ip address 10.100.1.8/32
3661 neighbor 10.100.1.1 remote-as 1
3662 neighbor 10.100.1.1 update-source lo
3663 neighbor 10.100.1.2 remote-as 1
3664 neighbor 10.100.1.2 update-source lo
3665 neighbor 10.100.1.3 remote-as 1
3666 neighbor 10.100.1.3 update-source lo
3667 neighbor 10.100.1.4 remote-as 1
3668 neighbor 10.100.1.4 update-source lo
3670 address-family ipv4 unicast
3671 neighbor 10.100.1.1 route-reflector-client
3672 neighbor 10.100.1.1 optimal-route-reflection orr-1
3673 neighbor 10.100.1.2 route-reflector-client
3674 neighbor 10.100.1.2 optimal-route-reflection orr-1
3675 neighbor 10.100.1.3 route-reflector-client
3676 neighbor 10.100.1.3 optimal-route-reflection orr-1
3677 neighbor 10.100.1.4 route-reflector-client
3678 neighbor 10.100.1.4 optimal-route-reflection orr-1
3679 optimal-route-reflection orr-1 10.100.1.4 10.100.1.3 10.100.1.1
3684 ospf router-id 8.8.8.8
3685 area 0 authentication
3691 Sample configuration on RR clients
3696 ip address 10.10.34.4/24
3704 ip address 10.10.74.4/24
3712 ip address 10.100.1.4/32
3717 neighbor 10.100.1.8 remote-as 1
3718 neighbor 10.100.1.8 update-source lo
3720 address-family ipv4 unicast
3721 neighbor 10.100.1.8 soft-reconfiguration inbound
3726 ospf router-id 4.4.4.4
3727 area 0 authentication
3730 mpls-te router-address 10.100.1.4
3731 mpls-te inter-as area 0.0.0.0
3740 When Optimal Route Reflection is not enabled on RR, it sends 10.100.1.1 as the best path to its clients.
3744 Router-RR# show ip bgp neighbors 10.100.1.4
3746 !--- Output suppressed.
3748 For address family: IPv4 Unicast
3749 Update group 2, subgroup 2
3750 Packet Queue length 0
3751 Route-Reflector Client
3752 Community attribute sent to this neighbor(all)
3755 !--- Output suppressed.
3758 Router-RR# show ip bgp
3759 BGP table version is 3, local router ID is 10.100.1.8, vrf id 0
3760 Default local pref 100, local AS 1
3761 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
3762 i internal, r RIB-failure, S Stale, R Removed
3763 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
3764 Origin codes: i - IGP, e - EGP, ? - incomplete
3765 RPKI validation codes: V valid, I invalid, N Not found
3767 Network Next Hop Metric LocPrf Weight Path
3768 * i203.0.113.0/24 10.100.1.2 0 100 0 i
3769 *>i 10.100.1.1 0 100 0 i
3770 *=i 10.100.1.3 0 100 0 i
3772 Displayed 1 routes and 3 total paths
3775 Router-PE4# show ip bgp
3776 BGP table version is 5, local router ID is 10.100.1.4, vrf id 0
3777 Default local pref 100, local AS 1
3778 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
3779 i internal, r RIB-failure, S Stale, R Removed
3780 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
3781 Origin codes: i - IGP, e - EGP, ? - incomplete
3782 RPKI validation codes: V valid, I invalid, N Not found
3784 Network Next Hop Metric LocPrf Weight Path
3785 *>i203.0.113.0/24 10.100.1.1 0 100 0 i
3787 Displayed 1 routes and 1 total paths
3790 When Optimal Route Reflection is enabled on RR, it sends 10.100.1.3 as the best path to its clients.
3794 Router-RR# show ip bgp neighbors 10.100.1.4
3796 !--- Output suppressed.
3798 For address family: IPv4 Unicast
3799 Update group 1, subgroup 1
3800 Packet Queue length 0
3801 Route-Reflector Client
3802 ORR group (configured) : orr-1
3803 Community attribute sent to this neighbor(all)
3806 !--- Output suppressed.
3809 Router-RR# show ip bgp
3810 BGP table version is 1, local router ID is 10.100.1.8, vrf id 0
3811 Default local pref 100, local AS 1
3812 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
3813 i internal, r RIB-failure, S Stale, R Removed
3814 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
3815 Origin codes: i - IGP, e - EGP, ? - incomplete
3816 RPKI validation codes: V valid, I invalid, N Not found
3818 Network Next Hop Metric LocPrf Weight Path
3819 * i203.0.113.0/24 10.100.1.2 0 100 0 i
3820 *>i 10.100.1.3 0 100 0 i
3821 * i 10.100.1.1 0 100 0 i
3823 Displayed 1 routes and 3 total paths
3826 Router-RR# show ip bgp optimal-route-reflection
3828 ORR group: orr-1, IPv4 Unicast
3829 Configured root: primary: 10.100.1.4(Router-PE4), secondary: 10.100.1.3(Router-PE3), tertiary: 10.100.1.1(Router-PE1)
3830 Active Root: 10.100.1.4(Router-PE4)
3838 Number of mapping entries: 4
3856 Number of mapping entries: 14
3860 Router-PE4# show ip bgp
3861 BGP table version is 3, local router ID is 10.100.1.4, vrf id 0
3862 Default local pref 100, local AS 1
3863 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
3864 i internal, r RIB-failure, S Stale, R Removed
3865 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
3866 Origin codes: i - IGP, e - EGP, ? - incomplete
3867 RPKI validation codes: V valid, I invalid, N Not found
3869 Network Next Hop Metric LocPrf Weight Path
3870 *>i203.0.113.0/24 10.100.1.3 0 100 0 i
3872 Displayed 1 routes and 1 total paths
3880 .. clicmd:: show debug
3882 Show all enabled debugs.
3884 .. clicmd:: show bgp listeners
3886 Display Listen sockets and the vrf that created them. Useful for debugging of when
3887 listen is not working and this is considered a developer debug statement.
3889 .. clicmd:: debug bgp allow-martian
3891 Enable or disable BGP accepting martian nexthops from a peer. Please note
3892 this is not an actual debug command and this command is also being deprecated
3893 and will be removed soon. The new command is :clicmd:`bgp allow-martian-nexthop`
3895 .. clicmd:: debug bgp bfd
3897 Enable or disable debugging for BFD events. This will show BFD integration
3898 library messages and BGP BFD integration messages that are mostly state
3899 transitions and validation problems.
3901 .. clicmd:: debug bgp conditional-advertisement
3903 Enable or disable debugging of BGP conditional advertisement.
3905 .. clicmd:: debug bgp neighbor-events
3907 Enable or disable debugging for neighbor events. This provides general
3908 information on BGP events such as peer connection / disconnection, session
3909 establishment / teardown, and capability negotiation.
3911 .. clicmd:: debug bgp updates
3913 Enable or disable debugging for BGP updates. This provides information on
3914 BGP UPDATE messages transmitted and received between local and remote
3917 .. clicmd:: debug bgp keepalives
3919 Enable or disable debugging for BGP keepalives. This provides information on
3920 BGP KEEPALIVE messages transmitted and received between local and remote
3923 .. clicmd:: debug bgp bestpath <A.B.C.D/M|X:X::X:X/M>
3925 Enable or disable debugging for bestpath selection on the specified prefix.
3927 .. clicmd:: debug bgp nht
3929 Enable or disable debugging of BGP nexthop tracking.
3931 .. clicmd:: debug bgp update-groups
3933 Enable or disable debugging of dynamic update groups. This provides general
3934 information on group creation, deletion, join and prune events.
3936 .. clicmd:: debug bgp zebra
3938 Enable or disable debugging of communications between *bgpd* and *zebra*.
3940 .. clicmd:: debug bgp optimal-route-reflection
3942 Enable or disable debugging of BGP Optimal Route Reflection.
3944 Dumping Messages and Routing Tables
3945 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3947 .. clicmd:: dump bgp all PATH [INTERVAL]
3949 .. clicmd:: dump bgp all-et PATH [INTERVAL]
3952 Dump all BGP packet and events to `path` file.
3953 If `interval` is set, a new file will be created for echo `interval` of
3954 seconds. The path `path` can be set with date and time formatting
3955 (strftime). The type ‘all-et’ enables support for Extended Timestamp Header
3956 (:ref:`packet-binary-dump-format`).
3958 .. clicmd:: dump bgp updates PATH [INTERVAL]
3960 .. clicmd:: dump bgp updates-et PATH [INTERVAL]
3963 Dump only BGP updates messages to `path` file.
3964 If `interval` is set, a new file will be created for echo `interval` of
3965 seconds. The path `path` can be set with date and time formatting
3966 (strftime). The type ‘updates-et’ enables support for Extended Timestamp
3967 Header (:ref:`packet-binary-dump-format`).
3969 .. clicmd:: dump bgp routes-mrt PATH
3971 .. clicmd:: dump bgp routes-mrt PATH INTERVAL
3974 Dump whole BGP routing table to `path`. This is heavy process. The path
3975 `path` can be set with date and time formatting (strftime). If `interval` is
3976 set, a new file will be created for echo `interval` of seconds.
3978 Note: the interval variable can also be set using hours and minutes: 04h20m00.
3981 .. _bgp-other-commands:
3986 The following are available in the top level *enable* mode:
3988 .. clicmd:: clear bgp \*
3992 .. clicmd:: clear bgp ipv4|ipv6 \*
3994 Clear all peers with this address-family activated.
3996 .. clicmd:: clear bgp ipv4|ipv6 unicast \*
3998 Clear all peers with this address-family and sub-address-family activated.
4000 .. clicmd:: clear bgp ipv4|ipv6 PEER
4002 Clear peers with address of X.X.X.X and this address-family activated.
4004 .. clicmd:: clear bgp ipv4|ipv6 unicast PEER
4006 Clear peer with address of X.X.X.X and this address-family and sub-address-family activated.
4008 .. clicmd:: clear bgp ipv4|ipv6 PEER soft|in|out
4010 Clear peer using soft reconfiguration in this address-family.
4012 .. clicmd:: clear bgp ipv4|ipv6 unicast PEER soft|in|out
4014 Clear peer using soft reconfiguration in this address-family and sub-address-family.
4016 .. clicmd:: clear bgp [ipv4|ipv6] [unicast] PEER|\* message-stats
4018 Clear BGP message statistics for a specified peer or for all peers,
4019 optionally filtered by activated address-family and sub-address-family.
4021 The following are available in the ``router bgp`` mode:
4023 .. clicmd:: write-quanta (1-64)
4025 BGP message Tx I/O is vectored. This means that multiple packets are written
4026 to the peer socket at the same time each I/O cycle, in order to minimize
4027 system call overhead. This value controls how many are written at a time.
4028 Under certain load conditions, reducing this value could make peer traffic
4029 less 'bursty'. In practice, leave this settings on the default (64) unless
4030 you truly know what you are doing.
4032 .. clicmd:: read-quanta (1-10)
4034 Unlike Tx, BGP Rx traffic is not vectored. Packets are read off the wire one
4035 at a time in a loop. This setting controls how many iterations the loop runs
4036 for. As with write-quanta, it is best to leave this setting on the default.
4038 The following command is available in ``config`` mode as well as in the
4039 ``router bgp`` mode:
4041 .. clicmd:: bgp graceful-shutdown
4043 The purpose of this command is to initiate BGP Graceful Shutdown which
4044 is described in :rfc:`8326`. The use case for this is to minimize or
4045 eliminate the amount of traffic loss in a network when a planned
4046 maintenance activity such as software upgrade or hardware replacement
4047 is to be performed on a router. The feature works by re-announcing
4048 routes to eBGP peers with the GRACEFUL_SHUTDOWN community included.
4049 Peers are then expected to treat such paths with the lowest preference.
4050 This happens automatically on a receiver running FRR; with other
4051 routing protocol stacks, an inbound policy may have to be configured.
4052 In FRR, triggering graceful shutdown also results in announcing a
4053 LOCAL_PREF of 0 to iBGP peers.
4055 Graceful shutdown can be configured per BGP instance or globally for
4056 all of BGP. These two options are mutually exclusive. The no form of
4057 the command causes graceful shutdown to be stopped, and routes will
4058 be re-announced without the GRACEFUL_SHUTDOWN community and/or with
4059 the usual LOCAL_PREF value. Note that if this option is saved to
4060 the startup configuration, graceful shutdown will remain in effect
4061 across restarts of *bgpd* and will need to be explicitly disabled.
4063 .. clicmd:: bgp input-queue-limit (1-4294967295)
4065 Set the BGP Input Queue limit for all peers when messaging parsing. Increase
4066 this only if you have the memory to handle large queues of messages at once.
4068 .. _bgp-displaying-bgp-information:
4070 Displaying BGP Information
4071 ==========================
4073 The following four commands display the IPv6 and IPv4 routing tables, depending
4074 on whether or not the ``ip`` keyword is used.
4075 Actually, :clicmd:`show ip bgp` command was used on older `Quagga` routing
4076 daemon project, while :clicmd:`show bgp` command is the new format. The choice
4077 has been done to keep old format with IPv4 routing table, while new format
4078 displays IPv6 routing table.
4080 .. clicmd:: show ip bgp [all] [wide|json [detail]]
4082 .. clicmd:: show ip bgp A.B.C.D [json]
4084 .. clicmd:: show bgp [all] [wide|json [detail]]
4086 .. clicmd:: show bgp X:X::X:X [json]
4088 These commands display BGP routes. When no route is specified, the default
4089 is to display all BGP routes.
4093 BGP table version is 0, local router ID is 10.1.1.1
4094 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
4095 Origin codes: i - IGP, e - EGP, ? - incomplete
4097 Network Next Hop Metric LocPrf Weight Path
4098 \*> 1.1.1.1/32 0.0.0.0 0 32768 i
4100 Total number of prefixes 1
4102 If ``wide`` option is specified, then the prefix table's width is increased
4103 to fully display the prefix and the nexthop.
4105 This is especially handy dealing with IPv6 prefixes and
4106 if :clicmd:`[no] bgp default show-nexthop-hostname` is enabled.
4108 If ``all`` option is specified, ``ip`` keyword is ignored, show bgp all and
4109 show ip bgp all commands display routes for all AFIs and SAFIs.
4111 If ``json`` option is specified, output is displayed in JSON format.
4113 If ``detail`` option is specified after ``json``, more verbose JSON output
4116 Some other commands provide additional options for filtering the output.
4118 .. clicmd:: show [ip] bgp regexp LINE
4120 This command displays BGP routes using AS path regular expression
4121 (:ref:`bgp-regular-expressions`).
4123 .. clicmd:: show [ip] bgp [all] summary [wide] [json]
4125 Show a bgp peer summary for the specified address family.
4127 The old command structure :clicmd:`show ip bgp` may be removed in the future
4128 and should no longer be used. In order to reach the other BGP routing tables
4129 other than the IPv6 routing table given by :clicmd:`show bgp`, the new command
4130 structure is extended with :clicmd:`show bgp [afi] [safi]`.
4132 ``wide`` option gives more output like ``LocalAS`` and extended ``Desc`` to
4137 exit1# show ip bgp summary wide
4139 IPv4 Unicast Summary (VRF default):
4140 BGP router identifier 192.168.100.1, local AS number 65534 vrf-id 0
4142 RIB entries 5, using 920 bytes of memory
4143 Peers 1, using 27 KiB of memory
4145 Neighbor V AS LocalAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
4146 192.168.0.2 4 65030 123 15 22 0 0 0 00:07:00 0 1 us-east1-rs1.frrouting.org
4148 Total number of neighbors 1
4151 .. clicmd:: show bgp [afi] [safi] [all] [wide|json]
4153 .. clicmd:: show bgp [<ipv4|ipv6> <unicast|multicast|vpn|labeled-unicast|flowspec> | l2vpn evpn]
4155 These commands display BGP routes for the specific routing table indicated by
4156 the selected afi and the selected safi. If no afi and no safi value is given,
4157 the command falls back to the default IPv6 routing table.
4159 .. clicmd:: show bgp l2vpn evpn route [type <macip|2|multicast|3|es|4|prefix|5>]
4161 EVPN prefixes can also be filtered by EVPN route type.
4163 .. clicmd:: show bgp vni <all|VNI> [vtep VTEP] [type <ead|1|macip|2|multicast|3>] [<detail|json>]
4165 Display per-VNI EVPN routing table in bgp. Filter route-type, vtep, or VNI.
4167 .. clicmd:: show bgp [afi] [safi] [all] summary [json]
4169 Show a bgp peer summary for the specified address family, and subsequent
4172 .. clicmd:: show bgp [afi] [safi] [all] summary failed [json]
4174 Show a bgp peer summary for peers that are not successfully exchanging routes
4175 for the specified address family, and subsequent address-family.
4177 .. clicmd:: show bgp [afi] [safi] [all] summary established [json]
4179 Show a bgp peer summary for peers that are successfully exchanging routes
4180 for the specified address family, and subsequent address-family.
4182 .. clicmd:: show bgp [afi] [safi] [all] summary neighbor [PEER] [json]
4184 Show a bgp summary for the specified peer, address family, and
4185 subsequent address-family. The neighbor filter can be used in combination
4186 with the failed, established filters.
4188 .. clicmd:: show bgp [afi] [safi] [all] summary remote-as <internal|external|ASN> [json]
4190 Show a bgp peer summary for the specified remote-as ASN or type (``internal``
4191 for iBGP and ``external`` for eBGP sessions), address family, and subsequent
4192 address-family. The remote-as filter can be used in combination with the
4193 failed, established filters.
4195 .. clicmd:: show bgp [afi] [safi] [all] summary terse [json]
4197 Shorten the output. Do not show the following information about the BGP
4198 instances: the number of RIB entries, the table version and the used memory.
4199 The ``terse`` option can be used in combination with the remote-as, neighbor,
4200 failed and established filters, and with the ``wide`` option as well.
4202 .. clicmd:: show bgp [afi] [safi] [neighbor [PEER] [routes|advertised-routes|received-routes] [detail] [json]
4204 This command shows information on a specific BGP peer of the relevant
4205 afi and safi selected.
4207 The ``routes`` keyword displays only routes in this address-family's BGP
4208 table that were received by this peer and accepted by inbound policy.
4210 The ``advertised-routes`` keyword displays only the routes in this
4211 address-family's BGP table that were permitted by outbound policy and
4212 advertised to to this peer.
4214 The ``received-routes`` keyword displays all routes belonging to this
4215 address-family (prior to inbound policy) that were received by this peer.
4217 If ``detail`` option is specified, the detailed version of all routes
4218 will be displayed. The same format as ``show [ip] bgp [afi] [safi] PREFIX``
4219 will be used, but for the whole table of received, advertised or filtered
4222 If ``json`` option is specified, output is displayed in JSON format.
4224 .. clicmd:: show bgp [<view|vrf> VIEWVRFNAME] [afi] [safi] neighbors PEER received prefix-filter [json]
4226 Display Address Prefix ORFs received from this peer.
4228 .. clicmd:: show bgp [afi] [safi] [all] dampening dampened-paths [wide|json]
4230 Display paths suppressed due to dampening of the selected afi and safi
4233 .. clicmd:: show bgp [afi] [safi] [all] dampening flap-statistics [wide|json]
4235 Display flap statistics of routes of the selected afi and safi selected.
4237 .. clicmd:: show bgp [afi] [safi] [all] dampening parameters [json]
4239 Display details of configured dampening parameters of the selected afi and
4242 If the ``json`` option is specified, output is displayed in JSON format.
4244 .. clicmd:: show bgp [afi] [safi] [all] version (1-4294967295) [wide|json]
4246 Display prefixes with matching version numbers. The version number and
4247 above having prefixes will be listed here.
4249 It helps to identify which prefixes were installed at some point.
4251 Here is an example of how to check what prefixes were installed starting
4252 with an arbitrary version:
4254 .. code-block:: shell
4256 # vtysh -c 'show bgp ipv4 unicast json' | jq '.tableVersion'
4258 # vtysh -c 'show ip bgp version 9 json' | jq -r '.routes | keys[]'
4260 # vtysh -c 'show ip bgp version 8 json' | jq -r '.routes | keys[]'
4264 .. clicmd:: show bgp [afi] [safi] statistics
4266 Display statistics of routes of the selected afi and safi.
4268 .. clicmd:: show bgp statistics-all
4270 Display statistics of routes of all the afi and safi.
4272 .. clicmd:: show [ip] bgp [afi] [safi] [all] cidr-only [wide|json]
4274 Display routes with non-natural netmasks.
4276 .. clicmd:: show [ip] bgp [afi] [safi] [all] prefix-list WORD [wide|json]
4278 Display routes that match the specified prefix-list.
4280 If ``wide`` option is specified, then the prefix table's width is increased
4281 to fully display the prefix and the nexthop.
4283 If the ``json`` option is specified, output is displayed in JSON format.
4285 .. clicmd:: show [ip] bgp [afi] [safi] [all] access-list WORD [wide|json]
4287 Display routes that match the specified access-list.
4289 .. clicmd:: show [ip] bgp [afi] [safi] [all] filter-list WORD [wide|json]
4291 Display routes that match the specified AS-Path filter-list.
4293 If ``wide`` option is specified, then the prefix table's width is increased
4294 to fully display the prefix and the nexthop.
4296 If the ``json`` option is specified, output is displayed in JSON format.
4298 .. clicmd:: show [ip] bgp [afi] [safi] [all] route-map WORD [wide|json]
4300 Display routes that match the specified route-map.
4302 If ``wide`` option is specified, then the prefix table's width is increased
4303 to fully display the prefix and the nexthop.
4305 If the ``json`` option is specified, output is displayed in JSON format.
4307 .. clicmd:: show [ip] bgp [afi] [safi] [all] <A.B.C.D/M|X:X::X:X/M> longer-prefixes [wide|json]
4309 Displays the specified route and all more specific routes.
4311 If ``wide`` option is specified, then the prefix table's width is increased
4312 to fully display the prefix and the nexthop.
4314 If the ``json`` option is specified, output is displayed in JSON format.
4316 .. clicmd:: show [ip] bgp [afi] [safi] [all] neighbors A.B.C.D [advertised-routes|received-routes|filtered-routes] [detail] [json|wide]
4318 Display the routes advertised to a BGP neighbor or received routes
4319 from neighbor or filtered routes received from neighbor based on the
4322 If ``wide`` option is specified, then the prefix table's width is increased
4323 to fully display the prefix and the nexthop.
4325 This is especially handy dealing with IPv6 prefixes and
4326 if :clicmd:`[no] bgp default show-nexthop-hostname` is enabled.
4328 If ``all`` option is specified, ``ip`` keyword is ignored and,
4329 routes displayed for all AFIs and SAFIs.
4330 if afi is specified, with ``all`` option, routes will be displayed for
4331 each SAFI in the selcted AFI
4333 If ``detail`` option is specified, the detailed version of all routes
4334 will be displayed. The same format as ``show [ip] bgp [afi] [safi] PREFIX``
4335 will be used, but for the whole table of received, advertised or filtered
4338 If ``json`` option is specified, output is displayed in JSON format.
4340 .. clicmd:: show [ip] bgp [afi] [safi] [all] detail-routes
4342 Display the detailed version of all routes. The same format as using
4343 ``show [ip] bgp [afi] [safi] PREFIX``, but for the whole BGP table.
4345 If ``all`` option is specified, ``ip`` keyword is ignored and,
4346 routes displayed for all AFIs and SAFIs.
4348 If ``afi`` is specified, with ``all`` option, routes will be displayed for
4349 each SAFI in the selected AFI.
4351 .. _bgp-display-routes-by-community:
4353 Displaying Routes by Community Attribute
4354 ----------------------------------------
4356 The following commands allow displaying routes based on their community
4359 .. clicmd:: show [ip] bgp <ipv4|ipv6> [all] community [wide|json]
4361 .. clicmd:: show [ip] bgp <ipv4|ipv6> [all] community COMMUNITY [wide|json]
4363 .. clicmd:: show [ip] bgp <ipv4|ipv6> [all] community COMMUNITY exact-match [wide|json]
4365 These commands display BGP routes which have the community attribute.
4366 attribute. When ``COMMUNITY`` is specified, BGP routes that match that
4367 community are displayed. When `exact-match` is specified, it display only
4368 routes that have an exact match.
4370 .. clicmd:: show [ip] bgp <ipv4|ipv6> community-list WORD [json]
4372 .. clicmd:: show [ip] bgp <ipv4|ipv6> community-list WORD exact-match [json]
4374 These commands display BGP routes for the address family specified that
4375 match the specified community list. When `exact-match` is specified, it
4376 displays only routes that have an exact match.
4378 If ``wide`` option is specified, then the prefix table's width is increased
4379 to fully display the prefix and the nexthop.
4381 This is especially handy dealing with IPv6 prefixes and
4382 if :clicmd:`[no] bgp default show-nexthop-hostname` is enabled.
4384 If ``all`` option is specified, ``ip`` keyword is ignored and,
4385 routes displayed for all AFIs and SAFIs.
4386 if afi is specified, with ``all`` option, routes will be displayed for
4387 each SAFI in the selcted AFI
4389 If ``json`` option is specified, output is displayed in JSON format.
4391 .. clicmd:: show bgp labelpool <chunks|inuse|ledger|requests|summary> [json]
4393 These commands display information about the BGP labelpool used for
4394 the association of MPLS labels with routes for L3VPN and Labeled Unicast
4396 If ``chunks`` option is specified, output shows the current list of label
4397 chunks granted to BGP by Zebra, indicating the start and end label in
4400 If ``inuse`` option is specified, output shows the current inuse list of
4401 label to prefix mappings
4403 If ``ledger`` option is specified, output shows ledger list of all
4404 label requests made per prefix
4406 If ``requests`` option is specified, output shows current list of label
4407 requests which have not yet been fulfilled by the labelpool
4409 If ``summary`` option is specified, output is a summary of the counts for
4410 the chunks, inuse, ledger and requests list along with the count of
4411 outstanding chunk requests to Zebra and the number of zebra reconnects
4414 If ``json`` option is specified, output is displayed in JSON format.
4416 .. _bgp-display-routes-by-lcommunity:
4418 Displaying Routes by Large Community Attribute
4419 ----------------------------------------------
4421 The following commands allow displaying routes based on their
4422 large community attribute.
4424 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community
4426 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY
4428 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY exact-match
4430 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY json
4432 These commands display BGP routes which have the large community attribute.
4433 attribute. When ``LARGE-COMMUNITY`` is specified, BGP routes that match that
4434 large community are displayed. When `exact-match` is specified, it display
4435 only routes that have an exact match. When `json` is specified, it display
4436 routes in json format.
4438 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community-list WORD
4440 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community-list WORD exact-match
4442 .. clicmd:: show [ip] bgp <ipv4|ipv6> large-community-list WORD json
4444 These commands display BGP routes for the address family specified that
4445 match the specified large community list. When `exact-match` is specified,
4446 it displays only routes that have an exact match. When `json` is specified,
4447 it display routes in json format.
4449 .. _bgp-display-routes-by-as-path:
4452 Displaying Routes by AS Path
4453 ----------------------------
4455 .. clicmd:: show bgp ipv4|ipv6 regexp LINE
4457 This commands displays BGP routes that matches a regular
4458 expression `line` (:ref:`bgp-regular-expressions`).
4460 .. clicmd:: show [ip] bgp ipv4 vpn
4462 .. clicmd:: show [ip] bgp ipv6 vpn
4464 Print active IPV4 or IPV6 routes advertised via the VPN SAFI.
4466 .. clicmd:: show bgp ipv4 vpn summary
4468 .. clicmd:: show bgp ipv6 vpn summary
4470 Print a summary of neighbor connections for the specified AFI/SAFI combination.
4472 Displaying Routes by Route Distinguisher
4473 ----------------------------------------
4475 .. clicmd:: show bgp [<ipv4|ipv6> vpn | l2vpn evpn [route]] rd <all|RD>
4477 For L3VPN and EVPN address-families, routes can be displayed on a per-RD
4478 (Route Distinguisher) basis or for all RD's.
4480 .. clicmd:: show bgp l2vpn evpn rd <all|RD> [overlay | tags]
4482 Use the ``overlay`` or ``tags`` keywords to display the overlay/tag
4483 information about the EVPN prefixes in the selected Route Distinguisher.
4485 .. clicmd:: show bgp l2vpn evpn route rd <all|RD> mac <MAC> [ip <MAC>] [json]
4487 For EVPN Type 2 (macip) routes, a MAC address (and optionally an IP address)
4488 can be supplied to the command to only display matching prefixes in the
4491 Displaying Update Group Information
4492 -----------------------------------
4494 .. clicmd:: show bgp update-groups [advertise-queue|advertised-routes|packet-queue]
4496 Display Information about each individual update-group being used.
4497 If SUBGROUP-ID is specified only display about that particular group. If
4498 advertise-queue is specified the list of routes that need to be sent
4499 to the peers in the update-group is displayed, advertised-routes means
4500 the list of routes we have sent to the peers in the update-group and
4501 packet-queue specifies the list of packets in the queue to be sent.
4503 .. clicmd:: show bgp update-groups statistics
4505 Display Information about update-group events in FRR.
4507 Displaying Nexthop Information
4508 ------------------------------
4509 .. clicmd:: show [ip] bgp [<view|vrf> VIEWVRFNAME] nexthop ipv4 [A.B.C.D] [detail] [json]
4511 .. clicmd:: show [ip] bgp [<view|vrf> VIEWVRFNAME] nexthop ipv6 [X:X::X:X] [detail] [json]
4513 .. clicmd:: show [ip] bgp [<view|vrf> VIEWVRFNAME] nexthop [<A.B.C.D|X:X::X:X>] [detail] [json]
4515 .. clicmd:: show [ip] bgp <view|vrf> all nexthop [json]
4517 Display information about nexthops to bgp neighbors. If a certain nexthop is
4518 specified, also provides information about paths associated with the nexthop.
4519 With detail option provides information about gates of each nexthop.
4521 .. clicmd:: show [ip] bgp [<view|vrf> VIEWVRFNAME] import-check-table [detail] [json]
4523 Display information about nexthops from table that is used to check network's
4524 existence in the rib for network statements.
4526 Segment-Routing IPv6
4527 --------------------
4529 .. clicmd:: show bgp segment-routing srv6
4531 This command displays information about SRv6 L3VPN in bgpd. Specifically,
4532 what kind of Locator is being used, and its Locator chunk information.
4533 And the SID of the SRv6 Function that is actually managed on bgpd.
4534 In the following example, bgpd is using a Locator named loc1, and two SRv6
4535 Functions are managed to perform VPNv6 VRF redirect for vrf10 and vrf20.
4539 router# show bgp segment-routing srv6
4544 - sid: 2001:db8:1:1::100
4546 - sid: 2001:db8:1:1::200
4550 vpn_policy[AFI_IP].tovpn_sid: none
4551 vpn_policy[AFI_IP6].tovpn_sid: none
4553 vpn_policy[AFI_IP].tovpn_sid: none
4554 vpn_policy[AFI_IP6].tovpn_sid: 2001:db8:1:1::100
4556 vpn_policy[AFI_IP].tovpn_sid: none
4557 vpn_policy[AFI_IP6].tovpn_sid: 2001:db8:1:1::200
4560 .. _bgp-route-reflector:
4565 BGP routers connected inside the same AS through BGP belong to an internal
4566 BGP session, or IBGP. In order to prevent routing table loops, IBGP does not
4567 advertise IBGP-learned routes to other routers in the same session. As such,
4568 IBGP requires a full mesh of all peers. For large networks, this quickly becomes
4569 unscalable. Introducing route reflectors removes the need for the full-mesh.
4571 When route reflectors are configured, these will reflect the routes announced
4572 by the peers configured as clients. A route reflector client is configured
4575 .. clicmd:: neighbor PEER route-reflector-client
4578 To avoid single points of failure, multiple route reflectors can be configured.
4580 A cluster is a collection of route reflectors and their clients, and is used
4581 by route reflectors to avoid looping.
4583 .. clicmd:: bgp cluster-id A.B.C.D
4585 .. clicmd:: bgp no-rib
4587 To set and unset the BGP daemon ``-n`` / ``--no_kernel`` options during runtime
4588 to disable BGP route installation to the RIB (Zebra), the ``[no] bgp no-rib``
4589 commands can be used;
4591 Please note that setting the option during runtime will withdraw all routes in
4592 the daemons RIB from Zebra and unsetting it will announce all routes in the
4593 daemons RIB to Zebra. If the option is passed as a command line argument when
4594 starting the daemon and the configuration gets saved, the option will persist
4595 unless removed from the configuration with the negating command prior to the
4596 configuration write operation. At this point in time non SAFI_UNICAST BGP
4597 data is not properly withdrawn from zebra when this command is issued.
4599 .. clicmd:: bgp allow-martian-nexthop
4601 When a peer receives a martian nexthop as part of the NLRI for a route
4602 permit the nexthop to be used as such, instead of rejecting and resetting
4605 .. clicmd:: bgp send-extra-data zebra
4607 This command turns on the ability of BGP to send extra data to zebra. Currently,
4608 it's the AS-Path, communities, and the path selection reason. The default
4609 behavior in BGP is not to send this data. If the routes were sent to zebra and
4610 the option is changed, bgpd doesn't reinstall the routes to comply with the new
4613 .. clicmd:: bgp session-dscp (0-63)
4615 This command allows bgp to control, at a global level, the TCP dscp values
4618 .. _bgp-suppress-fib:
4620 Suppressing routes not installed in FIB
4621 =======================================
4623 The FRR implementation of BGP advertises prefixes learnt from a peer to other
4624 peers even if the routes do not get installed in the FIB. There can be
4625 scenarios where the hardware tables in some of the routers (along the path from
4626 the source to destination) is full which will result in all routes not getting
4627 installed in the FIB. If these routes are advertised to the downstream routers
4628 then traffic will start flowing and will be dropped at the intermediate router.
4630 The solution is to provide a configurable option to check for the FIB install
4631 status of the prefixes and advertise to peers if the prefixes are successfully
4632 installed in the FIB. The advertisement of the prefixes are suppressed if it is
4633 not installed in FIB.
4635 The following conditions apply will apply when checking for route installation
4638 1. The advertisement or suppression of routes based on FIB install status
4639 applies only for newly learnt routes from peer (routes which are not in
4641 2. If the route received from peer already exists in BGP local RIB and route
4642 attributes have changed (best path changed), the old path is deleted and
4643 new path is installed in FIB. The FIB install status will not have any
4644 effect. Therefore only when the route is received first time the checks
4646 3. The feature will not apply for routes learnt through other means like
4647 redistribution to bgp from other protocols. This is applicable only to
4649 4. If a route is installed in FIB and then gets deleted from the dataplane,
4650 then routes will not be withdrawn from peers. This will be considered as
4652 5. The feature will slightly increase the time required to advertise the routes
4653 to peers since the route install status needs to be received from the FIB
4654 6. If routes are received by the peer before the configuration is applied, then
4655 the bgp sessions need to be reset for the configuration to take effect.
4656 7. If the route which is already installed in dataplane is removed for some
4657 reason, sending withdraw message to peers is not currently supported.
4659 .. clicmd:: bgp suppress-fib-pending
4661 This command is applicable at the global level and at an individual
4662 bgp level. If applied at the global level all bgp instances will
4663 wait for fib installation before announcing routes and there is no
4664 way to turn it off for a particular bgp vrf.
4671 You can set different routing policy for a peer. For example, you can set
4672 different filter for a peer.
4678 neighbor 10.0.0.1 remote-as 2
4679 address-family ipv4 unicast
4680 neighbor 10.0.0.1 distribute-list 1 in
4684 neighbor 10.0.0.1 remote-as 2
4685 address-family ipv4 unicast
4686 neighbor 10.0.0.1 distribute-list 2 in
4689 This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view 2.
4690 When the update is inserted into view 1, distribute-list 1 is applied. On the
4691 other hand, when the update is inserted into view 2, distribute-list 2 is
4695 .. _bgp-regular-expressions:
4697 BGP Regular Expressions
4698 =======================
4700 BGP regular expressions are based on :t:`POSIX 1003.2` regular expressions. The
4701 following description is just a quick subset of the POSIX regular expressions.
4705 Matches any single character.
4708 Matches 0 or more occurrences of pattern.
4711 Matches 1 or more occurrences of pattern.
4714 Match 0 or 1 occurrences of pattern.
4717 Matches the beginning of the line.
4720 Matches the end of the line.
4723 The ``_`` character has special meanings in BGP regular expressions. It
4724 matches to space and comma , and AS set delimiter ``{`` and ``}`` and AS
4725 confederation delimiter ``(`` and ``)``. And it also matches to the
4726 beginning of the line and the end of the line. So ``_`` can be used for AS
4727 value boundaries match. This character technically evaluates to
4731 .. _bgp-configuration-examples:
4733 Miscellaneous Configuration Examples
4734 ====================================
4736 Example of a session to an upstream, advertising only one prefix to it.
4741 bgp router-id 10.236.87.1
4742 neighbor upstream peer-group
4743 neighbor upstream remote-as 64515
4744 neighbor upstream capability dynamic
4745 neighbor 10.1.1.1 peer-group upstream
4746 neighbor 10.1.1.1 description ACME ISP
4748 address-family ipv4 unicast
4749 network 10.236.87.0/24
4750 neighbor upstream prefix-list pl-allowed-adv out
4753 ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
4754 ip prefix-list pl-allowed-adv seq 10 deny any
4756 A more complex example including upstream, peer and customer sessions
4757 advertising global prefixes and NO_EXPORT prefixes and providing actions for
4758 customer routes based on community values. Extensive use is made of route-maps
4759 and the 'call' feature to support selective advertising of prefixes. This
4760 example is intended as guidance only, it has NOT been tested and almost
4761 certainly contains silly mistakes, if not serious flaws.
4766 bgp router-id 10.236.87.1
4767 neighbor upstream capability dynamic
4768 neighbor cust capability dynamic
4769 neighbor peer capability dynamic
4770 neighbor 10.1.1.1 remote-as 64515
4771 neighbor 10.1.1.1 peer-group upstream
4772 neighbor 10.2.1.1 remote-as 64516
4773 neighbor 10.2.1.1 peer-group upstream
4774 neighbor 10.3.1.1 remote-as 64517
4775 neighbor 10.3.1.1 peer-group cust-default
4776 neighbor 10.3.1.1 description customer1
4777 neighbor 10.4.1.1 remote-as 64518
4778 neighbor 10.4.1.1 peer-group cust
4779 neighbor 10.4.1.1 description customer2
4780 neighbor 10.5.1.1 remote-as 64519
4781 neighbor 10.5.1.1 peer-group peer
4782 neighbor 10.5.1.1 description peer AS 1
4783 neighbor 10.6.1.1 remote-as 64520
4784 neighbor 10.6.1.1 peer-group peer
4785 neighbor 10.6.1.1 description peer AS 2
4787 address-family ipv4 unicast
4788 network 10.123.456.0/24
4789 network 10.123.456.128/25 route-map rm-no-export
4790 neighbor upstream route-map rm-upstream-out out
4791 neighbor cust route-map rm-cust-in in
4792 neighbor cust route-map rm-cust-out out
4793 neighbor cust send-community both
4794 neighbor peer route-map rm-peer-in in
4795 neighbor peer route-map rm-peer-out out
4796 neighbor peer send-community both
4797 neighbor 10.3.1.1 prefix-list pl-cust1-network in
4798 neighbor 10.4.1.1 prefix-list pl-cust2-network in
4799 neighbor 10.5.1.1 prefix-list pl-peer1-network in
4800 neighbor 10.6.1.1 prefix-list pl-peer2-network in
4803 ip prefix-list pl-default permit 0.0.0.0/0
4805 ip prefix-list pl-upstream-peers permit 10.1.1.1/32
4806 ip prefix-list pl-upstream-peers permit 10.2.1.1/32
4808 ip prefix-list pl-cust1-network permit 10.3.1.0/24
4809 ip prefix-list pl-cust1-network permit 10.3.2.0/24
4811 ip prefix-list pl-cust2-network permit 10.4.1.0/24
4813 ip prefix-list pl-peer1-network permit 10.5.1.0/24
4814 ip prefix-list pl-peer1-network permit 10.5.2.0/24
4815 ip prefix-list pl-peer1-network permit 192.168.0.0/24
4817 ip prefix-list pl-peer2-network permit 10.6.1.0/24
4818 ip prefix-list pl-peer2-network permit 10.6.2.0/24
4819 ip prefix-list pl-peer2-network permit 192.168.1.0/24
4820 ip prefix-list pl-peer2-network permit 192.168.2.0/24
4821 ip prefix-list pl-peer2-network permit 172.16.1/24
4823 bgp as-path access-list seq 5 asp-own-as permit ^$
4824 bgp as-path access-list seq 10 asp-own-as permit _64512_
4826 ! #################################################################
4827 ! Match communities we provide actions for, on routes receives from
4828 ! customers. Communities values of <our-ASN>:X, with X, have actions:
4830 ! 100 - blackhole the prefix
4831 ! 200 - set no_export
4832 ! 300 - advertise only to other customers
4833 ! 400 - advertise only to upstreams
4834 ! 500 - set no_export when advertising to upstreams
4835 ! 2X00 - set local_preference to X00
4837 ! blackhole the prefix of the route
4838 bgp community-list standard cm-blackhole permit 64512:100
4840 ! set no-export community before advertising
4841 bgp community-list standard cm-set-no-export permit 64512:200
4843 ! advertise only to other customers
4844 bgp community-list standard cm-cust-only permit 64512:300
4846 ! advertise only to upstreams
4847 bgp community-list standard cm-upstream-only permit 64512:400
4849 ! advertise to upstreams with no-export
4850 bgp community-list standard cm-upstream-noexport permit 64512:500
4852 ! set local-pref to least significant 3 digits of the community
4853 bgp community-list standard cm-prefmod-100 permit 64512:2100
4854 bgp community-list standard cm-prefmod-200 permit 64512:2200
4855 bgp community-list standard cm-prefmod-300 permit 64512:2300
4856 bgp community-list standard cm-prefmod-400 permit 64512:2400
4857 bgp community-list expanded cme-prefmod-range permit 64512:2...
4859 ! Informational communities
4861 ! 3000 - learned from upstream
4862 ! 3100 - learned from customer
4863 ! 3200 - learned from peer
4865 bgp community-list standard cm-learnt-upstream permit 64512:3000
4866 bgp community-list standard cm-learnt-cust permit 64512:3100
4867 bgp community-list standard cm-learnt-peer permit 64512:3200
4869 ! ###################################################################
4870 ! Utility route-maps
4872 ! These utility route-maps generally should not used to permit/deny
4873 ! routes, i.e. they do not have meaning as filters, and hence probably
4874 ! should be used with 'on-match next'. These all finish with an empty
4875 ! permit entry so as not interfere with processing in the caller.
4877 route-map rm-no-export permit 10
4878 set community additive no-export
4879 route-map rm-no-export permit 20
4881 route-map rm-blackhole permit 10
4882 description blackhole, up-pref and ensure it cannot escape this AS
4883 set ip next-hop 127.0.0.1
4884 set local-preference 10
4885 set community additive no-export
4886 route-map rm-blackhole permit 20
4888 ! Set local-pref as requested
4889 route-map rm-prefmod permit 10
4890 match community cm-prefmod-100
4891 set local-preference 100
4892 route-map rm-prefmod permit 20
4893 match community cm-prefmod-200
4894 set local-preference 200
4895 route-map rm-prefmod permit 30
4896 match community cm-prefmod-300
4897 set local-preference 300
4898 route-map rm-prefmod permit 40
4899 match community cm-prefmod-400
4900 set local-preference 400
4901 route-map rm-prefmod permit 50
4903 ! Community actions to take on receipt of route.
4904 route-map rm-community-in permit 10
4905 description check for blackholing, no point continuing if it matches.
4906 match community cm-blackhole
4908 route-map rm-community-in permit 20
4909 match community cm-set-no-export
4912 route-map rm-community-in permit 30
4913 match community cme-prefmod-range
4915 route-map rm-community-in permit 40
4917 ! #####################################################################
4918 ! Community actions to take when advertising a route.
4919 ! These are filtering route-maps,
4921 ! Deny customer routes to upstream with cust-only set.
4922 route-map rm-community-filt-to-upstream deny 10
4923 match community cm-learnt-cust
4924 match community cm-cust-only
4925 route-map rm-community-filt-to-upstream permit 20
4927 ! Deny customer routes to other customers with upstream-only set.
4928 route-map rm-community-filt-to-cust deny 10
4929 match community cm-learnt-cust
4930 match community cm-upstream-only
4931 route-map rm-community-filt-to-cust permit 20
4933 ! ###################################################################
4934 ! The top-level route-maps applied to sessions. Further entries could
4935 ! be added obviously..
4938 route-map rm-cust-in permit 10
4939 call rm-community-in
4941 route-map rm-cust-in permit 20
4942 set community additive 64512:3100
4943 route-map rm-cust-in permit 30
4945 route-map rm-cust-out permit 10
4946 call rm-community-filt-to-cust
4948 route-map rm-cust-out permit 20
4950 ! Upstream transit ASes
4951 route-map rm-upstream-out permit 10
4952 description filter customer prefixes which are marked cust-only
4953 call rm-community-filt-to-upstream
4955 route-map rm-upstream-out permit 20
4956 description only customer routes are provided to upstreams/peers
4957 match community cm-learnt-cust
4960 ! outbound policy is same as for upstream
4961 route-map rm-peer-out permit 10
4962 call rm-upstream-out
4964 route-map rm-peer-in permit 10
4965 set community additive 64512:3200
4968 Example of how to set up a 6-Bone connection.
4972 ! bgpd configuration
4973 ! ==================
4975 ! MP-BGP configuration
4978 bgp router-id 10.0.0.1
4979 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as `as-number`
4982 network 3ffe:506::/32
4983 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
4984 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
4985 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as `as-number`
4986 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
4989 ipv6 access-list all permit any
4991 ! Set output nexthop address.
4993 route-map set-nexthop permit 10
4994 match ipv6 address all
4995 set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
4996 set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
5005 TCP provides a mechanism for the user to specify the max segment size.
5006 setsockopt API is used to set the max segment size for TCP session. We
5007 can configure this as part of BGP neighbor configuration.
5009 This document explains how to avoid ICMP vulnerability issues by limiting
5010 TCP max segment size when you are using MTU discovery. Using MTU discovery
5011 on TCP paths is one method of avoiding BGP packet fragmentation.
5013 TCP negotiates a maximum segment size (MSS) value during session connection
5014 establishment between two peers. The MSS value negotiated is primarily based
5015 on the maximum transmission unit (MTU) of the interfaces to which the
5016 communicating peers are directly connected. However, due to variations in
5017 link MTU on the path taken by the TCP packets, some packets in the network
5018 that are well within the MSS value might be fragmented when the packet size
5019 exceeds the link's MTU.
5021 This feature is supported with TCP over IPv4 and TCP over IPv6.
5025 Below configuration can be done in router bgp mode and allows the user to
5026 configure the tcp-mss value per neighbor. The configuration gets applied
5027 only after hard reset is performed on that neighbor. If we configure tcp-mss
5028 on both the neighbors then both neighbors need to be reset.
5030 The configuration takes effect based on below rules, so there is a configured
5031 tcp-mss and a synced tcp-mss value per TCP session.
5033 By default if the configuration is not done then the TCP max segment size is
5034 set to the Maximum Transmission unit (MTU) – (IP/IP6 header size + TCP header
5035 size + ethernet header). For IPv4 its MTU – (20 bytes IP header + 20 bytes TCP
5036 header + 12 bytes ethernet header) and for IPv6 its MTU – (40 bytes IPv6 header
5037 + 20 bytes TCP header + 12 bytes ethernet header).
5039 If the config is done then it reduces 12-14 bytes for the ether header and
5040 uses it after synchronizing in TCP handshake.
5042 .. clicmd:: neighbor <A.B.C.D|X:X::X:X|WORD> tcp-mss (1-65535)
5044 When tcp-mss is configured kernel reduces 12-14 bytes for ethernet header.
5045 E.g. if tcp-mss is configured as 150 the synced value will be 138.
5047 Note: configured and synced value is different since TCP module will reduce
5048 12 bytes for ethernet header.
5055 frr# show running-config
5056 Building configuration...
5058 Current configuration:
5061 bgp router-id 192.0.2.1
5062 neighbor 198.51.100.2 remote-as 100
5063 neighbor 198.51.100.2 tcp-mss 150 => new entry
5064 neighbor 2001:DB8::2 remote-as 100
5065 neighbor 2001:DB8::2 tcp-mss 400 => new entry
5072 frr# show bgp neighbors 198.51.100.2
5073 BGP neighbor is 198.51.100.2, remote AS 100, local AS 100, internal link
5075 BGP version 4, remote router ID 192.0.2.2, local router ID 192.0.2.1
5076 BGP state = Established, up for 02:15:28
5077 Last read 00:00:28, Last write 00:00:28
5078 Hold time is 180, keepalive interval is 60 seconds
5079 Configured tcp-mss is 150, synced tcp-mss is 138 => new display
5083 frr# show bgp neighbors 2001:DB8::2
5084 BGP neighbor is 2001:DB8::2, remote AS 100, local AS 100, internal link
5086 BGP version 4, remote router ID 192.0.2.2, local router ID 192.0.2.1
5087 BGP state = Established, up for 02:16:34
5088 Last read 00:00:34, Last write 00:00:34
5089 Hold time is 180, keepalive interval is 60 seconds
5090 Configured tcp-mss is 400, synced tcp-mss is 388 => new display
5092 Show command json output:
5093 -------------------------
5097 frr# show bgp neighbors 2001:DB8::2 json
5102 "nbrInternalLink":true,
5105 "remoteRouterId":"192.0.2.2",
5106 "localRouterId":"192.0.2.1",
5107 "bgpState":"Established",
5108 "bgpTimerUpMsec":8349000,
5109 "bgpTimerUpString":"02:19:09",
5110 "bgpTimerUpEstablishedEpoch":1613054251,
5111 "bgpTimerLastRead":9000,
5112 "bgpTimerLastWrite":9000,
5113 "bgpInUpdateElapsedTimeMsecs":8347000,
5114 "bgpTimerHoldTimeMsecs":180000,
5115 "bgpTimerKeepAliveIntervalMsecs":60000,
5116 "bgpTcpMssConfigured":400, => new entry
5117 "bgpTcpMssSynced":388, => new entry
5121 frr# show bgp neighbors 198.51.100.2 json
5126 "nbrInternalLink":true,
5129 "remoteRouterId":"192.0.2.2",
5130 "localRouterId":"192.0.2.1",
5131 "bgpState":"Established",
5132 "bgpTimerUpMsec":8370000,
5133 "bgpTimerUpString":"02:19:30",
5134 "bgpTimerUpEstablishedEpoch":1613054251,
5135 "bgpTimerLastRead":30000,
5136 "bgpTimerLastWrite":30000,
5137 "bgpInUpdateElapsedTimeMsecs":8368000,
5138 "bgpTimerHoldTimeMsecs":180000,
5139 "bgpTimerKeepAliveIntervalMsecs":60000,
5140 "bgpTcpMssConfigured":150, => new entry
5141 "bgpTcpMssSynced":138, => new entry
5143 .. include:: routeserver.rst
5145 .. include:: rpki.rst
5147 .. include:: wecmp_linkbw.rst
5149 .. include:: flowspec.rst
5151 .. [#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)
5152 .. [bgp-route-osci-cond] McPherson, D. and Gill, V. and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", IETF RFC3345
5153 .. [stable-flexible-ibgp] Flavel, A. and M. Roughan, "Stable and flexible iBGP", ACM SIGCOMM 2009
5154 .. [ibgp-correctness] Griffin, T. and G. Wilfong, "On the correctness of IBGP configuration", ACM SIGCOMM 2002
5156 .. _bgp-fast-convergence:
5158 BGP fast-convergence support
5159 ============================
5160 Whenever BGP peer address becomes unreachable we must bring down the BGP
5161 session immediately. Currently only single-hop EBGP sessions are brought
5162 down immediately.IBGP and multi-hop EBGP sessions wait for hold-timer
5163 expiry to bring down the sessions.
5165 This new configuration option helps user to teardown BGP sessions immediately
5166 whenever peer becomes unreachable.
5168 .. clicmd:: bgp fast-convergence
5170 This configuration is available at the bgp level. When enabled, configuration
5171 is applied to all the neighbors configured in that bgp instance.
5176 neighbor 10.0.0.2 remote-as 64496
5177 neighbor fd00::2 remote-as 64496
5178 bgp fast-convergence
5180 address-family ipv4 unicast
5184 address-family ipv6 unicast
5185 neighbor fd00::2 activate