Checking the Connection

At the moment, we have DNS enabled for xenon only, so let's check that this works correctly before starting to reconfigure the remaining machines. We already know that the connection to the router is OK, but since we used an IP address rather than a host name, DNS wasn't required—we already knew the IP address, so didn't need to look it up. Now we will bring DNS into play to complete the test:

xenon# ping www.sun.com
www.sun.com is alive
xenon#

Good. DNS has managed to resolve the host name www.sun.com into the correct IP address and has successfully managed to ping it.

Nslookup

It's always nice when we can dig a little deeper into the details we are checking. For example, we don't really know that the nameserver was contacted—we certainly didn't see any communication with it. To see this sort of information we can use a program named nslookup. This is a utility that is able to carry out many DNS-related tasks, as we'll see later, but for now let's use it to confirm that DNS is working as we expect. The output below shows that our nameserver is able to determine the correct address of the system being queried:

xenon# nslookup www.sun.com
Server:  our.nameserver.com
Address:  172.35.63.2

Name:    www.sun.com
Address:  192.18.97.241
xenon#

Traceroute

We introduced traceroute earlier, but it is on this type of connection that this command really shines. Traceroute will detect the network routes that a machine takes to get to its destination, and also indicate if the machine is having problems along with the network that the problem lies with. For example, if we look at the route we took to get to the system above, we can see it is quite complex!

xenon# traceroute www.sun.com
traceroute to www.sun.com (192.18.97.241), 30 hops max, 40 byte packets
 1  192.18.95.200 (192.18.95.200)  1.133 ms  1.099 ms  0.924 ms
 2  gateway.sun.com (193.18.96.1)  1.519 ms  1.130 ms  0.981 ms
www.sun.com (192.18.97.241)  1.147 ms *  1.065 ms
xenon#

Traceroute also shows the time taken to reach the system. This helps us to spot any bottlenecks there may be along the way.

Ping

This is a useful, quick command to determine poor-performing networks. Running it with the “spray” option (or even running the spray command), we can see if packet loss is occurring, as well as approximate response times:

xenon# ping -s www.sun.com 64 5
PING www.sun.com: 64 data bytes
72 bytes from www.sun.com (192.18.97.241): icmp_seq=0. time=194. ms
72 bytes from www.sun.com (192.18.97.241): icmp_seq=1. time=193. ms
72 bytes from www.sun.com (192.18.97.241): icmp_seq=2. time=194. ms
72 bytes from www.sun.com (192.18.97.241): icmp_seq=3. time=193. ms
72 bytes from www.sun.com (192.18.97.241): icmp_seq=4. time=195. ms

----www.sun.com PING Statistics----
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 193/193/195
xenon#

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset