Discovering the principles behind IPv4 addresses requires setting up a minimal network architecture to serve as a basis for a few experiments.
Here is the diagram of the architecture that you will build:
        

In a terminal on your host system, enter the command s7nsa_hub_switch.py h:9991 h:9992 and leave this terminal open.
You have just created the two virtual hubs shown in the diagram✍.
The numbers associated with them do not correspond to anything in practice; they can be regarded as labels attached to the casing of these devices to distinguish them.

In another terminal on your host system, enter the following commands, taking care not to swap the arguments✍: In the terminal that was used to create the hubs, enter the command list and verify that each of the two hubs is indeed connected to three cables, as shown in the diagram.
Note that the dotted lines in the diagram suggest that it would be possible to connect many more devices to these hubs.
Log in to the root account (with the s7nsa password) of each of these five virtual machines and, on each of them, enter the command ip addr.
You should find the network interfaces named eth0 or eth1✍ as shown in the diagram: B1, C1, B2, and C2 each have an eth0 interface, while A1A2 has the eth0 and eth1 interfaces.

Also note that all these machines have an additional interface named lo: the “loopback” interface.
In general, network devices designed to use IP addresses include such an interface, which is not connected to any other device and is configured as 127.0.0.1/8.
The “loopback” interface is used to allow applications on a single machine to communicate with each other as though they were interacting remotely over the network; they refer to each other using the address 127.0.0.1, which corresponds to the local machine.
Using the command ping 127.0.0.1, you should observe that each system responds to itself; stop this command with the Ctrl c key combination.

The ip addr command showed that, unlike the lo interface, none of the eth0 or eth1 network interfaces on your machines had yet been assigned an IP address.
On your A1A2 machine, configure the eth0 and eth1 network interfaces as follows✍: Immediately check with ip addr that the addresses chosen in the diagram have been correctly assigned to the interfaces.
Use the same approach to configure: and verify with ip addr that all these interfaces are configured according to the diagram.
Note that IPv4 addresses are 32 bits long and are usually represented using dotted decimal notation (each byte is expressed in decimal and dots separate them).
The /24 notation that follows these addresses will be explained later.

From the C1 machine, use ping 192.168.10.3 to verify that it responds to itself using the address that has just been assigned to it✍.
Then use ping 192.168.10.2 and ping 192.168.10.1 to verify that the three IP addresses assigned to the devices connected to hub 9991 can all reach each other.
Use a similar approach to verify connectivity between the three addresses assigned to the devices connected to hub 9992.

You have just observed that the addresses assigned to the devices connected to the same hub can communicate with each other.
However, the addresses were chosen rather freely when creating the diagram, and nothing yet explains how signals travel through the cables and find the correct destination.
This is what you are about to discover here.

From the C1 machine, contact the A1A2 machine using ping 192.168.10.1.
While the previous command is running, on the B1 machine use the command tcpdump -eni eth0 in order to listen to all the network frames that reach the eth0 network interface of this machine and display a summary of them.
You can stop the ping command once several frames have been displayed.

Among the information to observe, you should first notice that the timestamp at the beginning of each line shows that these frames come in pairs: every second one frame is transmitted and another follows immediately afterwards.
The first of these two frames contains an “ICMP echo request” packet originating from the IP address of the eth0 interface on C1; it is generated by the ping command.
The second of these two frames contains an “ICMP echo reply” packet originating from the IP address of the eth0 interface on A1A2; it is generated by the operating system of A1A2 in response to the previous frame.

Immediately after the timestamp, the lines in the capture contain information in the form ss:ss:ss:ss:ss:ss > dd:dd:dd:dd:dd:dd.
This represents the source and destination MAC addresses of the captured frame.
Unlike IP addresses, which were chosen more or less freely during configuration, these MAC addresses are assigned once and for all when each network interface is manufactured by its manufacturer.
A MAC address is made of six bytes (usually written in hexadecimal) and is intended to be globally unique, so that if several devices were connected to the same hub or switch, they would not share the same MAC address✍.
The first three bytes of a MAC address identify the manufacturer of the network interface, according to the OUI list, while the last three are assigned freely by the manufacturer (avoiding duplicates).

Use ip addr on C1 and A1A2 to verify that the MAC addresses shown correspond to the frames displayed by tcpdump on B1.
This illustrates the principle of network protocol encapsulation✍: IP packets are encapsulated within MAC frames.
When the IP address 192.168.10.3 (C1) attempts to contact the IP address 192.168.10.1 (A1A2): Communication based on MAC frames relies on the principle that such a frame transmitted over a cable may be relayed (via a hub or a switch) to every network interface that could potentially have the targeted MAC address.
Among all these interfaces, the one that was actually addressed will process the contents of the frame, while the others will simply ignore it.

However, one point still needs to be clarified.
When using the ping command on C1, the source MAC address is easily known because it is that of the eth0 interface on this machine.
But the destination is only specified as an IP address in the command line; its MAC address is not provided.
How then does the operating system on C1 know the destination MAC address (that of the eth0 interface on A1A2) for the frame about to be emitted?

