A Measurement Framework for Pin-Pointing Routing Changes

Transcription

1 A Measurement Framework for Pin-Pointing Routing Changes Renata Teixeira Univ. Calif. San Diego La Jolla, CA Jennifer Rexfor AT&T Labs Research Florham Park, NJ ABSTRACT Changes in the en-to-en path between two hosts can lea to suen s in the roun-trip time an available banwith, or even the complete loss of connectivity. Determining the reason for the routing is crucial for iagnosing an fixing the problem, an for holing a particular omain accountable for the isruption. Active measurement tools like traceroute can infer the current path between two en-points, but not where an why the path. Analyzing BGP ata from multiple vantage points seems like a promising way to infer the root cause of routing s. In this paper, we explain the inherent limitations of using BGP ata alone an argue for a istribute approach to troubleshooting routing problems. We propose a solution where each AS continuously maintains a view of routing s in its own network, without requiring aitional support from the unerlying routers. Then, we escribe how to query the measurement servers along the AS-level forwaring path from the source to the estination to uncover the location an the reason for the routing. Categories an Subject Descriptors C.2.2 [Network Protocols]: Routing Protocols; C.2.3 [Computer- Communication Networks]: Network Operations General Terms Management,Measurement, Design, Reliability, Performance Keywors Network troubleshooting, root cause analysis, BGP, IGP 1. INTRODUCTION The en-to-en path between two hosts may for various reasons, such as equipment failures an configuration s. In aition to transient isruptions uring routing convergence, the new path may have a larger roun-trip time, lower available banwith, smaller maximum transmission unit, more aggressive packet filtering policies, or a forwaring loop or blackhole that rops packets. When multiple estinations experience routing s at the Permission to make igital or har copies of all or part of this work for personal or classroom use is grante without fee provie that copies are not mae or istribute for profit or commercial avantage an that copies bear this notice an the full citation on the first page. To copy otherwise, to republish, to post on servers or to reistribute to lists, requires prior specific permission an/or a fee. SIGCOMM 0 Workshops, Aug. 30+Sept. 3, 200, Portlan, Oregon, USA. Copyright 200 ACM X/0/ $.00. same time, the large shift in traffic may overloa one or more links in an IP backbone network. Knowing why the routing happene is necessary for network aministrators to iagnose an fix persistent reachability problems, or to tune the configuration of the routing protocols to rebalance the traffic loa. Determining where the routing originate is crucial for having greater accountability for service isruptions in the Internet. Such accountability is important for compensating en users for violations of service-level agreements an for helping network aministrators select goo upstream proviers an peers. In this paper, we propose a measurement framework for pin-pointing the causes of routing s. Active measurement tools such as traceroute [1] seem like the most natural way to iagnose a routing. However, traceroute returns inconsistent results for paths that are changing uring the measurement process; in aition, some routers o not sen ICMP replies an many firewalls iscar the probe packets. Also, ientifying the Autonomous System (AS) associate with each hop in the path is surprisingly ifficult [2]. The future eployment of more sophisticate router-level support for active measurement (e.g., the IP Measurement Protocol [3, ]) may resolve some of these issues. However, active measurement provies a view of a path only at the time the probes are sent, requiring a high probe rate to track routing s. More importantly, active measurements alone only reveal what part of a path has an where packet elay, loss, or reorering occur [, 6], but not necessarily what cause the route to an where the originate. An alternate approach is to exploit publicly-available passive measurements of routing s in the Borer Gateway Protocol (BGP). Each RouteViews [] an RIPE-NCC [8] fee logs the avertisement an withrawal messages receive via an external BGP (ebgp) session with one router in a participating AS. Recent stuies have propose looking for patterns across AS paths, estinations, an time to pin-point the location an cause of routing s [9, 10, 11]. However, a single topology or configuration can lea to numerous patterns of upates, an multiple events coul lea to the same sequence of routing messages [12]. Combining ata from multiple vantage points reuces the uncertainty but the approach is still fraught with ifficulty because some routing s are not visible in BGP an others can lea to misleaing BGP messages. One of the main contributions of this paper is to ientify these problems an erive guielines for iagnosing routing s, as iscusse in Section 2. We argue that it is possible to use passive measurements for iagnosing routing problems if each AS contributes by solving its part of the puzzle. In Section 3, we present a strawman proposal where each AS constructs a view of its part of the routing system base on ata reaily available from toay s routers router configuration state, BGP upate messages from borer routers, the up/own

2 status of BGP sessions, an intraomain routing messages. The AS uses the information to etermine whether a routing was triggere by an internal or external cause. Rather than sening raw ata to a central repository, an AS accepts queries from neighboring omains about past routing s. To iagnose external routing s, an AS may forwar a query to the next AS in either the ol or the new forwaring path. Our propose scheme can be viewe as an approach to the Why problem articulate in [13] or to the automatic error reporting scenario in []. In particular, we show how to answer questions like why i the forwaring path to estination? The paper conclues in Section with iscussion of future research irections. 2. PUBLIC BGP DATA IS NOT ENOUGH This section highlights the challenges of fining the root cause of routing s through analysis of BGP upate ata alone. We iscuss why some plausible assumptions o not hol uner certain scenarios. In particular, we show that (i) many routing s are not visible in the BGP ata an (ii) a partial view of the BGP ata may lea to inaccurate conclusions, an erive principles that guie our approach in the next section. 2.1 Routing Changes Not Visible in ebgp ASes in the core of the Internet usually connect to multiple neighboring ASes, an two ASes may connect in multiple physical locations. Routers at the borer of a network learn how to reach external prefixes by speaking external BGP (ebgp) with routers in neighboring ASes. Upon selecting an externally-learne route, the borer router uses internal BGP (ibgp) to istribute the route to the other routers insie the AS. BGP is responsible for (i) etermining the AS-level route to reach a estination prefix an (ii) for each router in an AS, selecting the best egress point for forwaring traffic towar that estination prefix. The internal path from the ingress point to the egress point is etermine by an Interior Gateway Protocol (IGP), such as OSPF or IS-IS. In this subsection, we iscuss three myths that relate to how routing s insie an AS may impact the forwaring path without being visible via an ebgp monitoring session. MYTH: The BGP upates from a single router accurately represent the AS. The routers an in Figure 1 learn how to reach estination prefix through ebgp an propagate that information via ibgp to all other routers in AS 1. A router invokes the BGP ecision process [1] to select a single best route for the prefix. The first few steps of the ecision process compare the BGP attributes, such as local preference an AS path length, of the caniate routes. Next, the router prefers an ebgp-learne route over any ibgp-learne routes. Still, multiple equally-goo choices may remain. For example, in Figure 1, the routes from an look equally attractive to router. breaks the tie by selecting the BGP route with the closest egress point the router with the smallest IGP path cost (i.e., router with cost of ). Such a routing ecision is commonly calle hot-potato routing. Hot-potato routing implies that ifferent routers in an AS may pick ifferent BGP-level routes. For example, picks the ebgp route through AS 3. Router learns two equally-goo ebgp routes an chooses (say) the one via AS 2 base on an arbitrary tie break, such as the router i. Base on hot-potato routing, router selects the route through an router selects the route through. As such, BGP ata collecte from woul only reveal the route via AS 3. Now suppose that a failure occurs on the link connecting router to AS 2. Then, both an woul switch to the route via AS 3, which may lea to a in the properties of the ento-en paths for traffic entering AS 1 at router. However, the link failure oes not cause a in the BGP route at an, as such, the is not visible to the measurement system. IMPLICATION 1. The measurement system nees to capture the BGP routing s from all of the borer routers. AS 2 6 A C failure 12 AS 1 AS 3 10 B D before after BGP ata collection Figure 1: BGP s are not etecte at ata collection point. MYTH: Routing s visible in ebgp have greater en-toen impact than s with local scope. IGP an ibgp s may have a significant influence on ento-en performance without causing any ebgp-visible routing. In Figure 1, router has three internal paths to reach two via egress point (with IGP costs of an, respectively) an one via egress point (with cost ). Due to hot-potato routing, selects the route through with cost. Even if a link fails on the shortest path, continues to use egress point, though packet forwaring shifts to the path with cost. This oes not cause an ibgp routing, let alone an ebgp-visible. Yet, if the path with cost has low available banwith or a high roun-trip time, the effects on user performance might be significant. Suppose now that a link failure makes all paths from to have an IGP cost higher than. Then, router switches to the BGP route with egress point. However, this ibgp routing may or may not be visible in ebgp. If were routing traffic via AS 3, then s new best BGP route woul have the same AS path as the ol one. Uner the common practice of non-transitive attribute filtering, router woul not sen a new ebgp avertisement to its neighbors. However, if were routing traffic via AS 2, router woul nee to sen an ebgp upate to its neighbors upon switching egress points. Either way, the traffic entering the AS at may experience a noticeable in performance properties. IMPLICATION 2. The measurement system nees to capture IGP an ibgp routing s insie an AS. MYTH: BGP ata from a router accurately represents routing s on that router. Network operators often configure their BGP-speaking routers to limit the scope of avertisements for subnets of larger aress blocks, in orer to limit the size of the BGP routing tables [1]. In Figure 2, router is an access router that connects to several customer networks that have been assigne aress blocks out of the larger prefix. For example, may have a static route irecting traffic for through the access link to a specific customer. Router oes not nee to avertise the route to any other routers insie the AS, or to routers in other omains; instea, simply avertises reachability to the supernet. Even a BGP fee collecte irectly from router

