proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-08-12 05:21:45 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

doc: manually finish conversion

Browse Source 
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This commit is contained in:
Quentin Young 2018-01-29 16:38:07 -05:00
parent d1a242fdbf
commit c1a54c054d
No known key found for this signature in database
GPG Key ID: DAF48E0F57E0834F
20 changed files with 4615 additions and 4984 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
doc/user/appendix.rst
View File

@ -1,11 +1,12 @@
.. _packet-binary-dump-format:
Packet Binary Dump Format
=========================
Packet Binary Dump Format
-------------------------
FRR can dump routing protocol packet into file with a binary format
(@pxref{Dump BGP packets and table}).
FRR can dump routing protocol packet into file with a binary format.
It seems to be better that we share the MRT's header format for
backward compatibility with MRT's dump logs. We should also define the

2710
doc/user/bgp.rst
View File

File diff suppressed because it is too large Load Diff

157
doc/user/eigrpd.rst
View File

@ -18,16 +18,14 @@ known topology.
Starting and Stopping eigrpd
============================
The default configuration file name of *eigrpd*'s is
:file:`eigrpd.conf`. When invocation *eigrpd* searches directory
|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
The default configuration file name of *eigrpd*'s is :file:`eigrpd.conf`. When
invocation *eigrpd* searches directory |INSTALL_PREFIX_ETC|. If
:file:`eigrpd.conf` is not there next search current directory. If an
integrated config is specified configuration is written into :file:`frr.conf`.
The EIGRP protocol requires interface information
maintained by *zebra* daemon. So running *zebra*
is mandatory to run *eigrpd*. Thus minimum sequence for running
EIGRP is like below:
The EIGRP protocol requires interface information maintained by *zebra* daemon.
So running *zebra* is mandatory to run *eigrpd*. Thus minimum sequence for
running EIGRP is:
::
@ -37,8 +35,10 @@ EIGRP is like below:
Please note that *zebra* must be invoked before *eigrpd*.
To stop *eigrpd*. Please use @command{kill `cat
/var/run/eigrpd.pid`}. Certain signals have special meanings to *eigrpd*.
To stop *eigrpd*, please use ::
kill `cat /var/run/eigrpd.pid`
Certain signals have special meanings to *eigrpd*.
+------------------+-----------------------------------------------------------+
| Signal | Meaning |
@ -65,23 +65,23 @@ EIGRP Configuration
===================
.. index:: router eigrp (1-65535)
.. clicmd:: router eigrp (1-65535)
The `router eigrp` command is necessary to enable EIGRP. To disable EIGRP,
use the `no router eigrp (1-65535)` command. EIGRP must be enabled before
carrying out any of the EIGRP commands.
.. index:: no router eigrp (1-65535)
.. clicmd:: no router eigrp (1-65535)
Disable EIGRP.
.. index:: network NETWORK
.. clicmd:: network NETWORK
.. index:: no network NETWORK
.. index:: no network NETWORK
.. clicmd:: no network NETWORK
Set the EIGRP enable interface by `network`. The interfaces which
have addresses matching with `network` are enabled.
@ -94,27 +94,25 @@ EIGRP Configuration
Below is very simple EIGRP configuration. Interface `eth0` and
interface which address match to `10.0.0.0/8` are EIGRP enabled.
::
::
!
router eigrp 1
network 10.0.0.0/8
!
!
router eigrp 1
network 10.0.0.0/8
!
Passive interface
.. index:: passive-interface (IFNAME|default)
.. clicmd:: passive-interface (IFNAME|default)
.. index:: no passive-interface IFNAME
.. index:: no passive-interface IFNAME
.. clicmd:: no passive-interface IFNAME
This command sets the specified interface to passive mode. On passive mode
interface, all receiving packets are ignored and eigrpd does
not send either multicast or unicast EIGRP packets except to EIGRP neighbors
specified with `neighbor` command. The interface may be specified
as `default` to make eigrpd default to passive on all interfaces.
interface, all receiving packets are ignored and eigrpd does not send either
multicast or unicast EIGRP packets except to EIGRP neighbors specified with
`neighbor` command. The interface may be specified as `default` to make
eigrpd default to passive on all interfaces.
The default is to be passive on all interfaces.
@ -124,70 +122,66 @@ How to Announce EIGRP route
===========================
.. index:: redistribute kernel
.. clicmd:: redistribute kernel
.. index:: redistribute kernel metric (1-4294967295) (0-4294967295) (0-255) (1-255) (1-65535)
.. clicmd:: redistribute kernel metric (1-4294967295) (0-4294967295) (0-255) (1-255) (1-65535)
.. index:: no redistribute kernel
.. index:: no redistribute kernel
.. clicmd:: no redistribute kernel
`redistribute kernel` redistributes routing information from
kernel route entries into the EIGRP tables. `no redistribute kernel`
disables the routes.
`redistribute kernel` redistributes routing information from kernel route
entries into the EIGRP tables. `no redistribute kernel` disables the routes.
.. index:: redistribute static
.. clicmd:: redistribute static
.. index:: redistribute static metric (1-4294967295) (0-4294967295) (0-255) (1-255) (1-65535)
.. clicmd:: redistribute static metric (1-4294967295) (0-4294967295) (0-255) (1-255) (1-65535)
.. index:: no redistribute static
.. index:: no redistribute static
.. clicmd:: no redistribute static
`redistribute static` redistributes routing information from
static route entries into the EIGRP tables. `no redistribute static`
disables the routes.
`redistribute static` redistributes routing information from static route
entries into the EIGRP tables. `no redistribute static` disables the routes.
.. index:: redistribute connected
.. clicmd:: redistribute connected
.. index:: redistribute connected metric (1-4294967295) (0-4294967295) (0-255) (1-255) (1-65535)
.. clicmd:: redistribute connected metric (1-4294967295) (0-4294967295) (0-255) (1-255) (1-65535)
.. index:: no redistribute connected
.. index:: no redistribute connected
.. clicmd:: no redistribute connected
Redistribute connected routes into the EIGRP tables. `no redistribute
connected` disables the connected routes in the EIGRP tables. This command
redistribute connected of the interface which EIGRP disabled. The connected
route on EIGRP enabled interface is announced by default.
Redistribute connected routes into the EIGRP tables. `no redistribute
connected` disables the connected routes in the EIGRP tables. This command
redistribute connected of the interface which EIGRP disabled. The connected
route on EIGRP enabled interface is announced by default.
.. index:: redistribute ospf
.. clicmd:: redistribute ospf
.. index:: redistribute ospf metric (1-4294967295) (0-4294967295) (0-255) (1-255) (1-65535)
.. clicmd:: redistribute ospf metric (1-4294967295) (0-4294967295) (0-255) (1-255) (1-65535)
.. index:: no redistribute ospf
.. index:: no redistribute ospf
.. clicmd:: no redistribute ospf
`redistribute ospf` redistributes routing information from ospf route
entries into the EIGRP tables. `no redistribute ospf` disables the
routes.
`redistribute ospf` redistributes routing information from ospf route
entries into the EIGRP tables. `no redistribute ospf` disables the routes.
.. index:: redistribute bgp
.. clicmd:: redistribute bgp
.. index:: redistribute bgp metric (1-4294967295) (0-4294967295) (0-255) (1-255) (1-65535)
.. clicmd:: redistribute bgp metric (1-4294967295) (0-4294967295) (0-255) (1-255) (1-65535)
.. index:: no redistribute bgp
.. index:: no redistribute bgp
.. clicmd:: no redistribute bgp
`redistribute bgp` redistributes routing information from
bgp route entries into the EIGRP tables. `no redistribute bgp`
disables the routes.
`redistribute bgp` redistributes routing information from bgp route entries
into the EIGRP tables. `no redistribute bgp` disables the routes.
.. _Show_EIGRP_Information:
@ -197,29 +191,29 @@ Show EIGRP Information
To display EIGRP routes.
.. index:: show ip eigrp topology
.. clicmd:: show ip eigrp topology
Show EIGRP routes.
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
::
The command displays current EIGRP status
eigrpd> **show ip eigrp topology**
# show ip eigrp topo
::
EIGRP Topology Table for AS(4)/ID(0.0.0.0)
eigrpd> **show ip eigrp topology**
# show ip eigrp topo
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply
r - reply Status, s - sia Status
EIGRP Topology Table for AS(4)/ID(0.0.0.0)
P 10.0.2.0/24, 1 successors, FD is 256256, serno: 0
via Connected, enp0s3
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply
r - reply Status, s - sia Status
P 10.0.2.0/24, 1 successors, FD is 256256, serno: 0
via Connected, enp0s3
EIGRP Debug Commands
@ -228,24 +222,25 @@ EIGRP Debug Commands
Debug for EIGRP protocol.
.. index:: debug eigrp packets
.. clicmd:: debug eigrp packets
Debug eigrp packets
`debug eigrp` will show EIGRP packets that are sent and recevied.
Debug eigrp packets
``debug eigrp`` will show EIGRP packets that are sent and recevied.
.. index:: debug eigrp transmit
.. clicmd:: debug eigrp transmit
Debug eigrp transmit events
`debug eigrp transmit` will display detailed information about the EIGRP transmit events.
Debug eigrp transmit events
``debug eigrp transmit`` will display detailed information about the EIGRP
transmit events.
.. index:: show debugging eigrp
.. clicmd:: show debugging eigrp
Display *eigrpd*'s debugging option.
`show debugging eigrp` will show all information currently set for eigrpd
debug.
Display *eigrpd*'s debugging option.
``show debugging eigrp`` will show all information currently set for eigrpd
debug.

211
doc/user/filter.rst
View File

@ -2,196 +2,177 @@
Filtering
*********
FRR provides many very flexible filtering features. Filtering is used
for both input and output of the routing information. Once filtering is
FRR provides many very flexible filtering features. Filtering is used
for both input and output of the routing information. Once filtering is
defined, it can be applied in any direction.
@comment node-name, next, previous, up
IP Access List
==============
.. index:: {Command} {access-list `name` permit `ipv4-network`} {}
.. index:: access-list NAME permit IPV4-NETWORK
.. clicmd:: access-list NAME permit IPV4-NETWORK
{Command} {access-list `name` permit `ipv4-network`} {}
.. index:: {Command} {access-list `name` deny `ipv4-network`} {}
.. index:: access-list NAME deny IPV4-NETWORK
.. clicmd:: access-list NAME deny IPV4-NETWORK
{Command} {access-list `name` deny `ipv4-network`} {}
Basic filtering is done by `access-list` as shown in the
following example.
Basic filtering is done by `access-list` as shown in the
following example.
::
::
access-list filter deny 10.0.0.0/9
access-list filter permit 10.0.0.0/8
access-list filter deny 10.0.0.0/9
access-list filter permit 10.0.0.0/8
@comment node-name, next, previous, up
IP Prefix List
==============
*ip prefix-list* provides the most powerful prefix based
filtering mechanism. In addition to *access-list* functionality,
filtering mechanism. In addition to *access-list* functionality,
*ip prefix-list* has prefix length range specification and
sequential number specification. You can add or delete prefix based
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`]} {}
.. index:: ip prefix-list NAME (permit|deny) PREFIX [le LEN] [ge LEN]
.. clicmd:: ip prefix-list NAME (permit|deny) PREFIX [le LEN] [ge LEN]
{Command} {ip prefix-list `name` (permit|deny) `prefix` [le `len`] [ge `len`]} {}
.. index:: {Command} {ip prefix-list `name` seq `number` (permit|deny) `prefix` [le `len`] [ge `len`]} {}
.. index:: ip prefix-list NAME seq NUMBER (permit|deny) PREFIX [le LEN] [ge LEN]
.. clicmd:: ip prefix-list NAME seq NUMBER (permit|deny) PREFIX [le LEN] [ge LEN]
{Command} {ip prefix-list `name` seq `number` (permit|deny) `prefix` [le `len`] [ge `len`]} {}
You can create *ip prefix-list* using above commands.
You can create *ip prefix-list* using above commands.
*@asis{seq}*
seq `number` can be set either automatically or manually. In the
seq
seq `number` can be set either automatically or manually. In the
case that sequential numbers are set manually, the user may pick any
number less than 4294967295. In the case that sequential number are set
number less than 4294967295. In the case that sequential number are set
automatically, the sequential number will increase by a unit of five (5)
per list. If a list with no specified sequential number is created
per list. If a list with no specified sequential number is created
after a list with a specified sequential number, the list will
automatically pick the next multiple of five (5) as the list number.
For example, if a list with number 2 already exists and a new list with
no specified number is created, the next list will be numbered 5. If
no specified number is created, the next list will be numbered 5. If
lists 2 and 7 already exist and a new list with no specified number is
created, the new list will be numbered 10.
le
Specifies prefix length. The prefix list will be applied if the prefix
length is less than or equal to the le prefix length.
*@asis{le}*
*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.
ge
Specifies prefix length. The prefix list will be applied if the prefix
length is greater than or equal to the ge prefix length.
*@asis{ge}*
*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.
Less than or equal to prefix numbers and greater than or equal to
prefix numbers can be used together. The order of the le and ge
commands does not matter.
If a prefix list with a different sequential number but with the exact
same rules as a previous list is created, an error will result.
However, in the case that the sequential number and the rules are
exactly similar, no error will result.
Less than or equal to prefix numbers and greater than or equal to
prefix numbers can be used together. The order of the le and ge
commands does not matter.
If a list with the same sequential number as a previous list is created,
the new list will overwrite the old list.
If a prefix list with a different sequential number but with the exact
same rules as a previous list is created, an error will result.
However, in the case that the sequential number and the rules are
exactly similar, no error will result.
Matching of IP Prefix is performed from the smaller sequential number to the
larger. The matching will stop once any rule has been applied.
If a list with the same sequential number as a previous list is created,
the new list will overwrite the old list.
In the case of no le or ge command, the prefix length must match exactly the
length specified in the prefix list.
Matching of IP Prefix is performed from the smaller sequential number to the
larger. The matching will stop once any rule has been applied.
In the case of no le or ge command, the prefix length must match exactly the
length specified in the prefix list.
.. index:: {Command} {no ip prefix-list `name`} {}
{Command} {no ip prefix-list `name`} {}
.. index:: no ip prefix-list NAME
.. clicmd:: no ip prefix-list NAME
.. _ip_prefix-list_description:
ip prefix-list description
--------------------------
.. index:: {Command} {ip prefix-list `name` description `desc`} {}
.. index:: ip prefix-list NAME description DESC
.. clicmd:: ip prefix-list NAME description DESC
{Command} {ip prefix-list `name` description `desc`} {}
Descriptions may be added to prefix lists. This command adds a
description to the prefix list.
Descriptions may be added to prefix lists. This command adds a
description to the prefix list.
.. index:: {Command} {no ip prefix-list `name` description [`desc`]} {}
.. index:: no ip prefix-list NAME description [DESC]
.. clicmd:: no ip prefix-list NAME description [DESC]
{Command} {no ip prefix-list `name` description [`desc`]} {}
Deletes the description from a prefix list. It is possible to use the
command without the full description.
Deletes the description from a prefix list. It is possible to use the
command without the full description.
.. _ip_prefix-list_sequential_number_control:
ip prefix-list sequential number control
----------------------------------------
.. index:: {Command} {ip prefix-list sequence-number} {}
.. index:: ip prefix-list sequence-number
.. clicmd:: ip prefix-list sequence-number
{Command} {ip prefix-list sequence-number} {}
With this command, the IP prefix list sequential number is displayed.
This is the default behavior.
With this command, the IP prefix list sequential number is displayed.
This is the default behavior.
.. index:: {Command} {no ip prefix-list sequence-number} {}
.. index:: no ip prefix-list sequence-number
.. clicmd:: no ip prefix-list sequence-number
{Command} {no ip prefix-list sequence-number} {}
With this command, the IP prefix list sequential number is not
displayed.
With this command, the IP prefix list sequential number is not
displayed.
.. _Showing_ip_prefix-list:
Showing ip prefix-list
----------------------
.. index:: {Command} {show ip prefix-list} {}
.. index:: show ip prefix-list
.. clicmd:: show ip prefix-list
{Command} {show ip prefix-list} {}
Display all IP prefix lists.
Display all IP prefix lists.
.. index:: {Command} {show ip prefix-list `name`} {}
.. index:: show ip prefix-list NAME
.. clicmd:: show ip prefix-list NAME
{Command} {show ip prefix-list `name`} {}
Show IP prefix list can be used with a prefix list name.
Show IP prefix list can be used with a prefix list name.
.. index:: {Command} {show ip prefix-list `name` seq `num`} {}
.. index:: show ip prefix-list NAME seq NUM
.. clicmd:: show ip prefix-list NAME seq NUM
{Command} {show ip prefix-list `name` seq `num`} {}
Show IP prefix list can be used with a prefix list name and sequential
number.
Show IP prefix list can be used with a prefix list name and sequential
number.
.. index:: {Command} {show ip prefix-list `name` `a.b.c.d/m`} {}
.. index:: show ip prefix-list NAME A.B.C.D/M
.. clicmd:: show ip prefix-list NAME A.B.C.D/M
{Command} {show ip prefix-list `name` `a.b.c.d/m`} {}
If the command longer is used, all prefix lists with prefix lengths equal to
or longer than the specified length will be displayed.
If the command first match is used, the first prefix length match will be
displayed.
If the command longer is used, all prefix lists with prefix lengths equal to
or longer than the specified length will be displayed. If the command first
match is used, the first prefix length match will be displayed.
.. index:: {Command} {show ip prefix-list `name` `a.b.c.d/m` longer} {}
{Command} {show ip prefix-list `name` `a.b.c.d/m` longer} {}
.. index:: {Command} {show ip prefix-list `name` `a.b.c.d/m` first-match} {}
{Command} {show ip prefix-list `name` `a.b.c.d/m` first-match} {}
.. index:: {Command} {show ip prefix-list summary} {}
{Command} {show ip prefix-list summary} {}
.. index:: {Command} {show ip prefix-list summary `name`} {}
{Command} {show ip prefix-list summary `name`} {}
.. index:: {Command} {show ip prefix-list detail} {}
{Command} {show ip prefix-list detail} {}
.. index:: {Command} {show ip prefix-list detail `name`} {}
{Command} {show ip prefix-list detail `name`} {}
.. index:: show ip prefix-list NAME A.B.C.D/M longer
.. clicmd:: show ip prefix-list NAME A.B.C.D/M longer
.. index:: show ip prefix-list NAME A.B.C.D/M first-match
.. clicmd:: show ip prefix-list NAME A.B.C.D/M first-match
.. index:: show ip prefix-list summary
.. clicmd:: show ip prefix-list summary
.. index:: show ip prefix-list summary NAME
.. clicmd:: show ip prefix-list summary NAME
.. index:: show ip prefix-list detail
.. clicmd:: show ip prefix-list detail
.. index:: show ip prefix-list detail NAME
.. clicmd:: show ip prefix-list detail NAME
Clear counter of ip prefix-list
-------------------------------
.. index:: {Command} {clear ip prefix-list} {}
.. index:: clear ip prefix-list
.. clicmd:: clear ip prefix-list
{Command} {clear ip prefix-list} {}
Clears the counters of all IP prefix lists. Clear IP Prefix List can be
used with a specified name and prefix.
Clears the counters of all IP prefix lists. Clear IP Prefix List can be used
with a specified name and prefix.
.. index:: {Command} {clear ip prefix-list `name`} {}
{Command} {clear ip prefix-list `name`} {}
.. index:: {Command} {clear ip prefix-list `name` `a.b.c.d/m`} {}
{Command} {clear ip prefix-list `name` `a.b.c.d/m`} {}
.. index:: clear ip prefix-list NAME
.. clicmd:: clear ip prefix-list NAME
.. index:: clear ip prefix-list NAME A.B.C.D/M
.. clicmd:: clear ip prefix-list NAME A.B.C.D/M

3
doc/user/installation.rst
View File

@ -156,6 +156,9 @@ customize the build to include or exclude specific features and dependencies.
Build without SNMP support.
.. option:: --disable-vtysh
Build without VTYSH.
You may specify any combination of the above options to the configure
script. By default, the executables are placed in :file:`/usr/local/sbin`

192
doc/user/ipv6.rst
View File

@ -4,11 +4,12 @@
IPv6 Support
************
FRR fully supports IPv6 routing. As described so far, Frr supports
RIPng, OSPFv3, and BGP-4+. You can give IPv6 addresses to an interface
and configure static IPv6 routing information. FRR IPv6 also provides
automatic address configuration via a feature called ``address auto configuration``. To do it, the router must send router advertisement
messages to the all nodes that exist on the network.
FRR fully supports IPv6 routing. As described so far, Frr supports RIPng,
OSPFv3, and BGP-4+. You can give IPv6 addresses to an interface and configure
static IPv6 routing information. FRR IPv6 also provides automatic address
configuration via a feature called ``address auto configuration``. To do it,
the router must send router advertisement messages to the all nodes that exist
on the network.
Previous versions of FRR could be built without IPv6 support. This is
no longer possible.
@ -17,177 +18,176 @@ Router Advertisement
====================
.. index:: no ipv6 nd suppress-ra
.. clicmd:: no ipv6 nd suppress-ra
Send router advertisment messages.
.. index:: ipv6 nd suppress-ra
.. clicmd:: ipv6 nd suppress-ra
Don't send router advertisment messages.
.. index:: ipv6 nd prefix ipv6prefix [valid-lifetime] [preferred-lifetime] [off-link] [no-autoconfig] [router-address]
.. clicmd:: ipv6 nd prefix ipv6prefix [valid-lifetime] [preferred-lifetime] [off-link] [no-autoconfig] [router-address]
Configuring the IPv6 prefix to include in router advertisements. Several prefix
specific optional parameters and flags may follow:
- ``valid-lifetime``: the length of time in seconds during what the prefix is
valid for the purpose of on-link determination. Value ``infinite`` represents
infinity (i.e. a value of all one bits (``0xffffffff``)).
Range: ``(0-4294967295)`` Default: ``2592000``
Configuring the IPv6 prefix to include in router advertisements. Several prefix
specific optional parameters and flags may follow:
- ``preferred-lifetime``: the length of time in seconds during what addresses
generated from the prefix remain preferred. Value ``infinite`` represents
infinity.
Range: ``(0-4294967295)`` Default: ``604800``
- ``valid-lifetime``: the length of time in seconds during what the prefix is
valid for the purpose of on-link determination. Value ``infinite`` represents
infinity (i.e. a value of all one bits (``0xffffffff``)).
Range: ``(0-4294967295)`` Default: ``2592000``
- ``off-link``: indicates that advertisement makes no statement about on-link or
off-link properties of the prefix.
Default: not set, i.e. this prefix can be used for on-link determination.
- ``preferred-lifetime``: the length of time in seconds during what addresses
generated from the prefix remain preferred. Value ``infinite`` represents
infinity.
Range: ``(0-4294967295)`` Default: ``604800``
- ``no-autoconfig``: indicates to hosts on the local link that the specified prefix
cannot be used for IPv6 autoconfiguration.
- ``off-link``: indicates that advertisement makes no statement about on-link or
off-link properties of the prefix.
Default: not set, i.e. this prefix can be used for on-link determination.
Default: not set, i.e. prefix can be used for autoconfiguration.
- ``no-autoconfig``: indicates to hosts on the local link that the specified prefix
cannot be used for IPv6 autoconfiguration.
- ``router-address``: indicates to hosts on the local link that the specified
prefix contains a complete IP address by setting R flag.
Default: not set, i.e. prefix can be used for autoconfiguration.
Default: not set, i.e. hosts do not assume a complete IP address is placed.
- ``router-address``: indicates to hosts on the local link that the specified
prefix contains a complete IP address by setting R flag.
Default: not set, i.e. hosts do not assume a complete IP address is placed.
.. index::
single: no ipv6 nd ra-interval [(1-1800)]
single: no ipv6 nd ra-interval [(1-1800)]
.. clicmd:: [no] ipv6 nd ra-interval [(1-1800)]
The maximum time allowed between sending unsolicited multicast router
advertisements from the interface, in seconds.
Default: ``600``
The maximum time allowed between sending unsolicited multicast router
advertisements from the interface, in seconds.
Default: ``600``
.. index:: ipv6 nd ra-interval msec (70-1800000)
.. index::
single: no ipv6 nd ra-interval [msec (70-1800000)]
single: ipv6 nd ra-interval msec (70-1800000)
.. clicmd:: [no] ipv6 nd ra-interval [msec (70-1800000)]
The maximum time allowed between sending unsolicited multicast router
advertisements from the interface, in milliseconds.
Default: ``600000``
The maximum time allowed between sending unsolicited multicast router
advertisements from the interface, in milliseconds.
Default: ``600000``
.. index::
single: ipv6 nd ra-lifetime (0-9000)
single: no ipv6 nd ra-lifetime [(0-9000)]
.. clicmd:: [no] ipv6 nd ra-lifetime [(0-9000)]
The value to be placed in the Router Lifetime field of router advertisements
sent from the interface, in seconds. Indicates the usefulness of the router
as a default router on this interface. Setting the value to zero indicates
that the router should not be considered a default router on this interface.
Must be either zero or between value specified with ``ipv6 nd ra-interval``
(or default) and 9000 seconds.
Default: ``1800``
The value to be placed in the Router Lifetime field of router advertisements
sent from the interface, in seconds. Indicates the usefulness of the router
as a default router on this interface. Setting the value to zero indicates
that the router should not be considered a default router on this interface.
Must be either zero or between value specified with ``ipv6 nd ra-interval``
(or default) and 9000 seconds.
Default: ``1800``
.. index::
single: no ipv6 nd reachable-time [(1-3600000)]
single: ipv6 nd reachable-time (1-3600000)
.. clicmd:: [no] ipv6 nd reachable-time [(1-3600000)]
The value to be placed in the Reachable Time field in the Router Advertisement
messages sent by the router, in milliseconds. The configured time enables the
router to detect unavailable neighbors. The value zero means unspecified (by
this router).
Default: ``0``
The value to be placed in the Reachable Time field in the Router
Advertisement messages sent by the router, in milliseconds. The configured
time enables the router to detect unavailable neighbors. The value zero
means unspecified (by this router).
Default: ``0``
.. index::
single: ipv6 nd managed-config-flag
single: no ipv6 nd managed-config-flag
.. clicmd:: [no] ipv6 nd managed-config-flag
Set/unset flag in IPv6 router advertisements which indicates to hosts that they
should use managed (stateful) protocol for addresses autoconfiguration in
addition to any addresses autoconfigured using stateless address
autoconfiguration.
Default: not set
Set/unset flag in IPv6 router advertisements which indicates to hosts that
they should use managed (stateful) protocol for addresses autoconfiguration
in addition to any addresses autoconfigured using stateless address
autoconfiguration.
Default: not set
.. index::
single: ipv6 nd other-config-flag
single: no ipv6 nd other-config-flag
.. clicmd:: [no] ipv6 nd other-config-flag
Set/unset flag in IPv6 router advertisements which indicates to hosts that
they should use administered (stateful) protocol to obtain autoconfiguration
information other than addresses.
Default: not set
Set/unset flag in IPv6 router advertisements which indicates to hosts that
they should use administered (stateful) protocol to obtain autoconfiguration
information other than addresses.
Default: not set
.. index::
single: ipv6 nd home-agent-config-flag
single: no ipv6 nd home-agent-config-flag
.. clicmd:: [no] ipv6 nd home-agent-config-flag
Set/unset flag in IPv6 router advertisements which indicates to hosts that
the router acts as a Home Agent and includes a Home Agent Option.
Default: not set
Set/unset flag in IPv6 router advertisements which indicates to hosts that
the router acts as a Home Agent and includes a Home Agent Option.
Default: not set
.. index:: ipv6 nd home-agent-preference (0-65535)
.. index::
single: no ipv6 nd home-agent-preference [(0-65535)]
single: ipv6 nd home-agent-preference (0-65535)
.. clicmd:: [no] ipv6 nd home-agent-preference [(0-65535)]
The value to be placed in Home Agent Option, when Home Agent config flag is set,
which indicates to hosts Home Agent preference. The default value of 0 stands
for the lowest preference possible.
Default: ``0``
The value to be placed in Home Agent Option, when Home Agent config flag is
set, which indicates to hosts Home Agent preference. The default value of 0
stands for the lowest preference possible.
Default: ``0``
.. index::
single: ipv6 nd home-agent-lifetime (0-65520)
single: no ipv6 nd home-agent-lifetime (0-65520)
.. clicmd:: [no] ipv6 nd home-agent-lifetime [(0-65520)]
The value to be placed in Home Agent Option, when Home Agent config flag is set,
which indicates to hosts Home Agent Lifetime. The default value of 0 means to
place the current Router Lifetime value.
Default: ``0``
The value to be placed in Home Agent Option, when Home Agent config flag is set,
which indicates to hosts Home Agent Lifetime. The default value of 0 means to
place the current Router Lifetime value.
Default: ``0``
.. index::
single: ipv6 nd adv-interval-option
single: no ipv6 nd adv-interval-option
.. clicmd:: [no] ipv6 nd adv-interval-option
Include an Advertisement Interval option which indicates to hosts the maximum time,
in milliseconds, between successive unsolicited Router Advertisements.
Default: not set
Include an Advertisement Interval option which indicates to hosts the maximum time,
in milliseconds, between successive unsolicited Router Advertisements.
Default: not set
.. index::
single: ipv6 nd router-preference (high|medium|low)
single: no ipv6 nd router-preference (high|medium|low)
.. clicmd:: [no] ipv6 nd router-preference [(high|medium|low)]
Set default router preference in IPv6 router advertisements per RFC4191.
Default: medium
Set default router preference in IPv6 router advertisements per RFC4191.
Default: medium
.. index::
single: ipv6 nd mtu (1-65535)
single: no ipv6 nd mtu [(1-65535)]
.. clicmd:: [no] ipv6 nd mtu [(1-65535)]
Include an MTU (type 5) option in each RA packet to assist the attached hosts
in proper interface configuration. The announced value is not verified to be
consistent with router interface MTU.
Default: don't advertise any MTU option.::
interface eth0
no ipv6 nd suppress-ra
ipv6 nd prefix 2001:0DB8:5009::/64
Include an MTU (type 5) option in each RA packet to assist the attached
hosts in proper interface configuration. The announced value is not verified
to be consistent with router interface MTU.
Default: don't advertise any MTU option.::
interface eth0
no ipv6 nd suppress-ra
ipv6 nd prefix 2001:0DB8:5009::/64
For more information see
:t:`RFC2462 (IPv6 Stateless Address Autoconfiguration)`,
:t:`RFC4861 (Neighbor Discovery for IP Version 6 (IPv6))`,
:t:`RFC6275 (Mobility Support in IPv6)` and
:t:`RFC4191 (Default Router Preferences and More-Specific Routes)`.
.. seealso::
- :rfc:`2462` (IPv6 Stateless Address Autoconfiguration)
- :rfc:`4861` (Neighbor Discovery for IP Version 6 (IPv6))
- :rfc:`6275` (Mobility Support in IPv6)
- :rfc:`4191` (Default Router Preferences and More-Specific Routes)

803
doc/user/isisd.rst
View File

File diff suppressed because it is too large Load Diff

35
doc/user/nhrpd.rst
View File

@ -4,18 +4,17 @@
NHRP
****
*nhrpd* is a daemon to support Next Hop Routing Protocol (NHRP).
NHRP is described in RFC2332.
*nhrpd* is an implementation of the :abbr:NHRP `(Next Hop Routing Protocol)`.
NHRP is described in :rfc`2332`.
NHRP is used to improve the efficiency of routing computer network
traffic over Non-Broadcast, Multiple Access (NBMA) Networks. NHRP provides
an ARP-like solution that allows a system to dynamically learn the NBMA
address of the other systems that are part of that network, allowing
these systems to directly communicate without requiring traffic to use
an intermediate hop.
NHRP is used to improve the efficiency of routing computer network traffic over
:abbr:`NBMA (Non-Broadcast, Multiple Access)` networks. NHRP provides an
ARP-like solution that allows a system to dynamically learn the NBMA address of
the other systems that are part of that network, allowing these systems to
directly communicate without requiring traffic to use an intermediate hop.
Cisco Dynamic Multipoint VPN (DMVPN) is based on NHRP, and
|PACKAGE_NAME| nhrpd implements this scenario.
Cisco Dynamic Multipoint VPN (DMVPN) is based on NHRP, and |PACKAGE_NAME| nhrpd
implements this scenario.
.. _Routing_Design:
@ -31,9 +30,8 @@ nhrpd does route NHRP domain addresses individually using per-host prefixes.
This is similar to Cisco FlexVPN; but in contrast to opennhrp which uses
a generic subnet route.
To create NBMA GRE tunnel you might use the following (linux terminal
commands):
::
To create NBMA GRE tunnel you might use the following (Linux terminal
commands):::
ip tunnel add gre1 mode gre key 42 ttl 64
ip addr add 10.255.255.2/32 dev gre1
@ -54,8 +52,7 @@ hub nodes, these routes should be internally redistributed using some
routing protocol (e.g. iBGP) to allow hubs to be able to relay all traffic.
This can be achieved in hubs with the following bgp configuration (network
command defines the GRE subnet):
::
command defines the GRE subnet):::
router bgp 65555
address-family ipv4 unicast
@ -98,20 +95,16 @@ announce internal, add additional IP range matches, or rate limitation
if needed. However, the above should be good in most cases.
This kernel NFLOG target's nflog-group is configured in global nhrp config
with:
::
with:::
nhrp nflog-group 1
To start sending these traffic notices out from hubs, use the nhrp
per-interface directive:
::
per-interface directive:::
interface gre1
ip nhrp redirect
.. _Integration_with_IKE:
Integration with IKE

219
doc/user/ospf6d.rst
View File

@ -4,82 +4,79 @@
OSPFv3
******
*ospf6d* is a daemon support OSPF version 3 for IPv6 network.
OSPF for IPv6 is described in RFC2740.
*ospf6d* is a daemon support OSPF version 3 for IPv6 network. OSPF for IPv6 is
described in :rfc:`2740`.
.. _OSPF6_router:
OSPF6 router
============
.. index:: {Command} {router ospf6} {}
.. index:: router ospf6
.. clicmd:: router ospf6
{Command} {router ospf6} {}
.. index:: router-id A.B.C.D
.. clicmd:: router-id A.B.C.D
.. index:: {OSPF6 Command} {router-id `a.b.c.d`} {}
Set router's Router-ID.
{OSPF6 Command} {router-id `a.b.c.d`} {}
Set router's Router-ID.
.. index:: interface IFNAME area AREA
.. clicmd:: interface IFNAME area AREA
.. index:: {OSPF6 Command} {interface `ifname` area `area`} {}
Bind interface to specified area, and start sending OSPF packets. `area` can
be specified as 0.
{OSPF6 Command} {interface `ifname` area `area`} {}
Bind interface to specified area, and start sending OSPF packets. `area` can
be specified as 0.
.. index:: timers throttle spf DELAY INITIAL-HOLDTIME MAX-HOLDTIME
.. clicmd:: timers throttle spf DELAY INITIAL-HOLDTIME MAX-HOLDTIME
.. index:: {OSPF6 Command} {timers throttle spf `delay` `initial-holdtime` `max-holdtime`} {}
.. index:: no timers throttle spf
.. clicmd:: no timers throttle spf
{OSPF6 Command} {timers throttle spf `delay` `initial-holdtime` `max-holdtime`} {}
.. index:: {OSPF6 Command} {no timers throttle spf} {}
This command sets the initial `delay`, the `initial-holdtime`
and the `maximum-holdtime` between when SPF is calculated and the
event which triggered the calculation. The times are specified in
milliseconds and must be in the range of 0 to 600000 milliseconds.
{OSPF6 Command} {no timers throttle spf} {}
This command sets the initial `delay`, the `initial-holdtime`
and the `maximum-holdtime` between when SPF is calculated and the
event which triggered the calculation. The times are specified in
milliseconds and must be in the range of 0 to 600000 milliseconds.
The `delay` specifies the minimum amount of time to delay SPF
calculation (hence it affects how long SPF calculation is delayed after
an event which occurs outside of the holdtime of any previous SPF
calculation, and also serves as a minimum holdtime).
The `delay` specifies the minimum amount of time to delay SPF
calculation (hence it affects how long SPF calculation is delayed after
an event which occurs outside of the holdtime of any previous SPF
calculation, and also serves as a minimum holdtime).
Consecutive SPF calculations will always be seperated by at least
'hold-time' milliseconds. The hold-time is adaptive and initially is
set to the `initial-holdtime` configured with the above command.
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
the current holdtime is reset to the `initial-holdtime`.
::
Consecutive SPF calculations will always be seperated by at least
'hold-time' milliseconds. The hold-time is adaptive and initially is
set to the `initial-holdtime` configured with the above command.
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
the current holdtime is reset to the `initial-holdtime`.::
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
there will always be at least 200ms between an event which requires SPF
calculation and the actual SPF calculation. Further consecutive SPF
calculations will always be seperated by between 400ms to 10s, the
hold-time increasing by 400ms each time an SPF-triggering event occurs
within the hold-time of the previous SPF calculation.
In this example, the `delay` is set to 200ms, the initial holdtime is set
to 400ms and the `maximum holdtime` to 10s. Hence there will always be at
least 200ms between an event which requires SPF calculation and the actual
SPF calculation. Further consecutive SPF calculations will always be
seperated by between 400ms to 10s, the hold-time increasing by 400ms each
time an SPF-triggering event occurs within the hold-time of the previous
SPF calculation.
.. index:: {OSPF6 Command} {auto-cost reference-bandwidth `cost`} {}
.. index:: auto-cost reference-bandwidth COST
.. clicmd:: auto-cost reference-bandwidth COST
{OSPF6 Command} {auto-cost reference-bandwidth `cost`} {}
.. index:: {OSPF6 Command} {no auto-cost reference-bandwidth} {}
.. index:: no auto-cost reference-bandwidth
.. clicmd:: no auto-cost reference-bandwidth
{OSPF6 Command} {no auto-cost reference-bandwidth} {}
This sets the reference bandwidth for cost calculations, where this
bandwidth is considered equivalent to an OSPF cost of 1, specified in
Mbits/s. The default is 100Mbit/s (i.e. a link of bandwidth 100Mbit/s
or higher will have a cost of 1. Cost of lower bandwidth links will be
scaled with reference to this cost).
This sets the reference bandwidth for cost calculations, where this
bandwidth is considered equivalent to an OSPF cost of 1, specified in
Mbits/s. The default is 100Mbit/s (i.e. a link of bandwidth 100Mbit/s
or higher will have a cost of 1. Cost of lower bandwidth links will be
scaled with reference to this cost).
This configuration setting MUST be consistent across all routers
within the OSPF domain.
This configuration setting MUST be consistent across all routers
within the OSPF domain.
.. _OSPF6_area:
@ -93,97 +90,97 @@ Area support for OSPFv3 is not yet implemented.
OSPF6 interface
===============
.. index:: {Interface Command} {ipv6 ospf6 cost COST} {}
.. index:: ipv6 ospf6 cost COST
.. clicmd:: ipv6 ospf6 cost COST
{Interface Command} {ipv6 ospf6 cost COST} {}
Sets interface's output cost. Default value depends on the interface
bandwidth and on the auto-cost reference bandwidth.
Sets interface's output cost. Default value depends on the interface
bandwidth and on the auto-cost reference bandwidth.
.. index:: {Interface Command} {ipv6 ospf6 hello-interval HELLOINTERVAL} {}
.. index:: ipv6 ospf6 hello-interval HELLOINTERVAL
.. clicmd:: ipv6 ospf6 hello-interval HELLOINTERVAL
{Interface Command} {ipv6 ospf6 hello-interval HELLOINTERVAL} {}
Sets interface's Hello Interval. Default 40
Sets interface's Hello Interval. Default 40
.. index:: {Interface Command} {ipv6 ospf6 dead-interval DEADINTERVAL} {}
.. index:: ipv6 ospf6 dead-interval DEADINTERVAL
.. clicmd:: ipv6 ospf6 dead-interval DEADINTERVAL
{Interface Command} {ipv6 ospf6 dead-interval DEADINTERVAL} {}
Sets interface's Router Dead Interval. Default value is 40.
Sets interface's Router Dead Interval. Default value is 40.
.. index:: {Interface Command} {ipv6 ospf6 retransmit-interval RETRANSMITINTERVAL} {}
.. index:: ipv6 ospf6 retransmit-interval RETRANSMITINTERVAL
.. clicmd:: ipv6 ospf6 retransmit-interval RETRANSMITINTERVAL
{Interface Command} {ipv6 ospf6 retransmit-interval RETRANSMITINTERVAL} {}
Sets interface's Rxmt Interval. Default value is 5.
Sets interface's Rxmt Interval. Default value is 5.
.. index:: {Interface Command} {ipv6 ospf6 priority PRIORITY} {}
.. index:: ipv6 ospf6 priority PRIORITY
.. clicmd:: ipv6 ospf6 priority PRIORITY
{Interface Command} {ipv6 ospf6 priority PRIORITY} {}
Sets interface's Router Priority. Default value is 1.
Sets interface's Router Priority. Default value is 1.
.. index:: {Interface Command} {ipv6 ospf6 transmit-delay TRANSMITDELAY} {}
.. index:: ipv6 ospf6 transmit-delay TRANSMITDELAY
.. clicmd:: ipv6 ospf6 transmit-delay TRANSMITDELAY
{Interface Command} {ipv6 ospf6 transmit-delay TRANSMITDELAY} {}
Sets interface's Inf-Trans-Delay. Default value is 1.
Sets interface's Inf-Trans-Delay. Default value is 1.
.. index:: {Interface Command} {ipv6 ospf6 network (broadcast|point-to-point)} {}
.. index:: ipv6 ospf6 network (broadcast|point-to-point)
.. clicmd:: ipv6 ospf6 network (broadcast|point-to-point)
{Interface Command} {ipv6 ospf6 network (broadcast|point-to-point)} {}
Set explicitly network type for specifed interface.
Set explicitly network type for specifed interface.
.. _Redistribute_routes_to_OSPF6:
Redistribute routes to OSPF6
============================
.. index:: {OSPF6 Command} {redistribute static} {}
.. index:: redistribute static
.. clicmd:: redistribute static
{OSPF6 Command} {redistribute static} {}
.. index:: {OSPF6 Command} {redistribute connected} {}
.. index:: redistribute connected
.. clicmd:: redistribute connected
{OSPF6 Command} {redistribute connected} {}
.. index:: {OSPF6 Command} {redistribute ripng} {}
.. index:: redistribute ripng
.. clicmd:: redistribute ripng
{OSPF6 Command} {redistribute ripng} {}
.. _Showing_OSPF6_information:
Showing OSPF6 information
=========================
.. index:: {Command} {show ipv6 ospf6 [INSTANCE_ID]} {}
.. index:: show ipv6 ospf6 [INSTANCE_ID]
.. clicmd:: show ipv6 ospf6 [INSTANCE_ID]
{Command} {show ipv6 ospf6 [INSTANCE_ID]} {}
INSTANCE_ID is an optional OSPF instance ID. To see router ID and OSPF
instance ID, simply type "show ipv6 ospf6 <cr>".
INSTANCE_ID is an optional OSPF instance ID. To see router ID and OSPF
instance ID, simply type "show ipv6 ospf6 <cr>".
.. index:: {Command} {show ipv6 ospf6 database} {}
.. index:: show ipv6 ospf6 database
.. clicmd:: show ipv6 ospf6 database
{Command} {show ipv6 ospf6 database} {}
This command shows LSA database summary. You can specify the type of LSA.
This command shows LSA database summary. You can specify the type of LSA.
.. index:: {Command} {show ipv6 ospf6 interface} {}
.. index:: show ipv6 ospf6 interface
.. clicmd:: show ipv6 ospf6 interface
{Command} {show ipv6 ospf6 interface} {}
To see OSPF interface configuration like costs.
To see OSPF interface configuration like costs.
.. index:: {Command} {show ipv6 ospf6 neighbor} {}
.. index:: show ipv6 ospf6 neighbor
.. clicmd:: show ipv6 ospf6 neighbor
{Command} {show ipv6 ospf6 neighbor} {}
Shows state and chosen (Backup) DR of neighbor.
Shows state and chosen (Backup) DR of neighbor.
.. index:: {Command} {show ipv6 ospf6 request-list A.B.C.D} {}
.. index:: show ipv6 ospf6 request-list A.B.C.D
.. clicmd:: show ipv6 ospf6 request-list A.B.C.D
{Command} {show ipv6 ospf6 request-list A.B.C.D} {}
Shows requestlist of neighbor.
Shows requestlist of neighbor.
.. index:: {Command} {show ipv6 route ospf6} {}
.. index:: show ipv6 route ospf6
.. clicmd:: show ipv6 route ospf6
{Command} {show ipv6 route ospf6} {}
This command shows internal routing table.
This command shows internal routing table.
.. index:: {Command} {show ipv6 ospf6 zebra} {}
.. index:: show ipv6 ospf6 zebra
.. clicmd:: show ipv6 ospf6 zebra
{Command} {show ipv6 ospf6 zebra} {}
Shows state about what is being redistributed between zebra and OSPF6
Shows state about what is being redistributed between zebra and OSPF6
OSPF6 Configuration Examples
============================
@ -192,13 +189,11 @@ Example of ospf6d configured on one interface and area:
::
interface eth0
ipv6 ospf6 instance-id 0
!
router ospf6
router-id 212.17.55.53
area 0.0.0.0 range 2001:770:105:2::/64
interface eth0 area 0.0.0.0
!
interface eth0
ipv6 ospf6 instance-id 0
!
router ospf6
router-id 212.17.55.53
area 0.0.0.0 range 2001:770:105:2::/64
interface eth0 area 0.0.0.0
!

424
doc/user/ospf_fundamentals.rst
View File

@ -4,7 +4,6 @@ OSPF Fundamentals
=================
.. index:: Link-state routing protocol
.. index:: Distance-vector routing protocol
:abbr:`OSPF` is, mostly, a link-state routing protocol. In contrast
@ -15,12 +14,9 @@ describe the state of their links to their immediate neighbouring
routers.
.. index:: Link State Announcement
.. index:: Link State Advertisement
.. index:: LSA flooding
.. index:: Link State DataBase
.. index:: Link State Database
Each router describes their link-state information in a message known
as an :abbr:`LSA (Link State Advertisement)`, which is then propogated
@ -69,128 +65,118 @@ will nearly all be covered in greater detail further on. They may be
broadly classed as:
.. index:: OSPF Hello Protocol overview
.. index:: OSPF Hello Protocol
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)`.
OSPF also uses the Hello protocol to propagate certain state between routers
sharing a link, for example:
- Hello protocol configured state, such as the dead-interval.
- Router priority, for DR/BDR election.
- DR/BDR election results.
- Any optional capabilities supported by each router.
The Hello protocol is comparatively trivial and will not be explored in greater
detail than here.
.. index:: OSPF LSA overview
.. _ospf-lsas:
LSAs
^^^^
At the heart of :abbr:`OSPF` are :abbr:`LSA (Link State Advertisement)`
messages. Despite the name, some :abbr:`LSA` s do not, strictly speaking,
describe link-state information. Common :abbr:`LSA` s describe information
such as:
- Routers, in terms of their links.
- Networks, in terms of attached routers.
- Routes, external to a link-state domain:
External Routes
Routes entirely external to :abbr:`OSPF`. Routers originating such
routes are known as :abbr:`ASBR (Autonomous-System Border Router)`
routers.
Summary Routes
Routes which summarise routing information relating to OSPF areas
external to the OSPF link-state area at hand, originated by
:abbr:`ABR (Area Boundary Router)` routers.
.. _ospf-lsa-flooding:
LSA Flooding
""""""""""""
OSPF defines several related mechanisms, used to manage synchronisation of
: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`.
*The Hello Protocol*
.. index:: OSPF Hello Protocol
.. index:: OSPF Areas overview
.. _ospf-areas:
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 (Bi-directional Forwarding Detection)`.
Areas
^^^^^
OSPF also uses the Hello protocol to propagate certain state between
routers sharing a link, for example:
OSPF provides for the protocol to be broken up into multiple smaller and
independent link-state areas. Each area must be connected to a common backbone
area by an :abbr:`ABR (Area Boundary Router)`. These :abbr:`ABR` routers are
responsible for summarising the link-state routing information of an area into
:term:`Summary LSAs`, possibly in a condensed (i.e. aggregated) form, and then
originating these summaries into all other areas the :abbr:`ABR` is connected
to.
*Hello protocol configured state, such as the dead-interval.*
*Router priority, for DR/BDR election.*
*DR/BDR election results.*
*Any optional capabilities supported by each router.*
The Hello protocol is comparatively trivial and will not be explored in
greater detail than here.
.. index:: OSPF LSA overview
*LSAs*
At the heart of :abbr:`OSPF` are :abbr:`LSA (Link State Advertisement)`
messages. Despite the name, some :abbr:`LSA`s do not, strictly speaking,
describe link-state information. Common :abbr:`LSA`s describe information
such as:
**
Routers, in terms of their links.
**
Networks, in terms of attached routers.
**
Routes, external to a link-state domain:
*External Routes*
Routes entirely external to :abbr:`OSPF`. Routers originating such
routes are known as :abbr:`ASBR (Autonomous-System Border Router)`
routers.
*Summary Routes*
Routes which summarise routing information relating to OSPF areas
external to the OSPF link-state area at hand, originated by
:abbr:`ABR (Area Boundary Router)` routers.
*LSA Flooding*
OSPF defines several related mechanisms, used to manage synchronisation of
: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`.
.. index:: OSPF Areas overview
*Areas*
OSPF provides for the protocol to be broken up into multiple smaller
and independent link-state areas. Each area must be connected to a
common backbone area by an :abbr:`ABR (Area Boundary Router)`. These
:abbr:`ABR` routers are responsible for summarising the link-state
routing information of an area into :term:`Summary LSAs`, possibly in a
condensed (i.e. aggregated) form, and then originating these summaries
into all other areas the :abbr:`ABR` is connected to.
Note that only summaries and external routes are passed between areas.
As these describe *paths*, rather than any router link-states,
routing between areas hence is by :term:`distance-vector`, **not**
link-state.
:ref:`OSPF_Areas`.
Note that only summaries and external routes are passed between areas. As
these describe *paths*, rather than any router link-states, routing between
areas hence is by :term:`distance-vector`, **not** link-state.
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.
The core objects in OSPF are :abbr:`LSA` s. 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.
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
:abbr:`TE (Traffic Engineering)` purposes, and even arbitrary data
by way of *Opaque* :abbr:`LSA`s.
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 :abbr:`TE (Traffic Engineering)` purposes, and
even arbitrary data by way of *Opaque* :abbr:`LSA` s.
LSA Header
^^^^^^^^^^
All LSAs share a common header with the following information:
* Type
- Type
Different types of :abbr:`LSA`s describe different things in
Different types of :abbr:`LSA` s describe different things in
:abbr:`OSPF`. Types include:
* Router LSA
* Network LSA
* Network Summary LSA
* Router Summary LSA
* AS-External LSA
- Router LSA
- Network LSA
- Network Summary LSA
- Router Summary LSA
- AS-External LSA
The specifics of the different types of LSA are examined below.
* Advertising Router
- Advertising Router
The Router ID of the router originating the LSA, see :ref:`ospf_router-id`.
* LSA ID
- LSA ID
The ID of the LSA, which is typically derived in some way from the
information the LSA describes, e.g. a Router LSA uses the Router ID as
@ -202,9 +188,9 @@ All LSAs share a common header with the following information:
an LSA with the same Type, LSA ID and Advertising Router ID, see
:ref:`OSPF_LSA_sequence_number,,LSA_Sequence_Number`.
* Age
- Age
A number to allow stale :abbr:`LSA`s to, eventually, be purged by routers
A number to allow stale :abbr:`LSA` s to, eventually, be purged by routers
from their :abbr:`LSDB`s.
The value nominally is one of seconds. An age of 3600, i.e. 1 hour, is
@ -222,96 +208,93 @@ All LSAs share a common header with the following information:
.. _OSPF_LSA_sequence_number:
* Sequence Number
- Sequence Number
A number used to distinguish newer instances of an LSA from older instances.
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
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.
Instances of these LSAs are specific to the link-state area in which
they are originated. Routes calculated from these two LSA types are
called :term:`intra-area routes`.
* Router LSA
- Router LSA
Each OSPF Router must originate a router :abbr:`LSA` to describe
itself. In it, the router lists each of its :abbr:`OSPF` enabled
interfaces, for the given link-state area, in terms of:
* Cost
Cost
The output cost of that interface, scaled inversely to some commonly known
reference value, :ref:`OSPF_auto-cost_reference-bandwidth,,auto-cost_reference-bandwidth`.
The output cost of that interface, scaled inversely to some commonly known
reference value, :ref:`OSPF_auto-cost_reference-bandwidth,,auto-cost_reference-bandwidth`.
Link Type
Transit Network
* Link Type
A link to a multi-access network, on which the router has at least one
Full adjacency with another router.
* Transit Network
:abbr:`PtP (Point-to-Point)`
A link to a single remote router, with a Full adjacency. No
:abbr:`DR (Designated Router)` is elected on such links; no network
LSA is originated for such a link.
A link to a multi-access network, on which the router has at least one
Full adjacency with another router.
Stub
A link with no adjacent neighbours, or a host route.
* :abbr:`PtP (Point-to-Point)`
A link to a single remote router, with a Full adjacency. No
:abbr:`DR (Designated Router)` is elected on such links; no network
LSA is originated for such a link.
* Stub
A link with no adjacent neighbours, or a host route.
* Link ID and Data
- Link ID and Data
These values depend on the Link Type:
+----------------+-----------------------------------+------------------------------------------+
| Link Type | Link ID | Link Data |
+================+===================================+==========================================+
| Transit | Link IP address of the :abbr:`DR` | Interface IP address |
+----------------+-----------------------------------+------------------------------------------+
| Point-to-Point | Router ID of the remote router | Local interface IP address, or the |
| | | :abbr:`ifindex (MIB-II interface index)` |
| | | for unnumbered links |
+----------------+-----------------------------------+------------------------------------------+
| Stub | IP address | Subnet Mask |
+----------------+-----------------------------------+------------------------------------------+
+----------------+-----------------------------------+------------------------------------------+
| Link Type | Link ID | Link Data |
+================+===================================+==========================================+
| Transit | Link IP address of the :abbr:`DR` | Interface IP address |
+----------------+-----------------------------------+------------------------------------------+
| Point-to-Point | Router ID of the remote router | Local interface IP address, or the |
| | | :abbr:`ifindex (MIB-II interface index)` |
| | | for unnumbered links |
+----------------+-----------------------------------+------------------------------------------+
| Stub | IP address | Subnet Mask |
+----------------+-----------------------------------+------------------------------------------+
Links on a router may be listed multiple times in the Router LSA, e.g.
a :abbr:`PtP` interface on which OSPF is enabled must *always*
be described by a Stub link in the Router :abbr:`LSA`, in addition to
being listed as PtP link in the Router :abbr:`LSA` if the adjacency
with the remote router is Full.
Links on a router may be listed multiple times in the Router LSA, e.g. a
:abbr:`PtP` interface on which OSPF is enabled must *always* be described
by a Stub link in the Router :abbr:`LSA`, in addition to being listed as
PtP link in the Router :abbr:`LSA` if the adjacency with the remote router
is Full.
Stub links may also be used as a way to describe links on which OSPF is
*not* spoken, known as :term:`passive interfaces`, see :ref:`OSPF_passive-interface,,passive-interface`.
Stub links may also be used as a way to describe links on which OSPF is
*not* spoken, known as :term:`passive interfaces`, see
:ref:`OSPF_passive-interface,,passive-interface`.
* Network LSA
- Network LSA
On multi-access links (e.g. ethernets, certain kinds of ATM and X.25
configurations), routers elect a :abbr:`DR`. The :abbr:`DR` is
responsible for originating a Network :abbr:`LSA`, which helps reduce
the information needed to describe multi-access networks with multiple
routers attached. The :abbr:`DR` also acts as a hub for the flooding of
:abbr:`LSA`s on that link, thus reducing flooding overheads.
:abbr:`LSA` s on that link, thus reducing flooding overheads.
The contents of the Network LSA describes the:
* Subnet Mask
- Subnet Mask
As the :abbr:`LSA` ID of a Network LSA must be the IP address of the
:abbr:`DR`, the Subnet Mask together with the :abbr:`LSA` ID gives
you the network address.
* Attached Routers
- Attached Routers
Each router fully-adjacent with the :abbr:`DR` is listed in the LSA,
by their Router-ID. This allows the corresponding Router :abbr:`LSA`s to be
by their Router-ID. This allows the corresponding Router :abbr:`LSA` s to be
easily retrieved from the :abbr:`LSDB`.
Summary of Link State LSAs:
@ -333,13 +316,14 @@ surprisingly, when OSPF routers build updated routing tables, the first
stage of :abbr:`SPF` calculation concerns itself only with these two
LSA types.
.. _ospf-link-state-lsa-examples:
Link-State LSA Examples
^^^^^^^^^^^^^^^^^^^^^^^
The example below (:ref:`OSPF_Link-State_LSA_Example`) shows two
:abbr:`LSA`s, both originated by the same router (Router ID
192.168.0.49) and with the same :abbr:`LSA` ID (192.168.0.49), but of
different LSA types.
The example below shows two :abbr:`LSA` s, both originated by the same router
(Router ID 192.168.0.49) and with the same :abbr:`LSA` ID (192.168.0.49), but
of different LSA types.
The first LSA being the router LSA describing 192.168.0.49's links: 2 links
to multi-access networks with fully-adjacent neighbours (i.e. Transit
@ -349,8 +333,6 @@ The second LSA being a Network LSA, for which 192.168.0.49 is the
:abbr:`DR`, listing the Router IDs of 4 routers on that network which
are fully adjacent with 192.168.0.49.
.. _OSPF_Link-State_LSA_Example:
::
# show ip ospf database router 192.168.0.49
@ -424,7 +406,7 @@ as their LSA ID, so you can then look up that Network LSA and from that
find all the attached routers on that link, leading potentially to more
links and Network and Router LSAs, etc. etc.
From just the above two :abbr:`LSA`s, one can already see the
From just the above two :abbr:`LSA` s, one can already see the
following partial topology:
::
@ -458,66 +440,57 @@ reachable addresses (though, OSPF will calculate routes to Router IDs).
External LSAs
^^^^^^^^^^^^^
External, or "Type 5", :abbr:`LSA`s describe routing information which is
External, or "Type 5", :abbr:`LSA` s describe routing information which is
entirely external to :abbr:`OSPF`, and is "injected" into
:abbr:`OSPF`. Such routing information may have come from another
routing protocol, such as RIP or BGP, they may represent static routes
or they may represent a default route.
An :abbr:`OSPF` router which originates External :abbr:`LSA`s is known as an
:abbr:`ASBR (AS Boundary Router)`. Unlike the link-state :abbr:`LSA`s, and
most other :abbr:`LSA`s, which are flooded only within the area in
which they originate, External :abbr:`LSA`s are flooded through-out
An :abbr:`OSPF` router which originates External :abbr:`LSA` s is known as an
:abbr:`ASBR (AS Boundary Router)`. Unlike the link-state :abbr:`LSA` s, and
most other :abbr:`LSA` s, which are flooded only within the area in
which they originate, External :abbr:`LSA` s are flooded through-out
the :abbr:`OSPF` network to all areas capable of carrying External
:abbr:`LSA`s (:ref:`OSPF_Areas`).
:abbr:`LSA` s (:ref:`OSPF_Areas`).
Routes internal to OSPF (intra-area or inter-area) are always preferred
over external routes.
The External :abbr:`LSA` describes the following:
* IP Network number
IP Network number
The IP Network number of the route is described by the :abbr:`LSA` ID field.
The IP Network number of the route is described by the :abbr:`LSA` ID
field.
IP Network Mask
The body of the External LSA describes the IP Network Mask of the route.
This, together with the :abbr:`LSA` ID, describes the prefix of the IP route
concerned.
* IP Network Mask
Metric
The cost of the External Route. This cost may be an OSPF cost (also known as
a "Type 1" metric), i.e. equivalent to the normal OSPF costs, or an
externally derived cost ("Type 2" metric) which is not comparable to OSPF
costs and always considered larger than any OSPF cost. Where there are both
Type 1 and 2 External routes for a route, the Type 1 is always preferred.
The body of the External LSA describes the IP Network Mask of the
route. This, together with the :abbr:`LSA` ID, describes the prefix
of the IP route concerned.
Forwarding Address
The address of the router to forward packets to for the route. This may be,
and usually is, left as 0 to specify that the ASBR originating the External
:abbr:`LSA` should be used. There must be an internal OSPF route to the
forwarding address, for the forwarding address to be useable.
* Metric
The cost of the External Route. This cost may be an OSPF cost (also
known as a "Type 1" metric), i.e. equivalent to the normal OSPF costs,
or an externally derived cost ("Type 2" metric) which is not comparable
to OSPF costs and always considered larger than any OSPF cost. Where
there are both Type 1 and 2 External routes for a route, the Type 1 is
always preferred.
* Forwarding Address
The address of the router to forward packets to for the route. This may
be, and usually is, left as 0 to specify that the ASBR originating the
External :abbr:`LSA` should be used. There must be an internal OSPF
route to the forwarding address, for the forwarding address to be
useable.
* Tag
An arbitrary 4-bytes of data, not interpreted by OSPF, which may
carry whatever information about the route which OSPF speakers desire.
Tag
An arbitrary 4-bytes of data, not interpreted by OSPF, which may carry
whatever information about the route which OSPF speakers desire.
AS External LSA Example
^^^^^^^^^^^^^^^^^^^^^^^
To illustrate, below is an example of an External :abbr:`LSA` in the
:abbr:`LSDB` of an OSPF router. It describes a route to the IP prefix
of 192.168.165.0/24, originated by the ASBR with Router-ID
192.168.0.49. The metric of 20 is external to OSPF. The forwarding
address is 0, so the route should forward to the originating ASBR if
selected.
:abbr:`LSDB` of an OSPF router. It describes a route to the IP prefix of
192.168.165.0/24, originated by the ASBR with Router-ID 192.168.0.49. The
metric of 20 is external to OSPF. The forwarding address is 0, so the route
should forward to the originating ASBR if selected.
::
@ -540,44 +513,33 @@ selected.
We can add this to our partial topology from above, which now looks
like:
::
like:::
--------------------- Network: ......
| Designated Router IP: 192.168.1.3
|
IP: 192.168.1.3 /---- External route: 192.168.165.0/24
(transit link) / Cost: 20 (External metric)
(cost: 10) /
Router ID: 192.168.0.49(stub)---------- IP: 192.168.3.190/32
(cost: 10) (cost: 39063)
(transit link)
IP: 192.168.0.49
|
|
------------------------------ Network: 192.168.0.48/29
| | | Designated Router IP: 192.168.0.49
| | |
| | Router ID: 192.168.0.54
| |
| Router ID: 192.168.0.53
|
Router ID: 192.168.0.52
--------------------- Network: ......
| Designated Router IP: 192.168.1.3
|
IP: 192.168.1.3 /---- External route: 192.168.165.0/24
(transit link) / Cost: 20 (External metric)
(cost: 10) /
Router ID: 192.168.0.49(stub)---------- IP: 192.168.3.190/32
(cost: 10) (cost: 39063)
(transit link)
IP: 192.168.0.49
|
|
------------------------------ Network: 192.168.0.48/29
| | | Designated Router IP: 192.168.0.49
| | |
| | Router ID: 192.168.0.54
| |
| 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.
.. _OSPF_Flooding:
OSPF Flooding
-------------
.. _OSPF_Areas:
OSPF Areas
----------
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.

1723
doc/user/ospfd.rst
View File

File diff suppressed because it is too large Load Diff

168
doc/user/protocol.rst
View File

@ -7,34 +7,30 @@ Zebra Protocol
Overview of the Zebra Protocol
==============================
Zebra Protocol is used by protocol daemons to communicate with the
zebra daemon.
Zebra Protocol is used by protocol daemons to communicate with the zebra
daemon.
Each protocol daemon may request and send information to and from the
zebra daemon such as interface states, routing state,
nexthop-validation, and so on. Protocol daemons may also install routes
with zebra. The zebra daemon manages which route is installed into the
forwarding table with the kernel.
Each protocol daemon may request and send information to and from the zebra
daemon such as interface states, routing state, nexthop-validation, and so on.
Protocol daemons may also install routes with zebra. The zebra daemon manages
which route is installed into the forwarding table with the kernel.
Zebra Protocol is a streaming protocol, with a common header. Two
versions of the header are in use. Version 0 is implicitely versioned.
Version 1 has an explicit version field. Version 0 can be distinguished
from all other versions by examining the 3rd byte of the header, which
contains a marker value for all versions bar version 0. The marker byte
corresponds to the command field in version 0, and the marker value is
a reserved command in version 0.
Zebra Protocol is a streaming protocol, with a common header. Two versions of
the header are in use. Version 0 is implicitely versioned. Version 1 has an
explicit version field. Version 0 can be distinguished from all other versions
by examining the 3rd byte of the header, which contains a marker value for all
versions bar version 0. The marker byte corresponds to the command field in
version 0, and the marker value is a reserved command in version 0.
We do not anticipate there will be further versions of the header for
the foreseeable future, as the command field in version 1 is wide
enough to allow for future extensions to done compatibly through
seperate commands.
We do not anticipate there will be further versions of the header for the
foreseeable future, as the command field in version 1 is wide enough to allow
for future extensions to done compatibly through seperate commands.
Version 0 is used by all versions of GNU Zebra as of this writing, and
versions of Quagga up to and including Quagga 0.98. Version 2 was created
for 0.99.21 of Quagga. Version 3 designates VRF compatibility and was
released in 1.0. Version 4 will be used as of FRR 2.0 to indicate that
we are a different Routing Suite now and to hopefully prevent accidental
Quagga <-> FRR issues.
Version 0 is used by all versions of GNU Zebra as of this writing, and versions
of Quagga up to and including Quagga 0.98. Version 2 was created for 0.99.21 of
Quagga. Version 3 designates VRF compatibility and was released in 1.0.
Version 4 will be used as of FRR 2.0 to indicate that we are a different
Routing Suite now and to hopefully prevent accidental Quagga <-> FRR issues.
Zebra Protocol Definition
=========================
@ -44,11 +40,11 @@ Zebra Protocol Header (version 0)
::
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+---------------+
| Length (2) | Command (1) |
+-------------------------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+---------------+
| Length (2) | Command (1) |
+-------------------------------+---------------+
Zebra Protocol Common Header (version 1)
@ -56,73 +52,71 @@ Zebra Protocol Common Header (version 1)
::
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+---------------+-------------+
| Length (2) | Marker (1) | Version (1) |
+-------------------------------+---------------+-------------+
| Command (2) |
+-------------------------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+---------------+-------------+
| Length (2) | Marker (1) | Version (1) |
+-------------------------------+---------------+-------------+
| Command (2) |
+-------------------------------+
Zebra Protocol Header Field Definitions
---------------------------------------
@table @samp
@item Length
Total packet length including this header. The minimum length is 3
bytes for version 0 messages and 6 bytes for version 1 messages.
Length
Total packet length including this header. The minimum length is 3 bytes for
version 0 messages and 6 bytes for version 1 messages.
@item Marker
Static marker with a value of 255 always. This is to allow version 0
Zserv headers (which do not include version explicitely) to be
distinguished from versioned headers. Not present in version 0
messages.
Marker
Static marker with a value of 255 always. This is to allow version 0 Zserv
headers (which do not include version explicitly) to be distinguished from
versioned headers. Not present in version 0 messages.
@item Version
Version number of the Zserv message. Clients should not continue
processing messages past the version field for versions they do not
recognise. Not present in version 0 messages.
Version
Version number of the Zserv message. Clients should not continue processing
messages past the version field for versions they do not recognise. Not
present in version 0 messages.
Command
The Zebra Protocol command.
@item Command
The Zebra Protocol command.
@end table
Zebra Protocol Commands
-----------------------
@multitable {ZEBRA_REDISTRIBUTE_DEFAULT_DELETE_WHATEVER} {99999}
@headitem Command @tab Value
@item ZEBRA_INTERFACE_ADD
@tab 1
@item ZEBRA_INTERFACE_DELETE
@tab 2
@item ZEBRA_INTERFACE_ADDRESS_ADD
@tab 3
@item ZEBRA_INTERFACE_ADDRESS_DELETE
@tab 4
@item ZEBRA_INTERFACE_UP
@tab 5
@item ZEBRA_INTERFACE_DOWN
@tab 6
@item ZEBRA_IPV4_ROUTE_ADD
@tab 7
@item ZEBRA_IPV4_ROUTE_DELETE
@tab 8
@item ZEBRA_IPV6_ROUTE_ADD
@tab 9
@item ZEBRA_IPV6_ROUTE_DELETE
@tab 10
@item ZEBRA_REDISTRIBUTE_ADD
@tab 11
@item ZEBRA_REDISTRIBUTE_DELETE
@tab 12
@item ZEBRA_REDISTRIBUTE_DEFAULT_ADD
@tab 13
@item ZEBRA_REDISTRIBUTE_DEFAULT_DELETE
@tab 14
@item ZEBRA_IPV4_NEXTHOP_LOOKUP
@tab 15
@item ZEBRA_IPV6_NEXTHOP_LOOKUP
@tab 16
@end multitable
+-----------------------------------+-------+
| Command | Value |
+===================================+=======+
| ZEBRA_INTERFACE_ADD | 1 |
+-----------------------------------+-------+
| ZEBRA_INTERFACE_DELETE | 2 |
+-----------------------------------+-------+
| ZEBRA_INTERFACE_ADDRESS_ADD | 3 |
+-----------------------------------+-------+
| ZEBRA_INTERFACE_ADDRESS_DELETE | 4 |
+-----------------------------------+-------+
| ZEBRA_INTERFACE_UP | 5 |
+-----------------------------------+-------+
| ZEBRA_INTERFACE_DOWN | 6 |
+-----------------------------------+-------+
| ZEBRA_IPV4_ROUTE_ADD | 7 |
+-----------------------------------+-------+
| ZEBRA_IPV4_ROUTE_DELETE | 8 |
+-----------------------------------+-------+
| ZEBRA_IPV6_ROUTE_ADD | 9 |
+-----------------------------------+-------+
| ZEBRA_IPV6_ROUTE_DELETE | 10 |
+-----------------------------------+-------+
| ZEBRA_REDISTRIBUTE_ADD | 11 |
+-----------------------------------+-------+
| ZEBRA_REDISTRIBUTE_DELETE | 12 |
+-----------------------------------+-------+
| ZEBRA_REDISTRIBUTE_DEFAULT_ADD | 13 |
+-----------------------------------+-------+
| ZEBRA_REDISTRIBUTE_DEFAULT_DELETE | 14 |
+-----------------------------------+-------+
| ZEBRA_IPV4_NEXTHOP_LOOKUP | 15 |
+-----------------------------------+-------+
| ZEBRA_IPV6_NEXTHOP_LOOKUP | 16 |
+-----------------------------------+-------+

799
doc/user/ripd.rst
View File

File diff suppressed because it is too large Load Diff

84
doc/user/ripngd.rst
View File

@ -4,16 +4,16 @@
RIPng
*****
*ripngd* supports the RIPng protocol as described in RFC2080. It's an
IPv6 reincarnation of the RIP protocol.
*ripngd* supports the RIPng protocol as described in :rfc:`2080`. It's an IPv6
reincarnation of the RIP protocol.
.. _Invoking_ripngd:
Invoking ripngd
===============
There are no `ripngd` specific invocation options. Common options
can be specified (:ref:`Common_Invocation_Options`).
There are no `ripngd` specific invocation options. Common options can be
specified (:ref:`Common_Invocation_Options`).
.. _ripngd_Configuration:
@ -22,72 +22,68 @@ ripngd Configuration
Currently ripngd supports the following commands:
.. index:: Command {router ripng} {}
.. index:: router ripng
.. clicmd:: router ripng
Command {router ripng} {}
Enable RIPng.
Enable RIPng.
.. index:: {RIPng Command} {flush_timer `time`} {}
.. index:: flush_timer TIME
.. clicmd:: flush_timer TIME
{RIPng Command} {flush_timer `time`} {}
Set flush timer.
Set flush timer.
.. index:: {RIPng Command} {network `network`} {}
.. index:: network NETWORK
.. clicmd:: network NETWORK
{RIPng Command} {network `network`} {}
Set RIPng enabled interface by `network`
Set RIPng enabled interface by NETWORK.
.. index:: {RIPng Command} {network `ifname`} {}
.. index:: network IFNAME
.. clicmd:: network IFNAME
{RIPng Command} {network `ifname`} {}
Set RIPng enabled interface by `ifname`
Set RIPng enabled interface by IFNAME.
.. index:: {RIPng Command} {route `network`} {}
.. index:: route NETWORK
.. clicmd:: route NETWORK
{RIPng Command} {route `network`} {}
Set RIPng static routing announcement of `network`.
Set RIPng static routing announcement of NETWORK.
.. index:: Command {router zebra} {}
.. index:: router zebra
.. clicmd:: router zebra
Command {router zebra} {}
This command is the default and does not appear in the configuration.
With this statement, RIPng routes go to the *zebra* daemon.
This command is the default and does not appear in the configuration. With
this statement, RIPng routes go to the *zebra* daemon.
.. _ripngd_Terminal_Mode_Commands:
ripngd Terminal Mode Commands
=============================
.. index:: Command {show ip ripng} {}
.. index:: show ip ripng
.. clicmd:: show ip ripng
Command {show ip ripng} {}
.. index:: show debugging ripng
.. clicmd:: show debugging ripng
.. index:: Command {show debugging ripng} {}
.. index:: debug ripng events
.. clicmd:: debug ripng events
Command {show debugging ripng} {}
.. index:: Command {debug ripng events} {}
.. index:: debug ripng packet
.. clicmd:: debug ripng packet
Command {debug ripng events} {}
.. index:: Command {debug ripng packet} {}
.. index:: debug ripng zebra
.. clicmd:: debug ripng zebra
Command {debug ripng packet} {}
.. index:: Command {debug ripng zebra} {}
Command {debug ripng zebra} {}
ripngd Filtering Commands
=========================
.. index:: Command {distribute-list `access_list` (in|out) `ifname`} {}
.. index:: distribute-list ACCESS_LIST (in|out) IFNAME
.. clicmd:: distribute-list ACCESS_LIST (in|out) IFNAME
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 ``in`` or ``out``. If `direct` is
``in``, the access-list is applied only to incoming packets.
::
distribute-list local-only out sit1
You can apply an access-list to the interface using the `distribute-list`
command. ACCESS_LIST is an access-list name. `direct` is ``in`` or
``out``. If `direct` is ``in``, the access-list is applied only to incoming
packets.::
distribute-list local-only out sit1

2
doc/user/routemap.rst
View File

@ -269,6 +269,6 @@ A simple example of a route-map:
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
See :ref:`bgp-configuration-examples` for examples of more sophisticated
useage of route-maps, including of the ``call`` action.

337
doc/user/rpki.rst
View File

@ -3,33 +3,26 @@
Prefix Origin Validation Using RPKI
===================================
Prefix Origin Validation allows BGP routers to verify if the origin AS of
an IP prefix is legitimate to announce this IP prefix. The required
attestation objects are stored in the Resource Public Key Infrastructure
(:abbr:`RPKI`). However, RPKI-enabled routers do not store cryptographic
data itself but only validation information. The validation of the
cryptographic data (so called Route Origin Authorization, or short
:abbr:`ROA`, objects) will be performed by trusted cache servers. The
RPKI/RTR protocol defines a standard mechanism to maintain the exchange of
the prefix/origin AS mapping between the cache server and routers.
In combination with a BGP Prefix Origin Validation scheme a router is able
to verify received BGP updates without suffering from cryptographic
complexity.
Prefix Origin Validation allows BGP routers to verify if the origin AS of an IP
prefix is legitimate to announce this IP prefix. The required attestation
objects are stored in the Resource Public Key Infrastructure (:abbr:`RPKI`).
However, RPKI-enabled routers do not store cryptographic data itself but only
validation information. The validation of the cryptographic data (so called
Route Origin Authorization, or short :abbr:`ROA`, objects) will be performed by
trusted cache servers. The RPKI/RTR protocol defines a standard mechanism to
maintain the exchange of the prefix/origin AS mapping between the cache server
and routers. In combination with a BGP Prefix Origin Validation scheme a
router is able to verify received BGP updates without suffering from
cryptographic complexity.
The RPKI/RTR protocol is defined in :rfc:`6810` and the validation scheme in
:rfc:`6811`. The current version of Prefix Origin Validation in FRR implements
both RFCs.
For a more detailed but still easy-to-read background, we suggest the
following two articles:
For a more detailed but still easy-to-read background, we suggest:
* @cite{Geoff Huston, Randy Bush: Securing BGP, In: The Internet
Protocol Journal, Volume 14, No. 2, 2011.}
`http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-2/142_bgp.html <http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-2/142_bgp.html>`_
* @cite{Geoff Huston: Resource Certification, In: The Internet Protocol
Journal, Volume 12, No.1, 2009.}
`http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-1/121_resource.html <http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-1/121_resource.html>`_
- [Securing-BGP]_
- [Resource-Certification]_
.. _Features_of_the_Current_Implementation:
@ -38,24 +31,19 @@ Features of the Current Implementation
In a nutshell, the current implementation provides the following features
* The BGP router can connect to one or more RPKI cache servers to
receive validated prefix to origin AS mappings.
Advanced failover can be implemented by server sockets with different
preference values.
* If no connection to an RPKI cache server can be established after a
- The BGP router can connect to one or more RPKI cache servers to receive
validated prefix to origin AS mappings. Advanced failover can be implemented
by server sockets with different preference values.
- If no connection to an RPKI cache server can be established after a
pre-defined timeout, the router will process routes without prefix origin
validation. It still will try to establish a connection to an RPKI cache
server in the background.
* By default, enabling RPKI does not change best path selection. In
particular, invalid prefixes will still be considered during best path
selection. However, the router can be configured to ignore all invalid
prefixes.
* Route maps can be configured to match a specific RPKI validation
state. This allows the creation of local policies, which handle BGP routes
based on the outcome of the Prefix Origin Validation.
- By default, enabling RPKI does not change best path selection. In particular,
invalid prefixes will still be considered during best path selection.
However, the router can be configured to ignore all invalid prefixes.
- Route maps can be configured to match a specific RPKI validation state. This
allows the creation of local policies, which handle BGP routes based on the
outcome of the Prefix Origin Validation.
.. _Enabling_RPKI:
@ -63,101 +51,96 @@ In a nutshell, the current implementation provides the following features
Enabling RPKI
-------------
.. index:: {Command} {rpki} {}
.. index:: rpki
.. clicmd:: rpki
{Command} {rpki} {}
This command enables the RPKI configuration mode. Most commands that start
with *rpki* can only be used in this mode.
This command enables the RPKI configuration mode. Most commands that start
with *rpki* can only be used in this mode.
When it is used in a telnet session, leaving of this mode cause rpki to be initialized.
When it is used in a telnet session, leaving of this mode cause rpki to be initialized.
Executing this command alone does not activate prefix
validation. You need to configure at least one reachable cache server. See section
:ref:`Configuring_RPKI/RTR_Cache_Servers` for configuring a cache server.
Executing this command alone does not activate prefix validation. You need
to configure at least one reachable cache server. See section
:ref:`configuring-rpki-rtr-cache-servers` for configuring a cache server.
.. _Configuring_RPKI/RTR_Cache_Servers:
.. _configuring-rpki-rtr-cache-servers:
Configuring RPKI/RTR Cache Servers
----------------------------------
The following commands are independent of a specific cache server.
.. index:: {RPKI Command} {rpki polling_period (1-3600)} {}
.. index:: rpki polling_period (1-3600)
.. clicmd:: rpki polling_period (1-3600)
{RPKI Command} {rpki polling_period (1-3600)} {}
.. index:: {RPKI Command} {no rpki polling_period} {}
.. index:: no rpki polling_period
.. clicmd:: no rpki polling_period
{RPKI Command} {no rpki polling_period} {}
Set the number of seconds the router waits until the router asks the cache again
for updated data.
Set the number of seconds the router waits until the router asks the cache
again for updated data.
The default value is 300 seconds.
The default value is 300 seconds.
.. index:: {RPKI Command} {rpki timeout <1-4,294,967,296>} {}
.. index:: rpki timeout <1-4,294,967,296>
.. clicmd:: rpki timeout <1-4,294,967,296>
{RPKI Command} {rpki timeout <1-4,294,967,296>} {}
.. index:: {RPKI Command} {no rpki timeout} {}
.. index:: no rpki timeout
.. clicmd:: no rpki timeout
{RPKI Command} {no rpki timeout} {}
Set the number of seconds the router waits for the cache reply. If the
cache server is not replying within this time period, the router deletes
all received prefix records from the prefix table.
Set the number of seconds the router waits for the cache reply. If the cache
server is not replying within this time period, the router deletes all
received prefix records from the prefix table.
The default value is 600 seconds.
The default value is 600 seconds.
.. index:: {RPKI Command} {rpki initial-synchronisation-timeout <1-4,294,967,296>} {}
.. index:: rpki initial-synchronisation-timeout <1-4,294,967,296>
.. clicmd:: rpki initial-synchronisation-timeout <1-4,294,967,296>
{RPKI Command} {rpki initial-synchronisation-timeout <1-4,294,967,296>} {}
.. index:: {RPKI Command} {no rpki initial-synchronisation-timeout} {}
.. index:: no rpki initial-synchronisation-timeout
.. clicmd:: no rpki initial-synchronisation-timeout
{RPKI Command} {no rpki initial-synchronisation-timeout} {}
Set the number of seconds until the first synchronization with the cache
server needs to be completed. If the timeout expires, BGP routing is
started without RPKI. The router will try to establish the cache server
connection in the background.
Set the number of seconds until the first synchronization with the cache
server needs to be completed. If the timeout expires, BGP routing is started
without RPKI. The router will try to establish the cache server connection in
the background.
The default value is 30 seconds.
The default value is 30 seconds.
The following commands configure one or multiple cache servers.
The following commands configure one or multiple cache servers.
.. index:: {RPKI Socket Command} {rpki cache (`A.B.C.D`|`WORD`) `PORT` [`SSH_USERNAME`] [`SSH_PRIVKEY_PATH`] [`SSH_PUBKEY_PATH`] [`KNOWN_HOSTS_PATH`] `PREFERENCE`} {}
.. index:: rpki cache (A.B.C.D|WORD) PORT [SSH_USERNAME] [SSH_PRIVKEY_PATH] [SSH_PUBKEY_PATH] [KNOWN_HOSTS_PATH] PREFERENCE
.. clicmd:: rpki cache (A.B.C.D|WORD) PORT [SSH_USERNAME] [SSH_PRIVKEY_PATH] [SSH_PUBKEY_PATH] [KNOWN_HOSTS_PATH] PREFERENCE
{RPKI Socket Command} {rpki cache (`A.B.C.D`|`WORD`) `PORT` [`SSH_USERNAME`] [`SSH_PRIVKEY_PATH`] [`SSH_PUBKEY_PATH`] [`KNOWN_HOSTS_PATH`] `PREFERENCE`} {}
.. index:: {RPKI Socket Command} {no rpki cache (`A.B.C.D`|`WORD`) [`PORT`] `PREFERENCE`} {}
.. index:: no rpki cache (A.B.C.D|WORD) [PORT] PREFERENCE
.. clicmd:: no rpki cache (A.B.C.D|WORD) [PORT] PREFERENCE
{RPKI Socket Command} {no rpki cache (`A.B.C.D`|`WORD`) [`PORT`] `PREFERENCE`} {}
Add a cache server to the socket. By default, the connection between
router and cache server is based on plain TCP. Protecting the connection
between router and cache server by SSH is optional.
Deleting a socket removes the associated cache server and
terminates the existing connection.
Add a cache server to the socket. By default, the connection between router
and cache server is based on plain TCP. Protecting the connection between
router and cache server by SSH is optional. Deleting a socket removes the
associated cache server and terminates the existing connection.
A.B.C.D|WORD
Address of the cache server.
PORT
Port number to connect to the cache server
SSH_USERNAME
SSH username to establish an SSH connection to the cache server.
*`A.B.C.D`|`WORD`*
Address of the cache server.
SSH_PRIVKEY_PATH
Local path that includes the private key file of the router.
*`PORT`*
Port number to connect to the cache server
SSH_PUBKEY_PATH
Local path that includes the public key file of the router.
*`SSH_USERNAME`*
SSH username to establish an SSH connection to the cache server.
*`SSH_PRIVKEY_PATH`*
Local path that includes the private key file of the router.
*`SSH_PUBKEY_PATH`*
Local path that includes the public key file of the router.
*`KNOWN_HOSTS_PATH`*
Local path that includes the known hosts file. The default value depends on the
configuration of the operating system environment, usually
:file:`~/.ssh/known_hosts`.
KNOWN_HOSTS_PATH
Local path that includes the known hosts file. The default value depends
on the configuration of the operating system environment, usually
:file:`~/.ssh/known_hosts`.
.. _Validating_BGP_Updates:
@ -165,35 +148,36 @@ The following commands are independent of a specific cache server.
Validating BGP Updates
----------------------
.. index:: {Route Map Command} {match rpki {notfound|invalid|valid}} {}
.. index:: match rpki notfound|invalid|valid
.. clicmd:: match rpki notfound|invalid|valid
{Route Map Command} {match rpki {notfound|invalid|valid}} {}
.. index:: {Route Map Command} {no match rpki {notfound|invalid|valid}} {}
.. index:: no match rpki notfound|invalid|valid
.. clicmd:: no match rpki notfound|invalid|valid
{Route Map Command} {no match rpki {notfound|invalid|valid}} {}
Create a clause for a route map to match prefixes with the specified RPKI state.
Create a clause for a route map to match prefixes with the specified RPKI
state.
**Note** that the matching of invalid prefixes requires that invalid
prefixes are considered for best path selection, i.e., @command{bgp
bestpath prefix-validate disallow-invalid} is not enabled.
prefixes are considered for best path selection, i.e.,
``bgp bestpath prefix-validate disallow-invalid`` is not enabled.
In the following example, the router prefers valid routes over invalid
prefixes because invalid routes have a lower local preference.
::
! Allow for invalid routes in route selection process
route bgp 60001
!
! Set local preference of invalid prefixes to 10
route-map rpki permit 10
match rpki invalid
set local-preference 10
!
! Set local preference of valid prefixes to 500
route-map rpki permit 500
match rpki valid
set local-preference 500
::
! Allow for invalid routes in route selection process
route bgp 60001
!
! Set local preference of invalid prefixes to 10
route-map rpki permit 10
match rpki invalid
set local-preference 10
!
! Set local preference of valid prefixes to 500
route-map rpki permit 500
match rpki valid
set local-preference 500
.. _Debugging:
@ -201,76 +185,77 @@ Validating BGP Updates
Debugging
---------
.. index:: {Command} {debug rpki} {}
.. index:: debug rpki
.. clicmd:: debug rpki
{Command} {debug rpki} {}
.. index:: {Command} {no debug rpki} {}
.. index:: no debug rpki
.. clicmd:: no debug rpki
{Command} {no debug rpki} {}
Enable or disable debugging output for RPKI.
Enable or disable debugging output for RPKI.
.. _Displaying_RPKI:
Displaying RPKI
---------------
.. index:: {Command} {show rpki prefix-table} {}
.. index:: show rpki prefix-table
.. clicmd:: show rpki prefix-table
{Command} {show rpki prefix-table} {}
Display all validated prefix to origin AS mappings/records which have been
received from the cache servers and stored in the router. Based on this data,
the router validates BGP Updates.
Display all validated prefix to origin AS mappings/records which have been
received from the cache servers and stored in the router. Based on this data,
the router validates BGP Updates.
.. index:: {Command} {show rpki cache-connection} {}
.. index:: show rpki cache-connection
.. clicmd:: show rpki cache-connection
{Command} {show rpki cache-connection} {}
Display all configured cache servers, whether active or not.
Display all configured cache servers, whether active or not.
RPKI Configuration Example
--------------------------
::
hostname bgpd1
password zebra
! log stdout
debug bgp updates
debug bgp keepalives
debug rpki
!
rpki
rpki polling_period 1000
rpki timeout 10
! SSH Example:
rpki cache example.com 22 rtr-ssh ./ssh_key/id_rsa ./ssh_key/id_rsa.pub preference 1
! TCP Example:
rpki cache rpki-validator.realmv6.org 8282 preference 2
exit
!
router bgp 60001
bgp router-id 141.22.28.223
network 192.168.0.0/16
neighbor 123.123.123.0 remote-as 60002
neighbor 123.123.123.0 route-map rpki in
!
address-family ipv6
neighbor 123.123.123.0 activate
neighbor 123.123.123.0 route-map rpki in
exit-address-family
!
route-map rpki permit 10
match rpki invalid
set local-preference 10
!
route-map rpki permit 20
match rpki notfound
set local-preference 20
!
route-map rpki permit 30
match rpki valid
set local-preference 30
!
route-map rpki permit 40
!
hostname bgpd1
password zebra
! log stdout
debug bgp updates
debug bgp keepalives
debug rpki
!
rpki
rpki polling_period 1000
rpki timeout 10
! SSH Example:
rpki cache example.com 22 rtr-ssh ./ssh_key/id_rsa ./ssh_key/id_rsa.pub preference 1
! TCP Example:
rpki cache rpki-validator.realmv6.org 8282 preference 2
exit
!
router bgp 60001
bgp router-id 141.22.28.223
network 192.168.0.0/16
neighbor 123.123.123.0 remote-as 60002
neighbor 123.123.123.0 route-map rpki in
!
address-family ipv6
neighbor 123.123.123.0 activate
neighbor 123.123.123.0 route-map rpki in
exit-address-family
!
route-map rpki permit 10
match rpki invalid
set local-preference 10
!
route-map rpki permit 20
match rpki notfound
set local-preference 20
!
route-map rpki permit 30
match rpki valid
set local-preference 30
!
route-map rpki permit 40
!
.. [Securing-BGP] `Geoff Huston, Randy Bush: Securing BGP, In: The Internet Protocol Journal, Volume 14, No. 2, 2011. <http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_14-2/142_bgp.html>`_
.. [Resource-Certification] `Geoff Huston: Resource Certification, In: The Internet Protocol Journal, Volume 12, No.1, 2009. <http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-1/121_resource.html>`_

210
doc/user/snmp.rst
View File

@ -4,69 +4,68 @@
SNMP Support
************
:abbr:`SNMP (Simple Network Managing Protocol)` is a widely implemented
feature for collecting network information from router and/or host.
FRR itself does not support SNMP agent (server daemon) functionality
but is able to connect to a SNMP agent using the SMUX protocol
(:rfc:`1227`) or the AgentX protocol (:rfc:`2741`) and make the
routing protocol MIBs available through it.
:abbr:`SNMP (Simple Network Managing Protocol)` is a widely implemented feature
for collecting network information from router and/or host. FRR itself does
not support SNMP agent (server daemon) functionality but is able to connect to
a SNMP agent using the SMUX protocol (:rfc:`1227`) or the AgentX protocol
(:rfc:`2741`) and make the routing protocol MIBs available through it.
Note that SNMP Support needs to be enabled at compile-time and loaded as
module on daemon startup. Refer to :ref:`Loadable_Module_Support` on
the latter.
Note that SNMP Support needs to be enabled at compile-time and loaded as module
on daemon startup. Refer to :ref:`Loadable_Module_Support` on the latter.
.. _Getting_and_installing_an_SNMP_agent:
Getting and installing an SNMP agent
====================================
There are several SNMP agent which support SMUX or AgentX. We recommend to use the latest
version of `net-snmp` which was formerly known as `ucd-snmp`.
It is free and open software and available at `http://www.net-snmp.org/ <http://www.net-snmp.org/>`_
and as binary package for most Linux distributions.
`net-snmp` has to be compiled with `--with-mib-modules=agentx` to
be able to accept connections from FRR using AgentX protocol or with
`--with-mib-modules=smux` to use SMUX protocol.
There are several SNMP agent which support SMUX or AgentX. We recommend to use
the latest version of `net-snmp` which was formerly known as `ucd-snmp`. It is
free and open software and available at `http://www.net-snmp.org/ <http://www.net-snmp.org/>`_
and as binary package for most Linux distributions. `net-snmp` has to be
compiled with `--with-mib-modules=agentx` to be able to accept connections from
FRR using AgentX protocol or with `--with-mib-modules=smux` to use SMUX
protocol.
Nowadays, SMUX is a legacy protocol. The AgentX protocol should be
preferred for any new deployment. Both protocols have the same coverage.
Nowadays, SMUX is a legacy protocol. The AgentX protocol should be preferred
for any new deployment. Both protocols have the same coverage.
.. _AgentX_configuration:
AgentX configuration
====================
.. program:: configure
To enable AgentX protocol support, FRR must have been build with the
`--enable-snmp` or `--enable-snmp=agentx` option. Both the
master SNMP agent (snmpd) and each of the FRR daemons must be
configured. In `/etc/snmp/snmpd.conf`, `master agentx`
directive should be added. In each of the FRR daemons, `agentx`
command will enable AgentX support.
:option:`--enable-snmp` or `--enable-snmp=agentx` option. Both the
master SNMP agent (snmpd) and each of the FRR daemons must be configured. In
:file:`/etc/snmp/snmpd.conf`, the ``master agentx`` directive should be added.
In each of the FRR daemons, ``agentx`` command will enable AgentX support.
::
/etc/snmp/snmpd.conf:
#
# example access restrictions setup
#
com2sec readonly default public
group MyROGroup v1 readonly
view all included .1 80
access MyROGroup "" any noauth exact all none none
#
# enable master agent for AgentX subagents
#
master agentx
/etc/snmp/snmpd.conf:
#
# example access restrictions setup
#
com2sec readonly default public
group MyROGroup v1 readonly
view all included .1 80
access MyROGroup "" any noauth exact all none none
#
# enable master agent for AgentX subagents
#
master agentx
/etc/frr/ospfd.conf:
! ... the rest of ospfd.conf has been omitted for clarity ...
!
agentx
!
/etc/frr/ospfd.conf:
! ... the rest of ospfd.conf has been omitted for clarity ...
!
agentx
!
Upon successful connection, you should get something like this in the
log of each FRR daemons:
Upon successful connection, you should get something like this in the log of
each FRR daemons:
::
@ -82,17 +81,17 @@ Then, you can use the following command to check everything works as expected:
[...]
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
was built. If need to configure FRR to use another transport, you can
configure it through `/etc/snmp/frr.conf`:
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 was built. If
need to configure FRR to use another transport, you can configure it through
:file:`/etc/snmp/frr.conf`:
::
/etc/snmp/frr.conf:
[snmpd]
# Use a remote master agent
agentXSocket tcp:192.168.15.12:705
/etc/snmp/frr.conf:
[snmpd]
# Use a remote master agent
agentXSocket tcp:192.168.15.12:705
.. _SMUX_configuration:
@ -101,68 +100,66 @@ SMUX configuration
==================
To enable SMUX protocol support, FRR must have been build with the
`--enable-snmp=smux` option.
:option:`--enable-snmp` option.
A separate connection has then to be established between the
SNMP agent (snmpd) and each of the FRR daemons. This connections
each use different OID numbers and passwords. Be aware that this OID
number is not the one that is used in queries by clients, it is solely
used for the intercommunication of the daemons.
A separate connection has then to be established between the SNMP agent (snmpd)
and each of the FRR daemons. This connections each use different OID numbers
and passwords. Be aware that this OID number is not the one that is used in
queries by clients, it is solely used for the intercommunication of the
daemons.
In the following example the ospfd daemon will be connected to the
snmpd daemon using the password "frr_ospfd". For testing it is
recommending to take exactly the below snmpd.conf as wrong access
restrictions can be hard to debug.
In the following example the ospfd daemon will be connected to the snmpd daemon
using the password "frr_ospfd". For testing it is recommending to take exactly
the below snmpd.conf as wrong access restrictions can be hard to debug.
::
/etc/snmp/snmpd.conf:
#
# example access restrictions setup
#
com2sec readonly default public
group MyROGroup v1 readonly
view all included .1 80
access MyROGroup "" any noauth exact all none none
#
# the following line is relevant for FRR
#
smuxpeer .1.3.6.1.4.1.3317.1.2.5 frr_ospfd
/etc/snmp/snmpd.conf:
#
# example access restrictions setup
#
com2sec readonly default public
group MyROGroup v1 readonly
view all included .1 80
access MyROGroup "" any noauth exact all none none
#
# the following line is relevant for FRR
#
smuxpeer .1.3.6.1.4.1.3317.1.2.5 frr_ospfd
/etc/frr/ospf:
! ... the rest of ospfd.conf has been omitted for clarity ...
!
smux peer .1.3.6.1.4.1.3317.1.2.5 frr_ospfd
!
/etc/frr/ospf:
! ... the rest of ospfd.conf has been omitted for clarity ...
!
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:
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]: accepted smux peer: \\
oid GNOME-PRODUCT-ZEBRA-MIB::ospfd, frr-0.96.5
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
# 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.
If that is a problem you should consider to patch snmpd and comment out the
troublesome `snmp_log()` line in the function
`netsnmp_agent_check_packet()` in `agent/snmp_agent.c`.
troublesome `snmp_log()` line in the function `netsnmp_agent_check_packet()` in
`agent/snmp_agent.c`.
MIB and command reference
=========================
The following OID numbers are used for the interprocess communication of snmpd and
the FRR daemons with SMUX only.
::
the FRR daemons with SMUX only.::
(OIDs below .iso.org.dod.internet.private.enterprises)
. (OIDs below .iso.org.dod.internet.private.enterprises)
zebra .1.3.6.1.4.1.3317.1.2.1 .gnome.gnomeProducts.zebra.zserv
bgpd .1.3.6.1.4.1.3317.1.2.2 .gnome.gnomeProducts.zebra.bgpd
ripd .1.3.6.1.4.1.3317.1.2.3 .gnome.gnomeProducts.zebra.ripd
@ -171,8 +168,7 @@ the FRR daemons with SMUX only.
Sadly, SNMP has not been implemented in all daemons yet. The following
OID numbers are used for querying the SNMP daemon by a client:
::
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
@ -181,26 +177,24 @@ OID numbers are used for querying the SNMP daemon by a client:
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`} {}
The following syntax is understood by the FRR daemons for configuring SNMP
using SMUX:
{Command} {smux peer `oid`} {}
.. index:: {Command} {no smux peer `oid`} {}
.. index:: smux peer OID
.. clicmd:: smux peer OID
.. index:: no smux peer OID
.. clicmd:: no smux peer OID
.. index:: smux peer OID PASSWORD
.. clicmd:: smux peer OID PASSWORD
.. index:: no smux peer OID PASSWORD
.. clicmd:: no smux peer OID PASSWORD
{Command} {no smux peer `oid`} {}
Here is the syntax for using AgentX:
.. index:: {Command} {smux peer `oid` `password`} {}
.. index:: agentx
.. clicmd:: agentx
.. index:: no agentx
.. clicmd:: no agentx
{Command} {smux peer `oid` `password`} {}
.. index:: {Command} {no smux peer `oid` `password`} {}
{Command} {no smux peer `oid` `password`} {}
Here is the syntax for using AgentX:
.. index:: {Command} {agentx} {}
{Command} {agentx} {}
.. index:: {Command} {no agentx} {}
{Command} {no agentx} {}
.. include:: snmptrap.rst

30
doc/user/snmptrap.rst
View File

@ -1,18 +1,18 @@
Handling SNMP Traps
===================
To handle snmp traps make sure your snmp setup of frr works
correctly as described in the frr documentation in :ref:`SNMP_Support`.
To handle snmp traps make sure your snmp setup of frr works 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:
The BGP4 mib will send traps on peer up/down events. These should be visible in
your snmp logs with a message similar to:
::
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`:
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`:
::
@ -20,9 +20,9 @@ your trapsink by adding the following lines to :file:`/etc/snmpd/snmpd.conf`:
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.
Configure the snmptrapd daemon by adding the following line to
This will send all traps to an snmptrapd running on localhost. You can of
course also use a dedicated management station to catch traps. Configure the
snmptrapd daemon by adding the following line to
:file:`/etc/snmpd/snmptrapd.conf`:
::
@ -32,15 +32,15 @@ Configure the snmptrapd daemon by adding the following line to
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
appropriate OID from their mib. (For additional information about which
traps are supported by your mib, lookup the mib on
appropriate OID from their mib. (For additional information about which traps
are supported by your mib, lookup the mib on
`http://www.oidview.com/mibs/detail.html <http://www.oidview.com/mibs/detail.html>`_).
Make sure snmptrapd is started.
Make sure *snmptrapd* is started.
The snmptrap_handle.sh script I personally use for handling BGP4 traps
is below. You can of course do all sorts of things when handling traps,
like sound a siren, have your display flash, etc., be creative ;).
The snmptrap_handle.sh script I personally use for handling BGP4 traps is
below. You can of course do all sorts of things when handling traps, like sound
a siren, have your display flash, etc., be creative ;).
::

