Jump to content
LOTROCommunity
Nordlicht

content.turbine.com Nachmittags-Nachts unerreichbar!

Recommended Posts

Moin zusammen!

Ich habe seit gut 2 Wochen zusammen mit einem Freund aus der Sippe folgendes Problem,

das der Freund auch schon im offiziellen Technikforum angesprochen hat (selber provider, selbe Nachbarschaft).

Problem:

Ab ca. 13:30-14:00 bis ca 01:00 Nachts bekommen wir für content.turbine.com massiven Paketverlust von bis zu 90%.

In Folge lädt weder irgendeine Turbine-website korrekt zuende (Forum, lorebook etc. sowohl von lotro als z.B. auch DDO),

noch kann man den launcher vernünftig starten, da er einerseits unglaublich lange auf eine webanfrage an obige Adresse wartet, bis es dort zu einem timeout kommt (launcher hängt bei "Haupteingabemaske öffnen"), und andererseits durch den praktischen Ausfall von content.turbine.com die diversen 5-600kb großen logos nicht geladen werden, auf die der launcher wartet, bis er dann mal zur Eingabe des accountnamens und des Passwortes auffordert.

Durch obige Probleme ist es uns beiden seit gut 2 Wochen praktisch unmöglich, in den Abendstunden HdRO zu starten und zu spielen.

Es frustriert mich zusehens, daß ich zum Wechsel zu Turbine noch Geld in das Spiel gesteckt habe... *grml*

Ich quote hier nochmal den technischen Teil aus dem post meines Kollegen von oben:


Launcher***.log

[...]

Could not get HttpWebResponse for "http://content.turbine.com/sites/clientsts/lotro/en/lotro_generic_teleport_screen_09.jpg":

System.Net.WebException: The operation has timed-out.

   at System.Net.HttpWebRequest.GetResponse()

   at com.turbine.launcher.UserControls.PrereqInstallControl.GetLastModified(String url) 14.07.2011 20:51:56

Downloading "EN Loading Screen 9" from "http://content.turbine.com/sites/clientsts/lotro/en/lotro_generic_teleport_screen_09.jpg" to "***Game-directory***\raw\en\logo\lotro_generic_teleport_screen_09.jpg" 14.07.2011 20:51:56

GetLauncherConfig from: "http://gls.lotro.com/launcher/lotro/lotrolauncher.server.config.xml"        14.07.2011 20:58:24

GetLauncherConfig from: "http://gls.lotro.com/launcher/lotro/lotrolauncher.server.config.xml"        14.07.2011 21:13:24

GetLauncherConfig from: "http://gls.lotro.com/launcher/lotro/lotrolauncher.server.config.xml"        14.07.2011 21:28:25

GetLauncherConfig from: "http://gls.lotro.com/launcher/lotro/lotrolauncher.server.config.xml"        14.07.2011 21:43:25

Enter AbortPatch()                                                                                   14.07.2011 21:54:15

Leave AbortPatch()                                                                                   14.07.2011 21:54:15

Launcher shutting down                                                                               14.07.2011 21:54:15

Launcher execution ends: 14.07.2011 21:54:15                                                         14.07.2011 21:54:15

------------------------------------------

2nd Launcher***.log

[...]

EN Loading Screen 8 was already installed.                                                           14.07.2011 22:01:09

Downloading "EN Loading Screen 9" from "http://content.turbine.com/sites/clientsts/lotro/en/lotro_generic_teleport_screen_09.jpg" to "***Game-directory***\raw\en\logo\lotro_generic_teleport_screen_09.jpg" 14.07.2011 22:01:09

GetLauncherConfig from: "http://gls.lotro.com/launcher/lotro/lotrolauncher.server.config.xml"        14.07.2011 22:09:20

GetLauncherConfig from: "http://gls.lotro.com/launcher/lotro/lotrolauncher.server.config.xml"        14.07.2011 22:24:21

GetLauncherConfig from: "http://gls.lotro.com/launcher/lotro/lotrolauncher.server.config.xml"        14.07.2011 22:39:21

GetLauncherConfig from: "http://gls.lotro.com/launcher/lotro/lotrolauncher.server.config.xml"        14.07.2011 22:54:22

Enter AbortPatch()                                                                                   14.07.2011 23:07:30

Leave AbortPatch()                                                                                   14.07.2011 23:07:30

