4. Affect a Temporary Configuration and Test

In this section, we’re going to configure the interfaces on Client1 and Client2 that are connected to the network “TELE301 Internal Network 1” using first principles. These changes are temporary in nature; a reboot would remove any changes. In the next section, we look at how we can make these changes permanent. Once we have configured both interfaces, we will verify IP-level connectivity between them by “pinging” one machine from the other. Then we shall briefly look at other common tools that are useful for learning more about the current state of the host and network.

First though, we need to prevent Ubuntu from automatically managing our interfaces for us, because then it would override the temporary changes we’re wanting to make. This is a common feature found on most modern systems. Ubuntu, and other Gnome-based desktop environments, perform this task using something called NetworkManager. It is designed to automatically configure network interfaces when, for example, a cable gets plugged in or a wireless network is joined, etc. Because we want to statically configure the interfaces – without using the typical permanent configuration facilities – we need to turn it off to prevent it from getting in our way. Figure 8, “Disabling Network Manager” shows where you can find the NetworkManager icon, and what you see when you right-click on it.

Figure 8. Disabling Network Manager

Disabling Network Manager

Network Manager by default can be found in the top panel in a Ubuntu desktop environment. It shows different menus if you left or right-click; this figure shows a right-click, which will enable us to disable Network Manager.

On Client1, disable Network Manager by right-clicking on the Network Manager icon, and un-ticking the entry Enable Networking. Repeat on Client2.

On Client1, open a terminal window (if you don’t have a shortcut already on your top panel, access it from ApplicationsAccessoriesTerminal) and type the ifconfig “interface configuration” command:

$ /sbin/ifconfig
lo        Link encap:Local Loopback  
          inet addr:  Mask:   or in CIDR notation
          inet6 addr: ::1/128 Scope:Host        IPv6: ignore for now…
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:720 (720.0 B)  TX bytes:720 (720.0 B)

Like many administrative commands, ifconfig lives in the directory /sbin (“system binaries”), and not /bin (“user binaries”), and because of this, users generally won’t be able to find it if they just type ifconfig[11] Also, note that even though ifconfig is an administrative command, it is not being used to make any changes or access restricted information, so we don’t need root privileges.

Hmmm, do you notice anything missing in the previous listing? Where are our Ethernet interfaces, eth0 (and eth1 on Client1, but we’re ignoring that for now), and what is that lo interface? Hopefully, you should be able to notice that the lo interface has an IPv4 address of, which you should recognise as being the loopback address which every machine will have, so this is the “loopback” interface (so called because if we send to it, we end up talking to the same host, which is still quite useful but we’ll see it more later on).

So, where are our Ethernet interfaces? By default, ifconfig only shows those interfaces that have the UP flag set. There are other flags as well, such as RUNNING. UP basically means the interface is configured, and RUNNING basically means that interface has layer-2 (“Datalink layer”) connectivity. So if you saw an interface that was UP but not RUNNING, that might indicate that the cable was unplugged somewhere.[12] You can ignore the other flags for the present time.

We can ask ifconfig to show all interfaces by using the option -a:

$ /sbin/ifconfig -a
eth0      Link encap:Ethernet  HWaddr 08:00:27:99:c2:7d
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1710 (1.7 KB)  TX bytes:1836 (1.8 KB)

eth1      Ignore for now. Only on Client1

lo        Link encap:Local Loopback  
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:720 (720.0 B)  TX bytes:720 (720.0 B)

Notice that your Ethernet hardware address (“MAC address”) will be different to that shown in the above listing. Look at the screenshot you took when configuring the VirtualBox network settings, and just ensure that the MAC address of eth0 is the same as Adaptor 1.

Repeat the above procedure on Client2, from disabling Network Manager.

Now we shall give Client1’s eth0 and Client2’s eth0 IPv4 addresses, and ensure they can talk to each other. This time, we shall be using ifconfig to make administrative changes to the system, so we shall require administrative powers (ie. use sudo as we practiced in the previous lab). Here is the information, taken from the topology map at the beginning of this lab, but shown in tabular form:

 Client1’s eth0Client2’s eth0
Netmask/24 = =

[a] Automatically determined from Address and Netmask

[b] Automatically determined from Address and Netmask

Notice that the Address of each is different, but the Network and Broadcast addresses are identical, which means they are in the same network. The Network and Broadcast addresses are, by default, determined automatically from the Address and Netmask. In the case of the Network address, all of the host bits are 0 (ie. the very first possible host address), while in the Broadcast address, all the host bits are 1 (ie. the very last possible host address). You don’t need to worry about the Network and Broadcast addresses for the present time; the default behaviour is desirable and correct.

Okay, so here’s how we can configure Client1:

# /sbin/ifconfig eth0 netmask up

Verify what we have done by querying the interface configuration, much as we did before. I’ve highlighted the parts that you should check.

