2. cnp3-ebook
3. exercises/routing-protocols
4. English
5. Browse

2 / 5

/ 5

Read-only strings

• Untranslated strings • state:empty
• Unfinished strings • state:<translated
• Translated strings • state:>=translated
• Strings marked for edit • state:needs-editing
• Strings with suggestions • has:suggestion
• Strings with variants • has:variant
• Strings with labels • has:label
• Strings with context • has:context
• Unfinished strings without suggestions • state:<translated AND NOT has:suggestion
• Strings with comments • has:comment
• Strings with any failing checks • has:check
• Approved strings • state:approved
• Strings waiting for review • state:translated

Position and priority

• Position and priority
• Position
• Priority
• Labels
• Source string
• Target string
• String age
• Number of words
• Number of comments
• Number of failing checks
• Key

	English
	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