summaryrefslogtreecommitdiffstats
path: root/doc/user/vnc.rst
diff options
context:
space:
mode:
Diffstat (limited to 'doc/user/vnc.rst')
-rw-r--r--doc/user/vnc.rst1393
1 files changed, 1393 insertions, 0 deletions
diff --git a/doc/user/vnc.rst b/doc/user/vnc.rst
new file mode 100644
index 0000000..4ff27c6
--- /dev/null
+++ b/doc/user/vnc.rst
@@ -0,0 +1,1393 @@
+.. _vnc-and-vnc-gw:
+
+**************
+VNC and VNC-GW
+**************
+
+This chapter describes how to use :abbr:`VNC (Virtual Network Control)`
+services, including :abbr:`NVA (Network Virtualization Authority)` and
+:abbr:`VNC-GW (VNC Gateway)` functions. Background information on NVAs,
+:abbr:`NVE (Network Virtualization Edge)` s, :abbr:`UN (Underlay Network)` s,
+and :abbr:`VN (Virtual Network)` is available from the
+`IETF <https://datatracker.ietf.org/wg/nvo3>`_. :abbr:`VNC-GW (VNC Gateway)` s
+support the import/export of routing information between VNC and :abbr:`CE
+(customer edge)` routers 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`. 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.
+
+
+.. _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.
+
+.. code-block:: frr
+
+ vnc defaults
+ ... various VNC defaults
+ exit-vnc
+
+
+These are the statements that can appear between ``vnc defaults`` and
+``exit-vnc``. Documentation for these statements is given in
+:ref:`vnc-nve-group-configuration`.
+
+- :clicmd:`rt import RT-LIST`
+- :clicmd:`rt export RT-LIST`
+- :clicmd:`rt both RT-LIST`
+- :clicmd:`rd ROUTE-DISTINGUISHER`
+- :clicmd:`l2rd NVE-ID-VALUE`
+- :clicmd:`response-lifetime LIFETIME|infinite`
+- :clicmd:`export bgp|zebra route-map MAP-NAME`
+- :clicmd:`export bgp|zebra no route-map`
+
+.. clicmd:: exit-vnc
+
+ Exit VNC configuration mode.
+
+.. _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.**
+
+.. 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.
+
+ .. code-block:: frr
+
+ vnc nve-group group1
+ ... configuration commands
+ exit-vnc
+
+
+The following statements are valid in an NVE group definition:
+
+.. 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) [#]_.
+
+ 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.
+
+.. 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.
+
+ These prefixes are used only for determining assignments of NVEs to NVE
+ Groups.
+
+.. 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.
+
+ 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``.
+
+.. 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.
+
+.. clicmd:: rt export RT-LIST
+
+.. clicmd:: rt import 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``
+
+ 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 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``.
+
+.. 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 parameter is used in conjunction with
+ :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
+ is optional.
+
+.. clicmd:: export bgp|zebra no route-map
+
+ Specify that no route-map should be applied to routes being exported to bgp
+ or zebra. This parameter is used in conjunction with
+ :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
+ is optional.
+
+.. 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 parameter is used in conjunction with
+ :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
+ is optional.
+
+.. 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.
+
+.. 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.
+
+ .. code-block:: frr
+
+ vnc l2-group group1
+ ... configuration commands
+ exit-vnc
+
+
+
+ Delete the L2 group named `name`.
+
+The following statements are valid in a L2 group definition:
+
+.. 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.
+
+.. clicmd:: 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.
+
+.. clicmd:: rt import RT-TARGET
+
+.. clicmd:: rt export 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
+`router bgp AS view NAME` command 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
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. clicmd:: vnc redistribute ipv4|ipv6 bgp|bgp-direct|ipv6 bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
+
+.. clicmd:: vnc redistribute ipv4|ipv6 bgp-direct-to-nve-groups view VIEWNAME
+
+
+ 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.
+
+.. 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.
+
+.. clicmd:: 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.
+
+.. 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.
+
+.. 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`.
+
+.. 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.
+
+.. clicmd:: vnc redistribute bgp-direct no (ipv4|ipv6) prefix-list
+
+ When redistributing `bgp-direct` routes,
+ specifies that no prefix-list should be applied.
+
+.. clicmd:: vnc redistribute bgp-direct route-map MAP-NAME
+
+ When redistributing `bgp-direct` routes,
+ specifies that the named route-map should be applied.
+
+.. 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.
+
+.. 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`.
+
+.. clicmd:: vnc export bgp|zebra group-nve 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.
+
+Some commands have a special meaning under certain export modes.
+
+: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.
+
+: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.
+
+: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.
+
+: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`):
+
+: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.
+
+: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.
+
+: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.
+
+: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 wildcarded to (potentially) match more
+ than one registration. The optional `mac` parameter specifies a layer-2 MAC
+ address that must match the registration(s) to be deleted. The optional
+ `local-next-hop` parameter is used to delete specific local nexthop
+ information.
+
+.. 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
+ wildcarded to (potentially) match more than one registration. The default
+ value for the `prefix` parameter is the wildcard value `*`.
+
+.. 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:
+
+.. 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.
+
+.. 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.
+
+.. clicmd:: show vnc nves
+
+.. 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.
+
+.. clicmd:: show vnc queries
+
+.. 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.
+
+.. clicmd:: show vnc registrations [all|local|remote|holddown|imported]
+
+.. 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.
+
+.. clicmd:: show vnc responses [active|removed]
+
+.. 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.
+
+.. 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.
+:ref:`vnc-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``, ``NVE 4``, ``NVE 7``, and ``NVE 8`` are members of
+the NVE group ``group1``. The NVEs ``NVE 3``, ``NVE 5``, ``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:: ../figures/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):
+
+.. code-block:: frr
+
+ 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):
+
+.. code-block:: frr
+
+ 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):
+
+.. code-block:: frr
+
+ 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 :ref:`vnc-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.
+
+.. code-block:: frr
+
+ 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``:
+
+.. code-block:: frr
+
+ 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. :ref:`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).
+
+.. _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:
+
+.. code-block:: frr
+
+ 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:
+
+.. code-block:: frr
+
+ 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:
+
+.. code-block:: frr
+
+ 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-config`
+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.png
+ :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:
+
+.. code-block:: frr
+
+ 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:
+
+.. code-block:: frr
+
+ 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:: ../figures/fig-vnc-redundant-route-reflectors.png
+ :align: center
+ :alt: Redundant Route Reflectors
+
+ FRR-based NVA with redundant route reflectors
+
+:file:`bgpd.conf` for ``BPGD Route Reflector 1`` on 192.168.1.100:
+
+.. code-block:: frr
+
+ 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:
+
+.. code-block:: frr
+
+ 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:
+
+.. code-block:: frr
+
+ 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 carried in 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.
+
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-23 07:50:19 +0000