draft-ietf-idr-bgp4-12.txt

xorp源码hg

   (decision process phases 1 and 2).

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over an external
   link.  If it does so, it shall do so prior to determining the degree
   of preference of the route and performing route selection (decision
   process phases 1 and 2).


5.1.5   LOCAL_PREF


   LOCAL_PREF is a well-known mandatory attribute that SHALL be included
   in all UPDATE messages that a given BGP speaker sends to the other
   internal peers. A BGP speaker SHALL calculate the degree of
   preference for each external route and include the degree of
   preference when advertising a route to its internal peers. The higher
   degree of preference MUST be preferred. A BGP speaker shall use the
   degree of preference learned via LOCAL_PREF in its decision process
   (see section 9.1.1).

   A BGP speaker MUST NOT include this attribute in UPDATE messages that
   it sends to external peers.  If it is contained in an UPDATE message
   that is received from an external peer, then this attribute MUST be
   ignored by the receiving speaker.


5.1.6   ATOMIC_AGGREGATE


   ATOMIC_AGGREGATE is a well-known discretionary attribute.  If a BGP
   speaker, when presented with a set of overlapping routes from one of
   its peers (see 9.1.4), selects the less specific route without
   selecting the more specific one, then the local system MUST attach
   the ATOMIC_AGGREGATE attribute to the route when propagating it to
   other BGP speakers (if that attribute is not already present in the
   received less specific route). A BGP speaker that receives a route
   with the ATOMIC_AGGREGATE attribute MUST NOT remove the attribute
   from the route when propagating it to other speakers. A BGP speaker
   that receives a route with the ATOMIC_AGGREGATE attribute MUST NOT
   make any NLRI of that route more specific (as defined in 9.1.4) when
   advertising this route to other BGP speakers.  A BGP speaker that
   receives a route with the ATOMIC_AGGREGATE attribute needs to be
   cognizant of the fact that the actual path to destinations, as
   specified in the NLRI of the route, while having the loop-free
   property, may traverse ASs that are not listed in the AS_PATH
   attribute.




Expiration Date July 2001                                      [Page 24]





RFC DRAFT                                                   January 2001


5.1.7   AGGREGATOR


   AGGREGATOR is an optional transitive attribute which may be included
   in updates which are formed by aggregation (see Section 9.2.4.2).  A
   BGP speaker which performs route aggregation may add the AGGREGATOR
   attribute which shall contain its own AS number and IP address.


6.  BGP Error Handling.


   This section describes actions to be taken when errors are detected
   while processing BGP messages.

   When any of the conditions described here are detected, a
   NOTIFICATION message with the indicated Error Code, Error Subcode,
   and Data fields is sent, and the BGP connection is closed.  If no
   Error Subcode is specified, then a zero must be used.

   The phrase "the BGP connection is closed" means that the transport
   protocol connection has been closed and that all resources for that
   BGP connection have been deallocated.  Routing table entries
   associated with the remote peer are marked as invalid.  The fact that
   the routes have become invalid is passed to other BGP peers before
   the routes are deleted from the system.

   Unless specified explicitly, the Data field of the NOTIFICATION
   message that is sent to indicate an error is empty.


6.1 Message Header error handling.


   All errors detected while processing the Message Header are indicated
   by sending the NOTIFICATION message with Error Code Message Header
   Error.  The Error Subcode elaborates on the specific nature of the
   error.

   The expected value of the Marker field of the message header is all
   ones if the message type is OPEN.  The expected value of the Marker
   field for all other types of BGP messages determined based on the
   presence of the Authentication Information Optional Parameter in the
   BGP OPEN message and the actual authentication mechanism (if the
   Authentication Information in the BGP OPEN message is present). If
   the Marker field of the message header is not the expected one, then
   a synchronization error has occurred and the Error Subcode is set to
   Connection Not Synchronized.



Expiration Date July 2001                                      [Page 25]





RFC DRAFT                                                   January 2001


   If the Length field of the message header is less than 19 or greater
   than 4096, or if the Length field of an OPEN message is less  than
   the minimum length of the OPEN message, or if the Length field of an
   UPDATE message is less than the minimum length of the UPDATE message,
   or if the Length field of a KEEPALIVE message is not equal to 19, or
   if the Length field of a NOTIFICATION message is less than the
   minimum length of the NOTIFICATION message, then the Error Subcode is
   set to Bad Message Length.  The Data field contains the erroneous
   Length field.

   If the Type field of the message header is not recognized, then the
   Error Subcode is set to Bad Message Type.  The Data field contains
   the erroneous Type field.


6.2 OPEN message error handling.


   All errors detected while processing the OPEN message are indicated
   by sending the NOTIFICATION message with Error Code OPEN Message
   Error.  The Error Subcode elaborates on the specific nature of the
   error.

   If the version number contained in the Version field of the received
   OPEN message is not supported, then the Error Subcode is set to
   Unsupported Version Number.  The Data field is a 1-octet unsigned
   integer, which indicates the largest locally supported version number
   less than the version the remote BGP peer bid (as indicated in the
   received OPEN message).

   If the Autonomous System field of the OPEN message is unacceptable,
   then the Error Subcode is set to Bad Peer AS.  The determination of
   acceptable Autonomous System numbers is outside the scope of this
   protocol.

   If the Hold Time field of the OPEN message is unacceptable, then the
   Error Subcode MUST be set to Unacceptable Hold Time.  An
   implementation MUST reject Hold Time values of one or two seconds.
   An implementation MAY reject any proposed Hold Time.  An
   implementation which accepts a Hold Time MUST use the negotiated
   value for the Hold Time.

   If the BGP Identifier field of the OPEN message is syntactically
   incorrect, then the Error Subcode is set to Bad BGP Identifier.
   Syntactic correctness means that the BGP Identifier field represents
   a valid IP host address.

   If one of the Optional Parameters in the OPEN message is not



