Onderwerp: probleem met onbereikbare website op VPS

Enkele dagen terug was mijn website die gehost wordt op een VPS gedurende 2 uren onbereikbaar. Chrome gaf me het foutvenster "Oops! Google Chrome could not find...". Wanneer ik een traceroute deed naar het serveradres van mijn VPS dan kreeg ik na enkele hops enkel nog time outs (tem hop 30). Ook via pingdom kon ik de tracerouteresultaten vanuit US en andere EU plaatsen raadplegen: telkens timeouts na een aantal hops. Naast die éne VPS heb ik nog een andere VPS en enkele shared hosting pakketten bij diezelfde hoster ook in hun Europees datacentrum. Alle sites bleken onbereikbaar.

Ik deelde deze info met m'n hosting provider en die zei dat hij mijn site kon bereiken. Dat was ook zo want via realtime Google Analytics verscheen er plots 1 bezoeker (waar anders 10 tot 20 bezoekers). Ik deelde de info die ik hierboven vermeldde met de webhoster en die zei dat het waarschijnlijk niet hun probleem was maar dat van m'n ISP. Ik ben geen serverspecialist maar als de traceroutes van rondom de wereld timeouten en enkel vanuit de webhoster premisses mijn site bereikbaar is dan heb ik het gevoel dat het probleem niet bij mijn ISP ligt.

1/ heeft iemand een idee wat hier aan de hand kan geweest zijn
2/ hoe kan ik in de toekomst meer te weten komen (via monitoring tools of zo) wat er juist gaande is en wie daarvoor verantwoordelijk is.

ter info: dit is het antwoord dat ik na verloop van tijd per email kreeg:
"This timeout occurs at 46.255.192.250. A lookup of this IP shows it belongs to a company called Cybercom Plenware Oy which is located in Finland. This company is not us or affiliated with us. You will need contact your network administrator or ISP regarding this issue and provide them the results of this trace route. As we do not know who your Internet Service Provider is we would not be able to provide you with there contact details. We would advise using your search engine of choice to find this information."

Kan zijn dat er bepaalde routes niet goed liepen en dus vanuit sommige landen/ISP's de websites niet bereikbaar waren.
Daarintegen, als pingdom aangeeft dat de sites offline waren(vanuit meerdere locaties) dan moet dat voldoende zijn om aan te tonen dat het aan de hoster ligt.

Zou zeggen, zet pingdom aan en als het weer gebeurt laat dan de downtime grafieken van pingdom zien.

Oorspronkelijk geplaatst door daniellesuetens

Enkele dagen terug was mijn website die gehost wordt op een VPS gedurende 2 uren onbereikbaar. Chrome gaf me het foutvenster "Oops! Google Chrome could not find...". Wanneer ik een traceroute deed naar het serveradres van mijn VPS dan kreeg ik na enkele hops enkel nog time outs (tem hop 30). Ook via pingdom kon ik de tracerouteresultaten vanuit US en andere EU plaatsen raadplegen: telkens timeouts na een aantal hops. Naast die éne VPS heb ik nog een andere VPS en enkele shared hosting pakketten bij diezelfde hoster ook in hun Europees datacentrum. Alle sites bleken onbereikbaar.

Ik deelde deze info met m'n hosting provider en die zei dat hij mijn site kon bereiken. Dat was ook zo want via realtime Google Analytics verscheen er plots 1 bezoeker (waar anders 10 tot 20 bezoekers). Ik deelde de info die ik hierboven vermeldde met de webhoster en die zei dat het waarschijnlijk niet hun probleem was maar dat van m'n ISP. Ik ben geen serverspecialist maar als de traceroutes van rondom de wereld timeouten en enkel vanuit de webhoster premisses mijn site bereikbaar is dan heb ik het gevoel dat het probleem niet bij mijn ISP ligt.

1/ heeft iemand een idee wat hier aan de hand kan geweest zijn
2/ hoe kan ik in de toekomst meer te weten komen (via monitoring tools of zo) wat er juist gaande is en wie daarvoor verantwoordelijk is.

ter info: dit is het antwoord dat ik na verloop van tijd per email kreeg:
"This timeout occurs at 46.255.192.250. A lookup of this IP shows it belongs to a company called Cybercom Plenware Oy which is located in Finland. This company is not us or affiliated with us. You will need contact your network administrator or ISP regarding this issue and provide them the results of this trace route. As we do not know who your Internet Service Provider is we would not be able to provide you with there contact details. We would advise using your search engine of choice to find this information."

