I have a trouble ticket that has been sitting for over 6 hours now and the chat will not work for me?

I have a customer that can't reach my server.

Here are the traces to and from the server

To Server from customrt

09/10/02 09:42:26 Fast traceroute sitecrafter.com
Trace sitecrafter.com (216.12.213.10) ...
1 172.23.4.33 718ms 696ms 768ms TTL: 0 (No rDNS)
2 172.23.4.33 799ms 708ms 689ms TTL: 0 (No rDNS)
3 172.24.20.66 791ms 704ms 789ms TTL: 0 (No rDNS)
4 63.215.128.129 766ms 777ms 800ms TTL: 0 (pos5-0.hsipaccess1.Washington1.Level3.net ok)
5 64.159.18.37 742ms 724ms 747ms TTL: 0 (gigabitethernet8-0.core1.Washington1.Level3.net ok)
6 209.244.219.138 754ms 720ms 734ms TTL: 0 (uswash2-c75c.savvis.net fraudulent rDNS)
7 64.242.22.157 825ms 793ms 830ms TTL: 0 (at-0-2-0811.usdlls2-j20c.savvis.net ok)
8 64.243.79.14 812ms 865ms 742ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
9 64.243.79.14 740ms * 894ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
10 64.243.79.14 769ms * 884ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
11 64.243.79.14 763ms * 759ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
12 64.243.79.14 807ms * 782ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
13 64.243.79.14 839ms * 909ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
14 64.243.79.14 739ms * 758ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
15 64.243.79.14 * * 766ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
16 No Response * * *
17 No Response * * *
18 No Response * * *
19 64.243.79.14 1701ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
20 64.243.79.14 1629ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
21 64.243.79.14 1341ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
22 64.243.79.14 1149ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
23 64.243.79.14 984ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
24 64.243.79.14 857ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
25 64.243.79.14 1052ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
26 64.243.79.14 827ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
27 No Response * * *
28 No Response * * *
29 No Response * * *

From Server to customer

[root /]# traceroute dpc6682009026.direcpc.com
traceroute to dpc6682009026.direcpc.com (66.82.9.26), 30 hops max, 38 byte packets
1 216.12.213.1 (216.12.213.1) 0.464 ms 0.366 ms 0.320 ms
2 207.218.223.5 (207.218.223.5) 0.414 ms 0.369 ms 0.322 ms
3 ge-1-1-0.r02.hstntx01.us.bb.verio.net (129.250.10.65) 0.802 ms 0.887 ms 0.823 ms
4 p16-2-0-0.r00.hstntx01.us.bb.verio.net (129.250.3.46) 0.922 ms 0.903 ms 0.939 ms
5 p16-1-1-1.r21.dllstx01.us.bb.verio.net (129.250.5.4) 5.715 ms 5.705 ms 5.621 ms
6 p16-2-0-0.r02.dllstx01.us.bb.verio.net (129.250.3.31) 5.743 ms 5.803 ms p16-2-0-0.r01.dllstx01.us.bb.verio.net (129.250.3.29) 5.702 ms
7 p4-2-0.r00.dllstx01.us.bb.verio.net (129.250.3.73) 5.761 ms 5.656 ms 5.695 ms
8 pos3-3.core2.Dallas1.Level3.net (209.245.240.177) 6.209 ms 6.170 ms 5.960 ms
9 so-4-1-0.mp2.Dallas1.Level3.net (209.247.10.109) 6.326 ms 6.468 ms 6.495 ms
10 so-3-0-0.mp2.Washington1.Level3.net (64.159.0.230) 48.141 ms 47.561 ms 47.526 ms
11 gige8-1.hsipaccess1.Washington1.Level3.net (64.159.18.103) 47.439 ms 47.928 ms 47.650 ms
12 unknown.Level3.net (63.215.128.130) 49.151 ms 48.777 ms 48.730 ms
13 172.24.20.65 (172.24.20.65) 49.370 ms 49.130 ms 52.335 ms
14 172.23.128.6 (172.23.128.6) 51.142 ms 49.446 ms 50.613 ms
15 192.168.11.5 (192.168.11.5) 49.319 ms !X * *
16 192.168.11.5 (192.168.11.5) 64.299 ms !X * *
17 * * 192.168.11.5 (192.168.11.5) 49.568 ms !X
18 * 192.168.11.5 (192.168.11.5) 50.153 ms !X *
19 192.168.11.5 (192.168.11.5) 75.340 ms !X * *
20 192.168.11.5 (192.168.11.5) 55.471 ms !X * 49.162 ms !X

Looks like a problem between upstreams. In that case, it's not RS's fault or task to fix it.
Just be glad your server's not down for EVERYONE!

Out of curiosity, has RS replied to the ticket yet?

I am having the same issue with customers inbound through the Savvis link.

Tracing route to livingstoneministries.com
[216.12.218.22]
over a maximum of 30 hops:

