rfc1403.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                       K.  Varadhan
Request for Comments: 1403                                        OARnet
Obsoletes: 1364                                             January 1993


                          BGP OSPF Interaction

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   This memo defines the various criteria to be used when designing an
   Autonomous System Border Routers (ASBR) that will run BGP with other
   ASBRs external to the AS and OSPF as its IGP.  This is a
   republication of RFC 1364 to correct some editorial problems.

Table of Contents

 1.  Introduction ....................................................  2
 2.  Route Exchange ..................................................  3
 2.1.  Exporting OSPF routes into BGP ................................  3
 2.2.  Importing BGP routes into OSPF ................................  4
 3.  BGP Identifier and OSPF router ID ...............................  5
 4.  Setting OSPF tags, BGP ORIGIN and AS_PATH attributes ............  6
 4.1.  Semantics of the characteristics bits .........................  8
 4.2.  Configuration parameters for setting the OSPF tag .............  9
 4.3.  Manually configured tags ...................................... 10
 4.4.  Automatically generated tags .................................. 10
 4.4.1.  Routes with incomplete path information, PathLength = 0 ..... 10
 4.4.2.  Routes with incomplete path information, PathLength = 1 ..... 11
 4.4.3.  Routes with incomplete path information, PathLength >= 1 .... 11
 4.4.4.  Routes with complete path information, PathLength = 0 ....... 12
 4.4.5.  Routes with complete path information, PathLength = 1 ....... 12
 4.4.6.  Routes with complete path information, PathLength >= 1 ...... 13
 4.5.  Miscellaneous tag settings .................................... 13
 4.6.  Summary of the TagType field setting .......................... 14
 5.  Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ...... 14
 6.  Security Considerations ......................................... 15
 7.  Acknowledgements ................................................ 15
 8.  Bibliography .................................................... 16
 9.  Author's Address ................................................ 17




Varadhan                                                        [Page 1]

RFC 1403                  BGP OSPF Interaction              January 1993


1.  Introduction

   This document defines the various criteria to be used when designing
   an Autonomous System Border Routers (ASBR) that will run BGP
   [RFC1267] with other ASBRs external to the AS, and OSPF [RFC1247] as
   its IGP.

   This document defines how the following fields in OSPF and attributes
   in BGP are to be set when interfacing between BGP and OSPF at an
   ASBR:

           OSPF cost and type      vs. BGP INTER-AS METRIC
           OSPF tag                vs. BGP ORIGIN and AS_PATH
           OSPF Forwarding Address vs. BGP NEXT_HOP

   For a more general treatise on routing and route exchange problems,
   please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist.

   This document uses the two terms "Autonomous System" and "Routing
   Domain".  The definitions for the two are below:

   The term Autonomous System is the same as is used in the BGP-3 RFC
   [RFC1267], given below:

        "The use of the term Autonomous System here stresses the fact
        that, even when multiple IGPs and metrics are used, the
        administration of an AS appears to other ASs to have a single
        coherent interior routing plan and presents a consistent picture
        of what networks are reachable through it.  From the standpoint
        of exterior routing, an AS can be viewed as monolithic:
        reachability to networks directly connected to the AS must be
        equivalent from all border gateways of the AS."

   The term Routing Domain was first used in [ROUTE-LEAKING] and is
   given below:

          "A Routing Domain is a collection of routers which coordinate
          their routing knowledge using a single (instance of) a routing
          protocol."

     This document follows the conventions embodied in the Host
     Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST",
     "SHOULD", and "MAY" for the various requirements.








Varadhan                                                        [Page 2]

RFC 1403                  BGP OSPF Interaction              January 1993


2.  Route Exchange

   This section discusses the constraints that must be met to exchange
   routes between an external BGP session with a peer from another AS
   and internal OSPF routes.

   BGP does not carry subnet information in routing updates.  Therefore,
   when referring to a subnetted network in the OSPF routing domain, we
   consider the equivalent network route in the context of BGP.
   Multiple subnet routes for a subnetted network in OSPF are collapsed
   into one network route when exported into BGP.

   2.1.  Exporting OSPF routes into BGP

      1.   The administrator MUST be able to selectively export OSPF
           routes into BGP via an appropriate filter mechanism.

           This filter mechanism MUST support such control with the
           granularity of a single network.

           Additionally, the administrator MUST be able to filter based
           on the OSPF tag and the various sub-fields of the OSPF tag.
           The settings of the tag and the sub-fields are defined in
           section 4 in more detail.

           o    The default MUST be to export no routes from OSPF into
                BGP.  A single configuration parameter MUST permit all
                OSPF inter-area and intra-area routes to be exported
                into BGP.

                OSPF external routes of type 1 and type 2 MUST never be
                exported into BGP unless they are explicitly configured.

      2.   When configured to export a network, the ASBR MUST advertise
           a network route for a subnetted network, as long as at least
           one subnet in the subnetted network is reachable via OSPF.

      3.   The network administrator MUST be able to statically
           configure the BGP attribute INTER-AS METRIC to be used for
           any network route.

           o    By default, the INTER_AS METRIC MUST not be set.  This
                is because the INTER_AS METRIC is an optional attribute
                in BGP.

           Explanatory text: The OSPF cost and the BGP INTER-AS METRIC
           are of different widths.  The OSPF cost is a two level
           metric.  The BGP INTER-AS METRIC is only an optional non-



