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.
``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]
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
.. 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
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.
+.. _Kernel_Interface:
+
****************
Kernel Interface
****************
*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.
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
::
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:
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.
::
*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.
*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:
**
- 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.
*deny*
**
- The route is denied by the route-map (return @samp{deny}).
+ The route is denied by the route-map (return ``deny``).
*cont*
{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:
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.
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`:
projects / mirror / frr.git / commitdiff