slow speed to Shanghai Telecom

my job requires me to connect servers in Shanghai Telecom everyday, every night I suffer from heavy packets loss and high pings from my home FIOS to Shanghai servers.

come on, Verizon should be better than this, please change the routes, route it through Level3 or something other than sprintlink.

Tracing route to 218.83.155.2 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms Wireless_Broadband_Router.home [192.168.1.1]
2 5 ms 4 ms 8 ms L100.PTLDOR-VFTTP-22.verizon-gni.net [98.108.166
.1]
3 5 ms 4 ms 4 ms G14-0-1-122.PTLDOR-LCR-01.verizon-gni.net [130.8
1.138.28]
4 10 ms 9 ms 11 ms so-7-3-0-0.SEA01-BB-RTR1.verizon-gni.net [130.81
.28.160]
5 11 ms 10 ms 11 ms 0.so-7-1-0.XT1.SEA7.ALTER.NET [152.63.105.57]
6 14 ms 12 ms 11 ms 0.so-2-0-0.XT1.SEA1.ALTER.NET [152.63.104.225]
7 11 ms 12 ms 12 ms POS4-0.BR1.SEA1.ALTER.NET [152.63.105.81]
8 11 ms 13 ms 12 ms 204.255.169.118
9 20 ms 19 ms 19 ms sl-crs1-tac-0-0-5-0.sprintlink.net [144.232.8.61
]
10 43 ms 42 ms 42 ms sl-crs1-sj-0-9-0-0.sprintlink.net [144.232.20.8]

11 42 ms 41 ms 41 ms sl-st20-sj-0-0-0.sprintlink.net [144.232.18.106]

12 141 ms * 143 ms sl-china1-7-0.sprintlink.net [144.223.242.126]
13 305 ms 306 ms 305 ms 202.97.51.145
14 320 ms 324 ms 323 ms 202.97.33.101
15 * * * Request timed out.
16 324 ms 320 ms * 61.152.86.45
17 325 ms 326 ms * 124.74.210.226
18 305 ms 307 ms * 218.1.4.110
19 * * 324 ms 218.1.4.109
20 305 ms 306 ms 304 ms 218.1.4.110
21 323 ms 323 ms 323 ms 218.1.4.109
22 305 ms 305 ms 304 ms 218.1.4.110
23 * 323 ms 323 ms 218.1.4.109
24 306 ms 304 ms 305 ms 218.1.4.110
25 323 ms * * 218.1.4.109

Accepted answers

Justin46

@jackc wrote:
i've been monitoring this issue constantly since I got FIOS, two months ago, the routes from my home FIOS to Shanghai telecom always goes through Sprint, usually day time the latency is ok, but it's a nightmare at night.
I myself is a network system administrator so i do understand these kind of stuff pretty well. since i'm not a Sprint customer, the only way for me is to seek help from Verizon, hoping they can change the routes, which I'm sure they can if they want to, but since i might be the only one got affecting by this, they probably not willing to do it just for me, in that case i'll have to live with VPN. 😞

Jack,

I hope you realize that this is a primarily user-to-user forum, it is very unlikely that any of us here will be able to help. It is certainly possible that a Verizon employee might see this thread and take some action, but IMO not likely.

I suggest you go to dslreports.com and post your problem in the Verizon Direct forum there. That forum is staffed by Verizon employees and lots of people have been successful in getting their problems fixed, no guarantees of course but it might just work. Be sure to provide the trace-routes, etc. You will need to register to post, but registration is free, and nobody but you and Verizon employees can see your posts.

Good luck.

__________________________________
Justin
Verizon FiOS TV, Internet, and phone
QIP6416-P1, IMG 1.7C, Build 09.83
Keller, TX 76248

All comments

sgip2000

Based on what you posted, it looks like Sprint is to blame for your problem.

jackc

true. the link between sprint and Shanghai telecom is saturated.

so to solve the problem, either Sprint need to increase the capacity to China Telecom or Verizon need to change the routing to Shanghai telecom bypass Sprint.

It should be easier for Verizon to change the routes than making Sprint fix the problem.

Guess what routes Verizon take when the destination is Fuzhou Telecom(city not very far away from Shanghai)?

Tracing route to 59.57.15.1 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms Wireless_Broadband_Router.home [192.168.1.1]
2 4 ms 3 ms 4 ms L100.PTLDOR-VFTTP-22.verizon-gni.net [98.108.166
.1]
3 6 ms 4 ms 5 ms G14-0-1-222.PTLDOR-LCR-02.verizon-gni.net [130.8
1.138.202]
4 11 ms 10 ms 10 ms P12-0.PTLDOR-LCR-01.verizon-gni.net [130.81.27.1
72]
5 10 ms 10 ms 11 ms so-7-3-0-0.SEA01-BB-RTR1.verizon-gni.net [130.81
.28.160]
6 11 ms 11 ms 10 ms 0.so-7-1-0.XT1.SEA7.ALTER.NET [152.63.105.57]
7 11 ms 12 ms 11 ms 0.so-2-0-0.XT1.SEA1.ALTER.NET [152.63.104.225]
8 13 ms 11 ms 11 ms POS4-0.BR2.SEA1.ALTER.NET [152.63.106.9]
9 12 ms 13 ms 12 ms 204.255.169.22
10 14 ms 17 ms 18 ms ae-32-52.ebr2.Seattle1.Level3.net [4.68.105.62]

