BGP & Internet Routing Books
BGP Articles, Links, Whitepapers
BGP Technical Presentations
BGP Security, ISP Core Security
BGP related Mailinglists
BGP Vendors (hardware)
IETF Protocol Reference (RFC)
|
BGP Protocol (IETF RFCs)
Home
-
About
-
Contact
Cisco IOS BGP Commands
JunOS BGP Configuration Guidelines
JunOS BGP Configuration Statements
Quagga Routing Documentation
OpenBGPD Manual Pages
Understanding IP Addressing
RIPE NCC ASN32 FAQ
BGP Large Communities
IPv4 Netmask Table
IPv4 CIDR Prefix Sizes
RIPE IPv4 CIDR Chart
RIPE IPv6 CIDR Chart
The RFC Archive
The
Border Gateway Protocol
(BGP)
is the routing
protocol used to exchange routing information across the Internet. It makes
it possible for ISPs to connect to each other and for end-users to connect
to more than one ISP.
BGP
is the only protocol that is
designed to deal with a network of the Internet's size, and the only
protocol that can deal well with having multiple connections to unrelated
routing domains.
BGP
first became an Internet standard in 1989 and was originally
defined in
RFC 1105
. The current version,
BGP4
was adopted in 1995 and is defined in
RFC 4271
. An overview of all BGP RFCs can be
found in the
BGP RFC
section on this
website.
BGP
has proven to be scalable, stable and provides the mechanisms
needed to support complex routing policies. When people talk about
"BGP"
today, they implicitly mean
BGP4
. There is no need to
specify the -4 version number because no one uses earlier versions, and very
few vendors even still support them.
The
Border Gateway Protocol
is an
inter-Autonomous
System routing protocol.
The primary function of a
BGP
speaking system is to exchange network reachability information with other
BGP
systems. This network reachability information includes
information on the list of
Autonomous Systems
(AS) that
reachability information traverses. This information is sufficient to
construct a graph of AS connectivity from which routing loops may be pruned
and some policy decisions at the AS level may be enforced.
BGP4
provides a set of mechanisms for supporting
Classless
Inter-Domain Routing
(
CIDR
) defined in
RFC 4632
. These mechanisms include support for
advertising a set of destinations as an
IP prefix
and eliminating the concept of network
"class" within
BGP.
BGP version 4
also introduces
mechanisms which allow aggregation of routes, including aggregation of AS
paths.
Routing information exchanged via
BGP
supports only the
destination-based forwarding paradigm, which assumes that a router forwards
a packet based solely on the destination address carried in the IP header of
the packet. This, in turn, reflects the set of policy decisions that can
(and can not) be enforced using
BGP
.
BGP
can support only the
policies conforming to the destination-based forwarding paradigm.
A unique AS number (ASN) is allocated to each AS for use in
BGP
routing. The numbers are
assigned
by IANA and the Regional Internet Registries (RIR), the same authorities
that allocate IP addresses. There are public numbers, which may be used on
the Internet and range from 1 to 64511, and private numbers from 64512 to
65535, which can be used within an organization.
Most
AS numbers
are currently 16-bit integers, but deployment of
32-bit AS Numbers (4-Byte ASN) is starting. Why? Because of expected ASN
shortage in the 16-bit range around the year 2010. In
RFC
4893
(May 2007), some new extensions to BGP are described to carry the
Autonomous System number as a four-octet entity. In
RFC
5668
(Oct 2009), a new type of a BGP extended community which carries
the 4-octet Autonomous System (AS) number, is defined.
Whether you are completely new to the
Border Gateway Protocol
or are
an experienced routing professional, by reading the
BGP Articles & Whitepapers
and
BGP Presentations
on this website you will
certainly learn a lot about the workings of this important technology. New
is a dedicated section on
BGP Security
.
Related Reading
Report from the IAB Workshop on Routing and Addressing
© 2002-2023
BGP4.AS
. All rights reserved.
Page last modified on Mon 15 October 2018 04:54:31 CET
BORDER GATEWAY PROTOCOL
