frrouting/frr
1
0
Fork 0
Code Issues Activity
frr/doc/developer/topotests.rst

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1519 lines
53 KiB
ReStructuredText
Raw Normal View History

Adding upstream version 10.1.1. Signed-off-by: Daniel Baumann <daniel@debian.org>
2025-02-05 10:03:58 +01:00
.. _topotests:
Topotests
=========
Topotests is a suite of topology tests for FRR built on top of micronet.
Installation and Setup
----------------------
Topotests run under python3.
Tested with Ubuntu 22.04,Ubuntu 20.04, and Debian 12.
Python protobuf version < 4 is required b/c python protobuf >= 4 requires a
protoc >= 3.19, and older package versions are shipped by in the above distros.
Instructions are the same for all setups. However, ExaBGP is only used for
BGP tests.
Tshark is only required if you enable any packet captures on test runs.
Valgrind is only required if you enable valgrind on test runs.
Installing Topotest Requirements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code:: shell
apt-get install \
gdb \
iproute2 \
net-tools \
python3-pip \
iputils-ping \
tshark \
valgrind
python3 -m pip install wheel
python3 -m pip install 'pytest>=6.2.4' 'pytest-xdist>=2.3.0'
python3 -m pip install 'scapy>=2.4.5'
python3 -m pip install xmltodict
python3 -m pip install git+https://github.com/Exa-Networks/exabgp@0659057837cd6c6351579e9f0fa47e9fb7de7311
useradd -d /var/run/exabgp/ -s /bin/false exabgp
The version of protobuf package that is installed on your system will determine
which versions of the python protobuf packages you need to install.
.. code:: shell
# - Either - For protobuf version <= 3.12
python3 -m pip install 'protobuf<4'
# - OR- for protobuf version >= 3.21
python3 -m pip install 'protobuf>=4'
# To enable the gRPC topotest also install:
python3 -m pip install grpcio grpcio-tools
Enable Coredumps
""""""""""""""""
Optional, will give better output.
.. code:: shell
disable apport (which move core files)
Set ``enabled=0`` in ``/etc/default/apport``.
Next, update security limits by changing :file:`/etc/security/limits.conf` to::
#<domain> <type> <item> <value>
* soft core unlimited
root soft core unlimited
* hard core unlimited
root hard core unlimited
Reboot for options to take effect.
SNMP Utilities Installation
"""""""""""""""""""""""""""
To run SNMP test you need to install SNMP utilities and MIBs. Unfortunately
there are some errors in the upstream MIBS which need to be patched up. The
following steps will get you there on Ubuntu 20.04.
.. code:: shell
apt install libsnmp-dev
apt install snmpd snmp
apt install snmp-mibs-downloader
download-mibs
wget https://raw.githubusercontent.com/FRRouting/frr-mibs/main/iana/IANA-IPPM-METRICS-REGISTRY-MIB -O /usr/share/snmp/mibs/iana/IANA-IPPM-METRICS-REGISTRY-MIB
wget https://raw.githubusercontent.com/FRRouting/frr-mibs/main/ietf/SNMPv2-PDU -O /usr/share/snmp/mibs/ietf/SNMPv2-PDU
wget https://raw.githubusercontent.com/FRRouting/frr-mibs/main/ietf/IPATM-IPMC-MIB -O /usr/share/snmp/mibs/ietf/IPATM-IPMC-MIB
edit /etc/snmp/snmp.conf to look like this
# As the snmp packages come without MIB files due to license reasons, loading
# of MIBs is disabled by default. If you added the MIBs you can reenable
# loading them by commenting out the following line.
mibs +ALL
FRR Installation
^^^^^^^^^^^^^^^^
FRR needs to be installed separately. It is assume to be configured like the
standard Ubuntu Packages:
- Binaries in :file:`/usr/lib/frr`
- State Directory :file:`/var/run/frr`
- Running under user ``frr``, group ``frr``
- vtygroup: ``frrvty``
- config directory: :file:`/etc/frr`
- For FRR Packages, install the dbg package as well for coredump decoding
No FRR config needs to be done and no FRR daemons should be run ahead of the
test. They are all started as part of the test.
Manual FRR build
""""""""""""""""
If you prefer to manually build FRR, then use the following suggested config:
.. code:: shell
./configure \
--prefix=/usr \
--sysconfdir=/etc \
--localstatedir=/var \
--sbindir=/usr/lib/frr \
--enable-vtysh \
--enable-pimd \
--enable-pim6d \
--enable-sharpd \
--enable-multipath=64 \
--enable-user=frr \
--enable-group=frr \
--enable-vty-group=frrvty \
--enable-snmp=agentx \
--with-pkg-extra-version=-my-manual-build
And create ``frr`` user and ``frrvty`` group as follows:
.. code:: shell
addgroup --system --gid 92 frr
addgroup --system --gid 85 frrvty
adduser --system --ingroup frr --home /var/run/frr/ \
--gecos "FRRouting suite" --shell /bin/false frr
usermod -G frrvty frr
Executing Tests
---------------
Configure your sudo environment
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Topotests must be run as root. Normally this will be accomplished through the
use of the ``sudo`` command. In order for topotests to be able to open new
windows (either XTerm or byobu/screen/tmux windows) certain environment
variables must be passed through the sudo command. One way to do this is to
specify the ``-E`` flag to ``sudo``. This will carry over most if not all
your environment variables include ``PATH``. For example:
.. code:: shell
sudo -E python3 -m pytest -s -v
If you do not wish to use ``-E`` (e.g., to avoid ``sudo`` inheriting
``PATH``) you can modify your `/etc/sudoers` config file to specifically pass
the environment variables required by topotests. Add the following commands to
your ``/etc/sudoers`` config file.
.. code:: shell
Defaults env_keep="TMUX"
Defaults env_keep+="TMUX_PANE"
Defaults env_keep+="STY"
Defaults env_keep+="DISPLAY"
If there was already an ``env_keep`` configuration there be sure to use the
``+=`` rather than ``=`` on the first line above as well.
Execute all tests in distributed test mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code:: shell
sudo -E pytest -s -v -nauto --dist=loadfile
The above command must be executed from inside the topotests directory.
All test\_\* scripts in subdirectories are detected and executed (unless
disabled in ``pytest.ini`` file). Pytest will execute up to N tests in parallel
where N is based on the number of cores on the host.
Analyze Test Results (``analyze.py``)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By default router and execution logs are saved in ``/tmp/topotests`` and an XML
results file is saved in ``/tmp/topotests/topotests.xml``. An analysis tool
``analyze.py`` is provided to archive and analyze these results after the run
completes.
After the test run completes one should pick an archive directory to store the
results in and pass this value to ``analyze.py``. On first execution the results
are moved to that directory from ``/tmp/topotests``. Subsequent runs of
``analyze.py`` with the same args will use that directories contents for instead
of copying any new results from ``/tmp``. Below is an example of this which also
shows the default behavior which is to display all failed and errored tests in
the run.
.. code:: shell
~/frr/tests/topotests# ./analyze.py -Ar run-save
bgp_multiview_topo1/test_bgp_multiview_topo1.py::test_bgp_converge
ospf_basic_functionality/test_ospf_lan.py::test_ospf_lan_tc1_p0
bgp_gr_functionality_topo2/test_bgp_gr_functionality_topo2.py::test_BGP_GR_10_p2
bgp_multiview_topo1/test_bgp_multiview_topo1.py::test_bgp_routingTable
Here we see that 4 tests have failed. We can dig deeper by displaying the
captured logs and errors. First let's redisplay the results enumerated by adding
the ``-E`` flag
.. code:: shell
~/frr/tests/topotests# ./analyze.py -Ar run-save -E
0 bgp_multiview_topo1/test_bgp_multiview_topo1.py::test_bgp_converge
1 ospf_basic_functionality/test_ospf_lan.py::test_ospf_lan_tc1_p0
2 bgp_gr_functionality_topo2/test_bgp_gr_functionality_topo2.py::test_BGP_GR_10_p2
3 bgp_multiview_topo1/test_bgp_multiview_topo1.py::test_bgp_routingTable
Now to look at the error message for a failed test we use ``-T N`` where N is
the number of the test we are interested in along with ``--errmsg`` option.
.. code:: shell
~/frr/tests/topotests# ./analyze.py -Ar run-save -T0 --errmsg
bgp_multiview_topo1/test_bgp_multiview_topo1.py::test_bgp_converge: AssertionError: BGP did not converge:
IPv4 Unicast Summary:
BGP router identifier 172.30.1.1, local AS number 100 VIEW 1 vrf-id -1
BGP table version 1
RIB entries 1, using 184 bytes of memory
Peers 3, using 2169 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
172.16.1.1 4 65001 0 0 0 0 0 never Connect 0 N/A
172.16.1.2 4 65002 0 0 0 0 0 never Connect 0 N/A
172.16.1.5 4 65005 0 0 0 0 0 never Connect 0 N/A
Total number of neighbors 3
assert False
Now to look at the error text for a failed test we can use ``-T RANGES`` where
``RANGES`` can be a number (e.g., ``5``), a range (e.g., ``0-10``), or a comma
separated list numbers and ranges (e.g., ``5,10-20,30``) of the test cases we
are interested in along with ``--errtext`` option. In the example below we'll
select the first failed test case.
.. code:: shell
~/frr/tests/topotests# ./analyze.py -Ar run-save -T0 --errtext
bgp_multiview_topo1/test_bgp_multiview_topo1.py::test_bgp_converge: def test_bgp_converge():
"Check for BGP converged on all peers and BGP views"
global fatal_error
global net
[...]
else:
# Bail out with error if a router fails to converge
bgpStatus = net["r%s" % i].cmd('vtysh -c "show ip bgp view %s summary"' % view)
> assert False, "BGP did not converge:\n%s" % bgpStatus
E AssertionError: BGP did not converge:
E
E IPv4 Unicast Summary:
E BGP router identifier 172.30.1.1, local AS number 100 VIEW 1 vrf-id -1
[...]
E Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
E 172.16.1.1 4 65001 0 0 0 0 0 never Connect 0 N/A
E 172.16.1.2 4 65002 0 0 0 0 0 never Connect 0 N/A
[...]
To look at the full capture for a test including the stdout and stderr which
includes full debug logs, use ``--full`` option, or specify a ``-T RANGES`` without
specifying ``--errmsg`` or ``--errtext``.
.. code:: shell
~/frr/tests/topotests# ./analyze.py -Ar run-save -T0
@classname: bgp_multiview_topo1.test_bgp_multiview_topo1
@name: test_bgp_converge
@time: 141.401
@message: AssertionError: BGP did not converge:
[...]
system-out: --------------------------------- Captured Log ---------------------------------
2021-08-09 02:55:06,581 DEBUG: lib.micronet_compat.topo: Topo(unnamed): Creating
2021-08-09 02:55:06,581 DEBUG: lib.micronet_compat.topo: Topo(unnamed): addHost r1
[...]
2021-08-09 02:57:16,932 DEBUG: topolog.r1: LinuxNamespace(r1): cmd_status("['/bin/bash', '-c', 'vtysh -c "show ip bgp view 1 summary" 2> /dev/null | grep ^[0-9] | grep -vP " 11\\s+(\\d+)"']", kwargs: {'encoding': 'utf-8', 'stdout': -1, 'stderr': -2, 'shell': False})
2021-08-09 02:57:22,290 DEBUG: topolog.r1: LinuxNamespace(r1): cmd_status("['/bin/bash', '-c', 'vtysh -c "show ip bgp view 1 summary" 2> /dev/null | grep ^[0-9] | grep -vP " 11\\s+(\\d+)"']", kwargs: {'encoding': 'utf-8', 'stdout': -1, 'stderr': -2, 'shell': False})
2021-08-09 02:57:27,636 DEBUG: topolog.r1: LinuxNamespace(r1): cmd_status("['/bin/bash', '-c', 'vtysh -c "show ip bgp view 1 summary"']", kwargs: {'encoding': 'utf-8', 'stdout': -1, 'stderr': -2, 'shell': False})
--------------------------------- Captured Out ---------------------------------
system-err: --------------------------------- Captured Err ---------------------------------
Filtered results
""""""""""""""""
There are 4 types of test results, [e]rrored, [f]ailed, [p]assed, and
[s]kipped. One can select the set of results to show with the ``-S`` or
``--select`` flags along with the letters for each type (i.e., ``-S efps``
would select all results). By default ``analyze.py`` will use ``-S ef`` (i.e.,
[e]rrors and [f]ailures) unless the ``--search`` filter is given in which case
the default is to search all results (i.e., ``-S efps``).
One can find all results which contain a ``REGEXP``. To filter results using a
regular expression use the ``--search REGEXP`` option. In this case, by default,
all result types will be searched for a match against the given ``REGEXP``. If a
test result output contains a match it is selected into the set of results to show.
An example of using ``--search`` would be to search all tests results for some
log message, perhaps a warning or error.
Using XML Results File from CI
""""""""""""""""""""""""""""""
``analyze.py`` actually only needs the ``topotests.xml`` file to run. This is
very useful for analyzing a CI run failure where one only need download the
``topotests.xml`` artifact from the run and then pass that to ``analyze.py``
with the ``-r`` or ``--results`` option.
For local runs if you wish to simply copy the ``topotests.xml`` file (leaving
the log files where they are), you can pass the ``-a`` (or ``--save-xml``)
instead of the ``-A`` (or ``-save``) options.
Analyze Results from a Container Run
""""""""""""""""""""""""""""""""""""
``analyze.py`` can also be used with ``docker`` or ``podman`` containers.
Everything works exactly as with a host run except that you specify the name of
the container, or the container-id, using the `-C` or ``--container`` option.
``analyze.py`` will then use the results inside that containers
``/tmp/topotests`` directory. It will extract and save those results when you
pass the ``-A`` or ``-a`` options just as withe host results.
Execute single test
^^^^^^^^^^^^^^^^^^^
.. code:: shell
cd test_to_be_run
sudo -E pytest ./test_to_be_run.py
For example, and assuming you are inside the frr directory:
.. code:: shell
cd tests/topotests/bgp_l3vpn_to_bgp_vrf
sudo -E pytest ./test_bgp_l3vpn_to_bgp_vrf.py
For further options, refer to pytest documentation.
Test will set exit code which can be used with ``git bisect``.
For the simulated topology, see the description in the python file.
Running Topotests with AddressSanitizer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Topotests can be run with AddressSanitizer. It requires GCC 4.8 or newer.
(Ubuntu 16.04 as suggested here is fine with GCC 5 as default). For more
information on AddressSanitizer, see
https://github.com/google/sanitizers/wiki/AddressSanitizer.
The checks are done automatically in the library call of ``checkRouterRunning``
(ie at beginning of tests when there is a check for all daemons running). No
changes or extra configuration for topotests is required beside compiling the
suite with AddressSanitizer enabled.
If a daemon crashed, then the errorlog is checked for AddressSanitizer output.
If found, then this is added with context (calling test) to
:file:`/tmp/AddressSanitizer.txt` in Markdown compatible format.
Compiling for GCC AddressSanitizer requires to use ``gcc`` as a linker as well
(instead of ``ld``). Here is a suggest way to compile frr with AddressSanitizer
for ``master`` branch:
.. code:: shell
git clone https://github.com/FRRouting/frr.git
cd frr
./bootstrap.sh
./configure \
--enable-address-sanitizer \
--prefix=/usr/lib/frr \
--sysconfdir=/etc \
--localstatedir=/var \
--sbindir=/usr/lib/frr --bindir=/usr/lib/frr \
--with-moduledir=/usr/lib/frr/modules \
--enable-multipath=0 --enable-rtadv \
--enable-tcp-zebra --enable-fpm --enable-pimd \
--enable-sharpd
make
sudo make install
# Create symlink for vtysh, so topotest finds it in /usr/lib/frr
sudo ln -s /usr/lib/frr/vtysh /usr/bin/
and create ``frr`` user and ``frrvty`` group as shown above.
Debugging Topotest Failures
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Install and run tests inside ``tmux`` or ``byobu`` for best results.
``XTerm`` is also fully supported. GNU ``screen`` can be used in most
situations; however, it does not work as well with launching ``vtysh`` or shell
on error.
For the below debugging options which launch programs or CLIs, topotest should
be run within ``tmux`` (or ``screen``)_, as ``gdb``, the shell or ``vtysh`` will
be launched using that windowing program, otherwise ``xterm`` will be attempted
to launch the given programs.
NOTE: you must run the topotest (pytest) such that your DISPLAY, STY or TMUX
environment variables are carried over. You can do this by passing the
``-E`` flag to ``sudo`` or you can modify your ``/etc/sudoers`` config to
automatically pass that environment variable through to the ``sudo``
environment.
.. _screen: https://www.gnu.org/software/screen/
.. _tmux: https://github.com/tmux/tmux/wiki
Capturing Packets
"""""""""""""""""
One can view and capture packets on any of the networks or interfaces defined by
the topotest by specifying the ``--pcap=NET|INTF|all[,NET|INTF,...]`` CLI option
as shown in the examples below.
.. code:: shell
# Capture on all networks in isis_topo1 test
sudo -E pytest isis_topo1 --pcap=all
# Capture on `sw1` network
sudo -E pytest isis_topo1 --pcap=sw1
# Capture on `sw1` network and on interface `eth0` on router `r2`
sudo -E pytest isis_topo1 --pcap=sw1,r2:r2-eth0
For each capture a window is opened displaying a live summary of the captured
packets. Additionally, the entire packet stream is captured in a pcap file in
the tests log directory e.g.,:
.. code:: console
$ sudo -E pytest isis_topo1 --pcap=sw1,r2:r2-eth0
...
$ ls -l /tmp/topotests/isis_topo1.test_isis_topo1/
-rw------- 1 root root 45172 Apr 19 05:30 capture-r2-r2-eth0.pcap
-rw------- 1 root root 48412 Apr 19 05:30 capture-sw1.pcap
...
Viewing Live Daemon Logs
""""""""""""""""""""""""
One can live view daemon or the frr logs in separate windows using the
``--logd`` CLI option as shown below.
.. code:: shell
# View `ripd` logs on all routers in test
sudo -E pytest rip_allow_ecmp --logd=ripd
# View `ripd` logs on all routers and `mgmtd` log on `r1`
sudo -E pytest rip_allow_ecmp --logd=ripd --logd=mgmtd,r1
For each capture a window is opened displaying a live summary of the captured
packets. Additionally, the entire packet stream is captured in a pcap file in
the tests log directory e.g.,
When using a unified log file ``frr.log`` one substitutes ``frr`` for the
daemon name in the ``--logd`` CLI option, e.g.,
.. code:: shell
# View `frr` log on all routers in test
sudo -E pytest some_test_suite --logd=frr
Spawning Debugging CLI, ``vtysh`` or Shells on Routers on Test Failure
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
One can have a debugging CLI invoked on test failures by specifying the
``--cli-on-error`` CLI option as shown in the example below.
.. code:: shell
sudo -E pytest --cli-on-error all-protocol-startup
The debugging CLI can run shell or vtysh commands on any combination of routers
It can also open shells or vtysh in their own windows for any combination of
routers. This is usually the most useful option when debugging failures. Here is
the help command from within a CLI launched on error:
.. code:: shell
test_bgp_multiview_topo1/test_bgp_routingTable> help
Basic Commands:
cli :: open a secondary CLI window
help :: this help
hosts :: list hosts
quit :: quit the cli
HOST can be a host or one of the following:
- '*' for all hosts
- '.' for the parent munet
- a regex specified between '/' (e.g., '/rtr.*/')
New Window Commands:
logd HOST [HOST ...] DAEMON :: tail -f on the logfile of the given DAEMON for the given HOST[S]
pcap NETWORK :: capture packets from NETWORK into file capture-NETWORK.pcap the command is run within a new window which also shows packet summaries. NETWORK can also be an interface specified as HOST:INTF. To capture inside the host namespace.
stderr HOST [HOST ...] DAEMON :: tail -f on the stderr of the given DAEMON for the given HOST[S]
stdlog HOST [HOST ...] :: tail -f on the `frr.log` for the given HOST[S]
stdout HOST [HOST ...] DAEMON :: tail -f on the stdout of the given DAEMON for the given HOST[S]
term HOST [HOST ...] :: open terminal[s] (TMUX or XTerm) on HOST[S], * for all
vtysh ROUTER [ROUTER ...] ::
xterm HOST [HOST ...] :: open XTerm[s] on HOST[S], * for all
Inline Commands:
[ROUTER ...] COMMAND :: execute vtysh COMMAND on the router[s]
[HOST ...] sh <SHELL-COMMAND> :: execute <SHELL-COMMAND> on hosts
[HOST ...] shi <INTERACTIVE-COMMAND> :: execute <INTERACTIVE-COMMAND> on HOST[s]
test_bgp_multiview_topo1/test_bgp_routingTable> r1 show int br
------ Host: r1 ------
Interface Status VRF Addresses
--------- ------ --- ---------
erspan0 down default
gre0 down default
gretap0 down default
lo up default
r1-eth0 up default 172.16.1.254/24
r1-stub up default 172.20.0.1/28
----------------------
test_bgp_multiview_topo1/test_bgp_routingTable>
Additionally, one can have ``vtysh`` or a shell launched on all routers when a
test fails. To launch the given process on each router after a test failure
specify one of ``--shell-on-error`` or ``--vtysh-on-error``.
Spawning ``vtysh`` or Shells on Routers
"""""""""""""""""""""""""""""""""""""""
Topotest can automatically launch a shell or ``vtysh`` for any or all routers in
a test. This is enabled by specifying 1 of 2 CLI arguments ``--shell`` or
``--vtysh``. Both of these options can be set to a single router value, multiple
comma-seperated values, or ``all``.
When either of these options are specified topotest will pause after setup and
each test to allow for inspection of the router state.
Here's an example of launching ``vtysh`` on routers ``rt1`` and ``rt2``.
.. code:: shell
sudo -E pytest --vtysh=rt1,rt2 all-protocol-startup
.. _debug_with_gdb:
Debugging with GDB
""""""""""""""""""
Topotest can automatically launch any daemon with ``gdb``, possibly setting
breakpoints for any test run. This is enabled by specifying 1 or 2 CLI arguments
``--gdb-routers`` and ``--gdb-daemons``. Additionally ``--gdb-breakpoints`` can
be used to automatically set breakpoints in the launched ``gdb`` processes.
Each of these options can be set to a single value, multiple comma-seperated
values, or ``all``. If ``--gdb-routers`` is empty but ``--gdb_daemons`` is set
then the given daemons will be launched in ``gdb`` on all routers in the test.
Likewise if ``--gdb_routers`` is set, but ``--gdb_daemons`` is empty then all
daemons on the given routers will be launched in ``gdb``.
Here's an example of launching ``zebra`` and ``bgpd`` inside ``gdb`` on router
``r1`` with a breakpoint set on ``nb_config_diff``
.. code:: shell
sudo -E pytest --gdb-routers=r1 \
--gdb-daemons=bgpd,zebra \
--gdb-breakpoints=nb_config_diff \
all-protocol-startup
Finally, for Emacs users, you can specify ``--gdb-use-emacs``. When specified
the first router and daemon to be launched in gdb will be launched and run with
Emacs gdb functionality by using `emacsclient --eval` commands. This provides an
IDE debugging experience for Emacs users. This functionality works best when
using password-less sudo.
Reporting Memleaks with FRR Memory Statistics
"""""""""""""""""""""""""""""""""""""""""""""
FRR reports all allocated FRR memory objects on exit to standard error.
Topotest can be run to report such output as errors in order to check for
memleaks in FRR memory allocations. Specifying the CLI argument
``--memleaks`` will enable reporting FRR-based memory allocations at exit as errors.
.. code:: shell
sudo -E pytest --memleaks all-protocol-startup
StdErr log from daemos after exit
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When running with ``--memleaks``, to enable the reporting of other,
non-memory related, messages seen on StdErr after the daemons exit,
the following env variable can be set::
export TOPOTESTS_CHECK_STDERR=Yes
(The value doesn't matter at this time. The check is whether the env
variable exists or not.) There is no pass/fail on this reporting; the
Output will be reported to the console.
Collect Memory Leak Information
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When running with ``--memleaks``, FRR processes report unfreed memory
allocations upon exit. To enable also reporting of memory leaks to a specific
location, define an environment variable ``TOPOTESTS_CHECK_MEMLEAK`` with the
file prefix, i.e.:
::
export TOPOTESTS_CHECK_MEMLEAK="/home/mydir/memleak_"
For tests that support the TOPOTESTS_CHECK_MEMLEAK environment variable, this
will enable output to the information to files with the given prefix (followed
by testname), e.g.,:
file:`/home/mydir/memcheck_test_bgp_multiview_topo1.txt` in case
of a memory leak.
Detecting Memleaks with Valgrind
""""""""""""""""""""""""""""""""
Topotest can automatically launch all daemons with ``valgrind`` to check for
memleaks. This is enabled by specifying 1 to 3 CLI arguments.
``--valgrind-memleaks`` enables memleak detection. ``--valgrind-extra`` enables
extra functionality including generating a suppression file. The suppression
file ``tools/valgrind.supp`` is used when memleak detection is enabled. Finally,
``--valgrind-leak-kinds=KINDS`` can be used to modify what types of links are
reported. This corresponds to valgrind's ``--show-link-kinds`` arg. The value is
either ``all`` or a comma-separated list of types:
``definite,indirect,possible,reachable``. The default is ``definite,possible``.
.. code:: shell
sudo -E pytest --valgrind-memleaks all-protocol-startup
.. note:: GDB can be used in conjection with valgrind.
When you enable ``--valgrind-memleaks`` and you also launch various daemons
under GDB (debug_with_gdb_) topotest will connect the two utilities using
``--vgdb-error=0`` and attaching to a ``vgdb`` process. This is very
useful for debugging bugs with use of uninitialized errors, et al.
Collecting Performance Data using perf(1)
"""""""""""""""""""""""""""""""""""""""""
Topotest can automatically launch any daemon under ``perf(1)`` to collect
performance data. The daemon is run in non-daemon mode with ``perf record -g``.
The ``perf.data`` file will be saved in the router specific directory under the
tests run directoy.
Here's an example of collecting performance data from ``mgmtd`` on router ``r1``
during the config_timing test.
.. code:: console
$ sudo -E pytest --perf=mgmtd,r1 config_timing
...
$ find /tmp/topotests/ -name '*perf.data*'
/tmp/topotests/config_timing.test_config_timing/r1/perf.data
To specify different arguments for ``perf record``, one can use the
``--perf-options`` this will replace the ``-g`` used by default.
Running Daemons under RR Debug (``rr record``)
""""""""""""""""""""""""""""""""""""""""""""""
Topotest can automatically launch any daemon under ``rr(1)`` to collect
execution state. The daemon is run in the foreground with ``rr record``.
The execution state will be saved in the router specific directory
(in a `rr` subdir that rr creates) under the test's run directoy.
Here's an example of collecting ``rr`` execution state from ``mgmtd`` on router
``r1`` during the ``config_timing`` test.
.. code:: console
$ sudo -E pytest --rr-routers=r1 --rr-daemons=mgmtd config_timing
...
$ find /tmp/topotests/ -name '*perf.data*'
/tmp/topotests/config_timing.test_config_timing/r1/perf.data
To specify additional arguments for ``rr record``, one can use the
``--rr-options``.
.. _code_coverage:
Code coverage
"""""""""""""
Code coverage reporting requires installation of the ``gcov`` and ``lcov``
packages.
Code coverage can automatically be gathered for any topotest run. To support
this FRR must first be compiled with the ``--enable-gcov`` configure option.
This will cause *.gnco files to be created during the build. When topotests are
run the statistics are generated and stored in *.gcda files. Topotest
infrastructure will gather these files, capture the information into a
``coverage.info`` ``lcov`` file and also report the coverage summary.
To enable code coverage support pass the ``--cov-topotest`` argument to pytest.
If you build your FRR in a directory outside of the FRR source directory you
will also need to pass the ``--cov-frr-build-dir`` argument specifying the build
directory location.
During the topotest run the *.gcda files are generated into a ``gcda``
sub-directory of the top-level run directory (i.e., normally
``/tmp/topotests/gcda``). These files will then be copied at the end of the
topotest run into the FRR build directory where the ``gcov`` and ``lcov``
utilities expect to find them. This is done to deal with the various different
file ownership and permissions.
At the end of the run ``lcov`` will be run to capture all of the coverage data
into a ``coverage.info`` file. This file will be located in the top-level run
directory (i.e., normally ``/tmp/topotests/coverage.info``).
The ``coverage.info`` file can then be used to generate coverage reports or file
markup (e.g., using the ``genhtml`` utility) or enable markup within your
IDE/editor if supported (e.g., the emacs ``cov-mode`` package)
NOTE: the *.gcda files in ``/tmp/topotests/gcda`` are cumulative so if you do
not remove them they will aggregate data across multiple topotest runs.
.. _topotests_docker:
Running Tests with Docker
-------------------------
There is a Docker image which allows to run topotests.
Quickstart
^^^^^^^^^^
If you have Docker installed, you can run the topotests in Docker. The easiest
way to do this, is to use the make targets from this repository.
Your current user needs to have access to the Docker daemon. Alternatively you
can run these commands as root.
.. code:: console
make topotests
This command will pull the most recent topotests image from Dockerhub, compile
FRR inside of it, and run the topotests.
Advanced Usage
^^^^^^^^^^^^^^
Internally, the topotests make target uses a shell script to pull the image and
spawn the Docker container.
There are several environment variables which can be used to modify the
behavior of the script, these can be listed by calling it with ``-h``:
.. code:: console
./tests/topotests/docker/frr-topotests.sh -h
For example, a volume is used to cache build artifacts between multiple runs of
the image. If you need to force a complete recompile, you can set
``TOPOTEST_CLEAN``:
.. code:: console
TOPOTEST_CLEAN=1 ./tests/topotests/docker/frr-topotests.sh
By default, ``frr-topotests.sh`` will build frr and run pytest. If you append
arguments and the first one starts with ``/`` or ``./``, they will replace the
call to pytest. If the appended arguments do not match this patttern, they will
be provided to pytest as arguments. So, to run a specific test with more
verbose logging:
.. code:: console
./tests/topotests/docker/frr-topotests.sh -vv -s all-protocol-startup/test_all_protocol_startup.py
And to compile FRR but drop into a shell instead of running pytest:
.. code:: console
./tests/topotests/docker/frr-topotests.sh /bin/bash
Development
^^^^^^^^^^^
The Docker image just includes all the components to run the topotests, but not
the topotests themselves. So if you just want to write tests and don't want to
make changes to the environment provided by the Docker image. You don't need to
build your own Docker image if you do not want to.
When developing new tests, there is one caveat though: The startup script of
the container will run a ``git-clean`` on its copy of the FRR tree to avoid any
pollution of the container with build artefacts from the host. This will also
result in your newly written tests being unavailable in the container unless at
least added to the index with ``git-add``.
If you do want to test changes to the Docker image, you can locally build the
image and run the tests without pulling from the registry using the following
commands:
.. code:: console
make topotests-build
TOPOTEST_PULL=0 make topotests
.. _topotests-guidelines:
Guidelines
----------
Executing Tests
^^^^^^^^^^^^^^^
To run the whole suite of tests the following commands must be executed at the
top level directory of topotest:
.. code:: shell
$ # Change to the top level directory of topotests.
$ cd path/to/topotests
$ # Tests must be run as root, since micronet requires it.
$ sudo -E pytest
In order to run a specific test, you can use the following command:
.. code:: shell
$ # running a specific topology
$ sudo -E pytest ospf-topo1/
$ # or inside the test folder
$ cd ospf-topo1
$ sudo -E pytest # to run all tests inside the directory
$ sudo -E pytest test_ospf_topo1.py # to run a specific test
$ # or outside the test folder
$ cd ..
$ sudo -E pytest ospf-topo1/test_ospf_topo1.py # to run a specific one
The output of the tested daemons will be available at the temporary folder of
your machine:
.. code:: shell
$ ls /tmp/topotest/ospf-topo1.test_ospf-topo1/r1
...
zebra.err # zebra stderr output
zebra.log # zebra log file
zebra.out # zebra stdout output
...
You can also run memory leak tests to get reports:
.. code:: shell
$ # Set the environment variable to apply to a specific test...
$ sudo -E env TOPOTESTS_CHECK_MEMLEAK="/tmp/memleak_report_" pytest ospf-topo1/test_ospf_topo1.py
$ # ...or apply to all tests adding this line to the configuration file
$ echo 'memleak_path = /tmp/memleak_report_' >> pytest.ini
$ # You can also use your editor
$ $EDITOR pytest.ini
$ # After running tests you should see your files:
$ ls /tmp/memleak_report_*
memleak_report_test_ospf_topo1.txt
Writing a New Test
^^^^^^^^^^^^^^^^^^
This section will guide you in all recommended steps to produce a standard
topology test.
This is the recommended test writing routine:
- Write a topology (Graphviz recommended)
- Obtain configuration files
- Write the test itself
- Format the new code using `black <https://github.com/psf/black>`_
- Create a Pull Request
Some things to keep in mind:
- BGP tests MUST use generous convergence timeouts - you must ensure
that any test involving BGP uses a convergence timeout of at least
130 seconds.
- Topotests are run on a range of Linux versions: if your test
requires some OS-specific capability (like mpls support, or vrf
support), there are test functions available in the libraries that
will help you determine whether your test should run or be skipped.
- Avoid including unstable data in your test: don't rely on link-local
addresses or ifindex values, for example, because these can change
from run to run.
- Using sleep is almost never appropriate. As an example: if the test resets the
peers in BGP, the test should look for the peers re-converging instead of just
sleeping an arbitrary amount of time and continuing on. See
``verify_bgp_convergence`` as a good example of this. In particular look at
it's use of the ``@retry`` decorator. If you are having troubles figuring out
what to look for, please do not be afraid to ask.
- Don't duplicate effort. There exists many protocol utility functions that can
be found in their eponymous module under ``tests/topotests/lib/`` (e.g.,
``ospf.py``)
Topotest File Hierarchy
"""""""""""""""""""""""
Before starting to write any tests one must know the file hierarchy. The
repository hierarchy looks like this:
.. code:: shell
$ cd path/to/topotest
$ find ./*
...
./README.md # repository read me
./GUIDELINES.md # this file
./conftest.py # test hooks - pytest related functions
./example-test # example test folder
./example-test/__init__.py # python package marker - must always exist.
./example-test/test_template.jpg # generated topology picture - see next section
./example-test/test_template.dot # Graphviz dot file
./example-test/test_template.py # the topology plus the test
...
./ospf-topo1 # the ospf topology test
./ospf-topo1/r1 # router 1 configuration files
./ospf-topo1/r1/zebra.conf # zebra configuration file
./ospf-topo1/r1/ospfd.conf # ospf configuration file
./ospf-topo1/r1/ospfroute.txt # 'show ip ospf' output reference file
# removed other for shortness sake
...
./lib # shared test/topology functions
./lib/topogen.py # topogen implementation
./lib/topotest.py # topotest implementation
Guidelines for creating/editing topotest:
- New topologies that don't fit the existing directories should create its own
- Always remember to add the ``__init__.py`` to new folders, this makes auto
complete engines and pylint happy
- Router (Quagga/FRR) specific code should go on topotest.py
- Generic/repeated router actions should have an abstraction in
topogen.TopoRouter.
- Generic/repeated non-router code should go to topotest.py
- pytest related code should go to conftest.py (e.g. specialized asserts)
Defining the Topology
"""""""""""""""""""""
The first step to write a new test is to define the topology. This step can be
done in many ways, but the recommended is to use Graphviz to generate a drawing
of the topology. It allows us to see the topology graphically and to see the
names of equipment, links and addresses.
Here is an example of Graphviz dot file that generates the template topology
:file:`tests/topotests/example-test/test_template.dot` (the inlined code might
get outdated, please see the linked file)::
graph template {
label="template";
# Routers
r1 [
shape=doubleoctagon,
label="r1",
fillcolor="#f08080",
style=filled,
];
r2 [
shape=doubleoctagon,
label="r2",
fillcolor="#f08080",
style=filled,
];
# Switches
s1 [
shape=oval,
label="s1\n192.168.0.0/24",
fillcolor="#d0e0d0",
style=filled,
];
s2 [
shape=oval,
label="s2\n192.168.1.0/24",
fillcolor="#d0e0d0",
style=filled,
];
# Connections
r1 -- s1 [label="eth0\n.1"];
r1 -- s2 [label="eth1\n.100"];
r2 -- s2 [label="eth0\n.1"];
}
Here is the produced graph:
.. graphviz::
graph template {
label="template";
# Routers
r1 [
shape=doubleoctagon,
label="r1",
fillcolor="#f08080",
style=filled,
];
r2 [
shape=doubleoctagon,
label="r2",
fillcolor="#f08080",
style=filled,
];
# Switches
s1 [
shape=oval,
label="s1\n192.168.0.0/24",
fillcolor="#d0e0d0",
style=filled,
];
s2 [
shape=oval,
label="s2\n192.168.1.0/24",
fillcolor="#d0e0d0",
style=filled,
];
# Connections
r1 -- s1 [label="eth0\n.1"];
r1 -- s2 [label="eth1\n.100"];
r2 -- s2 [label="eth0\n.1"];
}
Generating / Obtaining Configuration Files
""""""""""""""""""""""""""""""""""""""""""
In order to get the configuration files or command output for each router, we
need to run the topology and execute commands in ``vtysh``. The quickest way to
achieve that is writing the topology building code and running the topology.
To bootstrap your test topology, do the following steps:
- Copy the template test
.. code:: shell
$ mkdir new-topo/
$ touch new-topo/__init__.py
$ cp example-test/test_template.py new-topo/test_new_topo.py
- Modify the template according to your dot file
Here is the template topology described in the previous section in python code:
.. code:: py
topodef = {
"s1": "r1"
"s2": ("r1", "r2")
}
If more specialized topology definitions, or router initialization arguments are
required a build function can be used instead of a dictionary:
.. code:: py
def build_topo(tgen):
"Build function"
# Create 2 routers
for routern in range(1, 3):
tgen.add_router("r{}".format(routern))
# Create a switch with just one router connected to it to simulate a
# empty network.
switch = tgen.add_switch("s1")
switch.add_link(tgen.gears["r1"])
# Create a connection between r1 and r2
switch = tgen.add_switch("s2")
switch.add_link(tgen.gears["r1"])
switch.add_link(tgen.gears["r2"])
- Run the topology
Topogen allows us to run the topology without running any tests, you can do
that using the following example commands:
.. code:: shell
$ # Running your bootstraped topology
$ sudo -E pytest -s --topology-only new-topo/test_new_topo.py
$ # Running the test_template.py topology
$ sudo -E pytest -s --topology-only example-test/test_template.py
$ # Running the ospf_topo1.py topology
$ sudo -E pytest -s --topology-only ospf-topo1/test_ospf_topo1.py
Parameters explanation:
.. program:: pytest
.. option:: -s
Actives input/output capture. If this is not specified a new window will be
opened for the interactive CLI, otherwise it will be activated inline.
.. option:: --topology-only
Don't run any tests, just build the topology.
After executing the commands above, you should get the following terminal
output:
.. code:: shell
frr/tests/topotests# sudo -E pytest -s --topology-only ospf_topo1/test_ospf_topo1.py
============================= test session starts ==============================
platform linux -- Python 3.9.2, pytest-6.2.4, py-1.10.0, pluggy-0.13.1
rootdir: /home/chopps/w/frr/tests/topotests, configfile: pytest.ini
plugins: forked-1.3.0, xdist-2.3.0
collected 11 items
[...]
unet>
The last line shows us that we are now using the CLI (Command Line
Interface), from here you can call your router ``vtysh`` or even bash.
Here's the help text:
.. code:: shell
unet> help
Commands:
help :: this help
sh [hosts] <shell-command> :: execute <shell-command> on <host>
term [hosts] :: open shell terminals for hosts
vtysh [hosts] :: open vtysh terminals for hosts
[hosts] <vtysh-command> :: execute vtysh-command on hosts
Here are some commands example:
.. code:: shell
unet> sh r1 ping 10.0.3.1
PING 10.0.3.1 (10.0.3.1) 56(84) bytes of data.
64 bytes from 10.0.3.1: icmp_seq=1 ttl=64 time=0.576 ms
64 bytes from 10.0.3.1: icmp_seq=2 ttl=64 time=0.083 ms
64 bytes from 10.0.3.1: icmp_seq=3 ttl=64 time=0.088 ms
^C
--- 10.0.3.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.083/0.249/0.576/0.231 ms
unet> r1 show run
Building configuration...
Current configuration:
!
frr version 8.1-dev-my-manual-build
frr defaults traditional
hostname r1
log file /tmp/topotests/ospf_topo1.test_ospf_topo1/r1/zebra.log
[...]
end
unet> show daemons
------ Host: r1 ------
zebra ospfd ospf6d staticd
------- End: r1 ------
------ Host: r2 ------
zebra ospfd ospf6d staticd
------- End: r2 ------
------ Host: r3 ------
zebra ospfd ospf6d staticd
------- End: r3 ------
------ Host: r4 ------
zebra ospfd ospf6d staticd
------- End: r4 ------
After you successfully configured your topology, you can obtain the
configuration files (per-daemon) using the following commands:
.. code:: shell
unet> sh r3 vtysh -d ospfd
Hello, this is FRRouting (version 3.1-devrzalamena-build).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
r1# show running-config
Building configuration...
Current configuration:
!
frr version 3.1-devrzalamena-build
frr defaults traditional
no service integrated-vtysh-config
!
log file ospfd.log
!
router ospf
ospf router-id 10.0.255.3
redistribute kernel
redistribute connected
redistribute static
network 10.0.3.0/24 area 0
network 10.0.10.0/24 area 0
network 172.16.0.0/24 area 1
!
line vty
!
end
r1#
You can also login to the node specified by nsenter using bash, etc.
A pid file for each node will be created in the relevant test dir.
You can run scripts inside the node, or use vtysh's <tab> or <?> feature.
.. code:: shell
[unet shell]
# cd tests/topotests/srv6_locator
# ./test_srv6_locator.py --topology-only
unet> r1 show segment-routing srv6 locator
Locator:
Name ID Prefix Status
-------------------- ------- ------------------------ -------
loc1 1 2001:db8:1:1::/64 Up
loc2 2 2001:db8:2:2::/64 Up
[Another shell]
# nsenter -a -t $(cat /tmp/topotests/srv6_locator.test_srv6_locator/r1.pid) bash --norc
# vtysh
r1# r1 show segment-routing srv6 locator
Locator:
Name ID Prefix Status
-------------------- ------- ------------------------ -------
loc1 1 2001:db8:1:1::/64 Up
loc2 2 2001:db8:2:2::/64 Up
Writing Tests
"""""""""""""
Test topologies should always be bootstrapped from
:file:`tests/topotests/example_test/test_template.py` because it contains
important boilerplate code that can't be avoided, like:
Example:
.. code:: py
# For all routers arrange for:
# - starting zebra using config file from <rtrname>/zebra.conf
# - starting ospfd using an empty config file.
for rname, router in router_list.items():
router.load_config(TopoRouter.RD_ZEBRA, "zebra.conf")
router.load_config(TopoRouter.RD_OSPF)
- The topology definition or build function
.. code:: py
topodef = {
"s1": ("r1", "r2"),
"s2": ("r2", "r3")
}
def build_topo(tgen):
# topology build code
...
- pytest setup/teardown fixture to start the topology and supply ``tgen``
argument to tests.
.. code:: py
@pytest.fixture(scope="module")
def tgen(request):
"Setup/Teardown the environment and provide tgen argument to tests"
tgen = Topogen(topodef, module.__name__)
# or
tgen = Topogen(build_topo, module.__name__)
...
# Start and configure the router daemons
tgen.start_router()
# Provide tgen as argument to each test function
yield tgen
# Teardown after last test runs
tgen.stop_topology()
Requirements:
- Directory name for a new topotest must not contain hyphen (``-``) characters.
To separate words, use underscores (``_``). For example, ``tests/topotests/bgp_new_example``.
- Test code should always be declared inside functions that begin with the
``test_`` prefix. Functions beginning with different prefixes will not be run
by pytest.
- Configuration files and long output commands should go into separated files
inside folders named after the equipment.
- Tests must be able to run without any interaction. To make sure your test
conforms with this, run it without the :option:`-s` parameter.
- Use `black <https://github.com/psf/black>`_ code formatter before creating
a pull request. This ensures we have a unified code style.
- Mark test modules with pytest markers depending on the daemons used during the
tests (see :ref:`topotests-markers`)
- Always use IPv4 :rfc:`5737` (``192.0.2.0/24``, ``198.51.100.0/24``,
``203.0.113.0/24``) and IPv6 :rfc:`3849` (``2001:db8::/32``) ranges reserved
for documentation.
Tips:
- Keep results in stack variables, so people inspecting code with ``pdb`` can
easily print their values.
Don't do this:
.. code:: py
assert foobar(router1, router2)
Do this instead:
.. code:: py
result = foobar(router1, router2)
assert result
- Use ``assert`` messages to indicate where the test failed.
Example:
.. code:: py
for router in router_list:
# ...
assert condition, 'Router "{}" condition failed'.format(router.name)
Debugging Execution
^^^^^^^^^^^^^^^^^^^
The most effective ways to inspect topology tests are:
- Run pytest with ``--pdb`` option. This option will cause a pdb shell to
appear when an assertion fails
Example: ``pytest -s --pdb ospf-topo1/test_ospf_topo1.py``
- Set a breakpoint in the test code with ``pdb``
Example:
.. code:: py
# Add the pdb import at the beginning of the file
import pdb
# ...
# Add a breakpoint where you think the problem is
def test_bla():
# ...
pdb.set_trace()
# ...
The `Python Debugger <https://docs.python.org/2.7/library/pdb.html>`__ (pdb)
shell allows us to run many useful operations like:
- Setting breaking point on file/function/conditions (e.g. ``break``,
``condition``)
- Inspecting variables (e.g. ``p`` (print), ``pp`` (pretty print))
- Running python code
.. tip::
The TopoGear (equipment abstraction class) implements the ``__str__`` method
that allows the user to inspect equipment information.
Example of pdb usage:
.. code:: shell
> /media/sf_src/topotests/ospf-topo1/test_ospf_topo1.py(121)test_ospf_convergence()
-> for rnum in range(1, 5):
(Pdb) help
Documented commands (type help <topic>):
========================================
EOF bt cont enable jump pp run unt
a c continue exit l q s until
alias cl d h list quit step up
args clear debug help n r tbreak w
b commands disable ignore next restart u whatis
break condition down j p return unalias where
Miscellaneous help topics:
==========================
exec pdb
Undocumented commands:
======================
retval rv
(Pdb) list
116 title2="Expected output")
117
118 def test_ospf_convergence():
119 "Test OSPF daemon convergence"
120 pdb.set_trace()
121 -> for rnum in range(1, 5):
122 router = 'r{}'.format(rnum)
123
124 # Load expected results from the command
125 reffile = os.path.join(CWD, '{}/ospfroute.txt'.format(router))
126 expected = open(reffile).read()
(Pdb) step
> /media/sf_src/topotests/ospf-topo1/test_ospf_topo1.py(122)test_ospf_convergence()
-> router = 'r{}'.format(rnum)
(Pdb) step
> /media/sf_src/topotests/ospf-topo1/test_ospf_topo1.py(125)test_ospf_convergence()
-> reffile = os.path.join(CWD, '{}/ospfroute.txt'.format(router))
(Pdb) print rnum
1
(Pdb) print router
r1
(Pdb) tgen = get_topogen()
(Pdb) pp tgen.gears[router]
<lib.topogen.TopoRouter object at 0x7f74e06c9850>
(Pdb) pp str(tgen.gears[router])
'TopoGear<name="r1",links=["r1-eth0"<->"s1-eth0","r1-eth1"<->"s3-eth0"]> TopoRouter<>'
(Pdb) l 125
120 pdb.set_trace()
121 for rnum in range(1, 5):
122 router = 'r{}'.format(rnum)
123
124 # Load expected results from the command
125 -> reffile = os.path.join(CWD, '{}/ospfroute.txt'.format(router))
126 expected = open(reffile).read()
127
128 # Run test function until we get an result. Wait at most 60 seconds.
129 test_func = partial(compare_show_ip_ospf, router, expected)
130 result, diff = topotest.run_and_expect(test_func, '',
(Pdb) router1 = tgen.gears[router]
(Pdb) router1.vtysh_cmd('show ip ospf route')
'============ OSPF network routing table ============\r\nN 10.0.1.0/24 [10] area: 0.0.0.0\r\n directly attached to r1-eth0\r\nN 10.0.2.0/24 [20] area: 0.0.0.0\r\n via 10.0.3.3, r1-eth1\r\nN 10.0.3.0/24 [10] area: 0.0.0.0\r\n directly attached to r1-eth1\r\nN 10.0.10.0/24 [20] area: 0.0.0.0\r\n via 10.0.3.1, r1-eth1\r\nN IA 172.16.0.0/24 [20] area: 0.0.0.0\r\n via 10.0.3.1, r1-eth1\r\nN IA 172.16.1.0/24 [30] area: 0.0.0.0\r\n via 10.0.3.1, r1-eth1\r\n\r\n============ OSPF router routing table =============\r\nR 10.0.255.2 [10] area: 0.0.0.0, ASBR\r\n via 10.0.3.3, r1-eth1\r\nR 10.0.255.3 [10] area: 0.0.0.0, ABR, ASBR\r\n via 10.0.3.1, r1-eth1\r\nR 10.0.255.4 IA [20] area: 0.0.0.0, ASBR\r\n via 10.0.3.1, r1-eth1\r\n\r\n============ OSPF external routing table ===========\r\n\r\n\r\n'
(Pdb) tgen.cli()
unet>
To enable more debug messages in other Topogen subsystems, more
logging messages can be displayed by modifying the test configuration file
``pytest.ini``:
.. code:: ini
[topogen]
# Change the default verbosity line from 'info'...
#verbosity = info
# ...to 'debug'
verbosity = debug
Instructions for use, write or debug topologies can be found in :ref:`topotests-guidelines`.
To learn/remember common code snippets see :ref:`topotests-snippets`.
Before creating a new topology, make sure that there isn't one already that
does what you need. If nothing is similar, then you may create a new topology,
preferably, using the newest template
(:file:`tests/topotests/example-test/test_template.py`).
.. include:: topotests-markers.rst
.. include:: topotests-snippets.rst
License
-------
All the configs and scripts are licensed under a ISC-style license. See Python
scripts for details.
Copy permalink