doc: strip trailing whitespace

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>

18 files changed, 152 insertions, 152 deletions

diff --git a/doc/user/defines.rst b/doc/user/defines.rst
index e8c779d3a..69766d3da 100644
--- a/doc/user/defines.rst
+++ b/doc/user/defines.rst
@@ -3,7 +3,7 @@
    That, in turn, needs to be generated by make at compile time.
    @c -*- texinfo -*-
    @c doc/defines.texi.  Generated from defines.texi.in by configure.
-   
+
    @c Set variables
    @set PACKAGE_NAME frr
    @set PACKAGE_TARNAME frr
@@ -13,7 +13,7 @@
    @set AUTHORS Kunihiro Ishiguro, et al.
    @set COPYRIGHT_YEAR 1999-2005
    @set COPYRIGHT_STR Copyright @copyright{} |COPYRIGHT_YEAR| |AUTHORS|
-   
+
    @c These may vary with installation environment.
    @set INSTALL_PREFIX_ETC /etc/frr
    @set INSTALL_PREFIX_SBIN /usr/lib/frr
diff --git a/doc/user/filter.rst b/doc/user/filter.rst
index 730e42403..73ffba8f3 100644
--- a/doc/user/filter.rst
+++ b/doc/user/filter.rst
@@ -25,7 +25,7 @@ IP Access List
 
     access-list filter deny 10.0.0.0/9
     access-list filter permit 10.0.0.0/8
-    
+
 
   @comment  node-name,  next,  previous,  up
 
@@ -38,7 +38,7 @@ filtering mechanism.  In addition to *access-list* functionality,
 sequential number specification.  You can add or delete prefix based
 filters to arbitrary points of prefix-list using sequential number specification.
 
-If no ip prefix-list is specified, it acts as permit.  If *ip prefix-list* 
+If no ip prefix-list is specified, it acts as permit.  If *ip prefix-list*
 is defined, and no match is found, default deny is applied.
 
 .. index:: {Command} {ip prefix-list `name` (permit|deny) `prefix` [le `len`] [ge `len`]} {}
@@ -66,12 +66,12 @@ is defined, and no match is found, default deny is applied.
 
 
 *@asis{le}*
-      *le* command specifies prefix length.  The prefix list will be 
+      *le* command specifies prefix length.  The prefix list will be
       applied if the prefix length is less than or equal to the le prefix length.
 
 
 *@asis{ge}*
-      *ge* command specifies prefix length.  The prefix list will be 
+      *ge* command specifies prefix length.  The prefix list will be
       applied if the prefix length is greater than or equal to the ge prefix length.
 
 
diff --git a/doc/user/index.rst b/doc/user/index.rst
index 0d705d10a..2e4636ec8 100644
--- a/doc/user/index.rst
+++ b/doc/user/index.rst
@@ -7,7 +7,7 @@ Welcome to FRR's documentation!
    overview
    installation
    basic
-   zebra 
+   zebra
    ripd
    ripngd
    ospfd
diff --git a/doc/user/isisd.rst b/doc/user/isisd.rst
index 648e849ee..83d7af55b 100644
--- a/doc/user/isisd.rst
+++ b/doc/user/isisd.rst
@@ -563,7 +563,7 @@ A simple example, with MD5 authentication enabled:
   net 47.0023.0000.0000.0000.0000.0000.0000.1900.0004.00
    metric-style wide
    is-type level-2-only
-  
+
 
 A Traffic Engineering configuration, with Inter-ASv2 support.
 
@@ -607,7 +607,7 @@ A Traffic Engineering configuration, with Inter-ASv2 support.
    mpls-te link unrsv-bw 7 1.25e+06
    mpls-te link rsc-clsclr 0xab
    mpls-te neighbor 10.1.1.2 as 65000
-  
+
 
 - Then the 'isisd.conf' itself:
 
@@ -631,5 +631,5 @@ A Traffic Engineering configuration, with Inter-ASv2 support.
     mpls-te router-address 10.1.1.1
   !
   line vty
-  
+
 
diff --git a/doc/user/kernel.rst b/doc/user/kernel.rst
index a11b3ef16..4611277de 100644
--- a/doc/user/kernel.rst
+++ b/doc/user/kernel.rst
@@ -40,8 +40,8 @@ interfaces.
   communication between kernel and FRR possible, similar to a routing
   socket on BSD systems.
 
-  Before you use this feature, be sure to select (in kernel configuration) 
-  the kernel/netlink support option 'Kernel/User network link driver' and 
+  Before you use this feature, be sure to select (in kernel configuration)
+  the kernel/netlink support option 'Kernel/User network link driver' and
   'Routing messages'.
 
   Today, the /dev/route special device file is obsolete.  Netlink
diff --git a/doc/user/nhrpd.rst b/doc/user/nhrpd.rst
index ae8a98619..ba6011b44 100644
--- a/doc/user/nhrpd.rst
+++ b/doc/user/nhrpd.rst
@@ -38,7 +38,7 @@ commands):
    ip tunnel add gre1 mode gre key 42 ttl 64
    ip addr add 10.255.255.2/32 dev gre1
    ip link set gre1 up
-  
+
 
 Note that the IP-address is assigned as host prefix to gre1. nhrpd will
 automatically create additional host routes pointing to gre1 when
@@ -62,7 +62,7 @@ command defines the GRE subnet):
      network 172.16.0.0/16
      redistribute nhrp
    exit-address-family
-  
+
 
 .. _Configuring_NHRP:
 
@@ -91,7 +91,7 @@ This can be achieved with the following iptables rule.
   	-m hashlimit --hashlimit-upto 4/minute --hashlimit-burst 1 \\
   	--hashlimit-mode srcip,dstip --hashlimit-srcmask 24 --hashlimit-dstmask 24 \\
   	--hashlimit-name loglimit-0 -j NFLOG --nflog-group 1 --nflog-range 128
-  
+
 
 You can fine tune the src/dstmask according to the prefix lengths you
 announce internal, add additional IP range matches, or rate limitation
@@ -102,7 +102,7 @@ with:
 ::
 
   nhrp nflog-group 1
-  
+
 
 To start sending these traffic notices out from hubs, use the nhrp
 per-interface directive:
