1: @c -*-texinfo-*-
2: @c This is part of the Quagga Manual.
3: @c @value{COPYRIGHT_STR}
4: @c See file quagga.texi for copying conditions.
5: @node BGP
6: @chapter BGP
7:
8: @acronym{BGP} stands for a Border Gateway Protocol. The lastest BGP version
9: is 4. It is referred as BGP-4. BGP-4 is one of the Exterior Gateway
10: Protocols and de-fact standard of Inter Domain routing protocol.
11: BGP-4 is described in @cite{RFC1771, A Border Gateway Protocol
12: 4 (BGP-4)}.
13:
14: Many extensions have been added to @cite{RFC1771}. @cite{RFC2858,
15: Multiprotocol Extensions for BGP-4} provides multiprotocol support to
16: BGP-4.
17:
18: @menu
19: * Starting BGP::
20: * BGP router::
21: * BGP network::
22: * BGP Peer::
23: * BGP Peer Group::
24: * BGP Address Family::
25: * Autonomous System::
26: * BGP Communities Attribute::
27: * BGP Extended Communities Attribute::
28: * Displaying BGP routes::
29: * Capability Negotiation::
30: * Route Reflector::
31: * Route Server::
32: * How to set up a 6-Bone connection::
33: * Dump BGP packets and table::
34: * BGP Configuration Examples::
35: @end menu
36:
37: @node Starting BGP
38: @section Starting BGP
39:
40: Default configuration file of @command{bgpd} is @file{bgpd.conf}.
41: @command{bgpd} searches the current directory first then
42: @value{INSTALL_PREFIX_ETC}/bgpd.conf. All of bgpd's command must be
43: configured in @file{bgpd.conf}.
44:
45: @command{bgpd} specific invocation options are described below. Common
46: options may also be specified (@pxref{Common Invocation Options}).
47:
48: @table @samp
49: @item -p @var{PORT}
50: @itemx --bgp_port=@var{PORT}
51: Set the bgp protocol's port number.
52:
53: @item -r
54: @itemx --retain
55: When program terminates, retain BGP routes added by zebra.
56: @end table
57:
58: @node BGP router
59: @section BGP router
60:
61: First of all you must configure BGP router with @command{router bgp}
62: command. To configure BGP router, you need AS number. AS number is an
63: identification of autonomous system. BGP protocol uses the AS number
64: for detecting whether the BGP connection is internal one or external one.
65:
66: @deffn Command {router bgp @var{asn}} {}
67: Enable a BGP protocol process with the specified @var{asn}. After
68: this statement you can input any @code{BGP Commands}. You can not
69: create different BGP process under different @var{asn} without
70: specifying @code{multiple-instance} (@pxref{Multiple instance}).
71: @end deffn
72:
73: @deffn Command {no router bgp @var{asn}} {}
74: Destroy a BGP protocol process with the specified @var{asn}.
75: @end deffn
76:
77: @deffn {BGP} {bgp router-id @var{A.B.C.D}} {}
78: This command specifies the router-ID. If @command{bgpd} connects to @command{zebra} it gets
79: interface and address information. In that case default router ID value
80: is selected as the largest IP Address of the interfaces. When
81: @code{router zebra} is not enabled @command{bgpd} can't get interface information
82: so @code{router-id} is set to 0.0.0.0. So please set router-id by hand.
83: @end deffn
84:
85: @menu
86: * BGP distance::
87: * BGP decision process::
88: * BGP route flap dampening::
89: @end menu
90:
91: @node BGP distance
92: @subsection BGP distance
93:
94: @deffn {BGP} {distance bgp <1-255> <1-255> <1-255>} {}
95: This command change distance value of BGP. Each argument is distance
96: value for external routes, internal routes and local routes.
97: @end deffn
98:
99: @deffn {BGP} {distance <1-255> @var{A.B.C.D/M}} {}
100: @deffnx {BGP} {distance <1-255> @var{A.B.C.D/M} @var{word}} {}
101: This command set distance value to
102: @end deffn
103:
104: @node BGP decision process
105: @subsection BGP decision process
106:
107: @table @asis
108: @item 1. Weight check
109:
110: @item 2. Local preference check.
111:
112: @item 3. Local route check.
113:
114: @item 4. AS path length check.
115:
116: @item 5. Origin check.
117:
118: @item 6. MED check.
119: @end table
120:
121: @deffn {BGP} {bgp bestpath as-path confed} {}
122: This command specifies that the length of confederation path sets and
123: sequences should should be taken into account during the BGP best path
124: decision process.
125: @end deffn
126:
127: @node BGP route flap dampening
128: @subsection BGP route flap dampening
129:
130: @deffn {BGP} {bgp dampening @var{<1-45>} @var{<1-20000>} @var{<1-20000>} @var{<1-255>}} {}
131: This command enables BGP route-flap dampening and specifies dampening parameters.
132:
133: @table @asis
134: @item @asis{half-life}
135: Half-life time for the penalty
136: @item @asis{reuse-threshold}
137: Value to start reusing a route
138: @item @asis{suppress-threshold}
139: Value to start suppressing a route
140: @item @asis{max-suppress}
141: Maximum duration to suppress a stable route
142: @end table
143:
144: The route-flap damping algorithm is compatible with @cite{RFC2439}. The use of this command
145: is not recommended nowadays, see @uref{http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378}.
146: @end deffn
147:
148: @node BGP network
149: @section BGP network
150:
151: @menu
152: * BGP route::
153: * Route Aggregation::
154: * Redistribute to BGP::
155: @end menu
156:
157: @node BGP route
158: @subsection BGP route
159:
160: @deffn {BGP} {network @var{A.B.C.D/M}} {}
161: This command adds the announcement network.
162: @example
163: @group
164: router bgp 1
165: network 10.0.0.0/8
166: @end group
167: @end example
168: This configuration example says that network 10.0.0.0/8 will be
169: announced to all neighbors. Some vendors' routers don't advertise
170: routes if they aren't present in their IGP routing tables; @code{bgpd}
171: doesn't care about IGP routes when announcing its routes.
172: @end deffn
173:
174: @deffn {BGP} {no network @var{A.B.C.D/M}} {}
175: @end deffn
176:
177: @node Route Aggregation
178: @subsection Route Aggregation
179:
180: @deffn {BGP} {aggregate-address @var{A.B.C.D/M}} {}
181: This command specifies an aggregate address.
182: @end deffn
183:
184: @deffn {BGP} {aggregate-address @var{A.B.C.D/M} as-set} {}
185: This command specifies an aggregate address. Resulting routes inlucde
186: AS set.
187: @end deffn
188:
189: @deffn {BGP} {aggregate-address @var{A.B.C.D/M} summary-only} {}
190: This command specifies an aggregate address. Aggreated routes will
191: not be announce.
192: @end deffn
193:
194: @deffn {BGP} {no aggregate-address @var{A.B.C.D/M}} {}
195: @end deffn
196:
197: @node Redistribute to BGP
198: @subsection Redistribute to BGP
199:
200: @deffn {BGP} {redistribute kernel} {}
201: Redistribute kernel route to BGP process.
202: @end deffn
203:
204: @deffn {BGP} {redistribute static} {}
205: Redistribute static route to BGP process.
206: @end deffn
207:
208: @deffn {BGP} {redistribute connected} {}
209: Redistribute connected route to BGP process.
210: @end deffn
211:
212: @deffn {BGP} {redistribute rip} {}
213: Redistribute RIP route to BGP process.
214: @end deffn
215:
216: @deffn {BGP} {redistribute ospf} {}
217: Redistribute OSPF route to BGP process.
218: @end deffn
219:
220: @node BGP Peer
221: @section BGP Peer
222:
223: @menu
224: * Defining Peer::
225: * BGP Peer commands::
226: * Peer filtering::
227: @end menu
228:
229: @node Defining Peer
230: @subsection Defining Peer
231:
232: @deffn {BGP} {neighbor @var{peer} remote-as @var{asn}} {}
233: Creates a new neighbor whose remote-as is @var{asn}. @var{peer}
234: can be an IPv4 address or an IPv6 address.
235: @example
236: @group
237: router bgp 1
238: neighbor 10.0.0.1 remote-as 2
239: @end group
240: @end example
241: In this case my router, in AS-1, is trying to peer with AS-2 at
242: 10.0.0.1.
243:
244: This command must be the first command used when configuring a neighbor.
245: If the remote-as is not specified, @command{bgpd} will complain like this:
246: @example
247: can't find neighbor 10.0.0.1
248: @end example
249: @end deffn
250:
251: @node BGP Peer commands
252: @subsection BGP Peer commands
253:
254: In a @code{router bgp} clause there are neighbor specific configurations
255: required.
256:
257: @deffn {BGP} {neighbor @var{peer} shutdown} {}
258: @deffnx {BGP} {no neighbor @var{peer} shutdown} {}
259: Shutdown the peer. We can delete the neighbor's configuration by
260: @code{no neighbor @var{peer} remote-as @var{as-number}} but all
261: configuration of the neighbor will be deleted. When you want to
262: preserve the configuration, but want to drop the BGP peer, use this
263: syntax.
264: @end deffn
265:
266: @deffn {BGP} {neighbor @var{peer} ebgp-multihop} {}
267: @deffnx {BGP} {no neighbor @var{peer} ebgp-multihop} {}
268: @end deffn
269:
270: @deffn {BGP} {neighbor @var{peer} description ...} {}
271: @deffnx {BGP} {no neighbor @var{peer} description ...} {}
272: Set description of the peer.
273: @end deffn
274:
275: @deffn {BGP} {neighbor @var{peer} version @var{version}} {}
276: Set up the neighbor's BGP version. @var{version} can be @var{4},
277: @var{4+} or @var{4-}. BGP version @var{4} is the default value used for
278: BGP peering. BGP version @var{4+} means that the neighbor supports
279: Multiprotocol Extensions for BGP-4. BGP version @var{4-} is similar but
280: the neighbor speaks the old Internet-Draft revision 00's Multiprotocol
281: Extensions for BGP-4. Some routing software is still using this
282: version.
283: @end deffn
284:
285: @deffn {BGP} {neighbor @var{peer} interface @var{ifname}} {}
286: @deffnx {BGP} {no neighbor @var{peer} interface @var{ifname}} {}
287: When you connect to a BGP peer over an IPv6 link-local address, you
288: have to specify the @var{ifname} of the interface used for the
289: connection. To specify IPv4 session addresses, see the
290: @code{neighbor @var{peer} update-source} command below.
291:
292: This command is deprecated and may be removed in a future release. Its
293: use should be avoided.
294: @end deffn
295:
296: @deffn {BGP} {neighbor @var{peer} next-hop-self} {}
297: @deffnx {BGP} {no neighbor @var{peer} next-hop-self} {}
298: This command specifies an announced route's nexthop as being equivalent
299: to the address of the bgp router.
300: @end deffn
301:
302: @deffn {BGP} {neighbor @var{peer} update-source @var{<ifname|address>}} {}
303: @deffnx {BGP} {no neighbor @var{peer} update-source} {}
304: Specify the IPv4 source address to use for the @acronym{BGP} session to this
305: neighbour, may be specified as either an IPv4 address directly or
306: as an interface name (in which case the @command{zebra} daemon MUST be running
307: in order for @command{bgpd} to be able to retrieve interface state).
308: @example
309: @group
310: router bgp 64555
311: neighbor foo update-source 192.168.0.1
312: neighbor bar update-source lo0
313: @end group
314: @end example
315: @end deffn
316:
317: @deffn {BGP} {neighbor @var{peer} default-originate} {}
318: @deffnx {BGP} {no neighbor @var{peer} default-originate} {}
319: @command{bgpd}'s default is to not announce the default route (0.0.0.0/0) even it
320: is in routing table. When you want to announce default routes to the
321: peer, use this command.
322: @end deffn
323:
324: @deffn {BGP} {neighbor @var{peer} port @var{port}} {}
325: @deffnx {BGP} {neighbor @var{peer} port @var{port}} {}
326: @end deffn
327:
328: @deffn {BGP} {neighbor @var{peer} send-community} {}
329: @deffnx {BGP} {neighbor @var{peer} send-community} {}
330: @end deffn
331:
332: @deffn {BGP} {neighbor @var{peer} weight @var{weight}} {}
333: @deffnx {BGP} {no neighbor @var{peer} weight @var{weight}} {}
334: This command specifies a default @var{weight} value for the neighbor's
335: routes.
336: @end deffn
337:
338: @deffn {BGP} {neighbor @var{peer} maximum-prefix @var{number}} {}
339: @deffnx {BGP} {no neighbor @var{peer} maximum-prefix @var{number}} {}
340: @end deffn
341:
342: @node Peer filtering
343: @subsection Peer filtering
344:
345: @deffn {BGP} {neighbor @var{peer} distribute-list @var{name} [in|out]} {}
346: This command specifies a distribute-list for the peer. @var{direct} is
347: @samp{in} or @samp{out}.
348: @end deffn
349:
350: @deffn {BGP command} {neighbor @var{peer} prefix-list @var{name} [in|out]} {}
351: @end deffn
352:
353: @deffn {BGP command} {neighbor @var{peer} filter-list @var{name} [in|out]} {}
354: @end deffn
355:
356: @deffn {BGP} {neighbor @var{peer} route-map @var{name} [in|out]} {}
357: Apply a route-map on the neighbor. @var{direct} must be @code{in} or
358: @code{out}.
359: @end deffn
360:
361: @c -----------------------------------------------------------------------
362: @node BGP Peer Group
363: @section BGP Peer Group
364:
365: @deffn {BGP} {neighbor @var{word} peer-group} {}
366: This command defines a new peer group.
367: @end deffn
368:
369: @deffn {BGP} {neighbor @var{peer} peer-group @var{word}} {}
370: This command bind specific peer to peer group @var{word}.
371: @end deffn
372:
373: @node BGP Address Family
374: @section BGP Address Family
375:
376: @c -----------------------------------------------------------------------
377: @node Autonomous System
378: @section Autonomous System
379:
380: The @acronym{AS,Autonomous System} number is one of the essential
381: element of BGP. BGP is a distance vector routing protocol, and the
382: AS-Path framework provides distance vector metric and loop detection to
383: BGP. @cite{RFC1930, Guidelines for creation, selection, and
384: registration of an Autonomous System (AS)} provides some background on
385: the concepts of an AS.
386:
387: The AS number is a two octet value, ranging in value from 1 to 65535.
388: The AS numbers 64512 through 65535 are defined as private AS numbers.
389: Private AS numbers must not to be advertised in the global Internet.
390:
391: @menu
392: * AS Path Regular Expression::
393: * Display BGP Routes by AS Path::
394: * AS Path Access List::
395: * Using AS Path in Route Map::
396: * Private AS Numbers::
397: @end menu
398:
399: @node AS Path Regular Expression
400: @subsection AS Path Regular Expression
401:
402: AS path regular expression can be used for displaying BGP routes and
403: AS path access list. AS path regular expression is based on
404: @code{POSIX 1003.2} regular expressions. Following description is
405: just a subset of @code{POSIX} regular expression. User can use full
406: @code{POSIX} regular expression. Adding to that special character '_'
407: is added for AS path regular expression.
408:
409: @table @code
410: @item .
411: Matches any single character.
412: @item *
413: Matches 0 or more occurrences of pattern.
414: @item +
415: Matches 1 or more occurrences of pattern.
416: @item ?
417: Match 0 or 1 occurrences of pattern.
418: @item ^
419: Matches the beginning of the line.
420: @item $
421: Matches the end of the line.
422: @item _
423: Character @code{_} has special meanings in AS path regular expression.
424: It matches to space and comma , and AS set delimiter @{ and @} and AS
425: confederation delimiter @code{(} and @code{)}. And it also matches to
426: the beginning of the line and the end of the line. So @code{_} can be
427: used for AS value boundaries match. @code{show ip bgp regexp _7675_}
428: matches to all of BGP routes which as AS number include @var{7675}.
429: @end table
430:
431: @node Display BGP Routes by AS Path
432: @subsection Display BGP Routes by AS Path
433:
434: To show BGP routes which has specific AS path information @code{show
435: ip bgp} command can be used.
436:
437: @deffn Command {show ip bgp regexp @var{line}} {}
438: This commands display BGP routes that matches AS path regular
439: expression @var{line}.
440: @end deffn
441:
442: @node AS Path Access List
443: @subsection AS Path Access List
444:
445: AS path access list is user defined AS path.
446:
447: @deffn {Command} {ip as-path access-list @var{word} @{permit|deny@} @var{line}} {}
448: This command defines a new AS path access list.
449: @end deffn
450:
451: @deffn {Command} {no ip as-path access-list @var{word}} {}
452: @deffnx {Command} {no ip as-path access-list @var{word} @{permit|deny@} @var{line}} {}
453: @end deffn
454:
455: @node Using AS Path in Route Map
456: @subsection Using AS Path in Route Map
457:
458: @deffn {Route Map} {match as-path @var{word}} {}
459: @end deffn
460:
461: @deffn {Route Map} {set as-path prepend @var{as-path}} {}
462: @end deffn
463:
464: @node Private AS Numbers
465: @subsection Private AS Numbers
466:
467: @c -----------------------------------------------------------------------
468: @node BGP Communities Attribute
469: @section BGP Communities Attribute
470:
471: BGP communities attribute is widely used for implementing policy
472: routing. Network operators can manipulate BGP communities attribute
473: based on their network policy. BGP communities attribute is defined
474: in @cite{RFC1997, BGP Communities Attribute} and
475: @cite{RFC1998, An Application of the BGP Community Attribute
476: in Multi-home Routing}. It is an optional transitive attribute,
477: therefore local policy can travel through different autonomous system.
478:
479: Communities attribute is a set of communities values. Each
480: communities value is 4 octet long. The following format is used to
481: define communities value.
482:
483: @table @code
484: @item AS:VAL
485: This format represents 4 octet communities value. @code{AS} is high
486: order 2 octet in digit format. @code{VAL} is low order 2 octet in
487: digit format. This format is useful to define AS oriented policy
488: value. For example, @code{7675:80} can be used when AS 7675 wants to
489: pass local policy value 80 to neighboring peer.
490: @item internet
491: @code{internet} represents well-known communities value 0.
492: @item no-export
493: @code{no-export} represents well-known communities value @code{NO_EXPORT}@*
494: @r{(0xFFFFFF01)}. All routes carry this value must not be advertised
495: to outside a BGP confederation boundary. If neighboring BGP peer is
496: part of BGP confederation, the peer is considered as inside a BGP
497: confederation boundary, so the route will be announced to the peer.
498: @item no-advertise
499: @code{no-advertise} represents well-known communities value
500: @code{NO_ADVERTISE}@*@r{(0xFFFFFF02)}. All routes carry this value
501: must not be advertise to other BGP peers.
502: @item local-AS
503: @code{local-AS} represents well-known communities value
504: @code{NO_EXPORT_SUBCONFED} @r{(0xFFFFFF03)}. All routes carry this
505: value must not be advertised to external BGP peers. Even if the
506: neighboring router is part of confederation, it is considered as
507: external BGP peer, so the route will not be announced to the peer.
508: @end table
509:
510: When BGP communities attribute is received, duplicated communities
511: value in the communities attribute is ignored and each communities
512: values are sorted in numerical order.
513:
514: @menu
515: * BGP Community Lists::
516: * Numbered BGP Community Lists::
517: * BGP Community in Route Map::
518: * Display BGP Routes by Community::
519: * Using BGP Communities Attribute::
520: @end menu
521:
522: @node BGP Community Lists
523: @subsection BGP Community Lists
524:
525: BGP community list is a user defined BGP communites attribute list.
526: BGP community list can be used for matching or manipulating BGP
527: communities attribute in updates.
528:
529: There are two types of community list. One is standard community
530: list and another is expanded community list. Standard community list
531: defines communities attribute. Expanded community list defines
532: communities attribute string with regular expression. Standard
533: community list is compiled into binary format when user define it.
534: Standard community list will be directly compared to BGP communities
535: attribute in BGP updates. Therefore the comparison is faster than
536: expanded community list.
537:
538: @deffn Command {ip community-list standard @var{name} @{permit|deny@} @var{community}} {}
539: This command defines a new standard community list. @var{community}
540: is communities value. The @var{community} is compiled into community
541: structure. We can define multiple community list under same name. In
542: that case match will happen user defined order. Once the
543: community list matches to communities attribute in BGP updates it
544: return permit or deny by the community list definition. When there is
545: no matched entry, deny will be returned. When @var{community} is
546: empty it matches to any routes.
547: @end deffn
548:
549: @deffn Command {ip community-list expanded @var{name} @{permit|deny@} @var{line}} {}
550: This command defines a new expanded community list. @var{line} is a
551: string expression of communities attribute. @var{line} can include
552: regular expression to match communities attribute in BGP updates.
553: @end deffn
554:
555: @deffn Command {no ip community-list @var{name}} {}
556: @deffnx Command {no ip community-list standard @var{name}} {}
557: @deffnx Command {no ip community-list expanded @var{name}} {}
558: These commands delete community lists specified by @var{name}. All of
559: community lists shares a single name space. So community lists can be
560: removed simpley specifying community lists name.
561: @end deffn
562:
563: @deffn {Command} {show ip community-list} {}
564: @deffnx {Command} {show ip community-list @var{name}} {}
565: This command display current community list information. When
566: @var{name} is specified the specified community list's information is
567: shown.
568:
569: @example
570: # show ip community-list
571: Named Community standard list CLIST
572: permit 7675:80 7675:100 no-export
573: deny internet
574: Named Community expanded list EXPAND
575: permit :
576:
577: # show ip community-list CLIST
578: Named Community standard list CLIST
579: permit 7675:80 7675:100 no-export
580: deny internet
581: @end example
582: @end deffn
583:
584: @node Numbered BGP Community Lists
585: @subsection Numbered BGP Community Lists
586:
587: When number is used for BGP community list name, the number has
588: special meanings. Community list number in the range from 1 and 99 is
589: standard community list. Community list number in the range from 100
590: to 199 is expanded community list. These community lists are called
591: as numbered community lists. On the other hand normal community lists
592: is called as named community lists.
593:
594: @deffn Command {ip community-list <1-99> @{permit|deny@} @var{community}} {}
595: This command defines a new community list. <1-99> is standard
596: community list number. Community list name within this range defines
597: standard community list. When @var{community} is empty it matches to
598: any routes.
599: @end deffn
600:
601: @deffn Command {ip community-list <100-199> @{permit|deny@} @var{community}} {}
602: This command defines a new community list. <100-199> is expanded
603: community list number. Community list name within this range defines
604: expanded community list.
605: @end deffn
606:
607: @deffn Command {ip community-list @var{name} @{permit|deny@} @var{community}} {}
608: When community list type is not specifed, the community list type is
609: automatically detected. If @var{community} can be compiled into
610: communities attribute, the community list is defined as a standard
611: community list. Otherwise it is defined as an expanded community
612: list. This feature is left for backward compability. Use of this
613: feature is not recommended.
614: @end deffn
615:
616: @node BGP Community in Route Map
617: @subsection BGP Community in Route Map
618:
619: In Route Map (@pxref{Route Map}), we can match or set BGP
620: communities attribute. Using this feature network operator can
621: implement their network policy based on BGP communities attribute.
622:
623: Following commands can be used in Route Map.
624:
625: @deffn {Route Map} {match community @var{word}} {}
626: @deffnx {Route Map} {match community @var{word} exact-match} {}
627: This command perform match to BGP updates using community list
628: @var{word}. When the one of BGP communities value match to the one of
629: communities value in community list, it is match. When
630: @code{exact-match} keyword is spcified, match happen only when BGP
631: updates have completely same communities value specified in the
632: community list.
633: @end deffn
634:
635: @deffn {Route Map} {set community none} {}
636: @deffnx {Route Map} {set community @var{community}} {}
637: @deffnx {Route Map} {set community @var{community} additive} {}
638: This command manipulate communities value in BGP updates. When
639: @code{none} is specified as communities value, it removes entire
640: communities attribute from BGP updates. When @var{community} is not
641: @code{none}, specified communities value is set to BGP updates. If
642: BGP updates already has BGP communities value, the existing BGP
643: communities value is replaced with specified @var{community} value.
644: When @code{additive} keyword is specified, @var{community} is appended
645: to the existing communities value.
646: @end deffn
647:
648: @deffn {Route Map} {set comm-list @var{word} delete} {}
649: This command remove communities value from BGP communities attribute.
650: The @var{word} is community list name. When BGP route's communities
651: value matches to the community list @var{word}, the communities value
652: is removed. When all of communities value is removed eventually, the
653: BGP update's communities attribute is completely removed.
654: @end deffn
655:
656: @node Display BGP Routes by Community
657: @subsection Display BGP Routes by Community
658:
659: To show BGP routes which has specific BGP communities attribute,
660: @code{show ip bgp} command can be used. The @var{community} value and
661: community list can be used for @code{show ip bgp} command.
662:
663: @deffn Command {show ip bgp community} {}
664: @deffnx Command {show ip bgp community @var{community}} {}
665: @deffnx Command {show ip bgp community @var{community} exact-match} {}
666: @code{show ip bgp community} displays BGP routes which has communities
667: attribute. When @var{community} is specified, BGP routes that matches
668: @var{community} value is displayed. For this command, @code{internet}
669: keyword can't be used for @var{community} value. When
670: @code{exact-match} is specified, it display only routes that have an
671: exact match.
672: @end deffn
673:
674: @deffn Command {show ip bgp community-list @var{word}} {}
675: @deffnx Command {show ip bgp community-list @var{word} exact-match} {}
676: This commands display BGP routes that matches community list
677: @var{word}. When @code{exact-match} is specified, display only routes
678: that have an exact match.
679: @end deffn
680:
681: @node Using BGP Communities Attribute
682: @subsection Using BGP Communities Attribute
683:
684: Following configuration is the most typical usage of BGP communities
685: attribute. AS 7675 provides upstream Internet connection to AS 100.
686: When following configuration exists in AS 7675, AS 100 networks
687: operator can set local preference in AS 7675 network by setting BGP
688: communities attribute to the updates.
689:
690: @example
691: router bgp 7675
692: neighbor 192.168.0.1 remote-as 100
693: neighbor 192.168.0.1 route-map RMAP in
694: !
695: ip community-list 70 permit 7675:70
696: ip community-list 70 deny
697: ip community-list 80 permit 7675:80
698: ip community-list 80 deny
699: ip community-list 90 permit 7675:90
700: ip community-list 90 deny
701: !
702: route-map RMAP permit 10
703: match community 70
704: set local-preference 70
705: !
706: route-map RMAP permit 20
707: match community 80
708: set local-preference 80
709: !
710: route-map RMAP permit 30
711: match community 90
712: set local-preference 90
713: @end example
714:
715: Following configuration announce 10.0.0.0/8 from AS 100 to AS 7675.
716: The route has communities value 7675:80 so when above configuration
717: exists in AS 7675, announced route's local preference will be set to
718: value 80.
719:
720: @example
721: router bgp 100
722: network 10.0.0.0/8
723: neighbor 192.168.0.2 remote-as 7675
724: neighbor 192.168.0.2 route-map RMAP out
725: !
726: ip prefix-list PLIST permit 10.0.0.0/8
727: !
728: route-map RMAP permit 10
729: match ip address prefix-list PLIST
730: set community 7675:80
731: @end example
732:
733: Following configuration is an example of BGP route filtering using
734: communities attribute. This configuration only permit BGP routes
735: which has BGP communities value 0:80 or 0:90. Network operator can
736: put special internal communities value at BGP border router, then
737: limit the BGP routes announcement into the internal network.
738:
739: @example
740: router bgp 7675
741: neighbor 192.168.0.1 remote-as 100
742: neighbor 192.168.0.1 route-map RMAP in
743: !
744: ip community-list 1 permit 0:80 0:90
745: !
746: route-map RMAP permit in
747: match community 1
748: @end example
749:
750: Following exmaple filter BGP routes which has communities value 1:1.
751: When there is no match community-list returns deny. To avoid
752: filtering all of routes, we need to define permit any at last.
753:
754: @example
755: router bgp 7675
756: neighbor 192.168.0.1 remote-as 100
757: neighbor 192.168.0.1 route-map RMAP in
758: !
759: ip community-list standard FILTER deny 1:1
760: ip community-list standard FILTER permit
761: !
762: route-map RMAP permit 10
763: match community FILTER
764: @end example
765:
766: Communities value keyword @code{internet} has special meanings in
767: standard community lists. In below example @code{internet} act as
768: match any. It matches all of BGP routes even if the route does not
769: have communities attribute at all. So community list @code{INTERNET}
770: is same as above example's @code{FILTER}.
771:
772: @example
773: ip community-list standard INTERNET deny 1:1
774: ip community-list standard INTERNET permit internet
775: @end example
776:
777: Following configuration is an example of communities value deletion.
778: With this configuration communities value 100:1 and 100:2 is removed
779: from BGP updates. For communities value deletion, only @code{permit}
780: community-list is used. @code{deny} community-list is ignored.
781:
782: @example
783: router bgp 7675
784: neighbor 192.168.0.1 remote-as 100
785: neighbor 192.168.0.1 route-map RMAP in
786: !
787: ip community-list standard DEL permit 100:1 100:2
788: !
789: route-map RMAP permit 10
790: set comm-list DEL delete
791: @end example
792:
793: @c -----------------------------------------------------------------------
794: @node BGP Extended Communities Attribute
795: @section BGP Extended Communities Attribute
796:
797: BGP extended communities attribute is introduced with MPLS VPN/BGP
798: technology. MPLS VPN/BGP expands capability of network infrastructure
799: to provide VPN functionality. At the same time it requires a new
800: framework for policy routing. With BGP Extended Communities Attribute
801: we can use Route Target or Site of Origin for implementing network
802: policy for MPLS VPN/BGP.
803:
804: BGP Extended Communities Attribute is similar to BGP Communities
805: Attribute. It is an optional transitive attribute. BGP Extended
806: Communities Attribute can carry multiple Extended Community value.
807: Each Extended Community value is eight octet length.
808:
809: BGP Extended Communities Attribute provides an extended range
810: compared with BGP Communities Attribute. Adding to that there is a
811: type field in each value to provides community space structure.
812:
813: There are two format to define Extended Community value. One is AS
814: based format the other is IP address based format.
815:
816: @table @code
817: @item AS:VAL
818: This is a format to define AS based Extended Community value.
819: @code{AS} part is 2 octets Global Administrator subfield in Extended
820: Community value. @code{VAL} part is 4 octets Local Administrator
821: subfield. @code{7675:100} represents AS 7675 policy value 100.
822: @item IP-Address:VAL
823: This is a format to define IP address based Extended Community value.
824: @code{IP-Address} part is 4 octets Global Administrator subfield.
825: @code{VAL} part is 2 octets Local Administrator subfield.
826: @code{10.0.0.1:100} represents
827: @end table
828:
829: @menu
830: * BGP Extended Community Lists::
831: * BGP Extended Communities in Route Map::
832: @end menu
833:
834: @node BGP Extended Community Lists
835: @subsection BGP Extended Community Lists
836:
837: Expanded Community Lists is a user defined BGP Expanded Community
838: Lists.
839:
840: @deffn Command {ip extcommunity-list standard @var{name} @{permit|deny@} @var{extcommunity}} {}
841: This command defines a new standard extcommunity-list.
842: @var{extcommunity} is extended communities value. The
843: @var{extcommunity} is compiled into extended community structure. We
844: can define multiple extcommunity-list under same name. In that case
845: match will happen user defined order. Once the extcommunity-list
846: matches to extended communities attribute in BGP updates it return
847: permit or deny based upon the extcommunity-list definition. When
848: there is no matched entry, deny will be returned. When
849: @var{extcommunity} is empty it matches to any routes.
850: @end deffn
851:
852: @deffn Command {ip extcommunity-list expanded @var{name} @{permit|deny@} @var{line}} {}
853: This command defines a new expanded extcommunity-list. @var{line} is
854: a string expression of extended communities attribute. @var{line} can
855: include regular expression to match extended communities attribute in
856: BGP updates.
857: @end deffn
858:
859: @deffn Command {no ip extcommunity-list @var{name}} {}
860: @deffnx Command {no ip extcommunity-list standard @var{name}} {}
861: @deffnx Command {no ip extcommunity-list expanded @var{name}} {}
862: These commands delete extended community lists specified by
863: @var{name}. All of extended community lists shares a single name
864: space. So extended community lists can be removed simpley specifying
865: the name.
866: @end deffn
867:
868: @deffn {Command} {show ip extcommunity-list} {}
869: @deffnx {Command} {show ip extcommunity-list @var{name}} {}
870: This command display current extcommunity-list information. When
871: @var{name} is specified the community list's information is shown.
872:
873: @example
874: # show ip extcommunity-list
875: @end example
876: @end deffn
877:
878: @node BGP Extended Communities in Route Map
879: @subsection BGP Extended Communities in Route Map
880:
881: @deffn {Route Map} {match extcommunity @var{word}} {}
882: @end deffn
883:
884: @deffn {Route Map} {set extcommunity rt @var{extcommunity}} {}
885: This command set Route Target value.
886: @end deffn
887:
888: @deffn {Route Map} {set extcommunity soo @var{extcommunity}} {}
889: This command set Site of Origin value.
890: @end deffn
891:
892: @c -----------------------------------------------------------------------
893: @node Displaying BGP routes
894: @section Displaying BGP Routes
895:
896: @menu
897: * Show IP BGP::
898: * More Show IP BGP::
899: @end menu
900:
901: @node Show IP BGP
902: @subsection Show IP BGP
903:
904: @deffn {Command} {show ip bgp} {}
905: @deffnx {Command} {show ip bgp @var{A.B.C.D}} {}
906: @deffnx {Command} {show ip bgp @var{X:X::X:X}} {}
907: This command displays BGP routes. When no route is specified it
908: display all of IPv4 BGP routes.
909: @end deffn
910:
911: @example
912: BGP table version is 0, local router ID is 10.1.1.1
913: Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
914: Origin codes: i - IGP, e - EGP, ? - incomplete
915:
916: Network Next Hop Metric LocPrf Weight Path
917: *> 1.1.1.1/32 0.0.0.0 0 32768 i
918:
919: Total number of prefixes 1
920: @end example
921:
922: @node More Show IP BGP
923: @subsection More Show IP BGP
924:
925: @deffn {Command} {show ip bgp regexp @var{line}} {}
926: This command display BGP routes using AS path regular expression (@pxref{Display BGP Routes by AS Path}).
927: @end deffn
928:
929: @deffn Command {show ip bgp community @var{community}} {}
930: @deffnx Command {show ip bgp community @var{community} exact-match} {}
931: This command display BGP routes using @var{community} (@pxref{Display
932: BGP Routes by Community}).
933: @end deffn
934:
935: @deffn Command {show ip bgp community-list @var{word}} {}
936: @deffnx Command {show ip bgp community-list @var{word} exact-match} {}
937: This command display BGP routes using community list (@pxref{Display
938: BGP Routes by Community}).
939: @end deffn
940:
941: @deffn {Command} {show ip bgp summary} {}
942: @end deffn
943:
944: @deffn {Command} {show ip bgp neighbor [@var{peer}]} {}
945: @end deffn
946:
947: @deffn {Command} {clear ip bgp @var{peer}} {}
948: Clear peers which have addresses of X.X.X.X
949: @end deffn
950:
951: @deffn {Command} {clear ip bgp @var{peer} soft in} {}
952: Clear peer using soft reconfiguration.
953: @end deffn
954:
955: @deffn {Command} {show ip bgp dampened-paths} {}
956: Display paths suppressed due to dampening
957: @end deffn
958:
959: @deffn {Command} {show ip bgp flap-statistics} {}
960: Display flap statistics of routes
961: @end deffn
962:
963: @deffn {Command} {show debug} {}
964: @end deffn
965:
966: @deffn {Command} {debug event} {}
967: @end deffn
968:
969: @deffn {Command} {debug update} {}
970: @end deffn
971:
972: @deffn {Command} {debug keepalive} {}
973: @end deffn
974:
975: @deffn {Command} {no debug event} {}
976: @end deffn
977:
978: @deffn {Command} {no debug update} {}
979: @end deffn
980:
981: @deffn {Command} {no debug keepalive} {}
982: @end deffn
983:
984: @node Capability Negotiation
985: @section Capability Negotiation
986:
987: When adding IPv6 routing information exchange feature to BGP. There
988: were some proposals. @acronym{IETF,Internet Engineering Task Force}
989: @acronym{IDR, Inter Domain Routing} @acronym{WG, Working group} adopted
990: a proposal called Multiprotocol Extension for BGP. The specification
991: is described in @cite{RFC2283}. The protocol does not define new protocols.
992: It defines new attributes to existing BGP. When it is used exchanging
993: IPv6 routing information it is called BGP-4+. When it is used for
994: exchanging multicast routing information it is called MBGP.
995:
996: @command{bgpd} supports Multiprotocol Extension for BGP. So if remote
997: peer supports the protocol, @command{bgpd} can exchange IPv6 and/or
998: multicast routing information.
999:
1000: Traditional BGP did not have the feature to detect remote peer's
1001: capabilities, e.g. whether it can handle prefix types other than IPv4
1002: unicast routes. This was a big problem using Multiprotocol Extension
1003: for BGP to operational network. @cite{RFC2842, Capabilities
1004: Advertisement with BGP-4} adopted a feature called Capability
1005: Negotiation. @command{bgpd} use this Capability Negotiation to detect
1006: the remote peer's capabilities. If the peer is only configured as IPv4
1007: unicast neighbor, @command{bgpd} does not send these Capability
1008: Negotiation packets (at least not unless other optional BGP features
1009: require capability negotation).
1010:
1011: By default, Quagga will bring up peering with minimal common capability
1012: for the both sides. For example, local router has unicast and
1013: multicast capabilitie and remote router has unicast capability. In
1014: this case, the local router will establish the connection with unicast
1015: only capability. When there are no common capabilities, Quagga sends
1016: Unsupported Capability error and then resets the connection.
1017:
1018: If you want to completely match capabilities with remote peer. Please
1019: use @command{strict-capability-match} command.
1020:
1021: @deffn {BGP} {neighbor @var{peer} strict-capability-match} {}
1022: @deffnx {BGP} {no neighbor @var{peer} strict-capability-match} {}
1023: Strictly compares remote capabilities and local capabilities. If capabilities
1024: are different, send Unsupported Capability error then reset connection.
1025: @end deffn
1026:
1027: You may want to disable sending Capability Negotiation OPEN message
1028: optional parameter to the peer when remote peer does not implement
1029: Capability Negotiation. Please use @command{dont-capability-negotiate}
1030: command to disable the feature.
1031:
1032: @deffn {BGP} {neighbor @var{peer} dont-capability-negotiate} {}
1033: @deffnx {BGP} {no neighbor @var{peer} dont-capability-negotiate} {}
1034: Suppress sending Capability Negotiation as OPEN message optional
1035: parameter to the peer. This command only affects the peer is configured
1036: other than IPv4 unicast configuration.
1037: @end deffn
1038:
1039: When remote peer does not have capability negotiation feature, remote
1040: peer will not send any capabilities at all. In that case, bgp
1041: configures the peer with configured capabilities.
1042:
1043: You may prefer locally configured capabilities more than the negotiated
1044: capabilities even though remote peer sends capabilities. If the peer
1045: is configured by @command{override-capability}, @command{bgpd} ignores
1046: received capabilities then override negotiated capabilities with
1047: configured values.
1048:
1049: @deffn {BGP} {neighbor @var{peer} override-capability} {}
1050: @deffnx {BGP} {no neighbor @var{peer} override-capability} {}
1051: Override the result of Capability Negotiation with local configuration.
1052: Ignore remote peer's capability value.
1053: @end deffn
1054:
1055: @node Route Reflector
1056: @section Route Reflector
1057:
1058: @deffn {BGP} {bgp cluster-id @var{a.b.c.d}} {}
1059: @end deffn
1060:
1061: @deffn {BGP} {neighbor @var{peer} route-reflector-client} {}
1062: @deffnx {BGP} {no neighbor @var{peer} route-reflector-client} {}
1063: @end deffn
1064:
1065: @node Route Server
1066: @section Route Server
1067:
1068: At an Internet Exchange point, many ISPs are connected to each other by
1069: external BGP peering. Normally these external BGP connection are done by
1070: @samp{full mesh} method. As with internal BGP full mesh formation,
1071: this method has a scaling problem.
1072:
1073: This scaling problem is well known. Route Server is a method to resolve
1074: the problem. Each ISP's BGP router only peers to Route Server. Route
1075: Server serves as BGP information exchange to other BGP routers. By
1076: applying this method, numbers of BGP connections is reduced from
1077: O(n*(n-1)/2) to O(n).
1078:
1079: Unlike normal BGP router, Route Server must have several routing tables
1080: for managing different routing policies for each BGP speaker. We call the
1081: routing tables as different @code{view}s. @command{bgpd} can work as
1082: normal BGP router or Route Server or both at the same time.
1083:
1084: @menu
1085: * Multiple instance::
1086: * BGP instance and view::
1087: * Routing policy::
1088: * Viewing the view::
1089: @end menu
1090:
1091: @node Multiple instance
1092: @subsection Multiple instance
1093:
1094: To enable multiple view function of @code{bgpd}, you must turn on
1095: multiple instance feature beforehand.
1096:
1097: @deffn {Command} {bgp multiple-instance} {}
1098: Enable BGP multiple instance feature. After this feature is enabled,
1099: you can make multiple BGP instances or multiple BGP views.
1100: @end deffn
1101:
1102: @deffn {Command} {no bgp multiple-instance} {}
1103: Disable BGP multiple instance feature. You can not disable this feature
1104: when BGP multiple instances or views exist.
1105: @end deffn
1106:
1107: When you want to make configuration more Cisco like one,
1108:
1109: @deffn {Command} {bgp config-type cisco} {}
1110: Cisco compatible BGP configuration output.
1111: @end deffn
1112:
1113: When bgp config-type cisco is specified,
1114:
1115: ``no synchronization'' is displayed.
1116: ``no auto-summary'' is displayed.
1117:
1118: ``network'' and ``aggregate-address'' argument is displayed as
1119: ``A.B.C.D M.M.M.M''
1120:
1121: Quagga: network 10.0.0.0/8
1122: Cisco: network 10.0.0.0
1123:
1124: Quagga: aggregate-address 192.168.0.0/24
1125: Cisco: aggregate-address 192.168.0.0 255.255.255.0
1126:
1127: Community attribute handling is also different. If there is no
1128: configuration is specified community attribute and extended community
1129: attribute are sent to neighbor. When user manually disable the
1130: feature community attribute is not sent to the neighbor. In case of
1131: @command{bgp config-type cisco} is specified, community attribute is not
1132: sent to the neighbor by default. To send community attribute user has
1133: to specify @command{neighbor A.B.C.D send-community} command.
1134:
1135: @example
1136: !
1137: router bgp 1
1138: neighbor 10.0.0.1 remote-as 1
1139: no neighbor 10.0.0.1 send-community
1140: !
1141: router bgp 1
1142: neighbor 10.0.0.1 remote-as 1
1143: neighbor 10.0.0.1 send-community
1144: !
1145: @end example
1146:
1147: @deffn {Command} {bgp config-type zebra} {}
1148: Quagga style BGP configuration. This is default.
1149: @end deffn
1150:
1151: @node BGP instance and view
1152: @subsection BGP instance and view
1153:
1154: BGP instance is a normal BGP process. The result of route selection
1155: goes to the kernel routing table. You can setup different AS at the
1156: same time when BGP multiple instance feature is enabled.
1157:
1158: @deffn {Command} {router bgp @var{as-number}} {}
1159: Make a new BGP instance. You can use arbitrary word for the @var{name}.
1160: @end deffn
1161:
1162: @example
1163: @group
1164: bgp multiple-instance
1165: !
1166: router bgp 1
1167: neighbor 10.0.0.1 remote-as 2
1168: neighbor 10.0.0.2 remote-as 3
1169: !
1170: router bgp 2
1171: neighbor 10.0.0.3 remote-as 4
1172: neighbor 10.0.0.4 remote-as 5
1173: @end group
1174: @end example
1175:
1176: BGP view is almost same as normal BGP process. The result of
1177: route selection does not go to the kernel routing table. BGP view is
1178: only for exchanging BGP routing information.
1179:
1180: @deffn {Command} {router bgp @var{as-number} view @var{name}} {}
1181: Make a new BGP view. You can use arbitrary word for the @var{name}. This
1182: view's route selection result does not go to the kernel routing table.
1183: @end deffn
1184:
1185: With this command, you can setup Route Server like below.
1186:
1187: @example
1188: @group
1189: bgp multiple-instance
1190: !
1191: router bgp 1 view 1
1192: neighbor 10.0.0.1 remote-as 2
1193: neighbor 10.0.0.2 remote-as 3
1194: !
1195: router bgp 2 view 2
1196: neighbor 10.0.0.3 remote-as 4
1197: neighbor 10.0.0.4 remote-as 5
1198: @end group
1199: @end example
1200:
1201: @node Routing policy
1202: @subsection Routing policy
1203:
1204: You can set different routing policy for a peer. For example, you can
1205: set different filter for a peer.
1206:
1207: @example
1208: @group
1209: bgp multiple-instance
1210: !
1211: router bgp 1 view 1
1212: neighbor 10.0.0.1 remote-as 2
1213: neighbor 10.0.0.1 distribute-list 1 in
1214: !
1215: router bgp 1 view 2
1216: neighbor 10.0.0.1 remote-as 2
1217: neighbor 10.0.0.1 distribute-list 2 in
1218: @end group
1219: @end example
1220:
1221: This means BGP update from a peer 10.0.0.1 goes to both BGP view 1 and view
1222: 2. When the update is inserted into view 1, distribute-list 1 is
1223: applied. On the other hand, when the update is inserted into view 2,
1224: distribute-list 2 is applied.
1225:
1226: @node Viewing the view
1227: @subsection Viewing the view
1228:
1229: To display routing table of BGP view, you must specify view name.
1230:
1231: @deffn {Command} {show ip bgp view @var{name}} {}
1232: Display routing table of BGP view @var{name}.
1233: @end deffn
1234:
1235: @node How to set up a 6-Bone connection
1236: @section How to set up a 6-Bone connection
1237:
1238:
1239: @example
1240: @group
1241: zebra configuration
1242: ===================
1243: !
1244: ! Actually there is no need to configure zebra
1245: !
1246:
1247: bgpd configuration
1248: ==================
1249: !
1250: ! This means that routes go through zebra and into the kernel.
1251: !
1252: router zebra
1253: !
1254: ! MP-BGP configuration
1255: !
1256: router bgp 7675
1257: bgp router-id 10.0.0.1
1258: neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 remote-as @var{as-number}
1259: !
1260: address-family ipv6
1261: network 3ffe:506::/32
1262: neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 activate
1263: neighbor 3ffe:1cfa:0:2:2a0:c9ff:fe9e:f56 route-map set-nexthop out
1264: neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 remote-as @var{as-number}
1265: neighbor 3ffe:1cfa:0:2:2c0:4fff:fe68:a231 route-map set-nexthop out
1266: exit-address-family
1267: !
1268: ipv6 access-list all permit any
1269: !
1270: ! Set output nexthop address.
1271: !
1272: route-map set-nexthop permit 10
1273: match ipv6 address all
1274: set ipv6 nexthop global 3ffe:1cfa:0:2:2c0:4fff:fe68:a225
1275: set ipv6 nexthop local fe80::2c0:4fff:fe68:a225
1276: !
1277: ! logfile FILENAME is obsolete. Please use log file FILENAME
1278:
1279: log file bgpd.log
1280: !
1281: @end group
1282: @end example
1283:
1284: @node Dump BGP packets and table
1285: @section Dump BGP packets and table
1286:
1287: @deffn Command {dump bgp all @var{path}} {}
1288: @deffnx Command {dump bgp all @var{path} @var{interval}} {}
1289: Dump all BGP packet and events to @var{path} file.
1290: @end deffn
1291:
1292: @deffn Command {dump bgp updates @var{path}} {}
1293: @deffnx Command {dump bgp updates @var{path} @var{interval}} {}
1294: Dump BGP updates to @var{path} file.
1295: @end deffn
1296:
1297: @deffn Command {dump bgp routes @var{path}} {}
1298: @deffnx Command {dump bgp routes @var{path}} {}
1299: Dump whole BGP routing table to @var{path}. This is heavy process.
1300: @end deffn
1301:
1302: @node BGP Configuration Examples
1303: @section BGP Configuration Examples
1304:
1305: Example of a session to an upstream, advertising only one prefix to it.
1306:
1307: @example
1308: router bgp 64512
1309: bgp router-id 10.236.87.1
1310: network 10.236.87.0/24
1311: neighbor upstream peer-group
1312: neighbor upstream remote-as 64515
1313: neighbor upstream capability dynamic
1314: neighbor upstream prefix-list pl-allowed-adv out
1315: neighbor 10.1.1.1 peer-group upstream
1316: neighbor 10.1.1.1 description ACME ISP
1317: !
1318: ip prefix-list pl-allowed-adv seq 5 permit 82.195.133.0/25
1319: ip prefix-list pl-allowed-adv seq 10 deny any
1320:
1321: @end example
1322:
1323: A more complex example. With upstream, peer and customer sessions.
1324: Advertising global prefixes and NO_EXPORT prefixes and providing
1325: actions for customer routes based on community values. Extensive use of
1326: route-maps and the 'call' feature to support selective advertising of
1327: prefixes. This example is intended as guidance only, it has NOT been
1328: tested and almost certainly containts silly mistakes, if not serious
1329: flaws.
1330:
1331: @example
1332: router bgp 64512
1333: bgp router-id 10.236.87.1
1334: network 10.123.456.0/24
1335: network 10.123.456.128/25 route-map rm-no-export
1336: neighbor upstream capability dynamic
1337: neighbor upstream route-map rm-upstream-out out
1338: neighbor cust capability dynamic
1339: neighbor cust route-map rm-cust-in in
1340: neighbor cust route-map rm-cust-out out
1341: neighbor cust send-community both
1342: neighbor peer capability dynamic
1343: neighbor peer route-map rm-peer-in in
1344: neighbor peer route-map rm-peer-out out
1345: neighbor peer send-community both
1346: neighbor 10.1.1.1 remote-as 64515
1347: neighbor 10.1.1.1 peer-group upstream
1348: neighbor 10.2.1.1 remote-as 64516
1349: neighbor 10.2.1.1 peer-group upstream
1350: neighbor 10.3.1.1 remote-as 64517
1351: neighbor 10.3.1.1 peer-group cust-default
1352: neighbor 10.3.1.1 description customer1
1353: neighbor 10.3.1.1 prefix-list pl-cust1-network in
1354: neighbor 10.4.1.1 remote-as 64518
1355: neighbor 10.4.1.1 peer-group cust
1356: neighbor 10.4.1.1 prefix-list pl-cust2-network in
1357: neighbor 10.4.1.1 description customer2
1358: neighbor 10.5.1.1 remote-as 64519
1359: neighbor 10.5.1.1 peer-group peer
1360: neighbor 10.5.1.1 prefix-list pl-peer1-network in
1361: neighbor 10.5.1.1 description peer AS 1
1362: neighbor 10.6.1.1 remote-as 64520
1363: neighbor 10.6.1.1 peer-group peer
1364: neighbor 10.6.1.1 prefix-list pl-peer2-network in
1365: neighbor 10.6.1.1 description peer AS 2
1366: !
1367: ip prefix-list pl-default permit 0.0.0.0/0
1368: !
1369: ip prefix-list pl-upstream-peers permit 10.1.1.1/32
1370: ip prefix-list pl-upstream-peers permit 10.2.1.1/32
1371: !
1372: ip prefix-list pl-cust1-network permit 10.3.1.0/24
1373: ip prefix-list pl-cust1-network permit 10.3.2.0/24
1374: !
1375: ip prefix-list pl-cust2-network permit 10.4.1.0/24
1376: !
1377: ip prefix-list pl-peer1-network permit 10.5.1.0/24
1378: ip prefix-list pl-peer1-network permit 10.5.2.0/24
1379: ip prefix-list pl-peer1-network permit 192.168.0.0/24
1380: !
1381: ip prefix-list pl-peer2-network permit 10.6.1.0/24
1382: ip prefix-list pl-peer2-network permit 10.6.2.0/24
1383: ip prefix-list pl-peer2-network permit 192.168.1.0/24
1384: ip prefix-list pl-peer2-network permit 192.168.2.0/24
1385: ip prefix-list pl-peer2-network permit 172.16.1/24
1386: !
1387: ip as-path access-list asp-own-as permit ^$
1388: ip as-path access-list asp-own-as permit _64512_
1389: !
1390: ! #################################################################
1391: ! Match communities we provide actions for, on routes receives from
1392: ! customers. Communities values of <our-ASN>:X, with X, have actions:
1393: !
1394: ! 100 - blackhole the prefix
1395: ! 200 - set no_export
1396: ! 300 - advertise only to other customers
1397: ! 400 - advertise only to upstreams
1398: ! 500 - set no_export when advertising to upstreams
1399: ! 2X00 - set local_preference to X00
1400: !
1401: ! blackhole the prefix of the route
1402: ip community-list standard cm-blackhole permit 64512:100
1403: !
1404: ! set no-export community before advertising
1405: ip community-list standard cm-set-no-export permit 64512:200
1406: !
1407: ! advertise only to other customers
1408: ip community-list standard cm-cust-only permit 64512:300
1409: !
1410: ! advertise only to upstreams
1411: ip community-list standard cm-upstream-only permit 64512:400
1412: !
1413: ! advertise to upstreams with no-export
1414: ip community-list standard cm-upstream-noexport permit 64512:500
1415: !
1416: ! set local-pref to least significant 3 digits of the community
1417: ip community-list standard cm-prefmod-100 permit 64512:2100
1418: ip community-list standard cm-prefmod-200 permit 64512:2200
1419: ip community-list standard cm-prefmod-300 permit 64512:2300
1420: ip community-list standard cm-prefmod-400 permit 64512:2400
1421: ip community-list expanded cme-prefmod-range permit 64512:2...
1422: !
1423: ! Informational communities
1424: !
1425: ! 3000 - learned from upstream
1426: ! 3100 - learned from customer
1427: ! 3200 - learned from peer
1428: !
1429: ip community-list standard cm-learnt-upstream permit 64512:3000
1430: ip community-list standard cm-learnt-cust permit 64512:3100
1431: ip community-list standard cm-learnt-peer permit 64512:3200
1432: !
1433: ! ###################################################################
1434: ! Utility route-maps
1435: !
1436: ! These utility route-maps generally should not used to permit/deny
1437: ! routes, i.e. they do not have meaning as filters, and hence probably
1438: ! should be used with 'on-match next'. These all finish with an empty
1439: ! permit entry so as not interfere with processing in the caller.
1440: !
1441: route-map rm-no-export permit 10
1442: set community additive no-export
1443: route-map rm-no-export permit 20
1444: !
1445: route-map rm-blackhole permit 10
1446: description blackhole, up-pref and ensure it cant escape this AS
1447: set ip next-hop 127.0.0.1
1448: set local-preference 10
1449: set community additive no-export
1450: route-map rm-blackhole permit 20
1451: !
1452: ! Set local-pref as requested
1453: route-map rm-prefmod permit 10
1454: match community cm-prefmod-100
1455: set local-preference 100
1456: route-map rm-prefmod permit 20
1457: match community cm-prefmod-200
1458: set local-preference 200
1459: route-map rm-prefmod permit 30
1460: match community cm-prefmod-300
1461: set local-preference 300
1462: route-map rm-prefmod permit 40
1463: match community cm-prefmod-400
1464: set local-preference 400
1465: route-map rm-prefmod permit 50
1466: !
1467: ! Community actions to take on receipt of route.
1468: route-map rm-community-in permit 10
1469: description check for blackholing, no point continuing if it matches.
1470: match community cm-blackhole
1471: call rm-blackhole
1472: route-map rm-community-in permit 20
1473: match community cm-set-no-export
1474: call rm-no-export
1475: on-match next
1476: route-map rm-community-in permit 30
1477: match community cme-prefmod-range
1478: call rm-prefmod
1479: route-map rm-community-in permit 40
1480: !
1481: ! #####################################################################
1482: ! Community actions to take when advertising a route.
1483: ! These are filtering route-maps,
1484: !
1485: ! Deny customer routes to upstream with cust-only set.
1486: route-map rm-community-filt-to-upstream deny 10
1487: match community cm-learnt-cust
1488: match community cm-cust-only
1489: route-map rm-community-filt-to-upstream permit 20
1490: !
1491: ! Deny customer routes to other customers with upstream-only set.
1492: route-map rm-community-filt-to-cust deny 10
1493: match community cm-learnt-cust
1494: match community cm-upstream-only
1495: route-map rm-community-filt-to-cust permit 20
1496: !
1497: ! ###################################################################
1498: ! The top-level route-maps applied to sessions. Further entries could
1499: ! be added obviously..
1500: !
1501: ! Customers
1502: route-map rm-cust-in permit 10
1503: call rm-community-in
1504: on-match next
1505: route-map rm-cust-in permit 20
1506: set community additive 64512:3100
1507: route-map rm-cust-in permit 30
1508: !
1509: route-map rm-cust-out permit 10
1510: call rm-community-filt-to-cust
1511: on-match next
1512: route-map rm-cust-out permit 20
1513: !
1514: ! Upstream transit ASes
1515: route-map rm-upstream-out permit 10
1516: description filter customer prefixes which are marked cust-only
1517: call rm-community-filt-to-upstream
1518: on-match next
1519: route-map rm-upstream-out permit 20
1520: description only customer routes are provided to upstreams/peers
1521: match community cm-learnt-cust
1522: !
1523: ! Peer ASes
1524: ! outbound policy is same as for upstream
1525: route-map rm-peer-out permit 10
1526: call rm-upstream-out
1527: !
1528: route-map rm-peer-in permit 10
1529: set community additive 64512:3200
1530: @end example
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to bgpd.texi CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / quagga / doc