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