@@ -110,7 +110,7 @@ per-interface directive:
 
   interface gre1
    ip nhrp redirect
-  
+
 
 .. _Integration_with_IKE:
 
diff --git a/doc/user/ospf6d.rst b/doc/user/ospf6d.rst
index 4fbf5c0dd..651849d46 100644
--- a/doc/user/ospf6d.rst
+++ b/doc/user/ospf6d.rst
@@ -56,7 +56,7 @@ OSPF6 router
 
       router ospf6
        timers throttle spf 200 400 10000
-      
+
 
     In this example, the `delay` is set to 200ms, the @var{initial
     holdtime} is set to 400ms and the `maximum holdtime` to 10s. Hence
@@ -200,5 +200,5 @@ Example of ospf6d configured on one interface and area:
    area 0.0.0.0 range 2001:770:105:2::/64
    interface eth0 area 0.0.0.0
   !
-  
+
 
diff --git a/doc/user/ospf_fundamentals.rst b/doc/user/ospf_fundamentals.rst
index a9df639b2..8651ad028 100644
--- a/doc/user/ospf_fundamentals.rst
+++ b/doc/user/ospf_fundamentals.rst
@@ -9,7 +9,7 @@ OSPF Fundamentals
 
 :abbr:`OSPF` is, mostly, a link-state routing protocol. In contrast
 to :term:`distance-vector` protocols, such as :abbr:`RIP` or
-:abbr:`BGP`, where routers describe available :term:`paths` (i.e@. routes) 
+:abbr:`BGP`, where routers describe available :term:`paths` (i.e@. routes)
 to each other, in :term:`link-state` protocols routers instead
 describe the state of their links to their immediate neighbouring
 routers.
@@ -96,7 +96,7 @@ broadly classed as:
   The Hello protocol is comparatively trivial and will not be explored in
   greater detail than here.
 
-  .. index:: OSPF LSA overview 
+  .. index:: OSPF LSA overview
 
 
 *LSAs*
@@ -160,11 +160,11 @@ OSPF LSAs
 :abbr:`LSA`s are the core object in OSPF@. Everything else in OSPF
 revolves around detecting what to describe in LSAs, when to update
 them, how to flood them throughout a network and how to calculate
-routes from them. 
+routes from them.
 
 There are a variety of different :abbr:`LSA`s, for purposes such
 as describing actual link-state information, describing paths (i.e.
-routes), describing bandwidth usage of links for 
+routes), describing bandwidth usage of links for
 :abbr:`TE (Traffic Engineering)` purposes, and even arbitrary data
 by way of *Opaque* :abbr:`LSA`s.
 
@@ -232,7 +232,7 @@ Link-State LSAs
 Of all the various kinds of :abbr:`LSA`s, just two types comprise the
 actual link-state part of :abbr:`OSPF`, Router :abbr:`LSA`s and
 Network :abbr:`LSA`s. These LSA types are absolutely core to the
-protocol. 
+protocol.
 
 Instances of these LSAs are specific to the link-state area in which
 they are originated. Routes calculated from these two LSA types are
@@ -280,7 +280,7 @@ called :term:`intra-area routes`.
   * Point-to-Point
     @tab Router ID of the remote router
     @tab Local interface IP address,
-    or the :abbr:`ifindex (MIB-II interface index)` 
+    or the :abbr:`ifindex (MIB-II interface index)`
     for unnumbered links
 
   * Stub
@@ -327,7 +327,7 @@ Summary of Link State LSAs:
 @headitem LSA Type @tab LSA ID Describes @tab LSA Data Describes
 
 * Router LSA
-@tab The Router ID 
+@tab The Router ID
 @tab The :abbr:`OSPF` enabled links of the router, within
 a specific link-state area.
 
@@ -372,10 +372,10 @@ are fully adjacent with 192.168.0.49.
 
     LS age: 38
     Options: 0x2  : *|-|-|-|-|-|E|*
-    LS Flags: 0x6  
+    LS Flags: 0x6
     Flags: 0x2 : ASBR
     LS Type: router-LSA
-    Link State ID: 192.168.0.49 
+    Link State ID: 192.168.0.49
     Advertising Router: 192.168.0.49
     LS Seq Number: 80000f90
     Checksum: 0x518b
@@ -407,7 +407,7 @@ are fully adjacent with 192.168.0.49.
 
     LS age: 285
     Options: 0x2  : *|-|-|-|-|-|E|*
-    LS Flags: 0x6  
+    LS Flags: 0x6
     LS Type: network-LSA
     Link State ID: 192.168.0.49 (address of Designated Router)
     Advertising Router: 192.168.0.49
@@ -419,7 +419,7 @@ are fully adjacent with 192.168.0.49.
           Attached Router: 192.168.0.52
           Attached Router: 192.168.0.53
           Attached Router: 192.168.0.54
-  
+
 
 Note that from one LSA, you can find the other. E.g. Given the
 Network-LSA you have a list of Router IDs on that network, from which
@@ -460,7 +460,7 @@ following partial topology:
     |   Router ID: 192.168.0.53
     |
   Router ID: 192.168.0.52
-  
+
 
 Note the Router IDs, though they look like IP addresses and often are
 IP addresses, are not strictly speaking IP addresses, nor need they be
@@ -548,7 +548,7 @@ selected.
           Metric: 20
           Forward Address: 0.0.0.0
           External Route Tag: 0
-  
+
 
 We can add this to our partial topology from above, which now looks
 like:
@@ -574,12 +574,12 @@ like:
     |   Router ID: 192.168.0.53
     |
   Router ID: 192.168.0.52
-  
+
 
 Summary LSAs
 ^^^^^^^^^^^^
 
-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. 
+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.
 
 .. _OSPF_Flooding:
 
diff --git a/doc/user/ospfd.rst b/doc/user/ospfd.rst
index f2ba1fc6a..da46905e8 100644
--- a/doc/user/ospfd.rst
+++ b/doc/user/ospfd.rst
@@ -165,16 +165,16 @@ Command {no router ospf} {}
                 Events which occur within the holdtime of the previous SPF calculation
                 will cause the holdtime to be increased by `initial-holdtime`, bounded
                 by the `maximum-holdtime` configured with this command. If the adaptive
-                hold-time elapses without any SPF-triggering event occuring then 
+                hold-time elapses without any SPF-triggering event occuring then
                 the current holdtime is reset to the `initial-holdtime`. The current
-                holdtime can be viewed with :ref:`show_ip_ospf`, where it is expressed as 
+                holdtime can be viewed with :ref:`show_ip_ospf`, where it is expressed as
                 a multiplier of the `initial-holdtime`.
 
 ::
 
                   router ospf
                    timers throttle spf 200 400 10000
-                  
+
 
                 In this example, the `delay` is set to 200ms, the @var{initial
                 holdtime} is set to 400ms and the `maximum holdtime` to 10s. Hence
@@ -205,14 +205,14 @@ Command {no router ospf} {}
                     This support may be enabled administratively (and indefinitely) or
                     conditionally. Conditional enabling of max-metric router-lsas can be
                     for a period of seconds after startup and/or for a period of seconds
-                    prior to shutdown. 
+                    prior to shutdown.
 
                     Enabling this for a period after startup allows OSPF to converge fully
                     first without affecting any existing routes used by other routers,
                     while still allowing any connected stub links and/or redistributed
                     routes to be reachable. Enabling this for a period of time in advance
                     of shutdown allows the router to gracefully excuse itself from the OSPF
-                    domain. 
+                    domain.
 
                     Enabling this feature administratively allows for administrative
                     intervention for whatever reason, for an indefinite period of time.
@@ -266,7 +266,7 @@ Command {no router ospf} {}
 
                               router ospf
                                network 192.168.1.0/24 area 0.0.0.0
-                              
+
 
                             Prefix length in interface must be equal or bigger (ie. smaller network) than
                             prefix length in network statement. For example statement above doesn't enable
@@ -278,7 +278,7 @@ Command {no router ospf} {}
                             Currently, if a peer prefix has been configured,
                             then we test whether the prefix in the network command contains
                             the destination prefix.  Otherwise, we test whether the network command prefix
-                            contains the local address prefix of the interface. 
+                            contains the local address prefix of the interface.
 
                             In some cases it may be more convenient to enable OSPF on a per
                             interface/subnet basis (:ref:`OSPF_ip_ospf_area_command`).
@@ -313,7 +313,7 @@ OSPF area
            network 192.168.1.0/24 area 0.0.0.0
            network 10.0.0.0/8 area 0.0.0.10
            area 0.0.0.10 range 10.0.0.0/8
-          
+
 
         With configuration above one Type-3 Summary-LSA with routing info 10.0.0.0/8 is
         announced into backbone area if area 0.0.0.10 contains at least one intra-area
@@ -343,7 +343,7 @@ OSPF area
                network 192.168.1.0/24 area 0.0.0.0
                network 10.0.0.0/8 area 0.0.0.10
                area 0.0.0.10 range 10.0.0.0/8 substitute 11.0.0.0/8