On the C1 and A1A2 machines, use the ip neigh command to display the ARP table.
You should observe that, for each machine with which either of these has already communicated, an entry shows the mapping between the peer's IP and MAC addresses.
This is consistent with the operation studied previously, since the system simply has to consult this table when transmitting a frame, but it still remains to understand how these MAC addresses were discovered before being added to this table.

On the C1 and A1A2 machines, use the ip neigh flush dev eth0 command to clear the ARP table; verify with ip neigh that the previously recorded MAC addresses have disappeared.
Make sure that the B1 machine is still capturing frames with tcpdump -eni eth0.
From C1, perform just two exchanges with A1A2 using ping -c2 192.168.10.1.
The capture on B1 should reveal six frames: The first two frames are the ones that populate the ARP tables: Verify with ip neigh that the ARP tables of C1 and A1A2 have indeed been populated again.
Then, each operating system only needs to consult its table when required, without having to issue further ARP requests for hosts that are already known✍.

Of course, the investigations carried out here around hub 9991, to illustrate the communication mechanisms within a single local subnet, can be carried out in a similar way around hub 9992.

It has already been mentioned that hubs and switches provide more or less the same service, but with some differences.
To observe this, return to the terminal in which the hub emulation tool is running and enter the command switch 9991 9992 to transform the two existing hubs into switches✍.
Immediately check the status of these two devices with the list command; they are now two switches, each still connected to three devices.
Also note that, following the various communications already performed, the source MAC addresses of the frames received on the different ports provide information about the MAC addresses of the connected interfaces.

Resume the ping 192.168.10.1 command on C1 while capturing traffic on B1 with tcpdump -eni eth0.
Observe that the exchanges do take place, but that B1 captures nothing.
If you capture the frames on A1A2 with tcpdump -eni eth0, you will observe that the frames are still being transmitted, but only over the cables connecting the two communicating hosts.
This is the key difference between a hub and a switch: To be able to make this decision, the switch learns the topology of the surrounding devices.
Whenever a frame arrives on one of its ports, it records the source MAC address as being reachable through that port, so that any future frame destined for that same address will be forwarded only to that port.
Of course, when first powered on, a switch does not yet know its environment; if it has to forward a frame to a MAC address that it has not yet learned, it will flood it out of all ports.
However, once a certain amount of traffic has been exchanged, this mapping becomes complete.
After that, only frames broadcast to ff:ff:ff:ff:ff:ff are, by definition, forwarded to all ports.