Qua symptoom zou je zeggen dat routing een tijdje niet gewerkt heeft .
Als dat van veel plaatsen het geval was verwacht je dat de oorzaak in het netwerk of heel dicht bij het netwerk van je hoster zit.
Het enige wat die verklaring een beetje lastig maakt is dat een hit op google analytics vanaf het netwerk van je hoster blijkbaar wel gemaakt kon worden.

Het zou nog steeds kunnen hoor, dat bijvoorbeeld transits weggevallen waren maar lokale peers niet, of andersom.

2 : Er zijn wel wat monitoring sites .
Om meer te zeggen wil je traceroutes vanaf verschillende netwerken naar je site .
En liefst kijken met looking glasses naar route advertisements voor dat netwerk op verschillende plekken.

Als je het IP geeft is er misschien wel wat te zien in de ripe RIS.
Je moet overigens echt behoorlijk goed bekend zijn met internet routing om in wat lastiger gevallen van buitenaf een redelijke diagnose te stellen.
traceroute zegt veel, maar het is niet altijd waar de sterretjes beginnen, dat daar ook het probleem begint.

In de hoop dat iemand er wijzer van wordt en wat meer klaarheid kan scheppen in de oorzaak van het probleem op IP 46.252.194.197, hier chronologisch enkele traceroutes van begin tot aan het einde van de problemen met het IP adres telkens vanop verschilende locaties zoals geregistreerd door Pingdom:

Traceroute 19-02-2014 22:18:05 from Toronto
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 184.75.210.225 (184.75.210.225) 0.166 ms 0.823 ms 0.969 ms
2 xe-0-0-1-3601.cr1.tor2.ca.nlayer.net (69.31.143.97) 1.444 ms 1.559 ms 1.672 ms
3 ae0-30g.cr1.tor1.ca.nlayer.net (69.31.143.24) 1.044 ms 1.183 ms 1.308 ms
4 ae2-50.tor10.ip4.tinet.net (199.229.230.89) 1.107 ms 1.239 ms 1.363 ms
5 xe-10-3-0.chi12.ip4.tinet.net (141.136.106.13) 10.708 ms 11.536 ms 11.681 ms
6 as3549.ip4.tinet.net (213.200.66.58) 40.283 ms 39.235 ms 39.327 ms
7 208.178.58.162 (208.178.58.162) 12.158 ms 12.392 ms 12.531 ms
8 if-22-2.tcore1.CT8-Chicago.as6453.net (64.86.79.2) 112.013 ms 112.339 ms 112.487 ms
9 * * *
10 if-20-2.tcore2.L78-London.as6453.net (216.6.99.14) 114.838 ms 115.024 ms 115.300 ms
11 if-8-2.tcore2.AV2-Amsterdam.as6453.net (80.231.131.6) 115.408 ms 115.205 ms *
12 if-2-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.5) 114.919 ms 114.933 ms 115.633 ms
13 195.219.194.2 (195.219.194.2) 115.272 ms 115.369 ms 115.891 ms
14 * * *
15 * * *
16 ip-208-109-115-178.ip.secureserver.net (208.109.115.178) 115.350 ms 114.708 ms 114.943 ms
17 ip-46-252-194-197.ip.secureserver.net (46.252.194.197) 114.559 ms 116.417 ms 116.283 ms
-----------------------------------------------------------------------
Traceroute 19-02-2014 22:23:03 from Leiria, Portugal
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 91.109.115.46 (91.109.115.46) 0.209 ms 0.526 ms 0.651 ms
2 94.46.225.173 (94.46.225.173) 0.375 ms 0.769 ms 0.891 ms
3 94.46.143.21 (94.46.143.21) 16.010 ms 16.235 ms 16.349 ms
4 te2-6.206.ccr01.opo01.atlas.cogentco.com (149.6.108.1) 7.176 ms !H * *
-----------------------------------------------------------------------
Traceroute 19-02-2014 22:23:03
Atlanta, GA
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 v617.er01.atl.ubiquity.io (23.19.153.1) 16.628 ms 16.735 ms 16.787 ms
2 ae5-109.cr2.atl1.us.nlayer.net (69.31.135.125) 0.298 ms 0.461 ms 0.550 ms
3 vlan-74.ar1.atl1.us.nlayer.net (69.31.135.166) 2.807 ms 2.879 ms 2.953 ms
4 ae-8.r04.atlnga05.us.bb.gin.ntt.net (204.2.241.93) 2.221 ms !N 2.333 ms !N 2.410 ms !N
--------------------------------------------------------------------
Traceroute 19-02-2014 22:31:05
Milan 2, Italy
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 wf2.mi.sw-gw1.seflow.it (95.141.32.1) 0.778 ms 0.967 ms 1.159 ms
2 caldera.dc2.hsr1a.seflow.it (95.141.47.254) 0.482 ms 0.860 ms 1.053 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
----------------------------------------------------------------
traceroute 19-02-2014 22:31:05
Philadelphia 2, PA
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 76.72.171.161 (76.72.171.161) 0.297 ms 0.400 ms 0.484 ms
2 xe-7-2-3.bar1.Philadelphia1.Level3.net (4.34.195.129) 0.132 ms 0.328 ms 0.415 ms
3 ae-11-11.bar2.Philadelphia1.Level3.net (4.69.153.90) 0.357 ms 0.455 ms 0.535 ms
4 ae-6-6.ebr2.NewYork1.Level3.net (4.69.133.170) 2.287 ms 2.388 ms 2.473 ms
5 ae-48-48.ebr2.NewYork2.Level3.net (4.69.201.38) 2.185 ms 2.295 ms

