Detecting Peering Infrastructure Outages in the Wild Vasileios - - PowerPoint PPT Presentation

detecting peering infrastructure outages in the wild
SMART_READER_LITE
LIVE PREVIEW

Detecting Peering Infrastructure Outages in the Wild Vasileios - - PowerPoint PPT Presentation

Detecting Peering Infrastructure Outages in the Wild Vasileios Giotsas , Christoph Dietzel , Georgios Smaragdakis , Anja Feldmann , Arthur Berger , Emile Aben # TU Berlin CAIDA DE-CIX MIT Akamai


slide-1
SLIDE 1

Detecting Peering Infrastructure Outages in the Wild

Vasileios Giotsas †∗, Christoph Dietzel † §, Georgios Smaragdakis ‡ †, Anja Feldmann †, Arthur Berger ¶ ‡, Emile Aben #

†TU Berlin ∗CAIDA §DE-CIX ‡MIT ¶Akamai #RIPE NCC

slide-2
SLIDE 2

Peering Infrastructures are critical part of the interconnection ecosystem

Internet Exchange Points (IXPs) provide a shared switching fabric for layer-2 bilateral and multilateral peering.

○ Largest IXPs support > 100 K of peerings, > 5 Tbps peak traffic ○ Typical SLA 99.99% (~52 min. downtime/year)1

Carrier-neutral co-location facilities (CFs) provide infrastructure for physical co-location and cross-connect interconnections.

○ Largest facilities support > 170 K of interconnections ○ Typical SLA 99.999% (~5 min. downtime/year)2

1 https://ams-ix.net/services-pricing/service-level-agreement 2http://www.telehouse.net/london-colocation/

2

slide-3
SLIDE 3

Outages in peering infrastructures can severely disrupt critical services and applications

3

slide-4
SLIDE 4

Outages in peering infrastructures can severely disrupt critical services and applications

4

Outage detection crucial to improve situational awareness, risk assessment and transparency.

slide-5
SLIDE 5

Current practice: “Is anyone else having issues?”

5

  • ASes try to crowd-source the detection and localization of outages.
  • Inadequate transparency/responsiveness from infrastructure operators.
slide-6
SLIDE 6

Symbiotic and interdependent infrastructures

6

https://www.franceix.net/en/technical/infrastructure/

slide-7
SLIDE 7

Remote peering extends the reach of IXPs and CFs beyond their local market

Global footprint of AMS-IX

https://ams-ix.net/connect-to-ams-ix/peering-around-the-globe

7

slide-8
SLIDE 8

Our Research Goals

  • 1. Outage detection:

○ Timely, at the finest granularity possible

  • 2. Outage localization:

○ Distinguish cascading effects from outage source

  • 3. Outage tracking:

○ Determine duration, shifts in routing paths, geographic spread

8

slide-9
SLIDE 9

Challenges in detecting infrastructure outages

9

Actual incident

slide-10
SLIDE 10

Challenges in detecting infrastructure outages

10

Before

  • utage

VP Actual incident Observed paths

slide-11
SLIDE 11

Challenges in detecting infrastructure outages

11

Before

  • utage

VP Actual incident Observed paths

slide-12
SLIDE 12

Challenges in detecting infrastructure outages

12

Before

  • utage

During

  • utage

VP Actual incident Observed paths

slide-13
SLIDE 13

Challenges in detecting infrastructure outages

13

AS path does not change!

Before

  • utage

During

  • utage
  • 1. Capturing the infrastructure-level hops between ASes

VP Actual incident Observed paths

slide-14
SLIDE 14

Challenges in detecting infrastructure outages

14

Before

  • utage

During

  • utage

IXP or Facility 2 failed

  • 1. Capturing the infrastructure-level hops between ASes

VP Actual incident Observed paths

slide-15
SLIDE 15

Challenges in detecting infrastructure outages

15

IXP is still active

Before

  • utage

During

  • utage

IXP or Facility 2 failed

During

  • utage
  • 1. Capturing the infrastructure-level hops between ASes
  • 2. Correlating the paths from multiple vantage points

VP VP Actual incident Observed paths

slide-16
SLIDE 16

