From 42fc5d26696cfa646edd21883d32a520816f5cc3 Mon Sep 17 00:00:00 2001
From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Fri, 15 Dec 2017 13:16:24 -0500
Subject: doc: start translating user manual to rst

Automatically translated all Texinfo files to RST using a script found
on the GCC mailing list[0]. Some formatting manually corrected.

Also created index.rst for building as well as boilerplate Sphinx
conf.py and Makefile.

[0] https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01095.html

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
---
 doc/user/conf.py | 293 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 293 insertions(+)
 create mode 100644 doc/user/conf.py

(limited to 'doc/user/conf.py')

diff --git a/doc/user/conf.py b/doc/user/conf.py
new file mode 100644
index 0000000000..ebb8b828a1
--- /dev/null
+++ b/doc/user/conf.py
@@ -0,0 +1,293 @@
+# -*- coding: utf-8 -*-
+#
+# FRR documentation build configuration file, created by
+# sphinx-quickstart on Tue Jan 31 16:00:52 2017.
+#
+# This file is execfile()d with the current directory set to its
+# containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys
+import os
+import re
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#sys.path.insert(0, os.path.abspath('.'))
+
+# -- General configuration ------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = ['sphinx.ext.todo']
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+# source_suffix = ['.rst', '.md']
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8-sig'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'FRR'
+copyright = u'2017, FRR'
+author = u'FRR'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+
+# The short X.Y version.
+version = u'?.?'
+# The full version, including alpha/beta/rc tags.
+release = u'?.?-?'
+
+val = re.compile('^S\["([^"]+)"\]="(.*)"$')
+with open('../../config.status', 'r') as cfgstatus:
+    for ln in cfgstatus.readlines():
+        m = val.match(ln)
+        if m is None: continue
+        if m.group(1) == 'PACKAGE_VERSION':
+            release = m.group(2)
+            version = release.split('-')[0]
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = None
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+#today_fmt = '%B %d, %Y'
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+exclude_patterns = ['_build']
+
+# The reST default role (used for this markup: `text`) to use for all
+# documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+# If true, keep warnings as "system message" paragraphs in the built documents.
+#keep_warnings = False
+
+# If true, `todo` and `todoList` produce output, else they produce nothing.
+todo_include_todos = True
+
+
+# -- Options for HTML output ----------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+html_theme = 'sphinx_rtd_theme'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further.  For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = []
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar.  Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# Add any extra paths that contain custom files (such as robots.txt or
+# .htaccess) here, relative to this directory. These files are copied
+# directly to the root of the documentation.
+#html_extra_path = []
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_domain_indices = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+#html_show_sphinx = True
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+#html_show_copyright = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.  The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# This is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = None
+
+# Language to be used for generating the HTML full-text search index.
+# Sphinx supports the following languages:
+#   'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja'
+#   'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr'
+#html_search_language = 'en'
+
+# A dictionary with options for the search language support, empty by default.
+# Now only 'ja' uses this config value
+#html_search_options = {'type': 'default'}
+
+# The name of a javascript file (relative to the configuration directory) that
+# implements a search results scorer. If empty, the default will be used.
+#html_search_scorer = 'scorer.js'
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'FRRdoc'
+
+# -- Options for LaTeX output ---------------------------------------------
+
+latex_elements = {
+# The paper size ('letterpaper' or 'a4paper').
+#'papersize': 'letterpaper',
+
+# The font size ('10pt', '11pt' or '12pt').
+#'pointsize': '10pt',
+
+# Additional stuff for the LaTeX preamble.
+#'preamble': '',
+
+# Latex figure (float) alignment
+#'figure_align': 'htbp',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+#  author, documentclass [howto, manual, or own class]).
+latex_documents = [
+    (master_doc, 'FRR.tex', u'FRR User Manual',
+     u'FRR', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+#latex_logo = None
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# If true, show page references after internal links.
+#latex_show_pagerefs = False
+
+# If true, show URL addresses after external links.
+#latex_show_urls = False
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_domain_indices = True
+
+
+# -- Options for manual page output ---------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+    (master_doc, 'frr', u'FRR User Manual',
+     [author], 1)
+]
+
+# If true, show URL addresses after external links.
+#man_show_urls = False
+
+
+# -- Options for Texinfo output -------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+#  dir menu entry, description, category)
+texinfo_documents = [
+    (master_doc, 'FRR', u'FRR User Manual',
+     author, 'FRR', 'One line description of project.',
+     'Miscellaneous'),
+]
+
+# Documents to append as an appendix to all manuals.
+#texinfo_appendices = []
+
+# If false, no module index is generated.
+#texinfo_domain_indices = True
+
+# How to display URL addresses: 'footnote', 'no', or 'inline'.
+#texinfo_show_urls = 'footnote'
+
+# If true, do not generate a @detailmenu in the "Top" node's menu.
+#texinfo_no_detailmenu = False
-- 
cgit v1.2.3


From 964b36623b38b9813cde1a8bf79ab9ced95305c1 Mon Sep 17 00:00:00 2001
From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Fri, 12 Jan 2018 16:00:24 -0500
Subject: doc: make conf.py know about variable substitutions

The old Texi docs had some Makefile-style variable substitutions they
used to pull in information like release date, configured install path,
etc. Sphinx has this ability as well, we start making use of it here.

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
---
 doc/user/conf.py | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

(limited to 'doc/user/conf.py')

diff --git a/doc/user/conf.py b/doc/user/conf.py
index ebb8b828a1..d62e46301c 100644
--- a/doc/user/conf.py
+++ b/doc/user/conf.py
@@ -24,7 +24,10 @@ import re
 # -- General configuration ------------------------------------------------
 
 # If your documentation needs a minimal Sphinx version, state it here.
-#needs_sphinx = '1.0'
+needs_sphinx = '1.0'
+
+# prolog for various variable substitutions
+rst_prolog = ''
 
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
@@ -36,7 +39,7 @@ templates_path = ['_templates']
 
 # The suffix(es) of source filenames.
 # You can specify multiple suffix as a list of string:
-# source_suffix = ['.rst', '.md']
+# source_suffix = ['.rst']
 source_suffix = '.rst'
 
 # The encoding of source files.
@@ -59,6 +62,10 @@ version = u'?.?'
 # The full version, including alpha/beta/rc tags.
 release = u'?.?-?'
 
+install_prefix_etc = "<install_prefix>"
+
+# extract version information, installation location, other stuff we need to
+# use when building final documents
 val = re.compile('^S\["([^"]+)"\]="(.*)"$')
 with open('../../config.status', 'r') as cfgstatus:
     for ln in cfgstatus.readlines():
@@ -67,6 +74,17 @@ with open('../../config.status', 'r') as cfgstatus:
         if m.group(1) == 'PACKAGE_VERSION':
             release = m.group(2)
             version = release.split('-')[0]
+        if m.group(1) == 'CFG_SYSCONF':
+            install_prefix_etc = m.group(2)
+
+
+# add substitutions to prolog
+rst_prolog += '''
+.. |INSTALL_PREFIX_ETC| replace:: {}
+.. |PACKAGE_VERSION| replace:: {}
+'''.format(install_prefix_etc, version)
+
+
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
-- 
cgit v1.2.3


From be46d2884737e18c6d0996a17c622b5bff336dee Mon Sep 17 00:00:00 2001
From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Fri, 19 Jan 2018 14:11:06 -0500
Subject: doc: use RST variable substitutions

In conf.py, extract & construct values for inline variables throughout
the docs. In the docs, use these inline variables in RST syntax.

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
---
 doc/user/basic.rst        | 16 ++++----
 doc/user/conf.py          | 42 +++++++++++++++------
 doc/user/defines.rst      |  2 +-
 doc/user/eigrpd.rst       |  2 +-
 doc/user/installation.rst |  2 +-
 doc/user/nhrpd.rst        |  2 +-
 doc/user/overview.rst     | 94 +++++++++++++++++++++++------------------------
 doc/user/ripd.rst         |  2 +-
 doc/user/vtysh.rst        | 16 ++++----
 9 files changed, 97 insertions(+), 81 deletions(-)

(limited to 'doc/user/conf.py')

diff --git a/doc/user/basic.rst b/doc/user/basic.rst
index c46665c501..933d49b01a 100644
--- a/doc/user/basic.rst
+++ b/doc/user/basic.rst
@@ -39,12 +39,12 @@ starting.
 
 Config files are generally found in:
 
-* :file:`@value{INSTALL_PREFIX_ETC}`/\*.conf
+* :file:`|INSTALL_PREFIX_ETC|`/\*.conf
 
 Each of the daemons has its own
 config file. For example, zebra's default config file name is:
 
-* :file:`@value{INSTALL_PREFIX_ETC`/zebra.conf}
+* :file:`INSTALL_PREFIX_ETC`/zebra.conf
 
 The daemon name plus :file:`.conf` is the default config file name. You
 can specify a config file using the :kbd:`-f` or :kbd:`--config-file`
@@ -312,7 +312,7 @@ Terminal Mode Commands
 .. index:: show version
 
 ``show version``
-  Show the current version of @value{PACKAGE_NAME} and its build host information.
+  Show the current version of |PACKAGE_NAME| and its build host information.
 
 .. index:: show logging
 
@@ -331,7 +331,7 @@ Terminal Mode Commands
 Common Invocation Options
 =========================
 
-These options apply to all @value{PACKAGE_NAME} daemons.
+These options apply to all |PACKAGE_NAME| daemons.
 
 
 ``-d, --daemon``
@@ -354,7 +354,7 @@ These options apply to all @value{PACKAGE_NAME} daemons.
 
   The file name is an run-time option rather than a configure-time option
   so that multiple routing daemons can be run simultaneously. This is
-  useful when using @value{PACKAGE_NAME} to implement a routing looking glass. One
+  useful when using |PACKAGE_NAME| to implement a routing looking glass. One
   machine can be used to collect differing routing views from differing
   points in the network.
 
@@ -391,7 +391,7 @@ the following command line option at daemon startup:
   Load the specified module, optionally passing options to it. If the module
   name contains a slash (/), it is assumed to be a full pathname to a file to
   be loaded. If it does not contain a slash, the
-  `@value{INSTALL_PREFIX_MODULES`} directory is searched for a module of
+  `INSTALL_PREFIX_MODULES` directory is searched for a module of
   the given name; first with the daemon name prepended (e.g. ``zebra_mod``
   for ``mod``), then without the daemon name prepended.
 
@@ -447,8 +447,8 @@ is no VTY password, one cannot connect to the VTY interface at all.
   Connected to localhost.
   Escape character is '^]'.
 
-  Hello, this is @value{PACKAGE_NAME} (version @value{PACKAGE_VERSION})
-  @value{COPYRIGHT_STR}
+  Hello, this is |PACKAGE_NAME| (version |PACKAGE_VERSION|)
+  |COPYRIGHT_STR|
 
   User Access Verification
 
diff --git a/doc/user/conf.py b/doc/user/conf.py
index d62e46301c..23ca7d8fe7 100644
--- a/doc/user/conf.py
+++ b/doc/user/conf.py
@@ -62,7 +62,30 @@ version = u'?.?'
 # The full version, including alpha/beta/rc tags.
 release = u'?.?-?'
 
-install_prefix_etc = "<install_prefix>"
+
+# -----------------------------------------------------------------------------
+# Extract values from codebase for substitution into docs.
+# -----------------------------------------------------------------------------
+
+# Various installation prefixes. Reasonable defaults are set where possible.
+# Values are overridden by logic below.
+replace_vars = {
+    'AUTHORS': 'Kunihiro Ishiguro, et al.',
+    'COPYRIGHT_YEAR': '1999-2005',
+    'COPYRIGHT_STR': None,
+    'PACKAGE_NAME': project.lower(),
+    'PACKAGE_TARNAME': project.lower(),
+    'PACKAGE_STRING': None,
+    'PACKAGE_URL': 'https://frrouting.org/',
+    'PACKAGE_VERSION': None,
+    'INSTALL_PREFIX_ETC': None,
+    'INSTALL_PREFIX_SBIN': None,
+    'INSTALL_PREFIX_STATE': None,
+    'INSTALL_PREFIX_MODULES': None,
+    'INSTALL_USER': None,
+    'INSTALL_GROUP': None,
+    'INSTALL_VTY_GROUP': None,
+}
 
 # extract version information, installation location, other stuff we need to
 # use when building final documents
