1. Home
  2. Training Library
  3. Cloud Computing Fundamentals
  4. Courses
  5. LPIC-1 102 Linux certification - Linux Networking (5 of 6)

Network Addressing Protocols

The course is part of this learning path

Contents

keyboard_tab
Course Introduction
1
Intro
PREVIEW48s
Troubleshooting
play-arrow
Network Addressing Protocols
Overview
Transcript
DifficultyIntermediate
Duration29m
Students619
Ratings
5/5
star star star star star

Description

With this fifth course in our Linux Server Professional LPIC-1 certification series, you will learn about network configuration and management, including the basics of TCP/IP, effective IP addressing, network protocols, and ports. You will also learn about how to properly set up DNS client services, aliases and hosts, and network interfaces using the ifconfig tool and its replacement, ip. Perhaps most important of all, you will discover some of Linux's powerful network troubleshooting tools, like netstat, netcat, and traceroute.

If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.

About the Author

Students16148
Courses17
Learning paths2

David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.

Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.

Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.

His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.

Covered Topics

Networking is about effectively identifying connected resources and controlling traffic between them, allowing what should be allowed and blocking what shouldn't. Without accurate identification, reliable communications and secure routing would, of course, be impossible. TCP/IP networks currently use one of two kinds of IP addresses for this identification, IPv4 and IPv6. IPv4 addresses, which are written in four numeric octets, each made up of numbers between 0 and 255, are divided into two sections, networks and nodes. The network section defines the address ranges a given network has available for individual devices like computers or smartphones, while the nodes section contains the endpoint addresses for these devices.

Since IP addresses can have different combinations of networks and nodes, we use network masks to communicate the format we're using. Let me explain using an example. Here's a sample IPv4 address.

Network addressing with IPv4 IPs

Let's say that the first three octets, whose current values are 192, 168, and 0, are all going to be network addresses. And the final octet, the 1, is for nodes. This means that the network or, more accurately, the subnet, identified as 192.168.0 can have a theoretical maximum of 256 devices attached to it: 192.168.0.1, 192.168.0.2, 192.168.0.3 etc., all the way to 254 since 0 and 255 are normally reserved addresses.

Similarly, we could use 19.168.1 as an entirely different subnet able to assign device addresses between 192.168.1.1 and 192.168.1.254. The netmask to identify such a three-octet network will be 255.255.255.0. A zero always represents network nodes, while the 255s are notations representing networks. If we wanted to use only two octets as network addresses leaving the other two for network nodes, we would use a netmask of 255.255.0.0. This would allow more that 65,000 possible device addresses. That's 256 squared, but limit us to only 65,000 possible subnets. Another way of describing such a network using CIDR, Classless Inter-Domain Routing notation, will be to add a slash 16 to the end of the address. In other words, keeping in mind that each octet is made up of 8 bits, 16 of the 32 total bits available will be network addresses, and 16 will be nodes.

Our earlier example, 255.255.255.0 could similarly be described as 192.168.0.0/24. To make it just a bit more complicated, you can also reserve only part of an octet for network addresses. Suppose you know that you'll never have more than a few devices attached to each of your subnets and you'd like to keep your options open for as many subnets as possible, you might want to reserve only, say, 128 nodes. In that case, you could define your subnet as 192.168.0.0/28, where 28 is four bits higher than 24 and four lower than 32.

Incidentally, you can Google subnet calculator for helping figuring out the proper CIDR settings for your network.

Even though mathematically there are more than four billion usable IPv4 addresses available, the many billions of Internet-connected devices would by now have long exhausted the supply. The protocol that has kept us going for the past couple of decades of growth is the reserving of these three address ranges for private networks using NAT, Network Address Translation. NAT allows port forwarding of a single public facing IP address to be used to route incoming and outgoing traffic to many thousands of local devices that individually have no public face at all. Addresses within these three private ranges cannot be reached from the Internet, but they can be reused simultaneously within millions of private networks that don't communicate directly with each other. IPv4 addresses are divided into classes. The value of the first octet of all Class A addresses will lie between 1 and 127. Class B addresses are between 128 and 191, and Class C falls between 192 and 223. If you're still awake at this point, you'll have noticed two interesting things. One, that those classes don't cover the values between 224 and 256. This is because addresses above 223 are part of Class D and E ranges, which serve other functions. And two, that each of our three private NAT address ranges falls within a different one of the first three classes. I'm sure that there's some very good architectural reason for this, but I'm afraid it's beyond me.

Network addressing with IPv6 IPs

There's a second solution to the problem of the diminishing supply of IPv4 addresses, IPv6. While IPv4 addresses are 32-bit, meaning they're made up of four 8-bit octets, IPv6 addresses are 128-bit, meaning that there are two to the 128 possible addresses - enough to keep us going for a very long time. Once IPv6 is fully implemented, there'll be no need for NAT addressing and avoiding address conflicts will be much simpler.

An IPv6 address is made up of eight hexadecimal numbers separated by colons. Multiple fields equaling zero can be represented by double colons. Therefore an address like this one could also be written this way.

Let's review. IPv4 addresses consist of four octets divided between network addresses and device nodes. The netmask or the CIDR slash notation tells routing software which octets are for networks and which are for individual devices. You can reserve only some addresses within an octet for networks. Private net networks allowed no direct access to the Internet but have addresses in three ranges reserved for them. IPv6 addresses contain 32 bits in eight fields of hexadecimal numbers and therefore promise a virtually unlimited number of unique addresses.