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
@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
access-list filter deny 10.0.0.0/9
access-list filter permit 10.0.0.0/8
-
+
@comment node-name, next, previous, up
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`]} {}
*@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.
overview
installation
basic
- zebra
+ zebra
ripd
ripngd
ospfd
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.
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:
mpls-te router-address 10.1.1.1
!
line vty
-
+
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
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
network 172.16.0.0/16
redistribute nhrp
exit-address-family
-
+
.. _Configuring_NHRP:
-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
::
nhrp nflog-group 1
-
+
To start sending these traffic notices out from hubs, use the nhrp
per-interface directive:
interface gre1
ip nhrp redirect
-
+
.. _Integration_with_IKE:
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
area 0.0.0.0 range 2001:770:105:2::/64
interface eth0 area 0.0.0.0
!
-
+
: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.
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*
: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.
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
* 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
@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.
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
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
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
| 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
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:
| 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:
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
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.
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
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`).
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
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
{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,
.. 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)} {}
!
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
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`]} {}
.. _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
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.
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)} {}
.. 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.
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:
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.
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:
mpls-te inter-as area 1
!
line vty
-
+
A router information example with PCE advsertisement:
pce neighbor as 65200
pce scope 0x80
!
-
+
@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
# zebra -d
# ripd -d
-
+
Please note that *zebra* must be invoked before *ripd*.
network 10.0.0.0/8
network eth0
!
-
+
Passive interface
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.
{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
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.
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.
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
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.
ip rip authentication mode md5
ip rip authentication key-chain test
!
-
+
.. _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:
``
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
203.181.89.241
Routing Information Sources:
Gateway BadPackets BadRoutes Distance Last Update
-
+
RIP Debug Commands
==================
::
distribute-list local-only out sit1
-
+
.. 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`} {}
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.
route-map rpki permit 500
match rpki valid
set local-preference 500
-
+
.. _Debugging:
!
route-map rpki permit 40
!
-
+
!
agentx
!
-
+
Upon successful connection, you should get something like this in the
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:
# 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
[snmpd]
# Use a remote master agent
agentXSocket tcp:192.168.15.12:705
-
+
.. _SMUX_configuration:
!
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.
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:
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`} {}
# 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.
::
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
*) suberror="Unknown" ;;
esac
;;
-02)
+02)
error="OPEN Message Error"
case "$suberrorcode" in
01) suberror="Unsupported Version Number" ;;
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)
`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.,
{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:
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
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} {}
vnc defaults
... various VNC defaults
exit-vnc
-
+
These are the statements that can appear between `vnc defaults`
and `exit-vnc`.
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
.. 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.
::
vnc nve-group group1
... configuration commands
exit-vnc
-
+
.. index:: {VNC} {no vnc nve-group `name`} {}
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`,
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,
{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.
{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.
{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.
{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.
.. 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.
::
vnc l2-group group1
... configuration commands
exit-vnc
-
+
.. index:: {VNC} {no vnc l2-group `name`} {}
{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`}
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).
`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.
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.
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.
`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
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)])} {}
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} {}
.. 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} {}
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
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.
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.
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
Routing entry for 10.0.0.0/8
Known via "static", distance 255, metric 0
directly connected, Null0
-
+
.. index:: Command {ipv6 route `network` `gateway`} {}
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.
set src 10.0.0.1
ip protocol rip route-map RM1
-
+
.. _zebra_FIB_push_interface:
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.
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} {}
projects / mirror_frr.git / commitdiff