1 1559 ms 1370 ms 1309 ms 172.23.4.33
2 1499 ms 1367 ms 758 ms 172.23.4.33
3 679 ms 747 ms * 172.24.20.66
4 739 ms 750 ms 689 ms
pos5-0.hsipaccess1.Washington1.Level3.net [63.21
5.128.129]
5 807 ms 744 ms 753 ms
gigabitethernet8-0.core1.Washington1.Level3.net
[64.159.18.37]
6 680 ms 745 ms 755 ms
uswash2-c75c.savvis.net [209.244.219.138]
7 751 ms * 1688 ms
at-0-2-0811.usdlls2-j20c.savvis.net [64.242.22.1
57]
8 807 ms 814 ms 809 ms
everyoneint-1.s2333b.usdlls2-j20c.savvis.net [64
.243.79.14]
9 everyoneint-1.s2333b.usdlls2-j20c.savvis.net
[64.243.79.14] reports: Desti
nation net unreachable.

Trace complete.

Any ideas?
Trouble ticket submitted.

Not blaming you, but please try to understand the purpose of a traceroute :

1 1559 ms 1370 ms 1309 ms 172.23.4.33

This means that your first hop causes a serious delay. This first hop is the link between the PC you're running this traceroute from and the first router at your ISP. So RackShack is not involved at all. You need to check your own PC or ISP, or anything in between.

Carl

I agree that there is a definite lag between the source PC and the first hop, but that is not causing the 'Destination Unreachable' reply from this IP : 64.243.79.14 (which appears to be Savvis equip just outside Rackshack's network).

Yes, it can cause timeouts for hops at a certain distance from the failing point. For example : if the saturation (or whatever) increases when you trace closer to the destination point, you'll get timeouts. I'm convinced that the problem is on your side, not RS - things like these happen all the time, and result in timeouts and such, but you'll need to resolve your local lag first.

Carl

NOPE!!!!

I submitted the ticket at 9:00 am, at 5:00pm I called the data center because the ticket had not even been looked at yet, at that point the guy on the phone sent it to networking, and 19 hours later network has not even looked into it.

I sent a email to Savvis.

Tell me this, why would a trace look like this then?

8 64.243.79.14 812ms 865ms 742ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
9 64.243.79.14 740ms * 894ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
10 64.243.79.14 769ms * 884ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
11 64.243.79.14 763ms * 759ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
12 64.243.79.14 807ms * 782ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
13 64.243.79.14 839ms * 909ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
14 64.243.79.14 739ms * 758ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
15 64.243.79.14 * * 766ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
16 No Response * * *
17 No Response * * *
18 No Response * * *
19 64.243.79.14 1701ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
20 64.243.79.14 1629ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
21 64.243.79.14 1341ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
22 64.243.79.14 1149ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
23 64.243.79.14 984ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
24 64.243.79.14 857ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
25 64.243.79.14 1052ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
26 64.243.79.14 827ms * * TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)
27 No Response * * *
28 No Response * * *
29 No Response * * *

The problems you mentioned are on your end as well :
1 172.23.4.33 718ms 696ms 768ms TTL: 0 (No rDNS)

In your first traceroute, FROM your local PC, you start with a serious lag at the first hop, causing problems at remote hops.
In the second traceroute, TO your local PC, things are going really well in the beginning, but as soon as the packets reach your ISP, things start to go wrong (no problems before the 15th hop).

These are clearly things beyond RackShack's area, so please don't expect them to resolve it.

Carl

----- Original Message -----
From: "NCC"
To: "'L. James Prevo'"; "NCC"
Sent: Wednesday, September 11, 2002 12:39 PM
Subject: RE: A bad ip?


James,

The ip in question is everyone's internet. This is our client but we do not
manage thier circuits we only provide a link up with them. I would suggest
contacting Everyone's Internet and if you can't get anywhere with them maybe
we can be of assistance.

Thanks James.

SAVVIS NCC
888-638-6771
ncc@savvis.net

Tell me this as well.

My customer has success this morning, then about a hour later starts having the same problems again.

His latency was the same.

09/11/02 08:14:54 Fast traceroute sitecrafter.com

Trace sitecrafter.com (216.12.213.10) ...

1 172.23.4.33 784ms 697ms 685ms TTL: 0 (No rDNS)

2 172.23.4.33 656ms 694ms 713ms TTL: 0 (No rDNS)

3 172.24.20.66 730ms 689ms 721ms TTL: 0 (No rDNS)

4 63.215.128.129 726ms 744ms 718ms TTL: 0 (pos5-0.hsipaccess1.Washington1.Level3.net ok)

5 64.159.18.101 722ms 756ms 702ms TTL: 0 (gigabitethernet8-1.core1.Washington1.Level3.net ok)

6 209.244.219.138 744ms 656ms 679ms TTL: 0 (uswash2-c75c.savvis.net fraudulent rDNS)

7 64.242.22.157 752ms 776ms 759ms TTL: 0 (at-0-2-0811.usdlls2-j20c.savvis.net ok)

8 64.243.79.14 765ms 732ms 768ms TTL: 0 (everyoneint-1.s2333b.usdlls2-j20c.savvis.net ok)

9 207.218.223.36 777ms 823ms 777ms TTL: 0 (No rDNS)

10 216.12.213.10 732ms 769ms 792ms TTL:242 (sitecrafter.com ok)

I think the problem could be bewtween

64.243.79.14 and 207.218.223.36

I've got one as well traceroute dies at:

everyoneint-1.s2333b.usd11s2-j20c.savvis.net [64.243.79.14]: Destination net unreachable.

Looks like the savvis router in question (probably the one on the other end of the ev1 connection, judging from the name) doesn't know how to get to parts of the ev1 network, even though isp's 'futher up' are sending incoming packets in it's direction.

Frustrating.

ljprevo -
In every instance the extreme latency appears to be very close to you. The loss is probably caused by exceeding the timeout of your traceroute utility.

shannon -
Please post or PM the traceroute and include the source IP.

Randy Williams
CTO, Rackshack.net

Yes, but this customer is accessing my servers in Florida just fine, and everywhere else he goes except Rackshack's network.

Wait a min here.

If my customer is coming in on Savvis, why is the trace going back to him on Verio?

All he gave me was the proxy, I thought his proxy might be what is causing he claims it is the same with the proxy on or off.

That's because of BGP4 routing. It takes the fastest inbound and outbound path, which may vary depending on which peering points your packets need to cross in both directions.
Like Randy said, I would first check if the problems are not on your (or your customer's) side, as your traces point in this direction.

Carl

You know, I am not a genius when it come to this. This customer is very important to me.

His ISP is telling him it is a problem in the Everyone's Internet Network

What the heck am I to do about this?

Are they trying to pass the buck?

It confuses the hell out of the customer when they can access
every other site on the net, but none at RS, all 4 of my servers this customer can't access.

ljprevo -

A few traces to your server seem ok:

Traceroute from VGER.KERNEL.ORG server at RedHat North Carolina/USA site
Result for 216.12.213.10; modeset: {AS-Query , ICMP-Query , SOA-Owner-Query }:
traceroute.exe to 216.12.213.10 (216.12.213.10), 30 hops max, 38 byte packets
1 209.116.70.66 (209.116.70.66) [AS13756/AS19290] dnsadmin@inflow.net 0.316 ms 0.257 ms 0.214 ms
2 rdu01-rr01-vl11.rdu01.inflow.net (64.244.31.35) [AS13756/AS19290] dnsadmin@inflow.net 0.342 ms 0.318 ms 0.248 ms
3 64.242.135.45 (64.242.135.45) [AS6347] dns@savvis.net 10.294 ms 10.101 ms 15.333 ms
4 at-1-2-812.usdlls2-01.j20c.savvis.net (64.240.34.30) [AS6347] dns@savvis.net 30.178 ms 30.429 ms 29.983 ms
5 everyoneint-1.s2333b.usdlls2-j20c.savvis.net (64.243.79.14) [AS6347] dns@savvis.net 36.320 ms 36.260 ms 36.136 ms
6 207.218.223.36 (207.218.223.36) [AS13749/AS5650] admin@ev1.net 39.158 ms 38.939 ms 38.943 ms
7 ns1.prevo.net (216.12.213.10) [AS13749/AS5650] admin@ev1.net 39.602 ms 38.640 ms 39.028 ms
_________________________________________________

route-views.oregon-ix.net>trace 216.12.213.10

Type escape sequence to abort.
Tracing the route to ns1.prevo.net (216.12.213.10)

1 nero-gw.oregon-ix.net (198.32.162.2) 200 msec 200 msec 208 msec
2 verio-gw.oregon-ix.net (198.32.162.6) 0 msec 0 msec 0 msec
3 d3-0-1-0.r01.ptldor01.us.ra.verio.net (129.250.55.113) [AS 2914] 4 msec 4 ms
ec 8 msec
4 ge-1-0-0.r02.ptldor01.us.bb.verio.net (129.250.31.222) [AS 2914] 4 msec 4 ms
ec 4 msec
5 p4-1-2-0.r00.snjsca04.us.bb.verio.net (129.250.4.31) [AS 2914] 20 msec 20 ms
ec 20 msec
6 p16-0-1-0.r21.snjsca04.us.bb.verio.net (129.250.5.137) [AS 2914] 16 msec 20
msec 20 msec
7 p16-0-0-0.r02.lsanca01.us.bb.verio.net (129.250.2.186) [AS 2914] 24 msec 24
msec 28 msec
8 p4-0-3-0.r01.sndgca01.us.bb.verio.net (129.250.3.210) [AS 2914] 32 msec 32 m
sec 28 msec
9 p4-2-0.r00.sndgca01.us.bb.verio.net (129.250.3.205) [AS 2914] 32 msec 28 mse
c 32 msec
10 p4-0-0-0.r02.hstntx01.us.bb.verio.net (129.250.3.185) [AS 2914] 60 msec 60 m
sec 60 msec
11 p16-2-0-0.r00.hstntx01.us.bb.verio.net (129.250.3.46) [AS 2914] 60 msec 60 m
sec 60 msec
12 ge-1.ev1.hstntx01.us.bb.verio.net (129.250.10.70) [AS 2914] 60 msec 60 msec
60 msec
13 207.218.223.36 [AS 13749] 60 msec 64 msec 60 msec
14 ns1.prevo.net (216.12.213.10) [AS 13749] 60 msec 64 msec 60 msec
_________________________________________________

route-server.east>trace 216.12.213.10

Type escape sequence to abort.
Tracing the route to ns1.prevo.net (216.12.213.10)

1 atm7-2-720.core1-tor.bb.attcanada.ca (216.191.65.117) 0 msec 4 msec 0 msec
2 pos5-0.gwy1-chi.bb.attcanada.ca (216.191.65.70) 12 msec 12 msec 12 msec
3 pa2-atm0-1-aads-igr01.chi.twtelecom.net (206.220.243.116) [AS 7018] 12 msec
16 msec 12 msec
4 core-02-ge-0-3-0-0.chcg.twtelecom.net (168.215.53.193) [AS 4323] 12 msec 12
msec 12 msec
5 core-01-so-2-3-0-0.dlfw.twtelecom.net (168.215.53.46) [AS 4323] 32 msec 36 m
sec 32 msec
6 dist-01-so-0-0-0-0.ausu.twtelecom.net (168.215.53.94) [AS 4323] 40 msec 40 m
sec 40 msec
7 dist-02-ge-2-3-0-0.ausu.twtelecom.net (168.215.53.162) [AS 4323] 36 msec 40
msec 44 msec
8 dist-01-so-0-0-0-0.snan.twtelecom.net (168.215.53.105) [AS 4323] 40 msec 40
msec 40 msec
9 dist-02-ge-2-3-0-0.snan.twtelecom.net (168.215.53.98) [AS 4323] 40 msec 40 m
sec 40 msec
10 dist-02-so-0-0-0-0.hsto.twtelecom.net (168.215.53.110) [AS 4323] 40 msec 44
msec 40 msec
11 66.162.210.254 [AS 4323] 44 msec 40 msec 44 msec
12 66.162.210.2 [AS 4323] 40 msec 40 msec 44 msec
13 207.218.223.36 [AS 13749] 40 msec 40 msec 44 msec
14 ns1.prevo.net (216.12.213.10) [AS 13749] 40 msec 44 msec 40 msec
_________________________________________________



Good question. Normally the outbound traffic on these two smaller links (Savvis and ELI) is reserved for dialup customers, as Rackshack traffic (mostly outbound) could easily overrun either of them at any time. (Of course they are there in the event I really need them.)

This, in itself, does not fundamentally cause any problems. And mango is right. BGP does dictate the outbound choice from the remaining providers, which could cause the same symptom.

Randy Williams
CTO, Rackshack.net

a) can he ping it at all?