$ /sbin/ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 08:00:27:99:c2:7d  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::a00:27ff:fe99:c27d/64 Scope:Link
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1710 (1.7 KB)  TX bytes:5693 (5.6 KB)

Repeat on Client2 using the very same procedure, but with a different address. Take a screenshot of both client machines showing the ifconfig output after configuration.

Go back to Client1, and use the ping command to see if you can reach Client2. This sends a message called an “ICMP Echo Request” (“ping”) to a target host. Upon receiving the request, the target would reply by sending back an “ICMP Echo Response” (“pong”). The requestor would then look at the time difference and print out the “round-trip time”, which is the time taken to send the message and get a response.


A lot of networks will prevent pings into their networks from outside, so if you try to ping well-known sites, such as Microsoft, you’ll probably find you do not get a reply. Thus, not getting a response doesn’t necessarily mean the target host is not up, as it could be filtered somewhere.

Let’s ping Client2 from Client1. We could also ping Client1 from Client2, but generally that is not needed, because if we get a response we know that traffic can flow in both directions.[13] The default behaviour of ping on Unix-like systems is to continue pinging, once per second, until stopped by the user typing Ctrl+C, which is generally shown as ^C:

$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=5.96 ms
64 bytes from icmp_seq=2 ttl=64 time=0.418 ms
64 bytes from icmp_seq=3 ttl=64 time=0.324 ms
64 bytes from icmp_seq=4 ttl=64 time=0.314 ms
--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.314/1.755/5.966/2.431 ms

So, if you saw something like the above, then that’s great! Take a screenshot for the assessment.

Didn’t work?

If you instead saw ping wait for a while and then output “Destination Host Unreachable”, that would indicate that Client2 is either mis-configured with an IPv4 address on its eth0 interface, or you configured its VirtualBox settings wrongly, perhaps connecting it to the wrong network.

You’ve just configured your first network. For a real beginner, working on their own on their first network, the hardest thing to understand is what you should put as the IP address.

Running late?

The rest of this section is optional. If you run out of time, you may skip over to Section 5, “Affect a Permanent Configuration”.

Have a look at those round-trip times reported by ping, the first is rather larger than the subsequent pings; if instead you don’t see this, don’t panic, just read on. In order to find out why we have a longer initial ping, we need to remind ourselves about how the “ARP cache” fits in to packet delivery.

In order to for Client1 to send a packet to Client2 on the local network, it needs to be able to address Client2’s Ethernet interface using the appropriate MAC address. However, Client1 wouldn’t know that MAC address corresponding to Client2’s IP address, so it uses the Address Resolution Protocol (ARP) to find out. ARP basically asks everyone on the network “Yo! Whoever has IP address, please respond to me at MAC address Client1’s eth0 MAC address”, and, assuming a station with IP address exists on that network, it will respond with “I have IP address, and my MAC address is Client2’s eth0 MAC address”. Client1 then remembers this in its ARP cache for a period of time; a common time-to-live is five minutes for most client systems, after which it will be expired from the cache.

So we can see that the first, more lengthy, ping is because it’s had to do some ARP lookup before it could actually deliver the ping request. If you were to repeat the ping command before the ARP entry expires, you would find you don’t get that first initial delay.


There can be other reasons for an initial delay, such as the system having to “page in” some of the operating system from memory if it hasn’t been used recently. Commonly there will be some combination of reasons that contribute to round-trip-time fluctuations, including those relating to the destination host and the intervening network.

We can inspect the ARP cache using the arp command. We suggest that you run it with the -n “numeric” option, which prints out IP addresses instead of trying to find names for them, which makes the output easier to recognise:

$ /usr/sbin/arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface              ether   08:00:27:93:32:8b   C                     eth0

If instead you see no output, or no entry for, it probably indicates that the entry expired before you ran the arp command. Run the ping command again and try again.

So far, we’ve seen enough to learn about the deliveries to hosts on the local network (“local deliveries”). But in real-life, there are many different networks that we might wish to communicate with. In fact, that’s the very reason IP was created. So how does it know whether something is a local delivery or whether it has to first be sent off to some other “router” to be sent towards its destination. That’s where the “routing table” comes in, which you should have some rememberance about from your previous studies. Here is how we can inspect the routing table on Client1:

$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface   U     0      0        0 eth0

As you can see, that’s a very short routing table, as Client1 only has one network it is currently connected to (Client1’s eth1 is not yet UP, but we’re ignoring that for now anyway). Most real systems with a connection to the Internet, or any other wider network, will also have at least a default route (aka. “route of last resort”), which basically says “if no other route matches, send it towards the router with IP address X”.

Now, we’re not going to be playing with routing until much later in the paper, but I would at least like to show you a couple of things while we’re talking about basic network interface management: how to add a (default) route, and to determine how something would get routed through a network, typically in order to find out where something is broken.