-              
+
 
             One Type-3 summary-LSA with routing info 11.0.0.0/8 is announced into backbone area if
             area 0.0.0.10 contains at least one intra-area network (ie. described with router-LSA or
@@ -392,7 +392,7 @@ OSPF area
 
 {OSPF Command} {no area (0-4294967295) stub} {}
                               Configure the area to be a stub area. That is, an area where no router
-                              originates routes external to OSPF and hence an area where all external 
+                              originates routes external to OSPF and hence an area where all external
                               routes are via the ABR(s). Hence, ABRs for such an area do not need
                               to pass AS-External LSAs (type-5s) or ASBR-Summary LSAs (type-4) into the
                               area. They need only pass Network-Summary (type-3) LSAs into such an area,
@@ -410,7 +410,7 @@ OSPF area
 .. index:: {OSPF Command} {no area (0-4294967295) stub no-summary} {}
 
 {OSPF Command} {no area (0-4294967295) stub no-summary} {}
-                                    Prevents an *ospfd* ABR from injecting inter-area 
+                                    Prevents an *ospfd* ABR from injecting inter-area
                                     summaries into the specified stub area.
 
 .. index:: {OSPF Command} {area `a.b.c.d` default-cost (0-16777215)} {}
@@ -445,7 +445,7 @@ OSPF area
                                               !
                                               access-list foo permit 10.10.0.0/16
                                               access-list foo deny any
-                                              
+
 
                                             With example above any intra-area paths from area 0.0.0.10 and from range
                                             10.10.0.0/16 (for example 10.10.1.0/24 and 10.10.2.128/30) are announced into
@@ -533,7 +533,7 @@ OSPF area
 OSPF interface
 ==============
 
-.. index:: {Interface Command} {ip ospf area `AREA` [`ADDR`]} {} 
+.. index:: {Interface Command} {ip ospf area `AREA` [`ADDR`]} {}
 
 {Interface Command} {ip ospf area `AREA` [`ADDR`]} {}
 .. index:: {Interface Command} {no ip ospf area [`ADDR`]} {}
@@ -588,7 +588,7 @@ OSPF interface
         .. _ip_ospf_message-digest-key:
 
         Set OSPF authentication key to a
-        cryptographic password.  The cryptographic algorithm is MD5.  
+        cryptographic password.  The cryptographic algorithm is MD5.
 
         KEYID identifies secret key used to create the message digest. This ID
         is part of the protocol and must be consistent across routers on a
@@ -627,7 +627,7 @@ OSPF interface
               specifies how many Hellos to send per second, from 2 (every 500ms) to
               20 (every 50ms). Thus one can have 1s convergence time for OSPF. If this form
               is specified, then the hello-interval advertised in Hello packets is set to
-              0 and the hello-interval on received Hello packets is not checked, thus 
+              0 and the hello-interval on received Hello packets is not checked, thus
               the hello-multiplier need NOT be the same across multiple routers on a common
               link.
 
@@ -642,7 +642,7 @@ OSPF interface
                 This value must be the same for all routers attached to a common network.
                 The default value is 10 seconds.
 
-                This command has no effect if :ref:`ip_ospf_dead-interval_minimal` is also 
+                This command has no effect if :ref:`ip_ospf_dead-interval_minimal` is also
                 specified for the interface.
 
 .. index:: {Interface Command} {ip ospf network (broadcast|non-broadcast|point-to-multipoint|point-to-point)} {}
@@ -680,7 +680,7 @@ OSPF interface
 .. index:: {Interface Command} {no ip ospf transmit-delay} {}
 
 {Interface Command} {no ip ospf transmit-delay} {}
-                        Set number of seconds for InfTransDelay value.  LSAs' age should be 
+                        Set number of seconds for InfTransDelay value.  LSAs' age should be
                         incremented by this value when transmitting.
                         The default value is 1 seconds.
 
@@ -1127,7 +1127,7 @@ A simple example, with MD5 authentication enabled:
   router ospf
    network 192.168.0.0/16 area 0.0.0.1
    area 0.0.0.1 authentication message-digest
-  
+
 
 An :abbr:`ABR` router, with MD5 authentication and performing summarisation
 of networks between the areas:
@@ -1162,7 +1162,7 @@ of networks between the areas:
    area 0.0.0.1 authentication message-digest
    area 0.0.0.1 range 10.2.0.0/16
   !
-  
+
 
 A Traffic Engineering configuration, with Inter-ASv2 support.
 
@@ -1206,7 +1206,7 @@ A Traffic Engineering configuration, with Inter-ASv2 support.
    mpls-te link unrsv-bw 7 1.25e+06
    mpls-te link rsc-clsclr 0xab
    mpls-te neighbor 192.168.2.2 as 65000
-  
+
 
 - Then the 'ospfd.conf' itself:
 
@@ -1235,7 +1235,7 @@ A Traffic Engineering configuration, with Inter-ASv2 support.
     mpls-te inter-as area 1
   !
   line vty
-  
+
 
 A router information example with PCE advsertisement:
 
@@ -1256,5 +1256,5 @@ A router information example with PCE advsertisement:
     pce neighbor as 65200
     pce scope 0x80
   !
-  
+
 
diff --git a/doc/user/protocol.rst b/doc/user/protocol.rst
index 2dce4c985..475b9c69b 100644
--- a/doc/user/protocol.rst
+++ b/doc/user/protocol.rst
@@ -93,7 +93,7 @@ Zebra Protocol Commands
 
 @multitable {ZEBRA_REDISTRIBUTE_DEFAULT_DELETE_WHATEVER} {99999}
 @headitem Command @tab Value
-@item ZEBRA_INTERFACE_ADD	
+@item ZEBRA_INTERFACE_ADD
 @tab 1
 @item ZEBRA_INTERFACE_DELETE
 @tab 2
diff --git a/doc/user/ripd.rst b/doc/user/ripd.rst
index 505ac9251..e28d215c6 100644
--- a/doc/user/ripd.rst
+++ b/doc/user/ripd.rst
@@ -37,7 +37,7 @@ RIP is like below:
 
   # zebra -d
   # ripd -d
-  
+
 
 Please note that *zebra* must be invoked before *ripd*.
 
@@ -153,7 +153,7 @@ Command {no router rip} {}
          network 10.0.0.0/8
          network eth0
         !
-        
+
 
       Passive interface
 
@@ -167,7 +167,7 @@ Command {no router rip} {}
           interface, all receiving packets are processed as normal and ripd does
           not send either multicast or unicast RIP packets except to RIP neighbors
           specified with `neighbor` command. The interface may be specified
-          as `default` to make ripd default to passive on all interfaces. 
+          as `default` to make ripd default to passive on all interfaces.
 
           The default is to be passive on all interfaces.
 
@@ -204,7 +204,7 @@ RIPv1 see :ref:`RIP_Authentication`.
 
 {RIP Command} {version `version`} {}
   Set RIP version to accept for reads and send.  `version`
-  can be either `1'' or `2''. 
+  can be either `1'' or `2''.
 
   Disabling RIPv1 by specifying version 2 is STRONGLY encouraged,
   :ref:`RIP_Authentication`. This may become the default in a future
@@ -224,7 +224,7 @@ RIPv1 see :ref:`RIP_Authentication`.
 
   This interface command overrides the global rip version setting, and
   selects which version of RIP to send packets with, for this interface
-  specifically. Choice of RIP Version 1, RIP Version 2, or both versions. 
+  specifically. Choice of RIP Version 1, RIP Version 2, or both versions.
   In the latter case, where `1 2' is specified, packets will be both
   broadcast and multicast.
 
@@ -374,7 +374,7 @@ Command {distribute-list `access_list` `direct` `ifname`} {}
     access-list private permit 10 10.0.0.0/8
     access-list private deny any
     !
-    
+
 
 `distribute-list` can be applied to both incoming and outgoing data.
 
@@ -463,9 +463,9 @@ statement.
   redistribute static [route-map MAP_NAME]
   redistribute connected [route-map MAP_NAME]
   .....
-  
 
-Cisco applies route-map _before_ routes will exported to rip route table. 
+
+Cisco applies route-map _before_ routes will exported to rip route table.
 In current FRR's test implementation, *ripd* applies route-map
 after routes are listed in the route table and before routes will be
 announced to an interface (something like output filter). I think it is not
@@ -536,10 +536,10 @@ RIPv1 can not be authenticated at all, thus when authentication is
 configured `ripd` will discard routing updates received via RIPv1
 packets.
 
-However, unless RIPv1 reception is disabled entirely, 
+However, unless RIPv1 reception is disabled entirely,
 :ref:`RIP_Version_Control`, RIPv1 REQUEST packets which are received,
 which query the router for routing information, will still be honoured
-by `ripd`, and `ripd` WILL reply to such packets. This allows 
+by `ripd`, and `ripd` WILL reply to such packets. This allows
 `ripd` to honour such REQUESTs (which sometimes is used by old
 equipment and very simple devices to bootstrap their default route),
 while still providing security for route updates which are received.
@@ -596,7 +596,7 @@ To prevent such unauthenticated querying of routes disable RIPv1,
            ip rip authentication mode md5
            ip rip authentication key-chain test
           !
-          
+
 
 .. _RIP_Timers:
 
@@ -610,7 +610,7 @@ RIP Timers
   RIP protocol has several timers.  User can configure those timers' values
   by `timers basic` command.
 
-  The default settings for the timers are as follows: 
+  The default settings for the timers are as follows:
 
 
 ``
@@ -674,7 +674,7 @@ Command {show ip rip status} {}
     Incoming update filter list for all interface is not set
     Default redistribution metric is 1
     Redistributing: kernel connected
-    Default version control: send version 2, receive version 2 
+    Default version control: send version 2, receive version 2
       Interface        Send  Recv
     Routing for Networks:
       eth0
@@ -683,7 +683,7 @@ Command {show ip rip status} {}
       203.181.89.241
     Routing Information Sources:
       Gateway          BadPackets BadRoutes  Distance Last Update
-  
+
 
 RIP Debug Commands
 ==================
diff --git a/doc/user/ripngd.rst b/doc/user/ripngd.rst
index 07ce7175f..46b78eb19 100644
--- a/doc/user/ripngd.rst
+++ b/doc/user/ripngd.rst
@@ -89,5 +89,5 @@ Command {distribute-list `access_list` (in|out) `ifname`} {}
 ::
 
     distribute-list local-only out sit1
-    
+
 
diff --git a/doc/user/routemap.rst b/doc/user/routemap.rst
index 75864b5ed..e0507bcee 100644
--- a/doc/user/routemap.rst
+++ b/doc/user/routemap.rst
@@ -222,7 +222,7 @@ Route Map Set Command
 .. index:: {Route-map Command} {set local-preference `local_pref`} {}
 
 {Route-map Command} {set local-preference `local_pref`} {}
-  Set the BGP local preference to `local_pref`. 
+  Set the BGP local preference to `local_pref`.
 
 .. index:: {Route-map Command} {set weight `weight`} {}
 
@@ -298,7 +298,7 @@ A simple example of a route-map:
   route-map test permit 10
    match ip address 10
    set local-preference 200
-  
+
 
 This means that if a route matches ip access-list number 10 it's
 local-preference value is set to 200.
diff --git a/doc/user/rpki.rst b/doc/user/rpki.rst
index c4970fa9c..c1a62ea85 100644
--- a/doc/user/rpki.rst
+++ b/doc/user/rpki.rst
@@ -194,7 +194,7 @@ Validating BGP Updates
         route-map rpki permit 500
          match rpki valid
          set local-preference 500
-      
+
 
 
 .. _Debugging:
@@ -273,5 +273,5 @@ RPKI Configuration Example
   !
   route-map rpki permit 40
   !
-  
+
 
diff --git a/doc/user/snmp.rst b/doc/user/snmp.rst
index 5d60ade98..a315cc127 100644
--- a/doc/user/snmp.rst
+++ b/doc/user/snmp.rst
@@ -63,7 +63,7 @@ command will enable AgentX support.
   	!
   	agentx
   	!
-  
+
 
 Upon successful connection, you should get something like this in the
 log of each FRR daemons:
@@ -71,7 +71,7 @@ log of each FRR daemons:
 ::
 
   2012/05/25 11:39:08 ZEBRA: snmp[info]: NET-SNMP version 5.4.3 AgentX subagent connected
-  
+
 
 Then, you can use the following command to check everything works as expected:
 
@@ -80,7 +80,7 @@ Then, you can use the following command to check everything works as expected:
   # snmpwalk -c public -v1 localhost .1.3.6.1.2.1.14.1.1
   OSPF-MIB::ospfRouterId.0 = IpAddress: 192.168.42.109
   [...]
-  
+
 
 The AgentX protocol can be transported over a Unix socket or using TCP
 or UDP. It usually defaults to a Unix socket and depends on how NetSNMP
@@ -93,7 +93,7 @@ configure it through `/etc/snmp/frr.conf`:
   	[snmpd]
   	# Use a remote master agent
   	agentXSocket tcp:192.168.15.12:705
-  
+
 
 .. _SMUX_configuration:
 
@@ -134,20 +134,20 @@ restrictions can be hard to debug.
   	!
   	smux peer .1.3.6.1.4.1.3317.1.2.5 frr_ospfd
   	!
-  
+
 
 After restarting snmpd and frr, a successful connection can be verified in
 the syslog and by querying the SNMP daemon:
 
 ::
 
-  snmpd[12300]: [smux_accept] accepted fd 12 from 127.0.0.1:36255 
+  snmpd[12300]: [smux_accept] accepted fd 12 from 127.0.0.1:36255
   snmpd[12300]: accepted smux peer: \\
   	oid GNOME-PRODUCT-ZEBRA-MIB::ospfd, frr-0.96.5
 
   # snmpwalk -c public -v1 localhost .1.3.6.1.2.1.14.1.1
   OSPF-MIB::ospfRouterId.0 = IpAddress: 192.168.42.109
-  
+
 
 Be warned that the current version (5.1.1) of the Net-SNMP daemon writes a line
 for every SNMP connect to the syslog which can lead to enormous log file sizes.
@@ -168,7 +168,7 @@ the FRR daemons with SMUX only.
   ripd	.1.3.6.1.4.1.3317.1.2.3 .gnome.gnomeProducts.zebra.ripd
   ospfd	.1.3.6.1.4.1.3317.1.2.5 .gnome.gnomeProducts.zebra.ospfd
   ospf6d	.1.3.6.1.4.1.3317.1.2.6 .gnome.gnomeProducts.zebra.ospf6d
-  
+
 
 Sadly, SNMP has not been implemented in all daemons yet. The following
 OID numbers are used for querying the SNMP daemon by a client:
@@ -176,10 +176,10 @@ OID numbers are used for querying the SNMP daemon by a client:
 
   zebra	.1.3.6.1.2.1.4.24   .iso.org.dot.internet.mgmt.mib-2.ip.ipForward
   ospfd	.1.3.6.1.2.1.14	    .iso.org.dot.internet.mgmt.mib-2.ospf
-  bgpd	.1.3.6.1.2.1.15	    .iso.org.dot.internet.mgmt.mib-2.bgp 
+  bgpd	.1.3.6.1.2.1.15	    .iso.org.dot.internet.mgmt.mib-2.bgp
   ripd	.1.3.6.1.2.1.23	    .iso.org.dot.internet.mgmt.mib-2.rip2
   ospf6d	.1.3.6.1.3.102	    .iso.org.dod.internet.experimental.ospfv3
-  
+
 
 The following syntax is understood by the FRR daemons for configuring SNMP using SMUX:
 .. index:: {Command} {smux peer `oid`} {}
diff --git a/doc/user/snmptrap.rst b/doc/user/snmptrap.rst
index 7ca94ff32..dccff057d 100644
--- a/doc/user/snmptrap.rst
+++ b/doc/user/snmptrap.rst
@@ -16,7 +16,7 @@ your trapsink by adding the following lines to :file:`/etc/snmpd/snmpd.conf`:
 
     # send traps to the snmptrapd on localhost
     trapsink localhost
-  
+
 
 This will send all traps to an snmptrapd running on localhost. You can
 of course also use a dedicated management station to catch traps.
@@ -26,7 +26,7 @@ Configure the snmptrapd daemon by adding the following line to
 ::
 
     traphandle .1.3.6.1.4.1.3317.1.2.2 /etc/snmp/snmptrap_handle.sh
-  
+
 
 This will use the bash script :file:`/etc/snmp/snmptrap_handle.sh` to handle
 the BGP4 traps. To add traps for other protocol daemons, lookup their
@@ -111,7 +111,7 @@ case "$suberrorcode" in
 *) suberror="Unknown" ;;
 esac
 ;;
-02)    
+02)
 error="OPEN Message Error"
 case "$suberrorcode" in
 01) suberror="Unsupported Version Number" ;;
diff --git a/doc/user/vnc.rst b/doc/user/vnc.rst
index 8f675310b..78366713b 100644
--- a/doc/user/vnc.rst
+++ b/doc/user/vnc.rst
@@ -6,11 +6,11 @@ VNC and VNC-GW
 
 This chapter describes how to use
 Virtual Network Control (:abbr:`VNC`) services,
-including Network Virtualization Authority (:abbr:`NVA`) and 
+including Network Virtualization Authority (:abbr:`NVA`) and
 VNC Gateway (:abbr:`VNC-GW`) functions.
-Background information on NVAs, 
+Background information on NVAs,
 Network Virtualization Edges (:abbr:`NVE`s), underlay networks (:abbr:`UN`s),
-and virtual networks (:abbr:`VN`s) is available from the  
+and virtual networks (:abbr:`VN`s) is available from the
 `IETF Network Virtualization Overlays <https://datatracker.ietf.org/wg/nvo3>`_
 VNC Gateways (:abbr:`VNC-GW`s) support the import/export of routing
 information between VNC and customer edge routers (:abbr:`CE`s)
@@ -48,14 +48,14 @@ the following areas:
 
 `General VNC` configuration applies to general VNC operation and is
 primarily used to control the method used to advertise tunnel
-information.  
+information.
 
 `Remote Forwarder Protocol (RFP)` configuration relates to the
-protocol used between NVAs and NVEs.  
+protocol used between NVAs and NVEs.
 
 `VNC Defaults` provides default parameters for registered NVEs.
 
-`VNC NVE Group` provides for configuration of a specific set of 
+`VNC NVE Group` provides for configuration of a specific set of
 registered NVEs and overrides default parameters.
 
 `Redistribution` and `Export` control VNC-GW operation, i.e.,
@@ -73,9 +73,9 @@ General VNC Configuration
 {VNC} {vnc advertise-un-method encap-safi|encap-attr} {}
   Advertise NVE underlay-network IP addresses using the encapsulation SAFI
   (`encap-safi`) or the UN address sub-TLV of the Tunnel Encapsulation attribute
-  (`encap-attr`). When `encap-safi` is used, neighbors under 
+  (`encap-attr`). When `encap-safi` is used, neighbors under
   `address-family encap` and/or `address-family encapv6` must be
-  configured.  The default is `encap-attr`. 
+  configured.  The default is `encap-attr`.
 
 .. _RFP_Related_Configuration:
 
@@ -88,9 +88,9 @@ Remote Forwarder Protocol (RFP).  Currently, only a simple example RFP
 is included in FRR.  Developers may use this example as a starting
 point to integrate FRR with an RFP of their choosing, e.g.,
 `OpenFlow`.  The example code includes the following sample
-configuration: 
+configuration:
 
-.. index:: {RFP} {rfp example-config-value `VALUE`} 
+.. index:: {RFP} {rfp example-config-value `VALUE`}
 
 {RFP} {rfp example-config-value `VALUE`}
   This is a simple example configuration parameter included as part of the
@@ -103,7 +103,7 @@ VNC Defaults Configuration
 
 The VNC Defaults section allows the user to specify default values for
 configuration parameters for all registered NVEs.
-Default values are overridden by :ref:`VNC_NVE_Group_Configuration`. 
+Default values are overridden by :ref:`VNC_NVE_Group_Configuration`.
 
 .. index:: {VNC} {vnc defaults} {}
 
@@ -116,7 +116,7 @@ Default values are overridden by :ref:`VNC_NVE_Group_Configuration`.
     vnc defaults
       ... various VNC defaults
     exit-vnc
-    
+
 
 These are the statements that can appear between `vnc defaults`
 and `exit-vnc`.
@@ -230,7 +230,7 @@ prefixes specified in the NVE Group definition.  When an NVE Group
 definition specifies both VN and UN address prefixes, then an NVE must
 match both prefixes in order to be assigned to the NVE Group.  In the
 event that multiple NVE Groups match based on VN and/or UN addresses,
-the NVE is assigned to the first NVE Group listed in the configuration.  
+the NVE is assigned to the first NVE Group listed in the configuration.
 If an NVE is not assigned to an NVE Group, its messages will be ignored.
 
 Configuration values specified for an NVE group apply to all
@@ -243,7 +243,7 @@ operation.}
 .. index:: {VNC} {vnc nve-group `name`} {}
 
 {VNC} {vnc nve-group `name`} {}
