6.033 | Spring 2018 | Undergraduate

Computer System Engineering

Week 6: Networking Part II

Lecture 10 Outline

  1. Introduction 
    • Today: Routing, some addressing.
    • Enormous growth of Internet => routing protocols redesigned to scale, and also to enforce policy.
    • Problem: DV and LS don’t scale to the Internet.
      • DV = Low overhead, but convergence time is proportional to longest path. Good for small networks.
      • LS = Fast convergence, but high overhead because of flooding. Good for MIT-sized networks, but not the Internet.
  2. (Three Ways We Deal With) Scale 
    • Path-vector routing
      • Like DV, but include the full path in the routing advertisements.  Overhead increases (advs are larger), but convergence time decreases (avoid counting to infinity).
      • Overhead is still lower than LS’s.
    • Routing hierarchy
      • Internet is divided into Autonomous Systems (ASes). ASes are universities, ISPs, government branches, etc. Each AS has a unique ID (its AS number). There are tens of thousands of them (but not billions).
      • Use one routing protocol to route across ASes, and a different protocol to route within ASes.
        • Implies that there are devices on the edge of each AS that can “translate” between or “speak” both protocols.
      • BGP is the path-vector protocol used across ASes.
    • Topological addressing
      • Despite being between ASes, BGP still routes to IP addresses (e.g., to 18.0.0.1, not to AS3).
      • Addresses are given to ASes in contiguous blocks, so that they can be specified succinctly via a particular notation (“CIDR” notation).
      • Keeps advertisements small(er than they would be otherwise).
  3. Policy Routing 
    • ASes also want to implement policy; they want “policy routing”.
    • Policy routing: Switches make routing decisions based on some set of policies set by a human.  Routing protocol must disseminate enough information to enable those policies.
    • What policies are typical in BGP? ASes don’t want to send traffic on a path unless they have financial incentive to do so.
    • Mechanism of enforcement: Selective advertisements. AS1 won’t tell AS2 about a path unless it will make money by letting AS2 use the path.
      • => Each AS will have a different view of the network, and that view will (almost certainly) *not* contain every physical link.
  4. Typical BGP Relationships (which will eventually lead us to typical BGP policies) 
    • Customer/provider
      • Customers pay for access (transit), which the provider provides.
    • Peers
      • Peers provide mutual access to a subset of each other’s routing tables, namely, the subset that contains their transit customers.
      • Why peer? Can save money and improve performance. Sometimes, it may be the only way to connect your customers to some part of the Internet.
      • Why *not* peer? You’d rather have customers.
  5. BGP Relationships => BGP Export Policies 
    • First decision: Which routes do I advertise to which neighbors? These are an AS’s “export policies.”
      • High-level: “Tell everyone about yourself (your internal IPs) and your customers; tell your customer about everyone.”
      • More specifically:
        • Providers export customer’s routes to everyone.
        • A customer exports its provider’s routes to *its* customers.
          • These two should make sense: Since the customer is paying for Internet, the provider should give them a route to as many destinations as possible. Similarly, the provider should allow *other* parts of the network to reach its customers.
        • AS exports *only* customer routes to peers.
          • Why not full table? AS doesn’t want to provide transit for its peers; they’re not paying it for transit.
    • Z will tell X about C; C is a customer of Z, and X and Z are peers.
    • X will tell Z, Y, and T about C1, C2, and C3.
    • Y will tell X about D.
    • X will *not* tell Y about C; it makes no money to provide transit from Y to C.
    • X doesn’t tell Y about T; it would lose money to provide transit from Y to T.
    • In example, Y appears disconnected from part of the network. BGP doesn’t prevent this. In practice, it never happens.
      • Almost every AS is a customer of someone else (i.e., Y would buy transit from someone).
      • Typically: Small ASes buy Internet from Tier-3 ISPs, which buy Internet from Tier-2 ISPs, which buy Internet from Tier-1 ISPs. Tier-1’s are huge; there are only a handful (10-15).
    • Additionally, all Tier-1 ISPs peer with one another. So each Tier-1 ISP can provide global connectivity.
      • This is an example where we need peering in order to reach part of the Internet.
  6. BGP Relationships => BGP Import Policies 
    • If an AS hears about a route to X from multiple neighbors, how does it decide? These are its “import policies.”
    • First: Make money. Prefer routes via customers—which you make money on—to routes via peers —which you don’t make, but don’t lose money on—to routes via providers—which you lose money on.
    • In the case of a tie (which happens often): There are a whole host of other attributes that BGP provides. A common one is AS-hop-count.
    • Each AS sets its own policies.
  7. BGP in Light of Distributed Routing 
    • HELLO protocol: BGP sends KEEPALIVE messages to neighbors.
    • Advertisements: Sent to neighbors. Look different depending on which neighbor.
      • BGP runs on top of TCP, a reliable-transport protocol. Doesn’t have to do periodic advertisements to handle failure. Instead, push advs when routes change.
    • Integration: Via policies described above.
    • Failures: Routes can be explicitly withdrawn in BGP when they fail. Routing loops avoided because BGP is path-vector.
  8. Problems With BGP 
    • Does it scale? Well, it works on the Internet. But…
      • BGP routing tables are getting big (exceeding the amount of memory dedicated to the table in some switches).
      • We see route instability due to misconfigurations or conflicting AS policies. “Route-flap damping” (ignore advs about frequently-changing routes) helps with this, but increases convergence time.
      • ASes can multi-home: Buy Internet from more than one ISP, usually for back-up or load-balancing. More multi-homed networks => bigger routing tables. The load-balancing itself is also tricky.
      • iBGP. An AS actually has multiple BGP routers on its edge, and a protocol called iBGP keeps them all in sync. iBGP requires an AS’s BGP routers to be connected in a complete graph, and so it doesn’t scale particularly well.
      • Basically: Internet has grown enough that scalability of BGP is becoming a concern.
    • Is it secure?
      • Goodness no. ASes can advertise about a prefix that they don’t actually own.
      • Similar problem (and solution) as in DNS. We’ll talk more about it after spring break.
    • Is it secure?
      • The protocol itself: Arguably yes.
      • BGP in practice: No. Again, mo’ money, mo’ problems. Also, human operator error due to the complexity of setting the policies.

Course Info

Instructor
As Taught In
Spring 2018
Learning Resource Types
Lecture Notes
Written Assignments
Projects with Examples
Instructor Insights