can cause the order of preference over all the routes to be undefined. That is,
given routes A, B, and C, if A is preferred to B, and B is preferred to C, then
a well-defined order should mean the preference is transitive (in the sense of
-orders [#med-transitivity-rant])_ and that A would be preferred to C.
+orders [#med-transitivity-rant]_) and that A would be preferred to C.
However, when MED is involved this need not be the case. With MED it is
possible that C is actually preferred over A. So A is preferred to B, B is
There may be iBGP topology specific ways to reduce the instability risks, even
while using MED, e.g.: by constraining the reflection topology and by tuning
-IGP costs between route-reflector clusters, see RFC3345 for details. In the
+IGP costs between route-reflector clusters, see :rfc:`3345` for details. In the
near future, the Add-Path extension to BGP may also solve MED oscillation while
still allowing MED to be used as intended, by distributing "best-paths per
neighbour AS". This would be at the cost of distributing at least as many
More generally, the instability problems that MED can introduce on more
complex, non-full-mesh, iBGP topologies may be avoided either by:
-- Setting :ref:`bgp_always-compare-med`, however this allows MED to be compared
+- Setting :clicmd:`bgp always-compare-med`, however this allows MED to be compared
across values set by different neighbour ASes, which may not produce
coherent desirable results, of itself.
- Effectively ignoring MED by setting MED to the same value (e.g.: 0) using
- :ref:`routemap_set_metric` on all received routes, in combination with
- setting :ref:`bgp_always-compare-med` on all speakers. This is the simplest
+ :clicmd:`set metric METRIC` on all received routes, in combination with
+ setting :clicmd:`bgp always-compare-med` on all speakers. This is the simplest
and most performant way to avoid MED oscillation issues, where an AS is happy
not to allow neighbours to inject this problematic metric.
follow the IGP topology.
.. _bgp_deterministic-med:
+
.. index:: bgp deterministic-med
.. clicmd:: bgp deterministic-med
process, specifically, the preference for older and already selected routes
from eBGP peers, :ref:`BGP_decision_process`.
+.. _bgp_always-compare-med:
+
.. index:: bgp always-compare-med
.. clicmd:: bgp always-compare-med
-.. _bgp_always-compare-med:
-
Always compare the MED on routes, even when they were received from
different neighbouring ASes. Setting this option makes the order of
preference of routes more defined, and should eliminate MED induced
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
-exclude_patterns = ['_build']
+exclude_patterns = ['_build', 'rpki.rst', 'ospf_fundamentals.rst']
# The reST default role (used for this markup: `text`) to use for all
# documents.
Show EIGRP Information
======================
-To display EIGRP routes.
-
-.. index:: show ip eigrp topology
-.. clicmd:: show ip eigrp topology
-
- Show EIGRP routes.
-
-The command displays all EIGRP routes.
-
.. index:: show ip eigrp topology
.. clicmd:: show ip eigrp topology
- The command displays current EIGRP status
+ Display current EIGRP status.
::
overview
installation
basic
- zebra
- ripd
- ripngd
- ospfd
- ospf6d
- isisd
- nhrpd
- bgp
- babeld
- vnc
vtysh
filter
routemap
ipv6
kernel
snmp
+ zebra
protocol
+ bgp
+ babeld
+ eigrpd
+ isisd
+ nhrpd
+ ospfd
+ ospf6d
pim
+ ripd
+ ripngd
+ vnc
+ appendix
Build without VTYSH.
+.. option:: --enable-fpm
+
+ Build with FPM module support.
+
You may specify any combination of the above options to the configure
script. By default, the executables are placed in :file:`/usr/local/sbin`
and the configuration files in :file:`/usr/local/etc`. The :file:`/usr/local/`
Show the ISIS routing table, as determined by the most recent SPF
calculation.
-.. _ospf-traffic-engineering:
-
Traffic Engineering
===================
Show Traffic Engineering router parameters.
+.. seealso::
+
+ :ref:`ospf-traffic-engineering`
+
.. _Debugging_ISIS:
Debugging ISIS
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)`.
+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:
""""""""""""
OSPF defines several related mechanisms, used to manage synchronisation of
-:abbr:`LSDB`s between neighbours as neighbours form adjacencies and the
+: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`.
- Age
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
called the :term:`MaxAge`. MaxAge LSAs are ignored in routing
Summary LSAs
^^^^^^^^^^^^
-Summary LSAs are created by :abbr:`ABR`s to summarise the destinations
+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.
+--------------------------------+------------------------------+
The Development list is used to discuss and document general issues related to
-project development and governance. The public `Slack instance
-<https://frrouting.slack.com>`_, and weekly technical meetings provide a higher
-bandwidth channel for discussions. The results of such discussions are
-reflected in updates, as appropriate, to code (i.e., merges), `GitHub
-<https://github.com/FRRouting/frr/issues>`_ tracked issues, and for governance
-or process changes, updates to the Development list and either this file or
-information posted at https://frrouting.org/.
+project development and governance. The public `Slack`_ instance and weekly
+technical meetings provide a higher bandwidth channel for discussions. The
+results of such discussions are reflected in updates, as appropriate, to code
+(i.e., merges), `GitHub issues`_ tracked issues, and for governance or process
+changes, updates to the Development list and either this file or information
+posted at `FRR`_.
.. index:: Bug Reports
.. index:: Bug hunting
Bug reports help us improve FRR and are very much appreciated.
.. _FRR: |PACKAGE_URL|
-.. _GitHub: http://github.com/frrouting/frr/
-.. _GitHub issues: http://github.com/frrouting/frr/
+.. _GitHub: https://github.com/frrouting/frr/
+.. _GitHub issues: https://github.com/frrouting/frr/issues
+.. _Slack: https://frrouting.slack.com/
Route maps are an ordered list of route map entries. Each entry may specify up
to four distincts sets of clauses:
-- :dfn:`Matching Policy`
+.. glossary::
- This specifies the policy implied if the *Matching Conditions* are
- met or not met, and which actions of the route-map are to be taken, if
- any. The two possibilities are:
+ 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
+ matching conditions, then it always matches.
- - :dfn:`permit`: If the entry matches, then carry out the :term:`Set
- Actions`. Then finish processing the route-map, permitting the route,
- unless an *Exit Action* indicates otherwise.
+ Set Actions
+ A route-map entry may, optionally, specify one or more Set Actions to set
+ or modify attributes of the route.
- - :dfn:`deny`: If the entry matches, then finish processing the route-map and
- deny the route (return ``deny``).
+ Matching Policy
+ This specifies the policy implied if the :term:`Matching Conditions` are
+ met or not met, and which actions of the route-map are to be taken, if
+ any. The two possibilities are:
- The *Matching Policy* is specified as part of the command which
- defines the ordered entry in the route-map. See below.
+ - :dfn:`permit`: If the entry matches, then carry out the
+ :term:`Set Actions`. Then finish processing the route-map, permitting
+ the route, unless an :term:`Exit Policy` action indicates otherwise.
-- :dfn:`Matching Conditions`
+ - :dfn:`deny`: If the entry matches, then finish processing the route-map and
+ deny the route (return `deny`).
- 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 matching
- conditions, then it always matches.
+ The `Matching Policy` is specified as part of the command which defines
+ the ordered entry in the route-map. See below.
-- :dfn:`Set Actions`
+ Call Action
+ Call to another route-map, after any :term:`Set Actions` have been carried out.
+ If the route-map called returns `deny` then processing of the route-map
+ finishes and the route is denied, regardless of the :term:Matching Policy` or
+ the :term:`Exit Policy`. If the called route-map returns `permit`, then
+ :term:`Matching Policy` and :term:`Exit Policy` govern further behaviour, as normal.
- A route-map entry may, optionally, specify one or more *Set Actions* to
- set or modify attributes of the route.
+ Exit Policy
+ An entry may, optionally, specify an alternative :dfn:`Exit Policy` to
+ take if the entry matched, rather than the normal policy of exiting the
+ route-map and permitting the route. The two possibilities are:
-- :dfn:`Call Action`
+ - :dfn:`next`: Continue on with processing of the route-map entries.
- Call to another route-map, after any *Set Actions* have been carried out.
- If the route-map called returns *deny* then processing of the route-map
- finishes and the route is denied, regardless of the *Matching Policy* or
- the *Exit Policy*. If the called route-map returns *permit*, then
- *Matching Policy* and *Exit Policy* govern further behaviour, as normal.
-
-- :dfn:`Exit Policy`
-
- An entry may, optionally, specify an alternative *Exit Policy* to
- take if the entry matched, rather than the normal policy of exiting the
- route-map and permitting the route. The two possibilities are:
-
- - :dfn:`next`: Continue on with processing of the route-map entries.
-
- - :dfn:`goto N`: Jump ahead to the first route-map entry whose order in
- the route-map is >= N. Jumping to a previous entry is not permitted.
+ - :dfn:`goto N`: Jump ahead to the first route-map entry whose order in
+ the route-map is >= N. Jumping to a previous entry is not permitted.
The default action of a route-map, if no entries match, is to deny. I.e. a
route-map essentially has as its last entry an empty *deny* entry, which
Route Map Set Command
=====================
+.. program:: configure
+
.. index:: set tag TAG
.. clicmd:: set tag TAG
-.. program:: configure
-
Set a tag on the matched route. This tag value can be from (1-4294967295).
Additionally if you have compiled with the :option:`--enable-realms`
configure option. Tag values from (1-255) are sent to the Linux kernel as a
When program terminates, retain routes added by zebra.
+.. program:: configure
+
.. _Interface_Commands:
Interface Commands
zebra Route Filtering
=====================
-Zebra supports :dfn:`prefix-list`s and :ref:`Route_Map`s to match routes
-received from other frr components. The permit/deny facilities provided by
+Zebra supports :dfn:`prefix-list` s and :ref:`Route_Map` s to match routes
+received from other FRR components. The permit/deny facilities provided by
these commands can be used to filter which routes zebra will install in the
kernel.
.. index:: ip protocol PROTOCOL route-map ROUTEMAP
.. clicmd:: ip protocol PROTOCOL route-map ROUTEMAP
- Apply a route-map filter to routes for the specified protocol. PROTOCOL can
- be **any** or one of
-
- - system,
- - kernel,
- - connected,
- - static,
- - rip,
- - ripng,
- - ospf,
- - ospf6,
- - isis,
- - bgp,
- - hsls.
+ Apply a route-map filter to routes for the specified protocol. PROTOCOL can
+ be **any** or one of
+
+ - system,
+ - kernel,
+ - connected,
+ - static,
+ - rip,
+ - ripng,
+ - ospf,
+ - ospf6,
+ - isis,
+ - bgp,
+ - hsls.
.. index:: set src ADDRESS
.. clicmd:: set src ADDRESS
projects / mirror / frr.git / commitdiff