-  Enter VNC configuration mode for defining the NVE group `name`.  
+  Enter VNC configuration mode for defining the NVE group `name`.
   Use `exit` or `exit-vnc` to exit group configuration mode.
 
 ::
@@ -251,7 +251,7 @@ operation.}
     vnc nve-group group1
       ... configuration commands
     exit-vnc
-    
+
 
 .. index:: {VNC} {no vnc nve-group `name`} {}
 
@@ -307,7 +307,7 @@ auto:vn:`two-byte-integer`
 
   Routes originated by NVEs in the NVE group will use
   the group's specified `route-distinguisher` when they are
-  advertised via BGP. 
+  advertised via BGP.
   If the `auto` form is specified, it means that a matching NVE has
   its RD set to
   `rd_type=IP=1`:`IPv4-address=VN-address`:`two-byte-integer`,
@@ -359,7 +359,7 @@ auto:vn:`two-byte-integer`
 
       The first form, `rt export`, specifies an `export rt-list`.
       The `export rt-list` will be attached to routes originated by
-      NVEs in the NVE group when they are advertised via BGP. 
+      NVEs in the NVE group when they are advertised via BGP.
       If the NVE group definition does not specify an `export rt-list`,
       then the default `export rt-list` is used.
       If neither a group nor a default `export rt-list` is configured,
