Lab - 4: Route Tables

Objectives

The lab is on observations of:

  • Route tables at hosts

  • ARP tables at hosts

  • Message exchange during ICMP echo request from a host in one subnet to a host in another subnet

Load Lab Network

Execute the commands to load the labpicker:

%load_ext uhed
%lab

In order to conduct this lab, please pick IP Routes lab from the dropdown menu and click on the Build Network button. Once successfully built, display the network topology using:

NET.showTopo()

Open a terminal using File > New > Terminal from top menu and then ssh (secure shell) into the hosts using the command:

gssh <username> <devicename>

Note

Reminder Example on ssh For example, for a user name, student01, ssh into the host1 using the command gssh student01 host1 at the terminal.

Topology Orientation

_images/routingTopo.png

Lab Network Topology: There are three hosts. One host has two interfaces connecting to the bridge: eth1 and eth2.

Observation Plan and Environment

  1. Determine the state of each host interface by showing the network interface table:

    NET.showInterfaces()

    Note

    Host interface state can also be determined from each host’s terminal: open a terminal for each host and ssh into the host. Using the ip addr command, identify the MAC and IP addresses assigned to the interface(s).

  2. Determine the state of each host’s route table:

    NET[<hostlabel>].getRouteTable()

    Note

    This state information can also be accessed via the host’s command line using the route -n command.

  3. Open a terminal on the three hosts and run tcpdump on their eth1 interfaces to monitor the incoming and outgoing traffic on that interface.

  4. Send echo request messages from the host with two interfaces to each of the other hosts. First, send an echo request via the eth2 interface on the host by sending a ping to the IP address of the other (single-interface) host sharing the subnet of this interface. Observe the tcpdump activity from the three captured interfaces. Finally, send an echo request to the remaining single-interface host and observe the resulting traffic.

Using either method above, check each host’s route table (host command line option shown below):

/ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
32.55.240.0     0.0.0.0         255.255.240.0   U     0      0        0 eth2
218.56.252.0    0.0.0.0         255.255.252.0   U     0      0        0 eth1
/ #

As is shown in the above route table, the host’s eth1 interface has only one destination subnet: the subnet to which the eth1 interface belongs. The following terminal output displays the host’s interface configuration state. The same is true for the host’s eth2 interface.

/ # ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2467: eth1@if2466: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc netem state UP group default qlen 1000
    link/ether 26:31:36:de:11:a2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 218.56.255.207/22 scope global eth1
       valid_lft forever preferred_lft forever
2469: eth2@if2468: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc netem state UP group default qlen 1000
    link/ether de:8a:e8:00:10:2a brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 32.55.249.146/20 scope global eth2
       valid_lft forever preferred_lft forever

When trying to send an ICMP echo request to a host at a given IP address, the operating system of the host checks the route table. If it cannot find a route, it is not able to send the packet and an ICMP message may display as output from the ping command:

/ # ping 134.68.190.242
connect: Network unreachable

A host with a single interface is configured as follows:

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2471: eth1@if2470: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc netem state UP group default qlen 1000
    link/ether b2:07:7f:fd:b7:1b brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 218.56.253.144/22 scope global eth1
       valid_lft forever preferred_lft forever

An echo request to this host from the host with two interfaces results in the following:

/ # ping -c 3 218.56.253.144
PING 218.56.253.144 (218.56.253.144) 56(84) bytes of data.
64 bytes from 218.56.253.144: icmp_seq=1 ttl=64 time=0.459 ms
64 bytes from 218.56.253.144: icmp_seq=2 ttl=64 time=0.092 ms
64 bytes from 218.56.253.144: icmp_seq=3 ttl=64 time=0.081 ms

--- 218.56.253.144 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2031ms
rtt min/avg/max/mdev = 0.081/0.210/0.459/0.175 ms

The tcpdump monitor at the host with two interfaces shows the echo request and echo reply packets, as well as the preceding ARP packets:

