The translation has come to an end.
Zen

Source string Source string

396/10000 · 396

The string is read-only.

English Actions
Exploring routing protocols
Routing protocols play a key role in the Internet since they ensure that all the routers have valid routing tables. In this section, we use IPMininet_ to explore how intradomain and interdomain routing protocols work in practice. IPMininet_ adds an abstraction layer above the actual configuration of the FRRouting daemons that implement these routing protocols.
Exploring OSPF
We first use IPMininet_ to explore the operation of OSPFv3, the version of OSPF that supports IPv6. We create a simple network with three routers and two hosts as shown in the figure below.
The code is very simple as by default IPMininet_ enables OSPF on routers. We introduce two specific parameters. First, the interface that connects a router to a host is flagged as a passive interface (``igp_passive=True``). This indicates to the router that there are no other routers attached to this interface and that it should not send or accept OSPF Hello messages on this interface. The second configuration parameter is that we set the IGP cost on each link.
We use this mininet_ topology to collect packet traces that show the packets that OSPF routers exchange. For this, we add the following ``post_build`` method that IPMininet_ starts after having constructed the network and before launching the daemons. It simply starts tcpdump_ on each router to collect the first 100 OSPF packets that they send/receive.
Finally, we can start the IPMininet_ topology and launch the daemons. The entire script is available from :download:`/exercises/ipmininet_scripts/ospf6.py`.
The script starts the routers and hosts.
We can easily verify that the paths used to forward packets are the expected ones according to the configured IGP weights.
We can also connect to the OSPFv3 daemon running on the routers to observe its state. For this, we use the ``noecho r1 telnet localhost ospf6d`` command.
The password to access this daemon is `zebra`. It supports various commands that are described in the `FRRouting documentation <http://docs.frrouting.org/en/latest/ospf6d.html#showing-ospf6-information>`_ We briefly illustrate some of them below.
The ``show ipv6 ospf6`` command reports the general state of the OSPFv3 daemon. The ``show ipv6 ospf6 neighbor`` command reports the state of the connected neighbors.
In its output, we see that ``r1`` is attached to two different routers. Finally, the ``show ipv6 ospf6 database`` returns the full OSPFv3 database with all the link state information that was distributed by OSPFv3.
We can also use the packet traces that were collected by tcpdump_ to observe the packets that the OSPFv3 daemons exchange. OSPFv3 is a more complex protocol that the basic link state protocol that we have described in this book, but you should be able to understand some of these packets. The packet traces are available as :download:`/exercises/traces/ospf6-r1-trace.pcap`, :download:`/exercises/traces/ospf6-r2-trace.pcap` and :download:`/exercises/traces/ospf6-r3-trace.pcap`. Here are a few interesting packets collected on router ``r1``.
The first packet that this router received his a Hello packet that was sent by router ``r2``. There are several interesting points to note about this packet. First, its source address is the link-local address (``fe80::68bc:b4ff:fe19:42b7``) of router ``r2`` on this interface. The destination address of the packet is reserved IPv6 multicast address for OSPFv3, i.e. ``ff02::5``. The Hop Limit of the packet is set to 1 and OSFPv3 uses a next header of type 89.
The Hello packet contains some parameters such as the `Hello interval` that is set to 1 second. This interval is the delay between the transmission of successive Hello packets. Since the `Router Dead Interval` is set to 3 seconds, the router will consider the link as down if it does not receive Hello packets during a period of 3 seconds. The second packet of the trace is sent by router ``r1``.
We can then observe the Database description packet that is sent by routers to announce the state of their OSPFv3 database. The details of this packet are beyond the scope of this simple exercise.
This packet is updated when new information is added in the router's OSPFv3 database. A few seconds router, this router sends another Database description packet that announces more information.
Router ``r2`` reacts to this updated Database description packet by requesting the link state information that it does not already know. For this, it sends a `LS Request` packet.
The requested information is sent in a `LS Update` packet shortly after that.
OSPFv3 also includes `LS Acknowledge` packets that acknowledge the correct reception of link state information.
A more detailed discussion of the packets that routing protocols exchange may be found in [Goralski2009]_.
Exploring RIP
IPMininet_ can also be used to perform experiments with RIP. A simple script that uses RIPng is provided below.
As RIP messages are exchanged using UDP on port 521, we filter this port in the tcpdump_ trace. RIPng distributes the routes and our two hosts can exchange packets. The entire script is available from :download:`/exercises/ipmininet_scripts/ripng.py`.
We can observe the RIPng messages that are exchanged over the network. :rfc:`2080` defines two types of RIPng messages:
the requests
the responses that contain the router's routing table
When a router starts, it sends a request message. This is illustrated in the figure below with the first message sent by router ``r2``. This message is sent inside an IPv6 packet whose source address is the link-local address of the router and the destination address is ``ff02::9`` which is the reserved multicast address for RIPng.
Router ``r2`` receives a similar request from ``fe80::481a:48ff:fed7:292e`` and replies by sending its routing table in a response message. Note that this message is sent to the link-local address of the requesting router.
Later, router ``r2`` will regularly transmit its distance vector inside an unsolicited response message that is sent towards the IPv6 multicast address ``ff02::9``.

Loading…

User avatar gegoa

String updated in the repository
The Hello packet contains some parameters such as the `Hello interval` that is set to 1 second. This interval is the delay between the transmission of successive Hello packets. Since the `Router Dead Interval` is set to 3 seconds, the router will consider the link as down if it does not receive Hello packets during a period of 3 seconds. The second packet of the trace is sent by router ``r1``.
The Hello packet contains some parameters such as the `Hello interval` that is set to 1 second. This interval is the delay between the transmission of successive Hello packets. Since the `Router Dead Interval` is set to 3 seconds, the router will consider the link as down if it does not receive Hello packets during a period of 3 seconds. The second packet of the trace is sent by router ``r1``.
a month ago
Browse all string changes

Glossary

English English
No related strings found in the glossary.

35597 String information

Flags
read-only, rst-text
Source string location
../../exercises/routing-protocols.rst:245
String age
4 years ago
Last updated
a month ago
Source string age
4 years ago
Translation file
locale/pot/exercises/routing-protocols.pot, string 16