Consider this another installment in the endless series of "things that you need to know nowadays, but for which simplified and practical information isn't readily available."
Imagine a typical workday. You might enter the IP address of a Web-capable remote control in your browser. Up comes the remote screen. You might then type in "www.digikey.com" to look up some parts. (You'd never enter "youtube.com" or something like that, of course, because you're a conscientious employee who doesn't goof off. Ahem.)
Fig. 1: Typical IPCONFIG Results in Windows Have you ever wondered how the network knows whether an address is local or remote? How does it know that the remote control is on the local network, but that digikey.com's server isn't?
It's not just the fact that you've entered "www.digikey.com." If you enter the "raw" IP address yourself — 184.108.40.206 at this writing — you'll still go to their main page. Likewise, on some networks, you could enter a local specifier such as "//localserver//foldername" to connect in a file browser. The fact that you've used text instead of an IP address obviously doesn't tell the computer whether that address is local.
Understanding how computers find each other will aid in troubleshooting common network problems. Unfortu¬nate¬ly, most of the documentation for this falls into two categories: It's either way too detailed and geeky, or it's a joy-joy feel-good overview that doesn't really tell you anything.
I'll try to cover the key points. To keep this short and sweet, I'll focus exclusively on ARP, DNS and network routing with TCP/IP and IPv4 addresses. While more complex setups certainly are possible, the base example will be a local network that's based on a DSL router/modem for shared Internet access.
THE DOMAIN NAME SYSTEM (DNS)
You're familiar with this, so I'll only mention a few extras and highlights. In essence, DNS is what allows you to use an easy-to-remember name like "digikey.com" instead of the raw IP address. If DNS is working properly on your computer, you can use that text as a synonym for the IP address.
Many years ago, everyone had a file on his or her computer with a name like "hosts." This contained the mappings for host names to IP addresses (or whatever that particular network used). This legacy still lives with us. On a typical Windows system, see "/windows/system32/drivers/etc/hosts." On a 'nix system (including Linux), the file "/etc/hosts" is used.
What many network administrators don't know (or have forgotten nowadays) is that the computer usually refers to these files first, before querying DNS. If you were to put "digikey.com" in the host file with a made-up IP address, you could get an error in your Web browser when you tried to go to Digikey's site. Likewise, a Bad Guy (capitalized out of irreverence) might tamper with the "hosts" info to force someone to a bogus site. Some viruses have exploited this in the past.
IP ADDRESSES: NETMASKS, THE PREFIX AND THE HOST NUMBER
Fig. 2: Finding the DSL Modem at the Default Gateway Attempting to explain network masking in great detail requires converting to binary and using the logical "AND" function. Do a Web search on this for more info (put on your foil hat to protect your brain from implosion first). Again, I'll just hit the need-to-know highlights.
Standard 32-bit IPv4 addresses are written as a group of four octets, each representing a single 8-bit byte. Each octet can thus have a value from 0 to 255, which represents all "0's" or all "1's," respectively.
The 32-bit netmask, which is written the same way, is used to break this IP address into two parts: the prefix and the host number. Here's a typical example from a small Class C network.
This IP address refers to host number 200 on the subnet (network base) 192.168.1.0.
With the standard Class A, B and C netmasks — 255.0.0.0, 255.255.0.0 and 255.255.255.0, respectively — it's easy to understand what is going on:
- If there's a "255" in the netmask (all 1's in binary), the corresponding octet in the IP address is part of the prefix.
- The network base will be host number 0 and isn't directly addressable.
- The broadcast address is the last possible host number — 255 in this example. It's reserved for sending messages to all local hosts at the same time.
The above values can be calculated by your PC from its own IP address and the network mask. Once the calculation is complete, a simple rule is applied when you try to contact any other host. If the IP has the same prefix, it's considered part of the local network.
Unless you're doing some esoteric (read: weird) subnetting, all hosts on the same network should have the same network mask, or they'll calculate different values. If we were accidentally to configure this host with a Class B instead of Class C netmask, we'd get this result:
Fig. 3: Watching the Address Resolution Protocol in Wireshark You're now using the wrong broadcast and base addresses. This particular host won't work properly. Another fact that should be obvious is that all hosts on a local network should use the same prefix — 192.168.1 in this case.
Try this: Take two PCs and give them static IP addresses 192.168.1.100 and 192.168.2.101. Hook them together with two standard cables and a small network switch. Start a command prompt and use the "ping" command to see if they can communicate: for example, from 192.168.1.100, enter "ping 192.168.2.101." With a netmask of 255.255.255.0, the ping won't work. But if you change the netmask to 255.255.0.0 (meaning that prefix is only the first two octets), it will.
You might want to become familiar with so-called "classless inter-domain routing," or CIDR, notation. This is commonly used by Internet Service Providers when assigning a small block of static IP addresses. Basically, with CIDR notation, the base address is followed by a value that specifies the number of "1" bits in the netmask: for example, 192.168.1.0/24 for a standard Class C network. The "/24" means that there are 24 "1" bits in the mask, or
CIDR notation is possible because netmasks follow a simple rule: "1" bits are always written to the left, and any "0's" go to the right. You can't intersperse "1's" and "0's." There are CIDR calculators online that will derive these values for you. One good one is at http://grox.net/utils/whatmask/.
ARP — THE ADDRESS RESOLUTION PROTOCOL
OK, you've entered the IP address of that remote control in your browser. The netmask is applied and your PC determines that it's local. It now does what's called an ARP broadcast.
If you have a packet sniffer such as Wireshark on your computer, you can actually watch this process (see Fig. 3). In the illustration, I've pinged our mail server at local IP address 192.168.50.3; I'm at 192.168.50.101. My machine broadcasts a request to the entire network: "who has this IP?" The mail server responds with its MAC address (00:22:19:0b:b7:0f). Now the Ethernet hardware, which always communicates from MAC to MAC at the local level, knows where to reach the mail server. The ping works (see the lower half of the picture).
If no machine responds to an ARP after a timeout (typically 30 seconds), or if more than one responds, you get an error. Also, once your PC has done an ARP, it will cache the results for a time; you might not see what I've shown in Fig. 3 if you repeat the experiment. But now let's see how non-local addresses are handled, using a …
Adding a Static IP Address to an Unknown Network Most small networks nowadays use the Dynamic Host Configuration Protocol, DHCP, to allow users to connect on the fly. The computer sends a request to the DHCP server, which provides everything it needs to connect: an IP address, netmask, default gateway and the location of the DNS servers. An employee can bring in a new laptop, plug it in and start browsing the Web without having to worry about entering network details.
But you, on the other hand, may need those details! Two useful commands that every engineer should know are "ipconfig /all" for Windows and "ifconfig -a" for Linux and MacOS. You can use these at a command prompt or terminal window to obtain critical information.
Fig. 1 shows a typical result for Windows (the MAC address is referred to as the "Physical Address"). This particular machine has a statically assigned IP ("DHCP Enabled" returns "No"). The address is 100.100.150.230, with a netmask of 255.255.255.0 and a default gateway of 100.100.150.1. The IP addresses of the DNS servers are shown at the bottom of the image. Now suppose that you need a static, unchanging IP for a Web-capable remote control. You can't just make up a value, not even if it's in the correct subnet. Using Fig. 1 as an example, you can't just choose "100.100.150.123" off the top of your head. You have to choose a static IP address that isn't within the range that the DHCP server would assign.
How do you do this, especially on an unfamiliar network? With most small networks, particularly those with Internet access, the DHCP server is simply part of the modem/router. In that case, the default gateway address obtained from Fig. 1 should take us straight into that modem or router. Open a Web browser and enter the default gateway and you should see a configuration screen (see Fig. 2). If need be, find the owner's manual for the unit online and try the default login information; worst case, you'll have to reset the unit and start over, but at least you'll be in control from that point on. Look for the DHCP configuration screen. It will typically assign a range of IP addresses; in this case, from, say, 100.100.150.100–100.100.150.200. Pick an IP address that's not within that range for your remote control.
By the way, this would also be a great time to start a detailed record of assigned IPs, passwords and other key information. We use ordinary spreadsheet software for this.
You're almost there; you can now enter the network information in that remote control unit. Use the static IP address that you've chosen. The rest of the information comes from the "ipconfig" or "ifconfig" and "cat /etc/hosts" command(s) that you ran earlier — default gateway, netmask and DNS information. Test the remote control, confirm that you can get into it with your Web browser, and you're good to go! By definition, this is simply an interconnection between different networks (i.e., those with different prefixes). Very complex routing is possible with large networks (such as the Internet itself), which could have many gateways. But if any communication will be done beyond the local network, there will always be at least one default gateway to the outside world.
In a small Class C network anchored on a DSL router/modem, this is easy to follow. All addresses will either be local or on the Internet, so we only need one gateway to the outside world: the DSL modem itself! Its IP address is provided as the "default gateway" to all hosts on the local network that will require Internet access.
Now suppose you enter "www.digikey.com" in your Web browser. The browser will query DNS to obtain the IP address (you'll see something like, "looking up digikey.com" at the bottom of the browser window). Using the values from Fig. 1 for this example, a DNS query will go to 220.127.116.11, the first DNS server listed. This is a non-local address; the netmask is applied and your computer actually routes the DNS request itself through the default gateway. The distant DNS server (typically a machine at your local ISP) will respond with the IP address.
This is why, if your default gateway is set incorrectly, your browser will hang at "looking up digikey.com" and eventually time out with an error. If the first DNS server doesn't respond, a query could be sent to 18.104.22.168, the alternate.
Some DHCP servers return the default gateway address for DNS; this means that the DSL router/modem takes care of the lookup.
In any event, assuming success, Digikey's IP address is returned to your browser and it will attempt to establish a formal connection to Digikey's Web server. Once again, the netmask is applied. Your computer determines that it's a non-local address and sends the request to the default gateway. The router "marks" the packet (typically by using a unique port number), then sends the request out onto the Internet. Digikey's Web server responds and (assuming no errors, of course!) returns a Web page. The router sends the packet back to your PC and the page is displayed in your browser.
There are many details that I've left out. But this should get you started and you'll be able to troubleshoot common network complaints with this knowledge.
If you're not familiar with "ping," play with it and learn how it works. It's non-destructive, so you won't hurt anything. It does a basic, simple host-to-host "are you there?" communication that either works or doesn't. If it doesn't, check your network settings, then check your hardware (bad cable or bad card?).
But what this knowledge implies is perhaps more useful. If you want to stop a Windows machine from accessing the Internet, simply convert it to a static IP address, and then remove the default gateway and DNS information in the network settings. This won't stop a skilled hacker, but it will prevent an automatic update from trying to install itself right in the middle of drive time (!). Note that turning off Automatic Updates in your Windows' settings will not stop third-party programs from trying to update themselves automatically.
Plus, it will make it much more difficult for employees to browse the Web on that machine, possibly downloading a virus or other malware without your knowledge. That alone is worth the trouble, believe me!
Stephen Poole, CBRE, AMD, CBNT, is market chief engineer at Crawford Broadcasting Company. This story is based on an article that appeared in the Crawford Broadcasting Local Oscillator newsletter.