bgpd — Border Gateway Protocol (BGP) routing daemon

Description

bgpd is a Border Gateway Protocol (BGP) daemon which manages the network routing tables. Its main
purpose is to exchange information concerning "network reachability" with other BGP systems. bgpd uses
the Border Gateway Protocol, Version 4, as described in RFC 4271.

BGP is an exterior gateway protocol using a multiple step decision process to find the best path.
Advanced filtering can be used to influence the route decision for traffic engineering. The session
engine of bgpd is responsible for maintaining the TCP session with each neighbor. Updates are passed to
the Route Decision Engine (RDE) where the paths are filtered and used to compute a Routing Information
Base (RIB). The parent process is responsible for keeping the RIB in sync with the kernel routing table.

The route decision process selects the best path by evaluating all paths to the same destination. The
decision process continues to the next step if paths have equal attributes. Paths that are less
preferred are taken out of consideration until there is only one path left.

1. All paths with errors or loops are not eligible.

2. Paths with an unreachable nexthop are not eligible. After this step all remaining paths are
valid.

3. The path with the highest LOCAL_PREF is selected.

4. The path with the shortest ASpath attribute is selected.

5. The ORIGIN attribute is compared. The order is IGP before EGP before incomplete origins.

6. The path with the lowest MULTI_EXIT_DISC metric is selected. Normally, this value is only
considered when choosing between multiple routes sent by the same neighbouring AS. However, if
“rdemedcomparealways” is set in the configuration, the metric is compared for routes sent by
any AS.

7. Comparison of the BGP session type. Paths learned over an external (EBGP) session are preferred
over those learned via an internal (IBGP) session.

8. The path with the highest local weight is selected.

9. If “rderoute-ageevaluate” is set then the oldest path is selected.

10. The path coming from the neighbor with the lowest BGPID wins. If the ORIGINATOR_ID attribute is
present, that value will be used in the comparison instead.

11. The path with the shortest CLUSTER_LIST attribute is selected. If it is not present then a
length of 0 is used in the comparison.

12. The path coming from the peer with the lowest IP address is selected. IPv4 sessions will be
preferred over IPv6 ones.

Attributes set by filters can be used to tip the decision process to prefer particular paths over others.
This can be achieved by changing the localpref, med, or weight attributes. AS path prepending or
changing the med or origin attribute can be used to influence the routing behaviour on remote systems.

To have bgpd enabled at boot time, use “rcctl enable bgpd”, which sets

bgpd_flags=""

in rc.conf.local(8).

When bgpd starts up, it reads settings from a configuration file, typically bgpd.conf(5). A running bgpd
process can be controlled using the bgpctl(8) utility.

The options are as follows:

-c Force bgpd to do carp(4) demotion at startup when the demote functionality is used.
Normally, bgpd will only do demotion at startup when the demotion counter for the group in
question is already greater than 0. bgpd will start handling demotion after all sessions
with demotion configured for the given group have been successfully established. At system
startup, rc(8) has the demotion counter for the group carp increased until after bgpd is
started, so this option should not be used in rc.conf(8).

-Dmacro=value
Define macro to be set to value on the command line. Overrides the definition of macro in
the configuration file.

-d Do not daemonize. If this option is specified, bgpd will run in the foreground and log to
stderr.

-ffile Use file as the configuration file, instead of the default /etc/bgpd.conf.

-n Configtest mode. Only check the configuration file for validity.

-v Produce more verbose output.

-V Show the version and exit.

Files

/etc/bgpd.conf                     Default bgpd configuration file.
       /run/openbgpd/bgpd.sock.<rdomain>  Default bgpd control socket, where <rdomain> is the routing domain  in
                                          which bgpd has been started.

History

       The bgpd program first appeared in OpenBSD 3.5.

Debian                                          January 17, 2025                                         BGPD(8)

Name

       bgpd — Border Gateway Protocol (BGP) routing daemon

Standards

