Hot-potato routing
In Internet routing between autonomous systems which are interconnected in multiple locations, hot-potato routing is the practice of passing traffic off to another autonomous system as quickly as possible, thus using their network for wide-area transit. Cold-potato routing is the opposite, where the originating autonomous system internally forwards the packet until it is as near to the destination as possible.[1][2][3]
Behaviors
Hot-potato routing (or "closest exit routing")[2] is the normal behavior generally employed by most ISPs.[1] Like a hot potato in the hand,[2] the source of the packet tries to hand it off as quickly as possible in order to minimize the burden on its network.[1]
Cold-potato routing (or "best exit routing")[2] on the other hand, requires more work from the source network, but keeps traffic under its control for longer, allowing it to offer a higher end-to-end quality of service to its users.[1] It is prone to misconfiguration as well as poor coordination between two networks, which can result in unnecessarily circuitous paths.[1] NSFNET used cold-potato routing in the 90s.[2]
When a transit network with a hot-potato policy peers with a transit network employing cold-potato routing, traffic ratios between the two networks tend to be symmetric.[2]
Implementation
Routing behavior can be influenced using two BGP "knobs": multi-exit discriminator (MED) and local preference.[1] In hot-potato routing, the MED attached to incoming EBGP-learned routes is discarded,[2] and the IGP cost is used instead.[3] In cold-potato routing, MED[2] or BGP communities are used to signal the cost of the route, which influences IBGP local preference.[3]
References
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 Subramanian, Lakshminarayanan; Padmanabhan, Venkata N.; Katz, Randy H. (2002-06-10). "Geographic Properties of Internet Routing". USENIX 2002 Annual Technical Conference. http://sahara.cs.berkeley.edu/papers/SPK02.pdf.
- ↑ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 McPherson, D.; Patel, K. (January 2006), Experience with the BGP-4 Protocol, IETF, p. 5. sec. 7.1.1, doi:10.17487/RFC4277, RFC 4277, https://tools.ietf.org/html/rfc4277, retrieved 2023-12-11
- ↑ 3.0 3.1 3.2 Decraene, B.; Francois, P.; Pelsser, C.; Ahmad, Z.; Armengol, A.J. Elizondo; Takeda, T. (April 2011), Requirements for the Graceful Shutdown of BGP Sessions, IETF, p. 18. sec. A.3, doi:10.17487/RFC6198, RFC 6198, https://tools.ietf.org/html/rfc6198, retrieved 2023-12-12
 |  |
