7 This chapter describes how to use :abbr:`VNC (Virtual Network Control)`
8 services, including :abbr:`NVA (Network Virtualization Authority)` and
9 :abbr:`VNC-GW (VNC Gateway)` functions. Background information on NVAs,
10 :abbr:`NVE (Network Virtualization Edge)` s, :abbr:`UN (Underlay Network)` s,
11 and :abbr:`VN (Virtual Network)` is available from the
12 `IETF <https://datatracker.ietf.org/wg/nvo3>`_. :abbr:`VNC-GW (VNC Gateway)` s
13 support the import/export of routing information between VNC and :abbr:`CE
14 (customer edge)` routers operating within a VN. Both IP/Layer 3 (L3) VNs, and
15 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`. Encapsulation information is provided via the Tunnel
20 Encapsulation Attribute, :rfc:`5512`.
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.
44 - :dfn:`Remote Forwarder Protocol (RFP)` configuration relates to the protocol
45 used between NVAs and NVEs.
47 - :dfn:`VNC Defaults` provides default parameters for registered NVEs.
49 - :dfn:`VNC NVE Group` provides for configuration of a specific set of
50 registered NVEs and overrides default parameters.
52 - :dfn:`Redistribution` and :dfn:`Export` control VNC-GW operation, i.e., the
53 import/export of routing information between VNC and customer edge routers
54 (:abbr:`CE` s) operating within a VN.
57 .. _general-vnc-configuration:
59 General VNC Configuration
60 -------------------------
62 .. _rfp-related-configuration:
64 RFP Related Configuration
65 -------------------------
67 The protocol that is used to communicate routing and Ethernet / L2 forwarding
68 information between NVAs and NVEs is referred to as the Remote Forwarder
69 Protocol (RFP). Currently, only a simple example RFP is included in FRR.
70 Developers may use this example as a starting point to integrate FRR with an
71 RFP of their choosing, e.g., `OpenFlow`. The example code includes the
72 following sample configuration:
74 .. clicmd:: rfp example-config-value VALUE
76 This is a simple example configuration parameter included as part of the RFP
77 example code. VALUE must be in the range of 0 to 4294967295.
79 .. _vnc-defaults-configuration:
81 VNC Defaults Configuration
82 --------------------------
84 The VNC Defaults section allows the user to specify default values for
85 configuration parameters for all registered NVEs.
86 Default values are overridden by :ref:`vnc-nve-group-configuration`.
88 .. clicmd:: vnc defaults
90 Enter VNC configuration mode for specifying VNC default behaviors. Use
91 `exit-vnc` to leave VNC configuration mode. `vnc defaults` is optional.
96 ... various VNC defaults
100 These are the statements that can appear between ``vnc defaults`` and
101 ``exit-vnc``. Documentation for these statements is given in
102 :ref:`vnc-nve-group-configuration`.
104 - :clicmd:`rt import RT-LIST`
105 - :clicmd:`rt export RT-LIST`
106 - :clicmd:`rt both RT-LIST`
107 - :clicmd:`rd ROUTE-DISTINGUISHER`
108 - :clicmd:`l2rd NVE-ID-VALUE`
109 - :clicmd:`response-lifetime LIFETIME|infinite`
110 - :clicmd:`export bgp|zebra route-map MAP-NAME`
111 - :clicmd:`export bgp|zebra no route-map`
116 Exit VNC configuration mode.
118 .. _vnc-nve-group-configuration:
120 VNC NVE Group Configuration
121 ---------------------------
123 A NVE Group corresponds to a specific set of NVEs. A Client NVE is
124 assigned to an NVE Group based on whether there is a match for either
125 its virtual or underlay network address against the VN and/or UN address
126 prefixes specified in the NVE Group definition. When an NVE Group
127 definition specifies both VN and UN address prefixes, then an NVE must
128 match both prefixes in order to be assigned to the NVE Group. In the
129 event that multiple NVE Groups match based on VN and/or UN addresses,
130 the NVE is assigned to the first NVE Group listed in the configuration.
131 If an NVE is not assigned to an NVE Group, its messages will be ignored.
133 Configuration values specified for an NVE group apply to all
134 member NVEs and override configuration values specified in the VNC
137 **At least one `nve-group` is mandatory for useful VNC operation.**
139 .. index:: vnc nve-group NAME
140 .. clicmd:: vnc nve-group NAME
142 Enter VNC configuration mode for defining the NVE group `name`.
143 Use `exit` or `exit-vnc` to exit group configuration mode.
148 ... configuration commands
152 .. index:: no vnc nve-group NAME
153 .. clicmd:: no vnc nve-group NAME
155 Delete the NVE group named `name`.
157 The following statements are valid in an NVE group definition:
159 .. index:: l2rd NVE-ID-VALUE
160 .. clicmd:: l2rd NVE-ID-VALUE
162 Set the value used to distinguish NVEs connected to the same physical
163 Ethernet segment (i.e., at the same location) [#]_.
165 The nve-id subfield may be specified as either a literal value in the range
166 1-255, or it may be specified as `auto:vn`, which means to use the
167 least-significant octet of the originating NVE's VN address.
169 .. index:: prefix vn|un A.B.C.D/M|X:X::X:X/M
170 .. clicmd:: prefix vn|un A.B.C.D/M|X:X::X:X/M
172 Specify the matching prefix for this NVE group by either virtual-network
173 address (`vn`) or underlay-network address (`un`). Either or both
174 virtual-network and underlay-network prefixes may be specified. Subsequent
175 virtual-network or underlay-network values within a `vnc nve-group`
176 `exit-vnc` block override their respective previous values.
178 These prefixes are used only for determining assignments of NVEs to NVE
181 .. index:: rd ROUTE-DISTINGUISHER
182 .. clicmd:: rd ROUTE-DISTINGUISHER
184 Specify the route distinguisher for routes advertised via BGP
185 VPNs. The route distinguisher must be in one of these forms:
187 - ``IPv4-address:two-byte-integer``
188 - ``four-byte-autonomous-system-number:two-byte-integer``
189 - ``two-byte-autonomous-system-number:four-byte-integer``
190 - ``auto:vn:two-byte-integer``
192 Routes originated by NVEs in the NVE group will use the group's specified
193 `route-distinguisher` when they are advertised via BGP. If the `auto` form
194 is specified, it means that a matching NVE has its RD set to
195 ``rd_type=IP=1:IPv4-address=VN-address:two-byte-integer``, for IPv4 VN
197 ``rd_type=IP=1:IPv4-address=Last-four-bytes-of-VN-address:two-byte-integer``,
198 for IPv6 VN addresses.
200 If the NVE group definition does not specify a `route-distinguisher`, then
201 the default `route-distinguisher` is used. If neither a group nor a default
202 `route-distinguisher` is configured, then the advertised RD is set to
203 ``two-byte-autonomous-system-number=0:four-byte-integer=0``.
205 .. index:: response-lifetime LIFETIME|infinite
206 .. clicmd:: response-lifetime LIFETIME|infinite
208 Specify the response lifetime, in seconds, to be included in RFP response
209 messages sent to NVEs. If the value 'infinite' is given, an infinite
210 lifetime will be used.
212 Note that this parameter is not the same as the lifetime supplied by NVEs in
213 RFP registration messages. This parameter does not affect the lifetime value
214 attached to routes sent by this server via BGP.
216 If the NVE group definition does not specify a `response-lifetime`, the
217 default `response-lifetime` will be used. If neither a group nor a default
218 `response-lifetime` is configured, the value 3600 will be used. The maximum
219 response lifetime is 2147483647.
221 .. index:: rt export RT-LIST
222 .. clicmd:: rt export RT-LIST
224 .. index:: rt import RT-LIST
225 .. clicmd:: rt import RT-LIST
227 .. index:: rt both RT-LIST
228 .. clicmd:: rt both RT-LIST
230 Specify route target import and export lists. `rt-list` is a
231 space-separated list of route targets, each element of which is
232 in one of the following forms:
234 - ``IPv4-address:two-byte-integer``
235 - ``four-byte-autonomous-system-number:two-byte-integer``
236 - ``two-byte-autonomous-system-number:four-byte-integer``
238 The first form, `rt export`, specifies an `export rt-list`. The `export
239 rt-list` will be attached to routes originated by NVEs in the NVE group
240 when they are advertised via BGP. If the NVE group definition does not
241 specify an `export rt-list`, then the default `export rt-list` is used.
242 If neither a group nor a default `export rt-list` is configured, then no
243 RT list will be sent; in turn, these routes will probably not be
244 processed by receiving NVAs.
246 The second form, `rt import` specifies an `import rt-list`, which is a
247 filter for incoming routes. In order to be made available to NVEs in the
248 group, incoming BGP VPN routes must have RT lists that have at least one
249 route target in common with the group's `import rt-list`.
251 If the NVE group definition does not specify an import filter, then the
252 default `import rt-list` is used. If neither a group nor a default
253 `import rt-list` is configured, there can be no RT intersections when
254 receiving BGP routes and therefore no incoming BGP routes will be
255 processed for the group.
257 The third, `rt both`, is a shorthand way of specifying both lists
258 simultaneously, and is equivalent to `rt export `rt-list`` followed by
259 `rt import `rt-list``.
261 .. index:: export bgp|zebra route-map MAP-NAME
262 .. clicmd:: export bgp|zebra route-map MAP-NAME
264 Specify that the named route-map should be applied to routes being exported
265 to bgp or zebra. This parameter is used in conjunction with
266 :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
269 .. index:: export bgp|zebra no route-map
270 .. clicmd:: export bgp|zebra no route-map
272 Specify that no route-map should be applied to routes being exported to bgp
273 or zebra. This parameter is used in conjunction with
274 :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
277 .. index:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
278 .. clicmd:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
280 Specify that the named prefix-list filter should be applied to routes being
281 exported to bgp or zebra. Prefix-lists for ipv4 and ipv6 are independent of
282 each other. This parameter is used in conjunction with
283 :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
286 .. index:: export bgp|zebra no ipv4|ipv6 prefix-list
287 .. clicmd:: export bgp|zebra no ipv4|ipv6 prefix-list
289 Specify that no prefix-list filter should be applied to routes being
290 exported to bgp or zebra. This parameter is used in conjunction with
291 :ref:`configuring-export-of-routes-to-other-routing-protocols`. This item
294 .. _vnc-l2-group-configuration:
296 VNC L2 Group Configuration
297 --------------------------
299 The route targets advertised with prefixes and addresses registered by an NVE
300 are determined based on the NVE's associated VNC NVE Group Configuration,
301 :ref:`vnc-nve-group-configuration`. Layer 2 (L2) Groups are used to override
302 the route targets for an NVE's Ethernet registrations based on the Logical
303 Network Identifier and label value. A Logical Network Identifier is used to
304 uniquely identify a logical Ethernet segment and is conceptually similar to the
305 Ethernet Segment Identifier defined in :rfc:`7432`. Both the Logical Network
306 Identifier and Label are passed to VNC via RFP prefix and address registration.
308 Note that a corresponding NVE group configuration must be present, and that
309 other NVE associated configuration information, notably RD, is not impacted by
310 L2 Group Configuration.
312 .. index:: vnc l2-group NAME
313 .. clicmd:: vnc l2-group NAME
315 Enter VNC configuration mode for defining the L2 group `name`.
316 Use `exit` or `exit-vnc` to exit group configuration mode.
321 ... configuration commands
325 .. index:: no vnc l2-group NAME
326 .. clicmd:: no vnc l2-group NAME
328 Delete the L2 group named `name`.
330 The following statements are valid in a L2 group definition:
332 .. index:: logical-network-id VALUE
333 .. clicmd:: logical-network-id VALUE
335 Define the Logical Network Identifier with a value in the range of
336 0-4294967295 that identifies the logical Ethernet segment.
338 .. index:: labels LABEL-LIST
339 .. clicmd:: labels LABEL-LIST
341 .. index:: no labels LABEL-LIST
342 .. clicmd:: no labels LABEL-LIST
344 Add or remove labels associated with the group. `label-list` is a
345 space separated list of label values in the range of 0-1048575.
347 .. index:: rt import RT-TARGET
348 .. clicmd:: rt import RT-TARGET
350 .. index:: rt export RT-TARGET
351 .. clicmd:: rt export RT-TARGET
353 .. index:: rt both RT-TARGET
354 .. clicmd:: rt both RT-TARGET
356 Specify the route target import and export value associated with the group.
357 A complete definition of these parameters is given above,
358 :ref:`vnc-nve-group-configuration`.
360 .. _configuring-redistribution-of-routes-from-other-routing-protocols:
362 Configuring Redistribution of Routes from Other Routing Protocols
363 -----------------------------------------------------------------
365 Routes from other protocols (including BGP) can be provided to VNC (both for
366 RFP and for redistribution via BGP) from three sources: the zebra kernel
367 routing process; directly from the main (default) unicast BGP RIB; or directly
368 from a designated BGP unicast exterior routing RIB instance.
370 The protocol named in the `vnc redistribute` command indicates the route
371 source: `bgp-direct` routes come directly from the main (default) unicast BGP
372 RIB and are available for RFP and are redistributed via BGP;
373 `bgp-direct-to-nve-groups` routes come directly from a designated BGP unicast
374 routing RIB and are made available only to RFP; and routes from other protocols
375 come from the zebra kernel routing process.
376 Note that the zebra process does not need to be active if
377 only `bgp-direct` or `bgp-direct-to-nve-groups` routes are used.
382 Routes originating from protocols other than BGP must be obtained
383 via the zebra routing process.
384 Redistribution of these routes into VNC does not support policy mechanisms
385 such as prefix-lists or route-maps.
390 `bgp-direct` redistribution supports policy via
391 prefix lists and route-maps. This policy is applied to incoming
392 original unicast routes before the redistribution translations
393 (described below) are performed.
395 Redistribution of `bgp-direct` routes is performed in one of three
396 possible modes: `plain`, `nve-group`, or `resolve-nve`.
397 The default mode is `plain`.
398 These modes indicate the kind of translations applied to routes before
399 they are added to the VNC RIB.
401 In `plain` mode, the route's next hop is unchanged and the RD is set
402 based on the next hop.
403 For `bgp-direct` redistribution, the following translations are performed:
405 - The VN address is set to the original unicast route's next hop address.
406 - The UN address is NOT set. (VN->UN mapping will occur via
407 ENCAP route or attribute, based on `vnc advertise-un-method`
408 setting, generated by the RFP registration of the actual NVE)
409 - The RD is set to as if auto:vn:0 were specified (i.e.,
410 `rd_type=IP=1`:`IPv4-address=VN-address`:`two-byte-integer=0`)
411 - The RT list is included in the extended community list copied from the
412 original unicast route (i.e., it must be set in the original unicast route).
414 In `nve-group` mode, routes are registered with VNC as if they came from an NVE
415 in the nve-group designated in the `vnc redistribute nve-group` command. The
416 following translations are performed:
418 - The next hop/VN address is set to the VN prefix configured for the
419 redistribute nve-group.
420 - The UN address is set to the UN prefix configured for the redistribute
422 - The RD is set to the RD configured for the redistribute nve-group.
423 - The RT list is set to the RT list configured for the redistribute nve-group.
424 If `bgp-direct` routes are being redistributed, any extended communities
425 present in the original unicast route will also be included.
427 In `resolve-nve` mode, the next hop of the original BGP route is typically the
428 address of an NVE connected router (CE) connected by one or more NVEs.
429 Each of the connected NVEs will register, via RFP, a VNC host route to the CE.
430 This mode may be though of as a mechanism to proxy RFP registrations of BGP
431 unicast routes on behalf of registering NVEs.
433 Multiple copies of the BGP route, one per matching NVE host route, will be
434 added to VNC. In other words, for a given BGP unicast route, each instance of
435 a RFP-registered host route to the unicast route's next hop will result in an
436 instance of an imported VNC route. Each such imported VNC route will have a
437 prefix equal to the original BGP unicast route's prefix, and a next hop equal
438 to the next hop of the matching RFP-registered host route. If there is no
439 RFP-registered host route to the next hop of the BGP unicast route, no
440 corresponding VNC route will be imported.
442 The following translations are applied:
444 - The Next Hop is set to the next hop of the NVE route (i.e., the
445 VN address of the NVE).
447 - The extended community list in the new route is set to the
450 - Any extended communities in the original BGP route
452 - Any extended communities in the NVE route
453 - An added route-origin extended community with the next hop of the
455 is added to the new route.
456 The value of the local administrator field defaults 5226 but may
457 be configured by the user via the `roo-ec-local-admin` parameter.
459 - The Tunnel Encapsulation attribute is set to the value of the Tunnel
460 Encapsulation attribute of the NVE route, if any.
463 bgp-direct-to-nve-groups routes
464 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
466 Unicast routes from the main or a designated instance of BGP may be
467 redistributed to VNC as bgp-direct-to-nve-groups routes. These routes are NOT
468 announced via BGP, but they are made available for local RFP lookup in response
469 to queries from NVEs.
471 A non-main/default BGP instance is configured using the `bgp multiple-instance`
472 and `router bgp AS view NAME` commands as described elsewhere in this document.
474 In order for a route in the unicast BGP RIB to be made available to a querying
475 NVE, there must already be, available to that NVE, an (interior) VNC route
476 matching the next hop address of the unicast route. When the unicast route is
477 provided to the NVE, its next hop is replaced by the next hop of the
478 corresponding NVE. If there are multiple longest-prefix-match VNC routes, the
479 unicast route will be replicated for each.
481 There is currently no policy (prefix-list or route-map) support for
482 `bgp-direct-to-nve-groups` routes.
484 Redistribution Command Syntax
485 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
487 .. index:: vnc redistribute ipv4|ipv6 bgp|bgp-direct|ipv6 bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
488 .. clicmd:: vnc redistribute ipv4|ipv6 bgp|bgp-direct|ipv6 bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
490 .. index:: vnc redistribute ipv4|ipv6 bgp-direct-to-nve-groups view VIEWNAME
491 .. clicmd:: vnc redistribute ipv4|ipv6 bgp-direct-to-nve-groups view VIEWNAME
493 .. index:: no vnc redistribute ipv4|ipv6 bgp|bgp-direct|bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
494 .. clicmd:: no vnc redistribute ipv4|ipv6 bgp|bgp-direct|bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
496 Import (or do not import) prefixes from another routing protocols. Specify
497 both the address family to import (`ipv4` or `ipv6`) and the protocol
498 (`bgp`, `bgp-direct`, `bgp-direct-to-nve-groups`, `connected`, `kernel`,
499 `ospf`, `rip`, or `static`). Repeat this statement as needed for each
500 combination of address family and routing protocol. Prefixes from protocol
501 `bgp-direct` are imported from unicast BGP in the same bgpd process.
502 Prefixes from all other protocols (including `bgp`) are imported via the
503 `zebra` kernel routing process.
505 .. index:: vnc redistribute mode plain|nve-group|resolve-nve
506 .. clicmd:: vnc redistribute mode plain|nve-group|resolve-nve
508 Redistribute routes from other protocols into VNC using the specified mode.
509 Not all combinations of modes and protocols are supported.
511 .. index:: vnc redistribute nve-group GROUP-NAME
512 .. clicmd:: vnc redistribute nve-group GROUP-NAME
514 .. index:: no vnc redistribute nve-group GROUP-NAME
515 .. clicmd:: no vnc redistribute nve-group GROUP-NAME
517 When using `nve-group` mode, assign (or do not assign) the NVE group
518 `group-name` to routes redistributed from another routing protocol.
519 `group-name` must be configured using `vnc nve-group`.
521 The VN and UN prefixes of the nve-group must both be configured, and each
522 prefix must be specified as a full-length (/32 for IPv4, /128 for IPv6)
525 .. index:: vnc redistribute lifetime LIFETIME|infinite
526 .. clicmd:: vnc redistribute lifetime LIFETIME|infinite
528 Assign a registration lifetime, either `lifetime` seconds or `infinite`, to
529 prefixes redistributed from other routing protocols as if they had been
530 received via RFP registration messages from an NVE. `lifetime` can be any
531 integer between 1 and 4294967295, inclusive.
533 .. index:: vnc redistribute resolve-nve roo-ec-local-admin 0-65536
534 .. clicmd:: vnc redistribute resolve-nve roo-ec-local-admin 0-65536
536 Assign a value to the local-administrator subfield used in the
537 Route Origin extended community that is assigned to routes exported
538 under the `resolve-nve` mode. The default value is `5226`.
540 The following four `prefix-list` and `route-map` commands may be specified
541 in the context of an nve-group or not. If they are specified in the context
542 of an nve-group, they apply only if the redistribution mode is `nve-group`,
543 and then only for routes being redistributed from `bgp-direct`. If they are
544 specified outside the context of an nve-group, then they apply only for
545 redistribution modes `plain` and `resolve-nve`, and then only for routes
546 being redistributed from `bgp-direct`.
548 .. index:: vnc redistribute bgp-direct (ipv4|ipv6) prefix-list LIST-NAME
549 .. clicmd:: vnc redistribute bgp-direct (ipv4|ipv6) prefix-list LIST-NAME
551 When redistributing `bgp-direct` routes,
552 specifies that the named prefix-list should be applied.
554 .. index:: vnc redistribute bgp-direct no (ipv4|ipv6) prefix-list
555 .. clicmd:: vnc redistribute bgp-direct no (ipv4|ipv6) prefix-list
557 When redistributing `bgp-direct` routes,
558 specifies that no prefix-list should be applied.
560 .. index:: vnc redistribute bgp-direct route-map MAP-NAME
561 .. clicmd:: vnc redistribute bgp-direct route-map MAP-NAME
563 When redistributing `bgp-direct` routes,
564 specifies that the named route-map should be applied.
566 .. index:: vnc redistribute bgp-direct no route-map
567 .. clicmd:: vnc redistribute bgp-direct no route-map
569 When redistributing `bgp-direct` routes,
570 specifies that no route-map should be applied.
572 .. _configuring-export-of-routes-to-other-routing-protocols:
574 Configuring Export of Routes to Other Routing Protocols
575 -------------------------------------------------------
577 Routes from VNC (both for RFP and for redistribution via BGP) can be provided
578 to other protocols, either via zebra or directly to BGP.
580 It is important to note that when exporting routes to other protocols, the
581 downstream protocol must also be configured to import the routes. For example,
582 when VNC routes are exported to unicast BGP, the BGP configuration must include
583 a corresponding `redistribute vnc-direct` statement.
585 .. index:: export bgp|zebra mode none|group-nve|registering-nve|ce
586 .. clicmd:: export bgp|zebra mode none|group-nve|registering-nve|ce
588 Specify how routes should be exported to bgp or zebra. If the mode is
589 `none`, routes are not exported. If the mode is `group-nve`, routes are
590 exported according to nve-group or vrf-policy group configuration
591 (:ref:`vnc-nve-group-configuration`): if a group is configured to allow
592 export, then each prefix visible to the group is exported with next hops set
593 to the currently-registered NVEs. If the mode is `registering-nve`, then all
594 VNC routes are exported with their original next hops. If the mode is `ce`,
595 only VNC routes that have an NVE connected CE Router encoded in a Route
596 Origin Extended Community are exported. This extended community must have an
597 administrative value that matches the configured `roo-ec-local-admin` value.
598 The next hop of the exported route is set to the encoded NVE connected CE
601 The default for both bgp and zebra is mode `none`.
603 .. index:: vnc export bgp|zebra group-nve group GROUP-NAME
604 .. clicmd:: vnc export bgp|zebra group-nve group GROUP-NAME
606 .. index:: vnc export bgp|zebra group-nve no group GROUP-NAME
607 .. clicmd:: vnc export bgp|zebra group-nve no group GROUP-NAME
609 When export mode is `group-nve`, export (or do not export) prefixes from the
610 specified nve-group or vrf-policy group to unicast BGP or to zebra. Repeat
611 this statement as needed for each nve-group to be exported. Each VNC prefix
612 that is exported will result in N exported routes to the prefix, each with a
613 next hop corresponding to one of the N NVEs currently associated with the
616 Some commands have a special meaning under certain export modes.
618 :clicmd:`export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME`
619 When export mode is `ce` or `registering-nve`,
620 specifies that the named prefix-list should be applied to routes
621 being exported to bgp or zebra.
622 Prefix-lists for ipv4 and ipv6 are independent of each other.
624 :clicmd:`export bgp|zebra no ipv4|ipv6 prefix-list`
625 When export mode is `ce` or `registering-nve`,
626 specifies that no prefix-list should be applied to routes
627 being exported to bgp or zebra.
629 :clicmd:`export bgp|zebra route-map MAP-NAME`
630 When export mode is `ce` or `registering-nve`, specifies that the named
631 route-map should be applied to routes being exported to bgp or zebra.
633 :clicmd:`export bgp|zebra no route-map`
634 When export mode is `ce` or `registering-nve`, specifies that no route-map
635 should be applied to routes being exported to bgp or zebra.
637 When the export mode is `group-nve`, policy for exported routes is specified
638 per-NVE-group or vrf-policy group inside a `nve-group` `RFG-NAME` block via
639 the following commands(:ref:`vnc-nve-group-configuration`):
641 :clicmd:`export bgp|zebra route-map MAP-NAME`
642 This command is valid inside a `nve-group` `RFG-NAME` block. It specifies
643 that the named route-map should be applied to routes being exported to bgp
646 :clicmd:`export bgp|zebra no route-map`
647 This command is valid inside a `nve-group` `RFG-NAME` block. It specifies
648 that no route-map should be applied to routes being exported to bgp or
651 :clicmd:`export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME`
652 This command is valid inside a `nve-group` `RFG-NAME` block. It specifies
653 that the named prefix-list filter should be applied to routes being exported
654 to bgp or zebra. Prefix-lists for ipv4 and ipv6 are independent of each
657 :clicmd:`export bgp|zebra no ipv4|ipv6 prefix-list`
658 This command is valid inside a `nve-group` `RFG-NAME` block. It specifies
659 that no prefix-list filter should be applied to routes being exported to
662 .. _manual-address-control:
664 Manual Address Control
665 ======================
667 The commands in this section can be used to augment normal dynamic VNC. The
668 `add vnc` commands can be used to manually add IP prefix or Ethernet MAC
669 address forwarding information. The `clear vnc` commands can be used to remove
670 manually and dynamically added information.
672 .. 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)]]
674 Register an IP prefix on behalf of the NVE identified by the VN and UN
675 addresses. The `cost` parameter provides the administrative preference of
676 the forwarding information for remote advertisement. If omitted, it defaults
677 to 255 (lowest preference). The `lifetime` parameter identifies the period,
678 in seconds, that the information remains valid. If omitted, it defaults to
679 `infinite`. The optional `local-next-hop` parameter is used to configure a
680 nexthop to be used by an NVE to reach the prefix via a locally connected CE
681 router. This information remains local to the NVA, i.e., not passed to other
682 NVAs, and is only passed to registered NVEs. When specified, it is also
683 possible to provide a `local-cost` parameter to provide a forwarding
684 preference. If omitted, it defaults to 255 (lowest preference).
686 .. 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))]
688 Register a MAC address for a logical Ethernet (L2VPN) on behalf of the NVE
689 identified by the VN and UN addresses. The optional `prefix` parameter is to
690 support enable IP address mediation for the given prefix. The `cost`
691 parameter provides the administrative preference of the forwarding
692 information. If omitted, it defaults to 255. The `lifetime` parameter
693 identifies the period, in seconds, that the information remains valid. If
694 omitted, it defaults to `infinite`.
696 .. 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)])
698 Delete the information identified by prefix, VN address, and UN address.
699 Any or all of these parameters may be wildcarded to (potentially) match more
700 than one registration. The optional `mac` parameter specifies a layer-2 MAC
701 address that must match the registration(s) to be deleted. The optional
702 `local-next-hop` parameter is used to delete specific local nexthop
705 .. 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)])
706 .. 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)])
708 Delete mac forwarding information. Any or all of these parameters may be
709 wildcarded to (potentially) match more than one registration. The default
710 value for the `prefix` parameter is the wildcard value `*`.
712 .. index:: clear vnc nve (\*|((vn|un) (A.B.C.D|X:X::X:X) [(un|vn) (A.B.C.D|X:X::X:X)]))
713 .. clicmd:: clear vnc nve (\*|((vn|un) (A.B.C.D|X:X::X:X) [(un|vn) (A.B.C.D|X:X::X:X)]))
715 Delete prefixes associated with the NVE specified by the given VN and UN
716 addresses. It is permissible to specify only one of VN or UN, in which case
717 any matching registration will be deleted. It is also permissible to specify
718 `*` in lieu of any VN or UN address, in which case all registrations will
721 .. _other-vnc-related-commands:
723 Other VNC-Related Commands
724 ==========================
726 Note: VNC-Related configuration can be obtained via the `show
727 running-configuration` command when in `enable` mode.
729 The following commands are used to clear and display Virtual Network Control
732 .. index:: clear vnc counters
733 .. clicmd:: clear vnc counters
735 Reset the counter values stored by the NVA. Counter
736 values can be seen using the `show vnc` commands listed above. This
737 command is only available in `enable` mode.
739 .. index:: show vnc summary
740 .. clicmd:: show vnc summary
742 Print counter values and other general information
743 about the NVA. Counter values can be reset
744 using the `clear vnc counters` command listed below.
746 .. index:: show vnc nves
747 .. clicmd:: show vnc nves
749 .. index:: show vnc nves vn|un ADDRESS
750 .. clicmd:: show vnc nves vn|un ADDRESS
752 Display the NVA's current clients. Specifying `address` limits the output to
753 the NVEs whose addresses match `address`. The time since the NVA last
754 communicated with the NVE, per-NVE summary counters and each NVE's addresses
757 .. index:: show vnc queries
758 .. clicmd:: show vnc queries
760 .. index:: show vnc queries PREFIX
761 .. clicmd:: show vnc queries PREFIX
763 Display active Query information. Queries remain valid for the default
764 Response Lifetime (:ref:`vnc-defaults-configuration`) or NVE-group Response
765 Lifetime (:ref:`vnc-nve-group-configuration`). Specifying `prefix` limits
766 the output to Query Targets that fall within `prefix`.
768 Query information is provided for each querying NVE, and includes the Query
769 Target and the time remaining before the information is removed.
771 .. index:: show vnc registrations [all|local|remote|holddown|imported]
772 .. clicmd:: show vnc registrations [all|local|remote|holddown|imported]
774 .. index:: show vnc registrations [all|local|remote|holddown|imported] PREFIX
775 .. clicmd:: show vnc registrations [all|local|remote|holddown|imported] PREFIX
777 Display local, remote, holddown, and/or imported registration information.
778 Local registrations are routes received via RFP, which are present in the
779 NVA Registrations Cache. Remote registrations are routes received via BGP
780 (VPN SAFIs), which are present in the NVE-group import tables. Holddown
781 registrations are local and remote routes that have been withdrawn but whose
782 holddown timeouts have not yet elapsed. Imported information represents
783 routes that are imported into NVA and are made available to querying NVEs.
784 Depending on configuration, imported routes may also be advertised via BGP.
785 Specifying `prefix` limits the output to the registered prefixes that fall
788 Registration information includes the registered prefix, the registering NVE
789 addresses, the registered administrative cost, the registration lifetime and
790 the time since the information was registered or, in the case of Holddown
791 registrations, the amount of time remaining before the information is
794 .. index:: show vnc responses [active|removed]
795 .. clicmd:: show vnc responses [active|removed]
797 .. index:: show vnc responses [active|removed] PREFIX
798 .. clicmd:: show vnc responses [active|removed] PREFIX
800 Display all, active and/or removed response information which are
801 present in the NVA Responses Cache. Responses remain valid for the
802 default Response Lifetime (:ref:`vnc-defaults-configuration`) or
803 NVE-group Response Lifetime (:ref:`vnc-nve-group-configuration`.)
804 When Removal Responses are enabled (:ref:`general-vnc-configuration`),
805 such responses are listed for the Response Lifetime. Specifying
806 `prefix` limits the output to the addresses that fall within
809 Response information is provided for each querying NVE, and includes
810 the response prefix, the prefix-associated registering NVE addresses,
811 the administrative cost, the provided response lifetime and the time
812 remaining before the information is to be removed or will become inactive.
814 .. index:: show memory vnc
815 .. clicmd:: show memory vnc
817 Print the number of memory items allocated by the NVA.
819 .. _example-vnc-and-vnc-gw-configurations:
821 Example VNC and VNC-GW Configurations
822 =====================================
824 .. _vnc-mesh-nva-config:
826 Mesh NVA Configuration
827 ----------------------
829 This example includes three NVAs, nine NVEs, and two NVE groups. Note that
830 while not shown, a single physical device may support multiple logical NVEs.
831 :ref:`vnc-fig-vnc-mesh` shows ``code NVA-1`` (192.168.1.100), ``NVA 2``
832 (192.168.1.101), and ``NVA 3`` (192.168.1.102), which are connected in a full
833 mesh. Each is a member of the autonomous system 64512. Each NVA provides VNC
834 services to three NVE clients in the 172.16.0.0/16 virtual-network address
835 range. The 172.16.0.0/16 address range is partitioned into two NVE groups,
836 ``group1`` (172.16.0.0/17) and ``group2`` (172.16.128.0/17).
838 Each NVE belongs to either NVE group ``group1`` or NVE group ``group2``. The
839 NVEs ``NVE 1``, ``NVE 2``, ``NVE 4``, ``NVE 7``, and ``NVE 8`` are members of
840 the NVE group ``group1``. The NVEs ``NVE 3``, ``NVE 5``, ``NVE 6``, and ``NVE
841 9`` are members of the NVE group ``group2``.
843 Each NVA advertises NVE underlay-network IP addresses using the
844 Tunnel Encapsulation Attribute.
846 .. _vnc-fig-vnc-mesh:
848 .. figure:: ../figures/fig-vnc-mesh.png
852 A three-way full mesh with three NVEs per NVA.
854 :file:`bgpd.conf` for ``NVA 1`` (192.168.1.100):
860 bgp router-id 192.168.1.100
862 neighbor 192.168.1.101 remote-as 64512
863 neighbor 192.168.1.102 remote-as 64512
865 address-family ipv4 vpn
866 neighbor 192.168.1.101 activate
867 neighbor 192.168.1.102 activate
872 response-lifetime 200
873 rt both 1000:1 1000:2
877 prefix vn 172.16.0.0/17
882 prefix vn 172.16.128.0/17
888 :file:`bgpd.conf` for ``NVA 2`` (192.168.1.101):
894 bgp router-id 192.168.1.101
896 neighbor 192.168.1.100 remote-as 64512
897 neighbor 192.168.1.102 remote-as 64512
899 address-family ipv4 vpn
900 neighbor 192.168.1.100 activate
901 neighbor 192.168.1.102 activate
905 prefix vn 172.16.0.0/17
907 response-lifetime 200
908 rt both 1000:1 1000:2
912 :file:`bgpd.conf` for ``NVA 3`` (192.168.1.102):
918 bgp router-id 192.168.1.102
920 neighbor 192.168.1.101 remote-as 64512
921 neighbor 192.168.1.102 remote-as 64512
923 address-family ipv4 vpn
924 neighbor 192.168.1.100 activate
925 neighbor 192.168.1.101 activate
930 response-lifetime 200
931 rt both 1000:1 1000:2
935 prefix vn 172.16.128.0/17
940 Mesh NVA and VNC-GW Configuration
941 ---------------------------------
943 This example includes two NVAs, each with two associated NVEs, and two VNC-GWs,
944 each supporting two CE routers physically attached to the four NVEs. Note that
945 this example is showing a more complex configuration where VNC-GW is separated
946 from normal NVA functions; it is equally possible to simplify the configuration
947 and combine NVA and VNC-GW functions in a single FRR instance.
950 .. figure:: ../figures/fig-vnc-gw.png
952 :alt: FRR VNC Gateway
954 Meshed NVEs and VNC-GWs
956 As shown in :ref:`vnc-fig-vnc-gw`, NVAs and VNC-GWs are connected in a full iBGP
957 mesh. The VNC-GWs each have two CEs configured as route-reflector clients.
958 Each client provides BGP updates with unicast routes that the VNC-GW reflects
959 to the other client. The VNC-GW also imports these unicast routes into VPN
960 routes to be shared with the other VNC-GW and the two NVAs. This route
961 importation is controlled with the ``vnc redistribute`` statements shown in the
962 configuration. Similarly, registrations sent by NVEs via RFP to the NVAs are
963 exported by the VNC-GWs to the route-reflector clients as unicast routes. RFP
964 registrations exported this way have a next-hop address of the CE behind the
965 connected (registering) NVE. Exporting VNC routes as IPv4 unicast is enabled
966 with the ``vnc export`` command below.
968 The configuration for ``VNC-GW 1`` is shown below.
973 bgp router-id 192.168.1.101
974 bgp cluster-id 1.2.3.4
975 neighbor 192.168.1.102 remote-as 64512
976 neighbor 192.168.1.103 remote-as 64512
977 neighbor 192.168.1.104 remote-as 64512
978 neighbor 172.16.1.2 remote-as 64512
979 neighbor 172.16.2.2 remote-as 64512
981 address-family ipv4 unicast
982 redistribute vnc-direct
983 no neighbor 192.168.1.102 activate
984 no neighbor 192.168.1.103 activate
985 no neighbor 192.168.1.104 activate
986 neighbor 172.16.1.2 route-reflector-client
987 neighbor 172.16.2.2 route-reflector-client
990 address-family ipv4 vpn
991 neighbor 192.168.1.102 activate
992 neighbor 192.168.1.103 activate
993 neighbor 192.168.1.104 activate
995 vnc export bgp mode ce
996 vnc redistribute mode resolve-nve
997 vnc redistribute ipv4 bgp-direct
1000 Note that in the VNC-GW configuration, the neighboring VNC-GW and NVAs each
1001 have a statement disabling the IPv4 unicast address family. IPv4 unicast is on
1002 by default and this prevents the other VNC-GW and NVAs from learning unicast
1003 routes advertised by the route-reflector clients.
1005 Configuration for ``NVA 2``:
1010 bgp router-id 192.168.1.104
1011 neighbor 192.168.1.101 remote-as 64512
1012 neighbor 192.168.1.102 remote-as 64512
1013 neighbor 192.168.1.103 remote-as 64512
1015 address-family ipv4 unicast
1016 no neighbor 192.168.1.101 activate
1017 no neighbor 192.168.1.102 activate
1018 no neighbor 192.168.1.103 activate
1021 address-family ipv4 vpn
1022 neighbor 192.168.1.101 activate
1023 neighbor 192.168.1.102 activate
1024 neighbor 192.168.1.103 activate
1028 response-lifetime 3600
1031 prefix vn 172.16.1.1/32
1032 response-lifetime 3600
1033 rt both 1000:1 1000:2
1036 prefix vn 172.16.2.1/32
1037 response-lifetime 3600
1038 rt both 1000:1 1000:2
1042 .. TBD make this its own example:
1044 .. @float Figure,fig:fig-vnc-gw-rr
1045 .. @center @image{fig-vnc-gw-rr,400pt,,FRR VNC Gateway with RR}
1047 .. An NVA can also import unicast routes from BGP without advertising the
1048 .. imported routes as VPN routes. Such imported routes, while not
1049 .. distributed to other NVAs or VNC-GWs, are are available to NVEs via
1050 .. RFP query messages sent to the NVA. @ref{fig:fig-vnc-gw-rr}
1051 .. shows an example topology where unicast routes are imported into NVAs
1052 .. from a Route Reflector. (@pxref{Route Reflector} for route reflector
1053 .. configuration details.) The following three lines can be added to the
1054 .. ``NVA 1`` and ``NVA 2`` configurations to import routes into VNC
1055 .. for local VNC use:
1058 .. neighbor 192.168.1.105 remote-as 64512
1059 .. vnc redistribute mode plain
1060 .. vnc redistribute ipv4 bgp-direct-to-nve-groups
1063 .. _vnc-with-frr-route-reflector-config:
1065 VNC with FRR Route Reflector Configuration
1066 ------------------------------------------
1068 A route reflector eliminates the need for a fully meshed NVA network by acting
1069 as the hub between NVAs. :ref:`vnc-fig-vnc-frr-route-reflector` shows BGP
1070 route reflector ``BGP Route Reflector 1`` (192.168.1.100) as a route reflector
1071 for NVAs ``NVA 2``(192.168.1.101) and ``NVA 3`` (192.168.1.102).
1073 .. _vnc-fig-vnc-frr-route-reflector:
1074 .. figure:: ../figures/fig-vnc-frr-route-reflector.png
1076 :alt: FRR Route Reflector
1078 Two NVAs and a BGP Route Reflector
1080 ``NVA 2`` and ``NVA 3`` advertise NVE underlay-network IP addresses using the
1081 Tunnel Encapsulation Attribute. ``BGP Route Reflector 1`` ``reflects''
1082 advertisements from ``NVA 2`` to ``NVA 3`` and vice versa.
1084 As in the example of :ref:`vnc-mesh-nva-config`, there are two NVE groups. The
1085 172.16.0.0/16 address range is partitioned into two NVE groups, ``group1``
1086 (172.16.0.0/17) and ``group2`` (172.16.128.0/17). The NVE ``NVE 4``, ``NVE
1087 7``, and ``NVE 8`` are members of the NVE group ``group1``. The NVEs ``NVE
1088 5``, ``NVE 6``, and ``NVE 9`` are members of the NVE group ``group2``.
1090 :file:`bgpd.conf` for ``BGP Route Reflector 1`` on 192.168.1.100:
1096 bgp router-id 192.168.1.100
1098 neighbor 192.168.1.101 remote-as 64512
1099 neighbor 192.168.1.101 port 7179
1100 neighbor 192.168.1.101 description iBGP-client-192-168-1-101
1102 neighbor 192.168.1.102 remote-as 64512
1103 neighbor 192.168.1.102 port 7179
1104 neighbor 192.168.1.102 description iBGP-client-192-168-1-102
1106 address-family ipv4 unicast
1107 neighbor 192.168.1.101 route-reflector-client
1108 neighbor 192.168.1.102 route-reflector-client
1111 address-family ipv4 vpn
1112 neighbor 192.168.1.101 activate
1113 neighbor 192.168.1.102 activate
1115 neighbor 192.168.1.101 route-reflector-client
1116 neighbor 192.168.1.102 route-reflector-client
1121 :file:`bgpd.conf` for ``NVA 2`` on 192.168.1.101:
1127 bgp router-id 192.168.1.101
1129 neighbor 192.168.1.100 remote-as 64512
1131 address-family ipv4 vpn
1132 neighbor 192.168.1.100 activate
1135 vnc nve-group group1
1136 prefix vn 172.16.0.0/17
1138 response-lifetime 200
1139 rt both 1000:1 1000:2
1143 :file:`bgpd.conf` for ``NVA 2`` on 192.168.1.102:
1149 bgp router-id 192.168.1.102
1151 neighbor 192.168.1.100 remote-as 64512
1153 address-family ipv4 vpn
1154 neighbor 192.168.1.100 activate
1159 response-lifetime 200
1160 rt both 1000:1 1000:2
1163 vnc nve-group group1
1164 prefix vn 172.16.128.0/17
1168 While not shown, an NVA can also be configured as a route reflector.
1170 .. _vnc-with-commercial-route-reflector-config:
1172 VNC with Commercial Route Reflector Configuration
1173 -------------------------------------------------
1175 This example is identical to :ref:`vnc-with-frr-route-reflector-config`
1176 with the exception that the route reflector is a commercial router. Only the
1177 VNC-relevant configuration is provided.
1179 .. figure:: ../figures/fig-vnc-commercial-route-reflector.png
1181 :alt: Commercial Route Reflector
1183 Two NVAs with a commercial route reflector
1185 :file:`bgpd.conf` for BGP route reflector ``Commercial Router`` on 192.168.1.104:::
1191 route 172.16.0.0/16 next-hop 192.168.1.104;
1194 autonomous-system 64512;
1197 resolution-ribs inet.0;
1200 resolution-ribs inet.0;
1221 cluster 192.168.1.104;
1222 neighbor 192.168.1.101;
1223 neighbor 192.168.1.102;
1228 policy-statement h {
1231 as-path-prepend 64512;
1237 :file:`bgpd.conf` for ``NVA 2`` on 192.168.1.101:
1243 bgp router-id 192.168.1.101
1245 neighbor 192.168.1.100 remote-as 64512
1247 address-family ipv4 vpn
1248 neighbor 192.168.1.100 activate
1251 vnc nve-group group1
1252 prefix vn 172.16.0.0/17
1254 response-lifetime 200
1255 rt both 1000:1 1000:2
1259 :file:`bgpd.conf` for ``NVA 3`` on 192.168.1.102:
1265 bgp router-id 192.168.1.102
1267 neighbor 192.168.1.100 remote-as 64512
1269 address-family ipv4 vpn
1270 neighbor 192.168.1.100 activate
1275 response-lifetime 200
1276 rt both 1000:1 1000:2
1279 vnc nve-group group1
1280 prefix vn 172.16.128.0/17
1284 VNC with Redundant Route Reflectors Configuration
1285 -------------------------------------------------
1287 This example combines the previous two
1288 (:ref:`vnc-with-frr-route-reflector-config` and
1289 :ref:`vnc-with-commercial-route-reflector-config`) into a redundant route
1290 reflector configuration. BGP route reflectors ``BGP Route Reflector 1`` and
1291 ``Commercial Router`` are the route reflectors for NVAs ``NVA 2`` and ``NVA
1292 3``. The two NVAs have connections to both route reflectors.
1294 .. figure:: ../figures/fig-vnc-redundant-route-reflectors.png
1296 :alt: Redundant Route Reflectors
1298 FRR-based NVA with redundant route reflectors
1300 :file:`bgpd.conf` for ``BPGD Route Reflector 1`` on 192.168.1.100:
1306 bgp router-id 192.168.1.100
1307 bgp cluster-id 192.168.1.100
1309 neighbor 192.168.1.104 remote-as 64512
1311 neighbor 192.168.1.101 remote-as 64512
1312 neighbor 192.168.1.101 description iBGP-client-192-168-1-101
1313 neighbor 192.168.1.101 route-reflector-client
1315 neighbor 192.168.1.102 remote-as 64512
1316 neighbor 192.168.1.102 description iBGP-client-192-168-1-102
1317 neighbor 192.168.1.102 route-reflector-client
1319 address-family ipv4 vpn
1320 neighbor 192.168.1.101 activate
1321 neighbor 192.168.1.102 activate
1322 neighbor 192.168.1.104 activate
1324 neighbor 192.168.1.101 route-reflector-client
1325 neighbor 192.168.1.102 route-reflector-client
1329 :file:`bgpd.conf` for ``NVA 2`` on 192.168.1.101:
1335 bgp router-id 192.168.1.101
1337 neighbor 192.168.1.100 remote-as 64512
1338 neighbor 192.168.1.104 remote-as 64512
1340 address-family ipv4 vpn
1341 neighbor 192.168.1.100 activate
1342 neighbor 192.168.1.104 activate
1345 vnc nve-group group1
1346 prefix vn 172.16.0.0/17
1348 response-lifetime 200
1349 rt both 1000:1 1000:2
1353 :file:`bgpd.conf` for ``NVA 3`` on 192.168.1.102:
1359 bgp router-id 192.168.1.102
1361 neighbor 192.168.1.100 remote-as 64512
1362 neighbor 192.168.1.104 remote-as 64512
1364 address-family ipv4 vpn
1365 neighbor 192.168.1.100 activate
1366 neighbor 192.168.1.104 activate
1371 response-lifetime 200
1372 rt both 1000:1 1000:2
1375 vnc nve-group group1
1376 prefix vn 172.16.128.0/17
1380 :file:`bgpd.conf` for the Commercial Router route reflector on 192.168.1.104:::
1385 route 172.16.0.0/16 next-hop 192.168.1.104;
1388 autonomous-system 64512;
1391 resolution-ribs inet.0;
1394 resolution-ribs inet.0;
1415 cluster 192.168.1.104;
1416 neighbor 192.168.1.101;
1417 neighbor 192.168.1.102;
1431 neighbor 192.168.1.100;
1437 policy-statement h {
1440 as-path-prepend 64512;
1446 .. [#] The nve-id is carried in the route distinguisher. It is the second octet
1447 of the eight-octet route distinguisher generated for Ethernet / L2
1448 advertisements. The first octet is a constant 0xFF, and the third
1449 through eighth octets are set to the L2
1450 ethernet address being advertised.