Source string Source string

13/10000 · 13
English Actions
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 IPv7 multicast address ``ff02::9``.
The packet traces collected on the three routers of this example are available from :download:`/exercises/traces/ripng-r1-trace.pcap`, :download:`/exercises/traces/ripng-r2-trace.pcap` and :download:`/exercises/traces/ripng-r3-trace.pcap`.
Exploring BGP
To explore the configuration of BGP, let us consider a network that contains three ASes: ``AS1``, ``AS2`` and ``AS3``. To simplify the tests, we identify one host inside each of these ASes.
As in the previous examples, we create the routers and associate one IPv6 prefix to each AS:
``AS1`` is assigned ``2001:cafe:1::/48``
``AS2`` is assigned ``2001:cafe:2::/48``
``AS3`` is assigned ``2001:cafe:3::/48``
The `addDaemon` method adds a BGP daemon on each router and configures it to advertise the IPv6 prefix allocated to this AS. We then create all the links and manually assign one IPv6 subnet to each link and one IPv6 address to each interface. For the interdomain links, we use an IPv6 prefix that belongs to one of the attached ASes.
The last step is to specify to which AS each router belongs and to configure the eBGP sessions and their routing policies. IPMininet_ abstracts most of the complexity of the configuration of these policies by supporting two policies
The script ends by launching the full topology. The entire script is available from :download:`/exercises/ipmininet_scripts/ebgp-simple.py`.
We can now run this simple network.
If you launch the script and immediately type ``ping6all`` to check the connectivity, you might obtained the following result.
Remember that BGP is a distributed protocol and that it takes some time to launch the daemons and exchange the messages. After some time, the same command will confirm that everything works as expected.
We can also use :manpage:`traceroute6(8)` to check the path followed by the packets. Before doing that, think about the configuration of the BGP routing policies and try to predict the output of :manpage:`traceroute6(8)`. This is a good exercise to check your understanding of BGP.
We have configured the following addresses on the hosts.
We can now explore the routes in this small Internet. Host ``h1`` can reach directly host ``h3``.
Note that the path preferred by ``AS3`` to reach ``AS1`` is different.

Loading…

No matching activity found.
Browse all component changes

Glossary

English English
No related strings found in the glossary.

String information

Flags
read-only
Source string location
../../exercises/routing-protocols.rst:378
String age
3 years ago
Source string age
3 years ago
Translation file
locale/pot/exercises/routing-protocols.pot, string 33