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