Launcher shutting down                                                                               14.07.2011 23:07:30

Launcher execution ends: 14.07.2011 23:07:30                                                         14.07.2011 23:07:30


[b]sorry folks, but [u]one hour[/u] waiting for the game to come up?[/b]

Nope, better cancel (the launcher and maybe also the payment?!?)...


------------------------------------------

>ping -t content.turbine.com

Ping a928.g.akamai.net [77.67.28.59] mit 32 Bytes Daten:

Antwort von 77.67.28.59: Bytes=32 Zeit=42ms TTL=57

Zeitüberschreitung der Anforderung.

Zeitüberschreitung der Anforderung.

Antwort von 77.67.28.59: Bytes=32 Zeit=42ms TTL=57

Antwort von 77.67.28.59: Bytes=32 Zeit=41ms TTL=57

[...]

Ping-Statistik für 77.67.28.59:

    Pakete: Gesendet = 186, Empfangen = 140, Verloren = 46 (24% Verlust),

Ca. Zeitangaben in Millisek.:

    Minimum = 40ms, Maximum = 52ms, Mittelwert = 41ms

-------------------------------------------

>tracert content.turbine.com

Routenverfolgung zu a928.g.akamai.net [77.67.28.59]  über maximal 30 Abschnitte:


  1    <1 ms    <1 ms    <1 ms  ******* [LAN]

  2    28 ms    29 ms    28 ms  ******* [my ISP]

  3    26 ms    28 ms    27 ms  ******* [my ISP]

  4    63 ms    34 ms    57 ms  ae10-0.cr01.asham.de.hansenet.net [62.109.67.1]

  5    34 ms    35 ms    35 ms  ae4-0.cr01.fra.de.hansenet.net [213.191.66.77]

  6    35 ms    35 ms    35 ms  ae1-0.xd02.fra.de.hansenet.net [62.109.69.34]

  7    56 ms    35 ms    35 ms  ae1-0.pr50.fra.de.hansenet.net [213.191.66.118]

  8    35 ms    35 ms    35 ms  ae0-0-grtfraix4.red.telefonica-wholesale.net.7.16.84.in-addr.arpa [84.16.7.185]

  9    37 ms    36 ms    36 ms  tinet-Xe2-0-3-0-grtfraix4.red.telefonica-wholesale.net [213.140.52.102]

 10    42 ms    42 ms    41 ms  xe-5-0-0.ams20.ip4.tinet.net [89.149.183.90]

 11    45 ms    41 ms    41 ms  77.67.28.59

Ablaufverfolgung beendet.

-------------------------------------------

>ping -t gls.lotro.com

Ping gls.lotro.com [74.201.102.12] mit 32 Bytes Daten:

Antwort von 74.201.102.12: Bytes=32 Zeit=130ms TTL=239

[...]

Ping-Statistik für 74.201.102.12:

    Pakete: Gesendet = 482, Empfangen = 481, Verloren = 1 (0% Verlust),

Ca. Zeitangaben in Millisek.:

    Minimum = 128ms, Maximum = 133ms, Mittelwert = 129ms

-------------------------------------------

>tracert gls.lotro.com

Routenverfolgung zu gls.lotro.com [74.201.102.12]  über maximal 30 Abschnitte:


  1    <1 ms    <1 ms    <1 ms  ******* [LAN]

  2    28 ms    28 ms    28 ms  ******* [my ISP]

  3    28 ms    27 ms    27 ms  ******* [my ISP]

  4    28 ms    28 ms    28 ms  ae9-0.cr01.weham.de.hansenet.net [62.109.72.5]

  5    35 ms    35 ms    67 ms  ae4-0.cr01.fra.de.hansenet.net [213.191.66.73]

  6    35 ms    35 ms    35 ms  ae0-0.xd02.fra.de.hansenet.net [62.109.69.30]

  7    35 ms    80 ms    34 ms  ae1-0.pr50.fra.de.hansenet.net [213.191.66.118]

  8    35 ms    35 ms    35 ms  ae0-0-grtfraix4.red.telefonica-wholesale.net.7.16.84.in-addr.arpa [84.16.7.185]

  9    44 ms    44 ms    45 ms  Xe-4-1-0-0-grtpartv1.red.telefonica-wholesale.net.121.142.94.in-addr.arpa [94.142.121.70]

 10   138 ms   126 ms   124 ms  Xe7-0-3-0-grtwaseq2.red.telefonica-wholesale.net.126.142.94.in-addr.arpa [94.142.126.77]

 11   125 ms   127 ms   125 ms  Xe8-3-0-0-grtwaseq4.red.telefonica-wholesale.net.119.142.94.in-addr.arpa [94.142.119.6]

 12   153 ms   126 ms   126 ms  Qwest-1-3-0-0-grtwaseq4.red.telefonica-wholesale.net [213.140.55.18]

 13   137 ms   136 ms   135 ms  bst-edge-05.inet.qwest.net [67.14.30.62]

 14   132 ms   131 ms   131 ms  65.120.117.250

 15   132 ms   129 ms   129 ms  border1.te7-1-bbnet1.bsn003.pnap.net [63.251.128.43]

 16   130 ms   129 ms   131 ms  74.201.102.105

 17   133 ms   132 ms   129 ms  74.201.102.154

 18   131 ms   132 ms   129 ms  74.201.102.12