b) can the isp provide a traceroute since it is in question as well?

I asked the customer for info how to contact his ISP.

Have requested full tracert log from client in question, will PM once I have it.

One thing to keep in mind, I believe someone mentioned direcpc before, and I know this client is with direcway (A directpc type situation), so the latency on the first hop IS going to be high. But that should not cause them to be able to ftp/access everywhere else except RS servers (as is the case here, I had the client in question try a dozen other locations, no problem, but coming into the RS datacenter it always died on the same hop, citing Network Not Reachable)...

Shannon, my customer is using Direcway as well having the same problems!!!

We onto something here? Maybe we can put our heads together and figure this out.

Same here...Directpc - which I believe is the same.

Your having problems as well?

Thank you for recommending this thread. I have posted at several boards, the closest i have come is www.copperhead.cc which is a Direcway forum. It seems that I am having the exact same problem. I have three dedicated server, only one on rackshack. I can access the other 2 24/7 rackshack only maybe if i am lucky 1 hour a day. 10pm, 3am. nothing good. This is really starting to p**s me off. If i dial up with the same pc i do not have any problems, i do not change any configurations except the route from direcway to my dialup isp. I have contacted direcways tech support and they say the problem is not on thier end, rackshack says the problem is not on thier end. Well it has to be on someones end. I even went so far as to format my harddrive, reload xp from scratch, installed just the direcway application and cute ftp no mods, no other software and had the EXACT same problem!!!! Help.,.. you know how hard it is to admin a server only being able to access it for less than an hour a day??

Just fyi I am on Direcway 2way Satmax 5 freq 1110.


Thanks
I can be contacted AIM: indyitboy Yhoo: Tellall.rm
I will be more than willing to answer any questions about the configuration, setup, and operation of direcway. I just need this stupid POS to work.. Thank you for reading my ramble..

JD

Forgot to add, and it wouldnt let me edit.. BTW I am using direcway now. I have the same problem trying to check email, ftp, ssh. I get the same timeouts on ip 64.243.79.14

Can you DirecWay / DirecPC users please post some traceroutes.

This doesn't make you think it might be a problem on their end? Just the fact alone that the only folks having problems are all connecting via Direc[way|pc] would lead me to believe it is a problem on their end.

-N

Tracing route to www.ahdonline.com [216.40.250.28]