ae-47-47.ebr2.NewYork2.Level3.net (4.69.201.34) 2.379 ms
6 ae-2-52.edge1.NewYork2.Level3.net (4.69.138.226) 2.299 ms 2.237 ms 2.216 ms
7 Tata-level3-2x10G.NewYork.Level3.net (4.68.62.186) 2.324 ms 2.428 ms 2.513 ms
8 63.243.128.38 (63.243.128.38) 78.574 ms 79.014 ms 78.621 ms
9 if-8-2.tcore2.AV2-Amsterdam.as6453.net (80.231.131.6) 78.754 ms 78.670 ms 78.827 ms
10 if-2-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.5) 79.457 ms 79.660 ms 79.849 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
-------------------------------------------------------------
19-02-2014 22:41:08
Leiria, Portugal
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 91.109.115.46 (91.109.115.46) 0.197 ms 0.412 ms 0.593 ms
2 94.46.225.173 (94.46.225.173) 0.309 ms 0.489 ms 0.672 ms
3 94.46.143.21 (94.46.143.21) 7.079 ms 7.272 ms 7.383 ms
4 te2-6.206.ccr01.opo01.atlas.cogentco.com (149.6.108.1) 8.091 ms 8.288 ms 8.385 ms
5 te7-1.ccr01.vgo01.atlas.cogentco.com (154.54.57.138) 10.437 ms 10.649 ms 10.755 ms
6 te2-1.ccr01.ovd01.atlas.cogentco.com (154.54.37.65) 116.490 ms 113.319 ms 113.532 ms
7 te0-5-0-3.ccr21.bio01.atlas.cogentco.com (154.54.36.141) 20.690 ms 21.049 ms 21.099 ms
8 be2243.ccr22.par01.atlas.cogentco.com (130.117.1.225) 33.776 ms 34.675 ms 35.042 ms
9 be2266.ccr22.ams03.atlas.cogentco.com (154.54.61.198) 43.924 ms 43.372 ms 43.601 ms
10 be2321.mag21.ams03.atlas.cogentco.com (154.54.78.102) 43.793 ms 42.909 ms 42.636 ms
11 tata.ams03.atlas.cogentco.com (130.117.15.78) 56.532 ms tata.ams03.atlas.cogentco.com

(130.117.15.74) 56.165 ms 57.101 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 ip-46-252-194-197.ip.secureserver.net (46.252.194.197) 57.399 ms 57.344 ms 57.376 ms
----------------------------------------------------
19-02-2014 22:55:13
Philadelphia 2, PA
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 76.72.171.161 (76.72.171.161) 0.430 ms 0.796 ms 0.971 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
----------------------------------
19-02-2014 23:11:05
Milan 2, Italy
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 wf2.mi.sw-gw1.seflow.it (95.141.32.1) 2.844 ms 3.351 ms 3.544 ms
2 caldera.dc2.hsr1a.seflow.it (95.141.47.254) 2.618 ms 3.444 ms 3.626 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * caldera.dc2.hsr1a.seflow.it (95.141.47.254) 2.931 ms !H
---------------------------------------
19-02-2014 23:11:05
Toronto 5, Canada
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 184.75.210.225 (184.75.210.225) 0.178 ms 0.367 ms 0.476 ms
2 xe-0-0-1-3601.cr1.tor2.ca.nlayer.net (69.31.143.97) 0.566 ms 0.666 ms 0.764 ms
3 ae0-30g.cr1.tor1.ca.nlayer.net (69.31.143.24) 0.181 ms 0.343 ms 0.450 ms
4 xe-2-0-1.cr1.nyc2.us.nlayer.net (69.22.142.145) 12.570 ms 12.760 ms 12.865 ms
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
------------------------------------
19-02-2014 23:21:07
Atlanta, GA

traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 v617.er01.atl.ubiquity.io (23.19.153.1) 2.204 ms 2.657 ms 2.803 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
------------------------------
19-02-2014 23:33:07
Leiria, Portugal
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 91.109.115.46 (91.109.115.46) 0.525 ms 0.846 ms 1.149 ms
2 94.46.225.173 (94.46.225.173) 0.141 ms 0.674 ms 0.987 ms
3 94.46.143.21 (94.46.143.21) 7.045 ms 7.309 ms 7.540 ms
4 te2-6.206.ccr01.opo01.atlas.cogentco.com (149.6.108.1) 7.699 ms 7.849 ms 8.006 ms
5 te7-1.ccr01.vgo01.atlas.cogentco.com (154.54.57.138) 25.558 ms 25.826 ms 26.003 ms
6 te2-1.ccr01.ovd01.atlas.cogentco.com (154.54.37.65) 16.214 ms 16.152 ms 16.242 ms
7 te0-5-0-3.ccr21.bio01.atlas.cogentco.com (154.54.36.141) 20.905 ms 21.132 ms 21.333 ms
8 be2243.ccr22.par01.atlas.cogentco.com (130.117.1.225) 33.111 ms 33.197 ms 33.410 ms
9 be2266.ccr22.ams03.atlas.cogentco.com (154.54.61.198) 42.461 ms 42.610 ms 42.799 ms
10 be2321.mag21.ams03.atlas.cogentco.com (154.54.78.102) 43.026 ms 43.759 ms 44.072 ms
11 tata.ams03.atlas.cogentco.com (130.117.15.74) 42.631 ms 42.166 ms 42.246 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
-----------------------------
19-02-2014 23:55:07
Philadelphia 2, PA
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 76.72.171.161 (76.72.171.161) 0.325 ms 0.522 ms 0.685 ms
2 xe-7-2-3.bar1.Philadelphia1.Level3.net (4.34.195.129) 0.135 ms 0.470 ms 0.633 ms
3 ae-11-11.bar2.Philadelphia1.Level3.net (4.69.153.90) 0.302 ms 0.503 ms 0.668 ms
4 ae-6-6.ebr2.NewYork1.Level3.net (4.69.133.170) 2.267 ms 2.505 ms 2.670 ms
5 ae-48-48.ebr2.NewYork2.Level3.net (4.69.201.38) 9.173 ms 9.512 ms 9.676 ms
6 ae-2-52.edge1.NewYork2.Level3.net (4.69.138.226) 2.247 ms 2.241 ms 2.400 ms
7 Tata-level3-2x10G.NewYork.Level3.net (4.68.62.186) 2.338 ms 2.503 ms 2.684 ms
8 63.243.128.38 (63.243.128.38) 78.572 ms 78.869 ms 78.495 ms
9 if-8-2.tcore2.AV2-Amsterdam.as6453.net (80.231.131.6) 79.229 ms 79.259 ms 79.040 ms
10 if-2-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.5) 78.620 ms 78.811 ms 78.568 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
-----------------------

traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 91.109.115.46 (91.109.115.46) 0.228 ms 0.708 ms 0.860 ms
2 94.46.225.173 (94.46.225.173) 0.525 ms 1.004 ms 1.152 ms
3 94.46.143.21 (94.46.143.21) 7.121 ms 7.385 ms 7.579 ms
4 te2-6.206.ccr01.opo01.atlas.cogentco.com (149.6.108.1) 7.744 ms 7.886 ms 8.045 ms
5 te7-1.ccr01.vgo01.atlas.cogentco.com (154.54.57.138) 9.575 ms 9.820 ms 10.002 ms
6 te2-1.ccr01.ovd01.atlas.cogentco.com (154.54.37.65) 16.267 ms 16.269 ms 16.512 ms
7 te0-5-0-3.ccr21.bio01.atlas.cogentco.com (154.54.36.141) 21.381 ms 21.425 ms 21.593 ms
8 be2243.ccr22.par01.atlas.cogentco.com (130.117.1.225) 33.309 ms 33.191 ms 33.428 ms
9 be2266.ccr22.ams03.atlas.cogentco.com (154.54.61.198) 42.734 ms 42.777 ms 42.920 ms
10 be2321.mag21.ams03.atlas.cogentco.com (154.54.78.102) 42.544 ms 42.486 ms 43.870 ms
11 tata.ams03.atlas.cogentco.com (130.117.15.78) 42.139 ms tata.ams03.atlas.cogentco.com

