Computer Network Design - Lab 2: Routing protocols

NWEN 302: 2019 Trimester 2

Assigned: 6 Sep 2019 (Friday)
Due: 18 Sep 2019 (Wednesday) for Part(a) - answers to all questions and report for part (a);
29 Sep 2019 (Sunday) for Part(b) - answers to all questions and combined report for both parts
SUBMISSION OF REASONABLE ATTEMPTS FOR BOTH PARTS ARE MANDATORY.
Value: 15%

Introduction

In this lab, you'll build networks with multiple routers and hosts, explore the use of static routes and routing protocols, configure the OSPF routing protocol, and gain practical experience configuring IPv4 and IPv6 addresses.

The lab is divided into two parts. The first part aims to familiarise you with the CORE network emulator and static routes, the second deals with OSPF.

Modern IP networks are "dual-stacked" as they run IPv4 and IPv6 protocols. IPv4 addresses have almost run out and you can expect to see increased use of IPv6 addressing throughout your career. All configuration and testing needs to be done for IPv4 and IPv6 in this lab. You'll use standard networking tools to explore and troubleshoot the network.
There are a number of places in this document where there are QUESTIONS and TASKS in blue text. You should make sure you cover ALL these points in your report.

IMPORTANT

You need to setup the VirtualBox environment for this lab in the same way that you did for Lab 1. You can follow the Lab 1 instructions to setup the VirtualBox environment after you have downloaded the virtual machine from here.

08/09/2019 - Please note there seems to be an issue with the version of FRR 7.1 installed on the VM where staticd does not start with Zebra. If you encounter this issue you can add static routes using standard Linux commands such as sudo ip route add 172.16.0.0/24 via 192.168.122.1 dev ens3.

Alternatively you can download a version of the virtual machine from here that has Quagga installed.

To start using Quagga on this virtual machine, you will need to double click on each router in the network, open services, and then enable zebra. You can click the tool icon next to the zebra service and add static routes to the bottom of this configuration file. This is the best approach, as saving the running config may result in issues where the same file is written to by multiple hosts. This won't prevent you completing the lab, but will make persistence easier to handle. Contact the lab tutors if you run into difficulty with this procedure. When you are ready to complete the second part (dynamic routing) you can enable OSPFv2 and OSPFv3 in the same way (through enabling them per router in the services).

A video to help you get started has been uploaded here.

The username and password for this virtual machine is:

nwen302

Laboratory Environment

This lab uses a software-based network emulator, CORE, developed by the U.S. Naval Research Laboratory. The package allows us to emulate complex networks with routers, switches and end hosts.

The routers are Linux based devices running a routing package called Free Range Routing (an actively developed fork of Quagga) which supports multiple routing protocols such as BGP, IS-IS, LDP, OSPF, PIM, and RIP. We'll be using OSPFv2 (IPv4) and OSPFv3 (IPv6) in this lab.

The end hosts are Linux network namespaces setup by CORE. We'll see more details of the devices later on.

The software is available on the nwen302-labs virtual machine. Launch the virtual machine using VirtualBox, and then connect to it through your terminal:

ssh -CY nwen302@your.ecs.host.ip

The -CY (or -X) flag enables X forwarding, which you will need in order to use CORE’s GUI. This virtual machine is available on the workstations in CO246. You should create a working directory and run the core-gui command from there, e.g:

mkdir nwen302-lab2 cd nwen302-lab2 sudo core-gui

Be sure to run core-gui as root, as if you do not some features such as the Wireshark integration will not work correctly.

After launching CORE, you should see a blank canvas similar to this:

image1.png

Finally, open the lab 3 topology file:

File -> Open -> /home/nwen302/NWEN302.imn

The topology should look like this:

image4.png

Backing up your work!

You are strongly encouraged to save your configuration on a regular basis into different files. Don't spend a couple of hours making changes only to find the save fails and you have to do it all again.

When you've finished using CORE use the “stop the session” button at the top left-hand side of the CORE GUI. Don’t forget to save your work before you close the GUI!

Part (a) - Static Routing

Network Layout

The network we're going to build and configure is shown below and comprises seven routers and four hosts.

image3.png

You can see from the diagram that there will be a number of alternative paths through the network. We'll be exploring how we can set this up.

Creating an initial setup

