1.. _bgp: 2 3*** 4BGP 5*** 6 7:abbr:`BGP` stands for Border Gateway Protocol. The latest BGP version is 4. 8BGP-4 is one of the Exterior Gateway Protocols and the de facto standard 9interdomain routing protocol. BGP-4 is described in :rfc:`1771` and updated by 10:rfc:`4271`. :rfc:`2858` adds multiprotocol support to BGP-4. 11 12.. _starting-bgp: 13 14Starting BGP 15============ 16 17The default configuration file of *bgpd* is :file:`bgpd.conf`. *bgpd* searches 18the 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 20config is not being used. 21 22*bgpd* specific invocation options are described below. Common options may also 23be specified (:ref:`common-invocation-options`). 24 25.. program:: bgpd 26 27.. option:: -p, --bgp_port <port> 28 29 Set the bgp protocol's port number. When port number is 0, that means do not 30 listen bgp port. 31 32.. option:: -l, --listenon 33 34 Specify a specific IP address 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. 37 38.. option:: -n, --no_kernel 39 40 Do not install learned routes into the linux kernel. This option is useful 41 for a route-reflector environment or if you are running multiple bgp 42 processes in the same namespace. This option is different than the --no_zebra 43 option in that a ZAPI connection is made. 44 45.. option:: -S, --skip_runas 46 47 Skip the normal process of checking capabilities and changing user and group 48 information. 49 50.. option:: -e, --ecmp 51 52 Run BGP with a limited ecmp capability, that is different than what BGP 53 was compiled with. The value specified must be greater than 0 and less 54 than or equal to the MULTIPATH_NUM specified on compilation. 55 56.. option:: -Z, --no_zebra 57 58 Do not communicate with zebra at all. This is different than the --no_kernel 59 option in that we do not even open a ZAPI connection to the zebra process. 60 61.. option:: -s, --socket_size 62 63 When opening tcp connections to our peers, set the socket send buffer 64 size that the kernel will use for the peers socket. This option 65 is only really useful at a very large scale. Experimentation should 66 be done to see if this is helping or not at the scale you are running 67 at. 68 69LABEL MANAGER 70------------- 71 72.. option:: -I, --int_num 73 74 Set zclient id. This is required when using Zebra label manager in proxy mode. 75 76.. _bgp-basic-concepts: 77 78Basic Concepts 79============== 80 81.. _bgp-autonomous-systems: 82 83Autonomous Systems 84------------------ 85 86From :rfc:`1930`: 87 88 An AS is a connected group of one or more IP prefixes run by one or more 89 network operators which has a SINGLE and CLEARLY DEFINED routing policy. 90 91Each AS has an identifying number associated with it called an :abbr:`ASN 92(Autonomous System Number)`. This is a two octet value ranging in value from 1 93to 65535. The AS numbers 64512 through 65535 are defined as private AS numbers. 94Private AS numbers must not be advertised on the global Internet. 95 96The :abbr:`ASN (Autonomous System Number)` is one of the essential elements of 97BGP. BGP is a distance vector routing protocol, and the AS-Path framework 98provides distance vector metric and loop detection to BGP. 99 100.. seealso:: :rfc:`1930` 101 102.. _bgp-address-families: 103 104Address Families 105---------------- 106 107Multiprotocol extensions enable BGP to carry routing information for multiple 108network layer protocols. BGP supports an Address Family Identifier (AFI) for 109IPv4 and IPv6. Support is also provided for multiple sets of per-AFI 110information via the BGP Subsequent Address Family Identifier (SAFI). FRR 111supports SAFIs for unicast information, labeled information (:rfc:`3107` and 112:rfc:`8277`), and Layer 3 VPN information (:rfc:`4364` and :rfc:`4659`). 113 114.. _bgp-route-selection: 115 116Route Selection 117--------------- 118 119The route selection process used by FRR's BGP implementation uses the following 120decision criterion, starting at the top of the list and going towards the 121bottom until one of the factors can be used. 122 1231. **Weight check** 124 125 Prefer higher local weight routes to lower routes. 126 1272. **Local preference check** 128 129 Prefer higher local preference routes to lower. 130 1313. **Local route check** 132 133 Prefer local routes (statics, aggregates, redistributed) to received routes. 134 1354. **AS path length check** 136 137 Prefer shortest hop-count AS_PATHs. 138 1395. **Origin check** 140 141 Prefer the lowest origin type route. That is, prefer IGP origin routes to 142 EGP, to Incomplete routes. 143 1446. **MED check** 145 146 Where routes with a MED were received from the same AS, prefer the route 147 with the lowest MED. :ref:`bgp-med`. 148 1497. **External check** 150 151 Prefer the route received from an external, eBGP peer over routes received 152 from other types of peers. 153 1548. **IGP cost check** 155 156 Prefer the route with the lower IGP cost. 157 1589. **Multi-path check** 159 160 If multi-pathing is enabled, then check whether the routes not yet 161 distinguished in preference may be considered equal. If 162 :clicmd:`bgp bestpath as-path multipath-relax` is set, all such routes are 163 considered equal, otherwise routes received via iBGP with identical AS_PATHs 164 or routes received from eBGP neighbours in the same AS are considered equal. 165 16610. **Already-selected external check** 167 168 Where both routes were received from eBGP peers, then prefer the route 169 which is already selected. Note that this check is not applied if 170 :clicmd:`bgp bestpath compare-routerid` is configured. This check can 171 prevent some cases of oscillation. 172 17311. **Router-ID check** 174 175 Prefer the route with the lowest `router-ID`. If the route has an 176 `ORIGINATOR_ID` attribute, through iBGP reflection, then that router ID is 177 used, otherwise the `router-ID` of the peer the route was received from is 178 used. 179 18012. **Cluster-List length check** 181 182 The route with the shortest cluster-list length is used. The cluster-list 183 reflects the iBGP reflection path the route has taken. 184 18513. **Peer address** 186 187 Prefer the route received from the peer with the higher transport layer 188 address, as a last-resort tie-breaker. 189 190.. _bgp-capability-negotiation: 191 192Capability Negotiation 193---------------------- 194 195When adding IPv6 routing information exchange feature to BGP. There were some 196proposals. :abbr:`IETF (Internet Engineering Task Force)` 197:abbr:`IDR (Inter Domain Routing)` adopted a proposal called Multiprotocol 198Extension for BGP. The specification is described in :rfc:`2283`. The protocol 199does not define new protocols. It defines new attributes to existing BGP. When 200it is used exchanging IPv6 routing information it is called BGP-4+. When it is 201used for exchanging multicast routing information it is called MBGP. 202 203*bgpd* supports Multiprotocol Extension for BGP. So if a remote peer supports 204the protocol, *bgpd* can exchange IPv6 and/or multicast routing information. 205 206Traditional BGP did not have the feature to detect a remote peer's 207capabilities, e.g. whether it can handle prefix types other than IPv4 unicast 208routes. This was a big problem using Multiprotocol Extension for BGP in an 209operational network. :rfc:`2842` adopted a feature called Capability 210Negotiation. *bgpd* use this Capability Negotiation to detect the remote peer's 211capabilities. If a peer is only configured as an IPv4 unicast neighbor, *bgpd* 212does not send these Capability Negotiation packets (at least not unless other 213optional BGP features require capability negotiation). 214 215By default, FRR will bring up peering with minimal common capability for the 216both sides. For example, if the local router has unicast and multicast 217capabilities and the remote router only has unicast capability the local router 218will establish the connection with unicast only capability. When there are no 219common capabilities, FRR sends Unsupported Capability error and then resets the 220connection. 221 222.. _bgp-router-configuration: 223 224BGP Router Configuration 225======================== 226 227ASN and Router ID 228----------------- 229 230First of all you must configure BGP router with the :clicmd:`router bgp ASN` 231command. The AS number is an identifier for the autonomous system. The BGP 232protocol uses the AS number for detecting whether the BGP connection is 233internal or external. 234 235.. index:: router bgp ASN 236.. clicmd:: router bgp ASN 237 238 Enable a BGP protocol process with the specified ASN. After 239 this statement you can input any `BGP Commands`. 240 241.. index:: no router bgp ASN 242.. clicmd:: no router bgp ASN 243 244 Destroy a BGP protocol process with the specified ASN. 245 246.. index:: bgp router-id A.B.C.D 247.. clicmd:: bgp router-id A.B.C.D 248 249 This command specifies the router-ID. If *bgpd* connects to *zebra* it gets 250 interface and address information. In that case default router ID value is 251 selected as the largest IP Address of the interfaces. When `router zebra` is 252 not enabled *bgpd* can't get interface information so `router-id` is set to 253 0.0.0.0. So please set router-id by hand. 254 255 256.. _bgp-multiple-autonomous-systems: 257 258Multiple Autonomous Systems 259--------------------------- 260 261FRR's BGP implementation is capable of running multiple autonomous systems at 262once. Each configured AS corresponds to a :ref:`zebra-vrf`. In the past, to get 263the same functionality the network administrator had to run a new *bgpd* 264process; using VRFs allows multiple autonomous systems to be handled in a 265single process. 266 267When using multiple autonomous systems, all router config blocks after the 268first one must specify a VRF to be the target of BGP's route selection. This 269VRF must be unique within respect to all other VRFs being used for the same 270purpose, i.e. two different autonomous systems cannot use the same VRF. 271However, the same AS can be used with different VRFs. 272 273.. note:: 274 275 The separated nature of VRFs makes it possible to peer a single *bgpd* 276 process to itself, on one machine. Note that this can be done fully within 277 BGP without a corresponding VRF in the kernel or Zebra, which enables some 278 practical use cases such as :ref:`route reflectors <bgp-route-reflector>` 279 and route servers. 280 281Configuration of additional autonomous systems, or of a router that targets a 282specific VRF, is accomplished with the following command: 283 284.. index:: router bgp ASN vrf VRFNAME 285.. clicmd:: router bgp ASN vrf VRFNAME 286 287 ``VRFNAME`` is matched against VRFs configured in the kernel. When ``vrf 288 VRFNAME`` is not specified, the BGP protocol process belongs to the default 289 VRF. 290 291An example configuration with multiple autonomous systems might look like this: 292 293.. code-block:: frr 294 295 router bgp 1 296 neighbor 10.0.0.1 remote-as 20 297 neighbor 10.0.0.2 remote-as 30 298 ! 299 router bgp 2 vrf blue 300 neighbor 10.0.0.3 remote-as 40 301 neighbor 10.0.0.4 remote-as 50 302 ! 303 router bgp 3 vrf red 304 neighbor 10.0.0.5 remote-as 60 305 neighbor 10.0.0.6 remote-as 70 306 ... 307 308.. seealso:: :ref:`bgp-vrf-route-leaking` 309.. seealso:: :ref:`zebra-vrf` 310 311 312.. _bgp-views: 313 314Views 315----- 316 317In addition to supporting multiple autonomous systems, FRR's BGP implementation 318also supports *views*. 319 320BGP views are almost the same as normal BGP processes, except that routes 321selected by BGP are not installed into the kernel routing table. Each BGP view 322provides an independent set of routing information which is only distributed 323via BGP. Multiple views can be supported, and BGP view information is always 324independent from other routing protocols and Zebra/kernel routes. BGP views use 325the core instance (i.e., default VRF) for communication with peers. 326 327.. index:: router bgp AS-NUMBER view NAME 328.. clicmd:: router bgp AS-NUMBER view NAME 329 330 Make a new BGP view. You can use an arbitrary word for the ``NAME``. Routes 331 selected by the view are not installed into the kernel routing table. 332 333 With this command, you can setup Route Server like below. 334 335 .. code-block:: frr 336 337 ! 338 router bgp 1 view 1 339 neighbor 10.0.0.1 remote-as 2 340 neighbor 10.0.0.2 remote-as 3 341 ! 342 router bgp 2 view 2 343 neighbor 10.0.0.3 remote-as 4 344 neighbor 10.0.0.4 remote-as 5 345 346.. index:: show [ip] bgp view NAME 347.. clicmd:: show [ip] bgp view NAME 348 349 Display the routing table of BGP view ``NAME``. 350 351 352Route Selection 353--------------- 354 355.. index:: bgp bestpath as-path confed 356.. clicmd:: bgp bestpath as-path confed 357 358 This command specifies that the length of confederation path sets and 359 sequences should should be taken into account during the BGP best path 360 decision process. 361 362.. index:: bgp bestpath as-path multipath-relax 363.. clicmd:: bgp bestpath as-path multipath-relax 364 365 This command specifies that BGP decision process should consider paths 366 of equal AS_PATH length candidates for multipath computation. Without 367 the knob, the entire AS_PATH must match for multipath computation. 368 369.. clicmd:: bgp bestpath compare-routerid 370 371 Ensure that when comparing routes where both are equal on most metrics, 372 including local-pref, AS_PATH length, IGP cost, MED, that the tie is broken 373 based on router-ID. 374 375 If this option is enabled, then the already-selected check, where 376 already selected eBGP routes are preferred, is skipped. 377 378 If a route has an `ORIGINATOR_ID` attribute because it has been reflected, 379 that `ORIGINATOR_ID` will be used. Otherwise, the router-ID of the peer the 380 route was received from will be used. 381 382 The advantage of this is that the route-selection (at this point) will be 383 more deterministic. The disadvantage is that a few or even one lowest-ID 384 router may attract all traffic to otherwise-equal paths because of this 385 check. It may increase the possibility of MED or IGP oscillation, unless 386 other measures were taken to avoid these. The exact behaviour will be 387 sensitive to the iBGP and reflection topology. 388 389.. _bgp-distance: 390 391Administrative Distance Metrics 392------------------------------- 393 394.. index:: distance bgp (1-255) (1-255) (1-255) 395.. clicmd:: distance bgp (1-255) (1-255) (1-255) 396 397 This command change distance value of BGP. The arguments are the distance 398 values for for external routes, internal routes and local routes 399 respectively. 400 401.. index:: distance (1-255) A.B.C.D/M 402.. clicmd:: distance (1-255) A.B.C.D/M 403 404.. index:: distance (1-255) A.B.C.D/M WORD 405.. clicmd:: distance (1-255) A.B.C.D/M WORD 406 407 Sets the administrative distance for a particular route. 408 409.. _bgp-requires-policy: 410 411Require policy on EBGP 412------------------------------- 413 414.. index:: [no] bgp ebgp-requires-policy 415.. clicmd:: [no] bgp ebgp-requires-policy 416 417 This command requires incoming and outgoing filters to be applied 418 for eBGP sessions as part of RFC-8212 compliance. Without the incoming 419 filter, no routes will be accepted. Without the outgoing filter, no 420 routes will be announced. 421 422 This is enabled by default for the traditional configuration and 423 turned off by default for datacenter configuration. 424 425 When you enable/disable this option you MUST clear the session. 426 427 When the incoming or outgoing filter is missing you will see 428 "(Policy)" sign under ``show bgp summary``: 429 430 .. code-block:: frr 431 432 exit1# show bgp summary 433 434 IPv4 Unicast Summary: 435 BGP router identifier 10.10.10.1, local AS number 65001 vrf-id 0 436 BGP table version 4 437 RIB entries 7, using 1344 bytes of memory 438 Peers 2, using 43 KiB of memory 439 440 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt 441 192.168.0.2 4 65002 8 10 0 0 0 00:03:09 5 (Policy) 442 fe80:1::2222 4 65002 9 11 0 0 0 00:03:09 (Policy) (Policy) 443 444 Additionally a `show bgp neighbor` command would indicate in the `For address family:` 445 block that: 446 447 .. code-block:: frr 448 449 exit1# show bgp neighbor 450 ... 451 For address family: IPv4 Unicast 452 Update group 1, subgroup 1 453 Packet Queue length 0 454 Inbound soft reconfiguration allowed 455 Community attribute sent to this neighbor(all) 456 Inbound updates discarded due to missing policy 457 Outbound updates discarded due to missing policy 458 0 accepted prefixes 459 460Reject routes with AS_SET or AS_CONFED_SET types 461------------------------------------------------ 462 463.. index:: [no] bgp reject-as-sets 464.. clicmd:: [no] bgp reject-as-sets 465 466 This command enables rejection of incoming and outgoing routes having AS_SET or AS_CONFED_SET type. 467 468Disable checking if nexthop is connected on EBGP sessions 469--------------------------------------------------------- 470 471.. index:: [no] bgp disable-ebgp-connected-route-check 472.. clicmd:: [no] bgp disable-ebgp-connected-route-check 473 474 This command is used to disable the connection verification process for EBGP peering sessions 475 that are reachable by a single hop but are configured on a loopback interface or otherwise 476 configured with a non-directly connected IP address. 477 478.. _bgp-route-flap-dampening: 479 480Route Flap Dampening 481-------------------- 482 483.. clicmd:: bgp dampening (1-45) (1-20000) (1-20000) (1-255) 484 485 This command enables BGP route-flap dampening and specifies dampening parameters. 486 487 half-life 488 Half-life time for the penalty 489 490 reuse-threshold 491 Value to start reusing a route 492 493 suppress-threshold 494 Value to start suppressing a route 495 496 max-suppress 497 Maximum duration to suppress a stable route 498 499 The route-flap damping algorithm is compatible with :rfc:`2439`. The use of 500 this command is not recommended nowadays. 501 502 At the moment, route-flap dampening is not working per VRF and is working only 503 for IPv4 unicast and multicast. 504 505.. seealso:: 506 https://www.ripe.net/publications/docs/ripe-378 507 508.. _bgp-med: 509 510Multi-Exit Discriminator 511------------------------ 512 513The BGP :abbr:`MED (Multi-Exit Discriminator)` attribute has properties which 514can cause subtle convergence problems in BGP. These properties and problems 515have proven to be hard to understand, at least historically, and may still not 516be widely understood. The following attempts to collect together and present 517what is known about MED, to help operators and FRR users in designing and 518configuring their networks. 519 520The BGP :abbr:`MED` attribute is intended to allow one AS to indicate its 521preferences for its ingress points to another AS. The MED attribute will not be 522propagated on to another AS by the receiving AS - it is 'non-transitive' in the 523BGP sense. 524 525E.g., if AS X and AS Y have 2 different BGP peering points, then AS X might set 526a MED of 100 on routes advertised at one and a MED of 200 at the other. When AS 527Y selects between otherwise equal routes to or via AS X, AS Y should prefer to 528take the path via the lower MED peering of 100 with AS X. Setting the MED 529allows an AS to influence the routing taken to it within another, neighbouring 530AS. 531 532In this use of MED it is not really meaningful to compare the MED value on 533routes where the next AS on the paths differs. E.g., if AS Y also had a route 534for some destination via AS Z in addition to the routes from AS X, and AS Z had 535also set a MED, it wouldn't make sense for AS Y to compare AS Z's MED values to 536those of AS X. The MED values have been set by different administrators, with 537different frames of reference. 538 539The default behaviour of BGP therefore is to not compare MED values across 540routes received from different neighbouring ASes. In FRR this is done by 541comparing the neighbouring, left-most AS in the received AS_PATHs of the routes 542and only comparing MED if those are the same. 543 544Unfortunately, this behaviour of MED, of sometimes being compared across routes 545and sometimes not, depending on the properties of those other routes, means MED 546can cause the order of preference over all the routes to be undefined. That is, 547given routes A, B, and C, if A is preferred to B, and B is preferred to C, then 548a well-defined order should mean the preference is transitive (in the sense of 549orders [#med-transitivity-rant]_) and that A would be preferred to C. 550 551However, when MED is involved this need not be the case. With MED it is 552possible that C is actually preferred over A. So A is preferred to B, B is 553preferred to C, but C is preferred to A. This can be true even where BGP 554defines a deterministic 'most preferred' route out of the full set of A,B,C. 555With MED, for any given set of routes there may be a deterministically 556preferred route, but there need not be any way to arrange them into any order 557of preference. With unmodified MED, the order of preference of routes literally 558becomes undefined. 559 560That MED can induce non-transitive preferences over routes can cause issues. 561Firstly, it may be perceived to cause routing table churn locally at speakers; 562secondly, and more seriously, it may cause routing instability in iBGP 563topologies, where sets of speakers continually oscillate between different 564paths. 565 566The first issue arises from how speakers often implement routing decisions. 567Though BGP defines a selection process that will deterministically select the 568same route as best at any given speaker, even with MED, that process requires 569evaluating all routes together. For performance and ease of implementation 570reasons, many implementations evaluate route preferences in a pair-wise fashion 571instead. Given there is no well-defined order when MED is involved, the best 572route that will be chosen becomes subject to implementation details, such as 573the order the routes are stored in. That may be (locally) non-deterministic, 574e.g.: it may be the order the routes were received in. 575 576This indeterminism may be considered undesirable, though it need not cause 577problems. It may mean additional routing churn is perceived, as sometimes more 578updates may be produced than at other times in reaction to some event . 579 580This first issue can be fixed with a more deterministic route selection that 581ensures routes are ordered by the neighbouring AS during selection. 582:clicmd:`bgp deterministic-med`. This may reduce the number of updates as routes 583are received, and may in some cases reduce routing churn. Though, it could 584equally deterministically produce the largest possible set of updates in 585response to the most common sequence of received updates. 586 587A deterministic order of evaluation tends to imply an additional overhead of 588sorting over any set of n routes to a destination. The implementation of 589deterministic MED in FRR scales significantly worse than most sorting 590algorithms at present, with the number of paths to a given destination. That 591number is often low enough to not cause any issues, but where there are many 592paths, the deterministic comparison may quickly become increasingly expensive 593in terms of CPU. 594 595Deterministic local evaluation can *not* fix the second, more major, issue of 596MED however. Which is that the non-transitive preference of routes MED can 597cause may lead to routing instability or oscillation across multiple speakers 598in iBGP topologies. This can occur with full-mesh iBGP, but is particularly 599problematic in non-full-mesh iBGP topologies that further reduce the routing 600information known to each speaker. This has primarily been documented with iBGP 601:ref:`route-reflection <bgp-route-reflector>` topologies. However, any 602route-hiding technologies potentially could also exacerbate oscillation with MED. 603 604This second issue occurs where speakers each have only a subset of routes, and 605there are cycles in the preferences between different combinations of routes - 606as the undefined order of preference of MED allows - and the routes are 607distributed in a way that causes the BGP speakers to 'chase' those cycles. This 608can occur even if all speakers use a deterministic order of evaluation in route 609selection. 610 611E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X, and from 612speaker 3 in AS Y; while speaker 5 in AS A might receive that route from 613speaker 1 in AS Y. AS Y might set a MED of 200 at speaker 1, and 100 at speaker 6143. I.e, using ASN:ID:MED to label the speakers: 615 616:: 617 618 . 619 /---------------\\ 620 X:2------|--A:4-------A:5--|-Y:1:200 621 Y:3:100--|-/ | 622 \\---------------/ 623 624 625 626Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs), then based 627on the RFC4271 decision process speaker 4 will choose X:2 over Y:3:100, based 628on the lower ID of 2. Speaker 4 advertises X:2 to speaker 5. Speaker 5 will 629continue to prefer Y:1:200 based on the ID, and advertise this to speaker 4. 630Speaker 4 will now have the full set of routes, and the Y:1:200 it receives 631from 5 will beat X:2, but when speaker 4 compares Y:1:200 to Y:3:100 the MED 632check now becomes active as the ASes match, and now Y:3:100 is preferred. 633Speaker 4 therefore now advertises Y:3:100 to 5, which will also agrees that 634Y:3:100 is preferred to Y:1:200, and so withdraws the latter route from 4. 635Speaker 4 now has only X:2 and Y:3:100, and X:2 beats Y:3:100, and so speaker 4 636implicitly updates its route to speaker 5 to X:2. Speaker 5 sees that Y:1:200 637beats X:2 based on the ID, and advertises Y:1:200 to speaker 4, and the cycle 638continues. 639 640The root cause is the lack of a clear order of preference caused by how MED 641sometimes is and sometimes is not compared, leading to this cycle in the 642preferences between the routes: 643 644:: 645 646 . 647 /---> X:2 ---beats---> Y:3:100 --\\ 648 | | 649 | | 650 \\---beats--- Y:1:200 <---beats---/ 651 652 653 654This particular type of oscillation in full-mesh iBGP topologies can be 655avoided by speakers preferring already selected, external routes rather than 656choosing to update to new a route based on a post-MED metric (e.g. router-ID), 657at the cost of a non-deterministic selection process. FRR implements this, as 658do many other implementations, so long as it is not overridden by setting 659:clicmd:`bgp bestpath compare-routerid`, and see also 660:ref:`bgp-route-selection`. 661 662However, more complex and insidious cycles of oscillation are possible with 663iBGP route-reflection, which are not so easily avoided. These have been 664documented in various places. See, e.g.: 665 666- [bgp-route-osci-cond]_ 667- [stable-flexible-ibgp]_ 668- [ibgp-correctness]_ 669 670for concrete examples and further references. 671 672There is as of this writing *no* known way to use MED for its original purpose; 673*and* reduce routing information in iBGP topologies; *and* be sure to avoid the 674instability problems of MED due the non-transitive routing preferences it can 675induce; in general on arbitrary networks. 676 677There may be iBGP topology specific ways to reduce the instability risks, even 678while using MED, e.g.: by constraining the reflection topology and by tuning 679IGP costs between route-reflector clusters, see :rfc:`3345` for details. In the 680near future, the Add-Path extension to BGP may also solve MED oscillation while 681still allowing MED to be used as intended, by distributing "best-paths per 682neighbour AS". This would be at the cost of distributing at least as many 683routes to all speakers as a full-mesh iBGP would, if not more, while also 684imposing similar CPU overheads as the "Deterministic MED" feature at each 685Add-Path reflector. 686 687More generally, the instability problems that MED can introduce on more 688complex, non-full-mesh, iBGP topologies may be avoided either by: 689 690- Setting :clicmd:`bgp always-compare-med`, however this allows MED to be compared 691 across values set by different neighbour ASes, which may not produce 692 coherent desirable results, of itself. 693- Effectively ignoring MED by setting MED to the same value (e.g.: 0) using 694 :clicmd:`set metric METRIC` on all received routes, in combination with 695 setting :clicmd:`bgp always-compare-med` on all speakers. This is the simplest 696 and most performant way to avoid MED oscillation issues, where an AS is happy 697 not to allow neighbours to inject this problematic metric. 698 699As MED is evaluated after the AS_PATH length check, another possible use for 700MED is for intra-AS steering of routes with equal AS_PATH length, as an 701extension of the last case above. As MED is evaluated before IGP metric, this 702can allow cold-potato routing to be implemented to send traffic to preferred 703hand-offs with neighbours, rather than the closest hand-off according to the 704IGP metric. 705 706Note that even if action is taken to address the MED non-transitivity issues, 707other oscillations may still be possible. E.g., on IGP cost if iBGP and IGP 708topologies are at cross-purposes with each other - see the Flavel and Roughan 709paper above for an example. Hence the guideline that the iBGP topology should 710follow the IGP topology. 711 712.. index:: bgp deterministic-med 713.. clicmd:: bgp deterministic-med 714 715 Carry out route-selection in way that produces deterministic answers 716 locally, even in the face of MED and the lack of a well-defined order of 717 preference it can induce on routes. Without this option the preferred route 718 with MED may be determined largely by the order that routes were received 719 in. 720 721 Setting this option will have a performance cost that may be noticeable when 722 there are many routes for each destination. Currently in FRR it is 723 implemented in a way that scales poorly as the number of routes per 724 destination increases. 725 726 The default is that this option is not set. 727 728Note that there are other sources of indeterminism in the route selection 729process, specifically, the preference for older and already selected routes 730from eBGP peers, :ref:`bgp-route-selection`. 731 732.. index:: bgp always-compare-med 733.. clicmd:: bgp always-compare-med 734 735 Always compare the MED on routes, even when they were received from 736 different neighbouring ASes. Setting this option makes the order of 737 preference of routes more defined, and should eliminate MED induced 738 oscillations. 739 740 If using this option, it may also be desirable to use 741 :clicmd:`set metric METRIC` to set MED to 0 on routes received from external 742 neighbours. 743 744 This option can be used, together with :clicmd:`set metric METRIC` to use 745 MED as an intra-AS metric to steer equal-length AS_PATH routes to, e.g., 746 desired exit points. 747 748 749.. _bgp-graceful-restart: 750 751Graceful Restart 752---------------- 753 754BGP graceful restart functionality as defined in 755`RFC-4724 <https://tools.ietf.org/html/rfc4724/>`_ defines the mechanisms that 756allows BGP speaker to continue to forward data packets along known routes 757while the routing protocol information is being restored. 758 759 760Usually, when BGP on a router restarts, all the BGP peers detect that the 761session went down and then came up. This "down/up" transition results in a 762"routing flap" and causes BGP route re-computation, generation of BGP routing 763updates, and unnecessary churn to the forwarding tables. 764 765The following functionality is provided by graceful restart: 766 7671. The feature allows the restarting router to indicate to the helping peer the 768 routes it can preserve in its forwarding plane during control plane restart 769 by sending graceful restart capability in the OPEN message sent during 770 session establishment. 7712. The feature allows helping router to advertise to all other peers the routes 772 received from the restarting router which are preserved in the forwarding 773 plane of the restarting router during control plane restart. 774 775 776:: 777 778 779 780 (R1)-----------------------------------------------------------------(R2) 781 782 1. BGP Graceful Restart Capability exchanged between R1 & R2. 783 784 <---------------------------------------------------------------------> 785 786 2. Kill BGP Process at R1. 787 788 ----------------------------------------------------------------------> 789 790 3. R2 Detects the above BGP Restart & verifies BGP Restarting 791 Capability of R1. 792 793 4. Start BGP Process at R1. 794 795 5. Re-establish the BGP session between R1 & R2. 796 797 <---------------------------------------------------------------------> 798 799 6. R2 Send initial route updates, followed by End-Of-Rib. 800 801 <---------------------------------------------------------------------- 802 803 7. R1 was waiting for End-Of-Rib from R2 & which has been received 804 now. 805 806 8. R1 now runs BGP Best-Path algorithm. Send Initial BGP Update, 807 followed by End-Of Rib 808 809 <---------------------------------------------------------------------> 810 811 812.. _bgp-end-of-rib-message: 813 814End-of-RIB (EOR) message 815^^^^^^^^^^^^^^^^^^^^^^^^ 816 817An UPDATE message with no reachable Network Layer Reachability Information 818(NLRI) and empty withdrawn NLRI is specified as the End-of-RIB marker that can 819be used by a BGP speaker to indicate to its peer the completion of the initial 820routing update after the session is established. 821 822For the IPv4 unicast address family, the End-of-RIB marker is an UPDATE message 823with the minimum length. For any other address family, it is an UPDATE message 824that contains only the MP_UNREACH_NLRI attribute with no withdrawn routes for 825that <AFI, SAFI>. 826 827Although the End-of-RIB marker is specified for the purpose of BGP graceful 828restart, it is noted that the generation of such a marker upon completion of 829the initial update would be useful for routing convergence in general, and thus 830the practice is recommended. 831 832.. _bgp-route-selection-deferral-timer: 833 834Route Selection Deferral Timer 835^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 836 837Specifies the time the restarting router defers the route selection process 838after restart. 839 840Restarting Router : The usage of route election deferral timer is specified 841in https://tools.ietf.org/html/rfc4724#section-4.1 842 843Once the session between the Restarting Speaker and the Receiving Speaker is 844re-established, the Restarting Speaker will receive and process BGP messages 845from its peers. 846 847However, it MUST defer route selection for an address family until it either. 848 8491. Receives the End-of-RIB marker from all its peers (excluding the ones with 850 the "Restart State" bit set in the received capability and excluding the ones 851 that do not advertise the graceful restart capability). 8522. The Selection_Deferral_Timer timeout. 853 854.. index:: bgp graceful-restart select-defer-time (0-3600) 855.. clicmd:: bgp graceful-restart select-defer-time (0-3600) 856 857 This is command, will set deferral time to value specified. 858 859 860.. index:: bgp graceful-restart rib-stale-time (1-3600) 861.. clicmd:: bgp graceful-restart rib-stale-time (1-3600) 862 863 This is command, will set the time for which stale routes are kept in RIB. 864 865.. _bgp-per-peer-graceful-restart: 866 867BGP Per Peer Graceful Restart 868^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 869 870Ability to enable and disable graceful restart, helper and no GR at all mode 871functionality at peer level. 872 873So bgp graceful restart can be enabled at modes global BGP level or at per 874peer level. There are two FSM, one for BGP GR global mode and other for peer 875per GR. 876 877Default global mode is helper and default peer per mode is inherit from global. 878If per peer mode is configured, the GR mode of this particular peer will 879override the global mode. 880 881.. _bgp-GR-global-mode-cmd: 882 883BGP GR Global Mode Commands 884^^^^^^^^^^^^^^^^^^^^^^^^^^^ 885 886.. index:: bgp graceful-restart 887.. clicmd:: bgp graceful-restart 888 889 This command will enable BGP graceful restart ifunctionality at the global 890 level. 891 892.. index:: bgp graceful-restart disable 893.. clicmd:: bgp graceful-restart disable 894 895 This command will disable both the functionality graceful restart and helper 896 mode. 897 898 899.. _bgp-GR-peer-mode-cmd: 900 901BGP GR Peer Mode Commands 902^^^^^^^^^^^^^^^^^^^^^^^^^ 903 904.. index:: neighbor A.B.C.D graceful-restart 905.. clicmd:: neighbor A.B.C.D graceful-restart 906 907 This command will enable BGP graceful restart ifunctionality at the peer 908 level. 909 910.. index:: neighbor A.B.C.D graceful-restart-helper 911.. clicmd:: neighbor A.B.C.D graceful-restart-helper 912 913 This command will enable BGP graceful restart helper only functionality 914 at the peer level. 915 916.. index:: neighbor A.B.C.D graceful-restart-disable 917.. clicmd:: neighbor A.B.C.D graceful-restart-disable 918 919 This command will disable the entire BGP graceful restart functionality 920 at the peer level. 921 922 923.. _bgp-shutdown: 924 925Administrative Shutdown 926----------------------- 927 928.. index:: [no] bgp shutdown [message MSG...] 929.. clicmd:: [no] bgp shutdown [message MSG...] 930 931 Administrative shutdown of all peers of a bgp instance. Drop all BGP peers, 932 but preserve their configurations. The peers are notified in accordance with 933 `RFC 8203 <https://tools.ietf.org/html/rfc8203/>`_ by sending a 934 ``NOTIFICATION`` message with error code ``Cease`` and subcode 935 ``Administrative Shutdown`` prior to terminating connections. This global 936 shutdown is independent of the neighbor shutdown, meaning that individually 937 shut down peers will not be affected by lifting it. 938 939 An optional shutdown message `MSG` can be specified. 940 941 942.. _bgp-network: 943 944Networks 945-------- 946 947.. index:: network A.B.C.D/M 948.. clicmd:: network A.B.C.D/M 949 950 This command adds the announcement network. 951 952 .. code-block:: frr 953 954 router bgp 1 955 address-family ipv4 unicast 956 network 10.0.0.0/8 957 exit-address-family 958 959 This configuration example says that network 10.0.0.0/8 will be 960 announced to all neighbors. Some vendors' routers don't advertise 961 routes if they aren't present in their IGP routing tables; `bgpd` 962 doesn't care about IGP routes when announcing its routes. 963 964.. index:: no network A.B.C.D/M 965.. clicmd:: no network A.B.C.D/M 966 967.. index:: [no] bgp network import-check 968.. clicmd:: [no] bgp network import-check 969 970 This configuration modifies the behavior of the network statement. 971 If you have this configured the underlying network must exist in 972 the rib. If you have the [no] form configured then BGP will not 973 check for the networks existence in the rib. For versions 7.3 and 974 before frr defaults for datacenter were the network must exist, 975 traditional did not check for existence. For versions 7.4 and beyond 976 both traditional and datacenter the network must exist. 977 978.. _bgp-ipv6-support: 979 980IPv6 Support 981------------ 982 983.. index:: [no] neighbor A.B.C.D activate 984.. clicmd:: [no] neighbor A.B.C.D activate 985 986 This configuration modifies whether to enable an address family for a 987 specific neighbor. By default only the IPv4 unicast address family is 988 enabled. 989 990 .. code-block:: frr 991 992 router bgp 1 993 address-family ipv6 unicast 994 neighbor 2001:0DB8::1 activate 995 network 2001:0DB8:5009::/64 996 exit-address-family 997 998 This configuration example says that network 2001:0DB8:5009::/64 will be 999 announced and enables the neighbor 2001:0DB8::1 to receive this announcement. 1000 1001.. index:: [no] bgp default ipv4-unicast 1002.. clicmd:: [no] bgp default ipv4-unicast 1003 1004 By default, only the IPv4 unicast address family is announced to all 1005 neighbors. Using the 'no bgp default ipv4-unicast' configuration overrides 1006 this default so that all address families need to be enabled explicitly. 1007 1008 .. code-block:: frr 1009 1010 router bgp 1 1011 no bgp default ipv4-unicast 1012 neighbor 10.10.10.1 remote-as 2 1013 neighbor 2001:0DB8::1 remote-as 3 1014 address-family ipv4 unicast 1015 neighbor 10.10.10.1 activate 1016 network 192.168.1.0/24 1017 exit-address-family 1018 address-family ipv6 unicast 1019 neighbor 2001:0DB8::1 activate 1020 network 2001:0DB8:5009::/64 1021 exit-address-family 1022 1023 This configuration demonstrates how the 'no bgp default ipv4-unicast' might 1024 be used in a setup with two upstreams where each of the upstreams should only 1025 receive either IPv4 or IPv6 annocuments. 1026 1027 1028.. _bgp-route-aggregation: 1029 1030Route Aggregation 1031----------------- 1032 1033.. _bgp-route-aggregation-ipv4: 1034 1035Route Aggregation-IPv4 Address Family 1036^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1037 1038.. index:: aggregate-address A.B.C.D/M 1039.. clicmd:: aggregate-address A.B.C.D/M 1040 1041 This command specifies an aggregate address. 1042 1043.. index:: aggregate-address A.B.C.D/M route-map NAME 1044.. clicmd:: aggregate-address A.B.C.D/M route-map NAME 1045 1046 Apply a route-map for an aggregated prefix. 1047 1048.. index:: aggregate-address A.B.C.D/M origin <egp|igp|incomplete> 1049.. clicmd:: aggregate-address A.B.C.D/M origin <egp|igp|incomplete> 1050 1051 Override ORIGIN for an aggregated prefix. 1052 1053.. index:: aggregate-address A.B.C.D/M as-set 1054.. clicmd:: aggregate-address A.B.C.D/M as-set 1055 1056 This command specifies an aggregate address. Resulting routes include 1057 AS set. 1058 1059.. index:: aggregate-address A.B.C.D/M summary-only 1060.. clicmd:: aggregate-address A.B.C.D/M summary-only 1061 1062 This command specifies an aggregate address. Aggregated routes will 1063 not be announced. 1064 1065.. index:: no aggregate-address A.B.C.D/M 1066.. clicmd:: no aggregate-address A.B.C.D/M 1067 1068 This command removes an aggregate address. 1069 1070 1071 This configuration example setup the aggregate-address under 1072 ipv4 address-family. 1073 1074 .. code-block:: frr 1075 1076 router bgp 1 1077 address-family ipv4 unicast 1078 aggregate-address 10.0.0.0/8 1079 aggregate-address 20.0.0.0/8 as-set 1080 aggregate-address 40.0.0.0/8 summary-only 1081 aggregate-address 50.0.0.0/8 route-map aggr-rmap 1082 exit-address-family 1083 1084 1085.. _bgp-route-aggregation-ipv6: 1086 1087Route Aggregation-IPv6 Address Family 1088^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1089 1090.. index:: aggregate-address X:X::X:X/M 1091.. clicmd:: aggregate-address X:X::X:X/M 1092 1093 This command specifies an aggregate address. 1094 1095.. index:: aggregate-address X:X::X:X/M route-map NAME 1096.. clicmd:: aggregate-address X:X::X:X/M route-map NAME 1097 1098 Apply a route-map for an aggregated prefix. 1099 1100.. index:: aggregate-address X:X::X:X/M origin <egp|igp|incomplete> 1101.. clicmd:: aggregate-address X:X::X:X/M origin <egp|igp|incomplete> 1102 1103 Override ORIGIN for an aggregated prefix. 1104 1105.. index:: aggregate-address X:X::X:X/M as-set 1106.. clicmd:: aggregate-address X:X::X:X/M as-set 1107 1108 This command specifies an aggregate address. Resulting routes include 1109 AS set. 1110 1111.. index:: aggregate-address X:X::X:X/M summary-only 1112.. clicmd:: aggregate-address X:X::X:X/M summary-only 1113 1114 This command specifies an aggregate address. Aggregated routes will 1115 not be announced. 1116 1117.. index:: no aggregate-address X:X::X:X/M 1118.. clicmd:: no aggregate-address X:X::X:X/M 1119 1120 This command removes an aggregate address. 1121 1122 1123 This configuration example setup the aggregate-address under 1124 ipv6 address-family. 1125 1126 .. code-block:: frr 1127 1128 router bgp 1 1129 address-family ipv6 unicast 1130 aggregate-address 10::0/64 1131 aggregate-address 20::0/64 as-set 1132 aggregate-address 40::0/64 summary-only 1133 aggregate-address 50::0/64 route-map aggr-rmap 1134 exit-address-family 1135 1136.. _bgp-redistribute-to-bgp: 1137 1138Redistribution 1139-------------- 1140 1141.. index:: redistribute kernel 1142.. clicmd:: redistribute kernel 1143 1144 Redistribute kernel route to BGP process. 1145 1146.. index:: redistribute static 1147.. clicmd:: redistribute static 1148 1149 Redistribute static route to BGP process. 1150 1151.. index:: redistribute connected 1152.. clicmd:: redistribute connected 1153 1154 Redistribute connected route to BGP process. 1155 1156.. index:: redistribute rip 1157.. clicmd:: redistribute rip 1158 1159 Redistribute RIP route to BGP process. 1160 1161.. index:: redistribute ospf 1162.. clicmd:: redistribute ospf 1163 1164 Redistribute OSPF route to BGP process. 1165 1166.. index:: redistribute vnc 1167.. clicmd:: redistribute vnc 1168 1169 Redistribute VNC routes to BGP process. 1170 1171.. index:: redistribute vnc-direct 1172.. clicmd:: redistribute vnc-direct 1173 1174 Redistribute VNC direct (not via zebra) routes to BGP process. 1175 1176.. index:: bgp update-delay MAX-DELAY 1177.. clicmd:: bgp update-delay MAX-DELAY 1178 1179.. index:: bgp update-delay MAX-DELAY ESTABLISH-WAIT 1180.. clicmd:: bgp update-delay MAX-DELAY ESTABLISH-WAIT 1181 1182 This feature is used to enable read-only mode on BGP process restart or when 1183 a BGP process is cleared using 'clear ip bgp \*'. Note that this command is 1184 configured at the global level and applies to all bgp instances/vrfs. It 1185 cannot be used at the same time as the "update-delay" command described below, 1186 which is entered in each bgp instance/vrf desired to delay update installation 1187 and advertisements. The global and per-vrf approaches to defining update-delay 1188 are mutually exclusive. 1189 1190 When applicable, read-only mode would begin as soon as the first peer reaches 1191 Established status and a timer for max-delay seconds is started. During this 1192 mode BGP doesn't run any best-path or generate any updates to its peers. This 1193 mode continues until: 1194 1195 1. All the configured peers, except the shutdown peers, have sent explicit EOR 1196 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached 1197 Established is considered an implicit-EOR. 1198 If the establish-wait optional value is given, then BGP will wait for 1199 peers to reach established from the beginning of the update-delay till the 1200 establish-wait period is over, i.e. the minimum set of established peers for 1201 which EOR is expected would be peers established during the establish-wait 1202 window, not necessarily all the configured neighbors. 1203 2. max-delay period is over. 1204 1205 On hitting any of the above two conditions, BGP resumes the decision process 1206 and generates updates to its peers. 1207 1208 Default max-delay is 0, i.e. the feature is off by default. 1209 1210 1211.. index:: update-delay MAX-DELAY 1212.. clicmd:: update-delay MAX-DELAY 1213 1214.. index:: update-delay MAX-DELAY ESTABLISH-WAIT 1215.. clicmd:: update-delay MAX-DELAY ESTABLISH-WAIT 1216 1217 This feature is used to enable read-only mode on BGP process restart or when 1218 a BGP process is cleared using 'clear ip bgp \*'. Note that this command is 1219 configured under the specific bgp instance/vrf that the feaure is enabled for. 1220 It cannot be used at the same time as the global "bgp update-delay" described 1221 above, which is entered at the global level and applies to all bgp instances. 1222 The global and per-vrf approaches to defining update-delay are mutually 1223 exclusive. 1224 1225 When applicable, read-only mode would begin as soon as the first peer reaches 1226 Established status and a timer for max-delay seconds is started. During this 1227 mode BGP doesn't run any best-path or generate any updates to its peers. This 1228 mode continues until: 1229 1230 1. All the configured peers, except the shutdown peers, have sent explicit EOR 1231 (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached 1232 Established is considered an implicit-EOR. 1233 If the establish-wait optional value is given, then BGP will wait for 1234 peers to reach established from the beginning of the update-delay till the 1235 establish-wait period is over, i.e. the minimum set of established peers for 1236 which EOR is expected would be peers established during the establish-wait 1237 window, not necessarily all the configured neighbors. 1238 2. max-delay period is over. 1239 1240 On hitting any of the above two conditions, BGP resumes the decision process 1241 and generates updates to its peers. 1242 1243 Default max-delay is 0, i.e. the feature is off by default. 1244 1245.. index:: table-map ROUTE-MAP-NAME 1246.. clicmd:: table-map ROUTE-MAP-NAME 1247 1248 This feature is used to apply a route-map on route updates from BGP to 1249 Zebra. All the applicable match operations are allowed, such as match on 1250 prefix, next-hop, communities, etc. Set operations for this attach-point are 1251 limited to metric and next-hop only. Any operation of this feature does not 1252 affect BGPs internal RIB. 1253 1254 Supported for ipv4 and ipv6 address families. It works on multi-paths as 1255 well, however, metric setting is based on the best-path only. 1256 1257.. _bgp-peers: 1258 1259Peers 1260----- 1261 1262.. _bgp-defining-peers: 1263 1264Defining Peers 1265^^^^^^^^^^^^^^ 1266 1267.. index:: neighbor PEER remote-as ASN 1268.. clicmd:: neighbor PEER remote-as ASN 1269 1270 Creates a new neighbor whose remote-as is ASN. PEER can be an IPv4 address 1271 or an IPv6 address or an interface to use for the connection. 1272 1273 .. code-block:: frr 1274 1275 router bgp 1 1276 neighbor 10.0.0.1 remote-as 2 1277 1278 In this case my router, in AS-1, is trying to peer with AS-2 at 10.0.0.1. 1279 1280 This command must be the first command used when configuring a neighbor. If 1281 the remote-as is not specified, *bgpd* will complain like this: :: 1282 1283 can't find neighbor 10.0.0.1 1284 1285.. index:: neighbor PEER remote-as internal 1286.. clicmd:: neighbor PEER remote-as internal 1287 1288 Create a peer as you would when you specify an ASN, except that if the 1289 peers ASN is different than mine as specified under the :clicmd:`router bgp ASN` 1290 command the connection will be denied. 1291 1292.. index:: neighbor PEER remote-as external 1293.. clicmd:: neighbor PEER remote-as external 1294 1295 Create a peer as you would when you specify an ASN, except that if the 1296 peers ASN is the same as mine as specified under the :clicmd:`router bgp ASN` 1297 command the connection will be denied. 1298 1299.. index:: [no] bgp listen range <A.B.C.D/M|X:X::X:X/M> peer-group PGNAME 1300.. clicmd:: [no] bgp listen range <A.B.C.D/M|X:X::X:X/M> peer-group PGNAME 1301 1302 Accept connections from any peers in the specified prefix. Configuration 1303 from the specified peer-group is used to configure these peers. 1304 1305.. note:: 1306 1307 When using BGP listen ranges, if the associated peer group has TCP MD5 1308 authentication configured, your kernel must support this on prefixes. On 1309 Linux, this support was added in kernel version 4.14. If your kernel does 1310 not support this feature you will get a warning in the log file, and the 1311 listen range will only accept connections from peers without MD5 configured. 1312 1313 Additionally, we have observed that when using this option at scale (several 1314 hundred peers) the kernel may hit its option memory limit. In this situation 1315 you will see error messages like: 1316 1317 ``bgpd: sockopt_tcp_signature: setsockopt(23): Cannot allocate memory`` 1318 1319 In this case you need to increase the value of the sysctl 1320 ``net.core.optmem_max`` to allow the kernel to allocate the necessary option 1321 memory. 1322 1323.. index:: [no] coalesce-time (0-4294967295) 1324.. clicmd:: [no] coalesce-time (0-4294967295) 1325 1326 The time in milliseconds that BGP will delay before deciding what peers 1327 can be put into an update-group together in order to generate a single 1328 update for them. The default time is 1000. 1329 1330.. _bgp-configuring-peers: 1331 1332Configuring Peers 1333^^^^^^^^^^^^^^^^^ 1334 1335.. index:: [no] neighbor PEER shutdown [message MSG...] [rtt (1-65535) [count (1-255)]] 1336.. clicmd:: [no] neighbor PEER shutdown [message MSG...] [rtt (1-65535) [count (1-255)]] 1337 1338 Shutdown the peer. We can delete the neighbor's configuration by 1339 ``no neighbor PEER remote-as ASN`` but all configuration of the neighbor 1340 will be deleted. When you want to preserve the configuration, but want to 1341 drop the BGP peer, use this syntax. 1342 1343 Optionally you can specify a shutdown message `MSG`. 1344 1345 Also, you can specify optionally _rtt_ in milliseconds to automatically 1346 shutdown the peer if round-trip-time becomes higher than defined. 1347 1348 Additional _count_ parameter is the number of keepalive messages to count 1349 before shutdown the peer if round-trip-time becomes higher than defined. 1350 1351.. index:: [no] neighbor PEER disable-connected-check 1352.. clicmd:: [no] neighbor PEER disable-connected-check 1353 1354 Allow peerings between directly connected eBGP peers using loopback 1355 addresses. 1356 1357.. index:: [no] neighbor PEER ebgp-multihop 1358.. clicmd:: [no] neighbor PEER ebgp-multihop 1359 1360 Specifying ``ebgp-multihop`` allows sessions with eBGP neighbors to 1361 establish when they are multiple hops away. When the neighbor is not 1362 directly connected and this knob is not enabled, the session will not 1363 establish. 1364 1365.. index:: [no] neighbor PEER description ... 1366.. clicmd:: [no] neighbor PEER description ... 1367 1368 Set description of the peer. 1369 1370.. index:: [no] neighbor PEER version VERSION 1371.. clicmd:: [no] neighbor PEER version VERSION 1372 1373 Set up the neighbor's BGP version. `version` can be `4`, `4+` or `4-`. BGP 1374 version `4` is the default value used for BGP peering. BGP version `4+` 1375 means that the neighbor supports Multiprotocol Extensions for BGP-4. BGP 1376 version `4-` is similar but the neighbor speaks the old Internet-Draft 1377 revision 00's Multiprotocol Extensions for BGP-4. Some routing software is 1378 still using this version. 1379 1380.. index:: [no] neighbor PEER interface IFNAME 1381.. clicmd:: [no] neighbor PEER interface IFNAME 1382 1383 When you connect to a BGP peer over an IPv6 link-local address, you have to 1384 specify the IFNAME of the interface used for the connection. To specify 1385 IPv4 session addresses, see the ``neighbor PEER update-source`` command 1386 below. 1387 1388 This command is deprecated and may be removed in a future release. Its use 1389 should be avoided. 1390 1391.. index:: [no] neighbor PEER next-hop-self [all] 1392.. clicmd:: [no] neighbor PEER next-hop-self [all] 1393 1394 This command specifies an announced route's nexthop as being equivalent to 1395 the address of the bgp router if it is learned via eBGP. If the optional 1396 keyword `all` is specified the modification is done also for routes learned 1397 via iBGP. 1398 1399.. index:: neighbor PEER attribute-unchanged [{as-path|next-hop|med}] 1400.. clicmd:: neighbor PEER attribute-unchanged [{as-path|next-hop|med}] 1401 1402 This command specifies attributes to be left unchanged for advertisements 1403 sent to a peer. Use this to leave the next-hop unchanged in ipv6 1404 configurations, as the route-map directive to leave the next-hop unchanged 1405 is only available for ipv4. 1406 1407.. index:: [no] neighbor PEER update-source <IFNAME|ADDRESS> 1408.. clicmd:: [no] neighbor PEER update-source <IFNAME|ADDRESS> 1409 1410 Specify the IPv4 source address to use for the :abbr:`BGP` session to this 1411 neighbour, may be specified as either an IPv4 address directly or as an 1412 interface name (in which case the *zebra* daemon MUST be running in order 1413 for *bgpd* to be able to retrieve interface state). 1414 1415 .. code-block:: frr 1416 1417 router bgp 64555 1418 neighbor foo update-source 192.168.0.1 1419 neighbor bar update-source lo0 1420 1421 1422.. index:: [no] neighbor PEER default-originate 1423.. clicmd:: [no] neighbor PEER default-originate 1424 1425 *bgpd*'s default is to not announce the default route (0.0.0.0/0) even if it 1426 is in routing table. When you want to announce default routes to the peer, 1427 use this command. 1428 1429.. index:: neighbor PEER port PORT 1430.. clicmd:: neighbor PEER port PORT 1431 1432.. index:: [no] neighbor PEER password PASSWORD 1433.. clicmd:: [no] neighbor PEER password PASSWORD 1434 1435 Set a MD5 password to be used with the tcp socket that is being used 1436 to connect to the remote peer. Please note if you are using this 1437 command with a large number of peers on linux you should consider 1438 modifying the `net.core.optmem_max` sysctl to a larger value to 1439 avoid out of memory errors from the linux kernel. 1440 1441.. index:: neighbor PEER send-community 1442.. clicmd:: neighbor PEER send-community 1443 1444.. index:: [no] neighbor PEER weight WEIGHT 1445.. clicmd:: [no] neighbor PEER weight WEIGHT 1446 1447 This command specifies a default `weight` value for the neighbor's routes. 1448 1449.. index:: [no] neighbor PEER maximum-prefix NUMBER [force] 1450.. clicmd:: [no] neighbor PEER maximum-prefix NUMBER [force] 1451 1452 Sets a maximum number of prefixes we can receive from a given peer. If this 1453 number is exceeded, the BGP session will be destroyed. 1454 1455 In practice, it is generally preferable to use a prefix-list to limit what 1456 prefixes are received from the peer instead of using this knob. Tearing down 1457 the BGP session when a limit is exceeded is far more destructive than merely 1458 rejecting undesired prefixes. The prefix-list method is also much more 1459 granular and offers much smarter matching criterion than number of received 1460 prefixes, making it more suited to implementing policy. 1461 1462 If _force_ is set, then ALL prefixes are counted for maximum instead of 1463 accepted only. This is useful for cases where an inbound filter is applied, 1464 but you want maximum-prefix to act on ALL (including filtered) prefixes. This 1465 option requires `soft-reconfiguration inbound` to be enabled for the peer. 1466 1467.. index:: [no] neighbor PEER maximum-prefix-out NUMBER 1468.. clicmd:: [no] neighbor PEER maximum-prefix-out NUMBER 1469 1470 Sets a maximum number of prefixes we can send to a given peer. 1471 1472 Since sent prefix count is managed by update-groups, this option 1473 creates a separate update-group for outgoing updates. 1474 1475.. index:: [no] neighbor PEER local-as AS-NUMBER [no-prepend] [replace-as] 1476.. clicmd:: [no] neighbor PEER local-as AS-NUMBER [no-prepend] [replace-as] 1477 1478 Specify an alternate AS for this BGP process when interacting with the 1479 specified peer. With no modifiers, the specified local-as is prepended to 1480 the received AS_PATH when receiving routing updates from the peer, and 1481 prepended to the outgoing AS_PATH (after the process local AS) when 1482 transmitting local routes to the peer. 1483 1484 If the no-prepend attribute is specified, then the supplied local-as is not 1485 prepended to the received AS_PATH. 1486 1487 If the replace-as attribute is specified, then only the supplied local-as is 1488 prepended to the AS_PATH when transmitting local-route updates to this peer. 1489 1490 Note that replace-as can only be specified if no-prepend is. 1491 1492 This command is only allowed for eBGP peers. 1493 1494.. index:: [no] neighbor <A.B.C.D|X:X::X:X|WORD> as-override 1495.. clicmd:: [no] neighbor <A.B.C.D|X:X::X:X|WORD> as-override 1496 1497 Override AS number of the originating router with the local AS number. 1498 1499 Usually this configuration is used in PEs (Provider Edge) to replace 1500 the incoming customer AS number so the connected CE (Customer Edge) 1501 can use the same AS number as the other customer sites. This allows 1502 customers of the provider network to use the same AS number across 1503 their sites. 1504 1505 This command is only allowed for eBGP peers. 1506 1507.. index:: [no] neighbor <A.B.C.D|X:X::X:X|WORD> allowas-in [<(1-10)|origin>] 1508.. clicmd:: [no] neighbor <A.B.C.D|X:X::X:X|WORD> allowas-in [<(1-10)|origin>] 1509 1510 Accept incoming routes with AS path containing AS number with the same value 1511 as the current system AS. 1512 1513 This is used when you want to use the same AS number in your sites, but you 1514 can't connect them directly. This is an alternative to 1515 `neighbor WORD as-override`. 1516 1517 The parameter `(1-10)` configures the amount of accepted occurences of the 1518 system AS number in AS path. 1519 1520 The parameter `origin` configures BGP to only accept routes originated with 1521 the same AS number as the system. 1522 1523 This command is only allowed for eBGP peers. 1524 1525.. index:: [no] neighbor <A.B.C.D|X:X::X:X|WORD> addpath-tx-all-paths 1526.. clicmd:: [no] neighbor <A.B.C.D|X:X::X:X|WORD> addpath-tx-all-paths 1527 1528 Configure BGP to send all known paths to neighbor in order to preserve multi 1529 path capabilities inside a network. 1530 1531.. index:: [no] neighbor <A.B.C.D|X:X::X:X|WORD> addpath-tx-bestpath-per-AS 1532.. clicmd:: [no] neighbor <A.B.C.D|X:X::X:X|WORD> addpath-tx-bestpath-per-AS 1533 1534 Configure BGP to send best known paths to neighbor in order to preserve multi 1535 path capabilities inside a network. 1536 1537.. index:: [no] neighbor PEER ttl-security hops NUMBER 1538.. clicmd:: [no] neighbor PEER ttl-security hops NUMBER 1539 1540 This command enforces Generalized TTL Security Mechanism (GTSM), as 1541 specified in RFC 5082. With this command, only neighbors that are the 1542 specified number of hops away will be allowed to become neighbors. This 1543 command is mutually exclusive with *ebgp-multihop*. 1544 1545.. index:: [no] neighbor PEER capability extended-nexthop 1546.. clicmd:: [no] neighbor PEER capability extended-nexthop 1547 1548 Allow bgp to negotiate the extended-nexthop capability with it's peer. 1549 If you are peering over a v6 LL address then this capability is turned 1550 on automatically. If you are peering over a v6 Global Address then 1551 turning on this command will allow BGP to install v4 routes with 1552 v6 nexthops if you do not have v4 configured on interfaces. 1553 1554.. index:: [no] bgp fast-external-failover 1555.. clicmd:: [no] bgp fast-external-failover 1556 1557 This command causes bgp to not take down ebgp peers immediately 1558 when a link flaps. `bgp fast-external-failover` is the default 1559 and will not be displayed as part of a `show run`. The no form 1560 of the command turns off this ability. 1561 1562.. index:: [no] bgp default ipv4-unicast 1563.. clicmd:: [no] bgp default ipv4-unicast 1564 1565 This command allows the user to specify that v4 peering is turned 1566 on by default or not. This command defaults to on and is not displayed. 1567 The `no bgp default ipv4-unicast` form of the command is displayed. 1568 1569.. index:: [no] bgp default show-hostname 1570.. clicmd:: [no] bgp default show-hostname 1571 1572 This command shows the hostname of the peer in certain BGP commands 1573 outputs. It's easier to troubleshoot if you have a number of BGP peers. 1574 1575.. index:: [no] bgp default show-nexthop-hostname 1576.. clicmd:: [no] bgp default show-nexthop-hostname 1577 1578 This command shows the hostname of the next-hop in certain BGP commands 1579 outputs. It's easier to troubleshoot if you have a number of BGP peers 1580 and a number of routes to check. 1581 1582.. index:: [no] neighbor PEER advertisement-interval (0-600) 1583.. clicmd:: [no] neighbor PEER advertisement-interval (0-600) 1584 1585 Setup the minimum route advertisement interval(mrai) for the 1586 peer in question. This number is between 0 and 600 seconds, 1587 with the default advertisement interval being 0. 1588 1589Displaying Information about Peers 1590^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1591 1592.. index:: show bgp <afi> <safi> neighbors WORD bestpath-routes [json] [wide] 1593.. clicmd:: show bgp <afi> <safi> neighbors WORD bestpath-routes [json] [wide] 1594 1595 For the given neighbor, WORD, that is specified list the routes selected 1596 by BGP as having the best path. 1597 1598.. _bgp-peer-filtering: 1599 1600Peer Filtering 1601^^^^^^^^^^^^^^ 1602 1603.. index:: neighbor PEER distribute-list NAME [in|out] 1604.. clicmd:: neighbor PEER distribute-list NAME [in|out] 1605 1606 This command specifies a distribute-list for the peer. `direct` is 1607 ``in`` or ``out``. 1608 1609.. index:: neighbor PEER prefix-list NAME [in|out] 1610.. clicmd:: neighbor PEER prefix-list NAME [in|out] 1611 1612.. index:: neighbor PEER filter-list NAME [in|out] 1613.. clicmd:: neighbor PEER filter-list NAME [in|out] 1614 1615.. index:: neighbor PEER route-map NAME [in|out] 1616.. clicmd:: neighbor PEER route-map NAME [in|out] 1617 1618 Apply a route-map on the neighbor. `direct` must be `in` or `out`. 1619 1620.. index:: bgp route-reflector allow-outbound-policy 1621.. clicmd:: bgp route-reflector allow-outbound-policy 1622 1623 By default, attribute modification via route-map policy out is not reflected 1624 on reflected routes. This option allows the modifications to be reflected as 1625 well. Once enabled, it affects all reflected routes. 1626 1627.. index:: [no] neighbor PEER sender-as-path-loop-detection 1628.. clicmd:: [no] neighbor PEER sender-as-path-loop-detection 1629 1630 Enable the detection of sender side AS path loops and filter the 1631 bad routes before they are sent. 1632 1633 This setting is disabled by default. 1634 1635.. _bgp-peer-group: 1636 1637Peer Groups 1638^^^^^^^^^^^ 1639 1640Peer groups are used to help improve scaling by generating the same 1641update information to all members of a peer group. Note that this means 1642that the routes generated by a member of a peer group will be sent back 1643to that originating peer with the originator identifier attribute set to 1644indicated the originating peer. All peers not associated with a 1645specific peer group are treated as belonging to a default peer group, 1646and will share updates. 1647 1648.. index:: neighbor WORD peer-group 1649.. clicmd:: neighbor WORD peer-group 1650 1651 This command defines a new peer group. 1652 1653.. index:: neighbor PEER peer-group PGNAME 1654.. clicmd:: neighbor PEER peer-group PGNAME 1655 1656 This command bind specific peer to peer group WORD. 1657 1658.. index:: neighbor PEER solo 1659.. clicmd:: neighbor PEER solo 1660 1661 This command is used to indicate that routes advertised by the peer 1662 should not be reflected back to the peer. This command only is only 1663 meaningful when there is a single peer defined in the peer-group. 1664 1665Capability Negotiation 1666^^^^^^^^^^^^^^^^^^^^^^ 1667 1668.. index:: neighbor PEER strict-capability-match 1669.. clicmd:: neighbor PEER strict-capability-match 1670 1671.. index:: no neighbor PEER strict-capability-match 1672.. clicmd:: no neighbor PEER strict-capability-match 1673 1674 Strictly compares remote capabilities and local capabilities. If 1675 capabilities are different, send Unsupported Capability error then reset 1676 connection. 1677 1678 You may want to disable sending Capability Negotiation OPEN message optional 1679 parameter to the peer when remote peer does not implement Capability 1680 Negotiation. Please use *dont-capability-negotiate* command to disable the 1681 feature. 1682 1683.. index:: [no] neighbor PEER dont-capability-negotiate 1684.. clicmd:: [no] neighbor PEER dont-capability-negotiate 1685 1686 Suppress sending Capability Negotiation as OPEN message optional parameter 1687 to the peer. This command only affects the peer is configured other than 1688 IPv4 unicast configuration. 1689 1690 When remote peer does not have capability negotiation feature, remote peer 1691 will not send any capabilities at all. In that case, bgp configures the peer 1692 with configured capabilities. 1693 1694 You may prefer locally configured capabilities more than the negotiated 1695 capabilities even though remote peer sends capabilities. If the peer is 1696 configured by *override-capability*, *bgpd* ignores received capabilities 1697 then override negotiated capabilities with configured values. 1698 1699 Additionally the operator should be reminded that this feature fundamentally 1700 disables the ability to use widely deployed BGP features. BGP unnumbered, 1701 hostname support, AS4, Addpath, Route Refresh, ORF, Dynamic Capabilities, 1702 and graceful restart. 1703 1704.. index:: neighbor PEER override-capability 1705.. clicmd:: neighbor PEER override-capability 1706 1707.. index:: no neighbor PEER override-capability 1708.. clicmd:: no neighbor PEER override-capability 1709 1710 Override the result of Capability Negotiation with local configuration. 1711 Ignore remote peer's capability value. 1712 1713.. _bgp-as-path-access-lists: 1714 1715AS Path Access Lists 1716-------------------- 1717 1718AS path access list is user defined AS path. 1719 1720.. index:: bgp as-path access-list WORD permit|deny LINE 1721.. clicmd:: bgp as-path access-list WORD permit|deny LINE 1722 1723 This command defines a new AS path access list. 1724 1725.. index:: no bgp as-path access-list WORD 1726.. clicmd:: no bgp as-path access-list WORD 1727 1728.. index:: no bgp as-path access-list WORD permit|deny LINE 1729.. clicmd:: no bgp as-path access-list WORD permit|deny LINE 1730 1731.. _bgp-bogon-filter-example: 1732 1733Bogon ASN filter policy configuration example 1734^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1735 1736.. code-block:: frr 1737 1738 bgp as-path access-list 99 permit _0_ 1739 bgp as-path access-list 99 permit _23456_ 1740 bgp as-path access-list 99 permit _1310[0-6][0-9]_|_13107[0-1]_ 1741 1742.. _bgp-using-as-path-in-route-map: 1743 1744Using AS Path in Route Map 1745-------------------------- 1746 1747.. index:: [no] match as-path WORD 1748.. clicmd:: [no] match as-path WORD 1749 1750 For a given as-path, WORD, match it on the BGP as-path given for the prefix 1751 and if it matches do normal route-map actions. The no form of the command 1752 removes this match from the route-map. 1753 1754.. index:: [no] set as-path prepend AS-PATH 1755.. clicmd:: [no] set as-path prepend AS-PATH 1756 1757 Prepend the given string of AS numbers to the AS_PATH of the BGP path's NLRI. 1758 The no form of this command removes this set operation from the route-map. 1759 1760.. index:: [no] set as-path prepend last-as NUM 1761.. clicmd:: [no] set as-path prepend last-as NUM 1762 1763 Prepend the existing last AS number (the leftmost ASN) to the AS_PATH. 1764 The no form of this command removes this set operation from the route-map. 1765 1766.. _bgp-communities-attribute: 1767 1768Communities Attribute 1769--------------------- 1770 1771The BGP communities attribute is widely used for implementing policy routing. 1772Network operators can manipulate BGP communities attribute based on their 1773network policy. BGP communities attribute is defined in :rfc:`1997` and 1774:rfc:`1998`. It is an optional transitive attribute, therefore local policy can 1775travel through different autonomous system. 1776 1777The communities attribute is a set of communities values. Each community value 1778is 4 octet long. The following format is used to define the community value. 1779 1780``AS:VAL`` 1781 This format represents 4 octet communities value. ``AS`` is high order 2 1782 octet in digit format. ``VAL`` is low order 2 octet in digit format. This 1783 format is useful to define AS oriented policy value. For example, 1784 ``7675:80`` can be used when AS 7675 wants to pass local policy value 80 to 1785 neighboring peer. 1786 1787``internet`` 1788 ``internet`` represents well-known communities value 0. 1789 1790``graceful-shutdown`` 1791 ``graceful-shutdown`` represents well-known communities value 1792 ``GRACEFUL_SHUTDOWN`` ``0xFFFF0000`` ``65535:0``. :rfc:`8326` implements 1793 the purpose Graceful BGP Session Shutdown to reduce the amount of 1794 lost traffic when taking BGP sessions down for maintenance. The use 1795 of the community needs to be supported from your peers side to 1796 actually have any effect. 1797 1798``accept-own`` 1799 ``accept-own`` represents well-known communities value ``ACCEPT_OWN`` 1800 ``0xFFFF0001`` ``65535:1``. :rfc:`7611` implements a way to signal 1801 to a router to accept routes with a local nexthop address. This 1802 can be the case when doing policing and having traffic having a 1803 nexthop located in another VRF but still local interface to the 1804 router. It is recommended to read the RFC for full details. 1805 1806``route-filter-translated-v4`` 1807 ``route-filter-translated-v4`` represents well-known communities value 1808 ``ROUTE_FILTER_TRANSLATED_v4`` ``0xFFFF0002`` ``65535:2``. 1809 1810``route-filter-v4`` 1811 ``route-filter-v4`` represents well-known communities value 1812 ``ROUTE_FILTER_v4`` ``0xFFFF0003`` ``65535:3``. 1813 1814``route-filter-translated-v6`` 1815 ``route-filter-translated-v6`` represents well-known communities value 1816 ``ROUTE_FILTER_TRANSLATED_v6`` ``0xFFFF0004`` ``65535:4``. 1817 1818``route-filter-v6`` 1819 ``route-filter-v6`` represents well-known communities value 1820 ``ROUTE_FILTER_v6`` ``0xFFFF0005`` ``65535:5``. 1821 1822``llgr-stale`` 1823 ``llgr-stale`` represents well-known communities value ``LLGR_STALE`` 1824 ``0xFFFF0006`` ``65535:6``. 1825 Assigned and intended only for use with routers supporting the 1826 Long-lived Graceful Restart Capability as described in 1827 [Draft-IETF-uttaro-idr-bgp-persistence]_. 1828 Routers receiving routes with this community may (depending on 1829 implementation) choose allow to reject or modify routes on the 1830 presence or absence of this community. 1831 1832``no-llgr`` 1833 ``no-llgr`` represents well-known communities value ``NO_LLGR`` 1834 ``0xFFFF0007`` ``65535:7``. 1835 Assigned and intended only for use with routers supporting the 1836 Long-lived Graceful Restart Capability as described in 1837 [Draft-IETF-uttaro-idr-bgp-persistence]_. 1838 Routers receiving routes with this community may (depending on 1839 implementation) choose allow to reject or modify routes on the 1840 presence or absence of this community. 1841 1842``accept-own-nexthop`` 1843 ``accept-own-nexthop`` represents well-known communities value 1844 ``accept-own-nexthop`` ``0xFFFF0008`` ``65535:8``. 1845 [Draft-IETF-agrewal-idr-accept-own-nexthop]_ describes 1846 how to tag and label VPN routes to be able to send traffic between VRFs 1847 via an internal layer 2 domain on the same PE device. Refer to 1848 [Draft-IETF-agrewal-idr-accept-own-nexthop]_ for full details. 1849 1850``blackhole`` 1851 ``blackhole`` represents well-known communities value ``BLACKHOLE`` 1852 ``0xFFFF029A`` ``65535:666``. :rfc:`7999` documents sending prefixes to 1853 EBGP peers and upstream for the purpose of blackholing traffic. 1854 Prefixes tagged with the this community should normally not be 1855 re-advertised from neighbors of the originating network. It is 1856 recommended upon receiving prefixes tagged with this community to 1857 add ``NO_EXPORT`` and ``NO_ADVERTISE``. 1858 1859``no-export`` 1860 ``no-export`` represents well-known communities value ``NO_EXPORT`` 1861 ``0xFFFFFF01``. All routes carry this value must not be advertised to 1862 outside a BGP confederation boundary. If neighboring BGP peer is part of BGP 1863 confederation, the peer is considered as inside a BGP confederation 1864 boundary, so the route will be announced to the peer. 1865 1866``no-advertise`` 1867 ``no-advertise`` represents well-known communities value ``NO_ADVERTISE`` 1868 ``0xFFFFFF02``. All routes carry this value must not be advertise to other 1869 BGP peers. 1870 1871``local-AS`` 1872 ``local-AS`` represents well-known communities value ``NO_EXPORT_SUBCONFED`` 1873 ``0xFFFFFF03``. All routes carry this value must not be advertised to 1874 external BGP peers. Even if the neighboring router is part of confederation, 1875 it is considered as external BGP peer, so the route will not be announced to 1876 the peer. 1877 1878``no-peer`` 1879 ``no-peer`` represents well-known communities value ``NOPEER`` 1880 ``0xFFFFFF04`` ``65535:65284``. :rfc:`3765` is used to communicate to 1881 another network how the originating network want the prefix propagated. 1882 1883When the communities attribute is received duplicate community values in the 1884attribute are ignored and value is sorted in numerical order. 1885 1886.. [Draft-IETF-uttaro-idr-bgp-persistence] <https://tools.ietf.org/id/draft-uttaro-idr-bgp-persistence-04.txt> 1887.. [Draft-IETF-agrewal-idr-accept-own-nexthop] <https://tools.ietf.org/id/draft-agrewal-idr-accept-own-nexthop-00.txt> 1888 1889.. _bgp-community-lists: 1890 1891Community Lists 1892^^^^^^^^^^^^^^^ 1893Community lists are user defined lists of community attribute values. These 1894lists can be used for matching or manipulating the communities attribute in 1895UPDATE messages. 1896 1897There are two types of community list: 1898 1899standard 1900 This type accepts an explicit value for the attribute. 1901 1902expanded 1903 This type accepts a regular expression. Because the regex must be 1904 interpreted on each use expanded community lists are slower than standard 1905 lists. 1906 1907.. index:: bgp community-list standard NAME permit|deny COMMUNITY 1908.. clicmd:: bgp community-list standard NAME permit|deny COMMUNITY 1909 1910 This command defines a new standard community list. ``COMMUNITY`` is 1911 communities value. The ``COMMUNITY`` is compiled into community structure. 1912 We can define multiple community list under same name. In that case match 1913 will happen user defined order. Once the community list matches to 1914 communities attribute in BGP updates it return permit or deny by the 1915 community list definition. When there is no matched entry, deny will be 1916 returned. When ``COMMUNITY`` is empty it matches to any routes. 1917 1918.. index:: bgp community-list expanded NAME permit|deny COMMUNITY 1919.. clicmd:: bgp community-list expanded NAME permit|deny COMMUNITY 1920 1921 This command defines a new expanded community list. ``COMMUNITY`` is a 1922 string expression of communities attribute. ``COMMUNITY`` can be a regular 1923 expression (:ref:`bgp-regular-expressions`) to match the communities 1924 attribute in BGP updates. The expanded community is only used to filter, 1925 not `set` actions. 1926 1927.. deprecated:: 5.0 1928 It is recommended to use the more explicit versions of this command. 1929 1930.. index:: bgp community-list NAME permit|deny COMMUNITY 1931.. clicmd:: bgp community-list NAME permit|deny COMMUNITY 1932 1933 When the community list type is not specified, the community list type is 1934 automatically detected. If ``COMMUNITY`` can be compiled into communities 1935 attribute, the community list is defined as a standard community list. 1936 Otherwise it is defined as an expanded community list. This feature is left 1937 for backward compatibility. Use of this feature is not recommended. 1938 1939 1940.. index:: no bgp community-list [standard|expanded] NAME 1941.. clicmd:: no bgp community-list [standard|expanded] NAME 1942 1943 Deletes the community list specified by ``NAME``. All community lists share 1944 the same namespace, so it's not necessary to specify ``standard`` or 1945 ``expanded``; these modifiers are purely aesthetic. 1946 1947.. index:: show bgp community-list [NAME detail] 1948.. clicmd:: show bgp community-list [NAME detail] 1949 1950 Displays community list information. When ``NAME`` is specified the 1951 specified community list's information is shown. 1952 1953 :: 1954 1955 # show bgp community-list 1956 Named Community standard list CLIST 1957 permit 7675:80 7675:100 no-export 1958 deny internet 1959 Named Community expanded list EXPAND 1960 permit : 1961 1962 # show bgp community-list CLIST detail 1963 Named Community standard list CLIST 1964 permit 7675:80 7675:100 no-export 1965 deny internet 1966 1967 1968.. _bgp-numbered-community-lists: 1969 1970Numbered Community Lists 1971^^^^^^^^^^^^^^^^^^^^^^^^ 1972 1973When number is used for BGP community list name, the number has 1974special meanings. Community list number in the range from 1 and 99 is 1975standard community list. Community list number in the range from 100 1976to 199 is expanded community list. These community lists are called 1977as numbered community lists. On the other hand normal community lists 1978is called as named community lists. 1979 1980.. index:: bgp community-list (1-99) permit|deny COMMUNITY 1981.. clicmd:: bgp community-list (1-99) permit|deny COMMUNITY 1982 1983 This command defines a new community list. The argument to (1-99) defines 1984 the list identifier. 1985 1986.. index:: bgp community-list (100-199) permit|deny COMMUNITY 1987.. clicmd:: bgp community-list (100-199) permit|deny COMMUNITY 1988 1989 This command defines a new expanded community list. The argument to 1990 (100-199) defines the list identifier. 1991 1992.. _bgp-using-communities-in-route-map: 1993 1994Using Communities in Route Maps 1995^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1996 1997In :ref:`route-map` we can match on or set the BGP communities attribute. Using 1998this feature network operator can implement their network policy based on BGP 1999communities attribute. 2000 2001The following commands can be used in route maps: 2002 2003.. index:: match community WORD exact-match [exact-match] 2004.. clicmd:: match community WORD exact-match [exact-match] 2005 2006 This command perform match to BGP updates using community list WORD. When 2007 the one of BGP communities value match to the one of communities value in 2008 community list, it is match. When `exact-match` keyword is specified, match 2009 happen only when BGP updates have completely same communities value 2010 specified in the community list. 2011 2012.. index:: set community <none|COMMUNITY> additive 2013.. clicmd:: set community <none|COMMUNITY> additive 2014 2015 This command sets the community value in BGP updates. If the attribute is 2016 already configured, the newly provided value replaces the old one unless the 2017 ``additive`` keyword is specified, in which case the new value is appended 2018 to the existing value. 2019 2020 If ``none`` is specified as the community value, the communities attribute 2021 is not sent. 2022 2023 It is not possible to set an expanded community list. 2024 2025.. index:: set comm-list WORD delete 2026.. clicmd:: set comm-list WORD delete 2027 2028 This command remove communities value from BGP communities attribute. The 2029 ``word`` is community list name. When BGP route's communities value matches 2030 to the community list ``word``, the communities value is removed. When all 2031 of communities value is removed eventually, the BGP update's communities 2032 attribute is completely removed. 2033 2034.. _bgp-communities-example: 2035 2036Example Configuration 2037^^^^^^^^^^^^^^^^^^^^^ 2038 2039The following configuration is exemplary of the most typical usage of BGP 2040communities attribute. In the example, AS 7675 provides an upstream Internet 2041connection to AS 100. When the following configuration exists in AS 7675, the 2042network operator of AS 100 can set local preference in AS 7675 network by 2043setting BGP communities attribute to the updates. 2044 2045.. code-block:: frr 2046 2047 router bgp 7675 2048 neighbor 192.168.0.1 remote-as 100 2049 address-family ipv4 unicast 2050 neighbor 192.168.0.1 route-map RMAP in 2051 exit-address-family 2052 ! 2053 bgp community-list 70 permit 7675:70 2054 bgp community-list 70 deny 2055 bgp community-list 80 permit 7675:80 2056 bgp community-list 80 deny 2057 bgp community-list 90 permit 7675:90 2058 bgp community-list 90 deny 2059 ! 2060 route-map RMAP permit 10 2061 match community 70 2062 set local-preference 70 2063 ! 2064 route-map RMAP permit 20 2065 match community 80 2066 set local-preference 80 2067 ! 2068 route-map RMAP permit 30 2069 match community 90 2070 set local-preference 90 2071 2072 2073The following configuration announces ``10.0.0.0/8`` from AS 100 to AS 7675. 2074The route has communities value ``7675:80`` so when above configuration exists 2075in AS 7675, the announced routes' local preference value will be set to 80. 2076 2077.. code-block:: frr 2078 2079 router bgp 100 2080 network 10.0.0.0/8 2081 neighbor 192.168.0.2 remote-as 7675 2082 address-family ipv4 unicast 2083 neighbor 192.168.0.2 route-map RMAP out 2084 exit-address-family 2085 ! 2086 ip prefix-list PLIST permit 10.0.0.0/8 2087 ! 2088 route-map RMAP permit 10 2089 match ip address prefix-list PLIST 2090 set community 7675:80 2091 2092 2093The following configuration is an example of BGP route filtering using 2094communities attribute. This configuration only permit BGP routes which has BGP 2095communities value ``0:80`` or ``0:90``. The network operator can set special 2096internal communities value at BGP border router, then limit the BGP route 2097announcements into the internal network. 2098 2099.. code-block:: frr 2100 2101 router bgp 7675 2102 neighbor 192.168.0.1 remote-as 100 2103 address-family ipv4 unicast 2104 neighbor 192.168.0.1 route-map RMAP in 2105 exit-address-family 2106 ! 2107 bgp community-list 1 permit 0:80 0:90 2108 ! 2109 route-map RMAP permit in 2110 match community 1 2111 2112 2113The following example filters BGP routes which have a community value of 2114``1:1``. When there is no match community-list returns ``deny``. To avoid 2115filtering all routes, a ``permit`` line is set at the end of the 2116community-list. 2117 2118.. code-block:: frr 2119 2120 router bgp 7675 2121 neighbor 192.168.0.1 remote-as 100 2122 address-family ipv4 unicast 2123 neighbor 192.168.0.1 route-map RMAP in 2124 exit-address-family 2125 ! 2126 bgp community-list standard FILTER deny 1:1 2127 bgp community-list standard FILTER permit 2128 ! 2129 route-map RMAP permit 10 2130 match community FILTER 2131 2132 2133The communities value keyword ``internet`` has special meanings in standard 2134community lists. In the below example ``internet`` matches all BGP routes even 2135if the route does not have communities attribute at all. So community list 2136``INTERNET`` is the same as ``FILTER`` in the previous example. 2137 2138.. code-block:: frr 2139 2140 bgp community-list standard INTERNET deny 1:1 2141 bgp community-list standard INTERNET permit internet 2142 2143 2144The following configuration is an example of communities value deletion. With 2145this configuration the community values ``100:1`` and ``100:2`` are removed 2146from BGP updates. For communities value deletion, only ``permit`` 2147community-list is used. ``deny`` community-list is ignored. 2148 2149.. code-block:: frr 2150 2151 router bgp 7675 2152 neighbor 192.168.0.1 remote-as 100 2153 address-family ipv4 unicast 2154 neighbor 192.168.0.1 route-map RMAP in 2155 exit-address-family 2156 ! 2157 bgp community-list standard DEL permit 100:1 100:2 2158 ! 2159 route-map RMAP permit 10 2160 set comm-list DEL delete 2161 2162 2163.. _bgp-extended-communities-attribute: 2164 2165Extended Communities Attribute 2166^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2167 2168BGP extended communities attribute is introduced with MPLS VPN/BGP technology. 2169MPLS VPN/BGP expands capability of network infrastructure to provide VPN 2170functionality. At the same time it requires a new framework for policy routing. 2171With BGP Extended Communities Attribute we can use Route Target or Site of 2172Origin for implementing network policy for MPLS VPN/BGP. 2173 2174BGP Extended Communities Attribute is similar to BGP Communities Attribute. It 2175is an optional transitive attribute. BGP Extended Communities Attribute can 2176carry multiple Extended Community value. Each Extended Community value is 2177eight octet length. 2178 2179BGP Extended Communities Attribute provides an extended range compared with BGP 2180Communities Attribute. Adding to that there is a type field in each value to 2181provides community space structure. 2182 2183There are two format to define Extended Community value. One is AS based format 2184the other is IP address based format. 2185 2186``AS:VAL`` 2187 This is a format to define AS based Extended Community value. ``AS`` part 2188 is 2 octets Global Administrator subfield in Extended Community value. 2189 ``VAL`` part is 4 octets Local Administrator subfield. ``7675:100`` 2190 represents AS 7675 policy value 100. 2191 2192``IP-Address:VAL`` 2193 This is a format to define IP address based Extended Community value. 2194 ``IP-Address`` part is 4 octets Global Administrator subfield. ``VAL`` part 2195 is 2 octets Local Administrator subfield. 2196 2197.. _bgp-extended-community-lists: 2198 2199Extended Community Lists 2200^^^^^^^^^^^^^^^^^^^^^^^^ 2201 2202.. index:: bgp extcommunity-list standard NAME permit|deny EXTCOMMUNITY 2203.. clicmd:: bgp extcommunity-list standard NAME permit|deny EXTCOMMUNITY 2204 2205 This command defines a new standard extcommunity-list. `extcommunity` is 2206 extended communities value. The `extcommunity` is compiled into extended 2207 community structure. We can define multiple extcommunity-list under same 2208 name. In that case match will happen user defined order. Once the 2209 extcommunity-list matches to extended communities attribute in BGP updates 2210 it return permit or deny based upon the extcommunity-list definition. When 2211 there is no matched entry, deny will be returned. When `extcommunity` is 2212 empty it matches to any routes. 2213 2214.. index:: bgp extcommunity-list expanded NAME permit|deny LINE 2215.. clicmd:: bgp extcommunity-list expanded NAME permit|deny LINE 2216 2217 This command defines a new expanded extcommunity-list. `line` is a string 2218 expression of extended communities attribute. `line` can be a regular 2219 expression (:ref:`bgp-regular-expressions`) to match an extended communities 2220 attribute in BGP updates. 2221 2222.. index:: no bgp extcommunity-list NAME 2223.. clicmd:: no bgp extcommunity-list NAME 2224 2225.. index:: no bgp extcommunity-list standard NAME 2226.. clicmd:: no bgp extcommunity-list standard NAME 2227 2228.. index:: no bgp extcommunity-list expanded NAME 2229.. clicmd:: no bgp extcommunity-list expanded NAME 2230 2231 These commands delete extended community lists specified by `name`. All of 2232 extended community lists shares a single name space. So extended community 2233 lists can be removed simply specifying the name. 2234 2235.. index:: show bgp extcommunity-list 2236.. clicmd:: show bgp extcommunity-list 2237 2238.. index:: show bgp extcommunity-list NAME detail 2239.. clicmd:: show bgp extcommunity-list NAME detail 2240 2241 This command displays current extcommunity-list information. When `name` is 2242 specified the community list's information is shown.:: 2243 2244 # show bgp extcommunity-list 2245 2246 2247.. _bgp-extended-communities-in-route-map: 2248 2249BGP Extended Communities in Route Map 2250""""""""""""""""""""""""""""""""""""" 2251 2252.. index:: match extcommunity WORD 2253.. clicmd:: match extcommunity WORD 2254 2255.. index:: set extcommunity rt EXTCOMMUNITY 2256.. clicmd:: set extcommunity rt EXTCOMMUNITY 2257 2258 This command set Route Target value. 2259 2260.. index:: set extcommunity soo EXTCOMMUNITY 2261.. clicmd:: set extcommunity soo EXTCOMMUNITY 2262 2263 This command set Site of Origin value. 2264 2265.. index:: set extcommunity bandwidth <(1-25600) | cumulative | num-multipaths> [non-transitive] 2266.. clicmd:: set extcommunity bandwidth <(1-25600) | cumulative | num-multipaths> [non-transitive] 2267 2268 This command sets the BGP link-bandwidth extended community for the prefix 2269 (best path) for which it is applied. The link-bandwidth can be specified as 2270 an ``explicit value`` (specified in Mbps), or the router can be told to use 2271 the ``cumulative bandwidth`` of all multipaths for the prefix or to compute 2272 it based on the ``number of multipaths``. The link bandwidth extended 2273 community is encoded as ``transitive`` unless the set command explicitly 2274 configures it as ``non-transitive``. 2275 2276.. seealso:: :ref:`wecmp_linkbw` 2277 2278Note that the extended expanded community is only used for `match` rule, not for 2279`set` actions. 2280 2281.. _bgp-large-communities-attribute: 2282 2283Large Communities Attribute 2284^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2285 2286The BGP Large Communities attribute was introduced in Feb 2017 with 2287:rfc:`8092`. 2288 2289The BGP Large Communities Attribute is similar to the BGP Communities Attribute 2290except that it has 3 components instead of two and each of which are 4 octets 2291in length. Large Communities bring additional functionality and convenience 2292over traditional communities, specifically the fact that the ``GLOBAL`` part 2293below is now 4 octets wide allowing seamless use in networks using 4-byte ASNs. 2294 2295``GLOBAL:LOCAL1:LOCAL2`` 2296 This is the format to define Large Community values. Referencing :rfc:`8195` 2297 the values are commonly referred to as follows: 2298 2299 - The ``GLOBAL`` part is a 4 octet Global Administrator field, commonly used 2300 as the operators AS number. 2301 - The ``LOCAL1`` part is a 4 octet Local Data Part 1 subfield referred to as 2302 a function. 2303 - The ``LOCAL2`` part is a 4 octet Local Data Part 2 field and referred to 2304 as the parameter subfield. 2305 2306 As an example, ``65551:1:10`` represents AS 65551 function 1 and parameter 2307 10. The referenced RFC above gives some guidelines on recommended usage. 2308 2309.. _bgp-large-community-lists: 2310 2311Large Community Lists 2312""""""""""""""""""""" 2313 2314Two types of large community lists are supported, namely `standard` and 2315`expanded`. 2316 2317.. index:: bgp large-community-list standard NAME permit|deny LARGE-COMMUNITY 2318.. clicmd:: bgp large-community-list standard NAME permit|deny LARGE-COMMUNITY 2319 2320 This command defines a new standard large-community-list. `large-community` 2321 is the Large Community value. We can add multiple large communities under 2322 same name. In that case the match will happen in the user defined order. 2323 Once the large-community-list matches the Large Communities attribute in BGP 2324 updates it will return permit or deny based upon the large-community-list 2325 definition. When there is no matched entry, a deny will be returned. When 2326 `large-community` is empty it matches any routes. 2327 2328.. index:: bgp large-community-list expanded NAME permit|deny LINE 2329.. clicmd:: bgp large-community-list expanded NAME permit|deny LINE 2330 2331 This command defines a new expanded large-community-list. Where `line` is a 2332 string matching expression, it will be compared to the entire Large 2333 Communities attribute as a string, with each large-community in order from 2334 lowest to highest. `line` can also be a regular expression which matches 2335 this Large Community attribute. 2336 2337.. index:: no bgp large-community-list NAME 2338.. clicmd:: no bgp large-community-list NAME 2339 2340.. index:: no bgp large-community-list standard NAME 2341.. clicmd:: no bgp large-community-list standard NAME 2342 2343.. index:: no bgp large-community-list expanded NAME 2344.. clicmd:: no bgp large-community-list expanded NAME 2345 2346 These commands delete Large Community lists specified by `name`. All Large 2347 Community lists share a single namespace. This means Large Community lists 2348 can be removed by simply specifying the name. 2349 2350.. index:: show bgp large-community-list 2351.. clicmd:: show bgp large-community-list 2352 2353.. index:: show bgp large-community-list NAME detail 2354.. clicmd:: show bgp large-community-list NAME detail 2355 2356 This command display current large-community-list information. When 2357 `name` is specified the community list information is shown. 2358 2359.. index:: show ip bgp large-community-info 2360.. clicmd:: show ip bgp large-community-info 2361 2362 This command displays the current large communities in use. 2363 2364.. _bgp-large-communities-in-route-map: 2365 2366Large Communities in Route Map 2367"""""""""""""""""""""""""""""" 2368 2369.. index:: match large-community LINE [exact-match] 2370.. clicmd:: match large-community LINE [exact-match] 2371 2372 Where `line` can be a simple string to match, or a regular expression. It 2373 is very important to note that this match occurs on the entire 2374 large-community string as a whole, where each large-community is ordered 2375 from lowest to highest. When `exact-match` keyword is specified, match 2376 happen only when BGP updates have completely same large communities value 2377 specified in the large community list. 2378 2379.. index:: set large-community LARGE-COMMUNITY 2380.. clicmd:: set large-community LARGE-COMMUNITY 2381 2382.. index:: set large-community LARGE-COMMUNITY LARGE-COMMUNITY 2383.. clicmd:: set large-community LARGE-COMMUNITY LARGE-COMMUNITY 2384 2385.. index:: set large-community LARGE-COMMUNITY additive 2386.. clicmd:: set large-community LARGE-COMMUNITY additive 2387 2388 These commands are used for setting large-community values. The first 2389 command will overwrite any large-communities currently present. 2390 The second specifies two large-communities, which overwrites the current 2391 large-community list. The third will add a large-community value without 2392 overwriting other values. Multiple large-community values can be specified. 2393 2394Note that the large expanded community is only used for `match` rule, not for 2395`set` actions. 2396 2397.. _bgp-l3vpn-vrfs: 2398 2399L3VPN VRFs 2400---------- 2401 2402*bgpd* supports :abbr:`L3VPN (Layer 3 Virtual Private Networks)` :abbr:`VRFs 2403(Virtual Routing and Forwarding)` for IPv4 :rfc:`4364` and IPv6 :rfc:`4659`. 2404L3VPN routes, and their associated VRF MPLS labels, can be distributed to VPN 2405SAFI neighbors in the *default*, i.e., non VRF, BGP instance. VRF MPLS labels 2406are reached using *core* MPLS labels which are distributed using LDP or BGP 2407labeled unicast. *bgpd* also supports inter-VRF route leaking. 2408 2409 2410.. _bgp-vrf-route-leaking: 2411 2412VRF Route Leaking 2413----------------- 2414 2415BGP routes may be leaked (i.e. copied) between a unicast VRF RIB and the VPN 2416SAFI RIB of the default VRF for use in MPLS-based L3VPNs. Unicast routes may 2417also be leaked between any VRFs (including the unicast RIB of the default BGP 2418instanced). A shortcut syntax is also available for specifying leaking from one 2419VRF to another VRF using the default instance's VPN RIB as the intemediary. A 2420common application of the VRF-VRF feature is to connect a customer's private 2421routing domain to a provider's VPN service. Leaking is configured from the 2422point of view of an individual VRF: ``import`` refers to routes leaked from VPN 2423to a unicast VRF, whereas ``export`` refers to routes leaked from a unicast VRF 2424to VPN. 2425 2426Required parameters 2427^^^^^^^^^^^^^^^^^^^ 2428 2429Routes exported from a unicast VRF to the VPN RIB must be augmented by two 2430parameters: 2431 2432- an :abbr:`RD (Route Distinguisher)` 2433- an :abbr:`RTLIST (Route-target List)` 2434 2435Configuration for these exported routes must, at a minimum, specify these two 2436parameters. 2437 2438Routes imported from the VPN RIB to a unicast VRF are selected according to 2439their RTLISTs. Routes whose RTLIST contains at least one route-target in 2440common with the configured import RTLIST are leaked. Configuration for these 2441imported routes must specify an RTLIST to be matched. 2442 2443The RD, which carries no semantic value, is intended to make the route unique 2444in the VPN RIB among all routes of its prefix that originate from all the 2445customers and sites that are attached to the provider's VPN service. 2446Accordingly, each site of each customer is typically assigned an RD that is 2447unique across the entire provider network. 2448 2449The RTLIST is a set of route-target extended community values whose purpose is 2450to specify route-leaking policy. Typically, a customer is assigned a single 2451route-target value for import and export to be used at all customer sites. This 2452configuration specifies a simple topology wherein a customer has a single 2453routing domain which is shared across all its sites. More complex routing 2454topologies are possible through use of additional route-targets to augment the 2455leaking of sets of routes in various ways. 2456 2457When using the shortcut syntax for vrf-to-vrf leaking, the RD and RT are 2458auto-derived. 2459 2460General configuration 2461^^^^^^^^^^^^^^^^^^^^^ 2462 2463Configuration of route leaking between a unicast VRF RIB and the VPN SAFI RIB 2464of the default VRF is accomplished via commands in the context of a VRF 2465address-family: 2466 2467.. index:: rd vpn export AS:NN|IP:nn 2468.. clicmd:: rd vpn export AS:NN|IP:nn 2469 2470 Specifies the route distinguisher to be added to a route exported from the 2471 current unicast VRF to VPN. 2472 2473.. index:: no rd vpn export [AS:NN|IP:nn] 2474.. clicmd:: no rd vpn export [AS:NN|IP:nn] 2475 2476 Deletes any previously-configured export route distinguisher. 2477 2478.. index:: rt vpn import|export|both RTLIST... 2479.. clicmd:: rt vpn import|export|both RTLIST... 2480 2481 Specifies the route-target list to be attached to a route (export) or the 2482 route-target list to match against (import) when exporting/importing between 2483 the current unicast VRF and VPN. 2484 2485 The RTLIST is a space-separated list of route-targets, which are BGP 2486 extended community values as described in 2487 :ref:`bgp-extended-communities-attribute`. 2488 2489.. index:: no rt vpn import|export|both [RTLIST...] 2490.. clicmd:: no rt vpn import|export|both [RTLIST...] 2491 2492 Deletes any previously-configured import or export route-target list. 2493 2494.. index:: label vpn export (0..1048575)|auto 2495.. clicmd:: label vpn export (0..1048575)|auto 2496 2497 Enables an MPLS label to be attached to a route exported from the current 2498 unicast VRF to VPN. If the value specified is ``auto``, the label value is 2499 automatically assigned from a pool maintained by the Zebra daemon. If Zebra 2500 is not running, or if this command is not configured, automatic label 2501 assignment will not complete, which will block corresponding route export. 2502 2503.. index:: no label vpn export [(0..1048575)|auto] 2504.. clicmd:: no label vpn export [(0..1048575)|auto] 2505 2506 Deletes any previously-configured export label. 2507 2508.. index:: nexthop vpn export A.B.C.D|X:X::X:X 2509.. clicmd:: nexthop vpn export A.B.C.D|X:X::X:X 2510 2511 Specifies an optional nexthop value to be assigned to a route exported from 2512 the current unicast VRF to VPN. If left unspecified, the nexthop will be set 2513 to 0.0.0.0 or 0:0::0:0 (self). 2514 2515.. index:: no nexthop vpn export [A.B.C.D|X:X::X:X] 2516.. clicmd:: no nexthop vpn export [A.B.C.D|X:X::X:X] 2517 2518 Deletes any previously-configured export nexthop. 2519 2520.. index:: route-map vpn import|export MAP 2521.. clicmd:: route-map vpn import|export MAP 2522 2523 Specifies an optional route-map to be applied to routes imported or exported 2524 between the current unicast VRF and VPN. 2525 2526.. index:: no route-map vpn import|export [MAP] 2527.. clicmd:: no route-map vpn import|export [MAP] 2528 2529 Deletes any previously-configured import or export route-map. 2530 2531.. index:: import|export vpn 2532.. clicmd:: import|export vpn 2533 2534 Enables import or export of routes between the current unicast VRF and VPN. 2535 2536.. index:: no import|export vpn 2537.. clicmd:: no import|export vpn 2538 2539 Disables import or export of routes between the current unicast VRF and VPN. 2540 2541.. index:: import vrf VRFNAME 2542.. clicmd:: import vrf VRFNAME 2543 2544 Shortcut syntax for specifying automatic leaking from vrf VRFNAME to 2545 the current VRF using the VPN RIB as intermediary. The RD and RT 2546 are auto derived and should not be specified explicitly for either the 2547 source or destination VRF's. 2548 2549 This shortcut syntax mode is not compatible with the explicit 2550 `import vpn` and `export vpn` statements for the two VRF's involved. 2551 The CLI will disallow attempts to configure incompatible leaking 2552 modes. 2553 2554.. index:: no import vrf VRFNAME 2555.. clicmd:: no import vrf VRFNAME 2556 2557 Disables automatic leaking from vrf VRFNAME to the current VRF using 2558 the VPN RIB as intermediary. 2559 2560 2561.. _bgp-evpn: 2562 2563Ethernet Virtual Network - EVPN 2564------------------------------- 2565 2566.. _bgp-evpn-advertise-pip: 2567 2568EVPN advertise-PIP 2569^^^^^^^^^^^^^^^^^^ 2570 2571In a EVPN symmetric routing MLAG deployment, all EVPN routes advertised 2572with anycast-IP as next-hop IP and anycast MAC as the Router MAC (RMAC - in 2573BGP EVPN Extended-Community). 2574EVPN picks up the next-hop IP from the VxLAN interface's local tunnel IP and 2575the RMAC is obtained from the MAC of the L3VNI's SVI interface. 2576Note: Next-hop IP is used for EVPN routes whether symmetric routing is 2577deployed or not but the RMAC is only relevant for symmetric routing scenario. 2578 2579Current behavior is not ideal for Prefix (type-5) and self (type-2) 2580routes. This is because the traffic from remote VTEPs routed sub optimally 2581if they land on the system where the route does not belong. 2582 2583The advertise-pip feature advertises Prefix (type-5) and self (type-2) 2584routes with system's individual (primary) IP as the next-hop and individual 2585(system) MAC as Router-MAC (RMAC), while leaving the behavior unchanged for 2586other EVPN routes. 2587 2588To support this feature there needs to have ability to co-exist a 2589(system-MAC, system-IP) pair with a (anycast-MAC, anycast-IP) pair with the 2590ability to terminate VxLAN-encapsulated packets received for either pair on 2591the same L3VNI (i.e associated VLAN). This capability is need per tenant 2592VRF instance. 2593 2594To derive the system-MAC and the anycast MAC, there needs to have a 2595separate/additional MAC-VLAN interface corresponding to L3VNI’s SVI. 2596The SVI interface’s MAC address can be interpreted as system-MAC 2597and MAC-VLAN interface's MAC as anycast MAC. 2598 2599To derive system-IP and anycast-IP, the default BGP instance's router-id is used 2600as system-IP and the VxLAN interface’s local tunnel IP as the anycast-IP. 2601 2602User has an option to configure the system-IP and/or system-MAC value if the 2603auto derived value is not preferred. 2604 2605Note: By default, advertise-pip feature is enabled and user has an option to 2606disable the feature via configuration CLI. Once the feature is disable under 2607bgp vrf instance or MAC-VLAN interface is not configured, all the routes follow 2608the same behavior of using same next-hop and RMAC values. 2609 2610.. index:: [no] advertise-pip [ip <addr> [mac <addr>]] 2611.. clicmd:: [no] advertise-pip [ip <addr> [mac <addr>]] 2612 2613Enables or disables advertise-pip feature, specifiy system-IP and/or system-MAC 2614parameters. 2615 2616+Support with VRF network namespace backend 2617+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2618It is possible to separate overlay networks contained in VXLAN interfaces from 2619underlay networks by using VRFs. VRF-lite and VRF-netns backends can be used for 2620that. In the latter case, it is necessary to set both bridge and vxlan interface 2621in the same network namespace, as below example illustrates: 2622 2623.. code-block:: shell 2624 2625 # linux shell 2626 ip netns add vrf1 2627 ip link add name vxlan101 type vxlan id 101 dstport 4789 dev eth0 local 10.1.1.1 2628 ip link set dev vxlan101 netns vrf1 2629 ip netns exec vrf1 ip link set dev lo up 2630 ip netns exec vrf1 brctl addbr bridge101 2631 ip netns exec vrf1 brctl addif bridge101 vxlan101 2632 2633This makes it possible to separate not only layer 3 networks like VRF-lite networks. 2634Also, VRF netns based make possible to separate layer 2 networks on separate VRF 2635instances. 2636 2637.. _bgp-debugging: 2638 2639Debugging 2640--------- 2641 2642.. index:: show debug 2643.. clicmd:: show debug 2644 2645 Show all enabled debugs. 2646 2647.. index:: show bgp listeners 2648.. clicmd:: show bgp listeners 2649 2650 Display Listen sockets and the vrf that created them. Useful for debugging of when 2651 listen is not working and this is considered a developer debug statement. 2652 2653.. index:: [no] debug bgp neighbor-events 2654.. clicmd:: [no] debug bgp neighbor-events 2655 2656 Enable or disable debugging for neighbor events. This provides general 2657 information on BGP events such as peer connection / disconnection, session 2658 establishment / teardown, and capability negotiation. 2659 2660.. index:: [no] debug bgp updates 2661.. clicmd:: [no] debug bgp updates 2662 2663 Enable or disable debugging for BGP updates. This provides information on 2664 BGP UPDATE messages transmitted and received between local and remote 2665 instances. 2666 2667.. index:: [no] debug bgp keepalives 2668.. clicmd:: [no] debug bgp keepalives 2669 2670 Enable or disable debugging for BGP keepalives. This provides information on 2671 BGP KEEPALIVE messages transmitted and received between local and remote 2672 instances. 2673 2674.. index:: [no] debug bgp bestpath <A.B.C.D/M|X:X::X:X/M> 2675.. clicmd:: [no] debug bgp bestpath <A.B.C.D/M|X:X::X:X/M> 2676 2677 Enable or disable debugging for bestpath selection on the specified prefix. 2678 2679.. index:: [no] debug bgp nht 2680.. clicmd:: [no] debug bgp nht 2681 2682 Enable or disable debugging of BGP nexthop tracking. 2683 2684.. index:: [no] debug bgp update-groups 2685.. clicmd:: [no] debug bgp update-groups 2686 2687 Enable or disable debugging of dynamic update groups. This provides general 2688 information on group creation, deletion, join and prune events. 2689 2690.. index:: [no] debug bgp zebra 2691.. clicmd:: [no] debug bgp zebra 2692 2693 Enable or disable debugging of communications between *bgpd* and *zebra*. 2694 2695Dumping Messages and Routing Tables 2696^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2697 2698.. index:: dump bgp all PATH [INTERVAL] 2699.. clicmd:: dump bgp all PATH [INTERVAL] 2700 2701.. index:: dump bgp all-et PATH [INTERVAL] 2702.. clicmd:: dump bgp all-et PATH [INTERVAL] 2703 2704.. index:: no dump bgp all [PATH] [INTERVAL] 2705.. clicmd:: no dump bgp all [PATH] [INTERVAL] 2706 2707 Dump all BGP packet and events to `path` file. 2708 If `interval` is set, a new file will be created for echo `interval` of 2709 seconds. The path `path` can be set with date and time formatting 2710 (strftime). The type ‘all-et’ enables support for Extended Timestamp Header 2711 (:ref:`packet-binary-dump-format`). 2712 2713.. index:: dump bgp updates PATH [INTERVAL] 2714.. clicmd:: dump bgp updates PATH [INTERVAL] 2715 2716.. index:: dump bgp updates-et PATH [INTERVAL] 2717.. clicmd:: dump bgp updates-et PATH [INTERVAL] 2718 2719.. index:: no dump bgp updates [PATH] [INTERVAL] 2720.. clicmd:: no dump bgp updates [PATH] [INTERVAL] 2721 2722 Dump only BGP updates messages to `path` file. 2723 If `interval` is set, a new file will be created for echo `interval` of 2724 seconds. The path `path` can be set with date and time formatting 2725 (strftime). The type ‘updates-et’ enables support for Extended Timestamp 2726 Header (:ref:`packet-binary-dump-format`). 2727 2728.. index:: dump bgp routes-mrt PATH 2729.. clicmd:: dump bgp routes-mrt PATH 2730 2731.. index:: dump bgp routes-mrt PATH INTERVAL 2732.. clicmd:: dump bgp routes-mrt PATH INTERVAL 2733 2734.. index:: no dump bgp route-mrt [PATH] [INTERVAL] 2735.. clicmd:: no dump bgp route-mrt [PATH] [INTERVAL] 2736 2737 Dump whole BGP routing table to `path`. This is heavy process. The path 2738 `path` can be set with date and time formatting (strftime). If `interval` is 2739 set, a new file will be created for echo `interval` of seconds. 2740 2741 Note: the interval variable can also be set using hours and minutes: 04h20m00. 2742 2743 2744.. _bgp-other-commands: 2745 2746Other BGP Commands 2747------------------ 2748 2749The following are available in the top level *enable* mode: 2750 2751.. index:: clear bgp \* 2752.. clicmd:: clear bgp \* 2753 2754 Clear all peers. 2755 2756.. index:: clear bgp ipv4|ipv6 \* 2757.. clicmd:: clear bgp ipv4|ipv6 \* 2758 2759 Clear all peers with this address-family activated. 2760 2761.. index:: clear bgp ipv4|ipv6 unicast \* 2762.. clicmd:: clear bgp ipv4|ipv6 unicast \* 2763 2764 Clear all peers with this address-family and sub-address-family activated. 2765 2766.. index:: clear bgp ipv4|ipv6 PEER 2767.. clicmd:: clear bgp ipv4|ipv6 PEER 2768 2769 Clear peers with address of X.X.X.X and this address-family activated. 2770 2771.. index:: clear bgp ipv4|ipv6 unicast PEER 2772.. clicmd:: clear bgp ipv4|ipv6 unicast PEER 2773 2774 Clear peer with address of X.X.X.X and this address-family and sub-address-family activated. 2775 2776.. index:: clear bgp ipv4|ipv6 PEER soft|in|out 2777.. clicmd:: clear bgp ipv4|ipv6 PEER soft|in|out 2778 2779 Clear peer using soft reconfiguration in this address-family. 2780 2781.. index:: clear bgp ipv4|ipv6 unicast PEER soft|in|out 2782.. clicmd:: clear bgp ipv4|ipv6 unicast PEER soft|in|out 2783 2784 Clear peer using soft reconfiguration in this address-family and sub-address-family. 2785 2786The following are available in the ``router bgp`` mode: 2787 2788.. index:: write-quanta (1-64) 2789.. clicmd:: write-quanta (1-64) 2790 2791 BGP message Tx I/O is vectored. This means that multiple packets are written 2792 to the peer socket at the same time each I/O cycle, in order to minimize 2793 system call overhead. This value controls how many are written at a time. 2794 Under certain load conditions, reducing this value could make peer traffic 2795 less 'bursty'. In practice, leave this settings on the default (64) unless 2796 you truly know what you are doing. 2797 2798.. index:: read-quanta (1-10) 2799.. clicmd:: read-quanta (1-10) 2800 2801 Unlike Tx, BGP Rx traffic is not vectored. Packets are read off the wire one 2802 at a time in a loop. This setting controls how many iterations the loop runs 2803 for. As with write-quanta, it is best to leave this setting on the default. 2804 2805.. _bgp-displaying-bgp-information: 2806 2807Displaying BGP Information 2808========================== 2809 2810The following four commands display the IPv6 and IPv4 routing tables, depending 2811on whether or not the ``ip`` keyword is used. 2812Actually, :clicmd:`show ip bgp` command was used on older `Quagga` routing 2813daemon project, while :clicmd:`show bgp` command is the new format. The choice 2814has been done to keep old format with IPv4 routing table, while new format 2815displays IPv6 routing table. 2816 2817.. index:: show ip bgp [wide] 2818.. clicmd:: show ip bgp [wide] 2819 2820.. index:: show ip bgp A.B.C.D [wide] 2821.. clicmd:: show ip bgp A.B.C.D [wide] 2822 2823.. index:: show bgp [wide] 2824.. clicmd:: show bgp [wide] 2825 2826.. index:: show bgp X:X::X:X [wide] 2827.. clicmd:: show bgp X:X::X:X [wide] 2828 2829 These commands display BGP routes. When no route is specified, the default 2830 is to display all BGP routes. 2831 2832 :: 2833 2834 BGP table version is 0, local router ID is 10.1.1.1 2835 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal 2836 Origin codes: i - IGP, e - EGP, ? - incomplete 2837 2838 Network Next Hop Metric LocPrf Weight Path 2839 \*> 1.1.1.1/32 0.0.0.0 0 32768 i 2840 2841 Total number of prefixes 1 2842 2843 If _wide_ option is specified, then the prefix table's width is increased 2844 to fully display the prefix and the nexthop. 2845 2846 This is especially handy dealing with IPv6 prefixes and 2847 if :clicmd:`[no] bgp default show-nexthop-hostname` is enabled. 2848 2849Some other commands provide additional options for filtering the output. 2850 2851.. index:: show [ip] bgp regexp LINE 2852.. clicmd:: show [ip] bgp regexp LINE 2853 2854 This command displays BGP routes using AS path regular expression 2855 (:ref:`bgp-regular-expressions`). 2856 2857.. index:: show [ip] bgp summary 2858.. clicmd:: show [ip] bgp summary 2859 2860 Show a bgp peer summary for the specified address family. 2861 2862The old command structure :clicmd:`show ip bgp` may be removed in the future 2863and should no longer be used. In order to reach the other BGP routing tables 2864other than the IPv6 routing table given by :clicmd:`show bgp`, the new command 2865structure is extended with :clicmd:`show bgp [afi] [safi]`. 2866 2867.. index:: show bgp [afi] [safi] 2868.. clicmd:: show bgp [afi] [safi] 2869 2870.. index:: show bgp <ipv4|ipv6> <unicast|multicast|vpn|labeled-unicast> 2871.. clicmd:: show bgp <ipv4|ipv6> <unicast|multicast|vpn|labeled-unicast> 2872 2873 These commands display BGP routes for the specific routing table indicated by 2874 the selected afi and the selected safi. If no afi and no safi value is given, 2875 the command falls back to the default IPv6 routing table. 2876 For EVPN prefixes, you can display the full BGP table for this AFI/SAFI 2877 using the standard `show bgp [afi] [safi]` syntax. 2878 2879.. index:: show bgp l2vpn evpn route [type <macip|2|multicast|3|es|4|prefix|5>] 2880.. clicmd:: show bgp l2vpn evpn route [type <macip|2|multicast|3|es|4|prefix|5>] 2881 2882 Additionally, you can also filter this output by route type. 2883 2884.. index:: show bgp [afi] [safi] summary 2885.. clicmd:: show bgp [afi] [safi] summary 2886 2887 Show a bgp peer summary for the specified address family, and subsequent 2888 address-family. 2889 2890.. index:: show bgp [afi] [safi] summary failed [json] 2891.. clicmd:: show bgp [afi] [safi] summary failed [json] 2892 2893 Show a bgp peer summary for peers that are not succesfully exchanging routes 2894 for the specified address family, and subsequent address-family. 2895 2896.. index:: show bgp [afi] [safi] summary established [json] 2897.. clicmd:: show bgp [afi] [safi] summary established [json] 2898 2899 Show a bgp peer summary for peers that are succesfully exchanging routes 2900 for the specified address family, and subsequent address-family. 2901 2902.. index:: show bgp [afi] [safi] neighbor [PEER] 2903.. clicmd:: show bgp [afi] [safi] neighbor [PEER] 2904 2905 This command shows information on a specific BGP peer of the relevant 2906 afi and safi selected. 2907 2908.. index:: show bgp [afi] [safi] dampening dampened-paths 2909.. clicmd:: show bgp [afi] [safi] dampening dampened-paths 2910 2911 Display paths suppressed due to dampening of the selected afi and safi 2912 selected. 2913 2914.. index:: show bgp [afi] [safi] dampening flap-statistics 2915.. clicmd:: show bgp [afi] [safi] dampening flap-statistics 2916 2917 Display flap statistics of routes of the selected afi and safi selected. 2918 2919.. index:: show bgp [afi] [safi] statistics 2920.. clicmd:: show bgp [afi] [safi] statistics 2921 2922 Display statistics of routes of the selected afi and safi. 2923 2924.. index:: show bgp statistics-all 2925.. clicmd:: show bgp statistics-all 2926 2927 Display statistics of routes of all the afi and safi. 2928 2929.. _bgp-display-routes-by-community: 2930 2931Displaying Routes by Community Attribute 2932---------------------------------------- 2933 2934The following commands allow displaying routes based on their community 2935attribute. 2936 2937.. index:: show [ip] bgp <ipv4|ipv6> community 2938.. clicmd:: show [ip] bgp <ipv4|ipv6> community 2939 2940.. index:: show [ip] bgp <ipv4|ipv6> community COMMUNITY 2941.. clicmd:: show [ip] bgp <ipv4|ipv6> community COMMUNITY 2942 2943.. index:: show [ip] bgp <ipv4|ipv6> community COMMUNITY exact-match 2944.. clicmd:: show [ip] bgp <ipv4|ipv6> community COMMUNITY exact-match 2945 2946 These commands display BGP routes which have the community attribute. 2947 attribute. When ``COMMUNITY`` is specified, BGP routes that match that 2948 community are displayed. When `exact-match` is specified, it display only 2949 routes that have an exact match. 2950 2951.. index:: show [ip] bgp <ipv4|ipv6> community-list WORD 2952.. clicmd:: show [ip] bgp <ipv4|ipv6> community-list WORD 2953 2954.. index:: show [ip] bgp <ipv4|ipv6> community-list WORD exact-match 2955.. clicmd:: show [ip] bgp <ipv4|ipv6> community-list WORD exact-match 2956 2957 These commands display BGP routes for the address family specified that 2958 match the specified community list. When `exact-match` is specified, it 2959 displays only routes that have an exact match. 2960 2961.. _bgp-display-routes-by-lcommunity: 2962 2963Displaying Routes by Large Community Attribute 2964---------------------------------------------- 2965 2966The following commands allow displaying routes based on their 2967large community attribute. 2968 2969.. index:: show [ip] bgp <ipv4|ipv6> large-community 2970.. clicmd:: show [ip] bgp <ipv4|ipv6> large-community 2971 2972.. index:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY 2973.. clicmd:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY 2974 2975.. index:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY exact-match 2976.. clicmd:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY exact-match 2977 2978.. index:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY json 2979.. clicmd:: show [ip] bgp <ipv4|ipv6> large-community LARGE-COMMUNITY json 2980 2981 These commands display BGP routes which have the large community attribute. 2982 attribute. When ``LARGE-COMMUNITY`` is specified, BGP routes that match that 2983 large community are displayed. When `exact-match` is specified, it display 2984 only routes that have an exact match. When `json` is specified, it display 2985 routes in json format. 2986 2987.. index:: show [ip] bgp <ipv4|ipv6> large-community-list WORD 2988.. clicmd:: show [ip] bgp <ipv4|ipv6> large-community-list WORD 2989 2990.. index:: show [ip] bgp <ipv4|ipv6> large-community-list WORD exact-match 2991.. clicmd:: show [ip] bgp <ipv4|ipv6> large-community-list WORD exact-match 2992 2993.. index:: show [ip] bgp <ipv4|ipv6> large-community-list WORD json 2994.. clicmd:: show [ip] bgp <ipv4|ipv6> large-community-list WORD json 2995 2996 These commands display BGP routes for the address family specified that 2997 match the specified large community list. When `exact-match` is specified, 2998 it displays only routes that have an exact match. When `json` is specified, 2999 it display routes in json format. 3000 3001.. _bgp-display-routes-by-as-path: 3002 3003 3004Displaying Routes by AS Path 3005---------------------------- 3006 3007.. index:: show bgp ipv4|ipv6 regexp LINE 3008.. clicmd:: show bgp ipv4|ipv6 regexp LINE 3009 3010 This commands displays BGP routes that matches a regular 3011 expression `line` (:ref:`bgp-regular-expressions`). 3012 3013.. index:: show [ip] bgp ipv4 vpn 3014.. clicmd:: show [ip] bgp ipv4 vpn 3015 3016.. index:: show [ip] bgp ipv6 vpn 3017.. clicmd:: show [ip] bgp ipv6 vpn 3018 3019 Print active IPV4 or IPV6 routes advertised via the VPN SAFI. 3020 3021.. index:: show bgp ipv4 vpn summary 3022.. clicmd:: show bgp ipv4 vpn summary 3023 3024.. index:: show bgp ipv6 vpn summary 3025.. clicmd:: show bgp ipv6 vpn summary 3026 3027 Print a summary of neighbor connections for the specified AFI/SAFI combination. 3028 3029Displaying Update Group Information 3030----------------------------------- 3031 3032.. index:: show bgp update-groups SUBGROUP-ID [advertise-queue|advertised-routes|packet-queue] 3033.. clicmd:: show bgp update-groups [advertise-queue|advertised-routes|packet-queue] 3034 3035 Display Information about each individual update-group being used. 3036 If SUBGROUP-ID is specified only display about that particular group. If 3037 advertise-queue is specified the list of routes that need to be sent 3038 to the peers in the update-group is displayed, advertised-routes means 3039 the list of routes we have sent to the peers in the update-group and 3040 packet-queue specifies the list of packets in the queue to be sent. 3041 3042.. index:: show bgp update-groups statistics 3043.. clicmd:: show bgp update-groups statistics 3044 3045 Display Information about update-group events in FRR. 3046 3047.. _bgp-route-reflector: 3048 3049Route Reflector 3050=============== 3051 3052BGP routers connected inside the same AS through BGP belong to an internal 3053BGP session, or IBGP. In order to prevent routing table loops, IBGP does not 3054advertise IBGP-learned routes to other routers in the same session. As such, 3055IBGP requires a full mesh of all peers. For large networks, this quickly becomes 3056unscalable. Introducing route reflectors removes the need for the full-mesh. 3057 3058When route reflectors are configured, these will reflect the routes announced 3059by the peers configured as clients. A route reflector client is configured 3060with: 3061 3062.. index:: neighbor PEER route-reflector-client 3063.. clicmd:: neighbor PEER route-reflector-client 3064 3065.. index:: no neighbor PEER route-reflector-client 3066.. clicmd:: no neighbor PEER route-reflector-client 3067 3068To avoid single points of failure, multiple route reflectors can be configured. 3069 3070A cluster is a collection of route reflectors and their clients, and is used 3071by route reflectors to avoid looping. 3072 3073.. index:: bgp cluster-id A.B.C.D 3074.. clicmd:: bgp cluster-id A.B.C.D 3075 3076.. _routing-policy: 3077 3078Routing Policy 3079============== 3080 3081You can set different routing policy for a peer. For example, you can set 3082different filter for a peer. 3083 3084.. code-block:: frr 3085 3086 ! 3087 router bgp 1 view 1 3088 neighbor 10.0.0.1 remote-as 2 3089 address-family ipv4 unicast 3090 neighbor 10.0.0.1 distribute-list 1 in 3091 exit-address-family 3092 ! 3093 router bgp 1 view 2 3094 neighbor 10.0.0.1 remote-as 2 3095 address-family ipv4 unicast 3096 neighbor 10.0.0.1 distribute-list 2 in 3097 exit-address-family 3098 3099This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view 2. 3100When the update is inserted into view 1, distribute-list 1 is applied. On the 3101other hand, when the update is inserted into view 2, distribute-list 2 is 3102applied. 3103 3104 3105.. _bgp-regular-expressions: 3106 3107BGP Regular Expressions 3108======================= 3109 3110BGP regular expressions are based on :t:`POSIX 1003.2` regular expressions. The 3111following description is just a quick subset of the POSIX regular expressions. 3112 3113 3114.\* 3115 Matches any single character. 3116 3117\* 3118 Matches 0 or more occurrences of pattern. 3119 3120\+ 3121 Matches 1 or more occurrences of pattern. 3122 3123? 3124 Match 0 or 1 occurrences of pattern. 3125 3126^ 3127 Matches the beginning of the line. 3128 3129$ 3130 Matches the end of the line. 3131 3132_ 3133 The ``_`` character has special meanings in BGP regular expressions. It 3134 matches to space and comma , and AS set delimiter ``{`` and ``}`` and AS 3135 confederation delimiter ``(`` and ``)``. And it also matches to the 3136 beginning of the line and the end of the line. So ``_`` can be used for AS 3137 value boundaries match. This character technically evaluates to 3138 ``(^|[,{}()]|$)``. 3139 3140 3141.. _bgp-configuration-examples: 3142 3143Miscellaneous Configuration Examples 3144==================================== 3145 3146Example of a session to an upstream, advertising only one prefix to it. 3147 3148.. code-block:: frr 3149 3150 router bgp 64512 3151 bgp router-id 10.236.87.1 3152 neighbor upstream peer-group 3153 neighbor upstream remote-as 64515 3154 neighbor upstream capability dynamic 3155 neighbor 10.1.1.1 peer-group upstream 3156 neighbor 10.1.1.1 description ACME ISP 3157 3158 address-family ipv4 unicast 3159 network 10.236.87.0/24 3160 neighbor upstream prefix-list pl-allowed-adv out 3161 exit-address-family 3162 ! 3163 ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25 3164 ip prefix-list pl-allowed-adv seq 10 deny any 3165 3166A more complex example including upstream, peer and customer sessions 3167advertising global prefixes and NO_EXPORT prefixes and providing actions for 3168customer routes based on community values. Extensive use is made of route-maps 3169and the 'call' feature to support selective advertising of prefixes. This 3170example is intended as guidance only, it has NOT been tested and almost 3171certainly contains silly mistakes, if not serious flaws. 3172 3173.. code-block:: frr 3174 3175 router bgp 64512 3176 bgp router-id 10.236.87.1 3177 neighbor upstream capability dynamic 3178 neighbor cust capability dynamic 3179 neighbor peer capability dynamic 3180 neighbor 10.1.1.1 remote-as 64515 3181 neighbor 10.1.1.1 peer-group upstream 3182 neighbor 10.2.1.1 remote-as 64516 3183 neighbor 10.2.1.1 peer-group upstream 3184 neighbor 10.3.1.1 remote-as 64517 3185 neighbor 10.3.1.1 peer-group cust-default 3186 neighbor 10.3.1.1 description customer1 3187 neighbor 10.4.1.1 remote-as 64518 3188 neighbor 10.4.1.1 peer-group cust 3189 neighbor 10.4.1.1 description customer2 3190 neighbor 10.5.1.1 remote-as 64519 3191 neighbor 10.5.1.1 peer-group peer 3192 neighbor 10.5.1.1 description peer AS 1 3193 neighbor 10.6.1.1 remote-as 64520 3194 neighbor 10.6.1.1 peer-group peer 3195 neighbor 10.6.1.1 description peer AS 2 3196 3197 address-family ipv4 unicast 3198 network 10.123.456.0/24 3199 network 10.123.456.128/25 route-map rm-no-export 3200 neighbor upstream route-map rm-upstream-out out 3201 neighbor cust route-map rm-cust-in in 3202 neighbor cust route-map rm-cust-out out 3203 neighbor cust send-community both 3204 neighbor peer route-map rm-peer-in in 3205 neighbor peer route-map rm-peer-out out 3206 neighbor peer send-community both 3207 neighbor 10.3.1.1 prefix-list pl-cust1-network in 3208 neighbor 10.4.1.1 prefix-list pl-cust2-network in 3209 neighbor 10.5.1.1 prefix-list pl-peer1-network in 3210 neighbor 10.6.1.1 prefix-list pl-peer2-network in 3211 exit-address-family 3212 ! 3213 ip prefix-list pl-default permit 0.0.0.0/0 3214 ! 3215 ip prefix-list pl-upstream-peers permit 10.1.1.1/32 3216 ip prefix-list pl-upstream-peers permit 10.2.1.1/32 3217 ! 3218 ip prefix-list pl-cust1-network permit 10.3.1.0/24 3219 ip prefix-list pl-cust1-network permit 10.3.2.0/24 3220 ! 3221 ip prefix-list pl-cust2-network permit 10.4.1.0/24 3222 ! 3223 ip prefix-list pl-peer1-network permit 10.5.1.0/24 3224 ip prefix-list pl-peer1-network permit 10.5.2.0/24 3225 ip prefix-list pl-peer1-network permit 192.168.0.0/24 3226 ! 3227 ip prefix-list pl-peer2-network permit 10.6.1.0/24 3228 ip prefix-list pl-peer2-network permit 10.6.2.0/24 3229 ip prefix-list pl-peer2-network permit 192.168.1.0/24 3230 ip prefix-list pl-peer2-network permit 192.168.2.0/24 3231 ip prefix-list pl-peer2-network permit 172.16.1/24 3232 ! 3233 bgp as-path access-list asp-own-as permit ^$ 3234 bgp as-path access-list asp-own-as permit _64512_ 3235 ! 3236 ! ################################################################# 3237 ! Match communities we provide actions for, on routes receives from 3238 ! customers. Communities values of <our-ASN>:X, with X, have actions: 3239 ! 3240 ! 100 - blackhole the prefix 3241 ! 200 - set no_export 3242 ! 300 - advertise only to other customers 3243 ! 400 - advertise only to upstreams 3244 ! 500 - set no_export when advertising to upstreams 3245 ! 2X00 - set local_preference to X00 3246 ! 3247 ! blackhole the prefix of the route 3248 bgp community-list standard cm-blackhole permit 64512:100 3249 ! 3250 ! set no-export community before advertising 3251 bgp community-list standard cm-set-no-export permit 64512:200 3252 ! 3253 ! advertise only to other customers 3254 bgp community-list standard cm-cust-only permit 64512:300 3255 ! 3256 ! advertise only to upstreams 3257 bgp community-list standard cm-upstream-only permit 64512:400 3258 ! 3259 ! advertise to upstreams with no-export 3260 bgp community-list standard cm-upstream-noexport permit 64512:500 3261 ! 3262 ! set local-pref to least significant 3 digits of the community 3263 bgp community-list standard cm-prefmod-100 permit 64512:2100 3264 bgp community-list standard cm-prefmod-200 permit 64512:2200 3265 bgp community-list standard cm-prefmod-300 permit 64512:2300 3266 bgp community-list standard cm-prefmod-400 permit 64512:2400 3267 bgp community-list expanded cme-prefmod-range permit 64512:2... 3268 ! 3269 ! Informational communities 3270 ! 3271 ! 3000 - learned from upstream 3272 ! 3100 - learned from customer 3273 ! 3200 - learned from peer 3274 ! 3275 bgp community-list standard cm-learnt-upstream permit 64512:3000 3276 bgp community-list standard cm-learnt-cust permit 64512:3100 3277 bgp community-list standard cm-learnt-peer permit 64512:3200 3278 ! 3279 ! ################################################################### 3280 ! Utility route-maps 3281 ! 3282 ! These utility route-maps generally should not used to permit/deny 3283 ! routes, i.e. they do not have meaning as filters, and hence probably 3284 ! should be used with 'on-match next'. These all finish with an empty 3285 ! permit entry so as not interfere with processing in the caller. 3286 ! 3287 route-map rm-no-export permit 10 3288 set community additive no-export 3289 route-map rm-no-export permit 20 3290 ! 3291 route-map rm-blackhole permit 10 3292 description blackhole, up-pref and ensure it cannot escape this AS 3293 set ip next-hop 127.0.0.1 3294 set local-preference 10 3295 set community additive no-export 3296 route-map rm-blackhole permit 20 3297 ! 3298 ! Set local-pref as requested 3299 route-map rm-prefmod permit 10 3300 match community cm-prefmod-100 3301 set local-preference 100 3302 route-map rm-prefmod permit 20 3303 match community cm-prefmod-200 3304 set local-preference 200 3305 route-map rm-prefmod permit 30 3306 match community cm-prefmod-300 3307 set local-preference 300 3308 route-map rm-prefmod permit 40 3309 match community cm-prefmod-400 3310 set local-preference 400 3311 route-map rm-prefmod permit 50 3312 ! 3313 ! Community actions to take on receipt of route. 3314 route-map rm-community-in permit 10 3315 description check for blackholing, no point continuing if it matches. 3316 match community cm-blackhole 3317 call rm-blackhole 3318 route-map rm-community-in permit 20 3319 match community cm-set-no-export 3320 call rm-no-export 3321 on-match next 3322 route-map rm-community-in permit 30 3323 match community cme-prefmod-range 3324 call rm-prefmod 3325 route-map rm-community-in permit 40 3326 ! 3327 ! ##################################################################### 3328 ! Community actions to take when advertising a route. 3329 ! These are filtering route-maps, 3330 ! 3331 ! Deny customer routes to upstream with cust-only set. 3332 route-map rm-community-filt-to-upstream deny 10 3333 match community cm-learnt-cust 3334 match community cm-cust-only 3335 route-map rm-community-filt-to-upstream permit 20 3336 ! 3337 ! Deny customer routes to other customers with upstream-only set. 3338 route-map rm-community-filt-to-cust deny 10 3339 match community cm-learnt-cust 3340 match community cm-upstream-only 3341 route-map rm-community-filt-to-cust permit 20 3342 ! 3343 ! ################################################################### 3344 ! The top-level route-maps applied to sessions. Further entries could 3345 ! be added obviously.. 3346 ! 3347 ! Customers 3348 route-map rm-cust-in permit 10 3349 call rm-community-in 3350 on-match next 3351 route-map rm-cust-in permit 20 3352 set community additive 64512:3100 3353 route-map rm-cust-in permit 30 3354 ! 3355 route-map rm-cust-out permit 10 3356 call rm-community-filt-to-cust 3357 on-match next 3358 route-map rm-cust-out permit 20 3359 ! 3360 ! Upstream transit ASes 3361 route-map rm-upstream-out permit 10 3362 description filter customer prefixes which are marked cust-only 3363 call rm-community-filt-to-upstream 3364 on-match next 3365 route-map rm-upstream-out permit 20 3366 description only customer routes are provided to upstreams/peers 3367 match community cm-learnt-cust 3368 ! 3369 ! Peer ASes 3370 ! outbound policy is same as for upstream 3371 route-map rm-peer-out permit 10 3372 call rm-upstream-out 3373 ! 3374 route-map rm-peer-in permit 10 3375 set community additive 64512:3200 3376 3377 3378Example of how to set up a 6-Bone connection. 3379 3380.. code-block:: frr 3381 3382 ! bgpd configuration 3383 ! ================== 3384 ! 3385 ! MP-BGP configuration 3386 ! 3387 router bgp 7675 3388 bgp router-id 10.0.0.1 3389 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as `as-number` 3390 ! 3391 address-family ipv6 3392 network 3ffe:506::/32 3393 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate 3394 neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out 3395 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as `as-number` 3396 neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out 3397 exit-address-family 3398 ! 3399 ipv6 access-list all permit any 3400 ! 3401 ! Set output nexthop address. 3402 ! 3403 route-map set-nexthop permit 10 3404 match ipv6 address all 3405 set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225 3406 set ipv6 nexthop local fe80::2c0:4fff:fe68:a225 3407 ! 3408 log file bgpd.log 3409 ! 3410 3411 3412.. include:: routeserver.rst 3413 3414.. include:: rpki.rst 3415 3416.. include:: wecmp_linkbw.rst 3417 3418.. include:: flowspec.rst 3419 3420.. [#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) 3421.. [bgp-route-osci-cond] McPherson, D. and Gill, V. and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", IETF RFC3345 3422.. [stable-flexible-ibgp] Flavel, A. and M. Roughan, "Stable and flexible iBGP", ACM SIGCOMM 2009 3423.. [ibgp-correctness] Griffin, T. and G. Wilfong, "On the correctness of IBGP configuration", ACM SIGCOMM 2002 3424