Inconsistency between BGP announced paths and actual paths traversed

1
Inconsistency between BGP announced paths and
actual paths traversed

• Presenter Lilian A. Atieno
• Course ECE697C- Fall 2002
• Instructor Professor Linix Gao

2
Outline

• Introduction
• Methodology
• Experiments
• Analysis
• Conclusion

3
Introduction

• How does BGP routing process work?
• Routes are advertised between BGP speakers
• Router updates routing table accordingly
• BGP table consists of
• Adj-RIB-In Routing info learnt from peers
• Loc-RIB Preferred routes selected as best path
  to each available destination based on local
  policies
• Adj-RIB-Out Routing info that BGP speaker has
  selected to advertise to peers.

4
BGP decision process

• Operator configures Input output policy-Engine
  to manipulate path attributes to influence
  decisions.
• This determines actual routes traversed
• Criteria of choosing best route (order of
  preference)
• Ignore inaccessible next hop
• largest weight
• largest local preference value
• shortest AS_PATH
• lowest origin type
• lowest MED value if routes are from same AS
• prefer EBGP paths to IBGP paths
• Shortest internal path inside AS to reach
  destination
• route from BGP router with lowest ROUTER_ID

5
Why is the BGP best path not always the actual
traversed path

• 2 possible reasons
• ISPs routing policies
• Example Route flap damping of unstable routes
• Convergence delay
• BGP table may reflecting a transit routing table

6
Experiment Methodology

• Analyzed BGP tables from several route servers
  and looking glasses for 14 days
• route attributes
• e.g. checked flap statistics, path aggregation
• best paths announced to destinations
  (particularly flapping best paths)
• used trace-route diagnostic tool to verify if the
  best path announced was actually traversed.
• In cases of inconsistencies, followed up on the
  experiment after every 2-3 hours

7
methodology

• Polled ISP operators via email to find out the
  causes of the inconsistencies
• Checked if eventually the best path changed to
  the initial traced route.

8
Evidences of Inconsistencies

• Evidence 1
• IP Address 203.62.252.26
• Best path at time t1
• 7018 1239 4637 1221, (aggregated by 1221
  203.62.252.26), (received used)
• 12.123.196.111 from 12.123.196.111
  (12.123.196.111)
• Origin IGP, localpref 100, valid, external,
  atomic-aggregate, best
• Community 70185000
• Actual path traversed was AS 7018 AS1 AS4637
  AS1221
• Best path at time t2
• 7018 1 4637 1221, (aggregated by 1221
  203.62.252.26), (received used)
• 12.123.21.243 from 12.123.21.243
  (12.123.21.243)
• Origin IGP, localpref 100, valid, external,
  atomic-aggregate, best
• Community 70185000
• Actual path traversed was AS 7018 AS1 AS4637
  AS1221

9

• Evidence 2
• IP address 24.48.8.0
• The actual path taken was
• The best path announced was

10
Analysis of the evidences

• Evidence 1
• The BGP table shown at t1 must have been a
  transit routing table
• Best path changed after BGP updates and it takes
  a duration of time for the internet to converge
  to new routes
• BGP table at t2 must have been the new table
  after internet convergence

11
Cont

• Evidence 2
• The best path to 24.48.8.0/24 (AS7911 AS19548
  AS7843) was listed as one of the flap routes by
  the Oregon router
• Alternate route (AS3356 AS19548 AS7843) was
  therefore used to 24.48.8.0/24
• Next slide shows that best path is flapping

12
(No Transcript)
13
(No Transcript)
14
Conclusion

• Because of convergence delay, the updated best
  path may be used, even though it may not be
  reflected in the BGP table.
• It is not possible to find explicit evidence that
  ISP policies affect route
• The evidence given in the project shows that
  stability of a route plays a role in choosing the
  best path even though its not explicitly listed
  in the BGP decision process