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/swinog