dynamics of hot potato routing in ip networks n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Dynamics of Hot-Potato Routing in IP Networks PowerPoint Presentation
Download Presentation
Dynamics of Hot-Potato Routing in IP Networks

Loading in 2 Seconds...

play fullscreen
1 / 30

Dynamics of Hot-Potato Routing in IP Networks - PowerPoint PPT Presentation


  • 120 Views
  • Uploaded on

Dynamics of Hot-Potato Routing in IP Networks. Jennifer Rexford AT&T Labs—Research http://www.research.att.com/~jrex Joint work with Renata Teixeira (UCSD), Aman Shaikh (AT&T), and Timothy Griffin (Intel). Outline. Internet routing Interdomain and intradomain routing

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Dynamics of Hot-Potato Routing in IP Networks' - mead


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
dynamics of hot potato routing in ip networks

Dynamics of Hot-Potato Routing in IP Networks

Jennifer Rexford

AT&T Labs—Research

http://www.research.att.com/~jrex

Joint work with Renata Teixeira (UCSD), Aman Shaikh (AT&T), and Timothy Griffin (Intel)

outline
Outline
  • Internet routing
    • Interdomain and intradomain routing
    • Coupling due to hot-potato routing
  • Measuring hot-potato routing
    • Measuring the two routing protocols
    • Correlating the two data streams
  • Performance evaluation
    • Characterization on AT&T’s network
  • Implications on operational practices
  • Conclusions and future directions
autonomous systems

Multiple links

Middle of path

Autonomous Systems

4

3

5

2

6

7

1

Web server

Client

AS path: 6, 5, 4, 3, 2, 1

interdomain routing bgp

“I can reach 12.34.158.0/24

via AS 1”

“I can reach 12.34.158.0/24”

2

3

1

12.34.158.5

Interdomain Routing (BGP)
  • Border Gateway Protocol (BGP)
    • IP prefix: block of destination IP addresses
    • AS path: sequence of ASes along the path
  • Policy configuration by the operator
    • Path selection: which of the paths to use?
    • Path export: which neighbors to tell?
intradomain routing igp
Intradomain Routing (IGP)
  • Interior Gateway Protocol (OSPF and IS-IS)
    • Shortest path routing based on link weights
    • Routers flood link-state information to each other
    • Routers compute “next hop” to reach other routers
  • Link weights configured by the operator
    • Simple heuristics: link capacity or physical distance
    • Traffic engineering: tuning link weights to the traffic

2

1

3

1

3

2

1

5

4

3

Path cost: 2+1+5

two level internet routing

inter-domain

routing (BGP)

AS 3

AS 2

intra-domain

routing (IGP)

AS 1

Two-Level Internet Routing
  • Hierarchical routing
    • Intra-domain
      • Metric based
    • Inter-domain
      • Reachability and policy
  • Design principles
    • Scalability
    • Isolation
    • Simplicity of reasoning

Autonomous system (AS) = network

with unified administrative routing

policy (ex. AT&T, Sprint, UCSD)

coupling hot potato routing

packet to dst

10

11

9

failure

planned maintenance

traffic engineering

dst

  • Consequences:
  • Routers CPU overload
  • Transient forwarding instability
  • Traffic shift
  • Inter-domain routing changes

Hot-potato routing = ISPs policy of routing to closest exit point when there

is more than one route to destination

Coupling: Hot-Potato Routing

Routes to thousands

of destinations

switch exit point!!!

Z

X

ISP network

ISP network

Y

bgp decision process

“Equally good”

BGP Decision Process
  • Ignore if exit point unreachable
  • Highest local preference
  • Lowest AS path length
  • Lowest origin type
  • Lowest MED (with same next hop AS)
  • Lowest IGP cost to next hop
  • Lowest router ID of BGP speaker
hot potato routing model

Z

10

X

8

9

9

W

dst

Y

Hot-Potato Routing Model
  • Cost vector for Z: cX=10, cW=8, and cY=9
  • Egress set for dst: {X, Y}
  • Best route for Z: through Y, which is closest

Hot-potato change: change in cost vector causes change in best route

why care about hot potatoes
Why Care about Hot Potatoes?
  • Understanding of Internet routing
    • Frequency of hot-potato routing changes
    • Influence on end-to-end performance
  • Operational practices
    • Knowing when hot-potato changes happen
    • Avoiding unnecessary hot-potato changes
    • Analyzing externally-caused BGP updates
  • Distributed root cause analysis
    • Each AS can tell what BGP updates it caused
    • Someone should know why each change happened
our approach
Our Approach
  • Measure both protocols
    • BGP and OSPF monitors
  • Correlate the two streams
    • Match BGP updates with OSPF events
  • Analyze the interaction

Z

OSPF messages

BGP updates

AT&T backbone

X

M

Y

heuristic for matching

refresh

link failure

weight change

chg cost

chg cost