1279
doc/user/vnc.rst
View File

File diff suppressed because it is too large Load Diff

208
doc/user/vtysh.rst
View File

@ -4,56 +4,58 @@
VTY shell
*********
*vtysh* provides a combined frontend to all FRR daemons in a
single combined session. It is enabled by default at build time, but can
be disabled through the *--disable-vtysh* option to
*./configure*.
.. program:: configure
*vtysh* has a configuration file, :file:`vtysh.conf`. The location
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.
*vtysh* provides a combined frontend to all FRR daemons in a single combined
session. It is enabled by default at build time, but can be disabled through
the :option:`--disable-vtysh` option to the configure script.
*vtysh* has a configuration file, :file:`vtysh.conf`. The location of that
file cannot be changed from |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.
.. warning::
This also means the ``hostname`` and ``banner motd`` commands (which both do
have effect for vtysh) need to be manually updated in :file:`vtysh.conf`.
@quotation Warning
This also means the *hostname* and *banner motd* commands
(which both do have effect for vtysh) need to be manually updated in
:file:`vtysh.conf`.
@end quotation
Permissions and setup requirements
==================================
*vtysh* connects to running daemons through Unix sockets located in
: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).
|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 *|INSTALL_VTY_GROUP|* group.
To restrict access to FRR configuration, make sure no unauthorized users 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 *|PACKAGE_NAME|* as service
name. No other (accounting, session, password change) calls will be
performed by vtysh.
vtysh has working (but rather useless) PAM support. It will perform 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 *|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
*|INSTALL_VTY_GROUP|* group. @strong{No security guarantees are
made for this configuration}.
Users using vtysh still need to have appropriate access to the daemons' 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 |INSTALL_VTY_GROUP| group.
.. index:: {Command} {username `username` nopassword} {}
.. warning::
No security guarantees are made for this configuration.
.. index:: username USERNAME nopassword
.. clicmd:: username USERNAME nopassword
{Command} {username `username` nopassword} {}
If PAM support is enabled at build-time, this command allows disabling the
use of PAM on a per-user basis. If vtysh finds that an user is trying to
use of PAM on a per-user basis. If vtysh finds that an user is trying to
use vtysh and a "nopassword" entry is found, no calls to PAM will be made
at all.
@ -64,108 +66,98 @@ Integrated configuration mode
=============================
Integrated configuration mode uses a single configuration file,
:file:`frr.conf`, for all daemons. This replaces the individual files like
: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:`|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
its settings to the individual daemons.
:file:`frr.conf` is located in |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 its settings to the individual daemons.
.. warning::
*vtysh -b* must also be executed after restarting any daemon.
@quotation Warning
*vtysh -b* must also be executed after restarting any daemon.
@end quotation
Configuration saving, file ownership and permissions
----------------------------------------------------
The :file:`frr.conf` file is not written by any of the daemons; instead
*vtysh* contains the neccessary logic to collect configuration from
all of the daemons, combine it and write it out.
The :file:`frr.conf` file is not written by any of the daemons; instead *vtysh*
contains the neccessary logic to collect configuration from all of the daemons,
combine it and write it out.
@quotation Warning
Daemons must be running for *vtysh* to be able to collect their
configuration. Any configuration from non-running daemons is permanently
lost after doing a configuration save.
@end quotation
.. warning::
Since the *vtysh* command may be running as ordinary user on the
system, configuration writes will be tried through *watchfrr*,
using the *write integrated* command internally. Since
*watchfrr* is running as superuser, *vtysh* is able to
ensure correct ownership and permissions on :file:`frr.conf`.
Daemons must be running for *vtysh* to be able to collect their
configuration. Any configuration from non-running daemons is permanently
lost after doing a configuration save.
If *watchfrr* is not running or the configuration write fails,
*vtysh* will attempt to directly write to the file. This is likely
to fail if running as unprivileged user; alternatively it may leave the
file with incorrect owner or permissions.
Since the *vtysh* command may be running as ordinary user on the system,
configuration writes will be tried through *watchfrr*, using the ``write
integrated`` command internally. Since *watchfrr* is running as superuser,
*vtysh* is able to ensure correct ownership and permissions on
:file:`frr.conf`.
Writing the configuration can be triggered directly by invoking
*vtysh -w*. This may be useful for scripting. Note this command
should be run as either the superuser or the FRR user.
If *watchfrr* is not running or the configuration write fails, *vtysh* will
attempt to directly write to the file. This is likely to fail if running as
unprivileged user; alternatively it may leave the file with incorrect owner or
permissions.
We recommend you do not mix the use of the two types of files. Further, it
is better not to use the integrated frr.conf file, as any syntax error in
it can lead to /all/ of your daemons being unable to start up. Per daemon
files are more robust as impact of errors in configuration are limited to
the daemon in whose file the error is made.
Writing the configuration can be triggered directly by invoking *vtysh -w*.
This may be useful for scripting. Note this command should be run as either the
superuser or the FRR user.
.. index:: {Command} {service integrated-vtysh-config} {}
We recommend you do not mix the use of the two types of files. Further, it is
better not to use the integrated :file:`frr.conf` file, as any syntax error in
it can lead to /all/ of your daemons being unable to start up. Per daemon files
are more robust as impact of errors in configuration are limited to the daemon
in whose file the error is made.
{Command} {service integrated-vtysh-config} {}
.. index:: {Command} {no service integrated-vtysh-config} {}
.. index:: service integrated-vtysh-config
.. clicmd:: service integrated-vtysh-config
{Command} {no service integrated-vtysh-config} {}
Control whether integrated :file:`frr.conf` file is written when
'write file' is issued.
.. index:: no service integrated-vtysh-config
.. clicmd:: no service integrated-vtysh-config
These commands need to be placed in :file:`vtysh.conf` to have any effect.
Note that since :file:`vtysh.conf` is not written by FRR itself, they
therefore need to be manually placed in that file.
Control whether integrated :file:`frr.conf` file is written when
'write file' is issued.
This command has 3 states:
These commands need to be placed in :file:`vtysh.conf` to have any effect.
Note that since :file:`vtysh.conf` is not written by FRR itself, they
therefore need to be manually placed in that file.
This command has 3 states:
``
*service integrated-vtysh-config*
service integrated-vtysh-config
*vtysh* will always write :file:`frr.conf`.
``
*no service integrated-vtysh-config*
no service integrated-vtysh-config
*vtysh* will never write :file:`frr.conf`; instead it will ask
daemons to write their individual configuration files.
``
Neither option present (default)
*vtysh* will check whether :file:`frr.conf` exists. If it does,
configuration writes will update that file. Otherwise, writes are performed
Neither option present (default)
*vtysh* will check whether :file:`frr.conf` exists. If it does,
configuration writes will update that file. Otherwise, writes are performed
through the individual daemons.
This command is primarily intended for packaging/distribution purposes, to
preset one of the two operating modes and ensure consistent operation across
installations.
This command is primarily intended for packaging/distribution purposes, to
preset one of the two operating modes and ensure consistent operation across
installations.
.. index:: {Command} {write integrated} {}
.. index:: write integrated
.. clicmd:: write integrated
{Command} {write integrated} {}
Unconditionally (regardless of *service integrated-vtysh-config*
setting) write out integrated :file:`frr.conf` file through
*watchfrr*. If *watchfrr* is not running, this command
is unavailable.
Unconditionally (regardless of ``service integrated-vtysh-config`` setting)
write out integrated :file:`frr.conf` file through *watchfrr*. If *watchfrr*
is not running, this command is unavailable.
.. warning::
Caveats
=======
Configuration changes made while some daemon is not running will be invisible
to that daemon. The daemon will start up with its saved configuration
(either in its individual configuration file, or in :file:`frr.conf`).
This is particularly troublesome for route-maps and prefix lists, which would
otherwise be synchronized between daemons.
Configuration changes made while some daemon is not running will be
invisible to that daemon. The daemon will start up with its saved
configuration (either in its individual configuration file, or in
:file:`frr.conf`). This is particularly troublesome for route-maps and
prefix lists, which would otherwise be synchronized between daemons.