Die Peerings am Standort Finnland beim Hoster mit dem großen H sind ja mal ein Reinfall.
Norddeutschland (Vodafone) geht erstmal über Frankfurt anstatt über Hamburg.
Von Finnland nach Google (8.8.8.8, google.fi) wird man in Amsterdam ins Google Netz geleitet.
27ms von einem Server zu Google sind ganz schön happig.
Genauso wie von meinem Standort 40 bis 50ms... ohje
Falls jemanden noch was einfällt, woran ich hätte denken sollen, bitte Bescheid sagen
find /etc -type f -exec grep -FH 10.0.0.1 {} +
# Eventuell auch noch mit einer anderen Schreibweise,
# falls es in irgendeiner Datei als Regex vorkommt...
find /etc -type f -exec grep -FH '10\.0\.0\.1' {} +Die Peerings am Standort Finnland beim Hoster mit dem großen H sind ja mal ein Reinfall.
...
dafür habe ich den Eindruck, das Weiße Haus ist unter meinem Bett,
einfach mal traceroute http://www.whitehouse.gov 
(das hat weniger Hops als zu meinem Arbeitsplatz ums Eck 
)
dafür habe ich den Eindruck, das Weiße Haus ist unter meinem Bett,
einfach mal traceroute http://www.whitehouse.gov
(das hat weniger Hops als zu meinem Arbeitsplatz ums Eck
Die verwenden Akamai. Landet bei mir in NL. Dadurch geht das nicht über den Atlantik.
Die Peerings am Standort Finnland beim Hoster mit dem großen H sind ja mal ein Reinfall.
Norddeutschland (Vodafone) geht erstmal über Frankfurt anstatt über Hamburg.
Von Finnland nach Google (8.8.8.8, google.fi) wird man in Amsterdam ins Google Netz geleitet.
27ms von einem Server zu Google sind ganz schön happig.
Genauso wie von meinem Standort 40 bis 50ms... ohje
VF is da eh komisch oft. was für wege das ganze geht. Ich gehe aktuell über VF zu DECIX zu H zu NetCup
Netcup scheint am DE-CIX allerdings nicht mit Vodafone zu peeren.
VF is da eh komisch oft. was für wege das ganze geht. Ich gehe aktuell über VF zu DECIX zu H zu NetCup
Netcup scheint am DE-CIX allerdings nicht mit Vodafone zu peeren.
Vor einem Monat sah das aber noch anders aus. Über Core Backbone ging es noch ohne H. Mit Anexia gibt es kein direktes Peering zu VF mehr.
Über Corebackbone (im Februar) waren die Pings zu meinen Servern und zum ersten GW im NC-Netz auch um 10ms schneller...
voja eh bei mir auch, aber derart wenige Hops, daß ma meint die Kiste is unterm Bett
jetzt sind wa wieder dort wie früher bei der Telephonie:
vom Nebenzimmer meinte man der is irgendwo im Urwald
und von Djschibuti klar wie vom Nebenzimmer
(das ist jetzt aber keine Unterstellung, daß Djschibuti der Urwald ist)
Dürfte ich um Traceroutes bezüglich des Routings bitten? Am Besten direkt per Mail schicken.
habs im Contactform im CCP gerade abgeschickt.
Gut erkannt, Hecke29!
Genau... "Erkannt"
dafür habe ich den Eindruck, das Weiße Haus ist unter meinem Bett,
einfach mal traceroute http://www.whitehouse.gov
(das hat weniger Hops als zu meinem Arbeitsplatz ums Eck
Das weiße Haus hat einen guten ping, aber ganze 3 Hops zwischen meiner öffentlichen IP und dem Zielserver.
[user@host ~]$ ping www.whitehouse.gov
[..]
rtt min/avg/max/mdev = 1.849/1.952/2.029/0.083 msDafür haben die vServer weniger Hops aber einen deutlich schlechteren ping:
[user@host ~]$ traceroute vserver bei netcup
7. public ip
8. gw-decix.ffm.netcup.net
9. vserver bei netcup
[user@host ~]$ ping vserver bei netcup
[...]
rtt min/avg/max/mdev = 5.067/5.473/6.113/0.317 msErgebnis: 1/3 weniger Hops, aber dafür einen 3mal so schlechten Ping. Kann man da noch was optimieren? Wieso haben die vServer hier einen so miesen ping??!!!
Ist halt die Frage: warum exportiert H das NC Netz für VF?
Netcup bezieht IP-Transit von H. Auch wenn dieser primär als Fallback dient, präferieren zahlreiche Provider den Routen über H (z.B. weil sie nicht mit netcup oder Anexia peeren).
Dies ist übrigens schon lange so. Als noch über Core-Backbone geroutet wurde, fiel das nur kaum auf, da Core-Backbone deutlich mehr Peerings als Anexia oder H hat.
also genau genommen ist die Route hier wie folgt:
Andersrum:
zu meinem vServer bei netcup via IPv6
# traceroute6 vServer
traceroute to vServer (2a03:4000:xxxx), 30 hops max, 80 byte packets
1 tunnel###.tunnel.tserv6.fra1.ipv6.he.net (2001:470:xxxx) 33.936 ms 29.921 ms 39.550 ms
2 10ge3-18.core1.fra1.he.net (2001:470:0:69::1) 52.872 ms 52.823 ms 52.787 ms
3 gw6-decix.ffm.netcup.net (2001:7f8::3:3a4:0:1) 51.459 ms 51.434 ms 51.400 ms
4 vServer (2a03:4000:xxxx) 42.501 ms 42.481 ms 42.443 ms
via IPv4
# traceroute vServer
traceroute to vServer (xxxx), 30 hops max, 60 byte packets
1 dmz (rfc1918-ip) 0.305 ms 0.473 ms 0.164 ms
2 * * *
3 gate0.isp.net (xxxx) 20.979 ms 21.000 ms 20.814 ms
4 gate1.isp.net (xxxx) 14.355 ms 13.306 ms 14.012 ms
5 ae0-408.vie10.core-backbone.com (80.255.15.209) 16.066 ms 15.882 ms 15.897 ms
6 ae1-2014.nbg40.core-backbone.com (81.95.15.206) 39.305 ms 38.696 ms 40.823 ms
7 core-backbone.hxxx (81.95.15.6) 26.728 ms 19.410 ms 18.677 ms
8 core11.nbg1.hxxx (213.239.229.161) 22.640 ms core12.nbg1.hxxx (213.239.229.165) 23.343 ms 23.204 ms
9 gw-hetzner1.nbg.netcup.net (78.47.244.254) 25.314 ms 21.967 ms 24.498 ms
10 vServer (xxxx) 29.779 ms 21.966 ms 20.959 ms
z.B. weil sie nicht mit netcup oder Anexia peeren
https://bgp.he.net/AS31334#_peers an Stelle 36: Anexia
