HELSINKI UNIVERSITY OF TECHNOLOGY

Laboratory of Telecommunication Technology

Licentiate course seminar, October 1996
Philippe Rua

INTER-DOMAIN ROUTING PROTOCOLS: EGP AND BGP.

Abstract

This paper presents two Internet protocols used in inter-domain routing: the Exterior
Gateway Protocol (EGP) and the Border Gateway Protocol (BGP).
When it became necessary to split the Internet into several domains, a specific solution was
also required in order to exchange global internet routing information between the domains.
After introducing some concepts used in inter-domain routing, this paper gives an overview
of the first inter-domain routing protocol to be used in the Internet, EGP, and explains its
limitations.
This paper then reviews BGP-3, a successor of EGP, and shows how the problems
encountered with EGP were addressed. The new requirements imposed by the development of
the Internet are also presented.

Table of Contents

1. Introduction
1.1 The Initial Problem.
1.2 An Evolving Solution.
2. Some Concepts Used in Inter-Domain Routing
3. The Exterior Gateway Protocol (EGP)
3.1 EGP Overview.
3.2 Some Interesting Details.
3.3 The Limitations of EGP.
4. The Border Gateway Protocol (BGP-3)
4.1 Main Differences With EGP.
4.2 The BGP Messages.
4.3 The Path Attributes.
4.4 UPDATE Message Handling.
5. Conclusions
Acronyms
References

1
 1. Introduction

1.1 The Initial Problem.

In the early 1980s, the Internet was a single network domain to which hosts and networks
were added in a relatively unstructured way. This growth required the addition of new routers
(then called gateways) participating in the Gateway-to-Gateway Protocol, the routing protocol
used at the time. Some problems became apparent:
• the overhead of the routing algorithm was becoming excessively large, not only because
of the increased size of the routing table but also because of the additional traffic
generated;
• the task of maintaining the routing system as whole was becoming almost impossible
because it included many heterogeneous routers administered by different people.
References: [1], [2], [3], [16] pp157-158.

1.2 An Evolving Solution.

As a consequence, the Internet Engineering Task Force (IETF) made the decision to split the
Internet into separate domains, or autonomous systems in the EGP/BGP parlance, and to
define a specific interface for the exchange of routing information between the domains: an
inter-domain routing protocol.
With this architecture, the choices made within one domain have less impact on the other
domains. For example the different domains can freely use any “interior" routing protocol
(such as RIP or OSPF). Also, inside a domain, the internal routing protocol overhead
generated by the handling of routes to networks in other domains can be reduced or even
eliminated: some or all external route announcements can be filtered out at the domain
border. The traffic to these destinations is then handled with the default route mechanism at
the cost of a possible sub-optimal routing.
The creation of a distinct protocol for inter-domain routing can be justified. Interior and
exterior routing protocols have some very different constraints to address. An interior routing
protocol is primarily concerned with routing efficiency whereas an exterior routing protocol
has to provide mechanisms for controlling the sharing of resources, for fault isolation and for
scaling.
Over the years several inter-domain routing protocols have been proposed as Requests For
Comments. (See Fig. 1.) This situation reflects the changing requirements linked to the
development of the Internet.

82 84 89 90 91 94 95 year
¶¶¿¶¾¿¶¶¿¾¶¿¶¶¿¶¶¿¶¶¿¶¶¿¶¾¿¶¾¿¶¾¿¶¶¿¶¶¿¶¾¿¶¾¿¶¶¿¶¶
· EGP(S) · · BGP-3(DS) · BGP-4(DS)
EGP(DS) · BGP-2(PS) BGP-4(PS)
BGP-1(E)

Fig. 1: Main RFC publications for EGP and BGP.

RFC status - E: Experimental, PS: Proposed Standard
DS: Draft Standard, S: Standard

The first of these protocols was EGP. Its successor, BGP, builds on the experience gained
with EGP. BGP is currently used in the Internet, but it is not yet a "real" standard. It has been

2
recycled once, back to the "proposed standard" status. The reason of the delay between BGP-
3 and BGP-4 is the introduction of the Classless Inter-Domain Routing (CIDR), a
consequence of the exponential growth of the Internet. The differences between the various
versions of BGP are detailed in [13].
Another recent protocol, the Inter-Domain Policy Routing protocol (IDPR), is not described
in this paper.
References: [1], [3], [13], [17].

2. Some Concepts Used in Inter-Domain Routing