The topology of the specified network has already been created for you. If you would rather, you can create the network topology manually using the CORE GUI. Using the “network-layer virtual nodes” button on the top left (the router icon), select router, and place the routers as necessary.

Once a router has been placed, you can right-click on it and click “services”. Leave all of the options unselected. CORE can automatically provision many network services, including routing platforms such as Free Range Routing and Quagga.

Numbering your interfaces

While it's often useful to automatically configure the IP addresses on workstations and laptops, it's almost always the case that routers have their addresses configured manually.

Typically, this would be achieved using Netplan on modern distributions, or through editing:

/etc/network/interfaces 

With a configuration such as:

auto eth0 
iface eth0 inet static
address 192.0.2.7/24
gateway 192.0.2.254
iface eth0 inet6 static
address 2001:db8::c0ca:1eaf/64
gateway 2001:db8::1ead:ed:beef

In the case of CORE, the easiest method to configure host and router IP addressing is using the GUI. With the emulation stopped, double click on each router and host and configure the IP addresses as given in the following table:

Router Port Cable IPv4 Address IPv4 Netmask IPv6 Address
R1   c1 10.10.1.1 255.255.255.0 2404:2000:2002:101::1/64
R1   c2 10.10.2.1 255.255.255.0 2404:2000:2002:102::1/64
R1   c10 10.10.10.1 255.255.255.0 2404:2000:2002:110::1/64
R1   c11 10.10.11.1 255.255.255.0 2404:2000:2002:111::1/64
R2   c1 10.10.1.2 255.255.255.0 2404:2000:2002:101::2/64
R2   c8 10.10.8.1 255.255.255.0 2404:2000:2002:108::1/64
R2   c9 10.10.9.1 255.255.255.0 2404:2000:2002:109::1/64
R3   c7 10.10.7.1 255.255.255.0 2404:2000:2002:107::1/64
R3   c2 10.10.2.2 255.255.255.0 2404:2000:2002:102::2/64
R3   c3 10.10.3.1 255.255.255.0 2404:2000:2002:103::1/64
R3   c9 10.10.9.2 255.255.255.0 2404:2000:2002:109::2/64
R4   c13 10.10.13.1 255.255.255.0 2404:2000:2002:113::1/64
R4   c3 10.10.3.2 255.255.255.0 2404:2000:2002:103::2/64
R4   c4 10.10.4.1 255.255.255.0 2404:2000:2002:104::1/64
R4   c12 10.10.12.1 255.255.255.0 2404:2000:2002:112::1/64
R5   c6 10.10.6.2 255.255.255.0 2404:2000:2002:106::2/64
R5   c4 10.10.4.2 255.255.255.0 2404:2000:2002:104::2/64
R5   c5 10.10.5.1 255.255.255.0 2404:2000:2002:105::1/64
R5   c8 10.10.8.2 255.255.255.0 2404:2000:2002:108::2/64
R6   c5 10.10.5.2 255.255.255.0 2404:2000:2002:105::2/64
R6   c7 10.10.7.2 255.255.255.0 2404:2000:2002:107::2/64
R7   c6 10.10.6.1 255.255.255.0 2404:2000:2002:106::1/64
m1 eth0 c10 10.10.10.2 255.255.255.0 2404:2000:2002:110::2/64
m2 eth0 c11 10.10.11.2 255.255.255.0 2404:2000:2002:111::2/64
m3 eth0 c12 10.10.12.2 255.255.255.0 2404:2000:2002:112::2/64
m4 eth0 c13 10.10.13.2 255.255.255.0 2404:2000:2002:113::2/64

The following table gives the address allocations for each of the links. Use the information in this table to create the links - for example, cable C1 should connect R1 and R2. You'll need to record the ports allocated to each link on the routers. To make this easier, select:

View -> Show -> Interface Names

Doing so will show you which interface names between pairs of routers and hosts need to be configured with the given IP addresses. For example, link C3 between R1 and R2 will require you to configure eth1 on R1 and eth1 on R3:

image2.png

TASK 1

  • Include a copy of the completed table in your report.

QUESTIONS

1. Why do the IPv4 addresses all start with 10.10?

2. What is the IPv6 equivalent?

3. What is a netmask and why does IPv4 need one?

TASK 2

Ensure you select the following:

View -> Show -> IPv4 Addresses

And:

