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`. 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
103 .. index:: rt import RT-LIST
104 .. clicmd:: rt import RT-LIST
106 .. index:: rt export RT-LIST
107 .. clicmd:: rt export RT-LIST
109 .. index:: rt both RT-LIST
110 .. clicmd:: rt both RT-LIST
112 Specify default route target import and export lists. `rt-list` is a
113 space-separated list of route targets, each element of which is
114 in one of the following forms:
116 - ``IPv4-address:two-byte-integer``
117 - ``four-byte-autonomous-system-number:two-byte-integer``
118 - ``two-byte-autonomous-system-number:four-byte-integer``
120 If no default import RT list is specified, then the default import RT list
121 is empty. If no default export RT list is specified, then the default export
124 A complete definition of these parameters is given below
125 (:ref:`VNC_NVE_Group_Configuration`).
127 .. index:: rd route-distinguisher
128 .. clicmd:: rd ROUTE-DISTINGUISHER
130 Specify the default route distinguisher (RD) for routes advertised via BGP
131 VPNs. The route distinguisher must be in one of four forms:
133 - ``IPv4-address:two-byte-integer``
134 - ``four-byte-autonomous-system-number:two-byte-integer``
135 - ``two-byte-autonomous-system-number:four-byte-integer``
136 - ``auto:vn:two-byte-integer``
138 If RD is specified in the defaults section, the default RD value is
139 `two-byte-autonomous-system-number=0:four-byte-integer=0`.
141 A complete definition of this parameter is given below
142 (:ref:`VNC_NVE_Group_Configuration`).
144 .. index:: l2rd NVE-ID-VALUE
145 .. clicmd:: l2rd NVE-ID-VALUE
147 Set the value used to distinguish NVEs connected to the same logical
148 Ethernet segment (i.e., L2VPN). A complete definition of this parameter is
149 given below (:ref:`VNC_NVE_Group_Configuration`).
151 .. index:: response-lifetime LIFETIME|infinite
152 .. clicmd:: response-lifetime LIFETIME|infinite
154 Specify the default lifetime to be included in RFP response messages sent to
157 A complete definition of this parameter is given below
158 (:ref:`VNC_NVE_Group_Configuration`).
160 .. index:: export bgp|zebra route-map MAP-NAME
161 .. clicmd:: export bgp|zebra route-map MAP-NAME
163 Specify that the named route-map should be applied to routes being exported
166 .. index:: export bgp|zebra no route-map
167 .. clicmd:: export bgp|zebra no route-map
169 Specify that no route-map should be applied to routes being exported to bgp
175 Exit VNC configuration mode.
177 .. _VNC_NVE_Group_Configuration:
179 VNC NVE Group Configuration
180 ---------------------------
182 A NVE Group corresponds to a specific set of NVEs. A Client NVE is
183 assigned to an NVE Group based on whether there is a match for either
184 its virtual or underlay network address against the VN and/or UN address
185 prefixes specified in the NVE Group definition. When an NVE Group
186 definition specifies both VN and UN address prefixes, then an NVE must
187 match both prefixes in order to be assigned to the NVE Group. In the
188 event that multiple NVE Groups match based on VN and/or UN addresses,
189 the NVE is assigned to the first NVE Group listed in the configuration.
190 If an NVE is not assigned to an NVE Group, its messages will be ignored.
192 Configuration values specified for an NVE group apply to all
193 member NVEs and override configuration values specified in the VNC
196 **At least one `nve-group` is mandatory for useful VNC operation.**
198 .. index:: vnc nve-group NAME
199 .. clicmd:: vnc nve-group NAME
201 Enter VNC configuration mode for defining the NVE group `name`.
202 Use `exit` or `exit-vnc` to exit group configuration mode.
207 ... configuration commands
211 .. index:: no vnc nve-group NAME
212 .. clicmd:: no vnc nve-group NAME
214 Delete the NVE group named `name`.
216 The following statements are valid in an NVE group definition:
218 .. index:: l2rd NVE-ID-VALUE
219 .. clicmd:: l2rd NVE-ID-VALUE
221 Set the value used to distinguish NVEs connected to the same physical
222 Ethernet segment (i.e., at the same location) [#]_.
224 The nve-id subfield may be specified as either a literal value in the range
225 1-255, or it may be specified as `auto:vn`, which means to use the
226 least-significant octet of the originating NVE's VN address.
228 .. index:: prefix vn|un A.B.C.D/M|X:X::X:X/M
229 .. clicmd:: prefix vn|un A.B.C.D/M|X:X::X:X/M
231 Specify the matching prefix for this NVE group by either virtual-network
232 address (`vn`) or underlay-network address (`un`). Either or both
233 virtual-network and underlay-network prefixes may be specified. Subsequent
234 virtual-network or underlay-network values within a `vnc nve-group`
235 `exit-vnc` block override their respective previous values.
237 These prefixes are used only for determining assignments of NVEs to NVE
240 .. index:: rd ROUTE-DISTINGUISHER
241 .. clicmd:: rd ROUTE-DISTINGUISHER
243 Specify the route distinguisher for routes advertised via BGP
244 VPNs. The route distinguisher must be in one of these forms:
246 - ``IPv4-address:two-byte-integer``
247 - ``four-byte-autonomous-system-number:two-byte-integer``
248 - ``two-byte-autonomous-system-number:four-byte-integer``
249 - ``auto:vn:`two-byte-integer`
251 Routes originated by NVEs in the NVE group will use the group's specified
252 `route-distinguisher` when they are advertised via BGP. If the `auto` form
253 is specified, it means that a matching NVE has its RD set to
254 ``rd_type=IP=1:IPv4-address=VN-address:two-byte-integer``, for IPv4 VN
256 ``rd_type=IP=1:IPv4-address=Last-four-bytes-of-VN-address:two-byte-integer``,
257 for IPv6 VN addresses.
259 If the NVE group definition does not specify a `route-distinguisher`, then
260 the default `route-distinguisher` is used. If neither a group nor a default
261 `route-distinguisher` is configured, then the advertised RD is set to
262 ``two-byte-autonomous-system-number=0:four-byte-integer=0``.
264 .. index:: response-lifetime LIFETIME|infinite
265 .. clicmd:: response-lifetime LIFETIME|infinite
267 Specify the response lifetime, in seconds, to be included in RFP response
268 messages sent to NVEs. If the value 'infinite' is given, an infinite
269 lifetime will be used.
271 Note that this parameter is not the same as the lifetime supplied by NVEs in
272 RFP registration messages. This parameter does not affect the lifetime value
273 attached to routes sent by this server via BGP.
275 If the NVE group definition does not specify a `response-lifetime`, the
276 default `response-lifetime` will be used. If neither a group nor a default
277 `response-lifetime` is configured, the value 3600 will be used. The maximum
278 response lifetime is 2147483647.
280 .. index:: rt export RT-LIST
281 .. clicmd:: rt export RT-LIST
283 .. index:: rt import RT-LIST
284 .. clicmd:: rt import RT-LIST
286 .. index:: rt both RT-LIST
287 .. clicmd:: rt both RT-LIST
289 Specify route target import and export lists. `rt-list` is a
290 space-separated list of route targets, each element of which is
291 in one of the following forms:
293 - ``IPv4-address:two-byte-integer``
294 - ``four-byte-autonomous-system-number:two-byte-integer``
295 - ``two-byte-autonomous-system-number:four-byte-integer``
297 The first form, `rt export`, specifies an `export rt-list`. The `export
298 rt-list` will be attached to routes originated by NVEs in the NVE group
299 when they are advertised via BGP. If the NVE group definition does not
300 specify an `export rt-list`, then the default `export rt-list` is used.
301 If neither a group nor a default `export rt-list` is configured, then no
302 RT list will be sent; in turn, these routes will probably not be
303 processed by receiving NVAs.
305 The second form, `rt import` specifies an `import rt-list`, which is a
306 filter for incoming routes. In order to be made available to NVEs in the
307 group, incoming BGP VPN routes must have RT lists that have at least one
308 route target in common with the group's `import rt-list`.
310 If the NVE group definition does not specify an import filter, then the
311 default `import rt-list` is used. If neither a group nor a default
312 `import rt-list` is configured, there can be no RT intersections when
313 receiving BGP routes and therefore no incoming BGP routes will be
314 processed for the group.
316 The third, `rt both`, is a shorthand way of specifying both lists
317 simultaneously, and is equivalent to `rt export `rt-list`` followed by
318 `rt import `rt-list``.
320 .. index:: export bgp|zebra route-map MAP-NAME
321 .. clicmd:: export bgp|zebra route-map MAP-NAME
323 Specify that the named route-map should be applied to routes being exported
324 to bgp or zebra. This paramter is used in conjunction with
325 :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`. This item
328 .. index:: export bgp|zebra no route-map
329 .. clicmd:: export bgp|zebra no route-map
331 Specify that no route-map should be applied to routes being exported to bgp
332 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 ipv4|ipv6 prefix-list LIST-NAME
337 .. clicmd:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
339 Specify that the named prefix-list filter should be applied to routes being
340 exported to bgp or zebra. Prefix-lists for ipv4 and ipv6 are independent of
341 each other. This paramter is used in conjunction with
342 :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`. This item
345 .. index:: export bgp|zebra no ipv4|ipv6 prefix-list
346 .. clicmd:: export bgp|zebra no ipv4|ipv6 prefix-list
348 Specify that no prefix-list filter should be applied to routes being
349 exported to bgp or zebra. This parameter is used in conjunction with
350 :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`. This item
353 .. _VNC_L2_Group_Configuration:
355 VNC L2 Group Configuration
356 --------------------------
358 The route targets advertised with prefixes and addresses registered by an NVE
359 are determined based on the NVE's associated VNC NVE Group Configuration,
360 :ref:`VNC_NVE_Group_Configuration`. Layer 2 (L2) Groups are used to override
361 the route targets for an NVE's Ethernet registrations based on the Logical
362 Network Identifier and label value. A Logical Network Identifier is used to
363 uniquely identify a logical Ethernet segment and is conceptually similar to the
364 Ethernet Segment Identifier defined in :rfc:`7432`. Both the Logical Network
365 Identifier and Label are passed to VNC via RFP prefix and address registration.
367 Note that a corresponding NVE group configuration must be present, and that
368 other NVE associated configuration information, notably RD, is not impacted by
369 L2 Group Configuration.
371 .. index:: vnc l2-group NAME
372 .. clicmd:: vnc l2-group NAME
374 Enter VNC configuration mode for defining the L2 group `name`.
375 Use `exit` or `exit-vnc` to exit group configuration mode.
380 ... configuration commands
384 .. index:: no vnc l2-group NAME
385 .. clicmd:: no vnc l2-group NAME
387 Delete the L2 group named `name`.
389 The following statements are valid in a L2 group definition:
391 .. index:: logical-network-id VALUE
392 .. clicmd:: logical-network-id VALUE
394 Define the Logical Network Identifier with a value in the range of
395 0-4294967295 that identifies the logical Ethernet segment.
397 .. index:: labels LABEL-LIST
398 .. clicmd:: labels LABEL-LIST
400 .. index:: no labels LABEL-LIST
401 .. clicmd:: no labels LABEL-LIST
403 Add or remove labels associated with the group. `label-list` is a
404 space separated list of label values in the range of 0-1048575.
406 .. index:: rt import RT-TARGET
407 .. clicmd:: rt import RT-TARGET
409 .. index:: rt export RT-TARGET
410 .. clicmd:: rt export RT-TARGET
412 .. index:: rt both RT-TARGET
413 .. clicmd:: rt both RT-TARGET
415 Specify the route target import and export value associated with the group.
416 A complete definition of these parameters is given above,
417 :ref:`VNC_NVE_Group_Configuration`.
419 .. _Configuring_Redistribution_of_Routes_from_Other_Routing_Protocols:
421 Configuring Redistribution of Routes from Other Routing Protocols
422 -----------------------------------------------------------------
424 Routes from other protocols (including BGP) can be provided to VNC (both for
425 RFP and for redistribution via BGP) from three sources: the zebra kernel
426 routing process; directly from the main (default) unicast BGP RIB; or directly
427 from a designated BGP unicast exterior routing RIB instance.
429 The protocol named in the `vnc redistribute` command indicates the route
430 source: `bgp-direct` routes come directly from the main (default) unicast BGP
431 RIB and are available for RFP and are redistributed via BGP;
432 `bgp-direct-to-nve-groups` routes come directly from a designated BGP unicast
433 routing RIB and are made available only to RFP; and routes from other protocols
434 come from the zebra kernel routing process.
435 Note that the zebra process does not need to be active if
436 only `bgp-direct` or `bgp-direct-to-nve-groups` routes are used.
441 Routes originating from protocols other than BGP must be obtained
442 via the zebra routing process.
443 Redistribution of these routes into VNC does not support policy mechanisms
444 such as prefix-lists or route-maps.
449 `bgp-direct` redistribution supports policy via
450 prefix lists and route-maps. This policy is applied to incoming
451 original unicast routes before the redistribution translations
452 (described below) are performed.
454 Redistribution of `bgp-direct` routes is performed in one of three
455 possible modes: `plain`, `nve-group`, or `resolve-nve`.
456 The default mode is `plain`.
457 These modes indicate the kind of translations applied to routes before
458 they are added to the VNC RIB.
460 In `plain` mode, the route's next hop is unchanged and the RD is set
461 based on the next hop.
462 For `bgp-direct` redistribution, the following translations are performed:
464 - The VN address is set to the original unicast route's next hop address.
465 - The UN address is NOT set. (VN->UN mapping will occur via
466 ENCAP route or attribute, based on `vnc advertise-un-method`
467 setting, generated by the RFP registration of the actual NVE)
468 - The RD is set to as if auto:vn:0 were specified (i.e.,
469 `rd_type=IP=1`:`IPv4-address=VN-address`:`two-byte-integer=0`)
470 - The RT list is included in the extended community list copied from the
471 original unicast route (i.e., it must be set in the original unicast route).
473 In `nve-group` mode, routes are registered with VNC as if they came from an NVE
474 in the nve-group designated in the `vnc redistribute nve-group` command. The
475 following translations are performed:
477 - The next hop/VN address is set to the VN prefix configured for the
478 redistribute nve-group.
479 - The UN address is set to the UN prefix configured for the redistribute
481 - The RD is set to the RD configured for the redistribute nve-group.
482 - The RT list is set to the RT list configured for the redistribute nve-group.
483 If `bgp-direct` routes are being redistributed, any extended communities
484 present in the original unicast route will also be included.
486 In `resolve-nve` mode, the next hop of the original BGP route is typically the
487 address of an NVE connected router (CE) connected by one or more NVEs.
488 Each of the connected NVEs will register, via RFP, a VNC host route to the CE.
489 This mode may be though of as a mechanism to proxy RFP registrations of BGP
490 unicast routes on behalf of registering NVEs.
492 Multiple copies of the BGP route, one per matching NVE host route, will be
493 added to VNC. In other words, for a given BGP unicast route, each instance of
494 a RFP-registered host route to the unicast route's next hop will result in an
495 instance of an imported VNC route. Each such imported VNC route will have a
496 prefix equal to the original BGP unicast route's prefix, and a next hop equal
497 to the next hop of the matching RFP-registered host route. If there is no
498 RFP-registered host route to the next hop of the BGP unicast route, no
499 corresponding VNC route will be imported.
501 The following translations are applied:
503 - The Next Hop is set to the next hop of the NVE route (i.e., the
504 VN address of the NVE).
506 - The extended community list in the new route is set to the
509 - Any extended communities in the original BGP route
511 - Any extended communities in the NVE route
512 - An added route-origin extended community with the next hop of the
514 is added to the new route.
515 The value of the local administrator field defaults 5226 but may
516 be configured by the user via the `roo-ec-local-admin` parameter.
518 - The Tunnel Encapsulation attribute is set to the value of the Tunnel
519 Encapsulation attribute of the NVE route, if any.
522 bgp-direct-to-nve-groups routes
523 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
525 Unicast routes from the main or a designated instance of BGP may be
526 redistributed to VNC as bgp-direct-to-nve-groups routes. These routes are NOT
527 announced via BGP, but they are made available for local RFP lookup in response
528 to queries from NVEs.
530 A non-main/default BGP instance is configured using the `bgp multiple-instance`
531 and `router bgp AS view NAME` commands as described elsewhere in this document.
533 In order for a route in the unicast BGP RIB to be made available to a querying
534 NVE, there must already be, available to that NVE, an (interior) VNC route
535 matching the next hop address of the unicast route. When the unicast route is
536 provided to the NVE, its next hop is replaced by the next hop of the
537 corresponding NVE. If there are multiple longest-prefix-match VNC routes, the
538 unicast route will be replicated for each.
540 There is currently no policy (prefix-list or route-map) support for
541 `bgp-direct-to-nve-groups` routes.
543 Redistribution Command Syntax
544 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
546 .. index:: vnc redistribute ipv4|ipv6 bgp|bgp-direct|ipv6 bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
547 .. clicmd:: vnc redistribute ipv4|ipv6 bgp|bgp-direct|ipv6 bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
549 .. index:: vnc redistribute ipv4|ipv6 bgp-direct-to-nve-groups view VIEWNAME
550 .. clicmd:: vnc redistribute ipv4|ipv6 bgp-direct-to-nve-groups view VIEWNAME
552 .. index:: no vnc redistribute ipv4|ipv6 bgp|bgp-direct|bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
553 .. clicmd:: no vnc redistribute ipv4|ipv6 bgp|bgp-direct|bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static
555 Import (or do not import) prefixes from another routing protocols. Specify
556 both the address family to import (`ipv4` or `ipv6`) and the protocol
557 (`bgp`, `bgp-direct`, `bgp-direct-to-nve-groups`, `connected`, `kernel`,
558 `ospf`, `rip`, or `static`). Repeat this statement as needed for each
559 combination of address family and routing protocol. Prefixes from protocol
560 `bgp-direct` are imported from unicast BGP in the same bgpd process.
561 Prefixes from all other protocols (including `bgp`) are imported via the
562 `zebra` kernel routing process.
564 .. index:: vnc redistribute mode plain|nve-group|resolve-nve
565 .. clicmd:: vnc redistribute mode plain|nve-group|resolve-nve
567 Redistribute routes from other protocols into VNC using the specified mode.
568 Not all combinations of modes and protocols are supported.
570 .. index:: vnc redistribute nve-group GROUP-NAME
571 .. clicmd:: vnc redistribute nve-group GROUP-NAME
573 .. index:: no vnc redistribute nve-group GROUP-NAME
574 .. clicmd:: no vnc redistribute nve-group GROUP-NAME
576 When using `nve-group` mode, assign (or do not assign) the NVE group
577 `group-name` to routes redistributed from another routing protocol.
578 `group-name` must be configured using `vnc nve-group`.
580 The VN and UN prefixes of the nve-group must both be configured, and each
581 prefix must be specified as a full-length (/32 for IPv4, /128 for IPv6)
584 .. index:: vnc redistribute lifetime LIFETIME|infinite
585 .. clicmd:: vnc redistribute lifetime LIFETIME|infinite
587 Assign a registration lifetime, either `lifetime` seconds or `infinite`, to
588 prefixes redistributed from other routing protocols as if they had been
589 received via RFP registration messages from an NVE. `lifetime` can be any
590 integer between 1 and 4294967295, inclusive.
592 .. index:: vnc redistribute resolve-nve roo-ec-local-admin 0-65536
593 .. clicmd:: vnc redistribute resolve-nve roo-ec-local-admin 0-65536
595 Assign a value to the local-administrator subfield used in the
596 Route Origin extended community that is assigned to routes exported
597 under the `resolve-nve` mode. The default value is `5226`.
599 The following four `prefix-list` and `route-map` commands may be specified
600 in the context of an nve-group or not. If they are specified in the context
601 of an nve-group, they apply only if the redistribution mode is `nve-group`,
602 and then only for routes being redistributed from `bgp-direct`. If they are
603 specified outside the context of an nve-group, then they apply only for
604 redistribution modes `plain` and `resolve-nve`, and then only for routes
605 being redistributed from `bgp-direct`.
607 .. index:: vnc redistribute bgp-direct (ipv4|ipv6) prefix-list LIST-NAME
608 .. clicmd:: vnc redistribute bgp-direct (ipv4|ipv6) prefix-list LIST-NAME
610 When redistributing `bgp-direct` routes,
611 specifies that the named prefix-list should be applied.
613 .. index:: vnc redistribute bgp-direct no (ipv4|ipv6) prefix-list
614 .. clicmd:: vnc redistribute bgp-direct no (ipv4|ipv6) prefix-list
616 When redistributing `bgp-direct` routes,
617 specifies that no prefix-list should be applied.
619 .. index:: vnc redistribute bgp-direct route-map MAP-NAME
620 .. clicmd:: vnc redistribute bgp-direct route-map MAP-NAME
622 When redistributing `bgp-direct` routes,
623 specifies that the named route-map should be applied.
625 .. index:: vnc redistribute bgp-direct no route-map
626 .. clicmd:: vnc redistribute bgp-direct no route-map
628 When redistributing `bgp-direct` routes,
629 specifies that no route-map should be applied.
631 .. _Configuring_Export_of_Routes_to_Other_Routing_Protocols:
633 Configuring Export of Routes to Other Routing Protocols
634 -------------------------------------------------------
636 Routes from VNC (both for RFP and for redistribution via BGP) can be provided
637 to other protocols, either via zebra or directly to BGP.
639 It is important to note that when exporting routes to other protocols, the
640 downstream protocol must also be configured to import the routes. For example,
641 when VNC routes are exported to unicast BGP, the BGP configuration must include
642 a corresponding `redistribute vnc-direct` statement.
644 .. index:: export bgp|zebra mode none|group-nve|registering-nve|ce
645 .. clicmd:: export bgp|zebra mode none|group-nve|registering-nve|ce
647 Specify how routes should be exported to bgp or zebra. If the mode is
648 `none`, routes are not exported. If the mode is `group-nve`, routes are
649 exported according to nve-group or vrf-policy group configuration
650 (:ref:`VNC_NVE_Group_Configuration`): if a group is configured to allow
651 export, then each prefix visible to the group is exported with next hops set
652 to the currently-registered NVEs. If the mode is `registering-nve`, then all
653 VNC routes are exported with their original next hops. If the mode is `ce`,
654 only VNC routes that have an NVE connected CE Router encoded in a Route
655 Origin Extended Community are exported. This extended community must have an
656 administrative value that matches the configured `roo-ec-local-admin` value.
657 The next hop of the exported route is set to the encoded NVE connected CE
660 The default for both bgp and zebra is mode `none`.
662 .. index:: vnc export bgp|zebra group-nve group GROUP-NAME
663 .. clicmd:: vnc export bgp|zebra group-nve group GROUP-NAME
665 .. index:: vnc export bgp|zebra group-nve no group GROUP-NAME
666 .. clicmd:: vnc export bgp|zebra group-nve no group GROUP-NAME
668 When export mode is `group-nve`, export (or do not export) prefixes from the
669 specified nve-group or vrf-policy group to unicast BGP or to zebra. Repeat
670 this statement as needed for each nve-group to be exported. Each VNC prefix
671 that is exported will result in N exported routes to the prefix, each with a
672 next hop corresponding to one of the N NVEs currently associated with the
675 .. index:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
676 .. clicmd:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
678 When export mode is `ce` or `registering-nve`,
679 specifies that the named prefix-list should be applied to routes
680 being exported to bgp or zebra.
681 Prefix-lists for ipv4 and ipv6 are independent of each other.
683 .. index:: export bgp|zebra no ipv4|ipv6 prefix-list
684 .. clicmd:: export bgp|zebra no ipv4|ipv6 prefix-list
686 When export mode is `ce` or `registering-nve`,
687 specifies that no prefix-list should be applied to routes
688 being exported to bgp or zebra.
690 .. index:: export bgp|zebra route-map MAP-NAME
691 .. clicmd:: export bgp|zebra route-map MAP-NAME
693 When export mode is `ce` or `registering-nve`, specifies that the named
694 route-map should be applied to routes being exported to bgp or zebra.
696 .. index:: export bgp|zebra no route-map
697 .. clicmd:: export bgp|zebra no route-map
699 When export mode is `ce` or `registering-nve`, specifies that no route-map
700 should be applied to routes being exported to bgp or zebra.
702 When the export mode is `group-nve`, policy for exported routes is specified
703 per-NVE-group or vrf-policy group inside a `nve-group` `RFG-NAME` block via
704 the following commands(:ref:`VNC_NVE_Group_Configuration`):
706 .. index:: export bgp|zebra route-map MAP-NAME
707 .. clicmd:: export bgp|zebra route-map MAP-NAME
709 This command is valid inside a `nve-group` `RFG-NAME` block. It specifies
710 that the named route-map should be applied to routes being exported to bgp
713 .. index:: export bgp|zebra no route-map
714 .. clicmd:: export bgp|zebra no route-map
716 This command is valid inside a `nve-group` `RFG-NAME` block. It specifies
717 that no route-map should be applied to routes being exported to bgp or
720 .. index:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
721 .. clicmd:: export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME
723 This command is valid inside a `nve-group` `RFG-NAME` block. It specifies
724 that the named prefix-list filter should be applied to routes being exported
725 to bgp or zebra. Prefix-lists for ipv4 and ipv6 are independent of each
728 .. index:: export bgp|zebra no ipv4|ipv6 prefix-list
730 .. clicmd:: export bgp|zebra no ipv4|ipv6 prefix-list
732 This command is valid inside a `nve-group` `RFG-NAME` block. It specifies
733 that no prefix-list filter should be applied to routes being exported to
736 .. _Manual_Address_Control:
738 Manual Address Control
739 ======================
741 The commands in this section can be used to augment normal dynamic VNC. The
742 `add vnc` commands can be used to manually add IP prefix or Ethernet MAC
743 address forwarding information. The `clear vnc` commands can be used to remove
744 manually and dynamically added information.
746 .. 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)]]
748 Register an IP prefix on behalf of the NVE identified by the VN and UN
749 addresses. The `cost` parameter provides the administrative preference of
750 the forwarding information for remote advertisement. If omitted, it defaults
751 to 255 (lowest preference). The `lifetime` parameter identifies the period,
752 in seconds, that the information remains valid. If omitted, it defaults to
753 `infinite`. The optional `local-next-hop` parameter is used to configure a
754 nexthop to be used by an NVE to reach the prefix via a locally connected CE
755 router. This information remains local to the NVA, i.e., not passed to other
756 NVAs, and is only passed to registered NVEs. When specified, it is also
757 possible to provide a `local-cost` parameter to provide a forwarding
758 preference. If omitted, it defaults to 255 (lowest preference).
760 .. 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))]
762 Register a MAC address for a logical Ethernet (L2VPN) on behalf of the NVE
763 identified by the VN and UN addresses. The optional `prefix` parameter is to
764 support enable IP address mediation for the given prefix. The `cost`
765 parameter provides the administrative preference of the forwarding
766 information. If omitted, it defaults to 255. The `lifetime` parameter
767 identifies the period, in seconds, that the information remains valid. If
768 omitted, it defaults to `infinite`.
770 .. 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)])
772 Delete the information identified by prefix, VN address, and UN address.
773 Any or all of these parameters may be wilcarded to (potentially) match more
774 than one registration. The optional `mac` parameter specifies a layer-2 MAC
775 address that must match the registration(s) to be deleted. The optional
776 `local-next-hop` parameter is used to delete specific local nexthop
779 .. 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)])
780 .. 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)])
782 Delete mac forwarding information. Any or all of these parameters may be
783 wilcarded to (potentially) match more than one registration. The default
784 value for the `prefix` parameter is the wildcard value `*`.
786 .. index:: clear vnc nve (\*|((vn|un) (A.B.C.D|X:X::X:X) [(un|vn) (A.B.C.D|X:X::X:X)]))
787 .. clicmd:: clear vnc nve (\*|((vn|un) (A.B.C.D|X:X::X:X) [(un|vn) (A.B.C.D|X:X::X:X)]))
789 Delete prefixes associated with the NVE specified by the given VN and UN
790 addresses. It is permissible to specify only one of VN or UN, in which case
791 any matching registration will be deleted. It is also permissible to specify
792 `*` in lieu of any VN or UN address, in which case all registrations will
795 .. _Other_VNC-Related_Commands:
797 Other VNC-Related Commands
798 ==========================
800 Note: VNC-Related configuration can be obtained via the `show
801 running-configuration` command when in `enable` mode.
803 The following commands are used to clear and display Virtual Network Control
806 .. index:: clear vnc counters
807 .. clicmd:: clear vnc counters
809 Reset the counter values stored by the NVA. Counter
810 values can be seen using the `show vnc` commands listed above. This
811 command is only available in `enable` mode.
813 .. index:: show vnc summary
814 .. clicmd:: show vnc summary
816 Print counter values and other general information
817 about the NVA. Counter values can be reset
818 using the `clear vnc counters` command listed below.
820 .. index:: show vnc nves
821 .. clicmd:: show vnc nves
823 .. index:: show vnc nves vn|un ADDRESS
824 .. clicmd:: show vnc nves vn|un ADDRESS
826 Display the NVA's current clients. Specifying `address` limits the output to
827 the NVEs whose addresses match `address`. The time since the NVA last
828 communicated with the NVE, per-NVE summary counters and each NVE's addresses
831 .. index:: show vnc queries
832 .. clicmd:: show vnc queries
834 .. index:: show vnc queries PREFIX
835 .. clicmd:: show vnc queries PREFIX
837 Display active Query information. Queries remain valid for the default
838 Response Lifetime (:ref:`VNC_Defaults_Configuration`) or NVE-group Response
839 Lifetime (:ref:`VNC_NVE_Group_Configuration`). Specifying `prefix` limits
840 the output to Query Targets that fall within `prefix`.
842 Query information is provided for each querying NVE, and includes the Query
843 Target and the time remaining before the information is removed.
845 .. index:: show vnc registrations [all|local|remote|holddown|imported]
846 .. clicmd:: show vnc registrations [all|local|remote|holddown|imported]
848 .. index:: show vnc registrations [all|local|remote|holddown|imported] PREFIX
849 .. clicmd:: show vnc registrations [all|local|remote|holddown|imported] PREFIX
851 Display local, remote, holddown, and/or imported registration information.
852 Local registrations are routes received via RFP, which are present in the
853 NVA Registrations Cache. Remote registrations are routes received via BGP
854 (VPN SAFIs), which are present in the NVE-group import tables. Holddown
855 registrations are local and remote routes that have been withdrawn but whose
856 holddown timeouts have not yet elapsed. Imported information represents
857 routes that are imported into NVA and are made available to querying NVEs.
858 Depending on configuration, imported routes may also be advertised via BGP.
859 Specifying `prefix` limits the output to the registered prefixes that fall
862 Registration information includes the registered prefix, the registering NVE
863 addresses, the registered administrative cost, the registration lifetime and
864 the time since the information was registered or, in the case of Holddown
865 registrations, the amount of time remaining before the information is
868 .. index:: show vnc responses [active|removed]
869 .. clicmd:: show vnc responses [active|removed]
871 .. index:: show vnc responses [active|removed] PREFIX
872 .. clicmd:: show vnc responses [active|removed] PREFIX
874 Display all, active and/or removed response information which are
875 present in the NVA Responses Cache. Responses remain valid for the
876 default Response Lifetime (:ref:`VNC_Defaults_Configuration`) or
877 NVE-group Response Lifetime (:ref:`VNC_NVE_Group_Configuration`.)
878 When Removal Responses are enabled (:ref:`General_VNC_Configuration`),
879 such responses are listed for the Response Lifetime. Specifying
880 `prefix` limits the output to the addresses that fall within
883 Response information is provided for each querying NVE, and includes
884 the response prefix, the prefix-associated registering NVE addresses,
885 the administrative cost, the provided response lifetime and the time
886 remaining before the information is to be removed or will become inactive.
888 .. index:: show memory vnc
889 .. clicmd:: show memory vnc
891 Print the number of memory items allocated by the NVA.
893 .. _Example_VNC_and_VNC-GW_Configurations:
895 Example VNC and VNC-GW Configurations
896 =====================================
898 .. _vnc-mesh-nva-config:
900 Mesh NVA Configuration
901 ----------------------
903 This example includes three NVAs, nine NVEs, and two NVE groups. Note that
904 while not shown, a single physical device may support multiple logical NVEs.
905 :figure:`fig-vnc-mesh` shows ``code NVA-1`` (192.168.1.100), ``NVA 2``
906 (192.168.1.101), and ``NVA 3`` (192.168.1.102), which are connected in a full
907 mesh. Each is a member of the autonomous system 64512. Each NVA provides VNC
908 services to three NVE clients in the 172.16.0.0/16 virtual-network address
909 range. The 172.16.0.0/16 address range is partitioned into two NVE groups,
910 ``group1`` (172.16.0.0/17) and ``group2`` (172.16.128.0/17).
912 Each NVE belongs to either NVE group ``group1`` or NVE group
913 ``group2``. The NVEs ``NVE 1``, ``NVE 2``, @code{NVE
914 4}, ``NVE 7``, and ``NVE 8`` are members of the NVE group
915 ``group1``. The NVEs ``NVE 3``, ``NVE 5``, @code{NVE
916 6}, and ``NVE 9`` are members of the NVE group ``group2``.
918 Each NVA advertises NVE underlay-network IP addresses using the
919 Tunnel Encapsulation Attribute.
921 .. _vnc-fig-vnc-mesh:
922 .. figure:: ../figure/fig-vnc-mesh.png
926 A three-way full mesh with three NVEs per NVA.
928 :file:`bgpd.conf` for ``NVA 1`` (192.168.1.100):::
932 bgp router-id 192.168.1.100
934 neighbor 192.168.1.101 remote-as 64512
935 neighbor 192.168.1.102 remote-as 64512
937 address-family ipv4 vpn
938 neighbor 192.168.1.101 activate
939 neighbor 192.168.1.102 activate
944 response-lifetime 200
945 rt both 1000:1 1000:2
949 prefix vn 172.16.0.0/17
954 prefix vn 172.16.128.0/17
960 :file:`bgpd.conf` for ``NVA 2`` (192.168.1.101):::
964 bgp router-id 192.168.1.101
966 neighbor 192.168.1.100 remote-as 64512
967 neighbor 192.168.1.102 remote-as 64512
969 address-family ipv4 vpn
970 neighbor 192.168.1.100 activate
971 neighbor 192.168.1.102 activate
975 prefix vn 172.16.0.0/17
977 response-lifetime 200
978 rt both 1000:1 1000:2
982 :file:`bgpd.conf` for ``NVA 3`` (192.168.1.102):::
986 bgp router-id 192.168.1.102
988 neighbor 192.168.1.101 remote-as 64512
989 neighbor 192.168.1.102 remote-as 64512
991 address-family ipv4 vpn
992 neighbor 192.168.1.100 activate
993 neighbor 192.168.1.101 activate
998 response-lifetime 200
999 rt both 1000:1 1000:2
1002 vnc nve-group group1
1003 prefix vn 172.16.128.0/17
1008 Mesh NVA and VNC-GW Configuration
1009 ---------------------------------
1011 This example includes two NVAs, each with two associated NVEs, and two VNC-GWs,
1012 each supporting two CE routers physically attached to the four NVEs. Note that
1013 this example is showing a more complex configuration where VNC-GW is separated
1014 from normal NVA functions; it is equally possible to simplify the configuration
1015 and combine NVA and VNC-GW functions in a single FRR instance.
1018 .. figure:: ../figures/fig-vnc-gw.png
1020 :alt: FRR VNC Gateway
1022 Meshed NVEs and VNC-GWs
1024 As shown in :figure:`fig-vnc-gw`, NVAs and VNC-GWs are connected in a full iBGP
1025 mesh. The VNC-GWs each have two CEs configured as route-reflector clients.
1026 Each client provides BGP updates with unicast routes that the VNC-GW reflects
1027 to the other client. The VNC-GW also imports these unicast routes into VPN
1028 routes to be shared with the other VNC-GW and the two NVAs. This route
1029 importation is controlled with the ``vnc redistribute`` statements shown in the
1030 configuration. Similarly, registrations sent by NVEs via RFP to the NVAs are
1031 exported by the VNC-GWs to the route-reflector clients as unicast routes. RFP
1032 registrations exported this way have a next-hop address of the CE behind the
1033 connected (registering) NVE. Exporting VNC routes as IPv4 unicast is enabled
1034 with the ``vnc export`` command below.
1036 The configuration for ``VNC-GW 1`` is shown below.::
1039 bgp router-id 192.168.1.101
1040 bgp cluster-id 1.2.3.4
1041 neighbor 192.168.1.102 remote-as 64512
1042 neighbor 192.168.1.103 remote-as 64512
1043 neighbor 192.168.1.104 remote-as 64512
1044 neighbor 172.16.1.2 remote-as 64512
1045 neighbor 172.16.2.2 remote-as 64512
1047 address-family ipv4 unicast
1048 redistribute vnc-direct
1049 no neighbor 192.168.1.102 activate
1050 no neighbor 192.168.1.103 activate
1051 no neighbor 192.168.1.104 activate
1052 neighbor 172.16.1.2 route-reflector-client
1053 neighbor 172.16.2.2 route-reflector-client
1056 address-family ipv4 vpn
1057 neighbor 192.168.1.102 activate
1058 neighbor 192.168.1.103 activate
1059 neighbor 192.168.1.104 activate
1061 vnc export bgp mode ce
1062 vnc redistribute mode resolve-nve
1063 vnc redistribute ipv4 bgp-direct
1066 Note that in the VNC-GW configuration, the neighboring VNC-GW and NVAs each
1067 have a statement disabling the IPv4 unicast address family. IPv4 unicast is on
1068 by default and this prevents the other VNC-GW and NVAs from learning unicast
1069 routes advertised by the route-reflector clients.
1071 Configuration for ``NVA 2``:::
1074 bgp router-id 192.168.1.104
1075 neighbor 192.168.1.101 remote-as 64512
1076 neighbor 192.168.1.102 remote-as 64512
1077 neighbor 192.168.1.103 remote-as 64512
1079 address-family ipv4 unicast
1080 no neighbor 192.168.1.101 activate
1081 no neighbor 192.168.1.102 activate
1082 no neighbor 192.168.1.103 activate
1085 address-family ipv4 vpn
1086 neighbor 192.168.1.101 activate
1087 neighbor 192.168.1.102 activate
1088 neighbor 192.168.1.103 activate
1092 response-lifetime 3600
1095 prefix vn 172.16.1.1/32
1096 response-lifetime 3600
1097 rt both 1000:1 1000:2
1100 prefix vn 172.16.2.1/32
1101 response-lifetime 3600
1102 rt both 1000:1 1000:2
1106 .. TBD make this its own example:
1108 .. @float Figure,fig:fig-vnc-gw-rr
1109 .. @center @image{fig-vnc-gw-rr,400pt,,Frr VNC Gateway with RR}
1111 .. An NVA can also import unicast routes from BGP without advertising the
1112 .. imported routes as VPN routes. Such imported routes, while not
1113 .. distributed to other NVAs or VNC-GWs, are are available to NVEs via
1114 .. RFP query messages sent to the NVA. @ref{fig:fig-vnc-gw-rr}
1115 .. shows an example topology where unicast routes are imported into NVAs
1116 .. from a Route Reflector. (@pxref{Route Reflector} for route reflector
1117 .. configuration details.) The following three lines can be added to the
1118 .. ``NVA 1`` and ``NVA 2`` configurations to import routes into VNC
1119 .. for local VNC use:
1122 .. neighbor 192.168.1.105 remote-as 64512
1123 .. vnc redistribute mode plain
1124 .. vnc redistribute ipv4 bgp-direct-to-nve-groups
1127 .. _vnc-with-frr-route-reflector-config:
1129 VNC with FRR Route Reflector Configuration
1130 ------------------------------------------
1132 A route reflector eliminates the need for a fully meshed NVA network by acting
1133 as the hub between NVAs. :figure:`vnc-fig-vnc-frr-route-reflector` shows BGP
1134 route reflector ``BGP Route Reflector 1`` (192.168.1.100) as a route reflector
1135 for NVAs ``NVA 2``(192.168.1.101) and ``NVA 3`` (192.168.1.102).
1137 @float Figure,fig:fig-vnc-frr-route-reflector @center
1138 @image{fig-vnc-frr-route-reflector,400pt,,Frr Route Reflector} @caption{Two
1139 NVAs and a BGP Route Reflector} @end float
1141 .. _vnc-fig-vnc-frr-route-reflector:
1142 .. figure:: ../figures/fig-vnc-frr-route-reflector.png
1144 :alt: FRR Route Reflector
1146 Two NVAs and a BGP Route Reflector
1148 ``NVA 2`` and ``NVA 3`` advertise NVE underlay-network IP addresses using the
1149 Tunnel Encapsulation Attribute. ``BGP Route Reflector 1`` ``reflects''
1150 advertisements from ``NVA 2`` to ``NVA 3`` and vice versa.
1152 As in the example of :ref:`vnc-mesh-nva-config`, there are two NVE groups. The
1153 172.16.0.0/16 address range is partitioned into two NVE groups, ``group1``
1154 (172.16.0.0/17) and ``group2`` (172.16.128.0/17). The NVE ``NVE 4``, ``NVE
1155 7``, and ``NVE 8`` are members of the NVE group ``group1``. The NVEs ``NVE
1156 5``, ``NVE 6``, and ``NVE 9`` are members of the NVE group ``group2``.
1158 :file:`bgpd.conf` for ``BGP Route Reflector 1`` on 192.168.1.100:::
1162 bgp router-id 192.168.1.100
1164 neighbor 192.168.1.101 remote-as 64512
1165 neighbor 192.168.1.101 port 7179
1166 neighbor 192.168.1.101 description iBGP-client-192-168-1-101
1168 neighbor 192.168.1.102 remote-as 64512
1169 neighbor 192.168.1.102 port 7179
1170 neighbor 192.168.1.102 description iBGP-client-192-168-1-102
1172 address-family ipv4 unicast
1173 neighbor 192.168.1.101 route-reflector-client
1174 neighbor 192.168.1.102 route-reflector-client
1177 address-family ipv4 vpn
1178 neighbor 192.168.1.101 activate
1179 neighbor 192.168.1.102 activate
1181 neighbor 192.168.1.101 route-reflector-client
1182 neighbor 192.168.1.102 route-reflector-client
1187 :file:`bgpd.conf` for ``NVA 2`` on 192.168.1.101:::
1191 bgp router-id 192.168.1.101
1193 neighbor 192.168.1.100 remote-as 64512
1195 address-family ipv4 vpn
1196 neighbor 192.168.1.100 activate
1199 vnc nve-group group1
1200 prefix vn 172.16.0.0/17
1202 response-lifetime 200
1203 rt both 1000:1 1000:2
1207 :file:`bgpd.conf` for ``NVA 2`` on 192.168.1.102:::
1211 bgp router-id 192.168.1.102
1213 neighbor 192.168.1.100 remote-as 64512
1215 address-family ipv4 vpn
1216 neighbor 192.168.1.100 activate
1221 response-lifetime 200
1222 rt both 1000:1 1000:2
1225 vnc nve-group group1
1226 prefix vn 172.16.128.0/17
1230 While not shown, an NVA can also be configured as a route reflector.
1232 .. _vnc-with-commercial-route-reflector-config:
1234 VNC with Commercial Route Reflector Configuration
1235 -------------------------------------------------
1237 This example is identical to :ref:`vnc-with-frr-route-reflector-configuration`
1238 with the exception that the route reflector is a commercial router. Only the
1239 VNC-relevant configuration is provided.
1241 .. figure:: ../figures/fig-vnc-commercial-route-reflector
1243 :alt: Commercial Route Reflector
1245 Two NVAs with a commercial route reflector
1247 :file:`bgpd.conf` for BGP route reflector ``Commercial Router`` on 192.168.1.104:::
1253 route 172.16.0.0/16 next-hop 192.168.1.104;
1256 autonomous-system 64512;
1259 resolution-ribs inet.0;
1262 resolution-ribs inet.0;
1283 cluster 192.168.1.104;
1284 neighbor 192.168.1.101;
1285 neighbor 192.168.1.102;
1290 policy-statement h {
1293 as-path-prepend 64512;
1299 :file:`bgpd.conf` for ``NVA 2`` on 192.168.1.101:::
1303 bgp router-id 192.168.1.101
1305 neighbor 192.168.1.100 remote-as 64512
1307 address-family ipv4 vpn
1308 neighbor 192.168.1.100 activate
1311 vnc nve-group group1
1312 prefix vn 172.16.0.0/17
1314 response-lifetime 200
1315 rt both 1000:1 1000:2
1319 :file:`bgpd.conf` for ``NVA 3`` on 192.168.1.102:::
1323 bgp router-id 192.168.1.102
1325 neighbor 192.168.1.100 remote-as 64512
1327 address-family ipv4 vpn
1328 neighbor 192.168.1.100 activate
1333 response-lifetime 200
1334 rt both 1000:1 1000:2
1337 vnc nve-group group1
1338 prefix vn 172.16.128.0/17
1342 VNC with Redundant Route Reflectors Configuration
1343 -------------------------------------------------
1345 This example combines the previous two
1346 (:ref:`vnc-with-frr-route-reflector-config` and
1347 :ref:`vnc-with-commercial-route-reflector-config`) into a redundant route
1348 reflector configuration. BGP route reflectors ``BGP Route Reflector 1`` and
1349 ``Commercial Router`` are the route reflectors for NVAs ``NVA 2`` and ``NVA
1350 3``. The two NVAs have connections to both route reflectors.
1352 .. figure:: ../fig-vnc-redundant-route-reflectors.png
1354 :alt: Redundant Route Reflectors
1356 FRR-based NVA with redundant route reflectors
1358 :file:`bgpd.conf` for ``Bgpd Route Reflector 1`` on 192.168.1.100:::
1362 bgp router-id 192.168.1.100
1363 bgp cluster-id 192.168.1.100
1365 neighbor 192.168.1.104 remote-as 64512
1367 neighbor 192.168.1.101 remote-as 64512
1368 neighbor 192.168.1.101 description iBGP-client-192-168-1-101
1369 neighbor 192.168.1.101 route-reflector-client
1371 neighbor 192.168.1.102 remote-as 64512
1372 neighbor 192.168.1.102 description iBGP-client-192-168-1-102
1373 neighbor 192.168.1.102 route-reflector-client
1375 address-family ipv4 vpn
1376 neighbor 192.168.1.101 activate
1377 neighbor 192.168.1.102 activate
1378 neighbor 192.168.1.104 activate
1380 neighbor 192.168.1.101 route-reflector-client
1381 neighbor 192.168.1.102 route-reflector-client
1385 :file:`bgpd.conf` for ``NVA 2`` on 192.168.1.101:::
1389 bgp router-id 192.168.1.101
1391 neighbor 192.168.1.100 remote-as 64512
1392 neighbor 192.168.1.104 remote-as 64512
1394 address-family ipv4 vpn
1395 neighbor 192.168.1.100 activate
1396 neighbor 192.168.1.104 activate
1399 vnc nve-group group1
1400 prefix vn 172.16.0.0/17
1402 response-lifetime 200
1403 rt both 1000:1 1000:2
1407 :file:`bgpd.conf` for ``NVA 3`` on 192.168.1.102:::
1411 bgp router-id 192.168.1.102
1413 neighbor 192.168.1.100 remote-as 64512
1414 neighbor 192.168.1.104 remote-as 64512
1416 address-family ipv4 vpn
1417 neighbor 192.168.1.100 activate
1418 neighbor 192.168.1.104 activate
1423 response-lifetime 200
1424 rt both 1000:1 1000:2
1427 vnc nve-group group1
1428 prefix vn 172.16.128.0/17
1432 :file:`bgpd.conf` for the Commercial Router route reflector on 192.168.1.104:::
1437 route 172.16.0.0/16 next-hop 192.168.1.104;
1440 autonomous-system 64512;
1443 resolution-ribs inet.0;
1446 resolution-ribs inet.0;
1467 cluster 192.168.1.104;
1468 neighbor 192.168.1.101;
1469 neighbor 192.168.1.102;
1483 neighbor 192.168.1.100;
1489 policy-statement h {
1492 as-path-prepend 64512;
1498 .. [#] The nve-id is carriedin the route distinguisher. It is the second octet
1499 of the eight-octet route distinguisher generated for Ethernet / L2
1500 advertisements. The first octet is a constant 0xFF, and the third
1501 through eighth octets are set to the L2
1502 ethernet address being advertised.