(130.117.15.74) 42.255 ms 42.362 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
-------------------------
20-02-2014 00:13:06
Paris, France
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 te3-4-110.ig1-cr-02.dc2.ig-1.net (78.40.124.3) 0.492 ms 0.865 ms 1.034 ms
2 te4-3.ig1-cr-01.dc2.par.ig-1.net (158.58.176.42) 1.577 ms 1.693 ms 1.797 ms
3 te1-3.ig1-cr-01.th2.par.ig-1.net (158.58.176.34) 1.177 ms 1.309 ms 1.447 ms
4 ix-5-0-1-0.tcore1.PVU-Paris.as6453.net (195.219.241.169) 0.493 ms 0.832 ms 1.012 ms
5 if-3-3.tcore1.FR0-Frankfurt.as6453.net (80.231.153.122) 14.847 ms 14.541 ms 14.992 ms
6 if-7-2.tcore1.FNM-Frankfurt.as6453.net (195.219.50.2) 14.670 ms 14.352 ms 14.409 ms
7 if-6-3.tcore1.AV2-Amsterdam.as6453.net (195.219.194.77) 14.779 ms 14.964 ms 15.108 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
---------------------
20-02-2014 00:30:05
Atlanta, GA
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 v617.er01.atl.ubiquity.io (23.19.153.1) 10.045 ms 10.430 ms 10.653 ms
2 ae5-109.cr2.atl1.us.nlayer.net (69.31.135.125) 0.345 ms 1.356 ms 1.595 ms
3 vlan-74.ar1.atl1.us.nlayer.net (69.31.135.166) 2.400 ms 2.579 ms 2.751 ms
4 ae-8.r04.atlnga05.us.bb.gin.ntt.net (204.2.241.93) 1.791 ms 1.986 ms 2.194 ms
5 ae-8.r20.asbnva02.us.bb.gin.ntt.net (129.250.5.214) 17.214 ms 14.965 ms 15.196 ms
6 ae-1.r00.asbnva02.us.bb.gin.ntt.net (129.250.3.110) 14.483 ms 14.472 ms 17.291 ms
7 ix-18-0.tcore2.AEQ-Ashburn.as6453.net (216.6.87.157) 14.694 ms 16.882 ms 18.197 ms
8 if-11-2.tcore2.NJY-Newark.as6453.net (216.6.87.138) 103.832 ms 104.687 ms 102.632 ms
9 * * *
10 if-7-2.tcore1.L78-London.as6453.net (66.198.70.26) 103.457 ms 104.092 ms 106.683 ms
11 if-2-2.tcore2.L78-London.as6453.net (80.231.131.1) 103.986 ms 104.440 ms 104.887 ms
12 if-8-2.tcore2.AV2-Amsterdam.as6453.net (80.231.131.6) 104.118 ms 103.927 ms 104.290 ms
13 if-2-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.5) 105.169 ms 103.260 ms 105.544 ms
14 195.219.194.2 (195.219.194.2) 117.953 ms * 123.058 ms
15 * * *
16 * * *
17 * * *
18 ip-208-109-115-178.ip.secureserver.net (208.109.115.178) 104.209 ms 104.343 ms 104.863 ms
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
------------------------------
20-02-2014 00:30:05
Milan 2, Italy
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 wf2.mi.sw-gw1.seflow.it (95.141.32.1) 0.615 ms 0.954 ms 1.201 ms
2 caldera.dc2.hsr1a.seflow.it (95.141.47.254) 0.822 ms 1.071 ms 1.317 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * caldera.dc2.hsr1a.seflow.it (95.141.47.254) 0.648 ms !H *

-------------------------
20-02-2014 00:53:05
Leiria, Portugal
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 91.109.115.46 (91.109.115.46) 0.217 ms 0.557 ms 0.990 ms
2 94.46.225.173 (94.46.225.173) 0.771 ms 1.200 ms 1.403 ms
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
-----------------------
20-02-2014 01:05:08
Philadelphia 2, PA

traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 76.72.171.161 (76.72.171.161) 0.350 ms 0.432 ms 0.503 ms
2 xe-7-2-3.bar1.Philadelphia1.Level3.net (4.34.195.129) 0.144 ms 0.344 ms 0.417 ms
3 ae-11-11.bar2.Philadelphia1.Level3.net (4.69.153.90) 0.328 ms 0.413 ms 0.502 ms
4 ae-6-6.ebr2.NewYork1.Level3.net (4.69.133.170) 2.317 ms 2.380 ms 2.431 ms
5 ae-45-45.ebr2.NewYork2.Level3.net (4.69.141.22) 2.303 ms ae-48-48.ebr2.NewYork2.Level3.net (4.69.201.38) 2.196 ms 2.318 ms
6 ae-2-52.edge1.NewYork2.Level3.net (4.69.138.226) 2.245 ms 2.248 ms 2.231 ms
7 Tata-level3-2x10G.NewYork.Level3.net (4.68.62.186) 2.348 ms 2.425 ms 2.526 ms
8 63.243.128.38 (63.243.128.38) 78.487 ms 78.779 ms 78.552 ms
9 if-8-2.tcore2.AV2-Amsterdam.as6453.net (80.231.131.6) 78.703 ms 78.701 ms 78.870 ms
10 if-2-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.5) 78.524 ms 78.657 ms 78.814 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
---------------------
20-02-2014 01:05:08
Milan 2, Italy

traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 wf2.mi.sw-gw1.seflow.it (95.141.32.1) 0.508 ms 0.757 ms 0.927 ms
2 caldera.dc2.hsr1a.seflow.it (95.141.47.254) 0.662 ms 0.835 ms 1.017 ms
3 caldera.dc2.hsr1a.seflow.it (95.141.47.254) 1.098 ms !H * *
------------------
20-02-2014 01:10:05
Milan 2, Italy
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 wf2.mi.sw-gw1.seflow.it (95.141.32.1) 5.017 ms 5.219 ms 5.316 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
--------------------------
20-02-2014 01:10:05
Atlanta, GA

traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets
1 v617.er01.atl.ubiquity.io (23.19.153.1) 0.547 ms 1.767 ms 1.991 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

Oorspronkelijk geplaatst door daniellesuetens

In de hoop dat iemand er wijzer van wordt en wat meer klaarheid kan scheppen in de oorzaak van het probleem op IP 46.252.194.197, hier chronologisch enkele traceroutes van begin tot aan het einde van de problemen met het IP adres telkens vanop verschilende locaties zoals geregistreerd door Pingdom:

Traceroute 19-02-2014 22:18:05 from Toronto
traceroute to 46.252.194.197 (46.252.194.197), 30 hops max, 60 byte packets

30 * * *

knip veel traceroutes.

Dit is een netwerk probleem geweest .
Het IP adres 46.252.194.197 wordt geannounced als prefix 46.252.192.0/22 door AS24696 (Godaddy AS).
Deze prefix heeft een periode van instabiliteit gehad 19 Feb 16:30 UTC tot ca 20 Feb 0:30 .
Op een aantal momenten tot z'n 1000 updates per uur , wat enorm veel is .

Met dit soort geklapper kun je wel stellen dat je geen of slechte connectiviteit hebt, in elk geval tussen de netwerken waar de instabiliteit naar toe gaat.

Het lijkt erop dat het probleem in elk geval zichtbaar was op netwerken in het pad van AS24696 naar AS6453 (TATA) en van alles daar achter.

Met wat langer turen (langer dan ik nu tijd voor heb) is wellicht nog wel te speculeren of de oorzaak eerder in godaddy ligt, of in de verbinding(en) met 6453 , maar goed, het is in elk geval de bron van de prefix (godaddy as) die wat kan doen als een prefix met of door een peer of transit niet meer goed doorkomt.

Als een pad volledig wegvalt is dat vaak beter, omdat verkeer dan via een andere verbinding kan herrouteren.
Als een pad voordurend op en neer gaat, heb je heel slechte connectiviteit , en kun je 'm beter (met de hand) even dichtzetten.

Als oorzaak zijn er meerdere mogelijkheden, het kan een fysiek slechte lijn zijn (laser die bijna kapot is en interface wat dan op en neer gaat of vezel met een net-niet breuk), maar eventueel zou een erg zware DDoS (router kan het amper of niet aan, verliest routing, ddos komt dan ook niet verder, routing herstelt, ddos haalt ook weer de router etc ) ook een oorzaak kunnen zijn.

In elk geval is het netwerk waar 46.252.192.0/22 z'n bron heeft degene die je aan moet spreken, en die in (bv) de RIPE RIS tool kan zien dat er op die tijd een hoop mis geweest is en dat het brede impact gehad heeft.
Dat heeft in dit geval niet zo veel te maken met de laatste hop in de traceroute die nog werkte.
Of jouw directe hoster die hele prefix 'doet' , of de hoster hier z'n datacenter/netwerk leverancier op aan moet spreken weet ik niet.

