If you could try the following command from the command prompt and let
me know if it completes successfully from your computer:
tracert 72.46.130.74
or if you don't have tracert in your system files, then:
ping 72.46.130.74
And if you want to see the web sites for the above address,
Control Panel: http://72.46.130.74:2082/
Web Host Manager: http://72.46.130.74:2086/
From my concast connected computer, none of the sites work.
Here is the message I sent to the host:
---
Dear host:
I think I found the problem but I do NOT know how to fix it.
Comcast(roadrunner) access from Houston does NOT work. The tracert
result shows that the packets are lost once the packet approaches your
site. However, using other internet providers such as dial up juno,
the packets complete the path.
Here is the comcast trace results:
==
C:\>tracert 72.46.130.74
Tracing route to server.theservergroup.net [72.46.130.74]
over a maximum of 30 hops:
1 6 ms 7 ms 8 ms 73.2.64.1
2 7 ms 15 ms 7 ms
ge-2-25-ur02.pasadena.tx.houston.comcast.net [68.85.250.201]
3 8 ms 7 ms 7 ms
po-14-ar01.royalton.tx.houston.comcast.net [68.85.245.62]
4 9 ms 7 ms 7 ms
po-11-ar02.royalton.tx.houston.comcast.net [68.85.244.98]
5 10 ms 10 ms 12 ms
po-17-ar02.greenspoint.tx.houston.comcast.net [68.85.244.130]
6 14 ms 16 ms 15 ms
pos-0-14-0-0-cr01.dallas.tx.ibone.comcast.net [68.86.85.153]
7 36 ms 37 ms 35 ms
pos-0-15-0-0-cr01.atlanta.ga.ibone.comcast.net [68.86.85.69]
8 51 ms 49 ms 49 ms
te-6-1-pr01.ashburn.va.ibone.comcast.net [68.86.88.101]
9 51 ms 51 ms 51 ms ashbbbrj01-ge040100.r2.as.cox.net
[68.86.88.102]
10 95 ms 95 ms 97 ms nwstdsrj01-ge710.rd.lv.cox.net
[68.1.0.85]
11 100 ms 97 ms 97 ms 24-234-18-130.ptp.lvcm.net
[24.234.18.130]
12 102 ms 100 ms 98 ms 24-234-18-130.ptp.lvcm.net
[24.234.18.130]
13 99 ms 99 ms 99 ms ge0502-csr1.lv1.marquisnet.com
[208.110.166.6]
14 102 ms 101 ms 102 ms unmapped.marquisnet.com
[204.15.164.158]
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
=== end of trace
Note that the last packet returned is 'unmapped.marquisnet.com
[204.15.164.158]' and then further paths are NOT returned.
I've attached a Working JUNO trace to my ehostus site for contrast.
====== Working Juno trace
c:\> tracert 72.46.130.74
Tracing route to [72.46.130.74]
over a maximum of 30 hops:
1 900 ms 199 ms 189 ms 192.168.254.1
2 222 ms 1465 ms 909 ms hou3-core1-f0-0-1.starnetusa.net
[66.217.192.1]
3 367 ms 1117 ms 227 ms
fe-0-1-1-511.aggr01.hstntx.grandecom.net [66.90.
133.102]
4 1248 ms 199 ms 207 ms s0-1-0-1-0.core02.smrctx.grandecom.net
[24.155.1
21.21]
5 320 ms 202 ms 617 ms bcr2-so-3-0-0.dallas.savvis.net
[208.172.129.137
]
6 371 ms 389 ms 224 ms cr2-pos0-0-3-0.dallas.savvis.net
[204.70.193.14]
7 1723 ms 241 ms 1953 ms cr2-loopback.lay.savvis.net
[208.172.34.71]
8 1204 ms 687 ms 1375 ms bpr1-ge-3-1-0.LosAngeles.savvis.net
[204.70.192.
214]
9 576 ms 1932 ms 1397 ms 216.89.82.38
10 224 ms 1000 ms 262 ms ge0101-bcr1.lv1.marquisnet.com
[208.110.166.97]
11 1776 ms 912 ms 282 ms ge0921-csr1.lv1.marquisnet.com
[208.110.166.38]
12 943 ms 254 ms 562 ms unmapped.marquisnet.com
[204.15.164.158]
13 251 ms 254 ms 265 ms server.theservergroup.net
[72.46.130.74]
Trace complete.
======== end of working juno trace
Please help
=========
----------
thanks,
jiml
Not a problem with ATT dsl. Connects instantly.
lee@big-laptop:~$ whois 72.46.130.74
OrgName: R & D Technologies, LLC
OrgID: RDTL
Address: 2675 Patrick Lane
Address: Suite 8
City: Las Vegas
StateProv: NV
PostalCode: 89120
Country: US
ReferralServer: rwhois://rwhois.rdtg.net:4321
NetRange: 72.46.128.0 - 72.46.159.255
CIDR: 72.46.128.0/19
NetName: NETBLK-RDTL-LV-3
NetHandle: NET-72-46-128-0-1
Parent: NET-72-0-0-0-0
NetType: Direct Allocation
NameServer: NS1.USERDNS.COM
NameServer: NS2.USERDNS.COM
Comment:
RegDate: 2006-08-30
Updated: 2006-09-27
OrgAbuseHandle: RAD89-ARIN
OrgAbuseName: RDTL Abuse Department
OrgAbusePhone: +1-973-273-5883
OrgAbuseEmail: abuser...@versaweb.net
OrgTechHandle: RTY1-ARIN
OrgTechName: Tyree, Robert
OrgTechPhone: +1-702-478-6598
OrgTechEmail: r...@rdtg.net
# ARIN WHOIS database, last updated 2008-03-26 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.
Found a referral to rwhois.rdtg.net:4321.
%rwhois V-1.0,V-1.5:00090h:00 ubersmith.rdtg.net (Ubersmith RWhois
Server V-1.0)
autharea=72.46.130.0/24
xautharea=72.46.130.0/24
network:Class-Name:network
network:Auth-Area:72.46.130.0/24
network:ID:NET-502.72.46.130.72/29
network:Network-Name:
network:IP-Network:72.46.130.72/29
network:IP-Network-Block:72.46.130.72 - 72.46.130.79
network:Org-Name:Main Royal Development Inc.
network:Street-Address:PO Box 401
network:City:Round Lake
network:State:Illinois
network:Postal-Code:60073
network:Country-Code:US
network:Tech-Contact:MAINT-502.72.46.130.72/29
network:Created:20070507220714000
network:Updated:20080108193404000
network:Updated-By:ip-a...@rdtg.net
network:POC-Name:IP Administrator
network:POC-Email:ip-a...@rdtg.net
network:POC-Phone:+1-973-273-5883
network:Tech-Name:IP Administrator
network:Tech-Email:ip-a...@rdtg.net
network:Tech-Phone:+1-973-273-5883
%ok
No log handling enabled - turning on stderr logging
read_config_store open failure on /var/net-snmp/snmpapp.conf
read_config_store open failure on /var/net-snmp/snmpapp.conf
read_config_store open failure on /var/net-snmp/snmpapp.conf
Go figure.
But I'm still working on this and appreciate the help.
On Thu, 27 Mar 2008 13:40:42 -0500, Lee Sharp <l...@spamtrap.com>
wrote:
Tell him Microsoft did not make my Ubuntu OS, so it may not help. :)
Latest from the office...
lee@big-laptop:~$ traceroute 72.46.130.74
traceroute to 72.46.130.74 (72.46.130.74), 30 hops max, 40 byte packets
1 fw-office.dnsalias.net (192.168.29.1) 0.432 ms 0.194 ms 0.181 ms
2 fw-office.dnsalias.net (192.168.29.1) 12.071 ms 7.887 ms 8.073 ms
3 ge-3-13-ur02.royalton.tx.houston.comcast.net (68.85.250.117) 7.809
ms 10.336 ms 16.756 ms
4 po-14-ar02.royalton.tx.houston.comcast.net (68.85.244.93) 8.739 ms
11.741 ms 7.935 ms
5 po-17-ar02.greenspoint.tx.houston.comcast.net (68.85.244.130)
14.493 ms 15.939 ms 12.286 ms
6 pos-0-15-0-0-cr01.dallas.tx.ibone.comcast.net (68.86.85.149)
16.896 ms 14.719 ms 14.561 ms
7 pos-0-15-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.85.69)
37.772 ms 46.917 ms 36.434 ms
8 te-6-1-pr01.ashburn.va.ibone.comcast.net (68.86.88.101) 50.969 ms
60.574 ms 50.819 ms
9 ashbbbrj01-ge040100.r2.as.cox.net (68.86.88.102) 52.193 ms 59.837
ms 51.820 ms
10 * nwstdsrj01-ge710.rd.lv.cox.net (68.1.0.85) 106.507 ms *
11 24-234-18-130.ptp.lvcm.net (24.234.18.130) 109.220 ms 97.703 ms
98.302 ms
12 24-234-18-130.ptp.lvcm.net (24.234.18.130) 102.307 ms 97.848 ms
101.304 ms
13 ge0502-csr1.lv1.marquisnet.com (208.110.166.6) 107.469 ms 97.791
ms 98.087 ms
14 unmapped.marquisnet.com (204.15.164.158) 111.638 ms 102.082 ms
103.028 ms
15 * * *
16 * * *
17 * * *
18 * * *
>JimL wrote:
I'll forward that info to the web hosting site.
Here is the dns rereport I received on the IP address:
====
And here is a dnsreport as of 03/27/2008 16:40:34 which shows some
errors :
===========
DNS report for site:
Parent pass NS records at parent servers Your NS records at the parent
servers are:
ns1.spothosted.com. [ 72.46.130.75 ]
ns2.spothosted.com. [ 72.46.130.76 ]
[These were obtained from h.gtld-servers.net.]
pass Glue at parent nameservers Parent nameservers (I checked with
h.gtld-servers.net.) know A record for your domain, Very good !
NS info NS records at your nameservers Your NS records at your
nameservers are:
ns2.theservergroup.net. [72.46.130.76 ]
ns1.theservergroup.net. [72.46.130.75 ]
pass Mismatched glue OK. The DNS report did not detect any
discrepancies between the glue provided by the parent servers and that
provided by your authoritative DNS servers.
pass No NS A records at nameservers OK. Your nameservers do include
corresponding A records when asked for your NS records. This ensures
that your DNS servers know the A records corresponding to all your NS
records.
pass All nameservers report identical NS records OK. The NS records at
all your nameservers are identical.
pass All nameservers respond OK. All of your nameservers listed at the
parent nameservers responded.
pass Nameserver name validity OK. All of the NS records that your
nameservers report seem valid (no IPs or partial domain names).
pass Number of nameservers OK. You have 2 nameservers. You must have
at least 2 nameservers (RFC2182 section 5 recommends at least 3
nameservers), and preferably no more than 7.
pass Lame nameservers OK. All the nameservers listed at the parent
servers answer authoritatively for your domain.
fail Missing (stealth) nameservers ERROR: stealth nameservers
(nameservers what does not exist at root servers , but exist at your
nameservers)
ns2.theservergroup.net. at ns1.spothosted.com. [72.46.130.75]
ns1.theservergroup.net. at ns1.spothosted.com. [72.46.130.75]
ns1.theservergroup.net. at ns2.spothosted.com. [72.46.130.76]
ns2.theservergroup.net. at ns2.spothosted.com. [72.46.130.76]
fail Missing nameservers 2 ERROR: missing nameservers (nameservers
what exist at root servers , but does not exist at your nameservers)
ns1.spothosted.com. missing at ns1.spothosted.com. [72.46.130.75]
ns2.spothosted.com. missing at ns1.spothosted.com. [72.46.130.75]
ns1.spothosted.com. missing at ns2.spothosted.com. [72.46.130.76]
ns2.spothosted.com. missing at ns2.spothosted.com. [72.46.130.76]
pass Nameservers on separate class C's Your nameservers seems to be in
different networks.
pass All NS IPs public OK. All of your NS records appear to use public
IPs. If there were any private IPs, they would not be reachable,
causing DNS delays.
SOA info SOA record Your SOA record is:
Primary nameserver: ns1.theservergroup.net.
Hostmaster E-mail address: grinch.mail.gmail.com.
Serial #: 2008032401
Refresh: 86400
Retry: 7200
Expire: 604800
Default TTL:86400
pass NS agreement on SOA Serial # OK. All your nameservers agree that
your SOA serial number is 2008032401. That means that all your
nameservers are using the same data.
fail SOA MNAME Check ERROR: Your SOA (Start of Authority) record
states that your master (primary) name server is:
ns1.theservergroup.net. That server is not listed at the parent
servers, which is not correct.
pass SOA Serial Number OK. Your SOA serial number is: 2008032401. This
appears to be in the recommended format of YYYYMMDDnn, where 'nn' is
the revision. This number must be incremented every time you make a
DNS change.
warn SOA REFRESH value Your SOA REFRESH interval is : 86400 seconds.
This seems too long (about 3600-7200 seconds is good if not using DNS
NOTIFY; RFC1912 2.2 recommends a value between 1200 to 43200 seconds
(20 minutes to 12 hours)). This value determines how often
secondary/slave nameservers check with the master for updates.
pass SOA RETRY value Your SOA RETRY interval is : 7200 seconds. This
seems normal (about 120-7200 seconds is good). The retry value is the
amount of time your secondary/slave nameservers will wait to contact
the master nameserver again if the last attempt failed.
pass SOA EXPIRE value Your SOA EXPIRE time is : 604800 seconds. This
seems normal (about 1209600 to 2419200 seconds (2-4 weeks) is good).
RFC1912 suggests 2-4 weeks. This is how long a secondary/slave
nameserver will wait before considering its DNS data stale if it can't
reach the primary nameserver.
pass SOA MINIMUM TTL value Your SOA MINIMUM TTL is : 86400 seconds.
This seems normal (about 3,600 to 86400 seconds or 1-24 hours is
good). RFC2308 suggests a value of 1-3 hours. This value used to
determine the default (technically, minimum) TTL (time-to-live) for
DNS entries, but now is used for negative caching.
=========== end of dns report
I think that eHostUS will have to fix their dns stuff - or give me my
money back.
Thanks.
JimL
> I think that eHostUS will have to fix their dns stuff - or give me my
>money back.
This is unlikely to be a DNS issue, although they may well have some
of those as well.
I'm with Lee, it looks like some sort of routing issue. What does it
look like if you do a traceroute from your webhost back to your
Comcast PC?
The hosting company informed me to be patient; that there would be a
different hosting company with new IP address provided shortly. They
said the control panel didn't work for many of their customers so they
are scrambling to find another.
Assuming I could get to my hosting site (which I can't), how would I
perform a tracert back to my comcast pc? I don't think they will let
me run tracert on their pc, or do you know of some software that I
could put on my web page at the hosting site?
JimL
> The hosting company informed me to be patient; that there would be a
>different hosting company with new IP address provided shortly. They
>said the control panel didn't work for many of their customers so they
>are scrambling to find another.
Well, at least they're working on it!
> Assuming I could get to my hosting site (which I can't), how would I
>perform a tracert back to my comcast pc? I don't think they will let
>me run tracert on their pc, or do you know of some software that I
>could put on my web page at the hosting site?
Sorry, I didn't realize you didn't have full access to the server.
Without that, you'd probably have to get them to run the traceroute
for you (although it might be possible to do it from a CGI script,
depending on what they allow access to.)
My best guess is that whatever machine is supposed to be
> 14 unmapped.marquisnet.com (204.15.164.158) 111.638 ms 102.082 ms 103.028 ms
HERE ---> > 15 * * *
Doesn't know how to reach the addresses on Comcast. Note that I cannot
(or could not when I last tried it) reach it from my virtual server in
Philadelphia, so it's not just Comcast addresses that don't work. All
my traceroutes stopped at the same place.
Note that I have no idea what that address is supposed to be. I don't,
for example, know if that is the machine I'm trying to get to or if it's
just another router. However, that is the machine that most likely has
the problem. Unless, of course, they're doing something rude, like
filtering the requests.
Normally, I'd say that it needs it's default route set to the
appropriate value, but if it works for some addresses (as has been
reported) then it's probably some BGP weirdness or other. I can think
of a number of likely possibilities.
--
Jonathan Guthrie (jgut...@brokersys.com)
Sto pro veritate
My hosting company that owned that IP address gave me a new IP
address and all is well now.
And I just checked the bad IP address again and it is working fine
when accessing it from comcast houston. Don't know about
Philadelphia.
On Thu, 27 Mar 2008 08:21:28 -0500, JimL <23...@email.hal-pc.org>
wrote:
>I would appreciate your help in identifying a network problem I am