Interface Management

Table of Contents

1. A Map, Notation and a bit of Theory
2. Prepare Client1
3. Create Client2
4. Affect a Temporary Configuration and Test
5. Affect a Permanent Configuration
6. Assessment
7. Cleanup

Required Reading Prior to Lab

To ensure you get plenty of time to ask for any help during the lab, please ensure you have read at least Section 1, “A Map, Notation and a bit of Theory” before coming to the lab, as this includes important revision material and does not require you be in the lab.

If you have already done so, congratulations! You can directly jump to Section 2, “Prepare Client1”.

Today is a fairly exciting lab; you get to create a network topology of (virtual) hosts and (virtual) Ethernet switches, which is a great first step to network management. In order to understand what it is that we’re creating, we will need to indulge in a little theory (don’t worry, its quite practical).

Then we’ll be adding another virtual machine, called Client2, to our network; add Client1 and Client2 into a separate network of their own, give them some addresses and ensure they can communicate with each other.

Naturally, there is a lot of ways in which network can go wrong, so we need some diagnostic tools to help us figure out what’s actually happening. We’ll look at some management and diagnostic tools that will be useful here.

Since prevention is better than cure, we’ll also show you how you can usefully name your interfaces which will help prevent mistakes later on.

1. A Map, Notation and a bit of Theory

Figure 5, “Topology for Interface Management Lab” shows the layout of the machines and switches in todays virtual environment. The smaller boxes connecting the PCs shown in the diagram are Ethernet switches, and will be managed automatically by VirtualBox. The switch to the left of Client1 we will ignore until much later in the lab. Client1 will have two interfaces, and will be connected to two separate networks, which we shall simply call “TELE301 Internal Network 1” and “TELE301 Internal Network 2”. VirtualBox calls these virtual Ethernet “Network Interface Cards” (“NICs”) as an “Adaptor”. By default each VirtualBox virtual machine will have one adaptor, so we will have to enable a second adaptor.

Figure 5. Topology for Interface Management Lab

Topology for Interface Management Lab

The topology of the virtual network we shall be creating today.


Inside each virtual machine (aka. “VM” or just “guest”), the operating system – Ubuntu Linux in our case – will give each interface a name. By default, Linux will give all of its Ethernet interfaces names such as ethN, where N starts at 0. Other OSes have different naming conventions, although they don’t really tell you a lot, such as what it is that they are connecting to: intnet1 and intnet2 might be better names, and we’ll rename those interfaces later.

We can recognise that Client1 is different from Client2 in that it attached to multiple networks at one time. You could imagine Client1 as being a notebook computer with one interface being a wired Ethernet port, and another being on a WiFi Wireless Ethernet network. We’ll ignore its second interface until later in this lab.

Each network, of which we have two, must have a different “network address” (we could also just as easily say “subnet address”, as the two terms are identical for our purposes currently). Thus, everything in “TELE301 Internal Network 1” has an IP address starting with 192.168.1.x, while everything in “TELE301 Internal Network 2” has an IP address starting with 192.168.2.x. This is important, because Client1 must be able to determine (via its “routing table”) which interface it should send traffic out of in order to reach a particular IP address.

Inside each network, each interface must have a different address, or else we wouldn’t be able to uniquely specify a particular host. Notice I said “interface”, and not “host”. An IP address is assigned to an interface, not a host; Client1 has two interfaces, and thus two addresses, each on a different network.

Client1’s interface on “TELE301 Internal Network 1”, Adaptor 1 has an IP address of 192.168.1.1, while Client2’s interface on the same network has an IP address of 192.168.1.2. Assume that Client1 wants to send a packet to 192.168.1.2: how does it determine which interface to send out of?

To answer that, note that each network has a network address such as 192.168.1.0/24. What does that /24 mean? It is the “prefix-length” and specifies the number of bits from the start (“left”) of the address where we stop talking about the network (the “network” or “subnet” ID) and start talking about the host ID. Recall an IPv4 address has 32 bits, and each number in a “dotted-quad”, a.b.c.d takes up eight of those bits:

       192    .    168    .     1     .     0     / 24       Network address
    1111 1111   1111 1111   1111 1111   0000 0000            Binary bitmask
       255    .    255    .    255    .     0                Netmask
              8           16          24                     Number of bits from start

Let’s explain what this shows:–

Line 1

This is a network address and prefix-length. The prefix-length is specified here in “CIDR” (pronounced “cider”) notation, which is a convenient shorthand for the older “netmask” (aka. “network mask” or “subnet mask”) on the third line.

Line 2

Shows the 24 (from /24) binary bits from the start of the 32-bit network address, nicely spaced out.

This lower this number, the fewer networks we can represent, but each network can have more hosts inside it. So, if every network on the Internet were to have a /8, we could only have 255 networks on the Internet, but each network could have 232-8 or over 16 million hosts[8]. Alternatively, if every network on the Internet had a /24, you could have over 16 million networks, but each network could have less than 256 hosts.

In practice, we have a mixture of different network sizes in use, and larger networks are “subnetted” into smaller networks, but we don’t need to concern ourselves with that for now.

Note that you should only ever have a string of ones at the beginning, then a string of zeros until the end.[9]

What this shows is that the entire first three octets specify the network ID portion of the address.

Line 3

Shows the “dotted quad” (or “dotted decimal”) notation, where every eight bits (“octet”, or “byte”) is converted into decimal. For our purposes today, we only need to recognise that binary “1111 1111” makes decimal 255, and binary “0000 0000” makes decimal 0.

Line 4

Notice that each number is at a location of a dot. Since every decimal number on the first line is specified in eight bits (hence, a maximum of 255, or 25-1) we can easily recognise /8 /16 and /24. So, for example, if I were to specify 10.0.0.0/8, then everything matching 10.x.y.z would be in that network..

We can actually specify “sub-octet” prefix-lengths, but these are harder to work with and we ignore them for now until much later in the paper.

So, you should be able to see, given the map above, that 192.168.1.2 is in the same network as 192.168.1.1, and in a different network to 192.168.2.113. If you have trouble understanding that, please ask a demonstrator.

One last, tiny little thing before we go on. Later on you will see that every machine has a “loopback” interface, often called “lo” or “lo0”, having an IP address of 127.0.0.1. Please note that every machine has one of these, and so anything sent to 127.0.0.1[10] gets sent to the local machine, which we call “localhost”.



[8] Although we would have to subtract two reserved addresses, but that’s not important right now.

[9] Unless you’re working with Cisco “wildcards”, in which case it is inverted, so a string of zeros followed by a string of ones.

[10] Actually, anything in 127.0.0.0/8.