Dit is een netwerk probleem geweest .
Het IP adres 46.252.194.197 wordt geannounced als prefix 46.252.192.0/22 door AS24696 (Godaddy AS).
Deze prefix heeft een periode van instabiliteit gehad 19 Feb 16:30 UTC tot ca 20 Feb 0:30 .
Op een aantal momenten tot z'n 1000 updates per uur , wat enorm veel is .

Met dit soort geklapper kun je wel stellen dat je geen of slechte connectiviteit hebt, in elk geval tussen de netwerken waar de instabiliteit naar toe gaat.

Lees meer: probleem met onbereikbare website op VPS http://www.webhostingtalk.nl/dedicat...#ixzz2uGUgWH5X

Waaruit kan je dit afleiden? Bestaat er een tool die die historiek van die netwerken bijhoudt? Ik leer graag bij, vandaar mijn vraag ;-)

Alvast bedankt!

Ik heb op basis van je info even wat zitten opzoeken en meen dit te begrijpen:
*er is een hierarchie in IP-land die gaat van Ip adressen naar Prefixen en zo naar Autonomous Systems (AS)
*het BGP protocol wisselt route-info uit tussen ASen
*the AS van het IP 46.252.194.197 is 26496
*dmv BGPlay (vond ik op ripe.net) kan je een zicht krijgen van de paden van representatieve ASen naar een bepaalde prefix; er wordt getoond of een pad van een AS naar de prefix wegvalt, wijzigt,.... door BGPlay af te spelen over de periode 19/02/14 - 20/02/14 zag ik inderdaad meer dan 2775 events (gewijzigde paden vanuit representatieve ASen,...) waardoor een pakket naar mijn IP zijn weg waarschijnlijk niet vond; dat is waarsch het klapperen waarover je het had.

Daarbij heb ik nog 2 vragen:
1/Ik heb even gecheckt en zag dat BGPlay wel pas data van 5 uren terug uit zijn hoed kan toveren. Recentere info is nog niet beschikbaar. Kan je toch dergelijke info op het moment van een probleem bekijken of op z'n minst met een kleinere vertraging (want na 5 uren is je probleem hopelijk al opgelost.
2/als m'n hoster die info ook kon checken, had hij dan niet zelf
*kunnen checken of het probleem bij zijn AS lag en indien ja het probleem oplossen
*indien het probleem niet bij hem lag proactief nieuwe en alternatieve routingpaden langs stabiele ASen kunnen broadcasten?

Als het probleem speelt wil je idd snel weten hoe het zit maar vrees dat je daar zo 123 niet de tools voor kunt krijgen.
Mocht het weer gebeuren, zet het dan snel op wht. Er is dan hopelijk iemand online die een eigen netwerk heeft en zo dus wat meer info kan verschaffen voor je.

Wat ook kan is een mailtje sturen naar info@ (zie profiel) dan wil ik wel even in de tabel kijken wat er loos is en wat tracerts doen vanuit meerdere locaties. Dan heb je op dat moment een geruster gevoel en wellicht wat meer bewijs in handen.

Oorspronkelijk geplaatst door daniellesuetens

Ik heb op basis van je info even wat zitten opzoeken en meen dit te begrijpen:
*er is een hierarchie in IP-land die gaat van Ip adressen naar Prefixen en zo naar Autonomous Systems (AS)
*het BGP protocol wisselt route-info uit tussen ASen
*the AS van het IP 46.252.194.197 is 26496
*dmv BGPlay (vond ik op ripe.net) kan je een zicht krijgen van de paden van representatieve ASen naar een bepaalde prefix; er wordt getoond of een pad van een AS naar de prefix wegvalt, wijzigt,.... door BGPlay af te spelen over de periode 19/02/14 - 20/02/14 zag ik inderdaad meer dan 2775 events (gewijzigde paden vanuit representatieve ASen,...) waardoor een pakket naar mijn IP zijn weg waarschijnlijk niet vond; dat is waarsch het klapperen waarover je het had.

Daarbij heb ik nog 2 vragen:
1/Ik heb even gecheckt en zag dat BGPlay wel pas data van 5 uren terug uit zijn hoed kan toveren. Recentere info is nog niet beschikbaar. Kan je toch dergelijke info op het moment van een probleem bekijken of op z'n minst met een kleinere vertraging (want na 5 uren is je probleem hopelijk al opgelost.
2/als m'n hoster die info ook kon checken, had hij dan niet zelf
*kunnen checken of het probleem bij zijn AS lag en indien ja het probleem oplossen
*indien het probleem niet bij hem lag proactief nieuwe en alternatieve routingpaden langs stabiele ASen kunnen broadcasten?

Applaus. Je hebt je snel en goed ingelezen.
Je geeft een prima samenvatting hoe internet routing werkt.

Een AS is een Autonomous System, en het komt neer op een netwerk wat onder één beheer verantwoording valt, en wat een eigen routing policy heeft.
Een routing policy wil zeggen het kiezen met welke andere ASen verkeer wordt uitgewisseld, en onder welke voorwaarden (peer, transit).

Een router die BGP spreekt ontvangt informatie van andere BGP routers waarmee een neighbour relatie geconfigureerd is over een prefix met daarbij een aantal attributen, waaronder de lijst van ASen waarlangs die prefix bereikbaar is, en nog een aantal metrics.
Een prefix kan van meer neighbours geleerd worden.
Tussen identieke prefixen maakt een BGP router de keuze wat de beste is, en alleen de beste keuze wordt doorgestuurd naar de overige neighbours.

Verschillende routers binnen een AS, maar zeker ook routers in verschillende ASen kunnen dus een ander pad hebben naar een bestemming.

Wat heel mooi is aan het RIPE RIS project is dat men van een behoorlijk aantal plekken in verschillende ASen de routing tables ziet, en dus een completer beeld kan samenstellen vai welke ASen een prefix bereikbaar is. Binnen een enkel AS heb je slechts zicht op dat AS, en dat zegt niet alles van hoe de rest van de wereld een prefix ziet , of niet ziet.

Inderdaad zijn al die updates en veranderende paden van die prefix wat men gewoonlijk 'klapperen' noemt. (engels : route flap )
Als het vooral de bron van de prefix is die instabiel is, zal die prefix klapperen, maar zullen andere prefixen die over dezelfde sessie uitgewisseld worden wel stabiel zijn.
Maar als oorzaak van de instabiliteit is dat de BGP sessie tussen twee ASen telkens reset, zullen alle prefixen die via die instabiele sessie uitgewisseld worden klapperen.

1) : Met een natte vinger idee van de hoeveelheid data die RIS moet aggregeren kan ik me voorstellen dat je dat niet snel real time doet.

Er zijn her en der looking glasses, waar je kunt kijken hoe de BGP table binnen een bepaald AS eruit ziet.
(google op looking glass, of soms route-server)

Soms zijn het routers met een publieke login (dedicated om alleen een bgp table te hebben, ze voeren geen verkeer), vaak zijn het webinterfaces waar je een paar queries kunt doen voor een prefix op een aantal routers binnen het AS van degene die het looking glass ter beschikking stelt.
Je moet dan al wel weten naar welke prefix of AS je op zoek bent, en een zeker mentaal beeld hebben hoe de onderlinge AS relaties liggen, want het is dan zeker geen bgp play interface.
Maar op moment _dat_ er een storing is, en je weet AS en prefix kun je in looking glasses veel nuttige dingen zien, en dat gaat wel real time.

Vanaf een lookingglass kun je meestal ook een ping en traceroute doen, dat zijn natuurlijk bekendere interfaces om netwerk problemen te debuggen.

2) : Ik weet dus niet of je hoster degene is die ook op BGP/AS niveau voor het netwerk verantwoordelijk is.
Het zou natuurlijk kunnnen dat van die /22 prefix jouw hoster slechts een /24 heeft, en een paar andere hosters de andere adressen, en dat hun gezamelijke upstream/DC de partij is die deze storing had moeten onderzoeken.
Inderdaad moet iemand die zo'n netwerk beheert dit kunnen onderzoeken; Alles in eigen AS en tot en met de BGP sessie naar een naburig AS kun je zelf troubleshooten, en problemen daarbuiten heb je dus looking glasses voor. En natuurlijk gewoon contacten (mail, telefoon) met de direct naburige ASen.
Een BGP sessie is _geen_ autodiscovery, dat is geconfigureerd met een bewuste keuze en wederzijdse afspraken, en dus zijn er contactgegevens.
Soms wel in een andere taal en tijdzone ...

Je kunt inderdaad keuzes maken in je announcements, hoewel invloed uitoefenen op routing policy voorbij je directe buur-ASen nogal tricky wordt.
Maar bijvoorbeeld niet (meer)announcen richting een een buur waarmee de verbinding instabiel is , is iets wat een netwerk engineer prima kan doen.

Als je hoster dan niet verantwoordelijk is voor het netwerk, maar wel voldoende kennis heeft had die ook kunnen zien dat er dingen met BGP announcements aan het misgaan waren en z'n leverancier aansturen om daar wat aan te gaan doen.
Overigens is kennis van deze materie vrij zeldzaam, voor veel hosters houdt 'het netwerk' gewoon op bij de default gateway, en is het daarachter een grote wolk 'internet' .