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
2012/1/4 Thomas Mueller thomas@chaschperli.ch
On 03.01.2012 23:13, Fredy Kuenzler wrote:
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
Hop 11 is in Paris, hop 12 in Ashburn. I don't see anomalies considering
the latency, as the atlantic is in between.
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.
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.
Sadly I can't do a traceroute from the other side.
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...
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.
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/swinoghttp://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog