]>
Commit | Line | Data |
---|---|---|
42fc5d26 QY |
1 | .. _VNC_and_VNC-GW: |
2 | ||
3 | ************** | |
4 | VNC and VNC-GW | |
5 | ************** | |
6 | ||
7 | This chapter describes how to use | |
8 | Virtual Network Control (@acronym{VNC}) services, | |
9 | including Network Virtualization Authority (@acronym{NVA}) and | |
10 | VNC Gateway (@acronym{VNC-GW}) functions. | |
11 | Background information on NVAs, | |
12 | Network Virtualization Edges (@acronym{NVE}s), underlay networks (@acronym{UN}s), | |
13 | and virtual networks (@acronym{VN}s) is available from the | |
14 | `https://datatracker.ietf.org/wg/nvo3,IETF Network Virtualization Overlays (@acronym{NVO3 <https://datatracker.ietf.org/wg/nvo3,IETF Network Virtualization Overlays (@acronym{NVO3>`_) Working Group}. | |
15 | VNC Gateways (@acronym{VNC-GW}s) support the import/export of routing | |
16 | information between VNC and customer edge routers (@acronym{CE}s) | |
17 | operating within a VN. Both IP/Layer 3 (L3) VNs, and IP with | |
18 | Ethernet/Layer 2 (L2) VNs are supported. | |
19 | ||
20 | BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VN | |
21 | information between NVAs. BGP based IP VPN support is defined in | |
22 | @cite{RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs)}, and | |
23 | @cite{RFC4659, BGP-MPLS IP Virtual Private Network (VPN) Extension for | |
24 | IPv6 VPN }. Both the Encapsulation Subsequent Address Family Identifier | |
25 | (SAFI) and the Tunnel Encapsulation Attribute, @cite{RFC5512, The BGP | |
26 | Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP | |
27 | Tunnel Encapsulation Attribute}, are supported. | |
28 | ||
29 | The protocol that is used to communicate routing and Ethernet / Layer 2 | |
30 | (L2) forwarding information between NVAs and NVEs is referred to as the | |
31 | Remote Forwarder Protocol (RFP). `OpenFlow` is an example | |
32 | RFP. Specific RFP implementations may choose to implement either a | |
33 | `hard-state` or `soft-state` prefix and address registration | |
34 | model. To support a `soft-state` refresh model, a `lifetime` | |
35 | in seconds is associated with all registrations and responses. | |
36 | ||
37 | The chapter also provides sample configurations for basic example scenarios. | |
38 | ||
39 | .. _Configuring_VNC: | |
40 | ||
41 | Configuring VNC | |
42 | =============== | |
43 | ||
44 | Virtual Network Control (@acronym{VNC}) service configuration commands | |
45 | appear in the `router bgp` section of the BGPD configuration file | |
46 | (:ref:`BGP_Configuration_Examples`). The commands are broken down into | |
47 | the following areas: | |
48 | ||
49 | `General VNC` configuration applies to general VNC operation and is | |
50 | primarily used to control the method used to advertise tunnel | |
51 | information. | |
52 | ||
53 | `Remote Forwarder Protocol (RFP)` configuration relates to the | |
54 | protocol used between NVAs and NVEs. | |
55 | ||
56 | `VNC Defaults` provides default parameters for registered NVEs. | |
57 | ||
58 | `VNC NVE Group` provides for configuration of a specific set of | |
59 | registered NVEs and overrides default parameters. | |
60 | ||
61 | `Redistribution` and `Export` control VNC-GW operation, i.e., | |
62 | the import/export of routing | |
63 | information between VNC and customer edge routers (@acronym{CE}s) | |
64 | operating within a VN. | |
65 | ||
66 | .. _General_VNC_Configuration: | |
67 | ||
68 | General VNC Configuration | |
69 | ------------------------- | |
70 | ||
71 | .. index:: {VNC} {vnc advertise-un-method encap-safi|encap-attr} {} | |
72 | ||
73 | {VNC} {vnc advertise-un-method encap-safi|encap-attr} {} | |
74 | Advertise NVE underlay-network IP addresses using the encapsulation SAFI | |
75 | (`encap-safi`) or the UN address sub-TLV of the Tunnel Encapsulation attribute | |
76 | (`encap-attr`). When `encap-safi` is used, neighbors under | |
77 | `address-family encap` and/or `address-family encapv6` must be | |
78 | configured. The default is `encap-attr`. | |
79 | ||
80 | .. _RFP_Related_Configuration: | |
81 | ||
82 | RFP Related Configuration | |
83 | ------------------------- | |
84 | ||
85 | The protocol that is used to communicate routing and Ethernet / L2 | |
86 | forwarding information between NVAs and NVEs is referred to as the | |
87 | Remote Forwarder Protocol (RFP). Currently, only a simple example RFP | |
88 | is included in Frr. Developers may use this example as a starting | |
89 | point to integrate Frr with an RFP of their choosing, e.g., | |
90 | `OpenFlow`. The example code includes the following sample | |
91 | configuration: | |
92 | ||
93 | .. index:: {RFP} {rfp example-config-value `VALUE`} | |
94 | ||
95 | {RFP} {rfp example-config-value `VALUE`} | |
96 | This is a simple example configuration parameter included as part of the | |
97 | RFP example code. `VALUE` must be in the range of 0 to 4294967295. | |
98 | ||
99 | .. _VNC_Defaults_Configuration: | |
100 | ||
101 | VNC Defaults Configuration | |
102 | -------------------------- | |
103 | ||
104 | The VNC Defaults section allows the user to specify default values for | |
105 | configuration parameters for all registered NVEs. | |
106 | Default values are overridden by :ref:`VNC_NVE_Group_Configuration`. | |
107 | ||
108 | .. index:: {VNC} {vnc defaults} {} | |
109 | ||
110 | {VNC} {vnc defaults} {} | |
111 | Enter VNC configuration mode for specifying VNC default behaviors. Use | |
112 | `exit-vnc` to leave VNC configuration mode. `vnc defaults` is optional. | |
113 | ||
114 | :: | |
115 | ||
116 | vnc defaults | |
117 | ... various VNC defaults | |
118 | exit-vnc | |
119 | ||
120 | ||
121 | These are the statements that can appear between `vnc defaults` | |
122 | and `exit-vnc`. | |
123 | ||
124 | .. index:: {VNC} {rt import `rt-list`} {} | |
125 | ||
126 | {VNC} {rt import `rt-list`} {} | |
127 | .. index:: {VNC} {rt export `rt-list`} {} | |
128 | ||
129 | {VNC} {rt export `rt-list`} {} | |
130 | .. index:: {VNC} {rt both `rt-list`} {} | |
131 | ||
132 | {VNC} {rt both `rt-list`} {} | |
133 | Specify default route target import and export lists. `rt-list` is a | |
134 | space-separated list of route targets, each element of which is | |
135 | in one of the following forms: | |
136 | ||
137 | ||
138 | `IPv4-address`:`two-byte-integer` | |
139 | ||
140 | `four-byte-autonomous-system-number`:`two-byte-integer` | |
141 | ||
142 | `two-byte-autonomous-system-number`:`four-byte-integer` | |
143 | ||
144 | If no default import RT list is specified, then the default import RT | |
145 | list is empty. | |
146 | If no default export RT list is specified, then the default export RT | |
147 | list is empty. | |
148 | ||
149 | A complete definition of these parameters is | |
150 | given below (:ref:`VNC_NVE_Group_Configuration`). | |
151 | ||
152 | .. index:: {VNC} {rd `route-distinguisher`} | |
153 | ||
154 | {VNC} {rd `route-distinguisher`} | |
155 | Specify the default route distinguisher (RD) for routes advertised via BGP | |
156 | VPNs. The route distinguisher must be in one of four forms: | |
157 | ||
158 | ||
159 | `IPv4-address`:`two-byte-integer` | |
160 | ||
161 | `four-byte-autonomous-system-number`:`two-byte-integer` | |
162 | ||
163 | `two-byte-autonomous-system-number`:`four-byte-integer` | |
164 | ||
165 | auto:vn:`two-byte-integer` | |
166 | ||
167 | If RD is specified in the defaults section, the default RD | |
168 | value is `two-byte-autonomous-system-number=0`:`four-byte-integer=0`. | |
169 | ||
170 | A complete definition of this parameter is | |
171 | given below (:ref:`VNC_NVE_Group_Configuration`). | |
172 | ||
173 | .. index:: {VNC} {l2rd `nve-id-value`} | |
174 | ||
175 | {VNC} {l2rd `nve-id-value`} | |
176 | Set the value used to distinguish NVEs connected to the same logical | |
177 | Ethernet segment (i.e., L2VPN). | |
178 | ||
179 | A complete definition of this parameter is | |
180 | given below (:ref:`VNC_NVE_Group_Configuration`). | |
181 | ||
182 | .. index:: {VNC} {response-lifetime `lifetime`|infinite} {} | |
183 | ||
184 | {VNC} {response-lifetime `lifetime`|infinite} {} | |
185 | Specify the default lifetime to be included in RFP | |
186 | response messages sent to NVEs. | |
187 | ||
188 | A complete definition of this parameter is | |
189 | given below (:ref:`VNC_NVE_Group_Configuration`). | |
190 | ||
191 | .. index:: {VNC} {export bgp|zebra route-map MAP-NAME} | |
192 | ||
193 | {VNC} {export bgp|zebra route-map MAP-NAME} | |
194 | Specify that the named route-map should be applied to routes | |
195 | being exported to bgp or zebra. | |
196 | ||
197 | .. index:: {VNC} {export bgp|zebra no route-map} | |
198 | ||
199 | {VNC} {export bgp|zebra no route-map} | |
200 | Specify that no route-map should be applied to routes | |
201 | being exported to bgp or zebra. | |
202 | ||
203 | .. index:: {VNC} {export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME} | |
204 | ||
205 | {VNC} {export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME} | |
206 | Specify that the named prefix-list filter should be applied to | |
207 | routes being exported to bgp or zebra. | |
208 | Prefix-lists for ipv4 and ipv6 are independent of each other. | |
209 | ||
210 | .. index:: {VNC} {export bgp|zebra no ipv4|ipv6 prefix-list} | |
211 | ||
212 | {VNC} {export bgp|zebra no ipv4|ipv6 prefix-list} | |
213 | Specify that no prefix-list filter should be applied to | |
214 | routes being exported to bgp or zebra. | |
215 | ||
216 | .. index:: {VNC} {exit-vnc} {} | |
217 | ||
218 | {VNC} {exit-vnc} {} | |
219 | Exit VNC configuration mode. | |
220 | ||
221 | .. _VNC_NVE_Group_Configuration: | |
222 | ||
223 | VNC NVE Group Configuration | |
224 | --------------------------- | |
225 | ||
226 | A NVE Group corresponds to a specific set of NVEs. A Client NVE is | |
227 | assigned to an NVE Group based on whether there is a match for either | |
228 | its virtual or underlay network address against the VN and/or UN address | |
229 | prefixes specified in the NVE Group definition. When an NVE Group | |
230 | definition specifies both VN and UN address prefixes, then an NVE must | |
231 | match both prefixes in order to be assigned to the NVE Group. In the | |
232 | event that multiple NVE Groups match based on VN and/or UN addresses, | |
233 | the NVE is assigned to the first NVE Group listed in the configuration. | |
234 | If an NVE is not assigned to an NVE Group, its messages will be ignored. | |
235 | ||
236 | Configuration values specified for an NVE group apply to all | |
237 | member NVEs and override configuration values specified in the VNC | |
238 | Defaults section. | |
239 | ||
240 | @strong{At least one `nve-group` is mandatory for useful VNC | |
241 | operation.} | |
242 | ||
243 | .. index:: {VNC} {vnc nve-group `name`} {} | |
244 | ||
245 | {VNC} {vnc nve-group `name`} {} | |
246 | Enter VNC configuration mode for defining the NVE group `name`. | |
247 | Use `exit` or `exit-vnc` to exit group configuration mode. | |
248 | ||
249 | :: | |
250 | ||
251 | vnc nve-group group1 | |
252 | ... configuration commands | |
253 | exit-vnc | |
254 | ||
255 | ||
256 | .. index:: {VNC} {no vnc nve-group `name`} {} | |
257 | ||
258 | {VNC} {no vnc nve-group `name`} {} | |
259 | Delete the NVE group named `name`. | |
260 | ||
261 | The following statements are valid in an NVE group definition: | |
262 | ||
263 | .. index:: {VNC} {l2rd `nve-id-value`} | |
264 | ||
265 | {VNC} {l2rd `nve-id-value`} | |
266 | Set the value used to distinguish NVEs connected to the same physical | |
267 | Ethernet segment (i.e., at the same location)@footnote{The nve-id is | |
268 | carried in the route | |
269 | distinguisher. It is the second octet of the eight-octet route | |
270 | distinguisher generated for Ethernet / L2 advertisements. | |
271 | The first octet is a constant 0xFF, and the third through eighth | |
272 | octets are set to the L2 ethernet address being advertised.} | |
273 | ||
274 | The nve-id subfield may be specified as either a literal value | |
275 | in the range 1-255, or it may be specified as `auto:vn`, which | |
276 | means to use the least-significant octet of the originating | |
277 | NVE's VN address. | |
278 | ||
279 | .. index:: {VNC} {prefix vn|un A.B.C.D/M|X:X::X:X/M} {} | |
280 | ||
281 | {VNC} {prefix vn|un A.B.C.D/M|X:X::X:X/M} {} | |
282 | .. _prefix: | |
283 | ||
284 | Specify the matching prefix for this NVE group by either virtual-network address | |
285 | (`vn`) or underlay-network address (`un`). Either or both virtual-network | |
286 | and underlay-network prefixes may be specified. Subsequent virtual-network or | |
287 | underlay-network values within a `vnc nve-group` `exit-vnc` | |
288 | block override their respective previous values. | |
289 | ||
290 | These prefixes are used only for determining assignments of NVEs | |
291 | to NVE Groups. | |
292 | ||
293 | .. index:: {VNC} {rd `route-distinguisher`} | |
294 | ||
295 | {VNC} {rd `route-distinguisher`} | |
296 | Specify the route distinguisher for routes advertised via BGP | |
297 | VPNs. The route distinguisher must be in one of these forms: | |
298 | ||
299 | ||
300 | `IPv4-address`:`two-byte-integer` | |
301 | ||
302 | `four-byte-autonomous-system-number`:`two-byte-integer` | |
303 | ||
304 | `two-byte-autonomous-system-number`:`four-byte-integer` | |
305 | ||
306 | auto:vn:`two-byte-integer` | |
307 | ||
308 | Routes originated by NVEs in the NVE group will use | |
309 | the group's specified `route-distinguisher` when they are | |
310 | advertised via BGP. | |
311 | If the `auto` form is specified, it means that a matching NVE has | |
312 | its RD set to | |
313 | `rd_type=IP=1`:`IPv4-address=VN-address`:`two-byte-integer`, | |
314 | for IPv4 VN addresses and | |
315 | `rd_type=IP=1`:`IPv4-address=Last-four-bytes-of-VN-address`:`two-byte-integer`, | |
316 | for IPv6 VN addresses. | |
317 | ||
318 | If the NVE group definition does not specify a `route-distinguisher`, | |
319 | then the default `route-distinguisher` is used. | |
320 | If neither a group nor a default `route-distinguisher` is | |
321 | configured, then the advertised RD is set to | |
322 | `two-byte-autonomous-system-number=0`:`four-byte-integer=0`. | |
323 | ||
324 | .. index:: {VNC} {response-lifetime `lifetime`|infinite} {} | |
325 | ||
326 | {VNC} {response-lifetime `lifetime`|infinite} {} | |
327 | Specify the response lifetime, in seconds, to be included in RFP | |
328 | response messages sent to NVEs. If the value | |
329 | 'infinite' is given, an infinite lifetime will be used. | |
330 | ||
331 | Note that this parameter is not the same as the lifetime supplied by | |
332 | NVEs in RFP registration messages. This parameter does not affect | |
333 | the lifetime value attached to routes sent by this server via BGP. | |
334 | ||
335 | If the NVE group definition does not specify a `response-lifetime`, | |
336 | the default `response-lifetime` will be used. | |
337 | If neither a group nor a default `response-lifetime` is configured, | |
338 | the value 3600 will be used. The maximum response lifetime is 2147483647. | |
339 | ||
340 | .. index:: {VNC} {rt export `rt-list`} {} | |
341 | ||
342 | {VNC} {rt export `rt-list`} {} | |
343 | .. index:: {VNC} {rt import `rt-list`} {} | |
344 | ||
345 | {VNC} {rt import `rt-list`} {} | |
346 | .. index:: {VNC} {rt both `rt-list`} {} | |
347 | ||
348 | {VNC} {rt both `rt-list`} {} | |
349 | Specify route target import and export lists. `rt-list` is a | |
350 | space-separated list of route targets, each element of which is | |
351 | in one of the following forms: | |
352 | ||
353 | ||
354 | `IPv4-address`:`two-byte-integer` | |
355 | ||
356 | `four-byte-autonomous-system-number`:`two-byte-integer` | |
357 | ||
358 | `two-byte-autonomous-system-number`:`four-byte-integer` | |
359 | ||
360 | The first form, `rt export`, specifies an `export rt-list`. | |
361 | The `export rt-list` will be attached to routes originated by | |
362 | NVEs in the NVE group when they are advertised via BGP. | |
363 | If the NVE group definition does not specify an `export rt-list`, | |
364 | then the default `export rt-list` is used. | |
365 | If neither a group nor a default `export rt-list` is configured, | |
366 | then no RT list will be sent; in turn, these routes will probably | |
367 | not be processed | |
368 | by receiving NVAs. | |
369 | ||
370 | The second form, `rt import` specifies an `import rt-list`, | |
371 | which is a filter for incoming routes. | |
372 | In order to be made available to NVEs in the group, | |
373 | incoming BGP VPN and @w{ENCAP} @w{SAFI} (when `vnc advertise-un-method encap-safi` is set) routes must have | |
374 | RT lists that have at least one route target in common with the | |
375 | group's `import rt-list`. | |
376 | ||
377 | If the NVE group definition does not specify an import filter, | |
378 | then the default `import rt-list` is used. | |
379 | If neither a group nor a default `import rt-list` is configured, | |
380 | there can be no RT intersections when receiving BGP routes and | |
381 | therefore no incoming BGP routes will be processed for the group. | |
382 | ||
383 | The third, `rt both`, is a shorthand way of specifying both | |
384 | lists simultaneously, and is equivalent to `rt export `rt-list`` | |
385 | followed by `rt import `rt-list``. | |
386 | ||
387 | .. index:: {VNC} {export bgp|zebra route-map MAP-NAME} | |
388 | ||
389 | {VNC} {export bgp|zebra route-map MAP-NAME} | |
390 | Specify that the named route-map should be applied to routes | |
391 | being exported to bgp or zebra. | |
392 | This paramter is used in conjunction with | |
393 | :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`. | |
394 | This item is optional. | |
395 | ||
396 | .. index:: {VNC} {export bgp|zebra no route-map} | |
397 | ||
398 | {VNC} {export bgp|zebra no route-map} | |
399 | Specify that no route-map should be applied to routes | |
400 | being exported to bgp or zebra. | |
401 | This paramter is used in conjunction with | |
402 | :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`. | |
403 | This item is optional. | |
404 | ||
405 | .. index:: {VNC} {export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME} | |
406 | ||
407 | {VNC} {export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME} | |
408 | Specify that the named prefix-list filter should be applied to | |
409 | routes being exported to bgp or zebra. | |
410 | Prefix-lists for ipv4 and ipv6 are independent of each other. | |
411 | This paramter is used in conjunction with | |
412 | :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`. | |
413 | This item is optional. | |
414 | ||
415 | .. index:: {VNC} {export bgp|zebra no ipv4|ipv6 prefix-list} | |
416 | ||
417 | {VNC} {export bgp|zebra no ipv4|ipv6 prefix-list} | |
418 | Specify that no prefix-list filter should be applied to | |
419 | routes being exported to bgp or zebra. | |
420 | This paramter is used in conjunction with | |
421 | :ref:`Configuring_Export_of_Routes_to_Other_Routing_Protocols`. | |
422 | This item is optional. | |
423 | ||
424 | .. _VNC_L2_Group_Configuration: | |
425 | ||
426 | VNC L2 Group Configuration | |
427 | -------------------------- | |
428 | ||
429 | The route targets advertised with prefixes and addresses registered by | |
430 | an NVE are determined based on the NVE's associated VNC NVE Group | |
431 | Configuration, :ref:`VNC_NVE_Group_Configuration`. Layer 2 (L2) Groups | |
432 | are used to override the route targets for an NVE's Ethernet | |
433 | registrations based on the Logical Network Identifier and label value. | |
434 | A Logical Network Identifier is used to uniquely identify a logical | |
435 | Ethernet segment and is conceptually similar to the Ethernet Segment | |
436 | Identifier defined in @cite{RFC7432, BGP MPLS-Based Ethernet VPN}. Both | |
437 | the Logical Network Identifier and Label are passed to VNC via RFP | |
438 | prefix and address registration. | |
439 | ||
440 | Note that a corresponding NVE group configuration must be present, and | |
441 | that other NVE associated configuration information, notably RD, is | |
442 | not impacted by L2 Group Configuration. | |
443 | ||
444 | .. index:: {VNC} {vnc l2-group `name`} {} | |
445 | ||
446 | {VNC} {vnc l2-group `name`} {} | |
447 | Enter VNC configuration mode for defining the L2 group `name`. | |
448 | Use `exit` or `exit-vnc` to exit group configuration mode. | |
449 | ||
450 | :: | |
451 | ||
452 | vnc l2-group group1 | |
453 | ... configuration commands | |
454 | exit-vnc | |
455 | ||
456 | ||
457 | .. index:: {VNC} {no vnc l2-group `name`} {} | |
458 | ||
459 | {VNC} {no vnc l2-group `name`} {} | |
460 | Delete the L2 group named `name`. | |
461 | ||
462 | The following statements are valid in a L2 group definition: | |
463 | ||
464 | .. index:: {VNC} {logical-network-id `VALUE`} | |
465 | ||
466 | {VNC} {logical-network-id `VALUE`} | |
467 | Define the Logical Network Identifier with a value in the range of | |
468 | 0-4294967295 that identifies the logical Ethernet segment. | |
469 | ||
470 | .. index:: {VNC} {labels `label-list`} | |
471 | ||
472 | {VNC} {labels `label-list`} | |
473 | .. index:: {VNC} {no labels `label-list`} | |
474 | ||
475 | {VNC} {no labels `label-list`} | |
476 | Add or remove labels associated with the group. `label-list` is a | |
477 | space separated list of label values in the range of 0-1048575. | |
478 | ||
479 | .. index:: {VNC} {rt import `rt-target`} {} | |
480 | ||
481 | {VNC} {rt import `rt-target`} {} | |
482 | .. index:: {VNC} {rt export `rt-target`} {} | |
483 | ||
484 | {VNC} {rt export `rt-target`} {} | |
485 | .. index:: {VNC} {rt both `rt-target`} {} | |
486 | ||
487 | {VNC} {rt both `rt-target`} {} | |
488 | Specify the route target import and export value associated with the | |
489 | group. A complete definition of these parameters is given above, | |
490 | :ref:`VNC_NVE_Group_Configuration`. | |
491 | ||
492 | .. _Configuring_Redistribution_of_Routes_from_Other_Routing_Protocols: | |
493 | ||
494 | Configuring Redistribution of Routes from Other Routing Protocols | |
495 | ----------------------------------------------------------------- | |
496 | ||
497 | Routes from other protocols (including BGP) can be provided to VNC (both | |
498 | for RFP and for redistribution via BGP) | |
499 | from three sources: the zebra kernel routing process; | |
500 | directly from the main (default) unicast BGP RIB; or directly | |
501 | from a designated BGP unicast exterior routing RIB instance. | |
502 | ||
503 | The protocol named in the `vnc redistribute` command indicates | |
504 | the route source: | |
505 | `bgp-direct` routes come directly from the main (default) | |
506 | unicast BGP RIB and are available for RFP and are redistributed via BGP; | |
507 | `bgp-direct-to-nve-groups` routes come directly from a designated | |
508 | BGP unicast routing RIB and are made available only to RFP; | |
509 | and routes from other protocols come from the zebra kernel | |
510 | routing process. | |
511 | Note that the zebra process does not need to be active if | |
512 | only `bgp-direct` or `bgp-direct-to-nve-groups` routes are used. | |
513 | ||
514 | `zebra` routes | |
515 | ^^^^^^^^^^^^^^ | |
516 | ||
517 | Routes originating from protocols other than BGP must be obtained | |
518 | via the zebra routing process. | |
519 | Redistribution of these routes into VNC does not support policy mechanisms | |
520 | such as prefix-lists or route-maps. | |
521 | ||
522 | `bgp-direct` routes | |
523 | ^^^^^^^^^^^^^^^^^^^ | |
524 | ||
525 | `bgp-direct` redistribution supports policy via | |
526 | prefix lists and route-maps. This policy is applied to incoming | |
527 | original unicast routes before the redistribution translations | |
528 | (described below) are performed. | |
529 | ||
530 | Redistribution of `bgp-direct` routes is performed in one of three | |
531 | possible modes: `plain`, `nve-group`, or `resolve-nve`. | |
532 | The default mode is `plain`. | |
533 | These modes indicate the kind of translations applied to routes before | |
534 | they are added to the VNC RIB. | |
535 | ||
536 | In `plain` mode, the route's next hop is unchanged and the RD is set | |
537 | based on the next hop. | |
538 | For `bgp-direct` redistribution, the following translations are performed: | |
539 | ||
540 | * | |
541 | The VN address is set to the original unicast route's next hop address. | |
542 | * | |
543 | The UN address is NOT set. (VN->UN mapping will occur via | |
544 | ENCAP route or attribute, based on `vnc advertise-un-method` | |
545 | setting, generated by the RFP registration of the actual NVE) | |
546 | * | |
547 | The RD is set to as if auto:vn:0 were specified (i.e., | |
548 | `rd_type=IP=1`:`IPv4-address=VN-address`:`two-byte-integer=0`) | |
549 | * | |
550 | The RT list is included in the extended community list copied from the | |
551 | original unicast route (i.e., it must be set in the original unicast route). | |
552 | ||
553 | In `nve-group` mode, routes are registered with VNC as | |
554 | if they came from an NVE in the nve-group designated in the | |
555 | `vnc redistribute nve-group` command. The following | |
556 | translations are performed: | |
557 | ||
558 | * | |
559 | The next hop/VN address is set to the VN prefix configured for the | |
560 | redistribute nve-group. | |
561 | * | |
562 | The UN address is set to the UN prefix configured for the | |
563 | redistribute nve-group. | |
564 | * | |
565 | The RD is set to the RD configured for the redistribute nve-group. | |
566 | * | |
567 | The RT list is set to the RT list configured for the redistribute nve-group. | |
568 | If `bgp-direct` routes are being redistributed, | |
569 | any extended communities present in the original unicast route | |
570 | will also be included. | |
571 | ||
572 | In `resolve-nve` mode, the next hop of the original BGP route is | |
573 | typically the address of an NVE connected router (CE) connected by one or | |
574 | more NVEs. | |
575 | Each of the connected NVEs will register, via RFP, a VNC host route | |
576 | to the CE. | |
577 | This mode may be though of as a mechanism to proxy RFP registrations | |
578 | of BGP unicast routes on behalf of registering NVEs. | |
579 | ||
580 | Multiple copies of the BGP route, one per matching NVE host route, will be | |
581 | added to VNC. | |
582 | In other words, for a given BGP unicast route, each instance of a | |
583 | RFP-registered host route to the unicast route's next hop will result | |
584 | in an instance of an imported VNC route. | |
585 | Each such imported VNC route will have a prefix equal to the original | |
586 | BGP unicast route's prefix, and a next hop equal to the next hop of the | |
587 | matching RFP-registered host route. | |
588 | If there is no RFP-registered host route to the next hop of the BGP unicast | |
589 | route, no corresponding VNC route will be imported. | |
590 | ||
591 | The following translations are applied: | |
592 | ||
593 | * | |
594 | The Next Hop is set to the next hop of the NVE route (i.e., the | |
595 | VN address of the NVE). | |
596 | ||
597 | * | |
598 | The extended community list in the new route is set to the | |
599 | union of: | |
600 | ||
601 | * | |
602 | Any extended communities in the original BGP route | |
603 | * | |
604 | Any extended communities in the NVE route | |
605 | * | |
606 | An added route-origin extended community with the next hop of the | |
607 | original BGP route | |
608 | is added to the new route. | |
609 | The value of the local administrator field defaults 5226 but may | |
610 | be configured by the user via the `roo-ec-local-admin` parameter. | |
611 | ||
612 | * | |
613 | The Tunnel Encapsulation attribute is set to the value of the Tunnel | |
614 | Encapsulation attribute of the NVE route, if any. | |
615 | ||
616 | ||
617 | `bgp-direct-to-nve-groups` routes | |
618 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
619 | ||
620 | Unicast routes from the main or a designated instance of BGP | |
621 | may be redistributed to VNC as bgp-direct-to-nve-groups routes. These | |
622 | routes are NOT announced via BGP, | |
623 | but they are made available for local RFP lookup in response to | |
624 | queries from NVEs. | |
625 | ||
626 | A non-main/default BGP instance is configured using the | |
627 | `bgp multiple-instance` and `router bgp AS view NAME` | |
628 | commands as described elsewhere in this document. | |
629 | ||
630 | In order for a route in the unicast BGP RIB to be made | |
631 | available to a querying NVE, there must already be, available to | |
632 | that NVE, an (interior) VNC route matching the next hop address | |
633 | of the unicast route. | |
634 | When the unicast route is provided to the NVE, its next hop | |
635 | is replaced by the next hop of the corresponding | |
636 | NVE. If there are multiple longest-prefix-match VNC routes, | |
637 | the unicast route will be replicated for each. | |
638 | ||
639 | There is currently no policy (prefix-list or route-map) support | |
640 | for `bgp-direct-to-nve-groups` routes. | |
641 | ||
642 | Redistribution Command Syntax | |
643 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
644 | ||
645 | .. index:: {VNC} {vnc redistribute ipv4|ipv6 bgp|bgp-direct|ipv6 bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static} {} | |
646 | ||
647 | {VNC} {vnc redistribute ipv4|ipv6 bgp|bgp-direct|ipv6 bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static} {} | |
648 | .. index:: {VNC} {vnc redistribute ipv4|ipv6 bgp-direct-to-nve-groups view `VIEWNAME`} {} | |
649 | ||
650 | {VNC} {vnc redistribute ipv4|ipv6 bgp-direct-to-nve-groups view `VIEWNAME`} {} | |
651 | .. index:: {VNC} {no vnc redistribute ipv4|ipv6 bgp|bgp-direct|bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static} {} | |
652 | ||
653 | {VNC} {no vnc redistribute ipv4|ipv6 bgp|bgp-direct|bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static} {} | |
654 | Import (or do not import) prefixes from another routing | |
655 | protocols. Specify both the address family to import (`ipv4` or | |
656 | `ipv6`) and the protocol (`bgp`, `bgp-direct`, | |
657 | `bgp-direct-to-nve-groups`, `connected`, | |
658 | `kernel`, `ospf`, `rip`, or `static`). Repeat | |
659 | this statement as needed for each combination of address family and | |
660 | routing protocol. | |
661 | Prefixes from protocol `bgp-direct` are imported from unicast BGP | |
662 | in the same bgpd process. | |
663 | Prefixes from all other protocols (including `bgp`) are imported | |
664 | via the `zebra` kernel routing process. | |
665 | ||
666 | .. index:: {VNC} {vnc redistribute mode plain|nve-group|resolve-nve} | |
667 | ||
668 | {VNC} {vnc redistribute mode plain|nve-group|resolve-nve} | |
669 | Redistribute routes from other protocols into VNC using the | |
670 | specified mode. | |
671 | Not all combinations of modes and protocols are supported. | |
672 | ||
673 | .. index:: {VNC} {vnc redistribute nve-group `group-name`} {} | |
674 | ||
675 | {VNC} {vnc redistribute nve-group `group-name`} {} | |
676 | .. index:: {VNC} {no vnc redistribute nve-group `group-name`} {} | |
677 | ||
678 | {VNC} {no vnc redistribute nve-group `group-name`} {} | |
679 | When using `nve-group` mode, | |
680 | assign (or do not assign) the NVE group `group-name` to routes | |
681 | redistributed from another routing protocol. `group-name` | |
682 | must be configured using `vnc nve-group`. | |
683 | ||
684 | The VN and UN prefixes of the nve-group must both be configured, | |
685 | and each prefix must be specified as a full-length (/32 for IPv4, | |
686 | /128 for IPv6) prefix. | |
687 | ||
688 | .. index:: {VNC} {vnc redistribute lifetime `lifetime`|infinite} {} | |
689 | ||
690 | {VNC} {vnc redistribute lifetime `lifetime`|infinite} {} | |
691 | Assign a registration lifetime, either `lifetime` seconds or | |
692 | `infinite`, to prefixes redistributed from other routing | |
693 | protocols as if they had been received via RFP registration messages | |
694 | from an NVE. `lifetime` can be any integer between 1 and | |
695 | 4294967295, inclusive. | |
696 | ||
697 | .. index:: {VNC} {vnc redistribute resolve-nve roo-ec-local-admin `0-65536`} | |
698 | ||
699 | {VNC} {vnc redistribute resolve-nve roo-ec-local-admin `0-65536`} | |
700 | Assign a value to the local-administrator subfield used in the | |
701 | Route Origin extended community that is assigned to routes exported | |
702 | under the `resolve-nve` mode. The default value is `5226`. | |
703 | ||
704 | The following four `prefix-list` and `route-map` commands | |
705 | may be specified in the context of an nve-group or not. | |
706 | If they are specified in the context of an nve-group, they | |
707 | apply only if the redistribution mode is `nve-group`, | |
708 | and then only for routes being redistributed from | |
709 | `bgp-direct`. | |
710 | If they are specified outside the context of an nve-group, then | |
711 | they apply only for redistribution modes `plain` and `resolve-nve`, | |
712 | and then only for routes being redistributed from `bgp-direct`. | |
713 | ||
714 | .. index:: {VNC} {vnc redistribute bgp-direct (ipv4|ipv6) prefix-list `LIST-NAME`} | |
715 | ||
716 | {VNC} {vnc redistribute bgp-direct (ipv4|ipv6) prefix-list `LIST-NAME`} | |
717 | When redistributing `bgp-direct` routes, | |
718 | specifies that the named prefix-list should be applied. | |
719 | ||
720 | .. index:: {VNC} {vnc redistribute bgp-direct no (ipv4|ipv6) prefix-list} | |
721 | ||
722 | {VNC} {vnc redistribute bgp-direct no (ipv4|ipv6) prefix-list} | |
723 | When redistributing `bgp-direct` routes, | |
724 | specifies that no prefix-list should be applied. | |
725 | ||
726 | .. index:: {VNC} {vnc redistribute bgp-direct route-map `MAP-NAME`} | |
727 | ||
728 | {VNC} {vnc redistribute bgp-direct route-map `MAP-NAME`} | |
729 | When redistributing `bgp-direct` routes, | |
730 | specifies that the named route-map should be applied. | |
731 | ||
732 | .. index:: {VNC} {vnc redistribute bgp-direct no route-map} | |
733 | ||
734 | {VNC} {vnc redistribute bgp-direct no route-map} | |
735 | When redistributing `bgp-direct` routes, | |
736 | specifies that no route-map should be applied. | |
737 | ||
738 | .. _Configuring_Export_of_Routes_to_Other_Routing_Protocols: | |
739 | ||
740 | Configuring Export of Routes to Other Routing Protocols | |
741 | ------------------------------------------------------- | |
742 | ||
743 | Routes from VNC (both for RFP and for redistribution via BGP) can be | |
744 | provided to other protocols, either via zebra or directly to BGP. | |
745 | ||
746 | It is important to note that when exporting routes to other protocols, | |
747 | the downstream protocol must also be configured to import the routes. | |
748 | For example, when VNC routes are exported to unicast BGP, the BGP | |
749 | configuration must include a corresponding `redistribute vnc-direct` | |
750 | statement. | |
751 | ||
752 | .. index:: {VNC} {export bgp|zebra mode none|group-nve|registering-nve|ce} | |
753 | ||
754 | {VNC} {export bgp|zebra mode none|group-nve|registering-nve|ce} | |
755 | Specify how routes should be exported to bgp or zebra. | |
756 | If the mode is `none`, routes are not exported. | |
757 | If the mode is `group-nve`, routes are exported according | |
758 | to nve-group or vrf-policy group configuration (:ref:`VNC_NVE_Group_Configuration`): if a group is configured to | |
759 | allow export, then each prefix visible to the group is exported | |
760 | with next hops set to the currently-registered NVEs. | |
761 | If the mode is `registering-nve`, then all VNC routes are | |
762 | exported with their original next hops. | |
763 | If the mode is `ce`, only VNC routes that have an NVE connected CE Router | |
764 | encoded in a Route Origin Extended Community are exported. | |
765 | This extended community must have an administrative value that | |
766 | matches the configured `roo-ec-local-admin` value. | |
767 | The next hop of the exported route is set to the encoded | |
768 | NVE connected CE Router. | |
769 | ||
770 | The default for both bgp and zebra is mode `none`. | |
771 | ||
772 | .. index:: {VNC} {vnc export bgp|zebra group-nve group `group-name`} | |
773 | ||
774 | {VNC} {vnc export bgp|zebra group-nve group `group-name`} | |
775 | .. index:: {VNC} {vnc export bgp|zebra group-nve no group `group-name`} | |
776 | ||
777 | {VNC} {vnc export bgp|zebra group-nve no group `group-name`} | |
778 | When export mode is `group-nve`, | |
779 | export (or do not export) prefixes from the specified nve-group or | |
780 | vrf-policy group | |
781 | to unicast BGP or to zebra. | |
782 | Repeat this statement as needed for each nve-group to be exported. | |
783 | Each VNC prefix that is exported will result in N exported routes to the | |
784 | prefix, each with a next hop corresponding to one of the N NVEs currently | |
785 | associated with the nve-group. | |
786 | ||
787 | .. index:: {VNC} export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME | |
788 | ||
789 | {VNC} export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME | |
790 | When export mode is `ce` or `registering-nve`, | |
791 | specifies that the named prefix-list should be applied to routes | |
792 | being exported to bgp or zebra. | |
793 | Prefix-lists for ipv4 and ipv6 are independent of each other. | |
794 | ||
795 | .. index:: {VNC} export bgp|zebra no ipv4|ipv6 prefix-list | |
796 | ||
797 | {VNC} export bgp|zebra no ipv4|ipv6 prefix-list | |
798 | When export mode is `ce` or `registering-nve`, | |
799 | specifies that no prefix-list should be applied to routes | |
800 | being exported to bgp or zebra. | |
801 | ||
802 | .. index:: {VNC} export bgp|zebra route-map MAP-NAME | |
803 | ||
804 | {VNC} export bgp|zebra route-map MAP-NAME | |
805 | When export mode is `ce` or `registering-nve`, | |
806 | specifies that the named route-map should be applied to routes | |
807 | being exported to bgp or zebra. | |
808 | ||
809 | .. index:: {VNC} export bgp|zebra no route-map | |
810 | ||
811 | {VNC} export bgp|zebra no route-map | |
812 | When export mode is `ce` or `registering-nve`, | |
813 | specifies that no route-map should be applied to routes | |
814 | being exported to bgp or zebra. | |
815 | ||
816 | When the export mode is `group-nve`, policy for exported | |
817 | routes is specified per-NVE-group or vrf-policy group inside a `nve-group` `RFG-NAME` block | |
818 | via the following commands(:ref:`VNC_NVE_Group_Configuration`): | |
819 | ||
820 | .. index:: {VNC} {export bgp|zebra route-map MAP-NAME} | |
821 | ||
822 | {VNC} {export bgp|zebra route-map MAP-NAME} | |
823 | This command is valid inside a `nve-group` `RFG-NAME` block. | |
824 | It specifies that the named route-map should be applied to routes | |
825 | being exported to bgp or zebra. | |
826 | ||
827 | .. index:: {VNC} {export bgp|zebra no route-map} | |
828 | ||
829 | {VNC} {export bgp|zebra no route-map} | |
830 | This command is valid inside a `nve-group` `RFG-NAME` block. | |
831 | It specifies that no route-map should be applied to routes | |
832 | being exported to bgp or zebra. | |
833 | ||
834 | .. index:: {VNC} {export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME} | |
835 | ||
836 | {VNC} {export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME} | |
837 | This command is valid inside a `nve-group` `RFG-NAME` block. | |
838 | It specifies that the named prefix-list filter should be applied to | |
839 | routes being exported to bgp or zebra. | |
840 | Prefix-lists for ipv4 and ipv6 are independent of each other. | |
841 | ||
842 | .. index:: {VNC} {export bgp|zebra no ipv4|ipv6 prefix-list} | |
843 | ||
844 | {VNC} {export bgp|zebra no ipv4|ipv6 prefix-list} | |
845 | This command is valid inside a `nve-group` `RFG-NAME` block. | |
846 | It specifies that no prefix-list filter should be applied to | |
847 | routes being exported to bgp or zebra. | |
848 | ||
849 | .. _Manual_Address_Control: | |
850 | ||
851 | Manual Address Control | |
852 | ====================== | |
853 | ||
854 | The commands in this section can be used to augment normal dynamic VNC. | |
855 | The `add vnc` commands can be used to manually add IP prefix or | |
856 | Ethernet MAC address forwarding information. The `clear vnc` | |
857 | commands can be used to remove manually and dynamically added | |
858 | information. | |
859 | ||
860 | .. index:: {Command} {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>]]} {} | |
861 | ||
862 | {Command} {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>]]} {} | |
863 | Register an IP prefix on behalf of the NVE identified by the VN and UN | |
864 | addresses. The `cost` parameter provides the administrative | |
865 | preference of the forwarding information for remote advertisement. If | |
866 | omitted, it defaults to 255 (lowest preference). The `lifetime` | |
867 | parameter identifies the period, in seconds, that the information | |
868 | remains valid. If omitted, it defaults to `infinite`. The optional | |
869 | `local-next-hop` parameter is used to configure a nexthop to be | |
870 | used by an NVE to reach the prefix via a locally connected CE router. | |
871 | This information remains local to the NVA, i.e., not passed to other | |
872 | NVAs, and is only passed to registered NVEs. When specified, it is also | |
873 | possible to provide a `local-cost` parameter to provide a | |
874 | forwarding preference. If omitted, it defaults to 255 (lowest | |
875 | preference). | |
876 | ||
877 | .. index:: {Command} {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>)]} {} | |
878 | ||
879 | {Command} {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>)]} {} | |
880 | Register a MAC address for a logical Ethernet (L2VPN) on behalf of the | |
881 | NVE identified by the VN and UN addresses. | |
882 | The optional `prefix` parameter is to support enable IP address | |
883 | mediation for the given prefix. The `cost` parameter provides the administrative | |
884 | preference of the forwarding information. If omitted, it defaults to | |
885 | 255. The `lifetime` parameter identifies the period, in seconds, | |
886 | that the information remains valid. If omitted, it defaults to | |
887 | `infinite`. | |
888 | ||
889 | .. index:: {Command} {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)])} {} | |
890 | ||
891 | {Command} {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)])} {} | |
892 | Delete the information identified by prefix, VN address, and UN address. | |
893 | Any or all of these parameters may be wilcarded to (potentially) match | |
894 | more than one registration. | |
895 | The optional `mac` parameter specifies a layer-2 MAC address | |
896 | that must match the registration(s) to be deleted. | |
897 | The optional `local-next-hop` parameter is used to | |
898 | delete specific local nexthop information. | |
899 | ||
900 | .. index:: {Command} {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)])} {} | |
901 | ||
902 | {Command} {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)])} {} | |
903 | Delete mac forwarding information. | |
904 | Any or all of these parameters may be wilcarded to (potentially) match | |
905 | more than one registration. | |
906 | The default value for the `prefix` parameter is the wildcard value `*`. | |
907 | ||
908 | .. index:: {Command} {clear vnc nve (*|((vn|un) (A.B.C.D|X:X::X:X) [(un|vn) (A.B.C.D|X:X::X:X)])) } {} | |
909 | ||
910 | {Command} {clear vnc nve (*|((vn|un) (A.B.C.D|X:X::X:X) [(un|vn) (A.B.C.D|X:X::X:X)])) } {} | |
911 | Delete prefixes associated with the NVE specified by the given VN and UN | |
912 | addresses. | |
913 | It is permissible to specify only one of VN or UN, in which case | |
914 | any matching registration will be deleted. | |
915 | It is also permissible to specify `*` in lieu of any VN or UN | |
916 | address, in which case all registrations will match. | |
917 | ||
918 | .. _Other_VNC-Related_Commands: | |
919 | ||
920 | Other VNC-Related Commands | |
921 | ========================== | |
922 | ||
923 | Note: VNC-Related configuration can be obtained via the `show running-configuration` command when in `enable` mode. | |
924 | ||
925 | The following commands are used to clear and display | |
926 | Virtual Network Control related information: | |
927 | ||
928 | .. index:: {COMMAND} {clear vnc counters} {} | |
929 | ||
930 | {COMMAND} {clear vnc counters} {} | |
931 | Reset the counter values stored by the NVA. Counter | |
932 | values can be seen using the `show vnc` commands listed above. This | |
933 | command is only available in `enable` mode. | |
934 | ||
935 | .. index:: {Command} {show vnc summary} {} | |
936 | ||
937 | {Command} {show vnc summary} {} | |
938 | Print counter values and other general information | |
939 | about the NVA. Counter values can be reset | |
940 | using the `clear vnc counters` command listed below. | |
941 | ||
942 | .. index:: {Command} {show vnc nves} {} | |
943 | ||
944 | {Command} {show vnc nves} {} | |
945 | .. index:: {Command} {show vnc nves vn|un `address`} {} | |
946 | ||
947 | {Command} {show vnc nves vn|un `address`} {} | |
948 | Display the NVA's current clients. Specifying `address` | |
949 | limits the output to the NVEs whose addresses match `address`. | |
950 | The time since the NVA last communicated with the NVE, per-NVE | |
951 | summary counters and each NVE's addresses will be displayed. | |
952 | ||
953 | .. index:: {Command} {show vnc queries} {} | |
954 | ||
955 | {Command} {show vnc queries} {} | |
956 | .. index:: {Command} {show vnc queries `prefix`} {} | |
957 | ||
958 | {Command} {show vnc queries `prefix`} {} | |
959 | Display active Query information. Queries remain valid for the default | |
960 | Response Lifetime (:ref:`VNC_Defaults_Configuration`) or NVE-group | |
961 | Response Lifetime (:ref:`VNC_NVE_Group_Configuration`). Specifying | |
962 | `prefix` limits the output to Query Targets that fall within | |
963 | `prefix`. | |
964 | ||
965 | Query information is provided for each querying NVE, and includes the | |
966 | Query Target and the time remaining before the information is removed. | |
967 | ||
968 | .. index:: {Command} {show vnc registrations [all|local|remote|holddown|imported]} {} | |
969 | ||
970 | {Command} {show vnc registrations [all|local|remote|holddown|imported]} {} | |
971 | .. index:: {Command} {show vnc registrations [all|local|remote|holddown|imported] `prefix`} {} | |
972 | ||
973 | {Command} {show vnc registrations [all|local|remote|holddown|imported] `prefix`} {} | |
974 | Display local, remote, holddown, and/or imported registration information. | |
975 | Local registrations are routes received via RFP, which are present in the | |
976 | NVA Registrations Cache. | |
977 | Remote registrations are routes received via BGP (VPN SAFIs), which | |
978 | are present in the NVE-group import tables. | |
979 | Holddown registrations are local and remote routes that have been | |
980 | withdrawn but whose holddown timeouts have not yet elapsed. | |
981 | Imported information represents routes that are imported into NVA and | |
982 | are made available to querying NVEs. Depending on configuration, | |
983 | imported routes may also be advertised via BGP. | |
984 | Specifying `prefix` limits the output to the registered prefixes that | |
985 | fall within `prefix`. | |
986 | ||
987 | Registration information includes the registered prefix, the registering | |
988 | NVE addresses, the registered administrative cost, the registration | |
989 | lifetime and the time since the information was registered or, in the | |
990 | case of Holddown registrations, the amount of time remaining before the | |
991 | information is removed. | |
992 | ||
993 | .. index:: {Command} {show vnc responses [active|removed]} {} | |
994 | ||
995 | {Command} {show vnc responses [active|removed]} {} | |
996 | .. index:: {Command} {show vnc responses [active|removed] `prefix`} {} | |
997 | ||
998 | {Command} {show vnc responses [active|removed] `prefix`} {} | |
999 | Display all, active and/or removed response information which are | |
1000 | present in the NVA Responses Cache. Responses remain valid for the | |
1001 | default Response Lifetime (:ref:`VNC_Defaults_Configuration`) or | |
1002 | NVE-group Response Lifetime (:ref:`VNC_NVE_Group_Configuration`.) | |
1003 | When Removal Responses are enabled (:ref:`General_VNC_Configuration`), | |
1004 | such responses are listed for the Response Lifetime. Specifying | |
1005 | `prefix` limits the output to the addresses that fall within | |
1006 | `prefix`. | |
1007 | ||
1008 | Response information is provided for each querying NVE, and includes | |
1009 | the response prefix, the prefix-associated registering NVE addresses, | |
1010 | the administrative cost, the provided response lifetime and the time | |
1011 | remaining before the information is to be removed or will become inactive. | |
1012 | ||
1013 | .. index:: {Command} {show memory vnc} {} | |
1014 | ||
1015 | {Command} {show memory vnc} {} | |
1016 | Print the number of memory items allocated by the NVA. | |
1017 | ||
1018 | .. _Example_VNC_and_VNC-GW_Configurations: | |
1019 | ||
1020 | Example VNC and VNC-GW Configurations | |
1021 | ===================================== | |
1022 | ||
1023 |