Ablaufverfolgung beendet.


As the path (and "serveability") of gls.lotro.com seems to be fine,

[i]"GetLauncherConfig"[/i] should have no problem to get the necessary data and start the game up.... alas (darn logos) [/code]




Meine Frage ist nun, hat jemand von Euch ein ähnliches Problem, oder vieleicht eine Lösung?





Da das Problem wie gesagt seit gut 2 Wochen andauert haben wir inzwischen auch andere sites ausgemacht, zu denen wir nur eine miserable Verbindung bekommen können (nur Nachmittags-Nachts... früh bis Mittags läuft alles wie geschmiert!).



Es ist offenbar ein ganzer Bereich von servern von/bei Akamai betroffen, 

die alle im Bereich [b]77.67.28.X[/b] liegen, so z.B.:

[code] content.turbine.com a928.g.akamai.net [77.67.28.59] lotroimages.akamai.lotro.com a1582.g.akamai.net [77.67.28.41] WARhammerOnlinePatcher probiert es auf 77.67.28.50:80 Der WoW-launcher will zu 77.67.28.90:80 ;) i.media-imdb.com a1969.g.akamai.net [77.67.28.41] www.myfoxny.com a692.g.akamai.net [77.67.28.58] www.abendblatt.de a1949.g.akamai.net [77.67.28.80] www.welt.de a1250.g.akamai.net [77.67.28.91]

Obige websites (IMDB, Abendblatt, Welt etc.) sind z.B. jetzt gerade von meinem Anschluss aus nicht aufzurufen...

ein "ping -t Adresse" liefert Verluste jenseits der 90%!

Daher nochmal... hat von Euch niemend diese Verbindungsprobleme?

Es wäre sehr nett, wenn ihr von Euren Anschlüssen mal ein:

ping -t content.turbine.com

,ein

tracert content.turbine.com

oder dasselbe z.B. bei den websites der Zeitungen versuchen würdet, und die Ergebnisse zusammen mit Zeit, Eurem ungefähren Standort (Stadt, (Bundes-)land) und Provider hier hineinschriebet.

Achtet zur Anonymisierung darauf, dass Eure LAN-IPs und mindestens die erste IP bei Eurem Provider ausge-Xt sind! :)

TIA, Nordlicht

EDIT: Bitte zur Zeitangabe der pings/tracerts eingefügt sowie ein paar typos korrigiert

Share this post


Link to post
Share on other sites


C:>ping -t content.turbine.com


Ping a928.g.akamai.net [92.122.216.145] mit 32 Bytes Daten:


Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=32ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=39ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=25ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=14ms TTL=60

Antwort von 92.122.216.145: Bytes=32 Zeit=13ms TTL=60

Zumindest scheint es so, als wenn ihr beide etwas gemeinsam habt, z.B. den Anbieter.

Share this post


Link to post
Share on other sites

Ja, klar, vor ein paar Tagen hier gepostet:

Das sieht bei mir aktuell ganz gut aus:

Routenverfolgung zu gls.lotro.com [74.201.102.12] über maximal 30 Abschnitte: 


1 <1 ms <1 ms <1 ms meine IP*** 

2 8 ms 7 ms 8 ms öffentliche IP***

3 11 ms 11 ms 11 ms ***