3 woul not reveal the existence of the subnet or any chang es in the reachability of this subnet. For example, following a failure of the customer s access link, the forwaring path of traffic estine to aresses in woul terminate at. Yet, the BGP monitoring system woul not observe any routing /2 A BGP ata collection B /16 Figure 2: Subnet /2 at router is not visible in BGP In aition to the example in Figure 2, other prefixes may be invisible ue to the BGP export policies applie on the monitoring session. For example, an AS may export customer-learne routes to a public monitoring system but not the routes learne from private peers; often the exact etails of which routes an AS exports to the RouteViews an RIPE-NCC monitors are unknown. IMPLICATION 3. The measurement system nees to know all routes the router knows, even if they are not normally visible in ebgp. 2.2 Misleaing BGP Changes Recent stuies [9, 10, 11] propose techniques for analyzing patterns in the BGP upates from multiple vantage points to infer the location an cause of routing s. The algorithms cluster the ata by time, prefix, an AS path to iscover common explanations for a set of BGP upates. The accuracy of these techniques epens on the completeness of the input ata. In this subsection, we iscuss how partial BGP ata can lea to incorrect iagnosis of a routing. MYTH:The AS responsible for a BGP routing appears in the ol or the new AS path [9, 10, 11]. The inference algorithms buil on the assumption that the AS responsible for a routing appears in either the ol path, the new path, or both. However, this may not hol when some of the ASes in the forwaring path o not contribute BGP fees. In the example in Figure 3, suppose that the sieways links between these ASes are private peering links, where each AS exports only the BGP routes learne from its ownstream customers [16]. All other links in the system correspon to provier-customer relationships where each AS exports its best route for each prefix. For simplicity, assume that each AS selects the BGP route with the shortest AS path, among the choices learne from the neighbors. In Figure 3(a), ASes,, an all choose the path through AS ; in particular, AS prefers the path through AS 2 over the longer path via AS. Now, suppose that AS 11 becomes a customer of AS 3, as shown in Figure 3(b). In response to this event, AS 3 now selects the new shorter AS path through AS 11 an announces the new path to AS 2. AS 2 prefers the new path over the ol path through AS 8 an starts irecting traffic via AS 3. This causes AS 2 to withraw the BGP route it ha avertise earlier to AS 1. Note that AS 2 oes not avertise the new route to AS 1 because of the export policy (i.e., o not export a route learne from one peer to another ). This causes AS 1 to switch to the longer customer-learne route via AS, as shown in Figure 3(b). Base only on BGP ata from ASes 1,,, 6, an, the inference algorithm woul only see the withrawal of the BGP route via AS 2. From AS 1 s vantage point, the AS path s from to ASes (a) Before (b) After Figure 3: AS causing the routing is not in the ol or new AS paths an 11 o not appear anywhere in either the ol or new paths. Collecting measurement ata from more vantage points woul reuce the likelihoo of these kins of problems, but knowing how many vantage points are truly necessary is ifficult without full knowlege of the AS graph an the routing policies. IMPLICATION. Accurate troubleshooting of routing s may require measurement ata from each AS. MYTH: Looking at routing s across prefixes resolves ambiguity about the origins of a routing. The inference algorithms narrow own the origin of a routing by ientifying the common attributes for prefixes that experience a routing close together in time. In Figure, suppose that each AS has a shortest AS path routing policy. Router in AS 1 has two BGP-learne routes to reach estination an initially selects egress point because of hot-potato routing. If the cost of the IGP path from to increases to, then woul select egress point to route to. In contrast, the BGP routes for an woul not because AS 1 has a single egress point for reaching each of these estinations. 1 AS 2 A 2 AS AS 3 AS C 3 10 B before after BGP ata collection Figure : Internal routing affecting only estinations in AS This hot-potato routing coul be misleaing to an external observer. If AS originates multiple estinations, the BGP upate stream from woul show many routes changing AS paths from 1 2 to 1 3. This woul suggest that one of the four ASes is involve. By looking across all prefixes, the observer woul see that all estinations originate by AS shift at the same time, an those originate by ASes 2 an 3 o not. This coul lea to the incorrect inference that AS (or the link between AS an AS 2) is responsible for the. Large hot-potato routing s (such as reporte in [1]) may also be mistakenly associate with a BGP session reset in one of the links in the AS path. IMPLICATION. The ASes involve in the routing shoul cooperate to pin-point the reason for the routing.

