Subject: Re: NSSA Problem

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Thu, 8 Aug 2002 16:30:32 -0700

Amit,

>            I can understand the point mentioned in
>RFC 2328 about the forwarding address but in this case
>I am not able to appreciate the MUST condition the
>RFC(with Exception when u start aggregating multiple
>routes).

It is true that type 7 LSAs that are aggregated into a single
Type 5 LSA with a 0.0.0.0 forwarding address do not need a
computed forwarding address. But usually an NSSA's ASBR has no
way of knowing whether or not its self-originated Type-7 LSAs
are aggregated by the NSSA's ABRs during translation. Without
providing configuration to the contrary, the NSSA's ASBRs MUST
assume their Type 7 LSAs (with the P-bit set) will not be
aggregated during translation and therefore MUST compute a
non-zero forwarding address.

I don't see much value in complicating the NSSA spec by
softening this requirement for Type 7 range aggregations or
for the case of an NSSA with just a single ABR. Its hard to
imagine any IPv4 application where the forwarding address
cannot be set (IPv6ers care to jump in???). Note that when the
P-bit is clear, the new NSSA spec does allow a Type 7 LSA to
have a 0.0.0.0 forwarding address.

>An ABR for an NSSA does not generate type 4 summaries for
>ASBRs within the NSSA.

This is because all type 5 LSA translations of type 7 LSAs are
originated by NSSA ABRs, not NSSA ASBRs.

>Hence a forwarding address is
>required to compute the best path to the prefix
>advertised in the translated LSA.

If the NSSA's ABR translators used a 0.0.0.0 forwarding
address in their Type 5 LSA translations, these Type 5 LSA
translations would cause packets to be forwarded directly
through their originating ABR rather than via a potentially
more preferred path through a different NSSA ABR. Note that
this is always the case when type 7 ranges aggregate Type 7
LSAs into a Type 5 LSA with a 0.0.0.0 forwarding address.

Pat

---

From: Amit Srivastava <[email-masked]>
Date: Thu, 8 Aug 2002 21:32:47 -0700

Hi Pat and Acee,
      See even if the forwarding address is not set in
the originating AS-external LSA(in the NSSA) the ABR
can know about the router which has originated the LSA
by its router id. So why they are imphasising on
setting of the forwarding address!!
I am still in the same state of confision plz help!!
Regards
Amit

> LSAs into a Type 5 LSA with a 0.0.0.0 forwarding

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

---

From: Acee Lindem <[email-masked]>
Date: Fri, 9 Aug 2002 12:55:02 -0400

Amit,

If the NSSA has multiple ABRs and there is no forwarding
address, routers outside the NSSA will always go through
the translating ABR independent of whether or not it
is the shortest path.

Thanks,
Acee

>>>RFC 2328 about the forwarding address but in this
>>>
>>case
>>
>>>RFC(with Exception when u start aggregating
>>>
>>multiple
>>
>>>routes).
>>>
>>>An ABR for an NSSA does not generate type 4
>>>
>>summaries for
>>
>>>ASBRs within the NSSA.
>>>

--
Acee

---

From: Amit Srivastava <[email-masked]>
Date: Sun, 11 Aug 2002 21:11:46 -0700

Hi Acee,
      I am sorry but i would not agree to your comment
See when multiple ABRs are there each of them would
have given router LSA in both the Area and when it
gets an AS-External LSA it can simply send the LSA to
other Area and will also give summary LSA(Type 4) for
the LSA. Now the router who will receive this LSA
would just do the SPF calculate the shortest ABR and
forward the packet to that ABR.
        That is why i am not able to appriciate the
Must condition of having forwarding address in the
type 7 LSAs.
Regards
Amit

--- Acee Lindem <[email-masked]> wrote:
> >>It is true that type 7 LSAs that are aggregated
> into
> >>a single
> >>Type 5 LSA with a 0.0.0.0 forwarding address do
> not
> >>need a
> >>providing configuration to the contrary, the
> NSSA's
> >>ASBRs MUST
> >>I don't see much value in complicating the NSSA
> spec
> >>by
> >>for the case of an NSSA with just a single ABR.
> Its
> >>hard to
> >>P-bit is clear, the new NSSA spec does allow a
> Type
> >>7 LSA to
> >>This is because all type 5 LSA translations of
> type
> >>7 LSAs are
> >>address in their Type 5 LSA translations, these
> Type
> >>5 LSA
> >>this is always the case when type 7 ranges
> aggregate
> >>Type 7

---

From: Amit Srivastava <[email-masked]>
Date: Tue, 13 Aug 2002 04:43:19 -0700

Hi All,
   I have a major doubt regarding the database
overflow.
If i follow the same approach as mentioned by the RFC
1765 is it becomes necessary that my database will be
identical in all the routers(i.e same LSAs in all the
router within the AS).
Actually i came across a scenario where your database
may not be identical even if you have the same
ospfExtLsdbLimit variable in all your router.
I don't know if it is a bug or is it a normal working
condition.
If any one know about it plz help
Regards
Amit

---

From: Acee Lindem <[email-masked]>
Date: Wed, 14 Aug 2002 09:50:07 -0400

Amit Srivastava wrote:

> the LSA.

Amit,

But an ABR for an NSSA does not generate type 4 summaries
for ASBRs originating type 7 LSAs within the NSSA. This
is clarified in section 2.3 of draft-ietf-ospf-nssa-update-11.txt.
This design point is consistent with the goal of isolating the
NSSA from the rest of the OSPF routing domain.

Thanks,
ACee

> Now the router who will receive this LSA
>>>      See even if the forwarding address is not
>>>
>>set in
>>
>>>the originating AS-external LSA(in the NSSA) the
>>>
>>ABR
>>
>>>can know about the router which has originated the
>>>
>>LSA
>>
>>>I am still in the same state of confision plz
>>>
>>help!!
>>
>>
>>Amit,
>>
>>>>>          I can understand the point mentioned
>>>>>
>>in
>>
>>>>>I am not able to appreciate the MUST condition
>>>>>
>>the
>>

--
Acee

---

From: Acee Lindem <[email-masked]>
Date: Wed, 14 Aug 2002 10:23:06 -0400

> If any one know about it plz help

Amit,
Sounds like a bug to me. Make sure you're not acknowledging
any LSAs that you drop due to reaching ospfExtLsdbLimit.

Good Luck,
Acee

--
Acee