Simplified IP Addressing
Let's say you are granted a full Class C suite of addresses, e.g., 18.104.22.168 as your network address. You are allowed to assign the host addresses (the last byte) as you please. If you use the default Class C netmask of 255.255.255.0 (see Table 5), you can assign host addresses of 22.214.171.124 through 126.96.36.199 on a single network. That's feasible of course, but you may want to break this up into multiple networks of perhaps 25 hosts each.
Let's do some mathematics. If we have 4 bits for hosts, will it be enough? 2<+>4<+>-2 = 14 and is not enough. So, let's use 5 bits for hosts: 2<+>5<+>-2 = 30 which will work. However, we have 8 bits in the last byte for hosts, so let's borrow three bits for subnetworks; then we still have the requisite 5 bits for hosts. Great, but how many subnets do we have? How about 2<+>3<+> = 8? We have, then, eight subnetworks with 30 host addresses on each. If you are doing the math, you are probably saying, “but 8x30 is only 240 addresses; what happened to the others?” Valid question! Oops, don't get sore, but it's time to construct another table. Note that each address will have the form of 210.168.94.last byte, and the SNM (sub-netmask) will have the form 255.255.255.last byte. Let's just work with the last byte.
From Table 2 (or Table 1), we see the SNM will be 255.255.255.224. The 224 comes from the last byte being 11100000. So what are the subnets? Table 6 shows them (last byte only).
Let's detail a few. First, take the smallest. The full subnetwork address of the smallest is 188.8.131.52. The next one up is 184.108.40.206, and so on. Remember that with three bits to work with, we get 2<+>3<+> = 8 subnets, and looking at Table 6, you see them.
Back to the question of why we get only 240 host addresses. “(Gasp)—another table!” Looking at the last byte, we get Table 7.
Now let's answer the question of what happened to the other addresses. To do this, tally all the “invalid addresses”, i.e., those that can't be used for host addresses.
First, we have eight subnets, each with a subnetwork address and a broadcast address. So we lose 8*2 = 16 addresses here. Now if we subtract these 16 from 256, we get 240 available host addresses.
Doing it the other way is much easier. We have eight subnetworks, each with 30 valid IP addresses; this gives us 8*30=240 valid IP addresses total, the magic number.
For fun, let's do one more thing: analyze the sixth subnetwork in a little more detail. The last byte is 10100000 binary or 160 decimal. The full subnet address is 220.127.116.11 decimal, and we use an SNM of 255.255.255.224. Remember, I said to take the subnet address, set all the host bits to 1s and add them to get the broadcast address. If we do this correctly, it should give the same result as Table 7.
We use five bits for host addresses, so the decimal value of the sixth bit is 32. Subtracting 1 gives 31. Thus, setting the five host bits to 1s, i.e., 00011111, gives a value of 31 decimal. Adding this to the last byte of the subnet address (160) gives 191 for the broadcast address, agreeing with Table 7. Here is the “whole Megillah”:
18.104.22.168 The Sub-Network address22.214.171.124-190 Valid host addresses126.96.36.199 Directed Broadcast address
One final point. Some authors use the term “sub-netmask” even when referring to the default netmasks—they are being just a tad loose with their terms. Happy IP addressing, and remember, Linux is inevitable.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide