Presentation on theme: "Advanced Computer Networks cs538, Fall UIUC Klara Nahrstedt Lecture 7, September 16, 2014 Based on M. Caesar, J. Rexford, “BGP Routing Policies."— Presentation transcript:
Advanced Computer Networks cs538, Fall 2014 @ UIUC Klara Nahrstedt Lecture 7, September 16, 2014 Based on M. Caesar, J. Rexford, “BGP Routing Policies in ISP Networks”, IEEE Network, Vol. 19. Issue 6, November/December 2005 Prior 2010-2013, lecture material by Brighten Godfrey and Matt Caesar
Announcements Assignment 1deadline Reading for next time: QoS Routing paper Zheng Wang, Jon Crowcroft, “Quality of Service Routing for Supporting Multimedia Applications”, IEEE Journal on Selected Areas in Communications, Vol. 14, No. 7, September 1996 Proposals for Final Projects Prepare project proposal At most 1 page describing Problem description Steps you plan to take to address the problem Related work (at least 3 full academic papers citations) and why your proposed problem is different than those or why your proposed solution is better. Deadline for proposal: 11:59pm Tuesday, September 23, 2014 Submit project proposal via email to instructor: klara@Illinois.edu (with subject: cs538 – Final Project Proposal) klara@Illinois.edu
Outline Basics about BGP BGP Routing Policies in ISP Networks Current Status
Autonomous System Concept Concept of Group of routers = Autonomous Systems (AS) Choice of AS size – economical, political, technical, admin reasons Routers in Global Internet = divided into groups Two Types of Internet Routing Protocols Interior Gateway Protocols (IGPs) Example: OSPF, MPLS, OpenFlow Intra-domain routing Exterior Gateway Protocols (EGPs) Inter-domain routing AS 1 AS 2 IGP1 used IGP2 used R1 R4 R2 EGP used R3 R5 R6 Intra-domain Routing Inter-domain Routing
Problems for inter-domain routing Scale issues Multiple parties No central control Conflicting interests Greater volume and diversity of attacks Hard to change architecture BGP Solution Born out of need for ISPs to control route selection
Flow of Routes and Data Between ISPs ISP 1 ISP 2 R1 R2 Routes advertised for customers of ISP1 Data to customers of ISP1 Border Router
BGP Characteristics Routing among Autonomous Systems All routes are given as a path of Autonomous Systems Exchange of reachability information across Autonomous Systems Example: Path to a given destination: 17, 2, 56, 12 – path vector BGP does not have any details about routers within each AS on the path Provision for Policies Managers can configure BGP to restrict which routes BGP advertises to outsiders Facilities for Transit Routing BGP classifies each AS as transit system if it agrees to pass traffic through to another autonomous system, or as stub system if it does not Reliable Transport BGP uses TCP for all communication on port 179 BGP speaker sends 19 bytes messages every 30 seconds to maintain connection
Intra and Inter-Domain Routing Metrics One could use throughput, delay, jitter, loss Most Internet routing software does not use any of these metrics Internet typically uses Administrative cost Hop count IGP and EGP differ in routing metrics!!! IGP uses routing metrics EGP does not use routing metrics IGP aims to choose optimal path EGP does not attempt to choose optimal path
Questions about Design Choices Why does BGP use path vector? Would it be beneficial for BGP to know the IGP routing scheme? Why are BGP update messages sent via TCP?
Current Status of BGP Incremental modifications to control routing Complexity addition Unforeseen security vulnerabilities Widespread misconfigurations Conflict between policies at different ISPs Modifications to decision processes Complex decision process Rest of the protocol simple
BGP sessions Sessions are established between border routers that reside at edges of Autonomous Systems Sessions are used to exchange routes between neighboring ASs. Border routers distribute routes to internal routers (via IGP) Each router combines BGP and IGP info to construct forwarding table Mapping of destination prefix to one or more outgoing links along shortest path within ISP to the chosen border router.
BGP Features Incremental Protocol After exchange of complete routing table between neighbors, only changes are exchanged. New advertisements, route withdrawals, change of route attributes Path-vector Protocol Advertisements contain list of ASes to reach destination Prefix level Route Advertisement AS sends a separate update for each of its reachable prefixes BGP Update Messages List of prefixes being advertised List of prefixes being withdrawn List of route attributes that describe characteristics of advertised routes
Selection of Route at BGP Router BGP router may have several alternate routes to a destination If no other policy exists then it selects route with minimum path length But to give ISP operators bigger flexibility and control over route selection, additional attributes were added to advertisements!! BGP Decision Process consists of ordered list of attributes (see table)
Example Topology with Three ISPs A, B, C Multi-Exit Discriminator
BGP Locations of Decision Process Locations where route attribute can be set by policy” Locally LocalPref is an int value set at and propagated through local AS and filtered before sent to neighboring ISP Neighbor MED value indicates which peering link should be used to reach AS advertising the MED attribute Neither Some attributes are set the protocol and can’t be changed (e.g., learned route)
BGP Processing of Route Advertisements Step 1 : Import Policy Determines which routes should be filtered and hence eliminated from consideration Can append or modify attributes Step 2: Decision Process Selects most desirable route Step 3: Export Policy Determines which neighbors the chosen route will be exported to
BGP: The picture at one router “Adj-RIB-In” Import policies Route selection Updates from neighbors Best route for each destination (“Loc-RIB”) prefix next- hop Forwarding table (FIB) in data plane Export policies Updates to neighbors (or not)
Configuring Import and Export Policies Preference influence to chose destination prefix Changing preference is done by adding/deleting/modifying route attributes in BGP advertisements Attributes can be modified during import and export Filtering to eliminate routes and control export Tagging to associate additional state with route Coordination mechanism to coordinate decisions made by group of routers in AS or to share context across AS boundaries Modified during import To control preference locally Modified during export To change how much Neighbor prefers the route
Community Attribute Community representing group of prefixes that share some common property and configured with BGP community attribute Variable-length string used to tag routes Highly expressive mechanism to support variety of policies Example One community value might affect how receiving router sets LocalPref Another community value might cause filtering of route at another router What is the problem with such an expressive mechanism? http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/28784-bgp-community.html
Taxonomy of Policies Business Relationship policy Economic or political relationships Traffic Engineering Control of traffic within ISP and across peering lists to avoid congestion Scalability Reduction of control traffic and avoidance of overloading routers Security-related Policies Protection against malicious or accidental attacks
Business Relationship Customer-Provider One IS pays another to forward its traffic Peer-to-Peer Two ISPs agree to connect to each other mutually benefiting Backup ISPs connect with each other for the event of failure D D A A B B E E destination C C F F
Business relationships (2) Influencing decision via LocalPrefs ISPs often prefer customer learned routes over routes learned from peers and providers Why is this the case? Controlling route export via community attribute Routes learned from providers or peers are usually not exported to other providers or peers because there is no economic incentive for an ISP.
Traffic Engineering Business relationship affects relative preferences for routes, but we may end up with multiple routes equally preferred ISPs want to engineer traffic by modifying preference within the same business class to meet or maximize certain performance criteria (QoS, availability) Outbound traffic control via changing LocalPerf and IGP Configure import policies that affect which routes get in set of equally good border routers Use ‘early-exit routing’ (hot-potato routing) What is the benefit of this routing policy? Use load balancing traffic over several links What are some of the issues with load balancing here?
Traffic Engineering (2) Inbound traffic control The goal is for ISP is to be allowed to control how much traffic it receives from each of its peering links This is a very challenging problem. Why? Possible approaches could be: Modification of MED attribute AS Path-length inflation
Scalability Misconfigurations and faults in neighboring ISPs can lead to Excessive rates of updates Route instability Poor service quality Overload of router’s processing capability or memory capacity Outage and router failures Goals are Limiting routing table size (by filtering and using community attribute) Limiting number of routing changes (by suppressing routes that flap)
Routing Instability Route flapping means frequent shifting of traffic to different paths What are the problems route flapping causes? Key mechanism to improve routing instability is flap damping Flap Damping is Mechanism that limits propagation of unstable routes It works by maintaining penalty value associated with route that is incremented whenever update is received. If penalty surpasses threshold, route is suppressed for some time (unavailable) to decision process
Security False information in BGP updates can be sent due to bugs, misconfigurations We need discard invalid routes via import filtering We need protect integrity of routing policies via rewriting attributes We need secure network infrastructure via export filtering We need blocking denial-of-service attacks via filtering and damping Is Black-hole route approach the only approach?
Conclusions Current version of BGP: Version 4 (BGP4), codified in RFC 4271 since 2006 BGP New Directions Configuration checking tools Language design New architectures
Your consent to our cookies if you continue to use this website.