BGP multihoming: Difference between revisions
imported>Howard C. Berkowitz (Continuing to add examples) |
imported>Howard C. Berkowitz No edit summary |
||
| Line 1: | Line 1: | ||
{{subpages}} | |||
'''BGP multihoming''' involves a variety of [[multihoming]] techniques, all of which require that there be an exchange of information from the [[autonomous system]]s being multihomed, to one or more other AS. In this discussion, the AS that is obtaining multiple paths will be called the "user AS". When multihoming without payment, between AS that provide mutual backup or other mutually beneficial AS, those AS will be called "peer 1 (P1), peer 2 (P1), etc." When the multihoming is to an "upstream" provider or providers that the user AS pays for transit to the Internet, those AS will be called "Transit1 (T1), transit 2 (T2), etc." | '''BGP multihoming''' involves a variety of [[multihoming]] techniques, all of which require that there be an exchange of information from the [[autonomous system]]s being multihomed, to one or more other AS. In this discussion, the AS that is obtaining multiple paths will be called the "user AS". When multihoming without payment, between AS that provide mutual backup or other mutually beneficial AS, those AS will be called "peer 1 (P1), peer 2 (P1), etc." When the multihoming is to an "upstream" provider or providers that the user AS pays for transit to the Internet, those AS will be called "Transit1 (T1), transit 2 (T2), etc." | ||
Revision as of 18:32, 31 January 2009
BGP multihoming involves a variety of multihoming techniques, all of which require that there be an exchange of information from the autonomous systems being multihomed, to one or more other AS. In this discussion, the AS that is obtaining multiple paths will be called the "user AS". When multihoming without payment, between AS that provide mutual backup or other mutually beneficial AS, those AS will be called "peer 1 (P1), peer 2 (P1), etc." When the multihoming is to an "upstream" provider or providers that the user AS pays for transit to the Internet, those AS will be called "Transit1 (T1), transit 2 (T2), etc."
See non-BGP provider multihoming for techniques by which some simple multihoming can be done without BGP. In general, however, BGP is more flexible, and need not be terribly complex for simple configurtions.
User multihoming
The cases include:
- Multiple BGP sessions to different points of presence of the same AS (i.e., T1) [1]. Any type of physical connectivity can be used at the POP, including a switch operated by T1
- BGP sessions to the POPs of two transit providers; the principles can be extended to any number of AS. T
- Default only; relationships are primary and backup
- Load-sharing to prefer each transit providers directly connected customers; either transit provider can take two routes if the other provider fails
- Customer routes taken only by one of two paths to the provider[2]
- BGP session with peer P1, who provides the preferred path to P1's customers and mutual backup to the Internet.[3]
- BGP sessions with peers P1 and P2, who do not provide mutual backup
- Multilateral peering at internet exchange point
Multihoming to users
IXP considerations
Depending on the BGP implementation, it may assume that unless told otherwise, the other router of a BGP session (e.g., P1 or T1) is physically connected to user router (U1). If there is an intermediate router(s) between the two, not running BGP, it is necessary to tell BGP so it can go across multiple routers. [5] The Cisco IOS and Quagga[6] command for this is
neighbor neighbor address ebpg-multihop hopcountReferences
- ↑ Chen, E. & T. Bates (August 1996), An Application of the BGP Community Attribute in Multi-home Routing, Internet Engineering Task Force, RFC 1998
- ↑ Halabi, Sam & Danny McPherson (2000), Redundancy, Symmetry and Load Balancing, Internet Routing Architectures, 2nd Edition, Cisco Press pp. 371-373
- ↑ Berkowitz, Howard C. (2002), The Provider-to-Provider Border, Building Service Provider Networks, Wiley p. 485
- ↑ Chandra, R.; P. Traina & T. Li (August 1996), BGP communities attribue, Internet Engineering Task Force, RFC 1997
- ↑ Greene, Barry Raveendran & Philip Smith (2002), ISP Routing Essentials, Cisco Press pp. 270-271
- ↑ , Multihoming, Quagga Routing SuiteSection 9, BGP