Source string Source string

202/10000 · 202
English Actions
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.
The same applies for the paths between ``h1`` and ``h2``
Besides :manpage:`ping6(8)` and :manpage:`traceroute6(8)`, it is also useful to interact with the BGP daemon that runs on each of our routers. This is done by connecting on the Command Line Interface of the BGP router using telnet.
The password for the BGP daemon is `zebra`. The `noecho` command indicates that mininet_ does not need to echo the characters that you type. You then enter the Quagga VTY that enables you to type commands. The `help` commands gives you some information about the available commands as well as `?`.
In these exercises, we mainly consider the ``show`` that extracts information from the BGP daemon. We type `show bgp` and press the `tabulation` key to see the available commands in the `show bgp`.
A useful command to start is `show bgp summary` which provides a summary of the state of the BGP daemon.
This router (`as1`) has two BGP neighbors: ``2001:cafe:1:12::2`` and ``2001:cafe:1:13::3``. Both BGP sessions are established using the current version of the protocol (version 4). About 50 messages were sent/received over each session. These messages are mainly the BGP Keepalive messages that are exchanged every 30 seconds. The last column indicates that two prefixes were received over each session. We can see more details about these two eBGP sessions with the `show bgp neighbors` command.
We can now observe the BGP-Loc-RIB of the router with the ``show bgp ipv6 command`` command.
It is interesting to look at the output of this command in details. Router `as1` has routes for three different IPv6 prefixes. The first prefix is its own prefix, ``2001:cafe:1::/48``. It has no nexthop since this prefix is originated by the router. Then, `as1` has received two paths for ``2001:cafe:2::/48``. In the BGP Loc-RIB, the `>` character indicates the best route according to the BGP decision process. ``2001:cafe:2::/48`` was learned over two different BGP sessions:
the eBGP session with ``fe80::3c81:2eff:fe19:465d`` with an AS-Path of ``AS3:AS2`` (see last column)
the eBGP session with ``fe80::c001:dcff:fe49:a512`` with an AS-Path of ``AS2`` (see last column)
The first of these two routes is preferred as indicated by the `>` character because it has a higher ``local-preference` (150) than the second one (100). For prefix ``2001:cafe:3::/48``, the route learned via ``fe80::3c81:2eff:fe19:465d`` is also preferred for the same reason.

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:529
String age
3 years ago
Source string age
3 years ago
Translation file
locale/pot/exercises/routing-protocols.pot, string 44