These concepts are common to EGP and BGP, the examples refer to Fig 2.
• An autonomous system (AS) is a set of routers and networks under the same
administration, where all the elements are "internally connected". In other words, between
any two elements of the AS there is a path using only elements of the AS.
In EGP and BGP, each AS is identified by a 16-bit number.
• Inside an AS, the routing tables are maintained by one Internal Gateway Protocol (IGP),
for example RIP or OSPF. The information about external networks is only acquired
through the inter-domain routing protocol and injected into the IGP.
• Two routers are exterior neighbours if they each have an interface to a common network
and they belong to different autonomous systems, e.g.; B and C, or A and F. They can also
be connected by a point-to-point link.
• A router is a border router if it has at least an exterior neighbour, e.g.: A, B, …,G. The
inter-domain protocol runs on the border routers.
• Two routers are interior neighbours if they are border routers in the same autonomous
system. They may be connected indirectly through several networks, e.g.: A and B.

Fig. 2: Inter-Domain Routing Concepts.

References: [1], [2], [16].

3
 3. The Exterior Gateway Protocol (EGP)

EGP is the first Inter-Domain Routing protocol which has been used in Internet. It is to be
noted that EGP is now considered as an "historic" standard, and therefore should not be used
anymore. This paper therefore only presents an overview of EGP and explains its limitations.
A detailed description can be found in the official documents defining the protocol [1], [2]
and [4].

3.1 EGP Overview.

At the time the Internet was to be split into several autonomous systems, the "natural"
division was a strict 2-level hierarchy, where one of the autonomous systems was much
bigger than the others and played a special role. This "core" AS was made of the ARPANET
and SATNET backbones. The others autonomous systems were "stub" regional networks only
linked to the core. (See Fig. 3.)

Fig. 3: The Internet topology according to EGP.

In line with this situation, one basic assumption in EGP is that the ASs in the Internet would
remain organised as a tree structure. As there are no cycles in this topology, the protocol has
no provision to carry the information that would be needed to avoid routing loops. Another
property of this topology is that there is only one route -- at the inter-domain level -- between
any two ASs, hence there is no defined mechanism for the selection between multiple routes
to the same destination.
EGP external neighbours exchange network reachability information: which networks can be
reached through each external neighbour. Reachable destinations are advertised inside the
AS, using the IGP. There is no specific EGP-defined communication between internal
neighbours.
A first-hop address and an arbitrary metric called "distance" is also carried (0-255). Each AS
can manipulate this metric freely: EGP only specifies that 255 represents an unreachable
destination. This "distance" is mostly used to specify a local preference for some route. For
example, if two ASs are directly connected by a main link and a backup link, the destinations
can be advertised with a higher "distance" through the backup link, hence this link would be
used only if the main link fails.
The actual operation of EGP is composed of three separate procedures, the times indicated
inside parenthesis are just typical values and are not part of the protocol:
• Neighbour acquisition - two external neighbours agree to exchange EGP information.
This is a simple "two-way handshake". The potential neighbours are usually explicitly

4
 configured for each border router. A neighbour can refuse to become an EGP partner or
cease its co-operation.
• Neighbour reachability - once two external neighbours have agreed to become EGP
partners they must check that the link is still operational, this is a periodic handshake (30
seconds).
• Network reachability - if the two external neighbours can reach each other, they
periodically exchange their list of reachable networks. Each neighbour polls its partner to
get a new list (2 minutes). The whole list must be sent each time.
EGP runs directly over IP, all messages are carried inside IP datagrams. EGP therefore
implements its own mechanism for reliability. For example all messages are sequenced.
References: [1], [2], [15], [16].

3.2 Some Interesting Details.

As mentioned earlier, EGP does not pass sufficient routing information to prevent routing
loops if cycles exist in the AS topology. The distance metrics of different ASs are quite
independent and hence cannot be used to count to infinity like with standard distance vector
protocols. Even if the metrics were made consistent, EGP propagates changes slowly. If a
cycle is introduced, for example as a consequence of an administrative mistake, and a routing
loop appears, the count to infinity required to break the routing loop could take up to eight
hours [16] p.173.
It is therefore important to keep a structure without cycles or at least to constrain the inter-
domain routing information to flow along a tree-structure. A "backdoor link", for example a
direct link between A and B in Fig. 3, is a good illustration of the cost to be paid when using
this work around. Such a link introduces a cycle in the information flow unless it is kept
strictly private: the autonomous systems A and B must only advertise their own networks to
the core. In practice, this means a lot of manual configuration and complicates noticeably the
task of the network administrators.
The IGP used in the autonomous system has an influence on the operation of EGP. For
example RIP does not differentiate between internal and external distances and also
increments the external distances with each internal hop. In the case of a backup link or a
backdoor link, the distance advertised internally must therefore be chosen very carefully so
that all internal nodes select the proper route. One convention was used to simplify this task
for backup links: the border routers in the core were configured to always advertise a
"distance" of 128 for reachable destinations. On the other hand, OSPF carries the reachability
information advertised by border routers as external links. OSPF does not modify the metric
and considers the external links to always have a larger metric than any internal route. It is
therefore much easier to administer competing external links if OSPF is used.
References: [1], [2], [16].

