BGP multihoming: Difference between revisions
Jump to navigation
Jump to search
imported>Howard C. Berkowitz (New page: '''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 o...) |
imported>Howard C. Berkowitz (Continuing to add examples) |
||
| Line 1: | Line 1: | ||
'''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." | ||
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: | The cases include: | ||
*Multiple BGP sessions to different [[point of presence|points of presence]] of the same AS (i.e., T1) <ref name=RFC1998>{{citation | *Multiple BGP sessions to different [[point of presence|points of presence]] of the same AS (i.e., T1) <ref name=RFC1998>{{citation | ||
| title = An Application of the BGP Community Attribute in Multi-home Routing | | title = An Application of the BGP Community Attribute in Multi-home Routing | ||
| id = RFC 1998 | | id = RFC 1998 | ||
| url = http://www.ietf.org/rfc/ | | url = http://www.ietf.org/rfc/rfc1998.txt | ||
| | | first1=E. | last1 = Chen | first2=T. | last2 = Bates | ||
| publisher = Internet Engineering Task Force | | publisher = Internet Engineering Task Force | ||
| date = August 1996 | | date = August 1996 | ||
}}</ref>. Any type of physical connectivity can be used at the POP, including a switch operated by T1 | }}</ref>. 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. | *BGP sessions to the POPs of two transit providers; the principles can be extended to any number of AS. T | ||
*BGP session with peer P1, who provides the preferred path to P1's customers and mutual backup to the Internet. | **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<ref name=IRA2>{{citation | |||
| title = Internet Routing Architectures, 2nd Edition | |||
| chapter = Redundancy, Symmetry and Load Balancing | |||
| first1 = Sam | last1 = Halabi |first2 = Danny | last2 = McPherson | |||
| publisher = Cisco Press | year = 2000}} pp. 371-373</ref> | |||
*BGP session with peer P1, who provides the preferred path to P1's customers and mutual backup to the Internet.<ref name=BerkowitzBSPN2002>{{citation | |||
| first = Howard C. | last = Berkowitz | |||
| title = Building Service Provider Networks | |||
| chapter = The Provider-to-Provider Border | |||
| publisher = Wiley | year = 2002}} p. 485 </ref></blockquote> | |||
*BGP sessions with peers P1 and P2, who do not provide mutual backup | *BGP sessions with peers P1 and P2, who do not provide mutual backup | ||
*Multilateral peering at [[internet exchange point]] | |||
==Multihoming to users== | |||
*RFC 1998 case using <code>NOEXPORT</code> community on the provider side<ref name=RFC1997>{{citation | |||
| title = BGP communities attribue | |||
| id = RFC 1997 | |||
| url = http://www.ietf.org/rfc/rfc1997.txt | |||
| first1=R. | last1 = Chandra| first2=P. | last2 = Traina | first3 = T. |last3 = Li | |||
| publisher = Internet Engineering Task Force | |||
| date = August 1996 | |||
}}</ref> | |||
==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. <ref name=Greene>{{citation | |||
| title = ISP Routing Essentials | |||
| first1 = Barry Raveendran | last1 = Greene | first2 = Philip | last2 = Smith | |||
| publisher = Cisco Press | year = 2002}} pp. 270-271</ref> The [[Cisco IOS]] and [[Quagga]]<ref name=QuaggaBGP>{{citation | |||
| url = http://www.quagga.net/docs/docs-info.php#SEC72 | |||
| chapter = Multihoming | |||
| title = Quagga Routing Suite}}Section 9, BGP</ref> command for this is | |||
<center><code>neighbor ''neighbor address'' ebpg-multihop ''hopcount''</code></center> | |||
==References== | |||
{{reflist}} | |||
Revision as of 14:18, 24 July 2008
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