A Model of BGP Routing for Network Engineering
Nick Feamster Jared Winick Jennifer Rexford
MIT Computer Science & AI Lab Lockheed Martin AT&T Labs–Research
feamster@csail.mit.edu jared.winick@lmco.com jrex@research.att.com
ABSTRACT
The performance of IP networks depends on a wide variety of dy-
namic conditions. Traffic shifts, equipment failures, planned main-
tenance, and topology changes in other parts of the Internet can
all degrade performance. To maintain good performance, network
operators must continually reconfigure the routing protocols. Op-
erators configure BGP to control how traffic flows to neighboring
Autonomous Systems (ASes), as well as how traffic traverses their
networks. However, because BGP route selection is distributed,
indirectly controlled by configurable policies, and influenced by
complex interactions with intradomain routing protocols, operators
cannot predict how a particular BGP configuration would behave in
practice. To avoid inadvertently degrading network performance,
operators need to evaluate the effects of configuration changes be-
fore deploying them on a live network. We propose an algorithm
that computes the outcome of the BGP route selection process for
each router in a single AS, given only a static snapshot of the net-
work state, without simulating the complex details of BGP message
passing. We describe a BGP emulator based on this algorithm;
the emulator exploits the unique characteristics of routing data to
reduce computational overhead. Using data from a large ISP, we
show that the emulator correctly computes BGP routing decisions
and has a running time that is acceptable for many tasks, such as
traffic engineering and capacity planning.
Categories and Subject Descriptors
C.2.2 [Network Protocols]: Routing Protocols; C.2.6 [Computer-
Communication Networks]: Internetworking
General Terms
Algorithms, Management, Performance, Measurement
Keywords
BGP, traffic engineering, modeling, routing
1. INTRODUCTION
The delivery of IP packets through the Internet depends on a
large collection of routers that compute end-to-end paths in a dis-
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
SIGMETRICS/Performance’04, June 12–16, 2004, New York, NY, USA.
Copyright 2004 ACM 1-58113-664-1/04/0006 ...$5.00.
tributed fashion, using standardized routing protocols. Providing
low latency, high throughput, and high reliability requires network
operators to adjust routing protocol configuration when performance
problems arise or network conditions change. For example, an op-
erator might adjust the configuration to respond to network conges-
tion or equipment failures or to prepare for planned maintenance.
However, the complexity of the protocols, the large number of tun-
able parameters, and the size of the network make it extremely
difficult for operators to reason about the effects of their actions.
The common approach of “tweak and pray” is no longer accept-
able in an environment where users have high expectations for per-
formance and reliability [1]. To avoid costly debugging time and
catastrophic mistakes, operators must be able to make predictions
quickly based on an accurate model of the routing protocols.
Previous work in this area has focused on Interior Gateway Pro-
tocols (IGPs), such as Open Shortest Path First (OSPF) and Inter-
mediate System-Intermediate System (IS-IS), that operate within a
single Autonomous System (AS). In these protocols, each link has a
configurable integer “cost” that is used to compute the shortest path
(smallest cost path) through the network. Tuning these link weights
gives operators a way to modify the paths inside the AS to satisfy
network and user performance goals [2]. Several existing tools [3,
4, 5] capture how changes to the link weights would affect the flow
of the offered traffic over the new paths and also propose good can-
didate settings of the link weights. Although these tools are ex-
tremely valuable to network operators, the flow of traffic in large
service provider backbones ultimately depends on the interdomain
routing protocol as well. A provider uses the Border Gateway Pro-
tocol (BGP) to exchange reachability information with neighboring
domains and to propagate these routes within its own network. Un-
fortunately, several subtleties make modeling BGP route selection
in an AS much more challenging than emulating IGP:
BGP’s distributed, path vector operation means that every
router may have a different view of network state. In contrast to
link state protocols that flood complete information throughout the
network, a BGP-speaking router sends incremental reachability in-
formation only to its immediate neighbors. In BGP, a router sends
an advertisement to notify its neighbor of a new route to a desti-
nation prefix and a withdrawal to revoke the route when it is no
longer available. Each BGP-speaking router locally computes its
own best BGP route from the best routes announced by its neigh-
bors. A change in the best path at one router can affect the selection
of the best route at another router, and no single router has a com-
plete view of the available BGP routes in the AS.
BGP route selection is a complex process that depends on a
combination of route attributes. While most IGPs advertise a sin-
gle integer metric for each link and select routes based on shortest

