Subject: Re: OSPF ASBR Path Selection

From: "Jeyanath Minto J - CTD, Chennai." <[email-masked]>
Date: Thu, 17 Oct 2002 19:39:00 +0530

Hi Acee ,

      it seems we never have both inter-area path and intra-area backbone
path to a ASBR.
 so below rule is unnecessary.

Excerpted from RFC 16.4.1

"
             o   The other paths, intra-area backbone paths and inter-
                 area paths, are of equal preference.
"

Minto

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]]
Sent: Thursday, October 17, 2002 2:30 AM
To: [email-masked]
Subject: OSPF ASBR Path Selection

As a piece of unfinished business, Alex Zinin asked that I
review a question regarding ASBR path selection when an external prefix
is advertised through an ASBR accessible via multiple areas. The crux of
the issue is whether RFC 2328 section 16.2(6) and section 16.4.1 conflict
with one another and can result in a routing loop. A link to
one of the E-mails on the subject is included below:

<http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind9912&L=OSPF&P=R3674&I
=-3>

Excerpted from RFC 16.2

         (6) Else, if the paths present in the table are intra-area
             paths, do nothing with the LSA (intra-area paths are always
             preferred).

Excerpted from RFC 16.4.1

             When multiple intra-AS paths are available to
             ASBRs/forwarding addresses, the following rules indicate
             which paths are preferred. These rules apply when the same
             ASBR is reachable through multiple areas, or when trying to
             decide which of several AS-external-LSAs should be
             preferred. In the former case the paths all terminate at the
             same ASBR, while in the latter the paths terminate at
             separate ASBRs/forwarding addresses. In either case, each
             path is represented by a separate routing table entry as
             defined in Section 11.

             This section only applies when RFC1583Compatibility is set
             to "disabled".

             The path preference rules, stated from highest to lowest
             preference, are as follows. Note that as a result of these
             rules, there may still be multiple paths of the highest
             preference. In this case, the path to use must be determined
             based on cost, as described in Section 16.4.

             o   Intra-area paths using non-backbone areas are always the
                 most preferred.

             o   The other paths, intra-area backbone paths and inter-
                 area paths, are of equal preference.

I've looked at this and my opinion is that while RFC 2328
could be more explicit, there is no problem. The reason is that
section 16.2 (5) explicitly specifies that for a router route you must
look up the routing table entry associated with the area whose summaries
you are examining. Hence, the rule in (6) only applies to an intra-area
path through the same area as the inter-area path.

Excerpted from RFC 2328 Section 16.2:

         (5) Next, look up the routing table entry for the destination N.
             (If N is an AS boundary router, look up the "router" routing
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             table entry associated with Area A).  If no entry exists for
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             N or if the entry's path type is "type 1 external" or "type
             2 external", then install the inter-area path to N, with
             associated area Area A, cost IAC, next hop equal to the list
             of next hops to router BR, and Advertising router equal to
             BR.

Are there any implementations that calculate a single ASBR route (vis-a-vis
one per area) and strictly prefer an intra-area path over an inter-area path
(independent of the corresponding areas)?

Thanks,
--
Acee

---

From: Acee Lindem <[email-masked]>
Date: Thu, 17 Oct 2002 11:12:29 -0400

>                  area paths, are of equal preference.

Hi Minto,

You are correct for a single ASBR. However, the same prefix may be

advertisd by multiple ABRs. RFC 2178 (obsoleted by RFC 2328) contains
the best description of the problem (excerpted below):

G.7 Advertising same external route from multiple areas

   This document fixes routing loops which can occur in RFC 1583 when
   the same external destination is advertised by AS boundary routers in
   separate areas. There are two manifestations of this problem. The
   first, discovered by Dennis Ferguson, occurs when an aggregated
   forwarding address is in use. In this case, the desirability of the
   forwarding address can change for the worse as a packet crosses an
   area aggregation boundary on the way to the forwarding address, which
   in turn can cause the preference of AS-external-LSAs to change,
   resulting in a routing loop.

   The second manifestation was discovered by Richard Woundy. It is
   caused by an incomplete application of OSPF's preference of intra-
   area routes over inter-area routes: paths to any given
   ASBR/forwarding address are selected first based on intra-area
   preference, while the comparison between separate ASBRs/forwarding
   addresses is driven only by cost, ignoring intra-area preference. His
   example is replicated in Figure 19.  Both router A3 and router B3 are
   originating an AS-external-LSA for 10.0.0.0/8, with the same type 2
   metric. Router A1 selects B1 as its next hop towards 10.0.0.0/8,
   based on shorter cost to ASBR B3 (via B1->B2->B3). However, the
   shorter route to B3 is not available to B1, due to B1's preference
   for the (higher cost) intra-area route to B3 through Area A. This
   leads B1 to select A1 as its next hop to 10.0.0.0/8, resulting in a
   routing loop.

   The following two changes have been made to prevent these routing
   loops:

   o   When originating a type 3 summary-LSA for a configured area
       address range, the cost of the summary-LSA is now set to the
       maximum cost of the range's component networks (instead of the
       previous algorithm which set the cost to the minimum component
       cost).  This change affects Sections 3.5 and 12.4.3, Figures 7
       and 8, and Tables 6 and 13.

   o   The preference rules for choosing among multiple AS-
       external-LSAs have been changed. Where previously cost was the
       only determining factor, now the preference is driven first by
       type of path (intra-area or inter-area, through non-backbone area
       or through backbone) to the ASBR/forwarding address, using cost
       only to break ties. This change affects Sections 16.4 and 16.4.1.

   After implementing this change, the example in Figure 19 is modified
   as follows. Router A1 now chooses A3 as the next

                              10.0.0.0/8
                              ----------
                                   |
                                +----+
                                | XX |
                                +----+
                   RIP          /    \        RIP
           ---------------------      --------------------
           !                                             !
           !                                             !
         +----+      +----+       1       +----+......+----+....
         | A3 |------| A1 |---------------| B1 |------| B3 |   .
         +----+   6  +----+               +----+  8   +----+   .
                                           1|  .         /     .
                       OSPF backbone        |  .        /      .
                                          +----+  2    /       .
                                          | B2 |-------  Area A.
                                          +----+................

                Figure 19: Example routing loop when the
            same external route is advertised from multiple
                                 areas

   hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The reason for
   both choices is that ASBRs/forwarding addresses are now chosen based
   first on intra-area preference, and then by cost.

   Unfortunately, this change is not backward compatible. While the
   change prevents routing loops when all routers run the new preference
   rules, it can actually create routing loops when some routers are
   running the new preference rules and other routers implement RFC
   1583.  For this reason, a new configuration parameter has been added:
   RFC1583Compatibility. Only when RFC1583Compatibility is set to
   "disabled" will the new preference rules take effect. See Appendix C
   for more details.

--
Acee