mirror of
https://github.com/Wojtek242/route0.git
synced 2024-10-29 21:40:50 +01:00
254 lines
12 KiB
Markdown
254 lines
12 KiB
Markdown
# Routing Protocol Basics
|
|
|
|
In [another lesson](forwarding-between-routers.md) lesson we achieved
|
|
connectivity between two hosts by setting up static routes in the network.
|
|
This method can work for small networks of a few routers that don't change
|
|
much, but would quickly become unmanageable in a larger network, especially if
|
|
you want your network to manage failures. In this lesson we use the same
|
|
[simple topology of two routers](../topology/two_rtrs), but this time we set up
|
|
the routing protocol IS-IS between the two routers.
|
|
|
|
## The basics
|
|
|
|
### Routing vs. forwarding
|
|
|
|
A common source of confusion is the distinction between routing and forwarding.
|
|
Forwarding is the action a router performs to a packet to transfer it from its
|
|
input interface to the output interface. The decision of which output
|
|
interface to use is made with the help of a routing table which maps the
|
|
destination IP address of a packet to an output interface. The routing table
|
|
can be manually configured just like we did in other lessons or it can be
|
|
managed by a routing protocol.
|
|
|
|
### Routing protocols
|
|
|
|
A routing protocol manages the communication between the routers in a network
|
|
to distribute information about paths to different IP subnets. It will
|
|
automatically discover neighbours, distribute its own connectivity information,
|
|
and calculate routes based on information received from its peers. There are
|
|
two ways in which this can be achieved. In distance vector routing the router
|
|
learns about its neighbours' routing tables and builds its own table based on
|
|
that information. This process is referred to as "routing by rumour". The
|
|
alternative is link state routing. In link state routing each router builds
|
|
its internal map of the entire network and calculates the best route based on
|
|
this map. You can read more about their differences
|
|
[online](https://techdifferences.com/difference-between-distance-vector-routing-and-link-state-routing.html).
|
|
|
|
## Setting up a routing protocol
|
|
|
|
### IS-IS
|
|
|
|
The routing protocol we will use is IS-IS which is an acronym for Intermediate
|
|
System to Intermediate System. The IS-IS protocol was defined by ISO,
|
|
independently of the IETF which defines the TCP/IP protocols, and thus its own
|
|
definition and specification is independent of IP and other IETF terminology
|
|
and definitions. For example, "intermediate system" is simply ISO's
|
|
nomenclature for router so the name IS-IS simply means router to router.
|
|
|
|
IS-IS is a link-state routing protocol and it uses Dijkstra's shortest path
|
|
algorithm for computing the best paths in the network.
|
|
|
|
### Start the network
|
|
|
|
For this lesson we will run the `routing_basics` scenario in the `two_rtrs`
|
|
topology
|
|
|
|
```
|
|
sudo python route0.py --topology two_rtrs --scenario routing_basics
|
|
```
|
|
|
|
The `routing_basics` scenario is just the `basic` scenario, but it also starts
|
|
the `isisd` daemon on the two routers though it does not configure the
|
|
protocol.
|
|
|
|
Start by inspecting the state of the network using the `ip addr` and `ip route`
|
|
commands. Verify that you are unable to ping `h2_1` from `h1_1` and vice
|
|
versa.
|
|
|
|
Before we start configuring the protocol, let's also open Wireshark to capture
|
|
the packets between `R1` and `R2`. In a separate terminal run
|
|
|
|
```
|
|
sudo python attach.py --node R1 --cmd wireshark
|
|
```
|
|
|
|
We will want to closely inspect what messages the protocol sends to each other
|
|
so let's inspect packets on `R1-eth1`. At first, even though `isisd` is up it
|
|
won't be sending any messages. There may be some other background noise,
|
|
notably from ICMPv6 which we can ignore.
|
|
|
|
### Configuring the IS-IS router
|
|
|
|
In order to configure the IS-IS protocol, let's connect to its daemon on `R1`.
|
|
In a new terminal run
|
|
|
|
```
|
|
sudo python attach.py --node R1 --daemon isisd
|
|
```
|
|
|
|
and enable protocol configuration by running `enable` (password is `route0`
|
|
for everything) followed by `configure terminal`.
|
|
|
|
The first thing we need to do is to configure the IS-IS process. Currently
|
|
only the daemon is running, but the daemon is not running any instances of the
|
|
IS-IS protocol so we need to start one. The first command to run is
|
|
|
|
```
|
|
router isis ROUTE0
|
|
```
|
|
|
|
where `ROUTE0` is simply the name we chose for the IS-IS process. This drops
|
|
us into the `config-router` context in which we adjust the settings for the
|
|
process. We must set a Network Entity Title (NET). We will set it to
|
|
`49.0001.0100.0000.0001.00` with the command
|
|
|
|
```
|
|
net 49.0001.0100.0000.0001.00
|
|
```
|
|
|
|
Since IS-IS was not built exclusively for IP addresses, the NET is not an IP
|
|
address. It is beyond the scope of this lesson to explain the full details of
|
|
how to assign a NET, but we will go over the basics. The first two digits `49`
|
|
identify this network as a private network. Together with the next four
|
|
digits, `0001`, they identify the area in the network. IS-IS has a two level
|
|
hierarchy where routers can be assigned to different areas. The next 12
|
|
digits, `0100.0000.0001` are the router ID and it is the binary-coded decimal
|
|
form of the router's loopback address. The last two digits always have to be
|
|
`00` to specify that this NET is referring to the current system.
|
|
|
|
We mentioned that IS-IS has a two level hierarchy. Level 1 is used for routing
|
|
within an area and level 2 is used for inter-area routing. Our network is too
|
|
small to concern ourselves with multiple levels so we will configure our
|
|
protocol to use level 2. We choose level 2 instead of level 1 as this way it
|
|
is easier to extend the network in the future to two levels. To do this we run
|
|
|
|
```
|
|
is-type level-2-only
|
|
```
|
|
|
|
We can now exit the `router` context by running `exit`.
|
|
|
|
## Adding interfaces
|
|
|
|
If you now look at the packet capture you will see that nothing has happened
|
|
yet even though we just setup a routing process. The routing protocol isn't
|
|
sending any messages, because we haven't told it which interface to include and
|
|
use for routing. Let's add `R1-eth1` as that's the interface connected to
|
|
`R2`. For this we start in the configuration terminal (re-run the commands
|
|
from before up to `configure terminal` if your connection timed out) and enter
|
|
the interface context
|
|
|
|
```
|
|
interface R1-eth1
|
|
```
|
|
|
|
and we attach this interface to the IS-IS we started in the previous step with
|
|
|
|
```
|
|
ip router isis ROUTE0
|
|
```
|
|
|
|
If you now go to Wireshark you will see IS-IS sending packets! Specifically,
|
|
it will be sending HELLO packets. HELLO packets are a standard mechanism for
|
|
protocols to notify its peers about their presence and hopefully they will hear
|
|
a HELLO back. Currently we only have IS-IS configured on `R1` so the HELLOs
|
|
are only sent in one direction. Have a quick look in Wireshark at what
|
|
information is included in the HELLO.
|
|
|
|
In order to get HELLOs in the other direction we need to repeat the same steps
|
|
for `R2`. The commands are identical, but the NET must be different. The
|
|
router ID must obviously be different, but since we are also running only at
|
|
level 2 we need to also assign a different area ID. A good value for `R2`'s
|
|
NET is `49.0002.0100.0000.0002.00`. Now setup IS-IS on the other side and add
|
|
the interface connected to `R1` to the protocol.
|
|
|
|
Once you finish setting up the other router you will start seeing HELLOs being
|
|
sent in both directions (you can tell, because the system ID and source MAC
|
|
address are different). This will allow the protocols to establish so called
|
|
adjacencies which simply means they connect with each other and establish some
|
|
state for their interactions.
|
|
|
|
Great! So now we have a routing protocol running on `R1` and `R2` and they're
|
|
talking to each other. Let's try pinging between the hosts.
|
|
|
|
### Link-State Packets
|
|
|
|
Unfortunately, as you will find out the two end-hosts still cannot find each
|
|
other. A closer inspection of the routing table on the routers will show that
|
|
they haven't actually shared their entire routing tables. Let's investigate
|
|
the Wireshark packet capture to see what they actually are sharing.
|
|
|
|
IS-IS shares link-state information with other routers using Link-State Packets
|
|
(LSPs) so we need to look for those in the packet capture. Unfortunately, it
|
|
doesn't send many of those (as it doesn't need to) compared to the amount of
|
|
HELLOs it sends so it may be quite hard to find them manually. Fortunately,
|
|
Wireshark has a filter box at the top and we can simply filter on `isis.lsp`
|
|
which will then show us only IS-IS LSPs. Wireshark's filter mechanism is very
|
|
powerful and is worth experimenting with in your own time.
|
|
|
|
There's a lot of information in these packets, but we can ignore most of it.
|
|
Open the `Link State Protocol Data Unit` section and at the bottom there will
|
|
be `Extended IP Reachability` (note that not all LSPs will have this so find
|
|
those that do). Expand that group and all groups within. Here we find all the
|
|
IP subnets advertised by the routing protocol. It shouldn't take too long to
|
|
spot the problem now. Only the `10.0.1.0/24` subnet is being shared which is
|
|
the subnet between the two routers. `R1` and `R2` are not telling each other
|
|
about their other interfaces.
|
|
|
|
At this point you may remember that we only added one interface on each router
|
|
to the IS-IS process. How is the protocol supposed to know which of the other
|
|
subnets it needs to advertise? It could advertise all of the ones it knows
|
|
about, but that may be undesirable. The solution is to instead simply add the
|
|
other interface which we want IS-IS to include in its map of the network to the
|
|
IS-IS process on each router. This way the IS-IS process will include that
|
|
interface's subnet in its messages as well as any other subnet it learns over
|
|
that link.
|
|
|
|
However, when we added the first interface the router started sending HELLO
|
|
packets immediately and in we don't really want that on the link with the hosts.
|
|
We just want to add the interfaces for IS-IS to advertise, but we don't want it
|
|
to be talking over that link. To achieve this we simply set the interface to
|
|
passive mode. The commands you need to run on `R1` once you're in the
|
|
`configure terminal` are
|
|
|
|
```
|
|
interface R1-eth2
|
|
ip router isis ROUTE0
|
|
isis passive
|
|
```
|
|
|
|
As soon as you do this you will notice a new LSP in the Wireshark packet
|
|
capture and if you inspect its contents you will find the subnet of the
|
|
`R1-eth2` interface being advertised. You should then shortly find that the
|
|
`R2` routing table will be updated with this information. Now make sure to do
|
|
apply a similar configuration to `R2` to advertise its path to the connected
|
|
host.
|
|
|
|
Finally, you will start seeing pings between the hosts going through. Success!
|
|
|
|
## Configuration files
|
|
|
|
It is a bit cumbersome to configure everything manually every time we start up
|
|
the network. That is why just like with `zebra` and `staticd` we can configure
|
|
`isisd` using configuration files. The configuration files for the network
|
|
configured in this lesson can be found in the [isis
|
|
scenario](../topology/two_rtrs/scenario/isis/isisd). You can find all the
|
|
possible options for configuration by either using `?` in the configuration
|
|
terminal of `isisd` or by browsing its
|
|
[documentation](http://docs.frrouting.org/en/latest/isisd.html).
|
|
|
|
## Conclusion
|
|
|
|
In this lesson you have learned how to configure the basics of a routing
|
|
protocol, in this case IS-IS, in order to achieve connectivity across a
|
|
network. The network we configured is simple, but it is enough to configure
|
|
even more complex networks.
|
|
|
|
As an exercise you could try and configure a bigger topology such as the one
|
|
[here](../topology/four_areas). It is up to you if you want to use one or two
|
|
levels of IS-IS for it. An example two-level area division is shown in this
|
|
topology's [isis scenario](../topology/four_areas/scenario/isis). You can try
|
|
to configure it manually like the network in this lesson or by using
|
|
configuration files. The solutions are provided in the `isisd` directory of
|
|
the scenario, but make sure you try it yourself first.
|