Hi,
I have noticed that our site, www.universityresource.com is often
unavailable.  At first we thought it was the hosting company but we
have rulled that out since they host many sites for us which are
always available.

Upon doing a tracert www.universityresource.com  the results were all
*'s (request timed out) over hundreds of tries.  This unavailability
is not continuous but seems to come up many times in a week.

My question is, what would cause such an error?  Why would Trace Route
produce all timeouts without a single server picking up the route
while our other sites on the same server are up, and while the server
support team are able to confirm that the site itself is working fine?

Hope you can help us solve this challenging question.

---

Request for Question Clarification by sublime1-ga on 02 Mar 2003 20:39 PST

mhffs...

"Routers can be configured not to respond to ping requests.
 For example Microsoft blocks pings.  Try tracert microsoft.com"
http://216.239.53.100/search?q=cache:LR2FOnXSN6sC:www.experts-exchange.com/Web/Q_10429037.html+tracert+all+timed+out&hl=en&ie=UTF-8

Could this be the situation you're experiencing?

---

Clarification of Question by mhffs-ga on 02 Mar 2003 20:44 PST

That is an interesting suggestion. however The core issue is not that
the servers are not responding to pings, but that the webpage is
unavailable and that it appears that a large number of servers are not
recognizing the address.  If we ping one of the other webs we own and
host on the same servers, say www.iactgreen.com the results are
immediately positive and Trace Route shows that servers across North
America respond to the address.

So what is happening with www.universityresource.com?

---

Clarification of Question by mhffs-ga on 02 Mar 2003 21:23 PST

To add clarification, after being completely unavailable the page will
then be completely available with every ping by TraceRoute returning a
server address in 10 to 30 ms.

---

Request for Question Clarification by sublime1-ga on 02 Mar 2003 21:26 PST

mhffs...

What you are describing would make me suspicious of the PC or
the ISP being used from which you are originating the tracert.
Does this seem to be a reasonable possibility?

---

Clarification of Question by mhffs-ga on 02 Mar 2003 21:33 PST

Not sure.  You raise a big issue.
When the traceRoute does succeed it identifies BellNexxia as the
nearest servers which is congruent with the fact that they are our ISP
(not our web server host).  Is this possible?  What are the mechanisms
for this sort of issue?  Are their solutions, for instance if the
issue were at the host I would create a mirror site.  Is there a way
of creating redundancy for the network address?

Thanks,
Martin

---

Request for Question Clarification by sublime1-ga on 02 Mar 2003 22:06 PST

mhffs...

When the tracert succeeds, it will identify the trail of 
computers from where the tracert is initiated to the site
being pinged. It makes sense, then, that the first several
servers would be identified as BellNexxia. From there, the
route is traced onto the web and ultimately to the website
host and the site itself.

If, when the tracert is unsuccessful, the initial BellNexxia
servers are not responding, this would indicate a problem
with their servers, or with the PC from which the tracert is
initiated. Mirroring your site will not improve the situation
if this is the case. If this were occurring to me, I would
first call a friend who is using a different ISP and have them
run a tracert on universityresource.com. If theirs is successful,
I would then try from my PC again. If the tracert is unsuccessful,
I would run 'ipconfig /all' from a command line (or the equivalent,
depending on the Operating System). If that checks good, I would
try 'ping yahoo.com' and see if that is successful. If you can
ping Yahoo, you should be able to ping UniversityResource, and
run a successful tracert. If, after an unsuccessful tracert,
you are unsuccessful pinging Yahoo, then the problem is on the
ISP of the originating PC, or on the PC itself.

I'm going to guess that the PC from which you're initiating the
tracert is running Windows XP, but I'll wait for your response
to the above before going further.

---

Clarification of Question by mhffs-ga on 03 Mar 2003 06:00 PST

Thanks for the detailed answer.  
The situation is this:
I am running windows 2000
I can ping webpages on the same server as UniversityResource,
I can ping all the regular web pages (yahoo, google, you name it)
When the page becomes unavailable it is as if the University Resource
address has been removed or hidden on the routing servers.  It simply
cannot be reached, at least not through the bell network.  I haven't
checked to see if it is available from a different ISP.  I will try
this the next time the Bell Network jams it and see if it is across
the board or local to them.

Thanks for your help.  I really appreciate your work on this.  I will
leave it open for a little longer to gather any further comment you
may have, and also to enter the results should I have an opportunity
to conduct the test mentioned above.

Cheers,
Martin

---