4 13 ms 11 ms 11 ms 92.79.200.146 

5 15 ms 16 ms 15 ms 212.162.17.69 

6 15 ms 15 ms 15 ms ae-34-52.ebr2.Dusseldorf1.Level3.net [4.69.139.3 

3] 

7 19 ms 17 ms 18 ms ae-48-48.ebr1.Amsterdam1.Level3.net [4.69.143.20 

9] 

8 19 ms 18 ms 19 ms ae-1-100.ebr2.Amsterdam1.Level3.net [4.69.141.17 

0] 

9 26 ms 25 ms 25 ms ae-46-46.ebr2.London1.Level3.net [4.69.143.74] 

10 94 ms 94 ms 94 ms ae-44-44.ebr1.NewYork1.Level3.net [4.69.137.78] 


11 94 ms 105 ms 95 ms ae-2-2.ebr1.Newark1.Level3.net [4.69.132.98] 

12 95 ms 95 ms 96 ms ae-1-51.edge2.Newark1.Level3.net [4.68.99.9] 

13 95 ms 95 ms 94 ms 4.68.111.70 

14 95 ms 95 ms 95 ms ewr-core-02.inet.qwest.net [205.171.17.157] 

15 * * * Zeitüberschreitung der Anforderung. 

16 101 ms 101 ms 101 ms 65.120.117.250 

17 112 ms 101 ms 101 ms border1.te8-1-bbnet2.bsn003.pnap.net [63.251.128.107] 

18 103 ms 105 ms 102 ms 74.201.102.105 

19 111 ms 111 ms 110 ms 74.201.102.154 

20 102 ms 101 ms 102 ms 74.201.102.12 


Ablaufverfolgung beendet.
Naturgemäß brauchen die Pakete zwischen London und New York etwas länger.
bzw.:

C:\>tracert content.turbine.com


Routenverfolgung zu a928.g.akamai.net [92.122.216.139]  über maximal 30 Abschnit

te:


  1    <1 ms    <1 ms    <1 ms  ++++ meine ip

  2     8 ms     8 ms     8 ms  ++++ öffentliche ip

  3    11 ms    11 ms    11 ms  145.254.21.13

  4    17 ms    15 ms    15 ms  92.79.213.146

  5    13 ms    13 ms    18 ms  amsix-ams6.netarch.akamai.com [195.69.145.208]

  6    13 ms    13 ms    12 ms  a92-122-216-139.deploy.akamaitechnologies.com [9

2.122.216.139]


Ablaufverfolgung beendet.

Share this post


Link to post
Share on other sites

Öhm, nanünana.... dass' ja ne ganz andere IP! ...

Deins ist: >tracert content.turbine.com     a928.g.akamai.net [92.122.216.139]

Während ich: >tracert content.turbine.com   a928.g.akamai.net [77.67.28.59]

Es ist natürlich möglich, dass die Akamai-serverfarm/service, whatever mehrere Maschinen/Server bzw Nummernkreise für einen Namen hat (loadbalancing etc.), aber das finde ich nun doch merkwürdig...

EDIT: Mach doch bitte auch mal ein:

nslookup content.turbine.com

und

nslookup a928.g.akamai.net

/EDIT

Wärst Du so nett und traceroutest Du mal die anderen 5 URLs?

tracert lotroimages.akamai.lotro.com

tracert i.media-imdb.com

tracert www.myfoxny.com

tracert www.abendblatt.de

tracert www.welt.de

Bitte, wo sitzt Du in etwa, welchen Provider hast Du und welchen DNS server benutzt Du?

Dank Dir, Nordlicht

P.S.: Ja, natürlich, wie eingangs schon geschrieben, Kollege und ich: Nachbarschaft und selber Provider ^^

Share this post


Link to post
Share on other sites

OK, ich habe vieleicht das Problem gefunden:

Unterschiedliche DNS-Server liefern für content.turbine.com *unterschiedliche* IPs und unterschiedliche Routen aus!

D.h., je nachdem, welchem DNS server Du grad "vertraust", wird hier auf unterschiedlichen Routen auf (wahrscheinlich) verschiedene Server umgebogen...

Das ist eigentlich ein absolutes NO NO!

Hier sieht man live, was es bedeutet: "Wer den DNS kontrolliert, beherrscht das Netz!"...