@@ -70,20 +93,15 @@ val = re.compile('^S\["([^"]+)"\]="(.*)"$')
 with open('../../config.status', 'r') as cfgstatus:
     for ln in cfgstatus.readlines():
         m = val.match(ln)
-        if m is None: continue
-        if m.group(1) == 'PACKAGE_VERSION':
-            release = m.group(2)
-            version = release.split('-')[0]
-        if m.group(1) == 'CFG_SYSCONF':
-            install_prefix_etc = m.group(2)
+        if not m or m.group(1) not in replace_vars.keys(): continue
+        replace_vars[m.group(1)] = m.group(2)
 
+# manually fill out some of these we can't get from config.status
+replace_vars['COPYRIGHT_STR'] = "Copyright (c) {} {}".format(replace_vars['COPYRIGHT_YEAR'], replace_vars['AUTHORS'])
 
 # add substitutions to prolog
-rst_prolog += '''
-.. |INSTALL_PREFIX_ETC| replace:: {}
-.. |PACKAGE_VERSION| replace:: {}
-'''.format(install_prefix_etc, version)
-
+for key, value in replace_vars.items():
+    rst_prolog += '.. |{0}| replace:: {1}\n'.format(key, value)
 
 
 # The language for content autogenerated by Sphinx. Refer to documentation
diff --git a/doc/user/defines.rst b/doc/user/defines.rst
index 014d66d0e8..e8c779d3a0 100644
--- a/doc/user/defines.rst
+++ b/doc/user/defines.rst
@@ -12,7 +12,7 @@
    @set PACKAGE_VERSION 3.1-dev
    @set AUTHORS Kunihiro Ishiguro, et al.
    @set COPYRIGHT_YEAR 1999-2005
-   @set COPYRIGHT_STR Copyright @copyright{} @value{COPYRIGHT_YEAR} @value{AUTHORS}
+   @set COPYRIGHT_STR Copyright @copyright{} |COPYRIGHT_YEAR| |AUTHORS|
    
    @c These may vary with installation environment.
    @set INSTALL_PREFIX_ETC /etc/frr
diff --git a/doc/user/eigrpd.rst b/doc/user/eigrpd.rst
index effec5dc1e..7686ef099d 100644
--- a/doc/user/eigrpd.rst
+++ b/doc/user/eigrpd.rst
@@ -20,7 +20,7 @@ Starting and Stopping eigrpd
 
 The default configuration file name of *eigrpd*'s is
 :file:`eigrpd.conf`.  When invocation *eigrpd* searches directory
-@value{INSTALL_PREFIX_ETC}.  If :file:`eigrpd.conf` is not there next
+|INSTALL_PREFIX_ETC|.  If :file:`eigrpd.conf` is not there next
 search current directory.  If an integrated config is specified
 configuration is written into frr.conf
 
diff --git a/doc/user/installation.rst b/doc/user/installation.rst
index 8ede815f7e..4695a08373 100644
--- a/doc/user/installation.rst
+++ b/doc/user/installation.rst
@@ -325,5 +325,5 @@ 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
-:file:`@value{INSTALL_PREFIX_ETC`/\*.conf}. :ref:`Config_Commands`.
+:file:`|INSTALL_PREFIX_ETC`/\*.conf|. :ref:`Config_Commands`.
 
diff --git a/doc/user/nhrpd.rst b/doc/user/nhrpd.rst
index 24037f85b6..a16730a3cc 100644
--- a/doc/user/nhrpd.rst
+++ b/doc/user/nhrpd.rst
@@ -15,7 +15,7 @@ these systems to directly communicate without requiring traffic to use
 an intermediate hop.
 
 Cisco Dynamic Multipoint VPN (DMVPN) is based on NHRP, and
-@value{PACKAGE_NAME} nhrpd implements this scenario.
+|PACKAGE_NAME| nhrpd implements this scenario.
 
 .. _Routing_Design:
 
diff --git a/doc/user/overview.rst b/doc/user/overview.rst
index 6393d0ba07..204393e2df 100644
--- a/doc/user/overview.rst
+++ b/doc/user/overview.rst
@@ -6,64 +6,63 @@ Overview
 
 .. index:: Overview
 
-`@value{PACKAGE_URL <@value{PACKAGE_URL>`_,,Frr} is a routing software package that
-provides TCP/IP based routing services with routing protocols support such
-as RIPv1, RIPv2, RIPng, OSPFv2, OSPFv3, IS-IS, BGP-4, and BGP-4+ (:ref:`Supported_RFCs`). Frr also supports special BGP Route Reflector and Route Server
-behavior.  In addition to traditional IPv4 routing protocols, Frr also
-supports IPv6 routing protocols.  With SNMP daemon which supports SMUX and AgentX
-protocol, Frr provides routing protocol MIBs (:ref:`SNMP_Support`).
-
-Frr uses an advanced software architecture to provide you with a high
-quality, multi server routing engine. Frr has an interactive user
+`FRR <|PACKAGE_URL|>`_ is a routing software package that provides TCP/IP based
+routing services with routing protocols support such as RIPv1, RIPv2, RIPng,
+OSPFv2, OSPFv3, IS-IS, BGP-4, and BGP-4+ (:ref:`Supported_RFCs`). FRR also
+supports special BGP Route Reflector and Route Server behavior.  In addition to
+traditional IPv4 routing protocols, FRR also supports IPv6 routing protocols.
+With SNMP daemon which supports SMUX and AgentX protocol, FRR provides routing
+protocol MIBs (:ref:`SNMP_Support`).
+
+FRR uses an advanced software architecture to provide you with a high
+quality, multi server routing engine. FRR has an interactive user
 interface for each routing protocol and supports common client commands. 
-Due to this design, you can add new protocol daemons to Frr easily.  You
-can use Frr library as your program's client user interface.
+Due to this design, you can add new protocol daemons to FRR easily.  You
+can use FRR library as your program's client user interface.
 
-Frr is distributed under the @sc{gnu} General Public License.
+FRR is distributed under the GNU General Public License.
 
-@comment  node-name,  next,  previous,  up
-
-About Frr
+About FRR
 =========
 
-.. index:: About Frr
+.. index:: About FRR
 
 Today, TCP/IP networks are covering all of the world.  The Internet has
 been deployed in many countries, companies, and to the home.  When you
 connect to the Internet your packet will pass many routers which have TCP/IP
 routing functionality.
 
-A system with Frr installed acts as a dedicated router.  With Frr,
+A system with FRR installed acts as a dedicated router.  With FRR,
 your machine exchanges routing information with other routers using routing
-protocols.  Frr uses this information to update the kernel routing table
+protocols.  FRR uses this information to update the kernel routing table
 so that the right data goes to the right place.  You can dynamically change
-the configuration and you may view routing table information from the Frr
+the configuration and you may view routing table information from the FRR
 terminal interface.
 
-Adding to routing protocol support, Frr can setup interface's flags,
+Adding to routing protocol support, FRR can setup interface's flags,
 interface's address, static routes and so on.  If you have a small network,
-or a stub network, or xDSL connection, configuring the Frr routing
+or a stub network, or xDSL connection, configuring the FRR routing
 software is very easy.  The only thing you have to do is to set up the
 interfaces and put a few commands about static routes and/or default routes. 
 If the network is rather large, or if the network structure changes
-frequently, you will want to take advantage of Frr's dynamic routing
+frequently, you will want to take advantage of FRR's dynamic routing
 protocol support for protocols such as RIP, OSPF, IS-IS or BGP.
 
 Traditionally, UNIX based router configuration is done by
 *ifconfig* and *route* commands.  Status of routing
 table is displayed by *netstat* utility.  Almost of these commands
-work only if the user has root privileges.  Frr has a different system
-administration method.  There are two user modes in Frr.  One is normal
+work only if the user has root privileges.  FRR has a different system
+administration method.  There are two user modes in FRR.  One is normal
 mode, the other is enable mode.  Normal mode user can only view system
 status, enable mode user can change system configuration.  This UNIX account
 independent feature will be great help to the router administrator.
 
-Currently, Frr supports common unicast routing protocols, that is BGP,
+Currently, FRR supports common unicast routing protocols, that is BGP,
 OSPF, RIP and IS-IS.  Upcoming for MPLS support, an implementation of LDP is
 currently being prepared for merging.  Implementations of BFD and PIM-SSM
 (IPv4) also exist, but are not actively being worked on.
 
-The ultimate goal of the Frr project is making a productive, quality, free
+The ultimate goal of the FRR project is making a productive, quality, free
 TCP/IP routing software package.
 
 @comment  node-name,  next,  previous,  up
@@ -78,7 +77,7 @@ System Architecture
 .. index:: Software internals
 
 Traditional routing software is made as a one process program which
-provides all of the routing protocol functionalities.  Frr takes a
+provides all of the routing protocol functionalities.  FRR takes a
 different approach.  It is made from a collection of several daemons that
 work together to build the routing table.  There may be several
 protocol-specific routing daemons and zebra the kernel routing manager.
@@ -110,7 +109,7 @@ architecture creates new possibilities for the routing system.
   |                              |
   +------------------------------+
 
-      Frr System Architecture
+      FRR System Architecture
   @end group
   
 
@@ -120,11 +119,11 @@ and terminal interfaces.  Each daemon has it's own configuration file and
 terminal interface.  When you configure a static route, it must be done in
 *zebra* configuration file.  When you configure BGP network it must
 be done in *bgpd* configuration file.  This can be a very annoying
-thing.  To resolve the problem, Frr provides integrated user interface
+thing.  To resolve the problem, FRR provides integrated user interface
 shell called *vtysh*.  *vtysh* connects to each daemon with
 UNIX domain socket and then works as a proxy for user input.
 
-Frr was planned to use multi-threaded mechanism when it runs with a
+FRR was planned to use multi-threaded mechanism when it runs with a
 kernel that supports multi-threads.  But at the moment, the thread library
 which comes with @sc{gnu}/Linux or FreeBSD has some problems with running
 reliable services such as routing software, so we don't use threads at all. 
@@ -138,20 +137,20 @@ Supported Platforms
 
 .. index:: Supported platforms
 
-.. index:: Frr on other systems
+.. index:: FRR on other systems
 
 .. index:: Compatibility with other systems
 
-.. index:: Operating systems that support Frr
+.. index:: Operating systems that support FRR
 
-Currently Frr supports @sc{gnu}/Linux and BSD. Porting Frr
+Currently FRR supports @sc{gnu}/Linux and BSD. Porting FRR
 to other platforms is not too difficult as platform dependent code should
 most be limited to the *zebra* daemon.  Protocol daemons are mostly
-platform independent. Please let us know when you find out Frr runs on a
+platform independent. Please let us know when you find out FRR runs on a
 platform which is not listed below.
 
 The list of officially supported platforms are listed below. Note that
-Frr may run correctly on other platforms, and may run with partial
+FRR may run correctly on other platforms, and may run with partial
 functionality on further platforms.
 
 @sp 1
@@ -178,7 +177,7 @@ may work with some effort:
   Mac OSX
 
 Also note that, in particular regarding proprietary platforms, compiler
-and C library choice will affect Frr.  Only recent versions of the
+and C library choice will affect FRR.  Only recent versions of the
 following C compilers are well-tested:
 
 @sp 1
@@ -291,18 +290,17 @@ When SNMP support is enabled, below RFC is also supported.
 
 @comment  node-name,  next,  previous,  up
 
-How to get Frr
+How to get FRR
 ==============
 
-The official Frr web-site is located at:
+The official FRR web-site is located at:
 
-`@value{PACKAGE_URL <@value{PACKAGE_URL>`_}
+`|PACKAGE_URL| <|PACKAGE_URL|>`_
 
 and contains further information, as well as links to additional
 resources. 
 
-`@value{PACKAGE_URL <@value{PACKAGE_URL>`_,Frr} is a fork of Quagga, whose
-web-site is located at:
+FRR is a fork of Quagga, whose website is located at:
 
 `http://www.quagga.net/ <http://www.quagga.net/>`_.
 
@@ -311,20 +309,20 @@ web-site is located at:
 Mailing List
 ============
 
-.. index:: How to get in touch with Frr
+.. index:: How to get in touch with FRR
 
-.. index:: Mailing Frr
+.. index:: Mailing FRR
 
 .. index:: Contact information
 
 .. index:: Mailing lists
 
