]>
Commit | Line | Data |
---|---|---|
718e3744 | 1 | @c -*-texinfo-*- |
438f5286 | 2 | @c This is part of the Frr Manual. |
76b89b4a | 3 | @c @value{COPYRIGHT_STR} |
d767b4d0 PJ |
4 | @c Portions: |
5 | @c Copyright @copyright{} 2015 Hewlett Packard Enterprise Development LP | |
438f5286 | 6 | @c See file frr.texi for copying conditions. |
718e3744 | 7 | @node BGP |
718e3744 | 8 | @chapter BGP |
9 | ||
aa5943f7 | 10 | @acronym{BGP} stands for a Border Gateway Protocol. The lastest BGP version |
718e3744 | 11 | is 4. It is referred as BGP-4. BGP-4 is one of the Exterior Gateway |
12 | Protocols and de-fact standard of Inter Domain routing protocol. | |
aa5943f7 | 13 | BGP-4 is described in @cite{RFC1771, A Border Gateway Protocol |
718e3744 | 14 | 4 (BGP-4)}. |
15 | ||
aa5943f7 | 16 | Many extensions have been added to @cite{RFC1771}. @cite{RFC2858, |
17 | Multiprotocol Extensions for BGP-4} provides multiprotocol support to | |
18 | BGP-4. | |
718e3744 | 19 | |
20 | @menu | |
21 | * Starting BGP:: | |
22 | * BGP router:: | |
d767b4d0 | 23 | * BGP MED:: |
718e3744 | 24 | * BGP network:: |
25 | * BGP Peer:: | |
26 | * BGP Peer Group:: | |
27 | * BGP Address Family:: | |
28 | * Autonomous System:: | |
29 | * BGP Communities Attribute:: | |
30 | * BGP Extended Communities Attribute:: | |
ca383542 | 31 | * BGP Large Communities Attribute:: |
446176bd | 32 | * Displaying BGP information:: |
718e3744 | 33 | * Capability Negotiation:: |
34 | * Route Reflector:: | |
35 | * Route Server:: | |
47e7c0b9 | 36 | * BGP Regular Expressions:: |
718e3744 | 37 | * How to set up a 6-Bone connection:: |
38 | * Dump BGP packets and table:: | |
aa5943f7 | 39 | * BGP Configuration Examples:: |
dabecd7c | 40 | * Prefix Origin Validation Using RPKI:: |
718e3744 | 41 | @end menu |
42 | ||
76b89b4a | 43 | @node Starting BGP |
718e3744 | 44 | @section Starting BGP |
45 | ||
46 | Default configuration file of @command{bgpd} is @file{bgpd.conf}. | |
47 | @command{bgpd} searches the current directory first then | |
48 | @value{INSTALL_PREFIX_ETC}/bgpd.conf. All of bgpd's command must be | |
49 | configured in @file{bgpd.conf}. | |
50 | ||
51 | @command{bgpd} specific invocation options are described below. Common | |
52 | options may also be specified (@pxref{Common Invocation Options}). | |
53 | ||
54 | @table @samp | |
55 | @item -p @var{PORT} | |
56 | @itemx --bgp_port=@var{PORT} | |
57 | Set the bgp protocol's port number. | |
58 | ||
59 | @item -r | |
60 | @itemx --retain | |
61 | When program terminates, retain BGP routes added by zebra. | |
d767b4d0 PJ |
62 | |
63 | @item -l | |
64 | @itemx --listenon | |
65 | Specify a specific IP address for bgpd to listen on, rather than its | |
66 | default of INADDR_ANY / IN6ADDR_ANY. This can be useful to constrain bgpd | |
67 | to an internal address, or to run multiple bgpd processes on one host. | |
68 | ||
718e3744 | 69 | @end table |
70 | ||
76b89b4a | 71 | @node BGP router |
718e3744 | 72 | @section BGP router |
73 | ||
74 | First of all you must configure BGP router with @command{router bgp} | |
75 | command. To configure BGP router, you need AS number. AS number is an | |
76 | identification of autonomous system. BGP protocol uses the AS number | |
77 | for detecting whether the BGP connection is internal one or external one. | |
78 | ||
79 | @deffn Command {router bgp @var{asn}} {} | |
80 | Enable a BGP protocol process with the specified @var{asn}. After | |
81 | this statement you can input any @code{BGP Commands}. You can not | |
82 | create different BGP process under different @var{asn} without | |
83 | specifying @code{multiple-instance} (@pxref{Multiple instance}). | |
84 | @end deffn | |
85 | ||
86 | @deffn Command {no router bgp @var{asn}} {} | |
87 | Destroy a BGP protocol process with the specified @var{asn}. | |
88 | @end deffn | |
89 | ||
90 | @deffn {BGP} {bgp router-id @var{A.B.C.D}} {} | |
91 | This command specifies the router-ID. If @command{bgpd} connects to @command{zebra} it gets | |
92 | interface and address information. In that case default router ID value | |
93 | is selected as the largest IP Address of the interfaces. When | |
94 | @code{router zebra} is not enabled @command{bgpd} can't get interface information | |
95 | so @code{router-id} is set to 0.0.0.0. So please set router-id by hand. | |
96 | @end deffn | |
97 | ||
98 | @menu | |
99 | * BGP distance:: | |
100 | * BGP decision process:: | |
c31e5726 | 101 | * BGP route flap dampening:: |
718e3744 | 102 | @end menu |
103 | ||
76b89b4a | 104 | @node BGP distance |
718e3744 | 105 | @subsection BGP distance |
106 | ||
107 | @deffn {BGP} {distance bgp <1-255> <1-255> <1-255>} {} | |
108 | This command change distance value of BGP. Each argument is distance | |
109 | value for external routes, internal routes and local routes. | |
110 | @end deffn | |
111 | ||
112 | @deffn {BGP} {distance <1-255> @var{A.B.C.D/M}} {} | |
113 | @deffnx {BGP} {distance <1-255> @var{A.B.C.D/M} @var{word}} {} | |
114 | This command set distance value to | |
115 | @end deffn | |
116 | ||
76b89b4a | 117 | @node BGP decision process |
718e3744 | 118 | @subsection BGP decision process |
119 | ||
438f5286 | 120 | The decision process Frr BGP uses to select routes is as follows: |
d767b4d0 | 121 | |
718e3744 | 122 | @table @asis |
123 | @item 1. Weight check | |
d767b4d0 | 124 | prefer higher local weight routes to lower routes. |
718e3744 | 125 | |
d767b4d0 PJ |
126 | @item 2. Local preference check |
127 | prefer higher local preference routes to lower. | |
128 | ||
129 | @item 3. Local route check | |
130 | Prefer local routes (statics, aggregates, redistributed) to received routes. | |
131 | ||
132 | @item 4. AS path length check | |
133 | Prefer shortest hop-count AS_PATHs. | |
134 | ||
135 | @item 5. Origin check | |
136 | Prefer the lowest origin type route. That is, prefer IGP origin routes to | |
137 | EGP, to Incomplete routes. | |
138 | ||
139 | @item 6. MED check | |
140 | Where routes with a MED were received from the same AS, | |
141 | prefer the route with the lowest MED. @xref{BGP MED}. | |
142 | ||
143 | @item 7. External check | |
144 | Prefer the route received from an external, eBGP peer | |
145 | over routes received from other types of peers. | |
146 | ||
147 | @item 8. IGP cost check | |
148 | Prefer the route with the lower IGP cost. | |
149 | ||
150 | @item 9. Multi-path check | |
151 | If multi-pathing is enabled, then check whether | |
152 | the routes not yet distinguished in preference may be considered equal. If | |
153 | @ref{bgp bestpath as-path multipath-relax} is set, all such routes are | |
154 | considered equal, otherwise routes received via iBGP with identical AS_PATHs | |
155 | or routes received from eBGP neighbours in the same AS are considered equal. | |
156 | ||
157 | @item 10 Already-selected external check | |
718e3744 | 158 | |
d767b4d0 PJ |
159 | Where both routes were received from eBGP peers, then prefer the route which |
160 | is already selected. Note that this check is not applied if @ref{bgp | |
161 | bestpath compare-routerid} is configured. This check can prevent some cases | |
162 | of oscillation. | |
718e3744 | 163 | |
d767b4d0 PJ |
164 | @item 11. Router-ID check |
165 | Prefer the route with the lowest @w{router-ID}. If the | |
166 | route has an @w{ORIGINATOR_ID} attribute, through iBGP reflection, then that | |
167 | router ID is used, otherwise the @w{router-ID} of the peer the route was | |
168 | received from is used. | |
718e3744 | 169 | |
d767b4d0 PJ |
170 | @item 12. Cluster-List length check |
171 | The route with the shortest cluster-list | |
172 | length is used. The cluster-list reflects the iBGP reflection path the | |
173 | route has taken. | |
174 | ||
175 | @item 13. Peer address | |
176 | Prefer the route received from the peer with the higher | |
177 | transport layer address, as a last-resort tie-breaker. | |
718e3744 | 178 | |
718e3744 | 179 | @end table |
180 | ||
6811845b | 181 | @deffn {BGP} {bgp bestpath as-path confed} {} |
182 | This command specifies that the length of confederation path sets and | |
183 | sequences should should be taken into account during the BGP best path | |
184 | decision process. | |
185 | @end deffn | |
186 | ||
2fdd455c | 187 | @deffn {BGP} {bgp bestpath as-path multipath-relax} {} |
d767b4d0 | 188 | @anchor{bgp bestpath as-path multipath-relax} |
2fdd455c PM |
189 | This command specifies that BGP decision process should consider paths |
190 | of equal AS_PATH length candidates for multipath computation. Without | |
191 | the knob, the entire AS_PATH must match for multipath computation. | |
192 | @end deffn | |
193 | ||
d767b4d0 PJ |
194 | @deffn {BGP} {bgp bestpath compare-routerid} {} |
195 | @anchor{bgp bestpath compare-routerid} | |
196 | ||
197 | Ensure that when comparing routes where both are equal on most metrics, | |
198 | including local-pref, AS_PATH length, IGP cost, MED, that the tie is broken | |
199 | based on router-ID. | |
200 | ||
201 | If this option is enabled, then the already-selected check, where | |
202 | already selected eBGP routes are preferred, is skipped. | |
203 | ||
204 | If a route has an @w{ORIGINATOR_ID} attribute because it has been reflected, | |
205 | that @w{ORIGINATOR_ID} will be used. Otherwise, the router-ID of the peer the | |
206 | route was received from will be used. | |
207 | ||
208 | The advantage of this is that the route-selection (at this point) will be | |
209 | more deterministic. The disadvantage is that a few or even one lowest-ID | |
210 | router may attract all trafic to otherwise-equal paths because of this | |
211 | check. It may increase the possibility of MED or IGP oscillation, unless | |
212 | other measures were taken to avoid these. The exact behaviour will be | |
213 | sensitive to the iBGP and reflection topology. | |
214 | ||
215 | @end deffn | |
216 | ||
217 | ||
c31e5726 AC |
218 | @node BGP route flap dampening |
219 | @subsection BGP route flap dampening | |
220 | ||
221 | @deffn {BGP} {bgp dampening @var{<1-45>} @var{<1-20000>} @var{<1-20000>} @var{<1-255>}} {} | |
222 | This command enables BGP route-flap dampening and specifies dampening parameters. | |
223 | ||
224 | @table @asis | |
225 | @item @asis{half-life} | |
226 | Half-life time for the penalty | |
227 | @item @asis{reuse-threshold} | |
228 | Value to start reusing a route | |
229 | @item @asis{suppress-threshold} | |
230 | Value to start suppressing a route | |
231 | @item @asis{max-suppress} | |
232 | Maximum duration to suppress a stable route | |
233 | @end table | |
234 | ||
235 | The route-flap damping algorithm is compatible with @cite{RFC2439}. The use of this command | |
236 | is not recommended nowadays, see @uref{http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378}. | |
237 | @end deffn | |
238 | ||
d767b4d0 PJ |
239 | @node BGP MED |
240 | @section BGP MED | |
241 | ||
242 | The BGP MED (Multi_Exit_Discriminator) attribute has properties which can | |
243 | cause subtle convergence problems in BGP. These properties and problems | |
244 | have proven to be hard to understand, at least historically, and may still | |
245 | not be widely understood. The following attempts to collect together and | |
438f5286 | 246 | present what is known about MED, to help operators and Frr users in |
d767b4d0 PJ |
247 | designing and configuring their networks. |
248 | ||
249 | The BGP @acronym{MED, Multi_Exit_Discriminator} attribute is intended to | |
250 | allow one AS to indicate its preferences for its ingress points to another | |
251 | AS. The MED attribute will not be propagated on to another AS by the | |
252 | receiving AS - it is `non-transitive' in the BGP sense. | |
253 | ||
254 | E.g., if AS X and AS Y have 2 different BGP peering points, then AS X | |
255 | might set a MED of 100 on routes advertised at one and a MED of 200 at the | |
256 | other. When AS Y selects between otherwise equal routes to or via | |
257 | AS X, AS Y should prefer to take the path via the lower MED peering of 100 with | |
258 | AS X. Setting the MED allows an AS to influence the routing taken to it | |
259 | within another, neighbouring AS. | |
260 | ||
261 | In this use of MED it is not really meaningful to compare the MED value on | |
262 | routes where the next AS on the paths differs. E.g., if AS Y also had a | |
263 | route for some destination via AS Z in addition to the routes from AS X, and | |
264 | AS Z had also set a MED, it wouldn't make sense for AS Y to compare AS Z's | |
265 | MED values to those of AS X. The MED values have been set by different | |
266 | administrators, with different frames of reference. | |
267 | ||
268 | The default behaviour of BGP therefore is to not compare MED values across | |
438f5286 | 269 | routes received from different neighbouring ASes. In Frr this is done by |
d767b4d0 PJ |
270 | comparing the neighbouring, left-most AS in the received AS_PATHs of the |
271 | routes and only comparing MED if those are the same. | |
272 | ||
273 | @c TeXInfo uses the old, non-UTF-8 capable, pdftex, and so | |
274 | @c doesn't render TeX the unicode precedes character correctly in PDF, etc. | |
275 | @c Using a TeX code on the other hand doesn't work for non-TeX outputs | |
276 | @c (plaintext, e.g.). So, use an output-conditional macro. | |
277 | ||
278 | @iftex | |
279 | @macro mprec{} | |
280 | @math{\\prec} | |
281 | @end macro | |
282 | @end iftex | |
283 | ||
284 | @ifnottex | |
285 | @macro mprec{} | |
286 | @math{≺} | |
287 | @end macro | |
288 | @end ifnottex | |
289 | ||
290 | Unfortunately, this behaviour of MED, of sometimes being compared across | |
291 | routes and sometimes not, depending on the properties of those other routes, | |
292 | means MED can cause the order of preference over all the routes to be | |
293 | undefined. That is, given routes A, B, and C, if A is preferred to B, and B | |
294 | is preferred to C, then a well-defined order should mean the preference is | |
295 | transitive (in the sense of orders @footnote{For some set of objects to have | |
296 | an order, there @emph{must} be some binary ordering relation that is defined | |
297 | for @emph{every} combination of those objects, and that relation @emph{must} | |
298 | be transitive. I.e.@:, if the relation operator is @mprec{}, and if | |
299 | a @mprec{} b and b @mprec{} c then that relation must carry over | |
300 | and it @emph{must} be that a @mprec{} c for the objects to have an | |
301 | order. The ordering relation may allow for equality, i.e. | |
302 | a @mprec{} b and b @mprec{} a may both be true amd imply that | |
303 | a and b are equal in the order and not distinguished by it, in | |
304 | which case the set has a partial order. Otherwise, if there is an order, | |
305 | all the objects have a distinct place in the order and the set has a total | |
306 | order.}) and that A would be preferred to C. | |
307 | ||
d767b4d0 PJ |
308 | However, when MED is involved this need not be the case. With MED it is |
309 | possible that C is actually preferred over A. So A is preferred to B, B is | |
310 | preferred to C, but C is preferred to A. This can be true even where BGP | |
311 | defines a deterministic ``most preferred'' route out of the full set of | |
312 | A,B,C. With MED, for any given set of routes there may be a | |
313 | deterministically preferred route, but there need not be any way to arrange | |
314 | them into any order of preference. With unmodified MED, the order of | |
315 | preference of routes literally becomes undefined. | |
316 | ||
317 | That MED can induce non-transitive preferences over routes can cause issues. | |
318 | Firstly, it may be perceived to cause routing table churn locally at | |
319 | speakers; secondly, and more seriously, it may cause routing instability in | |
320 | iBGP topologies, where sets of speakers continually oscillate between | |
321 | different paths. | |
322 | ||
323 | The first issue arises from how speakers often implement routing decisions. | |
324 | Though BGP defines a selection process that will deterministically select | |
325 | the same route as best at any given speaker, even with MED, that process | |
326 | requires evaluating all routes together. For performance and ease of | |
327 | implementation reasons, many implementations evaluate route preferences in a | |
328 | pair-wise fashion instead. Given there is no well-defined order when MED is | |
329 | involved, the best route that will be chosen becomes subject to | |
330 | implementation details, such as the order the routes are stored in. That | |
331 | may be (locally) non-deterministic, e.g.@: it may be the order the routes | |
332 | were received in. | |
333 | ||
334 | This indeterminism may be considered undesirable, though it need not cause | |
335 | problems. It may mean additional routing churn is perceived, as sometimes | |
336 | more updates may be produced than at other times in reaction to some event . | |
337 | ||
338 | This first issue can be fixed with a more deterministic route selection that | |
339 | ensures routes are ordered by the neighbouring AS during selection. | |
340 | @xref{bgp deterministic-med}. This may reduce the number of updates as | |
341 | routes are received, and may in some cases reduce routing churn. Though, it | |
342 | could equally deterministically produce the largest possible set of updates | |
343 | in response to the most common sequence of received updates. | |
344 | ||
345 | A deterministic order of evaluation tends to imply an additional overhead of | |
346 | sorting over any set of n routes to a destination. The implementation of | |
438f5286 | 347 | deterministic MED in Frr scales significantly worse than most sorting |
d767b4d0 PJ |
348 | algorithms at present, with the number of paths to a given destination. |
349 | That number is often low enough to not cause any issues, but where there are | |
350 | many paths, the deterministic comparison may quickly become increasingly | |
351 | expensive in terms of CPU. | |
352 | ||
353 | Deterministic local evaluation can @emph{not} fix the second, more major, | |
354 | issue of MED however. Which is that the non-transitive preference of routes | |
355 | MED can cause may lead to routing instability or oscillation across multiple | |
356 | speakers in iBGP topologies. This can occur with full-mesh iBGP, but is | |
357 | particularly problematic in non-full-mesh iBGP topologies that further | |
358 | reduce the routing information known to each speaker. This has primarily | |
359 | been documented with iBGP route-reflection topologies. However, any | |
360 | route-hiding technologies potentially could also exacerbate oscillation with | |
361 | MED. | |
362 | ||
363 | This second issue occurs where speakers each have only a subset of routes, | |
364 | and there are cycles in the preferences between different combinations of | |
365 | routes - as the undefined order of preference of MED allows - and the routes | |
366 | are distributed in a way that causes the BGP speakers to 'chase' those | |
367 | cycles. This can occur even if all speakers use a deterministic order of | |
368 | evaluation in route selection. | |
369 | ||
370 | E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X, and | |
371 | from speaker 3 in AS Y; while speaker 5 in AS A might receive that route | |
372 | from speaker 1 in AS Y. AS Y might set a MED of 200 at speaker 1, and 100 | |
373 | at speaker 3. I.e, using ASN:ID:MED to label the speakers: | |
374 | ||
375 | @example | |
376 | ||
377 | /---------------\ | |
378 | X:2------|--A:4-------A:5--|-Y:1:200 | |
379 | Y:3:100--|-/ | | |
380 | \---------------/ | |
381 | ||
382 | @end example | |
383 | ||
384 | Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs), then | |
385 | based on the RFC4271 decision process speaker 4 will choose X:2 over | |
386 | Y:3:100, based on the lower ID of 2. Speaker 4 advertises X:2 to speaker 5. | |
387 | Speaker 5 will continue to prefer Y:1:200 based on the ID, and advertise | |
388 | this to speaker 4. Speaker 4 will now have the full set of routes, and the | |
389 | Y:1:200 it receives from 5 will beat X:2, but when speaker 4 compares | |
390 | Y:1:200 to Y:3:100 the MED check now becomes active as the ASes match, and | |
391 | now Y:3:100 is preferred. Speaker 4 therefore now advertises Y:3:100 to 5, | |
392 | which will also agrees that Y:3:100 is preferred to Y:1:200, and so | |
393 | withdraws the latter route from 4. Speaker 4 now has only X:2 and Y:3:100, | |
394 | and X:2 beats Y:3:100, and so speaker 4 implicitly updates its route to | |
395 | speaker 5 to X:2. Speaker 5 sees that Y:1:200 beats X:2 based on the ID, | |
396 | and advertises Y:1:200 to speaker 4, and the cycle continues. | |
397 | ||
398 | The root cause is the lack of a clear order of preference caused by how MED | |
399 | sometimes is and sometimes is not compared, leading to this cycle in the | |
400 | preferences between the routes: | |
401 | ||
402 | @example | |
403 | ||
404 | /---> X:2 ---beats---> Y:3:100 --\ | |
405 | | | | |
406 | | | | |
407 | \---beats--- Y:1:200 <---beats---/ | |
408 | ||
409 | @end example | |
410 | ||
411 | This particular type of oscillation in full-mesh iBGP topologies can be | |
412 | avoided by speakers preferring already selected, external routes rather than | |
413 | choosing to update to new a route based on a post-MED metric (e.g. | |
438f5286 | 414 | router-ID), at the cost of a non-deterministic selection process. Frr |
d767b4d0 PJ |
415 | implements this, as do many other implementations, so long as it is not |
416 | overridden by setting @ref{bgp bestpath compare-routerid}, and see also | |
417 | @ref{BGP decision process}, . | |
418 | ||
419 | However, more complex and insidious cycles of oscillation are possible with | |
420 | iBGP route-reflection, which are not so easily avoided. These have been | |
421 | documented in various places. See, e.g., @cite{McPherson, D. and Gill, V. | |
422 | and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation | |
423 | Condition", IETF RFC3345}, and @cite{Flavel, A. and M. Roughan, "Stable | |
424 | and flexible iBGP", ACM SIGCOMM 2009}, and @cite{Griffin, T. and G. Wilfong, | |
425 | "On the correctness of IBGP configuration", ACM SIGCOMM 2002} for concrete | |
426 | examples and further references. | |
427 | ||
428 | There is as of this writing @emph{no} known way to use MED for its original | |
429 | purpose; @emph{and} reduce routing information in iBGP topologies; | |
430 | @emph{and} be sure to avoid the instability problems of MED due the | |
431 | non-transitive routing preferences it can induce; in general on arbitrary | |
432 | networks. | |
433 | ||
434 | There may be iBGP topology specific ways to reduce the instability risks, | |
435 | even while using MED, e.g.@: by constraining the reflection topology and by | |
436 | tuning IGP costs between route-reflector clusters, see RFC3345 for details. | |
437 | In the near future, the Add-Path extension to BGP may also solve MED | |
438 | oscillation while still allowing MED to be used as intended, by distributing | |
439 | "best-paths per neighbour AS". This would be at the cost of distributing at | |
440 | least as many routes to all speakers as a full-mesh iBGP would, if not more, | |
441 | while also imposing similar CPU overheads as the "Deterministic MED" feature | |
442 | at each Add-Path reflector. | |
443 | ||
444 | More generally, the instability problems that MED can introduce on more | |
445 | complex, non-full-mesh, iBGP topologies may be avoided either by: | |
446 | ||
447 | @itemize | |
448 | ||
449 | @item | |
450 | Setting @ref{bgp always-compare-med}, however this allows MED to be compared | |
451 | across values set by different neighbour ASes, which may not produce | |
452 | coherent desirable results, of itself. | |
453 | ||
454 | @item | |
455 | Effectively ignoring MED by setting MED to the same value (e.g.@: 0) using | |
456 | @ref{routemap set metric} on all received routes, in combination with | |
457 | setting @ref{bgp always-compare-med} on all speakers. This is the simplest | |
458 | and most performant way to avoid MED oscillation issues, where an AS is happy | |
459 | not to allow neighbours to inject this problematic metric. | |
460 | ||
461 | @end itemize | |
462 | ||
463 | As MED is evaluated after the AS_PATH length check, another possible use for | |
464 | MED is for intra-AS steering of routes with equal AS_PATH length, as an | |
465 | extension of the last case above. As MED is evaluated before IGP metric, | |
466 | this can allow cold-potato routing to be implemented to send traffic to | |
467 | preferred hand-offs with neighbours, rather than the closest hand-off | |
468 | according to the IGP metric. | |
469 | ||
470 | Note that even if action is taken to address the MED non-transitivity | |
471 | issues, other oscillations may still be possible. E.g., on IGP cost if | |
472 | iBGP and IGP topologies are at cross-purposes with each other - see the | |
473 | Flavel and Roughan paper above for an example. Hence the guideline that the | |
474 | iBGP topology should follow the IGP topology. | |
475 | ||
476 | @deffn {BGP} {bgp deterministic-med} {} | |
477 | @anchor{bgp deterministic-med} | |
478 | ||
479 | Carry out route-selection in way that produces deterministic answers | |
480 | locally, even in the face of MED and the lack of a well-defined order of | |
481 | preference it can induce on routes. Without this option the preferred route | |
482 | with MED may be determined largely by the order that routes were received | |
483 | in. | |
484 | ||
485 | Setting this option will have a performance cost that may be noticeable when | |
438f5286 | 486 | there are many routes for each destination. Currently in Frr it is |
d767b4d0 PJ |
487 | implemented in a way that scales poorly as the number of routes per |
488 | destination increases. | |
489 | ||
490 | The default is that this option is not set. | |
491 | @end deffn | |
492 | ||
493 | Note that there are other sources of indeterminism in the route selection | |
494 | process, specifically, the preference for older and already selected routes | |
495 | from eBGP peers, @xref{BGP decision process}. | |
496 | ||
497 | @deffn {BGP} {bgp always-compare-med} {} | |
498 | @anchor{bgp always-compare-med} | |
499 | ||
500 | Always compare the MED on routes, even when they were received from | |
501 | different neighbouring ASes. Setting this option makes the order of | |
502 | preference of routes more defined, and should eliminate MED induced | |
503 | oscillations. | |
504 | ||
505 | If using this option, it may also be desirable to use @ref{routemap set | |
506 | metric} to set MED to 0 on routes received from external neighbours. | |
507 | ||
508 | This option can be used, together with @ref{routemap set metric} to use MED | |
509 | as an intra-AS metric to steer equal-length AS_PATH routes to, e.g., desired | |
510 | exit points. | |
511 | @end deffn | |
512 | ||
513 | ||
514 | ||
76b89b4a | 515 | @node BGP network |
718e3744 | 516 | @section BGP network |
517 | ||
518 | @menu | |
519 | * BGP route:: | |
520 | * Route Aggregation:: | |
521 | * Redistribute to BGP:: | |
522 | @end menu | |
523 | ||
76b89b4a | 524 | @node BGP route |
718e3744 | 525 | @subsection BGP route |
526 | ||
527 | @deffn {BGP} {network @var{A.B.C.D/M}} {} | |
528 | This command adds the announcement network. | |
529 | @example | |
530 | @group | |
531 | router bgp 1 | |
30dff1e4 DW |
532 | address-family ipv4 unicast |
533 | network 10.0.0.0/8 | |
534 | exit-address-family | |
718e3744 | 535 | @end group |
536 | @end example | |
537 | This configuration example says that network 10.0.0.0/8 will be | |
538 | announced to all neighbors. Some vendors' routers don't advertise | |
41367172 | 539 | routes if they aren't present in their IGP routing tables; @code{bgpd} |
718e3744 | 540 | doesn't care about IGP routes when announcing its routes. |
541 | @end deffn | |
542 | ||
543 | @deffn {BGP} {no network @var{A.B.C.D/M}} {} | |
544 | @end deffn | |
545 | ||
76b89b4a | 546 | @node Route Aggregation |
718e3744 | 547 | @subsection Route Aggregation |
548 | ||
549 | @deffn {BGP} {aggregate-address @var{A.B.C.D/M}} {} | |
550 | This command specifies an aggregate address. | |
551 | @end deffn | |
552 | ||
553 | @deffn {BGP} {aggregate-address @var{A.B.C.D/M} as-set} {} | |
d767b4d0 | 554 | This command specifies an aggregate address. Resulting routes include |
718e3744 | 555 | AS set. |
556 | @end deffn | |
557 | ||
558 | @deffn {BGP} {aggregate-address @var{A.B.C.D/M} summary-only} {} | |
559 | This command specifies an aggregate address. Aggreated routes will | |
560 | not be announce. | |
561 | @end deffn | |
562 | ||
563 | @deffn {BGP} {no aggregate-address @var{A.B.C.D/M}} {} | |
564 | @end deffn | |
565 | ||
76b89b4a | 566 | @node Redistribute to BGP |
718e3744 | 567 | @subsection Redistribute to BGP |
568 | ||
569 | @deffn {BGP} {redistribute kernel} {} | |
570 | Redistribute kernel route to BGP process. | |
571 | @end deffn | |
572 | ||
573 | @deffn {BGP} {redistribute static} {} | |
574 | Redistribute static route to BGP process. | |
575 | @end deffn | |
576 | ||
577 | @deffn {BGP} {redistribute connected} {} | |
578 | Redistribute connected route to BGP process. | |
579 | @end deffn | |
580 | ||
581 | @deffn {BGP} {redistribute rip} {} | |
582 | Redistribute RIP route to BGP process. | |
583 | @end deffn | |
584 | ||
585 | @deffn {BGP} {redistribute ospf} {} | |
586 | Redistribute OSPF route to BGP process. | |
587 | @end deffn | |
588 | ||
65efcfce LB |
589 | @deffn {BGP} {redistribute vpn} {} |
590 | Redistribute VNC routes to BGP process. | |
591 | @end deffn | |
592 | ||
f188f2c4 DS |
593 | @deffn {BGP} {update-delay @var{max-delay}} {} |
594 | @deffnx {BGP} {update-delay @var{max-delay} @var{establish-wait}} {} | |
595 | This feature is used to enable read-only mode on BGP process restart or when | |
596 | BGP process is cleared using 'clear ip bgp *'. When applicable, read-only mode | |
597 | would begin as soon as the first peer reaches Established status and a timer | |
598 | for max-delay seconds is started. | |
599 | ||
600 | During this mode BGP doesn't run any best-path or generate any updates to its | |
601 | peers. This mode continues until: | |
602 | 1. All the configured peers, except the shutdown peers, have sent explicit EOR | |
603 | (End-Of-RIB) or an implicit-EOR. The first keep-alive after BGP has reached | |
604 | Established is considered an implicit-EOR. | |
605 | If the establish-wait optional value is given, then BGP will wait for | |
606 | peers to reach established from the begining of the update-delay till the | |
607 | establish-wait period is over, i.e. the minimum set of established peers for | |
608 | which EOR is expected would be peers established during the establish-wait | |
609 | window, not necessarily all the configured neighbors. | |
610 | 2. max-delay period is over. | |
611 | On hitting any of the above two conditions, BGP resumes the decision process | |
612 | and generates updates to its peers. | |
613 | ||
614 | Default max-delay is 0, i.e. the feature is off by default. | |
615 | @end deffn | |
616 | ||
73ac8160 DS |
617 | @deffn {BGP} {table-map @var{route-map-name}} {} |
618 | This feature is used to apply a route-map on route updates from BGP to Zebra. | |
619 | All the applicable match operations are allowed, such as match on prefix, | |
620 | next-hop, communities, etc. Set operations for this attach-point are limited | |
621 | to metric and next-hop only. Any operation of this feature does not affect | |
622 | BGPs internal RIB. | |
623 | ||
624 | Supported for ipv4 and ipv6 address families. It works on multi-paths as well, | |
625 | however, metric setting is based on the best-path only. | |
626 | @end deffn | |
627 | ||
76b89b4a | 628 | @node BGP Peer |
718e3744 | 629 | @section BGP Peer |
630 | ||
631 | @menu | |
632 | * Defining Peer:: | |
633 | * BGP Peer commands:: | |
634 | * Peer filtering:: | |
635 | @end menu | |
636 | ||
76b89b4a | 637 | @node Defining Peer |
718e3744 | 638 | @subsection Defining Peer |
639 | ||
640 | @deffn {BGP} {neighbor @var{peer} remote-as @var{asn}} {} | |
641 | Creates a new neighbor whose remote-as is @var{asn}. @var{peer} | |
642 | can be an IPv4 address or an IPv6 address. | |
643 | @example | |
644 | @group | |
645 | router bgp 1 | |
646 | neighbor 10.0.0.1 remote-as 2 | |
647 | @end group | |
648 | @end example | |
649 | In this case my router, in AS-1, is trying to peer with AS-2 at | |
650 | 10.0.0.1. | |
651 | ||
652 | This command must be the first command used when configuring a neighbor. | |
653 | If the remote-as is not specified, @command{bgpd} will complain like this: | |
654 | @example | |
655 | can't find neighbor 10.0.0.1 | |
656 | @end example | |
657 | @end deffn | |
658 | ||
76b89b4a | 659 | @node BGP Peer commands |
718e3744 | 660 | @subsection BGP Peer commands |
661 | ||
662 | In a @code{router bgp} clause there are neighbor specific configurations | |
663 | required. | |
664 | ||
665 | @deffn {BGP} {neighbor @var{peer} shutdown} {} | |
666 | @deffnx {BGP} {no neighbor @var{peer} shutdown} {} | |
667 | Shutdown the peer. We can delete the neighbor's configuration by | |
668 | @code{no neighbor @var{peer} remote-as @var{as-number}} but all | |
669 | configuration of the neighbor will be deleted. When you want to | |
670 | preserve the configuration, but want to drop the BGP peer, use this | |
671 | syntax. | |
672 | @end deffn | |
673 | ||
674 | @deffn {BGP} {neighbor @var{peer} ebgp-multihop} {} | |
675 | @deffnx {BGP} {no neighbor @var{peer} ebgp-multihop} {} | |
676 | @end deffn | |
677 | ||
678 | @deffn {BGP} {neighbor @var{peer} description ...} {} | |
679 | @deffnx {BGP} {no neighbor @var{peer} description ...} {} | |
680 | Set description of the peer. | |
681 | @end deffn | |
682 | ||
683 | @deffn {BGP} {neighbor @var{peer} version @var{version}} {} | |
684 | Set up the neighbor's BGP version. @var{version} can be @var{4}, | |
685 | @var{4+} or @var{4-}. BGP version @var{4} is the default value used for | |
686 | BGP peering. BGP version @var{4+} means that the neighbor supports | |
687 | Multiprotocol Extensions for BGP-4. BGP version @var{4-} is similar but | |
688 | the neighbor speaks the old Internet-Draft revision 00's Multiprotocol | |
689 | Extensions for BGP-4. Some routing software is still using this | |
690 | version. | |
691 | @end deffn | |
692 | ||
693 | @deffn {BGP} {neighbor @var{peer} interface @var{ifname}} {} | |
694 | @deffnx {BGP} {no neighbor @var{peer} interface @var{ifname}} {} | |
825cd49e PJ |
695 | When you connect to a BGP peer over an IPv6 link-local address, you |
696 | have to specify the @var{ifname} of the interface used for the | |
697 | connection. To specify IPv4 session addresses, see the | |
698 | @code{neighbor @var{peer} update-source} command below. | |
699 | ||
700 | This command is deprecated and may be removed in a future release. Its | |
701 | use should be avoided. | |
718e3744 | 702 | @end deffn |
703 | ||
1ac2e776 DL |
704 | @deffn {BGP} {neighbor @var{peer} next-hop-self [all]} {} |
705 | @deffnx {BGP} {no neighbor @var{peer} next-hop-self [all]} {} | |
718e3744 | 706 | This command specifies an announced route's nexthop as being equivalent |
9e7a53c1 TT |
707 | to the address of the bgp router if it is learned via eBGP. |
708 | If the optional keyword @code{all} is specified the modifiation is done | |
709 | also for routes learned via iBGP. | |
718e3744 | 710 | @end deffn |
711 | ||
466c9656 | 712 | @deffn {BGP} {neighbor @var{peer} update-source @var{<ifname|address>}} {} |
718e3744 | 713 | @deffnx {BGP} {no neighbor @var{peer} update-source} {} |
825cd49e PJ |
714 | Specify the IPv4 source address to use for the @acronym{BGP} session to this |
715 | neighbour, may be specified as either an IPv4 address directly or | |
716 | as an interface name (in which case the @command{zebra} daemon MUST be running | |
717 | in order for @command{bgpd} to be able to retrieve interface state). | |
718 | @example | |
719 | @group | |
720 | router bgp 64555 | |
721 | neighbor foo update-source 192.168.0.1 | |
722 | neighbor bar update-source lo0 | |
723 | @end group | |
724 | @end example | |
718e3744 | 725 | @end deffn |
726 | ||
727 | @deffn {BGP} {neighbor @var{peer} default-originate} {} | |
728 | @deffnx {BGP} {no neighbor @var{peer} default-originate} {} | |
729 | @command{bgpd}'s default is to not announce the default route (0.0.0.0/0) even it | |
730 | is in routing table. When you want to announce default routes to the | |
731 | peer, use this command. | |
732 | @end deffn | |
733 | ||
734 | @deffn {BGP} {neighbor @var{peer} port @var{port}} {} | |
735 | @deffnx {BGP} {neighbor @var{peer} port @var{port}} {} | |
736 | @end deffn | |
737 | ||
738 | @deffn {BGP} {neighbor @var{peer} send-community} {} | |
739 | @deffnx {BGP} {neighbor @var{peer} send-community} {} | |
740 | @end deffn | |
741 | ||
742 | @deffn {BGP} {neighbor @var{peer} weight @var{weight}} {} | |
743 | @deffnx {BGP} {no neighbor @var{peer} weight @var{weight}} {} | |
744 | This command specifies a default @var{weight} value for the neighbor's | |
745 | routes. | |
746 | @end deffn | |
747 | ||
748 | @deffn {BGP} {neighbor @var{peer} maximum-prefix @var{number}} {} | |
749 | @deffnx {BGP} {no neighbor @var{peer} maximum-prefix @var{number}} {} | |
750 | @end deffn | |
751 | ||
5aebb9c7 AC |
752 | @deffn {BGP} {neighbor @var{peer} local-as @var{as-number}} {} |
753 | @deffnx {BGP} {neighbor @var{peer} local-as @var{as-number} no-prepend} {} | |
754 | @deffnx {BGP} {neighbor @var{peer} local-as @var{as-number} no-prepend replace-as} {} | |
755 | @deffnx {BGP} {no neighbor @var{peer} local-as} {} | |
756 | Specify an alternate AS for this BGP process when interacting with the | |
757 | specified peer. With no modifiers, the specified local-as is prepended to | |
758 | the received AS_PATH when receiving routing updates from the peer, and | |
759 | prepended to the outgoing AS_PATH (after the process local AS) when | |
760 | transmitting local routes to the peer. | |
761 | ||
762 | If the no-prepend attribute is specified, then the supplied local-as is not | |
763 | prepended to the received AS_PATH. | |
764 | ||
765 | If the replace-as attribute is specified, then only the supplied local-as is | |
766 | prepended to the AS_PATH when transmitting local-route updates to this peer. | |
767 | ||
768 | Note that replace-as can only be specified if no-prepend is. | |
769 | ||
770 | This command is only allowed for eBGP peers. | |
771 | @end deffn | |
772 | ||
5d804b43 PM |
773 | @deffn {BGP} {neighbor @var{peer} ttl-security hops @var{number}} {} |
774 | @deffnx {BGP} {no neighbor @var{peer} ttl-security hops @var{number}} {} | |
775 | This command enforces Generalized TTL Security Mechanism (GTSM), as | |
776 | specified in RFC 5082. With this command, only neighbors that are the | |
777 | specified number of hops away will be allowed to become neighbors. This | |
778 | command is mututally exclusive with @command{ebgp-multihop}. | |
779 | @end deffn | |
780 | ||
76b89b4a | 781 | @node Peer filtering |
718e3744 | 782 | @subsection Peer filtering |
783 | ||
784 | @deffn {BGP} {neighbor @var{peer} distribute-list @var{name} [in|out]} {} | |
785 | This command specifies a distribute-list for the peer. @var{direct} is | |
786 | @samp{in} or @samp{out}. | |
787 | @end deffn | |
788 | ||
789 | @deffn {BGP command} {neighbor @var{peer} prefix-list @var{name} [in|out]} {} | |
790 | @end deffn | |
791 | ||
792 | @deffn {BGP command} {neighbor @var{peer} filter-list @var{name} [in|out]} {} | |
793 | @end deffn | |
794 | ||
795 | @deffn {BGP} {neighbor @var{peer} route-map @var{name} [in|out]} {} | |
796 | Apply a route-map on the neighbor. @var{direct} must be @code{in} or | |
797 | @code{out}. | |
798 | @end deffn | |
799 | ||
8bd9d948 DS |
800 | @deffn {BGP} {bgp route-reflector allow-outbound-policy} {} |
801 | By default, attribute modification via route-map policy out is not reflected | |
802 | on reflected routes. This option allows the modifications to be reflected as | |
803 | well. Once enabled, it affects all reflected routes. | |
804 | @end deffn | |
805 | ||
718e3744 | 806 | @c ----------------------------------------------------------------------- |
76b89b4a | 807 | @node BGP Peer Group |
718e3744 | 808 | @section BGP Peer Group |
809 | ||
810 | @deffn {BGP} {neighbor @var{word} peer-group} {} | |
811 | This command defines a new peer group. | |
812 | @end deffn | |
813 | ||
814 | @deffn {BGP} {neighbor @var{peer} peer-group @var{word}} {} | |
815 | This command bind specific peer to peer group @var{word}. | |
816 | @end deffn | |
817 | ||
76b89b4a | 818 | @node BGP Address Family |
718e3744 | 819 | @section BGP Address Family |
820 | ||
d81c7f12 LB |
821 | Multiprotocol BGP enables BGP to carry routing information for multiple |
822 | Network Layer protocols. BGP supports multiple Address Family | |
823 | Identifier (AFI), namely IPv4 and IPv6. Support is also provided for | |
824 | multiple sets of per-AFI information via Subsequent Address Family | |
825 | Identifiers (SAFI). In addition to unicast information, VPN information | |
3bb7cd7f | 826 | @cite{RFC4364} and @cite{RFC4659}, and Encapsulation attribute |
d81c7f12 LB |
827 | @cite{RFC5512} is supported. |
828 | ||
ff216554 LB |
829 | @deffn {Command} {show ip bgp ipv4 vpn} {} |
830 | @deffnx {Command} {show ipv6 bgp ipv6 vpn} {} | |
d81c7f12 LB |
831 | Print active IPV4 or IPV6 routes advertised via the VPN SAFI. |
832 | @end deffn | |
833 | ||
3bb7cd7f | 834 | @deffn {Command} {show bgp ipv4 vpn summary} {} |
d81c7f12 LB |
835 | @deffnx {Command} {show bgp ipv6 vpn summary} {} |
836 | Print a summary of neighbor connections for the specified AFI/SAFI combination. | |
837 | @end deffn | |
838 | ||
718e3744 | 839 | @c ----------------------------------------------------------------------- |
76b89b4a | 840 | @node Autonomous System |
718e3744 | 841 | @section Autonomous System |
842 | ||
aa5943f7 | 843 | The @acronym{AS,Autonomous System} number is one of the essential |
844 | element of BGP. BGP is a distance vector routing protocol, and the | |
845 | AS-Path framework provides distance vector metric and loop detection to | |
846 | BGP. @cite{RFC1930, Guidelines for creation, selection, and | |
847 | registration of an Autonomous System (AS)} provides some background on | |
848 | the concepts of an AS. | |
718e3744 | 849 | |
aa5943f7 | 850 | The AS number is a two octet value, ranging in value from 1 to 65535. |
851 | The AS numbers 64512 through 65535 are defined as private AS numbers. | |
852 | Private AS numbers must not to be advertised in the global Internet. | |
718e3744 | 853 | |
854 | @menu | |
718e3744 | 855 | * Display BGP Routes by AS Path:: |
856 | * AS Path Access List:: | |
857 | * Using AS Path in Route Map:: | |
858 | * Private AS Numbers:: | |
859 | @end menu | |
860 | ||
76b89b4a | 861 | @node Display BGP Routes by AS Path |
718e3744 | 862 | @subsection Display BGP Routes by AS Path |
863 | ||
aa5943f7 | 864 | To show BGP routes which has specific AS path information @code{show |
718e3744 | 865 | ip bgp} command can be used. |
866 | ||
47e7c0b9 NK |
867 | @deffn Command {show bgp @{ipv4|ipv6@} regexp @var{line}} {} |
868 | This commands displays BGP routes that matches a regular | |
869 | expression @var{line} (@pxref{BGP Regular Expressions}). | |
718e3744 | 870 | @end deffn |
871 | ||
76b89b4a | 872 | @node AS Path Access List |
718e3744 | 873 | @subsection AS Path Access List |
874 | ||
aa5943f7 | 875 | AS path access list is user defined AS path. |
718e3744 | 876 | |
877 | @deffn {Command} {ip as-path access-list @var{word} @{permit|deny@} @var{line}} {} | |
878 | This command defines a new AS path access list. | |
879 | @end deffn | |
880 | ||
881 | @deffn {Command} {no ip as-path access-list @var{word}} {} | |
882 | @deffnx {Command} {no ip as-path access-list @var{word} @{permit|deny@} @var{line}} {} | |
883 | @end deffn | |
884 | ||
76b89b4a | 885 | @node Using AS Path in Route Map |
718e3744 | 886 | @subsection Using AS Path in Route Map |
887 | ||
888 | @deffn {Route Map} {match as-path @var{word}} {} | |
889 | @end deffn | |
890 | ||
891 | @deffn {Route Map} {set as-path prepend @var{as-path}} {} | |
9b97a19b PJ |
892 | Prepend the given string of AS numbers to the AS_PATH. |
893 | @end deffn | |
894 | ||
895 | @deffn {Route Map} {set as-path prepend last-as @var{num}} {} | |
896 | Prepend the existing last AS number (the leftmost ASN) to the AS_PATH. | |
718e3744 | 897 | @end deffn |
898 | ||
76b89b4a | 899 | @node Private AS Numbers |
718e3744 | 900 | @subsection Private AS Numbers |
901 | ||
718e3744 | 902 | @c ----------------------------------------------------------------------- |
76b89b4a | 903 | @node BGP Communities Attribute |
718e3744 | 904 | @section BGP Communities Attribute |
905 | ||
aa5943f7 | 906 | BGP communities attribute is widely used for implementing policy |
718e3744 | 907 | routing. Network operators can manipulate BGP communities attribute |
908 | based on their network policy. BGP communities attribute is defined | |
aa5943f7 | 909 | in @cite{RFC1997, BGP Communities Attribute} and |
910 | @cite{RFC1998, An Application of the BGP Community Attribute | |
718e3744 | 911 | in Multi-home Routing}. It is an optional transitive attribute, |
912 | therefore local policy can travel through different autonomous system. | |
913 | ||
aa5943f7 | 914 | Communities attribute is a set of communities values. Each |
718e3744 | 915 | communities value is 4 octet long. The following format is used to |
916 | define communities value. | |
917 | ||
918 | @table @code | |
919 | @item AS:VAL | |
920 | This format represents 4 octet communities value. @code{AS} is high | |
921 | order 2 octet in digit format. @code{VAL} is low order 2 octet in | |
922 | digit format. This format is useful to define AS oriented policy | |
923 | value. For example, @code{7675:80} can be used when AS 7675 wants to | |
924 | pass local policy value 80 to neighboring peer. | |
925 | @item internet | |
926 | @code{internet} represents well-known communities value 0. | |
927 | @item no-export | |
928 | @code{no-export} represents well-known communities value @code{NO_EXPORT}@* | |
929 | @r{(0xFFFFFF01)}. All routes carry this value must not be advertised | |
930 | to outside a BGP confederation boundary. If neighboring BGP peer is | |
931 | part of BGP confederation, the peer is considered as inside a BGP | |
932 | confederation boundary, so the route will be announced to the peer. | |
933 | @item no-advertise | |
934 | @code{no-advertise} represents well-known communities value | |
935 | @code{NO_ADVERTISE}@*@r{(0xFFFFFF02)}. All routes carry this value | |
936 | must not be advertise to other BGP peers. | |
937 | @item local-AS | |
938 | @code{local-AS} represents well-known communities value | |
939 | @code{NO_EXPORT_SUBCONFED} @r{(0xFFFFFF03)}. All routes carry this | |
940 | value must not be advertised to external BGP peers. Even if the | |
941 | neighboring router is part of confederation, it is considered as | |
942 | external BGP peer, so the route will not be announced to the peer. | |
943 | @end table | |
944 | ||
945 | When BGP communities attribute is received, duplicated communities | |
946 | value in the communities attribute is ignored and each communities | |
947 | values are sorted in numerical order. | |
948 | ||
949 | @menu | |
950 | * BGP Community Lists:: | |
951 | * Numbered BGP Community Lists:: | |
952 | * BGP Community in Route Map:: | |
953 | * Display BGP Routes by Community:: | |
954 | * Using BGP Communities Attribute:: | |
955 | @end menu | |
956 | ||
76b89b4a | 957 | @node BGP Community Lists |
718e3744 | 958 | @subsection BGP Community Lists |
959 | ||
960 | BGP community list is a user defined BGP communites attribute list. | |
961 | BGP community list can be used for matching or manipulating BGP | |
962 | communities attribute in updates. | |
963 | ||
aa5943f7 | 964 | There are two types of community list. One is standard community |
718e3744 | 965 | list and another is expanded community list. Standard community list |
966 | defines communities attribute. Expanded community list defines | |
967 | communities attribute string with regular expression. Standard | |
968 | community list is compiled into binary format when user define it. | |
969 | Standard community list will be directly compared to BGP communities | |
970 | attribute in BGP updates. Therefore the comparison is faster than | |
971 | expanded community list. | |
972 | ||
973 | @deffn Command {ip community-list standard @var{name} @{permit|deny@} @var{community}} {} | |
974 | This command defines a new standard community list. @var{community} | |
975 | is communities value. The @var{community} is compiled into community | |
976 | structure. We can define multiple community list under same name. In | |
977 | that case match will happen user defined order. Once the | |
978 | community list matches to communities attribute in BGP updates it | |
979 | return permit or deny by the community list definition. When there is | |
980 | no matched entry, deny will be returned. When @var{community} is | |
981 | empty it matches to any routes. | |
982 | @end deffn | |
983 | ||
984 | @deffn Command {ip community-list expanded @var{name} @{permit|deny@} @var{line}} {} | |
985 | This command defines a new expanded community list. @var{line} is a | |
47e7c0b9 NK |
986 | string expression of communities attribute. @var{line} can be a |
987 | regular expression (@pxref{BGP Regular Expressions}) to match | |
988 | the communities attribute in BGP updates. | |
718e3744 | 989 | @end deffn |
990 | ||
991 | @deffn Command {no ip community-list @var{name}} {} | |
992 | @deffnx Command {no ip community-list standard @var{name}} {} | |
993 | @deffnx Command {no ip community-list expanded @var{name}} {} | |
994 | These commands delete community lists specified by @var{name}. All of | |
995 | community lists shares a single name space. So community lists can be | |
996 | removed simpley specifying community lists name. | |
997 | @end deffn | |
998 | ||
999 | @deffn {Command} {show ip community-list} {} | |
1000 | @deffnx {Command} {show ip community-list @var{name}} {} | |
4f65c0d6 | 1001 | This command displays current community list information. When |
718e3744 | 1002 | @var{name} is specified the specified community list's information is |
1003 | shown. | |
1004 | ||
1005 | @example | |
1006 | # show ip community-list | |
1007 | Named Community standard list CLIST | |
1008 | permit 7675:80 7675:100 no-export | |
1009 | deny internet | |
1010 | Named Community expanded list EXPAND | |
1011 | permit : | |
1012 | ||
1013 | # show ip community-list CLIST | |
1014 | Named Community standard list CLIST | |
1015 | permit 7675:80 7675:100 no-export | |
1016 | deny internet | |
1017 | @end example | |
1018 | @end deffn | |
1019 | ||
76b89b4a | 1020 | @node Numbered BGP Community Lists |
718e3744 | 1021 | @subsection Numbered BGP Community Lists |
1022 | ||
aa5943f7 | 1023 | When number is used for BGP community list name, the number has |
718e3744 | 1024 | special meanings. Community list number in the range from 1 and 99 is |
1025 | standard community list. Community list number in the range from 100 | |
1026 | to 199 is expanded community list. These community lists are called | |
1027 | as numbered community lists. On the other hand normal community lists | |
1028 | is called as named community lists. | |
1029 | ||
1030 | @deffn Command {ip community-list <1-99> @{permit|deny@} @var{community}} {} | |
1031 | This command defines a new community list. <1-99> is standard | |
1032 | community list number. Community list name within this range defines | |
1033 | standard community list. When @var{community} is empty it matches to | |
1034 | any routes. | |
1035 | @end deffn | |
1036 | ||
1037 | @deffn Command {ip community-list <100-199> @{permit|deny@} @var{community}} {} | |
1038 | This command defines a new community list. <100-199> is expanded | |
1039 | community list number. Community list name within this range defines | |
1040 | expanded community list. | |
1041 | @end deffn | |
1042 | ||
1043 | @deffn Command {ip community-list @var{name} @{permit|deny@} @var{community}} {} | |
1044 | When community list type is not specifed, the community list type is | |
1045 | automatically detected. If @var{community} can be compiled into | |
1046 | communities attribute, the community list is defined as a standard | |
1047 | community list. Otherwise it is defined as an expanded community | |
1048 | list. This feature is left for backward compability. Use of this | |
1049 | feature is not recommended. | |
1050 | @end deffn | |
1051 | ||
76b89b4a | 1052 | @node BGP Community in Route Map |
718e3744 | 1053 | @subsection BGP Community in Route Map |
1054 | ||
aa5943f7 | 1055 | In Route Map (@pxref{Route Map}), we can match or set BGP |
718e3744 | 1056 | communities attribute. Using this feature network operator can |
1057 | implement their network policy based on BGP communities attribute. | |
1058 | ||
aa5943f7 | 1059 | Following commands can be used in Route Map. |
718e3744 | 1060 | |
1061 | @deffn {Route Map} {match community @var{word}} {} | |
1062 | @deffnx {Route Map} {match community @var{word} exact-match} {} | |
1063 | This command perform match to BGP updates using community list | |
1064 | @var{word}. When the one of BGP communities value match to the one of | |
1065 | communities value in community list, it is match. When | |
1066 | @code{exact-match} keyword is spcified, match happen only when BGP | |
1067 | updates have completely same communities value specified in the | |
1068 | community list. | |
1069 | @end deffn | |
1070 | ||
1071 | @deffn {Route Map} {set community none} {} | |
1072 | @deffnx {Route Map} {set community @var{community}} {} | |
1073 | @deffnx {Route Map} {set community @var{community} additive} {} | |
1074 | This command manipulate communities value in BGP updates. When | |
1075 | @code{none} is specified as communities value, it removes entire | |
1076 | communities attribute from BGP updates. When @var{community} is not | |
1077 | @code{none}, specified communities value is set to BGP updates. If | |
1078 | BGP updates already has BGP communities value, the existing BGP | |
1079 | communities value is replaced with specified @var{community} value. | |
1080 | When @code{additive} keyword is specified, @var{community} is appended | |
1081 | to the existing communities value. | |
1082 | @end deffn | |
1083 | ||
1084 | @deffn {Route Map} {set comm-list @var{word} delete} {} | |
1085 | This command remove communities value from BGP communities attribute. | |
1086 | The @var{word} is community list name. When BGP route's communities | |
1087 | value matches to the community list @var{word}, the communities value | |
1088 | is removed. When all of communities value is removed eventually, the | |
1089 | BGP update's communities attribute is completely removed. | |
1090 | @end deffn | |
1091 | ||
76b89b4a | 1092 | @node Display BGP Routes by Community |
718e3744 | 1093 | @subsection Display BGP Routes by Community |
1094 | ||
aa5943f7 | 1095 | To show BGP routes which has specific BGP communities attribute, |
b0e019cc NK |
1096 | @code{show bgp @{ipv4|ipv6@}} command can be used. The |
1097 | @var{community} and @var{community-list} subcommand can be used. | |
1098 | ||
1099 | @deffn Command {show bgp @{ipv4|ipv6@} community} {} | |
1100 | @deffnx Command {show bgp @{ipv4|ipv6@} community @var{community}} {} | |
1101 | @deffnx Command {show bgp @{ipv4|ipv6@} community @var{community} exact-match} {} | |
1102 | @code{show bgp @{ipv4|ipv6@} community} displays BGP routes which has communities | |
1103 | attribute. Where the address family can be IPv4 or IPv6 among others. When | |
1104 | @var{community} is specified, BGP routes that matches @var{community} value is | |
1105 | displayed. For this command, @code{internet} keyword can't be used for | |
1106 | @var{community} value. When @code{exact-match} is specified, it display only | |
1107 | routes that have an exact match. | |
1108 | @end deffn | |
1109 | ||
1110 | @deffn Command {show bgp @{ipv4|ipv6@} community-list @var{word}} {} | |
1111 | @deffnx Command {show bgp @{ipv4|ipv6@} community-list @var{word} exact-match} {} | |
1112 | This commands display BGP routes for the address family specified that matches | |
1113 | community list @var{word}. When @code{exact-match} is specified, display only | |
1114 | routes that have an exact match. | |
718e3744 | 1115 | @end deffn |
1116 | ||
76b89b4a | 1117 | @node Using BGP Communities Attribute |
718e3744 | 1118 | @subsection Using BGP Communities Attribute |
1119 | ||
aa5943f7 | 1120 | Following configuration is the most typical usage of BGP communities |
718e3744 | 1121 | attribute. AS 7675 provides upstream Internet connection to AS 100. |
1122 | When following configuration exists in AS 7675, AS 100 networks | |
1123 | operator can set local preference in AS 7675 network by setting BGP | |
1124 | communities attribute to the updates. | |
1125 | ||
1126 | @example | |
1127 | router bgp 7675 | |
1128 | neighbor 192.168.0.1 remote-as 100 | |
30dff1e4 DW |
1129 | address-family ipv4 unicast |
1130 | neighbor 192.168.0.1 route-map RMAP in | |
1131 | exit-address-family | |
718e3744 | 1132 | ! |
1133 | ip community-list 70 permit 7675:70 | |
1134 | ip community-list 70 deny | |
1135 | ip community-list 80 permit 7675:80 | |
1136 | ip community-list 80 deny | |
1137 | ip community-list 90 permit 7675:90 | |
1138 | ip community-list 90 deny | |
1139 | ! | |
1140 | route-map RMAP permit 10 | |
1141 | match community 70 | |
1142 | set local-preference 70 | |
1143 | ! | |
1144 | route-map RMAP permit 20 | |
1145 | match community 80 | |
1146 | set local-preference 80 | |
1147 | ! | |
1148 | route-map RMAP permit 30 | |
1149 | match community 90 | |
1150 | set local-preference 90 | |
1151 | @end example | |
1152 | ||
aa5943f7 | 1153 | Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675. |
718e3744 | 1154 | The route has communities value 7675:80 so when above configuration |
1155 | exists in AS 7675, announced route's local preference will be set to | |
1156 | value 80. | |
1157 | ||
1158 | @example | |
1159 | router bgp 100 | |
1160 | network 10.0.0.0/8 | |
1161 | neighbor 192.168.0.2 remote-as 7675 | |
30dff1e4 DW |
1162 | address-family ipv4 unicast |
1163 | neighbor 192.168.0.2 route-map RMAP out | |
1164 | exit-address-family | |
718e3744 | 1165 | ! |
1166 | ip prefix-list PLIST permit 10.0.0.0/8 | |
1167 | ! | |
1168 | route-map RMAP permit 10 | |
1169 | match ip address prefix-list PLIST | |
1170 | set community 7675:80 | |
1171 | @end example | |
1172 | ||
aa5943f7 | 1173 | Following configuration is an example of BGP route filtering using |
718e3744 | 1174 | communities attribute. This configuration only permit BGP routes |
1175 | which has BGP communities value 0:80 or 0:90. Network operator can | |
1176 | put special internal communities value at BGP border router, then | |
1177 | limit the BGP routes announcement into the internal network. | |
1178 | ||
1179 | @example | |
1180 | router bgp 7675 | |
1181 | neighbor 192.168.0.1 remote-as 100 | |
30dff1e4 DW |
1182 | address-family ipv4 unicast |
1183 | neighbor 192.168.0.1 route-map RMAP in | |
1184 | exit-address-family | |
718e3744 | 1185 | ! |
1186 | ip community-list 1 permit 0:80 0:90 | |
1187 | ! | |
1188 | route-map RMAP permit in | |
1189 | match community 1 | |
1190 | @end example | |
1191 | ||
aa5943f7 | 1192 | Following exmaple filter BGP routes which has communities value 1:1. |
718e3744 | 1193 | When there is no match community-list returns deny. To avoid |
1194 | filtering all of routes, we need to define permit any at last. | |
1195 | ||
1196 | @example | |
1197 | router bgp 7675 | |
1198 | neighbor 192.168.0.1 remote-as 100 | |
30dff1e4 DW |
1199 | address-family ipv4 unicast |
1200 | neighbor 192.168.0.1 route-map RMAP in | |
1201 | exit-address-family | |
718e3744 | 1202 | ! |
1203 | ip community-list standard FILTER deny 1:1 | |
1204 | ip community-list standard FILTER permit | |
1205 | ! | |
1206 | route-map RMAP permit 10 | |
1207 | match community FILTER | |
1208 | @end example | |
1209 | ||
aa5943f7 | 1210 | Communities value keyword @code{internet} has special meanings in |
718e3744 | 1211 | standard community lists. In below example @code{internet} act as |
1212 | match any. It matches all of BGP routes even if the route does not | |
1213 | have communities attribute at all. So community list @code{INTERNET} | |
1214 | is same as above example's @code{FILTER}. | |
1215 | ||
1216 | @example | |
1217 | ip community-list standard INTERNET deny 1:1 | |
1218 | ip community-list standard INTERNET permit internet | |
1219 | @end example | |
1220 | ||
aa5943f7 | 1221 | Following configuration is an example of communities value deletion. |
718e3744 | 1222 | With this configuration communities value 100:1 and 100:2 is removed |
1223 | from BGP updates. For communities value deletion, only @code{permit} | |
1224 | community-list is used. @code{deny} community-list is ignored. | |
1225 | ||
1226 | @example | |
1227 | router bgp 7675 | |
1228 | neighbor 192.168.0.1 remote-as 100 | |
30dff1e4 DW |
1229 | address-family ipv4 unicast |
1230 | neighbor 192.168.0.1 route-map RMAP in | |
1231 | exit-address-family | |
718e3744 | 1232 | ! |
1233 | ip community-list standard DEL permit 100:1 100:2 | |
1234 | ! | |
1235 | route-map RMAP permit 10 | |
1236 | set comm-list DEL delete | |
1237 | @end example | |
1238 | ||
1239 | @c ----------------------------------------------------------------------- | |
76b89b4a | 1240 | @node BGP Extended Communities Attribute |
718e3744 | 1241 | @section BGP Extended Communities Attribute |
1242 | ||
aa5943f7 | 1243 | BGP extended communities attribute is introduced with MPLS VPN/BGP |
718e3744 | 1244 | technology. MPLS VPN/BGP expands capability of network infrastructure |
1245 | to provide VPN functionality. At the same time it requires a new | |
1246 | framework for policy routing. With BGP Extended Communities Attribute | |
1247 | we can use Route Target or Site of Origin for implementing network | |
1248 | policy for MPLS VPN/BGP. | |
1249 | ||
aa5943f7 | 1250 | BGP Extended Communities Attribute is similar to BGP Communities |
718e3744 | 1251 | Attribute. It is an optional transitive attribute. BGP Extended |
1252 | Communities Attribute can carry multiple Extended Community value. | |
1253 | Each Extended Community value is eight octet length. | |
1254 | ||
aa5943f7 | 1255 | BGP Extended Communities Attribute provides an extended range |
718e3744 | 1256 | compared with BGP Communities Attribute. Adding to that there is a |
1257 | type field in each value to provides community space structure. | |
1258 | ||
aa5943f7 | 1259 | There are two format to define Extended Community value. One is AS |
718e3744 | 1260 | based format the other is IP address based format. |
1261 | ||
1262 | @table @code | |
1263 | @item AS:VAL | |
1264 | This is a format to define AS based Extended Community value. | |
1265 | @code{AS} part is 2 octets Global Administrator subfield in Extended | |
1266 | Community value. @code{VAL} part is 4 octets Local Administrator | |
1267 | subfield. @code{7675:100} represents AS 7675 policy value 100. | |
1268 | @item IP-Address:VAL | |
1269 | This is a format to define IP address based Extended Community value. | |
1270 | @code{IP-Address} part is 4 octets Global Administrator subfield. | |
1271 | @code{VAL} part is 2 octets Local Administrator subfield. | |
1272 | @code{10.0.0.1:100} represents | |
1273 | @end table | |
1274 | ||
1275 | @menu | |
1276 | * BGP Extended Community Lists:: | |
1277 | * BGP Extended Communities in Route Map:: | |
1278 | @end menu | |
1279 | ||
76b89b4a | 1280 | @node BGP Extended Community Lists |
718e3744 | 1281 | @subsection BGP Extended Community Lists |
1282 | ||
aa5943f7 | 1283 | Expanded Community Lists is a user defined BGP Expanded Community |
718e3744 | 1284 | Lists. |
1285 | ||
1286 | @deffn Command {ip extcommunity-list standard @var{name} @{permit|deny@} @var{extcommunity}} {} | |
1287 | This command defines a new standard extcommunity-list. | |
1288 | @var{extcommunity} is extended communities value. The | |
1289 | @var{extcommunity} is compiled into extended community structure. We | |
1290 | can define multiple extcommunity-list under same name. In that case | |
1291 | match will happen user defined order. Once the extcommunity-list | |
1292 | matches to extended communities attribute in BGP updates it return | |
1293 | permit or deny based upon the extcommunity-list definition. When | |
1294 | there is no matched entry, deny will be returned. When | |
1295 | @var{extcommunity} is empty it matches to any routes. | |
1296 | @end deffn | |
1297 | ||
1298 | @deffn Command {ip extcommunity-list expanded @var{name} @{permit|deny@} @var{line}} {} | |
1299 | This command defines a new expanded extcommunity-list. @var{line} is | |
1300 | a string expression of extended communities attribute. @var{line} can | |
47e7c0b9 NK |
1301 | be a regular expression (@pxref{BGP Regular Expressions}) to match an |
1302 | extended communities attribute in BGP updates. | |
718e3744 | 1303 | @end deffn |
1304 | ||
1305 | @deffn Command {no ip extcommunity-list @var{name}} {} | |
1306 | @deffnx Command {no ip extcommunity-list standard @var{name}} {} | |
1307 | @deffnx Command {no ip extcommunity-list expanded @var{name}} {} | |
1308 | These commands delete extended community lists specified by | |
1309 | @var{name}. All of extended community lists shares a single name | |
1310 | space. So extended community lists can be removed simpley specifying | |
1311 | the name. | |
1312 | @end deffn | |
1313 | ||
1314 | @deffn {Command} {show ip extcommunity-list} {} | |
1315 | @deffnx {Command} {show ip extcommunity-list @var{name}} {} | |
4f65c0d6 | 1316 | This command displays current extcommunity-list information. When |
718e3744 | 1317 | @var{name} is specified the community list's information is shown. |
1318 | ||
1319 | @example | |
1320 | # show ip extcommunity-list | |
1321 | @end example | |
1322 | @end deffn | |
1323 | ||
76b89b4a | 1324 | @node BGP Extended Communities in Route Map |
718e3744 | 1325 | @subsection BGP Extended Communities in Route Map |
1326 | ||
1327 | @deffn {Route Map} {match extcommunity @var{word}} {} | |
1328 | @end deffn | |
1329 | ||
1330 | @deffn {Route Map} {set extcommunity rt @var{extcommunity}} {} | |
1331 | This command set Route Target value. | |
1332 | @end deffn | |
1333 | ||
1334 | @deffn {Route Map} {set extcommunity soo @var{extcommunity}} {} | |
1335 | This command set Site of Origin value. | |
1336 | @end deffn | |
1337 | ||
1338 | @c ----------------------------------------------------------------------- | |
ca383542 NK |
1339 | @node BGP Large Communities Attribute |
1340 | @section BGP Large Communities Attribute | |
1341 | ||
1342 | The BGP Large Communities attribute was introduced in Feb 2017 with | |
1343 | @cite{RFC8092, BGP Large Communities Attribute}. | |
1344 | ||
1345 | The BGP Large Communities Attribute is similar to the BGP Communities | |
1346 | Attribute except that it has 3 components instead of two and each of | |
1347 | which are 4 octets in length. Large Communities bring additional | |
1348 | functionality and convenience over traditional communities, specifically | |
1349 | the fact that the @code{GLOBAL} part below is now 4 octets wide allowing | |
1350 | AS4 operators seamless use. | |
1351 | ||
1352 | @table @code | |
1353 | @item GLOBAL:LOCAL1:LOCAL2 | |
1354 | This is the format to define Large Community values. Referencing | |
1355 | @cite{RFC8195, Use of BGP Large Communities} the values are commonly | |
1356 | referred to as follows. | |
1357 | The @code{GLOBAL} part is a 4 octet Global Administrator field, common | |
1358 | use of this field is the operators AS number. | |
1359 | The @code{LOCAL1} part is a 4 octet Local Data Part 1 subfield referred | |
1360 | to as a function. | |
1361 | The @code{LOCAL2} part is a 4 octet Local Data Part 2 field and referred | |
1362 | to as the parameter subfield. @code{65551:1:10} represents AS 65551 | |
1363 | function 1 and parameter 10. | |
1364 | The referenced RFC above gives some guidelines on recommended usage. | |
1365 | @end table | |
1366 | ||
1367 | @menu | |
1368 | * BGP Large Community Lists:: | |
1369 | * BGP Large Communities in Route Map:: | |
1370 | @end menu | |
1371 | ||
1372 | @node BGP Large Community Lists | |
1373 | @subsection BGP Large Community Lists | |
1374 | ||
1375 | Two types of large community lists are supported, namely @code{standard} and | |
1376 | @code{expanded}. | |
1377 | ||
1378 | @deffn Command {ip large-community-list standard @var{name} @{permit|deny@} @var{large-community}} {} | |
1379 | This command defines a new standard large-community-list. | |
1380 | @var{large-community} is the Large Community value. We | |
1381 | can add multiple large communities under same name. In that case | |
1382 | the match will happen in the user defined order. Once the large-community-list | |
1383 | matches the Large Communities attribute in BGP updates it will return | |
1384 | permit or deny based upon the large-community-list definition. When | |
1385 | there is no matched entry, a deny will be returned. When @var{large-community} | |
1386 | is empty it matches any routes. | |
1387 | @end deffn | |
1388 | ||
1389 | @deffn Command {ip large-community-list expanded @var{name} @{permit|deny@} @var{line}} {} | |
1390 | This command defines a new expanded large-community-list. Where @var{line} is | |
1391 | a string matching expression, it will be compared to the entire Large Communities | |
1392 | attribute as a string, with each large-community in order from lowest to highest. | |
1393 | @var{line} can also be a regular expression which matches this Large | |
1394 | Community attribute. | |
1395 | @end deffn | |
1396 | ||
1397 | @deffn Command {no ip large-community-list @var{name}} {} | |
1398 | @deffnx Command {no ip large-community-list standard @var{name}} {} | |
1399 | @deffnx Command {no ip large-community-list expanded @var{name}} {} | |
1400 | These commands delete Large Community lists specified by | |
1401 | @var{name}. All Large Community lists share a single namespace. | |
1402 | This means Large Community lists can be removed by simply specifying the name. | |
1403 | @end deffn | |
1404 | ||
1405 | @deffn {Command} {show ip large-community-list} {} | |
1406 | @deffnx {Command} {show ip large-community-list @var{name}} {} | |
1407 | This command display current large-community-list information. When | |
1408 | @var{name} is specified the community list information is shown. | |
1409 | @end deffn | |
1410 | ||
1411 | @deffn {Command} {show ip bgp large-community-info} {} | |
1412 | This command displays the current large communities in use. | |
1413 | @end deffn | |
1414 | ||
1415 | @node BGP Large Communities in Route Map | |
1416 | @subsection BGP Large Communities in Route Map | |
1417 | ||
1418 | @deffn {Route Map} {match large-community @var{line}} {} | |
1419 | Where @var{line} can be a simple string to match, or a regular expression. | |
1420 | It is very important to note that this match occurs on the entire | |
1421 | large-community string as a whole, where each large-community is ordered | |
1422 | from lowest to highest. | |
1423 | @end deffn | |
1424 | ||
1425 | @deffn {Route Map} {set large-community @var{large-community}} {} | |
1426 | @deffnx {Route Map} {set large-community @var{large-community} @var{large-community}} {} | |
1427 | @deffnx {Route Map} {set large-community @var{large-community} additive} {} | |
1428 | These commands are used for setting large-community values. The first | |
1429 | command will overwrite any large-communities currently present. | |
1430 | The second specifies two large-communities, which overwrites the current | |
1431 | large-community list. The third will add a large-community value without | |
1432 | overwriting other values. Multiple large-community values can be specified. | |
1433 | @end deffn | |
1434 | ||
1435 | @c ----------------------------------------------------------------------- | |
1436 | ||
446176bd NK |
1437 | @node Displaying BGP information |
1438 | @section Displaying BGP information | |
718e3744 | 1439 | |
1440 | @menu | |
446176bd NK |
1441 | * Showing BGP information:: |
1442 | * Other BGP commands:: | |
718e3744 | 1443 | @end menu |
1444 | ||
446176bd NK |
1445 | @node Showing BGP information |
1446 | @subsection Showing BGP information | |
718e3744 | 1447 | |
1448 | @deffn {Command} {show ip bgp} {} | |
1449 | @deffnx {Command} {show ip bgp @var{A.B.C.D}} {} | |
1450 | @deffnx {Command} {show ip bgp @var{X:X::X:X}} {} | |
1451 | This command displays BGP routes. When no route is specified it | |
1452 | display all of IPv4 BGP routes. | |
1453 | @end deffn | |
1454 | ||
1455 | @example | |
1456 | BGP table version is 0, local router ID is 10.1.1.1 | |
1457 | Status codes: s suppressed, d damped, h history, * valid, > best, i - internal | |
1458 | Origin codes: i - IGP, e - EGP, ? - incomplete | |
1459 | ||
1460 | Network Next Hop Metric LocPrf Weight Path | |
1461 | *> 1.1.1.1/32 0.0.0.0 0 32768 i | |
1462 | ||
1463 | Total number of prefixes 1 | |
1464 | @end example | |
1465 | ||
718e3744 | 1466 | @deffn {Command} {show ip bgp regexp @var{line}} {} |
47e7c0b9 NK |
1467 | This command displays BGP routes using AS path regular expression |
1468 | (@pxref{BGP Regular Expressions}). | |
718e3744 | 1469 | @end deffn |
1470 | ||
1471 | @deffn Command {show ip bgp community @var{community}} {} | |
1472 | @deffnx Command {show ip bgp community @var{community} exact-match} {} | |
4f65c0d6 | 1473 | This command displays BGP routes using @var{community} (@pxref{Display |
718e3744 | 1474 | BGP Routes by Community}). |
1475 | @end deffn | |
1476 | ||
1477 | @deffn Command {show ip bgp community-list @var{word}} {} | |
1478 | @deffnx Command {show ip bgp community-list @var{word} exact-match} {} | |
4f65c0d6 | 1479 | This command displays BGP routes using community list (@pxref{Display |
718e3744 | 1480 | BGP Routes by Community}). |
1481 | @end deffn | |
1482 | ||
446176bd NK |
1483 | @deffn {Command} {show bgp @{ipv4|ipv6@} summary} {} |
1484 | Show a bgp peer summary for the specified address family. | |
718e3744 | 1485 | @end deffn |
1486 | ||
446176bd NK |
1487 | @deffn {Command} {show bgp @{ipv4|ipv6@} neighbor [@var{peer}]} {} |
1488 | This command shows information on a specific BGP @var{peer}. | |
718e3744 | 1489 | @end deffn |
1490 | ||
446176bd NK |
1491 | @deffn {Command} {show bgp @{ipv4|ipv6@} dampening dampened-paths} {} |
1492 | Display paths suppressed due to dampening. | |
718e3744 | 1493 | @end deffn |
1494 | ||
446176bd NK |
1495 | @deffn {Command} {show bgp @{ipv4|ipv6@} dampening flap-statistics} {} |
1496 | Display flap statistics of routes. | |
1497 | @end deffn | |
1498 | ||
1499 | @node Other BGP commands | |
1500 | @subsection Other BGP commands | |
1501 | ||
1502 | @deffn {Command} {clear bgp @{ipv4|ipv6@} *} {} | |
1503 | Clear all address family peers. | |
718e3744 | 1504 | @end deffn |
1505 | ||
446176bd NK |
1506 | @deffn {Command} {clear bgp @{ipv4|ipv6@} @var{peer}} {} |
1507 | Clear peers which have addresses of X.X.X.X | |
c31e5726 AC |
1508 | @end deffn |
1509 | ||
446176bd NK |
1510 | @deffn {Command} {clear bgp @{ipv4|ipv6@} @var{peer} soft in} {} |
1511 | Clear peer using soft reconfiguration. | |
c31e5726 AC |
1512 | @end deffn |
1513 | ||
718e3744 | 1514 | @deffn {Command} {show debug} {} |
1515 | @end deffn | |
1516 | ||
1517 | @deffn {Command} {debug event} {} | |
1518 | @end deffn | |
1519 | ||
1520 | @deffn {Command} {debug update} {} | |
1521 | @end deffn | |
1522 | ||
1523 | @deffn {Command} {debug keepalive} {} | |
1524 | @end deffn | |
1525 | ||
1526 | @deffn {Command} {no debug event} {} | |
1527 | @end deffn | |
1528 | ||
1529 | @deffn {Command} {no debug update} {} | |
1530 | @end deffn | |
1531 | ||
1532 | @deffn {Command} {no debug keepalive} {} | |
1533 | @end deffn | |
1534 | ||
76b89b4a | 1535 | @node Capability Negotiation |
718e3744 | 1536 | @section Capability Negotiation |
1537 | ||
aa5943f7 | 1538 | When adding IPv6 routing information exchange feature to BGP. There |
1539 | were some proposals. @acronym{IETF,Internet Engineering Task Force} | |
1540 | @acronym{IDR, Inter Domain Routing} @acronym{WG, Working group} adopted | |
1541 | a proposal called Multiprotocol Extension for BGP. The specification | |
1542 | is described in @cite{RFC2283}. The protocol does not define new protocols. | |
1543 | It defines new attributes to existing BGP. When it is used exchanging | |
1544 | IPv6 routing information it is called BGP-4+. When it is used for | |
1545 | exchanging multicast routing information it is called MBGP. | |
1546 | ||
1547 | @command{bgpd} supports Multiprotocol Extension for BGP. So if remote | |
1548 | peer supports the protocol, @command{bgpd} can exchange IPv6 and/or | |
1549 | multicast routing information. | |
1550 | ||
1551 | Traditional BGP did not have the feature to detect remote peer's | |
1552 | capabilities, e.g. whether it can handle prefix types other than IPv4 | |
1553 | unicast routes. This was a big problem using Multiprotocol Extension | |
1554 | for BGP to operational network. @cite{RFC2842, Capabilities | |
1555 | Advertisement with BGP-4} adopted a feature called Capability | |
1556 | Negotiation. @command{bgpd} use this Capability Negotiation to detect | |
1557 | the remote peer's capabilities. If the peer is only configured as IPv4 | |
1558 | unicast neighbor, @command{bgpd} does not send these Capability | |
1559 | Negotiation packets (at least not unless other optional BGP features | |
1560 | require capability negotation). | |
1561 | ||
438f5286 | 1562 | By default, Frr will bring up peering with minimal common capability |
aa5943f7 | 1563 | for the both sides. For example, local router has unicast and |
1564 | multicast capabilitie and remote router has unicast capability. In | |
1565 | this case, the local router will establish the connection with unicast | |
438f5286 | 1566 | only capability. When there are no common capabilities, Frr sends |
aa5943f7 | 1567 | Unsupported Capability error and then resets the connection. |
1568 | ||
1569 | If you want to completely match capabilities with remote peer. Please | |
718e3744 | 1570 | use @command{strict-capability-match} command. |
1571 | ||
1572 | @deffn {BGP} {neighbor @var{peer} strict-capability-match} {} | |
1573 | @deffnx {BGP} {no neighbor @var{peer} strict-capability-match} {} | |
1574 | Strictly compares remote capabilities and local capabilities. If capabilities | |
1575 | are different, send Unsupported Capability error then reset connection. | |
1576 | @end deffn | |
1577 | ||
aa5943f7 | 1578 | You may want to disable sending Capability Negotiation OPEN message |
718e3744 | 1579 | optional parameter to the peer when remote peer does not implement |
1580 | Capability Negotiation. Please use @command{dont-capability-negotiate} | |
1581 | command to disable the feature. | |
1582 | ||
1583 | @deffn {BGP} {neighbor @var{peer} dont-capability-negotiate} {} | |
1584 | @deffnx {BGP} {no neighbor @var{peer} dont-capability-negotiate} {} | |
1585 | Suppress sending Capability Negotiation as OPEN message optional | |
1586 | parameter to the peer. This command only affects the peer is configured | |
1587 | other than IPv4 unicast configuration. | |
1588 | @end deffn | |
1589 | ||
aa5943f7 | 1590 | When remote peer does not have capability negotiation feature, remote |
1591 | peer will not send any capabilities at all. In that case, bgp | |
1592 | configures the peer with configured capabilities. | |
718e3744 | 1593 | |
aa5943f7 | 1594 | You may prefer locally configured capabilities more than the negotiated |
1595 | capabilities even though remote peer sends capabilities. If the peer | |
1596 | is configured by @command{override-capability}, @command{bgpd} ignores | |
1597 | received capabilities then override negotiated capabilities with | |
1598 | configured values. | |
718e3744 | 1599 | |
1600 | @deffn {BGP} {neighbor @var{peer} override-capability} {} | |
1601 | @deffnx {BGP} {no neighbor @var{peer} override-capability} {} | |
1602 | Override the result of Capability Negotiation with local configuration. | |
1603 | Ignore remote peer's capability value. | |
1604 | @end deffn | |
1605 | ||
76b89b4a | 1606 | @node Route Reflector |
718e3744 | 1607 | @section Route Reflector |
1608 | ||
1609 | @deffn {BGP} {bgp cluster-id @var{a.b.c.d}} {} | |
1610 | @end deffn | |
1611 | ||
1612 | @deffn {BGP} {neighbor @var{peer} route-reflector-client} {} | |
1613 | @deffnx {BGP} {no neighbor @var{peer} route-reflector-client} {} | |
1614 | @end deffn | |
1615 | ||
76b89b4a | 1616 | @node Route Server |
718e3744 | 1617 | @section Route Server |
1618 | ||
1619 | At an Internet Exchange point, many ISPs are connected to each other by | |
1620 | external BGP peering. Normally these external BGP connection are done by | |
aa5943f7 | 1621 | @samp{full mesh} method. As with internal BGP full mesh formation, |
718e3744 | 1622 | this method has a scaling problem. |
1623 | ||
1624 | This scaling problem is well known. Route Server is a method to resolve | |
1625 | the problem. Each ISP's BGP router only peers to Route Server. Route | |
1626 | Server serves as BGP information exchange to other BGP routers. By | |
1627 | applying this method, numbers of BGP connections is reduced from | |
1628 | O(n*(n-1)/2) to O(n). | |
1629 | ||
1630 | Unlike normal BGP router, Route Server must have several routing tables | |
1631 | for managing different routing policies for each BGP speaker. We call the | |
1632 | routing tables as different @code{view}s. @command{bgpd} can work as | |
1633 | normal BGP router or Route Server or both at the same time. | |
1634 | ||
1635 | @menu | |
1636 | * Multiple instance:: | |
1637 | * BGP instance and view:: | |
1638 | * Routing policy:: | |
1639 | * Viewing the view:: | |
1640 | @end menu | |
1641 | ||
76b89b4a | 1642 | @node Multiple instance |
718e3744 | 1643 | @subsection Multiple instance |
1644 | ||
1645 | To enable multiple view function of @code{bgpd}, you must turn on | |
1646 | multiple instance feature beforehand. | |
1647 | ||
1648 | @deffn {Command} {bgp multiple-instance} {} | |
1649 | Enable BGP multiple instance feature. After this feature is enabled, | |
1650 | you can make multiple BGP instances or multiple BGP views. | |
1651 | @end deffn | |
1652 | ||
1653 | @deffn {Command} {no bgp multiple-instance} {} | |
1654 | Disable BGP multiple instance feature. You can not disable this feature | |
1655 | when BGP multiple instances or views exist. | |
1656 | @end deffn | |
1657 | ||
1658 | When you want to make configuration more Cisco like one, | |
1659 | ||
1660 | @deffn {Command} {bgp config-type cisco} {} | |
1661 | Cisco compatible BGP configuration output. | |
1662 | @end deffn | |
1663 | ||
1664 | When bgp config-type cisco is specified, | |
1665 | ||
1666 | ``no synchronization'' is displayed. | |
2b09e211 | 1667 | ``no auto-summary'' is displayed. |
718e3744 | 1668 | |
1669 | ``network'' and ``aggregate-address'' argument is displayed as | |
1670 | ``A.B.C.D M.M.M.M'' | |
1671 | ||
438f5286 | 1672 | Frr: network 10.0.0.0/8 |
718e3744 | 1673 | Cisco: network 10.0.0.0 |
1674 | ||
438f5286 | 1675 | Frr: aggregate-address 192.168.0.0/24 |
718e3744 | 1676 | Cisco: aggregate-address 192.168.0.0 255.255.255.0 |
1677 | ||
1678 | Community attribute handling is also different. If there is no | |
1679 | configuration is specified community attribute and extended community | |
1680 | attribute are sent to neighbor. When user manually disable the | |
1681 | feature community attribute is not sent to the neighbor. In case of | |
aa5943f7 | 1682 | @command{bgp config-type cisco} is specified, community attribute is not |
718e3744 | 1683 | sent to the neighbor by default. To send community attribute user has |
aa5943f7 | 1684 | to specify @command{neighbor A.B.C.D send-community} command. |
718e3744 | 1685 | |
aa5943f7 | 1686 | @example |
718e3744 | 1687 | ! |
1688 | router bgp 1 | |
1689 | neighbor 10.0.0.1 remote-as 1 | |
30dff1e4 DW |
1690 | address-family ipv4 unicast |
1691 | no neighbor 10.0.0.1 send-community | |
1692 | exit-address-family | |
718e3744 | 1693 | ! |
718e3744 | 1694 | router bgp 1 |
1695 | neighbor 10.0.0.1 remote-as 1 | |
30dff1e4 DW |
1696 | address-family ipv4 unicast |
1697 | neighbor 10.0.0.1 send-community | |
1698 | exit-address-family | |
718e3744 | 1699 | ! |
aa5943f7 | 1700 | @end example |
718e3744 | 1701 | |
1702 | @deffn {Command} {bgp config-type zebra} {} | |
438f5286 | 1703 | Frr style BGP configuration. This is default. |
718e3744 | 1704 | @end deffn |
1705 | ||
76b89b4a | 1706 | @node BGP instance and view |
718e3744 | 1707 | @subsection BGP instance and view |
1708 | ||
1709 | BGP instance is a normal BGP process. The result of route selection | |
1710 | goes to the kernel routing table. You can setup different AS at the | |
1711 | same time when BGP multiple instance feature is enabled. | |
1712 | ||
1713 | @deffn {Command} {router bgp @var{as-number}} {} | |
1714 | Make a new BGP instance. You can use arbitrary word for the @var{name}. | |
1715 | @end deffn | |
1716 | ||
1717 | @example | |
1718 | @group | |
1719 | bgp multiple-instance | |
1720 | ! | |
1721 | router bgp 1 | |
1722 | neighbor 10.0.0.1 remote-as 2 | |
1723 | neighbor 10.0.0.2 remote-as 3 | |
1724 | ! | |
1725 | router bgp 2 | |
1726 | neighbor 10.0.0.3 remote-as 4 | |
1727 | neighbor 10.0.0.4 remote-as 5 | |
1728 | @end group | |
1729 | @end example | |
1730 | ||
1731 | BGP view is almost same as normal BGP process. The result of | |
1732 | route selection does not go to the kernel routing table. BGP view is | |
1733 | only for exchanging BGP routing information. | |
1734 | ||
1735 | @deffn {Command} {router bgp @var{as-number} view @var{name}} {} | |
1736 | Make a new BGP view. You can use arbitrary word for the @var{name}. This | |
1737 | view's route selection result does not go to the kernel routing table. | |
1738 | @end deffn | |
1739 | ||
1740 | With this command, you can setup Route Server like below. | |
1741 | ||
1742 | @example | |
1743 | @group | |
1744 | bgp multiple-instance | |
1745 | ! | |
1746 | router bgp 1 view 1 | |
1747 | neighbor 10.0.0.1 remote-as 2 | |
1748 | neighbor 10.0.0.2 remote-as 3 | |
1749 | ! | |
1750 | router bgp 2 view 2 | |
1751 | neighbor 10.0.0.3 remote-as 4 | |
1752 | neighbor 10.0.0.4 remote-as 5 | |
1753 | @end group | |
1754 | @end example | |
1755 | ||
76b89b4a | 1756 | @node Routing policy |
718e3744 | 1757 | @subsection Routing policy |
1758 | ||
1759 | You can set different routing policy for a peer. For example, you can | |
1760 | set different filter for a peer. | |
1761 | ||
1762 | @example | |
1763 | @group | |
1764 | bgp multiple-instance | |
1765 | ! | |
1766 | router bgp 1 view 1 | |
1767 | neighbor 10.0.0.1 remote-as 2 | |
30dff1e4 DW |
1768 | address-family ipv4 unicast |
1769 | neighbor 10.0.0.1 distribute-list 1 in | |
1770 | exit-address-family | |
718e3744 | 1771 | ! |
1772 | router bgp 1 view 2 | |
1773 | neighbor 10.0.0.1 remote-as 2 | |
30dff1e4 DW |
1774 | address-family ipv4 unicast |
1775 | neighbor 10.0.0.1 distribute-list 2 in | |
1776 | exit-address-family | |
718e3744 | 1777 | @end group |
1778 | @end example | |
1779 | ||
1780 | This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view | |
1781 | 2. When the update is inserted into view 1, distribute-list 1 is | |
1782 | applied. On the other hand, when the update is inserted into view 2, | |
1783 | distribute-list 2 is applied. | |
1784 | ||
76b89b4a | 1785 | @node Viewing the view |
718e3744 | 1786 | @subsection Viewing the view |
1787 | ||
1788 | To display routing table of BGP view, you must specify view name. | |
1789 | ||
1790 | @deffn {Command} {show ip bgp view @var{name}} {} | |
1791 | Display routing table of BGP view @var{name}. | |
1792 | @end deffn | |
1793 | ||
47e7c0b9 NK |
1794 | @node BGP Regular Expressions |
1795 | @section BGP Regular Expressions | |
1796 | ||
1797 | BGP regular expressions are based on @code{POSIX 1003.2} regular | |
1798 | expressions. The following description is just a quick subset of the | |
1799 | @code{POSIX} regular expressions. Adding to that, the special character | |
1800 | '_' is added. | |
1801 | ||
1802 | @table @code | |
1803 | @item . | |
1804 | Matches any single character. | |
1805 | @item * | |
1806 | Matches 0 or more occurrences of pattern. | |
1807 | @item + | |
1808 | Matches 1 or more occurrences of pattern. | |
1809 | @item ? | |
1810 | Match 0 or 1 occurrences of pattern. | |
1811 | @item ^ | |
1812 | Matches the beginning of the line. | |
1813 | @item $ | |
1814 | Matches the end of the line. | |
1815 | @item _ | |
1816 | Character @code{_} has special meanings in BGP regular expressions. | |
1817 | It matches to space and comma , and AS set delimiter @{ and @} and AS | |
1818 | confederation delimiter @code{(} and @code{)}. And it also matches to | |
1819 | the beginning of the line and the end of the line. So @code{_} can be | |
1820 | used for AS value boundaries match. This character technically evaluates | |
1821 | to @code{(^|[,@{@}() ]|$)}. | |
1822 | @end table | |
1823 | ||
76b89b4a | 1824 | @node How to set up a 6-Bone connection |
718e3744 | 1825 | @section How to set up a 6-Bone connection |
1826 | ||
6a22b1fc | 1827 | |
718e3744 | 1828 | @example |
1829 | @group | |
1830 | zebra configuration | |
1831 | =================== | |
1832 | ! | |
1833 | ! Actually there is no need to configure zebra | |
1834 | ! | |
1835 | ||
1836 | bgpd configuration | |
1837 | ================== | |
1838 | ! | |
1839 | ! This means that routes go through zebra and into the kernel. | |
1840 | ! | |
1841 | router zebra | |
1842 | ! | |
1843 | ! MP-BGP configuration | |
1844 | ! | |
1845 | router bgp 7675 | |
1846 | bgp router-id 10.0.0.1 | |
1847 | neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as @var{as-number} | |
1848 | ! | |
1849 | address-family ipv6 | |
1850 | network 3ffe:506::/32 | |
1851 | neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate | |
1852 | neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out | |
1853 | neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as @var{as-number} | |
1854 | neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out | |
1855 | exit-address-family | |
1856 | ! | |
1857 | ipv6 access-list all permit any | |
1858 | ! | |
1859 | ! Set output nexthop address. | |
1860 | ! | |
1861 | route-map set-nexthop permit 10 | |
1862 | match ipv6 address all | |
1863 | set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225 | |
1864 | set ipv6 nexthop local fe80::2c0:4fff:fe68:a225 | |
1865 | ! | |
1866 | ! logfile FILENAME is obsolete. Please use log file FILENAME | |
7190f4ea | 1867 | |
718e3744 | 1868 | log file bgpd.log |
1869 | ! | |
1870 | @end group | |
1871 | @end example | |
1872 | ||
76b89b4a | 1873 | @node Dump BGP packets and table |
718e3744 | 1874 | @section Dump BGP packets and table |
1875 | ||
4db5d90a AF |
1876 | @deffn Command {dump bgp all @var{path} [@var{interval}]} {} |
1877 | @deffnx Command {dump bgp all-et @var{path} [@var{interval}]} {} | |
1878 | @deffnx Command {no dump bgp all [@var{path}] [@var{interval}]} {} | |
718e3744 | 1879 | Dump all BGP packet and events to @var{path} file. |
4db5d90a AF |
1880 | If @var{interval} is set, a new file will be created for echo @var{interval} of seconds. |
1881 | The path @var{path} can be set with date and time formatting (strftime). | |
1882 | The type ‘all-et’ enables support for Extended Timestamp Header (@pxref{Packet Binary Dump Format}). | |
1883 | (@pxref{Packet Binary Dump Format}) | |
718e3744 | 1884 | @end deffn |
1885 | ||
4db5d90a AF |
1886 | @deffn Command {dump bgp updates @var{path} [@var{interval}]} {} |
1887 | @deffnx Command {dump bgp updates-et @var{path} [@var{interval}]} {} | |
1888 | @deffnx Command {no dump bgp updates [@var{path}] [@var{interval}]} {} | |
1889 | Dump only BGP updates messages to @var{path} file. | |
1890 | If @var{interval} is set, a new file will be created for echo @var{interval} of seconds. | |
1891 | The path @var{path} can be set with date and time formatting (strftime). | |
1892 | The type ‘updates-et’ enables support for Extended Timestamp Header (@pxref{Packet Binary Dump Format}). | |
718e3744 | 1893 | @end deffn |
1894 | ||
4db5d90a AF |
1895 | @deffn Command {dump bgp routes-mrt @var{path}} {} |
1896 | @deffnx Command {dump bgp routes-mrt @var{path} @var{interval}} {} | |
1897 | @deffnx Command {no dump bgp route-mrt [@var{path}] [@var{interval}]} {} | |
718e3744 | 1898 | Dump whole BGP routing table to @var{path}. This is heavy process. |
4db5d90a AF |
1899 | The path @var{path} can be set with date and time formatting (strftime). |
1900 | If @var{interval} is set, a new file will be created for echo @var{interval} of seconds. | |
718e3744 | 1901 | @end deffn |
aa5943f7 | 1902 | |
4db5d90a AF |
1903 | Note: the interval variable can also be set using hours and minutes: 04h20m00. |
1904 | ||
1905 | ||
aa5943f7 | 1906 | @node BGP Configuration Examples |
1907 | @section BGP Configuration Examples | |
1908 | ||
1909 | Example of a session to an upstream, advertising only one prefix to it. | |
1910 | ||
1911 | @example | |
1912 | router bgp 64512 | |
1913 | bgp router-id 10.236.87.1 | |
aa5943f7 | 1914 | neighbor upstream peer-group |
1915 | neighbor upstream remote-as 64515 | |
1916 | neighbor upstream capability dynamic | |
aa5943f7 | 1917 | neighbor 10.1.1.1 peer-group upstream |
1918 | neighbor 10.1.1.1 description ACME ISP | |
30dff1e4 DW |
1919 | |
1920 | address-family ipv4 unicast | |
1921 | network 10.236.87.0/24 | |
1922 | neighbor upstream prefix-list pl-allowed-adv out | |
1923 | exit-address-family | |
aa5943f7 | 1924 | ! |
1925 | ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25 | |
1926 | ip prefix-list pl-allowed-adv seq 10 deny any | |
1927 | ||
1928 | @end example | |
1929 | ||
1930 | A more complex example. With upstream, peer and customer sessions. | |
1931 | Advertising global prefixes and NO_EXPORT prefixes and providing | |
1932 | actions for customer routes based on community values. Extensive use of | |
1933 | route-maps and the 'call' feature to support selective advertising of | |
1934 | prefixes. This example is intended as guidance only, it has NOT been | |
1935 | tested and almost certainly containts silly mistakes, if not serious | |
1936 | flaws. | |
1937 | ||
1938 | @example | |
1939 | router bgp 64512 | |
1940 | bgp router-id 10.236.87.1 | |
aa5943f7 | 1941 | neighbor upstream capability dynamic |
aa5943f7 | 1942 | neighbor cust capability dynamic |
aa5943f7 | 1943 | neighbor peer capability dynamic |
aa5943f7 | 1944 | neighbor 10.1.1.1 remote-as 64515 |
1945 | neighbor 10.1.1.1 peer-group upstream | |
1946 | neighbor 10.2.1.1 remote-as 64516 | |
1947 | neighbor 10.2.1.1 peer-group upstream | |
1948 | neighbor 10.3.1.1 remote-as 64517 | |
1949 | neighbor 10.3.1.1 peer-group cust-default | |
1950 | neighbor 10.3.1.1 description customer1 | |
aa5943f7 | 1951 | neighbor 10.4.1.1 remote-as 64518 |
1952 | neighbor 10.4.1.1 peer-group cust | |
aa5943f7 | 1953 | neighbor 10.4.1.1 description customer2 |
1954 | neighbor 10.5.1.1 remote-as 64519 | |
1955 | neighbor 10.5.1.1 peer-group peer | |
aa5943f7 | 1956 | neighbor 10.5.1.1 description peer AS 1 |
1957 | neighbor 10.6.1.1 remote-as 64520 | |
1958 | neighbor 10.6.1.1 peer-group peer | |
aa5943f7 | 1959 | neighbor 10.6.1.1 description peer AS 2 |
30dff1e4 DW |
1960 | |
1961 | address-family ipv4 unicast | |
1962 | network 10.123.456.0/24 | |
1963 | network 10.123.456.128/25 route-map rm-no-export | |
1964 | neighbor upstream route-map rm-upstream-out out | |
1965 | neighbor cust route-map rm-cust-in in | |
1966 | neighbor cust route-map rm-cust-out out | |
1967 | neighbor cust send-community both | |
1968 | neighbor peer route-map rm-peer-in in | |
1969 | neighbor peer route-map rm-peer-out out | |
1970 | neighbor peer send-community both | |
1971 | neighbor 10.3.1.1 prefix-list pl-cust1-network in | |
1972 | neighbor 10.4.1.1 prefix-list pl-cust2-network in | |
1973 | neighbor 10.5.1.1 prefix-list pl-peer1-network in | |
1974 | neighbor 10.6.1.1 prefix-list pl-peer2-network in | |
1975 | exit-address-family | |
aa5943f7 | 1976 | ! |
1977 | ip prefix-list pl-default permit 0.0.0.0/0 | |
1978 | ! | |
1979 | ip prefix-list pl-upstream-peers permit 10.1.1.1/32 | |
1980 | ip prefix-list pl-upstream-peers permit 10.2.1.1/32 | |
1981 | ! | |
1982 | ip prefix-list pl-cust1-network permit 10.3.1.0/24 | |
1983 | ip prefix-list pl-cust1-network permit 10.3.2.0/24 | |
1984 | ! | |
1985 | ip prefix-list pl-cust2-network permit 10.4.1.0/24 | |
1986 | ! | |
1987 | ip prefix-list pl-peer1-network permit 10.5.1.0/24 | |
1988 | ip prefix-list pl-peer1-network permit 10.5.2.0/24 | |
1989 | ip prefix-list pl-peer1-network permit 192.168.0.0/24 | |
1990 | ! | |
1991 | ip prefix-list pl-peer2-network permit 10.6.1.0/24 | |
1992 | ip prefix-list pl-peer2-network permit 10.6.2.0/24 | |
1993 | ip prefix-list pl-peer2-network permit 192.168.1.0/24 | |
1994 | ip prefix-list pl-peer2-network permit 192.168.2.0/24 | |
1995 | ip prefix-list pl-peer2-network permit 172.16.1/24 | |
1996 | ! | |
1997 | ip as-path access-list asp-own-as permit ^$ | |
1998 | ip as-path access-list asp-own-as permit _64512_ | |
1999 | ! | |
2000 | ! ################################################################# | |
2001 | ! Match communities we provide actions for, on routes receives from | |
2002 | ! customers. Communities values of <our-ASN>:X, with X, have actions: | |
2003 | ! | |
2004 | ! 100 - blackhole the prefix | |
2005 | ! 200 - set no_export | |
2006 | ! 300 - advertise only to other customers | |
2007 | ! 400 - advertise only to upstreams | |
2008 | ! 500 - set no_export when advertising to upstreams | |
2009 | ! 2X00 - set local_preference to X00 | |
2010 | ! | |
2011 | ! blackhole the prefix of the route | |
2012 | ip community-list standard cm-blackhole permit 64512:100 | |
2013 | ! | |
2014 | ! set no-export community before advertising | |
2015 | ip community-list standard cm-set-no-export permit 64512:200 | |
2016 | ! | |
2017 | ! advertise only to other customers | |
2018 | ip community-list standard cm-cust-only permit 64512:300 | |
2019 | ! | |
2020 | ! advertise only to upstreams | |
2021 | ip community-list standard cm-upstream-only permit 64512:400 | |
2022 | ! | |
2023 | ! advertise to upstreams with no-export | |
2024 | ip community-list standard cm-upstream-noexport permit 64512:500 | |
2025 | ! | |
2026 | ! set local-pref to least significant 3 digits of the community | |
2027 | ip community-list standard cm-prefmod-100 permit 64512:2100 | |
2028 | ip community-list standard cm-prefmod-200 permit 64512:2200 | |
2029 | ip community-list standard cm-prefmod-300 permit 64512:2300 | |
2030 | ip community-list standard cm-prefmod-400 permit 64512:2400 | |
2031 | ip community-list expanded cme-prefmod-range permit 64512:2... | |
2032 | ! | |
2033 | ! Informational communities | |
2034 | ! | |
2035 | ! 3000 - learned from upstream | |
2036 | ! 3100 - learned from customer | |
2037 | ! 3200 - learned from peer | |
2038 | ! | |
2039 | ip community-list standard cm-learnt-upstream permit 64512:3000 | |
2040 | ip community-list standard cm-learnt-cust permit 64512:3100 | |
2041 | ip community-list standard cm-learnt-peer permit 64512:3200 | |
2042 | ! | |
2043 | ! ################################################################### | |
2044 | ! Utility route-maps | |
2045 | ! | |
2046 | ! These utility route-maps generally should not used to permit/deny | |
2047 | ! routes, i.e. they do not have meaning as filters, and hence probably | |
2048 | ! should be used with 'on-match next'. These all finish with an empty | |
2049 | ! permit entry so as not interfere with processing in the caller. | |
2050 | ! | |
2051 | route-map rm-no-export permit 10 | |
2052 | set community additive no-export | |
2053 | route-map rm-no-export permit 20 | |
2054 | ! | |
2055 | route-map rm-blackhole permit 10 | |
2056 | description blackhole, up-pref and ensure it cant escape this AS | |
2057 | set ip next-hop 127.0.0.1 | |
2058 | set local-preference 10 | |
2059 | set community additive no-export | |
2060 | route-map rm-blackhole permit 20 | |
2061 | ! | |
2062 | ! Set local-pref as requested | |
2063 | route-map rm-prefmod permit 10 | |
2064 | match community cm-prefmod-100 | |
2065 | set local-preference 100 | |
2066 | route-map rm-prefmod permit 20 | |
2067 | match community cm-prefmod-200 | |
2068 | set local-preference 200 | |
2069 | route-map rm-prefmod permit 30 | |
2070 | match community cm-prefmod-300 | |
2071 | set local-preference 300 | |
2072 | route-map rm-prefmod permit 40 | |
2073 | match community cm-prefmod-400 | |
2074 | set local-preference 400 | |
2075 | route-map rm-prefmod permit 50 | |
2076 | ! | |
2077 | ! Community actions to take on receipt of route. | |
2078 | route-map rm-community-in permit 10 | |
2079 | description check for blackholing, no point continuing if it matches. | |
2080 | match community cm-blackhole | |
2081 | call rm-blackhole | |
2082 | route-map rm-community-in permit 20 | |
2083 | match community cm-set-no-export | |
2084 | call rm-no-export | |
2085 | on-match next | |
2086 | route-map rm-community-in permit 30 | |
2087 | match community cme-prefmod-range | |
2088 | call rm-prefmod | |
2089 | route-map rm-community-in permit 40 | |
2090 | ! | |
2091 | ! ##################################################################### | |
2092 | ! Community actions to take when advertising a route. | |
2093 | ! These are filtering route-maps, | |
2094 | ! | |
2095 | ! Deny customer routes to upstream with cust-only set. | |
2096 | route-map rm-community-filt-to-upstream deny 10 | |
2097 | match community cm-learnt-cust | |
2098 | match community cm-cust-only | |
2099 | route-map rm-community-filt-to-upstream permit 20 | |
2100 | ! | |
2101 | ! Deny customer routes to other customers with upstream-only set. | |
2102 | route-map rm-community-filt-to-cust deny 10 | |
2103 | match community cm-learnt-cust | |
2104 | match community cm-upstream-only | |
2105 | route-map rm-community-filt-to-cust permit 20 | |
2106 | ! | |
2107 | ! ################################################################### | |
2108 | ! The top-level route-maps applied to sessions. Further entries could | |
2109 | ! be added obviously.. | |
2110 | ! | |
2111 | ! Customers | |
2112 | route-map rm-cust-in permit 10 | |
2113 | call rm-community-in | |
2114 | on-match next | |
2115 | route-map rm-cust-in permit 20 | |
2116 | set community additive 64512:3100 | |
2117 | route-map rm-cust-in permit 30 | |
2118 | ! | |
2119 | route-map rm-cust-out permit 10 | |
2120 | call rm-community-filt-to-cust | |
2121 | on-match next | |
2122 | route-map rm-cust-out permit 20 | |
2123 | ! | |
2124 | ! Upstream transit ASes | |
2125 | route-map rm-upstream-out permit 10 | |
2126 | description filter customer prefixes which are marked cust-only | |
2127 | call rm-community-filt-to-upstream | |
2128 | on-match next | |
2129 | route-map rm-upstream-out permit 20 | |
2130 | description only customer routes are provided to upstreams/peers | |
2131 | match community cm-learnt-cust | |
2132 | ! | |
2133 | ! Peer ASes | |
2134 | ! outbound policy is same as for upstream | |
2135 | route-map rm-peer-out permit 10 | |
2136 | call rm-upstream-out | |
2137 | ! | |
2138 | route-map rm-peer-in permit 10 | |
2139 | set community additive 64512:3200 | |
2140 | @end example | |
dabecd7c MR |
2141 | |
2142 | @include rpki.texi |