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