-There is a mailing list for discussions about Frr.  If you have any
-comments or suggestions to Frr, please subscribe to:
+There is a mailing list for discussions about FRR.  If you have any
+comments or suggestions to FRR, please subscribe to:
 
 `https://lists.frrouting.org/listinfo/frog <https://lists.frrouting.org/listinfo/frog>`_.
 
-The `@value{PACKAGE_URL <@value{PACKAGE_URL>`_,,Frr} site has further information on
+The `FRR <|PACKAGE_URL|>`_ site has further information on
 the available mailing lists, see:
 
 `https://lists.frrouting.org/ <https://lists.frrouting.org/>`_
@@ -361,7 +359,7 @@ When you send a bug report, please be careful about the points below.
   Please send your configuration file with the report.  If you specify
   arguments to the configure script please note that too.
 
-Bug reports are very important for us to improve the quality of Frr.
-Frr is still in the development stage, but please don't hesitate to
+Bug reports are very important for us to improve the quality of FRR.
+FRR is still in the development stage, but please don't hesitate to
 send a bug report to `http://github.com/frrouting/frr/issues <http://github.com/frrouting/frr/issues>`_.
 
diff --git a/doc/user/ripd.rst b/doc/user/ripd.rst
index 0aae9bcc39..dc9d7c06d2 100644
--- a/doc/user/ripd.rst
+++ b/doc/user/ripd.rst
@@ -23,7 +23,7 @@ Starting and Stopping ripd
 
 The default configuration file name of *ripd*'s is
 :file:`ripd.conf`.  When invocation *ripd* searches directory
-@value{INSTALL_PREFIX_ETC}.  If :file:`ripd.conf` is not there next
+|INSTALL_PREFIX_ETC|.  If :file:`ripd.conf` is not there next
 search current directory.
 
 RIP uses UDP port 520 to send and receive RIP packets.  So the user must have
diff --git a/doc/user/vtysh.rst b/doc/user/vtysh.rst
index d6ed3631a2..a609c2fd7c 100644
--- a/doc/user/vtysh.rst
+++ b/doc/user/vtysh.rst
@@ -10,7 +10,7 @@ be disabled through the *--disable-vtysh* option to
 *./configure*.
 
 *vtysh* has a configuration file, :file:`vtysh.conf`.  The location
-of that file cannot be changed from :file:`@value{INSTALL_PREFIX_ETC`} since
+of that file cannot be changed from :file:`|INSTALL_PREFIX_ETC|` since
 it contains options controlling authentication behavior.  This file will
 also not be written by configuration-save commands, it is intended to be
 updated manually by an administrator with an external editor.
@@ -25,28 +25,28 @@ Permissions and setup requirements
 ==================================
 
 *vtysh* connects to running daemons through Unix sockets located in
-:file:`@value{INSTALL_PREFIX_STATE`}.  Running vtysh thus requires access to
-that directory, plus membership in the *@value{INSTALL_VTY_GROUP*}
+:file:`|INSTALL_PREFIX_STATE|`.  Running vtysh thus requires access to
+that directory, plus membership in the *|INSTALL_VTY_GROUP|*
 group (which is the group that the daemons will change ownership of their
 sockets to).
 
 To restrict access to Frr configuration, make sure no unauthorized users
-are members of the *@value{INSTALL_VTY_GROUP*} group.
+are members of the *|INSTALL_VTY_GROUP|* group.
 
 PAM support (experimental)
 --------------------------
 
 vtysh has working (but rather useless) PAM support.  It will perform
-an "authenticate" PAM call using *@value{PACKAGE_NAME*} as service
+an "authenticate" PAM call using *|PACKAGE_NAME|* as service
 name. No other (accounting, session, password change) calls will be
 performed by vtysh.
 
 Users using vtysh still need to have appropriate access to the daemons'
-VTY sockets, usually by being member of the *@value{INSTALL_VTY_GROUP*}
+VTY sockets, usually by being member of the *|INSTALL_VTY_GROUP|*
 group.  If they have this membership, PAM support is useless since they can
 connect to daemons and issue commands using some other tool.  Alternatively,
 the *vtysh* binary could be made SGID (set group ID) to the
-*@value{INSTALL_VTY_GROUP*} group.  @strong{No security guarantees are
+*|INSTALL_VTY_GROUP|* group.  @strong{No security guarantees are
 made for this configuration}.
 
 .. index:: {Command} {username `username` nopassword} {}
@@ -67,7 +67,7 @@ Integrated configuration mode uses a single configuration file,
 :file:`frr.conf`, for all daemons.  This replaces the individual files like
 :file:`zebra.conf` or :file:`bgpd.conf`.
 
-:file:`frr.conf` is located in :file:`@value{INSTALL_PREFIX_ETC`}.  All
+:file:`frr.conf` is located in :file:`|INSTALL_PREFIX_ETC|`.  All
 daemons check for the existence of this file at startup, and if it exists
 will not load their individual configuration files.  Instead,
 *vtysh -b* must be invoked to process :file:`frr.conf` and apply
-- 
cgit v1.2.3


From fd8100976ef122293af75ffdefd9d84beda48416 Mon Sep 17 00:00:00 2001
From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Fri, 19 Jan 2018 17:24:48 -0500
Subject: doc: set 'release' and 'version' again

accidentally removed in older commit

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
---
 doc/user/conf.py | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

(limited to 'doc/user/conf.py')

diff --git a/doc/user/conf.py b/doc/user/conf.py
index 23ca7d8fe7..86d8353e2a 100644
--- a/doc/user/conf.py
+++ b/doc/user/conf.py
@@ -97,7 +97,11 @@ with open('../../config.status', 'r') as cfgstatus:
         replace_vars[m.group(1)] = m.group(2)
 
 # manually fill out some of these we can't get from config.status
-replace_vars['COPYRIGHT_STR'] = "Copyright (c) {} {}".format(replace_vars['COPYRIGHT_YEAR'], replace_vars['AUTHORS'])
+replace_vars['COPYRIGHT_STR'] = "Copyright (c)"
+replace_vars['COPYRIGHT_STR'] += ' {}'.format(replace_vars['COPYRIGHT_YEAR'])
+replace_vars['COPYRIGHT_STR'] += ' {}'.format(replace_vars['AUTHORS'])
+release = replace_vars['PACKAGE_VERSION']
+version = release.split('-')[0]
 
 # add substitutions to prolog
 for key, value in replace_vars.items():
-- 
cgit v1.2.3


From 2731b07dba127668f8e0b0e405b61e388ba202fe Mon Sep 17 00:00:00 2001
From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Fri, 26 Jan 2018 15:51:59 -0500
Subject: doc: add clicmd role for frr cli

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
---
 doc/user/conf.py | 6 ++++++
 1 file changed, 6 insertions(+)

(limited to 'doc/user/conf.py')

diff --git a/doc/user/conf.py b/doc/user/conf.py
index 86d8353e2a..1eac6af763 100644
--- a/doc/user/conf.py
+++ b/doc/user/conf.py
@@ -331,3 +331,9 @@ texinfo_documents = [
 
 # If true, do not generate a @detailmenu in the "Top" node's menu.
 #texinfo_no_detailmenu = False
+
+# custom extensions here
+def setup(app):
+    # object type for FRR CLI commands, can be extended to document parent CLI
+    # node later on
+    app.add_object_type('clicmd', 'clicmd')
-- 
cgit v1.2.3


From 013f9762db7b5f9a4570971f917f4a0857188f42 Mon Sep 17 00:00:00 2001
From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Thu, 1 Feb 2018 16:10:11 -0500
Subject: doc: fixup some build warnings

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
---
 doc/user/bgp.rst               | 15 +++++----
 doc/user/conf.py               |  2 +-
 doc/user/eigrpd.rst            | 11 +------
 doc/user/index.rst             | 22 +++++++------
 doc/user/installation.rst      |  4 +++
 doc/user/isisd.rst             |  6 ++--
 doc/user/ospf_fundamentals.rst | 10 +++---
 doc/user/overview.rst          | 18 +++++------
 doc/user/routemap.rst          | 73 ++++++++++++++++++++----------------------
 doc/user/zebra.rst             | 34 +++++++++++---------
 10 files changed, 97 insertions(+), 98 deletions(-)

(limited to 'doc/user/conf.py')

diff --git a/doc/user/bgp.rst b/doc/user/bgp.rst
index a4c141fd32..d02973f28d 100644
--- a/doc/user/bgp.rst
+++ b/doc/user/bgp.rst
@@ -279,7 +279,7 @@ and sometimes not, depending on the properties of those other routes, means MED
 can cause the order of preference over all the routes to be undefined. That is,
 given routes A, B, and C, if A is preferred to B, and B is preferred to C, then
 a well-defined order should mean the preference is transitive (in the sense of
-orders [#med-transitivity-rant])_ and that A would be preferred to C.
+orders [#med-transitivity-rant]_) and that A would be preferred to C.
 
 However, when MED is involved this need not be the case. With MED it is
 possible that C is actually preferred over A. So A is preferred to B, B is
@@ -409,7 +409,7 @@ induce; in general on arbitrary networks.
 
 There may be iBGP topology specific ways to reduce the instability risks, even
 while using MED, e.g.: by constraining the reflection topology and by tuning
-IGP costs between route-reflector clusters, see RFC3345 for details.  In the
+IGP costs between route-reflector clusters, see :rfc:`3345` for details.  In the
 near future, the Add-Path extension to BGP may also solve MED oscillation while
 still allowing MED to be used as intended, by distributing "best-paths per
 neighbour AS". This would be at the cost of distributing at least as many
@@ -420,12 +420,12 @@ Add-Path reflector.
 More generally, the instability problems that MED can introduce on more
 complex, non-full-mesh, iBGP topologies may be avoided either by:
 
-- Setting :ref:`bgp_always-compare-med`, however this allows MED to be compared
+- Setting :clicmd:`bgp always-compare-med`, however this allows MED to be compared
   across values set by different neighbour ASes, which may not produce
   coherent desirable results, of itself.
 - Effectively ignoring MED by setting MED to the same value (e.g.: 0) using
-  :ref:`routemap_set_metric` on all received routes, in combination with
-  setting :ref:`bgp_always-compare-med` on all speakers. This is the simplest
+  :clicmd:`set metric METRIC` on all received routes, in combination with
+  setting :clicmd:`bgp always-compare-med` on all speakers. This is the simplest
   and most performant way to avoid MED oscillation issues, where an AS is happy
   not to allow neighbours to inject this problematic metric.
 
@@ -443,6 +443,7 @@ paper above for an example. Hence the guideline that the iBGP topology should
 follow the IGP topology.
 
 .. _bgp_deterministic-med:
+
 .. index:: bgp deterministic-med
 .. clicmd:: bgp deterministic-med
 
@@ -463,11 +464,11 @@ Note that there are other sources of indeterminism in the route selection
 process, specifically, the preference for older and already selected routes
 from eBGP peers, :ref:`BGP_decision_process`.
 
+.. _bgp_always-compare-med:
+
 .. index:: bgp always-compare-med
 .. clicmd:: bgp always-compare-med
 
-.. _bgp_always-compare-med:
-
    Always compare the MED on routes, even when they were received from
    different neighbouring ASes. Setting this option makes the order of
    preference of routes more defined, and should eliminate MED induced
diff --git a/doc/user/conf.py b/doc/user/conf.py
index 1eac6af763..b0bcb2ed43 100644
--- a/doc/user/conf.py
+++ b/doc/user/conf.py
@@ -123,7 +123,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', 'rpki.rst', 'ospf_fundamentals.rst']
 
 # The reST default role (used for this markup: `text`) to use for all
 # documents.
diff --git a/doc/user/eigrpd.rst b/doc/user/eigrpd.rst
index 7c2c55d166..7c8109fa97 100644
--- a/doc/user/eigrpd.rst
+++ b/doc/user/eigrpd.rst
@@ -188,19 +188,10 @@ How to Announce EIGRP route
 Show EIGRP Information
 ======================
 
-To display EIGRP routes.
-
-.. index:: show ip eigrp topology
-.. clicmd:: show ip eigrp topology
-
-   Show EIGRP routes.
-
-The command displays all EIGRP routes.
-
 .. index:: show ip eigrp topology
 .. clicmd:: show ip eigrp topology
 
-   The command displays current EIGRP status
+   Display current EIGRP status.
 
    ::
 
diff --git a/doc/user/index.rst b/doc/user/index.rst
index 0929fb51ad..036c87c86e 100644
--- a/doc/user/index.rst
+++ b/doc/user/index.rst
@@ -7,22 +7,24 @@ Welcome to FRR's documentation!
    overview
    installation
    basic
-   zebra
-   ripd
-   ripngd
-   ospfd
-   ospf6d
-   isisd
-   nhrpd
-   bgp
-   babeld
-   vnc
    vtysh
    filter
    routemap
    ipv6
    kernel
    snmp
+   zebra
    protocol
+   bgp
+   babeld
+   eigrpd
+   isisd
+   nhrpd
+   ospfd
+   ospf6d
    pim
+   ripd
+   ripngd
+   vnc
+   appendix
 
diff --git a/doc/user/installation.rst b/doc/user/installation.rst
index 356d243e47..471448d004 100644
--- a/doc/user/installation.rst
+++ b/doc/user/installation.rst
@@ -166,6 +166,10 @@ customize the build to include or exclude specific features and dependencies.
 
    Build without VTYSH.
 
+.. option:: --enable-fpm
+
+   Build with FPM module support.
+
 You may specify any combination of the above options to the configure
 script. By default, the executables are placed in :file:`/usr/local/sbin`
 and the configuration files in :file:`/usr/local/etc`. The :file:`/usr/local/`
diff --git a/doc/user/isisd.rst b/doc/user/isisd.rst
index 1dffc2cf8f..50592cc21b 100644
--- a/doc/user/isisd.rst
+++ b/doc/user/isisd.rst
@@ -410,8 +410,6 @@ Showing ISIS information
    Show the ISIS routing table, as determined by the most recent SPF
    calculation.
 
-.. _ospf-traffic-engineering:
-
 Traffic Engineering
 ===================
 
@@ -444,6 +442,10 @@ Traffic Engineering
 
    Show Traffic Engineering router parameters.
 
+.. seealso::
+
+   :ref:`ospf-traffic-engineering`
+
 .. _Debugging_ISIS:
 
 Debugging ISIS
diff --git a/doc/user/ospf_fundamentals.rst b/doc/user/ospf_fundamentals.rst
index ac9a343ad5..d01fd74984 100644
--- a/doc/user/ospf_fundamentals.rst
+++ b/doc/user/ospf_fundamentals.rst
@@ -73,8 +73,8 @@ The Hello Protocol
 The OSPF Hello protocol allows OSPF to quickly detect changes in two-way
 reachability between routers on a link. OSPF can additionally avail of other
 sources of reachability information, such as link-state information provided by
-hardware, or through dedicated reachability protocols such as :abbr:`BFD
-(Bidirectional Forwarding Detection)`.
+hardware, or through dedicated reachability protocols such as
+:abbr:`BFD (Bidirectional Forwarding Detection)`.
 
 OSPF also uses the Hello protocol to propagate certain state between routers
 sharing a link, for example:
@@ -118,7 +118,7 @@ LSA Flooding
 """"""""""""
 
 OSPF defines several related mechanisms, used to manage synchronisation of
-:abbr:`LSDB`s between neighbours as neighbours form adjacencies and the
+:abbr:`LSDB` s between neighbours as neighbours form adjacencies and the
 propogation, or :term:`flooding` of new or updated :abbr:`LSA` s.
 
 :ref:`OSPF_Flooding`.
@@ -191,7 +191,7 @@ All LSAs share a common header with the following information:
 - Age
 
   A number to allow stale :abbr:`LSA` s to, eventually, be purged by routers
-  from their :abbr:`LSDB`s.
+  from their :abbr:`LSDB` s.
 
   The value nominally is one of seconds. An age of 3600, i.e. 1 hour, is
   called the :term:`MaxAge`. MaxAge LSAs are ignored in routing
@@ -540,6 +540,6 @@ like:::
 Summary LSAs
 ^^^^^^^^^^^^
 
-Summary LSAs are created by :abbr:`ABR`s to summarise the destinations
+Summary LSAs are created by :abbr:`ABR` s to summarise the destinations
 available within one area to other areas. These LSAs may describe IP networks,
 potentially in aggregated form, or :abbr:`ASBR` routers.
diff --git a/doc/user/overview.rst b/doc/user/overview.rst
index 2b5e2f9b2b..c3549417d7 100644
--- a/doc/user/overview.rst
+++ b/doc/user/overview.rst
@@ -262,13 +262,12 @@ Italicized lists are private.
 +--------------------------------+------------------------------+
 
 The Development list is used to discuss and document general issues related to
-project development and governance. The public `Slack instance
-<https://frrouting.slack.com>`_, and weekly technical meetings provide a higher
-bandwidth channel for discussions. The results of such discussions are
-reflected in updates, as appropriate, to code (i.e., merges), `GitHub
-<https://github.com/FRRouting/frr/issues>`_ tracked issues, and for governance
-or process changes, updates to the Development list and either this file or
-information posted at https://frrouting.org/.
+project development and governance. The public `Slack`_ instance and weekly
+technical meetings provide a higher bandwidth channel for discussions. The
+results of such discussions are reflected in updates, as appropriate, to code
+(i.e., merges), `GitHub issues`_ tracked issues, and for governance or process
+changes, updates to the Development list and either this file or information
+posted at `FRR`_.
 
 .. index:: Bug Reports
 .. index:: Bug hunting
@@ -298,5 +297,6 @@ When you send a bug report, please be careful about the points below.
 Bug reports help us improve FRR and are very much appreciated.
 
 .. _FRR: |PACKAGE_URL|
-.. _GitHub: http://github.com/frrouting/frr/
-.. _GitHub issues: http://github.com/frrouting/frr/
+.. _GitHub: https://github.com/frrouting/frr/
+.. _GitHub issues: https://github.com/frrouting/frr/issues
+.. _Slack: https://frrouting.slack.com/
diff --git a/doc/user/routemap.rst b/doc/user/routemap.rst
index 735838b0e6..471a286283 100644
--- a/doc/user/routemap.rst
+++ b/doc/user/routemap.rst
@@ -10,52 +10,49 @@ allowing policy to be applied to routes.
 Route maps are an ordered list of route map entries. Each entry may specify up
 to four distincts sets of clauses:
 
-- :dfn:`Matching Policy`
+.. glossary::
 
-  This specifies the policy implied if the *Matching Conditions* are
-  met or not met, and which actions of the route-map are to be taken, if
-  any. The two possibilities are:
+   Matching Conditions
+      A route-map entry may, optionally, specify one or more conditions which
+      must be matched if the entry is to be considered further, as governed by
+      the Match Policy. If a route-map entry does not explicitely specify any
+      matching conditions, then it always matches.
 
-  - :dfn:`permit`: If the entry matches, then carry out the :term:`Set
-    Actions`. Then finish processing the route-map, permitting the route,
-    unless an *Exit Action* indicates otherwise.
+   Set Actions
+      A route-map entry may, optionally, specify one or more Set Actions to set
+      or modify attributes of the route.
 
-  - :dfn:`deny`: If the entry matches, then finish processing the route-map and
-    deny the route (return ``deny``).
+   Matching Policy
+      This specifies the policy implied if the :term:`Matching Conditions` are
+      met or not met, and which actions of the route-map are to be taken, if
+      any. The two possibilities are:
 
-    The *Matching Policy* is specified as part of the command which
-    defines the ordered entry in the route-map. See below.
+      - :dfn:`permit`: If the entry matches, then carry out the
+        :term:`Set Actions`. Then finish processing the route-map, permitting
+        the route, unless an :term:`Exit Policy` action indicates otherwise.
 
-- :dfn:`Matching Conditions`
+      - :dfn:`deny`: If the entry matches, then finish processing the route-map and
+        deny the route (return `deny`).
 
-  A route-map entry may, optionally, specify one or more conditions which must
-  be matched if the entry is to be considered further, as governed by the Match
-  Policy. If a route-map entry does not explicitely specify any matching
-  conditions, then it always matches.
+      The `Matching Policy` is specified as part of the command which defines
+      the ordered entry in the route-map. See below.
 
-- :dfn:`Set Actions`
+   Call Action
+      Call to another route-map, after any :term:`Set Actions` have been carried out.
+      If the route-map called returns `deny` then processing of the route-map
+      finishes and the route is denied, regardless of the :term:Matching Policy` or
+      the :term:`Exit Policy`. If the called route-map returns `permit`, then
+      :term:`Matching Policy` and :term:`Exit Policy` govern further behaviour, as normal.
 
-  A route-map entry may, optionally, specify one or more *Set Actions* to
-  set or modify attributes of the route.
+   Exit Policy
+      An entry may, optionally, specify an alternative :dfn:`Exit Policy` to
+      take if the entry matched, rather than the normal policy of exiting the
+      route-map and permitting the route. The two possibilities are:
 
-- :dfn:`Call Action`
+      - :dfn:`next`: Continue on with processing of the route-map entries.
 
-  Call to another route-map, after any *Set Actions* have been carried out.
-  If the route-map called returns *deny* then processing of the route-map
-  finishes and the route is denied, regardless of the *Matching Policy* or
-  the *Exit Policy*. If the called route-map returns *permit*, then
-  *Matching Policy* and *Exit Policy* govern further behaviour, as normal.
-
-- :dfn:`Exit Policy`
-
-  An entry may, optionally, specify an alternative *Exit Policy* to
-  take if the entry matched, rather than the normal policy of exiting the
-  route-map and permitting the route. The two possibilities are:
-
-  - :dfn:`next`: Continue on with processing of the route-map entries.
-
-  - :dfn:`goto N`: Jump ahead to the first route-map entry whose order in
-    the route-map is >= N. Jumping to a previous entry is not permitted.
+      - :dfn:`goto N`: Jump ahead to the first route-map entry whose order in
+        the route-map is >= N. Jumping to a previous entry is not permitted.
 
 The default action of a route-map, if no entries match, is to deny.  I.e. a
 route-map essentially has as its last entry an empty *deny* entry, which
@@ -188,11 +185,11 @@ Route Map Match Command
 Route Map Set Command
 =====================
 
+.. program:: configure
+
 .. index:: set tag TAG
 .. clicmd:: set tag TAG
 
-.. program:: configure
-
    Set a tag on the matched route. This tag value can be from (1-4294967295).
    Additionally if you have compiled with the :option:`--enable-realms`
    configure option. Tag values from (1-255) are sent to the Linux kernel as a
diff --git a/doc/user/zebra.rst b/doc/user/zebra.rst
index b04b8c7365..4f1692e58c 100644
--- a/doc/user/zebra.rst
+++ b/doc/user/zebra.rst
@@ -34,6 +34,8 @@ Besides the common invocation options (:ref:`Common_Invocation_Options`), the
 
    When program terminates, retain routes added by zebra.
 
+.. program:: configure
+
 .. _Interface_Commands:
 
 Interface Commands
@@ -444,28 +446,28 @@ longer-prefix
 zebra Route Filtering
 =====================
 
-Zebra supports :dfn:`prefix-list`s and :ref:`Route_Map`s to match routes
-received from other frr components. The permit/deny facilities provided by
+Zebra supports :dfn:`prefix-list` s and :ref:`Route_Map` s to match routes
+received from other FRR components. The permit/deny facilities provided by
 these commands can be used to filter which routes zebra will install in the
 kernel.
 
 .. index:: ip protocol PROTOCOL route-map ROUTEMAP
 .. clicmd:: ip protocol PROTOCOL route-map ROUTEMAP
 
-  Apply a route-map filter to routes for the specified protocol. PROTOCOL can
-  be **any** or one of
-
-  - system,
-  - kernel,
-  - connected,
-  - static,
-  - rip,
-  - ripng,
-  - ospf,
-  - ospf6,
-  - isis,
-  - bgp,
-  - hsls.
+   Apply a route-map filter to routes for the specified protocol. PROTOCOL can
+   be **any** or one of
+
+   - system,
+   - kernel,
+   - connected,
+   - static,
+   - rip,
+   - ripng,
+   - ospf,
+   - ospf6,
+   - isis,
+   - bgp,
+   - hsls.
 
 .. index:: set src ADDRESS
 .. clicmd:: set src ADDRESS
-- 
cgit v1.2.3


From 9e146a818b52741d97ff3ae25caa1523c20e554d Mon Sep 17 00:00:00 2001
From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Thu, 1 Feb 2018 17:38:05 -0500
Subject: doc: fix more broken refs, restore routeserver.rst

At some point the routeserver docs got lost, converted those from texi
and put them back. Also fixed some broken cli xrefs.

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
---
 doc/user/bgp.rst         |  44 +---
 doc/user/conf.py         |   2 +-
 doc/user/isisd.rst       |   2 +
 doc/user/routeserver.rst | 546 +++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 560 insertions(+), 34 deletions(-)
 create mode 100644 doc/user/routeserver.rst

(limited to 'doc/user/conf.py')

diff --git a/doc/user/bgp.rst b/doc/user/bgp.rst
index e80039a714..ba4238b946 100644
--- a/doc/user/bgp.rst
+++ b/doc/user/bgp.rst
@@ -141,7 +141,7 @@ The decision process FRR BGP uses to select routes is as follows:
 
    If multi-pathing is enabled, then check whether the routes not yet
    distinguished in preference may be considered equal. If
-   :ref:`bgp-bestpath-as-path-multipath-relax` is set, all such routes are
+   :clicmd:`bgp bestpath as-path multipath-relax` is set, all such routes are
    considered equal, otherwise routes received via iBGP with identical AS_PATHs
    or routes received from eBGP neighbours in the same AS are considered equal.
 
@@ -149,8 +149,8 @@ The decision process FRR BGP uses to select routes is as follows:
 
     Where both routes were received from eBGP peers, then prefer the route
     which is already selected. Note that this check is not applied if
-    :ref:`bgp-bestpath-compare-routerid` is configured. This check can prevent
-    some cases of oscillation.
+    :clicmd:`bgp bestpath compare-routerid` is configured. This check can
+    prevent some cases of oscillation.
 
 11. Router-ID check
 
@@ -178,7 +178,6 @@ The decision process FRR BGP uses to select routes is as follows:
    sequences should should be taken into account during the BGP best path
    decision process.
 
-.. _bgp-bestpath-as-path-multipath-relax:
 .. index:: bgp bestpath as-path multipath-relax
 .. clicmd:: bgp bestpath as-path multipath-relax
 
@@ -186,7 +185,6 @@ The decision process FRR BGP uses to select routes is as follows:
    of equal AS_PATH length candidates for multipath computation. Without
    the knob, the entire AS_PATH must match for multipath computation.
 
-.. _bgp-bestpath-compare-routerid:
 .. clicmd:: bgp bestpath compare-routerid
 
    Ensure that when comparing routes where both are equal on most metrics,
@@ -312,7 +310,7 @@ updates may be produced than at other times in reaction to some event .
 
 This first issue can be fixed with a more deterministic route selection that
 ensures routes are ordered by the neighbouring AS during selection.
-:ref:`bgp-deterministic-med`. This may reduce the number of updates as routes
+:clicmd:`bgp deterministic-med`. This may reduce the number of updates as routes
 are received, and may in some cases reduce routing churn. Though, it could
 equally deterministically produce the largest possible set of updates in
 response to the most common sequence of received updates.
@@ -389,8 +387,8 @@ avoided by speakers preferring already selected, external routes rather than
 choosing to update to new a route based on a post-MED metric (e.g.  router-ID),
 at the cost of a non-deterministic selection process. FRR implements this, as
 do many other implementations, so long as it is not overridden by setting
-:ref:`bgp-bestpath-compare-routerid`, and see also :ref:`bgp-decision-process`,
-.
+:clicmd:`bgp bestpath compare-routerid`, and see also
+:ref:`bgp-decision-process`.
 
 However, more complex and insidious cycles of oscillation are possible with
 iBGP route-reflection, which are not so easily avoided. These have been
@@ -442,8 +440,6 @@ topologies are at cross-purposes with each other - see the Flavel and Roughan
 paper above for an example. Hence the guideline that the iBGP topology should
 follow the IGP topology.
 
-.. _bgp-deterministic-med:
-
 .. index:: bgp deterministic-med
 .. clicmd:: bgp deterministic-med
 
@@ -464,8 +460,6 @@ Note that there are other sources of indeterminism in the route selection
 process, specifically, the preference for older and already selected routes
 from eBGP peers, :ref:`bgp-decision-process`.
 
-.. _bgp-always-compare-med:
-
 .. index:: bgp always-compare-med
 .. clicmd:: bgp always-compare-med
 
@@ -475,12 +469,12 @@ from eBGP peers, :ref:`bgp-decision-process`.
    oscillations.
 
    If using this option, it may also be desirable to use
-   :ref:`routemap-set-metric` to set MED to 0 on routes received from external
+   :clicmd:`set metric METRIC` to set MED to 0 on routes received from external
    neighbours.
 
-   This option can be used, together with :ref:`routemap-set-metric` to use MED
-   as an intra-AS metric to steer equal-length AS_PATH routes to, e.g., desired
-   exit points.
+   This option can be used, together with :clicmd:`set metric METRIC` to use
+   MED as an intra-AS metric to steer equal-length AS_PATH routes to, e.g.,
+   desired exit points.
 
 .. _bgp-network:
 
@@ -2298,23 +2292,7 @@ flaws.
    route-map rm-peer-in permit 10
     set community additive 64512:3200
 
-
-.. _configuring-frr-as-a-route-server:
-
-Configuring FRR as a Route Server
-=================================
-
-The purpose of a Route Server is to centralize the peerings between BGP
-speakers. For example if we have an exchange point scenario with four BGP
-speakers, each of which maintaining a BGP peering with the other three
-(:ref:`fig:full-mesh`), we can convert it into a centralized scenario where
-each of the four establishes a single BGP peering against the Route Server
-(:ref:`fig:route-server`).
-
-We will first describe briefly the Route Server model implemented by FRR.
-We will explain the commands that have been added for configuring that
-model. And finally we will show a full example of FRR configured as Route
-Server.
+.. include:: routeserver.rst
 
 .. include:: rpki.rst
 
diff --git a/doc/user/conf.py b/doc/user/conf.py
index b0bcb2ed43..e79dea0bdf 100644
--- a/doc/user/conf.py
+++ b/doc/user/conf.py
@@ -123,7 +123,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', 'rpki.rst', 'ospf_fundamentals.rst']
+exclude_patterns = ['_build', 'rpki.rst', 'routeserver.rst', 'ospf_fundamentals.rst']
 
 # The reST default role (used for this markup: `text`) to use for all
 # documents.
diff --git a/doc/user/isisd.rst b/doc/user/isisd.rst
index 783bb5a454..23b1af57ab 100644
--- a/doc/user/isisd.rst
+++ b/doc/user/isisd.rst
@@ -410,6 +410,8 @@ Showing ISIS information
    Show the ISIS routing table, as determined by the most recent SPF
    calculation.
 
+.. _isis-traffic-engineering:
+
 Traffic Engineering
 ===================
 
diff --git a/doc/user/routeserver.rst b/doc/user/routeserver.rst
new file mode 100644
index 0000000000..86fab0249f
--- /dev/null
+++ b/doc/user/routeserver.rst
@@ -0,0 +1,546 @@
+.. _configuring-frr-as-a-route-server:
+
+Configuring FRR as a Route Server
+=================================
+
+The purpose of a Route Server is to centralize the peerings between BGP
+speakers. For example if we have an exchange point scenario with four BGP
+speakers, each of which maintaining a BGP peering with the other three
+(:ref:`fig-topologies-full`), we can convert it into a centralized scenario where
+each of the four establishes a single BGP peering against the Route Server
+(:ref:`fig-topologies-rs`).
+
+We will first describe briefly the Route Server model implemented by FRR.
+We will explain the commands that have been added for configuring that
+model. And finally we will show a full example of FRR configured as Route
+Server.
+
+.. _description-of-the-route-server-model:
+
+Description of the Route Server model
+-------------------------------------
+
+First we are going to describe the normal processing that BGP announcements
+suffer inside a standard BGP speaker, as shown in :ref:`fig-normal-processing`,
+it consists of three steps:
+
+- When an announcement is received from some peer, the `In` filters configured
+  for that peer are applied to the announcement. These filters can reject the
+  announcement, accept it unmodified, or accept it with some of its attributes
+  modified.
+
+- The announcements that pass the `In` filters go into the Best Path Selection
+  process, where they are compared to other announcements referred to the same
+  destination that have been received from different peers (in case such other
+  announcements exist). For each different destination, the announcement which
+  is selected as the best is inserted into the BGP speaker's Loc-RIB.
+
+- The routes which are inserted in the Loc-RIB are considered for announcement
+  to all the peers (except the one from which the route came). This is done by
+  passing the routes in the Loc-RIB through the `Out` filters corresponding to
+  each peer. These filters can reject the route, accept it unmodified, or
+  accept it with some of its attributes modified. Those routes which are
+  accepted by the `Out` filters of a peer are announced to that peer.
+
+.. _fig-normal-processing:
+.. figure:: ../figures/fig-normal-processing.png
+   :alt: Normal announcement processing
+   :align: center
+
+   Announcement processing inside a 'normal' BGP speaker
+
+.. _fig-topologies-full:
+.. figure:: ../figures/fig_topologies_full.png
+   :alt: Full Mesh BGP Topology
+   :align: center
+
+   Full Mesh
+
+.. _fig-topologies-rs:
+.. figure:: ../figures/fig_topologies_rs.png
+   :alt: Route Server BGP Topology
+   :align: center
+
+   Route server and clients
+
+Of course we want that the routing tables obtained in each of the routers are
+the same when using the route server than when not. But as a consequence of
+having a single BGP peering (against the route server), the BGP speakers can no
+longer distinguish from/to which peer each announce comes/goes.
+
+.. _filter-delegation:
+This means that the routers connected to the route server are not able to apply
+by themselves the same input/output filters as in the full mesh scenario, so
+they have to delegate those functions to the route server.
+
+Even more, the 'best path' selection must be also performed inside the route
+server on behalf of its clients. The reason is that if, after applying the
+filters of the announcer and the (potential) receiver, the route server decides
+to send to some client two or more different announcements referred to the same
+destination, the client will only retain the last one, considering it as an
+implicit withdrawal of the previous announcements for the same destination.
+This is the expected behavior of a BGP speaker as defined in :rfc:`1771`,
+and even though there are some proposals of mechanisms that permit multiple
+paths for the same destination to be sent through a single BGP peering, none
+are currently supported by most existing BGP implementations.
+
+As a consequence a route server must maintain additional information and
+perform additional tasks for a RS-client that those necessary for common BGP
+peerings. Essentially a route server must:
+
+.. _route-server-tasks:
+
+- Maintain a separated Routing Information Base (Loc-RIB)
+  for each peer configured as RS-client, containing the routes
+  selected as a result of the 'Best Path Selection' process
+  that is performed on behalf of that RS-client.
+
+- Whenever it receives an announcement from a RS-client,
+  it must consider it for the Loc-RIBs of the other RS-clients.
+
+  - This means that for each of them the route server must pass the
+    announcement through the appropriate `Out` filter of the
+    announcer.
+
+  - Then through the appropriate `In` filter of the potential receiver.
+
+  - Only if the announcement is accepted by both filters it will be passed
+    to the 'Best Path Selection' process.
+
+  - Finally, it might go into the Loc-RIB of the receiver.
+
+When we talk about the 'appropriate' filter, both the announcer and the
+receiver of the route must be taken into account. Suppose that the route server
+receives an announcement from client A, and the route server is considering it
+for the Loc-RIB of client B. The filters that should be applied are the same
+that would be used in the full mesh scenario, i.e., first the `Out` filter of
+router A for announcements going to router B, and then the `In` filter of
+router B for announcements coming from router A.
+
+We call 'Export Policy' of a RS-client to the set of `Out` filters that the
+client would use if there was no route server. The same applies for the 'Import
+Policy' of a RS-client and the set of `In` filters of the client if there was
+no route server.
+
+It is also common to demand from a route server that it does not modify some
+BGP attributes (next-hop, as-path and MED) that are usually modified by
+standard BGP speakers before announcing a route.
+
+The announcement processing model implemented by Frr is shown in
+:ref:`fig-rs-processing`. The figure shows a mixture of RS-clients (B, C and D)
+with normal BGP peers (A). There are some details that worth additional
+comments:
+
+- Announcements coming from a normal BGP peer are also considered for the
+  Loc-RIBs of all the RS-clients. But logically they do not pass through any
+  export policy.
+
+- Those peers that are configured as RS-clients do not receive any announce
+  from the `Main` Loc-RIB.
+
+- Apart from import and export policies, `In` and `Out` filters can also be set
+  for RS-clients. `In` filters might be useful when the route server has also
+  normal BGP peers. On the other hand, `Out` filters for RS-clients are
+  probably unnecessary, but we decided not to remove them as they do not hurt
+  anybody (they can always be left empty).
+
+.. _fig-rs-processing:
+.. figure:: ../figures/fig-rs-processing.png
+   :align: center
+   :alt: Route Server Processing Model
+
+   Announcement processing model implemented by the Route Server
+
+.. _commands-for-configuring-a-route-server:
+
+Commands for configuring a Route Server
+---------------------------------------
+
+Now we will describe the commands that have been added to frr
+in order to support the route server features.
+
+.. index:: neighbor PEER-GROUP route-server-client
+.. clicmd:: neighbor PEER-GROUP route-server-client
+
+.. index:: neighbor A.B.C.D route-server-client
+.. clicmd:: neighbor A.B.C.D route-server-client
+
+.. index:: neighbor X:X::X:X route-server-client
+.. clicmd:: neighbor X:X::X:X route-server-client
+
+   This command configures the peer given by `peer`, `A.B.C.D` or `X:X::X:X` as
+   an RS-client.
+
+   Actually this command is not new, it already existed in standard Frr. It
+   enables the transparent mode for the specified peer. This means that some
+   BGP attributes (as-path, next-hop and MED) of the routes announced to that
+   peer are not modified.
+
+   With the route server patch, this command, apart from setting the
+   transparent mode, creates a new Loc-RIB dedicated to the specified peer
+   (those named `Loc-RIB for X` in :ref:`fig-rs-processing`.). Starting from
+   that moment, every announcement received by the route server will be also
+   considered for the new Loc-RIB.
+
+.. index:: neigbor A.B.C.D|X.X::X.X|peer-group route-map WORD import|export
+.. clicmd:: neigbor A.B.C.D|X.X::X.X|peer-group route-map WORD import|export
+
+   This set of commands can be used to specify the route-map that represents
+   the Import or Export policy of a peer which is configured as a RS-client
+   (with the previous command).
+
+.. index:: match peer A.B.C.D|X:X::X:X
+.. clicmd:: match peer A.B.C.D|X:X::X:X
+
+   This is a new *match* statement for use in route-maps, enabling them to
+   describe import/export policies. As we said before, an import/export policy
+   represents a set of input/output filters of the RS-client. This statement
+   makes possible that a single route-map represents the full set of filters
+   that a BGP speaker would use for its different peers in a non-RS scenario.
+
+   The *match peer* statement has different semantics whether it is used inside
+   an import or an export route-map. In the first case the statement matches if
+   the address of the peer who sends the announce is the same that the address
+   specified by {A.B.C.D|X:X::X:X}. For export route-maps it matches when
+   {A.B.C.D|X:X::X:X} is the address of the RS-Client into whose Loc-RIB the
+   announce is going to be inserted (how the same export policy is applied
+   before different Loc-RIBs is shown in :ref:`fig-rs-processing`.).
+
+.. index:: call WORD
+.. clicmd:: call WORD
+
+   This command (also used inside a route-map) jumps into a different
+   route-map, whose name is specified by `WORD`. When the called
+   route-map finishes, depending on its result the original route-map
+   continues or not. Apart from being useful for making import/export
+   route-maps easier to write, this command can also be used inside
+   any normal (in or out) route-map.
+
+.. _example-of-route-server-configuration:
+
+Example of Route Server Configuration
+-------------------------------------
+
+Finally we are going to show how to configure a Frr daemon to act as a
+Route Server. For this purpose we are going to present a scenario without
+route server, and then we will show how to use the configurations of the BGP
+routers to generate the configuration of the route server.
+
+All the configuration files shown in this section have been taken
+from scenarios which were tested using the VNUML tool
+`http://www.dit.upm.es/vnuml,VNUML <http://www.dit.upm.es/vnuml,VNUML>`_.
+
+.. _configuration-of-the-bgp-routers-without-route-server:
+
+Configuration of the BGP routers without Route Server
+-----------------------------------------------------
+
+We will suppose that our initial scenario is an exchange point with three
+BGP capable routers, named RA, RB and RC. Each of the BGP speakers generates
+some routes (with the `network` command), and establishes BGP peerings
+against the other two routers. These peerings have In and Out route-maps
+configured, named like 'PEER-X-IN' or 'PEER-X-OUT'. For example the
+configuration file for router RA could be the following:
+
+::
+
+   #Configuration for router 'RA'
+   !
+   hostname RA
+   password ****
+   !
+   router bgp 65001
+     no bgp default ipv4-unicast
+     neighbor 2001:0DB8::B remote-as 65002
+     neighbor 2001:0DB8::C remote-as 65003
+   !
+     address-family ipv6
+       network 2001:0DB8:AAAA:1::/64
+       network 2001:0DB8:AAAA:2::/64
+       network 2001:0DB8:0000:1::/64
+       network 2001:0DB8:0000:2::/64
+       neighbor 2001:0DB8::B activate
+       neighbor 2001:0DB8::B soft-reconfiguration inbound
+       neighbor 2001:0DB8::B route-map PEER-B-IN in
+       neighbor 2001:0DB8::B route-map PEER-B-OUT out
+       neighbor 2001:0DB8::C activate
+       neighbor 2001:0DB8::C soft-reconfiguration inbound
+       neighbor 2001:0DB8::C route-map PEER-C-IN in
+       neighbor 2001:0DB8::C route-map PEER-C-OUT out
+     exit-address-family
+   !
+   ipv6 prefix-list COMMON-PREFIXES seq  5 permit 2001:0DB8:0000::/48 ge 64 le 64
+   ipv6 prefix-list COMMON-PREFIXES seq 10 deny any
+   !
+   ipv6 prefix-list PEER-A-PREFIXES seq  5 permit 2001:0DB8:AAAA::/48 ge 64 le 64
+   ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any
+   !
+   ipv6 prefix-list PEER-B-PREFIXES seq  5 permit 2001:0DB8:BBBB::/48 ge 64 le 64
+   ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any
+   !
+   ipv6 prefix-list PEER-C-PREFIXES seq  5 permit 2001:0DB8:CCCC::/48 ge 64 le 64
+   ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any
+   !
+   route-map PEER-B-IN permit 10
+     match ipv6 address prefix-list COMMON-PREFIXES
+     set metric 100
+   route-map PEER-B-IN permit 20
+     match ipv6 address prefix-list PEER-B-PREFIXES
+     set community 65001:11111
+   !
+   route-map PEER-C-IN permit 10
+     match ipv6 address prefix-list COMMON-PREFIXES
+     set metric 200
+   route-map PEER-C-IN permit 20
+     match ipv6 address prefix-list PEER-C-PREFIXES
+     set community 65001:22222
+   !
+   route-map PEER-B-OUT permit 10
+     match ipv6 address prefix-list PEER-A-PREFIXES
+   !
+   route-map PEER-C-OUT permit 10
+     match ipv6 address prefix-list PEER-A-PREFIXES
+   !
+   line vty
+   !
+
+
+.. _configuration-of-the-bgp-routers-with-route-server:
+
+Configuration of the BGP routers with Route Server
+--------------------------------------------------
+
+To convert the initial scenario into one with route server, first we must
+modify the configuration of routers RA, RB and RC. Now they must not peer
+between them, but only with the route server. For example, RA's
+configuration would turn into:
+
+::
+
+  # Configuration for router 'RA'
+  !
+  hostname RA
+  password ****
+  !
+  router bgp 65001
+    no bgp default ipv4-unicast
+    neighbor 2001:0DB8::FFFF remote-as 65000
+  !
+    address-family ipv6
+      network 2001:0DB8:AAAA:1::/64
+      network 2001:0DB8:AAAA:2::/64
+      network 2001:0DB8:0000:1::/64
+      network 2001:0DB8:0000:2::/64
+
+      neighbor 2001:0DB8::FFFF activate
+      neighbor 2001:0DB8::FFFF soft-reconfiguration inbound
+    exit-address-family
+  !
+  line vty
+  !
+
+
+Which is logically much simpler than its initial configuration, as it now
+maintains only one BGP peering and all the filters (route-maps) have
+disappeared.
+
+.. _configuration-of-the-route-server-itself:
+
+Configuration of the Route Server itself
+----------------------------------------
+
+As we said when we described the functions of a route server
+(:ref:`description-of-the-route-server-model`), it is in charge of all the
+route filtering. To achieve that, the In and Out filters from the RA, RB and RC
+configurations must be converted into Import and Export policies in the route
+server.
+
+This is a fragment of the route server configuration (we only show
+the policies for client RA):
+
+::
+
+  # Configuration for Route Server ('RS')
+  !
+  hostname RS
+  password ix
+  !
+  bgp multiple-instance
+  !
+  router bgp 65000 view RS
+    no bgp default ipv4-unicast
+    neighbor 2001:0DB8::A  remote-as 65001
+    neighbor 2001:0DB8::B  remote-as 65002
+    neighbor 2001:0DB8::C  remote-as 65003
+  !
+    address-family ipv6
+      neighbor 2001:0DB8::A activate
+      neighbor 2001:0DB8::A route-server-client
+      neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import
+      neighbor 2001:0DB8::A route-map RSCLIENT-A-EXPORT export
+      neighbor 2001:0DB8::A soft-reconfiguration inbound
+
+      neighbor 2001:0DB8::B activate
+      neighbor 2001:0DB8::B route-server-client
+      neighbor 2001:0DB8::B route-map RSCLIENT-B-IMPORT import
+      neighbor 2001:0DB8::B route-map RSCLIENT-B-EXPORT export
+      neighbor 2001:0DB8::B soft-reconfiguration inbound
+
+      neighbor 2001:0DB8::C activate
+      neighbor 2001:0DB8::C route-server-client
+      neighbor 2001:0DB8::C route-map RSCLIENT-C-IMPORT import
+      neighbor 2001:0DB8::C route-map RSCLIENT-C-EXPORT export
+      neighbor 2001:0DB8::C soft-reconfiguration inbound
+    exit-address-family
+  !
+  ipv6 prefix-list COMMON-PREFIXES seq  5 permit 2001:0DB8:0000::/48 ge 64 le 64
+  ipv6 prefix-list COMMON-PREFIXES seq 10 deny any
+  !
+  ipv6 prefix-list PEER-A-PREFIXES seq  5 permit 2001:0DB8:AAAA::/48 ge 64 le 64
+  ipv6 prefix-list PEER-A-PREFIXES seq 10 deny any
+  !
+  ipv6 prefix-list PEER-B-PREFIXES seq  5 permit 2001:0DB8:BBBB::/48 ge 64 le 64
+  ipv6 prefix-list PEER-B-PREFIXES seq 10 deny any
+  !
+  ipv6 prefix-list PEER-C-PREFIXES seq  5 permit 2001:0DB8:CCCC::/48 ge 64 le 64
+  ipv6 prefix-list PEER-C-PREFIXES seq 10 deny any
+  !
+  route-map RSCLIENT-A-IMPORT permit 10
+    match peer 2001:0DB8::B
+    call A-IMPORT-FROM-B
+  route-map RSCLIENT-A-IMPORT permit 20
+    match peer 2001:0DB8::C
+    call A-IMPORT-FROM-C
+  !
+  route-map A-IMPORT-FROM-B permit 10
+    match ipv6 address prefix-list COMMON-PREFIXES
+    set metric 100
+  route-map A-IMPORT-FROM-B permit 20
+    match ipv6 address prefix-list PEER-B-PREFIXES
+    set community 65001:11111
+  !
+  route-map A-IMPORT-FROM-C permit 10
+    match ipv6 address prefix-list COMMON-PREFIXES
+    set metric 200
+  route-map A-IMPORT-FROM-C permit 20
+    match ipv6 address prefix-list PEER-C-PREFIXES
+    set community 65001:22222
+  !
+  route-map RSCLIENT-A-EXPORT permit 10
+    match peer 2001:0DB8::B
+    match ipv6 address prefix-list PEER-A-PREFIXES
+  route-map RSCLIENT-A-EXPORT permit 20
+    match peer 2001:0DB8::C
+    match ipv6 address prefix-list PEER-A-PREFIXES
+  !
+  ...
+  ...
+  ...
+
+
+If you compare the initial configuration of RA with the route server
+configuration above, you can see how easy it is to generate the Import and
+Export policies for RA from the In and Out route-maps of RA's original
+configuration.
+
+When there was no route server, RA maintained two peerings, one with RB and
+another with RC. Each of this peerings had an In route-map configured. To
+build the Import route-map for client RA in the route server, simply add
+route-map entries following this scheme:
+
+::
+
+   route-map <NAME> permit 10
+       match peer <Peer Address>
+       call <In Route-Map for this Peer>
+   route-map <NAME> permit 20
+       match peer <Another Peer Address>
+       call <In Route-Map for this Peer>
+
+
+This is exactly the process that has been followed to generate the route-map
+RSCLIENT-A-IMPORT. The route-maps that are called inside it (A-IMPORT-FROM-B
+and A-IMPORT-FROM-C) are exactly the same than the In route-maps from the
+original configuration of RA (PEER-B-IN and PEER-C-IN), only the name is
+different.
+
+The same could have been done to create the Export policy for RA (route-map
+RSCLIENT-A-EXPORT), but in this case the original Out route-maps where so
+simple that we decided not to use the `call WORD` commands, and we
+integrated all in a single route-map (RSCLIENT-A-EXPORT).
+
+The Import and Export policies for RB and RC are not shown, but
+the process would be identical.
+
+Further considerations about Import and Export route-maps
+---------------------------------------------------------
+
+The current version of the route server patch only allows to specify a
+route-map for import and export policies, while in a standard BGP speaker
+apart from route-maps there are other tools for performing input and output
+filtering (access-lists, community-lists, ...). But this does not represent
+any limitation, as all kinds of filters can be included in import/export
+route-maps. For example suppose that in the non-route-server scenario peer
+RA had the following filters configured for input from peer B:
+
+::
+
+   neighbor 2001:0DB8::B prefix-list LIST-1 in
+   neighbor 2001:0DB8::B filter-list LIST-2 in
+   neighbor 2001:0DB8::B route-map PEER-B-IN in
+   ...
+   ...
+   route-map PEER-B-IN permit 10
+     match ipv6 address prefix-list COMMON-PREFIXES
+     set local-preference 100
+   route-map PEER-B-IN permit 20
+     match ipv6 address prefix-list PEER-B-PREFIXES
+     set community 65001:11111
+
+
+It is posible to write a single route-map which is equivalent to
+the three filters (the community-list, the prefix-list and the
+route-map). That route-map can then be used inside the Import
+policy in the route server. Lets see how to do it:
+
+::
+
+   neighbor 2001:0DB8::A route-map RSCLIENT-A-IMPORT import
+   ...
+   !
+   ...
+   route-map RSCLIENT-A-IMPORT permit 10
+     match peer 2001:0DB8::B
+     call A-IMPORT-FROM-B
+   ...
+   ...
+   !
+   route-map A-IMPORT-FROM-B permit 1
+     match ipv6 address prefix-list LIST-1
+     match as-path LIST-2
+     on-match goto 10
+   route-map A-IMPORT-FROM-B deny 2
+   route-map A-IMPORT-FROM-B permit 10
+     match ipv6 address prefix-list COMMON-PREFIXES
+     set local-preference 100
+   route-map A-IMPORT-FROM-B permit 20
+     match ipv6 address prefix-list PEER-B-PREFIXES
+     set community 65001:11111
+   !
+   ...
+   ...
+
+
+The route-map A-IMPORT-FROM-B is equivalent to the three filters (LIST-1,
+LIST-2 and PEER-B-IN). The first entry of route-map A-IMPORT-FROM-B (sequence
+number 1) matches if and only if both the prefix-list LIST-1 and the
+filter-list LIST-2 match. If that happens, due to the 'on-match goto 10'
+statement the next route-map entry to be processed will be number 10, and as of
+that point route-map A-IMPORT-FROM-B is identical to PEER-B-IN. If the first
+entry does not match, `on-match goto 10`' will be ignored and the next
+processed entry will be number 2, which will deny the route.
+
+Thus, the result is the same that with the three original filters, i.e., if
+either LIST-1 or LIST-2 rejects the route, it does not reach the route-map
+PEER-B-IN. In case both LIST-1 and LIST-2 accept the route, it passes to
+PEER-B-IN, which can reject, accept or modify the route.
-- 
cgit v1.2.3


From 5a32c42459ea04b7a8b666745e55528edc57b302 Mon Sep 17 00:00:00 2001
From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Fri, 2 Feb 2018 16:27:00 -0500
Subject: doc: add logos

Branding!

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
---
 doc/developer/conf.py           |   6 +++---
 doc/figures/frr-logo-icon.png   | Bin 0 -> 1609 bytes
 doc/figures/frr-logo-medium.png | Bin 0 -> 13129 bytes
 doc/figures/frr-logo-small.png  | Bin 0 -> 6175 bytes
 doc/figures/frr-logo.png        | Bin 0 -> 26502 bytes
 doc/user/conf.py                |   6 +++---
 6 files changed, 6 insertions(+), 6 deletions(-)
 create mode 100644 doc/figures/frr-logo-icon.png
 create mode 100644 doc/figures/frr-logo-medium.png
 create mode 100644 doc/figures/frr-logo-small.png
 create mode 100644 doc/figures/frr-logo.png

(limited to 'doc/user/conf.py')

diff --git a/doc/developer/conf.py b/doc/developer/conf.py
index c3295f88bd..e4c56f54c3 100644
--- a/doc/developer/conf.py
+++ b/doc/developer/conf.py
@@ -176,12 +176,12 @@ html_theme = 'sphinx_rtd_theme'
 
 # The name of an image file (relative to this directory) to place at the top
 # of the sidebar.
-#html_logo = None
+html_logo = '../figures/frr-logo-medium.png'
 
 # The name of an image file (within the static path) to use as favicon of the
 # docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
 # pixels large.
-#html_favicon = None
+html_favicon = '../figures/frr-logo-icon.png'
 
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
@@ -277,7 +277,7 @@ latex_documents = [
 
 # The name of an image file (relative to this directory) to place at the top of
 # the title page.
-#latex_logo = None
+latex_logo = '../figures/frr-logo-medium.png'
 
 # For "manual" documents, if this is true, then toplevel headings are parts,
 # not chapters.
diff --git a/doc/figures/frr-logo-icon.png b/doc/figures/frr-logo-icon.png
new file mode 100644
index 0000000000..37973fcf2d
Binary files /dev/null and b/doc/figures/frr-logo-icon.png differ
diff --git a/doc/figures/frr-logo-medium.png b/doc/figures/frr-logo-medium.png
new file mode 100644
index 0000000000..04e18ebf5d
Binary files /dev/null and b/doc/figures/frr-logo-medium.png differ
diff --git a/doc/figures/frr-logo-small.png b/doc/figures/frr-logo-small.png
new file mode 100644
index 0000000000..2a9a2c7fd5
Binary files /dev/null and b/doc/figures/frr-logo-small.png differ
diff --git a/doc/figures/frr-logo.png b/doc/figures/frr-logo.png
new file mode 100644
index 0000000000..6e66414c3a
Binary files /dev/null and b/doc/figures/frr-logo.png differ
diff --git a/doc/user/conf.py b/doc/user/conf.py
index e79dea0bdf..6aa97de304 100644
--- a/doc/user/conf.py
+++ b/doc/user/conf.py
@@ -176,12 +176,12 @@ html_theme = 'sphinx_rtd_theme'
 
 # The name of an image file (relative to this directory) to place at the top
 # of the sidebar.
-#html_logo = None
+html_logo = '../figures/frr-logo-medium.png'
 
 # The name of an image file (within the static path) to use as favicon of the
 # docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
 # pixels large.
-#html_favicon = None
+html_favicon = '../figures/frr-logo-icon.png'
 
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
@@ -277,7 +277,7 @@ latex_documents = [
 
 # The name of an image file (relative to this directory) to place at the top of
 # the title page.
-#latex_logo = None
+latex_logo = '../figures/frr-logo-medium.png'
 
 # For "manual" documents, if this is true, then toplevel headings are parts,
 # not chapters.
-- 
cgit v1.2.3


From 6c749456224b383a95e717c95cdb6289eb9cb5e4 Mon Sep 17 00:00:00 2001
From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Wed, 7 Feb 2018 19:22:52 -0500
Subject: doc: use python 2.6 format strings

Centos 6 only has python 2.6 which requires numerical identifiers for
format strings

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
---
 doc/developer/conf.py | 4 ++--
 doc/manpages/conf.py  | 6 +++---
 doc/user/conf.py      | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

(limited to 'doc/user/conf.py')

diff --git a/doc/developer/conf.py b/doc/developer/conf.py
index e4c56f54c3..1cb1d45af6 100644
--- a/doc/developer/conf.py
+++ b/doc/developer/conf.py
@@ -98,8 +98,8 @@ with open('../../config.status', 'r') as cfgstatus:
 
 # manually fill out some of these we can't get from config.status
 replace_vars['COPYRIGHT_STR'] = "Copyright (c)"
-replace_vars['COPYRIGHT_STR'] += ' {}'.format(replace_vars['COPYRIGHT_YEAR'])
-replace_vars['COPYRIGHT_STR'] += ' {}'.format(replace_vars['AUTHORS'])
+replace_vars['COPYRIGHT_STR'] += ' {0}'.format(replace_vars['COPYRIGHT_YEAR'])
+replace_vars['COPYRIGHT_STR'] += ' {0}'.format(replace_vars['AUTHORS'])
 release = replace_vars['PACKAGE_VERSION']
 version = release.split('-')[0]
 
diff --git a/doc/manpages/conf.py b/doc/manpages/conf.py
index 403e86e55e..6da6ebff0a 100644
--- a/doc/manpages/conf.py
+++ b/doc/manpages/conf.py
@@ -100,8 +100,8 @@ with open('../../config.status', 'r') as cfgstatus:
 
 # manually fill out some of these we can't get from config.status
 replace_vars['COPYRIGHT_STR'] = "Copyright (c)"
-replace_vars['COPYRIGHT_STR'] += ' {}'.format(replace_vars['COPYRIGHT_YEAR'])
-replace_vars['COPYRIGHT_STR'] += ' {}'.format(replace_vars['AUTHORS'])
+replace_vars['COPYRIGHT_STR'] += ' {0}'.format(replace_vars['COPYRIGHT_YEAR'])
+replace_vars['COPYRIGHT_STR'] += ' {0}'.format(replace_vars['AUTHORS'])
 release = replace_vars['PACKAGE_VERSION']
 version = release.split('-')[0]
 
@@ -306,7 +306,7 @@ latex_documents = [
 # If true, show URL addresses after external links.
 #man_show_urls = False
 
-fwfrr = "{} routing engine for use with FRRouting."
+fwfrr = "{0} routing engine for use with FRRouting."
 
 man_pages = [
     ('bgpd', 'bgpd', fwfrr.format("a BGPv4, BGPv4+, BGPv4- "), [], 8),
diff --git a/doc/user/conf.py b/doc/user/conf.py
index 6aa97de304..bd1bf6c041 100644
--- a/doc/user/conf.py
+++ b/doc/user/conf.py
@@ -98,8 +98,8 @@ with open('../../config.status', 'r') as cfgstatus:
 
 # manually fill out some of these we can't get from config.status
 replace_vars['COPYRIGHT_STR'] = "Copyright (c)"
-replace_vars['COPYRIGHT_STR'] += ' {}'.format(replace_vars['COPYRIGHT_YEAR'])
-replace_vars['COPYRIGHT_STR'] += ' {}'.format(replace_vars['AUTHORS'])
+replace_vars['COPYRIGHT_STR'] += ' {0}'.format(replace_vars['COPYRIGHT_YEAR'])
+replace_vars['COPYRIGHT_STR'] += ' {0}'.format(replace_vars['AUTHORS'])
 release = replace_vars['PACKAGE_VERSION']
 version = release.split('-')[0]
 
-- 
cgit v1.2.3


From 2f8c365e02d044898c9286b907695d87f1fa0e1b Mon Sep 17 00:00:00 2001
From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Thu, 8 Feb 2018 11:53:49 -0500
Subject: doc: change html theme, add svg logo

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
---
 doc/developer/conf.py    | 10 ++++++----
 doc/figures/frr-icon.svg | 39 +++++++++++++++++++++++++++++++++++++++
 doc/user/conf.py         | 10 ++++++----
 3 files changed, 51 insertions(+), 8 deletions(-)
 create mode 100644 doc/figures/frr-icon.svg

(limited to 'doc/user/conf.py')

diff --git a/doc/developer/conf.py b/doc/developer/conf.py
index 1cb1d45af6..7078910289 100644
--- a/doc/developer/conf.py
+++ b/doc/developer/conf.py
@@ -157,12 +157,14 @@ todo_include_todos = True
 
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
-html_theme = 'sphinx_rtd_theme'
+html_theme = 'classic'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
-#html_theme_options = {}
+html_theme_options = {
+    'sidebarbgcolor': '#374249'
+}
 
 # Add any paths that contain custom themes here, relative to this directory.
 #html_theme_path = []
@@ -176,7 +178,7 @@ html_theme = 'sphinx_rtd_theme'
 
 # The name of an image file (relative to this directory) to place at the top
 # of the sidebar.
-html_logo = '../figures/frr-logo-medium.png'
+html_logo = '../figures/frr-icon.svg'
 
 # The name of an image file (within the static path) to use as favicon of the
 # docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
@@ -186,7 +188,7 @@ html_favicon = '../figures/frr-logo-icon.png'
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
+#html_static_path = ['_static']
 
 # Add any extra paths that contain custom files (such as robots.txt or
 # .htaccess) here, relative to this directory. These files are copied
diff --git a/doc/figures/frr-icon.svg b/doc/figures/frr-icon.svg
new file mode 100644
index 0000000000..f7bdebc62e
--- /dev/null
+++ b/doc/figures/frr-icon.svg
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   viewBox="0 0 255.16251 264.35001"
+   height="264.35001"
+   width="255.16251"
+   xml:space="preserve"
+   version="1.1"
+   id="svg2"><metadata
+     id="metadata8"><rdf:RDF><cc:Work
+         rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title></dc:title></cc:Work></rdf:RDF></metadata><defs
+     id="defs6" /><g
+     transform="matrix(1.25,0,0,-1.25,0,264.35)"
+     id="g10"><g
+       transform="scale(0.1,0.1)"
+       id="g12"><path
+         id="path14"
+         style="fill:#f36f16;fill-opacity:1;fill-rule:nonzero;stroke:none"
+         d="m 260.984,905.711 c 0,-431.5 345.223,-786.52 788.866,-832.2696 l 0,290.4566 c -274.799,44.071 -483.912,269.543 -484.475,541.813 0.563,272.249 209.676,497.819 484.475,541.849 l 0,290.5 C 606.207,1692.18 261.063,1337.24 260.984,905.711" /><path
+         id="path16"
+         style="fill:#f36f16;fill-opacity:1;fill-rule:nonzero;stroke:none"
+         d="m 709.863,908.891 c 0,-197.121 146.297,-362.243 343.647,-408.469 l 0,816.938 C 856.16,1271.14 709.863,1106.06 709.863,908.891" /><path
+         id="path18"
+         style="fill:#f36f16;fill-opacity:1;fill-rule:nonzero;stroke:none"
+         d="m 748.035,2114.83 1.395,-202.42 C 349.336,1773.27 53.4609,1430.82 2.73828,1017.01 L 0,994.961 l 133.66,0 2.309,17.319 c 60.746,449.24 447.246,801.35 928.931,838.53 l 19.35,1.55 -336.215,262.47" /><path
+         id="path20"
+         style="fill:#393536;fill-opacity:1;fill-rule:nonzero;stroke:none"
+         d="m 1395.52,1123.39 c 0,-51.43 -41.66,-93.14 -93.14,-93.14 -51.42,0 -93.17,41.71 -93.17,93.14 0,51.46 41.75,93.19 93.17,93.19 51.48,0 93.14,-41.73 93.14,-93.19" /><path
+         id="path22"
+         style="fill:#f36f16;fill-opacity:1;fill-rule:nonzero;stroke:none"
+         d="m 1529.56,476.52 49.41,-72.372 c 118.33,73.59 206.07,171.122 264.08,280.274 l -90.08,18.258 C 1701.77,615.23 1627.9,537.191 1529.56,476.52 Z m 338.86,848.67 -95.9,0 c 44.87,-92.73 68.09,-194.02 68.42,-295.5 0,-11.12 -0.48,-22.22 -1.06,-33.311 l 80.2,-75.578 c 5.3,36.097 8.22,72.5 8.14,108.889 0.34,100.55 -20.33,201.15 -59.8,295.5" /><path
+         id="path24"
+         style="fill:#f36f16;fill-opacity:1;fill-rule:nonzero;stroke:none"
+         d="m 1663.19,790.07 378.12,-76.73 -321,302.64 c 0.23,6.25 0.73,12.42 0.73,18.71 0,284.04 -218.31,520.69 -508.02,574.72 l 0,-127.07 c 215.24,-51.78 373.82,-232.3 374.38,-447.49 -0.56,-215.42 -159.14,-395.901 -374.38,-447.709 l 0,-127.129 C 1214.79,460.289 1537.38,0 1537.38,0 l 164.55,0 -353.76,500.422 c 139.05,58.219 251.25,161.488 315.02,289.648" /></g></g></svg>
\ No newline at end of file
diff --git a/doc/user/conf.py b/doc/user/conf.py
index bd1bf6c041..a9ea4ad90c 100644
--- a/doc/user/conf.py
+++ b/doc/user/conf.py
@@ -157,12 +157,14 @@ todo_include_todos = True
 
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
-html_theme = 'sphinx_rtd_theme'
+html_theme = 'classic'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
-#html_theme_options = {}
+html_theme_options = {
+    'sidebarbgcolor': '#374249'
+}
 
 # Add any paths that contain custom themes here, relative to this directory.
 #html_theme_path = []
@@ -176,7 +178,7 @@ html_theme = 'sphinx_rtd_theme'
 
 # The name of an image file (relative to this directory) to place at the top
 # of the sidebar.
-html_logo = '../figures/frr-logo-medium.png'
+html_logo = '../figures/frr-icon.svg'
 
 # The name of an image file (within the static path) to use as favicon of the
 # docs.  This file should be a Windows icon file (.ico) being 16x16 or 32x32
@@ -186,7 +188,7 @@ html_favicon = '../figures/frr-logo-icon.png'
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
+# html_static_path = ['_static']
 
 # Add any extra paths that contain custom files (such as robots.txt or
 # .htaccess) here, relative to this directory. These files are copied
-- 
cgit v1.2.3


From b59555c6bf74592c9959a85033e6c56bdac15eae Mon Sep 17 00:00:00 2001
From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Thu, 22 Feb 2018 12:27:12 -0500
Subject: doc: change info file name from FRR -> frr

conventions yo

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
---
 debianpkg/frr-doc.info | 2 +-
 debianpkg/rules        | 4 ++--
 doc/Makefile.am        | 4 ++--
 doc/developer/conf.py  | 2 +-
 doc/user/conf.py       | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

(limited to 'doc/user/conf.py')

diff --git a/debianpkg/frr-doc.info b/debianpkg/frr-doc.info
index 5fadb0024d..a83255a24f 100644
--- a/debianpkg/frr-doc.info
+++ b/debianpkg/frr-doc.info
@@ -1 +1 @@
-doc/user/_build/texinfo/FRR.info
+doc/user/_build/texinfo/frr.info
diff --git a/debianpkg/rules b/debianpkg/rules
index 1d98e2099b..14294f54fe 100755
--- a/debianpkg/rules
+++ b/debianpkg/rules
@@ -140,8 +140,8 @@ override_dh_auto_build:
 ifeq ($(GENERATE_PDF), 1)
 	dh_auto_build -- -C doc user.pdf
 endif
-	rm -vf doc/user/_build/texinfo/FRR.info
-	dh_auto_build -- -C doc FRR.info
+	rm -vf doc/user/_build/texinfo/frr.info
+	dh_auto_build -- -C doc frr.info
 
 override_dh_auto_test:
 
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 943fba91e2..b822a3c685 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -86,8 +86,8 @@ developer.html:
 
 # info target, handled by automake installation
 install-data-local: frr.info
-	gzip < user/_build/texinfo/FRR.info > ${infodir}/FRR.info.gz
-	install-info user/_build/texinfo/FRR.info ${infodir}/dir
+	gzip < user/_build/texinfo/frr.info > ${infodir}/frr.info.gz
+	install-info user/_build/texinfo/frr.info ${infodir}/dir
 
 # include sources for shipped docs
 EXTRA_DIST = manpages/defines.rst \
diff --git a/doc/developer/conf.py b/doc/developer/conf.py
index 7078910289..3f531c14b0 100644
--- a/doc/developer/conf.py
+++ b/doc/developer/conf.py
@@ -317,7 +317,7 @@ man_pages = [
 # (source start file, target name, title, author,
 #  dir menu entry, description, category)
 texinfo_documents = [
-    (master_doc, 'FRR', u"FRR Developer's Manual",
+    (master_doc, 'frr', u"FRR Developer's Manual",
      author, 'FRR', 'One line description of project.',
      'Miscellaneous'),
 ]
diff --git a/doc/user/conf.py b/doc/user/conf.py
index a9ea4ad90c..817a6d83bb 100644
--- a/doc/user/conf.py
+++ b/doc/user/conf.py
@@ -317,7 +317,7 @@ man_pages = [
 # (source start file, target name, title, author,
 #  dir menu entry, description, category)
 texinfo_documents = [
-    (master_doc, 'FRR', u'FRR User Manual',
+    (master_doc, 'frr', u'FRR User Manual',
      author, 'FRR', 'One line description of project.',
      'Miscellaneous'),
 ]
-- 
cgit v1.2.3


From 37ba370b9eb45c2905c9c411f29c8ecf5e0e4c53 Mon Sep 17 00:00:00 2001
From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Wed, 7 Mar 2018 16:28:23 -0500
Subject: doc: change html theme to 'default'

Looks like older versions of Sphinx switched around naming for the default
themes.

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
---
 doc/Makefile.am       | 5 +++--
 doc/developer/conf.py | 2 +-
 doc/manpages/conf.py  | 2 +-
 doc/user/conf.py      | 2 +-
 4 files changed, 6 insertions(+), 5 deletions(-)

(limited to 'doc/user/conf.py')

diff --git a/doc/Makefile.am b/doc/Makefile.am
index 62f3ae2b6a..caa909d50d 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -10,7 +10,7 @@
 # never built as part of a regular build. They are only built when explicitly
 # asked for. See comment further down.
 SUBDIRS = manpages user
-AM_MAKEFLAGS = DESTDIR=${DESTDIR} infodir=${infodir}
+AM_MAKEFLAGS = DESTDIR=${DESTDIR} infodir=${infodir} doczdir=${abs_srcdir}
 
 MANPAGE_BUILDDIR = manpages/_build/man
 
@@ -117,7 +117,8 @@ developer-html:
 # $ make help
 
 # dist tarballs want doc sources
-EXTRA_DIST = manpages/defines.rst \
+EXTRA_DIST = frr-sphinx.mk \
+	manpages/defines.rst \
 	manpages/ldpd.rst \
 	manpages/index.rst \
 	manpages/bgpd.rst \
diff --git a/doc/developer/conf.py b/doc/developer/conf.py
index 3f531c14b0..e2293b2a6b 100644
--- a/doc/developer/conf.py
+++ b/doc/developer/conf.py
@@ -157,7 +157,7 @@ todo_include_todos = True
 
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
-html_theme = 'classic'
+html_theme = 'default'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
diff --git a/doc/manpages/conf.py b/doc/manpages/conf.py
index 50331b6f0a..a78e1a2c38 100644
--- a/doc/manpages/conf.py
+++ b/doc/manpages/conf.py
@@ -159,7 +159,7 @@ todo_include_todos = True
 
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
-html_theme = 'classic'
+html_theme = 'default'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
diff --git a/doc/user/conf.py b/doc/user/conf.py
index 817a6d83bb..efe1023740 100644
--- a/doc/user/conf.py
+++ b/doc/user/conf.py
@@ -157,7 +157,7 @@ todo_include_todos = True
 
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
-html_theme = 'classic'
+html_theme = 'default'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
-- 
cgit v1.2.3