3.3 The Limitations of EGP.

EGP proved the usefulness of the concept of inter-domain routing protocol. However, it was
designed for the Internet of the early 80's and some of its limitations made its replacement
necessary:
• The periodic exchange of complete reachability information in one IP datagram,
combined with the growing number of networks, means that beyond the maximum size

5
 supported by the network (MTU), the message is always fragmented. The loss of a
fragment then forces a complete retransmission, which is inefficient. A more serious
consequence is that, in case of congestion, the failure to perform the exchange in time
causes the routes to be dropped.
• EGP does not provide any protection if a router misbehaves, the warning given in [1] is
very explicit: "If any gateway sends a network reachability message with false
information, claiming to be an appropriate first hop to a network which it in fact cannot
even reach, traffic destined to that network may never be delivered."
• Because its basic design assumes a tree-like topology, EGP does not support the meshed
architecture topology required in Internet today, where multiple commercial backbones
are competing.
It is to be noted that, despite these limitations, EGP is still in use today. For example, a stub
AS with only one link to the rest of the Internet can very well use EGP for its inter-domain
protocol, as long as the backbone provides an EGP peer.
References: [1], [5], [6], [7], [16].

4. The Border Gateway Protocol (BGP-3)

BGP is the successor of EGP. This paper only reviews BGP-3. The additions brought by the
latest design iteration, BGP-4, are best explained when presenting CIDR and therefore are not
detailed here. (See [13], [14], [16].)
The official documents defining BGP-3 are [10], and [11].

4.1 Main Differences With EGP.

The BGP characteristics briefly presented here collectively address most of the limitations of
EGP.
• The Internet topology model used by BGP is a general graph whose nodes are ASs and
whose edges are connections between pairs of ASs.
• In order to avoid routing loops in a meshed topology, the designers of BGP invented a new
technology: the path vector. The principle is simple, with each advertised destination, BGP
maintains a complete list of transit autonomous systems. When a border router receives a
route advertisement it will refuse to use that route if its own AS is in the list.
• BGP runs on the top of TCP and therefore can assume a reliable message transfer. This
greatly simplifies the protocol as there is no need for complex error recovery mechanisms.
This choice also decreases indirectly the volume of data which is exchanged between
routers: because messages are delivered reliably, BGP uses incremental updates of routing
information.
A consequence is that each BGP router memorises the information provided by its
partners.
• BGP specifies a direct transfer of information between interior neighbours. The transfer is
performed over “internal” BGP connections, independently of any constraints imposed by
the interior routing protocol.
It is to be noted that, although BGP defines new security and authentication mechanisms, it
does not seem to offer any additional protection if a router misbehaves.

6
The comparison of the two protocols in the field have shown that BGP is clearly superior to
EGP in terms of CPU and bandwidth requirements [9]. On the other hand, [8] evaluates the
extra memory requirements for BGP to less than 7 percent.
References: [8], [9], [10], [11], [15], [16].

4.2 The BGP Messages.

