Border Gateway Protocol (BGP) Persistent Route Oscillation Condition
RFC 3345
Network Working Group D. McPherson
Request for Comments: 3345 TCB
Category: Informational V. Gill
AOL Time Warner, Inc.
D. Walton
A. Retana
Cisco Systems, Inc.
August 2002
Border Gateway Protocol (BGP) Persistent Route Oscillation Condition
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
In particular configurations, the BGP scaling mechanisms defined in
"BGP Route Reflection - An Alternative to Full Mesh IBGP" and
"Autonomous System Confederations for BGP" will introduce persistent
BGP route oscillation. This document discusses the two types of
persistent route oscillation that have been identified, describes
when these conditions will occur, and provides some network design
guidelines to avoid introducing such occurrences.
1. Introduction
The Border Gateway Protocol (BGP) 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.
In particular configurations, the BGP [1] scaling mechanisms defined
in "BGP Route Reflection - An Alternative to Full Mesh IBGP" [2] and
"Autonomous System Confederations for BGP" [3] will introduce
persistent BGP route oscillation.
The problem is inherent in the way BGP works: locally defined routing
policies may conflict globally, and certain types of conflicts can
cause persistent oscillation of the protocol. Given current
practices, we happen to see the problem manifest itself in the
context of MED + route reflectors or confederations.
McPherson, et al. Informational [Page 1]
RFC 3345 BGP Persistent Route Oscillation Condition August 2002
The current specification of BGP-4 [4] states that the
MULTI_EXIT_DISC is only comparable between routes learned from the
same neighboring AS. This limitation is consistent with the
description of the attribute: "The MULTI_EXIT_DISC attribute may be
used on external (inter-AS) links to discriminate among multiple exit
or entry points to the same neighboring AS." [1,4]
In a full mesh iBGP network, all the internal routers have complete
visibility of the available exit points into a neighboring AS. The
comparison of the MULTI_EXIT_DISC for only some paths is not a
problem.
Because of the scalability implications of a full mesh iBGP network,
two alternatives have been standardized: route reflectors [2] and AS
confederations [3]. Both alternatives describe methods by which
route distribution may be achieved without a full iBGP mesh in an AS.
The route reflector alternative defines the ability to re-advertise
(reflect) iBGP-learned routes to other iBGP peers once the best path
is selected [2]. AS Confederations specify the operation of a
collection of autonomous systems under a common administration as a
single entity (i.e. from the outside, the internal topology and the
existence of separate autonomous systems are not visible). In both
cases, the reduction of the iBGP full mesh results in the fact that
not all the BGP speakers in the AS have complete visibility of the
available exit points into a neighboring AS. In fact, the visibility
may be partial and inconsistent depending on the location (and
function) of the router in the AS.
In certain topologies involving either route reflectors or
confederations (detailed description later in this document), the
partial visibility of the available exit points into a neighboring AS
may result in an inconsistent best path selection decision as the
routers don't have all the relevant information. If the
inconsistencies span more than one peering router, they may result in
a persistent route oscillation. The best path selection rules
applied in this document are consistent with the current
specification [4].
The persistent route oscillation behavior is deterministic and can be
avoided by employing some rudimentary BGP network design principles
until protocol enhancements resolve the problem.
In the following sections a taxonomy of the types of oscillations is
presented and a description of the set of conditions that will
trigger route oscillations is given. We continue by providing
several network design alternatives that remove the potential of this
Show full document text