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

211
doc/user/filter.rst
View File

@ -2,196 +2,177 @@
Filtering Filtering
********* *********
FRR provides many very flexible filtering features. Filtering is used FRR provides many very flexible filtering features. Filtering is used
for both input and output of the routing information. Once filtering is for both input and output of the routing information. Once filtering is
defined, it can be applied in any direction. defined, it can be applied in any direction.
@comment node-name, next, previous, up
IP Access List 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:: access-list NAME deny IPV4-NETWORK
.. index:: {Command} {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
============== ==============
*ip prefix-list* provides the most powerful prefix based *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 *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. 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. 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:: ip prefix-list NAME seq NUMBER (permit|deny) PREFIX [le LEN] [ge LEN]
.. index:: {Command} {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.
seq
seq `number` can be set either automatically or manually. In the
*@asis{seq}*
seq `number` can be set either automatically or manually. In the
case that sequential numbers are set manually, the user may pick any 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) 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 after a list with a specified sequential number, the list will
automatically pick the next multiple of five (5) as the list number. 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 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 lists 2 and 7 already exist and a new list with no specified number is
created, the new list will be numbered 10. 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}* ge
*le* command specifies prefix length. The prefix list will be Specifies prefix length. The prefix list will be applied if the prefix
applied if the prefix length is less than or equal to the le prefix length. length is greater than or equal to the ge prefix length.
*@asis{ge}* Less than or equal to prefix numbers and greater than or equal to
*ge* command specifies prefix length. The prefix list will be prefix numbers can be used together. The order of the le and ge
applied if the prefix length is greater than or equal to the ge prefix length. 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 If a list with the same sequential number as a previous list is created,
prefix numbers can be used together. The order of the le and ge the new list will overwrite the old list.
commands does not matter.
If a prefix list with a different sequential number but with the exact Matching of IP Prefix is performed from the smaller sequential number to the
same rules as a previous list is created, an error will result. larger. The matching will stop once any rule has been applied.
However, in the case that the sequential number and the rules are
exactly similar, no error will result.
If a list with the same sequential number as a previous list is created, In the case of no le or ge command, the prefix length must match exactly the
the new list will overwrite the old list. length specified in the prefix list.
Matching of IP Prefix is performed from the smaller sequential number to the .. index:: no ip prefix-list NAME
larger. The matching will stop once any rule has been applied. .. clicmd:: no ip prefix-list NAME
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`} {}
.. _ip_prefix-list_description: .. _ip_prefix-list_description:
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
Descriptions may be added to prefix lists. This command adds a description to the prefix list.
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
Deletes the description from a prefix list. It is possible to use the command without the full description.
command without the full description.
.. _ip_prefix-list_sequential_number_control: .. _ip_prefix-list_sequential_number_control:
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.
With this command, the IP prefix list sequential number is displayed. This is the default behavior.
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
With this command, the IP prefix list sequential number is not displayed.
displayed.
.. _Showing_ip_prefix-list: .. _Showing_ip_prefix-list:
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
Show IP prefix list can be used with a prefix list name and sequential number.
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
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
or longer than the specified length will be displayed. match is used, the first prefix length match 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} {} .. index:: show ip prefix-list NAME A.B.C.D/M longer
.. clicmd:: show ip prefix-list NAME A.B.C.D/M longer
{Command} {show ip prefix-list `name` `a.b.c.d/m` longer} {} .. index:: show ip prefix-list NAME A.B.C.D/M first-match
.. index:: {Command} {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
{Command} {show ip prefix-list `name` `a.b.c.d/m` first-match} {} .. clicmd:: show ip prefix-list summary
.. index:: {Command} {show ip prefix-list summary} {} .. index:: show ip prefix-list summary NAME
.. clicmd:: show ip prefix-list summary NAME
{Command} {show ip prefix-list summary} {} .. index:: show ip prefix-list detail
.. index:: {Command} {show ip prefix-list summary `name`} {} .. clicmd:: show ip prefix-list detail
.. index:: show ip prefix-list detail NAME
{Command} {show ip prefix-list summary `name`} {} .. clicmd:: show ip prefix-list detail 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`} {}
Clear counter of ip prefix-list 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
Clears the counters of all IP prefix lists. Clear IP Prefix List can be with a specified name and prefix.
used with a specified name and prefix.
.. index:: {Command} {clear ip prefix-list `name`} {} .. index:: clear ip prefix-list NAME
.. clicmd:: 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 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. Build without SNMP support.
.. option:: --disable-vtysh
Build without VTYSH.
You may specify any combination of the above options to the configure You may specify any combination of the above options to the configure
script. By default, the executables are placed in :file:`/usr/local/sbin` 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 IPv6 Support
************ ************
FRR fully supports IPv6 routing. As described so far, Frr supports FRR fully supports IPv6 routing. As described so far, Frr supports RIPng,
RIPng, OSPFv3, and BGP-4+. You can give IPv6 addresses to an interface OSPFv3, and BGP-4+. You can give IPv6 addresses to an interface and configure
and configure static IPv6 routing information. FRR IPv6 also provides static IPv6 routing information. FRR IPv6 also provides automatic address
automatic address configuration via a feature called ``address auto configuration``. To do it, the router must send router advertisement configuration via a feature called ``address auto configuration``. To do it,
messages to the all nodes that exist on the network. 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 Previous versions of FRR could be built without IPv6 support. This is
no longer possible. no longer possible.
@ -17,177 +18,176 @@ Router Advertisement
==================== ====================
.. index:: no ipv6 nd suppress-ra .. index:: no ipv6 nd suppress-ra
.. clicmd:: no ipv6 nd suppress-ra .. clicmd:: no ipv6 nd suppress-ra
Send router advertisment messages. Send router advertisment messages.
.. index:: ipv6 nd suppress-ra .. index:: ipv6 nd suppress-ra
.. clicmd:: ipv6 nd suppress-ra .. clicmd:: ipv6 nd suppress-ra
Don't send router advertisment messages. Don't send router advertisment messages.
.. index:: ipv6 nd prefix ipv6prefix [valid-lifetime] [preferred-lifetime] [off-link] [no-autoconfig] [router-address] .. 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] .. 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 Configuring the IPv6 prefix to include in router advertisements. Several prefix
valid for the purpose of on-link determination. Value ``infinite`` represents specific optional parameters and flags may follow:
infinity (i.e. a value of all one bits (``0xffffffff``)).
Range: ``(0-4294967295)`` Default: ``2592000``
- ``preferred-lifetime``: the length of time in seconds during what addresses - ``valid-lifetime``: the length of time in seconds during what the prefix is
generated from the prefix remain preferred. Value ``infinite`` represents valid for the purpose of on-link determination. Value ``infinite`` represents
infinity. infinity (i.e. a value of all one bits (``0xffffffff``)).
Range: ``(0-4294967295)`` Default: ``604800`` Range: ``(0-4294967295)`` Default: ``2592000``
- ``off-link``: indicates that advertisement makes no statement about on-link or - ``preferred-lifetime``: the length of time in seconds during what addresses
off-link properties of the prefix. generated from the prefix remain preferred. Value ``infinite`` represents
Default: not set, i.e. this prefix can be used for on-link determination. infinity.
Range: ``(0-4294967295)`` Default: ``604800``
- ``no-autoconfig``: indicates to hosts on the local link that the specified prefix - ``off-link``: indicates that advertisement makes no statement about on-link or
cannot be used for IPv6 autoconfiguration. 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 Default: not set, i.e. prefix can be used for autoconfiguration.
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. - ``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:: .. index::
single: no ipv6 nd ra-interval [(1-1800)] single: no ipv6 nd ra-interval [(1-1800)]
single: no ipv6 nd ra-interval [(1-1800)] single: no ipv6 nd ra-interval [(1-1800)]
.. clicmd:: [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. The maximum time allowed between sending unsolicited multicast router
Default: ``600`` advertisements from the interface, in seconds.
Default: ``600``
.. index:: ipv6 nd ra-interval msec (70-1800000) .. index:: ipv6 nd ra-interval msec (70-1800000)
.. index:: .. index::
single: no ipv6 nd ra-interval [msec (70-1800000)] single: no ipv6 nd ra-interval [msec (70-1800000)]
single: ipv6 nd ra-interval msec (70-1800000) single: ipv6 nd ra-interval msec (70-1800000)
.. clicmd:: [no] 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. The maximum time allowed between sending unsolicited multicast router
Default: ``600000`` advertisements from the interface, in milliseconds.
Default: ``600000``
.. index:: .. index::
single: ipv6 nd ra-lifetime (0-9000) single: ipv6 nd ra-lifetime (0-9000)
single: no ipv6 nd ra-lifetime [(0-9000)] single: no ipv6 nd ra-lifetime [(0-9000)]
.. clicmd:: [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 The value to be placed in the Router Lifetime field of router advertisements
as a default router on this interface. Setting the value to zero indicates sent from the interface, in seconds. Indicates the usefulness of the router
that the router should not be considered a default router on this interface. as a default router on this interface. Setting the value to zero indicates
Must be either zero or between value specified with ``ipv6 nd ra-interval`` that the router should not be considered a default router on this interface.
(or default) and 9000 seconds. Must be either zero or between value specified with ``ipv6 nd ra-interval``
Default: ``1800`` (or default) and 9000 seconds.
Default: ``1800``
.. index:: .. index::
single: no ipv6 nd reachable-time [(1-3600000)] single: no ipv6 nd reachable-time [(1-3600000)]
single: ipv6 nd reachable-time (1-3600000) single: ipv6 nd reachable-time (1-3600000)
.. clicmd:: [no] 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 The value to be placed in the Reachable Time field in the Router
router to detect unavailable neighbors. The value zero means unspecified (by Advertisement messages sent by the router, in milliseconds. The configured
this router). time enables the router to detect unavailable neighbors. The value zero
Default: ``0`` means unspecified (by this router).
Default: ``0``
.. index:: .. index::
single: ipv6 nd managed-config-flag single: ipv6 nd managed-config-flag
single: no ipv6 nd managed-config-flag single: no ipv6 nd managed-config-flag
.. clicmd:: [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 Set/unset flag in IPv6 router advertisements which indicates to hosts that
addition to any addresses autoconfigured using stateless address they should use managed (stateful) protocol for addresses autoconfiguration
autoconfiguration. in addition to any addresses autoconfigured using stateless address
Default: not set autoconfiguration.
Default: not set
.. index:: .. index::
single: ipv6 nd other-config-flag single: ipv6 nd other-config-flag
single: no ipv6 nd other-config-flag single: no ipv6 nd other-config-flag
.. clicmd:: [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 Set/unset flag in IPv6 router advertisements which indicates to hosts that
information other than addresses. they should use administered (stateful) protocol to obtain autoconfiguration
Default: not set information other than addresses.
Default: not set
.. index:: .. index::
single: ipv6 nd home-agent-config-flag single: ipv6 nd home-agent-config-flag
single: no ipv6 nd home-agent-config-flag single: no ipv6 nd home-agent-config-flag
.. clicmd:: [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. Set/unset flag in IPv6 router advertisements which indicates to hosts that
Default: not set 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:: ipv6 nd home-agent-preference (0-65535)
.. index:: .. index::
single: no ipv6 nd home-agent-preference [(0-65535)] single: no ipv6 nd home-agent-preference [(0-65535)]
single: ipv6 nd home-agent-preference (0-65535) single: ipv6 nd home-agent-preference (0-65535)
.. clicmd:: [no] 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 The value to be placed in Home Agent Option, when Home Agent config flag is
for the lowest preference possible. set, which indicates to hosts Home Agent preference. The default value of 0
Default: ``0`` stands for the lowest preference possible.
Default: ``0``
.. index:: .. index::
single: ipv6 nd home-agent-lifetime (0-65520) single: ipv6 nd home-agent-lifetime (0-65520)
single: no 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)] .. 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:: .. index::
single: ipv6 nd adv-interval-option single: ipv6 nd adv-interval-option
single: no ipv6 nd adv-interval-option single: no ipv6 nd adv-interval-option
.. clicmd:: [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. Include an Advertisement Interval option which indicates to hosts the maximum time,
Default: not set in milliseconds, between successive unsolicited Router Advertisements.
Default: not set
.. index:: .. index::
single: ipv6 nd router-preference (high|medium|low) single: ipv6 nd router-preference (high|medium|low)
single: no 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)] .. 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:: .. index::
single: ipv6 nd mtu (1-65535) single: ipv6 nd mtu (1-65535)
single: no ipv6 nd mtu [(1-65535)] single: no ipv6 nd mtu [(1-65535)]
.. clicmd:: [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.:: Include an MTU (type 5) option in each RA packet to assist the attached
interface eth0 hosts in proper interface configuration. The announced value is not verified
no ipv6 nd suppress-ra to be consistent with router interface MTU.
ipv6 nd prefix 2001:0DB8:5009::/64
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 .. seealso::
:t:`RFC2462 (IPv6 Stateless Address Autoconfiguration)`,
:t:`RFC4861 (Neighbor Discovery for IP Version 6 (IPv6))`, - :rfc:`2462` (IPv6 Stateless Address Autoconfiguration)
:t:`RFC6275 (Mobility Support in IPv6)` and - :rfc:`4861` (Neighbor Discovery for IP Version 6 (IPv6))
:t:`RFC4191 (Default Router Preferences and More-Specific Routes)`. - :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 NHRP
**** ****
*nhrpd* is a daemon to support Next Hop Routing Protocol (NHRP). *nhrpd* is an implementation of the :abbr:NHRP `(Next Hop Routing Protocol)`.
NHRP is described in RFC2332. NHRP is described in :rfc`2332`.
NHRP is used to improve the efficiency of routing computer network NHRP is used to improve the efficiency of routing computer network traffic over
traffic over Non-Broadcast, Multiple Access (NBMA) Networks. NHRP provides :abbr:`NBMA (Non-Broadcast, Multiple Access)` networks. NHRP provides an
an ARP-like solution that allows a system to dynamically learn the NBMA ARP-like solution that allows a system to dynamically learn the NBMA address of
address of the other systems that are part of that network, allowing the other systems that are part of that network, allowing these systems to
these systems to directly communicate without requiring traffic to use directly communicate without requiring traffic to use an intermediate hop.
an intermediate hop.
Cisco Dynamic Multipoint VPN (DMVPN) is based on NHRP, and Cisco Dynamic Multipoint VPN (DMVPN) is based on NHRP, and |PACKAGE_NAME| nhrpd
|PACKAGE_NAME| nhrpd implements this scenario. implements this scenario.
.. _Routing_Design: .. _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 This is similar to Cisco FlexVPN; but in contrast to opennhrp which uses
a generic subnet route. a generic subnet route.
To create NBMA GRE tunnel you might use the following (linux terminal To create NBMA GRE tunnel you might use the following (Linux terminal
commands): commands):::
::
ip tunnel add gre1 mode gre key 42 ttl 64 ip tunnel add gre1 mode gre key 42 ttl 64
ip addr add 10.255.255.2/32 dev gre1 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. 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 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 router bgp 65555
address-family ipv4 unicast 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. if needed. However, the above should be good in most cases.
This kernel NFLOG target's nflog-group is configured in global nhrp config This kernel NFLOG target's nflog-group is configured in global nhrp config
with: with:::
::
nhrp nflog-group 1 nhrp nflog-group 1
To start sending these traffic notices out from hubs, use the nhrp To start sending these traffic notices out from hubs, use the nhrp
per-interface directive: per-interface directive:::
::
interface gre1 interface gre1
ip nhrp redirect ip nhrp redirect
.. _Integration_with_IKE: .. _Integration_with_IKE:
Integration with IKE Integration with IKE

219
doc/user/ospf6d.rst
View File

@ -4,82 +4,79 @@
OSPFv3 OSPFv3
****** ******
*ospf6d* is a daemon support OSPF version 3 for IPv6 network. *ospf6d* is a daemon support OSPF version 3 for IPv6 network. OSPF for IPv6 is
OSPF for IPv6 is described in RFC2740. described in :rfc:`2740`.
.. _OSPF6_router: .. _OSPF6_router:
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`} {} .. index:: interface IFNAME area AREA
Set router's Router-ID. .. 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`} {} .. index:: timers throttle spf DELAY INITIAL-HOLDTIME MAX-HOLDTIME
Bind interface to specified area, and start sending OSPF packets. `area` can .. clicmd:: timers throttle spf DELAY INITIAL-HOLDTIME MAX-HOLDTIME
be specified as 0.
.. 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`} {} This command sets the initial `delay`, the `initial-holdtime`
.. index:: {OSPF6 Command} {no timers throttle spf} {} 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} {} The `delay` specifies the minimum amount of time to delay SPF
This command sets the initial `delay`, the `initial-holdtime` calculation (hence it affects how long SPF calculation is delayed after
and the `maximum-holdtime` between when SPF is calculated and the an event which occurs outside of the holdtime of any previous SPF
event which triggered the calculation. The times are specified in calculation, and also serves as a minimum holdtime).
milliseconds and must be in the range of 0 to 600000 milliseconds.
The `delay` specifies the minimum amount of time to delay SPF Consecutive SPF calculations will always be seperated by at least
calculation (hence it affects how long SPF calculation is delayed after 'hold-time' milliseconds. The hold-time is adaptive and initially is
an event which occurs outside of the holdtime of any previous SPF set to the `initial-holdtime` configured with the above command.
calculation, and also serves as a minimum holdtime). Events which occur within the holdtime of the previous SPF calculation
will cause the holdtime to be increased by `initial-holdtime`, bounded
Consecutive SPF calculations will always be seperated by at least by the `maximum-holdtime` configured with this command. If the adaptive
'hold-time' milliseconds. The hold-time is adaptive and initially is hold-time elapses without any SPF-triggering event occuring then
set to the `initial-holdtime` configured with the above command. the current holdtime is reset to the `initial-holdtime`.::
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 router ospf6
timers throttle spf 200 400 10000 timers throttle spf 200 400 10000
In this example, the `delay` is set to 200ms, the @var{initial In this example, the `delay` is set to 200ms, the initial holdtime is set
holdtime} is set to 400ms and the `maximum holdtime` to 10s. Hence to 400ms and the `maximum holdtime` to 10s. Hence there will always be at
there will always be at least 200ms between an event which requires SPF least 200ms between an event which requires SPF calculation and the actual
calculation and the actual SPF calculation. Further consecutive SPF SPF calculation. Further consecutive SPF calculations will always be
calculations will always be seperated by between 400ms to 10s, the seperated by between 400ms to 10s, the hold-time increasing by 400ms each
hold-time increasing by 400ms each time an SPF-triggering event occurs time an SPF-triggering event occurs within the hold-time of the previous
within the hold-time of the previous SPF calculation. 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:: no auto-cost reference-bandwidth
.. index:: {OSPF6 Command} {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
This sets the reference bandwidth for cost calculations, where this bandwidth is considered equivalent to an OSPF cost of 1, specified in
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
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
or higher will have a cost of 1. Cost of lower bandwidth links will be scaled with reference to this cost).
scaled with reference to this cost).
This configuration setting MUST be consistent across all routers This configuration setting MUST be consistent across all routers
within the OSPF domain. within the OSPF domain.
.. _OSPF6_area: .. _OSPF6_area:
@ -93,97 +90,97 @@ Area support for OSPFv3 is not yet implemented.
OSPF6 interface 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
Sets interface's output cost. Default value depends on the interface bandwidth and on the auto-cost reference bandwidth.
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:
Redistribute routes to OSPF6 Redistribute routes to OSPF6
============================ ============================
.. index:: {OSPF6 Command} {redistribute static} {} .. index:: redistribute static
.. clicmd:: redistribute static
{OSPF6 Command} {redistribute static} {} .. index:: redistribute connected
.. index:: {OSPF6 Command} {redistribute connected} {} .. clicmd:: redistribute connected
{OSPF6 Command} {redistribute connected} {} .. index:: redistribute ripng
.. index:: {OSPF6 Command} {redistribute ripng} {} .. clicmd:: redistribute ripng
{OSPF6 Command} {redistribute ripng} {}
.. _Showing_OSPF6_information: .. _Showing_OSPF6_information:
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 is an optional OSPF instance ID. To see router ID and OSPF instance ID, simply type "show ipv6 ospf6 <cr>".
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 OSPF6 Configuration Examples
============================ ============================
@ -192,13 +189,11 @@ Example of ospf6d configured on one interface and area:
:: ::
interface eth0 interface eth0
ipv6 ospf6 instance-id 0 ipv6 ospf6 instance-id 0
! !
router ospf6 router ospf6
router-id 212.17.55.53 router-id 212.17.55.53
area 0.0.0.0 range 2001:770:105:2::/64 area 0.0.0.0 range 2001:770:105:2::/64
interface eth0 area 0.0.0.0 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:: Link-state routing protocol
.. index:: Distance-vector routing protocol .. index:: Distance-vector routing protocol
:abbr:`OSPF` is, mostly, a link-state routing protocol. In contrast :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. routers.
.. index:: Link State Announcement .. index:: Link State Announcement
.. index:: Link State Advertisement .. index:: Link State Advertisement
.. index:: LSA flooding .. index:: LSA flooding
.. index:: Link State Database
.. index:: Link State DataBase
Each router describes their link-state information in a message known Each router describes their link-state information in a message known
as an :abbr:`LSA (Link State Advertisement)`, which is then propogated 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: 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 Areas overview
.. index:: OSPF Hello Protocol .. _ospf-areas:
The OSPF Hello protocol allows OSPF to quickly detect changes in Areas
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)`.
OSPF also uses the Hello protocol to propagate certain state between OSPF provides for the protocol to be broken up into multiple smaller and
routers sharing a link, for example: 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
*Hello protocol configured state, such as the dead-interval.* these describe *paths*, rather than any router link-states, routing between
areas hence is by :term:`distance-vector`, **not** link-state.
*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`.
OSPF LSAs OSPF LSAs
--------- ---------
:abbr:`LSA`s are the core object in OSPF. Everything else in OSPF The core objects in OSPF are :abbr:`LSA` s. Everything else in OSPF revolves
revolves around detecting what to describe in LSAs, when to update around detecting what to describe in LSAs, when to update them, how to flood
them, how to flood them throughout a network and how to calculate them throughout a network and how to calculate routes from them.
routes from them.
There are a variety of different :abbr:`LSA`s, for purposes such There are a variety of different :abbr:`LSA` s, for purposes such as describing
as describing actual link-state information, describing paths (i.e. actual link-state information, describing paths (i.e. routes), describing
routes), describing bandwidth usage of links for bandwidth usage of links for :abbr:`TE (Traffic Engineering)` purposes, and
:abbr:`TE (Traffic Engineering)` purposes, and even arbitrary data even arbitrary data by way of *Opaque* :abbr:`LSA` s.
by way of *Opaque* :abbr:`LSA`s.
LSA Header LSA Header
^^^^^^^^^^ ^^^^^^^^^^
All LSAs share a common header with the following information: 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: :abbr:`OSPF`. Types include:
* Router LSA - Router LSA
* Network LSA - Network LSA
* Network Summary LSA - Network Summary LSA
* Router Summary LSA - Router Summary LSA
* AS-External LSA - AS-External LSA
The specifics of the different types of LSA are examined below. 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`. 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 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 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 an LSA with the same Type, LSA ID and Advertising Router ID, see
:ref:`OSPF_LSA_sequence_number,,LSA_Sequence_Number`. :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. from their :abbr:`LSDB`s.
The value nominally is one of seconds. An age of 3600, i.e. 1 hour, is 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: .. _OSPF_LSA_sequence_number:
* Sequence Number - Sequence Number
A number used to distinguish newer instances of an LSA from older instances. A number used to distinguish newer instances of an LSA from older instances.
Link-State LSAs Link-State LSAs
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^
Of all the various kinds of :abbr:`LSA`s, just two types comprise 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 actual link-state part of :abbr:`OSPF`, Router :abbr:`LSA` s and
Network :abbr:`LSA`s. These LSA types are absolutely core to the Network :abbr:`LSA` s. These LSA types are absolutely core to the
protocol. protocol.
Instances of these LSAs are specific to the link-state area in which Instances of these LSAs are specific to the link-state area in which
they are originated. Routes calculated from these two LSA types are they are originated. Routes calculated from these two LSA types are
called :term:`intra-area routes`. called :term:`intra-area routes`.
* Router LSA - Router LSA
Each OSPF Router must originate a router :abbr:`LSA` to describe Each OSPF Router must originate a router :abbr:`LSA` to describe
itself. In it, the router lists each of its :abbr:`OSPF` enabled itself. In it, the router lists each of its :abbr:`OSPF` enabled
interfaces, for the given link-state area, in terms of: 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 Link Type
reference value, :ref:`OSPF_auto-cost_reference-bandwidth,,auto-cost_reference-bandwidth`. 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 Stub
Full adjacency with another router. A link with no adjacent neighbours, or a host route.
* :abbr:`PtP (Point-to-Point)` - Link ID and Data
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
These values depend on the Link Type: These values depend on the Link Type:
+----------------+-----------------------------------+------------------------------------------+ +----------------+-----------------------------------+------------------------------------------+
| Link Type | Link ID | Link Data | | Link Type | Link ID | Link Data |
+================+===================================+==========================================+ +================+===================================+==========================================+
| Transit | Link IP address of the :abbr:`DR` | Interface IP address | | 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 | | Point-to-Point | Router ID of the remote router | Local interface IP address, or the |
| | | :abbr:`ifindex (MIB-II interface index)` | | | | :abbr:`ifindex (MIB-II interface index)` |
| | | for unnumbered links | | | | for unnumbered links |
+----------------+-----------------------------------+------------------------------------------+ +----------------+-----------------------------------+------------------------------------------+
| Stub | IP address | Subnet Mask | | Stub | IP address | Subnet Mask |
+----------------+-----------------------------------+------------------------------------------+ +----------------+-----------------------------------+------------------------------------------+
Links on a router may be listed multiple times in the Router LSA, e.g. Links on a router may be listed multiple times in the Router LSA, e.g. a
a :abbr:`PtP` interface on which OSPF is enabled must *always* :abbr:`PtP` interface on which OSPF is enabled must *always* be described
be described by a Stub link in the Router :abbr:`LSA`, in addition to by a Stub link in the Router :abbr:`LSA`, in addition to being listed as
being listed as PtP link in the Router :abbr:`LSA` if the adjacency PtP link in the Router :abbr:`LSA` if the adjacency with the remote router
with the remote router is Full. is Full.
Stub links may also be used as a way to describe links on which OSPF is 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`. *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 On multi-access links (e.g. ethernets, certain kinds of ATM and X.25
configurations), routers elect a :abbr:`DR`. The :abbr:`DR` is configurations), routers elect a :abbr:`DR`. The :abbr:`DR` is
responsible for originating a Network :abbr:`LSA`, which helps reduce responsible for originating a Network :abbr:`LSA`, which helps reduce
the information needed to describe multi-access networks with multiple the information needed to describe multi-access networks with multiple
routers attached. The :abbr:`DR` also acts as a hub for the flooding of 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: 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 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 :abbr:`DR`, the Subnet Mask together with the :abbr:`LSA` ID gives
you the network address. you the network address.
* Attached Routers - Attached Routers
Each router fully-adjacent with the :abbr:`DR` is listed in the LSA, 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`. easily retrieved from the :abbr:`LSDB`.
Summary of Link State LSAs: 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 stage of :abbr:`SPF` calculation concerns itself only with these two
LSA types. LSA types.
.. _ospf-link-state-lsa-examples:
Link-State LSA Examples Link-State LSA Examples
^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
The example below (:ref:`OSPF_Link-State_LSA_Example`) shows two The example below shows two :abbr:`LSA` s, both originated by the same router
:abbr:`LSA`s, both originated by the same router (Router ID (Router ID 192.168.0.49) and with the same :abbr:`LSA` ID (192.168.0.49), but
192.168.0.49) and with the same :abbr:`LSA` ID (192.168.0.49), but of of different LSA types.
different LSA types.
The first LSA being the router LSA describing 192.168.0.49's links: 2 links 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 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 :abbr:`DR`, listing the Router IDs of 4 routers on that network which
are fully adjacent with 192.168.0.49. are fully adjacent with 192.168.0.49.
.. _OSPF_Link-State_LSA_Example:
:: ::
# show ip ospf database router 192.168.0.49 # 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 find all the attached routers on that link, leading potentially to more
links and Network and Router LSAs, etc. etc. 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: following partial topology:
:: ::
@ -458,66 +440,57 @@ reachable addresses (though, OSPF will calculate routes to Router IDs).
External LSAs 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 entirely external to :abbr:`OSPF`, and is "injected" into
:abbr:`OSPF`. Such routing information may have come from another :abbr:`OSPF`. Such routing information may have come from another
routing protocol, such as RIP or BGP, they may represent static routes routing protocol, such as RIP or BGP, they may represent static routes
or they may represent a default route. or they may represent a default route.
An :abbr:`OSPF` router which originates External :abbr:`LSA`s is known as an 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 :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 most other :abbr:`LSA` s, which are flooded only within the area in
which they originate, External :abbr:`LSA`s are flooded through-out which they originate, External :abbr:`LSA` s are flooded through-out
the :abbr:`OSPF` network to all areas capable of carrying External 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 Routes internal to OSPF (intra-area or inter-area) are always preferred
over external routes. over external routes.
The External :abbr:`LSA` describes the following: 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 IP Network Mask
field. 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 Forwarding Address
route. This, together with the :abbr:`LSA` ID, describes the prefix The address of the router to forward packets to for the route. This may be,
of the IP route concerned. 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 Tag
An arbitrary 4-bytes of data, not interpreted by OSPF, which may carry
The cost of the External Route. This cost may be an OSPF cost (also whatever information about the route which OSPF speakers desire.
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.
AS External LSA Example AS External LSA Example
^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
To illustrate, below is an example of an External :abbr:`LSA` in the 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 :abbr:`LSDB` of an OSPF router. It describes a route to the IP prefix of
of 192.168.165.0/24, originated by the ASBR with Router-ID 192.168.165.0/24, originated by the ASBR with Router-ID 192.168.0.49. The
192.168.0.49. The metric of 20 is external to OSPF. The forwarding metric of 20 is external to OSPF. The forwarding address is 0, so the route
address is 0, so the route should forward to the originating ASBR if should forward to the originating ASBR if selected.
selected.
:: ::
@ -540,44 +513,33 @@ selected.
We can add this to our partial topology from above, which now looks We can add this to our partial topology from above, which now looks
like: like:::
::
--------------------- Network: ...... --------------------- Network: ......
| Designated Router IP: 192.168.1.3 | Designated Router IP: 192.168.1.3
| |
IP: 192.168.1.3 /---- External route: 192.168.165.0/24 IP: 192.168.1.3 /---- External route: 192.168.165.0/24
(transit link) / Cost: 20 (External metric) (transit link) / Cost: 20 (External metric)
(cost: 10) / (cost: 10) /
Router ID: 192.168.0.49(stub)---------- IP: 192.168.3.190/32 Router ID: 192.168.0.49(stub)---------- IP: 192.168.3.190/32
(cost: 10) (cost: 39063) (cost: 10) (cost: 39063)
(transit link) (transit link)
IP: 192.168.0.49 IP: 192.168.0.49
| |
| |
------------------------------ Network: 192.168.0.48/29 ------------------------------ Network: 192.168.0.48/29
| | | Designated Router IP: 192.168.0.49 | | | Designated Router IP: 192.168.0.49
| | | | | |
| | Router ID: 192.168.0.54 | | Router ID: 192.168.0.54
| | | |
| Router ID: 192.168.0.53 | Router ID: 192.168.0.53
| |
Router ID: 192.168.0.52 Router ID: 192.168.0.52
Summary LSAs Summary LSAs
^^^^^^^^^^^^ ^^^^^^^^^^^^
Summary LSAs are created by :abbr:`ABR`s to summarise the destinations available within one area to other areas. These LSAs may describe IP networks, potentially in aggregated form, or :abbr:`ASBR` routers. Summary LSAs are created by :abbr:`ABR`s to summarise the destinations
available within one area to other areas. These LSAs may describe IP networks,
.. _OSPF_Flooding: potentially in aggregated form, or :abbr:`ASBR` routers.
OSPF Flooding
-------------
.. _OSPF_Areas:
OSPF Areas
----------

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

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 RIPng
***** *****
*ripngd* supports the RIPng protocol as described in RFC2080. It's an *ripngd* supports the RIPng protocol as described in :rfc:`2080`. It's an IPv6
IPv6 reincarnation of the RIP protocol. reincarnation of the RIP protocol.
.. _Invoking_ripngd: .. _Invoking_ripngd:
Invoking ripngd Invoking ripngd
=============== ===============
There are no `ripngd` specific invocation options. Common options There are no `ripngd` specific invocation options. Common options can be
can be specified (:ref:`Common_Invocation_Options`). specified (:ref:`Common_Invocation_Options`).
.. _ripngd_Configuration: .. _ripngd_Configuration:
@ -22,72 +22,68 @@ ripngd Configuration
Currently ripngd supports the following commands: 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 command is the default and does not appear in the configuration. this statement, RIPng routes go to the *zebra* daemon.
With this statement, RIPng routes go to the *zebra* daemon.
.. _ripngd_Terminal_Mode_Commands: .. _ripngd_Terminal_Mode_Commands:
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:: debug ripng packet
.. index:: Command {debug ripng events} {} .. clicmd:: debug ripng packet
Command {debug ripng events} {} .. index:: debug ripng zebra
.. index:: Command {debug ripng packet} {} .. clicmd:: debug ripng zebra
Command {debug ripng packet} {}
.. index:: Command {debug ripng zebra} {}
Command {debug ripng zebra} {}
ripngd Filtering Commands 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`
You can apply an access-list to the interface using the command. ACCESS_LIST is an access-list name. `direct` is ``in`` or
`distribute-list` command. `access_list` is an access-list ``out``. If `direct` is ``in``, the access-list is applied only to incoming
name. `direct` is ``in`` or ``out``. If `direct` is packets.::
``in``, the access-list is applied only to incoming packets.
::
distribute-list local-only out sit1
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 This means that if a route matches ip access-list number 10 it's
local-preference value is set to 200. 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. 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 Using RPKI
=================================== ===================================
Prefix Origin Validation allows BGP routers to verify if the origin AS of Prefix Origin Validation allows BGP routers to verify if the origin AS of an IP
an IP prefix is legitimate to announce this IP prefix. The required prefix is legitimate to announce this IP prefix. The required attestation
attestation objects are stored in the Resource Public Key Infrastructure objects are stored in the Resource Public Key Infrastructure (:abbr:`RPKI`).
(:abbr:`RPKI`). However, RPKI-enabled routers do not store cryptographic However, RPKI-enabled routers do not store cryptographic data itself but only
data itself but only validation information. The validation of the validation information. The validation of the cryptographic data (so called
cryptographic data (so called Route Origin Authorization, or short Route Origin Authorization, or short :abbr:`ROA`, objects) will be performed by
:abbr:`ROA`, objects) will be performed by trusted cache servers. The trusted cache servers. The RPKI/RTR protocol defines a standard mechanism to
RPKI/RTR protocol defines a standard mechanism to maintain the exchange of maintain the exchange of the prefix/origin AS mapping between the cache server
the prefix/origin AS mapping between the cache server and routers. and routers. In combination with a BGP Prefix Origin Validation scheme a
In combination with a BGP Prefix Origin Validation scheme a router is able router is able to verify received BGP updates without suffering from
to verify received BGP updates without suffering from cryptographic cryptographic complexity.
complexity.
The RPKI/RTR protocol is defined in :rfc:`6810` and the validation scheme in 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 :rfc:`6811`. The current version of Prefix Origin Validation in FRR implements
both RFCs. both RFCs.
For a more detailed but still easy-to-read background, we suggest the For a more detailed but still easy-to-read background, we suggest:
following two articles:
* @cite{Geoff Huston, Randy Bush: Securing BGP, In: The Internet - [Securing-BGP]_
Protocol Journal, Volume 14, No. 2, 2011.} - [Resource-Certification]_
`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>`_
.. _Features_of_the_Current_Implementation: .. _Features_of_the_Current_Implementation:
@ -38,24 +31,19 @@ Features of the Current Implementation
In a nutshell, the current implementation provides the following features In a nutshell, the current implementation provides the following features
* The BGP router can connect to one or more RPKI cache servers to - The BGP router can connect to one or more RPKI cache servers to receive
receive validated prefix to origin AS mappings. validated prefix to origin AS mappings. Advanced failover can be implemented
Advanced failover can be implemented by server sockets with different by server sockets with different preference values.
preference values. - If no connection to an RPKI cache server can be established after a
* If no connection to an RPKI cache server can be established after a
pre-defined timeout, the router will process routes without prefix origin pre-defined timeout, the router will process routes without prefix origin
validation. It still will try to establish a connection to an RPKI cache validation. It still will try to establish a connection to an RPKI cache
server in the background. server in the background.
- By default, enabling RPKI does not change best path selection. In particular,
* By default, enabling RPKI does not change best path selection. In invalid prefixes will still be considered during best path selection.
particular, invalid prefixes will still be considered during best path However, the router can be configured to ignore all invalid prefixes.
selection. However, the router can be configured to ignore all invalid - Route maps can be configured to match a specific RPKI validation state. This
prefixes. allows the creation of local policies, which handle BGP routes based on the
outcome of the Prefix Origin Validation.
* 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: .. _Enabling_RPKI:
@ -63,101 +51,96 @@ In a nutshell, the current implementation provides the following features
Enabling RPKI Enabling RPKI
------------- -------------
.. index:: {Command} {rpki} {} .. index:: rpki
.. clicmd:: rpki
{Command} {rpki} {} This command enables the RPKI configuration mode. Most commands that start
This command enables the RPKI configuration mode. Most commands that start with *rpki* can only be used in this mode.
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 Executing this command alone does not activate prefix validation. You need
validation. You need to configure at least one reachable cache server. See section to configure at least one reachable cache server. See section
:ref:`Configuring_RPKI/RTR_Cache_Servers` for configuring a cache server. :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 Configuring RPKI/RTR Cache Servers
---------------------------------- ----------------------------------
The following commands are independent of a specific cache server. 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:: no rpki polling_period
.. index:: {RPKI Command} {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
Set the number of seconds the router waits until the router asks the cache again again for updated data.
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:: no rpki timeout
.. index:: {RPKI Command} {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
Set the number of seconds the router waits for the cache reply. If the server is not replying within this time period, the router deletes all
cache server is not replying within this time period, the router deletes received prefix records from the prefix table.
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:: no rpki initial-synchronisation-timeout
.. index:: {RPKI Command} {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
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
server needs to be completed. If the timeout expires, BGP routing is without RPKI. The router will try to establish the cache server connection in
started without RPKI. The router will try to establish the cache server the background.
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:: no rpki cache (A.B.C.D|WORD) [PORT] PREFERENCE
.. index:: {RPKI Socket Command} {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
Add a cache server to the socket. By default, the connection between and cache server is based on plain TCP. Protecting the connection between
router and cache server is based on plain TCP. Protecting the connection router and cache server by SSH is optional. Deleting a socket removes the
between router and cache server by SSH is optional. associated cache server and terminates the existing connection.
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.
SSH_PRIVKEY_PATH
*`A.B.C.D`|`WORD`* Local path that includes the private key file of the router.
Address of the cache server.
*`PORT`* SSH_PUBKEY_PATH
Port number to connect to the cache server Local path that includes the public key file of the router.
*`SSH_USERNAME`* KNOWN_HOSTS_PATH
SSH username to establish an SSH connection to the cache server. 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`.
*`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`.
.. _Validating_BGP_Updates: .. _Validating_BGP_Updates:
@ -165,35 +148,36 @@ The following commands are independent of a specific cache server.
Validating BGP Updates 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:: no match rpki notfound|invalid|valid
.. index:: {Route Map Command} {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
Create a clause for a route map to match prefixes with the specified RPKI state. state.
**Note** that the matching of invalid prefixes requires that invalid **Note** that the matching of invalid prefixes requires that invalid
prefixes are considered for best path selection, i.e., @command{bgp prefixes are considered for best path selection, i.e.,
bestpath prefix-validate disallow-invalid} is not enabled. ``bgp bestpath prefix-validate disallow-invalid`` is not enabled.
In the following example, the router prefers valid routes over invalid In the following example, the router prefers valid routes over invalid
prefixes because invalid routes have a lower local preference. 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: .. _Debugging:
@ -201,76 +185,77 @@ Validating BGP Updates
Debugging Debugging
--------- ---------
.. index:: {Command} {debug rpki} {} .. index:: debug rpki
.. clicmd:: debug rpki
{Command} {debug rpki} {} .. index:: no debug rpki
.. index:: {Command} {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:
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
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,
received from the cache servers and stored in the router. Based on this data, the router validates BGP Updates.
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 RPKI Configuration Example
-------------------------- --------------------------
:: ::
hostname bgpd1 hostname bgpd1
password zebra password zebra
! log stdout ! log stdout
debug bgp updates debug bgp updates
debug bgp keepalives debug bgp keepalives
debug rpki debug rpki
! !
rpki rpki
rpki polling_period 1000 rpki polling_period 1000
rpki timeout 10 rpki timeout 10
! SSH Example: ! SSH Example:
rpki cache example.com 22 rtr-ssh ./ssh_key/id_rsa ./ssh_key/id_rsa.pub preference 1 rpki cache example.com 22 rtr-ssh ./ssh_key/id_rsa ./ssh_key/id_rsa.pub preference 1
! TCP Example: ! TCP Example:
rpki cache rpki-validator.realmv6.org 8282 preference 2 rpki cache rpki-validator.realmv6.org 8282 preference 2
exit exit
! !
router bgp 60001 router bgp 60001
bgp router-id 141.22.28.223 bgp router-id 141.22.28.223
network 192.168.0.0/16 network 192.168.0.0/16
neighbor 123.123.123.0 remote-as 60002 neighbor 123.123.123.0 remote-as 60002
neighbor 123.123.123.0 route-map rpki in neighbor 123.123.123.0 route-map rpki in
! !
address-family ipv6 address-family ipv6
neighbor 123.123.123.0 activate neighbor 123.123.123.0 activate
neighbor 123.123.123.0 route-map rpki in neighbor 123.123.123.0 route-map rpki in
exit-address-family exit-address-family
! !
route-map rpki permit 10 route-map rpki permit 10
match rpki invalid match rpki invalid
set local-preference 10 set local-preference 10
! !
route-map rpki permit 20 route-map rpki permit 20
match rpki notfound match rpki notfound
set local-preference 20 set local-preference 20
! !
route-map rpki permit 30 route-map rpki permit 30
match rpki valid match rpki valid
set local-preference 30 set local-preference 30
! !
route-map rpki permit 40 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 SNMP Support
************ ************
:abbr:`SNMP (Simple Network Managing Protocol)` is a widely implemented :abbr:`SNMP (Simple Network Managing Protocol)` is a widely implemented feature
feature for collecting network information from router and/or host. for collecting network information from router and/or host. FRR itself does
FRR itself does not support SNMP agent (server daemon) functionality not support SNMP agent (server daemon) functionality but is able to connect to
but is able to connect to a SNMP agent using the SMUX protocol a SNMP agent using the SMUX protocol (:rfc:`1227`) or the AgentX protocol
(:rfc:`1227`) or the AgentX protocol (:rfc:`2741`) and make the (:rfc:`2741`) and make the routing protocol MIBs available through it.
routing protocol MIBs available through it.
Note that SNMP Support needs to be enabled at compile-time and loaded as Note that SNMP Support needs to be enabled at compile-time and loaded as module
module on daemon startup. Refer to :ref:`Loadable_Module_Support` on on daemon startup. Refer to :ref:`Loadable_Module_Support` on the latter.
the latter.
.. _Getting_and_installing_an_SNMP_agent: .. _Getting_and_installing_an_SNMP_agent:
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 There are several SNMP agent which support SMUX or AgentX. We recommend to use
version of `net-snmp` which was formerly known as `ucd-snmp`. the latest version of `net-snmp` which was formerly known as `ucd-snmp`. It is
It is free and open software and available at `http://www.net-snmp.org/ <http://www.net-snmp.org/>`_ 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. and as binary package for most Linux distributions. `net-snmp` has to be
`net-snmp` has to be compiled with `--with-mib-modules=agentx` to compiled with `--with-mib-modules=agentx` to be able to accept connections from
be able to accept connections from FRR using AgentX protocol or with FRR using AgentX protocol or with `--with-mib-modules=smux` to use SMUX
`--with-mib-modules=smux` to use SMUX protocol. protocol.
Nowadays, SMUX is a legacy protocol. The AgentX protocol should be Nowadays, SMUX is a legacy protocol. The AgentX protocol should be preferred
preferred for any new deployment. Both protocols have the same coverage. for any new deployment. Both protocols have the same coverage.
.. _AgentX_configuration: .. _AgentX_configuration:
AgentX configuration AgentX configuration
==================== ====================
.. program:: configure
To enable AgentX protocol support, FRR must have been build with the To enable AgentX protocol support, FRR must have been build with the
`--enable-snmp` or `--enable-snmp=agentx` option. Both the :option:`--enable-snmp` or `--enable-snmp=agentx` option. Both the
master SNMP agent (snmpd) and each of the FRR daemons must be master SNMP agent (snmpd) and each of the FRR daemons must be configured. In
configured. In `/etc/snmp/snmpd.conf`, `master agentx` :file:`/etc/snmp/snmpd.conf`, the ``master agentx`` directive should be added.
directive should be added. In each of the FRR daemons, `agentx` In each of the FRR daemons, ``agentx`` command will enable AgentX support.
command will enable AgentX support.
:: ::
/etc/snmp/snmpd.conf: /etc/snmp/snmpd.conf:
# #
# example access restrictions setup # example access restrictions setup
# #
com2sec readonly default public com2sec readonly default public
group MyROGroup v1 readonly group MyROGroup v1 readonly
view all included .1 80 view all included .1 80
access MyROGroup "" any noauth exact all none none access MyROGroup "" any noauth exact all none none
# #
# enable master agent for AgentX subagents # enable master agent for AgentX subagents
# #
master agentx master agentx
/etc/frr/ospfd.conf: /etc/frr/ospfd.conf:
! ... the rest of ospfd.conf has been omitted for clarity ... ! ... the rest of ospfd.conf has been omitted for clarity ...
! !
agentx agentx
! !
Upon successful connection, you should get something like this in the Upon successful connection, you should get something like this in the log of
log of each FRR daemons: 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 The AgentX protocol can be transported over a Unix socket or using TCP or UDP.
or UDP. It usually defaults to a Unix socket and depends on how NetSNMP It usually defaults to a Unix socket and depends on how NetSNMP was built. If
was built. If need to configure FRR to use another transport, you can need to configure FRR to use another transport, you can configure it through
configure it through `/etc/snmp/frr.conf`: :file:`/etc/snmp/frr.conf`:
:: ::
/etc/snmp/frr.conf: /etc/snmp/frr.conf:
[snmpd] [snmpd]
# Use a remote master agent # Use a remote master agent
agentXSocket tcp:192.168.15.12:705 agentXSocket tcp:192.168.15.12:705
.. _SMUX_configuration: .. _SMUX_configuration:
@ -101,68 +100,66 @@ SMUX configuration
================== ==================
To enable SMUX protocol support, FRR must have been build with the 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 A separate connection has then to be established between the SNMP agent (snmpd)
SNMP agent (snmpd) and each of the FRR daemons. This connections and each of the FRR daemons. This connections each use different OID numbers
each use different OID numbers and passwords. Be aware that this OID and passwords. Be aware that this OID number is not the one that is used in
number is not the one that is used in queries by clients, it is solely queries by clients, it is solely used for the intercommunication of the
used for the intercommunication of the daemons. daemons.
In the following example the ospfd daemon will be connected to the In the following example the ospfd daemon will be connected to the snmpd daemon
snmpd daemon using the password "frr_ospfd". For testing it is using the password "frr_ospfd". For testing it is recommending to take exactly
recommending to take exactly the below snmpd.conf as wrong access the below snmpd.conf as wrong access restrictions can be hard to debug.
restrictions can be hard to debug.
:: ::
/etc/snmp/snmpd.conf: /etc/snmp/snmpd.conf:
# #
# example access restrictions setup # example access restrictions setup
# #
com2sec readonly default public com2sec readonly default public
group MyROGroup v1 readonly group MyROGroup v1 readonly
view all included .1 80 view all included .1 80
access MyROGroup "" any noauth exact all none none access MyROGroup "" any noauth exact all none none
# #
# the following line is relevant for FRR # the following line is relevant for FRR
# #
smuxpeer .1.3.6.1.4.1.3317.1.2.5 frr_ospfd smuxpeer .1.3.6.1.4.1.3317.1.2.5 frr_ospfd
/etc/frr/ospf: /etc/frr/ospf:
! ... the rest of ospfd.conf has been omitted for clarity ... ! ... the rest of ospfd.conf has been omitted for clarity ...
! !
smux peer .1.3.6.1.4.1.3317.1.2.5 frr_ospfd 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 After restarting snmpd and frr, a successful connection can be verified in the
the syslog and by querying the SNMP daemon: syslog and by querying the SNMP daemon:
:: ::
snmpd[12300]: [smux_accept] accepted fd 12 from 127.0.0.1:36255 snmpd[12300]: [smux_accept] accepted fd 12 from 127.0.0.1:36255
snmpd[12300]: accepted smux peer: \\ snmpd[12300]: accepted smux peer: \\
oid GNOME-PRODUCT-ZEBRA-MIB::ospfd, frr-0.96.5 oid GNOME-PRODUCT-ZEBRA-MIB::ospfd, frr-0.96.5
# snmpwalk -c public -v1 localhost .1.3.6.1.2.1.14.1.1 # snmpwalk -c public -v1 localhost .1.3.6.1.2.1.14.1.1
OSPF-MIB::ospfRouterId.0 = IpAddress: 192.168.42.109 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 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. 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 If that is a problem you should consider to patch snmpd and comment out the
troublesome `snmp_log()` line in the function troublesome `snmp_log()` line in the function `netsnmp_agent_check_packet()` in
`netsnmp_agent_check_packet()` in `agent/snmp_agent.c`. `agent/snmp_agent.c`.
MIB and command reference MIB and command reference
========================= =========================
The following OID numbers are used for the interprocess communication of snmpd and 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 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 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 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 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 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 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 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: The following syntax is understood by the FRR daemons for configuring SNMP
.. index:: {Command} {smux peer `oid`} {} using SMUX:
{Command} {smux peer `oid`} {} .. index:: smux peer OID
.. index:: {Command} {no 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 .. include:: snmptrap.rst

30
doc/user/snmptrap.rst
View File

@ -1,18 +1,18 @@
Handling SNMP Traps Handling SNMP Traps
=================== ===================
To handle snmp traps make sure your snmp setup of frr works To handle snmp traps make sure your snmp setup of frr works correctly as
correctly as described in the frr documentation in :ref:`SNMP_Support`. described in the frr documentation in :ref:`SNMP_Support`.
The BGP4 mib will send traps on peer up/down events. These should be The BGP4 mib will send traps on peer up/down events. These should be visible in
visible in your snmp logs with a message similar to: your snmp logs with a message similar to:
:: ::
snmpd[13733]: Got trap from peer on fd 14 snmpd[13733]: Got trap from peer on fd 14
To react on these traps they should be handled by a trapsink. Configure To react on these traps they should be handled by a trapsink. Configure your
your trapsink by adding the following lines to :file:`/etc/snmpd/snmpd.conf`: 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 trapsink localhost
This will send all traps to an snmptrapd running on localhost. You can This will send all traps to an snmptrapd running on localhost. You can of
of course also use a dedicated management station to catch traps. course also use a dedicated management station to catch traps. Configure the
Configure the snmptrapd daemon by adding the following line to snmptrapd daemon by adding the following line to
:file:`/etc/snmpd/snmptrapd.conf`: :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 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 the BGP4 traps. To add traps for other protocol daemons, lookup their
appropriate OID from their mib. (For additional information about which appropriate OID from their mib. (For additional information about which traps
traps are supported by your mib, lookup the mib on are supported by your mib, lookup the mib on
`http://www.oidview.com/mibs/detail.html <http://www.oidview.com/mibs/detail.html>`_). `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 The snmptrap_handle.sh script I personally use for handling BGP4 traps is
is below. You can of course do all sorts of things when handling traps, below. You can of course do all sorts of things when handling traps, like sound
like sound a siren, have your display flash, etc., be creative ;). 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 VTY shell
********* *********
*vtysh* provides a combined frontend to all FRR daemons in a .. program:: configure
single combined session. It is enabled by default at build time, but can
be disabled through the *--disable-vtysh* option to
*./configure*.
*vtysh* has a configuration file, :file:`vtysh.conf`. The location *vtysh* provides a combined frontend to all FRR daemons in a single combined
of that file cannot be changed from :file:`|INSTALL_PREFIX_ETC|` since session. It is enabled by default at build time, but can be disabled through
it contains options controlling authentication behavior. This file will the :option:`--disable-vtysh` option to the configure script.
also not be written by configuration-save commands, it is intended to be
updated manually by an administrator with an external editor. *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 Permissions and setup requirements
================================== ==================================
*vtysh* connects to running daemons through Unix sockets located in *vtysh* connects to running daemons through Unix sockets located in
:file:`|INSTALL_PREFIX_STATE|`. Running vtysh thus requires access to |INSTALL_PREFIX_STATE|. Running vtysh thus requires access to that directory,
that directory, plus membership in the *|INSTALL_VTY_GROUP|* plus membership in the |INSTALL_VTY_GROUP| group (which is the group that the
group (which is the group that the daemons will change ownership of their daemons will change ownership of their sockets to).
sockets to).
To restrict access to FRR configuration, make sure no unauthorized users To restrict access to FRR configuration, make sure no unauthorized users are
are members of the *|INSTALL_VTY_GROUP|* group. members of the |INSTALL_VTY_GROUP| group.
PAM support (experimental) PAM support (experimental)
-------------------------- --------------------------
vtysh has working (but rather useless) PAM support. It will perform vtysh has working (but rather useless) PAM support. It will perform an
an "authenticate" PAM call using *|PACKAGE_NAME|* as service "authenticate" PAM call using |PACKAGE_NAME| as service name. No other
name. No other (accounting, session, password change) calls will be (accounting, session, password change) calls will be performed by vtysh.
performed by vtysh.
Users using vtysh still need to have appropriate access to the daemons' Users using vtysh still need to have appropriate access to the daemons' VTY
VTY sockets, usually by being member of the *|INSTALL_VTY_GROUP|* sockets, usually by being member of the |INSTALL_VTY_GROUP| group. If they
group. If they have this membership, PAM support is useless since they can have this membership, PAM support is useless since they can connect to daemons
connect to daemons and issue commands using some other tool. Alternatively, and issue commands using some other tool. Alternatively, the *vtysh* binary
the *vtysh* binary could be made SGID (set group ID) to the could be made SGID (set group ID) to the |INSTALL_VTY_GROUP| group.
*|INSTALL_VTY_GROUP|* group. @strong{No security guarantees are
made for this configuration}.
.. 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 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 use vtysh and a "nopassword" entry is found, no calls to PAM will be made
at all. at all.
@ -64,108 +66,98 @@ Integrated configuration mode
============================= =============================
Integrated configuration mode uses a single configuration file, 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:`zebra.conf` or :file:`bgpd.conf`.
:file:`frr.conf` is located in :file:`|INSTALL_PREFIX_ETC|`. All :file:`frr.conf` is located in |INSTALL_PREFIX_ETC|. All daemons check for the
daemons check for the existence of this file at startup, and if it exists existence of this file at startup, and if it exists will not load their
will not load their individual configuration files. Instead, individual configuration files. Instead, ``vtysh -b`` must be invoked to
*vtysh -b* must be invoked to process :file:`frr.conf` and apply process :file:`frr.conf` and apply its settings to the individual daemons.
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 Configuration saving, file ownership and permissions
---------------------------------------------------- ----------------------------------------------------
The :file:`frr.conf` file is not written by any of the daemons; instead The :file:`frr.conf` file is not written by any of the daemons; instead *vtysh*
*vtysh* contains the neccessary logic to collect configuration from contains the neccessary logic to collect configuration from all of the daemons,
all of the daemons, combine it and write it out. combine it and write it out.
@quotation Warning .. 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
Since the *vtysh* command may be running as ordinary user on the Daemons must be running for *vtysh* to be able to collect their
system, configuration writes will be tried through *watchfrr*, configuration. Any configuration from non-running daemons is permanently
using the *write integrated* command internally. Since lost after doing a configuration save.
*watchfrr* is running as superuser, *vtysh* is able to
ensure correct ownership and permissions on :file:`frr.conf`.
If *watchfrr* is not running or the configuration write fails, Since the *vtysh* command may be running as ordinary user on the system,
*vtysh* will attempt to directly write to the file. This is likely configuration writes will be tried through *watchfrr*, using the ``write
to fail if running as unprivileged user; alternatively it may leave the integrated`` command internally. Since *watchfrr* is running as superuser,
file with incorrect owner or permissions. *vtysh* is able to ensure correct ownership and permissions on
:file:`frr.conf`.
Writing the configuration can be triggered directly by invoking If *watchfrr* is not running or the configuration write fails, *vtysh* will
*vtysh -w*. This may be useful for scripting. Note this command attempt to directly write to the file. This is likely to fail if running as
should be run as either the superuser or the FRR user. 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 Writing the configuration can be triggered directly by invoking *vtysh -w*.
is better not to use the integrated frr.conf file, as any syntax error in This may be useful for scripting. Note this command should be run as either the
it can lead to /all/ of your daemons being unable to start up. Per daemon superuser or the FRR user.
files are more robust as impact of errors in configuration are limited to
the daemon in whose file the error is made.
.. 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:: service integrated-vtysh-config
.. index:: {Command} {no service integrated-vtysh-config} {} .. clicmd:: service integrated-vtysh-config
{Command} {no service integrated-vtysh-config} {} .. index:: no service integrated-vtysh-config
Control whether integrated :file:`frr.conf` file is written when .. clicmd:: no service integrated-vtysh-config
'write file' is issued.
These commands need to be placed in :file:`vtysh.conf` to have any effect. Control whether integrated :file:`frr.conf` file is written when
Note that since :file:`vtysh.conf` is not written by FRR itself, they 'write file' is issued.
therefore need to be manually placed in that file.
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`. *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 *vtysh* will never write :file:`frr.conf`; instead it will ask
daemons to write their individual configuration files. daemons to write their individual configuration files.
Neither option present (default)
`` *vtysh* will check whether :file:`frr.conf` exists. If it does,
Neither option present (default) configuration writes will update that file. Otherwise, writes are performed
*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. through the individual daemons.
This command is primarily intended for packaging/distribution purposes, to This command is primarily intended for packaging/distribution purposes, to
preset one of the two operating modes and ensure consistent operation across preset one of the two operating modes and ensure consistent operation across
installations. installations.
.. index:: {Command} {write integrated} {} .. index:: write integrated
.. clicmd:: write integrated
{Command} {write integrated} {} Unconditionally (regardless of ``service integrated-vtysh-config`` setting)
Unconditionally (regardless of *service integrated-vtysh-config* write out integrated :file:`frr.conf` file through *watchfrr*. If *watchfrr*
setting) write out integrated :file:`frr.conf` file through is not running, this command is unavailable.
*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
Configuration changes made while some daemon is not running will be invisible :file:`frr.conf`). This is particularly troublesome for route-maps and
to that daemon. The daemon will start up with its saved configuration prefix lists, which would otherwise be synchronized between daemons.
(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.