BGPCommunitiesAttribute, RFC 1997, August 1996.

       ProtectionofBGPSessionsviatheTCPMD5SignatureOption, RFC 2385, August 1998.

       UseofBGP-4MultiprotocolExtensionsforIPv6Inter-DomainRouting, RFC 2545, March 1999.

       RouteRefreshCapabilityforBGP-4, RFC 2918, September 2000.

       NOPEERCommunityforBorderGatewayProtocol(BGP)RouteScopeControl, RFC 3765, April 2004.

       ABorderGatewayProtocol4(BGP-4), RFC 4271, January 2006.

       BGPExtendedCommunitiesAttribute, RFC 4360, February 2006.

       BGP/MPLSIPVirtualPrivateNetworks(VPNs), RFC 4364, February 2006.

       BGPRouteReflection:AnAlternativetoFullMeshInternalBGP(IBGP), RFC 4456, April 2006.

       SubcodesforBGPCeaseNotificationMessage, RFC 4486, April 2006.

       GracefulRestartMechanismforBGP, RFC 4724, January 2007.

       MultiprotocolExtensionsforBGP-4, RFC 4760, January 2007.

       TheGeneralizedTTLSecurityMechanism(GTSM), RFC 5082, October 2007.

       CapabilitiesAdvertisementwithBGP-4, RFC 5492, February 2009.

       4-OctetASSpecificBGPExtendedCommunity, RFC 5668, October 2009.

       Autonomous-System-WideUniqueBGPIdentifierforBGP-4, RFC 6286, June 2011.

       SubcodesforBGPFiniteStateMachineError, RFC 6608, May 2012.

       BGPSupportforFour-OctetAutonomousSystem(AS)NumberSpace, RFC 6793, Dec 2012.

       RevisedErrorHandlingforBGPUPDATEMessages, RFC 7606, August 2015.

       Multi-ThreadedRoutingToolkit(MRT)RoutingInformationExportFormat, RFC 6396, October 2011.

       SubcodesforBGPFiniteStateMachineError, RFC 6608, May 2012.

       EnhancedRouteRefreshCapabilityforBGP-4, RFC 7313, July 2014.

       CodificationofAS0Processing, RFC 7607, August 2015.

       AdvertisementofMultiplePathsinBGP, RFC 7911, July 2016.

       InternetExchangeBGPRouteServer, RFC 7947, September 2016.

       Multi-ThreadedRoutingToolkit(MRT)RoutingInformationExportFormatwithBGPAdditionalPathExtensions, RFC 8050, May 2017.

       BGPLargeCommunitiesAttribute, RFC 8092, February 2017.

       BGPPrefixOriginValidationStateExtendedCommunity, RFC 8097, March 2017.

       BGPAdministrativeShutdownCommunication, RFC 8203, July 2017.

       TheResourcePublicKeyInfrastructure(RPKI)toRouterProtocol,Version1, RFC 8210, September 2017.

       DefaultExternalBGP(EBGP)RoutePropagationBehaviorwithoutPolicies, RFC 8212, July 2017.

       GracefulBGPSessionShutdown, RFC 8326, March 2018.

       NotificationMessageSupportforBGPGracefulRestart, RFC 8538, March 2019.

       ExtendedMessageSupportforBGP, RFC 8654, October 2019.

       AdvertisingIPv4NetworkLayerReachabilityInformation(NLRI)withanIPv6NextHop, RFC 8950,  November
       2020.

       DisseminationofFlowSpecificationRules, RFC 8955, December 2020.

       DisseminationofFlowSpecificationRulesforIPv6, RFC 8956, December 2020.

       ExtendedOptionalParametersLengthforBGPOPENMessage, RFC 9072, July 2021.

       RouteLeakPreventionandDetectionUsingRolesinUPDATEandOPENMessages, RFC 9234, May 2022.

       BorderGatewayProtocol4(BGP-4)SendHoldTimer, RFC 9687, November 2024.

       BGPAS_PATHVerificationBasedonResourcePublicKeyInfrastructure(RPKI)AutonomousSystemProviderAuthorization(ASPA)Objects, draft-ietf-sidrops-aspa-verification, October 2022.