View -> Show -> IPv6 Addresses 
  • Include a copy of YOUR network diagram in your report. The screenshot should include visible IPv4 and IPv6 addresses. For the sake of readability, deselect:

View -> Show -> Interface Names

Starting up the Devices

image4.png

Your diagram should look something like the one above. Its topology should be the same as the Network Layout shown earlier. Make sure your setup is logically equivalent before you go any further.

At the top left corner of the CORE GUI you will see the green “start the session” button. Once you click this button, CORE will create the routers and hosts. It may take a few seconds before the devices are responsive. To login to each network device, double click on it. You have full administrative rights on these virtual machines - with power comes responsibility!

Before you go any further, start the Free Range Routing service on the 7 routers:

service frr start

The router devices use a software package called Free Range Routing (FRR), which mentioned earlier, is an actively developed fork of Quagga. While functionally very similar, Free Range Routing is developed by many of the original Quagga developers and is supported by the Linux Foundation.

The command line interface to this software is a very good implementation of the industry standard Cisco routers so using Google to find FRR (or Quagga) and Cisco documentation will be helpful. The FRR software runs as a set of Unix processes that handle different routing protocols. We'll be using the OSPFv2 (IPv4), OSPFv3 (IPv6) and Zebra components. You can connect to these processes using the following commands:

Process Command Usage
Zebra telnet localhost 2601 Configure interfaces, static routes
OSPF telnet localhost 2604 Configure OSPF for IPv4
OSPF6 telnet localhost 2606 Configure OSPF for IPv6

If you are presented with a “connection refused” error, ensure the FRR service has been started. You will need to start it every time you turn off/turn on the emulation.

Notes: The configuration of Zebra and OSPF follows Cisco-alike style. It means you can undo your configuration by "no + original command".

Connect to the Zebra process on R1

R1:~# telnet localhost 2601 
Trying 127.0.0.1... 
Connected to localhost. 
Escape character is '^]'. 

Hello, this is FRRouting (version 7.1). 
Copyright 1996-2005 Kunihiro Ishiguro, et al. 

User Access Verification 

Password:
Router> enable
Password: 
Router# 

The password is zebra - the login is a two stage process. You need to use enable to gain administrative privilege. You can look at the current configuration using the command:

write terminal

It is possible (albeit unnecessary in our case) to configure the router interfaces using Zebra rather than the CORE GUI:

Router# configure terminal
Router(config)# interface eth0
Router(config-if)# ip address 10.10.1.1/24
Router(config-if)# ipv6 address 2404:2000:2002:101::1/64
Router(config-if)# exit
Router(config)# exit
Router# write memory
Configuration saved to /etc/quagga/zebra.conf
Router#

Get in the habit of saving your changes to memory. If you don't you'll lose them when the device restarts!

Now you can get on with numbering all the connected interfaces on your seven routers, R1 - R7. Once you think they're all connected you need to test that each link is working using ping and ping6. There's no routing set up yet so don't expect to be able to ping across the network. This is a laborious task but you need to make sure each link is tested and working before you proceed.

TASK 3

  • Record your tests in your report.

For example:
R1:~# ping -c 3 10.10.2.2
PING 10.10.2.2 (10.10.2.2) 56(84) bytes of data.
64 bytes from 10.10.2.2: icmp_seq=1 ttl=64 time=20.8 ms
64 bytes from 10.10.2.2: icmp_seq=2 ttl=64 time=0.427 ms
64 bytes from 10.10.2.2: icmp_seq=3 ttl=64 time=0.389 ms

--- 10.10.2.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2025ms
rtt min/avg/max/mdev = 0.389/7.220/20.846/9.635 ms

and

R1:~# ping6 -c 3 2404:2000:2002:110::2
PING 2404:2000:2002:110::2(2404:2000:2002:110::2) 56 data bytes
64 bytes from 2404:2000:2002:110::2: icmp_seq=1 ttl=64 time=20.6 ms
64 bytes from 2404:2000:2002:110::2: icmp_seq=2 ttl=64 time=0.521 ms
64 bytes from 2404:2000:2002:110::2: icmp_seq=3 ttl=64 time=0.176 ms

--- 2404:2000:2002:110::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2025ms
rtt min/avg/max/mdev = 0.176/7.108/20.629/9.561 ms

Configuring the Unix hosts

Login to the machine M1.

QUESTION

4. What is a default gateway?

