Add lesson on forwarding between routers

lessons/README.md

@@ -3,3 +3,4 @@
 * [Introduction to Route 0](introduction-to-route-0.md)
 * [IP Addresses and Subnets](ip-addresses-and-subnets.md)
 * [Configuring Zebra and STATIC](configuring-zebra-and-static.md)
+* [Forwarding between Routers](forwarding-between-routers.md)

lessons/forwarding-between-routers.md

@@ -0,0 +1,122 @@
+# 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 <next-hop>
+```
+
+where you must decide what the `<next-hop>` 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.