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.
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`.
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.
