Presentation is loading. Please wait.

Presentation is loading. Please wait.

Internet Routing Instability Craig Labovitz G. Robert Malan Farnam Jahanian Presenters: Supranamaya Ranjan Mohammed Ahamed Appeared: SIGCOMM ‘97.

Similar presentations


Presentation on theme: "Internet Routing Instability Craig Labovitz G. Robert Malan Farnam Jahanian Presenters: Supranamaya Ranjan Mohammed Ahamed Appeared: SIGCOMM ‘97."— Presentation transcript:

1 Internet Routing Instability Craig Labovitz G. Robert Malan Farnam Jahanian Presenters: Supranamaya Ranjan Mohammed Ahamed Appeared: SIGCOMM ‘97

2 Internet Structure Many small ISP’s at lowest level Small number of big ISP’s at core

3 The Core of the Internet Verio UUNet Sprint rice.edu Routing done using BGP at core Inter-domain routing could be RIP/OSPF etc

4 BGP Overview Verio UUNet Sprint 128.42.x.x 196.29.x.x 128.42.x.x 100.100.x.x 196.29.x.x 92.92.x.x 100.100.x.x 196.29.x.x 92.92.x.x

5 BGP Overview (contd.) Similar to Distance Vector routing Path Vector protocol Loop detection done using AS_PATH field Peering session (TCP) R1R1 R2R2 Exchange full routing table at start Updates sent incrementally

6 Key Point The volume of BGP messages exchanged is abnormally high Most messages are redundant / unnecessary and do not correspond to and topology or policy changes

7 Consequence: Instability Normal data packets handled by dedicated hardware BGP packet processing consumes CPU time Severe CPU processing overhead takes the router offline Route Flap Storm: C B A Router A temporarily fails When A becomes alive B & C send full routing tables B & C fail…cascading effect How do we avoid /lessen the impact of these problems?

8 Route Dampening Router does not accept frequent route updates to a destination Might signal that network has erratic connectivity Increment counter for destination when route changes Counter exceeds threshold stop accepting updates Problem: Future legitimate announcements are accepted only after a delay Decrement counter with time

9 Prefix Aggregation/Super-netting Core router advertises a less specific network prefix Reduces size of routing tables exchanged Problems: - Internet addresses largely non-hierarchically assigned Prefix aggregation is not effective because: - 25% of prefixes multi-homed - Multi-homed prefixes should be exposed at the core - Domain renumbering not done when changing ISP’s

10 Route Servers O(N) peering sessions per Router 1 peering session per router Route Server In-spite of all these measures the BGP message overhead is unexpectedly high

11 Evaluation Methodology Data from Route Server at M.A.E west (D.C) peering point Peering point for more than 60 major ISP’s Time series analysis of message exchange events Nine month log

12 Observation: Lot’s of redundant updates Duplicate route with-drawls Number of With-drawlsUniqueISP A232764344 F8641712435 I247902314112 Ratio 5 7 175 One Reason: - Stateless BGP - No state of previous with-drawls maintained

13 Observation: Instability Proportional to Activity After removing duplicate messages: Time of day Lesser messages Lesser messages 10:00 AM ISP infrastructure up-grade Instability density with time 6:00 12:00 18:00 24:00

14 Evidence from Fine Grained Structure Conjecture: BGP packets are competing with data packets during high bandwidth activity. Number of instability events Frequency (1/hour) 7 days 24 hours Power spectral density

15 Observation: Instability & size uncorrelated ISP’s serving more network prefixes may not contribute more to instability AADiff Proportion of routing table Proportion of announcements WADup Proportion of routing table Proportion of announcements WADiff Proportion of routing table Proportion of announcements

16 Observation: Instability distributed over routes 75% median 20% to 90% of routes change 10 times or less No single route contributes significantly to instability 10 # of announcements per prefix+AS Cumulative proportion

17 Observation: Synchronized updates Inter-arrival times of updates shows periodicity 30 s and 1 minute patterns Some routers collect and send Updates once every 30 s Routers get synchronized Possible reasons: Border router- Internal router: interaction misconfigured?? AADiff Inter Arrival Time distribution for AADiff’s Proportion 30s 1min

18 End-to-end Perspective Chinoy: “Dynamics of Internet routing information” (SIGCOMM 93) Measurements on NSFNET showed: - Processing and forwarding latency of BDP update is 3 orders of magnitude more than the latency incurred in forwarding data packets - Will lead to packet drops during the intervening period Paxson : “End-to-End routing behavior in the internet” (SIGCOMM 96) - Routing loops introduce loops into other router’s routing tables - An end-to-end route changes every 1.5 hours on an average

19 End-to-End perspective (Paxson) Pathology type Probability in 1995 Probability in 1996 Long-lived Routing loops Short-lived Routing loops Outage>30s Total 0.065% ~ 0.14% ~ same 0.96%2.2% 3.4%1.5%

20 Summary and Conclusions Redundant routing information flows in core Instability distributed across autonomous systems Possible reasons for instability: - Stateless BGP updates - Misconfigured routers - Synchronization - Clocks driving the links not synchronized (link “flaps”)

21 Follow-up work & impact Migration from stateless to stateful BGP decreased duplicate withdrawals by an order of magnitude “Origins of Internet Routing Instability”-1999 But Duplicate Announcements (AADup) doubled Reason: Non-transitive attribute filtering not implemented - BGP specification: “never propagate non-transitive attributes”.. - ASPATH is transitive attribute - MED (Multi Exit Discriminator) is NOT transitive

22 Propagating MED’s Causes Oscillations


Download ppt "Internet Routing Instability Craig Labovitz G. Robert Malan Farnam Jahanian Presenters: Supranamaya Ranjan Mohammed Ahamed Appeared: SIGCOMM ‘97."

Similar presentations


Ads by Google