7 This chapter describes how to use Virtual Network Control (:abbr:`VNC`)
8 services, including Network Virtualization Authority (:abbr:`NVA`) and VNC
9 Gateway (:abbr:`VNC-GW`) functions. Background information on NVAs, Network
10 Virtualization Edges (:abbr:`NVE`s), underlay networks (:abbr:`UN`s), and
11 virtual networks (:abbr:`VN`s) is available from the
12 `IETF Network Virtualization Overlays <https://datatracker.ietf.org/wg/nvo3>`_
13 :abbr:`VNC-GW (VNC-Gateways)` support the import/export of routing information
14 between VNC and customer edge routers (:abbr:`CE` s) operating within a VN.
15 Both IP/Layer 3 (L3) VNs, and IP with Ethernet/Layer 2 (L2) VNs are supported.
17 BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VN
18 information between NVAs. BGP based IP VPN support is defined in :rfc:`4364`,
19 and :rfc:`4659`. Both the Encapsulation Subsequent Address Family Identifier
20 (SAFI) and the Tunnel Encapsulation Attribute, :rfc:`5512` are supported.
22 The protocol that is used to communicate routing and Ethernet / Layer 2 (L2)
23 forwarding information between NVAs and NVEs is referred to as the Remote
24 Forwarder Protocol (RFP). `OpenFlow` is an example RFP. Specific RFP
25 implementations may choose to implement either a `hard-state` or `soft-state`
26 prefix and address registration model. To support a `soft-state` refresh model,
27 a `lifetime` in seconds is associated with all registrations and responses.
29 The chapter also provides sample configurations for basic example scenarios.
36 Virtual Network Control (:abbr:`VNC`) service configuration commands appear in
37 the `router bgp` section of the BGPD configuration file
38 (:ref:`bgp-configuration-examples`). The commands are broken down into the
41 - :dfn:`General VNC` configuration applies to general VNC operation and is
42 primarily used to control the method used to advertise tunnel information.
43 - :dfn:`Remote Forwarder Protocol (RFP)` configuration relates to the protocol
44 used between NVAs and NVEs.
45 - :dfn:`VNC Defaults` provides default parameters for registered NVEs.
46 - :dfn:`VNC NVE Group` provides for configuration of a specific set of
47 registered NVEs and overrides default parameters.
48 - :dfn:`Redistribution` and :dfn:`Export` control VNC-GW operation, i.e., the
49 import/export of routing information between VNC and customer edge routers
50 (:abbr:`CE`s) operating within a VN.
53 .. _General_VNC_Configuration:
55 General VNC Configuration
56 -------------------------
58 .. clicmd:: vnc advertise-un-method encap-safi|encap-attr
60 Advertise NVE underlay-network IP addresses using the encapsulation SAFI
61 (`encap-safi`) or the UN address sub-TLV of the Tunnel Encapsulation
62 attribute (`encap-attr`). When `encap-safi` is used, neighbors under
63 `address-family encap` and/or `address-family encapv6` must be configured.
64 The default is `encap-attr`.
66 .. _RFP_Related_Configuration:
68 RFP Related Configuration
69 -------------------------
71 The protocol that is used to communicate routing and Ethernet / L2 forwarding
72 information between NVAs and NVEs is referred to as the Remote Forwarder
73 Protocol (RFP). Currently, only a simple example RFP is included in FRR.
74 Developers may use this example as a starting point to integrate FRR with an
75 RFP of their choosing, e.g., `OpenFlow`. The example code includes the
76 following sample configuration:
78 .. clicmd:: rfp example-config-value VALUE
80 This is a simple example configuration parameter included as part of the RFP
81 example code. VALUE must be in the range of 0 to 4294967295.
83 .. _VNC_Defaults_Configuration:
85 VNC Defaults Configuration
86 --------------------------
88 The VNC Defaults section allows the user to specify default values for
89 configuration parameters for all registered NVEs.
90 Default values are overridden by :ref:`VNC_NVE_Group_Configuration`.
92 .. clicmd:: vnc defaults
94 Enter VNC configuration mode for specifying VNC default behaviors. Use
95 `exit-vnc` to leave VNC configuration mode. `vnc defaults` is optional.
100 ... various VNC defaults
104 These are the statements that can appear between ``vnc defaults`` and
107 .. index:: rt import RT-LIST
108 .. clicmd:: rt import RT-LIST
110 .. index:: rt export RT-LIST
111 .. clicmd:: rt export RT-LIST
113 .. index:: rt both RT-LIST
114 .. clicmd:: rt both RT-LIST
116 Specify default route target import and export lists. `rt-list` is a
117 space-separated list of route targets, each element of which is
118 in one of the following forms:
120 - ``IPv4-address:two-byte-integer``
121 - ``four-byte-autonomous-system-number:two-byte-integer``
122 - ``two-byte-autonomous-system-number:four-byte-integer``
124 If no default import RT list is specified, then the default import RT list
125 is empty. If no default export RT list is specified, then the default export
128 A complete definition of these parameters is given below
129 (:ref:`VNC_NVE_Group_Configuration`).
131 .. index:: rd route-distinguisher
132 .. clicmd:: rd ROUTE-DISTINGUISHER
134 Specify the default route distinguisher (RD) for routes advertised via BGP
135 VPNs. The route distinguisher must be in one of four forms:
137 - ``IPv4-address:two-byte-integer``
138 - ``four-byte-autonomous-system-number:two-byte-integer``
139 - ``two-byte-autonomous-system-number:four-byte-integer``
140 - ``auto:vn:two-byte-integer``
142 If RD is specified in the defaults section, the default RD value is
143 `two-byte-autonomous-system-number=0`:`four-byte-integer=0`.
145 A complete definition of this parameter is given below
146 (:ref:`VNC_NVE_Group_Configuration`).
148 .. index:: l2rd NVE-ID-VALUE
150 .. clicmd:: l2rd NVE-ID-VALUE
152 Set the value used to distinguish NVEs connected to the same logical
153 Ethernet segment (i.e., L2VPN). A complete definition of this parameter is
154 given below (:ref:`VNC_NVE_Group_Configuration`).
156 .. index:: response-lifetime LIFETIME|infinite
157 .. clicmd:: response-lifetime LIFETIME|infinite
159 Specify the default lifetime to be included in RFP response messages sent to
162 A complete definition of this parameter is given below
163 (:ref:`VNC_NVE_Group_Configuration`).
165 .. index:: export bgp|zebra route-map MAP-NAME
167 .. clicmd:: export bgp|zebra route-map MAP-NAME
169 Specify that the named route-map should be applied to routes being exported
172 .. index:: export bgp|zebra no route-map
174 .. clicmd:: export bgp|zebra no route-map
176 Specify that no route-map should be applied to routes being exported to bgp
182 Exit VNC configuration mode.
184 .. _VNC_NVE_Group_Configuration:
186 VNC NVE Group Configuration
187 ---------------------------
189 A NVE Group corresponds to a specific set of NVEs. A Client NVE is
190 assigned to an NVE Group based on whether there is a match for either
191 its virtual or underlay network address against the VN and/or UN address
192 prefixes specified in the NVE Group definition. When an NVE Group
193 definition specifies both VN and UN address prefixes, then an NVE must
194 match both prefixes in order to be assigned to the NVE Group. In the
195 event that multiple NVE Groups match based on VN and/or UN addresses,
196 the NVE is assigned to the first NVE Group listed in the configuration.
197 If an NVE is not assigned to an NVE Group, its messages will be ignored.
199 Configuration values specified for an NVE group apply to all
200 member NVEs and override configuration values specified in the VNC
203 **At least one `nve-group` is mandatory for useful VNC operation.**
205 .. index:: vnc nve-group NAME
206 .. clicmd:: vnc nve-group NAME
208 Enter VNC configuration mode for defining the NVE group `name`.
209 Use `exit` or `exit-vnc` to exit group configuration mode.
214 ... configuration commands
218 .. index:: no vnc nve-group NAME
219 .. clicmd:: no vnc nve-group NAME
221 Delete the NVE group named `name`.
223 The following statements are valid in an NVE group definition:
225 .. index:: l2rd NVE-ID-VALUE
226 .. clicmd:: l2rd NVE-ID-VALUE
228 Set the value used to distinguish NVEs connected to the same physical
229 Ethernet segment (i.e., at the same location) [#]_.
231 The nve-id subfield may be specified as either a literal value in the range
232 1-255, or it may be specified as `auto:vn`, which means to use the
233 least-significant octet of the originating NVE's VN address.
235 .. index:: prefix vn|un A.B.C.D/M|X:X::X:X/M
236 .. clicmd:: prefix vn|un A.B.C.D/M|X:X::X:X/M
238 Specify the matching prefix for this NVE group by either virtual-network
239 address (`vn`) or underlay-network address (`un`). Either or both
240 virtual-network and underlay-network prefixes may be specified. Subsequent
241 virtual-network or underlay-network values within a `vnc nve-group`
242 `exit-vnc` block override their respective previous values.
244 These prefixes are used only for determining assignments of NVEs to NVE
247 .. index:: rd ROUTE-DISTINGUISHER
248 .. clicmd:: rd ROUTE-DISTINGUISHER
250 Specify the route distinguisher for routes advertised via BGP
251 VPNs. The route distinguisher must be in one of these forms:
253 - ``IPv4-address:two-byte-integer``
254 - ``four-byte-autonomous-system-number:two-byte-integer``
255 - ``two-byte-autonomous-system-number:four-byte-integer``
256 - ``auto:vn:`two-byte-integer`
258 Routes originated by NVEs in the NVE group will use the group's specified
259 `route-distinguisher` when they are advertised via BGP. If the `auto` form
260 is specified, it means that a matching NVE has its RD set to
261 ``rd_type=IP=1:IPv4-address=VN-address:two-byte-integer``, for IPv4 VN
263 ``rd_type=IP=1`:`IPv4-address=Last-four-bytes-of-VN-address:two-byte-integer``,
264 for IPv6 VN addresses.
266 If the NVE group definition does not specify a `route-distinguisher`, then
267 the default `route-distinguisher` is used. If neither a group nor a default
268 `route-distinguisher` is configured, then the advertised RD is set to
269 ``two-byte-autonomous-system-number=0:four-byte-integer=0``.
271 .. index:: response-lifetime LIFETIME|infinite
272 .. clicmd:: response-lifetime LIFETIME|infinite
274 Specify the response lifetime, in seconds, to be included in RFP response
275 messages sent to NVEs. If the value 'infinite' is given, an infinite
276 lifetime will be used.
278 Note that this parameter is not the same as the lifetime supplied by NVEs in
279 RFP registration messages. This parameter does not affect the lifetime value
280 attached to routes sent by this server via BGP.
282 If the NVE group definition does not specify a `response-lifetime`, the
283 default `response-lifetime` will be used. If neither a group nor a default
284 `response-lifetime` is configured, the value 3600 will be used. The maximum
285 response lifetime is 2147483647.
287 .. index:: rt export RT-LIST
288 .. clicmd:: rt export RT-LIST
290 .. index:: rt import RT-LIST
291 .. clicmd:: rt import RT-LIST
293 .. index:: rt both RT-LIST
294 .. clicmd:: rt both RT-LIST
296 Specify route target import and export lists. `rt-list` is a
297 space-separated list of route targets, each element of which is
298 in one of the following forms:
300 ``IPv4-address:two-byte-integer``
301 ``four-byte-autonomous-system-number:two-byte-integer``
302 ``two-byte-autonomous-system-number:four-byte-integer``
304 The first form, `rt export`, specifies an `export rt-list`. The `export
305 rt-list` will be attached to routes originated by NVEs in the NVE group
306 when they are advertised via BGP. If the NVE group definition does not
307 specify an `export rt-list`, then the default `export rt-list` is used.
308 If neither a group nor a default `export rt-list` is configured, then no
309 RT list will be sent; in turn, these routes will probably not be
310 processed by receiving NVAs.
312 The second form, `rt import` specifies an `import rt-list`, which is a
313 filter for incoming routes. In order to be made available to NVEs in the
314 group, incoming BGP VPN and `ENCAP` `SAFI` (when `vnc advertise-un-method
315 encap-safi` is set) routes must have RT lists that have at least one
316 route target in common with the group's `import rt-list`.
318 If the NVE group definition does not specify an import filter, then the
319 default `import rt-list` is used. If neither a group nor a default
320 `import rt-list` is configured, there can be no RT intersections when
321 receiving BGP routes and therefore no incoming BGP routes will be
322 processed for the group.
324 The third, `rt both`, is a shorthand way of specifying both lists
325 simultaneously, and is equivalent to `rt export `rt-list`` followed by
326 `rt import `rt-list``.
328 .. index:: export bgp|zebra route-map MAP-NAME
329 .. clicmd:: export bgp|zebra route-map MAP-NAME
331 Specify that the named route-map should be applied to routes being exported
332 to bgp or zebra. This paramter is used in conjunction with
333 :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`. This item
336 .. index:: export bgp|zebra no route-map
337 .. clicmd:: export bgp|zebra no route-map
339 Specify that no route-map should be applied to routes being exported to bgp
340 or zebra. This paramter is used in conjunction with
341 :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`. This item
344 .. index:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
345 .. clicmd:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
347 Specify that the named prefix-list filter should be applied to routes being
348 exported to bgp or zebra. Prefix-lists for ipv4 and ipv6 are independent of
349 each other. This paramter is used in conjunction with
350 :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`. This item
353 .. index:: export bgp|zebra no ipv4|ipv6 prefix-list
354 .. clicmd:: export bgp|zebra no ipv4|ipv6 prefix-list
356 Specify that no prefix-list filter should be applied to routes being
357 exported to bgp or zebra. This parameter is used in conjunction with
358 :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`. This item
361 .. _VNC_L2_Group_Configuration:
363 VNC L2 Group Configuration
364 --------------------------
366 The route targets advertised with prefixes and addresses registered by an NVE
367 are determined based on the NVE's associated VNC NVE Group Configuration,
368 :ref:`VNC_NVE_Group_Configuration`. Layer 2 (L2) Groups are used to override
369 the route targets for an NVE's Ethernet registrations based on the Logical
370 Network Identifier and label value. A Logical Network Identifier is used to
371 uniquely identify a logical Ethernet segment and is conceptually similar to the
372 Ethernet Segment Identifier defined in :rfc:`7432`. Both the Logical Network
373 Identifier and Label are passed to VNC via RFP prefix and address registration.
375 Note that a corresponding NVE group configuration must be present, and that
376 other NVE associated configuration information, notably RD, is not impacted by
377 L2 Group Configuration.
379 .. index:: vnc l2-group NAME
380 .. clicmd:: vnc l2-group NAME
382 Enter VNC configuration mode for defining the L2 group `name`.
383 Use `exit` or `exit-vnc` to exit group configuration mode.
388 ... configuration commands
392 .. index:: no vnc l2-group NAME
393 .. clicmd:: no vnc l2-group NAME
395 Delete the L2 group named `name`.
397 The following statements are valid in a L2 group definition:
399 .. index:: logical-network-id VALUE
400 .. clicmd:: logical-network-id VALUE
402 Define the Logical Network Identifier with a value in the range of
403 0-4294967295 that identifies the logical Ethernet segment.
405 .. index:: labels LABEL-LIST
406 .. clicmd:: labels LABEL-LIST
408 .. index:: no labels LABEL-LIST
409 .. clicmd:: no labels LABEL-LIST
411 Add or remove labels associated with the group. `label-list` is a
412 space separated list of label values in the range of 0-1048575.
414 .. index:: rt import RT-TARGET
415 .. clicmd:: rt import RT-TARGET
417 .. index:: rt export RT-TARGET
418 .. clicmd:: rt export RT-TARGET
420 .. index:: rt both RT-TARGET
421 .. clicmd:: rt both RT-TARGET
423 Specify the route target import and export value associated with the group.
424 A complete definition of these parameters is given above,
425 :ref:`VNC_NVE_Group_Configuration`.
427 .. _Configuring_Redistribution_of_Routes_from_Other_Routing_Protocols:
429 Configuring Redistribution of Routes from Other Routing Protocols
430 -----------------------------------------------------------------
432 Routes from other protocols (including BGP) can be provided to VNC (both for
433 RFP and for redistribution via BGP) from three sources: the zebra kernel
434 routing process; directly from the main (default) unicast BGP RIB; or directly
435 from a designated BGP unicast exterior routing RIB instance.
437 The protocol named in the `vnc redistribute` command indicates the route
438 source: `bgp-direct` routes come directly from the main (default) unicast BGP
439 RIB and are available for RFP and are redistributed via BGP;
440 `bgp-direct-to-nve-groups` routes come directly from a designated BGP unicast
441 routing RIB and are made available only to RFP; and routes from other protocols
442 come from the zebra kernel routing process.
443 Note that the zebra process does not need to be active if
444 only `bgp-direct` or `bgp-direct-to-nve-groups` routes are used.
449 Routes originating from protocols other than BGP must be obtained
450 via the zebra routing process.
451 Redistribution of these routes into VNC does not support policy mechanisms
452 such as prefix-lists or route-maps.
457 `bgp-direct` redistribution supports policy via
458 prefix lists and route-maps. This policy is applied to incoming
459 original unicast routes before the redistribution translations
460 (described below) are performed.
462 Redistribution of `bgp-direct` routes is performed in one of three
463 possible modes: `plain`, `nve-group`, or `resolve-nve`.
464 The default mode is `plain`.
465 These modes indicate the kind of translations applied to routes before
466 they are added to the VNC RIB.
468 In `plain` mode, the route's next hop is unchanged and the RD is set
469 based on the next hop.
470 For `bgp-direct` redistribution, the following translations are performed:
472 - The VN address is set to the original unicast route's next hop address.
473 - The UN address is NOT set. (VN->UN mapping will occur via
474 ENCAP route or attribute, based on `vnc advertise-un-method`
475 setting, generated by the RFP registration of the actual NVE)
476 - The RD is set to as if auto:vn:0 were specified (i.e.,
477 `rd_type=IP=1`:`IPv4-address=VN-address`:`two-byte-integer=0`)
478 - The RT list is included in the extended community list copied from the
479 original unicast route (i.e., it must be set in the original unicast route).
481 In `nve-group` mode, routes are registered with VNC as if they came from an NVE
482 in the nve-group designated in the `vnc redistribute nve-group` command. The
483 following translations are performed:
485 - The next hop/VN address is set to the VN prefix configured for the
486 redistribute nve-group.
487 - The UN address is set to the UN prefix configured for the redistribute
489 - The RD is set to the RD configured for the redistribute nve-group.
490 - The RT list is set to the RT list configured for the redistribute nve-group.
491 If `bgp-direct` routes are being redistributed, any extended communities
492 present in the original unicast route will also be included.
494 In `resolve-nve` mode, the next hop of the original BGP route is typically the
495 address of an NVE connected router (CE) connected by one or more NVEs.
496 Each of the connected NVEs will register, via RFP, a VNC host route to the CE.
497 This mode may be though of as a mechanism to proxy RFP registrations of BGP
498 unicast routes on behalf of registering NVEs.
500 Multiple copies of the BGP route, one per matching NVE host route, will be
501 added to VNC. In other words, for a given BGP unicast route, each instance of
502 a RFP-registered host route to the unicast route's next hop will result in an
503 instance of an imported VNC route. Each such imported VNC route will have a
504 prefix equal to the original BGP unicast route's prefix, and a next hop equal
505 to the next hop of the matching RFP-registered host route. If there is no
506 RFP-registered host route to the next hop of the BGP unicast route, no
507 corresponding VNC route will be imported.
509 The following translations are applied:
511 - The Next Hop is set to the next hop of the NVE route (i.e., the
512 VN address of the NVE).
514 - The extended community list in the new route is set to the
517 - Any extended communities in the original BGP route
519 - Any extended communities in the NVE route
520 - An added route-origin extended community with the next hop of the
522 is added to the new route.
523 The value of the local administrator field defaults 5226 but may
524 be configured by the user via the `roo-ec-local-admin` parameter.
526 - The Tunnel Encapsulation attribute is set to the value of the Tunnel
527 Encapsulation attribute of the NVE route, if any.
530 bgp-direct-to-nve-groups routes
531 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
533 Unicast routes from the main or a designated instance of BGP may be
534 redistributed to VNC as bgp-direct-to-nve-groups routes. These routes are NOT
535 announced via BGP, but they are made available for local RFP lookup in response
536 to queries from NVEs.
538 A non-main/default BGP instance is configured using the `bgp multiple-instance`
539 and `router bgp AS view NAME` commands as described elsewhere in this document.
541 In order for a route in the unicast BGP RIB to be made available to a querying
542 NVE, there must already be, available to that NVE, an (interior) VNC route
543 matching the next hop address of the unicast route. When the unicast route is
544 provided to the NVE, its next hop is replaced by the next hop of the
545 corresponding NVE. If there are multiple longest-prefix-match VNC routes, the
546 unicast route will be replicated for each.
548 There is currently no policy (prefix-list or route-map) support for
549 `bgp-direct-to-nve-groups` routes.
551 Redistribution Command Syntax
552 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
554 .. index:: vnc redistribute ipv4|ipv6 bgp|bgp-direct|ipv6 bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
555 .. clicmd:: vnc redistribute ipv4|ipv6 bgp|bgp-direct|ipv6 bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
557 .. index:: vnc redistribute ipv4|ipv6 bgp-direct-to-nve-groups view VIEWNAME
558 .. clicmd:: vnc redistribute ipv4|ipv6 bgp-direct-to-nve-groups view VIEWNAME
560 .. index:: no vnc redistribute ipv4|ipv6 bgp|bgp-direct|bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
561 .. clicmd:: no vnc redistribute ipv4|ipv6 bgp|bgp-direct|bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
564 Import (or do not import) prefixes from another routing protocols. Specify
565 both the address family to import (`ipv4` or `ipv6`) and the protocol
566 (`bgp`, `bgp-direct`, `bgp-direct-to-nve-groups`, `connected`, `kernel`,
567 `ospf`, `rip`, or `static`). Repeat this statement as needed for each
568 combination of address family and routing protocol. Prefixes from protocol
569 `bgp-direct` are imported from unicast BGP in the same bgpd process.
570 Prefixes from all other protocols (including `bgp`) are imported via the
571 `zebra` kernel routing process.
573 .. index:: vnc redistribute mode plain|nve-group|resolve-nve
574 .. clicmd:: vnc redistribute mode plain|nve-group|resolve-nve
577 Redistribute routes from other protocols into VNC using the specified mode.
578 Not all combinations of modes and protocols are supported.
580 .. index:: vnc redistribute nve-group GROUP-NAME
581 .. clicmd:: vnc redistribute nve-group GROUP-NAME
583 .. index:: no vnc redistribute nve-group GROUP-NAME
584 .. clicmd:: no vnc redistribute nve-group GROUP-NAME
587 When using `nve-group` mode, assign (or do not assign) the NVE group
588 `group-name` to routes redistributed from another routing protocol.
589 `group-name` must be configured using `vnc nve-group`.
591 The VN and UN prefixes of the nve-group must both be configured, and each
592 prefix must be specified as a full-length (/32 for IPv4, /128 for IPv6)
595 .. index:: vnc redistribute lifetime LIFETIME|infinite
596 .. clicmd:: vnc redistribute lifetime LIFETIME|infinite
599 Assign a registration lifetime, either `lifetime` seconds or `infinite`, to
600 prefixes redistributed from other routing protocols as if they had been
601 received via RFP registration messages from an NVE. `lifetime` can be any
602 integer between 1 and 4294967295, inclusive.
604 .. index:: vnc redistribute resolve-nve roo-ec-local-admin 0-65536
605 .. clicmd:: vnc redistribute resolve-nve roo-ec-local-admin 0-65536
608 Assign a value to the local-administrator subfield used in the
609 Route Origin extended community that is assigned to routes exported
610 under the `resolve-nve` mode. The default value is `5226`.
612 The following four `prefix-list` and `route-map` commands may be specified
613 in the context of an nve-group or not. If they are specified in the context
614 of an nve-group, they apply only if the redistribution mode is `nve-group`,
615 and then only for routes being redistributed from `bgp-direct`. If they are
616 specified outside the context of an nve-group, then they apply only for
617 redistribution modes `plain` and `resolve-nve`, and then only for routes
618 being redistributed from `bgp-direct`.
620 .. index:: vnc redistribute bgp-direct (ipv4|ipv6) prefix-list LIST-NAME
621 .. clicmd:: vnc redistribute bgp-direct (ipv4|ipv6) prefix-list LIST-NAME
623 When redistributing `bgp-direct` routes,
624 specifies that the named prefix-list should be applied.
626 .. index:: vnc redistribute bgp-direct no (ipv4|ipv6) prefix-list
627 .. clicmd:: vnc redistribute bgp-direct no (ipv4|ipv6) prefix-list
629 When redistributing `bgp-direct` routes,
630 specifies that no prefix-list should be applied.
632 .. index:: vnc redistribute bgp-direct route-map MAP-NAME
633 .. clicmd:: vnc redistribute bgp-direct route-map MAP-NAME
635 When redistributing `bgp-direct` routes,
636 specifies that the named route-map should be applied.
638 .. index:: vnc redistribute bgp-direct no route-map
639 .. clicmd:: vnc redistribute bgp-direct no route-map
641 When redistributing `bgp-direct` routes,
642 specifies that no route-map should be applied.
644 .. _Configuring_Export_of_Routes_to_Other_Routing_Protocols:
646 Configuring Export of Routes to Other Routing Protocols
647 -------------------------------------------------------
649 Routes from VNC (both for RFP and for redistribution via BGP) can be provided
650 to other protocols, either via zebra or directly to BGP.
652 It is important to note that when exporting routes to other protocols, the
653 downstream protocol must also be configured to import the routes. For example,
654 when VNC routes are exported to unicast BGP, the BGP configuration must include
655 a corresponding `redistribute vnc-direct` statement.
657 .. index:: export bgp|zebra mode none|group-nve|registering-nve|ce
658 .. clicmd:: export bgp|zebra mode none|group-nve|registering-nve|ce
661 Specify how routes should be exported to bgp or zebra. If the mode is
662 `none`, routes are not exported. If the mode is `group-nve`, routes are
663 exported according to nve-group or vrf-policy group configuration
664 (:ref:`VNC_NVE_Group_Configuration`): if a group is configured to allow
665 export, then each prefix visible to the group is exported with next hops set
666 to the currently-registered NVEs. If the mode is `registering-nve`, then all
667 VNC routes are exported with their original next hops. If the mode is `ce`,
668 only VNC routes that have an NVE connected CE Router encoded in a Route
669 Origin Extended Community are exported. This extended community must have an
670 administrative value that matches the configured `roo-ec-local-admin` value.
671 The next hop of the exported route is set to the encoded NVE connected CE
674 The default for both bgp and zebra is mode `none`.
676 .. index:: vnc export bgp|zebra group-nve group GROUP-NAME
677 .. clicmd:: vnc export bgp|zebra group-nve group GROUP-NAME
679 .. index:: vnc export bgp|zebra group-nve no group GROUP-NAME
680 .. clicmd:: vnc export bgp|zebra group-nve no group GROUP-NAME
682 When export mode is `group-nve`, export (or do not export) prefixes from the
683 specified nve-group or vrf-policy group to unicast BGP or to zebra. Repeat
684 this statement as needed for each nve-group to be exported. Each VNC prefix
685 that is exported will result in N exported routes to the prefix, each with a
686 next hop corresponding to one of the N NVEs currently associated with the
689 .. index:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
690 .. clicmd:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
692 When export mode is `ce` or `registering-nve`,
693 specifies that the named prefix-list should be applied to routes
694 being exported to bgp or zebra.
695 Prefix-lists for ipv4 and ipv6 are independent of each other.
697 .. index:: export bgp|zebra no ipv4|ipv6 prefix-list
698 .. clicmd:: export bgp|zebra no ipv4|ipv6 prefix-list
700 When export mode is `ce` or `registering-nve`,
701 specifies that no prefix-list should be applied to routes
702 being exported to bgp or zebra.
704 .. index:: export bgp|zebra route-map MAP-NAME
705 .. clicmd:: export bgp|zebra route-map MAP-NAME
708 When export mode is `ce` or `registering-nve`, specifies that the named
709 route-map should be applied to routes being exported to bgp or zebra.
711 .. index:: export bgp|zebra no route-map
712 .. clicmd:: export bgp|zebra no route-map
714 When export mode is `ce` or `registering-nve`, specifies that no route-map
715 should be applied to routes being exported to bgp or zebra.
717 When the export mode is `group-nve`, policy for exported routes is specified
718 per-NVE-group or vrf-policy group inside a `nve-group` `RFG-NAME` block via
719 the following commands(:ref:`VNC_NVE_Group_Configuration`):
721 .. index:: export bgp|zebra route-map MAP-NAME
722 .. clicmd:: export bgp|zebra route-map MAP-NAME
724 This command is valid inside a `nve-group` `RFG-NAME` block. It specifies
725 that the named route-map should be applied to routes being exported to bgp
728 .. index:: export bgp|zebra no route-map
729 .. clicmd:: export bgp|zebra no route-map
731 This command is valid inside a `nve-group` `RFG-NAME` block. It specifies
732 that no route-map should be applied to routes being exported to bgp or
735 .. index:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
736 .. clicmd:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
738 This command is valid inside a `nve-group` `RFG-NAME` block. It specifies
739 that the named prefix-list filter should be applied to routes being exported
740 to bgp or zebra. Prefix-lists for ipv4 and ipv6 are independent of each
743 .. index:: export bgp|zebra no ipv4|ipv6 prefix-list
745 .. clicmd:: export bgp|zebra no ipv4|ipv6 prefix-list
747 This command is valid inside a `nve-group` `RFG-NAME` block. It specifies
748 that no prefix-list filter should be applied to routes being exported to
751 .. _Manual_Address_Control:
753 Manual Address Control
754 ======================
756 The commands in this section can be used to augment normal dynamic VNC. The
757 `add vnc` commands can be used to manually add IP prefix or Ethernet MAC
758 address forwarding information. The `clear vnc` commands can be used to remove
759 manually and dynamically added information.
761 .. 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)]]
763 Register an IP prefix on behalf of the NVE identified by the VN and UN
764 addresses. The `cost` parameter provides the administrative preference of
765 the forwarding information for remote advertisement. If omitted, it defaults
766 to 255 (lowest preference). The `lifetime` parameter identifies the period,
767 in seconds, that the information remains valid. If omitted, it defaults to
768 `infinite`. The optional `local-next-hop` parameter is used to configure a
769 nexthop to be used by an NVE to reach the prefix via a locally connected CE
770 router. This information remains local to the NVA, i.e., not passed to other
771 NVAs, and is only passed to registered NVEs. When specified, it is also
772 possible to provide a `local-cost` parameter to provide a forwarding
773 preference. If omitted, it defaults to 255 (lowest preference).
775 .. 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))]
777 Register a MAC address for a logical Ethernet (L2VPN) on behalf of the NVE
778 identified by the VN and UN addresses. The optional `prefix` parameter is to
779 support enable IP address mediation for the given prefix. The `cost`
780 parameter provides the administrative preference of the forwarding
781 information. If omitted, it defaults to 255. The `lifetime` parameter
782 identifies the period, in seconds, that the information remains valid. If
783 omitted, it defaults to `infinite`.
785 .. 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)])
787 Delete the information identified by prefix, VN address, and UN address.
788 Any or all of these parameters may be wilcarded to (potentially) match more
789 than one registration. The optional `mac` parameter specifies a layer-2 MAC
790 address that must match the registration(s) to be deleted. The optional
791 `local-next-hop` parameter is used to delete specific local nexthop
794 .. 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)])
795 .. 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)])
797 Delete mac forwarding information. Any or all of these parameters may be
798 wilcarded to (potentially) match more than one registration. The default
799 value for the `prefix` parameter is the wildcard value `*`.
801 .. index:: clear vnc nve (\*|((vn|un) (A.B.C.D|X:X::X:X) [(un|vn) (A.B.C.D|X:X::X:X)]))
802 .. clicmd:: clear vnc nve (\*|((vn|un) (A.B.C.D|X:X::X:X) [(un|vn) (A.B.C.D|X:X::X:X)]))
804 Delete prefixes associated with the NVE specified by the given VN and UN
805 addresses. It is permissible to specify only one of VN or UN, in which case
806 any matching registration will be deleted. It is also permissible to specify
807 `*` in lieu of any VN or UN address, in which case all registrations will
810 .. _Other_VNC-Related_Commands:
812 Other VNC-Related Commands
813 ==========================
815 Note: VNC-Related configuration can be obtained via the `show
816 running-configuration` command when in `enable` mode.
818 The following commands are used to clear and display Virtual Network Control
821 .. index:: clear vnc counters
822 .. clicmd:: clear vnc counters
824 Reset the counter values stored by the NVA. Counter
825 values can be seen using the `show vnc` commands listed above. This
826 command is only available in `enable` mode.
828 .. index:: show vnc summary
829 .. clicmd:: show vnc summary
831 Print counter values and other general information
832 about the NVA. Counter values can be reset
833 using the `clear vnc counters` command listed below.
835 .. index:: show vnc nves
836 .. clicmd:: show vnc nves
838 .. index:: show vnc nves vn|un ADDRESS
839 .. clicmd:: show vnc nves vn|un ADDRESS
841 Display the NVA's current clients. Specifying `address` limits the output to
842 the NVEs whose addresses match `address`. The time since the NVA last
843 communicated with the NVE, per-NVE summary counters and each NVE's addresses
846 .. index:: show vnc queries
847 .. clicmd:: show vnc queries
849 .. index:: show vnc queries PREFIX
850 .. clicmd:: show vnc queries PREFIX
852 Display active Query information. Queries remain valid for the default
853 Response Lifetime (:ref:`VNC_Defaults_Configuration`) or NVE-group Response
854 Lifetime (:ref:`VNC_NVE_Group_Configuration`). Specifying `prefix` limits
855 the output to Query Targets that fall within `prefix`.
857 Query information is provided for each querying NVE, and includes the Query
858 Target and the time remaining before the information is removed.
860 .. index:: show vnc registrations [all|local|remote|holddown|imported]
861 .. clicmd:: show vnc registrations [all|local|remote|holddown|imported]
863 .. index:: show vnc registrations [all|local|remote|holddown|imported] PREFIX
864 .. clicmd:: show vnc registrations [all|local|remote|holddown|imported] PREFIX
866 Display local, remote, holddown, and/or imported registration information.
867 Local registrations are routes received via RFP, which are present in the
868 NVA Registrations Cache. Remote registrations are routes received via BGP
869 (VPN SAFIs), which are present in the NVE-group import tables. Holddown
870 registrations are local and remote routes that have been withdrawn but whose
871 holddown timeouts have not yet elapsed. Imported information represents
872 routes that are imported into NVA and are made available to querying NVEs.
873 Depending on configuration, imported routes may also be advertised via BGP.
874 Specifying `prefix` limits the output to the registered prefixes that fall
877 Registration information includes the registered prefix, the registering NVE
878 addresses, the registered administrative cost, the registration lifetime and
879 the time since the information was registered or, in the case of Holddown
880 registrations, the amount of time remaining before the information is
883 .. index:: show vnc responses [active|removed]
884 .. clicmd:: show vnc responses [active|removed]
886 .. index:: show vnc responses [active|removed] PREFIX
887 .. clicmd:: show vnc responses [active|removed] PREFIX
889 Display all, active and/or removed response information which are
890 present in the NVA Responses Cache. Responses remain valid for the
891 default Response Lifetime (:ref:`VNC_Defaults_Configuration`) or
892 NVE-group Response Lifetime (:ref:`VNC_NVE_Group_Configuration`.)
893 When Removal Responses are enabled (:ref:`General_VNC_Configuration`),
894 such responses are listed for the Response Lifetime. Specifying
895 `prefix` limits the output to the addresses that fall within
898 Response information is provided for each querying NVE, and includes
899 the response prefix, the prefix-associated registering NVE addresses,
900 the administrative cost, the provided response lifetime and the time
901 remaining before the information is to be removed or will become inactive.
903 .. index:: show memory vnc
904 .. clicmd:: show memory vnc
907 Print the number of memory items allocated by the NVA.
909 .. _Example_VNC_and_VNC-GW_Configurations:
911 Example VNC and VNC-GW Configurations
912 =====================================
914 .. [#] The nve-id is carriedin the route distinguisher. It is the second octet
915 of the eight-octet route distinguisher generated for Ethernet / L2
916 advertisements. The first octet is a constant 0xFF, and the third
917 through eighth octets are set to the L2
918 ethernet address being advertised.