Again you should configure the other Unix hosts and test that you can ping and ping6 neighbouring devices.

TASK 4

  • Record your tests in your report.

Configuring static routing

We said earlier that routing was not configured across the network. That means that each router can only talk to devices on networks it is directly connected to. Check the routing table using the route (or route -6) command:
R2:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.1.0       *               255.255.255.0   U     0      0        0 eth0
10.10.8.0       *               255.255.255.0   U     0      0        0 eth1
10.10.9.0       *               255.255.255.0   U     0      0        0 eth2

For IPv4 that means devices it can reach with ARP.

QUESTION

5. What is the mechanism for IPv6 which corresponds to ARP? Briefly describe this in your report.

We could connect to each router and create static routes to other networks. For example, you could connect to R2 and add routes to the network between R3 and R6 under zebra like this:

ip route 10.10.7.0/24 10.10.9.2
ipv6 route 2404:2000:2002:107::/64 2404:2000:2002:109::2

Try adding these routes and check the output of the route command to see the changes.

(NOTE: If you are having issues with IPv6, try the command in Part (b) Task 2)

QUESTIONS

6. How many static routes would you need to add to allow m1, m2, m3 and m4 to talk to each other? Explain how you reached your answer.

7. In a number of places there is a choice of paths. How would you decide which path to use?

8. What would happen if one or more of your links failed?

9. What happens if you add an additional router?

Part (b) - Dynamic Routing using OSPF and OSPF6

Even if you weren't able to calculate the answer to Q6 above correctly you can see that the answer is not trivial and as your network grows and more routers are added the problem gets much harder. We'll create a simple OSPF setup on the seven routers so that each device will be able to reach all the others.

Remove any static routes you added in the previous section. E.g.
no ip route 10.10.7.0/24 10.10.9.2
no ipv6 route 2404:2000:2002:107::/64 2404:2000:2002:109::2

Configuring OSPF

This time we'll connect to port 2604 so that we attach to the OSPF process. Add the following lines to each router's config:

router ospf
 redistribute connected
 network 10.10.0.0/8 area 0.0.0.0

Don't forget to save your changes using write memory.

What has changed?

We can look at the changes in a number of ways.

Inside the OSPF process we can run the command show ip ospf route to give something like this:

Router# sh ip ospf route 
============ OSPF network routing table ============
N    10.10.1.0/24          [30] area: 0.0.0.0
                           via 10.10.6.2, eth0
N    10.10.2.0/24          [40] area: 0.0.0.0
                           via 10.10.6.2, eth0
N    10.10.3.0/24          [30] area: 0.0.0.0
                           via 10.10.6.2, eth0
N    10.10.4.0/24          [20] area: 0.0.0.0
                           via 10.10.6.2, eth0
N    10.10.5.0/24          [20] area: 0.0.0.0
                           via 10.10.6.2, eth0
N    10.10.6.0/24          [10] area: 0.0.0.0
                           directly attached to eth0
N    10.10.7.0/24          [30] area: 0.0.0.0
                           via 10.10.6.2, eth0
N    10.10.8.0/24          [20] area: 0.0.0.0
                           via 10.10.6.2, eth0
N    10.10.9.0/24          [30] area: 0.0.0.0
                           via 10.10.6.2, eth0
N    10.10.10.0/24         [40] area: 0.0.0.0
                           via 10.10.6.2, eth0
N    10.10.11.0/24         [40] area: 0.0.0.0
                           via 10.10.6.2, eth0
N    10.10.12.0/24         [30] area: 0.0.0.0
                           via 10.10.6.2, eth0
N    10.10.13.0/24         [30] area: 0.0.0.0
                           via 10.10.6.2, eth0

============ OSPF router routing table =============
R    10.10.2.1             [30] area: 0.0.0.0, ASBR
                           via 10.10.6.2, eth0
R    10.10.6.2             [10] area: 0.0.0.0, ASBR
                           via 10.10.6.2, eth0
R    10.10.7.2             [20] area: 0.0.0.0, ASBR
                           via 10.10.6.2, eth0
R    10.10.9.1             [20] area: 0.0.0.0, ASBR
                           via 10.10.6.2, eth0
R    10.10.9.2             [30] area: 0.0.0.0, ASBR
                           via 10.10.6.2, eth0
R    10.10.13.1            [20] area: 0.0.0.0, ASBR
                           via 10.10.6.2, eth0

