RFC3509 日本語訳

3509 Alternative Implementations of OSPF Area Border Routers. A.Zinin, A. Lindem, D. Yeung. April 2003. (Format: TXT=24326 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                           A. Zinin
Request for Comments: 3509                                       Alcatel
Category: Informational                                        A. Lindem
                                                        Redback Networks
                                                                D. Yeung
                                                        Procket Networks
                                                              April 2003

Network Working Group A. Zinin Request for Comments: 3509 Alcatel Category: Informational A. Lindem Redback Networks D. Yeung Procket Networks April 2003

        Alternative Implementations of OSPF Area Border Routers

Alternative Implementations of OSPF Area Border Routers

Status of this Memo

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

Abstract

   Open Shortest Path First (OSPF) is a link-state intra-domain routing
   protocol used for routing in IP networks.  Though the definition of
   the Area Border Router (ABR) in the OSPF specification does not
   require a router with multiple attached areas to have a backbone
   connection, it is actually necessary to provide successful routing to
   the inter-area and external destinations.  If this requirement is not
   met, all traffic destined for the areas not connected to such an ABR
   or out of the OSPF domain, is dropped.  This document describes
   alternative ABR behaviors implemented in Cisco and IBM routers.

Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers.

1 Overview

1 Overview

1.1 Introduction

1.1 Introduction

   An OSPF routing domain can be split into several subdomains, called
   areas, which limit the scope of LSA flooding.  According to [Ref1] a
   router having attachments to multiple areas is called an "area border
   router" (ABR).  The primary function of an ABR is to provide its
   attached areas with Type-3 and Type-4 LSAs, which are used for
   describing routes and AS boundary routers (ASBRs) in other areas, as
   well as to perform actual inter-area routing.

An OSPF routing domain can be split into several subdomains, called areas, which limit the scope of LSA flooding. According to [Ref1] a router having attachments to multiple areas is called an "area border router" (ABR). The primary function of an ABR is to provide its attached areas with Type-3 and Type-4 LSAs, which are used for describing routes and AS boundary routers (ASBRs) in other areas, as well as to perform actual inter-area routing.

Zinin, et al.                Informational                      [Page 1]

RFC 3509                   OSPF ABR Behavior                  April 2003

Zinin, et al. Informational [Page 1] RFC 3509 OSPF ABR Behavior April 2003

1.2 Motivation

1.2 Motivation

   In OSPF domains the area topology is restricted so that there must be
   a backbone area (area 0) and all other areas must have either
   physical or virtual connections to the backbone.  The reason for this
   star-like topology is that OSPF inter-area routing uses the
   distance-vector approach and a strict area hierarchy permits
   avoidance of the "counting to infinity" problem.  OSPF prevents
   inter-area routing loops by implementing a split-horizon mechanism,
   allowing ABRs to inject into the backbone only Summary-LSAs derived
   from the
   intra-area routes, and limiting ABRs' SPF calculation to consider
   only Summary-LSAs in the backbone area's link-state database.

In OSPF domains the area topology is restricted so that there must be a backbone area (area 0) and all other areas must have either physical or virtual connections to the backbone. The reason for this star-like topology is that OSPF inter-area routing uses the distance-vector approach and a strict area hierarchy permits avoidance of the "counting to infinity" problem. OSPF prevents inter-area routing loops by implementing a split-horizon mechanism, allowing ABRs to inject into the backbone only Summary-LSAs derived from the intra-area routes, and limiting ABRs' SPF calculation to consider only Summary-LSAs in the backbone area's link-state database.

   The last restriction leads to a problem when an ABR has no backbone
   connection (in OSPF, an ABR does not need to be attached to the
   backbone).  Consider a sample OSPF domain depicted in the Figure 1.

The last restriction leads to a problem when an ABR has no backbone connection (in OSPF, an ABR does not need to be attached to the backbone). Consider a sample OSPF domain depicted in the Figure 1.

                          .                .
                           .    Area 0    .
                            +--+      +--+
                          ..|R1|..  ..|R2|..
                         .  +--+  ..  +--+  .
                         .        ..        .
                         .       +--+       .
                         . Area1 |R3| Area2 .
                         .       +--+  +--+ .
                         .        ..   |R4| .
                         .       .  .  +--+ .
                          .......    .......

. . . Area 0 . +--+ +--+ ..|R1|.. ..|R2|.. . +--+ .. +--+ . . .. . . +--+ . . Area1 |R3| Area2 . . +--+ +--+ . . .. |R4| . . . . +--+ . ....... .......

                  Figure 1. ABR dropping transit traffic

Figure 1. ABR dropping transit traffic

   In this example R1, R2, and R3 are ABRs.  R1 and R2 have backbone
   connections, while R3 doesn't.

In this example R1, R2, and R3 are ABRs. R1 and R2 have backbone connections, while R3 doesn't.

   Following the section 12.4.1 of [Ref1], R3 will identify itself as an
   ABR by setting the bit B in its router-LSA.  Being an ABR, R3 can
   only consider summary-LSAs from the backbone when building the
   routing table (according to section 16.2 of [Ref1]), so it will not
   have any inter-area routes in its routing table, but only intra-area
   routes from both Area 1 and Area 2.  Consequently, according to
   section 12.4.3 of [Ref1], R3 will originate into Areas 1 and 2 only
   summary-LSAs covering destinations in the directly attached areas,
   i.e., in Area 2---the summary-LSAs for Area 1, and in Area 1---the
   summary-LSAs for Area 2.

Following the section 12.4.1 of [Ref1], R3 will identify itself as an ABR by setting the bit B in its router-LSA. Being an ABR, R3 can only consider summary-LSAs from the backbone when building the routing table (according to section 16.2 of [Ref1]), so it will not have any inter-area routes in its routing table, but only intra-area routes from both Area 1 and Area 2. Consequently, according to section 12.4.3 of [Ref1], R3 will originate into Areas 1 and 2 only summary-LSAs covering destinations in the directly attached areas, i.e., in Area 2---the summary-LSAs for Area 1, and in Area 1---the summary-LSAs for Area 2.

Zinin, et al.                Informational                      [Page 2]

RFC 3509                   OSPF ABR Behavior                  April 2003

Zinin, et al. Informational [Page 2] RFC 3509 OSPF ABR Behavior April 2003

   At the same time, router R2, as an ABR connected to the backbone,
   will inject into Area 2 summary-LSAs describing the destinations in
   Area 0 (the backbone), Area 1 and other areas reachable through the
   backbone.

At the same time, router R2, as an ABR connected to the backbone, will inject into Area 2 summary-LSAs describing the destinations in Area 0 (the backbone), Area 1 and other areas reachable through the backbone.

   This results in a situation where internal router R4 calculates its
   routes to destinations in the backbone and areas other than Area 1
   via R2.  The topology of Area 2 itself can be such that the best path
   from R4 to R2 is via R3, so all traffic destined for the backbone and
   backbone-attached areas goes through R3.  Router R3 in turn, having
   only intra-area routes for areas 1 and 2, will drop all traffic not
   destined for the areas directly attached to it.  The same problem can
   occur when a backbone-connected ABR loses all of its adjacencies in
   the backbone---even if there are other normally functioning ABRs in
   the attached areas, all traffic going to the backbone (destined for
   it or for other areas) will be dropped.

This results in a situation where internal router R4 calculates its routes to destinations in the backbone and areas other than Area 1 via R2. The topology of Area 2 itself can be such that the best path from R4 to R2 is via R3, so all traffic destined for the backbone and backbone-attached areas goes through R3. Router R3 in turn, having only intra-area routes for areas 1 and 2, will drop all traffic not destined for the areas directly attached to it. The same problem can occur when a backbone-connected ABR loses all of its adjacencies in the backbone---even if there are other normally functioning ABRs in the attached areas, all traffic going to the backbone (destined for it or for other areas) will be dropped.

   In a standard OSPF implementation this situation can be remedied by
   use of Virtual Links (see section 15 of [Ref1] for more details).  In
   this case, router R3 will have a virtual backbone connection, will
   form an adjacency over it, will receive all LSAs directly from a
   backbone-attached router (R1 or R2, or both in our example) and will
   install intra- or inter-area routes.

In a standard OSPF implementation this situation can be remedied by use of Virtual Links (see section 15 of [Ref1] for more details). In this case, router R3 will have a virtual backbone connection, will form an adjacency over it, will receive all LSAs directly from a backbone-attached router (R1 or R2, or both in our example) and will install intra- or inter-area routes.

   While being an unavoidable technique for repairing a partitioned
   backbone area, the use of virtual links in the described situation
   adds extra configuration headaches and system traffic overhead.

While being an unavoidable technique for repairing a partitioned backbone area, the use of virtual links in the described situation adds extra configuration headaches and system traffic overhead.

   Another situation where standard ABR behavior does not provide
   acceptable results is when it is necessary to provide redundant
   connectivity to an ASBR via several different OSPF areas.  This would
   allow a provider to aggregate all their customers connecting through
   a single access point into one area while still offering a redundant
   connection through another access point in a different area, as shown
   in Figure 2.

Another situation where standard ABR behavior does not provide acceptable results is when it is necessary to provide redundant connectivity to an ASBR via several different OSPF areas. This would allow a provider to aggregate all their customers connecting through a single access point into one area while still offering a redundant connection through another access point in a different area, as shown in Figure 2.

Zinin, et al.                Informational                      [Page 3]

RFC 3509                   OSPF ABR Behavior                  April 2003

Zinin, et al. Informational [Page 3] RFC 3509 OSPF ABR Behavior April 2003

                            .                .
                             .    Area 0    .
                              +--+      +--+
                            ..|R1|..  ..|R2|..
                           .  +--+  ..  +--+  .
                           .        ..        .
                           .        ..        .
                           . Area1  .. Area2  .
                           .        ..        .
                           .        ..        .
                           .       +--+       .
                            .......|R3|.......
                               ASBR+--+
                                   /..\
                                --+-  -+--
                                CN1    CNx

. . . Area 0 . +--+ +--+ ..|R1|.. ..|R2|.. . +--+ .. +--+ . . .. . . .. . . Area1 .. Area2 . . .. . . .. . . +--+ . .......|R3|....... ASBR+--+ /..\ --+- -+-- CN1 CNx

                 Customer Networks (CN1--CNx) Advertised
                 as AS External or NSSA External Routes

Customer Networks (CN1--CNx) Advertised as AS External or NSSA External Routes

                  Figure 2. Dual Homed Customer Router

Figure 2. Dual Homed Customer Router

   This technique is already used in a number of networks including one
   of a major provider.

This technique is already used in a number of networks including one of a major provider.

   The next section describes alternative ABR behaviors, implemented in
   Cisco and IBM routers.  The changes are in the ABR definition and
   inter-area route calculation.  Any other parts of standard OSPF are
   not changed.

The next section describes alternative ABR behaviors, implemented in Cisco and IBM routers. The changes are in the ABR definition and inter-area route calculation. Any other parts of standard OSPF are not changed.

   These solutions are targeted to the situation when an ABR has no
   backbone connection.  They imply that a router connected to multiple
   areas without a backbone connection is not an ABR and should function
   as a router internal to every attached area.  This solution emulates
   a situation where separate OSPF processes are run for each area and
   supply routes to the routing table.  It remedies the situation
   described in the examples above by not dropping transit traffic.
   Note that a router following it does not function as a real border
   router---it doesn't originate summary-LSAs.  Nevertheless such a
   behavior may be desirable in certain situations.

These solutions are targeted to the situation when an ABR has no backbone connection. They imply that a router connected to multiple areas without a backbone connection is not an ABR and should function as a router internal to every attached area. This solution emulates a situation where separate OSPF processes are run for each area and supply routes to the routing table. It remedies the situation described in the examples above by not dropping transit traffic. Note that a router following it does not function as a real border router---it doesn't originate summary-LSAs. Nevertheless such a behavior may be desirable in certain situations.

   Note that the proposed solutions do not obviate the need of virtual
   link configuration in case an area has no physical backbone
   connection at all.  The methods described here improve the behavior
   of a router connecting two or more backbone-attached areas.

Note that the proposed solutions do not obviate the need of virtual link configuration in case an area has no physical backbone connection at all. The methods described here improve the behavior of a router connecting two or more backbone-attached areas.

Zinin, et al.                Informational                      [Page 4]

RFC 3509                   OSPF ABR Behavior                  April 2003

Zinin, et al. Informational [Page 4] RFC 3509 OSPF ABR Behavior April 2003

2 Changes to ABR Behavior

2 Changes to ABR Behavior

2.1 Definitions

2.1 Definitions

   The following definitions will be used in this document to describe
   the new ABR behaviors:

The following definitions will be used in this document to describe the new ABR behaviors:

   Configured area:
      An area is considered configured if the router has at least one
      interface in any state assigned to that area.

Configured area: An area is considered configured if the router has at least one interface in any state assigned to that area.

   Actively Attached area:
      An area is considered actively attached if the router has at least
      one interface in that area in the state other than Down.

Actively Attached area: An area is considered actively attached if the router has at least one interface in that area in the state other than Down.

   Active Backbone Connection:
      A router is considered to have an active backbone connection if
      the backbone area is actively attached and there is at least one
      fully adjacent neighbor in it.

Active Backbone Connection: A router is considered to have an active backbone connection if the backbone area is actively attached and there is at least one fully adjacent neighbor in it.

   Area Border Router (ABR):

Area Border Router (ABR):

      Cisco Systems Interpretation:
         A router is considered to be an ABR if it has more than one
         area Actively Attached and one of them is the backbone area.

Cisco Systems Interpretation: A router is considered to be an ABR if it has more than one area Actively Attached and one of them is the backbone area.

      IBM Interpretation:
         A router is considered to be an ABR if it has more than one
         Actively Attached area and the backbone area Configured.

IBM Interpretation: A router is considered to be an ABR if it has more than one Actively Attached area and the backbone area Configured.

2.2 Implementation Details

2.2 Implementation Details

   The following changes are made to the base OSPF, described in [Ref1]:

The following changes are made to the base OSPF, described in [Ref1]:

   1.  The algorithm for Type 1 LSA (router-LSA) origination is changed
       to prevent a multi-area connected router from identifying itself
       as an ABR by the bit B (as described in section 12.4.1 of [Ref1])
       until it considers itself as an ABR according to the definitions
       given in section 2.1.

1. The algorithm for Type 1 LSA (router-LSA) origination is changed to prevent a multi-area connected router from identifying itself as an ABR by the bit B (as described in section 12.4.1 of [Ref1]) until it considers itself as an ABR according to the definitions given in section 2.1.

   2.  The algorithm for the routing table calculation is changed to
       allow the router to consider the summary-LSAs from all attached
       areas if it is not an ABR, but has more than one attached area,
       or it does not have an Active Backbone Connection.  Definitions
       of the terms used in this paragraph are given in section 2.1.

2. The algorithm for the routing table calculation is changed to allow the router to consider the summary-LSAs from all attached areas if it is not an ABR, but has more than one attached area, or it does not have an Active Backbone Connection. Definitions of the terms used in this paragraph are given in section 2.1.

Zinin, et al.                Informational                      [Page 5]

RFC 3509                   OSPF ABR Behavior                  April 2003

Zinin, et al. Informational [Page 5] RFC 3509 OSPF ABR Behavior April 2003

       So, the paragraph 1 of section 16.2 of [Ref1] should be
       interpreted as follows:

So, the paragraph 1 of section 16.2 of [Ref1] should be interpreted as follows:

       "The inter-area routes are calculated by examining summary-LSAs.
       If the router is an ABR and has an Active Backbone Connection,
       only backbone summary-LSAs are examined.  Otherwise (either the
       router is not an ABR or it has no Active Backbone Connection),
       the router should consider summary-LSAs from all Actively
       Attached areas..."

"The inter-area routes are calculated by examining summary-LSAs. If the router is an ABR and has an Active Backbone Connection, only backbone summary-LSAs are examined. Otherwise (either the router is not an ABR or it has no Active Backbone Connection), the router should consider summary-LSAs from all Actively Attached areas..."

   3.  For Cisco ABR approach, the algorithm for the summary-LSAs
       origination is changed to prevent loops of summary-LSAs in
       situations where the router considers itself an ABR but doesn't
       have an Active Backbone Connection (and, consequently, examines
       summaries from all attached areas).  The algorithm is changed to
       allow an ABR to announce only intra-area routes in such a
       situation.

3. For Cisco ABR approach, the algorithm for the summary-LSAs origination is changed to prevent loops of summary-LSAs in situations where the router considers itself an ABR but doesn't have an Active Backbone Connection (and, consequently, examines summaries from all attached areas). The algorithm is changed to allow an ABR to announce only intra-area routes in such a situation.

       So, the paragraph 2 of subsection 12.4.3 of [Ref1] should be
       interpreted as follows:

So, the paragraph 2 of subsection 12.4.3 of [Ref1] should be interpreted as follows:

       "Summary-LSAs are originated by area border routers.  The precise
       summary routes to advertise into an area are determined by
       examining the routing table structure (see Section 11) in
       accordance with the algorithm described below.  Note that while
       only intra-area routes are advertised into the backbone, if the
       router has an Active Backbone Connection, both intra-area and
       inter-area routes are advertised into the other areas; otherwise,
       the router only advertises intra-area routes into non-backbone
       areas."

"Summary-LSAs are originated by area border routers. The precise summary routes to advertise into an area are determined by examining the routing table structure (see Section 11) in accordance with the algorithm described below. Note that while only intra-area routes are advertised into the backbone, if the router has an Active Backbone Connection, both intra-area and inter-area routes are advertised into the other areas; otherwise, the router only advertises intra-area routes into non-backbone areas."

       For this policy to be applied we change steps 6 and 7 in the
       summary origination algorithm to be as follows:

For this policy to be applied we change steps 6 and 7 in the summary origination algorithm to be as follows:

       Step 6:

Step 6:

          "Else, if the destination of this route is an AS boundary
          router, a summary-LSA should be originated if and only if the
          routing table entry describes the preferred path to the AS
          boundary router (see Step 3 of Section 16.4).  If so, a Type 4
          summary-LSA is originated for the destination, with Link State
          ID equal to the AS boundary router's Router ID and metric
          equal to the routing table entry's cost.  If the ABR
          performing this algorithm does not have an Active Backbone
          Connection, it can originate Type 4 summary-LSA only if the
          type of the route to the ASBR is intra-area.  Note: Type 4
          summary-LSAs should not be generated if Area A has been
          configured as a stub area."

"Else, if the destination of this route is an AS boundary router, a summary-LSA should be originated if and only if the routing table entry describes the preferred path to the AS boundary router (see Step 3 of Section 16.4). If so, a Type 4 summary-LSA is originated for the destination, with Link State ID equal to the AS boundary router's Router ID and metric equal to the routing table entry's cost. If the ABR performing this algorithm does not have an Active Backbone Connection, it can originate Type 4 summary-LSA only if the type of the route to the ASBR is intra-area. Note: Type 4 summary-LSAs should not be generated if Area A has been configured as a stub area."

Zinin, et al.                Informational                      [Page 6]

RFC 3509                   OSPF ABR Behavior                  April 2003

Zinin, et al. Informational [Page 6] RFC 3509 OSPF ABR Behavior April 2003

       Step 7:

Step 7:

          "Else, the Destination type is network.  If this is an
          inter-area route and the ABR performing this algorithm has an
          Active Backbone Connection, generate a Type 3 summary-LSA for
          the destination, with Link State ID equal to the network's
          address (if necessary, the Link State ID can also have one or
          more of the network's host bits set; see Appendix E for
          details) and metric equal to the routing table cost."

"Else, the Destination type is network. If this is an inter-area route and the ABR performing this algorithm has an Active Backbone Connection, generate a Type 3 summary-LSA for the destination, with Link State ID equal to the network's address (if necessary, the Link State ID can also have one or more of the network's host bits set; see Appendix E for details) and metric equal to the routing table cost."

   The changes in the ABR behavior described in this section allow a
   multi-area connected router to successfully route traffic destined
   for the backbone and other areas.  Note that if the router does not
   have a backbone area Configured it does not actively attract
   inter-area traffic, because it does not consider itself an ABR and
   does not originate summary-LSAs.  It still can forward traffic from
   one attached area to another along intra-area routes in case other
   routers in corresponding areas have the best inter-area paths over
   it, as described in section 1.2.

The changes in the ABR behavior described in this section allow a multi-area connected router to successfully route traffic destined for the backbone and other areas. Note that if the router does not have a backbone area Configured it does not actively attract inter-area traffic, because it does not consider itself an ABR and does not originate summary-LSAs. It still can forward traffic from one attached area to another along intra-area routes in case other routers in corresponding areas have the best inter-area paths over it, as described in section 1.2.

   By processing all summaries when the backbone is not active, we
   prevent the ABR, which has just lost its last backbone adjacency,
   from dropping any packets going through the ABR in question to
   another ABR and destined towards the backbone or other areas not
   connected to the ABR directly.

By processing all summaries when the backbone is not active, we prevent the ABR, which has just lost its last backbone adjacency, from dropping any packets going through the ABR in question to another ABR and destined towards the backbone or other areas not connected to the ABR directly.

3 Virtual Link Treatment

3 Virtual Link Treatment

   The Cisco ABR approach described in this document requires an ABR to
   have at least one active interface in the backbone area.  This
   requirement may cause problems with virtual links in those rare
   situations where the backbone area is purely virtual, as shown in
   Figure 3, and the state of the VL is determined as in [Ref1].

The Cisco ABR approach described in this document requires an ABR to have at least one active interface in the backbone area. This requirement may cause problems with virtual links in those rare situations where the backbone area is purely virtual, as shown in Figure 3, and the state of the VL is determined as in [Ref1].

                     .......    ...........    ......
                            .  .           .  .
                            +--+    VL     +--+
                            |R1|***********|R2|
                            +--+           +--+
                     Area 1 .  .  Area 2   .  . Area 3
                     .......    ...........    ......

....... ........... ...... . . . . +--+ VL +--+ |R1|***********|R2| +--+ +--+ Area 1 . . Area 2 . . Area 3 ....... ........... ......

                        Figure 3. Purely Virtual Backbone

Figure 3. Purely Virtual Backbone

   If R1 and R2 treat virtual links as in [Ref1], their virtual links
   will never go up, because their router-LSAs do not contain the B-bit,
   which is, in turn, because the routers do not have active interfaces
   (virtual links) in the backbone and do not consider themselves ABRs.

If R1 and R2 treat virtual links as in [Ref1], their virtual links will never go up, because their router-LSAs do not contain the B-bit, which is, in turn, because the routers do not have active interfaces (virtual links) in the backbone and do not consider themselves ABRs.

Zinin, et al.                Informational                      [Page 7]

RFC 3509                   OSPF ABR Behavior                  April 2003

Zinin, et al. Informational [Page 7] RFC 3509 OSPF ABR Behavior April 2003

   Note that this problem does not appear if one of the routers has a
   real interface in the backbone, as it usually is in real networks.

Note that this problem does not appear if one of the routers has a real interface in the backbone, as it usually is in real networks.

   Though the situation described is deemed to be rather rare,
   implementations supporting Cisco ABR behavior may consider changing
   VL-specific code so that a virtual link is reported up (an
   InterfaceUp event is generated) when a router with corresponding
   router-ID is seen via Dijkstra, no matter whether its router-LSA
   indicates that it is an ABR or not.  This means that checking of
   configured virtual links should be done not in step 4 of the
   algorithm in 16.1 of [Ref1] when a router routing entry is added, but
   every time a vertex is added to the SPT in step 3 of the same
   algorithm.

Though the situation described is deemed to be rather rare, implementations supporting Cisco ABR behavior may consider changing VL-specific code so that a virtual link is reported up (an InterfaceUp event is generated) when a router with corresponding router-ID is seen via Dijkstra, no matter whether its router-LSA indicates that it is an ABR or not. This means that checking of configured virtual links should be done not in step 4 of the algorithm in 16.1 of [Ref1] when a router routing entry is added, but every time a vertex is added to the SPT in step 3 of the same algorithm.

4 Compatibility

4 Compatibility

   The changes of the OSPF ABR operations do not influence any aspects
   of the router-to-router cooperation and do not create routing loops,
   and hence are fully compatible with standard OSPF.  Proof of
   compatibility is outside the scope of this document.

The changes of the OSPF ABR operations do not influence any aspects of the router-to-router cooperation and do not create routing loops, and hence are fully compatible with standard OSPF. Proof of compatibility is outside the scope of this document.

5 Deployment Considerations

5 Deployment Considerations

   This section discusses the deployments details of the ABR behaviors
   described in this document.  Note that this approach is fully
   compatible with standard ABR behavior, so ABRs acting as described in
   [Ref1] and in this document can coexist in an OSPF domain and will
   function without problems.

This section discusses the deployments details of the ABR behaviors described in this document. Note that this approach is fully compatible with standard ABR behavior, so ABRs acting as described in [Ref1] and in this document can coexist in an OSPF domain and will function without problems.

   Deployment of ABRs using the alternative methods improves the
   behavior of a router connected to multiple areas without a backbone
   attachment, but can lead to unexpected routing asymmetry, as
   described below.

Deployment of ABRs using the alternative methods improves the behavior of a router connected to multiple areas without a backbone attachment, but can lead to unexpected routing asymmetry, as described below.

   Consider an OSPF domain depicted in Figure 4.

Consider an OSPF domain depicted in Figure 4.

Zinin, et al.                Informational                      [Page 8]

RFC 3509                   OSPF ABR Behavior                  April 2003

Zinin, et al. Informational [Page 8] RFC 3509 OSPF ABR Behavior April 2003

                      .        Backbone         .
                     .                           .
                     .   ---------------------   .
                      .   |1               1|   .
                       ..+--+.............+--+..
                       ..|R1|.....    ....|R4|..
                      .  +--+     .  .    +--+  .
                      .   1|      .  .     /4   .
                      .    |    8 +--+ 4  /     .
                      .    |    +-|R3|---+      .
                      .   1|   /  +--+\4        .
                      .  +--+ /   .  . \ 4 +--+ .
                      .  |R2|/8   .  .  +--|R5| .
                      .  +--+     .  .     +--+ .
                      .   |       .  .       |  .
                      . --------- .  . -------- .
                      .   net N   .  .  net M   .
                      .           .  .          .
                      .  Area 1   .  .  Area 2  .
                       ...........    ..........

. Backbone . . . . --------------------- . . |1 1| . ..+--+.............+--+.. ..|R1|..... ....|R4|.. . +--+ . . +--+ . . 1| . . /4 . . | 8 +--+ 4 / . . | +-|R3|---+ . . 1| / +--+\4 . . +--+ / . . \ 4 +--+ . . |R2|/8 . . +--|R5| . . +--+ . . +--+ . . | . . | . . --------- . . -------- . . net N . . net M . . . . . . Area 1 . . Area 2 . ........... ..........

                  Figure 4. Inter-area routing asymmetry

Figure 4. Inter-area routing asymmetry

   Assume that R3 uses the approach described in this document.  In this
   case R2 will have inter-area routes to network M via ABR R1 only.  R5
   in turn will have its inter-area route to network N via R4, but as
   far as R4 is only reachable via R3, all traffic destined to network N
   will pass through R3.  R3 will have an intra-area route to network N
   via R2 and will, of course, route it directly to it (because
   intra-area routes are always preferred over inter-area ones).
   Traffic going back from network N to network M will pass through R2
   and will be routed to R1, as R2 will not have any inter-area routes
   via R3.  So, traffic from N to M will always go through the backbone
   while traffic from M to N will cross the areas directly via R3 and,
   in this example, will not use a more optimal path through the
   backbone.

Assume that R3 uses the approach described in this document. In this case R2 will have inter-area routes to network M via ABR R1 only. R5 in turn will have its inter-area route to network N via R4, but as far as R4 is only reachable via R3, all traffic destined to network N will pass through R3. R3 will have an intra-area route to network N via R2 and will, of course, route it directly to it (because intra-area routes are always preferred over inter-area ones). Traffic going back from network N to network M will pass through R2 and will be routed to R1, as R2 will not have any inter-area routes via R3. So, traffic from N to M will always go through the backbone while traffic from M to N will cross the areas directly via R3 and, in this example, will not use a more optimal path through the backbone.

   Note that this problem is not caused by the fact that R3 uses the
   alternative approach.  The reason for attracting the attention to it
   is that R3 is not really functioning as an ABR in case this new
   behavior is used, i.e., it does not inject summary-LSAs into the
   attached areas, but inter-area traffic can still go through it.

Note that this problem is not caused by the fact that R3 uses the alternative approach. The reason for attracting the attention to it is that R3 is not really functioning as an ABR in case this new behavior is used, i.e., it does not inject summary-LSAs into the attached areas, but inter-area traffic can still go through it.

6 Security Considerations

6 Security Considerations

   The alternative ABR behaviors specified in this document do not raise
   any security issues that are not already covered in [Ref1].

The alternative ABR behaviors specified in this document do not raise any security issues that are not already covered in [Ref1].

Zinin, et al.                Informational                      [Page 9]

RFC 3509                   OSPF ABR Behavior                  April 2003

Zinin, et al. Informational [Page 9] RFC 3509 OSPF ABR Behavior April 2003

7 Acknowledgements

7 Acknowledgements

   Authors would like to thank Alvaro Retana, Russ White, and Liem
   Nguyen for their review of the document.

Authors would like to thank Alvaro Retana, Russ White, and Liem Nguyen for their review of the document.

8 Disclaimer

8 Disclaimer

   This document describes OSPF ABR implementations of respective
   vendors "as is", only for informational purposes, and without any
   warranties, guarantees or support.  These implementations are subject
   to possible future changes.  For the purposes of easier deployment,
   information about software versions where described behavior was
   integrated is provided below.

This document describes OSPF ABR implementations of respective vendors "as is", only for informational purposes, and without any warranties, guarantees or support. These implementations are subject to possible future changes. For the purposes of easier deployment, information about software versions where described behavior was integrated is provided below.

   Initial Cisco ABR implementation (slightly different from the one
   described in this memo, requiring non-backbone areas to be
   configured, and not necessarily actively attached in the ABR
   definition) was introduced in Cisco IOS (tm) version 11.1(6).  Cisco
   ABR behavior described in this document was integrated in Cisco IOS
   (tm) in version 12.1(3)T.

Initial Cisco ABR implementation (slightly different from the one described in this memo, requiring non-backbone areas to be configured, and not necessarily actively attached in the ABR definition) was introduced in Cisco IOS (tm) version 11.1(6). Cisco ABR behavior described in this document was integrated in Cisco IOS (tm) in version 12.1(3)T.

   The ABR behavior described as IBM ABR approach was implemented by IBM
   in IBM Nways Multiprotocol Routing Services (MRS) 3.3.

The ABR behavior described as IBM ABR approach was implemented by IBM in IBM Nways Multiprotocol Routing Services (MRS) 3.3.

   Note that the authors do not intend to keep this document in sync
   with actual implementations.

Note that the authors do not intend to keep this document in sync with actual implementations.

10 References

10 References

   [Ref1] Moy, J., "OSPF version 2", STD 54, RFC 2328, April 1998.

[Ref1] Moy, J., "OSPF version 2", STD 54, RFC 2328, April 1998.

Zinin, et al.                Informational                     [Page 10]

RFC 3509                   OSPF ABR Behavior                  April 2003

Zinin, et al. Informational [Page 10] RFC 3509 OSPF ABR Behavior April 2003

11 Authors' Addresses

11 Authors' Addresses

   Alex Zinin
   Alcatel

Alex Zinin Alcatel

   EMail: zinin@psg.com

EMail: zinin@psg.com

   Derek M. Yeung
   Procket Networks
   1100 Cadillac Ct
   Milpitas, CA 95035

Derek M. Yeung Procket Networks 1100 Cadillac Ct Milpitas, CA 95035

   Phone: 408-635-7911
   EMail: myeung@procket.com

Phone: 408-635-7911 EMail: myeung@procket.com

   Acee Lindem
   Redback Networks
   102 Carric Bend Court
   Cary, NC 27519 USA

Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519 USA

   Phone: 919-387-6971
   EMail: acee@redback.com

Phone: 919-387-6971 EMail: acee@redback.com

Zinin, et al.                Informational                     [Page 11]

RFC 3509                   OSPF ABR Behavior                  April 2003

Zinin, et al. Informational [Page 11] RFC 3509 OSPF ABR Behavior April 2003

12  Full Copyright Statement

12 Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Funding for the RFC Editor function is currently provided by the Internet Society.

Zinin, et al.                Informational                     [Page 12]

Zinin, et al. Informational [Page 12]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

位置情報・GPS情報の取得方法

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る