Merge pull request #9472 from rampxxxx/pathd_doc_augmented

[mirror_frr.git] / doc / user / setup.rst

.. _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
--------------------------
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 than this is where we would modify FRR to
allow this to happen.

::

   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