BGP decision process
--------------------
-The decision process Frr BGP uses to select routes is as follows:
+The decision process FRR BGP uses to select routes is as follows:
cause subtle convergence problems in BGP. These properties and problems
have proven to be hard to understand, at least historically, and may still
not be widely understood. The following attempts to collect together and
-present what is known about MED, to help operators and Frr users in
+present what is known about MED, to help operators and FRR users in
designing and configuring their networks.
The BGP :abbr:`MED ( Multi_Exit_Discriminator)` attribute is intended to
administrators, with different frames of reference.
The default behaviour of BGP therefore is to not compare MED values across
-routes received from different neighbouring ASes. In Frr this is done by
+routes received from different neighbouring ASes. In FRR this is done by
comparing the neighbouring, left-most AS in the received AS_PATHs of the
routes and only comparing MED if those are the same.
A deterministic order of evaluation tends to imply an additional overhead of
sorting over any set of n routes to a destination. The implementation of
-deterministic MED in Frr scales significantly worse than most sorting
+deterministic MED in FRR scales significantly worse than most sorting
algorithms at present, with the number of paths to a given destination.
That number is often low enough to not cause any issues, but where there are
many paths, the deterministic comparison may quickly become increasingly
This particular type of oscillation in full-mesh iBGP topologies can be
avoided by speakers preferring already selected, external routes rather than
choosing to update to new a route based on a post-MED metric (e.g.
-router-ID), at the cost of a non-deterministic selection process. Frr
+router-ID), at the cost of a non-deterministic selection process. FRR
implements this, as do many other implementations, so long as it is not
overridden by setting :ref:`bgp_bestpath_compare-routerid`, and see also
:ref:`BGP_decision_process`, .
in.
Setting this option will have a performance cost that may be noticeable when
- there are many routes for each destination. Currently in Frr it is
+ there are many routes for each destination. Currently in FRR it is
implemented in a way that scales poorly as the number of routes per
destination increases.
Negotiation packets (at least not unless other optional BGP features
require capability negotation).
-By default, Frr will bring up peering with minimal common capability
+By default, FRR will bring up peering with minimal common capability
for the both sides. For example, local router has unicast and
multicast capabilitie and remote router has unicast capability. In
this case, the local router will establish the connection with unicast
-only capability. When there are no common capabilities, Frr sends
+only capability. When there are no common capabilities, FRR sends
Unsupported Capability error and then resets the connection.
If you want to completely match capabilities with remote peer. Please
'network' and 'aggregate-address' argument is displayed as
'A.B.C.D M.M.M.M'
-Frr: network 10.0.0.0/8
+FRR: network 10.0.0.0/8
Cisco: network 10.0.0.0
-Frr: aggregate-address 192.168.0.0/24
+FRR: aggregate-address 192.168.0.0/24
Cisco: aggregate-address 192.168.0.0 255.255.255.0
Community attribute handling is also different. If there is no
.. index:: bgp config-type zebra
``bgp config-type zebra``
- Frr style BGP configuration. This is default.
+ FRR style BGP configuration. This is default.
.. _BGP_instance_and_view:
Filtering
*********
-Frr provides many very flexible filtering features. Filtering is used
+FRR provides many very flexible filtering features. Filtering is used
for both input and output of the routing information. Once filtering is
defined, it can be applied in any direction.
IPv6 Support
************
-Frr fully supports IPv6 routing. As described so far, Frr supports
+FRR fully supports IPv6 routing. As described so far, Frr supports
RIPng, OSPFv3, and BGP-4+. You can give IPv6 addresses to an interface
-and configure static IPv6 routing information. Frr IPv6 also provides
+and configure static IPv6 routing information. FRR IPv6 also provides
automatic address configuration via a feature called ``address auto configuration``. To do it, the router must send router advertisement
messages to the all nodes that exist on the network.
-Previous versions of Frr could be built without IPv6 support. This is
+Previous versions of FRR could be built without IPv6 support. This is
no longer possible.
Router Advertisement
*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 between kernel and Frr possible, similar to a routing
+ 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)
Today, the /dev/route special device file is obsolete. Netlink
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
+ After the kernel configuration, please reconfigure and rebuild FRR.
+ You can use netlink as a dynamic routing update channel between FRR
and the kernel.
This table is fully separate from the default unicast table. However,
RPF lookup can include the unicast table.
-WARNING: RPF lookup results are non-responsive in this version of Frr,
+WARNING: RPF lookup results are non-responsive in this version of FRR,
i.e. multicast routing does not actively react to changes in underlying
unicast topology!
========================
Zebra supports a 'FIB push' interface that allows an external
-component to learn the forwarding information computed by the Frr
+component to learn the forwarding information computed by the FRR
routing suite. This is a loadable module that needs to be enabled
at startup as described in :ref:`Loadable_Module_Support`.
-In Frr, the Routing Information Base (RIB) resides inside
+In FRR, the Routing Information Base (RIB) resides inside
zebra. Routing protocols communicate their best routes to zebra, and
zebra computes the best route across protocols for each prefix. This
latter information makes up the Forwarding Information Base
(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,
+FRR. The kernel FIB is updated in an OS-specific way. For example,
the `netlink` interface is used on Linux, and route sockets are
used on FreeBSD.
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
+ 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.
hold-time increasing by 400ms each time an SPF-triggering event occurs
within the hold-time of the previous SPF calculation.
- This command supercedes the *timers spf* command in previous Frr
+ This command supercedes the *timers spf* command in previous FRR
releases.
.. index:: {OSPF Command} {max-metric router-lsa [on-startup|on-shutdown] <5-86400>} {}
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
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.
+ Summarizing Type-7 AS-external-LSAs isn't supported yet by FRR.
::
Version 0 is used by all versions of GNU Zebra as of this writing, and
versions of Quagga up to and including Quagga 0.98. Version 2 was created
for 0.99.21 of Quagga. Version 3 designates VRF compatibility and was
-released in 1.0. Version 4 will be used as of Frr 2.0 to indicate that
+released in 1.0. Version 4 will be used as of FRR 2.0 to indicate that
we are a different Routing Suite now and to hopefully prevent accidental
Quagga <-> FRR issues.
Version 2 of RIP supports a variable length subnet mask (VLSM). By
extending the subnet mask, the mask can be divided and reused. Each
subnet can be used for different purposes such as large to middle size
-LANs and WAN links. Frr *ripd* does not support the non-sequential
+LANs and WAN links. FRR *ripd* does not support the non-sequential
netmasks that are included in RIP Version 2.
In a case of similar information with the same prefix and metric, the
.. index:: {RIP command} {no route `a.b.c.d/m`} {}
{RIP command} {no route `a.b.c.d/m`} {}
- This command is specific to Frr. The `route` command makes a static
+ This command is specific to FRR. The `route` command makes a static
route only inside RIP. This command should be used only by advanced
users who are particularly knowledgeable about the RIP protocol. In
- most cases, we recommend creating a static route in Frr and
+ most cases, we recommend creating a static route in FRR and
redistributing it in RIP using `redistribute static`.
.. _Filtering_RIP_Routes:
Cisco applies route-map _before_ routes will exported to rip route table.
-In current Frr's test implementation, *ripd* applies route-map
+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
so clear, but it is draft and it may be changed at future.
-.. _Configuring_Frr_as_a_Route_Server:
+.. _Configuring_FRR_as_a_Route_Server:
*********************************
-Configuring Frr as a Route Server
+Configuring FRR as a Route Server
*********************************
The purpose of a Route Server is to centralize the peerings between BGP
each of the four establishes a single BGP peering against the Route Server
(:ref:`fig:route-server`).
-We will first describe briefly the Route Server model implemented by Frr.
+We will first describe briefly the Route Server model implemented by FRR.
We will explain the commands that have been added for configuring that
-model. And finally we will show a full example of Frr configured as Route
+model. And finally we will show a full example of FRR configured as Route
Server.
@acronym{SNMP,Simple Network Managing Protocol} is a widely implemented
feature for collecting network information from router and/or host.
-Frr itself does not support SNMP agent (server daemon) functionality
+FRR itself does not support SNMP agent (server daemon) functionality
but is able to connect to a SNMP agent using the SMUX protocol
(@cite{RFC1227}) or the AgentX protocol (@cite{RFC2741}) and make the
routing protocol MIBs available through it.
It is free and open software and available at `http://www.net-snmp.org/ <http://www.net-snmp.org/>`_
and as binary package for most Linux distributions.
`net-snmp` has to be compiled with `--with-mib-modules=agentx` to
-be able to accept connections from Frr using AgentX protocol or with
+be able to accept connections from FRR using AgentX protocol or with
`--with-mib-modules=smux` to use SMUX protocol.
Nowadays, SMUX is a legacy protocol. The AgentX protocol should be
AgentX configuration
====================
-To enable AgentX protocol support, Frr must have been build with the
+To enable AgentX protocol support, FRR must have been build with the
`--enable-snmp` or `--enable-snmp=agentx` option. Both the
-master SNMP agent (snmpd) and each of the Frr daemons must be
+master SNMP agent (snmpd) and each of the FRR daemons must be
configured. In `/etc/snmp/snmpd.conf`, `master agentx`
-directive should be added. In each of the Frr daemons, `agentx`
+directive should be added. In each of the FRR daemons, `agentx`
command will enable AgentX support.
::
Upon successful connection, you should get something like this in the
-log of each Frr daemons:
+log of each FRR daemons:
::
The AgentX protocol can be transported over a Unix socket or using TCP
or UDP. It usually defaults to a Unix socket and depends on how NetSNMP
-was built. If need to configure Frr to use another transport, you can
+was built. If need to configure FRR to use another transport, you can
configure it through `/etc/snmp/frr.conf`:
::
SMUX configuration
==================
-To enable SMUX protocol support, Frr must have been build with the
+To enable SMUX protocol support, FRR must have been build with the
`--enable-snmp=smux` option.
A separate connection has then to be established between the
-SNMP agent (snmpd) and each of the Frr daemons. This connections
+SNMP agent (snmpd) and each of the FRR daemons. This connections
each use different OID numbers and passwords. Be aware that this OID
number is not the one that is used in queries by clients, it is solely
used for the intercommunication of the daemons.
view all included .1 80
access MyROGroup "" any noauth exact all none none
#
- # the following line is relevant for Frr
+ # the following line is relevant for FRR
#
smuxpeer .1.3.6.1.4.1.3317.1.2.5 frr_ospfd
=========================
The following OID numbers are used for the interprocess communication of snmpd and
-the Frr daemons with SMUX only.
+the FRR daemons with SMUX only.
::
(OIDs below .iso.org.dod.internet.private.enterprises)
ospf6d .1.3.6.1.3.102 .iso.org.dod.internet.experimental.ospfv3
-The following syntax is understood by the Frr daemons for configuring SNMP using SMUX:
+The following syntax is understood by the FRR daemons for configuring SNMP using SMUX:
.. index:: {Command} {smux peer `oid`} {}
{Command} {smux peer `oid`} {}
The protocol that is used to communicate routing and Ethernet / L2
forwarding information between NVAs and NVEs is referred to as the
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.,
+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:
VTY shell
*********
-*vtysh* provides a combined frontend to all Frr daemons in a
+*vtysh* provides a combined frontend to all FRR daemons in a
single combined session. It is enabled by default at build time, but can
be disabled through the *--disable-vtysh* option to
*./configure*.
group (which is the group that the daemons will change ownership of their
sockets to).
-To restrict access to Frr configuration, make sure no unauthorized users
+To restrict access to FRR configuration, make sure no unauthorized users
are members of the *|INSTALL_VTY_GROUP|* group.
PAM support (experimental)
Writing the configuration can be triggered directly by invoking
*vtysh -w*. This may be useful for scripting. Note this command
-should be run as either the superuser or the Frr user.
+should be run as either the superuser or the FRR user.
We recommend you do not mix the use of the two types of files. Further, it
is better not to use the integrated frr.conf file, as any syntax error in
'write file' is issued.
These commands need to be placed in :file:`vtysh.conf` to have any effect.
- Note that since :file:`vtysh.conf` is not written by Frr itself, they
+ Note that since :file:`vtysh.conf` is not written by FRR itself, they
therefore need to be manually placed in that file.
This command has 3 states:
projects / mirror / frr.git / commitdiff