diff options
Diffstat (limited to 'doc/developer')
| -rw-r--r-- | doc/developer/building-frr-for-centos6.rst | 6 | ||||
| -rw-r--r-- | doc/developer/building-frr-for-ubuntu1804.rst | 2 | ||||
| -rw-r--r-- | doc/developer/building-libyang.rst | 20 | ||||
| -rw-r--r-- | doc/developer/conf.py | 2 | ||||
| -rw-r--r-- | doc/developer/index.rst | 1 | ||||
| -rw-r--r-- | doc/developer/maintainer-release-build.rst | 4 | ||||
| -rw-r--r-- | doc/developer/modules.rst | 6 | ||||
| -rw-r--r-- | doc/developer/next-hop-tracking.rst | 2 | ||||
| -rw-r--r-- | doc/developer/packaging-debian.rst | 4 | ||||
| -rw-r--r-- | doc/developer/packaging.rst | 1 | ||||
| -rw-r--r-- | doc/developer/process-architecture.rst | 4 | ||||
| -rw-r--r-- | doc/developer/vtysh.rst | 201 | ||||
| -rw-r--r-- | doc/developer/workflow.rst | 58 | ||||
| -rw-r--r-- | doc/developer/zebra.rst | 383 |
14 files changed, 575 insertions, 119 deletions
diff --git a/doc/developer/building-frr-for-centos6.rst b/doc/developer/building-frr-for-centos6.rst index 5f9ce705f2..c57573cb9f 100644 --- a/doc/developer/building-frr-for-centos6.rst +++ b/doc/developer/building-frr-for-centos6.rst @@ -244,7 +244,7 @@ Load the modifed sysctl's on the system: Add init.d startup files ^^^^^^^^^^^^^^^^^^^^^^^^ -.. code-block:: +.. code-block:: shell sudo install -p -m 755 redhat/frr.init /etc/init.d/frr sudo chkconfig --add frr @@ -252,13 +252,13 @@ Add init.d startup files Enable FRR daemon at startup ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -.. code-block:: +.. code-block:: shell sudo chkconfig frr on Start FRR manually (or reboot) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -.. code-block:: +.. code-block:: shell sudo /etc/init.d/frr start diff --git a/doc/developer/building-frr-for-ubuntu1804.rst b/doc/developer/building-frr-for-ubuntu1804.rst index 2d1edc063d..e69ded8f73 100644 --- a/doc/developer/building-frr-for-ubuntu1804.rst +++ b/doc/developer/building-frr-for-ubuntu1804.rst @@ -115,7 +115,7 @@ Create empty FRR configuration files ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Although not strictly necessary, it's good practice to create empty -configuration files _before_ starting FRR. This assures that the permissions +configuration files _before_ starting FRR. This assures that the permissions are correct. If the files are not already present, FRR will create them. It's also important to consider _which_ files to create. FRR supports writing diff --git a/doc/developer/building-libyang.rst b/doc/developer/building-libyang.rst index 9757ad454e..005b6ba786 100644 --- a/doc/developer/building-libyang.rst +++ b/doc/developer/building-libyang.rst @@ -40,23 +40,3 @@ When building libyang on CentOS 6, it's also necessary to pass the Note: please check the `libyang build requirements <https://github.com/CESNET/libyang/blob/master/README.md#build-requirements>`_ first. - -Libyang uses loadable libraries an YANG modules. It supports -environment variables to allow overriding the load paths for each of -these. With FRR, this override currently must be done at the time of -running FRR's configure command using new options. The new options are: - -.. code-block:: shell - - --with-yangmodelsdir=DIR - yang models directory (${datarootdir}/yang) - --with-libyang-pluginsdir=DIR - yangmodule plugins directory - (${libdir}/frr/libyang_plugins) - -an example which uses the compile directory is: - -.. code-block:: shell - - ./configure --with-libyang-pluginsdir="`pwd`/yang/libyang_plugins/.libs" \ - --with-yangmodelsdir="`pwd`/yang" diff --git a/doc/developer/conf.py b/doc/developer/conf.py index 61253c4b2f..254c9f6bfc 100644 --- a/doc/developer/conf.py +++ b/doc/developer/conf.py @@ -131,7 +131,7 @@ language = None # List of patterns, relative to source directory, that match files and # directories to ignore when looking for source files. -exclude_patterns = ['_build'] +exclude_patterns = ['_build', 'building-libyang.rst'] # The reST default role (used for this markup: `text`) to use for all # documents. diff --git a/doc/developer/index.rst b/doc/developer/index.rst index 42192db637..9838e1098c 100644 --- a/doc/developer/index.rst +++ b/doc/developer/index.rst @@ -12,3 +12,4 @@ FRRouting Developer's Guide bgpd ospf zebra + vtysh diff --git a/doc/developer/maintainer-release-build.rst b/doc/developer/maintainer-release-build.rst index 907bd14ee6..85aaa5365a 100644 --- a/doc/developer/maintainer-release-build.rst +++ b/doc/developer/maintainer-release-build.rst @@ -1,5 +1,5 @@ -Release Build Procedure for FRR maintainers -========================================================= +Release Build Procedure for FRR Maintainers +=========================================== 1. Rename branch (if needed) diff --git a/doc/developer/modules.rst b/doc/developer/modules.rst index bde7682e4e..99c79462ab 100644 --- a/doc/developer/modules.rst +++ b/doc/developer/modules.rst @@ -103,9 +103,9 @@ standard entry point for loadable modules. Command line parameters ----------------------- -Command line parameters can be passed directly to a module by appending a -colon to the module name when loading it, e.g. ``-M mymodule:myparameter``. -The text after the colon will be accessible in the module's code through +Command line parameters can be passed directly to a module by appending a +colon to the module name when loading it, e.g. ``-M mymodule:myparameter``. +The text after the colon will be accessible in the module's code through ``THIS_MODULE->load_args``. For example, see how the format parameter is configured in the ``zfpm_init()`` function inside ``zebra_fpm.c``. diff --git a/doc/developer/next-hop-tracking.rst b/doc/developer/next-hop-tracking.rst index e6484102a8..a9af5e749c 100644 --- a/doc/developer/next-hop-tracking.rst +++ b/doc/developer/next-hop-tracking.rst @@ -269,7 +269,7 @@ RNH table:: O O / \ O O - + struct rnh { uint8_t flags; diff --git a/doc/developer/packaging-debian.rst b/doc/developer/packaging-debian.rst index 4ea784c0fc..c812a38212 100644 --- a/doc/developer/packaging-debian.rst +++ b/doc/developer/packaging-debian.rst @@ -1,5 +1,5 @@ -Debian -====== +Packaging Debian +================ (Tested on Ubuntu 12.04, 14.04, 16.04, 17.10, 18.04, Debian 8 and 9) diff --git a/doc/developer/packaging.rst b/doc/developer/packaging.rst index e9bb3a5409..27e6e155fb 100644 --- a/doc/developer/packaging.rst +++ b/doc/developer/packaging.rst @@ -5,4 +5,5 @@ Packaging .. toctree:: :maxdepth: 2 + maintainer-release-build packaging-debian diff --git a/doc/developer/process-architecture.rst b/doc/developer/process-architecture.rst index 806afa644c..6e0eb68188 100644 --- a/doc/developer/process-architecture.rst +++ b/doc/developer/process-architecture.rst @@ -118,7 +118,7 @@ The following diagram illustrates a simplified version of this infrastructure. .. todo: replace these with SVG .. figure:: ../figures/threadmaster-single.png :align: center - + Lifecycle of a program using a single threadmaster. The series of "task" boxes represents the current ready task queue. The various @@ -183,7 +183,7 @@ running their own ``threadmaster``-based event loop. .. todo: replace these with SVG .. figure:: ../figures/threadmaster-multiple.png :align: center - + Lifecycle of a program using multiple pthreads, each running their own ``threadmaster`` diff --git a/doc/developer/vtysh.rst b/doc/developer/vtysh.rst new file mode 100644 index 0000000000..4a52eb0544 --- /dev/null +++ b/doc/developer/vtysh.rst @@ -0,0 +1,201 @@ +.. _vtysh: + +***** +VTYSH +***** + +.. seealso:: :ref:`command-line-interface` + +.. _vtysh-architecture: + +Architecture +============ + +VTYSH is a shell for FRR daemons. It amalgamates all the CLI commands defined +in each of the daemons and presents them to the user in a single shell, which +saves the user from having to telnet to each of the daemons and use their +individual shells. The amalgamation is achieved by +:ref:`extracting <vtysh-command-extraction>` commands from daemons and +injecting them into VTYSH at build time. + +At runtime, VTYSH maintains an instance of a CLI mode tree just like each +daemon. However, the mode tree in VTYSH contains (almost) all commands from +every daemon in the same tree, whereas individual daemons have trees that only +contain commands relevant to themselves. VTYSH also uses the library CLI +facilities to maintain the user's current position in the tree (the current +node). Note that this position must be synchronized with all daemons; if a +daemon receives a command that causes it to change its current node, VTYSH must +also change its node. Since the extraction script does not understand the +handler code of commands, but only their definitions, this and other behaviors +must be manually programmed into VTYSH for every case where the internal state +of VTYSH must change in response to a command. Details on how this is done are +discussed in the :ref:`vtysh-special-defuns` section. + +VTYSH also handles writing and applying the integrated configuration file, +:file:`/etc/frr/frr.conf`. Since it has knowledge of the entire command space +of FRR, it can intelligently distribute configuration commands only to the +daemons that understand them. Similarly, when writing the configuration file it +takes care of combining multiple instances of configuration blocks and +simplifying the output. This is discussed in :ref:`vtysh-configuration`. + +.. _vtysh-command-extraction: + +Command Extraction +------------------ + +When VTYSH is a built, a Perl script named :file:`extract.pl` searches the FRR +codebase looking for ``DEFUN``'s. It extracts these ``DEFUN``'s, transforms +them into ``DEFSH``'s and appends them to ``vtysh_cmd.c``. Each ``DEFSH`` +contains the name of the command plus ``_vtysh``, as well as a flag that +indicates which daemons the command was found in. When the command is executed +in VTYSH, this flag is inspected to determine which daemons to send the command +to. This way, commands are only sent to the daemons that know about them, +avoiding spurious errors from daemons that don't have the command defined. + +The extraction script contains lots of hardcoded knowledge about what sources +to look at and what flags to use for certain commands. + +.. _vtysh-special-defuns: + +Special DEFUNs +-------------- + +In addition to the vanilla ``DEFUN`` macro for defining CLI commands, there are +several VTYSH-specific ``DEFUN`` variants that each serve different purposes. + +``DEFSH`` + Used almost exclusively by generated VTYSH code. This macro defines a + ``cmd_element`` with no handler function; the command, when executed, is + simply forwarded to the daemons indicated in the daemon flag. + +``DEFUN_NOSH`` + Used by daemons. Has the same expansion as a ``DEFUN``, but ``extract.pl`` + will skip these definitions when extracting commands. This is typically used + when VTYSH must take some special action upon receiving the command, and the + programmer therefore needs to write VTYSH's copy of the command manually + instead of using the generated version. + +``DEFUNSH`` + The same as ``DEFUN``, but with an argument that allows specifying the + ``->daemon`` field of the generated ``cmd_element``. This is used by VTYSH + to determine which daemons to send the command to. + +``DEFUNSH_ATTR`` + A version of ``DEFUNSH`` that allows setting the ``->attr`` field of the + generated ``cmd_element``. Not used in practice. + +.. _vtysh-configuration: + +Configuration Management +------------------------ + +When integrated configuration is used, VTYSH manages writing, reading and +applying the FRR configuration file. VTYSH can be made to read and apply an +integrated configuration to all running daemons by launching it with ``-f +<file>``. It sends the appropriate configuration lines to the relevant daemons +in the same way that commands entered by the user on VTYSH's shell prompt are +processed. + +Configuration writing is more complicated. VTYSH makes a best-effort attempt to +combine and simplify the configuration as much as possible. A working example +is best to explain this behavior. + +Example +^^^^^^^ + +Suppose we have just *staticd* and *zebra* running on the system, and use VTYSH +to apply the following configuration snippet: + +.. code-block:: frr + + ! + vrf blue + ip protocol static route-map ExampleRoutemap + ip route 192.168.0.0/24 192.168.0.1 + exit-vrf + ! + +Note that *staticd* defines static route commands and *zebra* defines ``ip +protocol`` commands. Therefore if we ask only *zebra* for its configuration, we +get the following:: + + (config)# do sh running-config zebra + Building configuration... + + ... + ! + vrf blue + ip protocol static route-map ExampleRoutemap + exit-vrf + ! + ... + +Note that the static route doesn't show up there. Similarly, if we ask +*staticd* for its configuration, we get:: + + (config)# do sh running-config staticd + + ... + ! + vrf blue + ip route 192.168.0.0/24 192.168.0.1 + exit-vrf + ! + ... + +But when we display the configuration with VTYSH, we see:: + + ubuntu-bionic(config)# do sh running-config + + ... + ! + vrf blue + ip protocol static route-map ExampleRoutemap + ip route 192.168.0.0/24 192.168.0.1 + exit-vrf + ! + ... + +This is because VTYSH asks each daemon for its currently running configuration, +and combines equivalent blocks together. In the above example, it combined the +``vrf blue`` blocks from both *zebra* and *staticd* together into one. This is +done in :file:`vtysh_config.c`. + +Protocol +======== + +VTYSH communicates with FRR daemons by way of domain socket. Each daemon +creates its own socket, typically in :file:`/var/run/frr/<daemon>.vty`. The +protocol is very simple. In the VTYSH to daemon direction, messages are simply +NULL-terminated strings, whose content are CLI commands. Here is a typical +message from VTYSH to a daemon: + +:: + + Request + + 00000000: 646f 2077 7269 7465 2074 6572 6d69 6e61 do write termina + 00000010: 6c0a 00 l.. + + +The response format has some more data in it. First is a NULL-terminated string +containing the plaintext response, which is just the output of the command that +was sent in the request. This is displayed to the user. The plaintext response +is followed by 3 null marker bytes, followed by a 1-byte status code that +indicates whether the command was successful or not. + +:: + + Response + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Plaintext Response | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Marker (0x00) | Status Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +The first ``0x00`` byte in the marker also serves to terminate the plaintext +response. diff --git a/doc/developer/workflow.rst b/doc/developer/workflow.rst index ee7592fd6a..543dfdd3b9 100644 --- a/doc/developer/workflow.rst +++ b/doc/developer/workflow.rst @@ -91,17 +91,63 @@ documentation and packaging systems will be updated to reflect the next possible release name to allow for easy distinguishing. After one month the development branch will be renamed to -``stable/MAJOR.MINOR``. This process is not held up unless a crash or security -issue has been found and needs to be addressed. Issues being fixed will not -cause a delay. +``stable/MAJOR.MINOR``. The branch is a stable branch. This process is not +held up unless a crash or security issue has been found and needs to +be addressed. Issues being fixed will not cause a delay. Bugfix releases are made as needed at 1 month intervals until the next -``MAJOR.MINOR`` relese branch is pulled. Depending on the severity of the bugs, +``MAJOR.MINOR`` release branch is pulled. Depending on the severity of the bugs, bugfix releases may occur sooner. Bugfixes are applied to the two most recent releases. Security fixes are -backported to all releases less than or equal to one year old. Security fixes -may also be backported to older releases depending on severity. +backported to all releases less than or equal to at least one year old. Security +fixes may also be backported to older releases depending on severity. + +Long term support branches ( LTS ) +----------------------------------------- + +This kind of branch is not yet officially supported, and need experimentation +before being effective. + +Previous definition of releases prevents long term support of previous releases. +For instance, bug and security fixes are not applied if the stable branch is too +old. + +Because the FRR users have a need to backport bug and security fixes after the +stable branch becomes too old, there is a need to provide support on a long term +basis on that stable branch. If that support is applied on that stable branch, +then that branch is a long term support branch. + +Having a LTS branch requires extra-work and requires one person to be in charge +of that maintenance branch for a certain amount of time. The amount of time will +be by default set to 4 months, and can be increased. 4 months stands for the time +between two releases, this time can be applied to the decision to continue with a +LTS release or not. In all cases, that time period will be well-defined and +published. Also, a self nomination from a person that proposes to handle the LTS +branch is required. The work can be shared by multiple people. In all cases, there +must be at least one person that is in charge of the maintenance branch. The person +on people responsible for a maintenance branch must be a FRR maintainer. Note that +they may choose to abandon support for the maintenance branch at any time. If +noone takes over the responsibility of the LTS branch, then the support will be +discontinued. + +The LTS branch duties are the following ones: + +- organise meetings on a (bi-)weekly or monthly basis, the handling of issues + and pull requested relative to that branch. When time permits, this may be done + during the regularly scheduled FRR meeting. + +- ensure the stability of the branch, by using and eventually adapting the + checking the CI tools of FRR ( indeed, maintaining may lead to create + maintenance branches for topotests or for CI). + +It will not be possible to backport feature requests to LTS branches. Actually, it +is a false good idea to use LTS for that need. Introducing feature requests may +break the paradigm where all more recent releases should also include the feature +request. This would require the LTS maintainer to ensure that all more recent +releases have support for this feature request. Moreover, introducing features +requests may result in breaking the stability of the branch. LTS branches are first +done to bring long term support for stability. Changelog --------- diff --git a/doc/developer/zebra.rst b/doc/developer/zebra.rst index 1bf31e9624..f771d48235 100644 --- a/doc/developer/zebra.rst +++ b/doc/developer/zebra.rst @@ -9,108 +9,335 @@ Zebra Overview of the Zebra Protocol ============================== -Zebra Protocol is used by protocol daemons to communicate with the zebra -daemon. +The Zebra protocol is used by protocol daemons to communicate with the +**zebra** daemon. -Each protocol daemon may request and send information to and from the zebra +Each protocol daemon may request and send information to and from the **zebra** daemon such as interface states, routing state, nexthop-validation, and so on. -Protocol daemons may also install routes with zebra. The zebra daemon manages -which route is installed into the forwarding table with the kernel. - -Zebra Protocol is a streaming protocol, with a common header. Two versions of -the header are in use. Version 0 is implicitely versioned. Version 1 has an -explicit version field. Version 0 can be distinguished from all other versions -by examining the 3rd byte of the header, which contains a marker value for all -versions bar version 0. The marker byte corresponds to the command field in -version 0, and the marker value is a reserved command in version 0. - -We do not anticipate there will be further versions of the header for the -foreseeable future, as the command field in version 1 is wide enough to allow -for future extensions to done compatibly through seperate commands. - -Version 0 is used by all versions of GNU Zebra as of this writing, and versions -of Quagga up to and including Quagga 0.98. Version 2 was created for 0.99.21 of -Quagga. Version 3 designates VRF compatibility and was released in 1.0. -Version 4 will be used as of FRR 2.0 to indicate that we are a different -Routing Suite now and to hopefully prevent accidental Quagga <-> FRR issues. +Protocol daemons may also install routes with **zebra**. The **zebra** daemon +manages which routes are installed into the forwarding table with the kernel. -Zebra Protocol Definition -========================= +The Zebra protocol is a streaming protocol, with a common header. Version 0 +lacks a version field and is implicitly versioned. Version 1 and all subsequent +versions have a version field. Version 0 can be distinguished from all other +versions by examining the 3rd byte of the header, which contains a marker value +of 255 (in Quagga) or 254 (in FRR) for all versions except version 0. The +marker byte corresponds to the command field in version 0, and the marker value +is a reserved command in version 0. -Zebra Protocol Header (version 0) ----------------------------------- +Version History +--------------- -:: +- Version 0 - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-------------------------------+---------------+ - | Length (2) | Command (1) | - +-------------------------------+---------------+ + Used by all versions of GNU Zebra and all version of Quagga up to and + including Quagga 0.98. This version has no ``version`` field, and so is + implicitly versioned as version 0. +- Version 1 -Zebra Protocol Common Header (version 1) ----------------------------------------- + Added ``marker`` and ``version`` fields, increased ``command`` field to 16 + bits. Used by Quagga versions 0.99.3 through 0.99.20. -:: +- Version 2 + + Used by Quagga versions 0.99.21 through 0.99.23. + +- Version 3 + + Added ``vrf_id`` field. Used by Quagga versions 0.99.23 until FRR fork. + +- Version 4 + + Change marker value to 254 to prevent people mixing and matching Quagga and + FRR daemon binaries. Used by FRR versions 2.0 through 3.0.3. + +- Version 5 - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-------------------------------+---------------+-------------+ - | Length (2) | Marker (1) | Version (1) | - +-------------------------------+---------------+-------------+ - | Command (2) | - +-------------------------------+ + Increased VRF identifier field from 16 to 32 bits. Used by FRR versions 4.0 + through 5.0.1. +- Version 6 + + Removed the following commands: + + * ZEBRA_IPV4_ROUTE_ADD + * ZEBRA_IPV4_ROUTE_DELETE + * ZEBRA_IPV6_ROUTE_ADD + * ZEBRA_IPV6_ROUTE_DELETE + + Used since FRR version 6.0. + + +Zebra Protocol Definition +========================= Zebra Protocol Header Field Definitions --------------------------------------- Length - Total packet length including this header. The minimum length is 3 bytes for - version 0 messages and 6 bytes for version 1 messages. + Total packet length including this header. Marker - Static marker with a value of 255 always. This is to allow version 0 Zserv - headers (which do not include version explicitly) to be distinguished from - versioned headers. Not present in version 0 messages. + Static marker. The marker value, when it exists, is 255 in all versions of + Quagga. It is 254 in all versions of FRR. This is to allow version 0 headers + (which do not include version explicitly) to be distinguished from versioned + headers. Version - Version number of the Zserv message. Clients should not continue processing - messages past the version field for versions they do not recognise. Not - present in version 0 messages. + Zebra protocol version number. Clients should not continue processing + messages past the version field for versions they do not recognise. Command - The Zebra Protocol command. + The Zebra protocol command. + + +Current Version +^^^^^^^^^^^^^^^ + +:: + + Version 5, 6 + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | Marker | Version | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | VRF ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Command | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +Past Versions +^^^^^^^^^^^^^ + +:: + + Version 0 + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | Command | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +:: + + Version 1, 2 + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | Marker | Version | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Command | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +:: + + Version 3, 4 + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | Marker | Version | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | VRF ID | Command | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zebra Protocol Commands ----------------------- -+-----------------------------------+-------+ -| Command | Value | -+===================================+=======+ -| ZEBRA_INTERFACE_ADD | 1 | -+-----------------------------------+-------+ -| ZEBRA_INTERFACE_DELETE | 2 | -+-----------------------------------+-------+ -| ZEBRA_INTERFACE_ADDRESS_ADD | 3 | -+-----------------------------------+-------+ -| ZEBRA_INTERFACE_ADDRESS_DELETE | 4 | -+-----------------------------------+-------+ -| ZEBRA_INTERFACE_UP | 5 | -+-----------------------------------+-------+ -| ZEBRA_INTERFACE_DOWN | 6 | -+-----------------------------------+-------+ -| ZEBRA_REDISTRIBUTE_ADD | 11 | -+-----------------------------------+-------+ -| ZEBRA_REDISTRIBUTE_DELETE | 12 | -+-----------------------------------+-------+ -| ZEBRA_REDISTRIBUTE_DEFAULT_ADD | 13 | -+-----------------------------------+-------+ -| ZEBRA_REDISTRIBUTE_DEFAULT_DELETE | 14 | -+-----------------------------------+-------+ -| ZEBRA_IPV4_NEXTHOP_LOOKUP | 15 | -+-----------------------------------+-------+ -| ZEBRA_IPV6_NEXTHOP_LOOKUP | 16 | -+-----------------------------------+-------+ ++------------------------------------+-------+ +| Command | Value | ++====================================+=======+ +| ZEBRA_INTERFACE_ADD | 0 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_DELETE | 1 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_ADDRESS_ADD | 2 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_ADDRESS_DELETE | 3 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_UP | 4 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_DOWN | 5 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_SET_MASTER | 6 | ++------------------------------------+-------+ +| ZEBRA_ROUTE_ADD | 7 | ++------------------------------------+-------+ +| ZEBRA_ROUTE_DELETE | 8 | ++------------------------------------+-------+ +| ZEBRA_ROUTE_NOTIFY_OWNER | 9 | ++------------------------------------+-------+ +| ZEBRA_REDISTRIBUTE_ADD | 10 | ++------------------------------------+-------+ +| ZEBRA_REDISTRIBUTE_DELETE | 11 | ++------------------------------------+-------+ +| ZEBRA_REDISTRIBUTE_DEFAULT_ADD | 12 | ++------------------------------------+-------+ +| ZEBRA_REDISTRIBUTE_DEFAULT_DELETE | 13 | ++------------------------------------+-------+ +| ZEBRA_ROUTER_ID_ADD | 14 | ++------------------------------------+-------+ +| ZEBRA_ROUTER_ID_DELETE | 15 | ++------------------------------------+-------+ +| ZEBRA_ROUTER_ID_UPDATE | 16 | ++------------------------------------+-------+ +| ZEBRA_HELLO | 17 | ++------------------------------------+-------+ +| ZEBRA_CAPABILITIES | 18 | ++------------------------------------+-------+ +| ZEBRA_NEXTHOP_REGISTER | 19 | ++------------------------------------+-------+ +| ZEBRA_NEXTHOP_UNREGISTER | 20 | ++------------------------------------+-------+ +| ZEBRA_NEXTHOP_UPDATE | 21 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_NBR_ADDRESS_ADD | 22 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_NBR_ADDRESS_DELETE | 23 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_BFD_DEST_UPDATE | 24 | ++------------------------------------+-------+ +| ZEBRA_IMPORT_ROUTE_REGISTER | 25 | ++------------------------------------+-------+ +| ZEBRA_IMPORT_ROUTE_UNREGISTER | 26 | ++------------------------------------+-------+ +| ZEBRA_IMPORT_CHECK_UPDATE | 27 | ++------------------------------------+-------+ +| ZEBRA_BFD_DEST_REGISTER | 28 | ++------------------------------------+-------+ +| ZEBRA_BFD_DEST_DEREGISTER | 29 | ++------------------------------------+-------+ +| ZEBRA_BFD_DEST_UPDATE | 30 | ++------------------------------------+-------+ +| ZEBRA_BFD_DEST_REPLAY | 31 | ++------------------------------------+-------+ +| ZEBRA_REDISTRIBUTE_ROUTE_ADD | 32 | ++------------------------------------+-------+ +| ZEBRA_REDISTRIBUTE_ROUTE_DEL | 33 | ++------------------------------------+-------+ +| ZEBRA_VRF_UNREGISTER | 34 | ++------------------------------------+-------+ +| ZEBRA_VRF_ADD | 35 | ++------------------------------------+-------+ +| ZEBRA_VRF_DELETE | 36 | ++------------------------------------+-------+ +| ZEBRA_VRF_LABEL | 37 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_VRF_UPDATE | 38 | ++------------------------------------+-------+ +| ZEBRA_BFD_CLIENT_REGISTER | 39 | ++------------------------------------+-------+ +| ZEBRA_BFD_CLIENT_DEREGISTER | 40 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_ENABLE_RADV | 41 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_DISABLE_RADV | 42 | ++------------------------------------+-------+ +| ZEBRA_IPV3_NEXTHOP_LOOKUP_MRIB | 44 | ++------------------------------------+-------+ +| ZEBRA_INTERFACE_LINK_PARAMS | 44 | ++------------------------------------+-------+ +| ZEBRA_MPLS_LABELS_ADD | 45 | ++------------------------------------+-------+ +| ZEBRA_MPLS_LABELS_DELETE | 46 | ++------------------------------------+-------+ +| ZEBRA_IPMR_ROUTE_STATS | 47 | ++------------------------------------+-------+ +| ZEBRA_LABEL_MANAGER_CONNECT | 48 | ++------------------------------------+-------+ +| ZEBRA_LABEL_MANAGER_CONNECT_ASYNC | 49 | ++------------------------------------+-------+ +| ZEBRA_GET_LABEL_CHUNK | 50 | ++------------------------------------+-------+ +| ZEBRA_RELEASE_LABEL_CHUNK | 51 | ++------------------------------------+-------+ +| ZEBRA_FEC_REGISTER | 52 | ++------------------------------------+-------+ +| ZEBRA_FEC_UNREGISTER | 53 | ++------------------------------------+-------+ +| ZEBRA_FEC_UPDATE | 54 | ++------------------------------------+-------+ +| ZEBRA_ADVERTISE_DEFAULT_GW | 55 | ++------------------------------------+-------+ +| ZEBRA_ADVERTISE_SUBNET | 56 | ++------------------------------------+-------+ +| ZEBRA_ADVERTISE_ALL_VNI | 57 | ++------------------------------------+-------+ +| ZEBRA_LOCAL_ES_ADD | 58 | ++------------------------------------+-------+ +| ZEBRA_LOCAL_ES_DEL | 59 | ++------------------------------------+-------+ +| ZEBRA_VNI_ADD | 60 | ++------------------------------------+-------+ +| ZEBRA_VNI_DEL | 61 | ++------------------------------------+-------+ +| ZEBRA_L2VNI_ADD | 63 | ++------------------------------------+-------+ +| ZEBRA_L2VNI_DEL | 64 | ++------------------------------------+-------+ +| ZEBRA_REMOTE_VTEP_ADD | 64 | ++------------------------------------+-------+ +| ZEBRA_REMOTE_VTEP_DEL | 65 | ++------------------------------------+-------+ +| ZEBRA_MACIP_ADD | 66 | ++------------------------------------+-------+ +| ZEBRA_MACIP_DEL | 67 | ++------------------------------------+-------+ +| ZEBRA_IP_PREFIX_ROUTE_ADD | 68 | ++------------------------------------+-------+ +| ZEBRA_IP_PREFIX_ROUTE_DEL | 69 | ++------------------------------------+-------+ +| ZEBRA_REMOTE_MACIP_ADD | 70 | ++------------------------------------+-------+ +| ZEBRA_REMOTE_MACIP_DEL | 71 | ++------------------------------------+-------+ +| ZEBRA_PW_ADD | 72 | ++------------------------------------+-------+ +| ZEBRA_PW_DELETE | 73 | ++------------------------------------+-------+ +| ZEBRA_PW_SET | 74 | ++------------------------------------+-------+ +| ZEBRA_PW_UNSET | 75 | ++------------------------------------+-------+ +| ZEBRA_PW_STATUS_UPDATE | 76 | ++------------------------------------+-------+ +| ZEBRA_RULE_ADD | 77 | ++------------------------------------+-------+ +| ZEBRA_RULE_DELETE | 78 | ++------------------------------------+-------+ +| ZEBRA_RULE_NOTIFY_OWNER | 79 | ++------------------------------------+-------+ +| ZEBRA_TABLE_MANAGER_CONNECT | 80 | ++------------------------------------+-------+ +| ZEBRA_GET_TABLE_CHUNK | 81 | ++------------------------------------+-------+ +| ZEBRA_RELEASE_TABLE_CHUNK | 82 | ++------------------------------------+-------+ +| ZEBRA_IPSET_CREATE | 83 | ++------------------------------------+-------+ +| ZEBRA_IPSET_DESTROY | 84 | ++------------------------------------+-------+ +| ZEBRA_IPSET_ENTRY_ADD | 85 | ++------------------------------------+-------+ +| ZEBRA_IPSET_ENTRY_DELETE | 86 | ++------------------------------------+-------+ +| ZEBRA_IPSET_NOTIFY_OWNER | 87 | ++------------------------------------+-------+ +| ZEBRA_IPSET_ENTRY_NOTIFY_OWNER | 88 | ++------------------------------------+-------+ +| ZEBRA_IPTABLE_ADD | 89 | ++------------------------------------+-------+ +| ZEBRA_IPTABLE_DELETE | 90 | ++------------------------------------+-------+ +| ZEBRA_IPTABLE_NOTIFY_OWNER | 91 | ++------------------------------------+-------+ +| ZEBRA_VXLAN_FLOOD_CONTROL | 92 | ++------------------------------------+-------+ |