Vodafone Kabel hat hier in der Region eine Eigenheit, welche die Latenz beeinflusst. Es gibt hier zwei Routen über welche die Pakete nach Frankfurt geschickt werden. Eine Route geht direkt vom cmts nach Frankfurt, die andere nimmt einen Umweg über Stuttgart. Da kommt es drauf an welche IP man erhalten hat. Die Routen sind an IPs gebunden. Ist also IP Lotterie hier in der Region mit Vodafone. Ich hab schon mehrfach temporär die mac Adresse des wan interfaces spoofen müssen bis der docsis Anschluss wieder eine IP zugewiesen bekam, die direkt nach Frankfurt geht. Dann stimmt aber auch die Latenz mit 10ms sofern das Segment nicht wieder dicht ist.
Routenverfolgung zu heise.de [193.99.144.80]
über maximal 30 Hops:
1 * * * Zeitüberschreitung der Anforderung.
2 8 ms 9 ms 9 ms ip-081-210-144-156.um21.pools.vodafone-ip.de [81.210.144.156]
3 10 ms 13 ms 13 ms de-fra04d-rc1-ae-48-0.aorta.net [84.116.191.161]
4 10 ms 10 ms 10 ms 84.116.190.94
5 12 ms 11 ms 10 ms be100.c350.f.de.plusline.net [80.81.193.132]
6 10 ms 10 ms 11 ms te2-2.c301.f.de.plusline.net [82.98.102.1]
7 11 ms 11 ms 12 ms 82.98.103.3
8 11 ms 10 ms 10 ms 212.19.61.13
9 10 ms 11 ms 11 ms redirector.heise.de [193.99.144.80]
Alles anzeigen
Wäre es nun eine IP die über Stuttgart geht, wäre zwischen hop 2 und 3 noch dieser drin
de-str01c-rc1-ae36-0.aorta.net [84.116.191.225]
Erkennt man anhand der Bezeichnungen der Hops, wo der Übergabepunkt von o2 ist?
ich habe hier nun mal für folgende Adresse alle Karlsruher probes von o2 und der DTAG durchgespielt
45.142.115.12
O2
Probe #1000169 (sieht nach ftth aus)
Fetching Measurement: 146523960
Traceroute from 78.51.186.11 to 45.142.115.12 (45.142.115.12):
1 dynamic-078-051-186-009.78.51.pool.telefonica.de (78.51.186.9) 1.108ms 0.549ms 0.616ms
2 loopback1.0005.acln.02.fra.de.net.telefonica.de (62.52.193.29) 7.6ms 7.534ms 7.354ms
3 bundle-ether37.0001.cord.02.fra.de.net.telefonica.de (62.53.12.56) 7.412ms 7.524ms 7.786ms
4 bundle-ether1.0002.prrx.09.fra.de.net.telefonica.de (62.53.13.89) 7.296ms 7.146ms 7.323ms
5 * * *
6 ae18-2025.fra20.core-backbone.com (5.56.17.25) 6.862ms 6.916ms 7.207ms
7 5.56.17.191 7.802ms 16.462ms 7.293ms
8 12.115.142.45.in-addr.arpa (45.142.115.12) 7.743ms 7.923ms 7.546ms
Probe #1004854 (sieht nach DSL aus)
Fetching Measurement: 146524392
Traceroute from 10.126.35.28 to 45.142.115.12 (45.142.115.12):
1 10.126.35.25 1.006ms 0.801ms 0.649ms
2 10.0.80.195 19.541ms 19.692ms 20.1ms
3 10.81.102.100 19.205ms 28.941ms 29.674ms
4 10.81.85.22 20.791ms 19.675ms 19.834ms
5 bvi500.0001.cord.01.off.de.net.telefonica.de (62.52.49.34) 20.747ms 20.659ms 20.747ms
6 ae0-0.0020.corp.11.fra.de.net.telefonica.de (62.53.12.53) 19.725ms 19.973ms 19.22ms
7 ae24-0.fra10.core-backbone.com (5.56.17.93) 20.106ms 19.569ms 20.003ms
8 ae2-2021.fra20.core-backbone.com (80.255.14.6) 18.617ms 18.74ms 19.745ms
9 5.56.17.191 53.817ms 60.609ms 47.734ms
10 12.115.142.45.in-addr.arpa (45.142.115.12) 22.22ms 21.219ms 20.665ms
Alles anzeigen
DTAG
Probe #21421
Fetching Measurement: 146524434
Traceroute from 10.0.30.150 to 45.142.115.12 (45.142.115.12):
1 10.0.30.254 0.996ms 0.345ms 0.278ms
2 p3e9bf571.dip0.t-ipconnect.de (62.155.245.113) 6.973ms 6.448ms 6.656ms
3 m-ef2-i.M.DE.NET.DTAG.DE (217.5.110.10) 13.186ms 12.684ms 13.519ms
4 80.150.168.185 15.452ms 14.743ms 14.536ms
5 ae4.cr5-fra6.ip4.gtt.net (89.149.140.174) 15.784ms 15.068ms 15.077ms
6 ip4.gtt.net (213.39.68.18) 24.136ms 23.859ms 28.716ms
7 12.115.142.45.in-addr.arpa (45.142.115.12) 15.911ms 15.313ms 15.485ms
Probe #50626
Fetching Measurement: 146524814
Traceroute from 10.11.128.135 to 45.142.115.12 (45.142.115.12):
1 10.11.128.1 1.2ms 0.674ms 0.588ms
2 p3e9bf533.dip0.t-ipconnect.de (62.155.245.51) 14.628ms 16.372ms 14.152ms
3 m-ef2-i.M.DE.NET.DTAG.DE (217.5.110.22) 20.257ms 18.99ms 19.468ms
4 80.150.168.185 20.537ms 21.506ms 21.12ms
5 ae4.cr5-fra6.ip4.gtt.net (89.149.140.174) 22.085ms 20.81ms 21.312ms
6 ip4.gtt.net (213.39.68.18) 28.065ms 28.281ms 35.181ms
7 12.115.142.45.in-addr.arpa (45.142.115.12) 22.403ms 23.286ms 22.554ms
Probe #21421
Fetching Measurement: 146524434
Traceroute from 10.0.30.150 to 45.142.115.12 (45.142.115.12):
1 10.0.30.254 0.996ms 0.345ms 0.278ms
2 p3e9bf571.dip0.t-ipconnect.de (62.155.245.113) 6.973ms 6.448ms 6.656ms
3 m-ef2-i.M.DE.NET.DTAG.DE (217.5.110.10) 13.186ms 12.684ms 13.519ms
4 80.150.168.185 15.452ms 14.743ms 14.536ms
5 ae4.cr5-fra6.ip4.gtt.net (89.149.140.174) 15.784ms 15.068ms 15.077ms
6 ip4.gtt.net (213.39.68.18) 24.136ms 23.859ms 28.716ms
7 12.115.142.45.in-addr.arpa (45.142.115.12) 15.911ms 15.313ms 15.485ms
Bei dieser frankfurter IP (Quake live server) stört mich bei der tkom ziemlich, dass sie die Pakete hier aus Kehl erstmal nach München schickt und dann nach frankfurt. Das lässt aufhorchen.
Wenn ihr nun sagt, dass die zugesicherten Bandbreiten laut Produktinformation eine untergeordnete Rolle spielen, da sie so oder so praktisch immer anliegen, würde nur noch der service ein Punkt für die telekom bleiben. Aber in den sauren Apfel würde ich ggf. beißen und das Risiko eingehen. Diese seltsamen peerings der tkom sind mir zu hanebüchen. Einzig die 24h Zwangstrennung von O2 ist noch ein recht negativer Punkt....