Return to bgpd.texi CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / quagga / doc

quagga 1.0.20160315

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