Scrigroup - Documente si articole

     

HomeDocumenteUploadResurseAlte limbi doc
BulgaraCeha slovacaCroataEnglezaEstonaFinlandezaFranceza
GermanaItalianaLetonaLituanianaMaghiaraOlandezaPoloneza
SarbaSlovenaSpaniolaSuedezaTurcaUcraineana

AdministrationAnimalsArtBiologyBooksBotanicsBusinessCars
ChemistryComputersComunicationsConstructionEcologyEconomyEducationElectronics
EngineeringEntertainmentFinancialFishingGamesGeographyGrammarHealth
HistoryHuman-resourcesLegislationLiteratureManagementsManualsMarketingMathematic
MedicinesMovieMusicNutritionPersonalitiesPhysicPoliticalPsychology
RecipesSociologySoftwareSportsTechnicalTourismVarious

Troubleshoot your network errors with TechRepublics TCP/IP Checklist

computers



+ Font mai mare | - Font mai mic



Troubleshoot your network errors with TechRepublics TCP/IP Checklist

Whether your systems are powered by Windows or Linux, network configuration problems inevitably arise. Often the problem can be traced to an improperly configured TCP/IP setting, but finding the culprit can be difficult.

Regular TechRepublic contributor and Internet specialist Dave Mays developed the following checklist to help you identify and eliminate network TCP/IP errors.



TechRepublics TCP/IP Checklist

What stopped working? The client or the server? Ask around before attacking coworkers PCs; learn if the outage is affecting others or just a single desktop.

If the server stopped working, you should notice many office mates banging their heads against their desks simultaneously. If this is the case, focus on fixing the server.

If a single client PC has stopped responding to the network, ask the user whether new software was just loaded or any recent changes have been made to the system, including the installation of service packs, new Internet software, Elf Bowling games, and so on.

Check the physical network. The physical topology of your network is most prone to failure. In fact, most network problems are often due to Physical Layer failures.

Is it plugged in? Check all network cable connections. Start at the NIC; is there a green light? Check the wiring closet to see if someone borrowed the patch cable. Check the hub to see if the system is getting a link across the cable.

If you dont have a cable tester, get one. Cabling is very susceptible to electricians, cleaning people, HVAC personnel, and so on.

Start PINGing. Both Windows and Linux have the PING command. In a typical network you have this order (client->gateway->server) or (client->gateway->internet).

First, attempt to PING yourself from the Windows command prompt or use the Linux shell. Your local loopback address for such testing is 127.0.0.1. Windows users should see the response shown in Listing A, while Linux operators should see the results shown in Listing B.

Listing A

C:WINDOWS>PING 127.0.0.1

PINGing 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time<10ms TTL=32

Reply from 127.0.0.1: bytes=32 time<10ms TTL=32

Reply from 127.0.0.1: bytes=32 time<10ms TTL=32

Reply from 127.0.0.1: bytes=32 time=1ms TTL=32

PING statistics for 127.0.0.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 1ms, Average = 0ms

Listing B

[root@gateway /root]# PING -c 4 127.0.0.1

PING 127.0.0.1 (127.0.0.1): 56 data bytes

64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=1.2 ms

64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.9 ms

64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.9 ms

64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.9 ms

--- 127.0.0.1 PING statistics ---

4 packets transmitted, 4 packets received, 0% packet loss

round-trip min/avg/max = 0.9/0.9/1.2 ms

Note that in Linux you must add -c 4 to the command, which requests four PINGs. Otherwise, you must stop the test using [CTRL]C.

If you do not receive a successful PING from yourself, in Windows, try re-installing the TCP/IP protocol from the Network Control Panel. In Linux, see if your Ethernet card is loading properly by using IFCONFIG. It should provide the information shown in Listing C.

Listing C

[root@gateway /root]# ifconfig

eth0 Link encap:Ethernet HWaddr 00:00:11:22:33:44

inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:219876 errors:0 dropped:0 overruns:0 frame:0

TX packets:153838 errors:0 dropped:0 overruns:0 carrier:0

collisions:77 txqueuelen:100

Interrupt:10 Base address:0x230

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

UP LOOPBACK RUNNING MTU:3924 Metric:1

RX packets:15 errors:0 dropped:0 overruns:0 frame:0

TX packets:15 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

By issuing the interface configuration (ifconfig) program, you will receive a list of your interfaces. If the loopback (lo) is not listed, you may have an incorrectly configured kernel or possible problems with the loopback module. Try recompiling/reinstalling to see if that resolves the problem.

If PINGing your loopback worked fine, then try PINGing someone who is on the same subnet as you. In the ifconfig example above, the IP address is set to 192.168.1.100. Thus, in this scenario you should attempt to PING 192.168.1.1. Be sure the target IP address being PINGed is a valid IP address assigned to a system; otherwise, youll receive errors. Use the Start | Run | IPCONFIG command to learn your NT machines IP configuration (use WINIPCFG with Windows 98).

Windows systems

IP Config provides valuable information about what network you are on, as well as your gateway address.

In Linux, use ifconfig to learn your network settings.

If you can PING someone on your local subnet, move on to the next step. If you can't, youre probably experiencing a Physical Layer failure. The usual suspects are bad cables or a NIC gone bad (they do that sometimes). With loopback, you were just testing the inner workings of the TCP/IP protocol stack; with PINGing on your local subnet you tested for failure on the failing machine. Try replacing the network card and using a new patch cable.

The next problem area is in the gateway. Find the IP address of your gateway. You can find this in the IPCONFIG screen with NT systems (WINIPCFG for Windows 98) or in Linux by running the netstat rn command, providing these results:

[root@gateway /root]# netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0

The -rn prints the routing table and puts everything in numeric format. In this example, the default gateway (0.0.0.0) is 192.168.1.254.

If you dont have a gateway configured, then one will not show up in WINIPCFG or when using netstat. This is a problem.

In Windows, locate Start | Settings | ControlPanel | Network | TCP/IP | Gateway and add your gateway. This is your local interface on your router. In Linux, use linuxconf or set up a temporary route using:

route add default gw gateway_ip_address

where gateway_ip_address is your gateway.

PING this address; this will prove a solid connection from your PC to the gateway. If you have made it this far, the PC is working, the cabling is working, and the router (gateway) interface is working. You can skip to the next section.

However, if you receive no response from the gateway, and you have one configured, its time to call in the big guns. Your router is improperly configured. It must have a local interface (IP address) on your subnet to listen to the traffic on your network. If there is no interface, have the router administrator add one. If it has one but has stopped working, it could mean youre experiencing a router failure, and others will be affected as well. Conversely, the router administrator may have loaded an old config; check with the administrator to make sure this isnt the case.

The final step is through the gateway. PING something that is on the other side of the gateway. In an intranet, PING a printer on a remote subnet. On the Internet, PING Yahoo! (204.71.200.68). If you do so successfully, you should not have a problem. If you can't get to a particular system in your network or on the Internet, that resource may not be available. You may want to tell the administrators of those systems about this checklist! Certainly, you can expect theyre working through the same difficulties as you.

Remember, TCP/IP was designed to be indestructible, even in a global thermonuclear war. After you get past an initial install, it should run for quite some time without any trouble. Always look for the most obvious problems first, and if in doubt, reboot your system.

Good luck!



Politica de confidentialitate | Termeni si conditii de utilizare



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 919
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved