CS640 Lab 3 Implementing ARP, ICMP, and RIP – Network Routing & Protocols

Important notes

• All answers and code that you write for this lab must be your own work. Plagiarism is a serious violation of university statutes and all answers will be thoroughly checked for it.

• Ensure that your answer has proper headings and subheadings wherever necessary.

• Late policy:

• Upto 30 minutes late — lose 0% of points

• Upto 24 hours late — lose 10% of points

• Upto 48 hours late — lose 30% of points

• Upto 72 hours late — lose 60% of points

• Beyond 72 hours — lose 100% of points

Overview

For this lab, you will modify your virtual router to:

1. Generate Internet Control Messaging Protocol (ICMP) messages when error conditions occur.
2. Populate the ARP cache by generating and consuming Address Resolution Protocol (ARP) messages.
3. Build a routing table using distance vector routing. With these changes, your virtual router will no longer depend on a static ARP cache or static route table, and it will be pingable and traceable.

https://pages.cs.wisc.edu/~mgliu/CS640/F22/labs/lab3/MACTable.java wget https://pages.cs.wisc.edu/~mgliu/CS640/F22/labs/lab3/MACTableEntry.java wget https://pages.cs.wisc.edu/~mgliu/CS640/F22/labs/lab3/Switch.java

For Router:

wget https://pages.cs.wisc.edu/~mgliu/CS640/F22/labs/lab3/RouteTable.java wget https://pages.cs.wisc.edu/~mgliu/CS640/F22/labs/lab3/Router.java

If you’ve forgotten the commands to start Mininet, POX, or your virtual router, you should refer back to Lab 2.

Note - Always execute run_pox.sh before executing run_mininet.py.

As you complete this lab, you may want to use tcpdump to examine the headers of packets sent/received by hosts. To run tcpdump on a specific host, open an xterm window:

mininet> xterm h1

Then start tcpdump in that xterm:

sudo tcpdump -n -vv -e -i h1-eth0

You’ll need to change the host number included in the interface (-i) argument to match the host on which you’re running tcpdump.

========================================================================

Part 2: Implement ICMP

For this part of the lab, you will add support for generating and responding to Internet Control Message Protocol (ICMP) messages. Details on the ICMP protocol are available from Network Sorcery's RFC Sourcebook. There are five different ICMP messages you need to generate.

Time exceeded

A time exceeded message must be sent whenever your virtual router discards a packet because the TTL field is 0. Your router should already have code that decrements the TTL field by 1 and checks if the field (after decrement) equals 0. You should update this portion of the code to generate an ICMP time exceeded message prior to dropping the packet whose TTL field is 0.

When the router generates ICMP messages for time exceeded (type 11, code 0), the packet must contain an Ethernet header, IP header, ICMP header, and ICMP payload. You can construct these headers, by creating Ethernet, IPv4, ICMP, and Data objects using the classes in the net.floodlightcontroller.packet package. To link the headers together, you should call the setPayload(..) method defined in the BasePacket class, which is the superclass for all of the header classes. Below is a snippet of code to get you started:

Ethernet ether = new Ethernet();

IPv4 ip = new IPv4();

ICMP icmp = new ICMP();

Data data = new Data();

ether.setPayload(ip);

ip.setPayload(icmp);

icmp.setPayload(data);

In the Ethernet header, you must populate the following fields:

• EtherType — set to Ethernet.TYPE_IPv4

• Source MAC — set to the MAC address of the out interface obtained by performing a lookup in the route table (invariably this will be the interface on which the original packet arrived)
• Destination MAC — set to the MAC address of the next hop, determined by performing a lookup in the route table followed by a lookup in the ARP cache

In the IP header, you must populate the following fields:

• TTL — set to 64

• Protocol — set to IPv4.PROTOCOL_ICMP

• Source IP — set to the IP address of the interface on which the original packet arrived

• Destination IP — set to the source IP of the original packet

In the ICMP header you must populate the following fields:

• Type — set to 11

• Code — set to 0

The payload that follows the ICMP header must contain: (1) 4 bytes of padding, (2) the original IP header from the packet that triggered the error message, and (3) the 8 bytes following the IP header in the original packet. This is illustrated in the figure below:

Once the ICMP packet is fully constructed, you should send it on the interface that is obtained from the longest prefix match in the route table for the source IP of the original packet (invariably this will be the interface on which the original packet arrived). You should drop the original packet after sending the time exceeded message.

You can verify you have implemented this correctly by running the traceroute command. You should traceroute from one host to another, and each router on the path between the hosts should show up in the traceroute once. Include the “-n” argument when you run traceroute, otherwise traceroute will try to convert IPs to hostnames using DNS which will generate spurious traffic and make traceroute slow. Below is example output produced using the single_rt topology:

mininet> h1 traceroute -n 10.0.2.102

traceroute to 10.0.2.102 (10.0.2.102), 30 hops max, 60 byte packets

1 10.0.1.1 153.720 ms 229.000 ms 228.789 ms

• 10.0.2.102 427.040 ms 426.764 ms 426.554 ms

Destination net unreachable

This message must be sent if there is no matching entry in the route table when forwarding an IP packet. Your router should already have code that drops a packet if there is no matching route entry. You should update this portion of the code to generate an ICMP destination net unreachable message prior to dropping the packet.

The destination net unreachable message should be constructed similar to the Network Sorcery's RFC Sourcebook.

