summaryrefslogtreecommitdiffstats
path: root/doc/user/setup.rst
diff options
context:
space:
mode:
Diffstat (limited to 'doc/user/setup.rst')
-rw-r--r--doc/user/setup.rst325
1 files changed, 325 insertions, 0 deletions
diff --git a/doc/user/setup.rst b/doc/user/setup.rst
new file mode 100644
index 0000000..372494f
--- /dev/null
+++ b/doc/user/setup.rst
@@ -0,0 +1,325 @@
+.. _basic-setup:
+
+Basic Setup
+============
+
+After installing FRR, some basic configuration must be completed before it is
+ready to use.
+
+Crash logs
+----------
+
+If any daemon should crash for some reason (segmentation fault, assertion
+failure, etc.), it will attempt to write a backtrace to a file located in
+:file:`/var/tmp/frr/<daemon>[-<instance>].<pid>/crashlog`. This feature is
+not affected by any configuration options.
+
+The crashlog file's directory also contains files corresponding to per-thread
+message buffers in files named
+:file:`/var/tmp/frr/<daemon>[-<instance>].<pid>/logbuf.<tid>`. In case of a
+crash, these may contain unwritten buffered log messages. To show the contents
+of these buffers, pipe their contents through ``tr '\0' '\n'``. A blank line
+marks the end of valid unwritten data (it will generally be followed by
+garbled, older log messages since the buffer is not cleared.)
+
+.. _daemons-configuration-file:
+
+Daemons Configuration File
+--------------------------
+After a fresh install, starting FRR will do nothing. This is because daemons
+must be explicitly enabled by editing a file in your configuration directory.
+This file is usually located at :file:`/etc/frr/daemons` and determines which
+daemons are activated when issuing a service start / stop command via init or
+systemd. The file initially looks like this:
+
+::
+
+ zebra=no
+ bgpd=no
+ ospfd=no
+ ospf6d=no
+ ripd=no
+ ripngd=no
+ isisd=no
+ pimd=no
+ ldpd=no
+ nhrpd=no
+ eigrpd=no
+ babeld=no
+ sharpd=no
+ staticd=no
+ pbrd=no
+ bfdd=no
+ fabricd=no
+
+ #
+ # If this option is set the /etc/init.d/frr script automatically loads
+ # the config via "vtysh -b" when the servers are started.
+ # Check /etc/pam.d/frr if you intend to use "vtysh"!
+ #
+ vtysh_enable=yes
+ zebra_options=" -s 90000000 --daemon -A 127.0.0.1"
+ bgpd_options=" --daemon -A 127.0.0.1"
+ ospfd_options=" --daemon -A 127.0.0.1"
+ ospf6d_options=" --daemon -A ::1"
+ ripd_options=" --daemon -A 127.0.0.1"
+ ripngd_options=" --daemon -A ::1"
+ isisd_options=" --daemon -A 127.0.0.1"
+ pimd_options=" --daemon -A 127.0.0.1"
+ ldpd_options=" --daemon -A 127.0.0.1"
+ nhrpd_options=" --daemon -A 127.0.0.1"
+ eigrpd_options=" --daemon -A 127.0.0.1"
+ babeld_options=" --daemon -A 127.0.0.1"
+ sharpd_options=" --daemon -A 127.0.0.1"
+ staticd_options=" --daemon -A 127.0.0.1"
+ pbrd_options=" --daemon -A 127.0.0.1"
+ bfdd_options=" --daemon -A 127.0.0.1"
+ fabricd_options=" --daemon -A 127.0.0.1"
+
+ #MAX_FDS=1024
+ # The list of daemons to watch is automatically generated by the init script.
+ #watchfrr_options=""
+
+ # for debugging purposes, you can specify a "wrap" command to start instead
+ # of starting the daemon directly, e.g. to use valgrind on ospfd:
+ # ospfd_wrap="/usr/bin/valgrind"
+ # or you can use "all_wrap" for all daemons, e.g. to use perf record:
+ # all_wrap="/usr/bin/perf record --call-graph -"
+ # the normal daemon command is added to this at the end.
+
+Breaking this file down:
+
+::
+
+ bgpd=yes
+
+To enable a particular daemon, simply change the corresponding 'no' to 'yes'.
+Subsequent service restarts should start the daemon.
+
+::
+
+ vtysh_enable=yes
+
+As the comment says, this causes :ref:`VTYSH <vty-shell>` to apply
+configuration when starting the daemons. This is useful for a variety of
+reasons touched on in the VTYSH documentation and should generally be enabled.
+
+::
+
+ MAX_FDS=1024
+
+This allows the operator to control the number of open file descriptors
+each daemon is allowed to start with. The current assumed value on
+most operating systems is 1024. If the operator plans to run bgp with
+several thousands of peers then this is where we would modify FRR to
+allow this to happen.
+
+::
+
+ FRR_NO_ROOT="yes"
+
+This option allows you to run FRR as a non-root user. Use this option
+only when you know what you are doing since most of the daemons
+in FRR will not be able to run under a regular user. This option
+is useful for example when you run FRR in a container with a designated
+user instead of root.
+
+::
+
+ zebra_options=" -s 90000000 --daemon -A 127.0.0.1"
+ bgpd_options=" --daemon -A 127.0.0.1"
+ ...
+
+The next set of lines controls what options are passed to daemons when started
+from the service script. Usually daemons will have ``--daemon`` and ``-A
+<address>`` specified in order to daemonize and listen for VTY commands on a
+particular address.
+
+The remaining file content regarding `watchfrr_options` and `*_wrap` settings
+should not normally be needed; refer to the comments in case they are.
+
+Services
+--------
+FRR daemons have their own terminal interface or VTY. After installation, it's
+a good idea to setup each daemon's port number to connect to them. To do this
+add the following entries to :file:`/etc/services`.
+
+::
+
+ zebrasrv 2600/tcp # zebra service
+ zebra 2601/tcp # zebra vty
+ ripd 2602/tcp # RIPd vty
+ ripngd 2603/tcp # RIPngd vty
+ ospfd 2604/tcp # OSPFd vty
+ bgpd 2605/tcp # BGPd vty
+ ospf6d 2606/tcp # OSPF6d vty
+ ospfapi 2607/tcp # ospfapi
+ isisd 2608/tcp # ISISd vty
+ babeld 2609/tcp # BABELd vty
+ nhrpd 2610/tcp # nhrpd vty
+ pimd 2611/tcp # PIMd vty
+ ldpd 2612/tcp # LDPd vty
+ eigprd 2613/tcp # EIGRPd vty
+ bfdd 2617/tcp # bfdd vty
+ fabricd 2618/tcp # fabricd vty
+ vrrpd 2619/tcp # vrrpd vty
+
+
+If you use a FreeBSD newer than 2.2.8, the above entries are already added to
+:file:`/etc/services` so there is no need to add it. If you specify a port
+number when starting the daemon, these entries may not be needed.
+
+You may need to make changes to the config files in |INSTALL_PREFIX_ETC|.
+
+Systemd
+-------
+Although not installed when installing from source, FRR provides a service file
+for use with ``systemd``. It is located in :file:`tools/frr.service` in the Git
+repository. If ``systemctl status frr.service`` indicates that the FRR service
+is not found, copy the service file from the Git repository into your preferred
+location. A good place is usually ``/etc/systemd/system/``.
+
+After issuing a ``systemctl daemon-reload``, you should be able to start the
+FRR service via ``systemctl start frr``. If this fails, or no daemons are
+started. check the ``journalctl`` logs for an indication of what went wrong.
+
+Operations
+----------
+
+This section covers a few common operational tasks and how to perform them.
+
+Interactive Shell
+^^^^^^^^^^^^^^^^^
+FRR offers an IOS-like interactive shell called ``vtysh`` where a user can run
+individual configuration or show commands. To get into this shell, issue the
+``vtysh`` command from either a privilege user (root, or with sudo) or a user
+account that is part of the ``frrvty`` group.
+e.g.
+
+.. code-block:: console
+
+ root@ub18:~# vtysh
+
+ Hello, this is FRRouting (version 8.1-dev).
+ Copyright 1996-2005 Kunihiro Ishiguro, et al.
+
+ ub18#
+
+.. note::
+ The default install location for vtysh is /usr/bin/vtysh
+
+
+Restarting
+^^^^^^^^^^
+
+Restarting kills all running FRR daemons and starts them again. Any unsaved
+configuration will be lost.
+
+.. code-block:: console
+
+ service frr restart
+
+.. note::
+
+ Alternatively, you can invoke the init script directly::
+
+ /etc/init.d/frr restart
+
+ Or, if using systemd::
+
+ systemctl restart frr
+
+Reloading
+^^^^^^^^^
+
+Reloading applies the differential between on-disk configuration and the
+current effective configuration of running FRR processes. This includes
+starting daemons that were previously stopped and any changes made to
+individual or unified daemon configuration files.
+
+.. code-block:: console
+
+ service frr reload
+
+.. note::
+
+ Alternatively, you can invoke the init script directly::
+
+ /etc/init.d/frr reload
+
+ Or, if using systemd::
+
+ systemctl reload frr
+
+See :ref:`FRR-RELOAD <frr-reload>` for more about the `frr-reload.py` script.
+
+
+Starting a new daemon
+^^^^^^^^^^^^^^^^^^^^^
+
+Suppose *bgpd* and *zebra* are running, and you wish to start *pimd*. In
+``/etc/frr/daemons`` make the following change:
+
+.. code-block:: diff
+
+ - pimd=no
+ + pimd=yes
+
+Then perform a reload.
+
+Currently there is no way to stop or restart an individual daemon. This is
+because FRR's monitoring program cannot currently distinguish between a crashed
+/ killed daemon versus one that has been intentionally stopped or restarted.
+The closest that can be achieved is to remove all configuration for the daemon,
+and set its line in ``/etc/frr/daemons`` to ``=no``. Once this is done, the
+daemon will be stopped the next time FRR is restarted.
+
+
+Network Namespaces
+^^^^^^^^^^^^^^^^^^
+
+It is possible to run FRR in different network namespaces so it can be
+further compartmentalized (e.g. confining to a smaller subset network).
+The network namespace configuration can be used in the default FRR
+configuration pathspace or it can be used in a different pathspace
+(`-N/--pathspace`).
+
+To use FRR network namespace in the default pathspace you should add
+or uncomment the ``watchfrr_options`` line in ``/etc/frr/daemons``:
+
+.. code-block:: diff
+
+ - #watchfrr_options="--netns"
+ + watchfrr_options="--netns=<network-namespace-name>"
+
+If you want to use a different pathspace with the network namespace
+(the recommended way) you should add/uncomment the ``watchfrr_options``
+line in ``/etc/frr/<namespace>/daemons``:
+
+.. code-block:: diff
+
+ - #watchfrr_options="--netns"
+ + #watchfrr_options="--netns=<network-namespace-name>"
+ +
+ + # `--netns` argument is optional and if not provided it will
+ + # default to the pathspace name.
+ + watchfrr_options="--netns"
+
+To start FRR in the new pathspace+network namespace the initialization script
+should be called with an extra parameter:
+
+
+.. code::
+
+ /etc/init.d/frr start <pathspace-name>
+
+
+.. note::
+
+ Some Linux distributions might not use the default init script
+ shipped with FRR, in that case you might want to try running the
+ bundled script in ``/usr/lib/frr/frrinit.sh``.
+
+ On systemd you might create different units or parameterize the
+ existing one. See the man page:
+ https://www.freedesktop.org/software/systemd/man/systemd.unit.html