============ OSPF external routing table ===========
N E2 172.23.0.0/16         [10/20] tag: 0
                           via 10.10.6.2, eth0

If you can't see all thirteen subnets find out why and fix it.

TASK 1

  • Include at least one version of this table in your report.

QUESTIONS

1. Which router was the example above taken from? Briefly explain your answer.

2. Will the table look the same on each router? Briefly explain your answer.

3. Dsconnect from the OSPF process on one of the routers and run the route command at the Unix prompt. Describe how the Unix routing table has changed.

Configuring OSPF6

By now you should be quite familiar with configuring the FRRouting processes. The relevant config for R1 is:
router ospf6
 router-id 10.10.1.1
 redistribute connected
 interface eth0 area 0.0.0.0
 interface eth1 area 0.0.0.0

Configure and check all seven routers as above. Note that the configuration will be different for each router.

TASK 2

  • Record details in your report.

By default, Linux devices are not configured to forward packets from one interface to another. CORE is already configured to forward IPv4 packets. We need to turn on IPv6 forwarding on R1 - R7
sysctl -w net.ipv6.conf.all.forwarding=1

This change is not permanent and when the router reboots the configuration will go back to the original behaviour. Edit the file /etc/sysctl.conf and edit the relevant line:
# Uncomment the next line to enable packet forwarding for IPv6
net.ipv6.conf.all.forwarding=1

QUESTION

4. How would you test that this change enables IPv6 packets to be forwarded?

Exploring the network from the edge

We should now have a working network which we can test and explore. Every device should be reachable from every other device. For example, if you log into m4 you should be able to ping m2:
ping -n 10.10.11.2
ping6 -n 2404:2000:2002:111::2

Find out what the -n flag does. Why do we use it here?

We can also use the tools traceroute and traceroute6 to see the path that packets take through the network. For example:
m4:~# traceroute -n 10.10.11.2
traceroute to 10.10.11.2 (10.10.11.2), 30 hops max, 40 byte packets
 1  10.10.13.1  0.220 ms  0.146 ms  0.142 ms
 2  10.10.3.1  0.367 ms  0.281 ms  0.254 ms
 3  10.10.2.1  2.287 ms  2.873 ms  3.231 ms
 4  10.10.11.2  4.921 ms  5.430 ms  5.865 ms

Double click on either R1 or R3 and run the command:

ifconfig eth1 down

This disconnects the link C2 shown on the network diagram earlier. Re-run the traceroute command. Once you are done, you can bring the link back up:

ifconfig eth1 up

QUESTIONS

5. What happens to the output of traceroute after disconnecting? Explain the result.

6. What happens if you wait for some time? Explain the result.

7. What happens if you Re-connect the link c2? Explain the result.

8. The changes you see take some time to happen. How long? Explain your result and how you worked this out.

You also trace the path that packets take through the network using mtr and ping -R. These tools are used very commonly to test for and diagnose network problems. Try using them while disconnecting links. Each tool has advantages and disadvantages in this situation.

TASK 3

  • Make sure you also test your IPv6 network.

Exploring the network from the core

In the section above we tried turning a link off and on again to see what happens from a user perspective. In this section we'll look more closely at what's happening with the OSPF protocols in the core. Connect to R3 and then connect to the OSPF process. Look at the routing table using show ip ospf route command.

QUESTION

9. What happens to this table when you disconnect c2?

OSPF in action

We can examine the OSPF protocol much more closely by turning on debugging in the OSPF process using:

terminal monitor
debug ospf lsa

This puts a significant load on a router in production and we need to turn it off when we've finished debugging by using:

no debug ospf lsa
no terminal monitor

This allows to look at the Link State Advertisements in OSPF. Repeat the experiment with disconnecting c2.

TASK 4

  • Use your theoretical knowledge of OSPF and sample output from the router to explain what's going on.

What to hand in

  • A PDF format report including your answers to all the questions and output from all the tasks listed above.
  • The completed CORE file NWEN302.imn

Grading scheme

The following aspects will be assessed:

  1. (80%) Did you correctly answer the questions and compete the tasks?
    • Part (a) (40%)
    • Part (b) (40%)
  2. (20%) Is the report well written?
    • Marks awarded for:
      • Clarity - Is each part, task and question clearly marked?
      • Consistency - Has the chosen format been adhered to?