From: Quentin Young Date: Fri, 26 Jan 2018 18:50:36 +0000 (-0500) Subject: doc: @smp{foo} -> ``foo`` X-Git-Tag: frr-5.0-dev~165^2~76 X-Git-Url: https://git.puffer.fish/?a=commitdiff_plain;h=8fa64b2a3fa554e261ad49892515410a14c3baf0;p=mirror%2Ffrr.git doc: @smp{foo} -> ``foo`` Signed-off-by: Quentin Young --- diff --git a/doc/user/babeld.rst b/doc/user/babeld.rst index 72d8531e31..fd96fea40a 100644 --- a/doc/user/babeld.rst +++ b/doc/user/babeld.rst @@ -131,8 +131,8 @@ Babel configuration assumed to interfere with all other channels except noninterfering channels, and interfaces with a channel number interfere with interfering interfaces and interfaces with the same channel number. - The default is @samp{babel channel interfering} for wireless - interfaces, and @samp{babel channel noninterfering} for wired + The default is ``babel channel interfering`` for wireless + interfaces, and ``babel channel noninterfering`` for wired interfaces. This is reset when the wired/wireless status of an interface is changed. diff --git a/doc/user/bgp.rst b/doc/user/bgp.rst index ccc3192bab..485f60e759 100644 --- a/doc/user/bgp.rst +++ b/doc/user/bgp.rst @@ -891,7 +891,7 @@ Peer filtering ``neighbor `peer` distribute-list `name` [in|out]`` This command specifies a distribute-list for the peer. `direct` is - @samp{in} or @samp{out}. + ``in`` or ``out``. .. index:: neighbor PEER prefix-list NAME [in|out] @@ -1889,7 +1889,7 @@ Route Server At an Internet Exchange point, many ISPs are connected to each other by external BGP peering. Normally these external BGP connection are done by -@samp{full mesh} method. As with internal BGP full mesh formation, +``full mesh`` method. As with internal BGP full mesh formation, this method has a scaling problem. This scaling problem is well known. Route Server is a method to resolve diff --git a/doc/user/installation.rst b/doc/user/installation.rst index 70d1a7c5b1..4fd916c475 100644 --- a/doc/user/installation.rst +++ b/doc/user/installation.rst @@ -233,11 +233,10 @@ Linux Notes .. index:: Linux configurations -There are several options available only to GNU/Linux systems: -@footnote{GNU/Linux has very flexible kernel configuration features}. If -you use GNU/Linux, make sure that the current kernel configuration is -what you want. FRR will run with any kernel configuration but some -recommendations do exist. +There are several options available only to GNU/Linux systems [#]_. +If you use GNU/Linux, make sure that the current kernel configuration is what +you want. FRR will run with any kernel configuration but some recommendations +do exist. - CONFIG_NETLINK @@ -332,3 +331,4 @@ needed. You may need to make changes to the config files in |INSTALL_PREFIX_ETC|. :ref:`Config_Commands`. +.. [#] GNU/Linux has very flexible kernel configuration features. diff --git a/doc/user/kernel.rst b/doc/user/kernel.rst index 4161c4ae94..a11b3ef167 100644 --- a/doc/user/kernel.rst +++ b/doc/user/kernel.rst @@ -1,3 +1,5 @@ +.. _Kernel_Interface: + **************** Kernel Interface **************** @@ -9,24 +11,24 @@ interfaces. *ioctl* - The @samp{ioctl} method is a very traditional way for reading or writing - kernel information. @samp{ioctl} can be used for looking up interfaces + The ``ioctl`` method is a very traditional way for reading or writing + kernel information. ``ioctl`` can be used for looking up interfaces and for modifying interface addresses, flags, mtu settings and other - types of information. Also, @samp{ioctl} can insert and delete kernel + types of information. Also, ``ioctl`` can insert and delete kernel routing table entries. It will soon be available on almost any platform which zebra supports, but it is a little bit ugly thus far, so if a better method is supported by the kernel, zebra will use that. *sysctl* - @samp{sysctl} can lookup kernel information using MIB (Management + ``sysctl`` can lookup kernel information using MIB (Management Information Base) syntax. Normally, it only provides a way of getting information from the kernel. So one would usually want to change kernel - information using another method such as @samp{ioctl}. + information using another method such as ``ioctl``. *proc filesystem* - @samp{proc filesystem} provides an easy way of getting kernel + ``proc filesystem`` provides an easy way of getting kernel information. diff --git a/doc/user/ripd.rst b/doc/user/ripd.rst index 201ea7ce19..504ff15185 100644 --- a/doc/user/ripd.rst +++ b/doc/user/ripd.rst @@ -359,14 +359,14 @@ RIP routes can be filtered by a distribute-list. Command {distribute-list `access_list` `direct` `ifname`} {} You can apply access lists to the interface with a `distribute-list` command. `access_list` is the access list name. `direct` is - @samp{in} or @samp{out}. If `direct` is @samp{in} the access list + ``in`` or ``out``. If `direct` is ``in`` the access list is applied to input packets. The `distribute-list` command can be used to filter the RIP path. `distribute-list` can apply access-lists to a chosen interface. First, one should specify the access-list. Next, the name of the access-list is used in the distribute-list command. For example, in the - following configuration @samp{eth0} will permit only the paths that + following configuration ``eth0`` will permit only the paths that match the route 10.0.0.0/8 :: @@ -387,8 +387,8 @@ Command {distribute-list `access_list` `direct` `ifname`} {} Command {distribute-list prefix `prefix_list` (in|out) `ifname`} {} You can apply prefix lists to the interface with a `distribute-list` command. `prefix_list` is the prefix list - name. Next is the direction of @samp{in} or @samp{out}. If - `direct` is @samp{in} the access list is applied to input packets. + name. Next is the direction of ``in`` or ``out``. If + `direct` is ``in`` the access list is applied to input packets. .. _RIP_Metric_Manipulation: diff --git a/doc/user/ripngd.rst b/doc/user/ripngd.rst index 2c4bfa2c35..07ce7175fc 100644 --- a/doc/user/ripngd.rst +++ b/doc/user/ripngd.rst @@ -83,8 +83,8 @@ ripngd Filtering Commands Command {distribute-list `access_list` (in|out) `ifname`} {} You can apply an access-list to the interface using the `distribute-list` command. `access_list` is an access-list - name. `direct` is @samp{in} or @samp{out}. If `direct` is - @samp{in}, the access-list is applied only to incoming packets. + name. `direct` is ``in`` or ``out``. If `direct` is + ``in``, the access-list is applied only to incoming packets. :: diff --git a/doc/user/routemap.rst b/doc/user/routemap.rst index 7ec3fcaf4f..75864b5edf 100644 --- a/doc/user/routemap.rst +++ b/doc/user/routemap.rst @@ -13,22 +13,22 @@ specify up to four distincts sets of clauses: *Matching Policy* - This specifies the policy implied if the @samp{Matching Conditions} are + 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: ** - @samp{permit}: If the entry matches, then carry out the @samp{Set + ``permit``: If the entry matches, then carry out the @samp{Set Actions}. Then finish processing the route-map, permitting the route, - unless an @samp{Exit Action} indicates otherwise. + unless an ``Exit Action`` indicates otherwise. ** - @samp{deny}: If the entry matches, then finish processing the route-map and - deny the route (return @samp{deny}). + ``deny``: If the entry matches, then finish processing the route-map and + deny the route (return ``deny``). - The @samp{Matching Policy} is specified as part of the command which + The ``Matching Policy`` is specified as part of the command which defines the ordered entry in the route-map. See below. @@ -45,32 +45,32 @@ specify up to four distincts sets of clauses: *Call Action* - Call to another route-map, after any @samp{Set Actions} have been - carried out. If the route-map called returns @samp{deny} then + 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 @samp{Matching Policy} or the @samp{Exit Policy}. If - the called route-map returns @samp{permit}, then @samp{Matching Policy} - and @samp{Exit Policy} govern further behaviour, as normal. + 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. *Exit Policy* - An entry may, optionally, specify an alternative @samp{Exit Policy} to + 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: ** - @samp{next}: Continue on with processing of the route-map entries. + ``next``: Continue on with processing of the route-map entries. ** - @samp{goto N}: Jump ahead to the first route-map entry whose order in + ``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 @samp{deny} +I.e. a route-map essentially has as its last entry an empty ``deny`` entry, which matches all routes. To change this behaviour, one must -specify an empty @samp{permit} entry as the last entry in the route-map. +specify an empty ``permit`` entry as the last entry in the route-map. To summarise the above: @@ -89,16 +89,16 @@ To summarise the above: ** - If *call* is present, call given route-map. If that returns a @samp{deny}, finish - processing and return @samp{deny}. + If *call* is present, call given route-map. If that returns a ``deny``, finish + processing and return ``deny``. ** - If @samp{Exit Policy} is *next*, goto next route-map entry + If ``Exit Policy`` is *next*, goto next route-map entry ** - If @samp{Exit Policy} is *goto*, goto first entry whose order in the list + If ``Exit Policy`` is *goto*, goto first entry whose order in the list is >= the given order. @@ -109,7 +109,7 @@ To summarise the above: *deny* ** - The route is denied by the route-map (return @samp{deny}). + The route is denied by the route-map (return ``deny``). *cont* @@ -127,7 +127,7 @@ Route Map Command {Command} {route-map `route-map-name` (permit|deny) `order`} {} Configure the `order`'th entry in `route-map-name` with - @samp{Match Policy} of either *permit* or *deny*. + ``Match Policy`` of either *permit* or *deny*. .. _Route_Map_Match_Command: @@ -304,5 +304,5 @@ This means that if a route matches ip access-list number 10 it's local-preference value is set to 200. See :ref:`BGP_Configuration_Examples` for examples of more sophisticated -useage of route-maps, including of the @samp{call} action. +useage of route-maps, including of the ``call`` action. diff --git a/doc/user/snmptrap.rst b/doc/user/snmptrap.rst index 70d5bcdc2f..9c6cb05b89 100644 --- a/doc/user/snmptrap.rst +++ b/doc/user/snmptrap.rst @@ -7,7 +7,7 @@ correctly as described in the frr documentation in :ref:`SNMP_Support`. The BGP4 mib will send traps on peer up/down events. These should be visible in your snmp logs with a message similar to: -@samp{snmpd[13733]: Got trap from peer on fd 14} +``snmpd[13733]: Got trap from peer on fd 14`` To react on these traps they should be handled by a trapsink. Configure your trapsink by adding the following lines to :file:`/etc/snmpd/snmpd.conf`: