mirror of
https://github.com/Wojtek242/route0.git
synced 2024-11-21 23:05:24 +01:00
Bunch of fixes to the lessons
This commit is contained in:
parent
8aa98e7460
commit
18c4d07f6f
@ -6,13 +6,12 @@ Linux, and Wireshark.
|
|||||||
## Topology
|
## Topology
|
||||||
|
|
||||||
First, let's look at the topology that we will be using for this lesson, the
|
First, let's look at the topology that we will be using for this lesson, the
|
||||||
`one_rtr` topology. You can view it in this its
|
[`one_rtr` topology](../topology/one_rtr). The network is very
|
||||||
[README](../topology/one_rtr/README.md). The network is very simple. It
|
simple. It consists of three nodes, but only one of them, `R1`, is a router,
|
||||||
consists of three nodes, but only one of them, `R1`, is a router, hence the
|
hence the name of the topology. The other two are end-hosts. A host is not
|
||||||
name of the topology. The other two are end-hosts. A host is not necessarily
|
necessarily a different device to a router, but it has a very different role in
|
||||||
a different device to a router, but it has a very different role in the
|
the network. A host will only have one outgoing link and it will not forward
|
||||||
network. A host will only have one outgoing link and it will not forward IP
|
IP packets which means that it can only be the source or destination of IP
|
||||||
packets which means that it can only be the source or destination of IP
|
|
||||||
communication. The convention in Route 0 is to name routers with a name that
|
communication. The convention in Route 0 is to name routers with a name that
|
||||||
starts with the letter `R` and hosts with a name starting with `h`.
|
starts with the letter `R` and hosts with a name starting with `h`.
|
||||||
|
|
||||||
@ -24,8 +23,7 @@ sudo python route0.py --topology one_rtr --scenario basic
|
|||||||
This command instructs the driver script `route0.py` to start a network with
|
This command instructs the driver script `route0.py` to start a network with
|
||||||
the `one_rtr` topology running the `basic` scenario. The `basic` scenario is
|
the `one_rtr` topology running the `basic` scenario. The `basic` scenario is
|
||||||
special and simply means to run the network and set up all the interface
|
special and simply means to run the network and set up all the interface
|
||||||
addresses and default routes. We will go over what this means later in this
|
addresses and default routes.
|
||||||
lesson.
|
|
||||||
|
|
||||||
Once the CLI prompt appears let us inspect Mininet's representation of the
|
Once the CLI prompt appears let us inspect Mininet's representation of the
|
||||||
network by running
|
network by running
|
||||||
@ -35,7 +33,7 @@ net
|
|||||||
in the command prompt. The output tells us about all the nodes in the network
|
in the command prompt. The output tells us about all the nodes in the network
|
||||||
and the connections between them. We can see that `R1`'s `R1-eth1` interface
|
and the connections between them. We can see that `R1`'s `R1-eth1` interface
|
||||||
is connected to `h1_1`'s `h1_1-eth1` interface and `R1-eth2` is connected to
|
is connected to `h1_1`'s `h1_1-eth1` interface and `R1-eth2` is connected to
|
||||||
`h1_2`'s `h1_2-eth1` interface. You can visualise the network by copy pasting
|
`h1_2`'s `h1_2-eth1` interface. You can visualise the network by copy-pasting
|
||||||
the output into this [web
|
the output into this [web
|
||||||
tool](https://achille.github.io/mininet-dump-visualizer/) though its usefulness
|
tool](https://achille.github.io/mininet-dump-visualizer/) though its usefulness
|
||||||
is limited for small networks such as this.
|
is limited for small networks such as this.
|
||||||
@ -73,8 +71,8 @@ will notice that the `lo` interface on `R1` actually has two IP addresses.
|
|||||||
The `ip route` command is used to list all the routes installed on a particular
|
The `ip route` command is used to list all the routes installed on a particular
|
||||||
node. The basic format of a route is `x.x.x.x/y via z.z.z.z` which says that
|
node. The basic format of a route is `x.x.x.x/y via z.z.z.z` which says that
|
||||||
to reach the IP network `x.x.x.x/y` you must go via the address `z.z.z.z` which
|
to reach the IP network `x.x.x.x/y` you must go via the address `z.z.z.z` which
|
||||||
should resolve to a directly connected neighbour. Note that you won't see such
|
should belong to an interface on a directly connected neighbour. Note that you
|
||||||
routes in this network setup, because the network is too simple.
|
won't see such routes in this network setup, because the network is too simple.
|
||||||
|
|
||||||
The host nodes have a default route installed which looks like `default via
|
The host nodes have a default route installed which looks like `default via
|
||||||
z.z.z.z` which means that the node should route all traffic it doesn't have a
|
z.z.z.z` which means that the node should route all traffic it doesn't have a
|
||||||
@ -87,8 +85,9 @@ network connected to the interface `if-name`.
|
|||||||
### ping
|
### ping
|
||||||
|
|
||||||
The command `ping` sends a special IP packet to the specified destination to
|
The command `ping` sends a special IP packet to the specified destination to
|
||||||
verify connectivity with that end-host. Try sending a ping from `h1_1` to an
|
verify connectivity with that end-host. Connectivity is verified if a response
|
||||||
IP address on `h1_2` by running
|
is received. Try sending a ping from `h1_1` to an IP address on `h1_2` by
|
||||||
|
running
|
||||||
```
|
```
|
||||||
h1_1 ping 10.2.0.1
|
h1_1 ping 10.2.0.1
|
||||||
```
|
```
|
||||||
@ -101,17 +100,17 @@ because it is directly connected to both of them.
|
|||||||
|
|
||||||
## Wireshark
|
## Wireshark
|
||||||
|
|
||||||
Before moving on to the next section it would be good to introduce a
|
Before moving on to the next lesson it would be good to introduce a
|
||||||
particularly useful tool in studying networks, Wireshark, by using it to look
|
particularly useful tool in studying networks, Wireshark, by using it to look
|
||||||
at pings from `h1_1` to `h1_2`. Wireshark is a tool that lets you capture and
|
at pings from `h1_1` to `h1_2`. Wireshark is a tool that lets you capture and
|
||||||
inspect packets sent and received over all interfaces on a device.
|
inspect packets sent and received over all interfaces on a device.
|
||||||
Furthermore, it is able to present them in a human readable form rather than
|
Furthermore, it is able to present them in a human readable form rather than
|
||||||
simply dumping the binary representation directly from the wire.
|
simply dumping the binary representation directly from the wire.
|
||||||
|
|
||||||
Start by running the command to trigger `h1_1` to start sending pings to
|
Start by running the command to trigger `h1_1` to send pings to `h1_2`. Now
|
||||||
`h1_2`. Now open a new terminal window and navigate to the `route0` directory.
|
open a new terminal window and navigate to the `route0` directory. We will use
|
||||||
We will use the `attach.py` helper script to run Wireshark on `R1` and `h1_2`.
|
the `attach.py` helper script to run Wireshark on `R1` and `h1_2`. Let's start
|
||||||
Let's start with `R1` by running
|
with `R1` by running
|
||||||
```
|
```
|
||||||
sudo python attach.py --node R1 --cmd wireshark
|
sudo python attach.py --node R1 --cmd wireshark
|
||||||
```
|
```
|
||||||
@ -123,12 +122,12 @@ connected to `h1_2`, the source of the packets. You can either double-click on
|
|||||||
the interface name or select the appropriate button on the menu bar in the
|
the interface name or select the appropriate button on the menu bar in the
|
||||||
top-left corner.
|
top-left corner.
|
||||||
|
|
||||||
Once the packet capture notice how the ping packets appear every second as a
|
Once the packet capture window opens notice how the ping packets appear every
|
||||||
request/reply pair. Look at the source and destination IP addresses as well.
|
second as a request/reply pair. Look at the source and destination IP
|
||||||
Note how the originating node has filled out the source address with the
|
addresses as well. Note how the originating node has filled out the source
|
||||||
address of its interface `h1_2-eth1` and how the reply has the addresses
|
address with the address of its interface `h1_1-eth1` and how the reply has the
|
||||||
flipped around. Have a look around and inspect the contents if you wish, but
|
addresses flipped around. Have a look around and inspect the contents if you
|
||||||
we won't go into any detail on the form of the ping packets.
|
wish, but we won't go into any detail on the format of the ping packets.
|
||||||
|
|
||||||
Now let's look at the packet capture on the other interface on `R1`. You can
|
Now let's look at the packet capture on the other interface on `R1`. You can
|
||||||
do this by stopping the current capture, finding the capture options button and
|
do this by stopping the current capture, finding the capture options button and
|
||||||
@ -147,7 +146,6 @@ This will shut down all the nodes and protocols that are running.
|
|||||||
|
|
||||||
## Conclusion
|
## Conclusion
|
||||||
|
|
||||||
In this lesson you learned how to start up Route 0 experiments and learned how
|
In this lesson you learned how to start Route 0 experiments and learned how to
|
||||||
to inspect your network using basic Linux commands and Wireshark. You will
|
inspect your network using basic Linux commands and Wireshark. You will find
|
||||||
find these tools will come in handy at all times whenever dealing with
|
these tools will come in handy at all times whenever dealing with networks.
|
||||||
networks.
|
|
||||||
|
@ -24,27 +24,27 @@ Start by having a look around using the commands you learned in the previous
|
|||||||
lesson, `ip address` and `ip route`, and notice how none of the addresses or
|
lesson, `ip address` and `ip route`, and notice how none of the addresses or
|
||||||
routes are present on any of the nodes. Furthermore, if you try running the
|
routes are present on any of the nodes. Furthermore, if you try running the
|
||||||
pings between any of the nodes, you will find they do not work and fail with a
|
pings between any of the nodes, you will find they do not work and fail with a
|
||||||
`Network is unreachable error`. In this lesson we will manually reconstruct
|
`Network is unreachable` error. In this lesson we will manually reconstruct
|
||||||
the `basic` network to illustrate all the different concepts involved.
|
the `basic` network to illustrate all the different concepts involved.
|
||||||
|
|
||||||
### Assigning IP addresses
|
### Assigning IP addresses
|
||||||
|
|
||||||
A good place to start would be to simply assign all the IP addresses as per the
|
A good place to start would be to simply assign all the IP addresses as per the
|
||||||
`one_rtr` topology [README](../topology/one_rtr/README.md). The command to
|
[`one_rtr` topology](../topology/one_rtr). The command to assign an IP address
|
||||||
assign an IP address to an interface in Linux has the form
|
to an interface in Linux has the form
|
||||||
```
|
```
|
||||||
ip address add [ip]/[mask-digits] dev [if-name]
|
ip address add <ip>/<mask-digits> dev <if-name>
|
||||||
```
|
```
|
||||||
|
|
||||||
This command assigns the address `ip` associated with the subnet defined by the
|
This command assigns the address `<ip>` associated with the subnet defined by
|
||||||
`mask-digits` to the interface `if-name`. This should be pretty
|
the `<mask-digits>` to the interface `<if-name>`. This should be pretty
|
||||||
self-explanatory except for the subnet which may be a new concept for some of
|
self-explanatory except for the subnet which may be a new concept for some of
|
||||||
you.
|
you.
|
||||||
|
|
||||||
An IPv4 address is basically a 32-bit number. The common representation
|
An IPv4 address is a 32-bit number. The common representation `x.x.x.x` simply
|
||||||
`x.x.x.x` simply splits this number into four 8-bit numbers making it more
|
splits this number into four 8-bit numbers making it more readable for a human.
|
||||||
readable for a human. This is why none of the four numbers ever exceed 255 as
|
This is why none of the four numbers ever exceed 255 as that is the largest
|
||||||
that is the largest number you can represent with 8 bits.
|
number you can represent with 8 bits.
|
||||||
|
|
||||||
A subnet is a subdivision of an IP network and determines all the possible IP
|
A subnet is a subdivision of an IP network and determines all the possible IP
|
||||||
addresses that can be connected directly to each other over a local network.
|
addresses that can be connected directly to each other over a local network.
|
||||||
@ -54,8 +54,8 @@ subnet means that we can communicate with all the other addresses in that
|
|||||||
subnet by using this interface.
|
subnet by using this interface.
|
||||||
|
|
||||||
The subnet of an IP address is determined by its prefix. The length in bits of
|
The subnet of an IP address is determined by its prefix. The length in bits of
|
||||||
the prefix is determine by the `mask-digits.`. Thus, the IP address
|
the prefix is determine by the `mask-digits`. Thus, the IP address
|
||||||
`10.11.12.13/24` belongs to a subnet defined by its first 24 bits, that is
|
`10.11.12.13/24` belongs to a subnet defined by its first 24 bits,
|
||||||
`10.11.12.0/24`. The router will now forward all traffic to any IP address on
|
`10.11.12.0/24`. The router will now forward all traffic to any IP address on
|
||||||
this subnet, such as `10.11.12.1` or `10.11.12.165`, over this interface.
|
this subnet, such as `10.11.12.1` or `10.11.12.165`, over this interface.
|
||||||
|
|
||||||
@ -89,7 +89,7 @@ example we only have `10.1.0.1` and `10.1.0.254` on the network on the subnet
|
|||||||
`10.1.0.0/24` which is effectively a local network of one point-to-point link.
|
`10.1.0.0/24` which is effectively a local network of one point-to-point link.
|
||||||
|
|
||||||
Try pinging `10.100.0.5` and `10.1.0.5` from `h1_1`. Notice how both fail, but
|
Try pinging `10.100.0.5` and `10.1.0.5` from `h1_1`. Notice how both fail, but
|
||||||
only the first one returns the `Network is unreachable error`. Why does the
|
only the first one returns the `Network is unreachable` error. Why does the
|
||||||
second one appear to be stuck? Since `10.1.0.5` belongs to the same subnet as
|
second one appear to be stuck? Since `10.1.0.5` belongs to the same subnet as
|
||||||
`h1_1-eth1` the host tries to send the ping over this interface, but as the
|
`h1_1-eth1` the host tries to send the ping over this interface, but as the
|
||||||
other end does not exist, the response never arrives.
|
other end does not exist, the response never arrives.
|
||||||
@ -102,21 +102,22 @@ sudo python attach.py --node h1_1 --cmd wireshark
|
|||||||
```
|
```
|
||||||
and start a packet capture on the `h1_1-eth1` interface.
|
and start a packet capture on the `h1_1-eth1` interface.
|
||||||
|
|
||||||
The first thing you will notice is how `h1_1` keeps send ARP protocol messages.
|
The first thing you will notice is how `h1_1` keeps sending ARP protocol
|
||||||
ARP stands for the Address Resolution Protocol and is the mechanism by which a
|
messages. ARP stands for the Address Resolution Protocol and is the mechanism
|
||||||
node finds the MAC address of the interface associated with the particular IP
|
by which a node finds the MAC address of the interface associated with the
|
||||||
address. In order to send a packet over a link it must be addressed to the
|
particular IP address. In order to send a packet over a link it must be
|
||||||
right MAC address as otherwise no interface on the local network will pick the
|
addressed to the right MAC address as otherwise no interface on the local
|
||||||
packet up. In this case we see packets constantly asking "Who has 10.1.0.5?
|
network will pick up the packet. In this case we see packets constantly asking
|
||||||
Tell 10.1.0.1", but nobody owns that IP address so nobody responds.
|
"Who has 10.1.0.5? Tell 10.1.0.1", but nobody owns that IP address so nobody
|
||||||
|
responds.
|
||||||
|
|
||||||
Let's now look at what happens when the IP address exists on the network. Set
|
Let's now look at what happens when the IP address exists on the network. Set
|
||||||
`h1_1` to ping the other end of its link `10.1.0.254` (you don't have to close
|
`h1_1` to ping the other end of its link `10.1.0.254` (you don't have to close
|
||||||
wireshark). Most of the packets sent and received will be the already known
|
Wireshark). Most of the packets sent and received will be the already known
|
||||||
ping packets, but every now and then an ARP request is sent. However, this
|
ping packets, but every now and then an ARP request is sent. However, this
|
||||||
time `h1_1` receives a response telling it the MAC address of the interface.
|
time `h1_1` receives a response telling it the MAC address of the interface.
|
||||||
If you inspect the ping packets that originate at `h1_1` you will notice that
|
If you inspect the ping packets that originate at `h1_1` you will notice that
|
||||||
they do use that MAC address in the Ethernet header.
|
they do use that MAC address as the destination in the Ethernet header.
|
||||||
|
|
||||||
You may wonder why do the nodes need to do this? After all the IP address
|
You may wonder why do the nodes need to do this? After all the IP address
|
||||||
already uniquely identifies the interface. This is because the IP protocol
|
already uniquely identifies the interface. This is because the IP protocol
|
||||||
@ -134,8 +135,8 @@ ping `10.2.0.1` from `h1_1` you will be told that the network is unreachable.
|
|||||||
If you look at the output of `ip route` on the host this error makes sense.
|
If you look at the output of `ip route` on the host this error makes sense.
|
||||||
The routing table doesn't know how to reach any subnet other than
|
The routing table doesn't know how to reach any subnet other than
|
||||||
`10.1.0.0/24`. We could just add a route for the `10.2.0.0/24` subnet to go
|
`10.1.0.0/24`. We could just add a route for the `10.2.0.0/24` subnet to go
|
||||||
via `R1` to `h1_1` which would work for `h1_2`, but would fail as soon as any
|
via `R1` which would work for `h1_2`, but would fail as soon as any new host is
|
||||||
new host is added to `R1`.
|
added to `R1`.
|
||||||
|
|
||||||
Instead we will add a default route to our host. A default route is the route
|
Instead we will add a default route to our host. A default route is the route
|
||||||
used for IP addresses that do not match any other more specific route. To add
|
used for IP addresses that do not match any other more specific route. To add
|
||||||
@ -153,26 +154,29 @@ the local network, but in principle we could have more. In that case,
|
|||||||
specifying an interface would not uniquely identify the next hop.
|
specifying an interface would not uniquely identify the next hop.
|
||||||
|
|
||||||
Try pinging `10.2.0.1` from `h1_1` now. You will notice that it no longer
|
Try pinging `10.2.0.1` from `h1_1` now. You will notice that it no longer
|
||||||
fails with a "Network unreachable error", but it still doesn't work. Let's
|
fails with a `Network is unreachable` error, but it still doesn't work. Let's
|
||||||
investigate using Wireshark. If you inspect the traffic at `h1_1` you will
|
investigate using Wireshark. If you inspect the traffic at `h1_1` you will
|
||||||
notice that the requests are being sent, but no responses are received. Let's
|
notice that the requests are being sent, but no responses are received. Let's
|
||||||
check if `R1` is forwarding the packets. If you launch Wireshark on `R1` you
|
check if `R1` is forwarding the packets. If you launch Wireshark on `R1` you
|
||||||
will notice that the packets are received on one interface and are forwarded to
|
will notice that the packets are received on one interface and are forwarded to
|
||||||
the other. If you also inspect `h1_2` you will find that the request packets
|
the other so that's not it. If you also inspect `h1_2` you will find that the
|
||||||
actually manage to make their way to the destination, but no response is sent.
|
request packets do manage to make their way to the destination, but still no
|
||||||
|
response is sent.
|
||||||
|
|
||||||
Can you figure out what's going on? What happens if you try pinging `h1_1`'s
|
Can you figure out what's going on? What happens if you try pinging `h1_1`'s
|
||||||
interface from `h1_2`?
|
interface from `h1_2`?
|
||||||
|
|
||||||
The problem is that `h1_2` doesn't have a default route itself. It receives
|
The problem is that `h1_2` doesn't have a default route itself. It receives
|
||||||
the ping packets and it tries to send a response back to source IP address, but
|
the ping packets and it tries to send a response back to the source IP address,
|
||||||
then it finds out it doesn't know how which way to send a packet to that IP
|
but then it finds out it doesn't know what to do with a packet addressed to
|
||||||
address. The solution is to install a default route just like we did for
|
that IP address. The solution is to install a default route just like we did
|
||||||
`h1_1`. Once installed you will notice that pings from `h1_1` now succeed.
|
for `h1_1`. Once installed you will notice that pings from `h1_1` now succeed.
|
||||||
|
|
||||||
## Conclusion
|
## Conclusion
|
||||||
|
|
||||||
In this lesson you learned how to assign IP addresses to interfaces, what
|
At this point you should have the same network as was for the `basic` scenario.
|
||||||
subnet is and how it is used in routing, and you also learned how to install
|
By building this network manually you learned how to assign IP addresses to
|
||||||
default routs on hosts. With these foundations we can move on to more complex
|
interfaces, what a subnet is and how it is used in routing, and you also
|
||||||
routing where not all hosts are directly connected to the same router.
|
learned how to install default routes on hosts. With these foundations we can
|
||||||
|
move on to more complex routing where not all hosts are directly connected to
|
||||||
|
the same router.
|
||||||
|
Loading…
Reference in New Issue
Block a user