Man man man! :(

Nord(mir wird grad speiübel)licht

P.S.: Wir diskutieren hier grad und *vermuten*, daß Akamai sowohl in USA wie in Europa ein Rechenzentrum mit "gespiegelten" contentservern hat und daß ein "deutscher DNS" auf das europäische RZ zeigt, während ein US-DNS (wir haben bis eben "Open-DNS" benutzt... man will sich ja nicht gänzlich widerstandsfrei Frau von der Lügens Zensur beugen... da müssen wir uns nun also eine andere Lösung überlegen ;)) zum US-RZ führt.

Oder aber das ist deren Form von traffic-shaping (wieso dann aber Nachmittags-Nachts (also zur besten US-Bürozeit ;)) deren dortiges gateway wegbricht, ist uns noch unverständlich)...

Anyway, mal gucken wie es morgen Nachmittag mit dem packetloss aussieht...

Share this post


Link to post
Share on other sites

P.S.: Ja, natürlich, wie eingangs schon geschrieben, Kollege und ich: Nachbarschaft und selber Provider ^^

Ja, und welcher denn? ;)

OK, ich habe vieleicht das Problem gefunden:Unterschiedliche DNS-Server liefern für content.turbine.com *unterschiedliche* IPs und unterschiedliche Routen aus!

Na, nicht die Routen, die ergeben sich automatisch aus der IP.

Jenachdem, wie akamai seine DNS-Server konfiguriert hat, kann das schon sein, dass die lokal unterschiedliche Werte ausgeben. Oder im Round-Robin-Verfahren mehrere und bei jeder Abfrage verschiedene.

Ich biete:

nslookup

Server:  google-public-dns-a.google.com

Address:  8.8.8.8


Nicht autorisierte Antwort:

Name:    a928.g.akamai.net

Addresses:  92.123.66.235, 92.123.66.233

Aliases:  content.turbine.com, content.turbine.com.edgesuite.net
traceroute
C:\>tracert content.turbine.com


Routenverfolgung zu a928.g.akamai.net [95.100.249.106]  über maximal 30 Abschnit

te:


  1    <1 ms    <1 ms    <1 ms  meine

  2     1 ms    <1 ms    <1 ms  meine

  3     1 ms     1 ms     1 ms  10.x.x.x (ISP)

  4     2 ms     2 ms     2 ms  10.x.x.x (ISP)

  5     3 ms     3 ms    31 ms  10.x.x.x (ISP)

  6     5 ms     3 ms     5 ms  10.x.x.x (ISP)

  7     4 ms     3 ms     3 ms  10.x.x.x (ISP)

  8     4 ms     3 ms     3 ms  10.x.x.x (ISP)

  9     4 ms     4 ms     6 ms  goodbye-le.man.mux.nu [80.64.180.86]

 10    22 ms    21 ms    21 ms  213.203.213.46

 11    22 ms    22 ms    22 ms  95.100.249.106

Aber auch die 92.x.x.x und deine 77.x.x.x liegen in Europa. Hop 1-9 wie oben,
 10    26 ms    26 ms    27 ms  xe-9-0-0.ams20.ip4.tinet.net [89.149.183.98]

 11    26 ms    27 ms    28 ms  77.67.28.59

Sieht nach Amsterdam aus :)

Share this post


Link to post
Share on other sites

OpenDNS hatte ich mal benutzt, inziwschen bin ich auch bei GoogleDNS gelandet.

Share this post


Link to post
Share on other sites

Moin moin!

Ja, und welcher denn? ;)


4    28 ms    28 ms    28 ms  ae9-0.cr01.weham.de.hansenet.net [62.109.72.5]

  5    35 ms    35 ms    67 ms  ae4-0.cr01.fra.de.hansenet.net [213.191.66.73]

  6    35 ms    35 ms    35 ms  ae0-0.xd02.fra.de.hansenet.net [62.109.69.30]

  7    35 ms    80 ms    34 ms  ae1-0.pr50.fra.de.hansenet.net [213.191.66.118]