11 25 ms 17 ms 18 ms ae-1-100.ebr1.Seattle1.Level3.net [4.69.132.17]

12 30 ms 35 ms 35 ms ae-7-7.ebr2.SanJose1.Level3.net [4.69.132.49]
13 26 ms 34 ms 35 ms ae-82-82.csw3.SanJose1.Level3.net [4.69.134.218]

14 39 ms 28 ms 28 ms ae-34-89.car4.SanJose1.Level3.net [4.68.18.134]

15 28 ms 28 ms 27 ms CHINA-TELEC.car4.SanJose1.Level3.net [4.71.114.1
02]
16 198 ms 199 ms 199 ms 202.97.49.109
17 198 ms 197 ms 197 ms 202.97.60.61
18 199 ms 199 ms 199 ms 202.97.33.225
19 206 ms 207 ms 206 ms 202.97.40.98
20 209 ms 210 ms 209 ms 218.5.100.50
21 212 ms 211 ms 212 ms 218.5.100.57
22 208 ms 212 ms 210 ms 59.57.15.1

Trace complete.

much better result when going through Level3.

Beazst

Certainly I can see why the second route is more appealing.

It can be rather challenging to force Internet traffic (packets) to take a static route.

This may seem like a logical solution but consider some of the ramifications:

the routers interconnecting you with Shanghai Telecom are unable to perform load balancing based on the relative network conditions
if the path is broken or disrupted the router will not be able to automatically redirect traffic to a functional link
the risk of duplicating this issue on Level 3's network increases as a result of more traffic

Not to mention that a tracert is merely a point-in-time snapshot of network performance.

Much like a system of roads and highways, traffic levels will vary throughout the day. The latency you seem to be experiencing would have to be monitored over a period of time to determine if this is really a routing issue or a temporary problem resulting from network congestion.

Your physical location relative to the server you are accessing can also influence this. It does in fact take longer for electrical signals to travel around the world than it does to travel across town.

I realize this doesn't fix the problem, but it's generally easier to accept that "latency happens" when we understand why.

Hope this helps. Robot Happy

jackc

i've been monitoring this issue constantly since I got FIOS, two months ago, the routes from my home FIOS to Shanghai telecom always goes through Sprint, usually day time the latency is ok, but it's a nightmare at night.

I myself is a network system administrator so i do understand these kind of stuff pretty well. since i'm not a Sprint customer, the only way for me is to seek help from Verizon, hoping they can change the routes, which I'm sure they can if they want to, but since i might be the only one got affecting by this, they probably not willing to do it just for me, in that case i'll have to live with VPN. 😞

spacedebris

Verizon will have very little that they can do about this. The routing is primarily controled by the company that owns the router. and they only control the route to the point it leaves their systems. So in this case Verizon routes it through their systems and then sends it to ALTER.NET. Alter.net then controls it via their network and they decide to send it to sprintlink. Unfortunatly Sprintlink is notoriously slow. Always has been. The only thing that can be done is that Sprintlink needs to expand their bandwidth (not going to happen) or Alter.net to route through another path. (not always possible). Sometimes the link on the other end can only be via one system. Not always but sometimes. Dont know in this case. But the point of this is their may not be anything Verizon can do about this. Its possible they may have some pull with the other companies and make requests but I wouldnt hold my breath. I tried for years to get my link from Los Angeles to Washington DC changed to go Via Dallas to bypass Kansas City and Sprintlink. I played an game online with a server in Washington DC. When my route took me via KC I would hit sprintlink and get hosed. Never could get the routing changed. (of course this wasnt with Verizon but one of the competition) Now with Verizon. My route goes through Dallas and all is good. But it wasnt because Verizon did anything, its just that verizons Gateway is with another company.

jackc

it isn't single ip routing problem, the issue applies to all servers and IP ranges in Shanghai Telecom. Yep, I did extensive tests on this for the past two months.

btw, Alter is Verizon Business. So yes, Verizon definitely able to change the routes, it is just they are willing to do or not.

Hubrisnxs

So yes, Verizon definitely able to change the routes, it is just they are willing to do or not.

They aren't on an individual customer basis. They have to justify it with x amount of customers. What you are talking about doing is at a NOC level and I used to work at a NOC And they do very little with altering paths, and even more rarely do they ever statically assign path's.

They will alter path's if it's a large scale outage affecting a huge amount of customers that requires the change. When I say a huge amount of customers, these customers also have to be represented by call in's and tickets, or they have to see their alarms going off on their monitors, so most likely whatever is happening is within acceptable thresholds or what they consider acceptable thresholds.

