[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: NSSA support of parallel paths though ABR
From:       "Moy, John" <John.Moy () SYCAMORENET ! COM>
Date:       1999-08-19 20:25:59
[Download RAW message or body]


Sorry for the late reply to this old note,
but I just wanted to point out that the curious
load distribution caused by the NSSA was NOT due to
problems in the translation, but only in the tie-breakers
used in ABR1's routing calculation (which Pat is going
to fix in the next draft).

If ABR1 correctly installs paths to both ASBR1 and ASBR2,
you'll get a nice 50-50 load split even if a) only one ABR
translates and b) only a single translated type-5 is produced
for both type-7s together (which is in my opinion the correct
and most efficient behavior).

John

-----Original Message-----
From: Adrian Smith [mailto:adrian@MSN.BT.CO.UK]
Sent: Thursday, August 05, 1999 10:14 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: NSSA support of parallel paths though ABR


Hi,

We've been testing an OSPF design using NSSA and have discovered some
issues with the way the translation process not giving the parallel paths
we would expect to see.  Can someone comment on whether this is the
intended operation of the translation & path selection process - if so I
think there are topologies such as our where this is not the best solution.

The problem:

       (lan area 0)

        ABR1       ABR2

       (lan - NSSA)

        ASBR1      ASBR2

We want to load share for traffic from area 0 through both ABRs and also
over the lan to both ASBRs (both of them being onwards connected to the
same destination.)

We inject the same route into the two ASBRs within a single NSSA leaf area.
 These ASBRs are an equal distance from the two ABRs for the area.

If we don't use NSSA (i.e. normal Type 5 externals) an area 0 router which
is equal distance from the two ABRs would see two paths.  Each ABR would
also see two paths - one to each ASBR.  This works fine.

With NSSA, Type 7 externals are injected at the two ASBRs (each containing
a forwarding address of their internal loopback address).  Say ABR2 is the
translating router:
 - ABR2 generates only one T5 LSA for the two L7s (picking one of the T7s)
 - ABR2 installs 2 parallel paths to the dest (one via ASBR1, one via
ASBR2)
 - ABR1 has 2 T7 LSAs (from the NSSA area) and also one T5 LSA (as flooded
over area0)
 - ABR1 only installs one path to the destination - via one ASBR, say
ASBR2.  This being the one it has a T5 LSA for.

Hence we get 75% of traffic going through ASBR2 and 25% going through
ASBR1!


This is caused by: only one router tranlating, only one of the T7s being
translated into T5 and the ABR in the NSSA prefering T5 to T7 routes.  So:
 - should a translating ABR be allowed to translate two T7s into equivalent
T5s if each has the same prefix/mask, metric/metric type, but a different
forwarding address.  (If so then is a need to define what LSA ID to use for
each as they would both get the router ID of the translating router - one
would have to use the host bits?)
 - why does the tie-break for installing routes prefer T5 to T7?  (impacts
all non tranlating ABRs)

I know new NSSA draft allows multiple ABRs to translate - however I suspect
the current wording also suffers from an issue with T5 being preferred to
T7 and the ABR only translating installed T7 LSAs - does this not cause a
race between two ABRs as to which installs a T7 and hence generates a T5?
 Are there any implementations?

Comments appreciated,

--Adrian Smith, BT.

[prev in list] [next in list] [prev in thread] [next in thread]