The operation of BGP is divided along the same general lines as EGP. The procedures are
presented under the corresponding message name.
All the BGP messages use the same fixed-length header (19 bytes). This header carries the
type (1-4, 1 byte) and the total length (19-8192, 2 bytes) of the message. The length is used
for message delineation because a TCP connection is a byte stream service. The header starts
with a 16 byte “marker” field as a redundant protection against message misalignment.
1. OPEN (cf. Neighbour acquisition) - two external or internal neighbours agree to
exchange BGP information. The potential BGP partners are usually explicitly configured
for each border router. After the opening a TCP connection towards the port 179 on a
potential partner, each side sends an OPEN message. The neighbour accepts the
association with a KEEPALIVE message. A neighbour can refuse to become a BGP
partner or cease its co-operation with a NOTIFICATION message.
The fields of the OPEN message are:
- the BGP version (1 byte): the version must be identical in both OPEN messages;
- the AS number of the sender (2 bytes);
- the hold time in seconds (2 bytes): the sender specifies how long its partner should wait
between messages, before deciding that the connection is lost;
- the BGP identifier (4 bytes) which is usually one of the IP interface address of the
router. The same identifier is used by one router for all its BGP associations;
- the authentication code (1 byte) and some variable length authentication data. The code
specifies the format of the data and also the content of the marker field which will be used
in the header of the next messages. The only code specified in [10] is 0: no data and a
marker set to all 1s.
2. UPDATE (cf. Network reachability) - once the two neighbours are BGP partners, they
exchange update messages which contain:
- a list of path attributes for one AS path, the attributes are coded in the “type, length,
value” format, the AS path itself is in one attribute, see the next section for more details;
- a list of networks which can be reached through this path, each IP network number is on
4 bytes, padded with 3, 2 or 1 null bytes depending on the network class.
After an initial phase where all the routing information is exchanged, BGP only transmits
messages carrying the incremental changes in routing information.
3. NOTIFICATION - this message is used to convey error notifications or a normal “cease”
notification. It includes an error code (1 byte), sub-code (1 byte) and variable length data.
4. KEEPALIVE (cf. Neighbour reachability) - once two external neighbours have agreed to
become BGP partners they must check that the link is still operational. This message is
sent if no UPDATE message has been sent during a given time. Usually this time is set to
one third of the hold time specified in the OPEN message (resulting in a typical
periodicity of 2 minutes). This message is made of a simple header.

7
Some sanity checks are performed on the header of all messages, the marker field itself must
comply with the security algorithm specified in the OPEN message, if an error is detected, a
NOTIFICATION is sent and the TCP connection is closed.
It is interesting to note that, if the Internet is stable, the steady state traffic generated by BGP
is only made of the periodic KEEPALIVE messages. This is a tiny 5 bit/sec bandwidth for
each BGP connection (one way).
References: [8], [10], [11], [16].

4.3 The Path Attributes.

Beside the list of reachable networks, the routing information is carried by BGP in the path
attributes of the UPDATE message.
Some binary flags are specified for each path attribute:
• well-known or optional: well-known attributes are understood by all BGP-3 routers, they
are essential for the operation of the protocol.
• transitive or local: an optional attribute is passed on to the next AS only if it is transitive,
note: a well-known attribute is marked as transitive in any case;
• complete or partial: an attribute is complete if it has been seen and handled by all the AS
on the path.
The well-known BGP-3 attributes are listed below:
• AS path: the list of transit AS;
• origin: the source of the information in the original AS, either IGP, EGP or incomplete
(any other source);
• next hop: the IP address of the next router to the destination, it may be different from the
sender of the message (local attribute);
• unreachable mark: this is used to inform that a previously advertised path is no longer
available;
BGP-3 also defines a local optional attribute:
• inter-AS metric: when two ASs have several common connections this attribute is used
locally to specify a preferred connection, this is the path with the lowest metric.
References: [10], [16].

4.4 UPDATE Message Handling.

In this section we use the following definition of a route selection operation: a BGP router
compares all the routes received from external and internal BGP peers. The algorithm used to
choose the “better” route is freely defined inside the AS and can use the information provided
in the path attributes. There are many possibilities such as counting the number of transit ASs
or assigning weights to different ASs. All the BGP routers in one AS must use the same
algorithm.
The general principle behind the route selection mechanism is that, for each destination, each
border router gets to know the best external route of each of its internal peers. The -- same –

8
AS-level best path to a destination is therefore determined by a route selection operation at
each border router of the AS.
Whenever a new route is selected or a reachable destination inside the AS has changed, an
UPDATE message is sent to each external peer, the local AS number is prepended to the AS
path attribute.
Note: the router which is the best exit point for a new route injects the route information into
the IGP. The use of direct connections to propagate inter-domain routing information to
internal BGP neighbours actually creates a synchronisation problem with the IGP: a route
should not be advertised to external neighbours before it is properly established within the AS
itself.
The UPDATE handling mechanism is know described with more details.
Please note that, for the sake of clarity, the explanations are given for an update concerning
only one network. In practice, several networks may be listed in the message.
When an UPDATE message is received, it is validated. The attributes are processed and
checked. This include the detection of the AS’s own AS number in the AS path attribute, if
this is the case, the route is never selected as this would result in a routing loop.
The actual handling of an UPDATE message is different whether it was received over an
external or an internal BGP connection.
Update received from an external neighbour.
• New route: for the network listed in the update message, the new route is compared with
the routes received previously from other external neighbours. If the best external route has
changed, it is advertised to the internal neighbours after a “hold down” time, a route
selection operation is also performed at that time.
• Unreachable route: if this route was the currently selected route to the destination, the
update is immediately propagated to all the internal neighbours. This is followed by a route
selection operation.
Update received from an internal neighbour.
• A route selection operation is performed. If a new route is selected, or a destination
becomes unreachable, this is immediately advertised to the external neighbours. If the
internal neighbours are linked by full-mesh BGP connections, as recommended in [10],
then the update is not propagated to internal neighbours.
References: [10], [12], [16].