Challenges in detecting infrastructure outages

16

  • 1. Capturing the infrastructure-level hops between ASes
  • 2. Correlating the paths from multiple vantage points
  • 3. Continuous monitoring of the routing system

Before

  • utage

During

  • utage

During

  • utage

VP VP

No hop changes The initial hops changed

Actual incident Observed paths

slide-17
SLIDE 17

Challenges in detecting infrastructure outages

17

  • 1. Capturing the infrastructure-level hops between ASes
  • 2. Correlating the paths from multiple vantage points
  • 3. Continuous monitoring of the routing system

France-IX topology

Djibouti Telecom Telkom Indonesi a

slide-18
SLIDE 18

Challenges in detecting infrastructure outages

18

  • 1. Capturing the infrastructure-level hops between ASes
  • 2. Correlating the paths from multiple vantage points
  • 3. Continuous monitoring of the routing system

BGP measurement BGP BGP BGP

Djibouti Telecom Telkom Indonesi a

slide-19
SLIDE 19

Challenges in detecting infrastructure outages

19

  • 1. Capturing the infrastructure-level hops between ASes
  • 2. Correlating the paths from multiple vantage points
  • 3. Continuous monitoring of the routing system

BGP BGP BGP Traceroute measurement

149.6.154.14 2 37.49.237.126

Telkom Indonesi a

slide-20
SLIDE 20

Challenges in detecting infrastructure outages

20

  • 1. Capturing the infrastructure-level hops between ASes
  • 2. Correlating the paths from multiple vantage points
  • 3. Continuous monitoring of the routing system

BGP BGP BGP Traceroute measurement Traceroute Traceroute Traceroute

149.6.154.14 2 37.49.237.126

3 Giotsas, Vasileios, et al. "Mapping peering interconnections to a facility", CoNEXT 2015 4 Motamedi, Reza, et al. “On the Geography of X-Connects”, Technical Report CIS-TR-2014-02. University of Oregon, 2014 5 Nomikos, George, et al. "traIXroute: Detecting IXPs in traceroute paths.". PAM 2016

Telkom Indonesi a

IP-to-Facility3,4 and IP-to-IXP5 mapping possible but expensive!

Djibouti Telecom

slide-21
SLIDE 21

Challenges in detecting infrastructure outages

21

  • 1. Capturing the infrastructure-level hops between ASes
  • 2. Correlating the paths from multiple vantage points
  • 3. Continuous monitoring of the routing system

BGP BGP BGP Traceroute Traceroute Traceroute

Can we combine continuous passive measurements with fine- grained topology discover?

slide-22
SLIDE 22

Challenges in detecting infrastructure outages

22

  • 1. Capturing the infrastructure-level hops between ASes
  • 2. Correlating the paths from multiple vantage points
  • 3. Continuous monitoring of the routing system

BGP BGP BGP Traceroute Traceroute Traceroute

slide-23
SLIDE 23

Deciphering location metadata in BGP

PREFIX: 1.0.0.0/24 ASPATH: 2 1 0 COMMUNITY: 2:200

23

slide-24
SLIDE 24

Deciphering location metadata in BGP

PREFIX: 1.0.0.0/24 ASPATH: 2 1 0 COMMUNITY: 2:200

24

BGP Communities:

  • Optional attribute
  • 32-bit numerical values
  • Encodes arbitrary

metadata

slide-25
SLIDE 25

Deciphering location metadata in BGP

PREFIX: 1.0.0.0/24 ASPATH: 2 1 0 COMMUNITY: 2:200

Top 16 bits: ASN that sets the community. Bottom 16 bits: Numerical value that encodes the actual meaning.

25

slide-26
SLIDE 26

Deciphering location metadata in BGP

PREFIX: 1.0.0.0/24 ASPATH: 2 1 0 COMMUNITY: 2:200

The BGP Community 2:200 is used to tag routes received at Facility 2

26

slide-27
SLIDE 27

Deciphering location metadata in BGP

PREFIX: 3.3.3.3/24 ASPATH: 4 3 COMMUNITY: 4:8714 4:400 PREFIX: 2.2.2.2/24 ASPATH: 4 2 COMMUNITY: 4:8714 4:400 PREFIX: 1.0.0.0/24 ASPATH: 2 1 0 COMMUNITY: 2:200

