[BACK]Return to bgpd.texi CVS log [TXT] [DIR] Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / quagga / doc

Diff for /embedaddon/quagga/doc/bgpd.texi between versions 1.1.1.2 and 1.1.1.3

version 1.1.1.2, 2013/07/21 23:54:38 version 1.1.1.3, 2016/11/02 10:09:11
Line 1 Line 1
 @c -*-texinfo-*-  @c -*-texinfo-*-
 @c This is part of the Quagga Manual.  @c This is part of the Quagga Manual.
 @c @value{COPYRIGHT_STR}  @c @value{COPYRIGHT_STR}
   @c Portions: 
   @c   Copyright @copyright{} 2015 Hewlett Packard Enterprise Development LP
 @c See file quagga.texi for copying conditions.  @c See file quagga.texi for copying conditions.
 @node BGP  @node BGP
 @chapter BGP  @chapter BGP
Line 18  BGP-4. Line 20  BGP-4.
 @menu  @menu
 * Starting BGP::                  * Starting BGP::                
 * BGP router::                    * BGP router::                  
   * BGP MED::
 * BGP network::                   * BGP network::                 
 * BGP Peer::                      * BGP Peer::                    
 * BGP Peer Group::                * BGP Peer Group::              
Line 53  Set the bgp protocol's port number. Line 56  Set the bgp protocol's port number.
 @item -r  @item -r
 @itemx --retain  @itemx --retain
 When program terminates, retain BGP routes added by zebra.  When program terminates, retain BGP routes added by zebra.
   
   @item -l
   @itemx --listenon
   Specify a specific IP address for bgpd to listen on, rather than its 
   default of INADDR_ANY / IN6ADDR_ANY. This can be useful to constrain bgpd
   to an internal address, or to run multiple bgpd processes on one host.
   
 @end table  @end table
   
 @node BGP router  @node BGP router
Line 104  This command set distance value to  Line 114  This command set distance value to 
 @node BGP decision process  @node BGP decision process
 @subsection BGP decision process  @subsection BGP decision process
   
   The decision process Quagga BGP uses to select routes is as follows:
   
 @table @asis  @table @asis
 @item 1. Weight check  @item 1. Weight check
   prefer higher local weight routes to lower routes.
       
@item 2. Local preference check.@item 2. Local preference check
 prefer higher local preference routes to lower.
   
@item 3. Local route check.@item 3. Local route check
 Prefer local routes (statics, aggregates, redistributed) to received routes.
   
@item 4. AS path length check.@item 4. AS path length check
 Prefer shortest hop-count AS_PATHs. 
   
@item 5. Origin check.@item 5. Origin check
 Prefer the lowest origin type route.  That is, prefer IGP origin routes to
 EGP, to Incomplete routes. 
   
@item 6. MED check.@item 6. MED check
 Where routes with a MED were received from the same AS,
 prefer the route with the lowest MED. @xref{BGP MED}.
 
 @item 7. External check
 Prefer the route received from an external, eBGP peer
 over routes received from other types of peers.
 
 @item 8. IGP cost check
 Prefer the route with the lower IGP cost.
 
 @item 9. Multi-path check
 If multi-pathing is enabled, then check whether
 the routes not yet distinguished in preference may be considered equal. If
 @ref{bgp bestpath as-path multipath-relax} is set, all such routes are
 considered equal, otherwise routes received via iBGP with identical AS_PATHs
 or routes received from eBGP neighbours in the same AS are considered equal.
 
 @item 10 Already-selected external check
 
 Where both routes were received from eBGP peers, then prefer the route which
 is already selected.  Note that this check is not applied if @ref{bgp
 bestpath compare-routerid} is configured.  This check can prevent some cases
 of oscillation.
 
 @item 11. Router-ID check
 Prefer the route with the lowest @w{router-ID}.  If the
 route has an @w{ORIGINATOR_ID} attribute, through iBGP reflection, then that
 router ID is used, otherwise the @w{router-ID} of the peer the route was
 received from is used.
 
 @item 12. Cluster-List length check
 The route with the shortest cluster-list
 length is used.  The cluster-list reflects the iBGP reflection path the
 route has taken.
 
 @item 13. Peer address
 Prefer the route received from the peer with the higher
 transport layer address, as a last-resort tie-breaker.
 
 @end table  @end table
   
 @deffn {BGP} {bgp bestpath as-path confed} {}  @deffn {BGP} {bgp bestpath as-path confed} {}