@@ -388,8 +388,8 @@ auto:vn:`two-byte-integer`
 
 {VNC} {export bgp|zebra route-map MAP-NAME}
       Specify that the named route-map should be applied to routes
-      being exported to bgp or zebra. 
-      This paramter is used in conjunction with 
+      being exported to bgp or zebra.
+      This paramter is used in conjunction with
       :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`.
       This item is optional.
 
@@ -397,8 +397,8 @@ auto:vn:`two-byte-integer`
 
 {VNC} {export bgp|zebra no route-map}
       Specify that no route-map should be applied to routes
-      being exported to bgp or zebra. 
-      This paramter is used in conjunction with 
+      being exported to bgp or zebra.
+      This paramter is used in conjunction with
       :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`.
       This item is optional.
 
@@ -407,8 +407,8 @@ auto:vn:`two-byte-integer`
 {VNC} {export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME}
       Specify that the named prefix-list filter should be applied to
       routes being exported to bgp or zebra.
-      Prefix-lists for ipv4 and ipv6 are independent of each other. 
-      This paramter is used in conjunction with 
+      Prefix-lists for ipv4 and ipv6 are independent of each other.
+      This paramter is used in conjunction with
       :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`.
       This item is optional.
 
@@ -416,8 +416,8 @@ auto:vn:`two-byte-integer`
 
 {VNC} {export bgp|zebra no ipv4|ipv6 prefix-list}
       Specify that no prefix-list filter should be applied to
-      routes being exported to bgp or zebra. 
-      This paramter is used in conjunction with 
+      routes being exported to bgp or zebra.
+      This paramter is used in conjunction with
       :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`.
       This item is optional.
 