4 MYTH: The BGP signaling path is an accurate representation of the AS-level forwaring path. Analysis of s in the BGP AS paths oes not necessarily she light on the s in the forwaring path because the two paths o not necessarily match [2]. For example, route aggregation may result in a BGP AS path that oes not inclue the AS(es) at the en of the forwaring path. In aition, the ibgp configuration insie an AS may lea to packet eflections where one router forwars a packet to another router that has a ifferent AS path for the same prefix [18]. These eflections may in fact be the root cause of a routing anomaly, making it important to have an accurate view of the real forwaring path. Finally, configuration mistakes (whether acciental or intentional) can lea to an incorrect BGP AS path. For example, an operator may configure a router to perform AS prepening (the common practice of aing artificial hops in the BGP AS path) with the wrong AS number. This can lea to a BGP AS path that bears little resemblance to the actual AS-level forwaring path. These mismatches between the two paths can lea to faulty conclusions. For example, real s in the forwaring path might not be visible as BGP routing s, an vice versa. Fortunately, each AS has enough internal information to know the next-hop AS in the AS-level forwaring path. IMPLICATION 6. Troubleshooting of routing s nees to propagate hop-by-hop along the AS-level forwaring path. The accuracy of ientifying the root cause of routing s using public BGP ata epens on how often these myths are violate an how much coverage is nee to get accurate results. Valiating these hypothesis requires further research, using exactly the ASlevel measurements that we propose in the next section. 3. PIN-POINTING ROUTING CHANGES We raw on the insights learne from the previous section to sketch a istribute troubleshooting service. Implications 1 an 3 imply that we nee a better source of ata that represents the ASlevel BGP routing ecisions (an AS-level forwaring table, if you will), an Implication 2 suggests that we also nee to keep track of internal s. In this section, we propose that each AS have an Omni server that constructs a comprehensive view of its part of the routing system 1. Implications an imply the nee for cooperation of the ASes involve in a routing. Thus, the Omni in one AS may nee to contact Omni servers in other ASes. Implication 6 suggests that the query resolution shoul follow the forwaring path; hence the Omni may launch a query to the next AS in the ol or new forwaring path to the estination. After escribing how the Omni server constructs the AS-level forwaring table an maintains the local routing state of the AS, we iscuss the hop-by-hop propagation of queries. We en this section with a brief iscussion of irections for future research. 3.1 AS-level Forwaring Table We efine an AS-level forwaring table as a mapping from prefixes to egress sets, where an egress set is the set of outgoing links that the borer routers in the AS use to reach the prefix. The Omni nees to buil an AS-level forwaring table to: (i) ientify routing s at the ege of the AS an (ii) etermine which neighboring ASes to query about routing s cause by external events. For example, in Figure 1, the Omni for AS 1 woul compute the egress set! " $#%&' ( ) *#+&", for estination prior to the - The name Omni is meant to capture the fact that the server is omniscient about the routing state in the omain. failure of the link to AS 2. After the failure, the set woul to!. *#%&' / " *#0&",. Instea of keeping all BGP upate messages, the Omni only maintains a log of s to the egress set. For example, the Omni woul not nee to retain information about BGP upates that a ownstream AS in the AS path or other route attributes. To compute egress set s, the Omni collects ibgp upates from all borer routers 2. Then, the Omni gathers the best routes for each borer router to etermine the egress set for each estination prefix. The AS-level forwaring table inclues all prefixes known at the router, in orer to avoi the kins of problems epicte in Figure 2. This is accomplishe by configuring the ibgp session to the Omni server to inject all routes that a router learns, incluing static routes (which might not normally be injecte in to BGP) an subnets that woul normally have limite scope. The Omni can then o an on-line pre-processing of this more complete BGP upate streams to compute the egress set for each prefix an store s to this set with a timestamp. This ataset represents the AS-level view of external routing s an coul conceivably serve as an improve fee to public BGP repositories such as RouteViews or RIPE-NCC. Currently, RouteViews an RIPE-NCC receive an ebgp upate stream from an iniviual router in the AS. Toay, these ebgp streams exclue prefixes that are not injecte into BGP. In aition, there is no ifferentiation between internally an externally learne routes, an no information about routing s that are subject to non-transitive attribute filtering. 3.2 Ientifying Local Routing Changes The Omni server also nees to keep track of local routing state the egress point selecte by each router for each prefix, the forwaring path through the AS, an the routing s cause by this AS. We efine a subpath as the part of the forwaring path from the ingress router to the outgoing ege link connecting to the next AS. The Omni is responsible for etermining whether a subpath has (local effect) an whether the AS was responsible for this (local cause). Upon etecting a performance or reachability problem, the source asks its local Omni if a routing has occurre. In particular, the source 1 asks the Omni if ingress router 2 ha any routing to estination aress aroun time 3. The Omni etermines if the subpath for (2, ) an whether the cause was local or not, using the ecision tree presente in Figure. First, the Omni searches for a in the egress set for close to time 3. Upon etecting an egress-set, the Omni etermines that the routing ha local cause if there was either a policy or an ege (i.e., an ebgp session failure or a for a subnet not normally injecte in BGP) consistent with the routing. Otherwise, the routing has an external cause. If the egress set for has not, the Omni etermines whether the subpath from 2 to has by examining both ibgp an IGP routing information for local causes. The ecision tree epens on the kins of measurement ata that are routinely collecte for network management purposes: Policy s: The Omni extracts the AS s policies from snapshots of the router s configuration state every time there is a. In practice, s occur infrequently. BGP session status: The status of BGP sessions can be obtaine Routers o not nee to forwar routes learne via ibgp, since the Omni learns these routes irectly. That is, the Omni shoul be configure as an ibgp peer of each borer router, rather than a route-reflector client. This substantially reuces the number of BGP upates receive by the Omni.