Line 124  sequences should should be taken into account during t Line 181  sequences should should be taken into account during t
 decision process.  decision process.
 @end deffn  @end deffn
   
   @deffn {BGP} {bgp bestpath as-path multipath-relax} {}
   @anchor{bgp bestpath as-path multipath-relax}
   This command specifies that BGP decision process should consider paths
   of equal AS_PATH length candidates for multipath computation. Without
   the knob, the entire AS_PATH must match for multipath computation.
   @end deffn
   
   @deffn {BGP} {bgp bestpath compare-routerid} {}
   @anchor{bgp bestpath compare-routerid}
   
   Ensure that when comparing routes where both are equal on most metrics,
   including local-pref, AS_PATH length, IGP cost, MED, that the tie is broken
   based on router-ID.
   
   If this option is enabled, then the already-selected check, where
   already selected eBGP routes are preferred, is skipped.
   
   If a route has an @w{ORIGINATOR_ID} attribute because it has been reflected,
   that @w{ORIGINATOR_ID} will be used.  Otherwise, the router-ID of the peer the
   route was received from will be used.
   
   The advantage of this is that the route-selection (at this point) will be
   more deterministic.  The disadvantage is that a few or even one lowest-ID
   router may attract all trafic to otherwise-equal paths because of this
   check.  It may increase the possibility of MED or IGP oscillation, unless
   other measures were taken to avoid these.  The exact behaviour will be
   sensitive to the iBGP and reflection topology.
   
   @end deffn
   
   
 @node BGP route flap dampening  @node BGP route flap dampening
 @subsection BGP route flap dampening  @subsection BGP route flap dampening
   
Line 145  The route-flap damping algorithm is compatible with @c Line 233  The route-flap damping algorithm is compatible with @c
 is not recommended nowadays, see @uref{http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378}.  is not recommended nowadays, see @uref{http://www.ripe.net/ripe/docs/ripe-378,,RIPE-378}.
 @end deffn  @end deffn
   
   @node BGP MED
   @section BGP MED
   
   The BGP MED (Multi_Exit_Discriminator) attribute has properties which can
   cause subtle convergence problems in BGP.  These properties and problems
   have proven to be hard to understand, at least historically, and may still
   not be widely understood.  The following attempts to collect together and
   present what is known about MED, to help operators and Quagga users in
   designing and configuring their networks.
   
   The BGP @acronym{MED, Multi_Exit_Discriminator} attribute is intended to
   allow one AS to indicate its preferences for its ingress points to another
   AS.  The MED attribute will not be propagated on to another AS by the
   receiving AS - it is `non-transitive' in the BGP sense.
   
   E.g., if AS X and AS Y have 2 different BGP peering points, then AS X
   might set a MED of 100 on routes advertised at one and a MED of 200 at the
   other.  When AS Y selects between otherwise equal routes to or via
   AS X, AS Y should prefer to take the path via the lower MED peering of 100 with
   AS X.  Setting the MED allows an AS to influence the routing taken to it
   within another, neighbouring AS.
   
   In this use of MED it is not really meaningful to compare the MED value on
   routes where the next AS on the paths differs.  E.g., if AS Y also had a
   route for some destination via AS Z in addition to the routes from AS X, and
   AS Z had also set a MED, it wouldn't make sense for AS Y to compare AS Z's
   MED values to those of AS X.  The MED values have been set by different
   administrators, with different frames of reference.
   
   The default behaviour of BGP therefore is to not compare MED values across
   routes received from different neighbouring ASes.  In Quagga this is done by
   comparing the neighbouring, left-most AS in the received AS_PATHs of the
   routes and only comparing MED if those are the same.
   
   @c TeXInfo uses the old, non-UTF-8 capable, pdftex, and so 
   @c doesn't render TeX the unicode precedes character correctly in PDF, etc.
   @c Using a TeX code on the other hand doesn't work for non-TeX outputs
   @c (plaintext, e.g.). So, use an output-conditional macro.
   
   @iftex
   @macro mprec{}
   @math{\\prec}
   @end macro
   @end iftex
   
   @ifnottex
   @macro mprec{}
   @math{≺}
   @end macro
   @end ifnottex
   
   Unfortunately, this behaviour of MED, of sometimes being compared across
   routes and sometimes not, depending on the properties of those other routes,
   means MED can cause the order of preference over all the routes to be
   undefined.  That is, given routes A, B, and C, if A is preferred to B, and B
   is preferred to C, then a well-defined order should mean the preference is
   transitive (in the sense of orders @footnote{For some set of objects to have
   an order, there @emph{must} be some binary ordering relation that is defined
   for @emph{every} combination of those objects, and that relation @emph{must}
   be transitive.  I.e.@:, if the relation operator is @mprec{}, and if 
   a @mprec{} b and b @mprec{} c then that relation must carry over
   and it @emph{must} be that a @mprec{} c for the objects to have an
   order.  The ordering relation may allow for equality, i.e. 
   a @mprec{} b and b @mprec{} a may both be true amd imply that
   a and b are equal in the order and not distinguished by it, in
   which case the set has a partial order.  Otherwise, if there is an order,
   all the objects have a distinct place in the order and the set has a total
   order.}) and that A would be preferred to C.
   
   However, when MED is involved this need not be the case.  With MED it is
   possible that C is actually preferred over A.  So A is preferred to B, B is
   preferred to C, but C is preferred to A.  This can be true even where BGP
   defines a deterministic ``most preferred'' route out of the full set of
   A,B,C.  With MED, for any given set of routes there may be a
   deterministically preferred route, but there need not be any way to arrange
   them into any order of preference.  With unmodified MED, the order of
   preference of routes literally becomes undefined.
   
   That MED can induce non-transitive preferences over routes can cause issues. 
   Firstly, it may be perceived to cause routing table churn locally at
   speakers; secondly, and more seriously, it may cause routing instability in
   iBGP topologies, where sets of speakers continually oscillate between
   different paths.
   
   The first issue arises from how speakers often implement routing decisions. 
   Though BGP defines a selection process that will deterministically select
   the same route as best at any given speaker, even with MED, that process
   requires evaluating all routes together.  For performance and ease of
   implementation reasons, many implementations evaluate route preferences in a
   pair-wise fashion instead.  Given there is no well-defined order when MED is
   involved, the best route that will be chosen becomes subject to
   implementation details, such as the order the routes are stored in.  That
   may be (locally) non-deterministic, e.g.@: it may be the order the routes
   were received in.  
   
   This indeterminism may be considered undesirable, though it need not cause
   problems.  It may mean additional routing churn is perceived, as sometimes
   more updates may be produced than at other times in reaction to some event .
   
   This first issue can be fixed with a more deterministic route selection that
   ensures routes are ordered by the neighbouring AS during selection. 
   @xref{bgp deterministic-med}.  This may reduce the number of updates as
   routes are received, and may in some cases reduce routing churn.  Though, it
   could equally deterministically produce the largest possible set of updates
   in response to the most common sequence of received updates.
   
   A deterministic order of evaluation tends to imply an additional overhead of
   sorting over any set of n routes to a destination.  The implementation of
   deterministic MED in Quagga scales significantly worse than most sorting
   algorithms at present, with the number of paths to a given destination. 
   That number is often low enough to not cause any issues, but where there are
   many paths, the deterministic comparison may quickly become increasingly
   expensive in terms of CPU.
   
   Deterministic local evaluation can @emph{not} fix the second, more major,
   issue of MED however.  Which is that the non-transitive preference of routes
   MED can cause may lead to routing instability or oscillation across multiple
   speakers in iBGP topologies.  This can occur with full-mesh iBGP, but is
   particularly problematic in non-full-mesh iBGP topologies that further
   reduce the routing information known to each speaker.  This has primarily
   been documented with iBGP route-reflection topologies.  However, any
   route-hiding technologies potentially could also exacerbate oscillation with
   MED.
   
   This second issue occurs where speakers each have only a subset of routes,
   and there are cycles in the preferences between different combinations of
   routes - as the undefined order of preference of MED allows - and the routes
   are distributed in a way that causes the BGP speakers to 'chase' those
   cycles.  This can occur even if all speakers use a deterministic order of
   evaluation in route selection.
   
   E.g., speaker 4 in AS A might receive a route from speaker 2 in AS X, and
   from speaker 3 in AS Y; while speaker 5 in AS A might receive that route
   from speaker 1 in AS Y.  AS Y might set a MED of 200 at speaker 1, and 100
   at speaker 3. I.e, using ASN:ID:MED to label the speakers:
   
   @example
   
              /---------------\
    X:2------|--A:4-------A:5--|-Y:1:200
    Y:3:100--|-/               |
              \---------------/
   
   @end example
   
   Assuming all other metrics are equal (AS_PATH, ORIGIN, 0 IGP costs), then
   based on the RFC4271 decision process speaker 4 will choose X:2 over
   Y:3:100, based on the lower ID of 2.  Speaker 4 advertises X:2 to speaker 5. 
   Speaker 5 will continue to prefer Y:1:200 based on the ID, and advertise
   this to speaker 4.  Speaker 4 will now have the full set of routes, and the
   Y:1:200 it receives from 5 will beat X:2, but when speaker 4 compares
   Y:1:200 to Y:3:100 the MED check now becomes active as the ASes match, and
   now Y:3:100 is preferred.  Speaker 4 therefore now advertises Y:3:100 to 5,
   which will also agrees that Y:3:100 is preferred to Y:1:200, and so
   withdraws the latter route from 4.  Speaker 4 now has only X:2 and Y:3:100,
   and X:2 beats Y:3:100, and so speaker 4 implicitly updates its route to
   speaker 5 to X:2.  Speaker 5 sees that Y:1:200 beats X:2 based on the ID,
   and advertises Y:1:200 to speaker 4, and the cycle continues.
   
   The root cause is the lack of a clear order of preference caused by how MED
   sometimes is and sometimes is not compared, leading to this cycle in the
   preferences between the routes:
   
   @example
   
          /---> X:2 ---beats---> Y:3:100 --\
         |                                  |
         |                                  |
          \---beats--- Y:1:200 <---beats---/
   
   @end example
   
   This particular type of oscillation in full-mesh iBGP topologies can  be
   avoided by speakers preferring already selected, external routes rather than
   choosing to update to new a route based on a post-MED metric (e.g. 
   router-ID), at the cost of a non-deterministic selection process.  Quagga
   implements this, as do many other implementations, so long as it is not
   overridden by setting @ref{bgp bestpath compare-routerid}, and see also
   @ref{BGP decision process}, .
   
   However, more complex and insidious cycles of oscillation are possible with
   iBGP route-reflection, which are not so easily avoided.  These have been
   documented in various places.  See, e.g., @cite{McPherson, D.  and Gill, V. 
   and Walton, D., "Border Gateway Protocol (BGP) Persistent Route Oscillation
   Condition", IETF RFC3345}, and @cite{Flavel, A.  and M.  Roughan, "Stable
   and flexible iBGP", ACM SIGCOMM 2009}, and @cite{Griffin, T.  and G.  Wilfong, 
   "On the correctness of IBGP configuration", ACM SIGCOMM 2002} for concrete 
   examples and further references.
   
   There is as of this writing @emph{no} known way to use MED for its original
   purpose; @emph{and} reduce routing information in iBGP topologies;
   @emph{and} be sure to avoid the instability problems of MED due the
   non-transitive routing preferences it can induce; in general on arbitrary
   networks.
   
   There may be iBGP topology specific ways to reduce the instability risks,
   even while using MED, e.g.@: by constraining the reflection topology and by
   tuning IGP costs between route-reflector clusters, see RFC3345 for details. 
   In the near future, the Add-Path extension to BGP may also solve MED
   oscillation while still allowing MED to be used as intended, by distributing
   "best-paths per neighbour AS".  This would be at the cost of distributing at
   least as many routes to all speakers as a full-mesh iBGP would, if not more,
   while also imposing similar CPU overheads as the "Deterministic MED" feature
   at each Add-Path reflector.
   
   More generally, the instability problems that MED can introduce on more
   complex, non-full-mesh, iBGP topologies may be avoided either by:
   
   @itemize 
   
   @item
   Setting @ref{bgp always-compare-med}, however this allows MED to be compared
   across values set by different neighbour ASes, which may not produce
   coherent desirable results, of itself.
   
   @item 
   Effectively ignoring MED by setting MED to the same value (e.g.@: 0) using
   @ref{routemap set metric} on all received routes, in combination with
   setting @ref{bgp always-compare-med} on all speakers. This is the simplest
   and most performant way to avoid MED oscillation issues, where an AS is happy
   not to allow neighbours to inject this problematic metric.
   
   @end itemize
   
   As MED is evaluated after the AS_PATH length check, another possible use for
   MED is for intra-AS steering of routes with equal AS_PATH length, as an
   extension of the last case above.  As MED is evaluated before IGP metric,
   this can allow cold-potato routing to be implemented to send traffic to
   preferred hand-offs with neighbours, rather than the closest hand-off
   according to the IGP metric.
   
   Note that even if action is taken to address the MED non-transitivity
   issues, other oscillations may still be possible.  E.g., on IGP cost if
   iBGP and IGP topologies are at cross-purposes with each other - see the
   Flavel and Roughan paper above for an example.  Hence the guideline that the
   iBGP topology should follow the IGP topology.
   
   @deffn {BGP} {bgp deterministic-med} {}
   @anchor{bgp deterministic-med}
   
   Carry out route-selection in way that produces deterministic answers
   locally, even in the face of MED and the lack of a well-defined order of
   preference it can induce on routes.  Without this option the preferred route
   with MED may be determined largely by the order that routes were received
   in.
   
   Setting this option will have a performance cost that may be noticeable when
   there are many routes for each destination.  Currently in Quagga it is
   implemented in a way that scales poorly as the number of routes per
   destination increases.
   
   The default is that this option is not set.
   @end deffn
   
   Note that there are other sources of indeterminism in the route selection
   process, specifically, the preference for older and already selected routes
   from eBGP peers, @xref{BGP decision process}.
   
   @deffn {BGP} {bgp always-compare-med} {}
   @anchor{bgp always-compare-med}
   
   Always compare the MED on routes, even when they were received from
   different neighbouring ASes.  Setting this option makes the order of
   preference of routes more defined, and should eliminate MED induced
   oscillations.
   
   If using this option, it may also be desirable to use @ref{routemap set
   metric} to set MED to 0 on routes received from external neighbours.
   
   This option can be used, together with @ref{routemap set metric} to use MED
   as an intra-AS metric to steer equal-length AS_PATH routes to, e.g., desired
   exit points.
   @end deffn
   
   
   
 @node BGP network  @node BGP network
 @section BGP network  @section BGP network
   
Line 182  This command specifies an aggregate address. Line 546  This command specifies an aggregate address.
 @end deffn  @end deffn
   
 @deffn {BGP} {aggregate-address @var{A.B.C.D/M} as-set} {}  @deffn {BGP} {aggregate-address @var{A.B.C.D/M} as-set} {}
This command specifies an aggregate address.  Resulting routes inlucdeThis command specifies an aggregate address.  Resulting routes include
 AS set.  AS set.
 @end deffn  @end deffn
   
Line 293  This command is deprecated and may be removed in a fut Line 657  This command is deprecated and may be removed in a fut
 use should be avoided.  use should be avoided.
 @end deffn  @end deffn
   
@deffn {BGP} {neighbor @var{peer} next-hop-self} {}@deffn {BGP} {neighbor @var{peer} next-hop-self [all]} {}
@deffnx {BGP} {no neighbor @var{peer} next-hop-self} {}@deffnx {BGP} {no neighbor @var{peer} next-hop-self [all]} {}
 This command specifies an announced route's nexthop as being equivalent  This command specifies an announced route's nexthop as being equivalent
to the address of the bgp router.to the address of the bgp router if it is learned via eBGP.
 If the optional keyword @code{all} is specified the modifiation is done
 also for routes learned via iBGP.
 @end deffn  @end deffn
   
 @deffn {BGP} {neighbor @var{peer} update-source @var{<ifname|address>}} {}  @deffn {BGP} {neighbor @var{peer} update-source @var{<ifname|address>}} {}
Line 360  Note that replace-as can only be specified if no-prepe Line 726  Note that replace-as can only be specified if no-prepe
 This command is only allowed for eBGP peers.  This command is only allowed for eBGP peers.
 @end deffn  @end deffn
   
   @deffn {BGP} {neighbor @var{peer} ttl-security hops @var{number}} {}
   @deffnx {BGP} {no neighbor @var{peer} ttl-security hops @var{number}} {}
   This command enforces Generalized TTL Security Mechanism (GTSM), as
   specified in RFC 5082. With this command, only neighbors that are the
   specified number of hops away will be allowed to become neighbors. This
   command is mututally exclusive with @command{ebgp-multihop}.
   @end deffn
   
 @node Peer filtering  @node Peer filtering
 @subsection Peer filtering  @subsection Peer filtering
   
Line 394  This command bind specific peer to peer group @var{wor Line 768  This command bind specific peer to peer group @var{wor
 @node BGP Address Family  @node BGP Address Family
 @section BGP Address Family  @section BGP Address Family
   
   Multiprotocol BGP enables BGP to carry routing information for multiple
   Network Layer protocols. BGP supports multiple Address Family
   Identifier (AFI), namely IPv4 and IPv6. Support is also provided for
   multiple sets of per-AFI information via Subsequent Address Family
   Identifiers (SAFI).  In addition to unicast information, VPN information
   @cite{RFC4364} and @cite{RFC4659}, and Encapsulation information
   @cite{RFC5512} is supported.
   
   @deffn {Command} {show ip bgp vpnv4 all} {}
   @deffnx {Command} {show ipv6 bgp vpn all} {}
   Print active IPV4 or IPV6 routes advertised via the VPN SAFI.
   @end deffn
   
   @deffn {Command} {show ip bgp encap all} {}
   @deffnx {Command} {show ipv6 bgp encap all} {}
   Print active IPV4 or IPV6 routes advertised via the Encapsulation SAFI.
   @end deffn
   
   @deffn {Command} {show bgp ipv4 encap summary} {}
   @deffnx {Command} {show bgp ipv4 vpn summary} {}
   @deffnx {Command} {show bgp ipv6 encap summary} {}
   @deffnx {Command} {show bgp ipv6 vpn summary} {}
   Print a summary of neighbor connections for the specified AFI/SAFI combination.
   @end deffn
   
 @c -----------------------------------------------------------------------  @c -----------------------------------------------------------------------
 @node Autonomous System  @node Autonomous System
 @section Autonomous System  @section Autonomous System
Line 480  This command defines a new AS path access list. Line 879  This command defines a new AS path access list.
 @end deffn  @end deffn
   
 @deffn {Route Map} {set as-path prepend @var{as-path}} {}  @deffn {Route Map} {set as-path prepend @var{as-path}} {}
   Prepend the given string of AS numbers to the AS_PATH.
 @end deffn  @end deffn
   
   @deffn {Route Map} {set as-path prepend last-as @var{num}} {}
   Prepend the existing last AS number (the leftmost ASN) to the AS_PATH.
   @end deffn
   
 @node Private AS Numbers  @node Private AS Numbers
 @subsection Private AS Numbers  @subsection Private AS Numbers
   
Line 1305  log file bgpd.log Line 1709  log file bgpd.log
 @node Dump BGP packets and table  @node Dump BGP packets and table
 @section Dump BGP packets and table  @section Dump BGP packets and table
   
@deffn Command {dump bgp all @var{path}} {}@deffn Command {dump bgp all @var{path} [@var{interval}]} {}
@deffnx Command {dump bgp all @var{path} @var{interval}} {}@deffnx Command {dump bgp all-et @var{path} [@var{interval}]} {}
 @deffnx Command {no dump bgp all [@var{path}] [@var{interval}]} {}
 Dump all BGP packet and events to @var{path} file.  Dump all BGP packet and events to @var{path} file.
   If @var{interval} is set, a new file will be created for echo @var{interval} of seconds.
   The path @var{path} can be set with date and time formatting (strftime).
   The type ‘all-et’ enables support for Extended Timestamp Header (@pxref{Packet Binary Dump Format}).
   (@pxref{Packet Binary Dump Format})
 @end deffn   @end deffn 
   
@deffn Command {dump bgp updates @var{path}} {}@deffn Command {dump bgp updates @var{path} [@var{interval}]} {}
@deffnx Command {dump bgp updates @var{path} @var{interval}} {}@deffnx Command {dump bgp updates-et @var{path} [@var{interval}]} {}
Dump BGP updates to @var{path} file.@deffnx Command {no dump bgp updates [@var{path}] [@var{interval}]} {}
 Dump only BGP updates messages to @var{path} file.
 If @var{interval} is set, a new file will be created for echo @var{interval} of seconds.
 The path @var{path} can be set with date and time formatting (strftime).
 The type ‘updates-et’ enables support for Extended Timestamp Header (@pxref{Packet Binary Dump Format}).
 @end deffn  @end deffn
   
@deffn Command {dump bgp routes @var{path}} {}@deffn Command {dump bgp routes-mrt @var{path}} {}
@deffnx Command {dump bgp routes @var{path}} {}@deffnx Command {dump bgp routes-mrt @var{path} @var{interval}} {}
 @deffnx Command {no dump bgp route-mrt [@var{path}] [@var{interval}]} {}
 Dump whole BGP routing table to @var{path}.  This is heavy process.  Dump whole BGP routing table to @var{path}.  This is heavy process.
   The path @var{path} can be set with date and time formatting (strftime).
   If @var{interval} is set, a new file will be created for echo @var{interval} of seconds.
 @end deffn  @end deffn
   
   Note: the interval variable can also be set using hours and minutes: 04h20m00.
   
   
 @node BGP Configuration Examples  @node BGP Configuration Examples
 @section BGP Configuration Examples  @section BGP Configuration Examples
Removed from v.1.1.1.2  
changed lines
  Added in v.1.1.1.3

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>