Gateway Protocol daemon
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
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
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.
- All paths with errors or loops are not eligible.
- Paths with an unreachable nexthop are not eligible. After
this step all remaining paths are valid.
- The path with the highest
LOCAL_PREF is selected.
- The path with the shortest AS
path attribute is selected.
- The ORIGIN attribute is
compared. The order is IGP before EGP before incomplete origins.
- 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 “
compare always” is set in the configuration, the metric is
compared for routes sent by any AS.
- Comparison of the BGP session type. Paths learned over an
external (EBGP) session are preferred over those learned via an internal
- The path with the lowest local
weight is selected.
- If “
evaluate” is set then the oldest path is selected.
- The path coming from the neighbor with the lowest
BGP ID wins. If the
ORIGINATOR_ID attribute is present that value
will be used in the comparison instead.
- 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.
- The path coming from the peer with the lowest IP address
is selected. IPv4 sessions will be preferred over IPv6 ones.
- In case of locally announced prefixes
bgpd will prefer statically set prefixes over
dynamically inserted 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
attributes. AS path prepending or changing
attribute can be used to influence the routing behaviour on remote systems.
is usually started at boot time, and can be
enabled by setting the following in
for more information
on the boot process and enabling daemons.
starts up, it reads settings from a
configuration file, typically
. A running
process can be controlled using the
The options are as follows:
- 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
- Define macro to be set to
value on the command line. Overrides the
definition of macro in the configuration
- Do not daemonize. If this option is specified,
bgpd will run in the foreground and log to
- Use file as the
configuration file, instead of the default
- Configtest mode. Only check the configuration file for
- Produce more verbose output.
- default bgpd configuration
- default bgpd control
P. Traina, and T. Li,
BGP Communities Attribute, RFC
1997, August 1996.
Protection of BGP Sessions via the TCP MD5 Signature
Option, RFC 2385, August
P. Marques and
F. Dupont, Use of BGP-4
Multiprotocol Extensions for IPv6 Inter-Domain Routing,
RFC 2545, March 1999.
Route Refresh Capability for BGP-4,
RFC 2918, September
NOPEER Community for Border Gateway Protocol (BGP) Route
Scope Control, RFC 3765,
T. Li, and S. Hares,
A Border Gateway Protocol 4 (BGP-4),
RFC 4271, January
D. Tappan, and Y. Rekhter,
BGP Extended Communities Attribute,
RFC 4360, February
E. Rosen and
Y. Rekhter, BGP/MPLS IP Virtual
Private Networks (VPNs), RFC 4364,
E. Chen, and R. Chandra,
BGP Route Reflection: An Alternative to Full Mesh Internal
BGP (IBGP), RFC 4456, April
E. Chen and
V. Gillet, Subcodes for BGP Cease
Notification Message, RFC 4486,
R. Chandra, D. Katz, and
Y. Rekhter, Multiprotocol
Extensions for BGP-4, RFC 4760,
Q. Vohra and
E. Chen, BGP Support for Four-octet
AS Number Space, RFC 4893,
J. Heasley, D. Meyer,
P. Savola, and C. Pignatoro,
The Generalized TTL Security Mechanism (GTSM),
RFC 5082, October
J. Scudder and
R. Chandra, Capabilities
Advertisement with BGP-4, RFC 5492,
J. Scudder, P. Mohapatra,
and K. Patel, Revised Error
Handling for BGP UPDATE Messages, RFC 7606,
R. Bush, H. Schiller, and
K. Patel, Codification of AS 0
Processing, RFC 7607, August
MRT routing information export
M. Chen, and A.
Suryanarayana, Subcodes for BGP Finite State Machine
Error, RFC 6608, May
J. Snijders, K. Patel,
I. Bagdonas, and N.
Hilliard, BGP Large Communities Attribute,
RFC 8092, February
J. Heitz, and J. Scudder,
BGP Administrative Shutdown Communication,
K. Patel, J. Scudder,
D. Ward, and R. Bush,
BGP Prefix Origin Validation State Extended
Community, RFC 8097, March
program first appeared in