5 policy local cause egress set ege local cause Was there a subpath? internal local cause external not local cause no not local cause Figure : Omni ecision tree for classifying s in a subpath s 1 (i,s,,t) failure link (3, ) Figure 6: i AS 1 Omni 1 2 (j,s,,t ) j Omni 2 AS 2 new path ol path AS 3 Omni 3 3 failure link (3, ) Omni AS forwaring path Omni query/response Collection of Omni servers iagnosing a routing by either SNMP ata or the venor-specific syslog. The status of ibgp sessions is use to etermine the propagation of BGP routes insie the AS, whereas the status of ebgp sessions is use to ientify ege s. IGP s: An IGP routing monitor [19] can continuously track the topology (routers an links) an the IGP parameters (such as link weights). This enables the Omni to learn about s in the forwaring paths between pairs of routers insie the AS, as well as the IGP path costs that influence the BGPlevel routing ecisions. The Omni ignores messages, such as refresh an uplicate IGP messages, that o not inicate a routing. The Omni can use the egress sets, ibgp session status, an IGP ata to compute the subpath for each ingress router an estination prefix, using the moel presente in [20, 21]. 3.3 Inter-AS Coorination Imagine that source 1 in Figure 6 is communicating with estination when the link between ASes 3 an fails. Source 1 asks 3 Omni 1 if the ingress router 2 ha any routing to estination aroun time 3. Following the ecision tree in Figure, Omni 1 etermines that the egress set because the BGP route through AS 3 was withrawn. Recognizing that the local routing ha an external cause, Omni 1 queries Omni 3 for the reason of router 6 s to estination at the time it learne of the egress set. Omni 3 uses its own ata to etermine that the failure of the ebgp session to AS cause the routing, an respons to Omni 1, which in turn respons to 1. The Omni ecies how to respon to a query by ientifying (i) whether the subpath s (local effect) an (ii) whether the AS is responsible for the (local cause): Local effects an local cause: When the AS is responsible for For instance, ISPs coul provie a Web interface for customers to initiate troubleshooting requests. the routing, the Omni respons irectly to the query with an explanation. Local effects an non-local cause: When the local routing has an external cause, the Omni examines the egress-set to etermine which neighboring ASes to query the neighbor in the ol subpath, the new subpath, or both. In the earlier example in Figure 3 in Section 2.2, the Omni in AS 1 woul query the Omni AS 2 (along the ol path, which has isappeare) which woul, in turn, query the Omni in AS 3 which coul explain the routing. No local effects: If the Omni observes no local routing, then the must have an external cause. The Omni simply irects the query to the next AS in the forwaring path; since the local subpath has not, both the ol an the new neighbor ASes are the same. If the query reaches the AS responsible for the estination IP aress, the Omni for that AS coul optionally initiate a reverse query towar 1 to etermine whether a routing occurre on the path from to 1. In [], Bennett escribes a scenario for automatic network error correction that resembles the behavior escribe here. Using IPMP, a user ientifies the last working AS in the forwaring path an issues a trouble report to that AS. In this scenario, the responsibility of iagnosing the problem falls to the AS where the effect of the problem is observe, not the one that cause the routing. This AS oes not necessarily have enough information to iagnose the problem. In our approach, queries are propagate via Omni servers in the ASes along the forwaring path, rather than through the forwaring-plane itself. Our approach avois the expense of placing new functionality in the forwaring plane an allows the queries to access a wier range of information about the ol an new forwaring paths to pin-point the location an cause of a routing. 3. Challenges for Distribute Diagnosis Our troubleshooting scheme raises several important practical issues that warrant further iscussion an investigation: Reachability of Omni servers: We envision that each en host woul know the name or IP aress of the Omni servers in its own omain, an that each Omni server woul know the IP aresses of the Omnis in neighboring ASes; we o not expect that this information woul nee to often. For simplicity, the borer routers in one AS coul be configure with static routes to irect packets sent to an Omni via the ege links connecting to the neighboring AS. We envision that an AS woul have multiple Omnis in ifferent locations to reuce the likelihoo that the very failure that causes a routing problem for en users compromises access to the troubleshooting service. Scalability of Omni servers: An Omni coul be overwhelme by attack traffic or even legitimate queries. An AS can install packet filters on its ege links that iscar all packets estine to the Omni that o not have a source aress corresponing to an Omni in the neighboring omain. To prevent excessive queries, the ege links coul impose a rate limit on traffic from each sener. In some cases, a high query rate may be inicative of a legitimate routing problem affecting multiple users. An Omni coul coalesce relate queries or return cache results without contacting the next AS in the path. In fact, the large number of (relate) queries might provie valuable hints about the scope of a routing problem. Time interval of a routing : The initiator of a query can provie a time interval when a routing may have occurre. An Omni along the query path may refine the time interval base

