Hi
a customer got problems with an application (trading tool) downloading from a server in the USA (206.106.137.3). A traceroute below.
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.
the same application runs fine with a http proxy at LayerOne (init7), a proxy on a hosteurope vps or on a Cablecom connection.
Is this the right place to report such a problem and aksing for help?
Thank you!
- Thomas
traceroute to 206.106.137.3 (206.106.137.3), 30 hops max, 60 byte packets 1 192.168.14.1 (192.168.14.1) [AS8151/AS28513] 1.394 ms 1.759 ms 1.362 ms 2 10.136.21.195 (10.136.21.195) [AS65534] 12.432 ms 13.231 ms 12.544 ms 3 22-27.186-195.fws.bluewin.ch (195.186.27.22) [AS3303/AS44038] 17.615 ms 18.040 ms 17.171 ms 4 85-27.186-195.fws.bluewin.ch (195.186.27.85) [AS3303/AS44038] 20.192 ms 17.757 ms 17.520 ms 5 tge2-4.zhhia01p-rtdi01.bluewin.ch (195.186.51.5) [AS3303/AS44038] 17.251 ms 17.302 ms 17.138 ms 6 tge2-4.zhhia01p-rtdi01.bluewin.ch (195.186.51.5) [AS3303/AS44038] 17.072 ms 17.700 ms 16.912 ms 7 net1702.zhhdz09p-rtdi01.bluewin.ch (213.3.247.169) [AS3303/AS44038] 17.966 ms 17.929 ms 17.966 ms 8 202-0-186-195.bluewin.ch (195.186.0.202) [AS3303/AS44038] 21.432 ms 19.125 ms 19.938 ms 9 i79tix-005-ae0.bb.ip-plus.net (138.187.129.7) [AS3303] 17.386 ms 17.596 ms 21.142 ms 10 zch-b1-link.telia.net (213.248.90.237) [AS1299] 17.117 ms 17.686 ms 17.173 ms 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 13 level3-ic-130870-ash-bb1.c.telia.net (213.248.89.178) [AS1299] 114.600 ms 114.618 ms 124.009 ms 14 vlan80.csw3.Washington1.Level3.net (4.69.149.190) [AS3356] 120.899 ms 120.495 ms 120.235 ms 15 ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) [AS3356] 113.387 ms 114.457 ms ae-82-82.ebr2.Washington1.Level3.net (4.69.134.153) [AS3356] 120.064 ms 16 ae-3-3.ebr1.NewYork2.Level3.net (4.69.132.90) [AS3356] 112.147 ms 112.035 ms 112.211 ms 17 ae-1-100.ebr2.NewYork2.Level3.net (4.69.135.254) [AS3356] 116.964 ms 116.742 ms 110.879 ms 18 ae-5-5.car2.Stamford1.Level3.net (4.69.142.81) [AS3356] 116.335 ms 123.342 ms 116.644 ms 19 INTERACTIVE.car2.Stamford1.Level3.net (4.26.50.110) [AS3356] 122.280 ms 117.676 ms 116.042 ms 20 www.interactivebrokers.com (206.106.137.3) [AS11449] 118.604 ms 117.565 ms 118.602 ms 22ms
traceroute and ping response times are just the indication how fast the management board on a particular router is able to send ICMP packets. If the management board is busy, it doesn't mean that the traffic is affected.
so, it needs a more detailed investigation with your provider, and most probably the problem lays outside of your ISP's control. Maybe some intermediate link somewhere is oversaturated, but that's not going to be changed at free will.
You can only get guaranteed throughput if you buy an end-to-end business connectivity service, but that's going to cost you an arm and a leg.
From: Thomas Mueller thomas@chaschperli.ch To: swinog@lists.swinog.ch Sent: Tuesday, January 3, 2012 4:45 PM Subject: [swinog] Swisscom VDSL -> TELIA -> USA problem
Hi
a customer got problems with an application (trading tool) downloading from a server in the USA (206.106.137.3). A traceroute below.
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.
the same application runs fine with a http proxy at LayerOne (init7), a proxy on a hosteurope vps or on a Cablecom connection.
Is this the right place to report such a problem and aksing for help?
Thank you!
- Thomas
traceroute to 206.106.137.3 (206.106.137.3), 30 hops max, 60 byte packets 1 192.168.14.1 (192.168.14.1) [AS8151/AS28513] 1.394 ms 1.759 ms 1.362 ms 2 10.136.21.195 (10.136.21.195) [AS65534] 12.432 ms 13.231 ms 12.544 ms 3 22-27.186-195.fws.bluewin.ch (195.186.27.22) [AS3303/AS44038] 17.615 ms 18.040 ms 17.171 ms 4 85-27.186-195.fws.bluewin.ch (195.186.27.85) [AS3303/AS44038] 20.192 ms 17.757 ms 17.520 ms 5 tge2-4.zhhia01p-rtdi01.bluewin.ch (195.186.51.5) [AS3303/AS44038] 17.251 ms 17.302 ms 17.138 ms 6 tge2-4.zhhia01p-rtdi01.bluewin.ch (195.186.51.5) [AS3303/AS44038] 17.072 ms 17.700 ms 16.912 ms 7 net1702.zhhdz09p-rtdi01.bluewin.ch (213.3.247.169) [AS3303/AS44038] 17.966 ms 17.929 ms 17.966 ms 8 202-0-186-195.bluewin.ch (195.186.0.202) [AS3303/AS44038] 21.432 ms 19.125 ms 19.938 ms 9 i79tix-005-ae0.bb.ip-plus.net (138.187.129.7) [AS3303] 17.386 ms 17.596 ms 21.142 ms 10 zch-b1-link.telia.net (213.248.90.237) [AS1299] 17.117 ms 17.686 ms 17.173 ms 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 13 level3-ic-130870-ash-bb1.c.telia.net (213.248.89.178) [AS1299] 114.600 ms 114.618 ms 124.009 ms 14 vlan80.csw3.Washington1.Level3.net (4.69.149.190) [AS3356] 120.899 ms 120.495 ms 120.235 ms 15 ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) [AS3356] 113.387 ms 114.457 ms ae-82-82.ebr2.Washington1.Level3.net (4.69.134.153) [AS3356] 120.064 ms 16 ae-3-3.ebr1.NewYork2.Level3.net (4.69.132.90) [AS3356] 112.147 ms 112.035 ms 112.211 ms 17 ae-1-100.ebr2.NewYork2.Level3.net (4.69.135.254) [AS3356] 116.964 ms 116.742 ms 110.879 ms 18 ae-5-5.car2.Stamford1.Level3.net (4.69.142.81) [AS3356] 116.335 ms 123.342 ms 116.644 ms 19 INTERACTIVE.car2.Stamford1.Level3.net (4.26.50.110) [AS3356] 122.280 ms 117.676 ms 116.042 ms 20 www.interactivebrokers.com (206.106.137.3) [AS11449] 118.604 ms 117.565 ms 118.602 ms 22ms
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hi Thomas
First of all - it might be a place to ask for help, if it was a Swiss peering or routing problem. Given the traceroute you posted, it doesn't look like there's much that can be done in Switzerland.
On 2nd thought... as VDSL customer, you're on "best effort" and have no guarantees that anything will work at all. In Forex trading (that's what this seems to be about), we're talking about miliseconds in which deals change and need to be placed - network latency is *THE* big issue for trading companies. They'll pay tenthousands a month just to get a milisecond less of latency. So if your customer is serious about Forex trading, he should lose this VDSL and look into some real uplink.
Good luck, Viktor
On 03.01.2012 4:45, Thomas Mueller wrote:
Hi
a customer got problems with an application (trading tool) downloading from a server in the USA (206.106.137.3). A traceroute below.
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.
the same application runs fine with a http proxy at LayerOne (init7), a proxy on a hosteurope vps or on a Cablecom connection.
Is this the right place to report such a problem and aksing for help?
Thank you!
- Thomas
traceroute to 206.106.137.3 (206.106.137.3), 30 hops max, 60 byte packets 1 192.168.14.1 (192.168.14.1) [AS8151/AS28513] 1.394 ms 1.759 ms 1.362 ms 2 10.136.21.195 (10.136.21.195) [AS65534] 12.432 ms 13.231 ms 12.544 ms 3 22-27.186-195.fws.bluewin.ch (195.186.27.22) [AS3303/AS44038] 17.615 ms 18.040 ms 17.171 ms 4 85-27.186-195.fws.bluewin.ch (195.186.27.85) [AS3303/AS44038] 20.192 ms 17.757 ms 17.520 ms 5 tge2-4.zhhia01p-rtdi01.bluewin.ch (195.186.51.5) [AS3303/AS44038] 17.251 ms 17.302 ms 17.138 ms 6 tge2-4.zhhia01p-rtdi01.bluewin.ch (195.186.51.5) [AS3303/AS44038] 17.072 ms 17.700 ms 16.912 ms 7 net1702.zhhdz09p-rtdi01.bluewin.ch (213.3.247.169) [AS3303/AS44038] 17.966 ms 17.929 ms 17.966 ms 8 202-0-186-195.bluewin.ch (195.186.0.202) [AS3303/AS44038] 21.432 ms 19.125 ms 19.938 ms 9 i79tix-005-ae0.bb.ip-plus.net (138.187.129.7) [AS3303] 17.386 ms 17.596 ms 21.142 ms 10 zch-b1-link.telia.net (213.248.90.237) [AS1299] 17.117 ms 17.686 ms 17.173 ms 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 13 level3-ic-130870-ash-bb1.c.telia.net (213.248.89.178) [AS1299] 114.600 ms 114.618 ms 124.009 ms 14 vlan80.csw3.Washington1.Level3.net (4.69.149.190) [AS3356] 120.899 ms 120.495 ms 120.235 ms 15 ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) [AS3356] 113.387 ms 114.457 ms ae-82-82.ebr2.Washington1.Level3.net (4.69.134.153) [AS3356] 120.064 ms 16 ae-3-3.ebr1.NewYork2.Level3.net (4.69.132.90) [AS3356] 112.147 ms 112.035 ms 112.211 ms 17 ae-1-100.ebr2.NewYork2.Level3.net (4.69.135.254) [AS3356] 116.964 ms 116.742 ms 110.879 ms 18 ae-5-5.car2.Stamford1.Level3.net (4.69.142.81) [AS3356] 116.335 ms 123.342 ms 116.644 ms 19 INTERACTIVE.car2.Stamford1.Level3.net (4.26.50.110) [AS3356] 122.280 ms 117.676 ms 116.042 ms 20 www.interactivebrokers.com (206.106.137.3) [AS11449] 118.604 ms 117.565 ms 118.602 ms 22ms
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
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.
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.
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...
HTH, F.
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
Hi Thomas
First of all - it might be a place to ask for help, if it was a Swiss peering or routing problem. Given the traceroute you posted, it doesn't look like there's much that can be done in Switzerland.
I am quite surprised to read such a comment. This mailing list HAVE TO BE OPEN for any kind of troubles ..
On 2nd thought... as VDSL customer, you're on "best effort" and have no guarantees that anything will work at all. In Forex trading (that's what this seems to be about), we're talking about miliseconds in which deals change and need to be placed - network latency is *THE* big issue for trading companies. They'll pay tenthousands a month just to get a milisecond less of latency. So if your customer is serious about Forex trading, he should lose this VDSL and look into some real uplink.
Cheers,
Good luck, Viktor
On 03.01.2012 4:45, Thomas Mueller wrote:
Hi
a customer got problems with an application (trading tool) downloading from a server in the USA (206.106.137.3). A traceroute below.
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.
the same application runs fine with a http proxy at LayerOne (init7), a proxy on a hosteurope vps or on a Cablecom connection.
Is this the right place to report such a problem and aksing for help?
Thank you!
- Thomas
traceroute to 206.106.137.3 (206.106.137.3), 30 hops max, 60 byte packets 1 192.168.14.1 (192.168.14.1) [AS8151/AS28513] 1.394 ms 1.759 ms 1.362 ms 2 10.136.21.195 (10.136.21.195) [AS65534] 12.432 ms 13.231 ms 12.544 ms 3 22-27.186-195.fws.bluewin.ch (195.186.27.22) [AS3303/AS44038] 17.615 ms 18.040 ms 17.171 ms 4 85-27.186-195.fws.bluewin.ch (195.186.27.85) [AS3303/AS44038] 20.192 ms 17.757 ms 17.520 ms 5 tge2-4.zhhia01p-rtdi01.bluewin.ch (195.186.51.5) [AS3303/AS44038] 17.251 ms 17.302 ms 17.138 ms 6 tge2-4.zhhia01p-rtdi01.bluewin.ch (195.186.51.5) [AS3303/AS44038] 17.072 ms 17.700 ms 16.912 ms 7 net1702.zhhdz09p-rtdi01.bluewin.ch (213.3.247.169) [AS3303/AS44038] 17.966 ms 17.929 ms 17.966 ms 8 202-0-186-195.bluewin.ch (195.186.0.202) [AS3303/AS44038] 21.432 ms 19.125 ms 19.938 ms 9 i79tix-005-ae0.bb.ip-plus.net (138.187.129.7) [AS3303] 17.386 ms 17.596 ms 21.142 ms 10 zch-b1-link.telia.net (213.248.90.237) [AS1299] 17.117 ms 17.686 ms 17.173 ms 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 13 level3-ic-130870-ash-bb1.c.telia.net (213.248.89.178) [AS1299] 114.600 ms 114.618 ms 124.009 ms 14 vlan80.csw3.Washington1.Level3.net (4.69.149.190) [AS3356] 120.899 ms 120.495 ms 120.235 ms 15 ae-72-72.ebr2.Washington1.Level3.net (4.69.134.149) [AS3356] 113.387 ms 114.457 ms ae-82-82.ebr2.Washington1.Level3.net (4.69.134.153) [AS3356] 120.064 ms 16 ae-3-3.ebr1.NewYork2.Level3.net (4.69.132.90) [AS3356] 112.147 ms 112.035 ms 112.211 ms 17 ae-1-100.ebr2.NewYork2.Level3.net (4.69.135.254) [AS3356] 116.964 ms 116.742 ms 110.879 ms 18 ae-5-5.car2.Stamford1.Level3.net (4.69.142.81) [AS3356] 116.335 ms 123.342 ms 116.644 ms 19 INTERACTIVE.car2.Stamford1.Level3.net (4.26.50.110) [AS3356] 122.280 ms 117.676 ms 116.042 ms 20 www.interactivebrokers.com (206.106.137.3) [AS11449] 118.604 ms 117.565 ms 118.602 ms 22ms
_______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
_______________________________________________ swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
- -- Nicolas STRINA
Jaguar Network Switzerland 5 route de Chene Case Postale 6298 CH - 1211 Geneva 6
More Than Your Hosting Company
Tel : +33 4 88 00 65 16 Gsm : +33 6 18 20 49 55
Std : +41 8 40 65 61 11 Fax : +33 4 88 00 65 25
URL: http://www.jaguar-network.ch/ Support 24+7 : support@jaguar-network.ch