It is now almost impossible to find a hub device (except perhaps at a flea market or in the back of an old network engineer's drawer).
Indeed, these devices are considered obsolete compared with switches because traffic on a hub systematically occupies every link, increasing the likelihood of collisions between frames and therefore reducing the efficiency of network traffic.
With a switch, on the other hand, several exchanges can take place simultaneously, provided they do not use the same links.
The improvement in efficiency is even more significant when multiple hubs or switches are interconnected to connect a large number of devices.
Although hubs are suboptimal, they remain useful for troubleshooting; simply place one between several devices to monitor the traffic (just as B1 was listening to the exchanges between C1 and A1A2).
However, you should certainly NOT assume that switches are security devices, by making traffic harder to intercept; this will be covered in this tutorial.

Until now, the communications considered involved: At no point did an address of the form 192.168.10.? attempt to reach an address of the form 192.168.20.? (or vice versa).

Before considering these new communications, first set up packet captures with tcpdump -eni eth0 on both C1 and C2.
From A1A2, then use ping -c2 192.168.10.3 to communicate with C1, followed by ping -c2 192.168.20.3 to communicate with C2.
Carefully observe the source IP addresses of the “ICMP echo request” packets captured in both cases.
You should find that, depending on the destination address, the A1A2 machine decides to identify itself using one IP address or the other (even though it has both).

To understand this choice, use the ip route command on A1A2; this is its routing table.
It indicates that all addresses of the form 192.168.10.0/24 are directly reachable via the eth0 interface, and likewise that addresses of the form 192.168.20.0/24 are reachable via the eth1 interface.
Such notations, also shown on the diagram at the beginning of this tutorial, mean “all IP addresses that produce 192.168.10.0 (respectively 192.168.20.0) when they are masked with the first 24 bits set to 1” (and the remaining 8 bits set to 0, since IPv4 addresses are 32 bits long)✍.

When A1A2 attempts to reach 192.168.10.3, the first entry in the routing table suggests combining this address with a 24-bit mask to check whether the result is indeed 192.168.10.0.
Since this is the case, that entry is selected and indicates that the eth0 interface should be used to reach this destination; the source address of the transmitted IP packet will therefore be that of this interface (192.168.10.1).
When A1A2 attempts to reach 192.168.20.3, combining this address with a 24-bit mask does not produce 192.168.10.0; the first entry in the routing table is therefore not applicable.
However, there is a second entry✍ that again suggests combining the destination address with a 24-bit mask, and this time the result is indeed 192.168.20.0; this entry is therefore selected and indicates that the eth1 interface should be used to reach this destination.
The source address of the transmitted IP packet will therefore be that of this interface (192.168.20.1).

These two entries in the routing table were not entered manually but automatically.
Indeed, the eth0 interface is configured with 192.168.10.1/24: an IP address and its associated subnet mask.
This mask indicates that the interface is connected to a subnet in which all IP addresses share the same first 24 bits as this address, that is, the 192.168.10.0/24 subnet, which is automatically added to the routing table.
The same applies to the eth1 interface, configured with 192.168.20.1/24, which belongs to the 192.168.20.0/24 subnet.
It is therefore very important to follow this rule: all IP addresses within the same subnet must be associated with the same subnet mask and must be identical for all the bits covered by that mask.

It is very common to use the notation expressing the length of the mask (24 bits in this case); however, some devices require the mask to be written explicitly as an IP address (255.255.255.0 is equivalent to the /24 notation).
It is very common to choose masks that end on a byte boundary (/16 or /24, for example), but this is not mandatory at all; it simply makes them easier to read and the calculations easier to perform (exercises illustrating this are provided later on).

A subnet is generally implemented using a switch✍, or several interconnected switches to provide more ports: this is known as a broadcast domain.
Indeed, all the interfaces that make up the subnet are expected to participate in the ARP protocol (studied earlier); an ARP request relies on the broadcasting of a frame to reach all the interfaces within such a subnet.

Use the ip route command on the B1, B2, C1 and C2 machines; the routing tables in question contain only a single entry, since only one network interface is configured.
From C1, then try ping 192.168.10.4: this address has not been assigned, but in theory it could belong to C1's subnet.
You should find that the command attempts to reach this address but receives no reply.
Still from C1, now try ping 192.168.20.1 and observe the immediate failure, without any attempt being made; indeed, C1's routing table can only reach addresses in the 192.168.10.0/24 subnet.
Complete the network configuration of C1 as follows✍: Check the updated state of the routing table using ip route.
You have just completed it by a route indicating that the 192.168.20.0/24 subnet can now be reached provided that traffic first passes through the 192.168.10.1 gateway, which is itself directly reachable.
Try ping 192.168.20.1 again from C1 and observe that you now receive a reply.
While capturing traffic on A1A2 with tcpdump -eni eth0, you should observe that the frames intended for 192.168.20.1 are addressed to the MAC address corresponding to 192.168.10.1, rather than to the one corresponding to the destination IP address.
This is indeed a phenomenon that is characteristic of routing.

In theory, with the explicit routing rule, C1 should also be able to reach B2 and C2.
However, ping 192.168.20.3 from C1 does not receive a reply.
On A1A2, use tcpdump -eni eth0 to verify that the IP packet does indeed arrive on this interface.
Then use tcpdump -eni eth1 and observe that this packet is not forwarded out through the other interface.
Indeed, by default, when network devices receive an IP packet that is not addressed to them, they simply ignore it.
A1A2 replied earlier because 192.168.20.1 is one of its own addresses, but this is not the case for 192.168.20.3.
Complete the network configuration of A1A2 as follows✍: This setting tells the A1A2 system that it should behave as a router; from now on, it must make the effort to forward IP packets that are not addressed to it directly, applying the same routing decisions as if it were the sender of the packet.
Observe that the “ICMP echo request” packet is now correctly retransmitted via the eth1 interface towards C2; however, there is still no reply.

For C2 to be able to reply to C1, it must know a route that allows it to do so.
Complete the network configuration of C2 as follows✍: Check the updated state of C2's routing table with ip route.
From now on, the ping 192.168.20.3 command from C1 should receive a reply.

Of course, for the situation to be complete, the same procedure must be applied to all the remaining machines.
Complete the network configuration of B1 as follows✍: Check the updated state of B1's routing table with ip route.
Complete the network configuration of B2 as follows✍: Check the updated state of B2's routing table with ip route.
Check that, from now on, each of your machines is able to reach any other machine.

This section presents a few exercises to practise the common calculations involving IPv4 addresses and their associated masks.
The practical applications concern subnet sizing and troubleshooting when investigating problematic situations (whether hosts should be reachable or not, whether routing is required or not, etc.).

You have already seen that IPv4 addresses consist of 32 bits and are associated with a subnet mask.
This subnet mask consists of two parts: If N is the length of the mask, then there are 2^32-N possible combinations for the free bits (for example, for /24, this gives 256 combinations).
However, there are two forbidden combinations: This means that in a subnet with a mask length N, it is only possible to assign 2^32-N-2 distinct IP addresses (for example, for /24, this gives 254 assignable addresses).

To complete the following exercises, have a sheet of paper, a pencil, and, if necessary, a calculator ready.

Subnet 195.221.233.0/24

Subnet 172.31.64.0/22

Subnet 192.168.24.128/26

An interface has the address 192.168.24.66 and the mask 255.255.255.240