... na? ^^
Na, nicht die Routen, die ergeben sich automatisch aus der IP. Jenachdem, wie akamai seine DNS-Server konfiguriert hat, kann das schon sein, dass die lokal unterschiedliche Werte ausgeben. Oder im Round-Robin-Verfahren mehrere und bei jeder Abfrage verschiedene.
Das meinte ich ja mit load-balancing (Round-Robin ist ja ein mögliches balancing Verfahren). Und die Routen ergeben sich deshalb automatisch aus der IP, weil eine IP über die Routingtabellen ja an ein RZ, also an einen physischen (wie logischen) Ort gebunden sind. Zwei IP-Adressen, die sich in der Endstelle nur um eine Ziffer unterscheiden, können zu zwei RechenZentren gehören, die einen halben Erdball voneinander entfernt stehen. Zu diesen sind dann auch die Routen logischerweise unterschiedlich. Genausogut können sie physisch im selben RZ stehen, aber durch die Routingtabellen "logisch" gänzlich unterschiedliche Wege nehmen, obwohl die Maschinen zu denen sie gehören im selben rack (oder im Fall von virtuellen Maschinen sogar auf derselben hardware) laufen... :) Da mein "Open-DNS" DNS jedoch für content.turbine.com beständig: a928.g.akamai.net [77.67.28.59] und a928.g.akamai.net [77.67.28.56] lieferte, zweifle ich irgendwie, dass Agras: a92-122-216-139.deploy.akamaitechnologies.com [92.122.216.139] lediglich eine weitere IP im Round-Robin-Verfahren ist, zumal es ja sogar zu einem anderen Alias-Namen auflöst. Nach Umstellung auf einen "örtlichen" DNS, liefert mir die Abfrage (z.B. über nslookup) dieselben IPs und Namen wie sie Agra weiter oben beschrieben hat. Über "open-DNS" habe ich wie schon geschrieben lediglich die [77.67.28.56 & 59] bekommen.
Ich biete: nslookup
Server:  google-public-dns-a.google.com

[...]Name:    a928.g.akamai.net

Addresses:  92.123.66.235, 92.123.66.233

Aliases:  content.turbine.com, content.turbine.com.edgesuite.net
traceroute
>tracert content.turbine.com

Routenverfolgung zu a928.g.akamai.net [95.100.249.106]  über maximal 30 Abschnit

te:

[...]   4 ms     3 ms     3 ms  10.x.x.x (ISP)

  9     4 ms     4 ms     6 ms  goodbye-le.man.mux.nu [80.64.180.86]

 10    22 ms    21 ms    21 ms  213.203.213.46

 11    22 ms    22 ms    22 ms  95.100.249.106

Da hast Du nslookup und traceroute aber über unterschiedliche DNS gefahren, korrekt? ;)
Aber auch die 92.x.x.x und deine 77.x.x.x liegen in Europa. Hop 1-9 wie oben,
 10    26 ms    26 ms    27 ms  xe-9-0-0.ams20.ip4.tinet.net [89.149.183.98]

 11    26 ms    27 ms    28 ms  77.67.28.59

Sieht nach Amsterdam aus :)

Mag sein, das ein query nach "content.turbine.com" bei unterschiedlichen DNS-Server zu sogar mehr als den 2 weiter oben von mir beschriebenen IP-Bereichen und auch Routen führt.

Das sollte aber nach Spezifikation nicht sein! ... DNS ist (eigentlich) streng hierarchisch!

Und genau diese "Tricksereien" sind es, die user in unterschiedlichen Ländern unterschiedliche Inhalte sehen lassen (ZensUrsula lässt grüßen)!

"Normalerweise" sollte eine DNS-Anfrage bzw. ein nslookup (eine DNS-Anfrage liefert zu jeder Anfrage ja jeweils nur eine IP ^^ ) bei jedem DNS dieselbe IP- & Aliasliste ergeben (mehrere IPs halt z.B. wegen vorgeschalteten load-balancern)...

Aber, um mal auf mein spezifisches Problem zurückzukommen:

Wieso bricht bitte "meine" Route bzw. brechen meine "Anlaufserver" [77.67.28.56 & 59] beständig nach 14:00 bis 1:00 Nachts (GMT(+1)) weg, sodaß ein Zugriff über diese IPs/Routen zu den (Web)Inhalten (über [77.67.28.56.X]) von Turbine, IMDB, Abendblatt und Welt etc. praktisch nicht mehr möglich ist?

Wenn es sich doch nur um "loadbalancing"-Verfahren handelt, die auf dieselben "pysischen" Inhaltsserver zugreifen?