9
 5. Conclusions

The main initial requirements for an inter-domain routing protocol were:

• provide a means for different domains to exchange information about the networks that
are reachable via them;
• let the domains run different intra-domain routing protocols;
• avoid routing loops between domains.
These requirements were met by EGP in the context of the 1980 Internet and its tree-structure
topology, but the Internet was growing and additional requirements soon appeared:
• support the initial requirements in a meshed topology;
• scale to a large number of networks;
• support policy routing.
The three first versions of BGP were designed to address these new requirements. The
introduction of the path vector technology and the use of incremental updates were two key
factors for their success .
The Internet did not stop growing, this created some strains on the management of network IP
addresses. The resulting new requirements for an inter-domain routing protocol is to support
route aggregation and the IP addressing scheme introduced by the Classless Inter-Domain
Routing (CIDR). BGP-3 is therefore already obsolete and is being replaced by BGP-4.
One can also foresee the need for the support of different types of services (for example low
delay variation) and multiple paths to one destination.

Acronyms
AS Autonomous System
BGP Border Gateway Protocol
EGP Exterior Gateway Protocol
IETF Internet Engineering Task Force
IGP Internal Gateway Protocol
IP Internet Protocol
MTU Media Transmission Unit
OSPF Open Shortest Path First
RIP Routing Information Protocol
TCP Transfer Control Protocol

10
 References

Note about the Requests For Comments (RFC): these documents can be retrieved from
http://ds.internic.net/ds/dspg1intdoc.html or ftp://ds.internic.net/rfc. The abbreviation
immediately following the RFC number is the RFC status as at 29 September 1996 - S:
Standards, DS: Draft Standards, PS: Proposed Standards, E: Experimental, I: Informational,
H: Historic. See [17] for more details.
NOTICE: The RFC publication date is in American format (mm/dd/yyyy).

EGP

[1] RFC0827, E. Rosen, "Exterior Gateway Protocol EGP", 10/01/1982. (Updated by

RFC0904)
[2] RFC0888, L. Seamonson, E. Rosen, ""STUB" Exterior Gateway Protocol", 01/01/1984.
[3] RFC0890, J. Postel, "Exterior Gateway Protocol implementation schedule",
02/01/1984.
[4] RFC0904 H, International Telegraph and Telephone Co, D. Mills, "Exterior Gateway
Protocol formal specification", 04/01/1984. (Updates RFC0827) (STD 18)
[5] RFC0911, P. Kirton, "EGP Gateway under Berkeley UNIX 4.2", 08/22/1984.
[6] RFC1092, J. Rekhter, "EGP and policy based routing in the new NSFNET backbone",
02/01/1989.
[7] RFC1093, H. Braun, "NSFNET routing architecture", 02/01/1989.

BGP

[8] RFC1265 I, Y. Rekhter, "BGP Protocol Analysis", 10/28/1991.

[9] RFC1266 I, Y. Rekhter, "Experience with the BGP Protocol", 10/28/1991.
[10] RFC1267 DS, K. Lougheed, Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)",
10/25/1991. (Obsoletes RFC1163)
[11] RFC1268 DS, P. Gross, Y. Rekhter, "Application of the Border Gateway Protocol in
the Internet", 10/25/1991. (Obsoletes RFC1164) (Obsoleted by RFC1655)
[12] RFC1403 PS, K. Varadhan, "BGP OSPF Interaction", 01/14/1993. (Obsoletes
RFC1364)
[13] RFC1771 DS, Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", 03/21/1995.
(Obsoletes RFC1654)
[14] RFC1772 DS, Y. Rekhter, P. Gross, "Application of the Border Gateway Protocol in
the Internet", 03/21/1995. (Obsoletes RFC1655)

General

[15] Martha Steenstrup, Routing in communications networks, Prentice Hall, 1995.

[16] Christian Huitema, Routing in the Internet, Prentice Hall, 1995.
[17] RFC1920 S, J. Postel, "INTERNET OFFICIAL PROTOCOL STANDARDS",
03/22/1996. (Obsoletes RFC1880) (STD 1)

11