Lab 3 A
Lab 3 A
1A good idea would be to read the lecture slides or the corresponding textbook sections (4.1, 4.2, 4.3,
5.1, 5.2, 5.3, 5.4, 5.5, 5.6) regarding the Network Layer to fully understand the concepts, you will
use and test in this Lab.
2You are allowed to use the same set of screenshots/pictures as your evidence. However, the answers and analysis in
your report must be your own individual ideas.
3If you want, you can use the tools available at the Racks’ computers to capture the screenshots and then download
them to an external USB storage unit for your analysis. You can use the Windows snipping tool: https://
support.microsoft.com/en-us/windows/use-snipping-tool-to-capture-screenshots-00246869-1843-655f-
f220-97299b865f6b
4Remember that every question requires the corresponding evidence so our grades can evaluate your work in the
best way possible. In this assignment, in particular, you will need to reuse multiple screenshots for di erent
questions. In the past, some students have created appendices with their evidence. You are welcome to do this,
however, keep in mind that you need to 1)reference this appendix in your response in the lab report and 2)Include the
appendix pages in the mapping of ALL the questions that use it.
Procedures
1. Verify that power switch nine (9) (on the power rail behind the rack) is turned ON.
2. Verify that the Netgear switches inside the rack display the numbers 1, 2, 3, and 4. Note
that we have two new switches for you to observe this time (four (4) in total).
3. Turn ON (Restart if it is already on) the PC by powering on switch eight (8) (on the power
rail behind the rack).
4. Login to the testbed’s PC with the following credentials:
Username: student
Password: 740Rocks$
5. If power switch three (3) (Lab 3) is ON, turn it OFF and wait for ve (5) seconds before
proceeding with the next step (Static charge can keep the device on for a couple of seconds).
6. Turn ON the power switch three (3) (on the power rail behind the rack) and wait up to two
(2) minutes for the hosts to boot and spread routing information5.
7. If you have any problems during the lab, you can repeat steps ve (5) and six (6) to restart all
the devices that participate in Lab 3a.
8. (Optional) Connect the Ethernet cable to your laptop and start Wireshark. In Lab 3a, we
are not going to capture any data on Wireshark but feel free to capture data for your curiosity
or if you want to gather additional information that might help you answer some of the
questions.
9. When you are done with the lab, shut down the computer and turn o all the power switches
EXCEPT 9!
FRRouting
The Linux-based hosts in the network testbeds (the “Racks”) use a routing application called
FRRouting, which is a fork of the now-deprecated tool Quagga. FRRouting (FRR) is a
free and open-source Internet routing protocol application for Linux and Unix platforms (i.e.,
Unix-based hosts). It allows Linux hosts to implement BGP, OSPF, RIP, IS-IS, PIM, LDP,
BFD, Babel, PBR, OpenFabric, and VRRP, with alpha support for EIGRP and NHRP
routing algorithms/protocols to create Linux-based “routers.” In other words, FRRouting
transforms Linux computers into Internet Routers.
FRR’s seamless integration with native Linux/Unix IP networking stacks makes it a general-
purpose routing stack applicable to a wide variety of use cases including connecting hosts/VMs/
containers to the network, advertising network services, LAN switching, and routing. In the
Racks, we have multiple Unix-based computers (i.e., Raspberry PIs) acting as routers using the
FRRouting application to simulate routing protocols such as BGP and RIP.
Quagga was named after an extinct type of zebra, so it should not surprise you that its routing
daemon (and the routing daemon in FRRouting) is called zebra.
The zebra daemon creates a virtual (simulated) Cisco IOS router interface over a Unix-based
machine that can be accessed via telnet over a localhost (only!). Let's make sure you
understand that last sentence. Cisco is a big networking company with one of the most popular
lines of networking routers. The operating system on those routers is named Internetwork
Operating System (IOS)6. You will use telnet, a remote login program, in a given
localhost to enter IOS commands for the zebra daemon running on a local Linux-based
6 Do not confuse it with iOS, as it was around long before the Apple iPhone.
computer (Raspberry PI), but this only works if you are already remotely logged into that local
machine (i.e., localhost).
As you probably gured out already, in Lab 3a (Checkpoint 1), using the Racks’ computers, you
will remotely connect (using ssh) to another Linux-based machine (i.e., multiple Raspberry PIs
acting as routers in the Racks), then remotely connect to a routing daemon in that machine (e.g.,
zebra), then remotely connect to another daemon in that machine, etc. In other words, in this
Lab, you will be “jumping” (remotely logging in) from one Linux machine to another and then,
inside that machine, “jumping” (remotely logging in) from one daemon to another (inside a
localhost).
In the testbed, multiple FRRouting daemons are started in multiple Linux-based hosts (i.e.,
Raspberry PIs) depending on the kind of routing protocol that is enabled on that router (BGP or
RIP) and the network connection and con guration of the Testbed. The daemons that are used
in this lab are:
• Zebra Daemon (localhost:2601): This is an abstraction layer that converts the
commands into versions speci c to the routing protocol you have chosen.
• RIP Daemon (localhost:2602): This emulates the RIP interface on the router and all
RIP-associated commands are sent using this interface.
• BGP Daemon (localhost:2605): Like the RIP daemon, but this one deals with BGP.
If you are following along so far, you should see that each router is connected to many subnets.
And, the router has an active interface for each subnet it is connected to. This is a critical point
for any lab about routing protocols and one that is often mistaken in network diagrams.
If you are not clear about all the mentioned above concepts, please re-read them to make them
more clear to you!
The diagram below illustrates the di erence in this way of thinking. End hosts generally only
have a single connection/interface to the network (eth0), so they have a single active interface
and thus a single IP address (e.g., 192.168.1.1 or 192.168.2.2). Thus, the red-colored
end hosts are often distinguished just by their IP address. However, the router (blue hosts) must
have multiple interfaces (eth0 and eth1 in the diagram below). Each interface is con gured
with an IP address (e.g., 192.168.1.2 and 192.168.2.1) which is included in the range of
addresses on the subnet (the /24 pre x notation shows a range of various addresses available in
the subnet (e.g., 192.168.1.0/24 and 192.168.0.0/24)).
Wrong
End host 1 Router 1 End host 2
192.168.1.1 192.168.1.2 192.168.1.3
Correct
Router 1
End host 1 End host 2
192.168.1.0/24 eth0: 192.168.1.2 192.168.2.0/24
eth0: 192.168.1.1 eth0: 192.168.2.2
eth1: 192.168.2.1
So, in a typical network, Routers are interconnected using their corresponding interfaces (e.g.,
eth0, eth1, eth2, etc. (these are just some common names for the routers’ interfaces)). Each of
these interfaces is assigned a corresponding IP address within the range of IP addresses available
for that subnet (e.g., 192.168.1.0/24 and 192.168.0.0/24). The IP addresses
connecting routers are also contained within a range of IP addresses of a subnet (as you can see
in the following example). So, by now you should really understand how IP addresses are
assigned to routers and subnetworks
Useful Tools
You will be searching around the network in the testbeds (i.e., around many Linux-based
machines (i.e., Raspberry PIs) and their routing (FRRouting)daemons) to determine various
bits of information (e.g., interface lists, routing tables, IP addresses, MAC addresses, and router
interfaces). The following tools will be essential for your search7.
NOTE: You will be running these tools from the PC mounted in the racks (the Racks’
computer), NOT from your laptop. You can use the Windows Command Window8 to execute
all the commands.
ifconfig -- You will be using it to examine the available network interfaces in a router. Just
type ifconfig at the command line and you will get a list of the network interfaces on the local
machine (e.g., Raspberry PI emulating a router). If an interface is active, you can see an Ethernet
MAC address, IPv4, and/or IPv6 addresses9 (if they exist), etc.
telnet -- Create a clear-text login shell on a remote machine. This program opens a TCP
connection to the local (i.e., localhost) or another computer. Anything you type will be
transmitted to the remote computer or daemon, and any response it displays will be transmitted
back to your computer and printed in the terminal. This lets you type commands that will be
executed on the remote computer and show the output in the local terminal window.
ssh -- Create a secure login shell on a remote machine. The "secure" portion of the name means
that the connection will be encrypted, allowing private communication over an insecure network.
Thus, ssh is an upgrade of telnet and should be used for most remote login applications (to
ensure connection encryption). An ssh connection can be used for basic terminal access (send,
execute, and examine commands to a remote machine), but can also transfer les, and tunnel
other applications.
7If you know nothing about these tools, my advice is to do a quick internet search to learn more about them before
going to the testbeds.
8 You can nd some useful information about the Windows CMD in this link
9 For this lab, you must only report the IPv4 addresses.
In this command, pi is the user name (in the Raspberry PIs). You will then be prompted for a
password. For all our Raspberry Pis, the password is pi. You may also be asked to verify a
server's certi cate by typing Yes.
The square brackets in the above command indicate that the -b parameter is optional. Do not
type those! But if you use this option, you should include the source_ip_address.
When you are done with an ssh session, type exit to log out and close down the connection.
The following list of commands is also going to be really useful in this lab:
ip route show
route -n
netstat -rn
Most importantly, you will want to look at the forwarding (“routing”) tables that have been
established at each router (in the testbed’s network). These commands give you some
information about the forwarding tables in various formats. The image below shows them in
use.
Source: https://www.tecmint.com/setup-linux-as-router/
Zebra
As discussed above, connecting to the zebra daemon will provide information about the
forwarding tables in RIP and BGP. You will need to use telnet for the connection, as the
zebra daemon cannot handle encrypted communications (as in ssh).
Use telnet localhost <PORT> to connect to the router interface (RIP or BGP) on the
speci ed port in a given localhost. As this has to be done from the local machine, you will
rst need to ssh into a particular Unix-based computer (e.g., Raspberry PI).
All daemons on all Raspberry Pis have the password zebra for you to access and send some
commands to the daemon.
To do anything more than view the routing tables on any daemon, you will need to add the en
option to enable the management interface which might ask you for the same password again.
Management interface commands are not required for checkpoint 1 (Lab 3a).
Remember the three port numbers for the three di erent types of router accesses: 2601 connects
to the zebra daemon. Port 2602 connects to the RIP router interface, and port 2605
connects to the BGP router interface. Here are some pictures of what you should see after
making such a connection. All this can be accessed using a telnet connection, once you are
connected (ssh) into the localhost (Linux-based machines) that contains the zebra
daemons.
Zebra Router (:2601)
Source: https://www.tecmint.com/setup-linux-as-router
Source: https://iplab.naist.jp/class/2019/materials/hands-on/03/dynamic-routing-2019.pdf
Source: http://xmodulo.com/centos-bgp-router-quagga.html
Where to Start
The network testbed (the “Rack”) hardware contains many devices (e.g., Raspberry PIs) acting
as routers by using the FRRouting application. The following routable public IP addresses
exist within the testbed:
• 1.0.0.1 (Loopback address to represent all hosts for subnet 1.0.0.0/8)
• 2.0.0.1 (Loopback address to represent all hosts for subnet 2.0.0.0/10)
• 2.64.0.1 (Loopback address to represent all hosts for subnet 2.64.0.0/10)
• 3.0.0.1 (Loopback address to represent all hosts for subnet 3.0.0.0/8)
• 3.0.0.2 (NAT10 for private subnet 192.168.0.0/24)
• 4.0.0.1 (Loopback address to represent all hosts for subnet 4.0.0.0/8)
• 5.0.0.1 (Loopback address to represent all hosts for subnet 5.0.0.0/8)
To investigate the network at the Rack and gure out the Network diagram of the network
testbed, you can ssh into one of the above IP addresses (e.g., ssh [email protected]). Once you
are connected to a Linux-based host (e.g., Raspberry Pi), you can rst use the ifconfig
command to discover the available interfaces in the router and their corresponding IP
addresses11. We are interested in the physical interfaces of the routers (e.g., eth0, eth1, etc.) as
this will guide you about the physical connections of the router to other routers in the network.
10 You are not required to analyze the NAT router for the rst part of this Lab (Checkpoint 1).
11 You can ignore the loopback interface (lo) in the routers.
The lo:1 interfaces can also help you identify the subnetwork information about the hosts that
could be connected to that router (i.e., the subnetwork information of the end hosts being served
by the router). You are NOT required to identify individual end hosts on the network. You are
only going to identify the router connection and the subnetwork connected to these routers.
Once you have discovered the interfaces in a router, it is time to start analyzing the forwarding
tables that each router contains. Some of the above commands (ip route show, route -n,
or netstat -rn) can help you nd out more about the connections of the localhost
(simulated router) that you are analyzing.
Then you can also access the IOS information (e.g., you can telnet to the di erent routing
daemons) to nd more information about the di erent, for example, forwarding (routing) tables
in BGP and RIP. To get useful information you can use some of the above commands (e.g.,
show ip route, show ip rip, or show ip bgp)12.
Finally, you can use ALL this information about a localhost to ssh into the next host (e.g.,
another router) in the network and repeat the process. This is an iterative process that you will
need to repeat multiple times until you have a clear picture of the network topology we have
implemented in the Racks. In other words, you will need to repeat this process for multiple hosts
in the Racks.
A piece of advice, every time you display something (e.g., forwarding table or IP information)
take a screenshot for your future analysis.
12 Please feel free to use any other RIP or BGP commands that you consider useful in these scenarios.
Questions
To answer these questions, you must use the provided PCAP le AND the aforementioned
tools to probe (examine) the routing network available at the testbed.
Answer the following ve (5) questions about the RIP routing in the Network Testbeds (the
“Racks):
1. (5 points) RIP response packets have elds for Metric, Next hop, Netmask, and
Destination IP addresses. Using the PCAP le, pick any RIP response packet and
list the values for each eld. Describe the purpose of each value and eld. Explain what is
the relationship between Netmask and network pre x. Then, lter by RIP packets and the
source IP address 2.128.13.1, and compare the rst and last response (of the ltered)
RIP packets, is there a di erence in the number of reported IP addresses? Why do you think
there is a di erence in the number of reported IP addresses between these two packets?
Using the last (of the ltered) RIP packet, answer how many hops there are between the
Router sending the response and the following subnetworks: 2.0.0.0/8,
2.128.23.0/24, and 24.0.0.0/8. How is this hop count calculated in RIP?
2. (7 points) For each of the RIP routers, provide a table showing the relationship between
interfaces, IP addresses, and MAC addresses. You may ignore the routers’ interfaces that do
not participate in RIP13.
3. (3 points) From all the routers participating in RIP, identify the border routers. How did
you identify them? What external IP addresses are learned by the border routers and
transmitted into the network (The border routers will take time to learn these external
routes and communicate them to the routers inside the AS)?
13 To better identify the routers, you might use any naming convention that you consider necessary.
4. (12 points) Draw the internal network structure (diagram) of the routers participating in
RIP. For each router, make sure to show the interface and IP address. For each subnet,
correctly state the address range in pre x notation.
5. (5 points) Two (2) neighboring RIP routers are vulnerable to a “count-to-in nity” situation
(Hint: think about the main source for the “count-to-in nity” problem (advertising a route
that was learned from a neighbor back to that neighbor) to nd these routers). Using the
packet list in the PCAP le, identify the routers and describe why these routers are
vulnerable to the issue.
Answer the following four (4) questions about the BGP routing in the Network Testbeds (the
“Racks):
6. (3 points) Using the PCAP le, identify and describe the iBGP connection(s). What routers
participate in this connection? Are these routers in the same subnet? If not, how are they able
to set up the iBGP session?
7. (7 points) For each of the BGP routers, provide a table showing the relationship between
interfaces, IP addresses, and MAC addresses. You may ignore the routers’ interfaces that do
not participate in BGP. For each router, also include the AS number (ASN) where the BGP
router is located14.
8. (12 points) Draw the BGP (eBGP and iBGP) network diagram. You do not have to show
the internal structure of the AS with RIP. For each border router, make sure to include the
interface and IP address on any external connections. For each link between ASes and
iBGP routers, list the subnet address range in pre x notation.
9. (6 points) Using only the BGP routing selection algorithm that we studied in class (Lecture
15) and your discovered network diagram (BGP), explain what path a packet sent from
1.0.0.5 to 5.14.74.1 would take through the networks (Hint: You will have to manually
nd the path based on the BGP routing selection algorithm that we studied in class and the
network topology you discovered). Assume that all BGP routers’ interfaces are accessible
and that all routes/paths have the same Local Preference value in AS1. Make sure to
explain your answer and each of the steps you took to determine the correct answer. What is
the deciding factor/step that helps you choose the best path/route between those two
addresses?
Turn-in
Write a report of your interactions and answer the questions. Make sure to include enough
details to ensure we understand that you understand what is going on. For instance,
screenshots should probably be annotated to show where a number came from -- do not
assume that because you know how to read a Wireshark screen we know that you know it.
Our graders will not make that assumption. So, prove it to us by describing/annotating
every value you nd.
Turn your answers into a PDF le and submit it to the Lab # 3a Checkpoint 1
Assignment on Gradescope.
14 To better identify the routers, you might use any naming convention that you consider necessary.