del

Stream of BGP updates

Heuristic for Matching

Stream of OSPF messages

Transform stream of OSPF

messages into routing

changes

Match BGP updates

with OSPF events that

happen close in time

time

Classify BGP updates

by possible OSPF causes

computing cost vectors
Transform OSPF messages into path cost changes from a router’s perspective

CHG Y, 7

DEL X

1

ADD X, 5

X 5

Y 7

Y 7

X 5

Y 7

X 5

Y 4

Computing Cost Vectors

OSPF routing changes:

Z

1

1

2

1

X

M

2

10

10

2

2

LSA weight change, 10

LSA weight change, 10

LSA delete

1

Y

classifying bgp updates
Classifying BGP Updates
  • Cannot have been caused by cost change
    • Destination just became (un)available in BGP
    • New BGP route through same egress point
    • New route better/worse than old (e.g., AS path len)
  • Can have been caused by cost change
    • New route is equally good as old route (perhaps X got closer, or Y got further away)

M

Z

X

dst

Y

the role of time

10 sec

70 sec

180 sec

The Role of Time
  • IGP link-state advertisements
    • Multiple LSAs from a single physical event
    • Group into single cost vector change
  • BGP update messages
    • Multiple BGP updates during convergence
    • Group into single BGP routing change
  • Matching IGP to BGP
    • Avoid matching unrelated IGP and BGP changes
    • Match related changes that are close in time

Characterize the measurement data to determine the right windows

summary results june 2003
Summary Results (June 2003)
  • High variability in % of BGP updates
  • One LSA can have a big impact
delay for bgp routing change
Delay for BGP Routing Change
  • Router vendor scan timer
    • BGP table scan every 60 seconds
    • OSPF changes arrive uniformly in interval
  • Internal BGP hierarchy (route reflectors)
    • Wait for another router to change best route
    • Introduces a wait for a second BGP scan
  • Transmitting many BGP messages
    • Latency for transferring the data

We have seen delays of up to 180 seconds!

delay for first bgp change

Two BGP scans

Cisco BGP scan timer

Delay for First BGP Change

Fraction of

Hot-Potato Changes

Routers in backbone (June)

Routers in backbone (September)

Router in lab

time BGP update – time LSA (seconds)

transferring multiple prefixes

81 seconds delay

Transferring Multiple Prefixes

Cumulative Number of

Hot-Potato Changes

time BGP update – time LSA (seconds)

bgp updates over prefixes

Contrast with

non-OSPF triggered

BGP updates

prefixes with only

one exit point

OSPF-triggered BGP updates

affects ~50% of prefixes

uniformly

BGP Updates Over Prefixes

Cumulative

%BGP updates

Non-OSPF triggered

All

OSPF-triggered

% prefixes

operational implications
Operational Implications
  • Forwarding plane convergence
    • Accuracy of active measurements
  • Router proximity to exit points
    • Likelihood of hot-potato routing changes
  • Cost in/out of links during maintenance
    • Avoid triggering BGP routing changes
forwarding convergence

Packets to dst may

be caught in a loop

for 60 seconds!

Forwarding Convergence

R1’s scan process

can take up to

60 seconds to run

Scan process

runs in R2

R2 starts using R1 to reach dst

10

R2

R1

111

10

100

dst

measurement accuracy

W1

W2

Measurement Accuracy
  • Measurements of customer experience
    • Probe machines have just one exit point!

loop to reach dst

10

R2

R1

111

100

dst

avoid equal distance exits

Z

Z

10

1

X

X

10

1000

Y

Y

Small changes will make

Z switch exit points to dst

More robust to intra-domain

routing changes

Avoid Equal-distance Exits

dst

dst

careful cost in out links

dst

Careful Cost in/out Links

Z

5

100

5

X

10

10

4

10

Y

Traffic is more predictable

Faster convergence

Less impact on neighbors

ongoing work
Ongoing Work
  • Black-box testing of the routers
    • Scan timer and its effects (forwarding loops)
    • Vendor interactions (with Cisco)
  • Impact of the IGP-triggered BGP updates
    • Changes in the flow of traffic
    • Forwarding loops during convergence
    • Externally visible BGP routing changes
  • Improving isolation (cooling those potatoes!)
    • Operational practices: preventing interactions
    • Protocol design: weaken the IGP/BGP coupling
    • Network design: internal topology/architecture
thanks
Thanks!
  • Any questions?
ibgp route reflectors

dst Y, 18

dst W, 20

dst Y, 21

dst W, 20

dst X,19

dst W, 20

Announcement X

dst

iBGP Route Reflectors

X

Z

9

10

Y

8

11

20

W

Scalability trade-off:

Less BGP state

vs.

Number of BGP updates from Z

and longer convergence delay

exporting routing instability

Announcement

Z

X

Y

Exporting Routing Instability

Z

X

dst

Y

No change => no announcement

dst