soundtraining.net website links

Sunday, February 23, 2014

What is a Default Gateway?

If you're new to networking, you've probably heard the term default gateway and wondered what it meant. You see it in the IP address configuration on hosts and routers, but what does it do?

The default gateway, also known as simply the gatewaythe default route, and on Cisco routers as the gateway of last resort, is the path packets use when there is no explicit route to a destination. Without a default gateway, each host would have to have a routing table containing explicit paths to every host on the Internet, an absurd and unworkable solution. When we configure a default gateway, we're saying to the host, "If you don't know what else to do with a packet, send it to the default gateway and let the gateway figure out what to do with the packet."

In order for a host's default gateway to work, there are certain criteria that must be met:
  • It must be an interface on a network already known to the host (If it's not known to the host, how will the host know how to get the packets to the gateway?)
  • It must be an interface on a device connected to the rest of the world, usually the public Internet.
Consider this diagram in which the three computers connected to the Cisco ASA use the ASA's inside interface as their gateway. The ASA then uses the ISP's router as its gateway.
In the above scenario, suppose the top laptop wants to visit a website, say www.soundtraining.net. It probably doesn't have an explicit route in its local routing table for www.soundtraining.net's IP address, so it hands the request off to its default gateway, the ASA. The ASA also doesn't have an explicit route in its routing table for www.soundtraining.net's IP address so it hands the packet off to its default gateway, which is the ISP's router. The process may be repeated through several routers before the packet finally arrives at its destination. You can see the entire process by using the command traceroute www.soundtraining.net in a terminal window.

One word of caution, on hosts with multiple interfaces, you can sometimes end up with multiple default gateways which can produce unpredictable results. Generally, you want only one default gateway configured per device, regardless of the number of interfaces on the device.

For More Resources for I.T. Pros

You'll find books on Cisco and Linux technologies at my bookstore at soundtraining.net/bookstore. Also, check out my video channel at soundtraining.net/videos.

Please Leave a Comment

If you find this networking tutorial helpful or if you notice something that needs to be corrected, please leave a comment.

Monday, December 23, 2013

Basic DNS Client Troubleshooting or How to Solve Name Resolution Problems

Sometimes, the network is up, all the link lights are on, pings by IP address work fine, but you still can't connect to a website. A likely culprit is name resolution.

The Name Resolution Process

Suppose you need to connect to www.soundtraining.net. Here's what happens when you type that URL into your browser:
  • Your computer has to find a way to associate www.soundtraining.net with an IP address. It's a lot like looking up a phone number in an old-fashioned phone book.
  • In the early days of the Internet, every host had a hosts file which held the hostname-to-IP address mapping for every host on the Internet. Although most systems today use DNS, all computers still contain a hosts file which usually takes precedence over other name resolution methods. On computers running modern Windows operating systems such as Windows 7 or 8, the hosts file is located in c:\windows\system32\drivers\etc.
  • Most computers maintain a local DNS cache containing the hostname-to-IP address mappings from previous lookups. A computer first checks its DNS cache to see if there's an entry for it from a previous connection attempt or from a static entry in the hosts file. (Computers running modern versions of the Windows operating system pre-load entries from hosts files into the DNS cache. Other operating systems may handle hosts file entries differently.)  On computers running the Windows operating system, you can view the contents of the DNS cache with the command ipconfig /displaydns. (Hint: You can filter the output using PowerShell's select-string capability. For example, the output of ipconfig /displaydns can get pretty lengthy. If you want to check for the existence of a particular text string, such as soundtraining.net, use the following syntax in PowerShell:
    ipconfig /displaydns | select-string -pattern "soundtraining.net".)
  • If the requested hostname doesn't exist in the DNS cache, the DNS resolver (the client) queries DNS servers in the order listed in the computer's configuration.
  • If the DNS server(s) is not reachable or can't resolve the hostname to an IP address, an error is returned.

Troubleshooting DNS and Name Resolution

Here are some steps to help you perform basic troubleshooting of name resolution issues.
  1. Confirm that name resolution is the issue by pinging the target host first by hostname, such as www.soundtraining.net, then by IP address. If the ping by hostname fails, but the ping by IP address is successful, the problem is most likely a name resolution issue.
  2. Determine the scope of the issue. If local name resolution works, but Internet name resolution doesn't, the problem is most likely with the service provider's DNS server. Try changing to the Google DNS servers (8.8.8.8 or 8.8.4.4) or OpenDNS servers (208.67.222.222 and 208.67.220.220) as a way of testing. If, on the other hand, Internet name resolution works, but local resolution doesn't the problem is most likely on the local DNS server.
  3. Check the TCP/IP settings on the local computer. If the problem exists on only a single computer, check its TCP/IP settings.
  4. Use the nslookup tool (it's included with most operating systems) to test connectivity with a DNS server. It's a powerful tool with many options, but it can also be used to perform a simple DNS query using the following syntax:
    nslookup soundtraining.net
    A simple query such as this will tell you whether name resolution is working at all and, if it is, which DNS server is being queried first. If nslookup returns an error stating that the server can't be reached, check for connectivity issues with the DNS server. If it returns an error stating that the domain or host doesn't exist, there's a problem with the DNS server configuration. If it returns what you believe to be a correct response, the problem may be an incorrect entry in the DNS cache or even an incorrectly configured hosts file.
  5. Check to see how widespread the problem is. If it's just users on a single subnet, it could be a misconfigured DHCP server providing incorrect IP settings.
  6. Check for malicious software. If the user is being directed to questionable websites, their computer may have been compromised with software that intercepts name resolution requests and redirects them to undesirable websites.
  7. Check the DNS cache with the command ipconfig /displaydns for incorrect entries or just do a precautionary clearing of the DNS cache with the command ipconfig /flushdns (administrator privileges are required to clear the DNS cache).
  8. Check for an incorrect entry in the hosts file. (This is not very likely, but it has happened to me when I made changes in the hosts file for testing purposes and forgot to change it back.)
  9. Try a reboot. As with most things digital, sometimes the problem can't be identified, but it can be solved with a reboot. This is especially true if you're using consumer grade routers that act as DNS forwarders, which is most of them. Just power-cycle the router or DNS server to see if the problem goes away.

DNS Troubleshooting Tools

The following tools and websites may also be helpful in name resolution troubleshooting.
BIND is the most commonly used DNS server. A download of BIND includes the dig utility which provides similar functionality to nslookup. You can download BIND from http://www.isc.org/downloads/.

For More Resources for I.T. Pros

You'll find books on Cisco and Linux technologies at my bookstore at soundtraining.net/bookstore. Also, check out my video channel at soundtraining.net/videos.

Please Leave a Comment

If you find this tutorial helpful or if you notice something that needs to be corrected, please leave a comment.

Wednesday, December 4, 2013

The Beginning Network Admin's Network Troubleshooting Checklist

I've recently been asked to work with groups of non-network admins to help them understand the basics of computer networks. Each of the groups has, as part of their jobs, installation of proprietary systems that must integrate with existing computer networks. None of the people in these classes is ever going to use tools like Fluke network testers or similar tools. They simply need to be able to install their software or hardware and do basic network troubleshooting. If that sounds like your situation, or if you're a new network administrator, here is a simple, ten-step checklist for network troubleshooting. It should be helpful for both beginning network administrators and non-network admins, too.
  1. Do a quick check of the rest of the network. Before you start running all kinds of tests on your system, check to make sure the rest of the network is functioning properly. Are other people or systems on the network having the same or similar problems as you? The problem may have nothing to do with your system or configuration.
  2. Gather information. What has changed since things were working properly? Has any new software been installed? Has any new hardware been installed? What settings may have been changed, either by you, another administrator, a vendor, or an end user? Have there been any power outages? Have there been any maintenance crews doing work which involved moving network equipment? Ask end users what was being done at the time of the failure. (Be careful not to be accusatory when asking questions like this. You want to get honest, helpful answers. You don't want people to get defensive or try to hide things.)
  3. Start at the physical layer. Check link lights, power cables, circuit breakers, cables, heat and dust (too much of either will down any electronic device including routers, switches, access points, firewalls, and servers). You can purchase an inexpensive cable tester for around $40.00. Such testers can be helpful, but if you don't have one, test a cable by replacing a known working cable with the cable in question. If it works with the first cable, but not the second, you've identified the problem. Make sure network cards are enabled. Check in the network settings on each affected device to ensure that network cards are enabled and active.
  4. Use ping, tracert (traceroute in Unix/Linux/Cisco), and pathping to test connectivity. Use ping within a single IP subnet and tracert or pathping when multiple IP subnets are involved. Here's how to use ping: Start by pinging your localhost (ping localhost or ping 127.0.0.1), then ping the IP address of the system you're working on, then ping another host on the same subnet, then ping the default gateway, and finally ping a remote system on another subnet. If all of the pings work except the remote system, try using tracert or pathping to see where connectivity fails. Try a ping by hostname instead of IP address. If a ping by hostname doesn't work, but a ping by IP address does work, the problem is most likely related to name resolution. See my post on DNS client troubleshooting.
  5. Check the routing table. If pings to systems on different networks fail, check the routing table for explicit entries, the correct default gateway, or duplicate default gateways (there should be only one). On a Windows computer, use the command route print to see the routing table. On a Cisco router, use the command show ip route.
  6. Check IP address settings. Use the Windows command line utility ipconfig to make sure the IP address is what you expect.
  7. Check for problems with MTU size. Use the mturoute tool to check MTU sizes on the network.
  8. Check for DHCP server connectivity. If you see an address starting with 169.254, that's an indication that the device or system could not reach a DHCP server to get an IP address.
  9. Is the IP address on the correct network? Check to ensure that the IP address of the device is on the same network or subnet as the rest of the devices. (If the subnet mask is 255.255.255.0 or /24, check to ensure that the first three octets of each of the connected devices match.)
  10. Check for a firewall blocking traffic. If you can ping out from a device, but not to the device, a likely culprit is a firewall on the device. Check the security settings. If the Windows firewall is disabled, check to see if a third-party firewall is enabled such as ZoneAlarm or Norton Internet Security. I once was stymied in troubleshooting by a surprise firewall that was included with a VPN client, so check for any other security-oriented software that might include a firewall.
Most network administrators have plenty of stories about forehead-slapping moments in troubleshooting when they missed something obvious. By following the above steps, hopefully you'll avoid flattening your forehead.

For More Resources for I.T. Pros

You'll find books on Cisco and Linux technologies at my bookstore at soundtraining.net/bookstore. Also, check out my video channel at soundtraining.net/videos.

Please Leave a Comment

If you find this networking tutorial helpful or if you notice something that needs to be corrected, please leave a comment.

Tuesday, July 2, 2013

How to Change an Ubuntu Server from DHCP-Assigned IP Address to Static IP Address


I noticed, while perusing a variety of blog posts related to Ubuntu server configuration, that none of them completely covered the necessary steps in changing the server's IP address from one assigned by DHCP to one configured statically. This blog post will explain how to do it, along with several follow-up steps that seem to be missing from other posts.

For this post, I used Ubuntu Server version 12.04.

It's common practice for servers to be configured with static IP addresses, so if your Ubuntu server is currently configured to receive its IP address from a DHCP server, you probably want to change it to use a static (manually configured) IP address.

There are four steps:
  • Use a text editor to modify /etc/network/interfaces
  • Restart networking
  • Verify the change to the IP address and the DNS client
  • Disable the DHCP client, if desired

Companion Video

I created a video demonstrating the process, in case you prefer to watch a video instead of reading the steps.

Configuration Steps

Modify /etc/network/interfaces

Use the following command to open /etc/network/interfaces for editing:
sudo vi /etc/network/interfaces
It's certainly not required for you to use the vi text editor, but it's my preference. Any text editor will work.
Under primary network interface, change static to dhcp and add the desired address, mask, gateway, DNS server(s), and DNS default search domain. In the example, the server's IP address is 192.168.1.4 with a 24-bit mask, the gateway is at 192.168.1.1, the IP addresses for the DNS servers are the OpenDNS servers, and the default search domain is soundtraining.net. Presumably, you'll use different addresses that appropriate for your environment.
When you're finished, the file should look similar to this:
How to configure a static IP address on Ubuntu server

Restart Networking

Use the following command to restart networking:
sudo service network-interface restart INTERFACE=eth0

Verify the Changed Configuration

Use the ifconfig command to verify the changed configuration.
Also, view the contents of /etc/resolv.conf to verify that it picked up the DNS configuration from the configuration changes. It should look similar to this:
Notice that the DHCP-assigned DNS server is still listed. That's because the DHCP client is still running.

Disable the DHCP Client

It's not required to disable the DHCP client and, in fact, you may want to have the DHCP server supply additional DNS servers. If, however, you want to, you can disable the DHCP client (dhclient), if desired, with the dhclient -r command. It's usually a good idea to restart networking after making changes like this:
sudo service network-interface restart INTERFACE=eth0

For More Information

Pick up a copy of either of my Linux books. If you're working with Red Hat-based operating systems such as RHEL, Fedora, or CentOS, The Accidental Administrator: Linux Server Step-by-Step Configuration Guide is designed to take you from initial installation through various types of server configurations. My other Linux book is Tweeting Linux: 140 Linux Configuration Commands Explained in 140 Characters or Less, a Linux command reference for people who want concise explanations of various Linux commands. Tweeting Linux is applicable to Red Hat, Ubuntu, and Debian-based systems.

Tuesday, June 25, 2013

Another name change?

I'm changing the name of this blog to make it more accurately reflect its technical nature and to tie it in more closely with my series of tech books called The Accidental Administrator. From now on, this blog will be known as The Accidental Administrator and I've shifted the name The Compassionate Geek to my new blog on customer service and communication for technical staff. I don't think it's that big a deal, but if you notice and wonder, now you know.

Thanks for reading and following my blogs.

Tuesday, June 11, 2013

Network Troubleshooting Tools

Can you have too many network troubleshooting tools? I think not. Here's a blog post by Jack Wallen, one of my favorite tech bloggers, over at Tech Republic listing five network troubleshooting tools. The only one I already knew about is DNS Stuff, which is great. I'll be trying the others out shortly. http://www.techrepublic.com/blog/five-apps/five-web-based-network-troubleshooting-tools/1881

Thursday, June 6, 2013

Cisco IOS CLI Shortcuts

If you spend a lot of time working in the Cisco command line, a solid knowledge of CLI shortcuts can save you a ton of time. I was going to write a blog post showing you the various shortcuts, but then I found a blog by Greg Ferro with a comprehensive list of shortcuts, nicely formatted. Here's the link:  http://etherealmind.com/cisco-ios-cli-shortcuts/
Do yourself a favor and print out the list and tape it to your monitor! (Thanks, Greg.)