 |
 |
|
|
||
|
 |
Department of Engineering |
|
|
|
|
| University of Cambridge > Engineering Department > computing help > jpmg help |
This page is intended to provide some advice about how to identify the cause of problems with network connections in CUED.
It covers
First, here are some symptoms that may be observed during normal computer use:
This does not tell you very much at all. You may happen not to have anyone sending you email at the moment. Even if you're expecting a particular message, there are a large number of potential reasons for it not to have arrived, many of which are far likelier than a network problem.
It is probably best in this circumstance to see if you can find any other evidence that the network isn't working.
There are a number of possible causes for this.
If you have more than one DNS server listed in your network configuration, and the first one is incorrect, most current operating systems will wait for a timeout on the first one before trying the second, for every hostname lookup that is done.
If remote networks (eg the links between JANET and the US) are heavily loaded, accesses to some web sites may be extremely slow. However, the existence of caches both within your web browser, and on proxy servers that your browser may be configured to use, is likely to mean that some pages are fetchable quickly (from cache) and only ones that aren't cached will be slow to fetch.
If a machine local to CUED is generating unreasonably large amounts of traffic, network congestion may also occur. In such circumstances, identifying the offending the machine is probably best left to CUED computer support staff.
It may just happen that the site or sites you are trying to access have problems of their own ...
Possible causes for this include:
As above, but without any caching of html pages by the browser, so every page you try to access will involve a hostname lookup (there are subtleties in this case relating to whether the browser separately caches DNS hostname lookup results).
Your browser may be configured to access a web proxy which is either very remote, or very heavily loaded. Sometimes laptops get configured for use at a remote site, and when they are brought to CUED, still attempt to use services (such as DNS servers, or web proxy servers) on the remote site. In some cases, this can result in extremely slow performance!
Very rarely a broken network card, or one which is incorrectly configured, may result in a situation in which a small proportion of network packets are transmitted, but most are not. This will result in extremely poor network performance.
Possible causes for this include:
It may just happen that the site or sites you are trying to access have problems of their own ...
Possible causes for this include:
If your browser is configured to try and access a proxy server that does not exist, or is not prepared to provide you with access, then you may find that all web sites you try to visit appear to refuse your connection.
See the section just below on checking that your local connection is working.
Very little of what is described later on this page will have any relevance if your computer is not correctly attached to the departmental network.
Things to check in that regard are:
The cable may plug directly into the back of the computer, or into a "transceiver" (typically a small box with a few green leds on it). Either the cable or the transceiver may have worked slightly loose. Check that it's firmly plugged in.
As before - the cable may look to be in the socket, but may have been pulled nearly out, so that the connection is not made. Check that it's firmly plugged in.
This is of particular relevance to PCMCIA/PC-Card/Cardbus ethernet cards in laptops ...
If this is a new setup, you may need to ask for assistance in getting yourself connected to the network. Otherwise, assure yourself that you haven't either made any changes to your system configuration recently.
It is not necessarily the case that a marked network "port" (socket) on the wall must be connected up to the network. If you've plugged your computer into a random socket, it is quite likely that it won't be patched into a network switch, and won't have any connection at all.
Alternatively, an error condition may be detected by one of the network switches, which may cause it to disable a particular socket.
If you have appropriate tools, look to see if your computer is seeing traffic on its network connection (in many cases, the Windows "Network Control Panel" will provide a real-time indication of this; Linux users may wish to use the "tcpdump" utility).
If you do not see any traffic, you should seek assistance.
If you believe you have a working local network connection, but very little else is happening (eg you cannot contact other machines in the department, particularly infrastructure machines such as www.eng.cam.ac.uk or the various email servers), then check recent copies of the departmental bulletin to see if there is scheduled downtime.
Failing that, contact the operators, who should know if a disaster has occurred!
This page is of course unlikely to be visible in such a situation, unless cached by your browser!
If your local connection is working, and you still believe there's a problem, you can often determine more about its location and nature by using the tools suggested below:
This page includes links to the ucam.eng.announce newsgroup, and to a "downtime" web page, both of which should provide details of any scheduled downtime of networking infrastructure within CUED
This page (on CUED's web server) keeps a cache of the most recent information gathered from the Computing Service's netnews server, which provides information about scheduled and unexpected downtime of central services including networking.
If our link to the rest of the university is down, this will either provide you with the reason if the outage was scheduled, or tell you when connectivity was last available otherwise.
This page gives an overview of network connection status between the central Computing Service systems and the rest of the university network and the rest of the Joint Academic Network (JANET).
If we have a working connection to the university network, this is likely to provide a good indication of any problems between Cambridge and "the rest of the world".
This page gives an overview of network connection status between the main JANET nodes, and between JANET and the rest of "the Internet", and should be accessible provided the link between CUED and the rest of the university network is working.
In the event of a network problem outside CUED (whether elsewhere in the university, or further afield), all reports or complaints should go via CUED networking support (network-support@eng.cam.ac.uk).
The page on reasons why the Web may seem slow provides a different perspective on some of the problems discussed here, and is worth looking at if you perceive performance problems particularly with web access.
The following tools may prove useful when pinning down more complicated network problems. However, it is not recommended that they be used by people who do not feel confident enough to understand the documentation that comes with them (if any ...).
This is a standard unix utility, although it may not be on the default path (look in /etc, /usr/etc, /sbin, and /usr/sbin if it's not). It can provide a summary of packet loss and round trip times for the (ICMP) packets it sends to a destination.
Be wary that routers may preferentially drop ICMP packets under load, so ping information should be regarded with some caution.
This will be installed by default on some unix systems (many redhat installations, for example), but not all. A similar proviso to that given for ping, applies, although some versions of traceroute operate with (outbound) udp packets instead, which mitigates some of that problem.
What traceroute provides that ping doesn't is an indication of where in the network packets are failing to get past. However, given the possibility of asymmetric routing (packets may not take the same path travelling to a host as they do when returning to your machine) among other problems, the information that traceroute provides can be distinctly mis-leading.
|
|