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 <[email protected]>
> 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
> [email protected]
> http://lists.swinog.ch/cgi-**bin/mailman/listinfo/swinog<http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog>
>
_______________________________________________
swinog mailing list
[email protected]
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
