Hello,
If i suppose that's:
- the AS11449 (which manages the subnet 206.106.137.0/24) is using Level3 as upstream provider to reach the subnet 195.186.0.0/17
- your public IP belongs to the subnet 195.186.0.0/17
- Level3 is using same routing policies regardless IP source subnet (206.106.137.0/24 and 4.0.0.0/9... (/9 opps :-/))
A traceroute from the other side should look like that (based on Level3's looking glass):
Show Level 3 (Stamford, CT) Traceroute to 195.186.27.22
1 ge-6-7.car1.Stamford1.Level3.net (4.69.143.45) 16 msec
ge-6-4.car1.Stamford1.Level3.net (4.69.143.25) 0 msec
ge-6-7.car1.Stamford1.Level3.net (4.69.143.45) 0 msec
2 ae-5-5.ebr1.NewYork1.Level3.net (4.69.142.86) 4 msec 0 msec 0 msec
3 ae-42-42.ebr2.London1.Level3.net (4.69.137.69) 104 msec
ae-41-41.ebr2.London1.Level3.net (4.69.137.65) 76 msec
ae-43-43.ebr2.London1.Level3.net (4.69.137.73) 72 msec
4 ae-24-24.ebr2.Frankfurt1.Level3.net (4.69.148.198) 148 msec 84 msec 132 msec
5 ae-82-82.csw3.Frankfurt1.Level3.net (4.69.140.26) 84 msec 80 msec
ae-72-72.csw2.Frankfurt1.Level3.net (4.69.140.22) 80 msec
6 * *
ae-4-90.edge5.Frankfurt1.Level3.net (4.69.154.201) 156 msec
7 195.16.160.78 276 msec 200 msec 200 msec
8 i69lss-025-bun3x200.bb.ip-plus.net (138.187.130.96) [AS3303 {RIPE-ASNBLOCK4}] 200 msec 148 msec 152 msec
9 *
i68geb-005-gig8-1-0.bb.ip-plus.net (138.187.129.153) [AS3303 {RIPE-ASNBLOCK4}] 96 msec 96 msec
10 po52.zhbdz09p-rtdi01.bluewin.ch (195.186.0.165) [AS3303 {RIPE-ASNBLOCK4}] 88 msec * *
[...]
21 * * * timeout !
Well it's clear that upstream and downstream paths are not the same!
Upstream (from the xDSL point of view)
A/ Bluewin: ???
B/ Swisscom: ???
C/ Telia: Zurich >> Paris >> Ashburn
D/ Level 3: Ashburn >> Washington >> New York >> Stamford
E/
Downstream (from the xDSL point of view)
A/ Level 3: Stamford >> New York >> London >> Frankfurt
B/ Swisscom: ???
C/ Bluewin: ???
So... The problem seems to come from a new routing policy somewhere in the path... and it may create jitter !
Well... That's why banks and exchanges pay their bandwidth so much „$ to avoid such kind of trouble (and of course to have the best latency ;-) )
Cheers,
Yann
On 03.01.2012 23:13, Fredy Kuenzler wrote:ah, beginner's mistake. :) I was on some geoip page that told me it was in EU and the map showed a point in switzerland.
Hop 11 is in Paris, hop 12 in Ashburn. I don't see anomalies considering the latency, as the atlantic is in between.Responsetime of hop 12 (80.91.251.98) is much higher than hop 11 (80.91.249.113) and a ping test did show lost packets on hop 12 but not on hop 11.
11 prs-bb1-link.telia.net (80.91.249.113) [AS1299] 25.882 ms 125.402 ms 25.827 ms
12 ash-bb1-link.telia.net (80.91.251.98) [AS1299] 108.584 ms 113.053 ms ash-bb1-link.telia.net (80.91.252.36) [AS1299] 158.407 ms
Sadly I can't do a traceroute from the other side.
The path seems to be multipath, but this is still ok. The loss / congestion could be on the return path, for proper diagnosis you need a traceroute from the other end, too.
yeah I know about the xDSL, guaranteed latency and "best effort" things. it's just a more or less one-man show and he does not bother about possible outages. the connection was working for about 2 years now and it is only slow on startup (after a 30min startup, the app is working normally). Seems it's just a problem while downloading some initial things.
Check return pathes to proxies and compare them to the direct link... and, as Victor already said, don't expect guaranteed latecy on a xDSL service...
as it seems to be a problem that is catchy to solve, he'll work with the easy solution of using a proxy (startup time: 30seconds).
thanks to all others who have answerd!
- Thomas
_______________________________________________
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog