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.
On Client1, disable Network Manager by right-clicking on the Network Manager icon, and un-ticking the entry . Repeat on Client2.
On Client1, open a terminal window (if you don’t have a shortcut already on your top panel, access it from ifconfig “interface configuration” command:→ → ) and type the
/sbin/ifconfiglo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 or 127.0.0.1/8 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
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
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 127.0.0.1, 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
UP basically means
the interface is configured, and
basically means that interface has layer-2 (“Datalink layer”)
connectivity. So if you saw an interface that was
UP but not
might indicate that the cable was unplugged
somewhere. You can ignore the other flags for the
We can ask ifconfig to show all
interfaces by using the option
/sbin/ifconfig -aeth0 Link encap:Ethernet HWaddr
08:00:27:99:c2:7dBROADCAST 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:127.0.0.1 Mask:255.0.0.0 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 eth0||Client2’s eth0|
|Netmask||/24 = 255.255.255.0||/24 = 255.255.255.0|
[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 192.168.1.1 netmask 255.255.255.0 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 eth0eth0 Link encap:Ethernet HWaddr 08:00:27:99:c2:7d inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe99:c27d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 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. The default behaviour of
ping on Unix-like systems is to continue
pinging, once per second, until stopped by the user typing
which is generally shown as
ping 192.168.1.2PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=5.96 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.418 ms 64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.324 ms 64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.314 ms
^C--- 192.168.1.2 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.
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.
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 192.168.1.2, please respond to me at MAC address
Client1’s eth0 MAC address”, and,
assuming a station with IP address 192.168.1.2 exists on that
network, it will respond with “I have IP address 192.168.1.2, 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
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
-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 -nAddress HWtype HWaddress Flags Mask Iface 192.168.1.2 ether
If instead you see no output, or no entry for 192.168.1.2, 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 -nKernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 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 192.168.1.254, 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 -nKernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
route add default gw 192.168.1.254SIOCADDRT: Operation not permitted Whoops, forgot to use sudo
route add default gw 192.168.1.254No output, no problem!
/sbin/route -nKernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.1.254 0.0.0.0 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
0.0.0.0 netmask 0.0.0.0 and the
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 192.168.12.34PING 192.168.12.34 (192.168.12.34) 56(84) bytes of data. From 192.168.1.1 icmp_seq=1 Destination Host Unreachable From 192.168.1.1 icmp_seq=2 Destination Host Unreachable --- 192.168.12.34 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, …
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 192.168.12.34 (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 192.168.12.34It will hang for about ten seconds… traceroute to 192.168.12.34 (192.168.12.34), 30 hops max, 60 byte packets 1 192.168.1.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.comtraceroute to google.com (184.108.40.206), 64 hops max, 52 byte packets 1 220.127.116.11 0.736 ms 0.474 ms 0.424 ms 2 18.104.22.168 0.812 ms 0.757 ms 0.721 ms 3 22.214.171.124 9.676 ms 9.802 ms 9.621 ms 4 126.96.36.199 20.069 ms 20.113 ms 20.047 ms 5 188.8.131.52 56.378 ms 44.905 ms 44.851 ms 6 184.108.40.206 44.910 ms 45.060 ms 44.893 ms 7 220.127.116.11 45.587 ms 45.525 ms 45.614 ms 8 18.104.22.168 52.161 ms 53.708 ms 54.021 ms 9 22.214.171.124 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
192.168.12.34 example, where we saw
!H being output instead of a time. Have a look
to find out what that means. Write it down, you will need it for
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.
/sbin is not in their
learn more about this in the scripting lab.
 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.
 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.