27

slide-28
SLIDE 28

Deciphering location metadata in BGP

PREFIX: 3.3.3.3/24 ASPATH: 4 3 COMMUNITY: 4:8714 4:400 PREFIX: 2.2.2.2/24 ASPATH: 4 2 COMMUNITY: 4:8714 4:400 PREFIX: 1.0.0.0/24 ASPATH: 2 1 0 COMMUNITY: 2:200

Multiple communities can tag different types

  • f ingress points.

28

slide-29
SLIDE 29

Deciphering location metadata in BGP

PREFIX: 3.3.3.3/24 ASPATH: 4 3 COMMUNITY: 4:400 PREFIX: 2.2.2.2/24 ASPATH: 4 2 COMMUNITY: 4:8714 4:400 PREFIX: 1.0.0.0/24 ASPATH: 2 1 0 COMMUNITY: 2:100

When a route changes ingress point, the community values will be update to reflect the change.

29

slide-30
SLIDE 30

Interpreting BGP Communities

  • Community values not

standardized.

  • Documentation in public data

sources:

○ WHOIS, NOCs websites

  • 3,049 communities by 468 ASes

30

slide-31
SLIDE 31

Topological coverage

31

  • ~50% of IPv4 and ~30% of IPv6

paths annotated with at least one Community in our dictionary.

  • 24% of the facilities in PeeringDB,

98% of the facilities with at least 20 members.

slide-32
SLIDE 32

Passive outage detection: Initialization

32

For each vantage point (VP) collect all the stable BGP routes tagged with the communities of the target facility (Facility 2)

Time

slide-33
SLIDE 33

Passive outage detection: Initialization

33

For each vantage point (VP) collect all the stable BGP routes tagged with the communities of the target facility (Facility 2)

AS_PATH: 1 x COMM: 1:FAC2 AS_PATH: 2 1 0 COMM: 2:FAC2 AS_PATH: 4 x COMM: 4:FAC2 Time

slide-34
SLIDE 34

Passive outage detection: Monitoring

34

Track the BGP updates of the stable paths for changes in the communities values that indicate ingress point change.

Time

slide-35
SLIDE 35

Passive outage detection: Monitoring

35

AS_PATH: 2 1 0 COMM: 2:FAC1

We don’t care about AS-level path changes if the ingress-tagging communities remain the same.

Time

slide-36
SLIDE 36

Passive outage detection: Outage signal

36

AS_PATH: 2 1 0 COMM: 2:FAC1 AS_PATH: 1 x COMM: 1:FAC1 AS_PATH: 4 x COMM: 4:FAC4 4:IXP

  • Concurrent changes of communities values for the same facility.
  • Indication of outage but not final inference yet!

Time

slide-37
SLIDE 37

Passive outage detection: Outage signal

37

AS_PATH: 2 1 0 COMM: 2:FAC1 AS_PATH: 1 x COMM: 1:FAC1 AS_PATH: 4 x COMM: 4:FAC4 4:IXP

  • Concurrent changes of communities values for the same facility.
  • Indication of outage but not final inference yet!

Partial outage Time

slide-38
SLIDE 38

Passive outage detection: Outage signal

38

AS_PATH: 2 1 0 COMM: 2:FAC1 AS_PATH: 1 x COMM: 1:FAC1 AS_PATH: 4 x COMM: 4:FAC4 4:IXP

  • Concurrent changes of communities values for the same facility.
  • Indication of outage but not final inference yet!

Partial outage? De-peering of large ASes? Major routing policy change? Time

slide-39
SLIDE 39

Passive outage detection: Outage signal

39

AS_PATH: 2 1 0 COMM: 2:FAC1 AS_PATH: 1 x COMM: 1:FAC1 AS_PATH: 4 x COMM: 4:FAC4 4:IXP

Signal investigation:

  • Targeted active measurements.
  • How disjoint are the affected paths?
  • How many ASes and links have been affected?

Partial outage? De-peering of large ASes? Major routing policy change? Time

slide-40
SLIDE 40