Generating ARP Replies

You should first update your router to generate ARP replies in response to received ARP requests. Your router should currently drop all non-IP packets. You need to modify this part of your router’s code to accept ARP packets (i.e., the EtherType field in the Ethernet header equals Ethernet.TYPE_ARP) in addition to IP packets.

If an ARP packet is an ARP request (i.e., the opcode field in the ARP header equals ARP.OP_REQUEST), then your router may need to send an ARP reply. Your router must only respond to ARP requests whose target IP protocol address equals the IP address of the interface on which the ARP request was received. You can obtain the target protocol address from an ARP packet as follows:

ARP arpPacket = (ARP)etherPacket.getPayload();

int targetIp =

ByteBuffer.wrap(arpPacket.getTargetProtocolAddress()).getInt();

An ARP reply packet must contain an Ethernet header and an ARP header. You can construct these headers, by creating Ethernet and ARP objects using the classes in the net.floodlightcontroller.packet package. Remember to link the headers together using the setPayload(..) method defined in the BasePacket class.

In the Ethernet header, you must populate the following fields:

• EtherType — set to Ethernet.TYPE_ARP

• Source MAC — set to the MAC address of the interface on which the original packet arrived
• Destination MAC — set to the source MAC address of the original packet

In the ARP header, you must populate the following fields:

• Hardware type — set to ARP.HW_TYPE_ETHERNET

• Protocol type — set to ARP.PROTO_TYPE_IP

• Hardware address length — set to Ethernet.DATALAYER_ADDRESS_LENGTH

• Protocol address length — set to 4

• Opcode — set to ARP.OP_REPLY

• Sender hardware address — set to the MAC address of the interface on which the original packet arrived
• Sender protocol address — set to the IP address of the interface on which the original packet arrived
• Target hardware address — set to the sender hardware address from the original packet

• Target protocol address — set to the sender protocol address from the original packet

Once the ARP reply is fully constructed, you should send it on the same interface on which the original packet arrived.

You can verify you have implemented this correctly by excluding the -a argument when you call the run_mininet.py script. You should still specify the -a arp_cache argument when you start your virtual router. If you can successfully ping between hosts, and running arp -n on the hosts after running ping shows some ARP cache entries on the host, then you have successfully implemented ARP replies.

Generating ARP Requests

ARP requests are more challenging to implement because your router must queue packets while waiting for a reply. Your router should currently call the lookup(...) function the ARPCache class when forwarding packets, and if no entry is found, generate a destination host unreachable ICMP message and drop the packet. You should modify your router to instead enqueue the packet and generate an ARP request if no matching entry is found in the ARP cache. Also, you should no longer generate a RFC2453 and Network Sorcery's RFC Sourcebook. If you’re not sure how distance vector routing works, you should read Section 3.3.2 of the textbook or the lecture slides on distance vector routing.

Starting RIP

Your router should only run RIP when a static route table is not provided (via the -r argument when running VirtualNetwork.jar). You should update Main.java and/or Router.java to appropriately start RIP.

When your router starts, you should add entries to the route table for the subnets that are directly reachable via the router’s interfaces. These subnets can be determined based on the IP address and netmask associated with each of the router’s interfaces. These entries should have no gateway.

RIP Packets

The RIPv2 and RIPv2Entry classes in the net.floodlightcontroller.packet package define the format for RIPv2 packets. All RIPv2 packets should be encapsulated in UDP packets whose source and destination ports are 520 (defined as a constant RIP_PORT in the UDP class). When sending RIP requests and unsolicited RIP responses, the destination IP address should be the multicast IP address reserved for RIP (224.0.0.9) and the destination Ethernet address should be the broadcast MAC address (FF:FF:FF:FF:FF:FF). When sending a RIP response for a specific RIP request, the destination IP address and destination Ethernet address should be the IP address and MAC address of the router interface that sent the request.

RIP Operation

Your router should send a RIP request out of all of the router’s interfaces when RIP is initialized. Your router should send an unsolicited RIP response out all of the router’s interfaces every 10 seconds thereafter.

You should update the handlePacket(...) method in the Router class to check if an arriving IP packet has a destination 224.0.0.9, a protocol type of UDP, and a UDP destination port of 520. Packets that match this criteria are RIP requests or responses. Your router should update its route table based on these packets, and send any necessary RIP response packets.

Your router should time out route table entries for which an update has not been received for more than 30 seconds. You should never remove route entries for the subnets that are directly reachable via the router’s interfaces .

Your implementation does not need to be a complete standards-compliant implementation of RIPv2. You should implement basic distance vector routing as discussed in the textbook and in-class, using RIPv2 packets as the format for messages exchanged between routers.

Testing RIP

To test your router’s control plane, you will need a topology with more than one router: pair_rt.topo, triangle_rt.topo, triangle_with_sw.topo, or linear5.topo. You should not include the -r argument when starting your routers, since your router should construct its route table using RIP, rather than using a statically provided route table.

========================================================================

Submission Instructions

You must submit a single tar file of the src directory containing the Java source files for your virtual switch and router. Please submit the entire src directory; do not submit any other files or directories. To create the tar file, run the following command, replacing username1 and username2 with the CS username of each group member:

tar czvf username1_username2.tgz src

IMPORTANT: username1 and username2 should be CS username, not NET ID

Upload the tar file to the Lab3 tab on Canvas . Please submit only one tar file per group.