/ # tcpdump -i eth1 -ne not ether dst 01:80:c2:00:00:00 and not ether proto 0x86DD
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
19:51:04.661184 26:31:36:de:11:a2 > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 218.56.253.144 tell 218.56.255.207, length 28
19:51:04.671417 b2:07:7f:fd:b7:1b > 26:31:36:de:11:a2, ethertype ARP (0x0806), length 42: Reply 218.56.253.144 is-at b2:07:7f:fd:b7:1b, length 28
19:51:04.763880 26:31:36:de:11:a2 > b2:07:7f:fd:b7:1b, ethertype IPv4 (0x0800), length 98: 218.56.255.207 > 218.56.253.144: ICMP echo request, id 2375, seq 1, length 64
19:51:04.764317 b2:07:7f:fd:b7:1b > 26:31:36:de:11:a2, ethertype IPv4 (0x0800), length 98: 218.56.253.144 > 218.56.255.207: ICMP echo reply, id 2375, seq 1, length 64
19:51:05.771279 26:31:36:de:11:a2 > b2:07:7f:fd:b7:1b, ethertype IPv4 (0x0800), length 98: 218.56.255.207 > 218.56.253.144: ICMP echo request, id 2375, seq 2, length 64
19:51:05.771330 b2:07:7f:fd:b7:1b > 26:31:36:de:11:a2, ethertype IPv4 (0x0800), length 98: 218.56.253.144 > 218.56.255.207: ICMP echo reply, id 2375, seq 2, length 64
19:51:06.795265 26:31:36:de:11:a2 > b2:07:7f:fd:b7:1b, ethertype IPv4 (0x0800), length 98: 218.56.255.207 > 218.56.253.144: ICMP echo request, id 2375, seq 3, length 64
19:51:06.795312 b2:07:7f:fd:b7:1b > 26:31:36:de:11:a2, ethertype IPv4 (0x0800), length 98: 218.56.253.144 > 218.56.255.207: ICMP echo reply, id 2375, seq 3, length 64

An ARP request was issued by the sending host to retrieve the MAC address of the interface configured with the intended destination IP address. We can check the ARP table of the sending host to see the current entries (this table info can also be accessed in the notebook: NET[<hostlabel>].getARPTable()):

/ # arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
218.56.253.144           ether   b2:07:7f:fd:b7:1b   C                     eth1
32.55.254.225            ether   de:a5:e6:39:0c:3c   C                     eth2

Although it was not shown in the preceding section, traffic has been sent from both interfaces on this host. Therefore, the ARP table shows two entries containing the IP addresses and MAC addresses of the single-interface hosts.

The single-interface hosts should only have one ARP entry in their ARP tables:

/ # arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
218.56.255.207           ether   26:31:36:de:11:a2   C                     eth1

ARP entries will be cached on the hosts. Caching can potentially reduce the number of required ARP exchanges for future IP traffic between these hosts. Additionally, future IP traffic may be sent quicker as it will not have to wait for the hosts to resolve the destination MAC addresses before sending IP packets.

Gathering Network State in the Lab Notebook

The interface configurations can be displayed in the notebook as shown below. All interfaces should have a MAC address and IP address upon building the lab topology:

_images/lab4_interfaces.png

Each host’s route table should contain one route per configured interface:

_images/lab4_singleroutetable.png
_images/lab4_routetable.png

Note

Two interfaces, two subnets, two routes: As shown in the figure above, the host with two different interfaces has two entries in its route table corresponding to the two subnets to which its interfaces belong.

Once all hosts have exchanged echo request/reply messages, their ARP tables should be appropriately populated:

_images/lab4_arptable.png

If echo request/reply messages are initiated rapidly, the bridge layer2 table should be fully populated with all host interface MAC address. Remember, you must retrieve this table soon after executing (successful) ping commands between all pairs of hosts (entries in the layer2 table timeout after about 300 seconds or 5 minutes):

_images/lab4_l2table.png

Learning Activity

Step 1 – Activity and Observations

1a. Issue a ping on the command line to a destination IP address for each host within their own subnet and also outside of their subnet to observe the results.

1b. Retrieve and investigate the ARP tables of all hosts:

NET[<hostlabel>].getARPTable()

1c. Retrieve and investigate the route tables of all hosts:

NET[<hostlabel>].getRouteTable()

Step 2 – Lab Homework

Important

The homework submission timeline is constrained in this lab: you must submit before your ARP table entries timeout. Complete your submission within 15 minutes of populating the host ARP tables.

2a. Populate the ARP tables on all of your hosts by logging into each host and sending an echo request packet (using the ping tool) to the other host in the same subnet.

2b. Before you submit, verify each host’s ARP table is populated appropriately:

NET[<hostlabel>].getARPTable()

2c. Submission:

STOP! Did you practice this week’s material using the %practice facility in your notebook? Please solve the question(s) and make sure to receive a Correct! response in all questions before you attempt to submit your assignment.

There are two steps to complete your assignment:

1. In your lab notebook, run:

%homework

to complete and submit this portion.

2. In your notebook, run:

%exercise

to solve the question(s) and submit this portion.

Caution

You only have one submission attempt available to you. It is recommended to complete the requirements before you load the homework to prevent submitting an incomplete network state.

Lab Wrap-up

Please follow the instructions to delete your reserved topology and then close and halt your lab notebook and any open terminals on the lab service.