over a maximum of 30 hops:



1 * * * Request timed out.

2 1773 ms 755 ms 743 ms 172.23.4.17

3 801 ms 811 ms 751 ms 172.24.20.66

4 920 ms 831 ms 1184 ms pos5-0.hsipaccess1.Washington1.Level3.net [63.215.128.129]

5 746 ms 811 ms 812 ms gigabitethernet8-2.core1.Washington1.Level3.net [64.159.18.165]

6 873 ms 811 ms 1124 ms uswash2-c75c.savvis.net [209.244.219.138]

7 809 ms 936 ms 987 ms at-0-2-0811.usdlls2-j20c.savvis.net [64.242.22.157]

8 985 ms 1060 ms 883 ms everyoneint-1.s2333b.usdlls2-j20c.savvis.net [64.243.79.14]

9 everyoneint-1.s2333b.usdlls2-j20c.savvis.net [64.243.79.14] reports: Destination net unreachable.



Trace complete.

Ok, then why can my customer connect to the same exact server, set up the same way at Dialtone?

No problems.

By the same token, every looking glass I tried worked to your servers.... Ahdonline's server does not respond to ICMP, but it is up nonetheless.

The 172.23.x.x numbers are un-routable, so I traced from 207.218.223.34 to the first routable number. We are absolutely solid to: 63.215.128.129 (see below)

So it appears that something may be specific to RS, but I haven't seen anything unusual other than the extremely high latency you experience long before you reach our routers...

