--- /dev/null
+abr
+Admin
+AFI
+agentx
+AgentX
+APK
+apps
+ARP
+ASes
+ASv
+autoconfiguration
+Autoconfiguration
+autoconfigured
+autodetected
+babeld
+backtrace
+backtraces
+behaviour
+bgp
+bgpd
+BGPD
+blackhole
+charon
+cisco
+Cisco
+cli
+clicmd
+conf
+config
+Config
+cr
+crashlog
+dataplane
+de
+deconfigured
+deserialization
+dev
+distincts
+dstmask
+eBGP
+eigrp
+eigrpd
+EOR
+eth
+ethernet
+ethernets
+extcommunity
+failover
+fallback
+favour
+filesystem
+Flavel
+frontend
+frr
+FRR
+frrvty
+gcc
+ge
+glibc
+gre
+hardcoded
+holddown
+Holddown
+holdtime
+honour
+honoured
+hostname
+hsls
+iBGP
+ibm
+ietf
+igmp
+inet
+init
+insta
+interdomain
+internet
+ip
+IP
+iptables
+ipv
+IPv
+isis
+isisd
+lan
+le
+libc
+libcap
+libexecinfo
+Loc
+localhost
+logfile
+loopback
+lsa
+LSA
+lsas
+LSAs
+Masaki
+Mbit
+Mbits
+mib
+motd
+mpls
+mrib
+mroute
+mroutes
+mrouting
+mtu
+multicast
+Multicast
+multicasting
+multihop
+multipath
+Multipath
+Multipoint
+multiprotocol
+Multiprotocol
+namespace
+nd
+neighbour
+neighbouring
+neighbours
+Netlink
+netmask
+netmasks
+nexthop
+nexthops
+nflog
+nhrp
+NHRP
+nhrpd
+noauth
+noninterfering
+Noninterfering
+nopassword
+nve
+NVE
+opennhrp
+optimisation
+optimisations
+ospf
+OSPF
+ospfd
+pathing
+pce
+peerings
+performant
+php
+pid
+pim
+pimd
+ppp
+pre
+prepend
+Prepend
+prepended
+proc
+protobuf
+Protobuf
+PtP
+ra
+readonly
+rebalance
+reconverge
+reestablish
+reestimated
+requestlist
+reservable
+Reservable
+rfc
+RFP
+RIBs
+ripd
+Ripd
+ripng
+ripngd
+Roughan
+rp
+rpki
+rtt
+RTT
+Rxmt
+µs
+safi
+setgid
+sm
+smux
+smuxpeer
+snmp
+SNMP
+snmpd
+snmptrap
+snmptrapd
+Solaris
+src
+stateful
+stdout
+strftime
+strongSwan
+subagents
+subsubsections
+summarisation
+summarise
+summarising
+supercedes
+synchronisation
+sysctl
+syslogd
+tc
+te
+Timestamp
+tmp
+trapsink
+txt
+unicast
+Unicast
+unix
+urib
+useable
+username
+usr
+vertices
+vici
+vn
+VN
+VNC
+vrf
+vrfs
+vty
+Vty
+vtysh
+wildcard
+wildcarded
+Wilfong
+xDSL
+xFF
``fpm`` module can be loaded for the *zebra* daemon. This provides the
Forwarding Plane Manager ("FPM") API.
-The module expects its argument to be either ``netlink`` or ``protobuf``,
-specifying the encapsulation to use. ``netlink`` is the default, and
+The module expects its argument to be either ``Netlink`` or ``protobuf``,
+specifying the encapsulation to use. ``Netlink`` is the default, and
``protobuf`` may not be available if the module was built without protobuf
support. Refer to :ref:`zebra-fib-push-interface` for more information.
BGP
***
-:abbr:`BGP` stands for a Border Gateway Protocol. The lastest BGP version is 4.
-It is referred as BGP-4. BGP-4 is one of the Exterior Gateway Protocols and
-de-fact standard of Inter Domain routing protocol. BGP-4 is described in
-:rfc:`1771`.
+:abbr:`BGP` stands for a Border Gateway Protocol. The latest BGP version is 4.
+BGP-4 is one of the Exterior Gateway Protocols and the de facto standard
+interdomain routing protocol. BGP-4 is described in :rfc:`1771`.
-Many extensions have been added to :rfc:`1771`. :rfc:`2858` provides
-multiprotocol support to BGP-4.
+Many extensions have been added to :rfc:`1771`. :rfc:`2858` adds multiprotocol
+support to BGP-4.
.. _starting-bgp:
The advantage of this is that the route-selection (at this point) will be
more deterministic. The disadvantage is that a few or even one lowest-ID
- router may attract all trafic to otherwise-equal paths because of this
+ router may attract all traffic to otherwise-equal paths because of this
check. It may increase the possibility of MED or IGP oscillation, unless
other measures were taken to avoid these. The exact behaviour will be
sensitive to the iBGP and reflection topology.
.. index:: aggregate-address A.B.C.D/M summary-only
.. clicmd:: aggregate-address A.B.C.D/M summary-only
- This command specifies an aggregate address. Aggreated routes will
+ This command specifies an aggregate address. Aggregated routes will
not be announce.
.. index:: no aggregate-address A.B.C.D/M
(End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached
Established is considered an implicit-EOR.
If the establish-wait optional value is given, then BGP will wait for
- peers to reach established from the begining of the update-delay till the
+ peers to reach established from the beginning of the update-delay till the
establish-wait period is over, i.e. the minimum set of established peers for
which EOR is expected would be peers established during the establish-wait
window, not necessarily all the configured neighbors.
This command specifies an announced route's nexthop as being equivalent to
the address of the bgp router if it is learned via eBGP. If the optional
- keyword `all` is specified the modifiation is done also for routes learned
+ keyword `all` is specified the modification is done also for routes learned
via iBGP.
.. index:: neighbor PEER update-source <IFNAME|ADDRESS>
This command enforces Generalized TTL Security Mechanism (GTSM), as
specified in RFC 5082. With this command, only neighbors that are the
specified number of hops away will be allowed to become neighbors. This
- command is mututally exclusive with *ebgp-multihop*.
+ command is mutually exclusive with *ebgp-multihop*.
.. _peer-filtering:
BGP Community Lists
-------------------
-BGP community list is a user defined BGP communites attribute list. BGP
+BGP community list is a user defined BGP communities attribute list. BGP
community list can be used for matching or manipulating BGP communities
attribute in updates.
These commands delete community lists specified by NAME. All of
community lists shares a single name space. So community lists can be
- removed simpley specifying community lists name.
+ removed simply specifying community lists name.
.. index:: show ip community-list
.. clicmd:: show ip community-list
.. index:: ip community-list NAME permit|deny COMMUNITY
.. clicmd:: ip community-list NAME permit|deny COMMUNITY
- When community list type is not specifed, the community list type is
+ When community list type is not specified, the community list type is
automatically detected. If COMMUNITY can be compiled into communities
attribute, the community list is defined as a standard community list.
Otherwise it is defined as an expanded community list. This feature is left
- for backward compability. Use of this feature is not recommended.
+ for backward compatibility. Use of this feature is not recommended.
.. _bgp-community-in-route-map:
This command perform match to BGP updates using community list WORD. When
the one of BGP communities value match to the one of communities value in
- community list, it is match. When `exact-match` keyword is spcified, match
+ community list, it is match. When `exact-match` keyword is specified, match
happen only when BGP updates have completely same communities value
specified in the community list.
match community 1
-Following exmaple filter BGP routes which has communities value 1:1.
+Following example filter BGP routes which has communities value 1:1.
When there is no match community-list returns deny. To avoid
filtering all of routes, we need to define permit any at last.
These commands delete extended community lists specified by `name`. All of
extended community lists shares a single name space. So extended community
- lists can be removed simpley specifying the name.
+ lists can be removed simply specifying the name.
.. index:: show ip extcommunity-list
.. clicmd:: show ip extcommunity-list
BGP VRFs
========
-Bgpd supports multiple VRF instances via the *router bgp* command:
+BPGD supports multiple VRF instances via the *router bgp* command:
.. index:: router bgp ASN vrf VRFNAME
.. clicmd:: router bgp ASN vrf VRFNAME
.. clicmd:: route-map vpn import|export MAP
Specifies an optional route-map to be applied to routes imported or exported
- betwen the current unicast VRF and VPN.
+ between the current unicast VRF and VPN.
.. index:: no route-map vpn import|export [MAP]
.. clicmd:: no route-map vpn import|export [MAP]
.. index:: import|export vpn
.. clicmd:: import|export vpn
- Enables import or export of routes betwen the current unicast VRF and VPN.
+ Enables import or export of routes between the current unicast VRF and VPN.
.. index:: no import|export vpn
.. clicmd:: no import|export vpn
- Disables import or export of routes betwen the current unicast VRF and VPN.
+ Disables import or export of routes between the current unicast VRF and VPN.
.. _displaying-bgp-information:
Negotiation. *bgpd* use this Capability Negotiation to detect the remote peer's
capabilities. If a peer is only configured as an IPv4 unicast neighbor, *bgpd*
does not send these Capability Negotiation packets (at least not unless other
-optional BGP features require capability negotation).
+optional BGP features require capability negotiation).
By default, FRR will bring up peering with minimal common capability for the
both sides. For example, if the local router has unicast and multicast
global prefixes and NO_EXPORT prefixes and providing actions for customer
routes based on community values. Extensive use of route-maps and the 'call'
feature to support selective advertising of prefixes. This example is intended
-as guidance only, it has NOT been tested and almost certainly containts silly
+as guidance only, it has NOT been tested and almost certainly contains silly
mistakes, if not serious flaws.
.. code-block:: frr
.. include:: rpki.rst
-.. [#med-transitivity-rant] For some set of objects to have an order, there *must* be some binary ordering relation that is defined for *every* combination of those objects, and that relation *must* be transitive. I.e.:, if the relation operator is <, and if a < b and b < c then that relation must carry over and it *must* be that a < c for the objects to have an order. The ordering relation may allow for equality, i.e. a < b and b < a may both be true amd imply that a and b are equal in the order and not distinguished by it, in which case the set has a partial order. Otherwise, if there is an order, all the objects have a distinct place in the order and the set has a total order)
+.. [#med-transitivity-rant] For some set of objects to have an order, there *must* be some binary ordering relation that is defined for *every* combination of those objects, and that relation *must* be transitive. I.e.:, if the relation operator is <, and if a < b and b < c then that relation must carry over and it *must* be that a < c for the objects to have an order. The ordering relation may allow for equality, i.e. a < b and b < a may both be true and imply that a and b are equal in the order and not distinguished by it, in which case the set has a partial order. Otherwise, if there is an order, all the objects have a distinct place in the order and the set has a total order)
.. [bgp-route-osci-cond] McPherson, D. and Gill, V. and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", IETF RFC3345
.. [stable-flexible-ibgp] Flavel, A. and M. Roughan, "Stable and flexible iBGP", ACM SIGCOMM 2009
.. [ibgp-correctness] Griffin, T. and G. Wilfong, "On the correctness of IBGP configuration", ACM SIGCOMM 2002
Debug eigrp packets
- ``debug eigrp`` will show EIGRP packets that are sent and recevied.
+ ``debug eigrp`` will show EIGRP packets that are sent and received.
.. index:: debug eigrp transmit
.. clicmd:: debug eigrp transmit
.. index:: Making FRR
Several distributions provide packages for FRR. Check your distribution's
-respositories to find out if a suitable version is available.
+repositories to find out if a suitable version is available.
FRR depends on various libraries depending on your operating system.
.. option:: --enable-gcc-rdynamic
Pass the ``-rdynamic`` option to the linker driver. This is in most cases
- neccessary for getting usable backtraces. This option defaults to on if the
+ necessary for getting usable backtraces. This option defaults to on if the
compiler is detected as gcc, but giving an explicit enable/disable is
suggested.
.. option:: --enable-numeric-version
Alpine Linux does not allow non-numeric characters in the version string.
- With this option, we provide a way to strip out these characters for apk dev
+ With this option, we provide a way to strip out these characters for APK dev
package builds.
You may specify any combination of the above options to the configure
.. option:: --enable-vty-group <group>
- Create Unix Vty sockets (for use with vtysh) with group owndership set to
- `group`. This allows one to create a seperate group which is restricted to
+ Create Unix Vty sockets (for use with vtysh) with group ownership set to
+ `group`. This allows one to create a separate group which is restricted to
accessing only the vty sockets, hence allowing one to delegate this group to
individual users, or to run vtysh setgid to this group.
- :makevar:`CONFIG_NETLINK`
- Kernel/User netlink socket. This is a brand new feature which enables an
+ Kernel/User Netlink socket. This is a brand new feature which enables an
advanced interface between the Linux kernel and zebra (:ref:`kernel-interface`).
- :makevar:`CONFIG_RTNETLINK`
Routing messages.
- This makes it possible to receive netlink routing messages. If you
+ This makes it possible to receive Netlink routing messages. If you
specify this option, *zebra* can detect routing information
updates directly from the kernel (:ref:`kernel-interface`).
- :makevar:`CONFIG_IP_MULTICAST`
IPv6 Support
************
-FRR fully supports IPv6 routing. As described so far, Frr supports RIPng,
+FRR fully supports IPv6 routing. As described so far, FRR supports RIPng,
OSPFv3, and BGP-4+. You can give IPv6 addresses to an interface and configure
static IPv6 routing information. FRR IPv6 also provides automatic address
configuration via a feature called ``address auto configuration``. To do it,
.. index:: no ipv6 nd suppress-ra
.. clicmd:: no ipv6 nd suppress-ra
- Send router advertisment messages.
+ Send router advertisement messages.
.. index:: ipv6 nd suppress-ra
.. clicmd:: ipv6 nd suppress-ra
- Don't send router advertisment messages.
+ Don't send router advertisement messages.
.. index:: ipv6 nd prefix ipv6prefix [valid-lifetime] [preferred-lifetime] [off-link] [no-autoconfig] [router-address]
.. clicmd:: ipv6 nd prefix ipv6prefix [valid-lifetime] [preferred-lifetime] [off-link] [no-autoconfig] [router-address]
This is a special filesystem mount that provides an easy way of getting
kernel information.
-- routing socket / netlink
+- routing socket / Netlink
On recent Linux kernels (2.0.x and 2.2.x), there is a kernel/user
- communication support called `netlink`. It makes asynchronous communication
+ communication support called `Netlink`. It makes asynchronous 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 'Routing
+ kernel/Netlink support option 'Kernel/User network link driver' and 'Routing
messages'.
Today, the :file:`/dev/route` special device file is obsolete. Netlink
- communication is done by reading/writing over netlink socket.
+ communication is done by reading/writing over Netlink socket.
After the kernel configuration, please reconfigure and rebuild FRR. You can
- use netlink as a dynamic routing update channel between FRR and the kernel.
+ use Netlink as a dynamic routing update channel between FRR and the kernel.
an event which occurs outside of the holdtime of any previous SPF
calculation, and also serves as a minimum holdtime).
- Consecutive SPF calculations will always be seperated by at least
+ Consecutive SPF calculations will always be separated by at least
'hold-time' milliseconds. The hold-time is adaptive and initially is
set to the `initial-holdtime` configured with the above command.
Events which occur within the holdtime of the previous SPF calculation
will cause the holdtime to be increased by `initial-holdtime`, bounded
by the `maximum-holdtime` configured with this command. If the adaptive
- hold-time elapses without any SPF-triggering event occuring then
+ hold-time elapses without any SPF-triggering event occurring then
the current holdtime is reset to the `initial-holdtime`.
.. code-block:: frr
to 400ms and the `maximum holdtime` to 10s. Hence there will always be at
least 200ms between an event which requires SPF calculation and the actual
SPF calculation. Further consecutive SPF calculations will always be
- seperated by between 400ms to 10s, the hold-time increasing by 400ms each
+ separated by between 400ms to 10s, the hold-time increasing by 400ms each
time an SPF-triggering event occurs within the hold-time of the previous
SPF calculation.
.. index:: ipv6 ospf6 network (broadcast|point-to-point)
.. clicmd:: ipv6 ospf6 network (broadcast|point-to-point)
- Set explicitly network type for specifed interface.
+ Set explicitly network type for specified interface.
.. _redistribute-routes-to-ospf6:
.. index:: Link State Database
Each router describes their link-state information in a message known as an
-:abbr:`LSA (Link State Advertisement)`, which is then propogated through to all
+:abbr:`LSA (Link State Advertisement)`, which is then propagated through to all
other routers in a link-state routing domain, by a process called `flooding`.
Each router thus builds up an :abbr:`LSDB (Link State Database)` of all the
link-state messages. From this collection of LSAs in the LSDB, each router can
---------------
:abbr:`OSPF` defines a range of mechanisms, concerned with detecting,
-describing and propogating state through a network. These mechanisms
+describing and propagating state through a network. These mechanisms
will nearly all be covered in greater detail further on. They may be
broadly classed as:
OSPF defines several related mechanisms, used to manage synchronisation of
:abbr:`LSDB` s between neighbours as neighbours form adjacencies and the
-propogation, or `flooding` of new or updated :abbr:`LSA` s.
+propagation, or `flooding` of new or updated :abbr:`LSA` s.
.. index:: OSPF Areas overview
| Router LSA | Router ID | The :abbr:`OSPF` enabled links of the |
| | | router, within a specific link-state area. |
+-------------+----------------------------+--------------------------------------------+
-| Network LSA | The IP address of the | The subet mask of the network and the |
+| Network LSA | The IP address of the | The subnet mask of the network and the |
| | :abbr:`DR` for the network | Router IDs of all routers on the network |
+-------------+----------------------------+--------------------------------------------+
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.
+ forwarding address, for the forwarding address to be usable.
Tag
An arbitrary 4-bytes of data, not interpreted by OSPF, which may carry
which still can reach the backbone - this restriction exists primarily
to ensure routing-loops are avoided.
- With the "Cisco" or "IBM" ABR type, the default in this release of
- FRR, this restriction is lifted, allowing an ABR to consider
- summaries learnt from other ABRs through non-backbone areas, and hence
- route via non-backbone areas as a last resort when, and only when,
- backbone links are down.
+ With the "Cisco" or "IBM" ABR type, the default in this release of FRR, this
+ restriction is lifted, allowing an ABR to consider summaries learned from
+ other ABRs through non-backbone areas, and hence route via non-backbone
+ areas as a last resort when, and only when, backbone links are down.
Note that areas with fully-adjacent virtual-links are considered to be
"transit capable" and can always be used to route backbone traffic, and
.. index:: no ospf rfc1583compatibility
.. clicmd:: no ospf rfc1583compatibility
- :rfc:`2328`, the sucessor to :rfc:`1583`, suggests according
+ :rfc:`2328`, the successor to :rfc:`1583`, suggests according
to section G.2 (changes) in section 16.4 a change to the path
preference algorithm that prevents possible routing loops that were
possible in the old version of OSPFv2. More specifically it demands
an event which occurs outside of the holdtime of any previous SPF
calculation, and also serves as a minimum holdtime).
- Consecutive SPF calculations will always be seperated by at least
+ Consecutive SPF calculations will always be separated by at least
'hold-time' milliseconds. The hold-time is adaptive and initially is
set to the `initial-holdtime` configured with the above command.
Events which occur within the holdtime of the previous SPF calculation
will cause the holdtime to be increased by `initial-holdtime`, bounded
by the `maximum-holdtime` configured with this command. If the adaptive
- hold-time elapses without any SPF-triggering event occuring then
+ hold-time elapses without any SPF-triggering event occurring then
the current holdtime is reset to the `initial-holdtime`. The current
holdtime can be viewed with :clicmd:`show ip ospf`, where it is expressed as
a multiplier of the `initial-holdtime`.
In this example, the `delay` is set to 200ms, the initial holdtime is set to
400ms and the `maximum holdtime` to 10s. Hence there will always be at least
200ms between an event which requires SPF calculation and the actual SPF
- calculation. Further consecutive SPF calculations will always be seperated
+ calculation. Further consecutive SPF calculations will always be separated
by between 400ms to 10s, the hold-time increasing by 400ms each time an
SPF-triggering event occurs within the hold-time of the previous SPF
calculation.
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 interface must be equal or bigger (i.e. smaller network) than
prefix length in network statement. For example statement above doesn't enable
ospf on interface with address 192.168.1.1/23, but it does on interface with
address 192.168.1.129/25.
Summarize intra area paths from specified area into one Type-3 summary-LSA
announced to other areas. This command can be used only in ABR and ONLY
- router-LSAs (Type-1) and network-LSAs (Type-2) (ie. LSAs with scope area) can
+ router-LSAs (Type-1) and network-LSAs (Type-2) (i.e. LSAs with scope area) can
be summarized. Type-5 AS-external-LSAs can't be summarized - their scope is AS.
Summarizing Type-7 AS-external-LSAs isn't supported yet by FRR.
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
- network (ie. described with router or network LSA) from this range.
+ network (i.e. described with router or network LSA) from this range.
.. index:: area A.B.C.D range IPV4_PREFIX not-advertise
.. clicmd:: area A.B.C.D range IPV4_PREFIX not-advertise
.. index:: no area A.B.C.D range IPV4_PREFIX not-advertise
.. clicmd:: no area A.B.C.D range IPV4_PREFIX not-advertise
- Instead of summarizing intra area paths filter them - ie. intra area paths from this
+ Instead of summarizing intra area paths filter them - i.e. intra area paths from this
range are not advertised into other areas.
This command makes sense in ABR only.
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
+ area 0.0.0.10 contains at least one intra-area network (i.e. described with router-LSA or
network-LSA) from range 10.0.0.0/8.
This command makes sense in ABR only.
Note that OSPF MD5 authentication requires that time never go backwards
(correct time is NOT important, only that it never goes backwards), even
- across resets, if ospfd is to be able to promptly reestabish adjacencies
+ across resets, if ospfd is to be able to promptly reestablish adjacencies
with its neighbours after restarts/reboots. The host should have system time
- be set at boot from an external or non-volatile source (eg battery backed
+ be set at boot from an external or non-volatile source (e.g. battery backed
clock, NTP, etc.) or else the system clock should be periodically saved to
- non-volative storage and restored at boot if MD5 authentication is to be
+ non-volatile storage and restored at boot if MD5 authentication is to be
expected to work reliably.
.. index:: ip ospf message-digest-key KEYID md5 KEY
.. index:: no ip ospf network
.. clicmd:: no ip ospf network
- Set explicitly network type for specifed interface.
+ Set explicitly network type for specified interface.
.. index:: ip ospf priority (0-255)
.. clicmd:: ip ospf priority (0-255)
.. index:: no capability opaque
.. clicmd:: no capability opaque
- *ospfd* support Opaque LSA (:rfc:`2370`) as fondment for MPLS Traffic
+ *ospfd* supports Opaque LSA (:rfc:`2370`) as fundamental for MPLS Traffic
Engineering LSA. Prior to used MPLS TE, opaque-lsa must be enable in the
configuration file. Alternate command could be "mpls-te on"
(:ref:`ospf-traffic-engineering`).
.. clicmd:: no pce scope
The commands are conform to :rfc:`5088` and allow OSPF router announce Path
- Compuatation Elemenent (PCE) capabilities through the Router Information
- (RI) LSA. Router Information must be enable prior to this. The command
- set/unset respectively the PCE IP adress, Autonomous System (AS) numbers of
+ Computation Element (PCE) capabilities through the Router Information (RI)
+ LSA. Router Information must be enable prior to this. The command set/unset
+ respectively the PCE IP address, Autonomous System (AS) numbers of
controlled domains, neighbor ASs, flag and scope. For flag and scope, please
refer to :rfc`5088` for the BITPATTERN recognition. Multiple 'pce neighbor'
command could be specified in order to specify all PCE neighbours.
.. index:: [no] segment-routing prefix A.B.C.D/M index (0-65535) [no-php-flag]
.. clicmd:: [no] segment-routing prefix A.B.C.D/M index (0-65535) [no-php-flag]
- Set the Segment Rounting index for the specifyed prefix. Note that, only
+ Set the Segment Routing index for the specified prefix. Note that, only
prefix with /32 corresponding to a loopback interface are currently
supported. The 'no-php-flag' means NO Penultimate Hop Popping that allows SR
node to request to its neighbor to not pop the label.
.. index:: show ip ospf database segment-routing <adv-router ADVROUTER|self-originate> [json]
.. clicmd:: show ip ospf database segment-routing <adv-router ADVROUTER|self-originate> [json]
- Show Segment Routing Data Base, all SR nodes, specific advertized router or
+ Show Segment Routing Data Base, all SR nodes, specific advertised router or
self router. Optional JSON output can be obtained by appending 'json' to the
end of the command.
!
line vty
-A router information example with PCE advsertisement:
+A router information example with PCE advertisement:
.. code-block:: frr
.. clicmd:: ip pim ecmp rebalance
If pim is using ECMP and an interface goes down, cause pim to rebalance all
- S,G flows aross the remaining nexthops. If this command is not configured
+ S,G flows across the remaining nexthops. If this command is not configured
pim only modifies those S,G flows that were using the interface that went
down. This command is vrf aware, to configure for a vrf, enter the vrf
submode.
.. clicmd:: ip pim keep-alive-timer (31-60000)
Modify the time out value for a S,G flow from 31-60000 seconds. 31 seconds
- is choosen for a lower bound because some hardware platforms cannot see data
- flowing in better than 30 second chunks. This comand is vrf aware, to
+ is chosen for a lower bound because some hardware platforms cannot see data
+ flowing in better than 30 second chunks. This command is vrf aware, to
configure for a vrf, enter the vrf submode.
.. index:: ip pim packets (1-100)
.. clicmd:: ip multicat boundary oil WORD
Set a pim multicast boundary, based upon the WORD prefix-list. If a pim join
- or IGMP report is received on this interface and the Group is denyed by the
+ or IGMP report is received on this interface and the Group is denied by the
prefix-list, PIM will ignore the join or report.
.. _pim-multicast-rib-insertion:
.. index:: show ip pim nexthop-lookup
.. clicmd:: show ip pim nexthop-lookup
- Display information about a S,G pair and how the RPF would be choosen. This
+ Display information about a S,G pair and how the RPF would be chosen. This
is especially useful if there are ECMP's available from the RPF lookup.
.. index:: show ip pim rp-info
.. clicmd:: show ip pim state
Display information about known S,G's and incoming interface as well as the
- OIL and how they were choosen.
+ OIL and how they were chosen.
.. index:: show ip pim upstream
.. clicmd:: show ip pim upstream
.. index:: show ip pim upstream-join-desired
.. clicmd:: show ip pim upstream-join-desired
-{show PIM Information} {show ip pim upstream-join-desired} {}
- Display upstream information for S,G's and if we desire to
- join the mcast tree
+ Display upstream information for S,G's and if we desire to
+ join the multicast tree
.. index:: show ip pim upstream-rpf
.. clicmd:: show ip pim upstream-rpf
==================
The debugging subsystem for PIM behaves in accordance with how FRR handles
-debugging. You can specify debugging at the enable cli mode as well as the
-configure cli mode. If you specify debug commands in the configuration cli
+debugging. You can specify debugging at the enable CLI mode as well as the
+configure CLI mode. If you specify debug commands in the configuration cli
mode, the debug commands can be persistent across restarts of the FRR pimd if
the config was written out.
.. index:: debug pim zebra
.. clicmd:: debug pim zebra
- This gathers data about events from zebra that come up through the zapi.
+ This gathers data about events from zebra that come up through the ZAPI.
based on the :term:`Bellman-Ford` algorithms. As a distance-vector
protocol, RIP router send updates to its neighbors periodically, thus
allowing the convergence to a known topology. In each update, the
-distance to any given network will be broadcasted to its neighboring
+distance to any given network will be broadcast to its neighboring
router.
*ripd* supports RIP version 2 as described in RFC2453 and RIP
To stop *ripd*. Please use::
kill `cat /var/run/ripd.pid`
-Certain signals have special meaningss to *ripd*.
+Certain signals have special meanings to *ripd*.
+-------------+------------------------------------------------------+
| Signal | Action |
RIP can be configured to send either Version 1 or Version 2 packets. The
default is to send RIPv2 while accepting both RIPv1 and RIPv2 (and replying
with packets of the appropriate version for REQUESTS / triggered updates). The
-version to receive and send can be specified globally, and further overriden on
-a per-interface basis if needs be for send and receive seperately (see below).
+version to receive and send can be specified globally, and further overridden on
+a per-interface basis if needs be for send and receive separately (see below).
It is important to note that RIPv1 cannot be authenticated. Further, if RIPv1
is enabled then RIP will reply to REQUEST packets, sending the state of its RIP
.. index:: no ip rip authentication key-chain KEY-CHAIN
.. clicmd:: no ip rip authentication key-chain KEY-CHAIN
- Specifiy Keyed MD5 chain.
+ Specify Keyed MD5 chain.
.. code-block:: frr
.. clicmd:: show ip rip status
The command displays current RIP status. It includes RIP timer,
- filtering, version, RIP enabled interface and RIP peer inforation.
+ filtering, version, RIP enabled interface and RIP peer information.
::
allowing policy to be applied to routes.
Route maps are an ordered list of route map entries. Each entry may specify up
-to four distincts sets of clauses:
+to four distinct sets of clauses:
.. glossary::
Matching Conditions
A route-map entry may, optionally, specify one or more conditions which
must be matched if the entry is to be considered further, as governed by
- the Match Policy. If a route-map entry does not explicitely specify any
+ the Match Policy. If a route-map entry does not explicitly specify any
matching conditions, then it always matches.
Set Actions
local-preference value is set to 200.
See :ref:`bgp-configuration-examples` for examples of more sophisticated
-useage of route-maps, including of the ``call`` action.
+usage of route-maps, including of the ``call`` action.
BGP attributes (next-hop, as-path and MED) that are usually modified by
standard BGP speakers before announcing a route.
-The announcement processing model implemented by Frr is shown in
+The announcement processing model implemented by FRR is shown in
:ref:`fig-rs-processing`. The figure shows a mixture of RS-clients (B, C and D)
with normal BGP peers (A). There are some details that worth additional
comments:
This command configures the peer given by `peer`, `A.B.C.D` or `X:X::X:X` as
an RS-client.
- Actually this command is not new, it already existed in standard Frr. It
+ Actually this command is not new, it already existed in standard FRR. It
enables the transparent mode for the specified peer. This means that some
BGP attributes (as-path, next-hop and MED) of the routes announced to that
peer are not modified.
Example of Route Server Configuration
-------------------------------------
-Finally we are going to show how to configure a Frr daemon to act as a
+Finally we are going to show how to configure a FRR daemon to act as a
Route Server. For this purpose we are going to present a scenario without
route server, and then we will show how to use the configurations of the BGP
routers to generate the configuration of the route server.
set community 65001:11111
-It is posible to write a single route-map which is equivalent to
-the three filters (the community-list, the prefix-list and the
-route-map). That route-map can then be used inside the Import
-policy in the route server. Lets see how to do it:
+It is possible to write a single route-map which is equivalent to the three
+filters (the community-list, the prefix-list and the route-map). That route-map
+can then be used inside the Import policy in the route server. Lets see how to
+do it:
.. code-block:: frr
.. clicmd:: 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
+ to bgp or zebra. This parameter is used in conjunction with
:ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
is optional.
.. clicmd:: 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
+ or zebra. This parameter is used in conjunction with
:ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
is optional.
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
+ each other. This parameter is used in conjunction with
:ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
is optional.
.. clicmd:: 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)])
Delete the information identified by prefix, VN address, and UN address.
- Any or all of these parameters may be wilcarded to (potentially) match more
+ Any or all of these parameters may be wildcarded to (potentially) match more
than one registration. The optional `mac` parameter specifies a layer-2 MAC
address that must match the registration(s) to be deleted. The optional
`local-next-hop` parameter is used to delete specific local nexthop
.. clicmd:: clear vnc mac (\*|xx:xx:xx:xx:xx:xx) virtual-network-identifier (\*|(1-4294967295)) (\*|[(vn|un) (A.B.C.D|X:X::X:X|\*) [(un|vn) (A.B.C.D|X:X::X:X|\*)] [prefix (\*|A.B.C.D/M|X:X::X:X/M)])
Delete mac forwarding information. Any or all of these parameters may be
- wilcarded to (potentially) match more than one registration. The default
+ wildcarded to (potentially) match more than one registration. The default
value for the `prefix` parameter is the wildcard value `*`.
.. index:: clear vnc nve (\*|((vn|un) (A.B.C.D|X:X::X:X) [(un|vn) (A.B.C.D|X:X::X:X)]))
.. TBD make this its own example:
..
.. @float Figure,fig:fig-vnc-gw-rr
-.. @center @image{fig-vnc-gw-rr,400pt,,Frr VNC Gateway with RR}
+.. @center @image{fig-vnc-gw-rr,400pt,,FRR VNC Gateway with RR}
.. @end float
.. An NVA can also import unicast routes from BGP without advertising the
.. imported routes as VPN routes. Such imported routes, while not
FRR-based NVA with redundant route reflectors
-:file:`bgpd.conf` for ``Bgpd Route Reflector 1`` on 192.168.1.100:
+:file:`bgpd.conf` for ``BPGD Route Reflector 1`` on 192.168.1.100:
.. code-block:: frr
----------------------------------------------------
The :file:`frr.conf` file is not written by any of the daemons; instead *vtysh*
-contains the neccessary logic to collect configuration from all of the daemons,
+contains the necessary logic to collect configuration from all of the daemons,
combine it and write it out.
.. warning::
.. clicmd:: no ip address LOCAL-ADDR peer PEER-ADDR/PREFIX
- Configure an IPv4 Pointopoint address on the interface. (The concept of PtP
- addressing does not exist for IPv6.)
+ Configure an IPv4 Point-to-Point address on the interface. (The concept of
+ PtP addressing does not exist for IPv6.)
`local-addr` has no subnet mask since the local side in PtP addressing is
always a single (/32) address. `peer-addr/prefix` can be an arbitrary subnet
.. index:: link-param use-bw BANDWIDTH
.. clicmd:: link-param use-bw BANDWIDTH
- These command specifies additionnal Traffic Engineering parameters of the
+ These command specifies additional Traffic Engineering parameters of the
interface in conformity to draft-ietf-ospf-te-metrics-extension-05.txt and
draft-ietf-isis-te-metrics-extension-03.txt. There are respectively the
delay, jitter, loss, available bandwidth, reservable bandwidth and utilized
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
-prevent traffic destined for a prefix to match less-specific routes (eg
-default) should the specified gateways not be reachable. Eg:
+prevent traffic destined for a prefix to match less-specific routes (e.g.
+default) should the specified gateways not be reachable. E.g.:
::
(FIB). Zebra feeds the FIB to the kernel, which allows the IP stack in
the kernel to forward packets according to the routes computed by
FRR. The kernel FIB is updated in an OS-specific way. For example,
-the `netlink` interface is used on Linux, and route sockets are
+the `Netlink` interface is used on Linux, and route sockets are
used on FreeBSD.
The FIB push interface aims to provide a cross-platform mechanism to
The encapsulation header for the messages exchanged with the FPM is
defined by the file :file:`fpm/fpm.h` in the frr tree. The routes
-themselves are encoded in netlink or protobuf format, with netlink
+themselves are encoded in Netlink or protobuf format, with Netlink
being the default.
Protobuf is one of a number of new serialization formats wherein the
encoding/decoding to/from the wire format is generated from the
schema. Protobuf messages can be extended easily while maintaining
backward-compatibility with older code. Protobuf has the following
-advantages over netlink:
+advantages over Netlink:
- Code for serialization/deserialization is generated automatically. This
reduces the likelihood of bugs, allows third-party programs to be integrated
- The message format is not tied to an OS (Linux), and can be evolved
independently.
-As mentioned before, zebra encodes routes sent to the FPM in netlink
+As mentioned before, zebra encodes routes sent to the FPM in Netlink
format by default. The format can be controlled via the FPM module's
-load-time option to zebra, which currently takes the values `netlink`
+load-time option to zebra, which currently takes the values `Netlink`
and `protobuf`.
The zebra FPM interface uses replace semantics. That is, if a 'route
projects / mirror_frr.git / commitdiff