@@ -444,7 +444,7 @@ not impacted by L2 Group Configuration.
 .. index:: {VNC} {vnc l2-group `name`} {}
 
 {VNC} {vnc l2-group `name`} {}
-  Enter VNC configuration mode for defining the L2 group `name`.  
+  Enter VNC configuration mode for defining the L2 group `name`.
   Use `exit` or `exit-vnc` to exit group configuration mode.
 
 ::
@@ -452,7 +452,7 @@ not impacted by L2 Group Configuration.
     vnc l2-group group1
       ... configuration commands
     exit-vnc
-    
+
 
 .. index:: {VNC} {no vnc l2-group `name`} {}
 
@@ -465,7 +465,7 @@ The following statements are valid in a L2 group definition:
 
 {VNC} {logical-network-id `VALUE`}
   Define the Logical Network Identifier with a value in the range of
-  0-4294967295 that identifies the logical Ethernet segment. 
+  0-4294967295 that identifies the logical Ethernet segment.
 
 .. index:: {VNC} {labels `label-list`}
 
@@ -537,16 +537,16 @@ In `plain` mode, the route's next hop is unchanged and the RD is set
 based on the next hop.
 For `bgp-direct` redistribution, the following translations are performed:
 
-* 
+*
   The VN address is set to the original unicast route's next hop address.
-* 
+*
   The UN address is NOT set. (VN->UN mapping will occur via
   ENCAP route or attribute, based on `vnc advertise-un-method`
-  setting, generated by the RFP registration of the actual NVE) 
-* 
+  setting, generated by the RFP registration of the actual NVE)
+*
   The RD is set to as if auto:vn:0 were specified (i.e.,
   `rd_type=IP=1`:`IPv4-address=VN-address`:`two-byte-integer=0`)
-* 
+*
   The RT list is included in the extended community list copied from the
   original unicast route (i.e., it must be set in the original unicast route).
 
@@ -555,17 +555,17 @@ if they came from an NVE in the nve-group designated in the
 `vnc redistribute nve-group` command. The following
 translations are performed:
 
-* 
+*
   The next hop/VN address is set to the VN prefix configured for the
   redistribute nve-group.
-* 
+*
   The UN address is set to the UN prefix configured for the
   redistribute nve-group.
-* 
+*
   The RD is set to the RD configured for the redistribute nve-group.
-* 
+*
   The RT list is set to the RT list configured for the redistribute nve-group.
-  If `bgp-direct` routes are being redistributed, 
+  If `bgp-direct` routes are being redistributed,
   any extended communities present in the original unicast route
   will also be included.
 
@@ -590,26 +590,26 @@ route, no corresponding VNC route will be imported.
 
 The following translations are applied:
 
-* 
+*
   The Next Hop is set to the next hop of the NVE route (i.e., the
   VN address of the NVE).
 
-* 
-  The extended community list in the new route is set to the 
+*
+  The extended community list in the new route is set to the
   union of:
 
-  * 
+  *
     Any extended communities in the original BGP route
-  * 
+  *
     Any extended communities in the NVE route
-  * 
+  *
     An added route-origin extended community with the next hop of the
     original BGP route
     is added to the new route.
     The value of the local administrator field defaults 5226 but may
     be configured by the user via the `roo-ec-local-admin` parameter.
 
-* 
+*
   The Tunnel Encapsulation attribute is set to the value of the Tunnel
   Encapsulation attribute of the NVE route, if any.
 
