]>
Commit | Line | Data |
---|---|---|
65efcfce | 1 | @c -*-texinfo-*- |
438f5286 | 2 | @c This is part of the Frr Manual. |
65efcfce | 3 | @c @value{COPYRIGHT_STR} |
438f5286 | 4 | @c See file frr.texi for copying conditions. |
65efcfce LB |
5 | |
6 | @node VNC and VNC-GW | |
7 | @chapter VNC and VNC-GW | |
8 | This chapter describes how to use | |
9 | Virtual Network Control (@acronym{VNC}) services, | |
10 | including Network Virtualization Authority (@acronym{NVA}) and | |
11 | VNC Gateway (@acronym{VNC-GW}) functions. | |
12 | Background information on NVAs, | |
13 | Network Virtualization Edges (@acronym{NVE}s), underlay networks (@acronym{UN}s), | |
14 | and virtual networks (@acronym{VN}s) is available from the | |
15 | @url{https://datatracker.ietf.org/wg/nvo3,IETF Network Virtualization Overlays (@acronym{NVO3}) Working Group}. | |
16 | VNC Gateways (@acronym{VNC-GW}s) support the import/export of routing | |
17 | information between VNC and customer edge routers (@acronym{CE}s) | |
18 | operating within a VN. Both IP/Layer 3 (L3) VNs, and IP with | |
19 | Ethernet/Layer 2 (L2) VNs are supported. | |
20 | ||
21 | BGP, with IP VPNs and Tunnel Encapsulation, is used to distribute VN | |
22 | information between NVAs. BGP based IP VPN support is defined in | |
23 | @cite{RFC4364, BGP/MPLS IP Virtual Private Networks (VPNs)}, and | |
24 | @cite{RFC4659, BGP-MPLS IP Virtual Private Network (VPN) Extension for | |
25 | IPv6 VPN }. Both the Encapsulation Subsequent Address Family Identifier | |
26 | (SAFI) and the Tunnel Encapsulation Attribute, @cite{RFC5512, The BGP | |
27 | Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP | |
28 | Tunnel Encapsulation Attribute}, are supported. | |
29 | ||
30 | The protocol that is used to communicate routing and Ethernet / Layer 2 | |
31 | (L2) forwarding information between NVAs and NVEs is referred to as the | |
32 | Remote Forwarder Protocol (RFP). @code{OpenFlow} is an example | |
33 | RFP. Specific RFP implementations may choose to implement either a | |
34 | @code{hard-state} or @code{soft-state} prefix and address registration | |
35 | model. To support a @code{soft-state} refresh model, a @var{lifetime} | |
36 | in seconds is associated with all registrations and responses. | |
37 | ||
38 | The chapter also provides sample configurations for basic example scenarios. | |
39 | ||
40 | @menu | |
41 | * Configuring VNC Services:: | |
42 | * Manual Address Control:: | |
43 | * Other VNC-Related Commands:: | |
44 | * Example VNC and VNC-GW Configurations:: | |
45 | * Release Notes:: | |
46 | @end menu | |
47 | ||
48 | @node Configuring VNC Services | |
49 | @section Configuring VNC | |
50 | ||
51 | Virtual Network Control (@acronym{VNC}) service configuration commands | |
52 | appear in the @code{router bgp} section of the BGPD configuration file | |
53 | (@pxref{BGP Configuration Examples}). The commands are broken down into | |
54 | the following areas: | |
55 | ||
56 | @menu | |
57 | * General VNC Configuration:: | |
58 | * RFP Related Configuration:: | |
59 | * VNC Defaults Configuration:: | |
60 | * VNC NVE Group Configuration:: | |
61 | * VNC L2 Group Configuration:: | |
62 | * Configuring Redistribution of Routes from Other Routing Protocols:: | |
63 | * Configuring Export of Routes to Other Routing Protocols:: | |
64 | @end menu | |
65 | ||
66 | @code{General VNC} configuration applies to general VNC operation and is | |
67 | primarily used to control the method used to advertise tunnel | |
68 | information. | |
69 | ||
70 | @code{Remote Forwarder Protocol (RFP)} configuration relates to the | |
71 | protocol used between NVAs and NVEs. | |
72 | ||
73 | @code{VNC Defaults} provides default parameters for registered NVEs. | |
74 | ||
75 | @code{VNC NVE Group} provides for configuration of a specific set of | |
76 | registered NVEs and overrides default parameters. | |
77 | ||
78 | @code{Redistribution} and @code{Export} control VNC-GW operation, i.e., | |
79 | the import/export of routing | |
80 | information between VNC and customer edge routers (@acronym{CE}s) | |
81 | operating within a VN. | |
82 | ||
83 | @node General VNC Configuration | |
84 | @subsection General VNC Configuration | |
85 | ||
86 | @deffn {VNC} {vnc advertise-un-method encap-safi|encap-attr} {} | |
87 | Advertise NVE underlay-network IP addresses using the encapsulation SAFI | |
88 | (@code{encap-safi}) or the UN address sub-TLV of the Tunnel Encapsulation attribute | |
89 | (@code{encap-attr}). When @code{encap-safi} is used, neighbors under | |
90 | @code{address-family encap} and/or @code{address-family encapv6} must be | |
91 | configured. The default is @code{encap-attr}. | |
92 | @end deffn | |
93 | ||
94 | @node RFP Related Configuration | |
95 | @subsection RFP Related Configuration | |
96 | ||
97 | The protocol that is used to communicate routing and Ethernet / L2 | |
98 | forwarding information between NVAs and NVEs is referred to as the | |
99 | Remote Forwarder Protocol (RFP). Currently, only a simple example RFP | |
438f5286 DS |
100 | is included in Frr. Developers may use this example as a starting |
101 | point to integrate Frr with an RFP of their choosing, e.g., | |
65efcfce LB |
102 | @code{OpenFlow}. The example code includes the following sample |
103 | configuration: | |
104 | ||
105 | @deffn {RFP} {rfp example-config-value @var{VALUE}} | |
106 | This is a simple example configuration parameter included as part of the | |
107 | RFP example code. @code{VALUE} must be in the range of 0 to 4294967295. | |
108 | @end deffn | |
109 | ||
110 | @node VNC Defaults Configuration | |
111 | @subsection VNC Defaults Configuration | |
112 | ||
113 | The VNC Defaults section allows the user to specify default values for | |
114 | configuration parameters for all registered NVEs. | |
115 | Default values are overridden by @ref{VNC NVE Group Configuration}. | |
116 | ||
117 | @deffn {VNC} {vnc defaults} {} | |
118 | Enter VNC configuration mode for specifying VNC default behaviors. Use | |
119 | @code{exit-vnc} to leave VNC configuration mode. @code{vnc | |
120 | defaults} is optional. | |
121 | ||
122 | @example | |
123 | vnc defaults | |
124 | ... various VNC defaults | |
125 | exit-vnc | |
126 | @end example | |
127 | @end deffn | |
128 | ||
129 | These are the statements that can appear between @code{vnc defaults} | |
130 | and @code{exit-vnc}. | |
131 | ||
132 | @deffn {VNC} {rt import @var{rt-list}} {} | |
133 | @deffnx {VNC} {rt export @var{rt-list}} {} | |
134 | @deffnx {VNC} {rt both @var{rt-list}} {} | |
135 | ||
136 | Specify default route target import and export lists. @var{rt-list} is a | |
137 | space-separated list of route targets, each element of which is | |
138 | in one of the following forms: | |
139 | @itemize | |
140 | @item @var{IPv4-address}:@var{two-byte-integer} | |
141 | @item @var{four-byte-autonomous-system-number}:@var{two-byte-integer} | |
142 | @item @var{two-byte-autonomous-system-number}:@var{four-byte-integer} | |
143 | @end itemize | |
144 | ||
145 | If no default import RT list is specified, then the default import RT | |
146 | list is empty. | |
147 | If no default export RT list is specified, then the default export RT | |
148 | list is empty. | |
149 | ||
150 | A complete definition of these parameters is | |
151 | given below (@pxref{VNC NVE Group Configuration}). | |
152 | ||
153 | @end deffn | |
154 | ||
155 | @deffn {VNC} {rd @var{route-distinguisher}} | |
156 | ||
157 | Specify the default route distinguisher (RD) for routes advertised via BGP | |
158 | VPNs. The route distinguisher must be in one of four forms: | |
159 | @itemize | |
160 | @item @var{IPv4-address}:@var{two-byte-integer} | |
161 | @item @var{four-byte-autonomous-system-number}:@var{two-byte-integer} | |
162 | @item @var{two-byte-autonomous-system-number}:@var{four-byte-integer} | |
163 | @item auto:vn:@var{two-byte-integer} | |
164 | @end itemize | |
165 | ||
166 | If RD is specified in the defaults section, the default RD | |
167 | value is @var{two-byte-autonomous-system-number=0}:@var{four-byte-integer=0}. | |
168 | ||
169 | A complete definition of this parameter is | |
170 | given below (@pxref{VNC NVE Group Configuration}). | |
171 | @end deffn | |
172 | ||
173 | @deffn {VNC} {l2rd @var{nve-id-value}} | |
174 | Set the value used to distinguish NVEs connected to the same logical | |
175 | Ethernet segment (i.e., L2VPN). | |
176 | ||
177 | A complete definition of this parameter is | |
178 | given below (@pxref{VNC NVE Group Configuration}). | |
179 | @end deffn | |
180 | ||
181 | @deffn {VNC} {response-lifetime @var{lifetime}|infinite} {} | |
182 | Specify the default lifetime to be included in RFP | |
183 | response messages sent to NVEs. | |
184 | ||
185 | A complete definition of this parameter is | |
186 | given below (@pxref{VNC NVE Group Configuration}). | |
187 | ||
188 | @end deffn | |
189 | ||
190 | @deffn {VNC} {export bgp|zebra route-map MAP-NAME} | |
191 | Specify that the named route-map should be applied to routes | |
192 | being exported to bgp or zebra. | |
193 | @end deffn | |
194 | ||
195 | @deffn {VNC} {export bgp|zebra no route-map} | |
196 | Specify that no route-map should be applied to routes | |
197 | being exported to bgp or zebra. | |
198 | @end deffn | |
199 | ||
200 | @deffn {VNC} {export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME} | |
201 | Specify that the named prefix-list filter should be applied to | |
202 | routes being exported to bgp or zebra. | |
203 | Prefix-lists for ipv4 and ipv6 are independent of each other. | |
204 | @end deffn | |
205 | ||
206 | @deffn {VNC} {export bgp|zebra no ipv4|ipv6 prefix-list} | |
207 | Specify that no prefix-list filter should be applied to | |
208 | routes being exported to bgp or zebra. | |
209 | @end deffn | |
210 | ||
211 | @deffn {VNC} {exit-vnc} {} | |
212 | Exit VNC configuration mode. | |
213 | @end deffn | |
214 | ||
215 | @c The following example @code{vnc defaults} defines a route target import-export | |
216 | @c list for the route targets 1000:1 and 1000:2; a default route | |
217 | @c distinguisher, 4444:10; and a default response lifetime of 500 | |
218 | @c seconds. | |
219 | @c | |
220 | @c @example | |
221 | @c vnc defaults | |
222 | @c rt both 1000:1 1000:2 | |
223 | @c rd 4444:10 | |
224 | @c response-lifetime 500 | |
225 | @c exit-vnc | |
226 | @c @end example | |
227 | ||
228 | @node VNC NVE Group Configuration | |
229 | @subsection VNC NVE Group Configuration | |
230 | ||
231 | A NVE Group corresponds to a specific set of NVEs. A Client NVE is | |
232 | assigned to an NVE Group based on whether there is a match for either | |
233 | its virtual or underlay network address against the VN and/or UN address | |
234 | prefixes specified in the NVE Group definition. When an NVE Group | |
235 | definition specifies both VN and UN address prefixes, then an NVE must | |
236 | match both prefixes in order to be assigned to the NVE Group. In the | |
237 | event that multiple NVE Groups match based on VN and/or UN addresses, | |
238 | the NVE is assigned to the first NVE Group listed in the configuration. | |
239 | If an NVE is not assigned to an NVE Group, its messages will be ignored. | |
240 | ||
241 | Configuration values specified for an NVE group apply to all | |
242 | member NVEs and override configuration values specified in the VNC | |
243 | Defaults section. | |
244 | ||
245 | @strong{At least one @code{nve-group} is mandatory for useful VNC | |
246 | operation.} | |
247 | ||
248 | @deffn {VNC} {vnc nve-group @var{name}} {} | |
249 | Enter VNC configuration mode for defining the NVE group @var{name}. | |
250 | Use @code{exit} or @code{exit-vnc} to exit group configuration mode. | |
251 | ||
252 | @example | |
253 | vnc nve-group group1 | |
254 | ... configuration commands | |
255 | exit-vnc | |
256 | @end example | |
257 | @end deffn | |
258 | ||
259 | @deffn {VNC} {no vnc nve-group @var{name}} {} | |
260 | Delete the NVE group named @var{name}. | |
261 | @end deffn | |
262 | ||
263 | The following statements are valid in an NVE group definition: | |
264 | ||
265 | @deffn {VNC} {l2rd @var{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 @code{auto:vn}, which | |
276 | means to use the least-significant octet of the originating | |
277 | NVE's VN address. | |
278 | @end deffn | |
279 | ||
280 | @deffn {VNC} {prefix vn|un A.B.C.D/M|X:X::X:X/M} {} | |
281 | @anchor{prefix} | |
282 | Specify the matching prefix for this NVE group by either virtual-network address | |
283 | (@code{vn}) or underlay-network address (@code{un}). Either or both virtual-network | |
284 | and underlay-network prefixes may be specified. Subsequent virtual-network or | |
285 | underlay-network values within a @code{vnc nve-group} @code{exit-vnc} | |
286 | block override their respective previous values. | |
287 | ||
288 | These prefixes are used only for determining assignments of NVEs | |
289 | to NVE Groups. | |
290 | @end deffn | |
291 | ||
292 | @deffn {VNC} {rd @var{route-distinguisher}} | |
293 | Specify the route distinguisher for routes advertised via BGP | |
294 | VPNs. The route distinguisher must be in one of these forms: | |
295 | @itemize | |
296 | @item @var{IPv4-address}:@var{two-byte-integer} | |
297 | @item @var{four-byte-autonomous-system-number}:@var{two-byte-integer} | |
298 | @item @var{two-byte-autonomous-system-number}:@var{four-byte-integer} | |
299 | @item auto:vn:@var{two-byte-integer} | |
300 | @end itemize | |
301 | ||
302 | Routes originated by NVEs in the NVE group will use | |
303 | the group's specified @var{route-distinguisher} when they are | |
304 | advertised via BGP. | |
305 | If the @code{auto} form is specified, it means that a matching NVE has | |
306 | its RD set to | |
307 | @var{rd_type=IP=1}:@var{IPv4-address=VN-address}:@var{two-byte-integer}, | |
308 | for IPv4 VN addresses and | |
309 | @var{rd_type=IP=1}:@var{IPv4-address=Last-four-bytes-of-VN-address}:@var{two-byte-integer}, | |
310 | for IPv6 VN addresses. | |
311 | ||
312 | If the NVE group definition does not specify a @var{route-distinguisher}, | |
313 | then the default @var{route-distinguisher} is used. | |
314 | If neither a group nor a default @var{route-distinguisher} is | |
315 | configured, then the advertised RD is set to | |
316 | @var{two-byte-autonomous-system-number=0}:@var{four-byte-integer=0}. | |
317 | @end deffn | |
318 | ||
319 | @deffn {VNC} {response-lifetime @var{lifetime}|infinite} {} | |
320 | Specify the response lifetime, in seconds, to be included in RFP | |
321 | response messages sent to NVEs. If the value | |
322 | ``infinite'' is given, an infinite lifetime will be used. | |
323 | ||
324 | Note that this parameter is not the same as the lifetime supplied by | |
325 | NVEs in RFP registration messages. This parameter does not affect | |
326 | the lifetime value attached to routes sent by this server via BGP. | |
327 | ||
328 | If the NVE group definition does not specify a @var{response-lifetime}, | |
329 | the default @var{response-lifetime} will be used. | |
330 | If neither a group nor a default @var{response-lifetime} is configured, | |
331 | the value 3600 will be used. The maximum response lifetime is 2147483647. | |
332 | @end deffn | |
333 | ||
334 | @deffn {VNC} {rt export @var{rt-list}} {} | |
335 | @deffnx {VNC} {rt import @var{rt-list}} {} | |
336 | @deffnx {VNC} {rt both @var{rt-list}} {} | |
337 | Specify route target import and export lists. @var{rt-list} is a | |
338 | space-separated list of route targets, each element of which is | |
339 | in one of the following forms: | |
340 | @itemize | |
341 | @item @var{IPv4-address}:@var{two-byte-integer} | |
342 | @item @var{four-byte-autonomous-system-number}:@var{two-byte-integer} | |
343 | @item @var{two-byte-autonomous-system-number}:@var{four-byte-integer} | |
344 | @end itemize | |
345 | ||
346 | The first form, @code{rt export}, specifies an @var{export rt-list}. | |
347 | The @var{export rt-list} will be attached to routes originated by | |
348 | NVEs in the NVE group when they are advertised via BGP. | |
349 | If the NVE group definition does not specify an @var{export rt-list}, | |
350 | then the default @var{export rt-list} is used. | |
351 | If neither a group nor a default @var{export rt-list} is configured, | |
352 | then no RT list will be sent; in turn, these routes will probably | |
353 | not be processed | |
354 | by receiving NVAs. | |
355 | ||
356 | The second form, @code{rt import} specifies an @var{import rt-list}, | |
357 | which is a filter for incoming routes. | |
358 | In order to be made available to NVEs in the group, | |
359 | incoming BGP VPN and @w{ENCAP} @w{SAFI} (when @code{vnc | |
360 | advertise-un-method encap-safi} is set) routes must have | |
361 | RT lists that have at least one route target in common with the | |
362 | group's @var{import rt-list}. | |
363 | ||
364 | If the NVE group definition does not specify an import filter, | |
365 | then the default @var{import rt-list} is used. | |
366 | If neither a group nor a default @var{import rt-list} is configured, | |
367 | there can be no RT intersections when receiving BGP routes and | |
368 | therefore no incoming BGP routes will be processed for the group. | |
369 | ||
370 | The third, @code{rt both}, is a shorthand way of specifying both | |
371 | lists simultaneously, and is equivalent to @code{rt export @var{rt-list}} | |
372 | followed by @code{rt import @var{rt-list}}. | |
373 | @end deffn | |
374 | ||
375 | @deffn {VNC} {export bgp|zebra route-map MAP-NAME} | |
376 | Specify that the named route-map should be applied to routes | |
377 | being exported to bgp or zebra. | |
378 | This paramter is used in conjunction with | |
379 | @ref{Configuring Export of Routes to Other Routing Protocols}. | |
380 | This item is optional. | |
381 | @end deffn | |
382 | ||
383 | @deffn {VNC} {export bgp|zebra no route-map} | |
384 | Specify that no route-map should be applied to routes | |
385 | being exported to bgp or zebra. | |
386 | This paramter is used in conjunction with | |
387 | @ref{Configuring Export of Routes to Other Routing Protocols}. | |
388 | This item is optional. | |
389 | @end deffn | |
390 | ||
391 | @deffn {VNC} {export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME} | |
392 | Specify that the named prefix-list filter should be applied to | |
393 | routes being exported to bgp or zebra. | |
394 | Prefix-lists for ipv4 and ipv6 are independent of each other. | |
395 | This paramter is used in conjunction with | |
396 | @ref{Configuring Export of Routes to Other Routing Protocols}. | |
397 | This item is optional. | |
398 | @end deffn | |
399 | ||
400 | @deffn {VNC} {export bgp|zebra no ipv4|ipv6 prefix-list} | |
401 | Specify that no prefix-list filter should be applied to | |
402 | routes being exported to bgp or zebra. | |
403 | This paramter is used in conjunction with | |
404 | @ref{Configuring Export of Routes to Other Routing Protocols}. | |
405 | This item is optional. | |
406 | @end deffn | |
407 | ||
408 | @c The following example shows two @code{vnc nve-group} definitions. The first one, | |
409 | @c ``group1'', applies to the IPV4 virtual-network route prefix 172.16/16. It | |
410 | @c sets the response lifetime to 200 seconds. It defines a route target | |
411 | @c import-export filter for the route targets 1000:1 and 1000:2 | |
412 | @c | |
413 | @c The second @code{vnc nve-group} definition, ``group2'', applies to the IPV6 | |
414 | @c underlay-network route prefix 10.0.2/24. It defines the same response | |
415 | @c lifetime and import-export filter as ``group1''. | |
416 | @c | |
417 | @c @example | |
418 | @c vnc nve-group group1 | |
419 | @c prefix vn 172.16/16 | |
420 | @c response-lifetime 200 | |
421 | @c rt both 1000:1 1000:2 | |
422 | @c exit-vnc | |
423 | @c | |
424 | @c vnc nve-group group2 | |
425 | @c prefix un 10.0.2/24 | |
426 | @c response-lifetime 200 | |
427 | @c rt both 1000:1 1000:2 | |
428 | @c exit-vnc | |
429 | @c @end example | |
430 | ||
431 | @node VNC L2 Group Configuration | |
432 | @subsection VNC L2 Group Configuration | |
433 | ||
434 | The route targets advertised with prefixes and addresses registered by | |
435 | an NVE are determined based on the NVE's associated VNC NVE Group | |
436 | Configuration, @pxref{VNC NVE Group Configuration}. Layer 2 (L2) Groups | |
437 | are used to override the route targets for an NVE's Ethernet | |
438 | registrations based on the Logical Network Identifier and label value. | |
439 | A Logical Network Identifier is used to uniquely identify a logical | |
440 | Ethernet segment and is conceptually similar to the Ethernet Segment | |
441 | Identifier defined in @cite{RFC7432, BGP MPLS-Based Ethernet VPN}. Both | |
442 | the Logical Network Identifier and Label are passed to VNC via RFP | |
443 | prefix and address registration. | |
444 | ||
445 | Note that a corresponding NVE group configuration must be present, and | |
446 | that other NVE associated configuration information, notably RD, is | |
447 | not impacted by L2 Group Configuration. | |
448 | ||
449 | @deffn {VNC} {vnc l2-group @var{name}} {} | |
450 | Enter VNC configuration mode for defining the L2 group @var{name}. | |
451 | Use @code{exit} or @code{exit-vnc} to exit group configuration mode. | |
452 | ||
453 | @example | |
454 | vnc l2-group group1 | |
455 | ... configuration commands | |
456 | exit-vnc | |
457 | @end example | |
458 | @end deffn | |
459 | ||
460 | @deffn {VNC} {no vnc l2-group @var{name}} {} | |
461 | Delete the L2 group named @var{name}. | |
462 | @end deffn | |
463 | ||
464 | The following statements are valid in a L2 group definition: | |
465 | ||
466 | @deffn {VNC} {logical-network-id @var{VALUE}} | |
467 | Define the Logical Network Identifier with a value in the range of | |
468 | 0-4294967295 that identifies the logical Ethernet segment. | |
469 | @end deffn | |
470 | ||
471 | @deffn {VNC} {labels @var{label-list}} | |
472 | @deffnx {VNC} {no labels @var{label-list}} | |
473 | Add or remove labels associated with the group. @var{label-list} is a | |
474 | space separated list of label values in the range of 0-1048575. | |
475 | @end deffn | |
476 | ||
477 | @deffn {VNC} {rt import @var{rt-target}} {} | |
478 | @deffnx {VNC} {rt export @var{rt-target}} {} | |
479 | @deffnx {VNC} {rt both @var{rt-target}} {} | |
480 | Specify the route target import and export value associated with the | |
481 | group. A complete definition of these parameters is given above, | |
482 | @pxref{VNC NVE Group Configuration}. | |
483 | @end deffn | |
484 | ||
485 | ||
486 | @node Configuring Redistribution of Routes from Other Routing Protocols | |
487 | @subsection Configuring Redistribution of Routes from Other Routing Protocols | |
488 | ||
489 | Routes from other protocols (including BGP) can be provided to VNC (both | |
490 | for RFP and for redistribution via BGP) | |
491 | from three sources: the zebra kernel routing process; | |
492 | directly from the main (default) unicast BGP RIB; or directly | |
493 | from a designated BGP unicast exterior routing RIB instance. | |
494 | ||
495 | The protocol named in the @code{vnc redistribute} command indicates | |
496 | the route source: | |
497 | @code{bgp-direct} routes come directly from the main (default) | |
498 | unicast BGP RIB and are available for RFP and are redistributed via BGP; | |
499 | @code{bgp-direct-to-nve-groups} routes come directly from a designated | |
500 | BGP unicast routing RIB and are made available only to RFP; | |
501 | and routes from other protocols come from the zebra kernel | |
502 | routing process. | |
503 | Note that the zebra process does not need to be active if | |
504 | only @code{bgp-direct} or @code{bgp-direct-to-nve-groups} routes are used. | |
505 | ||
506 | @subsubsection @code{zebra} routes | |
507 | ||
508 | Routes originating from protocols other than BGP must be obtained | |
509 | via the zebra routing process. | |
510 | Redistribution of these routes into VNC does not support policy mechanisms | |
511 | such as prefix-lists or route-maps. | |
512 | ||
513 | @subsubsection @code{bgp-direct} routes | |
514 | ||
515 | @code{bgp-direct} redistribution supports policy via | |
516 | prefix lists and route-maps. This policy is applied to incoming | |
517 | original unicast routes before the redistribution translations | |
518 | (described below) are performed. | |
519 | ||
520 | Redistribution of @code{bgp-direct} routes is performed in one of three | |
521 | possible modes: @code{plain}, @code{nve-group}, or @code{resolve-nve}. | |
522 | The default mode is @code{plain}. | |
523 | These modes indicate the kind of translations applied to routes before | |
524 | they are added to the VNC RIB. | |
525 | ||
526 | In @code{plain} mode, the route's next hop is unchanged and the RD is set | |
527 | based on the next hop. | |
528 | For @code{bgp-direct} redistribution, the following translations are performed: | |
529 | @itemize @bullet | |
530 | @item | |
531 | The VN address is set to the original unicast route's next hop address. | |
532 | @item | |
533 | The UN address is NOT set. (VN->UN mapping will occur via | |
534 | ENCAP route or attribute, based on @code{vnc advertise-un-method} | |
535 | setting, generated by the RFP registration of the actual NVE) | |
536 | @item | |
537 | The RD is set to as if auto:vn:0 were specified (i.e., | |
538 | @var{rd_type=IP=1}:@var{IPv4-address=VN-address}:@var{two-byte-integer=0}) | |
539 | @item | |
540 | The RT list is included in the extended community list copied from the | |
541 | original unicast route (i.e., it must be set in the original unicast route). | |
542 | @end itemize | |
543 | ||
544 | ||
545 | ||
546 | In @code{nve-group} mode, routes are registered with VNC as | |
547 | if they came from an NVE in the nve-group designated in the | |
548 | @code{vnc redistribute nve-group} command. The following | |
549 | translations are performed: | |
550 | ||
551 | @itemize @bullet | |
552 | @item | |
553 | The next hop/VN address is set to the VN prefix configured for the | |
554 | redistribute nve-group. | |
555 | @item | |
556 | The UN address is set to the UN prefix configured for the | |
557 | redistribute nve-group. | |
558 | @item | |
559 | The RD is set to the RD configured for the redistribute nve-group. | |
560 | @item | |
561 | The RT list is set to the RT list configured for the redistribute nve-group. | |
562 | If @code{bgp-direct} routes are being redistributed, | |
563 | any extended communities present in the original unicast route | |
564 | will also be included. | |
565 | @end itemize | |
566 | ||
567 | ||
568 | In @code{resolve-nve} mode, the next hop of the original BGP route is | |
569 | typically the address of an NVE connected router (CE) connected by one or | |
570 | more NVEs. | |
571 | Each of the connected NVEs will register, via RFP, a VNC host route | |
572 | to the CE. | |
573 | This mode may be though of as a mechanism to proxy RFP registrations | |
574 | of BGP unicast routes on behalf of registering NVEs. | |
575 | ||
576 | Multiple copies of the BGP route, one per matching NVE host route, will be | |
577 | added to VNC. | |
578 | In other words, for a given BGP unicast route, each instance of a | |
579 | RFP-registered host route to the unicast route's next hop will result | |
580 | in an instance of an imported VNC route. | |
581 | Each such imported VNC route will have a prefix equal to the original | |
582 | BGP unicast route's prefix, and a next hop equal to the next hop of the | |
583 | matching RFP-registered host route. | |
584 | If there is no RFP-registered host route to the next hop of the BGP unicast | |
585 | route, no corresponding VNC route will be imported. | |
586 | ||
587 | The following translations are applied: | |
588 | ||
589 | @itemize @bullet | |
590 | @item | |
591 | The Next Hop is set to the next hop of the NVE route (i.e., the | |
592 | VN address of the NVE). | |
593 | ||
594 | @item | |
595 | The extended community list in the new route is set to the | |
596 | union of: | |
597 | @itemize @minus | |
598 | @item | |
599 | Any extended communities in the original BGP route | |
600 | @item | |
601 | Any extended communities in the NVE route | |
602 | @item | |
603 | An added route-origin extended community with the next hop of the | |
604 | original BGP route | |
605 | is added to the new route. | |
606 | The value of the local administrator field defaults 5226 but may | |
607 | be configured by the user via the @code{roo-ec-local-admin} parameter. | |
608 | @end itemize | |
609 | ||
610 | @item | |
611 | The Tunnel Encapsulation attribute is set to the value of the Tunnel | |
612 | Encapsulation attribute of the NVE route, if any. | |
613 | ||
614 | @end itemize | |
615 | ||
616 | @subsubsection @code{bgp-direct-to-nve-groups} routes | |
617 | ||
618 | Unicast routes from the main or a designated instance of BGP | |
619 | may be redistributed to VNC as bgp-direct-to-nve-groups routes. These | |
620 | routes are NOT announced via BGP, | |
621 | but they are made available for local RFP lookup in response to | |
622 | queries from NVEs. | |
623 | ||
624 | A non-main/default BGP instance is configured using the | |
625 | @code{bgp multiple-instance} and @code{router bgp AS view NAME} | |
626 | commands as described elsewhere in this document. | |
627 | ||
628 | In order for a route in the unicast BGP RIB to be made | |
629 | available to a querying NVE, there must already be, available to | |
630 | that NVE, an (interior) VNC route matching the next hop address | |
631 | of the unicast route. | |
632 | When the unicast route is provided to the NVE, its next hop | |
633 | is replaced by the next hop of the corresponding | |
634 | NVE. If there are multiple longest-prefix-match VNC routes, | |
635 | the unicast route will be replicated for each. | |
636 | ||
637 | There is currently no policy (prefix-list or route-map) support | |
638 | for @code{bgp-direct-to-nve-groups} routes. | |
639 | ||
640 | @subsubsection Redistribution Command Syntax | |
641 | ||
642 | @deffn {VNC} {vnc redistribute ipv4|ipv6 bgp|bgp-direct|ipv6 bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static} {} | |
643 | @deffnx {VNC} {vnc redistribute ipv4|ipv6 bgp-direct-to-nve-groups view @var{VIEWNAME}} {} | |
644 | @deffnx {VNC} {no vnc redistribute ipv4|ipv6 bgp|bgp-direct|bgp-direct-to-nve-groups|connected|kernel|ospf|rip|static} {} | |
645 | Import (or do not import) prefixes from another routing | |
646 | protocols. Specify both the address family to import (@code{ipv4} or | |
647 | @code{ipv6}) and the protocol (@code{bgp}, @code{bgp-direct}, | |
648 | @code{bgp-direct-to-nve-groups}, @code{connected}, | |
649 | @code{kernel}, @code{ospf}, @code{rip}, or @code{static}). Repeat | |
650 | this statement as needed for each combination of address family and | |
651 | routing protocol. | |
652 | Prefixes from protocol @code{bgp-direct} are imported from unicast BGP | |
653 | in the same bgpd process. | |
654 | Prefixes from all other protocols (including @code{bgp}) are imported | |
655 | via the @code{zebra} kernel routing process. | |
656 | @end deffn | |
657 | ||
658 | @deffn {VNC} {vnc redistribute mode plain|nve-group|resolve-nve} | |
659 | Redistribute routes from other protocols into VNC using the | |
660 | specified mode. | |
661 | Not all combinations of modes and protocols are supported. | |
662 | @end deffn | |
663 | ||
664 | @deffn {VNC} {vnc redistribute nve-group @var{group-name}} {} | |
665 | @deffnx {VNC} {no vnc redistribute nve-group @var{group-name}} {} | |
666 | When using @code{nve-group} mode, | |
667 | assign (or do not assign) the NVE group @var{group-name} to routes | |
668 | redistributed from another routing protocol. @var{group-name} | |
669 | must be configured using @code{vnc nve-group}. | |
670 | ||
671 | The VN and UN prefixes of the nve-group must both be configured, | |
672 | and each prefix must be specified as a full-length (/32 for IPv4, | |
673 | /128 for IPv6) prefix. | |
674 | @end deffn | |
675 | ||
676 | @deffn {VNC} {vnc redistribute lifetime @var{lifetime}|infinite} {} | |
677 | Assign a registration lifetime, either @var{lifetime} seconds or | |
678 | @code{infinite}, to prefixes redistributed from other routing | |
679 | protocols as if they had been received via RFP registration messages | |
680 | from an NVE. @var{lifetime} can be any integer between 1 and | |
681 | 4294967295, inclusive. | |
682 | @end deffn | |
683 | ||
684 | @deffn {VNC} {vnc redistribute resolve-nve roo-ec-local-admin @var{0-65536}} | |
685 | Assign a value to the local-administrator subfield used in the | |
686 | Route Origin extended community that is assigned to routes exported | |
687 | under the @code{resolve-nve} mode. The default value is @var{5226}. | |
688 | @end deffn | |
689 | ||
690 | The following four @code{prefix-list} and @code{route-map} commands | |
691 | may be specified in the context of an nve-group or not. | |
692 | If they are specified in the context of an nve-group, they | |
693 | apply only if the redistribution mode is @code{nve-group}, | |
694 | and then only for routes being redistributed from | |
695 | @code{bgp-direct}. | |
696 | If they are specified outside the context of an nve-group, then | |
697 | they apply only for redistribution modes @code{plain} and @code{resolve-nve}, | |
698 | and then only for routes being redistributed from @code{bgp-direct}. | |
699 | ||
700 | @deffn {VNC} {vnc redistribute bgp-direct (ipv4|ipv6) prefix-list @var{LIST-NAME}} | |
701 | When redistributing @code{bgp-direct} routes, | |
702 | specifies that the named prefix-list should be applied. | |
703 | @end deffn | |
704 | ||
705 | @deffn {VNC} {vnc redistribute bgp-direct no (ipv4|ipv6) prefix-list} | |
706 | When redistributing @code{bgp-direct} routes, | |
707 | specifies that no prefix-list should be applied. | |
708 | @end deffn | |
709 | ||
710 | @deffn {VNC} {vnc redistribute bgp-direct route-map @var{MAP-NAME}} | |
711 | When redistributing @code{bgp-direct} routes, | |
712 | specifies that the named route-map should be applied. | |
713 | @end deffn | |
714 | ||
715 | @deffn {VNC} {vnc redistribute bgp-direct no route-map} | |
716 | When redistributing @code{bgp-direct} routes, | |
717 | specifies that no route-map should be applied. | |
718 | @end deffn | |
719 | ||
720 | @node Configuring Export of Routes to Other Routing Protocols | |
721 | @subsection Configuring Export of Routes to Other Routing Protocols | |
722 | ||
723 | Routes from VNC (both for RFP and for redistribution via BGP) can be | |
724 | provided to other protocols, either via zebra or directly to BGP. | |
725 | ||
726 | It is important to note that when exporting routes to other protocols, | |
727 | the downstream protocol must also be configured to import the routes. | |
728 | For example, when VNC routes are exported to unicast BGP, the BGP | |
5ee62c66 | 729 | configuration must include a corresponding @code{redistribute vnc-direct} |
65efcfce LB |
730 | statement. |
731 | ||
732 | @deffn {VNC} {export bgp|zebra mode none|group-nve|registering-nve|ce} | |
733 | Specify how routes should be exported to bgp or zebra. | |
734 | If the mode is @code{none}, routes are not exported. | |
735 | If the mode is @code{group-nve}, routes are exported according | |
736 | to nve-group configuration (@pxref{VNC NVE Group Configuration}): if a group is configured to | |
737 | allow export, then each prefix visible to the group is exported | |
738 | with next hops set to the currently-registered NVEs. | |
739 | If the mode is @code{registering-nve}, then all VNC routes are | |
740 | exported with their original next hops. | |
741 | If the mode is @code{ce}, only VNC routes that have an NVE connected CE Router | |
742 | encoded in a Route Origin Extended Community are exported. | |
743 | This extended community must have an administrative value that | |
744 | matches the configured @code{roo-ec-local-admin} value. | |
745 | The next hop of the exported route is set to the encoded | |
746 | NVE connected CE Router. | |
747 | ||
748 | The default for both bgp and zebra is mode @code{none}. | |
749 | @end deffn | |
750 | ||
751 | @deffn {VNC} {vnc export bgp|zebra group-nve group @var{group-name}} | |
752 | @deffnx {VNC} {vnc export bgp|zebra group-nve no group @var{group-name}} | |
753 | When export mode is @code{group-nve}, | |
754 | export (or do not export) prefixes from the specified nve-group | |
755 | to unicast BGP or to zebra. | |
756 | Repeat this statement as needed for each nve-group to be exported. | |
757 | Each VNC prefix that is exported will result in N exported routes to the | |
758 | prefix, each with a next hop corresponding to one of the N NVEs currently | |
759 | associated with the nve-group. | |
760 | @end deffn | |
761 | ||
762 | @deffn {VNC} export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME | |
763 | When export mode is @code{ce} or @code{registering-nve}, | |
764 | specifies that the named prefix-list should be applied to routes | |
765 | being exported to bgp or zebra. | |
766 | Prefix-lists for ipv4 and ipv6 are independent of each other. | |
767 | @end deffn | |
768 | ||
769 | @deffn {VNC} export bgp|zebra no ipv4|ipv6 prefix-list | |
770 | When export mode is @code{ce} or @code{registering-nve}, | |
771 | specifies that no prefix-list should be applied to routes | |
772 | being exported to bgp or zebra. | |
773 | @end deffn | |
774 | ||
775 | @deffn {VNC} export bgp|zebra route-map MAP-NAME | |
776 | When export mode is @code{ce} or @code{registering-nve}, | |
777 | specifies that the named route-map should be applied to routes | |
778 | being exported to bgp or zebra. | |
779 | @end deffn | |
780 | ||
781 | @deffn {VNC} export bgp|zebra no route-map | |
782 | When export mode is @code{ce} or @code{registering-nve}, | |
783 | specifies that no route-map should be applied to routes | |
784 | being exported to bgp or zebra. | |
785 | @end deffn | |
786 | ||
787 | When the export mode is @code{group-nve}, policy for exported | |
788 | routes is specified per-NVE-group inside a @code{nve-group} @var{RFG-NAME} block | |
789 | via the following commands(@pxref{VNC NVE Group Configuration}): | |
790 | ||
791 | @deffn {VNC} {export bgp|zebra route-map MAP-NAME} | |
792 | This command is valid inside a @code{nve-group} @var{RFG-NAME} block. | |
793 | It specifies that the named route-map should be applied to routes | |
794 | being exported to bgp or zebra. | |
795 | @end deffn | |
796 | ||
797 | @deffn {VNC} {export bgp|zebra no route-map} | |
798 | This command is valid inside a @code{nve-group} @var{RFG-NAME} block. | |
799 | It specifies that no route-map should be applied to routes | |
800 | being exported to bgp or zebra. | |
801 | @end deffn | |
802 | ||
803 | @deffn {VNC} {export bgp|zebra ipv4|ipv6 prefix-list LIST-NAME} | |
804 | This command is valid inside a @code{nve-group} @var{RFG-NAME} block. | |
805 | It specifies that the named prefix-list filter should be applied to | |
806 | routes being exported to bgp or zebra. | |
807 | Prefix-lists for ipv4 and ipv6 are independent of each other. | |
808 | @end deffn | |
809 | ||
810 | @deffn {VNC} {export bgp|zebra no ipv4|ipv6 prefix-list} | |
811 | This command is valid inside a @code{nve-group} @var{RFG-NAME} block. | |
812 | It specifies that no prefix-list filter should be applied to | |
813 | routes being exported to bgp or zebra. | |
814 | @end deffn | |
815 | ||
816 | @node Manual Address Control | |
817 | @section Manual Address Control | |
818 | ||
819 | The commands in this section can be used to augment normal dynamic VNC. | |
820 | The @code{add vnc} commands can be used to manually add IP prefix or | |
821 | Ethernet MAC address forwarding information. The @code{clear vnc} | |
822 | commands can be used to remove manually and dynamically added | |
823 | information. | |
824 | ||
825 | @deffn {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>]]} {} | |
826 | Register an IP prefix on behalf of the NVE identified by the VN and UN | |
827 | addresses. The @code{cost} parameter provides the administrative | |
828 | preference of the forwarding information for remote advertisement. If | |
829 | omitted, it defaults to 255 (lowest preference). The @code{lifetime} | |
830 | parameter identifies the period, in seconds, that the information | |
831 | remains valid. If omitted, it defaults to @var{infinite}. The optional | |
832 | @code{local-next-hop} parameter is used to configure a nexthop to be | |
833 | used by an NVE to reach the prefix via a locally connected CE router. | |
834 | This information remains local to the NVA, i.e., not passed to other | |
835 | NVAs, and is only passed to registered NVEs. When specified, it is also | |
836 | possible to provide a @code{local-cost} parameter to provide a | |
837 | forwarding preference. If omitted, it defaults to 255 (lowest | |
838 | preference). | |
839 | @end deffn | |
840 | ||
841 | ||
842 | @deffn {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>)]} {} | |
843 | Register a MAC address for a logical Ethernet (L2VPN) on behalf of the | |
844 | NVE identified by the VN and UN addresses. | |
845 | The optional @code{prefix} parameter is to support enable IP address | |
846 | mediation for the given prefix. The @code{cost} parameter provides the administrative | |
847 | preference of the forwarding information. If omitted, it defaults to | |
848 | 255. The @code{lifetime} parameter identifies the period, in seconds, | |
849 | that the information remains valid. If omitted, it defaults to | |
850 | @var{infinite}. | |
851 | @end deffn | |
852 | ||
853 | @deffn {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)])} {} | |
854 | Delete the information identified by prefix, VN address, and UN address. | |
855 | Any or all of these parameters may be wilcarded to (potentially) match | |
856 | more than one registration. | |
857 | The optional @code{mac} parameter specifies a layer-2 MAC address | |
858 | that must match the registration(s) to be deleted. | |
859 | The optional @code{local-next-hop} parameter is used to | |
860 | delete specific local nexthop information. | |
861 | @end deffn | |
862 | ||
863 | @deffn {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)])} {} | |
864 | Delete mac forwarding information. | |
865 | Any or all of these parameters may be wilcarded to (potentially) match | |
866 | more than one registration. | |
867 | The default value for the @code{prefix} parameter is the wildcard value @var{*}. | |
868 | @end deffn | |
869 | ||
870 | @deffn {Command} {clear vnc nve (*|((vn|un) (A.B.C.D|X:X::X:X) [(un|vn) (A.B.C.D|X:X::X:X)])) } {} | |
871 | Delete prefixes associated with the NVE specified by the given VN and UN | |
872 | addresses. | |
873 | It is permissible to specify only one of VN or UN, in which case | |
874 | any matching registration will be deleted. | |
875 | It is also permissible to specify @code{*} in lieu of any VN or UN | |
876 | address, in which case all registrations will match. | |
877 | @end deffn | |
878 | ||
879 | @node Other VNC-Related Commands | |
880 | @section Other VNC-Related Commands | |
881 | ||
882 | Note: VNC-Related configuration can be obtained via the @code{show | |
883 | running-configuration} command when in @code{enable} mode. | |
884 | ||
885 | The following commands are used to clear and display | |
886 | Virtual Network Control related information: | |
887 | ||
888 | @deffn {COMMAND} {clear vnc counters} {} | |
889 | Reset the counter values stored by the NVA. Counter | |
890 | values can be seen using the @code{show vnc} commands listed above. This | |
891 | command is only available in @code{enable} mode. | |
892 | @end deffn | |
893 | ||
894 | @deffn {Command} {show vnc summary} {} | |
895 | Print counter values and other general information | |
896 | about the NVA. Counter values can be reset | |
897 | using the @code{clear vnc counters} command listed below. | |
898 | @end deffn | |
899 | ||
900 | @deffn {Command} {show vnc nves} {} | |
901 | @deffnx {Command} {show vnc nves vn|un @var{address}} {} | |
902 | Display the NVA's current clients. Specifying @var{address} | |
903 | limits the output to the NVEs whose addresses match @var{address}. | |
904 | The time since the NVA last communicated with the NVE, per-NVE | |
905 | summary counters and each NVE's addresses will be displayed. | |
906 | @end deffn | |
907 | ||
908 | @deffn {Command} {show vnc queries} {} | |
909 | @deffnx {Command} {show vnc queries @var{prefix}} {} | |
910 | Display active Query information. Queries remain valid for the default | |
911 | Response Lifetime (@pxref{VNC Defaults Configuration}) or NVE-group | |
912 | Response Lifetime (@pxref{VNC NVE Group Configuration}). Specifying | |
913 | @var{prefix} limits the output to Query Targets that fall within | |
914 | @var{prefix}. | |
915 | ||
916 | Query information is provided for each querying NVE, and includes the | |
917 | Query Target and the time remaining before the information is removed. | |
918 | @end deffn | |
919 | ||
920 | @deffn {Command} {show vnc registrations [all|local|remote|holddown|imported]} {} | |
921 | @deffnx {Command} {show vnc registrations [all|local|remote|holddown|imported] @var{prefix}} {} | |
922 | Display local, remote, holddown, and/or imported registration information. | |
923 | Local registrations are routes received via RFP, which are present in the | |
924 | NVA Registrations Cache. | |
925 | Remote registrations are routes received via BGP (VPN SAFIs), which | |
926 | are present in the NVE-group import tables. | |
927 | Holddown registrations are local and remote routes that have been | |
928 | withdrawn but whose holddown timeouts have not yet elapsed. | |
929 | Imported information represents routes that are imported into NVA and | |
930 | are made available to querying NVEs. Depending on configuration, | |
931 | imported routes may also be advertised via BGP. | |
932 | Specifying @var{prefix} limits the output to the registered prefixes that | |
933 | fall within @var{prefix}. | |
934 | ||
935 | Registration information includes the registered prefix, the registering | |
936 | NVE addresses, the registered administrative cost, the registration | |
937 | lifetime and the time since the information was registered or, in the | |
938 | case of Holddown registrations, the amount of time remaining before the | |
939 | information is removed. | |
940 | @end deffn | |
941 | ||
942 | @deffn {Command} {show vnc responses [active|removed]} {} | |
943 | @deffnx {Command} {show vnc responses [active|removed] @var{prefix}} {} | |
944 | Display all, active and/or removed response information which are | |
945 | present in the NVA Responses Cache. Responses remain valid for the | |
946 | default Response Lifetime (@pxref{VNC Defaults Configuration}) or | |
947 | NVE-group Response Lifetime (@pxref{VNC NVE Group Configuration}.) | |
948 | When Removal Responses are enabled (@pxref{General VNC Configuration}), | |
949 | such responses are listed for the Response Lifetime. Specifying | |
950 | @var{prefix} limits the output to the addresses that fall within | |
951 | @var{prefix}. | |
952 | ||
953 | Response information is provided for each querying NVE, and includes | |
954 | the response prefix, the prefix-associated registering NVE addresses, | |
955 | the administrative cost, the provided response lifetime and the time | |
956 | remaining before the information is to be removed or will become inactive. | |
957 | @end deffn | |
958 | ||
959 | @deffn {Command} {show memory vnc} {} | |
960 | Print the number of memory items allocated by the NVA. | |
961 | @end deffn | |
962 | ||
963 | @node Example VNC and VNC-GW Configurations | |
964 | @section Example VNC and VNC-GW Configurations | |
965 | ||
966 | @menu | |
967 | * Mesh NVA Configuration:: | |
968 | * Mesh NVA and VNC-GW Configuration:: | |
438f5286 | 969 | * VNC with Frr Route Reflector Configuration:: |
65efcfce LB |
970 | * VNC with Commercial Route Reflector Configuration:: |
971 | * VNC with Redundant Route Reflectors Configuration:: | |
972 | @c * Interfacing VNC to an IGP:: | |
973 | @end menu | |
974 | ||
975 | @node Mesh NVA Configuration | |
976 | @subsection Mesh NVA Configuration | |
977 | ||
978 | This example includes three NVAs, nine NVEs, and two NVE groups. Note | |
979 | that while not shown, a single physical device may support multiple | |
980 | logical NVEs. @ref{fig:fig-vnc-mesh} shows @code{NVA 1} | |
981 | (192.168.1.100), @code{NVA 2} (192.168.1.101), and @code{NVA 3} | |
982 | (192.168.1.102), which are connected in a full mesh. Each is a | |
983 | member of the autonomous system 64512. Each NVA provides VNC | |
984 | services to three NVE clients in the 172.16.0.0/16 virtual-network | |
985 | address range. The 172.16.0.0/16 address range is partitioned into | |
986 | two NVE groups, @code{group1} (172.16.0.0/17) and @code{group2} | |
987 | (172.16.128.0/17). | |
988 | ||
989 | Each NVE belongs to either NVE group @code{group1} or NVE group | |
990 | @code{group2}. The NVEs @code{NVE 1}, @code{NVE 2}, @code{NVE | |
991 | 4}, @code{NVE 7}, and @code{NVE 8} are members of the NVE group | |
992 | @code{group1}. The NVEs @code{NVE 3}, @code{NVE 5}, @code{NVE | |
993 | 6}, and @code{NVE 9} are members of the NVE group @code{group2}. | |
994 | ||
995 | Each NVA advertises NVE underlay-network IP addresses using the | |
996 | Tunnel Encapsulation Attribute. | |
997 | ||
998 | @float Figure,fig:fig-vnc-mesh | |
999 | @center @image{fig-vnc-mesh,400pt,,Three-way Mesh} | |
1000 | @caption{A three-way full mesh with three NVEs per NVA} | |
1001 | @end float | |
1002 | ||
1003 | @file{bgpd.conf} for @code{NVA 1} (192.168.1.100) | |
1004 | @verbatim | |
1005 | router bgp 64512 | |
1006 | ||
1007 | bgp router-id 192.168.1.100 | |
1008 | ||
1009 | neighbor 192.168.1.101 remote-as 64512 | |
1010 | neighbor 192.168.1.102 remote-as 64512 | |
1011 | ||
1012 | address-family vpnv4 | |
1013 | neighbor 192.168.1.101 activate | |
1014 | neighbor 192.168.1.102 activate | |
1015 | exit-address-family | |
1016 | ||
1017 | vnc defaults | |
1018 | rd 64512:1 | |
1019 | response-lifetime 200 | |
1020 | rt both 1000:1 1000:2 | |
1021 | exit-vnc | |
1022 | ||
1023 | vnc nve-group group1 | |
1024 | prefix vn 172.16.0.0/17 | |
1025 | rt both 1000:1 | |
1026 | exit-vnc | |
1027 | ||
1028 | vnc nve-group group2 | |
1029 | prefix vn 172.16.128.0/17 | |
1030 | rt both 1000:2 | |
1031 | exit-vnc | |
1032 | ||
1033 | exit | |
1034 | @end verbatim | |
1035 | ||
1036 | @file{bgpd.conf} for @code{NVA 2} (192.168.1.101): | |
1037 | @verbatim | |
1038 | router bgp 64512 | |
1039 | ||
1040 | bgp router-id 192.168.1.101 | |
1041 | ||
1042 | neighbor 192.168.1.100 remote-as 64512 | |
1043 | neighbor 192.168.1.102 remote-as 64512 | |
1044 | ||
1045 | address-family vpnv4 | |
1046 | neighbor 192.168.1.100 activate | |
1047 | neighbor 192.168.1.102 activate | |
1048 | exit-address-family | |
1049 | ||
1050 | vnc nve-group group1 | |
1051 | prefix vn 172.16.0.0/17 | |
1052 | rd 64512:1 | |
1053 | response-lifetime 200 | |
1054 | rt both 1000:1 1000:2 | |
1055 | exit-vnc | |
1056 | exit | |
1057 | @end verbatim | |
1058 | ||
1059 | @file{bgpd.conf} for @code{NVA 3} (192.168.1.102): | |
1060 | @verbatim | |
1061 | router bgp 64512 | |
1062 | ||
1063 | bgp router-id 192.168.1.102 | |
1064 | ||
1065 | neighbor 192.168.1.101 remote-as 64512 | |
1066 | neighbor 192.168.1.102 remote-as 64512 | |
1067 | ||
1068 | address-family vpnv4 | |
1069 | neighbor 192.168.1.100 activate | |
1070 | neighbor 192.168.1.101 activate | |
1071 | exit-address-family | |
1072 | ||
1073 | vnc defaults | |
1074 | rd 64512:1 | |
1075 | response-lifetime 200 | |
1076 | rt both 1000:1 1000:2 | |
1077 | exit-vnc | |
1078 | ||
1079 | vnc nve-group group1 | |
1080 | prefix vn 172.16.128.0/17 | |
1081 | exit-vnc | |
1082 | exit | |
1083 | @end verbatim | |
1084 | ||
1085 | @node Mesh NVA and VNC-GW Configuration | |
1086 | @subsection Mesh NVA and VNC-GW Configuration | |
1087 | ||
1088 | This example includes two NVAs, each with two associated NVEs, and two | |
1089 | VNC-GWs, each supporting two CE routers physically attached to the four | |
1090 | NVEs. Note that this example is showing a more complex configuration | |
1091 | where VNC-GW is separated from normal NVA functions; it is equally | |
1092 | possible to simplify the configuration and combine NVA and VNC-GW | |
438f5286 | 1093 | functions in a single frr instance. |
65efcfce LB |
1094 | |
1095 | @float Figure,fig:fig-vnc-gw | |
438f5286 | 1096 | @center @image{fig-vnc-gw,400pt,,Frr VNC Gateway} |
65efcfce LB |
1097 | @caption{Meshed NVEs and VNC-GWs} |
1098 | @end float | |
1099 | ||
1100 | As shown in @ref{fig:fig-vnc-gw}, NVAs and VNC-GWs are connected in a | |
1101 | full iBGP mesh. The VNC-GWs each have two CEs configured as | |
1102 | route-reflector clients. Each client provides BGP updates with unicast | |
1103 | routes that the VNC-GW reflects to the other client. The VNC-GW also | |
1104 | imports these unicast routes into VPN routes to be shared with the other | |
1105 | VNC-GW and the two NVAs. This route importation is controlled with the | |
1106 | @code{vnc redistribute} statements shown in the configuration. | |
1107 | Similarly, registrations sent by NVEs via RFP to the NVAs are exported | |
1108 | by the VNC-GWs to the route-reflector clients as unicast routes. RFP | |
1109 | registrations exported this way have a next-hop address of the CE behind | |
1110 | the connected (registering) NVE. Exporting VNC routes as IPv4 unicast | |
1111 | is enabled with the @code{vnc export} command below. | |
1112 | ||
1113 | The configuration for @code{VNC-GW 1} is shown below. | |
1114 | @verbatim | |
1115 | router bgp 64512 | |
1116 | bgp router-id 192.168.1.101 | |
1117 | bgp cluster-id 1.2.3.4 | |
65efcfce | 1118 | neighbor 192.168.1.102 remote-as 64512 |
65efcfce | 1119 | neighbor 192.168.1.103 remote-as 64512 |
65efcfce | 1120 | neighbor 192.168.1.104 remote-as 64512 |
65efcfce | 1121 | neighbor 172.16.1.2 remote-as 64512 |
65efcfce | 1122 | neighbor 172.16.2.2 remote-as 64512 |
30dff1e4 DW |
1123 | ! |
1124 | address-family ipv4 unicast | |
1125 | redistribute vnc-direct | |
1126 | no neighbor 192.168.1.102 activate | |
1127 | no neighbor 192.168.1.103 activate | |
1128 | no neighbor 192.168.1.104 activate | |
1129 | neighbor 172.16.1.2 route-reflector-client | |
1130 | neighbor 172.16.2.2 route-reflector-client | |
1131 | exit-address-family | |
1132 | ! | |
65efcfce LB |
1133 | address-family vpnv4 unicast |
1134 | neighbor 192.168.1.102 activate | |
1135 | neighbor 192.168.1.103 activate | |
1136 | neighbor 192.168.1.104 activate | |
1137 | exit-address-family | |
1138 | vnc export bgp mode ce | |
1139 | vnc redistribute mode resolve-nve | |
1140 | vnc redistribute ipv4 bgp-direct | |
1141 | exit | |
1142 | @end verbatim | |
1143 | ||
1144 | Note that in the VNC-GW configuration, the neighboring VNC-GW and | |
1145 | NVAs each have a statement disabling the IPv4 unicast address family. | |
1146 | IPv4 unicast is on by default and this prevents the other VNC-GW and | |
1147 | NVAs from learning unicast routes advertised by the route-reflector clients. | |
1148 | ||
1149 | Configuration for @code{NVA 2}: | |
1150 | @verbatim | |
1151 | router bgp 64512 | |
1152 | bgp router-id 192.168.1.104 | |
1153 | neighbor 192.168.1.101 remote-as 64512 | |
65efcfce | 1154 | neighbor 192.168.1.102 remote-as 64512 |
65efcfce | 1155 | neighbor 192.168.1.103 remote-as 64512 |
30dff1e4 DW |
1156 | ! |
1157 | address-family ipv4 unicast | |
1158 | no neighbor 192.168.1.101 activate | |
1159 | no neighbor 192.168.1.102 activate | |
1160 | no neighbor 192.168.1.103 activate | |
1161 | exit-address-family | |
1162 | ! | |
65efcfce LB |
1163 | address-family vpnv4 unicast |
1164 | neighbor 192.168.1.101 activate | |
1165 | neighbor 192.168.1.102 activate | |
1166 | neighbor 192.168.1.103 activate | |
1167 | exit-address-family | |
30dff1e4 | 1168 | ! |
65efcfce LB |
1169 | vnc defaults |
1170 | response-lifetime 3600 | |
1171 | exit-vnc | |
1172 | vnc nve-group nve1 | |
1173 | prefix vn 172.16.1.1/32 | |
1174 | response-lifetime 3600 | |
1175 | rt both 1000:1 1000:2 | |
1176 | exit-vnc | |
1177 | vnc nve-group nve2 | |
1178 | prefix vn 172.16.2.1/32 | |
1179 | response-lifetime 3600 | |
1180 | rt both 1000:1 1000:2 | |
1181 | exit-vnc | |
1182 | exit | |
1183 | @end verbatim | |
1184 | ||
1185 | @c TBD make this its own example: | |
1186 | @c | |
1187 | @c @float Figure,fig:fig-vnc-gw-rr | |
438f5286 | 1188 | @c @center @image{fig-vnc-gw-rr,400pt,,Frr VNC Gateway with RR} |
65efcfce LB |
1189 | @c @end float |
1190 | @c An NVA can also import unicast routes from BGP without advertising the | |
1191 | @c imported routes as VPN routes. Such imported routes, while not | |
1192 | @c distributed to other NVAs or VNC-GWs, are are available to NVEs via | |
1193 | @c RFP query messages sent to the NVA. @ref{fig:fig-vnc-gw-rr} | |
1194 | @c shows an example topology where unicast routes are imported into NVAs | |
1195 | @c from a Route Reflector. (@pxref{Route Reflector} for route reflector | |
1196 | @c configuration details.) The following three lines can be added to the | |
1197 | @c @code{NVA 1} and @code{NVA 2} configurations to import routes into VNC | |
1198 | @c for local VNC use: | |
1199 | @c | |
1200 | @c @verbatim | |
1201 | @c neighbor 192.168.1.105 remote-as 64512 | |
1202 | @c vnc redistribute mode plain | |
1203 | @c vnc redistribute ipv4 bgp-direct-to-nve-groups | |
1204 | @c @end verbatim | |
1205 | ||
438f5286 DS |
1206 | @node VNC with Frr Route Reflector Configuration |
1207 | @subsection VNC with Frr Route Reflector Configuration | |
65efcfce LB |
1208 | A route reflector eliminates the need for a fully meshed NVA |
1209 | network by acting as the hub between NVAs. | |
438f5286 | 1210 | @ref{fig:fig-vnc-frr-route-reflector} shows BGP route reflector |
65efcfce LB |
1211 | @code{BGP Route Reflector 1} (192.168.1.100) as a route reflector for |
1212 | NVAs @code{NVA 2}(192.168.1.101) and @code{NVA 3} | |
1213 | (192.168.1.102). | |
1214 | ||
438f5286 DS |
1215 | @float Figure,fig:fig-vnc-frr-route-reflector |
1216 | @center @image{fig-vnc-frr-route-reflector,400pt,,Frr Route Reflector} | |
65efcfce LB |
1217 | @caption{Two NVAs and a BGP Route Reflector} |
1218 | @end float | |
1219 | ||
1220 | @code{NVA 2} and @code{NVA 3} | |
1221 | advertise NVE underlay-network IP addresses using the Tunnel Encapsulation Attribute. | |
1222 | @code{BGP Route Reflector 1} ``reflects'' advertisements from | |
1223 | @code{NVA 2} to @code{NVA 3} and vice versa. | |
1224 | ||
1225 | As in the example of @ref{Mesh NVA Configuration}, there are two NVE groups. | |
1226 | The 172.16.0.0/16 address range is partitioned into two NVE groups, | |
1227 | @code{group1} (172.16.0.0/17) and @code{group2} (172.16.128.0/17). | |
1228 | The NVE @code{NVE 4}, @code{NVE 7}, and @code{NVE 8} are | |
1229 | members of the NVE group @code{group1}. The NVEs @code{NVE 5}, | |
1230 | @code{NVE 6}, and @code{NVE 9} are members of the NVE group | |
1231 | @code{group2}. | |
1232 | ||
1233 | @file{bgpd.conf} for @code{BGP Route Reflector 1} on 192.168.1.100: | |
1234 | @verbatim | |
1235 | router bgp 64512 | |
1236 | ||
1237 | bgp router-id 192.168.1.100 | |
1238 | ||
1239 | neighbor 192.168.1.101 remote-as 64512 | |
1240 | neighbor 192.168.1.101 port 7179 | |
1241 | neighbor 192.168.1.101 description iBGP-client-192-168-1-101 | |
65efcfce LB |
1242 | |
1243 | neighbor 192.168.1.102 remote-as 64512 | |
1244 | neighbor 192.168.1.102 port 7179 | |
1245 | neighbor 192.168.1.102 description iBGP-client-192-168-1-102 | |
30dff1e4 DW |
1246 | |
1247 | address-family ipv4 unicast | |
1248 | neighbor 192.168.1.101 route-reflector-client | |
1249 | neighbor 192.168.1.102 route-reflector-client | |
1250 | exit-address-family | |
65efcfce LB |
1251 | |
1252 | address-family vpnv4 | |
1253 | neighbor 192.168.1.101 activate | |
1254 | neighbor 192.168.1.102 activate | |
1255 | ||
1256 | neighbor 192.168.1.101 route-reflector-client | |
1257 | neighbor 192.168.1.102 route-reflector-client | |
1258 | exit-address-family | |
1259 | ||
1260 | exit | |
1261 | @end verbatim | |
1262 | ||
1263 | @file{bgpd.conf} for @code{NVA 2} on 192.168.1.101: | |
1264 | @verbatim | |
1265 | router bgp 64512 | |
1266 | ||
1267 | bgp router-id 192.168.1.101 | |
1268 | ||
1269 | neighbor 192.168.1.100 remote-as 64512 | |
1270 | ||
1271 | address-family vpnv4 | |
1272 | neighbor 192.168.1.100 activate | |
1273 | exit-address-family | |
1274 | ||
1275 | vnc nve-group group1 | |
1276 | prefix vn 172.16.0.0/17 | |
1277 | rd 64512:1 | |
1278 | response-lifetime 200 | |
1279 | rt both 1000:1 1000:2 | |
1280 | exit-vnc | |
1281 | exit | |
1282 | @end verbatim | |
1283 | ||
1284 | @file{bgpd.conf} for @code{NVA 2} on 192.168.1.102: | |
1285 | @verbatim | |
1286 | router bgp 64512 | |
1287 | ||
1288 | bgp router-id 192.168.1.102 | |
1289 | ||
1290 | neighbor 192.168.1.100 remote-as 64512 | |
1291 | ||
1292 | address-family vpnv4 | |
1293 | neighbor 192.168.1.100 activate | |
1294 | exit-address-family | |
1295 | ||
1296 | vnc defaults | |
1297 | rd 64512:1 | |
1298 | response-lifetime 200 | |
1299 | rt both 1000:1 1000:2 | |
1300 | exit-vnc | |
1301 | ||
1302 | vnc nve-group group1 | |
1303 | prefix vn 172.16.128.0/17 | |
1304 | exit-vnc | |
1305 | exit | |
1306 | @end verbatim | |
1307 | ||
1308 | While not shown, an NVA can also be configured as a route reflector. | |
1309 | ||
1310 | @node VNC with Commercial Route Reflector Configuration | |
1311 | @subsection VNC with Commercial Route Reflector Configuration | |
438f5286 | 1312 | This example is identical to @ref{VNC with Frr Route Reflector |
65efcfce LB |
1313 | Configuration} with the exception that the route reflector is a |
1314 | commercial router. Only the | |
1315 | VNC-relevant configuration is provided. | |
1316 | ||
1317 | @float Figure,fig:fig-vnc-commercial-route-reflector | |
1318 | @center @image{fig-vnc-commercial-route-reflector,400pt,,Commercial Route Reflector} | |
1319 | @caption{Two NVAs with a commercial route reflector} | |
1320 | @end float | |
1321 | ||
1322 | @file{bgpd.conf} for BGP route reflector @code{Commercial Router} on 192.168.1.104: | |
1323 | @verbatim | |
1324 | version 8.5R1.13; | |
1325 | routing-options { | |
1326 | rib inet.0 { | |
1327 | static { | |
1328 | route 172.16.0.0/16 next-hop 192.168.1.104; | |
1329 | } | |
1330 | } | |
1331 | autonomous-system 64512; | |
1332 | resolution { | |
1333 | rib inet.3 { | |
1334 | resolution-ribs inet.0; | |
1335 | } | |
1336 | rib bgp.l3vpn.0 { | |
1337 | resolution-ribs inet.0; | |
1338 | } | |
1339 | } | |
1340 | } | |
1341 | protocols { | |
1342 | bgp { | |
1343 | advertise-inactive; | |
1344 | family inet { | |
1345 | labeled-unicast; | |
1346 | } | |
1347 | group 1 { | |
1348 | type internal; | |
1349 | advertise-inactive; | |
1350 | advertise-peer-as; | |
1351 | import h; | |
1352 | family inet { | |
1353 | unicast; | |
1354 | } | |
1355 | family inet-vpn { | |
1356 | unicast; | |
1357 | } | |
1358 | cluster 192.168.1.104; | |
1359 | neighbor 192.168.1.101; | |
1360 | neighbor 192.168.1.102; | |
1361 | } | |
1362 | } | |
1363 | } | |
1364 | policy-options { | |
1365 | policy-statement h { | |
1366 | from protocol bgp; | |
1367 | then { | |
1368 | as-path-prepend 64512; | |
1369 | accept; | |
1370 | } | |
1371 | } | |
1372 | } | |
1373 | @end verbatim | |
1374 | ||
1375 | @file{bgpd.conf} for @code{NVA 2} on 192.168.1.101: | |
1376 | @verbatim | |
1377 | router bgp 64512 | |
1378 | ||
1379 | bgp router-id 192.168.1.101 | |
1380 | ||
1381 | neighbor 192.168.1.100 remote-as 64512 | |
1382 | ||
1383 | address-family vpnv4 | |
1384 | neighbor 192.168.1.100 activate | |
1385 | exit-address-family | |
1386 | ||
1387 | vnc nve-group group1 | |
1388 | prefix vn 172.16.0.0/17 | |
1389 | rd 64512:1 | |
1390 | response-lifetime 200 | |
1391 | rt both 1000:1 1000:2 | |
1392 | exit-vnc | |
1393 | exit | |
1394 | @end verbatim | |
1395 | ||
1396 | @file{bgpd.conf} for @code{NVA 3} on 192.168.1.102: | |
1397 | @verbatim | |
1398 | router bgp 64512 | |
1399 | ||
1400 | bgp router-id 192.168.1.102 | |
1401 | ||
1402 | neighbor 192.168.1.100 remote-as 64512 | |
1403 | ||
1404 | address-family vpnv4 | |
1405 | neighbor 192.168.1.100 activate | |
1406 | exit-address-family | |
1407 | ||
1408 | vnc defaults | |
1409 | rd 64512:1 | |
1410 | response-lifetime 200 | |
1411 | rt both 1000:1 1000:2 | |
1412 | exit-vnc | |
1413 | ||
1414 | vnc nve-group group1 | |
1415 | prefix vn 172.16.128.0/17 | |
1416 | exit-vnc | |
1417 | exit | |
1418 | @end verbatim | |
1419 | ||
1420 | @node VNC with Redundant Route Reflectors Configuration | |
1421 | @subsection VNC with Redundant Route Reflectors Configuration | |
438f5286 | 1422 | This example combines the previous two (@ref{VNC with Frr Route |
65efcfce LB |
1423 | Reflector Configuration} and @ref{VNC with Commercial Route Reflector |
1424 | Configuration}) into a redundant route reflector configuration. BGP | |
1425 | route reflectors @code{BGP Route Reflector 1} and @code{Commercial Router} | |
1426 | are the route reflectors for NVAs @code{NVA 2} and | |
1427 | @code{NVA 3}. The two NVAs have connections to both | |
1428 | route reflectors. | |
1429 | ||
1430 | @float Figure,fig:fig-vnc-redundant-route-reflectors | |
1431 | @center @image{fig-vnc-redundant-route-reflectors,400pt,,Redundant Route Reflectors} | |
438f5286 | 1432 | @caption{Frr-based NVA with redundant route reflectors} |
65efcfce LB |
1433 | @end float |
1434 | ||
1435 | @file{bgpd.conf} for @code{Bgpd Route Reflector 1} on 192.168.1.100: | |
1436 | @verbatim | |
1437 | router bgp 64512 | |
1438 | ||
1439 | bgp router-id 192.168.1.100 | |
1440 | bgp cluster-id 192.168.1.100 | |
1441 | ||
1442 | neighbor 192.168.1.104 remote-as 64512 | |
1443 | ||
1444 | neighbor 192.168.1.101 remote-as 64512 | |
1445 | neighbor 192.168.1.101 description iBGP-client-192-168-1-101 | |
1446 | neighbor 192.168.1.101 route-reflector-client | |
1447 | ||
1448 | neighbor 192.168.1.102 remote-as 64512 | |
1449 | neighbor 192.168.1.102 description iBGP-client-192-168-1-102 | |
1450 | neighbor 192.168.1.102 route-reflector-client | |
1451 | ||
1452 | address-family vpnv4 | |
1453 | neighbor 192.168.1.101 activate | |
1454 | neighbor 192.168.1.102 activate | |
1455 | neighbor 192.168.1.104 activate | |
1456 | ||
1457 | neighbor 192.168.1.101 route-reflector-client | |
1458 | neighbor 192.168.1.102 route-reflector-client | |
1459 | exit-address-family | |
1460 | exit | |
1461 | @end verbatim | |
1462 | ||
1463 | @file{bgpd.conf} for @code{NVA 2} on 192.168.1.101: | |
1464 | @verbatim | |
1465 | router bgp 64512 | |
1466 | ||
1467 | bgp router-id 192.168.1.101 | |
1468 | ||
1469 | neighbor 192.168.1.100 remote-as 64512 | |
1470 | neighbor 192.168.1.104 remote-as 64512 | |
1471 | ||
1472 | address-family vpnv4 | |
1473 | neighbor 192.168.1.100 activate | |
1474 | neighbor 192.168.1.104 activate | |
1475 | exit-address-family | |
1476 | ||
1477 | vnc nve-group group1 | |
1478 | prefix vn 172.16.0.0/17 | |
1479 | rd 64512:1 | |
1480 | response-lifetime 200 | |
1481 | rt both 1000:1 1000:2 | |
1482 | exit-vnc | |
1483 | exit | |
1484 | @end verbatim | |
1485 | ||
1486 | @file{bgpd.conf} for @code{NVA 3} on 192.168.1.102: | |
1487 | @verbatim | |
1488 | router bgp 64512 | |
1489 | ||
1490 | bgp router-id 192.168.1.102 | |
1491 | ||
1492 | neighbor 192.168.1.100 remote-as 64512 | |
1493 | neighbor 192.168.1.104 remote-as 64512 | |
1494 | ||
1495 | address-family vpnv4 | |
1496 | neighbor 192.168.1.100 activate | |
1497 | neighbor 192.168.1.104 activate | |
1498 | exit-address-family | |
1499 | ||
1500 | vnc defaults | |
1501 | rd 64512:1 | |
1502 | response-lifetime 200 | |
1503 | rt both 1000:1 1000:2 | |
1504 | exit-vnc | |
1505 | ||
1506 | vnc nve-group group1 | |
1507 | prefix vn 172.16.128.0/17 | |
1508 | exit-vnc | |
1509 | exit | |
1510 | @end verbatim | |
1511 | ||
1512 | @file{bgpd.conf} for the Commercial Router route reflector on | |
1513 | 192.168.1.104: | |
1514 | @verbatim | |
1515 | routing-options { | |
1516 | rib inet.0 { | |
1517 | static { | |
1518 | route 172.16.0.0/16 next-hop 192.168.1.104; | |
1519 | } | |
1520 | } | |
1521 | autonomous-system 64512; | |
1522 | resolution { | |
1523 | rib inet.3 { | |
1524 | resolution-ribs inet.0; | |
1525 | } | |
1526 | rib bgp.l3vpn.0 { | |
1527 | resolution-ribs inet.0; | |
1528 | } | |
1529 | } | |
1530 | } | |
1531 | protocols { | |
1532 | bgp { | |
1533 | advertise-inactive; | |
1534 | family inet { | |
1535 | labeled-unicast; | |
1536 | } | |
1537 | group 1 { | |
1538 | type internal; | |
1539 | advertise-inactive; | |
1540 | advertise-peer-as; | |
1541 | import h; | |
1542 | family inet { | |
1543 | unicast; | |
1544 | } | |
1545 | family inet-vpn { | |
1546 | unicast; | |
1547 | } | |
1548 | cluster 192.168.1.104; | |
1549 | neighbor 192.168.1.101; | |
1550 | neighbor 192.168.1.102; | |
1551 | } | |
1552 | ||
1553 | group 2 { | |
1554 | type internal; | |
1555 | advertise-inactive; | |
1556 | advertise-peer-as; | |
1557 | import h; | |
1558 | family inet { | |
1559 | unicast; | |
1560 | } | |
1561 | family inet-vpn { | |
1562 | unicast; | |
1563 | } | |
1564 | neighbor 192.168.1.100; | |
1565 | } | |
1566 | ||
1567 | } | |
1568 | } | |
1569 | policy-options { | |
1570 | policy-statement h { | |
1571 | from protocol bgp; | |
1572 | then { | |
1573 | as-path-prepend 64512; | |
1574 | accept; | |
1575 | } | |
1576 | } | |
1577 | } | |
1578 | @end verbatim | |
1579 | ||
1580 | @node Release Notes | |
1581 | @section Release Notes | |
1582 | ||
1583 | @c A paragraph that introduces our release notes. | |
1584 | ||
1585 | @c outer list, one item per VNC release, items preceded by bullet | |
1586 | @itemize @bullet | |
1587 | @item | |
1588 | ||
1589 | @c @item | |
1590 | @end itemize | |
1591 | ||
1592 | @evenheading @thispage@|@|@thistitle | |
1593 | @oddheading @thischapter@|@|@thispage | |
1594 | @everyfooting | |
1595 |