A Measurement Framework for Pin-Pointing Routing

ChangesRenata Teixeira

(UC San Diego)http://www-cse.ucsd.edu/~teixeira

with

Jennifer Rexford (AT&T)

NetTs’04 – Portland, OR

2NetTs’04

Why understand routing changes?

Routing changes cause service disruptions Convergence delay Traffic shift Change in path properties

• RTT, available bandwidth, or lost connectivity

Operators need to know Why: For diagnosing and fixing problems Where: For accountability

• Need to guarantee service-level agreements

3NetTs’04

What can be done with active measurements?

Active measurements: traceroute-like tools Can’t probe in the past Shows the effect, not the cause

User(s)

Web Server

(d)AS 1

AS 2

AS 3

AS 4

4NetTs’04

Can we use passive measurements?

Passive measurements: public BGP data

Data Correlation

BGP update feeds

root causeData Collection

(RouteViews, RIPE)

5NetTs’04

Why Public BGP Data is Not Enough?

Myth: The BGP updates from a single router accurately represent the AS

C

A B

DBGP datacollection

dst

6

12 10

7

AS 1 AS 2

No change

The measurement system needs to capture the BGP routing changes from all border routers

6NetTs’04

Why Public BGP Data is Not Enough?

C

A B

DBGP datacollection

dst

6

12 10

5 7

AS 1 AS 2

Myth:Routing changes visible in eBGP have greater impact end-to-end impact than changes with local scope.

The measurement system needs to capture internal changes inside an AS

7NetTs’04

Why Public BGP Data is Not Enough?

ABGP datacollection

Myth:BGP data from a router accurately represents changes on that router.

12.1.1.0/24

12.1.0.0/16The measurement system needs to know all routes the router knows.

8NetTs’04

Misleading BGP Changes

BGP datacollection

Myth:The AS responsible for the change appears in the old or the new AS path.

1

4

5

6

2 3

7

8

9

10

11

Accurate troubleshooting may require measurement data from each AS

old: 1,2,8,9,10new: 1,4,5,6,7,10

9NetTs’04

Misleading BGP Changes

Myth:Looking at routing changes across prefixes resolves

A B

CBGP datacollection

10

7

AS 1 AS 2

AS 3

d1

d2

d3

12ASes involved in the change need to cooperate to

pin-point the reason for the change

Changes for d2, but not for d1 and d3

10NetTs’04

Strawman Proposal: Omni Server

Creating an AS-level view BGP feeds from all border routers

• Inject all routes known in each router Internal routing data Archive log of routing changes

Responding to queries Local cause: responds directly No local change: query neighbor AS Local change from downstream cause: query old

and/or new neighbor AS

11NetTs’04

Diagnosis with Omnis

i

jOmni 1

Omni 3

Omni 2

Omni 4

User(s)

Web Server

(d)

(i,s,d,t)

(j,s,d,t’)failure link (3,4)

failure link (3,4)

AS 1

AS 2

AS 3

AS 4

12NetTs’04

Conclusion

Passive data AS-level view History (answers in the past) Distributed

Active querying Servers, not routers See cause, not effect

13NetTs’04

Future Directions

How often are the myths violated? Measurement studies of ISP networks

Doesn’t Omni require lots of data? ISPs already collect this kind of data Routing protocols extensions to reveal reasons of routing

changes Will ASes really cooperate?

Pressure to provide service-level agreements Small group of ASes that choose to cooperate

Won’t ASes cheat? Need techniques to detect persistent lying