A B
R
a b
routers
Neighboring AS
routes
eBGP
routes
eBGP
router
ingress
egress
Figure 1: Network engineering terminology.
paths, BGP route advertisements include various attributes, such as
the list of the ASes in the path (the AS path) and the IP address of
the router responsible for the route (the next hop). BGP route selec-
tion is based on a complex, multi-stage decision process [6]. BGP
allows operators to specify complex policies that have an indirect
effect on the selection of the best path.
BGP route selection depends on interactions with intradomain
routing protocols. Whereas the IGP can be modeled in isolation,
the selection of the best BGP route at each router also depends on
the IGP path cost to the BGP next hop announcing the route. “Hot
potato” routing, where a router prefers the route with the shortest
IGP path (the closest exit point), introduces a complex coupling
between BGP and the underlying IGP.
Hierarchical iBGP configuration affects the routing choices
that are available at each router. Internal BGP (iBGP) is used
to distribute BGP-learned routes throughout an AS. Rather than
having an iBGP session between each pair of routers (“full mesh
iBGP”), large provider networks typically distribute routes in a hi-
erarchical fashion. This makes the choices available at one router
dependent on the decisions made at other routers and may prevent
the protocol from converging.
In this paper, we present a model that accurately determines how
the network configuration and the routes learned via external BGP
(eBGP) affect the flow of traffic through an AS. While some ex-
isting tools simulate BGP’s behavior [7], this is the first paper to
develop a model that determines the outcome of the BGP path se-
lection process at each router in an AS without simulating the dy-
namics of the protocol. This type of model is important for sev-
eral reasons. First, network operators need to know the paths that
routers ultimately select to perform engineering tasks (e.g., traffic
engineering and maintenance), but they have no need for a com-
putationally expensive simulation of routing dynamics. We present
an emulator based on our model that facilitates these tasks by pro-
viding fast, accurate answers to “what if” questions about the ef-
fects of changes to the network. Second, an accurate model of BGP
route selection can be used to improve and validate existing simula-
tors by highlighting subtleties of the protocol and situations where
BGP might not converge to a unique solution. A simulator may
only compute one possible outcome, which may not accurately re-
flect the outcome in a real network. The modeling framework we
present can determine whether a BGP configuration would con-
verge to a unique outcome.
Predicting how a configuration change would affect the flow of
traffic first requires a way to determine which route each ingress
router in the AS would select for each destination prefix, given a
network configuration and the eBGP routes learned at the egress
routers (as shown in Figure 1). This paper solves precisely this
problem. The model of BGP routing that we present is essentially
an abstraction that conceals protocol details that are irrelevant to
the outcome of the BGP decision process. The model computes
BGP routing decisions when the network is configured “correctly”,
which can be checked separately by testing certain sufficient con-
ditions. Our model can also be combined with prefix-level traffic
measurements to form the basis of a traffic engineering tool.
The rest of the paper is organized as follows. In Section 2, we
present several examples of network engineering tasks that moti-
vate the need for an accurate, predictive model of BGP path se-
lection in an AS. Section 3 describes the practical constraints that
the network configuration and routing advertisements must satisfy
to make modeling BGP route selection possible and applies these
constraints in a novel way to decompose the route prediction prob-
lem into three distinct phases. In Section 4, we describe each phase
of the route prediction algorithm in detail. Section 5 describes a
prototype implementation of a BGP emulator. In Sections 6 and 7,
we present an evaluation and validation of our prototype on routing
and configuration data from a large tier-1 ISP. These experiments
show that the route prediction algorithm accurately predicts BGP
routing decisions and that it is efficient enough to be practical for
many network engineering tasks. Section 8 provides an overview
of related work. We conclude in Section 9.
2. NETWORK ENGINEERING
In this section, we discuss network engineering problems that
operators commonly face. These examples demonstrate the need
to systematically model BGP’s route selection process and move
beyond today’s “tweak and pray” techniques. We then discuss why
a practical model of BGP is useful; in particular, we discuss the
advantages a model has over simulation and live testing.
2.1 Network Engineering Problems
Network operators must adjust routing protocol configuration to
respond to the following common changes in network conditions:
Changes in traffic load. Because traffic is dynamic, the amount
of traffic to any destination may suddenly change, causing changes
in traffic distribution across network links. For example, a Web site
sometimes experiences a traffic surge due to a flash crowd (i.e., the
“Slashdot effect”); a network that was routing traffic to that desti-
nation through a neighboring AS could experience congestion on
an outbound link to that destination. A network operator must re-
configure routing policy to alleviate congestion.
Changes in link capacity. Network links are frequently up-
graded to higher capacity. In response, network operators may wish
to adjust configuration to route additional traffic through recently
upgraded links. For example, if link
in Figure 1 were upgraded
from an OC12 to an OC48, a network operator would want to shift
traffic from  to
.
Long-term connectivity changes. On longer timescales, the
points where a network connects to neighboring ASes, as well as
the ASes that it connects to, change. As links to other ASes appear
and disappear, network operators must move large amounts of traf-
fic. If the AS shown in Figure 1 added a third link to its neighboring
AS, an operator would shift a portion of traffic to that AS from

and

to the new link.
Changes in available routes. Due to protocol dynamics and
changing commercial agreements, an AS might suddenly receive
an alternate route to a destination that could cause traffic flow to
shift dramatically; alternatively, an existing route could suddenly
disappear. These events may require a network operator to rebal-
ance the flow of traffic.
Planned maintenance. Network operators commonly perform
routine maintenance on portions of their network, adjusting inte-