6 on its own measurement ata. The measurements may reveal that multiple 8 routing s occur close together in time (e.g., uring BGP path exploration uring elaye convergence [22]). We envision that the Omni woul answer queries about s from one stable route to another, rather than reporting the short-live routes uring the transition. The Omni also nees to keep track of prefixes with routes that flap continuously to respon to queries about these estinations. Incentives for ASes to participate: Our troubleshooting service epens on the participation of many, if not all, of the ASes in the core of the Internet. The cooperation of stub ASes woul be valuable, too, to iagnose routing problems originating insie these networks. We believe ISPs woul want to provie a troubleshooting service to their customers as part of a service-level agreement (SLA). These ISPs woul nee to have similar arrangements with their peers an upstream proviers to ensure accountability for network isruptions. In fact, a collection of ASes (e.g., run by one company or consortium) coul provie an SLA only for IP traffic that stays within the group of ASes, allowing for a partial eployment of Omnis. In a competitive environment, separate mechanisms are necessary to prevent ASes from proviing inaccurate responses to queries. An AS coul use its own BGP upate ata to valiate the responses sent by a neighbor s Omni. More generally, thir parties coul use traceroute or BGP upate ata to etect persistently suspicious responses.. CONCLUSIONS Ientifying the location an cause of routing s is crucial for troubleshooting performance an reachability problems. Currently available measurement ata, such as traceroute probes an public BGP upate fees, are not sufficient. Instea, we believe that the infrastructure shoul have irect support for the iagnosis of routing problems. We argue that each AS shoul have an Omni server that constructs a network-wie view of its part of the Internet routing system an answers (an forwars) queries about possible routing s. The Omni coul also store information about the MTU size an packet filter for each link to iagnose other kins of reachability problems. In aition, with traffic measurements from the ege links, the Omni server coul etect shifts in incoming traffic an query the preceing omain about the. Although our solution oes not rely on special support from the network, extensions to the routers such as propose in IPMP woul make the problem easier to solve. Ieally, each router woul have a special monitoring session that provies a view of all of the routes it learns (incluing alternate BGP routes as well as routes not injecte into BGP), the ynamic status of its routing protocol ajacencies (e.g., for OSPF ajacencies an BGP sessions), an an explanation for local routing s (e.g., local policy, withrawal of best route by a neighbor, etc.). More generally, we believe that extening the routing protocols to reveal the unerlying reason for a routing is a promising avenue for future work. Acknowlegments We woul like to thank Jay Borkenhagen for his invaluable insights about the challenges of iagnosing routing problems in prouction networks. Thanks also to Christophe Diot, Geoff Voelker, an the anonymous reviewers for their helpful comments. Renata Teixeira was supporte by a fellowship from Capes/Brazil an by AT&T s support for the UCSD Center for Networke Systems.. REFERENCES [1] V. Jacobson, Traceroute. ftp://ftp.ee.lbl.gov/traceroute.tar.gz. [2] Z. M. Mao, J. Rexfor, J. Wang, an R. H. Katz, Towars an accurate AS-level traceroute tool, in Proc. ACM SIGCOMM, August [3] A. McGregor an M. Luckie, IP measurement protocol (IPMP). Internet Draft, raft-mcgregor-ipmp-0.txt, February 200. [] J. Bennett, The case for an Internet Measurement Protocol, November posting on the Internet Measurement Research Group, org/mail-archive/working-groups/imrg/ current/msg001.%html. [] N. Feamster, D. Anerson, H. Balakrishnan, an F. Kaashoek, Measuring the effects of Internet path faults on reactive routing, in Proc. ACM SIGMETRICS, June [6] R. Mahajan, N. Spring, D. Wetherall, an T. Anerson, User-level Internet path iagnosis, in Proc. ACM SOSP, October [] Route Views. [8] RIPE NCC RIS. [9] D.-F. Chang, R. Govinan, an J. Heiemann, The temporal an topological characteristics of BGP path s, in Proc. IEEE ICNP, November [10] M. Caesar, L. Subramanian, an R. H. Katz, Towars localizing root causes of BGP ynamics, Tech. Rep. CSD , UC Berkeley, November [11] A. Felmann, O. Maennel, Z. M. Mao, A. Berger, an B. Maggs, Locating Internet Routing Instabilities, in Proc. ACM SIGCOMM, September 200. [12] T. G. Griffin, What is the soun of one route flapping?. presentation at the Network Moeling an Simulation Summer Workshop, [13] D. Clark, C. Partrige, J. C. Ramming, an J. Wroclawski, A knowlege plane for the Internet, in Proc. ACM SIGCOMM, August [1] A Borer Gateway Protocol (BGP-). Internet Draft raft-ietf-ir-bgp-2.txt, work in progress, November [1] E. Chen an J. Stewart, A Framework for Inter-Domain Route Aggregation, RFC 219, IETF, February [16] G. Huston, Interconnection, peering, an settlements, in Proc. INET, June [1] R. Teixeira, A. Shaikh, T. Griffin, an J. Rexfor, Dynamics of hot-potato routing in IP networks, in Proc. ACM SIGMETRICS, June 200. [18] T. G. Griffin an G. Wilfong, On the correctness of IBGP configuration, in Proc. ACM SIGCOMM, August [19] A. Shaikh an A. Greenberg, OSPF monitoring: Architecture, esign, an eployment experience, in Proc. USENIX/ACM NSDI, March 200. [20] N. Feamster, J. Winick, an J. Rexfor, A moel of BGP routing for network engineering, in Proc. ACM SIGMETRICS, June 200. [21] A. Felmann, A. Greenberg, C. Lun, N. Reingol, an J. Rexfor, NetScope: Traffic engineering for IP networks, IEEE Network Magazine, pp , March [22] C. Labovitz, A. Ahuja, A. Bose, an F. Jahanian, Delaye Internet routing convergence, IEEE/ACM Trans. on Networking, June 2001.