Comp 343/443 Week 11: Nov 5 (Guy Fawkes day) ============================== post-Halloween discussion of zombies (zombie processes) blast: created win/lin servers CIDR BGP RPC linkstate TCP and congestion ============================= Finish CIDR: Longest-match rule and changing providers If A moves from P1 to P2, what changes do P3, P4, etc have to make? CIDR and staying out of jail (allowing change of provider) Providers P0(A,B,C), P1(D,E), P2(F,G) each with customers listed in parentheses. Routing tables assuming each customer gets an address from its provider's block Longest-match allows customers to move without renumbering hidden cost of such moves New case: Providers P0(B,C), P1(A,D,E), P2(F,G) each with customers listed (A has moved from P0 to P1) but now we have addrs unrelated to provider, and so A needs to be entered in every table! /------\ Consider P0---P1---P2 versus P0___P1___P2 router pseudo-hierarchy v. addr-alloc true hierarchy Don't have to agree, but there is a cost for disagreement What if B adds a link to P1, in addition to link to A? How CIDR allows provider-based and geography-based routing provider-based addresses Problems: route asymmetries: we assumed there was a single entry point to each provider, but usually this is false! inefficient routes (send to closest link to dest provider?) A | P1: r1--------r2----+---R3 | | | | | | | | | P2: s1--+-----s2--------s3 | B BGP "MED" value (not defined yet) allows server providers to carry the server's *outbound* traffic! renumbering: threat or menace? [DHCP, NAT] Locators v. EID changing IP addrs midstream geographical addresses minor problems: inefficient paths between close sites. large sites Real issue with geographical routing: who carries the traffic? Provider-based: *business* model jibes with routing model!! New routing picture: destinations are networks, still, but some are organizations and some are major providers, with intermediate nets in between. Sometimes we might CHOOSE whether to view a large net as one unit, or to view it as separate medium-sized subunits (for the sake of visualization, assume the subunits have some geographical nature, or other attribute so that we can treat them as separate destinations. Tradeoff: consolidation => more compact routing table individual subentries => more optimal route selection 2-step routing: when does it NOT find optimal routes? Randall Munroe cartoon =================================================================== BGP Internet routing is large and complex, with different sites having different and sometimes even conflicting goals. Why we need external routing: we can't compare internal metrics with someone else's. It just does not work. Metrics may be based on: hopcount RTT bandwidth cost congestion One provider's metric may even use larger numbers for *better* routes. An Autonomous System is a domain in which one consistent metric is used; typically administered by a single organization. Between AS's we can't use cost info. Lots of problems come up as a result. BGP basics: how AS's actually talk to each other. Autonomous Systems Routing reduced to finding an AS-path! EGP (predecessor to BGP) and tree structure configurable for preferences For each destination: receive lots of routes from neighbors; filter INPUT choose route we will use: eliminate AS_PATH loops apply local preference apply MED break ties by choosing routes through fewer ASs, etc decide whether we will advertise that route: filter OUTPUT Rule: we can only advertise routes we actually use! local traffic v transit traffic configurable for supporting transit routing or not ASpath info, and loop avoidance instability MED values ("multi exit discriminator") BGP: important part of network management at ISP level BGP relationships: ================= customer-provider: provider agrees to handle transit for customer customer advertises its own routes only! siblings: often provide mutual backup; not "normal" transit peers: large providers exchanging all customer traffic with each other advertise all routes to each other * Export ONLY customer routes to other peers * Export all peer routes to its customers In a general sort of way, we advertise routes UPWARDS. Well, provider routes as "big blocks" do get advertised downwards. Every AS exports its OWN routes and OWN customers' routes Internally, we might also rank customer routes over peer routes (illustrate) customers DO NOT export provider/peer routes to providers Providers DO export provider/peer routes to customers (often aggregated) Peers DO NOT export provider/peer routes to each other (Peers (usually) DO NOT provide transit services to third parties.) What if small ISP A connects to providers P1 and P2? A negotiates rules as to what traffic it will send to P1 & what to P2 Then A uses BGP to implement route advertisements (& route learning) A *might* advertise its customers to both P1 and P2. If A "learns" of a route from P1 only, then A will use P1 for routing, even if P2 advertises a route too. This illustrates INPUT FILTERING. siblings DO export provider/peer routes to one another ============ Tier1: about 15 ASs with no providers: AT&T, Sprint, UUNET, ... Transit Core: tier-1s and ASs that peer with those AND EACH OTHER Regional ISPs: ~2000 of them (Rexford notes) Stub AS: no peers, no customers ============= ----ISP1---nwu | |link1 | ----ISP2---luc 1. nwu,luc don't export link1: no transit at all 2. Export but have ISP1, ISP2 rank at low preference: used for backup only; ISP1 prefers route to luc through ISP2 3. Have luc have a path to ISP1 via link1; that won't be used unless luc starts to route to ISP1 via link1, eg if ISP2 reports ISP1 is unreachable... No-valley theorem: at most one peer-peer link; LHS are cust->prov or sib->sib links General ideas about routing * we need aggregated routing for table-size efficiency (desperately!) * there is often a "natural" routing hierarchy, eg provider-based * cidr allows us to allocate addresses consistent with the routing hierarchy * routing "hierarchy" is often just an approximation; there are lots of exception cases that are dealt with via extra table entries. * longest-match is to allow moving in the hierarchy without renumbering, and multi-homing (multiple attachments) to the hierarchy. ======== BGP and MED values