Passive outage detection: Outage tracking

40

AS_PATH: 1 x COMM: 1:FAC2 AS_PATH: 2 1 0 COMM: 2:FAC2

End of outage inferred when the majority

  • f paths return to the original facility.

Time

slide-41
SLIDE 41

De-noising of BGP routing activity

41

The aggregated activity of BGP messages (updates, withdrawals, states) provides no outage indication.

Time Number of BGP messages (log)

105 103 101

slide-42
SLIDE 42

De-noising of BGP routing activity

42

The aggregated activity of BGP messages (updates, withdrawals, states) provides no outage indication. The BGP activity filtered using communities provides strong

  • utage signal.

Time Number of BGP messages (log)

105 103 101

Time Number of BGP messages (log)

105 103 101 1.0 0.4 0.2 0.6 0.8

Fraction of infrastructure paths

slide-43
SLIDE 43

43

  • The location of community values that trigger outage signals

may not be the outage source!

  • Communities encode the ingress point closest to our VPs

(near-end infrastructure)

○ ASes may be interconnected over multiple intermediate infrastructures ○ Failures in intermediate infrastructures may affect the near-end infrastructure paths

Outage localization is more complicated!

slide-44
SLIDE 44

Outage localization is more complicated!

44

Time

slide-45
SLIDE 45

Outage localization is more complicated!

45

Time

slide-46
SLIDE 46

Outage localization is more complicated!

46

Outage in Facility 2 causes drop in the paths of Facility 4!

Time

slide-47
SLIDE 47

Outage localization is more complicated!

47

Time

slide-48
SLIDE 48

Outage localization is more complicated!

48

Outage in Facility 3 causes drop in the paths of Facility 4!

Time

slide-49
SLIDE 49

Outage source disambiguation and localization

49

  • Create high-resolution co-location maps:

○ AS to Facilities, AS to IXPs, IXPs to Facilities ○ Sources: PeeringDB, DataCenterMap, operator websites

  • Decorrelate the behaviour of affected ASes based on their

infrastructure colocation.

slide-50
SLIDE 50

Outage localization is more complicated!

50

Far-end ASes colocated in Facility 2

Time

slide-51
SLIDE 51

Outage localization is more complicated!

51

Far-end ASes colocated in Facility 3

Time

slide-52
SLIDE 52

Outage source disambiguation and localization

52

Paths not investigated in aggregated manner, but at the granularity of separate (AS, Facility) co-locations.

London Telecity HE8/9 outage London Telehouse North outage

Time

slide-53
SLIDE 53

Outage source disambiguation and localization

53

London Telecity HE8/9 outage London Telehouse North outage London Telecity HE8/9 outage London Telehouse North outage

Paths not investigated in aggregated manner, but at the granularity of separate (AS, Facility) co-locations.

Time

slide-54
SLIDE 54

Detecting peering infrastructure outages in the wild

54

  • 159 outages in 5 years of BGP data

○ 76% of the outages not reported in popular mailing lists/websites

  • Validation through status reports, direct feedback, social media

○ 90% accuracy, 93% precision (for trackable PoPs)

slide-55
SLIDE 55

Effect of outages on Service Level Agreements

55

~70% of failed facilities below 99.999% uptime ~50% of failed IXPs below 99.99% uptime 5% of failed infrastructures below 99.9% uptime!

slide-56
SLIDE 56

Measuring the impact of outages

56

> 56 % of the affected links in different country, > 20% in different continent! Median RTT rises by > 100 ms for rerouted paths during AMS-IX

  • utage.

Number of affected links (log)

105 103 101

CDF

1.0 0.4 0.2 0.6 0.8 0.44

Distance from outage source (km)

12K 8K 10K 6K 4K 2K

Fraction of paths RTT (ms)

slide-57
SLIDE 57

Conclusions

  • Timely and accurate infrastructure-level outage detection through

passive BGP monitoring

  • Majority of outages not (widely) reported
  • Remote peering and infrastructure interdependencies amplify the

impact of local incidents

  • Hard evidence on outages can improve accountability,

transparency and resilience strategies

57

slide-58
SLIDE 58

Thank you!

58