Border 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 systems.
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
- The path with the shortest AS path attribute
- 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
rde med 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 (IBGP)
- The path with the lowest local weight is
- If “
rde route-age 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 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
information on the boot process and enabling daemons.
starts up, it reads settings from a
configuration file, typically
process can be controlled
using the bgpctl(8)
The options are as follows:
bgpd to do
at startup when the demote functionality is
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
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
- Use file as the configuration file,
instead of the default
- Configtest mode. Only check the configuration file for validity.
- Produce more verbose output.
bgpd configuration file
bgpd control socket
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,
Error Handling for Optional
Transitive BGP Attributes,
MRT routing information export
M. Chen, and A.
Suryanarayana, Subcodes for BGP Finite State Machine
Error, RFC 6608, May
program first appeared in