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