Request for Question Clarification by sublime1-ga on 03 Mar 2003 07:59 PST

mhffs...

I thought so. Windows 2000 and XP are essentially the same, and
have this bug in common: by default, there is a service called
'DNS Client' that is set to start automatically. The description
for this service is "Resolves and caches Domain Name System (DNS)
names". My experience with this service, and the experience of 
others, as well, is that it sometimes slows things down - badly -
to the degree that it uses 100% of my 1667MHZ CPU capacity for
more than a minute, searching its DNS cache for addresses, and
that is just in the process of the browser going to a new page,
much less the process of a tracert. When I disabled it, there
were no resulting problems, and my system speed increased greatly
when browsing.

To disable it, go to Start -> Settings -> Control Panel ->
Administrative Tools -> Component Services, and select
'Services (Local)'. Then find 'DNS Client' in the list of
services to the right. Double-click on it and set the 
'Startup type', in the middle of the Properties dialog,
to 'manual' or 'disabled' (mine is on manual). Then
reboot and see if there's a difference in your results.

Another point to be aware of is that, if your site server
is running a firewall, it would be normal for it to show
up (as the last entry in the tracert) as '*' - timed out.
This should *not* be the case for *most* of the intermediate
servers, however, and certainly not for the BellNexxia
ISP servers.

I'll be gone much of the day, but will check in when I get
back.

sublime1-ga

Martin...

Thank you for your willingness to pay for the help you received,
when you might have simply let the question expire. That is a
most honorable and exceptional quality of character.

Since the others who assisted you here are not (as yet) researchers
who are authorized to post an answer, I will step to the plate on
behalf of us all, and close the question for you.

Please be aware that you can still post requests for clarification 
on this topic, should the need arise, and comments can still be
added, as well.

Thanks again for your generosity.

sublime1-ga

Hmm from what I see it's you have a faulty hardware equipment most
probably your site have its dedicated server (hmm?) if so then it
might be either the Nic or the cables or else related to them ...

Dear Mhffs,

Sublime1's suggestion of asking a friend to do a traceroute for you is
a sensible one.  If you don't have any friends [ ;^) ], go to

http://www.traceroute.org

and you'll find links to a number of systems around the world willing
to perform a traceroute for you to a specified system.  Checking
whether these work when access from your PC doesn't may help you to
find whether the problem is local to your PC or to your web server.

I hope this helps.

Carnegie

It's like you're reading my mind.
Thanks.

I really have to wonder if this is simply a DNS issue here. As i'm
sure you know, when you type in www.universityresource.com, that must
first be converted to an IP. Next time you have this problem, open a
command prompt, and type nslookup www.universityresource.com and see
what happens. You should have an IP address resolved for you. It turns
out that www.universityresource.com is a CNAME (alias) for
universityresource.com, which resolves to 66.96.244.85

DNS is a really simply thing many people overlook when troubleshooting
things like this. Give it a try, let me know what happens.

Interesting comment.  Let me address the issues for you and tell you
about the possible resolution.
The DSN Client issue:
1. Only University Resource.com site becomes unavailable.  
When it becomes unavailable it can be such for hours or days.
2. I set up an account with a second ISP. When the site is blocked by
the Bell.Nexxia network I simply dial up on this second ISP and can
access the site without trouble.  This functional connection can be
documented by tracert.  I have also documented that the site is
available outside of this network by using the trace sites listed
earlier in this thread.

I have written to Bell.sympatico about this NameServer issue and
included some of the documentation in the form of tracert for
universityResource and for other sites illustrating that they are
available while UniversityResource was being blocked.
I have not received a response from Bell, but with the exception of a
few hours starting at 6pm on March 13th 2003.  It is my hope that this
letter has solved the issue.

My hope is also that anyone experiencing similar issues with their
site will find this case and get some ideas on how to document the
issue.

I meant to say:
with the exception of a few hours on March 13th, 2003 the issue is no
longer occuring.  ( I guess I should cross my fingers on this).

If someone would care to post something in the "answer" box I will
close this case and thank everyone for their very generous help.

Many Thanks,
Martin Holmes

It appears to be a problem at BellNexxia - we have also seen several
prolonged outages and periods of unreliability, centring on their
peering connections in Chicago.  Latency was running to 3000ms or
simply timing out.  On a couple of days last month, no one on
Bell/Sympatico connections in Canada could see Google, nor much of the
rest of the US Internet.  Their hostmaster's inbox had overflowed when
I tried sending them tracert reports!  I suspect they've learned from
it - have you have the same problem in the last few days?