BGP Wedgies
RFC 4264
Document | Type | RFC - Informational (November 2005; No errata) | |
---|---|---|---|
Authors | Tim Griffin , Geoff Huston | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4264 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | David Kessens | ||
Send notices to | dmm@1-4-5.net, isoc-contact@aarnet.edu.au, dmm@cisco.com, dmm@uoregon.edu |
Network Working Group T. Griffin Request for Comments: 4264 University of Cambridge Category: Informational G. Huston APNIC November 2005 BGP Wedgies 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 (2005). Abstract It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable. Also, the stable state where BGP converges may be selected by BGP in a non-deterministic manner. These stable, but unintended, BGP states are termed here "BGP Wedgies". Table of Contents 1. Introduction ....................................................2 2. Describing BGP Routing Policy ...................................2 3. BGP Wedgies .....................................................3 4. Multi-Party BGP Wedgies .........................................6 5. BGP and Determinism .............................................7 6. Security Considerations .........................................8 7. References ......................................................9 7.1. Normative References .......................................9 7.2. Informative References .....................................9 Griffin & Huston Informational [Page 1] RFC 4264 BGP Wedgies November 2005 1. Introduction It has commonly been assumed that the Border Gateway Protocol (BGP) [RFC1771] is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. This is a 'problem statement' memo that describes a class of BGP configurations for which there is more than one stable forwarding state. In this class of configurations there exist multiple stable forwarding states. One of these stable forwarding states is the intended state, with other stable forwarding states being unintended. The BGP convergence process of selection of a stable forwarding state may operate in a non-deterministic manner in such cases. These stable, but unintended, BGP states are termed here "BGP Wedgies". 2. Describing BGP Routing Policy BGP routing policies generally reflect each network administrator's objective to optimize their position with respect to their network's cost, performance, and reliability. With respect to cost optimization, the local network's default routing policy often reflects a local preference to prefer routes learned from a customer to routes learned from some form of peering exchange. In the same vein, the local network is often configured to prefer routes learned from a peer or a customer over those learned from a directly connected upstream transit provider. These preferences may be expressed via a local preference configuration setting, where the local preference overrides the AS path length metric of the base BGP operation. In terms of engineering reliability in the inter-domain routing environment it is commonly the case that a service provider may enter into arrangements with two or more upstream transit providers, passing routes to all upstream providers, and receiving traffic from all sources. If the path to one upstream fails, the traffic will switch to other links. Once the path is recovered, the traffic should switch back. In such situations of multiple upstream providers it is also common to place a relative preference on the providers, so that one connection is regarded as a preferred, or "primary" connection, and other connections are regarded as less preferred, or "backup" connections. The intent is typically that the backup connections will be used for traffic only for the duration of a failure in the primary connection. Griffin & Huston Informational [Page 2] RFC 4264 BGP Wedgies November 2005 It is possible to express this primary / backup policy using local AS path prepending, where the AS path is artificially lengthened towards the backup providers, using additional instances of the local AS. This is not a deterministic selection algorithm, as the selected primary provider may in turn be using AS path prepending to itsShow full document text