Subject: [OSPF] ignoring self-originated type 3/5 LSAs when running SPF

From: Nischal Sheth <[email-masked]>
Date: Tue, 20 Jan 2009 19:34:05 -0800

and type 5 LSAs when running SPF.  According to item (2) in section 16.2
and item (2) in section 16.4 of the RFC, self-originated type 3 and type
5 LSAs are to be ignored when calculating inter-area and external routes.

Can someone explain the rationale behind these rules?  On the surface it
seems that following these rules, particularly for type 5 LSAs, causes
somewhat strange behavior wherein we add an OSPF route pointing to another
ASBR originating the route even though we ourselves are advertising the
same route.

Of course, these external routes typically never get into the FIB due to
the presence of the corresponding non-OSPF routes that are being advertised
into OSPF.  However, I am trying to understand why these routes should even
get added into the OSPF routing table with a next-hop pointing to another
ASBR.

Thanks,
Nischal

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Sengottuvelan Srirangan <[email-masked]>
Date: Tue, 20 Jan 2009 20:50:22 -0800 (PST)

---

From: Acee Lindem <[email-masked]>
Date: Wed, 21 Jan 2009 14:07:48 -0500

Your concern doesn't apply to type 3 summaries since that fact that  
you are advertising a summary into the backbone implies that you have  
an intra-area route in a non-backbone area - the intra-area route  
will be preferred over a summary from any other router. For ASE and  
NSSA prefixes, local RIB policy can be used to determine whether you  
want to prefer your redistributed route or an AS External or NSSA  
route learned via OSPF. If the OSPF AS external calculation enforced  
a strict "split-horizon" rule, you would not be able to do the latter.

Thanks,
Acee

On Jan 20, 2009, at 10:34 PM, Nischal Sheth wrote:

>
> I have a question about RFC 2328 w.r.t. ignoring self-originated  
> type 3

---

From: Nitin Kakkar <[email-masked]>
Date: Wed, 21 Jan 2009 11:26:57 -0800

Now lets say ospf use self originated lsa's and calculate paths, with incorrect path selection rule in rtm or fib, one can end up with routing loops. 
So what is the safest way to avoid such problems?

Again Remember destinations given by self originated T3 & T5 prefixes are not new, they are already available in control & forwarding domains, so we are not missing out on any route.

Hope this helps
Nitin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem
Sent: Wednesday, January 21, 2009 11:08 AM
To: Nischal Sheth
Cc: [email-masked]
Subject: Re: [OSPF] ignoring self-originated type 3/5 LSAs when running SPF

Hi Nischal,

Thanks,
Acee

---

From: Nischal Sheth <[email-masked]>
Date: Wed, 21 Jan 2009 11:37:46 -0800

> Hi Nischal,
> Your concern doesn't apply to type 3 summaries since that fact that you 
> are advertising a summary into the backbone implies that you have an 
> intra-area route in a non-backbone area - the intra-area route will be 
> preferred over a summary from any other router. For ASE and NSSA 
> prefixes, local RIB policy can be used to determine whether you want to 
> prefer your redistributed route or an AS External or NSSA route learned 
> via OSPF. If the OSPF AS external calculation enforced a strict 
> "split-horizon" rule, you would not be able to do the latter.
> 

Hi Acee,

Thanks for responding.  Your explanation w.r.t. the ASE and NSSA prefixes
makes sense.

-Nischal

---

From: Nischal Sheth <[email-masked]>
Date: Wed, 21 Jan 2009 12:10:18 -0800

> Nischal,
>   Another dimension for your thought process,
>   Think how does ospf originate T5 & T3 LSA's? 
>   Some other protocol (T5's ) or ospf from another area (T3's case), inside the box already have route to these destinations. Ospf is merely *relaying* this reach-ability information to its domain.
> 

Hi Nitin,

It appears to me that imposing a strict split-horizon rule in OSPF itself i.e.
do not install ASE/NSSA routes pointing to another ASBR if we are originating
the same prefix, would ensure that we don't get loops.

The rules specified in RFC 2328 provide you more flexibility, as Acee pointed
out.  However, you can create loops if local RIB policy is not configured 
correctly e.g. both ASBRs are configured to prefer the OSPF learnt route over
the redistributed route.  This seems to be a reasonable tradeoff.

Thanks,
Nischal