We don’t actually have anything operating as a router in this network, but we can simulate a misconfiguration, which is perhaps more interesting. We’re going to pretend that there should be a router at the address, but that the router is currently present on the network. We shall only do this activity for Client1.

On Client1, run the following commands to first inspect the routing table before you make the change, then add a default route to its routing table, then inspect the routing table to verify the change:

$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface   U     0      0        0 eth0
$ route add default gw
SIOCADDRT: Operation not permitted   Whoops, forgot to use sudo
# route add default gw
No output, no problem!
$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface   U     0      0        0 eth0         UG    0      0        0 eth0

Notice that the gw part of the command specifies the “gateway” (meaning “nearest router” in this case) that Client1 is going to use to try and get to anywhere else. The default is shorthand for -net netmask and the G in the Flags field indicates that this route sends via a gateway, as opposed to a local delivery.

Since we’ve spent a bit of effort breaking the network, let’s spend a little bit of effort to recognise how we’ve broken it, and then fix it. Imagine you’re currently drinking your morning coffee, of whatever, you get a call from a user saying that they can’t get to anywhere on the Internet. Pretend for now you don’t know it’s because the router is down.

At Client1, you do a few little tests: you could start on the inside (eg. “Does this machine have a valid IP address?”) and work outwards toward the Internet (eg. “Can this machine get to sites on the Internet?”), but it can be faster to start outwards, often because you might recognise various error messages more easily than a user, and be able to come to a resolution faster (eg. “Oh, its a DNS issue”, or “Hmmm, what about other sites?”). In this case, let’s say you start by pinging a machine you know the IP address of, one that happens to be outside your network:

$ ping -c2
PING ( 56(84) bytes of data.
From icmp_seq=1 Destination Host Unreachable
From icmp_seq=2 Destination Host Unreachable

--- ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, …

Network is unreachable

If you instead get a message about “Network is unreachable”, that is a standard networking error that indicates that there is no route to the network, and you therefore haven’t added the default route as instructed above.

Notice it says “Destination Host Unreachable”. This is a standard networking error that indicates an ARP lookup failed. “Aha!” you say, so somewhere in the path between here and (which we’re imagining is on a wider network for now), “there is a host down somewhere, but where?”. This is when we use traceroute, to find out where in the path the packets are being “dropped”.

$ traceroute -n
It will hang for about ten seconds…
traceroute to (, 30 hops max, 60 byte packets
 1  3004.111 ms !H  3004.116 ms !H  3004.116 ms !H

Take a screenshot. What are we seeing here? Before we explain it, let’s see an example in a larger network: a traceroute to google.com from my office workstation, which is running Mac OS X:

$ traceroute -n google.com
traceroute to google.com (, 64 hops max, 52 byte packets
 1  0.736 ms  0.474 ms  0.424 ms
 2  0.812 ms  0.757 ms  0.721 ms
 3  9.676 ms  9.802 ms  9.621 ms
 4  20.069 ms  20.113 ms  20.047 ms
 5  56.378 ms  44.905 ms  44.851 ms
 6  44.910 ms  45.060 ms  44.893 ms
 7  45.587 ms  45.525 ms  45.614 ms
 8  52.161 ms  53.708 ms  54.021 ms
 9  45.751 ms  45.758 ms  45.716 ms

In this example, which you probably won’t be able to reproduce on your own student lab machines, we successfully reach google.com. Note that it is showing you the time taken to get to each hop from the query source: you can often see transitions between the local network to remote networks, or in the case of New Zealand, when it leaves the country on one of the long-haul links, although in this case the round-trip times would indicate the traffic is not leaving New Zealand (if it were, we would expect the trip-times to be on the order of 200ms). If you want other, more interesting examples, when you’re at home, try google.com.cn, or any website if you have trouble getting to it.

But back to our earlier traceroute -n example, where we saw !H being output instead of a time. Have a look at traceroute(1) to find out what that means. Write it down, you will need it for the assessment.

Okay, enough of that. Let’s fix it by removing the route (in the real-world, if the router was supposed to exist, we would fix the router instead).

# route del default

That’s quite enough for this section. In the next section, we’ll make the IP configuration permanent on Client1 (remember, nothing is permanent on Client2 because its running from a Live CD. Reboot Client1, leaving Client2 as it is.

[11] Because /sbin is not in their PATH. We learn more about this in the scripting lab.

[12] In Cisco-parlance, we would instead say “up and up”. Knowledge that the data-link layer is working in particularly useful in serial interface such as WAN network links.

[13] At least, this is true at the IP layer, but as we will see much later, devices such as Firewall and NAT boundaries can cause problems here, so pinging Client1 from Client2 as well could be useful when crossing such boundaries.