@@ -631,7 +631,7 @@ In order for a route in the unicast BGP RIB to be made
 available to a querying NVE, there must already be, available to
 that NVE, an (interior) VNC route matching the next hop address
 of the unicast route.
-When the unicast route is provided to the NVE, its next hop 
+When the unicast route is provided to the NVE, its next hop
 is replaced by the next hop of the corresponding
 NVE. If there are multiple longest-prefix-match VNC routes,
 the unicast route will be replicated for each.
@@ -692,13 +692,13 @@ Redistribution Command Syntax
         `infinite`, to prefixes redistributed from other routing
         protocols as if they had been received via RFP registration messages
         from an NVE.  `lifetime` can be any integer between 1 and
-        4294967295, inclusive. 
+        4294967295, inclusive.
 
 .. index:: {VNC} {vnc redistribute resolve-nve roo-ec-local-admin `0-65536`}
 
 {VNC} {vnc redistribute resolve-nve roo-ec-local-admin `0-65536`}
         Assign a value to the local-administrator subfield used in the
-        Route Origin extended community that is assigned to routes exported 
+        Route Origin extended community that is assigned to routes exported
         under the `resolve-nve` mode. The default value is `5226`.
 
       The following four `prefix-list` and `route-map` commands
@@ -884,7 +884,7 @@ information.
   preference of the forwarding information.  If omitted, it defaults to
   255.  The `lifetime` parameter identifies the period, in seconds,
   that the information remains valid.  If omitted, it defaults to
-  `infinite`. 
+  `infinite`.
 
 .. index:: {Command} {clear vnc prefix (*|A.B.C.D/M|X:X::X:X/M) (*|[(vn|un) (A.B.C.D|X:X::X:X|*) [(un|vn) (A.B.C.D|X:X::X:X|*)] [mac xx:xx:xx:xx:xx:xx] [local-next-hop (A.B.C.D|X:X::X:X)])} {}
 
@@ -922,7 +922,7 @@ Other VNC-Related Commands
 
 Note: VNC-Related configuration can be obtained via the `show running-configuration` command when in `enable` mode.
 
-The following commands are used to clear and display 
+The following commands are used to clear and display
 Virtual Network Control related information:
 
 .. index:: {COMMAND} {clear vnc counters} {}
@@ -935,8 +935,8 @@ Virtual Network Control related information:
 .. index:: {Command} {show vnc summary} {}
 
 {Command} {show vnc summary} {}
-  Print counter values and other general information 
-  about the NVA. Counter values can be reset 
+  Print counter values and other general information
+  about the NVA. Counter values can be reset
   using the `clear vnc counters` command listed below.
 
 .. index:: {Command} {show vnc nves} {}
diff --git a/doc/user/zebra.rst b/doc/user/zebra.rst
index 3d448f6c8..ab60857bc 100644
--- a/doc/user/zebra.rst
+++ b/doc/user/zebra.rst
@@ -233,7 +233,7 @@ Command {ip route `network` `gateway`} {}
     ip route 10.0.0.0/8 10.0.0.2
     ip route 10.0.0.0/8 ppp0
     ip route 10.0.0.0/8 null0
-    
+
 
   First example defines 10.0.0.0/8 static route with gateway 10.0.0.2.
   Second one defines the same prefix but with gateway to interface ppp0. The
@@ -251,7 +251,7 @@ Command {ip route `network` `netmask` `gateway`} {}
     ip route 10.0.0.0 255.255.255.0 10.0.0.2
     ip route 10.0.0.0 255.255.255.0 ppp0
     ip route 10.0.0.0 255.255.255.0 null0
-    
+
 
   These statements are equivalent to those in the previous example.
 
@@ -267,7 +267,7 @@ Multiple nexthop static route
   ip route 10.0.0.1/32 10.0.0.2
   ip route 10.0.0.1/32 10.0.0.3
   ip route 10.0.0.1/32 eth0
-  
+
 
 If there is no route to 10.0.0.2 and 10.0.0.3, and interface eth0
 is reachable, then the last route is installed into the kernel.
@@ -282,14 +282,14 @@ nexthops, if the platform supports this.
   S>  10.0.0.1/32 [1/0] via 10.0.0.2 inactive
                         via 10.0.0.3 inactive
     *                   is directly connected, eth0
-  
+
 
 ::
 
   ip route 10.0.0.0/8 10.0.0.2
   ip route 10.0.0.0/8 10.0.0.3
   ip route 10.0.0.0/8 null0 255
-  
+
 
 This will install a multihop route via the specified next-hops if they are
 reachable, as well as a high-metric blackhole route, which can be useful to
@@ -307,7 +307,7 @@ default) should the specified gateways not be reachable. Eg:
   Routing entry for 10.0.0.0/8
     Known via "static", distance 255, metric 0
       directly connected, Null0
-  
+
 
 .. index:: Command {ipv6 route `network` `gateway`} {}
 
@@ -406,7 +406,7 @@ Command {show ip rpf `addr`} {}
       Routing entry for 192.0.2.0/24 using Unicast RIB
         Known via "kernel", distance 0, metric 0, best
         * 198.51.100.1, via eth0
-      
+
 
     Indicates that a multicast source lookup for 192.0.2.1 would use an
     Unicast RIB entry for 192.0.2.0/24 with a gateway of 198.51.100.1.
@@ -473,7 +473,7 @@ Command {ip protocol `protocol` route-map `routemap`} {}
        set src 10.0.0.1
 
   ip protocol rip route-map RM1
-  
+
 
 .. _zebra_FIB_push_interface:
 
@@ -527,11 +527,11 @@ schema. Protobuf messages can be extended easily while maintaining
 backward-compatibility with older code. Protobuf has the following
 advantages over netlink:
 
-* 
+*
   Code for serialization/deserialization is generated
   automatically. This reduces the likelihood of bugs, allows third-party
   programs to be integrated quickly, and makes it easy to add fields.
-* 
+*
   The message format is not tied to an OS (Linux), and can be evolved
   independently.
 
@@ -566,7 +566,7 @@ Command {show ip route} {}
     S  0.0.0.0/0              203.181.89.1
     C* 127.0.0.0/8            lo
     C* 203.181.89.240/28      eth0
-    
+
 
 .. index:: Command {show ipv6 route} {}