Varadhan                                                        [Page 3]

RFC 1403                  BGP OSPF Interaction              January 1993


           transitive attribute.  Hence, a more complex BGP INTER-AS
           METRIC-OSPF cost mapping scheme is not necessary.

      4.   When an ASBR is advertising an OSPF route to network Y to
           external BGP neighbours and learns that the route has become
           unreachable, the ASBR MUST immediately propagate this
           information to the external BGP neighbours.

      5.   An implementation of BGP and OSPF on an ASBR MUST have a
           mechanism to set up a minimum amount of time that must elapse
           between the learning of a new route via OSPF and subsequent
           advertisement of the route via BGP to the external
           neighbours.

           o    The default value for this setting MUST be 0, indicating
                that the route is to be advertised to the neighbour BGP
                peers instantly.

                Note that [RFC1267] mandates a mechanism to dampen the
                inbound advertisements from adjacent neighbours.

   2.2.  Importing BGP routes into OSPF

      1.   BGP implementations SHOULD allow an AS to control
           announcements of BGP-learned routes into OSPF.
           Implementations SHOULD support such control with the
           granularity of a single network.  Implementations SHOULD also
           support such control with the granularity of an autonomous
           system, where the autonomous system may be either the
           autonomous system that originated the route or the autonomous
           system that advertised the route to the local system
           (adjacent autonomous system).

           o    The default MUST be to export no routes from BGP into
                OSPF.  Administrators must configure every route they
                wish to import.

                A configuration parameter MAY allow an administrator to
                configure an ASBR to import all the BGP routes into the
                OSPF routing domain.

      2.   The administrator MUST be able to configure the OSPF cost and
           the OSPF metric type of every route imported into OSPF.

           o    The OSPF cost MUST default to 1; the OSPF metric type
                MUST default to type 2.





Varadhan                                                        [Page 4]

RFC 1403                  BGP OSPF Interaction              January 1993


      3.   Routes learned via BGP from peers within the same AS MUST not
           be imported into OSPF.

      4.   The ASBR MUST never generate a default route into the OSPF
           routing domain unless explicitly configured to do so.

           A possible criterion for generating default into an IGP is to
           allow the administrator to specify a set of (network route,
           AS_PATH, default route cost, default route type) tuples.  If
           the ASBR learns of the network route for an element of the
           set, with the corresponding AS_PATH, then it generates a
           default route into the OSPF routing domain, with cost
           "default route cost" and type, "default route type".  The
           lowest cost default route will then be injected into the OSPF
           routing domain.

           This is the recommended method for originating default routes
           in the OSPF routing domain.

3.  BGP Identifier and OSPF router ID

   The BGP identifier MUST be the same as the OSPF router id at all
   times that the router is up.

   This characteristic is required for two reasons.

     i    Synchronisation between OSPF and BGP

          Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3,
          belong to the same autonomous system.


                                     +-----+
                                     | RT3 |
                                     +-----+
                                        |

                          Autonomous System running OSPF

                                 /               \
                             +-----+          +-----+
                             | RT1 |          | RT2 |
                             +-----+          +-----+


          Both RT1 and RT2 have routes to an external network X and
          import it into the OSPF routing domain.  RT3 is advertising
          the route to network X to other external BGP speakers.  RT3



Varadhan                                                        [Page 5]

RFC 1403                  BGP OSPF Interaction              January 1993


          must use the OSPF router ID to determine whether it is using
          RT1 or RT2 to forward packets to network X and hence build the
          correct AS_PATH to advertise to other external speakers.

          More precisely, RT3 must determine which ASBR it is using to
          reach network X by matching the OSPF router ID for its route
          to network X with the BGP Identifier of one of the ASBRs, and
          use the corresponding route for further advertisement to
          external BGP peers.

     ii   It will be convenient for the network administrator looking at
          an ASBR to correlate different BGP and OSPF routes based on
          the identifier.

4.  Setting OSPF tags, BGP ORIGIN and AS_PATH attributes

   The OSPF external route tag is a "32-bit field attached to each
   external route . . . It may be used to communicate information
   between AS boundary routers; the precise nature of such information
   is outside the scope of [the] specification." [RFC1247]

   OSPF imports information from various routing protocols at all its
   ASBRs.  In some instances, it is possible to use protocols other than
   EGP or BGP across autonomous systems.  It is important, in BGP, to
   differentiate between routes that are external to the OSPF routing
   domain but must be considered internal to the AS, as opposed to
   routes that are external to the AS.

   Routes that are internal to the AS and that may or may not be
   external to the OSPF routing domain will not come to the various BGP
   speakers from other BGP speakers within the same autonomous system
   via BGP.  Therefore, ASBRs running BGP must have knowledge of this
   class of routes so that they can advertise these routes to the