bgpd.texi 72 KB

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