# Forwarding Between Routers The `one_rtr` topology is extremely simple and can get away with a lot because it is directly connected to all the hosts in the network. Configuring the subnets on the interfaces is enough to do all the routing it ever needs to do. What happens when we put one more router in between the two hosts? This is the [`two_rtrs` topology](../topology/two_rtrs). In the `one_rtr` topology, configuring IP addresses and default routes on the end-hosts by starting the `basic` scenario was enough for the two hosts to ping each other. This is not the case for `two_rtrs`. In this short lesson we go over the missing link. ## Using Wireshark to find the problem If you haven't guessed already, Wireshark is often the best tool to use for debugging any networking problem. Knowing where exactly your packet was lost will lead you to the source of the problem much faster. Start the `two_rtrs` topology in the `basic` scenario ``` sudo python route0.py --topology two_rtrs --scenario basic ``` and get `h1_1` to start sending pings to `h2_1`. The IP address you want to ping is `10.2.0.1` which you can verify with the `ip addr` command. The pings will fail which is expected. Now with the help of Wireshark let's trace the steps of the packet and find out where it is getting lost. As a reminder you can run Wireshark either directly from Mininet in the usual way you would run a command on a node or by using the `attach.py` script in a separate terminal window. Let's start with node `h1_1` to see if the ping request is being sent at all. Using the `attach.py`, in a new terminal window we run ``` sudo python attach.py --node h1_1 --cmd wireshark ``` In the Wireshark window we choose the `h1_1-eth1` interface and we see that the packets are being sent, but no responses being received. At least we know that the sender is working fine. Let's move to the next hop along the path, `R1`. Close the Wireshark window and re-open it on `R1`. Here we have two interfaces to monitor. From the [topology](../topology/two_rtrs) file we see that `R1-eth2` is the interface connected to `h1_1-eth1` so it would be the best place to start. We quickly find that this interface is also receiving packets as expected so at least know there is no fault on the connection between the host and the router. What do you see if you now move to the other interface on `R1`? It seems that our ping requests are being lost somewhere on `R1`. ## Adding a new route If a router receives packets, but does not forward them it is usually a sign that something is wrong with the routing table. Sure enough, if we inspect the routing table on `R1` using the `ip route` command we find that `R1` does not know how to reach `10.2.0.1`. In fact, it even tells `h1_1` about this. If you're patient and inspect the packet capture on `R1-eth2` in Wireshark for long enough you will spot an ICMP response packet notifying about an unreachable network. The source address is `R1` interface which shows us that this error does in fact originate at this router. The fix is pretty straightforward, we need to add an appropriate route to the routing table. But what is an appropriate route? The end-hosts don't have any trouble with their routing tables as they have a default route. A default route is the route chosen for a packet if there are no other more specific routes available. If we install such a default route pointing at `R2` it would solve our problem, but is this appropriate? What if we now added one more router to `R1`? A default route works for a host, because it only has one outgoing link, but a router will have multiple links so the choice of a default route is not such a simple thing to do. So what route do we install instead? If you look at `R2`, the route it has pointing at the `h2_1` host is a route for the `10.2.0.0/24` subnet. Therefore, we need to tell `R1` to forward all traffic for `10.2.0.0/24` via `R2`, because that router knows what to do next. This way when we connect another router we can simply add a similar route to `R1` for the subnets that `R3` knows about. This is in essence what a routing protocol does. Every node tells its neighbours which subnets it can reach so that they can install routes for those subnets pointing at that node. For a route we also need a next hop which is simply an IP address on the next router on the path. We want that next hop to unambiguously point at `R2`. Therefore, we cannot just point the route at the `R1-eth1` interface as it is possible to have more than one router connected to that local network. Instead we must point the route at the interface on `R2` that is connected to `R1`. Use `ip addr` or look up the topology file to find this IP address. Now it is finally time to add the route to `R1`. The command you need to run on `R1` is ``` ip route add 10.2.0.0/24 via ``` where you must decide what the `` should be. Note that installing this route won't immediately solve the ping problem. You will find the ping packet to be forwarded correctly, but no response will be sent. This is because you must install a similar route on `R2` pointing at the source subnet of the packets, `10.1.0.0/24` so that the response can also be forwarded correctly. It is left to you to figure out how to do this. Note that if you inspect the packet capture on `R2` before you install that route you will see that the ping request packets aren't being forwarded to `h2_1` even though the correct forwarding rules for the forward direction are installed. I am not actually sure what is happening, but my guess is that Linux might not be forwarding packets for which it doesn't recognise the source address. This might be a counter-measure to prevent attacks relying on source IP address spoofing. ## Conclusion With the reverse route installed you will now be seeing pings succeeding on `h1_1`. Success! In this lesson you learned how to route to subnets on other routers by installing routes that point at the next router on the path. This is what routing protocols do, but in an automated fashion. To learn how routing protocols work look out for lessons on configuring IS-IS.