From: Quentin Young <qlyoung@cumulusnetworks.com>
Date: Tue, 30 Jan 2018 20:05:15 +0000 (-0500)
Subject: Merge branch 'master' into docs-user
X-Git-Tag: frr-5.0-dev~165^2~63
X-Git-Url: https://git.puffer.fish/?a=commitdiff_plain;h=d38549c99dd39a6f5df0acd3efa48284d077ea66;p=mirror%2Ffrr.git

Merge branch 'master' into docs-user

Manually merged these doc commits:

3bb7cd7f56649ef17eeada95c132de1146c5fc92
ff21655441a64c427b3e373272e7b4564a8a1bb1
---

d38549c99dd39a6f5df0acd3efa48284d077ea66
diff --cc doc/user/bgp.rst
index 4ba69394b2,0000000000..06f124679f
mode 100644,000000..100644
--- a/doc/user/bgp.rst
+++ b/doc/user/bgp.rst
@@@ -1,2349 -1,0 +1,2335 @@@
 +.. _BGP:
 +
 +***
 +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`.
 +
 +Many extensions have been added to :rfc:`1771`. :rfc:`2858` provides
 +multiprotocol support to BGP-4.
 +
 +.. _Starting_BGP:
 +
 +Starting BGP
 +============
 +
 +Default configuration file of *bgpd* is :file:`bgpd.conf`.  *bgpd* searches the
 +current directory first then |INSTALL_PREFIX_ETC|/bgpd.conf. All of bgpd's
 +command must be configured in :file:`bgpd.conf`.
 +
 +*bgpd* specific invocation options are described below. Common options may also
 +be specified (:ref:`Common_Invocation_Options`).
 +
 +.. program:: bgpd
 +
 +.. option:: -p <port>
 +.. option:: --bgp_port <port>
 +
 +   Set the bgp protocol's port number.
 +
 +.. option:: -r
 +.. option:: --retain
 +
 +   When program terminates, retain BGP routes added by zebra.
 +
 +.. option:: -l
 +.. option:: --listenon
 +
 +   Specify a specific IP address for bgpd to listen on, rather than its
 +   default of INADDR_ANY / IN6ADDR_ANY. This can be useful to constrain bgpd
 +   to an internal address, or to run multiple bgpd processes on one host.
 +
 +
 +.. _BGP_router:
 +
 +BGP router
 +==========
 +
 +First of all you must configure BGP router with *router bgp* command. To
 +configure BGP router, you need AS number. AS number is an identification of
 +autonomous system. BGP protocol uses the AS number for detecting whether the
 +BGP connection is internal one or external one.
 +
 +.. index:: router bgp ASN
 +.. clicmd:: router bgp ASN
 +
 +   Enable a BGP protocol process with the specified ASN. After
 +   this statement you can input any `BGP Commands`. You can not
 +   create different BGP process under different ASN without
 +   specifying `multiple-instance` (:ref:`Multiple_instance`).
 +
 +.. index:: no router bgp ASN
 +.. clicmd:: no router bgp ASN
 +
 +   Destroy a BGP protocol process with the specified ASN.
 +
 +.. index:: bgp router-id A.B.C.D
 +.. clicmd:: bgp router-id A.B.C.D
 +
 +   This command specifies the router-ID. If *bgpd* connects to *zebra* it gets
 +   interface and address information. In that case default router ID value is
 +   selected as the largest IP Address of the interfaces. When `router zebra` is
 +   not enabled *bgpd* can't get interface information so `router-id` is set to
 +   0.0.0.0. So please set router-id by hand.
 +
 +.. _BGP_distance:
 +
 +BGP distance
 +------------
 +
 +.. index:: distance bgp (1-255) (1-255) (1-255)
 +.. clicmd:: distance bgp (1-255) (1-255) (1-255)
 +
 +   This command change distance value of BGP. Each argument is distance value
 +   for external routes, internal routes and local routes.
 +
 +.. index:: distance (1-255) A.B.C.D/M
 +.. clicmd:: distance (1-255) A.B.C.D/M
 +
 +.. index:: distance (1-255) A.B.C.D/M word
 +.. clicmd:: distance (1-255) A.B.C.D/M word
 +
 +.. _BGP_decision_process:
 +
 +BGP decision process
 +--------------------
 +
 +The decision process FRR BGP uses to select routes is as follows:
 +
 +1. Weight check
 +
 +
 +   Prefer higher local weight routes to lower routes.
 +
 +2. Local preference check
 +
 +
 +   Prefer higher local preference routes to lower.
 +
 +3. Local route check
 +
 +   Prefer local routes (statics, aggregates, redistributed) to received routes.
 +
 +4. AS path length check
 +
 +   Prefer shortest hop-count AS_PATHs.
 +
 +5. Origin check
 +
 +   Prefer the lowest origin type route. That is, prefer IGP origin routes to
 +   EGP, to Incomplete routes.
 +
 +6. MED check
 +
 +   Where routes with a MED were received from the same AS, prefer the route
 +   with the lowest MED. :ref:`BGP_MED`.
 +
 +7. External check
 +
 +   Prefer the route received from an external, eBGP peer over routes received
 +   from other types of peers.
 +
 +8. IGP cost check
 +
 +   Prefer the route with the lower IGP cost.
 +
 +9. Multi-path check
 +
 +   If multi-pathing is enabled, then check whether the routes not yet
 +   distinguished in preference may be considered equal. If
 +   :ref:`bgp_bestpath_as-path_multipath-relax` is set, all such routes are
 +   considered equal, otherwise routes received via iBGP with identical AS_PATHs
 +   or routes received from eBGP neighbours in the same AS are considered equal.
 +
 +10. Already-selected external check
 +
 +    Where both routes were received from eBGP peers, then prefer the route
 +    which is already selected. Note that this check is not applied if
 +    :ref:`bgp_bestpath_compare-routerid` is configured. This check can prevent
 +    some cases of oscillation.
 +
 +11. Router-ID check
 +
 +    Prefer the route with the lowest `router-ID`. If the route has an
 +    `ORIGINATOR_ID` attribute, through iBGP reflection, then that router ID is
 +    used, otherwise the `router-ID` of the peer the route was received from is
 +    used.
 +
 +12. Cluster-List length check
 +
 +    The route with the shortest cluster-list length is used. The cluster-list
 +    reflects the iBGP reflection path the route has taken.
 +
 +
 +13. Peer address
 +
 +    Prefer the route received from the peer with the higher
 +    transport layer address, as a last-resort tie-breaker.
 +
 +
 +.. index:: bgp bestpath as-path confed
 +.. clicmd:: bgp bestpath as-path confed
 +
 +   This command specifies that the length of confederation path sets and
 +   sequences should should be taken into account during the BGP best path
 +   decision process.
 +
 +.. _bgp_bestpath_as-path_multipath-relax:
 +.. index:: bgp bestpath as-path multipath-relax
 +.. clicmd:: bgp bestpath as-path multipath-relax
 +
 +   This command specifies that BGP decision process should consider paths
 +   of equal AS_PATH length candidates for multipath computation. Without
 +   the knob, the entire AS_PATH must match for multipath computation.
 +
 +.. _bgp_bestpath_compare-routerid:
 +.. clicmd:: bgp bestpath compare-routerid
 +
 +   Ensure that when comparing routes where both are equal on most metrics,
 +   including local-pref, AS_PATH length, IGP cost, MED, that the tie is broken
 +   based on router-ID.
 +
 +   If this option is enabled, then the already-selected check, where
 +   already selected eBGP routes are preferred, is skipped.
 +
 +   If a route has an `ORIGINATOR_ID` attribute because it has been reflected,
 +   that `ORIGINATOR_ID` will be used. Otherwise, the router-ID of the peer the
 +   route was received from will be used.
 +
 +   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
 +   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.
 +
 +
 +.. _BGP_route_flap_dampening:
 +
 +BGP route flap dampening
 +------------------------
 +
 +.. clicmd:: bgp dampening (1-45) (1-20000) (1-20000) (1-255)
 +
 +
 +   This command enables BGP route-flap dampening and specifies dampening parameters.
 +
 +
 +   half-life
 +      Half-life time for the penalty
 +
 +   reuse-threshold
 +      Value to start reusing a route
 +
 +   suppress-threshold
 +      Value to start suppressing a route
 +
 +   max-suppress
 +      Maximum duration to suppress a stable route
 +
 +   The route-flap damping algorithm is compatible with :rfc:`2439`. The use of
 +   this command is not recommended nowadays.
 +
 +.. seealso::
 +
 +   `http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378 <http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378>`_
 +
 +.. _BGP_MED:
 +
 +BGP MED
 +=======
 +
 +The BGP :abbr:`MED (Multi Exit Discriminator)` attribute has properties which
 +can 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 designing and
 +configuring their networks.
 +
 +The BGP :abbr:`MED` attribute is intended to allow one AS to indicate its
 +preferences for its ingress points to another AS. The MED attribute will not be
 +propagated on to another AS by the receiving AS - it is 'non-transitive' in the
 +BGP sense.
 +
 +E.g., if AS X and AS Y have 2 different BGP peering points, then AS X might set
 +a MED of 100 on routes advertised at one and a MED of 200 at the other. When AS
 +Y selects between otherwise equal routes to or via AS X, AS Y should prefer to
 +take the path via the lower MED peering of 100 with AS X. Setting the MED
 +allows an AS to influence the routing taken to it within another, neighbouring
 +AS.
 +
 +In this use of MED it is not really meaningful to compare the MED value on
 +routes where the next AS on the paths differs. E.g., if AS Y also had a route
 +for some destination via AS Z in addition to the routes from AS X, and AS Z had
 +also set a MED, it wouldn't make sense for AS Y to compare AS Z's MED values to
 +those of AS X. The MED values have been set by different 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
 +comparing the neighbouring, left-most AS in the received AS_PATHs of the routes
 +and only comparing MED if those are the same.
 +
 +Unfortunately, this behaviour of MED, of sometimes being compared across routes
 +and sometimes not, depending on the properties of those other routes, means MED
 +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 @footnote{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) 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
 +preferred to C, but C is preferred to A. This can be true even where BGP
 +defines a deterministic 'most preferred' route out of the full set of A,B,C.
 +With MED, for any given set of routes there may be a deterministically
 +preferred route, but there need not be any way to arrange them into any order
 +of preference. With unmodified MED, the order of preference of routes literally
 +becomes undefined.
 +
 +That MED can induce non-transitive preferences over routes can cause issues.
 +Firstly, it may be perceived to cause routing table churn locally at speakers;
 +secondly, and more seriously, it may cause routing instability in iBGP
 +topologies, where sets of speakers continually oscillate between different
 +paths.
 +
 +The first issue arises from how speakers often implement routing decisions.
 +Though BGP defines a selection process that will deterministically select the
 +same route as best at any given speaker, even with MED, that process requires
 +evaluating all routes together. For performance and ease of implementation
 +reasons, many implementations evaluate route preferences in a pair-wise fashion
 +instead. Given there is no well-defined order when MED is involved, the best
 +route that will be chosen becomes subject to implementation details, such as
 +the order the routes are stored in. That may be (locally) non-deterministic,
 +e.g.: it may be the order the routes were received in.
 +
 +This indeterminism may be considered undesirable, though it need not cause
 +problems. It may mean additional routing churn is perceived, as sometimes more
 +updates may be produced than at other times in reaction to some event .
 +
 +This first issue can be fixed with a more deterministic route selection that
 +ensures routes are ordered by the neighbouring AS during selection.
 +:ref:`bgp_deterministic-med`. This may reduce the number of updates as routes
 +are received, and may in some cases reduce routing churn. Though, it could
 +equally deterministically produce the largest possible set of updates in
 +response to the most common sequence of received updates.
 +
 +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
 +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 expensive
 +in terms of CPU.
 +
 +Deterministic local evaluation can *not* fix the second, more major, issue of
 +MED however. Which is that the non-transitive preference of routes MED can
 +cause may lead to routing instability or oscillation across multiple speakers
 +in iBGP topologies. This can occur with full-mesh iBGP, but is particularly
 +problematic in non-full-mesh iBGP topologies that further reduce the routing
 +information known to each speaker. This has primarily been documented with iBGP
 +route-reflection topologies. However, any route-hiding technologies potentially
 +could also exacerbate oscillation with MED.
 +
 +This second issue occurs where speakers each have only a subset of routes, and
 +there are cycles in the preferences between different combinations of routes -
 +as the undefined order of preference of MED allows - and the routes are
 +distributed in a way that causes the BGP speakers to 'chase' those cycles. This
 +can occur even if all speakers use a deterministic order of evaluation in route
 +selection.
 +
 +E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X, and from
 +speaker 3 in AS Y; while speaker 5 in AS A might receive that route from
 +speaker 1 in AS Y. AS Y might set a MED of 200 at speaker 1, and 100 at speaker
 +3. I.e, using ASN:ID:MED to label the speakers:
 +
 +::
 +
 +   .
 +             /---------------\\
 +   X:2------|--A:4-------A:5--|-Y:1:200
 +               Y:3:100--|-/   |
 +             \\---------------/
 +
 +
 +
 +Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs), then based
 +on the RFC4271 decision process speaker 4 will choose X:2 over Y:3:100, based
 +on the lower ID of 2. Speaker 4 advertises X:2 to speaker 5.  Speaker 5 will
 +continue to prefer Y:1:200 based on the ID, and advertise this to speaker 4.
 +Speaker 4 will now have the full set of routes, and the Y:1:200 it receives
 +from 5 will beat X:2, but when speaker 4 compares Y:1:200 to Y:3:100 the MED
 +check now becomes active as the ASes match, and now Y:3:100 is preferred.
 +Speaker 4 therefore now advertises Y:3:100 to 5, which will also agrees that
 +Y:3:100 is preferred to Y:1:200, and so withdraws the latter route from 4.
 +Speaker 4 now has only X:2 and Y:3:100, and X:2 beats Y:3:100, and so speaker 4
 +implicitly updates its route to speaker 5 to X:2. Speaker 5 sees that Y:1:200
 +beats X:2 based on the ID, and advertises Y:1:200 to speaker 4, and the cycle
 +continues.
 +
 +The root cause is the lack of a clear order of preference caused by how MED
 +sometimes is and sometimes is not compared, leading to this cycle in the
 +preferences between the routes:
 +
 +::
 +
 +   .
 +    /---> X:2 ---beats---> Y:3:100 --\\
 +   |                                   |
 +   |                                   |
 +    \\---beats--- Y:1:200 <---beats---/
 +
 +
 +
 +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 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`,
 +.
 +
 +However, more complex and insidious cycles of oscillation are possible with
 +iBGP route-reflection, which are not so easily avoided. These have been
 +documented in various places. See, e.g.:
 +
 +- [bgp-route-osci-cond]_
 +- [stable-flexible-ibgp]_
 +- [ibgp-correctness]_
 +
 +for concrete examples and further references.
 +
 +There is as of this writing *no* known way to use MED for its original purpose;
 +*and* reduce routing information in iBGP topologies; *and* be sure to avoid the
 +instability problems of MED due the non-transitive routing preferences it can
 +induce; in general on arbitrary networks.
 +
 +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
 +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
 +routes to all speakers as a full-mesh iBGP would, if not more, while also
 +imposing similar CPU overheads as the "Deterministic MED" feature at each
 +Add-Path reflector.
 +
 +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
 +  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
 +  and most performant way to avoid MED oscillation issues, where an AS is happy
 +  not to allow neighbours to inject this problematic metric.
 +
 +As MED is evaluated after the AS_PATH length check, another possible use for
 +MED is for intra-AS steering of routes with equal AS_PATH length, as an
 +extension of the last case above. As MED is evaluated before IGP metric, this
 +can allow cold-potato routing to be implemented to send traffic to preferred
 +hand-offs with neighbours, rather than the closest hand-off according to the
 +IGP metric.
 +
 +Note that even if action is taken to address the MED non-transitivity issues,
 +other oscillations may still be possible. E.g., on IGP cost if iBGP and IGP
 +topologies are at cross-purposes with each other - see the Flavel and Roughan
 +paper above for an example. Hence the guideline that the iBGP topology should
 +follow the IGP topology.
 +
 +.. _bgp_deterministic-med:
 +.. index:: bgp deterministic-med
 +.. clicmd:: bgp deterministic-med
 +
 +   Carry out route-selection in way that produces deterministic answers
 +   locally, even in the face of MED and the lack of a well-defined order of
 +   preference it can induce on routes. Without this option the preferred route
 +   with MED may be determined largely by the order that routes were received
 +   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
 +   implemented in a way that scales poorly as the number of routes per
 +   destination increases.
 +
 +   The default is that this option is not set.
 +
 +Note that there are other sources of indeterminism in the route selection
 +process, specifically, the preference for older and already selected routes
 +from eBGP peers, :ref:`BGP_decision_process`.
 +
 +.. 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
 +   oscillations.
 +
 +   If using this option, it may also be desirable to use
 +   :ref:`routemap_set_metric` to set MED to 0 on routes received from external
 +   neighbours.
 +
 +   This option can be used, together with :ref:`routemap_set_metric` to use MED
 +   as an intra-AS metric to steer equal-length AS_PATH routes to, e.g., desired
 +   exit points.
 +
 +.. _BGP_network:
 +
 +BGP network
 +===========
 +
 +
 +.. _BGP_route:
 +
 +BGP route
 +---------
 +
 +.. index:: network A.B.C.D/M
 +.. clicmd:: network A.B.C.D/M
 +
 +   This command adds the announcement network.::
 +
 +     router bgp 1
 +      address-family ipv4 unicast
 +       network 10.0.0.0/8
 +      exit-address-family
 +
 +   This configuration example says that network 10.0.0.0/8 will be
 +   announced to all neighbors. Some vendors' routers don't advertise
 +   routes if they aren't present in their IGP routing tables; `bgpd`
 +   doesn't care about IGP routes when announcing its routes.
 +
 +.. index:: no network A.B.C.D/M
 +.. clicmd:: no network A.B.C.D/M
 +
 +
 +.. _Route_Aggregation:
 +
 +Route Aggregation
 +-----------------
 +
 +.. index:: aggregate-address A.B.C.D/M
 +.. clicmd:: aggregate-address A.B.C.D/M
 +
 +   This command specifies an aggregate address.
 +
 +.. index:: aggregate-address A.B.C.D/M as-set
 +.. clicmd:: aggregate-address A.B.C.D/M as-set
 +
 +   This command specifies an aggregate address. Resulting routes include
 +   AS set.
 +
 +.. 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
 +   not be announce.
 +
 +.. index:: no aggregate-address A.B.C.D/M
 +.. clicmd:: no aggregate-address A.B.C.D/M
 +
 +
 +
 +.. _Redistribute_to_BGP:
 +
 +Redistribute to BGP
 +-------------------
 +
 +.. index:: redistribute kernel
 +.. clicmd:: redistribute kernel
 +
 +   Redistribute kernel route to BGP process.
 +
 +.. index:: redistribute static
 +.. clicmd:: redistribute static
 +
 +   Redistribute static route to BGP process.
 +
 +.. index:: redistribute connected
 +.. clicmd:: redistribute connected
 +
 +   Redistribute connected route to BGP process.
 +
 +.. index:: redistribute rip
 +.. clicmd:: redistribute rip
 +
 +   Redistribute RIP route to BGP process.
 +
 +.. index:: redistribute ospf
 +.. clicmd:: redistribute ospf
 +
 +   Redistribute OSPF route to BGP process.
 +
 +.. index:: redistribute vpn
 +.. clicmd:: redistribute vpn
 +
 +   Redistribute VNC routes to BGP process.
 +
 +.. index:: update-delay MAX-DELAY
 +.. clicmd:: update-delay MAX-DELAY
 +
 +.. index:: update-delay MAX-DELAY ESTABLISH-WAIT
 +.. clicmd:: update-delay MAX-DELAY ESTABLISH-WAIT
 +
 +   This feature is used to enable read-only mode on BGP process restart or when
 +   BGP process is cleared using 'clear ip bgp \*'. When applicable, read-only
 +   mode would begin as soon as the first peer reaches Established status and a
 +   timer for max-delay seconds is started.
 +
 +   During this mode BGP doesn't run any best-path or generate any updates to its
 +   peers. This mode continues until:
 +
 +   1. All the configured peers, except the shutdown peers, have sent explicit EOR
 +      (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
 +      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.
 +   2. max-delay period is over.
 +
 +   On hitting any of the above two conditions, BGP resumes the decision process
 +   and generates updates to its peers.
 +
 +   Default max-delay is 0, i.e. the feature is off by default.
 +
 +.. index:: table-map ROUTE-MAP-NAME
 +.. clicmd:: table-map ROUTE-MAP-NAME
 +
 +   This feature is used to apply a route-map on route updates from BGP to
 +   Zebra.  All the applicable match operations are allowed, such as match on
 +   prefix, next-hop, communities, etc. Set operations for this attach-point are
 +   limited to metric and next-hop only. Any operation of this feature does not
 +   affect BGPs internal RIB.
 +
 +   Supported for ipv4 and ipv6 address families. It works on multi-paths as
 +   well, however, metric setting is based on the best-path only.
 +
 +.. _BGP_Peer:
 +
 +BGP Peer
 +========
 +
 +.. _Defining_Peer:
 +
 +Defining Peer
 +-------------
 +
 +.. index:: neighbor PEER remote-as ASN
 +.. clicmd:: neighbor PEER remote-as ASN
 +
 +
 +   Creates a new neighbor whose remote-as is ASN. PEER can be an IPv4 address
 +   or an IPv6 address.::
 + 
 +      router bgp 1
 +       neighbor 10.0.0.1 remote-as 2
 + 
 +   In this case my router, in AS-1, is trying to peer with AS-2 at 10.0.0.1.
 + 
 +   This command must be the first command used when configuring a neighbor.  If
 +   the remote-as is not specified, *bgpd* will complain like this:::
 + 
 +      can't find neighbor 10.0.0.1
 +
 +
 +.. _BGP_Peer_commands:
 +
 +BGP Peer commands
 +-----------------
 +
 +In a `router bgp` clause there are neighbor specific configurations
 +required.
 +
 +.. index:: neighbor PEER shutdown
 +.. clicmd:: neighbor PEER shutdown
 +
 +.. index:: no neighbor PEER shutdown
 +.. clicmd:: no neighbor PEER shutdown
 +
 +   Shutdown the peer. We can delete the neighbor's configuration by
 +   ``no neighbor PEER remote-as ASN`` but all configuration of the neighbor
 +   will be deleted. When you want to preserve the configuration, but want to
 +   drop the BGP peer, use this syntax.
 +
 +.. index:: neighbor PEER ebgp-multihop
 +.. clicmd:: neighbor PEER ebgp-multihop
 +
 +.. index:: no neighbor PEER ebgp-multihop
 +.. clicmd:: no neighbor PEER ebgp-multihop
 +
 +
 +.. index:: neighbor PEER description ...
 +.. clicmd:: neighbor PEER description ...
 +
 +
 +.. index:: no neighbor PEER description ...
 +.. clicmd:: no neighbor PEER description ...
 +
 +   Set description of the peer.
 +
 +.. index:: neighbor PEER version VERSION
 +.. clicmd:: neighbor PEER version VERSION
 +
 +   Set up the neighbor's BGP version. `version` can be `4`,
 +   `4+` or `4-`. BGP version `4` is the default value used for
 +   BGP peering. BGP version `4+` means that the neighbor supports
 +   Multiprotocol Extensions for BGP-4. BGP version `4-` is similar but
 +   the neighbor speaks the old Internet-Draft revision 00's Multiprotocol
 +   Extensions for BGP-4. Some routing software is still using this
 +   version.
 +
 +.. index:: neighbor PEER interface IFNAME
 +.. clicmd:: neighbor PEER interface IFNAME
 +
 +
 +.. index:: no neighbor PEER interface IFNAME
 +.. clicmd:: no neighbor PEER interface IFNAME
 +
 +   When you connect to a BGP peer over an IPv6 link-local address, you have to
 +   specify the IFNAME of the interface used for the connection. To specify
 +   IPv4 session addresses, see the ``neighbor PEER update-source`` command
 +   below.
 +
 +   This command is deprecated and may be removed in a future release. Its use
 +   should be avoided.
 +
 +.. index:: neighbor PEER next-hop-self [all]
 +.. clicmd:: neighbor PEER next-hop-self [all]
 +
 +
 +.. index:: no neighbor PEER next-hop-self [all]
 +.. clicmd:: no neighbor PEER next-hop-self [all]
 +
 +   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
 +   via iBGP.
 +
 +.. index:: neighbor PEER update-source <IFNAME|ADDRESS>
 +.. clicmd:: neighbor PEER update-source <IFNAME|ADDRESS>
 +
 +
 +.. index:: no neighbor PEER update-source
 +.. clicmd:: no neighbor PEER update-source
 +
 +   Specify the IPv4 source address to use for the :abbr:`BGP` session to this
 +   neighbour, may be specified as either an IPv4 address directly or as an
 +   interface name (in which case the *zebra* daemon MUST be running in order
 +   for *bgpd* to be able to retrieve interface state).::
 +
 +      router bgp 64555
 +       neighbor foo update-source 192.168.0.1
 +       neighbor bar update-source lo0
 +
 +
 +.. index:: neighbor PEER default-originate
 +.. clicmd:: neighbor PEER default-originate
 +
 +.. index:: no neighbor PEER default-originate
 +.. clicmd:: no neighbor PEER default-originate
 +
 +   *bgpd*'s default is to not announce the default route (0.0.0.0/0) even it
 +   is in routing table. When you want to announce default routes to the
 +   peer, use this command.
 +
 +.. index:: neighbor PEER port PORT
 +.. clicmd:: neighbor PEER port PORT
 +
 +.. index:: neighbor PEER send-community
 +.. clicmd:: neighbor PEER send-community
 +
 +.. index:: neighbor PEER weight WEIGHT
 +.. clicmd:: neighbor PEER weight WEIGHT
 +
 +
 +.. index:: no neighbor PEER weight WEIGHT
 +.. clicmd:: no neighbor PEER weight WEIGHT
 +
 +   This command specifies a default `weight` value for the neighbor's routes.
 +
 +.. index:: neighbor PEER maximum-prefix NUMBER
 +.. clicmd:: neighbor PEER maximum-prefix NUMBER
 +
 +
 +.. index:: no neighbor PEER maximum-prefix NUMBER
 +.. clicmd:: no neighbor PEER maximum-prefix NUMBER
 +
 +
 +.. index:: neighbor PEER local-as AS-NUMBER
 +.. clicmd:: neighbor PEER local-as AS-NUMBER
 +
 +
 +.. index:: neighbor PEER local-as AS-NUMBER no-prepend
 +.. clicmd:: neighbor PEER local-as AS-NUMBER no-prepend
 +
 +
 +.. index:: neighbor PEER local-as AS-NUMBER no-prepend replace-as
 +.. clicmd:: neighbor PEER local-as AS-NUMBER no-prepend replace-as
 +
 +
 +.. index:: no neighbor PEER local-as
 +.. clicmd:: no neighbor PEER local-as
 +
 +   Specify an alternate AS for this BGP process when interacting with the
 +   specified peer. With no modifiers, the specified local-as is prepended to
 +   the received AS_PATH when receiving routing updates from the peer, and
 +   prepended to the outgoing AS_PATH (after the process local AS) when
 +   transmitting local routes to the peer.
 +
 +   If the no-prepend attribute is specified, then the supplied local-as is not
 +   prepended to the received AS_PATH.
 +
 +   If the replace-as attribute is specified, then only the supplied local-as is
 +   prepended to the AS_PATH when transmitting local-route updates to this peer.
 +
 +   Note that replace-as can only be specified if no-prepend is.
 +
 +   This command is only allowed for eBGP peers.
 +
 +.. index:: neighbor PEER ttl-security hops NUMBER
 +.. clicmd:: neighbor PEER ttl-security hops NUMBER
 +
 +
 +.. index:: no neighbor PEER ttl-security hops NUMBER
 +.. clicmd:: no neighbor PEER ttl-security hops NUMBER
 +
 +   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*.
 +
 +.. _Peer_filtering:
 +
 +Peer filtering
 +--------------
 +
 +.. index:: neighbor PEER distribute-list NAME [in|out]
 +.. clicmd:: neighbor PEER distribute-list NAME [in|out]
 +
 +   This command specifies a distribute-list for the peer. `direct` is
 +   ``in`` or ``out``.
 +
 +.. index:: neighbor PEER prefix-list NAME [in|out]
 +.. clicmd:: neighbor PEER prefix-list NAME [in|out]
 +
 +.. index:: neighbor PEER filter-list NAME [in|out]
 +.. clicmd:: neighbor PEER filter-list NAME [in|out]
 +
 +.. index:: neighbor PEER route-map NAME [in|out]
 +.. clicmd:: neighbor PEER route-map NAME [in|out]
 +
 +   Apply a route-map on the neighbor. `direct` must be `in` or `out`.
 +
 +.. index:: bgp route-reflector allow-outbound-policy
 +.. clicmd:: bgp route-reflector allow-outbound-policy
 +
 +   By default, attribute modification via route-map policy out is not reflected
 +   on reflected routes. This option allows the modifications to be reflected as
 +   well. Once enabled, it affects all reflected routes.
 +
 +.. _BGP_Peer_Group:
 +
 +BGP Peer Group
 +==============
 +
 +.. index:: neighbor WORD peer-group
 +.. clicmd:: neighbor WORD peer-group
 +
 +   This command defines a new peer group.
 +
 +.. index:: neighbor PEER peer-group WORD
 +.. clicmd:: neighbor PEER peer-group WORD
 +
 +   This command bind specific peer to peer group WORD.
 +
 +.. _BGP_Address_Family:
 +
 +BGP Address Family
 +==================
 +
 +Multiprotocol BGP enables BGP to carry routing information for multiple Network
 +Layer protocols. BGP supports multiple Address Family Identifier (AFI), namely
 +IPv4 and IPv6. Support is also provided for multiple sets of per-AFI
 +information via Subsequent Address Family Identifiers (SAFI). In addition to
 +unicast information, VPN information :rfc:`4364` and :rfc:`4659`, and
- Encapsulation information :rfc:`5512` is supported.
++Encapsulation attribute :rfc:`5512` is supported.
 +
- .. index:: show ip bgp vpnv4 all
- .. clicmd:: show ip bgp vpnv4 all
++.. index:: show ip bgp ipv4 vpn
++.. clicmd:: show ip bgp ipv4 vpn
 +
- .. index:: show ipv6 bgp vpn all
- .. clicmd:: show ipv6 bgp vpn all
++.. index:: show ipv6 bgp ipv6 vpn
++.. clicmd:: show ipv6 bgp ipv6 vpn
 +
 +   Print active IPV4 or IPV6 routes advertised via the VPN SAFI.
 +
- .. index:: show ip bgp encap all
- .. clicmd:: show ip bgp encap all
- 
- .. index:: show ipv6 bgp encap all
- .. clicmd:: show ipv6 bgp encap all
- 
-    Print active IPV4 or IPV6 routes advertised via the Encapsulation SAFI.
- 
- .. index:: show bgp ipv4 encap summary
- .. clicmd:: show bgp ipv4 encap summary
- 
 +.. index:: show bgp ipv4 vpn summary
 +.. clicmd:: show bgp ipv4 vpn summary
 +
- .. index:: show bgp ipv6 encap summary
- .. clicmd:: show bgp ipv6 encap summary
- 
 +.. index:: show bgp ipv6 vpn summary
 +.. clicmd:: show bgp ipv6 vpn summary
 +
 +   Print a summary of neighbor connections for the specified AFI/SAFI combination.
 +
 +.. _Autonomous_System:
 +
 +Autonomous System
 +=================
 +
 +The :abbr:`AS (Autonomous System)` number is one of the essential element of
 +BGP. BGP is a distance vector routing protocol, and the AS-Path framework
 +provides distance vector metric and loop detection to BGP. :rfc:`1930` provides
 +some background on the concepts of an AS.
 +
 +The AS number is a two octet value, ranging in value from 1 to 65535. The AS
 +numbers 64512 through 65535 are defined as private AS numbers. Private AS
 +numbers must not to be advertised in the global Internet.
 +
 +.. _Display_BGP_Routes_by_AS_Path:
 +
 +Display BGP Routes by AS Path
 +-----------------------------
 +
 +To show BGP routes which has specific AS path information `show ip bgp` command
 +can be used.
 +
 +.. index:: show bgp ipv4|ipv6 regexp LINE
 +.. clicmd:: show bgp ipv4|ipv6 regexp LINE
 +
 +   This commands displays BGP routes that matches a regular
 +   expression `line` (:ref:`BGP_Regular_Expressions`).
 +
 +.. _AS_Path_Access_List:
 +
 +AS Path Access List
 +-------------------
 +
 +AS path access list is user defined AS path.
 +
 +.. index:: ip as-path access-list WORD permit|deny LINE
 +.. clicmd:: ip as-path access-list WORD permit|deny LINE
 +
 +   This command defines a new AS path access list.
 +
 +.. index:: no ip as-path access-list WORD
 +.. clicmd:: no ip as-path access-list WORD
 +
 +.. index:: no ip as-path access-list WORD permit|deny LINE
 +.. clicmd:: no ip as-path access-list WORD permit|deny LINE
 +
 +.. _Using_AS_Path_in_Route_Map:
 +
 +Using AS Path in Route Map
 +--------------------------
 +
 +.. index:: match as-path WORD
 +.. clicmd:: match as-path WORD
 +
 +
 +.. index:: set as-path prepend AS-PATH
 +.. clicmd:: set as-path prepend AS-PATH
 +
 +   Prepend the given string of AS numbers to the AS_PATH.
 +
 +.. index:: set as-path prepend last-as NUM
 +.. clicmd:: set as-path prepend last-as NUM
 +
 +   Prepend the existing last AS number (the leftmost ASN) to the AS_PATH.
 +
 +.. _Private_AS_Numbers:
 +
 +Private AS Numbers
 +------------------
 +
 +.. _BGP_Communities_Attribute:
 +
 +BGP Communities Attribute
 +=========================
 +
 +BGP communities attribute is widely used for implementing policy routing.
 +Network operators can manipulate BGP communities attribute based on their
 +network policy. BGP communities attribute is defined in :rfc:`1997` and
 +:rfc:`1998`. It is an optional transitive attribute, therefore local policy can
 +travel through different autonomous system.
 +
 +Communities attribute is a set of communities values. Each communities value is
 +4 octet long. The following format is used to define communities value.
 +
 +
 +AS:VAL
 +   This format represents 4 octet communities value. ``AS`` is high order 2
 +   octet in digit format. ``VAL`` is low order 2 octet in digit format. This
 +   format is useful to define AS oriented policy value. For example,
 +   ``7675:80`` can be used when AS 7675 wants to pass local policy value 80 to
 +   neighboring peer.
 +
 +internet
 +   `internet` represents well-known communities value 0.
 +
 +no-export
 +   ``no-export`` represents well-known communities value ``NO_EXPORT``
 +   ``0xFFFFFF01``. All routes carry this value must not be advertised to
 +   outside a BGP confederation boundary. If neighboring BGP peer is part of BGP
 +   confederation, the peer is considered as inside a BGP confederation
 +   boundary, so the route will be announced to the peer.
 +
 +no-advertise
 +   ``no-advertise`` represents well-known communities value ``NO_ADVERTISE``
 +   ``0xFFFFFF02``. All routes carry this value must not be advertise to other
 +   BGP peers.
 +
 +local-AS
 +   ``local-AS`` represents well-known communities value ``NO_EXPORT_SUBCONFED``
 +   ``0xFFFFFF03``. All routes carry this value must not be advertised to
 +   external BGP peers. Even if the neighboring router is part of confederation,
 +   it is considered as external BGP peer, so the route will not be announced to
 +   the peer.
 +
 +When BGP communities attribute is received, duplicated communities value in the
 +communities attribute is ignored and each communities values are sorted in
 +numerical order.
 +
 +.. _BGP_Community_Lists:
 +
 +BGP Community Lists
 +-------------------
 +
 +BGP community list is a user defined BGP communites attribute list. BGP
 +community list can be used for matching or manipulating BGP communities
 +attribute in updates.
 +
 +There are two types of community list. One is standard community list and
 +another is expanded community list. Standard community list defines communities
 +attribute. Expanded community list defines communities attribute string with
 +regular expression. Standard community list is compiled into binary format when
 +user define it. Standard community list will be directly compared to BGP
 +communities attribute in BGP updates. Therefore the comparison is faster than
 +expanded community list.
 +
 +.. index:: ip community-list standard NAME permit|deny COMMUNITY
 +.. clicmd:: ip community-list standard NAME permit|deny COMMUNITY
 +
 +   This command defines a new standard community list. COMUNITY is
 +   communities value. The COMUNITY is compiled into community structure. We
 +   can define multiple community list under same name. In that case match will
 +   happen user defined order. Once the community list matches to communities
 +   attribute in BGP updates it return permit or deny by the community list
 +   definition. When there is no matched entry, deny will be returned. When
 +   COMUNITY is empty it matches to any routes.
 +
 +.. index:: ip community-list expanded NAME permit|deny LINE
 +.. clicmd:: ip community-list expanded NAME permit|deny LINE
 +
 +   This command defines a new expanded community list. COMUNITY is a
 +   string expression of communities attribute. COMUNITY can be a
 +   regular expression (:ref:`BGP_Regular_Expressions`) to match
 +   the communities attribute in BGP updates.
 +
 +.. index:: no ip community-list NAME
 +.. clicmd:: no ip community-list NAME
 +
 +.. index:: no ip community-list standard NAME
 +.. clicmd:: no ip community-list standard NAME
 +
 +.. index:: no ip community-list expanded NAME
 +.. clicmd:: no ip community-list expanded NAME
 +
 +   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.
 +
 +.. index:: show ip community-list
 +.. clicmd:: show ip community-list
 +
 +.. index:: show ip community-list NAME
 +.. clicmd:: show ip community-list NAME
 +
 +   This command displays current community list information. When NAME is
 +   specified the specified community list's information is shown.
 +
 +   ::
 +   
 +       # show ip community-list
 +       Named Community standard list CLIST
 +       permit 7675:80 7675:100 no-export
 +       deny internet
 +         Named Community expanded list EXPAND
 +       permit :
 +   
 +         # show ip community-list CLIST
 +         Named Community standard list CLIST
 +       permit 7675:80 7675:100 no-export
 +       deny internet
 +
 +
 +.. _Numbered_BGP_Community_Lists:
 +
 +Numbered BGP Community Lists
 +----------------------------
 +
 +When number is used for BGP community list name, the number has
 +special meanings. Community list number in the range from 1 and 99 is
 +standard community list. Community list number in the range from 100
 +to 199 is expanded community list. These community lists are called
 +as numbered community lists. On the other hand normal community lists
 +is called as named community lists.
 +
 +.. index:: ip community-list (1-99) permit|deny COMMUNITY
 +.. clicmd:: ip community-list (1-99) permit|deny COMMUNITY
 +
 +   This command defines a new community list. (1-99) is standard
 +   community list number. Community list name within this range defines
 +   standard community list. When `community` is empty it matches to
 +   any routes.
 +
 +.. index:: ip community-list (100-199) permit|deny COMMUNITY
 +.. clicmd:: ip community-list (100-199) permit|deny COMMUNITY
 +
 +   This command defines a new community list. (100-199) is expanded
 +   community list number. Community list name within this range defines
 +   expanded 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
 +   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.
 +
 +.. _BGP_Community_in_Route_Map:
 +
 +BGP Community in Route Map
 +--------------------------
 +
 +In Route Map (:ref:`Route_Map`), we can match or set BGP
 +communities attribute. Using this feature network operator can
 +implement their network policy based on BGP communities attribute.
 +
 +Following commands can be used in Route Map.
 +
 +.. index:: match community WORD
 +.. clicmd:: match community WORD
 +
 +.. index:: match community WORD exact-match
 +.. clicmd:: match community WORD exact-match
 +
 +   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
 +   happen only when BGP updates have completely same communities value
 +   specified in the community list.
 +
 +.. index:: set community none
 +.. clicmd:: set community none
 +
 +.. index:: set community COMMUNITY
 +.. clicmd:: set community COMMUNITY
 +
 +.. index:: set community COMMUNITY additive
 +.. clicmd:: set community COMMUNITY additive
 +
 +   This command manipulate communities value in BGP updates. When
 +   `none` is specified as communities value, it removes entire
 +   communities attribute from BGP updates. When `community` is not
 +   `none`, specified communities value is set to BGP updates. If
 +   BGP updates already has BGP communities value, the existing BGP
 +   communities value is replaced with specified `community` value.
 +   When `additive` keyword is specified, `community` is appended
 +   to the existing communities value.
 +
 +.. index:: set comm-list WORD delete
 +.. clicmd:: set comm-list WORD delete
 +
 +   This command remove communities value from BGP communities attribute.
 +   The `word` is community list name. When BGP route's communities
 +   value matches to the community list `word`, the communities value
 +   is removed. When all of communities value is removed eventually, the
 +   BGP update's communities attribute is completely removed.
 +
 +.. _Display_BGP_Routes_by_Community:
 +
 +Display BGP Routes by Community
 +-------------------------------
 +
 +To show BGP routes which has specific BGP communities attribute,
 +`show bgp {ipv4|ipv6}` command can be used. The
 +`community` and `community-list` subcommand can be used.
 +
 +.. index:: show bgp ipv4|ipv6 community
 +.. clicmd:: show bgp ipv4|ipv6 community
 +
 +.. index:: show bgp ipv4|ipv6 community COMMUNITY
 +.. clicmd:: show bgp ipv4|ipv6 community COMMUNITY
 +
 +.. index:: show bgp ipv4|ipv6 community COMMUNITY exact-match
 +.. clicmd:: show bgp ipv4|ipv6 community COMMUNITY exact-match
 +
 +   `show bgp {ipv4|ipv6} community` displays BGP routes which has communities
 +   attribute. Where the address family can be IPv4 or IPv6 among others. When
 +   `community` is specified, BGP routes that matches `community` value is
 +   displayed. For this command, `internet` keyword can't be used for
 +   `community` value. When `exact-match` is specified, it display only
 +   routes that have an exact match.
 +
 +.. index:: show bgp ipv4|ipv6 community-list WORD
 +.. clicmd:: show bgp ipv4|ipv6 community-list WORD
 +
 +.. index:: show bgp ipv4|ipv6 community-list WORD exact-match
 +.. clicmd:: show bgp ipv4|ipv6 community-list WORD exact-match
 +
 +   This commands display BGP routes for the address family specified that matches
 +   community list `word`. When `exact-match` is specified, display only
 +   routes that have an exact match.
 +
 +.. _Using_BGP_Communities_Attribute:
 +
 +Using BGP Communities Attribute
 +-------------------------------
 +
 +Following configuration is the most typical usage of BGP communities
 +attribute. AS 7675 provides upstream Internet connection to AS 100.
 +When following configuration exists in AS 7675, AS 100 networks
 +operator can set local preference in AS 7675 network by setting BGP
 +communities attribute to the updates.::
 +
 +   router bgp 7675
 +    neighbor 192.168.0.1 remote-as 100
 +    address-family ipv4 unicast
 +     neighbor 192.168.0.1 route-map RMAP in
 +    exit-address-family
 +   !
 +   ip community-list 70 permit 7675:70
 +   ip community-list 70 deny
 +   ip community-list 80 permit 7675:80
 +   ip community-list 80 deny
 +   ip community-list 90 permit 7675:90
 +   ip community-list 90 deny
 +   !
 +   route-map RMAP permit 10
 +    match community 70
 +    set local-preference 70
 +   !
 +   route-map RMAP permit 20
 +    match community 80
 +    set local-preference 80
 +   !
 +   route-map RMAP permit 30
 +    match community 90
 +    set local-preference 90
 +
 +
 +Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675.
 +The route has communities value 7675:80 so when above configuration
 +exists in AS 7675, announced route's local preference will be set to
 +value 80.::
 +
 +   router bgp 100
 +    network 10.0.0.0/8
 +    neighbor 192.168.0.2 remote-as 7675
 +    address-family ipv4 unicast
 +     neighbor 192.168.0.2 route-map RMAP out
 +    exit-address-family
 +   !
 +   ip prefix-list PLIST permit 10.0.0.0/8
 +   !
 +   route-map RMAP permit 10
 +    match ip address prefix-list PLIST
 +    set community 7675:80
 +
 +
 +Following configuration is an example of BGP route filtering using
 +communities attribute. This configuration only permit BGP routes
 +which has BGP communities value 0:80 or 0:90. Network operator can
 +put special internal communities value at BGP border router, then
 +limit the BGP routes announcement into the internal network.::
 +
 +   router bgp 7675
 +    neighbor 192.168.0.1 remote-as 100
 +    address-family ipv4 unicast
 +     neighbor 192.168.0.1 route-map RMAP in
 +    exit-address-family
 +   !
 +   ip community-list 1 permit 0:80 0:90
 +   !
 +   route-map RMAP permit in
 +    match community 1
 +
 +
 +Following exmaple 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.::
 +
 +   router bgp 7675
 +    neighbor 192.168.0.1 remote-as 100
 +    address-family ipv4 unicast
 +     neighbor 192.168.0.1 route-map RMAP in
 +    exit-address-family
 +   !
 +   ip community-list standard FILTER deny 1:1
 +   ip community-list standard FILTER permit
 +   !
 +   route-map RMAP permit 10
 +    match community FILTER
 +
 +
 +Communities value keyword `internet` has special meanings in
 +standard community lists. In below example `internet` act as
 +match any. It matches all of BGP routes even if the route does not
 +have communities attribute at all. So community list ``INTERNET``
 +is same as above example's ``FILTER``.::
 +
 +   ip community-list standard INTERNET deny 1:1
 +   ip community-list standard INTERNET permit internet
 +
 +
 +Following configuration is an example of communities value deletion.
 +With this configuration communities value 100:1 and 100:2 is removed
 +from BGP updates. For communities value deletion, only `permit`
 +community-list is used. `deny` community-list is ignored.::
 +
 +   router bgp 7675
 +    neighbor 192.168.0.1 remote-as 100
 +    address-family ipv4 unicast
 +     neighbor 192.168.0.1 route-map RMAP in
 +    exit-address-family
 +   !
 +   ip community-list standard DEL permit 100:1 100:2
 +   !
 +   route-map RMAP permit 10
 +    set comm-list DEL delete
 +
 +
 +.. _BGP_Extended_Communities_Attribute:
 +
 +BGP Extended Communities Attribute
 +==================================
 +
 +BGP extended communities attribute is introduced with MPLS VPN/BGP technology.
 +MPLS VPN/BGP expands capability of network infrastructure to provide VPN
 +functionality. At the same time it requires a new framework for policy routing.
 +With BGP Extended Communities Attribute we can use Route Target or Site of
 +Origin for implementing network policy for MPLS VPN/BGP.
 +
 +BGP Extended Communities Attribute is similar to BGP Communities Attribute. It
 +is an optional transitive attribute. BGP Extended Communities Attribute can
 +carry multiple Extended Community value.  Each Extended Community value is
 +eight octet length.
 +
 +BGP Extended Communities Attribute provides an extended range compared with BGP
 +Communities Attribute. Adding to that there is a type field in each value to
 +provides community space structure.
 +
 +There are two format to define Extended Community value. One is AS based format
 +the other is IP address based format.
 +
 +*AS:VAL*
 +   This is a format to define AS based Extended Community value.
 +   `AS` part is 2 octets Global Administrator subfield in Extended
 +   Community value. `VAL` part is 4 octets Local Administrator
 +   subfield. `7675:100` represents AS 7675 policy value 100.
 +
 +*IP-Address:VAL*
 +   This is a format to define IP address based Extended Community value.
 +   `IP-Address` part is 4 octets Global Administrator subfield.
 +   `VAL` part is 2 octets Local Administrator subfield.
 +   `10.0.0.1:100` represents
 +
 +.. _BGP_Extended_Community_Lists:
 +
 +BGP Extended Community Lists
 +----------------------------
 +
 +Expanded Community Lists is a user defined BGP Expanded Community
 +Lists.
 +
 +.. index:: ip extcommunity-list standard NAME permit|deny EXTCOMMUNITY
 +.. clicmd:: ip extcommunity-list standard NAME permit|deny EXTCOMMUNITY
 +
 +   This command defines a new standard extcommunity-list.
 +   `extcommunity` is extended communities value. The
 +   `extcommunity` is compiled into extended community structure. We
 +   can define multiple extcommunity-list under same name. In that case
 +   match will happen user defined order. Once the extcommunity-list
 +   matches to extended communities attribute in BGP updates it return
 +   permit or deny based upon the extcommunity-list definition. When
 +   there is no matched entry, deny will be returned. When
 +   `extcommunity` is empty it matches to any routes.
 +
 +.. index:: ip extcommunity-list expanded NAME permit|deny LINE
 +.. clicmd:: ip extcommunity-list expanded NAME permit|deny LINE
 +
 +   This command defines a new expanded extcommunity-list. `line` is
 +   a string expression of extended communities attribute. `line` can
 +   be a regular expression (:ref:`BGP_Regular_Expressions`) to match an
 +   extended communities attribute in BGP updates.
 +
 +.. index:: no ip extcommunity-list NAME
 +.. clicmd:: no ip extcommunity-list NAME
 +
 +.. index:: no ip extcommunity-list standard NAME
 +.. clicmd:: no ip extcommunity-list standard NAME
 +
 +.. index:: no ip extcommunity-list expanded NAME
 +.. clicmd:: no ip extcommunity-list expanded NAME
 +
 +   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.
 +
 +.. index:: show ip extcommunity-list
 +.. clicmd:: show ip extcommunity-list
 +
 +.. index:: show ip extcommunity-list NAME
 +.. clicmd:: show ip extcommunity-list NAME
 +
 +   This command displays current extcommunity-list information. When
 +   `name` is specified the community list's information is shown.
 +
 +::
 +
 +    # show ip extcommunity-list
 +
 +
 +.. _BGP_Extended_Communities_in_Route_Map:
 +
 +BGP Extended Communities in Route Map
 +-------------------------------------
 +
 +.. index:: match extcommunity WORD
 +.. clicmd:: match extcommunity WORD
 +
 +
 +.. index:: set extcommunity rt EXTCOMMUNITY
 +.. clicmd:: set extcommunity rt EXTCOMMUNITY
 +
 +   This command set Route Target value.
 +
 +.. index:: set extcommunity soo EXTCOMMUNITY
 +.. clicmd:: set extcommunity soo EXTCOMMUNITY
 +
 +   This command set Site of Origin value.
 +
 +.. _BGP_Large_Communities_Attribute:
 +
 +BGP Large Communities Attribute
 +===============================
 +
 +The BGP Large Communities attribute was introduced in Feb 2017 with
 +:rfc:`8092`.
 +
 +The BGP Large Communities Attribute is similar to the BGP Communities
 +Attribute except that it has 3 components instead of two and each of
 +which are 4 octets in length. Large Communities bring additional
 +functionality and convenience over traditional communities, specifically
 +the fact that the `GLOBAL` part below is now 4 octets wide allowing
 +AS4 operators seamless use.
 +
 +
 +*GLOBAL:LOCAL1:LOCAL2*
 +   This is the format to define Large Community values. Referencing
 +   :t:`RFC8195, Use of BGP Large Communities` the values are commonly
 +   referred to as follows.
 +   The `GLOBAL` part is a 4 octet Global Administrator field, common
 +   use of this field is the operators AS number.
 +   The `LOCAL1` part is a 4 octet Local Data Part 1 subfield referred
 +   to as a function.
 +   The `LOCAL2` part is a 4 octet Local Data Part 2 field and referred
 +   to as the parameter subfield. `65551:1:10` represents AS 65551
 +   function 1 and parameter 10.
 +   The referenced RFC above gives some guidelines on recommended usage.
 +
 +.. _BGP_Large_Community_Lists:
 +
 +BGP Large Community Lists
 +-------------------------
 +
 +Two types of large community lists are supported, namely `standard` and
 +`expanded`.
 +
 +.. index:: ip large-community-list standard NAME permit|deny LARGE-COMMUNITY
 +.. clicmd:: ip large-community-list standard NAME permit|deny LARGE-COMMUNITY
 +
 +   This command defines a new standard large-community-list.
 +   `large-community` is the Large Community value. We
 +   can add multiple large communities under same name. In that case
 +   the match will happen in the user defined order. Once the large-community-list
 +   matches the Large Communities attribute in BGP updates it will return
 +   permit or deny based upon the large-community-list definition. When
 +   there is no matched entry, a deny will be returned. When `large-community`
 +   is empty it matches any routes.
 +
 +.. index:: ip large-community-list expanded NAME permit|deny LINE
 +.. clicmd:: ip large-community-list expanded NAME permit|deny LINE
 +
 +   This command defines a new expanded large-community-list. Where `line` is
 +   a string matching expression, it will be compared to the entire Large Communities
 +   attribute as a string, with each large-community in order from lowest to highest.
 +   `line` can also be a regular expression which matches this Large
 +   Community attribute.
 +
 +.. index:: no ip large-community-list NAME
 +.. clicmd:: no ip large-community-list NAME
 +
 +.. index:: no ip large-community-list standard NAME
 +.. clicmd:: no ip large-community-list standard NAME
 +
 +.. index:: no ip large-community-list expanded NAME
 +.. clicmd:: no ip large-community-list expanded NAME
 +
 +   These commands delete Large Community lists specified by
 +   `name`. All Large Community lists share a single namespace.
 +   This means Large Community lists can be removed by simply specifying the name.
 +
 +.. index:: show ip large-community-list
 +.. clicmd:: show ip large-community-list
 +
 +.. index:: show ip large-community-list NAME
 +.. clicmd:: show ip large-community-list NAME
 +
 +   This command display current large-community-list information. When
 +   `name` is specified the community list information is shown.
 +
 +.. index:: show ip bgp large-community-info
 +.. clicmd:: show ip bgp large-community-info
 +
 +   This command displays the current large communities in use.
 +
 +.. _BGP_Large_Communities_in_Route_Map:
 +
 +BGP Large Communities in Route Map
 +----------------------------------
 +
 +.. index:: match large-community LINE
 +.. clicmd:: match large-community LINE
 +
 +   Where `line` can be a simple string to match, or a regular expression.
 +   It is very important to note that this match occurs on the entire
 +   large-community string as a whole, where each large-community is ordered
 +   from lowest to highest.
 +
 +.. index:: set large-community LARGE-COMMUNITY
 +.. clicmd:: set large-community LARGE-COMMUNITY
 +
 +.. index:: set large-community LARGE-COMMUNITY LARGE-COMMUNITY
 +.. clicmd:: set large-community LARGE-COMMUNITY LARGE-COMMUNITY
 +
 +.. index:: set large-community LARGE-COMMUNITY additive
 +.. clicmd:: set large-community LARGE-COMMUNITY additive
 +
 +   These commands are used for setting large-community values. The first
 +   command will overwrite any large-communities currently present.
 +   The second specifies two large-communities, which overwrites the current
 +   large-community list. The third will add a large-community value without
 +   overwriting other values. Multiple large-community values can be specified.
 +
 +.. _Displaying_BGP_information:
 +
 +Displaying BGP information
 +==========================
 +
 +
 +.. _Showing_BGP_information:
 +
 +Showing BGP information
 +-----------------------
 +
 +.. index:: show ip bgp
 +.. clicmd:: show ip bgp
 +
 +.. index:: show ip bgp A.B.C.D
 +.. clicmd:: show ip bgp A.B.C.D
 +
 +.. index:: show ip bgp X:X::X:X
 +.. clicmd:: show ip bgp X:X::X:X
 +
 +   This command displays BGP routes. When no route is specified it
 +   display all of IPv4 BGP routes.
 +
 +   ::
 +   
 +      BGP table version is 0, local router ID is 10.1.1.1
 +         Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
 +         Origin codes: i - IGP, e - EGP, ? - incomplete
 +   
 +      Network    Next Hop      Metric LocPrf Weight Path
 +         \*> 1.1.1.1/32       0.0.0.0      0   32768 i
 +   
 +         Total number of prefixes 1
 +
 +
 +.. index:: show ip bgp regexp LINE
 +.. clicmd:: show ip bgp regexp LINE
 +
 +   This command displays BGP routes using AS path regular expression
 +   (:ref:`BGP_Regular_Expressions`).
 +
 +.. index:: show ip bgp community COMMUNITY
 +.. clicmd:: show ip bgp community COMMUNITY
 +
 +.. index:: show ip bgp community COMMUNITY exact-match
 +.. clicmd:: show ip bgp community COMMUNITY exact-match
 +
 +   This command displays BGP routes using `community` (:ref:`Display_BGP_Routes_by_Community`).
 +
 +.. index:: show ip bgp community-list WORD
 +.. clicmd:: show ip bgp community-list WORD
 +
 +.. index:: show ip bgp community-list WORD exact-match
 +.. clicmd:: show ip bgp community-list WORD exact-match
 +
 +   This command displays BGP routes using community list (:ref:`Display_BGP_Routes_by_Community`).
 +
 +.. index:: show bgp ipv4|ipv6 summary
 +.. clicmd:: show bgp ipv4|ipv6 summary
 +
 +   Show a bgp peer summary for the specified address family.
 +
 +.. index:: show bgp ipv4|ipv6 neighbor [PEER]
 +.. clicmd:: show bgp ipv4|ipv6 neighbor [PEER]
 +
 +   This command shows information on a specific BGP `peer`.
 +
 +.. index:: show bgp ipv4|ipv6 dampening dampened-paths
 +.. clicmd:: show bgp ipv4|ipv6 dampening dampened-paths
 +
 +   Display paths suppressed due to dampening.
 +
 +.. index:: show bgp ipv4|ipv6 dampening flap-statistics
 +.. clicmd:: show bgp ipv4|ipv6 dampening flap-statistics
 +
 +   Display flap statistics of routes.
 +
 +.. _Other_BGP_commands:
 +
 +Other BGP commands
 +------------------
 +
 +.. index:: clear bgp ipv4|ipv6 \*
 +.. clicmd:: clear bgp ipv4|ipv6 \*
 +
 +   Clear all address family peers.
 +
 +.. index:: clear bgp ipv4|ipv6 PEER
 +.. clicmd:: clear bgp ipv4|ipv6 PEER
 +
 +   Clear peers which have addresses of X.X.X.X
 +
 +.. index:: clear bgp ipv4|ipv6 PEER soft in
 +.. clicmd:: clear bgp ipv4|ipv6 PEER soft in
 +
 +   Clear peer using soft reconfiguration.
 +
 +.. index:: show debug
 +.. clicmd:: show debug
 +
 +.. index:: debug event
 +.. clicmd:: debug event
 +
 +.. index:: debug update
 +.. clicmd:: debug update
 +
 +.. index:: debug keepalive
 +.. clicmd:: debug keepalive
 +
 +.. index:: no debug event
 +.. clicmd:: no debug event
 +
 +.. index:: no debug update
 +.. clicmd:: no debug update
 +
 +.. index:: no debug keepalive
 +.. clicmd:: no debug keepalive
 +
 +
 +.. _Capability_Negotiation:
 +
 +Capability Negotiation
 +======================
 +
 +When adding IPv6 routing information exchange feature to BGP. There
 +were some proposals. :abbr:`IETF (Internet Engineering Task Force)`
 +:abbr:`IDR ( Inter Domain Routing)` :abbr:`IDR ( Inter Domain Routing)` adopted
 +a proposal called Multiprotocol Extension for BGP. The specification
 +is described in :rfc:`2283`. The protocol does not define new protocols.
 +It defines new attributes to existing BGP. When it is used exchanging
 +IPv6 routing information it is called BGP-4+. When it is used for
 +exchanging multicast routing information it is called MBGP.
 +
 +*bgpd* supports Multiprotocol Extension for BGP. So if remote
 +peer supports the protocol, *bgpd* can exchange IPv6 and/or
 +multicast routing information.
 +
 +Traditional BGP did not have the feature to detect remote peer's
 +capabilities, e.g. whether it can handle prefix types other than IPv4
 +unicast routes. This was a big problem using Multiprotocol Extension
 +for BGP to operational network. @cite{RFC2842, Capabilities
 +Advertisement with BGP-4} adopted a feature called Capability
 +Negotiation. *bgpd* use this Capability Negotiation to detect
 +the remote peer's capabilities. If the peer is only configured as IPv4
 +unicast neighbor, *bgpd* does not send these Capability
 +Negotiation packets (at least not unless other optional BGP features
 +require capability negotation).
 +
 +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
 +Unsupported Capability error and then resets the connection.
 +
 +If you want to completely match capabilities with remote peer. Please
 +use *strict-capability-match* command.
 +
 +.. index:: neighbor PEER strict-capability-match
 +.. clicmd:: neighbor PEER strict-capability-match
 +
 +.. index:: no neighbor PEER strict-capability-match
 +.. clicmd:: no neighbor PEER strict-capability-match
 +
 +   Strictly compares remote capabilities and local capabilities. If capabilities
 +   are different, send Unsupported Capability error then reset connection.
 +
 +   You may want to disable sending Capability Negotiation OPEN message
 +   optional parameter to the peer when remote peer does not implement
 +   Capability Negotiation. Please use *dont-capability-negotiate*
 +   command to disable the feature.
 +
 +.. index:: neighbor PEER dont-capability-negotiate
 +.. clicmd:: neighbor PEER dont-capability-negotiate
 +
 +.. index:: no neighbor PEER dont-capability-negotiate
 +.. clicmd:: no neighbor PEER dont-capability-negotiate
 +
 +   Suppress sending Capability Negotiation as OPEN message optional
 +   parameter to the peer. This command only affects the peer is configured
 +   other than IPv4 unicast configuration.
 +
 +   When remote peer does not have capability negotiation feature, remote
 +   peer will not send any capabilities at all. In that case, bgp
 +   configures the peer with configured capabilities.
 +
 +   You may prefer locally configured capabilities more than the negotiated
 +   capabilities even though remote peer sends capabilities. If the peer
 +   is configured by *override-capability*, *bgpd* ignores
 +   received capabilities then override negotiated capabilities with
 +   configured values.
 +
 +.. index:: neighbor PEER override-capability
 +.. clicmd:: neighbor PEER override-capability
 +
 +.. index:: no neighbor PEER override-capability
 +.. clicmd:: no neighbor PEER override-capability
 +
 +   Override the result of Capability Negotiation with local configuration.
 +   Ignore remote peer's capability value.
 +
 +.. _Route_Reflector:
 +
 +Route Reflector
 +===============
 +
 +.. index:: bgp cluster-id A.B.C.D
 +.. clicmd:: bgp cluster-id A.B.C.D
 +
 +.. index:: neighbor PEER route-reflector-client
 +.. clicmd:: neighbor PEER route-reflector-client
 +
 +.. index:: no neighbor PEER route-reflector-client
 +.. clicmd:: no neighbor PEER route-reflector-client
 +
 +
 +.. _Route_Server:
 +
 +Route Server
 +============
 +
 +At an Internet Exchange point, many ISPs are connected to each other by the
 +"full mesh method". As with internal BGP full mesh formation,
 +
 +this method has a scaling problem.
 +
 +This scaling problem is well known. Route Server is a method to resolve the
 +problem. Each ISP's BGP router only peers to Route Server. Route Server serves
 +as BGP information exchange to other BGP routers. By applying this method,
 +numbers of BGP connections is reduced from O(n*(n-1)/2) to O(n).
 +
 +Unlike normal BGP router, Route Server must have several routing tables for
 +managing different routing policies for each BGP speaker. We call the routing
 +tables as different "views". *bgpd* can work as normal BGP router or Route
 +Server or both at the same time.
 +
 +.. _Multiple_instance:
 +
 +Multiple instance
 +-----------------
 +
 +To enable multiple view function of *bgpd*, you must turn on multiple instance
 +feature beforehand.
 +
 +.. index:: bgp multiple-instance
 +.. clicmd:: bgp multiple-instance
 +
 +   Enable BGP multiple instance feature. After this feature is enabled,
 +   you can make multiple BGP instances or multiple BGP views.
 +
 +.. index:: no bgp multiple-instance
 +.. clicmd:: no bgp multiple-instance
 +
 +   Disable BGP multiple instance feature. You can not disable this feature
 +   when BGP multiple instances or views exist.
 +
 +When you want to make configuration more Cisco like one,
 +
 +.. index:: bgp config-type cisco
 +.. clicmd:: bgp config-type cisco
 +
 +   Cisco compatible BGP configuration output.
 +
 +When bgp config-type cisco is specified,
 +
 +'no synchronization' is displayed.
 +'no auto-summary' is displayed.
 +
 +'network' and 'aggregate-address' argument is displayed as
 +'A.B.C.D M.M.M.M'
 +
 +FRR: network 10.0.0.0/8
 +Cisco: network 10.0.0.0
 +
 +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
 +configuration is specified community attribute and extended community
 +attribute are sent to neighbor. When user manually disable the
 +feature community attribute is not sent to the neighbor. In case of
 +*bgp config-type cisco* is specified, community attribute is not
 +sent to the neighbor by default. To send community attribute user has
 +to specify *neighbor A.B.C.D send-community* command.::
 +
 +   !
 +   router bgp 1
 +    neighbor 10.0.0.1 remote-as 1
 +    address-family ipv4 unicast
 +     no neighbor 10.0.0.1 send-community
 +    exit-address-family
 +   !
 +   router bgp 1
 +    neighbor 10.0.0.1 remote-as 1
 +    address-family ipv4 unicast
 +     neighbor 10.0.0.1 send-community
 +    exit-address-family
 +   !
 +
 +
 +.. index:: bgp config-type zebra
 +.. clicmd:: bgp config-type zebra
 +
 +   FRR style BGP configuration. This is default.
 +
 +.. _BGP_instance_and_view:
 +
 +BGP instance and view
 +---------------------
 +
 +BGP instance is a normal BGP process. The result of route selection
 +goes to the kernel routing table. You can setup different AS at the
 +same time when BGP multiple instance feature is enabled.
 +
 +.. index:: router bgp AS-NUMBER
 +.. clicmd:: router bgp AS-NUMBER
 +
 +   Make a new BGP instance. You can use arbitrary word for the `name`.
 +
 +  ::
 +  
 +     bgp multiple-instance
 +     !
 +     router bgp 1
 +      neighbor 10.0.0.1 remote-as 2
 +      neighbor 10.0.0.2 remote-as 3
 +     !
 +     router bgp 2
 +      neighbor 10.0.0.3 remote-as 4
 +      neighbor 10.0.0.4 remote-as 5
 +
 +
 +BGP view is almost same as normal BGP process. The result of
 +route selection does not go to the kernel routing table. BGP view is
 +only for exchanging BGP routing information.
 +
 +.. index:: router bgp AS-NUMBER view NAME
 +.. clicmd:: router bgp AS-NUMBER view NAME
 +
 +   Make a new BGP view. You can use arbitrary word for the `name`. This view's
 +   route selection result does not go to the kernel routing table.
 +
 +   With this command, you can setup Route Server like below.
 +
 +   ::
 +   
 +      bgp multiple-instance
 +      !
 +      router bgp 1 view 1
 +       neighbor 10.0.0.1 remote-as 2
 +       neighbor 10.0.0.2 remote-as 3
 +      !
 +      router bgp 2 view 2
 +       neighbor 10.0.0.3 remote-as 4
 +       neighbor 10.0.0.4 remote-as 5
 +
 +
 +.. _Routing_policy:
 +
 +Routing policy
 +--------------
 +
 +You can set different routing policy for a peer. For example, you can
 +set different filter for a peer.::
 +
 +   bgp multiple-instance
 +   !
 +   router bgp 1 view 1
 +    neighbor 10.0.0.1 remote-as 2
 +    address-family ipv4 unicast
 +     neighbor 10.0.0.1 distribute-list 1 in
 +    exit-address-family
 +   !
 +   router bgp 1 view 2
 +    neighbor 10.0.0.1 remote-as 2
 +    address-family ipv4 unicast
 +     neighbor 10.0.0.1 distribute-list 2 in
 +    exit-address-family
 +
 +
 +This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view
 +2. When the update is inserted into view 1, distribute-list 1 is
 +applied. On the other hand, when the update is inserted into view 2,
 +distribute-list 2 is applied.
 +
 +.. _Viewing_the_view:
 +
 +Viewing the view
 +----------------
 +
 +To display routing table of BGP view, you must specify view name.
 +
 +.. index:: show ip bgp view NAME
 +.. clicmd:: show ip bgp view NAME
 +
 +   Display routing table of BGP view ``NAME``.
 +
 +.. _BGP_Regular_Expressions:
 +
 +BGP Regular Expressions
 +=======================
 +
 +BGP regular expressions are based on `POSIX 1003.2` regular
 +expressions. The following description is just a quick subset of the
 +`POSIX` regular expressions. Adding to that, the special character
 +'_' is added.
 +
 +
 +.*
 +   Matches any single character.
 +
 +*
 +   Matches 0 or more occurrences of pattern.
 +
 ++
 +   Matches 1 or more occurrences of pattern.
 +
 +?
 +   Match 0 or 1 occurrences of pattern.
 +
 +^
 +   Matches the beginning of the line.
 +
 +$
 +   Matches the end of the line.
 +
 +_
 +   Character `_` has special meanings in BGP regular expressions.  It matches
 +   to space and comma , and AS set delimiter { and } and AS confederation
 +   delimiter `(` and `)`. And it also matches to the beginning of the line and
 +   the end of the line. So `_` can be used for AS value boundaries match. This
 +   character technically evaluates to `(^|[,{}() ]|$)`.
 +
 +.. _How_to_set_up_a_6-Bone_connection:
 +
 +How to set up a 6-Bone connection
 +=================================
 +
 +::
 +
 +   zebra configuration
 +   ===================
 +   !
 +   ! Actually there is no need to configure zebra
 +   !
 +
 +   bgpd configuration
 +   ==================
 +   !
 +   ! This means that routes go through zebra and into the kernel.
 +   !
 +   router zebra
 +   !
 +   ! MP-BGP configuration
 +   !
 +   router bgp 7675
 +    bgp router-id 10.0.0.1
 +    neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as `as-number`
 +   !
 +    address-family ipv6
 +    network 3ffe:506::/32
 +    neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
 +    neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
 +    neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as `as-number`
 +    neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
 +    exit-address-family
 +   !
 +   ipv6 access-list all permit any
 +   !
 +   ! Set output nexthop address.
 +   !
 +   route-map set-nexthop permit 10
 +    match ipv6 address all
 +    set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
 +    set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
 +   !
 +   ! logfile FILENAME is obsolete. Please use log file FILENAME
 +
 +   log file bgpd.log
 +   !
 +
 +
 +.. _Dump_BGP_packets_and_table:
 +
 +Dump BGP packets and table
 +==========================
 +
 +.. index:: dump bgp all PATH [INTERVAL]
 +.. clicmd:: dump bgp all PATH [INTERVAL]
 +
 +.. index:: dump bgp all-et PATH [INTERVAL]
 +.. clicmd:: dump bgp all-et PATH [INTERVAL]
 +
 +.. index:: no dump bgp all [PATH] [INTERVAL]
 +.. clicmd:: no dump bgp all [PATH] [INTERVAL]
 +
 +   Dump all BGP packet and events to `path` file.
 +   If `interval` is set, a new file will be created for echo `interval` of seconds.
 +   The path `path` can be set with date and time formatting (strftime).
 +   The type ‘all-et’ enables support for Extended Timestamp Header (:ref:`Packet_Binary_Dump_Format`).
 +   (:ref:`Packet_Binary_Dump_Format`)
 +
 +.. index:: dump bgp updates PATH [INTERVAL]
 +.. clicmd:: dump bgp updates PATH [INTERVAL]
 +
 +.. index:: dump bgp updates-et PATH [INTERVAL]
 +.. clicmd:: dump bgp updates-et PATH [INTERVAL]
 +
 +.. index:: no dump bgp updates [PATH] [INTERVAL]
 +.. clicmd:: no dump bgp updates [PATH] [INTERVAL]
 +
 +   Dump only BGP updates messages to `path` file.
 +   If `interval` is set, a new file will be created for echo `interval` of seconds.
 +   The path `path` can be set with date and time formatting (strftime).
 +   The type ‘updates-et’ enables support for Extended Timestamp Header (:ref:`Packet_Binary_Dump_Format`).
 +
 +.. index:: dump bgp routes-mrt PATH
 +.. clicmd:: dump bgp routes-mrt PATH
 +
 +.. index:: dump bgp routes-mrt PATH INTERVAL
 +.. clicmd:: dump bgp routes-mrt PATH INTERVAL
 +
 +.. index:: no dump bgp route-mrt [PATH] [INTERVAL]
 +.. clicmd:: no dump bgp route-mrt [PATH] [INTERVAL]
 +
 +   Dump whole BGP routing table to `path`. This is heavy process.
 +   The path `path` can be set with date and time formatting (strftime).
 +   If `interval` is set, a new file will be created for echo `interval` of seconds.
 +
 +   Note: the interval variable can also be set using hours and minutes: 04h20m00.
 +
 +.. _bgp-configuration-examples:
 +
 +BGP Configuration Examples
 +==========================
 +
 +Example of a session to an upstream, advertising only one prefix to it.::
 +
 +   router bgp 64512
 +    bgp router-id 10.236.87.1
 +    neighbor upstream peer-group
 +    neighbor upstream remote-as 64515
 +    neighbor upstream capability dynamic
 +    neighbor 10.1.1.1 peer-group upstream
 +    neighbor 10.1.1.1 description ACME ISP
 +
 +    address-family ipv4 unicast
 +     network 10.236.87.0/24
 +     neighbor upstream prefix-list pl-allowed-adv out
 +    exit-address-family
 +   !
 +   ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
 +   ip prefix-list pl-allowed-adv seq 10 deny any
 +
 +A more complex example. With upstream, peer and customer sessions.
 +Advertising 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 mistakes, if not serious
 +flaws.
 +
 +::
 +
 +   router bgp 64512
 +    bgp router-id 10.236.87.1
 +    neighbor upstream capability dynamic
 +    neighbor cust capability dynamic
 +    neighbor peer capability dynamic
 +    neighbor 10.1.1.1 remote-as 64515
 +    neighbor 10.1.1.1 peer-group upstream
 +    neighbor 10.2.1.1 remote-as 64516
 +    neighbor 10.2.1.1 peer-group upstream
 +    neighbor 10.3.1.1 remote-as 64517
 +    neighbor 10.3.1.1 peer-group cust-default
 +    neighbor 10.3.1.1 description customer1
 +    neighbor 10.4.1.1 remote-as 64518
 +    neighbor 10.4.1.1 peer-group cust
 +    neighbor 10.4.1.1 description customer2
 +    neighbor 10.5.1.1 remote-as 64519
 +    neighbor 10.5.1.1 peer-group peer
 +    neighbor 10.5.1.1 description peer AS 1
 +    neighbor 10.6.1.1 remote-as 64520
 +    neighbor 10.6.1.1 peer-group peer
 +    neighbor 10.6.1.1 description peer AS 2
 +
 +    address-family ipv4 unicast
 +     network 10.123.456.0/24
 +     network 10.123.456.128/25 route-map rm-no-export
 +     neighbor upstream route-map rm-upstream-out out
 +     neighbor cust route-map rm-cust-in in
 +     neighbor cust route-map rm-cust-out out
 +     neighbor cust send-community both
 +     neighbor peer route-map rm-peer-in in
 +     neighbor peer route-map rm-peer-out out
 +     neighbor peer send-community both
 +     neighbor 10.3.1.1 prefix-list pl-cust1-network in
 +     neighbor 10.4.1.1 prefix-list pl-cust2-network in
 +     neighbor 10.5.1.1 prefix-list pl-peer1-network in
 +     neighbor 10.6.1.1 prefix-list pl-peer2-network in
 +    exit-address-family
 +   !
 +   ip prefix-list pl-default permit 0.0.0.0/0
 +   !
 +   ip prefix-list pl-upstream-peers permit 10.1.1.1/32
 +   ip prefix-list pl-upstream-peers permit 10.2.1.1/32
 +   !
 +   ip prefix-list pl-cust1-network permit 10.3.1.0/24
 +   ip prefix-list pl-cust1-network permit 10.3.2.0/24
 +   !
 +   ip prefix-list pl-cust2-network permit 10.4.1.0/24
 +   !
 +   ip prefix-list pl-peer1-network permit 10.5.1.0/24
 +   ip prefix-list pl-peer1-network permit 10.5.2.0/24
 +   ip prefix-list pl-peer1-network permit 192.168.0.0/24
 +   !
 +   ip prefix-list pl-peer2-network permit 10.6.1.0/24
 +   ip prefix-list pl-peer2-network permit 10.6.2.0/24
 +   ip prefix-list pl-peer2-network permit 192.168.1.0/24
 +   ip prefix-list pl-peer2-network permit 192.168.2.0/24
 +   ip prefix-list pl-peer2-network permit 172.16.1/24
 +   !
 +   ip as-path access-list asp-own-as permit ^$
 +   ip as-path access-list asp-own-as permit _64512_
 +   !
 +   ! #################################################################
 +   ! Match communities we provide actions for, on routes receives from
 +   ! customers. Communities values of <our-ASN>:X, with X, have actions:
 +   !
 +   ! 100 - blackhole the prefix
 +   ! 200 - set no_export
 +   ! 300 - advertise only to other customers
 +   ! 400 - advertise only to upstreams
 +   ! 500 - set no_export when advertising to upstreams
 +   ! 2X00 - set local_preference to X00
 +   !
 +   ! blackhole the prefix of the route
 +   ip community-list standard cm-blackhole permit 64512:100
 +   !
 +   ! set no-export community before advertising
 +   ip community-list standard cm-set-no-export permit 64512:200
 +   !
 +   ! advertise only to other customers
 +   ip community-list standard cm-cust-only permit 64512:300
 +   !
 +   ! advertise only to upstreams
 +   ip community-list standard cm-upstream-only permit 64512:400
 +   !
 +   ! advertise to upstreams with no-export
 +   ip community-list standard cm-upstream-noexport permit 64512:500
 +   !
 +   ! set local-pref to least significant 3 digits of the community
 +   ip community-list standard cm-prefmod-100 permit 64512:2100
 +   ip community-list standard cm-prefmod-200 permit 64512:2200
 +   ip community-list standard cm-prefmod-300 permit 64512:2300
 +   ip community-list standard cm-prefmod-400 permit 64512:2400
 +   ip community-list expanded cme-prefmod-range permit 64512:2...
 +   !
 +   ! Informational communities
 +   !
 +   ! 3000 - learned from upstream
 +   ! 3100 - learned from customer
 +   ! 3200 - learned from peer
 +   !
 +   ip community-list standard cm-learnt-upstream permit 64512:3000
 +   ip community-list standard cm-learnt-cust permit 64512:3100
 +   ip community-list standard cm-learnt-peer permit 64512:3200
 +   !
 +   ! ###################################################################
 +   ! Utility route-maps
 +   !
 +   ! These utility route-maps generally should not used to permit/deny
 +   ! routes, i.e. they do not have meaning as filters, and hence probably
 +   ! should be used with 'on-match next'. These all finish with an empty
 +   ! permit entry so as not interfere with processing in the caller.
 +   !
 +   route-map rm-no-export permit 10
 +    set community additive no-export
 +   route-map rm-no-export permit 20
 +   !
 +   route-map rm-blackhole permit 10
 +    description blackhole, up-pref and ensure it cant escape this AS
 +    set ip next-hop 127.0.0.1
 +    set local-preference 10
 +    set community additive no-export
 +   route-map rm-blackhole permit 20
 +   !
 +   ! Set local-pref as requested
 +   route-map rm-prefmod permit 10
 +    match community cm-prefmod-100
 +    set local-preference 100
 +   route-map rm-prefmod permit 20
 +    match community cm-prefmod-200
 +    set local-preference 200
 +   route-map rm-prefmod permit 30
 +    match community cm-prefmod-300
 +    set local-preference 300
 +   route-map rm-prefmod permit 40
 +    match community cm-prefmod-400
 +    set local-preference 400
 +   route-map rm-prefmod permit 50
 +   !
 +   ! Community actions to take on receipt of route.
 +   route-map rm-community-in permit 10
 +    description check for blackholing, no point continuing if it matches.
 +    match community cm-blackhole
 +    call rm-blackhole
 +   route-map rm-community-in permit 20
 +    match community cm-set-no-export
 +    call rm-no-export
 +    on-match next
 +   route-map rm-community-in permit 30
 +    match community cme-prefmod-range
 +    call rm-prefmod
 +   route-map rm-community-in permit 40
 +   !
 +   ! #####################################################################
 +   ! Community actions to take when advertising a route.
 +   ! These are filtering route-maps,
 +   !
 +   ! Deny customer routes to upstream with cust-only set.
 +   route-map rm-community-filt-to-upstream deny 10
 +    match community cm-learnt-cust
 +    match community cm-cust-only
 +   route-map rm-community-filt-to-upstream permit 20
 +   !
 +   ! Deny customer routes to other customers with upstream-only set.
 +   route-map rm-community-filt-to-cust deny 10
 +    match community cm-learnt-cust
 +    match community cm-upstream-only
 +   route-map rm-community-filt-to-cust permit 20
 +   !
 +   ! ###################################################################
 +   ! The top-level route-maps applied to sessions. Further entries could
 +   ! be added obviously..
 +   !
 +   ! Customers
 +   route-map rm-cust-in permit 10
 +    call rm-community-in
 +    on-match next
 +   route-map rm-cust-in permit 20
 +    set community additive 64512:3100
 +   route-map rm-cust-in permit 30
 +   !
 +   route-map rm-cust-out permit 10
 +    call rm-community-filt-to-cust
 +    on-match next
 +   route-map rm-cust-out permit 20
 +   !
 +   ! Upstream transit ASes
 +   route-map rm-upstream-out permit 10
 +    description filter customer prefixes which are marked cust-only
 +    call rm-community-filt-to-upstream
 +    on-match next
 +   route-map rm-upstream-out permit 20
 +    description only customer routes are provided to upstreams/peers
 +    match community cm-learnt-cust
 +   !
 +   ! Peer ASes
 +   ! outbound policy is same as for upstream
 +   route-map rm-peer-out permit 10
 +    call rm-upstream-out
 +   !
 +   route-map rm-peer-in permit 10
 +    set community additive 64512:3200
 +
 +
 +.. _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
 +speakers. For example if we have an exchange point scenario with four BGP
 +speakers, each of which maintaining a BGP peering with the other three
 +(:ref:`fig:full-mesh`), we can convert it into a centralized scenario where
 +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 explain the commands that have been added for configuring that
 +model. And finally we will show a full example of FRR configured as Route
 +Server.
 +
 +.. include:: rpki.rst
 +
 +
 +.. [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
diff --cc doc/user/vnc.rst
index b133b8c920,0000000000..7cd2153dc3
mode 100644,000000..100644
--- a/doc/user/vnc.rst
+++ b/doc/user/vnc.rst
@@@ -1,919 -1,0 +1,1503 @@@
 +.. _VNC_and_VNC-GW:
 +
 +**************
 +VNC and VNC-GW
 +**************
 +
 +This chapter describes how to use Virtual Network Control (:abbr:`VNC`)
 +services, including Network Virtualization Authority (:abbr:`NVA`) and VNC
 +Gateway (:abbr:`VNC-GW`) functions. 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
 +`IETF Network Virtualization Overlays <https://datatracker.ietf.org/wg/nvo3>`_
 +:abbr:`VNC-GW (VNC-Gateways)` support the import/export of routing information
 +between VNC and customer edge routers (:abbr:`CE` s) operating within a VN.
 +Both IP/Layer 3 (L3) VNs, and IP with Ethernet/Layer 2 (L2) VNs are supported.
 +
 +BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VN
 +information between NVAs. BGP based IP VPN support is defined in :rfc:`4364`,
- and :rfc:`4659`. Both the Encapsulation Subsequent Address Family Identifier
- (SAFI) and the Tunnel Encapsulation Attribute, :rfc:`5512` are supported.
++and :rfc:`4659`. Encapsulation information is provided via the Tunnel
++Encapsulation Attribute, :rfc:`5512`.
 +
 +The protocol that is used to communicate routing and Ethernet / Layer 2 (L2)
 +forwarding information between NVAs and NVEs is referred to as the Remote
 +Forwarder Protocol (RFP). `OpenFlow` is an example RFP. Specific RFP
 +implementations may choose to implement either a `hard-state` or `soft-state`
 +prefix and address registration model. To support a `soft-state` refresh model,
 +a `lifetime` in seconds is associated with all registrations and responses.
 +
 +The chapter also provides sample configurations for basic example scenarios.
 +
 +.. _configuring-vnc:
 +
 +Configuring VNC
 +===============
 +
 +Virtual Network Control (:abbr:`VNC`) service configuration commands appear in
 +the `router bgp` section of the BGPD configuration file
 +(:ref:`bgp-configuration-examples`). The commands are broken down into the
 +following areas:
 +
 +- :dfn:`General VNC` configuration applies to general VNC operation and is
 +  primarily used to control the method used to advertise tunnel information.
-   - :dfn:`Remote Forwarder Protocol (RFP)` configuration relates to the protocol
-     used between NVAs and NVEs.
-     - :dfn:`VNC Defaults` provides default parameters for registered NVEs.
-       - :dfn:`VNC NVE Group` provides for configuration of a specific set of
-         registered NVEs and overrides default parameters.
-         - :dfn:`Redistribution` and :dfn:`Export` control VNC-GW operation, i.e., the
-           import/export of routing information between VNC and customer edge routers
-           (:abbr:`CE`s) operating within a VN.
 +
++- :dfn:`Remote Forwarder Protocol (RFP)` configuration relates to the protocol
++  used between NVAs and NVEs.
 +
-         .. _General_VNC_Configuration:
++- :dfn:`VNC Defaults` provides default parameters for registered NVEs.
 +
-      General VNC Configuration
-      -------------------------
++- :dfn:`VNC NVE Group` provides for configuration of a specific set of
++  registered NVEs and overrides default parameters.
 +
-      .. clicmd:: vnc advertise-un-method encap-safi|encap-attr
++- :dfn:`Redistribution` and :dfn:`Export` control VNC-GW operation, i.e., the
++  import/export of routing information between VNC and customer edge routers
++  (:abbr:`CE` s) operating within a VN.
 +
-   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
-   `address-family encap` and/or `address-family encapv6` must be configured.
-   The default is `encap-attr`.
 +
-   .. _RFP_Related_Configuration:
++.. _General_VNC_Configuration:
++
++.. General VNC Configuration
++.. -------------------------
++
++.. _RFP_Related_Configuration:
 +
 +RFP Related Configuration
 +-------------------------
 +
 +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., `OpenFlow`. The example code includes the
 +following sample configuration:
 +
 +.. clicmd:: rfp example-config-value VALUE
 +
 +This is a simple example configuration parameter included as part of the RFP
 +example code. VALUE must be in the range of 0 to 4294967295.
 +
 +.. _VNC_Defaults_Configuration:
 +
 +VNC Defaults Configuration
 +--------------------------
 +
 +The VNC Defaults section allows the user to specify default values for
 +configuration parameters for all registered NVEs.
 +Default values are overridden by :ref:`VNC_NVE_Group_Configuration`.
 +
 +.. clicmd:: vnc defaults
 +
 +Enter VNC configuration mode for specifying VNC default behaviors. Use
 +`exit-vnc` to leave VNC configuration mode. `vnc defaults` is optional.
 +
 +::
 +
- vnc defaults
- ... various VNC defaults
- exit-vnc
++   vnc defaults
++   ... various VNC defaults
++   exit-vnc
 +
 +
 +These are the statements that can appear between ``vnc defaults`` and
 +``exit-vnc``.
 +
 +.. index:: rt import RT-LIST
 +.. clicmd:: rt import RT-LIST
 +
 +.. index:: rt export RT-LIST
 +.. clicmd:: rt export RT-LIST
 +
 +.. index:: rt both RT-LIST
 +.. clicmd:: rt both RT-LIST
 +
 +   Specify default route target import and export lists. `rt-list` is a
 +   space-separated list of route targets, each element of which is
 +   in one of the following forms:
 +
 +   - ``IPv4-address:two-byte-integer``
-      - ``four-byte-autonomous-system-number:two-byte-integer``
-        - ``two-byte-autonomous-system-number:four-byte-integer``
++   - ``four-byte-autonomous-system-number:two-byte-integer``
++   - ``two-byte-autonomous-system-number:four-byte-integer``
 +
-        If no default import RT list is specified, then the default import RT list
-        is empty. If no default export RT list is specified, then the default export
-        RT list is empty.
++   If no default import RT list is specified, then the default import RT list
++   is empty. If no default export RT list is specified, then the default export
++   RT list is empty.
 +
-        A complete definition of these parameters is given below
-        (:ref:`VNC_NVE_Group_Configuration`).
++   A complete definition of these parameters is given below
++   (:ref:`VNC_NVE_Group_Configuration`).
 +
-        .. index:: rd route-distinguisher
-        .. clicmd:: rd ROUTE-DISTINGUISHER
++.. index:: rd route-distinguisher
++.. clicmd:: rd ROUTE-DISTINGUISHER
 +
 +   Specify the default route distinguisher (RD) for routes advertised via BGP
 +   VPNs. The route distinguisher must be in one of four forms:
 +
 +    - ``IPv4-address:two-byte-integer``
-       - ``four-byte-autonomous-system-number:two-byte-integer``
-         - ``two-byte-autonomous-system-number:four-byte-integer``
-           - ``auto:vn:two-byte-integer``
++    - ``four-byte-autonomous-system-number:two-byte-integer``
++    - ``two-byte-autonomous-system-number:four-byte-integer``
++    - ``auto:vn:two-byte-integer``
 +
-           If RD is specified in the defaults section, the default RD value is
-           `two-byte-autonomous-system-number=0`:`four-byte-integer=0`.
++    If RD is specified in the defaults section, the default RD value is
++    `two-byte-autonomous-system-number=0:four-byte-integer=0`.
 +
-           A complete definition of this parameter is given below
-           (:ref:`VNC_NVE_Group_Configuration`).
++    A complete definition of this parameter is given below
++    (:ref:`VNC_NVE_Group_Configuration`).
 +
-           .. index:: l2rd NVE-ID-VALUE
- 
-        .. clicmd:: l2rd NVE-ID-VALUE
++.. index:: l2rd NVE-ID-VALUE
++.. clicmd:: l2rd NVE-ID-VALUE
 +
 +   Set the value used to distinguish NVEs connected to the same logical
 +   Ethernet segment (i.e., L2VPN).  A complete definition of this parameter is
 +   given below (:ref:`VNC_NVE_Group_Configuration`).
 +
-    .. index:: response-lifetime LIFETIME|infinite
-    .. clicmd:: response-lifetime LIFETIME|infinite
++.. index:: response-lifetime LIFETIME|infinite
++.. clicmd:: response-lifetime LIFETIME|infinite
 +
 +   Specify the default lifetime to be included in RFP response messages sent to
 +   NVEs.
 +
 +   A complete definition of this parameter is given below
 +   (:ref:`VNC_NVE_Group_Configuration`).
 +
 +.. index:: export bgp|zebra route-map MAP-NAME
- 
 +.. 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.
++   Specify that the named route-map should be applied to routes being exported
++   to bgp or zebra.
 +
 +.. index:: export bgp|zebra no route-map
- 
 +.. clicmd:: export bgp|zebra no route-map
 +
- Specify that no route-map should be applied to routes being exported to bgp
- or zebra.
++   Specify that no route-map should be applied to routes being exported to bgp
++   or zebra.
 +
 +.. index:: exit-vnc
 +.. clicmd:: exit-vnc
 +
 +   Exit VNC configuration mode.
 +
-    .. _VNC_NVE_Group_Configuration:
++.. _VNC_NVE_Group_Configuration:
 +
 +VNC NVE Group Configuration
 +---------------------------
 +
 +A NVE Group corresponds to a specific set of NVEs. A Client NVE is
 +assigned to an NVE Group based on whether there is a match for either
 +its virtual or underlay network address against the VN and/or UN address
 +prefixes specified in the NVE Group definition. When an NVE Group
 +definition specifies both VN and UN address prefixes, then an NVE must
 +match both prefixes in order to be assigned to the NVE Group. In the
 +event that multiple NVE Groups match based on VN and/or UN addresses,
 +the NVE is assigned to the first NVE Group listed in the configuration.
 +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
 +member NVEs and override configuration values specified in the VNC
 +Defaults section.
 +
 +**At least one `nve-group` is mandatory for useful VNC operation.**
 +
 +.. index:: vnc nve-group NAME
 +.. clicmd:: vnc 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
++     vnc nve-group group1
++     ... configuration commands
++     exit-vnc
 +
 +
 +.. index:: no vnc nve-group NAME
 +.. clicmd:: no vnc nve-group NAME
 +
 +   Delete the NVE group named `name`.
 +
 +   The following statements are valid in an NVE group definition:
 +
-    .. index:: l2rd NVE-ID-VALUE
-    .. clicmd:: l2rd NVE-ID-VALUE
++.. index:: l2rd NVE-ID-VALUE
++.. clicmd:: l2rd NVE-ID-VALUE
 +
- Set the value used to distinguish NVEs connected to the same physical
- Ethernet segment (i.e., at the same location) [#]_.
++   Set the value used to distinguish NVEs connected to the same physical
++   Ethernet segment (i.e., at the same location) [#]_.
 +
- The nve-id subfield may be specified as either a literal value in the range
- 1-255, or it may be specified as `auto:vn`, which means to use the
- least-significant octet of the originating NVE's VN address.
++   The nve-id subfield may be specified as either a literal value in the range
++   1-255, or it may be specified as `auto:vn`, which means to use the
++   least-significant octet of the originating NVE's VN address.
 +
 +.. index:: prefix vn|un A.B.C.D/M|X:X::X:X/M
 +.. clicmd:: prefix vn|un A.B.C.D/M|X:X::X:X/M
 +
-   Specify the matching prefix for this NVE group by either virtual-network
-   address (`vn`) or underlay-network address (`un`). Either or both
-   virtual-network and underlay-network prefixes may be specified. Subsequent
-   virtual-network or underlay-network values within a `vnc nve-group`
-   `exit-vnc` block override their respective previous values.
++   Specify the matching prefix for this NVE group by either virtual-network
++   address (`vn`) or underlay-network address (`un`). Either or both
++   virtual-network and underlay-network prefixes may be specified. Subsequent
++   virtual-network or underlay-network values within a `vnc nve-group`
++   `exit-vnc` block override their respective previous values.
 +
-   These prefixes are used only for determining assignments of NVEs to NVE
-   Groups.
++   These prefixes are used only for determining assignments of NVEs to NVE
++   Groups.
 +
-   .. index:: rd ROUTE-DISTINGUISHER
-   .. clicmd:: rd ROUTE-DISTINGUISHER
++.. index:: rd ROUTE-DISTINGUISHER
++.. clicmd:: rd ROUTE-DISTINGUISHER
 +
 +   Specify the route distinguisher for routes advertised via BGP
 +   VPNs. The route distinguisher must be in one of these forms:
 +
 +   - ``IPv4-address:two-byte-integer``
-      - ``four-byte-autonomous-system-number:two-byte-integer``
-        - ``two-byte-autonomous-system-number:four-byte-integer``
-          - ``auto:vn:`two-byte-integer`
- 
-          Routes originated by NVEs in the NVE group will use the group's specified
-          `route-distinguisher` when they are advertised via BGP.  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``, for IPv4 VN
-          addresses and
-          ``rd_type=IP=1`:`IPv4-address=Last-four-bytes-of-VN-address:two-byte-integer``,
-          for IPv6 VN addresses.
++   - ``four-byte-autonomous-system-number:two-byte-integer``
++   - ``two-byte-autonomous-system-number:four-byte-integer``
++   - ``auto:vn:`two-byte-integer`
++
++   Routes originated by NVEs in the NVE group will use the group's specified
++   `route-distinguisher` when they are advertised via BGP.  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``, for IPv4 VN
++   addresses and
++   ``rd_type=IP=1:IPv4-address=Last-four-bytes-of-VN-address:two-byte-integer``,
++   for IPv6 VN addresses.
++
++   If the NVE group definition does not specify a `route-distinguisher`, then
++   the default `route-distinguisher` is used.  If neither a group nor a default
++   `route-distinguisher` is configured, then the advertised RD is set to
++   ``two-byte-autonomous-system-number=0:four-byte-integer=0``.
++
++.. index:: response-lifetime LIFETIME|infinite
++.. clicmd:: response-lifetime LIFETIME|infinite
++
++   Specify the response lifetime, in seconds, to be included in RFP response
++   messages sent to NVEs. If the value 'infinite' is given, an infinite
++   lifetime will be used.
++
++   Note that this parameter is not the same as the lifetime supplied by NVEs in
++   RFP registration messages. This parameter does not affect the lifetime value
++   attached to routes sent by this server via BGP.
++
++   If the NVE group definition does not specify a `response-lifetime`, the
++   default `response-lifetime` will be used.  If neither a group nor a default
++   `response-lifetime` is configured, the value 3600 will be used. The maximum
++   response lifetime is 2147483647.
 +
-          If the NVE group definition does not specify a `route-distinguisher`, then
-          the default `route-distinguisher` is used.  If neither a group nor a default
-          `route-distinguisher` is configured, then the advertised RD is set to
-          ``two-byte-autonomous-system-number=0:four-byte-integer=0``.
- 
-          .. index:: response-lifetime LIFETIME|infinite
-          .. clicmd:: response-lifetime LIFETIME|infinite
- 
-       Specify the response lifetime, in seconds, to be included in RFP response
-       messages sent to NVEs. If the value 'infinite' is given, an infinite
-       lifetime will be used.
- 
-       Note that this parameter is not the same as the lifetime supplied by NVEs in
-       RFP registration messages. This parameter does not affect the lifetime value
-       attached to routes sent by this server via BGP.
- 
-       If the NVE group definition does not specify a `response-lifetime`, the
-       default `response-lifetime` will be used.  If neither a group nor a default
-       `response-lifetime` is configured, the value 3600 will be used. The maximum
-       response lifetime is 2147483647.
- 
-       .. index:: rt export RT-LIST
-       .. clicmd:: rt export RT-LIST
++.. index:: rt export RT-LIST
++.. clicmd:: rt export RT-LIST
 +
-    .. index:: rt import RT-LIST
-    .. clicmd:: rt import RT-LIST
++.. index:: rt import RT-LIST
++.. clicmd:: rt import RT-LIST
 +
 +.. index:: rt both RT-LIST
 +.. clicmd:: rt both RT-LIST
 +
 +   Specify route target import and export lists. `rt-list` is a
 +   space-separated list of route targets, each element of which is
 +   in one of the following forms:
 +
-    ``IPv4-address:two-byte-integer``
-    ``four-byte-autonomous-system-number:two-byte-integer``
-    ``two-byte-autonomous-system-number:four-byte-integer``
++   - ``IPv4-address:two-byte-integer``
++   - ``four-byte-autonomous-system-number:two-byte-integer``
++   - ``two-byte-autonomous-system-number:four-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.  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, then no
 +   RT list will be sent; in turn, these routes will probably not be
 +   processed by receiving NVAs.
 +
 +   The second form, `rt import` specifies an `import rt-list`, which is a
 +   filter for incoming routes.  In order to be made available to NVEs in the
-    group, incoming BGP VPN and `ENCAP` `SAFI` (when `vnc advertise-un-method
-    encap-safi` is set) routes must have RT lists that have at least one
++   group, incoming BGP VPN routes must have RT lists that have at least one
 +   route target in common with the group's `import rt-list`.
 +
 +   If the NVE group definition does not specify an import filter, then the
 +   default `import rt-list` is used.  If neither a group nor a default
 +   `import rt-list` is configured, there can be no RT intersections when
 +   receiving BGP routes and therefore no incoming BGP routes will be
 +   processed for the group.
 +
 +   The third, `rt both`, is a shorthand way of specifying both lists
 +   simultaneously, and is equivalent to `rt export `rt-list`` followed by
 +   `rt import `rt-list``.
 +
 +.. index:: export bgp|zebra route-map MAP-NAME
 +.. 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
 +   :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`.  This item
 +   is optional.
 +
 +.. index:: export bgp|zebra no route-map
 +.. 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
 +   :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`.  This item
 +   is optional.
 +
 +.. index:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
 +.. clicmd:: 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
 +   :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`.  This item
 +   is optional.
 +
 +.. index:: export bgp|zebra no ipv4|ipv6 prefix-list
 +.. clicmd:: 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 parameter is used in conjunction with
 +   :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`.  This item
 +   is optional.
 +
 +.. _VNC_L2_Group_Configuration:
 +
 +VNC L2 Group Configuration
 +--------------------------
 +
 +The route targets advertised with prefixes and addresses registered by an NVE
 +are determined based on the NVE's associated VNC NVE Group Configuration,
 +:ref:`VNC_NVE_Group_Configuration`. Layer 2 (L2) Groups are used to override
 +the route targets for an NVE's Ethernet registrations based on the Logical
 +Network Identifier and label value.  A Logical Network Identifier is used to
 +uniquely identify a logical Ethernet segment and is conceptually similar to the
 +Ethernet Segment Identifier defined in :rfc:`7432`. Both the Logical Network
 +Identifier and Label are passed to VNC via RFP prefix and address registration.
 +
 +Note that a corresponding NVE group configuration must be present, and that
 +other NVE associated configuration information, notably RD, is not impacted by
 +L2 Group Configuration.
 +
 +.. index:: vnc l2-group NAME
 +.. clicmd:: vnc 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:: no vnc l2-group NAME
 +.. clicmd:: no vnc l2-group NAME
 +
 +   Delete the L2 group named `name`.
 +
 +The following statements are valid in a L2 group definition:
 +
 +.. index:: logical-network-id VALUE
 +.. clicmd:: logical-network-id VALUE
 +
 +   Define the Logical Network Identifier with a value in the range of
 +   0-4294967295 that identifies the logical Ethernet segment.
 +
 +.. index:: labels LABEL-LIST
 +.. clicmd:: labels LABEL-LIST
 +
 +.. index:: no labels LABEL-LIST
 +.. clicmd:: no labels LABEL-LIST
 +
 +   Add or remove labels associated with the group. `label-list` is a
 +   space separated list of label values in the range of 0-1048575.
 +
 +.. index:: rt import RT-TARGET
 +.. clicmd:: rt import RT-TARGET
 +
 +.. index:: rt export RT-TARGET
 +.. clicmd:: rt export RT-TARGET
 +
 +.. index:: rt both RT-TARGET
 +.. clicmd:: rt both RT-TARGET
 +
 +   Specify the route target import and export value associated with the group.
 +   A complete definition of these parameters is given above,
 +   :ref:`VNC_NVE_Group_Configuration`.
 +
 +.. _Configuring_Redistribution_of_Routes_from_Other_Routing_Protocols:
 +
 +Configuring Redistribution of Routes from Other Routing Protocols
 +-----------------------------------------------------------------
 +
 +Routes from other protocols (including BGP) can be provided to VNC (both for
 +RFP and for redistribution via BGP) from three sources: the zebra kernel
 +routing process; directly from the main (default) unicast BGP RIB; or directly
 +from a designated BGP unicast exterior routing RIB instance.
 +
 +The protocol named in the `vnc redistribute` command indicates the route
 +source: `bgp-direct` routes come directly from the main (default) unicast BGP
 +RIB and are available for RFP and are redistributed via BGP;
 +`bgp-direct-to-nve-groups` routes come directly from a designated BGP unicast
 +routing RIB and are made available only to RFP; and routes from other protocols
 +come from the zebra kernel routing process.
 +Note that the zebra process does not need to be active if
 +only `bgp-direct` or `bgp-direct-to-nve-groups` routes are used.
 +
 +zebra routes
 +^^^^^^^^^^^^
 +
 +Routes originating from protocols other than BGP must be obtained
 +via the zebra routing process.
 +Redistribution of these routes into VNC does not support policy mechanisms
 +such as prefix-lists or route-maps.
 +
 +bgp-direct routes
 +^^^^^^^^^^^^^^^^^
 +
 +`bgp-direct` redistribution supports policy via
 +prefix lists and route-maps. This policy is applied to incoming
 +original unicast routes before the redistribution translations
 +(described below) are performed.
 +
 +Redistribution of `bgp-direct` routes is performed in one of three
 +possible modes: `plain`, `nve-group`, or `resolve-nve`.
 +The default mode is `plain`.
 +These modes indicate the kind of translations applied to routes before
 +they are added to the VNC RIB.
 +
 +In `plain` mode, the route's next hop is unchanged and the RD is set
 +based on the next hop.
 +For `bgp-direct` redistribution, the following translations are performed:
 +
 +- The VN address is set to the original unicast route's next hop address.
 +- The UN address is NOT set. (VN->UN mapping will occur via
 +  ENCAP route or attribute, based on `vnc advertise-un-method`
 +  setting, generated by the RFP registration of the actual NVE)
 +- 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).
 +
 +In `nve-group` mode, routes are registered with VNC as if they came from an NVE
 +in the nve-group designated in the `vnc redistribute nve-group` command. The
 +following translations are performed:
 +
 +- The next hop/VN address is set to the VN prefix configured for the
 +  redistribute nve-group.
 +- The UN address is set to the UN prefix configured for the redistribute
 +  nve-group.
 +- The RD is set to the RD configured for the redistribute nve-group.
 +- The RT list is set to the RT list configured for the redistribute nve-group.
 +  If `bgp-direct` routes are being redistributed, any extended communities
 +  present in the original unicast route will also be included.
 +
 +In `resolve-nve` mode, the next hop of the original BGP route is typically the
 +address of an NVE connected router (CE) connected by one or more NVEs.
 +Each of the connected NVEs will register, via RFP, a VNC host route to the CE.
 +This mode may be though of as a mechanism to proxy RFP registrations of BGP
 +unicast routes on behalf of registering NVEs.
 +
 +Multiple copies of the BGP route, one per matching NVE host route, will be
 +added to VNC.  In other words, for a given BGP unicast route, each instance of
 +a RFP-registered host route to the unicast route's next hop will result in an
 +instance of an imported VNC route.  Each such imported VNC route will have a
 +prefix equal to the original BGP unicast route's prefix, and a next hop equal
 +to the next hop of the matching RFP-registered host route.  If there is no
 +RFP-registered host route to the next hop of the BGP unicast route, no
 +corresponding VNC route will be imported.
 +
 +The following translations are applied:
 +
 +- The Next Hop is set to the next hop of the NVE route (i.e., the
 +  VN address of the NVE).
 +
 +- The extended community list in the new route is set to the
 +  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.
 +
 +
 +bgp-direct-to-nve-groups routes
 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 +
 +Unicast routes from the main or a designated instance of BGP may be
 +redistributed to VNC as bgp-direct-to-nve-groups routes. These routes are NOT
 +announced via BGP, but they are made available for local RFP lookup in response
 +to queries from NVEs.
 +
 +A non-main/default BGP instance is configured using the `bgp multiple-instance`
 +and `router bgp AS view NAME` commands as described elsewhere in this document.
 +
 +In order for a route in the unicast BGP RIB to be made available to a querying
 +NVE, there must already be, available to that NVE, an (interior) VNC route
 +matching the next hop address of the unicast route.  When the unicast route is
 +provided to the NVE, its next hop 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.
 +
 +There is currently no policy (prefix-list or route-map) support for
 +`bgp-direct-to-nve-groups` routes.
 +
 +Redistribution Command Syntax
 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 +
 +.. index:: vnc redistribute ipv4|ipv6 bgp|bgp-direct|ipv6 bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
 +.. clicmd:: vnc redistribute ipv4|ipv6 bgp|bgp-direct|ipv6 bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
 +
 +.. index:: vnc redistribute ipv4|ipv6 bgp-direct-to-nve-groups view VIEWNAME
 +.. clicmd:: vnc redistribute ipv4|ipv6 bgp-direct-to-nve-groups view VIEWNAME
 +
 +.. index:: no vnc redistribute ipv4|ipv6 bgp|bgp-direct|bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
 +.. clicmd:: no vnc redistribute ipv4|ipv6 bgp|bgp-direct|bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
 +
- 
 +   Import (or do not import) prefixes from another routing protocols. Specify
 +   both the address family to import (`ipv4` or `ipv6`) and the protocol
 +   (`bgp`, `bgp-direct`, `bgp-direct-to-nve-groups`, `connected`, `kernel`,
 +   `ospf`, `rip`, or `static`). Repeat this statement as needed for each
 +   combination of address family and routing protocol.  Prefixes from protocol
 +   `bgp-direct` are imported from unicast BGP in the same bgpd process.
 +   Prefixes from all other protocols (including `bgp`) are imported via the
 +   `zebra` kernel routing process.
 +
 +.. index:: vnc redistribute mode plain|nve-group|resolve-nve
 +.. clicmd:: vnc redistribute mode plain|nve-group|resolve-nve
 +
- 
 +   Redistribute routes from other protocols into VNC using the specified mode.
 +   Not all combinations of modes and protocols are supported.
 +
 +.. index:: vnc redistribute nve-group GROUP-NAME
 +.. clicmd:: vnc redistribute nve-group GROUP-NAME
 +
 +.. index:: no vnc redistribute nve-group GROUP-NAME
 +.. clicmd:: no vnc redistribute nve-group GROUP-NAME
 +
- 
 +   When using `nve-group` mode, assign (or do not assign) the NVE group
 +   `group-name` to routes redistributed from another routing protocol.
 +   `group-name` must be configured using `vnc nve-group`.
 +
 +   The VN and UN prefixes of the nve-group must both be configured, and each
 +   prefix must be specified as a full-length (/32 for IPv4, /128 for IPv6)
 +   prefix.
 +
 +.. index:: vnc redistribute lifetime LIFETIME|infinite
 +.. clicmd:: vnc redistribute lifetime LIFETIME|infinite
 +
- 
 +   Assign a registration lifetime, either `lifetime` seconds or `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.
 +
 +.. index:: vnc redistribute resolve-nve roo-ec-local-admin 0-65536
 +.. clicmd:: 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
 +   under the `resolve-nve` mode. The default value is `5226`.
 +
 +The following four `prefix-list` and `route-map` commands may be specified
 +in the context of an nve-group or not.  If they are specified in the context
 +of an nve-group, they apply only if the redistribution mode is `nve-group`,
 +and then only for routes being redistributed from `bgp-direct`.  If they are
 +specified outside the context of an nve-group, then they apply only for
 +redistribution modes `plain` and `resolve-nve`, and then only for routes
 +being redistributed from `bgp-direct`.
 +
 +.. index:: vnc redistribute bgp-direct (ipv4|ipv6) prefix-list LIST-NAME
 +.. clicmd:: vnc redistribute bgp-direct (ipv4|ipv6) prefix-list LIST-NAME
 +
 +   When redistributing `bgp-direct` routes,
 +   specifies that the named prefix-list should be applied.
 +
 +.. index:: vnc redistribute bgp-direct no (ipv4|ipv6) prefix-list
 +.. clicmd:: vnc redistribute bgp-direct no (ipv4|ipv6) prefix-list
 +
 +   When redistributing `bgp-direct` routes,
 +   specifies that no prefix-list should be applied.
 +
 +.. index:: vnc redistribute bgp-direct route-map  MAP-NAME
 +.. clicmd:: vnc redistribute bgp-direct route-map  MAP-NAME
 +
 +   When redistributing `bgp-direct` routes,
 +   specifies that the named route-map should be applied.
 +
 +.. index:: vnc redistribute bgp-direct no route-map
 +.. clicmd:: vnc redistribute bgp-direct no route-map
 +
 +   When redistributing `bgp-direct` routes,
 +   specifies that no route-map should be applied.
 +
 +.. _Configuring_Export_of_Routes_to_Other_Routing_Protocols:
 +
 +Configuring Export of Routes to Other Routing Protocols
 +-------------------------------------------------------
 +
 +Routes from VNC (both for RFP and for redistribution via BGP) can be provided
 +to other protocols, either via zebra or directly to BGP.
 +
 +It is important to note that when exporting routes to other protocols, the
 +downstream protocol must also be configured to import the routes.  For example,
 +when VNC routes are exported to unicast BGP, the BGP configuration must include
 +a corresponding `redistribute vnc-direct` statement.
 +
 +.. index:: export bgp|zebra mode none|group-nve|registering-nve|ce
 +.. clicmd:: export bgp|zebra mode none|group-nve|registering-nve|ce
 +
- 
 +   Specify how routes should be exported to bgp or zebra.  If the mode is
 +   `none`, routes are not exported.  If the mode is `group-nve`, routes are
 +   exported according to nve-group or vrf-policy group configuration
 +   (:ref:`VNC_NVE_Group_Configuration`): if a group is configured to allow
 +   export, then each prefix visible to the group is exported with next hops set
 +   to the currently-registered NVEs.  If the mode is `registering-nve`, then all
 +   VNC routes are exported with their original next hops.  If the mode is `ce`,
 +   only VNC routes that have an NVE connected CE Router encoded in a Route
 +   Origin Extended Community are exported.  This extended community must have an
 +   administrative value that matches the configured `roo-ec-local-admin` value.
 +   The next hop of the exported route is set to the encoded NVE connected CE
 +   Router.
 +
-   The default for both bgp and zebra is mode `none`.
++   The default for both bgp and zebra is mode `none`.
 +
 +.. index:: vnc export bgp|zebra group-nve group GROUP-NAME
 +.. clicmd:: vnc export bgp|zebra group-nve group GROUP-NAME
 +
 +.. index:: vnc export bgp|zebra group-nve no group GROUP-NAME
 +.. clicmd:: vnc export bgp|zebra group-nve no group GROUP-NAME
 +
 +   When export mode is `group-nve`, export (or do not export) prefixes from the
 +   specified nve-group or vrf-policy group to unicast BGP or to zebra.  Repeat
 +   this statement as needed for each nve-group to be exported.  Each VNC prefix
 +   that is exported will result in N exported routes to the prefix, each with a
 +   next hop corresponding to one of the N NVEs currently associated with the
 +   nve-group.
 +
 +.. index:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
 +.. clicmd:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
 +
 +   When export mode is `ce` or `registering-nve`,
 +   specifies that the named prefix-list should be applied to routes
 +   being exported to bgp or zebra.
 +   Prefix-lists for ipv4 and ipv6 are independent of each other.
 +
 +.. index:: export bgp|zebra no ipv4|ipv6 prefix-list
 +.. clicmd:: export bgp|zebra no ipv4|ipv6 prefix-list
 +
-     When export mode is `ce` or `registering-nve`,
-     specifies that no prefix-list should be applied to routes
-     being exported to bgp or zebra.
++   When export mode is `ce` or `registering-nve`,
++   specifies that no prefix-list should be applied to routes
++   being exported to bgp or zebra.
 +
 +.. index:: export bgp|zebra route-map MAP-NAME
 +.. clicmd:: export bgp|zebra route-map MAP-NAME
 +
- 
 +   When export mode is `ce` or `registering-nve`, specifies that the named
 +   route-map should be applied to routes being exported to bgp or zebra.
 +
 +.. index:: export bgp|zebra no route-map
 +.. clicmd:: export bgp|zebra no route-map
 +
 +   When export mode is `ce` or `registering-nve`, specifies that no route-map
 +   should be applied to routes being exported to bgp or zebra.
 +
 +   When the export mode is `group-nve`, policy for exported routes is specified
 +   per-NVE-group or vrf-policy group inside a `nve-group` `RFG-NAME` block via
 +   the following commands(:ref:`VNC_NVE_Group_Configuration`):
 +
 +.. index:: export bgp|zebra route-map MAP-NAME
 +.. clicmd:: export bgp|zebra route-map MAP-NAME
 +
 +   This command is valid inside a `nve-group` `RFG-NAME` block.  It specifies
 +   that the named route-map should be applied to routes being exported to bgp
 +   or zebra.
 +
 +.. index:: export bgp|zebra no route-map
 +.. clicmd:: export bgp|zebra no route-map
 +
 +   This command is valid inside a `nve-group` `RFG-NAME` block.  It specifies
 +   that no route-map should be applied to routes being exported to bgp or
 +   zebra.
 +
 +.. index:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
 +.. clicmd:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
 +
 +   This command is valid inside a `nve-group` `RFG-NAME` block.  It specifies
 +   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.
 +
 +.. index:: export bgp|zebra no ipv4|ipv6 prefix-list
 +
 +.. clicmd:: export bgp|zebra no ipv4|ipv6 prefix-list
 +
 +   This command is valid inside a `nve-group` `RFG-NAME` block.  It specifies
 +   that no prefix-list filter should be applied to routes being exported to
 +   bgp or zebra.
 +
 +.. _Manual_Address_Control:
 +
 +Manual Address Control
 +======================
 +
 +The commands in this section can be used to augment normal dynamic VNC.  The
 +`add vnc` commands can be used to manually add IP prefix or Ethernet MAC
 +address forwarding information. The `clear vnc` commands can be used to remove
 +manually and dynamically added information.
 +
 +.. clicmd:: add vnc prefix (A.B.C.D/M|X:X::X:X/M) vn (A.B.C.D|X:X::X:X) un (A.B.C.D|X:X::X:X) [cost (0-255)] [lifetime (infinite|(1-4294967295))] [local-next-hop (A.B.C.D|X:X::X:X) [local-cost (0-255)]]
 +
 +   Register an IP prefix on behalf of the NVE identified by the VN and UN
 +   addresses. The `cost` parameter provides the administrative preference of
 +   the forwarding information for remote advertisement. If omitted, it defaults
 +   to 255 (lowest preference). The `lifetime` parameter identifies the period,
 +   in seconds, that the information remains valid. If omitted, it defaults to
 +   `infinite`. The optional `local-next-hop` parameter is used to configure a
 +   nexthop to be used by an NVE to reach the prefix via a locally connected CE
 +   router. This information remains local to the NVA, i.e., not passed to other
 +   NVAs, and is only passed to registered NVEs. When specified, it is also
 +   possible to provide a `local-cost` parameter to provide a forwarding
 +   preference. If omitted, it defaults to 255 (lowest preference).
 +
 +.. clicmd:: add vnc mac xx:xx:xx:xx:xx:xx virtual-network-identifier (1-4294967295) vn (A.B.C.D|X:X::X:X) un (A.B.C.D|X:X::X:X) [prefix (A.B.C.D/M|X:X::X:X/M)] [cost (0-255)] [lifetime (infinite|(1-4294967295))]
 +
 +   Register a MAC address for a logical Ethernet (L2VPN) on behalf of the NVE
 +   identified by the VN and UN addresses. The optional `prefix` parameter is to
 +   support enable IP address mediation for the given prefix. The `cost`
 +   parameter provides the administrative 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`.
 +
 +.. 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
 +   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
 +   information.
 +
 +.. index:: 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)])
 +.. 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
 +   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)]))
 +.. clicmd:: clear vnc nve (\*|((vn|un) (A.B.C.D|X:X::X:X) [(un|vn) (A.B.C.D|X:X::X:X)]))
 +
 +   Delete prefixes associated with the NVE specified by the given VN and UN
 +   addresses. It is permissible to specify only one of VN or UN, in which case
 +   any matching registration will be deleted. It is also permissible to specify
 +   `*` in lieu of any VN or UN address, in which case all registrations will
 +   match.
 +
 +.. _Other_VNC-Related_Commands:
 +
 +Other VNC-Related Commands
 +==========================
 +
 +Note: VNC-Related configuration can be obtained via the `show
 +running-configuration` command when in `enable` mode.
 +
 +The following commands are used to clear and display Virtual Network Control
 +related information:
 +
 +.. index:: clear vnc counters
 +.. clicmd:: clear vnc counters
 +
 +   Reset the counter values stored by the NVA. Counter
 +   values can be seen using the `show vnc` commands listed above. This
 +   command is only available in `enable` mode.
 +
 +.. index:: show vnc summary
 +.. clicmd:: show vnc summary
 +
 +   Print counter values and other general information
 +   about the NVA. Counter values can be reset
 +   using the `clear vnc counters` command listed below.
 +
 +.. index:: show vnc nves
 +.. clicmd:: show vnc nves
 +
 +.. index:: show vnc nves vn|un ADDRESS
 +.. clicmd:: show vnc nves vn|un ADDRESS
 +
 +   Display the NVA's current clients. Specifying `address` limits the output to
 +   the NVEs whose addresses match `address`. The time since the NVA last
 +   communicated with the NVE, per-NVE summary counters and each NVE's addresses
 +   will be displayed.
 +
 +.. index:: show vnc queries
 +.. clicmd:: show vnc queries
 +
 +.. index:: show vnc queries PREFIX
 +.. clicmd:: show vnc queries PREFIX
 +
 +   Display active Query information. Queries remain valid for the default
 +   Response Lifetime (:ref:`VNC_Defaults_Configuration`) or NVE-group Response
 +   Lifetime (:ref:`VNC_NVE_Group_Configuration`). Specifying `prefix` limits
 +   the output to Query Targets that fall within `prefix`.
 +
 +   Query information is provided for each querying NVE, and includes the Query
 +   Target and the time remaining before the information is removed.
 +
 +.. index:: show vnc registrations [all|local|remote|holddown|imported]
 +.. clicmd:: show vnc registrations [all|local|remote|holddown|imported]
 +
 +.. index:: show vnc registrations [all|local|remote|holddown|imported] PREFIX
 +.. clicmd:: show vnc registrations [all|local|remote|holddown|imported] PREFIX
 +
 +   Display local, remote, holddown, and/or imported registration information.
 +   Local registrations are routes received via RFP, which are present in the
 +   NVA Registrations Cache. Remote registrations are routes received via BGP
 +   (VPN SAFIs), which are present in the NVE-group import tables. Holddown
 +   registrations are local and remote routes that have been withdrawn but whose
 +   holddown timeouts have not yet elapsed. Imported information represents
 +   routes that are imported into NVA and are made available to querying NVEs.
 +   Depending on configuration, imported routes may also be advertised via BGP.
 +   Specifying `prefix` limits the output to the registered prefixes that fall
 +   within `prefix`.
 +
 +   Registration information includes the registered prefix, the registering NVE
 +   addresses, the registered administrative cost, the registration lifetime and
 +   the time since the information was registered or, in the case of Holddown
 +   registrations, the amount of time remaining before the information is
 +   removed.
 +
 +.. index:: show vnc responses [active|removed]
 +.. clicmd:: show vnc responses [active|removed]
 +
 +.. index:: show vnc responses [active|removed] PREFIX
 +.. clicmd:: show vnc responses [active|removed] PREFIX
 +
 +   Display all, active and/or removed response information which are
 +   present in the NVA Responses Cache. Responses remain valid for the
 +   default Response Lifetime (:ref:`VNC_Defaults_Configuration`) or
 +   NVE-group Response Lifetime (:ref:`VNC_NVE_Group_Configuration`.)
 +   When Removal Responses are enabled (:ref:`General_VNC_Configuration`),
 +   such responses are listed for the Response Lifetime. Specifying
 +   `prefix` limits the output to the addresses that fall within
 +   `prefix`.
 +
 +   Response information is provided for each querying NVE, and includes
 +   the response prefix, the prefix-associated registering NVE addresses,
 +   the administrative cost, the provided response lifetime and the time
 +   remaining before the information is to be removed or will become inactive.
 +
 +.. index:: show memory vnc
 +.. clicmd:: show memory vnc
 +
- 
 +   Print the number of memory items allocated by the NVA.
 +
 +.. _Example_VNC_and_VNC-GW_Configurations:
 +
 +Example VNC and VNC-GW Configurations
 +=====================================
 +
++.. _vnc-mesh-nva-config:
++
++Mesh NVA Configuration
++----------------------
++
++This example includes three NVAs, nine NVEs, and two NVE groups. Note that
++while not shown, a single physical device may support multiple logical NVEs.
++:figure:`fig-vnc-mesh` shows ``code NVA-1`` (192.168.1.100), ``NVA 2``
++(192.168.1.101), and ``NVA 3`` (192.168.1.102), which are connected in a full
++mesh. Each is a member of the autonomous system 64512. Each NVA provides VNC
++services to three NVE clients in the 172.16.0.0/16 virtual-network address
++range. The 172.16.0.0/16 address range is partitioned into two NVE groups,
++``group1`` (172.16.0.0/17) and ``group2`` (172.16.128.0/17).
++
++Each NVE belongs to either NVE group ``group1`` or NVE group
++``group2``.  The NVEs ``NVE 1``, ``NVE 2``, @code{NVE
++4}, ``NVE 7``, and ``NVE 8`` are members of the NVE group
++``group1``.  The NVEs ``NVE 3``, ``NVE 5``, @code{NVE
++6}, and ``NVE 9`` are members of the NVE group ``group2``.
++
++Each NVA advertises NVE underlay-network IP addresses using the
++Tunnel Encapsulation Attribute.
++
++.. _vnc-fig-vnc-mesh:
++.. figure:: ../figure/fig-vnc-mesh.png
++   :align: center
++   :alt: Three-way Mesh
++
++   A three-way full mesh with three NVEs per NVA.
++
++:file:`bgpd.conf` for ``NVA 1`` (192.168.1.100):::
++
++   router bgp 64512
++
++       bgp router-id 192.168.1.100
++
++       neighbor 192.168.1.101  remote-as 64512
++       neighbor 192.168.1.102  remote-as 64512
++
++       address-family ipv4 vpn
++           neighbor 192.168.1.101 activate
++           neighbor 192.168.1.102 activate
++       exit-address-family
++
++       vnc defaults
++           rd 64512:1
++           response-lifetime 200
++           rt both 1000:1 1000:2
++       exit-vnc
++
++       vnc nve-group group1
++           prefix vn 172.16.0.0/17
++           rt both 1000:1
++       exit-vnc
++
++       vnc nve-group group2
++           prefix vn 172.16.128.0/17
++           rt both 1000:2
++       exit-vnc
++
++   exit
++
++:file:`bgpd.conf` for ``NVA 2`` (192.168.1.101):::
++
++   router bgp 64512
++
++       bgp router-id 192.168.1.101
++
++       neighbor 192.168.1.100  remote-as 64512
++       neighbor 192.168.1.102  remote-as 64512
++
++       address-family ipv4 vpn
++           neighbor 192.168.1.100 activate
++           neighbor 192.168.1.102 activate
++       exit-address-family
++
++       vnc nve-group group1
++           prefix vn 172.16.0.0/17
++           rd 64512:1
++           response-lifetime 200
++           rt both 1000:1 1000:2
++       exit-vnc
++   exit
++
++:file:`bgpd.conf` for ``NVA 3`` (192.168.1.102):::
++
++   router bgp 64512
++
++       bgp router-id 192.168.1.102
++
++       neighbor 192.168.1.101  remote-as 64512
++       neighbor 192.168.1.102  remote-as 64512
++
++       address-family ipv4 vpn
++           neighbor 192.168.1.100 activate
++           neighbor 192.168.1.101 activate
++       exit-address-family
++
++       vnc defaults
++           rd 64512:1
++           response-lifetime 200
++           rt both 1000:1 1000:2
++       exit-vnc
++
++       vnc nve-group group1
++           prefix vn 172.16.128.0/17
++       exit-vnc
++   exit
++
++
++Mesh NVA and VNC-GW Configuration
++---------------------------------
++
++This example includes two NVAs, each with two associated NVEs, and two VNC-GWs,
++each supporting two CE routers physically attached to the four NVEs. Note that
++this example is showing a more complex configuration where VNC-GW is separated
++from normal NVA functions; it is equally possible to simplify the configuration
++and combine NVA and VNC-GW functions in a single FRR instance.
++
++.. _vnc-fig-vnc-gw:
++.. figure:: ../figures/fig-vnc-gw.png
++   :align: center
++   :alt: FRR VNC Gateway
++
++   Meshed NVEs and VNC-GWs
++
++As shown in :figure:`fig-vnc-gw`, NVAs and VNC-GWs are connected in a full iBGP
++mesh. The VNC-GWs each have two CEs configured as route-reflector clients.
++Each client provides BGP updates with unicast routes that the VNC-GW reflects
++to the other client. The VNC-GW also imports these unicast routes into VPN
++routes to be shared with the other VNC-GW and the two NVAs. This route
++importation is controlled with the ``vnc redistribute`` statements shown in the
++configuration. Similarly, registrations sent by NVEs via RFP to the NVAs are
++exported by the VNC-GWs to the route-reflector clients as unicast routes. RFP
++registrations exported this way have a next-hop address of the CE behind the
++connected (registering) NVE. Exporting VNC routes as IPv4 unicast is enabled
++with the ``vnc export`` command below.
++
++The configuration for ``VNC-GW 1`` is shown below.::
++
++   router bgp 64512
++    bgp router-id 192.168.1.101
++    bgp cluster-id 1.2.3.4
++    neighbor 192.168.1.102 remote-as 64512
++    neighbor 192.168.1.103 remote-as 64512
++    neighbor 192.168.1.104 remote-as 64512
++    neighbor 172.16.1.2 remote-as 64512
++    neighbor 172.16.2.2 remote-as 64512
++    !
++    address-family ipv4 unicast
++     redistribute vnc-direct
++     no neighbor 192.168.1.102 activate
++     no neighbor 192.168.1.103 activate
++     no neighbor 192.168.1.104 activate
++     neighbor 172.16.1.2 route-reflector-client
++     neighbor 172.16.2.2 route-reflector-client
++    exit-address-family
++    !
++    address-family ipv4 vpn
++      neighbor 192.168.1.102 activate
++      neighbor 192.168.1.103 activate
++      neighbor 192.168.1.104 activate
++    exit-address-family
++    vnc export bgp mode ce
++    vnc redistribute mode resolve-nve
++    vnc redistribute ipv4 bgp-direct
++    exit
++
++Note that in the VNC-GW configuration, the neighboring VNC-GW and NVAs each
++have a statement disabling the IPv4 unicast address family. IPv4 unicast is on
++by default and this prevents the other VNC-GW and NVAs from learning unicast
++routes advertised by the route-reflector clients.
++
++Configuration for ``NVA 2``:::
++
++   router bgp 64512
++    bgp router-id 192.168.1.104
++    neighbor 192.168.1.101 remote-as 64512
++    neighbor 192.168.1.102 remote-as 64512
++    neighbor 192.168.1.103 remote-as 64512
++    !
++    address-family ipv4 unicast
++     no neighbor 192.168.1.101 activate
++     no neighbor 192.168.1.102 activate
++     no neighbor 192.168.1.103 activate
++    exit-address-family
++    !
++    address-family ipv4 vpn
++      neighbor 192.168.1.101 activate
++      neighbor 192.168.1.102 activate
++      neighbor 192.168.1.103 activate
++    exit-address-family
++    !
++    vnc defaults
++     response-lifetime 3600
++     exit-vnc
++    vnc nve-group nve1
++     prefix vn 172.16.1.1/32
++     response-lifetime 3600
++     rt both 1000:1 1000:2
++     exit-vnc
++    vnc nve-group nve2
++     prefix vn 172.16.2.1/32
++     response-lifetime 3600
++     rt both 1000:1 1000:2
++     exit-vnc
++    exit
++
++.. 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}
++.. @end float
++.. An NVA can also import unicast routes from BGP without advertising the
++.. imported routes as VPN routes.  Such imported routes, while not
++.. distributed to other NVAs or VNC-GWs, are are available to NVEs via
++.. RFP query messages sent to the NVA. @ref{fig:fig-vnc-gw-rr}
++.. shows an example topology where unicast routes are imported into NVAs
++.. from a Route Reflector.  (@pxref{Route Reflector} for route reflector
++.. configuration details.)  The following three lines can be added to the
++.. ``NVA 1`` and ``NVA 2`` configurations to import routes into VNC
++.. for local VNC use:
++..
++.. @verbatim
++..  neighbor 192.168.1.105 remote-as 64512
++..  vnc redistribute mode plain
++..  vnc redistribute ipv4 bgp-direct-to-nve-groups
++.. @end verbatim
++
++.. _vnc-with-frr-route-reflector-config:
++
++VNC with FRR Route Reflector Configuration
++------------------------------------------
++
++A route reflector eliminates the need for a fully meshed NVA network by acting
++as the hub between NVAs. :figure:`vnc-fig-vnc-frr-route-reflector` shows BGP
++route reflector ``BGP Route Reflector 1`` (192.168.1.100) as a route reflector
++for NVAs ``NVA 2``(192.168.1.101) and ``NVA 3`` (192.168.1.102).
++
++@float Figure,fig:fig-vnc-frr-route-reflector @center
++@image{fig-vnc-frr-route-reflector,400pt,,Frr Route Reflector} @caption{Two
++NVAs and a BGP Route Reflector} @end float
++
++.. _vnc-fig-vnc-frr-route-reflector:
++.. figure:: ../figures/fig-vnc-frr-route-reflector.png
++   :align: center
++   :alt: FRR Route Reflector
++
++   Two NVAs and a BGP Route Reflector
++
++``NVA 2`` and ``NVA 3`` advertise NVE underlay-network IP addresses using the
++Tunnel Encapsulation Attribute. ``BGP Route Reflector 1`` ``reflects''
++advertisements from ``NVA 2`` to ``NVA 3`` and vice versa.
++
++As in the example of :ref:`vnc-mesh-nva-config`, there are two NVE groups.  The
++172.16.0.0/16 address range is partitioned into two NVE groups, ``group1``
++(172.16.0.0/17) and ``group2`` (172.16.128.0/17).  The NVE ``NVE 4``, ``NVE
++7``, and ``NVE 8`` are members of the NVE group ``group1``.  The NVEs ``NVE
++5``, ``NVE 6``, and ``NVE 9`` are members of the NVE group ``group2``.
++
++:file:`bgpd.conf` for ``BGP Route Reflector 1`` on 192.168.1.100:::
++
++   router bgp 64512
++
++       bgp router-id 192.168.1.100
++
++       neighbor 192.168.1.101 remote-as 64512
++       neighbor 192.168.1.101 port 7179
++       neighbor 192.168.1.101 description iBGP-client-192-168-1-101
++
++       neighbor 192.168.1.102 remote-as 64512
++       neighbor 192.168.1.102 port 7179
++       neighbor 192.168.1.102 description iBGP-client-192-168-1-102
++
++       address-family ipv4 unicast
++           neighbor 192.168.1.101 route-reflector-client
++           neighbor 192.168.1.102 route-reflector-client
++       exit-address-family
++
++       address-family ipv4 vpn
++           neighbor 192.168.1.101 activate
++           neighbor 192.168.1.102 activate
++
++           neighbor 192.168.1.101 route-reflector-client
++           neighbor 192.168.1.102 route-reflector-client
++       exit-address-family
++
++   exit
++
++:file:`bgpd.conf` for ``NVA 2`` on 192.168.1.101:::
++
++   router bgp 64512
++
++       bgp router-id 192.168.1.101
++
++       neighbor 192.168.1.100  remote-as 64512
++
++       address-family ipv4 vpn
++           neighbor 192.168.1.100 activate
++       exit-address-family
++
++       vnc nve-group group1
++           prefix vn 172.16.0.0/17
++           rd 64512:1
++           response-lifetime 200
++           rt both 1000:1 1000:2
++       exit-vnc
++   exit
++
++:file:`bgpd.conf` for ``NVA 2`` on 192.168.1.102:::
++
++  router bgp 64512
++
++      bgp router-id 192.168.1.102
++
++      neighbor 192.168.1.100  remote-as 64512
++
++      address-family ipv4 vpn
++          neighbor 192.168.1.100 activate
++      exit-address-family
++
++      vnc defaults
++          rd 64512:1
++          response-lifetime 200
++          rt both 1000:1 1000:2
++      exit-vnc
++
++      vnc nve-group group1
++          prefix vn 172.16.128.0/17
++      exit-vnc
++  exit
++
++While not shown, an NVA can also be configured as a route reflector.
++
++.. _vnc-with-commercial-route-reflector-config:
++
++VNC with Commercial Route Reflector Configuration
++-------------------------------------------------
++
++This example is identical to :ref:`vnc-with-frr-route-reflector-configuration`
++with the exception that the route reflector is a commercial router. Only the
++VNC-relevant configuration is provided.
++
++.. figure:: ../figures/fig-vnc-commercial-route-reflector
++   :align: center
++   :alt: Commercial Route Reflector
++
++   Two NVAs with a commercial route reflector
++
++:file:`bgpd.conf` for BGP route reflector ``Commercial Router`` on 192.168.1.104:::
++
++   version 8.5R1.13;
++   routing-options {
++       rib inet.0 {
++           static {
++               route 172.16.0.0/16 next-hop 192.168.1.104;
++           }
++       }
++       autonomous-system 64512;
++       resolution {
++           rib inet.3 {
++               resolution-ribs inet.0;
++           }
++           rib bgp.l3vpn.0 {
++               resolution-ribs inet.0;
++           }
++       }
++   }
++   protocols {
++       bgp {
++           advertise-inactive;
++           family inet {
++               labeled-unicast;
++           }
++          group 1 {
++               type internal;
++               advertise-inactive;
++               advertise-peer-as;
++               import h;
++               family inet {
++                   unicast;
++               }
++               family inet-vpn {
++                   unicast;
++               }
++               cluster 192.168.1.104;
++               neighbor 192.168.1.101;
++               neighbor 192.168.1.102;
++           }
++       }
++   }
++   policy-options {
++       policy-statement h {
++           from protocol bgp;
++           then {
++               as-path-prepend 64512;
++               accept;
++           }
++       }
++   }
++
++:file:`bgpd.conf` for ``NVA 2`` on 192.168.1.101:::
++
++   router bgp 64512
++
++       bgp router-id 192.168.1.101
++
++       neighbor 192.168.1.100  remote-as 64512
++
++       address-family ipv4 vpn
++           neighbor 192.168.1.100 activate
++       exit-address-family
++
++       vnc nve-group group1
++           prefix vn 172.16.0.0/17
++           rd 64512:1
++           response-lifetime 200
++           rt both 1000:1 1000:2
++       exit-vnc
++   exit
++
++:file:`bgpd.conf` for ``NVA 3`` on 192.168.1.102:::
++
++   router bgp 64512
++
++       bgp router-id 192.168.1.102
++
++       neighbor 192.168.1.100  remote-as 64512
++
++       address-family ipv4 vpn
++           neighbor 192.168.1.100 activate
++       exit-address-family
++
++       vnc defaults
++           rd 64512:1
++           response-lifetime 200
++           rt both 1000:1 1000:2
++       exit-vnc
++
++       vnc nve-group group1
++           prefix vn 172.16.128.0/17
++       exit-vnc
++   exit
++
++VNC with Redundant Route Reflectors Configuration
++-------------------------------------------------
++
++This example combines the previous two
++(:ref:`vnc-with-frr-route-reflector-config` and
++:ref:`vnc-with-commercial-route-reflector-config`) into a redundant route
++reflector configuration.  BGP route reflectors ``BGP Route Reflector 1`` and
++``Commercial Router`` are the route reflectors for NVAs ``NVA 2`` and ``NVA
++3``.  The two NVAs have connections to both route reflectors.
++
++.. figure:: ../fig-vnc-redundant-route-reflectors.png
++   :align: center
++   :alt: Redundant Route Reflectors
++
++   FRR-based NVA with redundant route reflectors
++
++:file:`bgpd.conf` for ``Bgpd Route Reflector 1`` on 192.168.1.100:::
++
++   router bgp 64512
++
++    bgp router-id 192.168.1.100
++    bgp cluster-id 192.168.1.100
++
++    neighbor 192.168.1.104 remote-as 64512
++
++    neighbor 192.168.1.101 remote-as 64512
++    neighbor 192.168.1.101 description iBGP-client-192-168-1-101
++    neighbor 192.168.1.101 route-reflector-client
++
++    neighbor 192.168.1.102 remote-as 64512
++    neighbor 192.168.1.102 description iBGP-client-192-168-1-102
++    neighbor 192.168.1.102 route-reflector-client
++
++    address-family ipv4 vpn
++     neighbor 192.168.1.101 activate
++     neighbor 192.168.1.102 activate
++     neighbor 192.168.1.104 activate
++
++     neighbor 192.168.1.101 route-reflector-client
++     neighbor 192.168.1.102 route-reflector-client
++    exit-address-family
++   exit
++
++:file:`bgpd.conf` for ``NVA 2`` on 192.168.1.101:::
++
++    router bgp 64512
++
++     bgp router-id 192.168.1.101
++
++     neighbor 192.168.1.100  remote-as 64512
++     neighbor 192.168.1.104  remote-as 64512
++
++     address-family ipv4 vpn
++      neighbor 192.168.1.100 activate
++      neighbor 192.168.1.104 activate
++     exit-address-family
++
++     vnc nve-group group1
++      prefix vn 172.16.0.0/17
++      rd 64512:1
++      response-lifetime 200
++      rt both 1000:1 1000:2
++     exit-vnc
++    exit
++
++:file:`bgpd.conf` for ``NVA 3`` on 192.168.1.102:::
++
++   router bgp 64512
++
++    bgp router-id 192.168.1.102
++
++    neighbor 192.168.1.100  remote-as 64512
++    neighbor 192.168.1.104  remote-as 64512
++
++    address-family ipv4 vpn
++     neighbor 192.168.1.100 activate
++     neighbor 192.168.1.104 activate
++    exit-address-family
++
++    vnc defaults
++     rd 64512:1
++     response-lifetime 200
++     rt both 1000:1 1000:2
++    exit-vnc
++
++    vnc nve-group group1
++     prefix vn 172.16.128.0/17
++    exit-vnc
++   exit
++
++:file:`bgpd.conf` for the Commercial Router route reflector on 192.168.1.104:::
++
++   routing-options {
++       rib inet.0 {
++           static {
++               route 172.16.0.0/16 next-hop 192.168.1.104;
++           }
++       }
++       autonomous-system 64512;
++       resolution {
++           rib inet.3 {
++               resolution-ribs inet.0;
++           }
++           rib bgp.l3vpn.0 {
++               resolution-ribs inet.0;
++           }
++       }
++   }
++   protocols {
++       bgp {
++           advertise-inactive;
++           family inet {
++               labeled-unicast;
++           }
++          group 1 {
++               type internal;
++               advertise-inactive;
++               advertise-peer-as;
++               import h;
++               family inet {
++                   unicast;
++               }
++               family inet-vpn {
++                   unicast;
++               }
++               cluster 192.168.1.104;
++               neighbor 192.168.1.101;
++               neighbor 192.168.1.102;
++           }
++
++          group 2 {
++               type internal;
++               advertise-inactive;
++               advertise-peer-as;
++               import h;
++               family inet {
++                   unicast;
++               }
++               family inet-vpn {
++                   unicast;
++               }
++               neighbor 192.168.1.100;
++           }
++
++       }
++   }
++   policy-options {
++       policy-statement h {
++           from protocol bgp;
++           then {
++               as-path-prepend 64512;
++               accept;
++           }
++       }
++   }
++
 +.. [#] The nve-id is carriedin the route distinguisher. It is the second octet
 +       of the eight-octet route distinguisher generated for Ethernet / L2
 +       advertisements. The first octet is a constant 0xFF, and the third
 +       through eighth octets are set to the L2
 +       ethernet address being advertised.
 +