How does DirectPC explain this latency? (I'm guessing that this latency is unusual.)

Randy Williams
CTO, Rackshack.net


telnet@ivhou-ni-0#trace 63.215.128.129 num
Type Control-c to abort
Tracing the route to IP node 63.215.128.129 from 1 to 30 hops

1 <1 ms <1 ms <1 ms 207.218.223.4
2 <1 ms <1 ms <1 ms 64.200.162.1
3 5 ms 5 ms 5 ms 64.200.111.177
4 28 ms 28 ms 28 ms 64.200.240.25
5 28 ms 28 ms 28 ms 64.200.103.118
6 28 ms 28 ms 28 ms 209.0.227.73
7 31 ms 31 ms 31 ms 209.244.8.13
8 50 ms 50 ms 50 ms 64.159.0.229
9 50 ms 50 ms 50 ms 63.215.128.129

telnet@ivhou-ni-0#trace 63.215.128.129 num
Type Control-c to abort
Tracing the route to IP node 63.215.128.129 from 1 to 30 hops

1 <1 ms <1 ms <1 ms 207.218.223.4
2 <1 ms <1 ms <1 ms 64.200.162.1
3 5 ms 5 ms 5 ms 64.200.111.177
4 28 ms 28 ms 28 ms 64.200.240.25
5 28 ms 28 ms 28 ms 64.200.103.118
6 28 ms 28 ms 28 ms 209.0.227.73
7 31 ms 31 ms 31 ms 209.244.8.13
8 50 ms 50 ms 50 ms 64.159.0.229
9 50 ms 50 ms 50 ms 63.215.128.129

telnet@ivhou-ni-0#trace 63.215.128.129 num
Type Control-c to abort
Tracing the route to IP node 63.215.128.129 from 1 to 30 hops

1 <1 ms <1 ms <1 ms 207.218.223.4
2 <1 ms <1 ms <1 ms 64.200.162.1
3 5 ms 5 ms 5 ms 64.200.111.177
4 28 ms 28 ms 28 ms 64.200.240.25
5 28 ms 28 ms 28 ms 64.200.103.118
6 28 ms 28 ms 28 ms 209.0.227.73
7 31 ms 32 ms 31 ms 209.244.8.13
8 50 ms 50 ms 50 ms 64.159.0.229
9 50 ms 50 ms 50 ms 63.215.128.129

telnet@ivhou-ni-0#trace 63.215.128.129 num
Type Control-c to abort
Tracing the route to IP node 63.215.128.129 from 1 to 30 hops

1 <1 ms <1 ms <1 ms 207.218.223.4
2 <1 ms <1 ms <1 ms 64.200.162.1
3 5 ms 5 ms 5 ms 64.200.111.177
4 28 ms 28 ms 28 ms 64.200.240.25
5 28 ms 28 ms 28 ms 64.200.103.118
6 28 ms 28 ms 28 ms 209.0.227.73
7 31 ms 31 ms 31 ms 209.244.8.13
8 50 ms 50 ms 50 ms 64.159.0.229
9 50 ms 50 ms 50 ms 63.215.128.129

telnet@ivhou-ni-0#trace 63.215.128.129 num
Type Control-c to abort
Tracing the route to IP node 63.215.128.129 from 1 to 30 hops

1 <1 ms <1 ms <1 ms 207.218.223.4
2 <1 ms <1 ms <1 ms 64.200.162.1
3 5 ms 5 ms 5 ms 64.200.111.177
4 28 ms 28 ms 28 ms 64.200.240.25
5 28 ms 28 ms 28 ms 64.200.103.118
6 28 ms 28 ms 28 ms 209.0.227.73
7 32 ms 32 ms 32 ms 209.244.8.13
8 50 ms 50 ms 50 ms 64.159.0.229
9 50 ms 50 ms 50 ms 63.215.128.129

telnet@ivhou-ni-0#trace 63.215.128.129 num
Type Control-c to abort
Tracing the route to IP node 63.215.128.129 from 1 to 30 hops

1 <1 ms <1 ms <1 ms 207.218.223.4
2 <1 ms <1 ms <1 ms 64.200.162.1
3 5 ms 5 ms 5 ms 64.200.111.177
4 28 ms 28 ms 28 ms 64.200.240.25
5 28 ms 28 ms 28 ms 64.200.103.118
6 28 ms 28 ms 28 ms 209.0.227.73
7 31 ms 31 ms 32 ms 209.244.8.13
8 50 ms 50 ms 50 ms 64.159.0.229
9 50 ms 50 ms 50 ms 63.215.128.129

telnet@ivhou-ni-0#trace 63.215.128.129 num
Type Control-c to abort
Tracing the route to IP node 63.215.128.129 from 1 to 30 hops

1 <1 ms <1 ms <1 ms 207.218.223.4
2 <1 ms <1 ms <1 ms 64.200.162.1
3 5 ms 5 ms 5 ms 64.200.111.177
4 28 ms 28 ms 28 ms 64.200.240.25
5 28 ms 28 ms 28 ms 64.200.103.118
6 28 ms 28 ms 28 ms 209.0.227.73
7 31 ms 31 ms 31 ms 209.244.8.13
8 50 ms 50 ms 50 ms 64.159.0.229
9 50 ms 50 ms 50 ms 63.215.128.129

latency is a big issue with the direcway srs (2way) Here is the post from hughs website..

---
DirecPC uses geo-synchronous satellites, which are above the earth at around 22,300 miles. When you request a web page or anything else on the internet, your request goes out on your modem to Hughes Networks NOC (Network Operations Center). Then the NOC actually fetches the data, sends it up to the satellite, it comes down to you, and you receive the data you want. It's seamless, and totally transparent to the user.

Of course, there is lag present which is inherent in satellite communications. Even at the speed of light (3x108 meters/sec), it takes around 0.23923 seconds, or 240ms for data to go up and bounce back down to you. For this reason, DirecPC may not be the best choice if you are a hardcore gamer.

If you add on the lag in modems, and include the internet, most ping times will be anywhere from 450 - 600ms. You may experience longer ping times, but many things can cause that.

---

Therefore we cannot do online gaming, rarely VPN, pcanywhere.

This is likely one of the best speeds achieved by sat just for your info: 11:30 PM : 2,493kbs DOWNLOAD (16043ms) / 41kbs UPLOAD.

I think this issue is going to die a quick and painful death. I was very close to getting a DirecWay system for the motor home so when I go traveling I can "check in"

NO way now, hotel with a dialup will be better than this.

I spoke with a rep a DirectWay and he admitted that the problem is on their end. He explained that the latency problems are due to the customer having to reach the Satellite to the datacenter, get the data back to the center, back up to the satellite and back to the customer.

He even admitted they are getting flooded with calls about these issues, esp when thier customer have to "connect to a server" such as FTP. When they request a HTTP doc it gets it and sends it, no "real" connection is needed.

In their terms they DO NOT support FTP

He told me if customers can connect to outside FTP and POP3 servers then they are lucky.

He even told me that bandwidth limitation is why customers can sometime connect and sometimes can't normally during low peak times.

I was hot, I told him DirectWay needs to address this publically and quit "blamming the other end!"

I wish you could get Mr. Marsh to get ahold of them.

The rep told me that it also depends how far the server is from Direcway's datacenter, if there is latency issues from one data center to DirecWay's center as well, forget about it shooting up to the satellite and back to the customer.

Oh well I tried, can someone here back this up, I am sending my customer here to read this thread.

Ok - I have a feeling I know what might be wrong.

Use the following link and tell me the IP that you use when you communicate: http://netview.cc.iastate.edu/cgi-bin/trace

Apparently it is not the first routable number that appears in the traces.

(just read above post - get me IP number anyway. Let me check one last thing.)

Randy Williams,CTO

first here are the result after clicking on the link:

Traceroute from netview.ait.iastate.edu to 64.157.38.188.
1 b06sr1-6 (129.186.6.251) 1 ms 1 ms 2 ms
2 b11sr1-lan255-8.tele.iastate.edu (129.186.255.10) 0 ms 1 ms 0 ms
3 b31gb1-lan254-128.tele.iastate.edu (129.186.254.131) 1 ms 1 ms 0 ms
4 b31br4.gw.iastate.edu (192.245.179.130) 1 ms 1 ms 5 ms
5 secar2.icn.state.ia.us (205.221.255.5) 2 ms 2 ms 2 ms
6 ICN-ISP1.icn.state.ia.us (207.28.254.1) 2 ms 2 ms 2 ms
7 p3-1.chcgil2-cr1.bbnplanet.net (4.24.202.13) 29 ms 30 ms 30 ms
8 so-2-3-0.chcgil2-br1.bbnplanet.net (4.24.7.133) 32 ms 29 ms 32 ms
9 so-7-0-0.chcgil2-br2.bbnplanet.net (4.24.5.218) 31 ms 29 ms 31 ms
10 p1-0.chcgil2-cr10.bbnplanet.net (4.24.9.50) 31 ms 29 ms 30 ms
11 216.140.14.141 (216.140.14.141) 31 ms 30 ms 30 ms
12 216.140.14.97 (216.140.14.97) 33 ms 34 ms 34 ms
13 so-2-0-0.c1.wash.broadwing.net (216.140.16.22) 55 ms 56 ms 55 ms
14 p0-0-0.a1.wash.broadwing.net (216.140.8.13) 55 ms 54 ms 55 ms
15 p8-0-0.e0.wash.broadwing.net (216.140.8.34) 55 ms 59 ms 55 ms
16 216.140.217.254 (216.140.217.254) 59 ms 58 ms 57 ms
17 192.168.9.253 (192.168.9.253) 87 ms * 78 ms

part 2.. more to come..

18 172.23.128.5 (172.23.128.5) 80 ms 67 ms 70 ms
19 172.23.4.22 (172.23.4.22) 74 ms * 78 ms
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 *

Sorry. I guess I was not clear.

Someone on DirectPC experiencing the problem first hand - use the following link and give me the IP number to which the site traces (or the whole trace).

http://netview.cc.iastate.edu/cgi-bin/trace

Randy Williams
CTO, Rackshack.net

He is on DirecWay

That would me myself. Here are the total results as on direcway

Traceroute and ping from Iowa State
The following is a traceroute and ping to your machine. Enter a different address if you wish.
Address:


--------------------------------------------------------------------------------
Traceroute from netview.ait.iastate.edu to 64.157.38.188.
1 b06sr1-6 (129.186.6.251) 1 ms 1 ms 2 ms
2 b11sr1-lan255-8.tele.iastate.edu (129.186.255.10) 0 ms 1 ms 0 ms
3 b31gb1-lan254-128.tele.iastate.edu (129.186.254.131) 1 ms 1 ms 0 ms
4 b31br4.gw.iastate.edu (192.245.179.130) 1 ms 1 ms 5 ms
5 secar2.icn.state.ia.us (205.221.255.5) 2 ms 2 ms 2 ms
6 ICN-ISP1.icn.state.ia.us (207.28.254.1) 2 ms 2 ms 2 ms
7 p3-1.chcgil2-cr1.bbnplanet.net (4.24.202.13) 29 ms 30 ms 30 ms
8 so-2-3-0.chcgil2-br1.bbnplanet.net (4.24.7.133) 32 ms 29 ms 32 ms
9 so-7-0-0.chcgil2-br2.bbnplanet.net (4.24.5.218) 31 ms 29 ms 31 ms
10 p1-0.chcgil2-cr10.bbnplanet.net (4.24.9.50) 31 ms 29 ms 30 ms
11 216.140.14.141 (216.140.14.141) 31 ms 30 ms 30 ms
12 216.140.14.97 (216.140.14.97) 33 ms 34 ms 34 ms
13 so-2-0-0.c1.wash.broadwing.net (216.140.16.22) 55 ms 56 ms 55 ms
14 p0-0-0.a1.wash.broadwing.net (216.140.8.13) 55 ms 54 ms 55 ms
15 p8-0-0.e0.wash.broadwing.net (216.140.8.34) 55 ms 59 ms 55 ms
16 216.140.217.254 (216.140.217.254) 59 ms 58 ms 57 ms
17 192.168.9.253 (192.168.9.253) 87 ms * 78 ms
18 172.23.128.5 (172.23.128.5) 80 ms 67 ms 70 ms
19 172.23.4.22 (172.23.4.22) 74 ms * 78 ms
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *

Ahdonline

He needs the line before the first hop

Like this

Traceroute from netview.ait.iastate.edu to 68.62.48.32.

1 b06sr1-6 (129.186.6.251) 1 ms 1 ms 1 ms
2 b11sr1-lan255-8.tele.iastate.edu (129.186.255.10) 0 ms 1 ms 0 ms
3 b31gb1-lan254-128.tele.iastate.edu (129.186.254.131) 1 ms 0 ms 1 ms
4 b31br4.gw.iastate.edu (192.245.179.130) 4 ms 2 ms 1 ms
etc
etc


he needs the line
Traceroute from netview.ait.iastate.edu to XX.XX.XX.XX

Guess I jumped the gun before trace - part II...

I don't see anything wrong with that IP: 64.157.38.188

(64.157.38.99/32 was blocked by the IDS five days ago...)

Trace from 207.218.223.34 to that number:
1 <1 ms <1 ms <1 ms 207.218.223.3
2 <1 ms <1 ms <1 ms 129.250.10.69
3 5 ms 5 ms 5 ms 129.250.5.4
4 5 ms 5 ms 5 ms 129.250.3.29
5 5 ms 5 ms 5 ms 209.245.240.189
6 5 ms 5 ms 5 ms 209.247.10.109
7 47 ms 47 ms 47 ms 64.159.0.230
8 47 ms 47 ms 46 ms 64.159.18.104
9 50 ms 49 ms 49 ms 63.215.128.138
10 49 ms 52 ms 50 ms 192.168.11.253
11 49 ms 49 ms 49 ms 172.23.128.5
12 49 ms 49 ms 50 ms 172.23.4.22
13 999 ms 1432 ms 1445 ms 64.157.38.188

Randy Williams
CTO, Rackshack.net

Just FYI. THe NOC .. HNS facility on Exploration lane in Germantown MD. The site is just off I240, north of DC.

That is where our requests travel through

Here is the trace from my server to that IP


[root /]# traceroute 64.157.38.188
traceroute to 64.157.38.188 (64.157.38.188), 30 hops max, 38 byte packets
1 216.12.213.1 (216.12.213.1) 0.464 ms 0.385 ms 0.344 ms
2 207.218.223.5 (207.218.223.5) 0.375 ms 0.411 ms 0.343 ms
3 ge-1-1-0.r02.hstntx01.us.bb.verio.net (129.250.10.65) 0.859 ms 0.855 ms 0
.807 ms
4 p16-2-0-0.r00.hstntx01.us.bb.verio.net (129.250.3.46) 0.908 ms 1.091 ms 0
.977 ms
5 p16-1-1-1.r21.dllstx01.us.bb.verio.net (129.250.5.4) 5.773 ms 5.680 ms 5.
594 ms
6 p16-2-0-0.r01.dllstx01.us.bb.verio.net (129.250.3.29) 5.640 ms 5.720 ms 5
.723 ms
7 pos1-1.core1.Dallas1.Level3.net (209.245.240.189) 5.939 ms 5.775 ms 5.850
ms
8 so-4-1-0.mp2.Dallas1.Level3.net (209.247.10.109) 6.116 ms 6.159 ms 6.154
ms
9 so-3-0-0.mp2.Washington1.Level3.net (64.159.0.230) 47.177 ms 47.368 ms 47
.444 ms
10 gige8-1.hsipaccess2.Washington1.Level3.net (64.159.18.104) 47.300 ms 47.48
0 ms 47.366 ms
11 unknown.Level3.net (63.215.128.138) 49.561 ms 49.365 ms 49.346 ms
12 192.168.9.253 (192.168.9.253) 87.529 ms 66.177 ms 66.111 ms
13 172.23.128.5 (172.23.128.5) 74.190 ms 72.703 ms 69.819 ms
14 172.23.4.22 (172.23.4.22) 70.624 ms 63.541 ms 67.670 ms
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[root /]#

IDS?

Who's that?

from: 216.12.213.1 - the same subnet as ljprevo

telnet@ni-1#trace 64.157.38.188 source 216.12.213.1 timeout 5
Type Control-c to abort
Tracing the route to IP node 64.157.38.188 from 1 to 30 hops

1 <1 ms <1 ms <1 ms 207.218.223.5
2 2 ms <1 ms <1 ms ge-1-1-0.r02.hstntx01.us.bb.verio.net [129.250.10.65]
3 <1 ms <1 ms <1 ms p16-2-0-0.r00.hstntx01.us.bb.verio.net [129.250.3.46]
4 5 ms 5 ms 5 ms p16-1-1-1.r21.dllstx01.us.bb.verio.net [129.250.5.4]
5 5 ms 5 ms 5 ms p16-2-0-0.r01.dllstx01.us.bb.verio.net [129.250.3.29]
6 5 ms 5 ms 5 ms pos1-1.core1.Dallas1.Level3.net [209.245.240.189]
7 6 ms 5 ms 6 ms so-4-1-0.mp2.Dallas1.Level3.net [209.247.10.109]
8 47 ms 47 ms 47 ms so-3-0-0.mp2.Washington1.Level3.net [64.159.0.230]
9 47 ms 47 ms 47 ms gige8-1.hsipaccess2.Washington1.Level3.net [64.159.18.104]
10 49 ms 49 ms 49 ms unknown.Level3.net [63.215.128.138]
11 62 ms 50 ms 56 ms 192.168.11.253
12 49 ms 49 ms 48 ms 172.23.128.5
13 49 ms 49 ms 50 ms 172.23.4.22
14 1737 ms 1421 ms 1451 ms dpclt038188.direcpc.com [64.157.38.188]

Ouch.

IDS = intrusion detection system

Randy Williams
CTO, Rackshack.net

Ouch because of the 1737 ms?

The IDS, is that RS's IDS?

Reason I ask, is these DirecWay users are behind a proxy, they share common IP#'s I believe, that would not have
anything to do with it would it?

right now at this very second i have access to my server.. SMTP, and FTP

Do a trace quick before you lose it.

you are correct on the ip.