ping
You can think of ping as network sonar. It sends out packets of information toward a server. If the remote server is online, ping reports back the number of bytes and time it took to get there. If the server is not online, it will give you an error message that the pinged server does not exist. Use this tool when you need a quick response to see that your network or your ISP's network is online; otherwise you’ll need to use other diagnostic tools.
The command-line structure of ping is
ping[-dfnqrvR] [-c count][-i wait interval ][-l preload] [-p pattern]
[-s packetsize] [-w waitsecs]
A typical readout of ping is shown here:
>ping localhost
> PING localhost.localdomain (127.0.0.1) from 127.0.0.1 :
56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.3 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.3 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.1 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.2 ms
Here we see that localhost.localdomain is connected. While ping will go on forever unless you hit [Ctrl]c, there’s another way to break out of an endless loop. You use the -c option, like so:
>ping -c 10 localhost
PING localhost.localdomain (127.0.0.1) from 127.0.0.1 :
56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.1 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.1 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.1 ms
64 bytes from 127.0.0.1: icmp_seq=4 ttl=255 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=5 ttl=255 time=0.1 ms
64 bytes from 127.0.0.1: icmp_seq=6 ttl=255 time=0.1 ms
64 bytes from 127.0.0.1: icmp_seq=7 ttl=255 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=8 ttl=255 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=9 ttl=255 time=0.1 ms
--- localhost.localdomain ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.2 ms
If the time seems to remain constant while you’re connected to your ISP, this might mean that the network is jammed.
Why use ping?
If you were an administrator, why would you want to use ping? The answer is that it’s the first line of defense. If you’re not using NT, then ping will tell you quickly if you’re online by sending you packets. It gets your boss off your back when he’s having network problems and barking the question, “Is the network up?” By using ping, you can at least tell him “Yes” or “No.”
Many companies have a mail server with many individual computers connected to it via a proxy server on the network. The direct way to this mail server is to ping it, as shown here:
ping -d -c 25
This command will ping for 25 packets. I think this is a fair amount of packets to test to see whether or not you’re online.
The -d option is for debugging.
If you’re on a workstation and have a proxy IP, then you might try this:
ping -d -r -c 25
This command is nearly the same as the previous example except it will bypass the routing tables. If your e-mail server is online, ping will return packets; otherwise you’ll get an error. This method should work if you’re not an administrator.
Scenario
Your boss yells that he can't send e-mail. What do you do? Using ping can help you with the first steps. If the packets are constant, then there might be a lot of traffic. Tell him to wait and try to send again. If the packets aren't constant, further diagnosis is needed.
netstat
Another major network tool is netstat. The netstat tool can provide you with plenty of information about your network, including information about TCP and UNIX connections. It can also tell you about the status of all the interfaces on your server. Interfaces for Ethernet are identified as eth0, eth1, etc; PPP as ppp0, ppp1, etc; and slip as sl0, sl1, etc. So, if you have one Ethernet connection up and running in the Iface column, it will be shown as UP.
You use the netstat tool to check which of your connections are up. This tool is very useful in a large network setting where you have perhaps 30 or more machines connected to a server and don't have the time to check all of them. You could use netstat to find the bad connections and then use some other network software to reconnect the machine if it finds a software problem, or you could go to the machine yourself and fix the hardware and the software. One place where this would come in handy is on an archive server. If everyone complains that they can't back up their work, you could invoke netstat to see if the server is up and then fix the problem by whatever means possible.
Displaying interface statistics
Invoke netstat at the prompt as follows:
>netstat –I
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg LRU
lo 3924 0 220 0 0 0 220 0 0 0
ppp0 1500 0 6 0 0 0 6 0 0 0
Let’s look at this command in detail:
- The MTU and Met fields show the current metric values for the interface (Iface).
- RX-OK/ERR represents received packets that are okay and those that have errors.
- TX-OK/EER represents transferred packets that are okay and those that have errors.
- RX-DRP represents received packets that have been dropped.
- TX-DRP represents transferred packets that have been dropped.
- The Flg column shows the flags that have been set for each interface. These values come ifconfig. The ones shown are one-character versions of long flag names:
L means that this interface is a loopback device.
R means that this interface is running.
U means that this interface is up.
P means that this is a point-to-point interface.
O means that ARP is turned off for this interface.
Displaying connections
The netstat tool has options to display active and passive sockets. These options show TCP, UDP, RAW, and UNIX socket connections. The flags to show these options are -t, -u, -w, and -x. For example, invoking netstat -ta produces this output:
>netstat –ta
tcp 0 0 *:1052 *:* LISTEN
tcp 0 0 *:1051 *:* LISTEN
tcp 0 0 *:1050 *:* LISTEN
tcp 0 0 *:1049 *:* LISTEN
tcp 0 0 *:1048 *:* LISTEN
tcp 0 0 *:1047 *:* LISTEN
tcp 0 0 *:1040 *:* LISTEN
tcp 0 0 *:1025 *:* LISTEN
tcp 0 0 *:6000 *:* LISTEN
tcp 0 0 *:smtp *:* LISTEN
tcp 0 0 *:printer *:* LISTEN
tcp 0 0 *:linuxconf *:* LISTEN
tcp 0 0 *:auth *:* LISTEN
tcp 0 0 *:finger *:* LISTEN
tcp 0 0 *:login *:* LISTEN
tcp 0 0 *:shell *:* LISTEN
tcp 0 0 *:telnet *:* LISTEN
tcp 0 0 *:ftp *:* LISTEN
tcp 0 0 *:sunrpc *:* LISTEN
This output shows that all servers are simply waiting for an incoming connection. Here’s some more interesting data from these options:
>netstat –tw
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 1 g69-17.citenet.net:1063 cti13.citenet.net:finger SYN_SENT
- Recv-Q represents the count of bytes not copied to this citenet.net socket.
- Send-Q represents the count of bytes not acknowledged by citenet.net.
Displaying program connections
In order to display program connections with netstat, you use the -p option. A sample readout is shown here:
>netstat –p
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 1 [ ] STREAM CONNECTED 6974 554/gnome-smproxy @00000082
unix 1 [ ] STREAM CONNECTED 1622 615/asclock_applet @0000007b
unix 1 [ ] STREAM CONNECTED 1309 601/gmc @0000006a
unix 1 [ ] STREAM CONNECTED 593 512/X @0000003f
unix 0 [ ] STREAM CONNECTED 201 1/init [5] @0000002e
unix 1 [ ] STREAM CONNECTED 6712 663/xemacs @00000081
unix 1 [ ] STREAM CONNECTED 1324 601/gmc @0000006b
unix 1 [ ] STREAM CONNECTED 589 513/ @0000003e
unix 1 [ ] STREAM CONNECTED 1667 592/panel @00000080
unix 1 [ ] STREAM CONNECTED 677 558/ @0000004b
unix 1 [ ] STREAM CONNECTED 46050 554/gnome-smproxy @000000b7
unix 1 [ ] STREAM CONNECTED 1647 592/panel @0000007f
unix 1 [ ] STREAM CONNECTED 1595 615/asclock_applet @00000077
unix 1 [ ] STREAM CONNECTED 1465 612/gen_util_applet @0000006e
unix 1 [ ] STREAM CONNECTED 1294 601/gmc @00000068
unix 1 [ ] STREAM CONNECTED 1112 592/panel @0000005d
This readout shows that all the programs are connected with their PIDs and their names (Program name). All of the programs are connected to UNIX sockets.
Why use netstat?
Why would anyone want to use netstat? The answer is to debug networks. You might use this tool if you suspected that your network was sluggish. This tool becomes the next logical step in debugging a network. After using ping, I’d use netstat to check all network connections.
Scenario
You’re on a network and supposedly connected to the Internet. Your boss comes in and yells at you because the e-mail server isn't working.
Here’s one strategy you can use to find out why it isn’t working. First, check the routing table. Do you still have a network? You can find out by issuing the command netstat -nr. If, in the Flag column, a U appears for all the interfaces in the Iface column, then you’re in luck—your network works. If not, you have a problem. You must check each interface and reinstall it using ifconfig and route or some similar tool.
Next, do a general packet check. This check will display general information in a list format as shown here:
Use netstat –s
Ip:
8285 total packets received
0 forwarded
0 incoming packets discarded
120 incoming packets delivered
8252 requests sent out
Icmp:
Tcp:
515 active connection openings
0 passive connection openings
0 failed connection attempts
0 connection resets received
0 connections established
8158 segments received
8120 segments sent out
117 segments retransmitted
39 bad segments received
150 resets sent
Udp:
Check the tcp section, and look at the segments’ received rates. If the rates are low, the problem could exist within your network, or maybe it’s just that you’re on a slow line. If there’s simply a lot of traffic, then you can tell your boss to send the e-mail later.
If the number of failed connection attempts is high, then your ISP is most likely causing the problem. You can reboot the computer if you're on a Microsoft network.
Rebooting on a Linux network is not necessary.
After this, you might try issuing netstat -i. I discussed this option in a previous section. You’d want to use this option to inspect the RX-OK, RX-ERR, RX-DRP, TX-OK, TX-ERR, and TX-DRP packet metric values. If RX/TX-ERR is near zero, then you’re in good shape. If the RX-ERR value is high, the problem is line speed, the ISP, or traffic. If the TX-ERR value is high, then the problem could be your network. You’ll need to clean the cables and check all the routes.
Where would you apply netstat? You’d use netstat on the main e-mail server or any server that uses the Internet heavily. It could be used on a LAN not connected to the Internet, but the traffic should be fairly constant. In that case, you’d then use netstat -n to check your UNIX connections. This will show which streams are connected.
whois
The whois tool will give you addresses and information related to an Internet address, which is useful for security purposes. You can use it as a first line of defense against crackers if you can get their ISP number. Then, you can call up the ISP and complain!
Use the following command at the prompt to invoke whois:
whois
For example, whois xoom.com yields the following information:
#whois xoom.com
[rs.internic.net]
Whois Server Version 1.1
Domain names in the .com, .net, and .org domains can now be
registered with many different competing registrars.
Go to http://www.internic.net for detailed information.
Domain Name: XOOM.COM
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: www.networksolutions.com
Name Server: NAME.PHX.FRONTIERNET.NET
Name Server: NAME.ROC.FRONTIERNET.NET
Name Server: NS1.XOOM.COM
Name Server: NS2.XOOM.COM
Name Server: NS3.XOOM.COM
This information isn’t too interesting in itself, but it’s also useful for the next network tool.
Why use whois?
If you suspect that your network is being hacked, whois can give you the name of the ISP or their main branch. This is the ethical reason for using this tool. Another use is to get information on computers that access your server.
Let’s suppose that weird_do.org hacked your system. If you type:
whois weird_do.org
you'll see something like this:
[rs.internic.net]
Whois Server Version 1.1
Domain names in .com, .net, and .org can now be
registered with many different competing registrars.
Go to http://www.internic.net for detailed information.
WEIRD_DO.ORG.TOM_GUN.ORG
WEIRD_DO.ORG
OR
Domain Name :WEIRD_DO.ORG
Registrar: TOM_GUN.ORG
Whois Server:whois.TOM_GUN.org
Referral Server:whois.TOM_GUN.org
Referral URL: www.TOM_GUN.org
Name Server:NS1.WEIRD_DO.ORG
Name Server: NS2:WEIRD_DO.ORG
Update Date: 23-july-1999
You can also use whois for purposes other than security. This is very similar to the previous example. For instance, the site oceania.org has a link that will tell you what server you’re using as the browser and your screen resolution. It’s obvious that they’re using whois in a creative fashion.
nslookup
Another major network tool is nslookup. You can use this tool to verify the operation of your name server; nslookup allows you to search for all kinds of data relating to a name server. You can look up mail records (MX), NS records (records associated with the root domain), and Start Of Authority (SOA) records, just to name a few. And, nslookup works in two modes: interactive and non-interactive. So, to get these records to appear, at the interactive prompt, you’d type set type=MX for mail records, followed by the name of the name server (yours or another company for which you’d like to see MX records). A good use of nslookup is on an e-mail server. If people can't send their e-mail, perhaps the server is offline. Invoke nslookup to check on the status of a remote e-mail server in general and to check the MX records in particular. Possibly the company is going through changes, which could cause e-mail problems on the client's end.
Let’s look at the interactive mode. There are many options for this command—too many to look at them all. The nslookup command-line form is:
nslookup [-option,,,] [host-to-find | [-server] ]
For example, invoking nslookup at the prompt yields the following:
> nslookup xoom.com
Server: g29-151.citenet.net
Address: 205.151.205.151
Non-authoritative answer:
Name: xoom.com
Address: 206.132.179.136
The non-authoritative answer means that xoom.com isn't the official domain name used for this server. If you type nslookup at the prompt, the following occurs:
> nslookup
Server: g29-151.citenet.net
Address: 205.151.205.151
At this prompt, you type in the domain name, and it will respond with the name and address.
Suppose you now want to look up MX records. At the nslookup prompt, you type >set type=MX:
>set type=MX
> xoom.com
Server: g29-151.citenet.net
Address: 205.151.205.151
xoom.com preference=10 mail exchanger=mail4.xoom.com
xoom.com preference=0 mail exchanger=mail1-mx2.xoom.com
xoom.com preference=0 mail exchanger=mail1-mx3.xoom.com
xoom.com nameserver=ns1.xoom.com
xoom.com nameserver=ns2.xoom.com
xoom.com nameserver=name.roc.globalcenter.net
xoom.com nameserver=name.pbx.globalcenter.net
mail4.xoom.com internet address=206.57.66.73
mail1-mx2.xoom.com internet address=206.57.66.72
One other interesting use of nslookup is to look up SOA records. Look at this example:
>set type=SOA
xoom.com
Server: g29-151.citenet.net
Address: 205.151.205.151
Non-authoritative answer:
origin=lugh.xoom.com
mail address=dns.xoom.com
serial=20000011300
refresh=10800
retry= 1800
expire= 604800
minimum ttl=3600
Authoritative answers can be found from:
xoom.com nameserver=ns1.xoom.com
xoom.com nameserver=ns2.xoom.com
xoom.com nameserver=name.roc.globalcenter.net
xoom.com nameserver=name.pbx.globalcenter.net
xoom.com nameserver=ns1.nuq1.gctr.net
ns1.xoom.com internet address=206.132.185.58
ns2.xoom.com internet address=206.132.185.59
name.roc.globalcenter.net internet address=206.130.187.10
name.pbx.globalcenter.net internet address=206.165.6.10
ns1.nuq1.gctr.net internet address=206.216.163.20.
Another interesting thing you can do is use the d2 option to print extensive debugging information about your network if it gets gummed up.
Why use nslookup
Why would you want to use nslookup? This tool checks to see if your domain name server is in working order. It’s also good for finding information on other domain name servers. In all, it’s an extremely versatile tool.
There is an interesting use of finger in nslookup. Once the host is defined, you can use finger to check to see whether certain users exist on that machine if a finger server exists on the remote machine to which you’re connecting.
For debugging your own server, you can use the d2 and debug options. In interactive mode, enter the following:
>set debug
>set d2
> xoom.com
Session looks like
;;res_nmkquery(QUERY,xoom.com,IN,A)
---------
SendRequest, len 26
HEADER:
opcode=QUERY,id=51423 rcode=NO ERROR
header:FLAGS, query:want recursion
questions= 1, answers=0, authority, records=0, additional=0
QUESTION:
xoom.com, type=A class=IN
----------
----------
Got answer (248 bytes)
opcode=QUERY,id=51423 rcode=NO ERROR
header:FLAGS, query:want recursion
questions= 1, answers=1, authority, records=5, additional=5
QUESTION:
xoom.com type=A class =IN
ANSWERS:
-> xoom.com
type=A class=IN, dlen=4
internet address=206.132.179.136
ttl:2488(41m28s)
AUTHORITY RECORDS:
-> xoom.com
type=NS,class=IN, dlen=6
nameserver=ns1.xoom.com
ttl=545(9m5s)
ADDITIONAL RECORDS
->ns1.xoom.com
type=A class=IN, dlen=4
internet address=206.132.185.59
ttl:145483
->name.roc.globalcenter.net
type=A class=IN, dlen=4
internet address=209.130.187.10
ttl:2488(41m28s)
-------------
Server:xoom.com
Address:206.132.179.136
---------------
If your name server is messed up, your report will look similar to the report shown above. This example is meant to be instructive (in case you’ve never seen what the debug information looks like).
Scenario
Back to the scenario where your boss is yelling at you because the e-mail server isn't working. You can enter the following at the prompt (let’s say that the name of your ISP is boring_biz.net):
>nslookup
>>set q=mx
mail1-mx1.boring_biz.net internet address=201.00.34.23
mail2-mx2.boring_biz.net internet address 201.01.35.24
>>set q=any
>>mail2
Server: boring_biz.net
Address: 200.00.22.21
If you get this response
mail2:can’t find 201.00.34.23: non-existent host/domain
then your network has problems!
Your next step is to check to see if your network is up. Go into nslookup again (I’m assuming you exited it), and type
>nslookup
>>set q=any
>>
You should see
Server :
Address:xxx.yyy.zzz.aaa
If not, you have a problem. If you do see it, then at the prompt run:
>>set q=mx
>>
You should see a listing something like this:
mail-mx1.
...
If not, there’s still a problem. Check the cables of your mail server or network card.
finger
The next tool is minor; finger has little use as far I can see. If you want to get the address or phone number of someone, then finger will be able to do it, assuming that you’re allowed access to the remote finger server.
The command-line structure of finger is
finger [-lmsp] [user...] [user@host...]
To best see how finger works, let's invoke it. At the prompt, type:
>finger –s
and you should see something like this:
Login Name Tty Idle Login Time Office Office Phone
kabir Larry Mintz 4 * Dec 24 20:46 (xxx)yyy-zzzz
Why use finger?
As far administration goes, finger doesn't really give much useful information. If you forgot the number of a user whose login name is hog, type:
>finger -s hog
which should report something like this:
Login Name tty idle login time Office Office #
hog Hoggish Greedly 3 * 9:15 WB34-1 666-6666
Conclusion
So many network tools exist to aid you in your network administration load. In this Daily Drill Down, I’ve shown how Linux (like UNIX) bears this weight with the help of a very powerful, yet simple-to-use set of network tools. These tools, ping, netstat, whois, nslookup, and finger, report a great deal of information to the administrator.
Larry Mintz is a Canadian citizen who does contract work on many levels. Larry holds a B.A. in mathematics from Concordia University, studies theoretical math, and has written solution manuals for many texts.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.Thanks : articles.techrepublic.com
ไม่มีความคิดเห็น:
แสดงความคิดเห็น