Expiration Date July 2001                                      [Page 26]





RFC DRAFT                                                   January 2001


   recognized, then the Error Subcode is set to Unsupported Optional
   Parameters.


   If the OPEN message carries Authentication Information (as an
   Optional Parameter), then the corresponding authentication procedure
   is invoked.  If the authentication procedure (based on Authentication
   Code and Authentication Data) fails, then the Error Subcode is set to
   Authentication Failure.



6.3 UPDATE message error handling.


   All errors detected while processing the UPDATE message are indicated
   by sending the NOTIFICATION message with Error Code UPDATE Message
   Error.  The error subcode elaborates on the specific nature of the
   error.

   Error checking of an UPDATE message begins by examining the path
   attributes.  If the Unfeasible Routes Length or Total Attribute
   Length is too large (i.e., if Unfeasible Routes Length + Total
   Attribute Length + 23 exceeds the message Length), then the Error
   Subcode is set to Malformed Attribute List.

   If any recognized attribute has Attribute Flags that conflict with
   the Attribute Type Code, then the Error Subcode is set to Attribute
   Flags Error.  The Data field contains the erroneous attribute (type,
   length and value).

   If any recognized attribute has Attribute Length that conflicts with
   the expected length (based on the attribute type code), then the
   Error Subcode is set to Attribute Length Error.  The Data field
   contains the erroneous attribute (type, length and value).

   If any of the mandatory well-known attributes are not present, then
   the Error Subcode is set to Missing Well-known Attribute.  The Data
   field contains the Attribute Type Code of the missing well-known
   attribute.

   If any of the mandatory well-known attributes are not recognized,
   then the Error Subcode is set to Unrecognized Well-known Attribute.
   The Data field contains the unrecognized attribute (type, length and
   value).

   If the ORIGIN attribute has an undefined value, then the Error
   Subcode is set to Invalid Origin Attribute.  The Data field contains



Expiration Date July 2001                                      [Page 27]





RFC DRAFT                                                   January 2001


   the unrecognized attribute (type, length and value).

   If the NEXT_HOP attribute field is syntactically incorrect, then the
   Error Subcode is set to Invalid NEXT_HOP Attribute.  The Data field
   contains the incorrect attribute (type, length and value).  Syntactic
   correctness means that the NEXT_HOP attribute represents a valid IP
   host address.  Semantic correctness applies only to the external BGP
   links. It means that the interface associated with the IP address, as
   specified in the NEXT_HOP attribute, shares a common subnet with the
   receiving BGP speaker and is not the IP address of the receiving BGP
   speaker.  If the NEXT_HOP attribute is semantically incorrect, the
   error should be logged, and the the route should be ignored.  In this
   case, no NOTIFICATION message should be sent.

   The AS_PATH attribute is checked for syntactic correctness.  If the
   path is syntactically incorrect, then the Error Subcode is set to
   Malformed AS_PATH.


   The information carried by the AS_PATH attribute is checked for AS
   loops. AS loop detection is done by scanning the full AS path (as
   specified in the AS_PATH attribute), and checking that the autonomous
   system number of the local system does not appear in the AS path. If
   the autonomous system number appears in the AS path the route may be
   stored in the Adj-RIB-In, but unless the router is configured to
   accept routes with its own autonomous system in the AS path, the
   route shall not be passed to the BGP Decision Process.  Operations of
   a router that is configured to accept routes with its own autonomous
   system number in the AS path are outside the scope of this document.

   If an optional attribute is recognized, then the value of this
   attribute is checked.  If an error is detected, the attribute is
   discarded, and the Error Subcode is set to Optional Attribute Error.
   The Data field contains the attribute (type, length and value).

   If any attribute appears more than once in the UPDATE message, then
   the Error Subcode is set to Malformed Attribute List.

   The NLRI field in the UPDATE message is checked for syntactic
   validity.  If the field is syntactically incorrect, then the Error
   Subcode is set to Invalid Network Field.

   An UPDATE message that contains correct path attributes, but no NLRI,
   shall be treated as a valid UPDATE message.







Expiration Date July 2001                                      [Page 28]





RFC DRAFT                                                   January 2001


6.4 NOTIFICATION message error handling.


   If a peer sends a NOTIFICATION message, and there is an error in that
   message, there is unfortunately no means of reporting this error via
   a subsequent NOTIFICATION message.  Any such error, such as an
   unrecognized Error Code or Error Subcode, should be noticed, logged
   locally, and brought to the attention of the administration of the
   peer.  The means to do this, however, lies outside the scope of this
   document.


6.5 Hold Timer Expired error handling.


   If a system does not receive successive KEEPALIVE and/or UPDATE
   and/or NOTIFICATION messages within the period specified in the Hold
   Time field of the OPEN message, then the NOTIFICATION message with
   Hold Timer Expired Error Code must be sent and the BGP connection
   closed.


6.6 Finite State Machine error handling.


   Any error detected by the BGP Finite State Machine (e.g., receipt of
   an unexpected event) is indicated by sending the NOTIFICATION message
   with Error Code Finite State Machine Error.


6.7 Cease.


   In absence of any fatal errors (that are indicated in this section),
   a BGP peer may choose at any given time to close its BGP connection
   by sending the NOTIFICATION message with Error Code Cease.  However,
   the Cease NOTIFICATION message must not be used when a fatal error
   indicated by this section does exist.


6.8 Connection collision detection.