Ausser meiner im vorigen post schon geäusserten Vermutung, dass es sich dabei um Routen zu pysikalisch unterschiedlichen Server(farmen) mit gespiegelten Inhalten (backup-/Hochverfügbarkeitslösung) handelt,

kann ich mir sonst nur noch die Möglichkeit vorstellen, das "meine" Route eine fallbacklösung darstellt, wobei auf dieser Route ab 14:00 (Beginn der Bürozeit in den USA ;)) derart viel traffic läuft, daß es meine Abfragen für jeweils den halben Tag abwürgt.

Du meinst ja, "Aber auch die 92.x.x.x und deine 77.x.x.x liegen in Europa. [..] Sieht nach Amsterdam aus :)"...

woher also die Unterschiede?

Ist zwar Wochenende, aber über Agras IPs (DNS wie gesagt auf lokalen provider umgestellt) habe ich z.Zt keine Verbindungsprobleme...

Deine (Eure) Meinungen, Einschätzungen, Ansätze, Fragen? :)

Just my 2c, Nordlicht

Share this post


Link to post
Share on other sites

Da hast Du nslookup und traceroute aber über unterschiedliche DNS gefahren, korrekt? ;)

Ich nicht. Windows. ;)

Ping, traceroute usw. greifen auf die im Resolver gecachte IP zu, während nslookup eine neue Anfrage an den DNS stellt. Warum der da aber google gefragt hat (2. DNS) statt meinen Router (als 1. DNS-Server in den Netzwerkeinstellungen eingetragen), kann ich dir nicht sagen.

Das sollte aber nach Spezifikation nicht sein! ... DNS ist (eigentlich) streng hierarchisch!

Und genau diese "Tricksereien" sind es, die user in unterschiedlichen Ländern unterschiedliche Inhalte sehen lassen (ZensUrsula lässt grüßen)!

"Normalerweise" sollte eine DNS-Anfrage bzw. ein nslookup (eine DNS-Anfrage liefert zu jeder Anfrage ja jeweils nur eine IP ^^ ) bei jedem DNS dieselbe IP- & Aliasliste ergeben (mehrere IPs halt z.B. wegen vorgeschalteten load-balancern)...

Wie du oben siehst, können auch mehrere IP-Adressen auf eine Anfrage zurückkommen.

Ich kenn' das RFC jetzt nicht aus dem Kopf, aber angenommen, man könnte 100 A-Records (IP-Adressen) für einen Namen hinterlegen, in der Antwort sind aber maximal 5 erlaubt. Dann muss der authoritative DNS-Server ja nach irgendeinem Verfahren 5 auswählen, die er sendet. Und dies kann schon nach geografischen Gesichtspunkten anhand der IP des anfragenden (Cache-)Servers geschehen.

Da die Antworten ja gecached werden (im Windows, im DNS-server deines Providers, Open-DNS, ...) sollte ein Client-Programm allerdings immer die gleiche IP mitgeteilt bekommen.

Aber, um mal auf mein spezifisches Problem zurückzukommen:

Wieso bricht bitte "meine" Route bzw. brechen meine "Anlaufserver" [77.67.28.56 & 59] beständig nach 14:00 bis 1:00 Nachts (GMT(+1)) weg, sodaß ein Zugriff über diese IPs/Routen zu den (Web)Inhalten (über [77.67.28.56.X]) von Turbine, IMDB, Abendblatt und Welt etc. praktisch nicht mehr möglich ist?

Das solltest du deinen Provider fragen. Entweder technisches Problem, überlastete Leitungen, zeitabhängiges Routing. Da gibt es viele Möglichkeiten.

Es könnte natürlich auch eine Antwort in der Art kommen: "Verwenden Sie bitte unseren DNS, die Routen zu den von uns ausgelieferten IP-Adressen sind stabil."

IP-Traffic kostest Geld. Warum soll der Provider Daten um die halbe Welt schicken (mit einem teuren Partner peeren), wenn ein passendes Rechenzentrum (und kostengünstiger Peeringpartner) gleich nebenan steht. Sprich, es könnte auch eine künstliche Beeinträchtigung bestimmer Routen/Netze sein.

Bedenke, dadurch, dass du einen DNS-Server in Amerika fragst, hebelst du das (geografische) Loadbalancing ja im Prinzip aus.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×