Interdomain Routing and the Border Gateway Protocol (BGP)— What does it all mean? Timothy G.
Download ReportTranscript Interdomain Routing and the Border Gateway Protocol (BGP)— What does it all mean? Timothy G.
Interdomain Routing and the Border Gateway Protocol (BGP)— What does it all mean? Timothy G. Griffin AT&T Research [email protected] http://www.research.att.com/~griffin http://www.research.att.com/~griffin/interdomain.html IMA Minneapolis April 6, 2003 Outline Part I: The glue that holds the Internet together : interdomain routing with The Border Gateway Protocol (BGP) Part II: A formal model of BGP routing policies Joint work with Gordon Wilfong and F. Bruce Shepherd, Bell Labs AT&T IP Backbone Anchorage, AK Year end 2001 Seattle Spokane Portland Portland Manchester Worcester Minneapolis R St. Paul Milwaukee Madison Rolling Meadows Grand Rapids Birmingham R R San San Francisco Francisco Salt Lake City Oak Brook Plymouth Chicago Omaha Las Vegas Kansas City R Harrisburg Wash. DC Silver Springs DaytonColumbus Cincinnati Angeles Albuquerque San Bernardino Oklahoma City Norfolk Louisville Nashville LA-Airport Blvd R Florissant Tulsa Rochelle Pk Hamilton Square Freehold R Richmond R Los Sherman Oaks Cedar Knolls Phil Arlington Redwood City Honolulu Framingham Providence Stamford Providence Bridgepor t New Brunswick NYC White Plains Baltimore Newark Bohemia Indianapolis St Louis Colorado Springs R R Pittsburgh Cleveland Akron South Bend Chicago Denver R San Jose Oakland Davenport R Cambridge Hartford Wayne Buffalo Detroit Des Moines Sacramento Albany Syracuse Rochester Glenview Camden, NJ NYCBdwy Raleigh Greensboro Charlotte Little Rock Anaheim Garden a Memphis Phoenix Birmingham Norcross Columbia Dunwoody San Diego Gateway Node Ft. Worth Atlanta Dallas Backbone Node R Remote GSR Access Router Jacksonville New Orleans Austin Remote Access Router Orlando Houston San Antonio N X DS3 N X OC3 N X OC12 N X OC48 NX OC192 R Note: Connectivity and nodes shown are targeted for deployment; actual deployment may vary. Maps should not be used to predict service availability. Tampa W. Palm Beach R Ft. Lauderdale Ft. Lauderdale Ojus Miami San Juan PR Rev. 6-4-01 wiscnet.net UW-Superior Rice Lake Rhinelander UW-Stout Marshfield UW-River Falls Stiles Jct. Wausau UW-Eau Claire Qwest and Other Provider(s) Clintonville er '02) (Summ UW-Stevens Point UW-Green Bay (Summer '02) Fox Valley TC (Summer '03) um (S UW-Oshkosh m ' er ) 02 UW-La Crosse La Crosse Portage Dodgeville GO BUCKY! Genuity UW-Madison (Summer '03) UW-Milwaukee UW-Whitewater UW-Parkside ) (Winter '02 UW-Platteville Gigabit Ethernet OC-12 (622Mbps) OC-3 (155Mbps) DS-3 (45Mbps) T1 (1.5Mbps) Chicago Internet 2 & Qwest Peering - Public and Private Commodity Internet Transit Internet2 Merit and Other State Networks National Education Network Regional Research Peers '02 ter (Win Chicago - 1 ) Chicago - 2 (Winter '02) Telstra international WorldCom (UUNet) Network Interconnections • Exchange Point – Layer 2 or Layer 3 • Private Circuit – May be provided by a third party What about Logical Connectivity? Application Separate physical networks glued together into one Application logical network Router Presentation Presentation Session Session Transport Transport Network Network Network DataLink 1 DataLink 1 DataLink 2 DataLink 2 Physical 1 Physical 1 Physical 2 Physical 2 Medium 1 Medium 2 8 All Hail the IP Datagram! H E A D E R D A T A 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL | Service Type | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... up to 65,515 octets of data ... shaded fields little-used today 1981, RFC 791 9 Hosts, Networks, and Routers Host 7 Host 1 Network A Host 2 Host 1 Router Network B Network C Unique IP Address = Network Number + Host Number Host 12 Host 2 10 Actually, IP addresses Identify Interfaces Host 7 Host 1 Network C, Host 3 Network A Host 2 Network A, Host 1 Host 3 Network B, Host 77 Network B Host 12 Host 2 Network C Machines can have more than one IP address. All routers do! 11 IP Forwarding Table Destination Net A Net B Net C, Host 3 Net C A destination is usually a network. May also be a host, or a “gateway of last resort” (default) Next Hop Router 1 Direct Router 2 Router 1 The next hop is either a directly connected network or a router on a directly connected network Interface INT 7 INT 4 INT 3 INT 7 A physical interface 12 IP Forwarding Process 1. Remove a packet from an input queue 2. Check for sanity, decrement TTL field 4. Place packet on correct output queue Forwarding Process If queues get full, just drop packets! 3. Match packet’s destination to a table entry If queues get full, just drop packets! IP Forwarding Table Router 13 Routing vs. Forwarding Net Default to upstream router A B R R2 R D R3 R R1 R4 A B C D E default Nxt Hop R1 Direct R3 R1 R3 R1 C R5 Net E Forwarding: determine next hop Routing: establish end-to-end paths Forwarding always works A B C D E default Routing can be badly broken Net A B C D E default Nxt Hop R2 R2 Direct R5 R5 R2 Nxt Hop R4 R3 R3 R4 Direct R4 14 How Are Forwarding Tables Populated to implement Routing? Statically Administrator manually configures forwarding table entries + More control + Not restricted to destination-based forwarding - Doesn’t scale - Slow to adapt to network failures Dynamically Routers exchange network reachability information using ROUTING PROTOCOLS. Routers use this to compute best routes + Can rapidly adapt to changes in network topology + Can be made to scale well - Complex distributed algorithms - Consume CPU, Bandwidth, Memory - Debugging can be difficult - Current protocols are destination-based In practice : a mix of these. Static routing mostly at the “edge” 15 Routers Talking to Routers (The “control plane”) Routing info Routing info • Routing computation is distributed among routers within a routing domain • Computation of best next hop based on routing information is the most CPU/memory intensive task on a router • Routing messages are usually not routed, but exchanged via layer 2 between physically adjacent routers (internal BGP and multi-hop external BGP are exceptions) Architecture of Dynamic Routing OSPF BGP AS 1 IGP = Interior Gateway Protocol Metric based: OSPF, IS-IS, RIP, EIGRP (cisco) EGP = Exterior Gateway Protocol EIGRP AS 2 Policy based: BGP The Routing Domain of BGP is the entire Internet Technology of Distributed Routing Link State • • • • • • Topology information is flooded within the routing domain Best end-to-end paths are computed locally at each router. Best end-to-end paths determine next-hops. Based on minimizing some notion of distance Works only if policy is shared and uniform Examples: OSPF, IS-IS Vectoring • • • • • • Each router knows little about network topology Only best next-hops are chosen by each router for each destination network. Best end-to-end paths result from composition of all next-hop choices Does not require any notion of distance Does not require uniform policies at all routers Examples: RIP, BGP The Gang of Four Link State IGP EGP OSPF IS-IS Vectoring RIP BGP Happy Packets: The Internet Does Not Exist Only to Populated Routing Tables BGP RIP Process BGP Process RIP Routing tables BGP Routing tables OSPF Process OSPF Routing tables RIP Domain OSPF Domain Forwarding Table Manager Forwarding Table 20 AS Numbers (ASNs) Currently over 14,000 in use. • • • • • • • • • Genuity: 1 MIT: 3 Harvard: 11 Yale: 29 UCLA: 52 AT&T: 7018, 5075, …, 6341, … UUNET: 701, 702, 284, 12199, … Sprint: 1239, 1240, 6211, 6242, … … ASNs represent units of routing policy 64512 through 65535 are “private” Autonomous Routing Domains Don’t Always Need BGP or an ASN Qwest Nail up routes 130.132.0.0/16 pointing to Yale Nail up default routes 0.0.0.0/0 pointing to Qwest Yale University 130.132.0.0/16 Static routing is the most common way of connecting an autonomous routing domain to the Internet. This helps explain why BGP is a mystery to many … U of Minnesota Neighborhood AS 7018 AT&T AS 1 Genuity AS 3908 Sources: ARIN, Route Views, RIPE SuperNet (Qwest) AS 57 UMN AS 1998 State of Minnesota AS 217 UMN 128.101.0.0/16 www.ima.umn.edu 128.101.10.128 (DNS) ASNs Can Be “Shared” (RFC 2270) AS 701 UUNet AS 7046 Crestar Bank AS 7046 NJIT AS 7046 Hood College 128.235.0.0/16 ASN 7046 is assigned to UUNet. It is used by Customers single homed to UUNet, but needing BGP for some reason (load balancing, etc..) [RFC 2270] Number of Used ASNs Source: Geoff Huston, http://bgp.potaroo.net AS Graphs Can Be Fun The subgraph showing all ASes that have more than 100 neighbors in full graph of 11,158 nodes. July 6, 2001. Point of view: AT&T route-server AS Graph != Internet Topology BGP was designed to throw away information! The AS graph may look like this. Reality may be closer to this… Growth of BGP Routes Percentage of IPv4 space advertised Source: Geoff Huston, http://bgp.potaroo.net, Nov. 3, 2002 Customers and Providers provider provider customer IP traffic customer Customer pays provider for access to the Internet The Peering Relationship peer provider peer customer Peers provide transit between their respective customers Peers do not provide transit between peers traffic allowed traffic NOT allowed Peers (often) do not exchange $$$ Peering Provides Shortcuts Peering also allows connectivity between the customers of “Tier 1” providers. peer provider peer customer BGP-4 • BGP = Border Gateway Protocol • Is a Policy-Based routing protocol • Is the de facto EGP of today’s global Internet • Relatively simple protocol, but configuration is complex and the entire world can see, and be impacted by, your mistakes. • 1989 : BGP-1 [RFC 1105] – • Replacement for EGP (1984, RFC 904) 1990 : BGP-2 [RFC 1163] • 1991 : BGP-3 [RFC 1267] • 1995 : BGP-4 [RFC 1771] – Support for Classless Interdomain Routing (CIDR) 32 BGP Operations (Simplified) Establish session on TCP port 179 AS1 BGP session Exchange all active routes AS2 Exchange incremental updates While connection is ALIVE exchange route UPDATE messages 33 Four Types of BGP Messages • Open : Establish a peering session. • Keep Alive : Handshake at regular intervals. • Notification : Shuts down a peering session. • Update : Announcing new routes or withdrawing previously announced routes. announcement = prefix + attributes values 34 BGP Attributes Value ----1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ... 255 Code --------------------------------ORIGIN AS_PATH NEXT_HOP MULTI_EXIT_DISC LOCAL_PREF ATOMIC_AGGREGATE AGGREGATOR COMMUNITY ORIGINATOR_ID CLUSTER_LIST DPA ADVERTISER RCID_PATH / CLUSTER_ID MP_REACH_NLRI MP_UNREACH_NLRI EXTENDED COMMUNITIES Reference --------[RFC1771] [RFC1771] [RFC1771] [RFC1771] [RFC1771] [RFC1771] [RFC1771] [RFC1997] [RFC2796] [RFC2796] [Chen] [RFC1863] [RFC1863] [RFC2283] [RFC2283] [Rosen] Most important attributes reserved for development From IANA: http://www.iana.org/assignments/bgp-parameters Not all attributes need to be present in every announcement Attributes are Used to Select Best Routes 192.0.2.0/24 pick me! 192.0.2.0/24 pick me! 192.0.2.0/24 pick me! 192.0.2.0/24 pick me! Given multiple routes to the same prefix, a BGP speaker must pick at most one best route (Note: it could reject them all!) BGP Route Processing Open ended programming. Constrained only by vendor configuration language Receive Apply Policy = filter routes & BGP Updates tweak attributes Apply Import Policies Based on Attribute Values Best Routes Best Route Selection Best Route Table Apply Policy = filter routes & tweak attributes Transmit BGP Updates Apply Export Policies Install forwarding Entries for best Routes. IP Forwarding Table 37 Route Selection Summary Highest Local Preference Enforce relationships Shortest ASPATH Lowest MED i-BGP < e-BGP traffic engineering Lowest IGP cost to BGP egress Lowest router ID Throw up hands and break ties Tweak Tweak Tweak • For inbound traffic – Filter outbound routes – Tweak attributes on outbound routes in the hope of influencing your neighbor’s best route selection • inbound traffic For outbound traffic – Filter inbound routes – Tweak attributes on inbound routes to influence best route selection In general, an AS has more control over outbound traffic outbound traffic outbound routes inbound routes ASPATH Attribute AS 1129 135.207.0.0/16 AS Path = 1755 1239 7018 6341 135.207.0.0/16 AS Path = 1239 7018 6341 AS 1239 Sprint AS 1755 135.207.0.0/16 AS Path = 1129 1755 1239 7018 6341 Ebone AS 12654 AS 6341 AT&T Research RIPE NCC RIS project 135.207.0.0/16 AS Path = 7018 6341 AS7018 135.207.0.0/16 AS Path = 6341 Global Access 135.207.0.0/16 AS Path = 3549 7018 6341 AT&T 135.207.0.0/16 AS Path = 7018 6341 AS 3549 Global Crossing 135.207.0.0/16 Prefix Originated 40 Shorter Doesn’t Always Mean Shorter In fairness: could you do this “right” and still scale? Mr. BGP says that path 4 1 is better than path 3 2 1 Duh! AS 4 AS 3 Exporting internal state would dramatically increase global instability and amount of routing state AS 2 AS 1 Shedding Inbound Traffic with ASPATH Padding Hack AS 1 provider 192.0.2.0/24 ASPATH = 2 2 2 192.0.2.0/24 ASPATH = 2 primary backup customer AS 2 192.0.2.0/24 Padding will (usually) force inbound traffic from AS 1 to take primary link 42 Padding May Not Shut Off All Traffic AS 1 AS 3 provider provider 192.0.2.0/24 ASPATH = 2 192.0.2.0/24 ASPATH = 2 2 2 2 2 2 2 2 2 2 2 2 2 2 primary backup customer AS 2 192.0.2.0/24 AS 3 will send traffic on “backup” link because it prefers customer routes and local preference is considered before ASPATH length! Padding in this way is often used as a form of load 43 balancing COMMUNITY Attribute to the Rescue! AS 1 AS 3 provider provider AS 3: normal customer local pref is 100, peer local pref is 90 192.0.2.0/24 ASPATH = 2 COMMUNITY = 3:70 192.0.2.0/24 ASPATH = 2 primary backup customer AS 2 192.0.2.0/24 Customer import policy at AS 3: If 3:90 in COMMUNITY then set local preference to 90 If 3:80 in COMMUNITY then set local preference to 80 If 3:70 in COMMUNITY then set local preference to 70 44 Hot Potato Routing: Go for the Closest Egress Point 192.44.78.0/24 egress 2 egress 1 15 56 IGP distances This Router has two BGP routes to 192.44.78.0/24. Hot potato: get traffic off of your network as Soon as possible. Go for egress 1! 45 Getting Burned by the Hot Potato 2865 High bandwidth Provider backbone 17 SFF Low bandwidth customer backbone Heavy Content Web Farm NYC 15 56 San Diego Many customers want their provider to carry the bits! tiny http request huge http reply 46 Cold Potato Routing with MEDs (Multi-Exit Discriminator Attribute) Prefer lower MED values 2865 17 Heavy Content Web Farm 192.44.78.0/24 MED = 56 192.44.78.0/24 MED = 15 15 56 192.44.78.0/24 This means that MEDs must be considered BEFORE IGP distance! Note1 : some providers will not listen to MEDs Note2 : MEDs need not be tied to IGP distance 47 PART II Policies Can Interact Strangely (“Route Pinning” Example) backup customer 1 3 2 Disaster strikes primary link and the backup takes over 4 Install backup link using community Primary link is restored but some traffic remains pinned to backup News at 11:00h • BGP is not guaranteed to converge on a stable routing. Policy interactions could lead to “livelock” protocol oscillations. See “Persistent Route Oscillations in Inter-domain Routing” by K. Varadhan, R. Govindan, and D. Estrin. ISI report, 1996 • Corollary: BGP is not guaranteed to recover from network failures. What Problem is BGP Solving? Underlying problem Distributed means of computing a solution. Shortest Paths RIP, OSPF, IS-IS X? BGP Separate dynamic and static semantics static semantics BGP Policies dynamic semantics BGP Stable Paths SPVP Problem (SPP) Booo Hooo, Many, many complications... SPVP = Simple Path Vector Protocol = a distributed algorithm for solving SPP An instance of the Stable Paths Problem (SPP) • • • • A graph of nodes and edges, Node 0, called the origin, For each non-zero node, a set or permitted paths to the origin. This set always contains the “null path”. A ranking of permitted paths at each node. Null path is always least preferred. (Not shown in diagram) 1 When modeling BGP : nodes represent BGP speaking routers, and 0 represents a node originating some address block 210 2 20 5 5210 2 4 420 430 3 30 0 1 130 10 most preferred … least preferred Yes, the translation gets messy! A Solution to a Stable Paths Problem 2 210 20 A solution is an assignment of permitted paths to each node such that • • node u’s assigned path is either the null path or is a path uwP, where wP is assigned to node w and {u,w} is an edge in the graph, each node1is assigned the highest ranked path among those consistent with the paths assigned to its neighbors. 5 5210 2 4 420 430 3 30 0 1 130 10 A Solution need not represent a shortest path tree, or a spanning tree. An SPP may have multiple solutions 120 10 120 10 1 120 10 1 0 0 2 210 20 DISAGREE 1 2 210 20 First solution 0 2 210 20 Second solution Multiple solutions can result in “Route Triggering” 10 1230 1 230 210 2 1 primary link 0 2 0 1 10 1230 2 230 210 0 backup link 3210 30 3 Remove primary link 3 3 Restore primary link 3210 30 BAD GADGET 2 210 20 4 0 130 10 1 3 3 320 30 Persistent Route Oscillations in Inter-Domain Routing. Kannan Varadhan, Ramesh Govindan, and Deborah Estrin. Computer Networks, Jan. 2000 SURPRISE : Beware of Backup Policies 210 20 BGP is not robust : it is not guaranteed to recover from network failures. 1 130 10 2 Becomes a BAD GADGET if link (4, 0) goes down. 4 40 420 430 0 3 3420 30 PRECARIOUS 4 310 3120 5 5310 563120 53120 4310 453120 43120 1 3 120 10 0 6 2 6310 643120 63120 This part has a solution only when node 1 is assigned the direct path (1 0). 210 20 As with DISAGREE, this part has two distinct solutions Distributed algorithms to solve SPP? • OSPF-like : – – – – Distribute topology, path ranks Solve SPP locally Exponential worst case How can loops be avoided when multiple solutions exist? • RIP-like: This is BGP… – Pick the best path from the set of your neighbor’s paths, tell your neighbors when you change your mind – Can diverge – Not guaranteed to find a solution, even when one exists – Even when converges, no bound on convergence time SPVP protocol Pick the best path available at any given time… process spvp[u] { receive P from w { rib-in(uw) := u P if rib(u) != best(u) { rib(u) := best(u) foreach v in peers(u) { send rib(u) to v } } } } SPVP wanders around assignment space = assignment = solution Solving an SPP Just enumerate all path assignments And check stability of each…. Exponential complexity But, in worst case you (probably) can’t do any better… Use 3-SAT… Variables V = {X1, X2, …, Xn} Clauses C1 = X17 or ~X23 or ~X3, C2 = ~X2 or X3 or ~X12 …. Cm = X6 or ~X7 or X18 Question Is there an variable assignment A:V {true, false} such that each clause C1, … ,Cm is true? 3-SAT is NP-complete Modeling assignment to variable X XX0 X0 X X X 0 0 0 XX0 X0 X = false X = true SPP Solvability is NP-complete C X7 0 C X5 0 C X3 0 X7 C X7 or X5 or X3 X7 X5 X5 X3 X3 0 BAD GADGET A sufficient condition for sanity If an instance of SPP has an acyclic dispute digraph, then Static (SPP) Dynamic (SPVP) solvable safe (can’t diverge) unique solution predictable restoration all sub-problems uniquely solvable robust with respect to link/node failures Dispute Digraph u v … (u v)P … (u v)Q ... … Q … P ... P Q Gives the dispute arc Q (u v)P 0 Dispute Digraph (cont.) u P v … (u,v)P ... … P ... Gives the transmission arc P (u,v)P 0 Dispute Digraph Example 130 10 210 20 1 2 0 20 10 420 210 3420 3 4 3420 30 420 430 BAD GADGET II CYCLE 430 130 30 PART VII Selected Bibliography Addressing and ASN RFCs • • • • • • • • • • • • • • RFC 1380 IESG Deliberations on Routing and Addressing (1992) RFC 1517Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) (1993) RFC 1518 An Architecture for IP Address Allocation with CIDR (1993) RFC 1519 Classless Inter-Domain Routing (CIDR) (1993) RFC 1467 Status of CIDR Deployment in the Intrenet (1983) RFC 1520 Exchanging Routing Information Across Provider Boundaries in the CIDR Environment (1993) RFC 1817 CIDR and Classful routing (1995) RFC 1918 Address Allocation for Private Internets (1996) RFC 2008 Implications of Various Address Allocation Policies for Internet Routing (1996) RFC 2050 Internet Registry IP Allocation Guidelines (1996) RFC 2260 Scalable Support for Multi-homed Multi-provider Connectivity (1998) RFC 2519 A Framework for Inter-Domain Route Aggregation (1999) RFC 1930 Guidelines for creation, selection, and registration of an Autonomous System (AS) RFC 2270 Using a Dedicated AS for Sites Homed to a Single Provider Selected BGP RFCs Internet Engineering Task Force (IETF) http://www.ietf.org • IDR : http://www.ietf.org/html.charters/idr-charter.html • RFC 1771 A Border Gateway Protocol 4 (BGP-4) • Latest draft rewrite: draft-ietf-idr-bgp4-18.txt • RFC 1772 Application of the Border Gateway Protocol in the Internet • RFC 1773 Experience with the BGP-4 protocol • RFC 1774 BGP-4 Protocol Analysis • RFC 2796 BGP Route Reflection An alternative to full mesh IBGP • RFC 3065 Autonomous System Confederations for BGP • RFC 1997 BGP Communities Attribute • RFC 1998 An Application of the BGP Community Attribute in Multihome Routing • RFC 2439 Route Flap Dampening Titles of Some Recent Internet Drafts • • • • • • • • • • • • • • Dynamic Capability for BGP-4 Application of Multiprotocol BGP-4 to IPv4 Multicast Routing Graceful Restart mechanism for BGP Cooperative Route Filtering Capability for BGP-4 Address Prefix Based Outbound Route Filter for BGP-4 Aspath Based Outbound Route Filter for BGP-4 Architectural Requirements for Inter-Domain Routing in the Internet BGP support for four-octet AS number space Autonomous System Number Substitution on Egress BGP Extended Communities Attribute Controlling the redistribution of BGP routes BGP Persistent Route Oscillation Condition Benchmarking Methodology for Basic BGP Convergence Terminology for Benchmarking External Routing Convergence Measurements BGP is a moving target … Selected Bibliography on Routing • Internet Routing Architectures. Bassam Halabi. Second edition Cisco Press, 2000 • BGP4: Inter-domain Routing in the Internet. John W. Stewart, III. Addison-Wesley, 1999 • Routing in the Internet. Christian Huitema. 2000 • ISP Survival Guide: Strategies for Running a Competitive ISP. Geoff Huston. Wiley, 1999. • Interconnection, Peering and Settlements. Geoff Huston. The Internet Protocol Journal. March and June 1999. 75 BGP Stability and Convergence • Route Flap Damping Exacerbates Internet Routing Convergence. Z.M.Mao, R.Govindan, G.Varghese,R.H.Kranz. SIGCOMM 2002. • The Impact of Internet Policy and Topology on Delayed Routing Convergence. Craig Labovitz, Abha Ahuja, Roger Wattenhofer, Srinivasan Venkatachary. INFOCOM 2001 • An Experimental Study of BGP Convergence. Craig Labovitz, Abha Ahuja, Abhijit Abose, Farnam Jahanian. SIGCOMM 2000 • Origins of Internet Routing Instability. C. Labovitz, R. Malan, F. Jahanian. INFOCOM 1999 • Internet Routing Instability. Craig Labovitz, G. Robert Malan and Farnam Jahanian. SIGCOMM 1997 Analysis of Interdomain Routing • Cooperative Association for Internet Data Analysis (CAIDA) – http://www.caida.org/ – Tools and analyses promoting the engineering and maintenance of a robust, scalable global Internet infrastructure • Internet Performance Measurement and Analysis (IPMA) – http://www.merit.edu/ipma/ – Studies the performance of networks and networking protocols in local and wide-area networks • National Laboratory for Applied Network Research (NLANR) – http://www.nlanr.net/ – Analysis, tools, visualization. • IRTF Routing Research Group (IRTF-RR) • – http://puck.nether.net/irtf-rr/ Geoff Huston: http://bgp.potaroo.net Internet Route Registries • Internet Route Registry – http://www.irr.net/ • Routing Policy Specification Language (RPSL) – RFC 2622 Routing Policy Specification Language (RPSL) – RFC 2650 Using RPSL in Practice • Internet Route Registry Daemon (IRRd) – http://www.irrd.net/ • RAToolSet – http://www.isi.edu/ra/RAToolSet/ Some BGP Theory • • • • • • • – – Persistent Route Oscillations in Inter-Domain Routing. Kannan Varadhan, Ramesh Govindan, and Deborah Estrin. Computer Networks, Jan. 2000. (Also USC Tech Report, Feb. 1996) – Shows that BGP is not guaranteed to converge An Architecture for Stable, Analyzable Internet Routing. Ramesh Govindan, Cengiz Alaettinoglu, George Eddy, David Kessens, Satish Kumar, and WeeSan Lee. IEEE Network Magazine, Jan-Feb 1999. – Use RPSL to specify policies. Store them in registries. Use registry for conguration generation and analysis. An Analysis of BGP Convergence Properties. Timothy G. Griffin, Gordon Wilfong. SIGCOMM 1999 – Model BGP, shows static analysis of divergence in policies is NP complete Policy Disputes in Path Vector Protocols. Timothy G. Griffin, F. Bruce Shepherd, Gordon Wilfong. ICNP 1999 – Define Stable Paths Problem and develop sufficient condition for “sanity” A Safe Path Vector Protocol. Timothy G. Griffin, Gordon Wilfong. INFOCOM 2001 – Dynamic solution for SPVP based on histories Stable Internet Routing without Global Coordination. Lixin Gao, Jennifer Rexford. SIGMETRICS 2000 – Show that if certain guidelines are followed, then all is well. Inherently safe backup routing with BGP. Lixin Gao, Timothy G. Griffin, Jennifer Rexford. INFOCOM 2001 – Use SPP to study complex backup policies On the Correctness of IBGP Configurations. Griffin and Wilfong.SIGCOMM 2002. An Analysis of the MED oscillation Problem. Griffin and Wilfong. ICNP 2002. Pointers • SIGCOMM 2001 Tutorial on BGP: • http://www.research.att.com/~griffin/sigcomm2001_bgp _tutorial/abstract.html • Links on Interdomain routing and BGP: • http://www.research.att.com/~griffin/interdomain.html • Papers on BGP theory: • http://www.research.att.com/~griffin/bgpresearch.html [email protected]