jackc

true. that's why i said on my previous post in this case i'll just have to live with VPN.

hellojue

Hi jackc, did your issue actually get resolved? i believe i am having the same problem, one symptom on my end is extremely high packet loss when conducting skype call. we did a few controlled tests, such as connecting to the same party in China from another connection (such as timer warner's from my neighbor), switched out a few routers, etc. it all points to the problem you suggested. would appreciate it if you could share any tips. thanks so much!

spacedebris

he marked it as solved because there is nothing that people here on the board could do to help.

It was a routing issue outside Verizon. There is slim hope that Verizon would re-route the routing to avoid sprintlink. No chance of getting sprintlink to increase bandwidth.

The only thing to try for this issue was to go to dslreports and post there and hope that Verizon would re-route.

How do your tracerts look?

hellojue

thanks for the note. my traceroute from last night looks like this. i am no expert, do you see any obvious problems from this report?

VERIZON FIOS 2010.6.1-10:52pm

traceroute to 218.83.155.2 (218.83.155.2), 64 hops max, 52 byte packets

1 wireless_broadband_router (192.168.1.1) 1.010 ms 0.483 ms 0.419 ms

2 74.108.111.1 (74.108.111.1) 2.206 ms 2.172 ms 2.047 ms

3 g3-0-6-1308.nycmny-lcr-13.verizon-gni.net (130.81.177.80) 4.944 ms 4.464 ms 4.418 ms

4 so-6-3-0-0.bb-rtr1.sea01.verizon-gni.net (130.81.28.52) 5.288 ms 5.287 ms 5.323 ms

5 0.so-0-0-0.xl3.nyc4.alter.net (152.63.1.41) 6.340 ms 6.168 ms 6.355 ms

6 0.xe-5-0-0.br3.nyc4.alter.net (152.63.16.181) 5.409 ms

0.xe-8-1-0.br3.nyc4.alter.net (152.63.17.53) 6.427 ms

0.xe-5-0-0.br3.nyc4.alter.net (152.63.16.181) 5.242 ms

7 sl-crs2-nyc-0-1-2-0.sprintlink.net (144.232.18.237) 7.627 ms 7.773 ms

204.255.168.118 (204.255.168.118) 8.418 ms

8 sl-crs2-chi-0-5-0-0.sprintlink.net (144.232.20.162) 43.092 ms

sl-crs2-pen-0-8-3-0.sprintlink.net (144.232.20.97) 15.427 ms

144.232.18.208 (144.232.18.208) 18.380 ms

9 sl-crs1-stk-0-4-0-2.sprintlink.net (144.232.8.169) 104.106 ms 113.831 ms 114.943 ms

10 sl-crs2-sj-0-14-0-0.sprintlink.net (144.232.24.34) 94.873 ms

sl-crs1-sj-0-2-2-0.sprintlink.net (144.232.20.113) 138.021 ms 117.587 ms

11 sl-st20-sj-0-0-0.sprintlink.net (144.232.18.106) 97.947 ms 93.715 ms 91.491 ms

12 sl-china1-7-0.sprintlink.net (144.223.242.126) 313.928 ms 317.458 ms 311.827 ms

13 202.97.50.77 (202.97.50.77) 344.874 ms 348.579 ms 340.814 ms

14 202.97.50.109 (202.97.50.109) 455.845 ms 458.797 ms *

15 202.97.33.253 (202.97.33.253) 464.717 ms 458.871 ms 463.128 ms

16 202.97.33.89 (202.97.33.89) 448.587 ms 449.789 ms 457.534 ms

17 * 61.152.86.173 (61.152.86.173) 464.598 ms 467.808 ms

18 61.152.81.22 (61.152.81.22) 453.682 ms 445.625 ms 509.638 ms

19 124.74.254.42 (124.74.254.42) 454.527 ms 458.911 ms 452.928 ms

20 124.74.254.41 (124.74.254.41) 443.591 ms * 438.447 ms

spacedebris

from the looks of it, you're having issues with sprintlink too. Now of course there may be more going on than actually shows on a tracert but at first blush it looks like the problem starts at about hop 9, although hops 9, 10, and 11 are a little slow they dont look too bad. But Hop 12...Thats where it really starts. The problem is that first its sprintlink, thats always bad news. But in addition, its sprintlink in China. Now having said that and seeing a relatively slow connection starting at hop 12, it does look fairly stable. No wild fluctuations, no spikes, just slow responses for what we are used to here. That could be due to the distance involved. It is also likely that the Chinese infrastructure is not as robust as ours (LOL). The fact that it happens more at night (other poster) is likely due to that it may be night for us, but its daytime for them, so their network gets hammered at that time. You could try going over to dsl reports (see previous post for link) and see if Verizon can re-route. But likely there is nothing that can be done as for the most part the network looks good until you get the china.

garukun

I'm seeing the same problem from PA. I have been using VPN as work arounds right now since Verizon is incapable of coming up with a solution after numerous calls with their tech support. This is definitely outrageous and frustrating.