Subject: Re: [OSPF] Functionally equivalent as-external lsa

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Sat, 15 Jul 2006 04:31:54 -0700 (PDT)

Chitra,

W.r.t.
          dummy    dummy

          SW(*)    SW(*)
           |       |
 +-----+   |       |   +-----+
 |     |   |       |   |     |
 |     +---+       +---+     |
 |     |               |     |
 |PSS9 +------ X ------|PSS11|
 +-----+               +-----+
 10.81.156.72          10.81.156.74
           3.3.3.0/24

  (*)dummy SW: only for up the Link of PSS9/PSS11.

 PSS9 and PSS11 both originate a functionally equivalent 
 external LSA for 3.3.3.0/24.

in summary neither PSS9 or PSS11's external LSA for prefix
3.3.3.0/24 is installed in PSS11's OSPF routing table. A path
external to OSPF, e.g. a static route or BGP advertisement,
controls the forwarding of packets destined to the prefix
3.3.3.0/24. Whenever PSS11 is originating its LSA, PSS9 should
flush its LSA and install PSS11's LSA as long as PSS11 is
reachable. When PSS9 and PSS11 are no longer reachable from
one another, PSS9 should remove PSS11's LSA from the OSPF
routing table and originate its own functionally equivalent
external LSA for the prefix 3.3.3.0/24, provided it still has
an imported path for it. PSS11's LSA may continue to live in
PSS9's LSDB until it age's out normally; but again, as with
PS11, neither LSA should be installed in the OSPF routing
table until PSS11 becomes reachable again. That's it. Read
on for a more detailed explanation.

>From RFC 2328 Section 12.4.4.1

  ...if two routers, both reachable
  from one another, originate functionally equivalent
  AS-external-LSAs (i.e., same destination, cost and
  non-zero forwarding address), then the LSA
  originated by the router having the highest OSPF
  Router ID is used. The router having the lower OSPF
  Router ID can then flush its LSA.

PSS9 should flush its 3.3.3.0/24 LSA. However, as Vishwas 
has pointed out, this was intended as an optimization
feature. But an implementation that chooses not to do this
could cause a subtle anomaly. See below. Regardless the
following text from RFC 2328 Section 14.1 still applies

  A router may only prematurely age its own self-originated
  LSAs. The router may not prematurely age LSAs that have
  been originated by other routers. An LSA is considered
  self-originated when either 1) the LSA's Advertising
  Router is equal to the router's own Router ID. 2) the LSA
  is a network-LSA and its Link State ID is equal to one of
  the router's own IP interface addresses.

Hence PSS11 and PSS9 retain each other's 3.3.3.0/24 LSAs
until they are flushed by the originating router or they age
out normally.

Regarding the text,

  If there is already a database copy, and if the database
  copy was received via flooding and installed less than
  MinLSArrival seconds ago, discard the new LSA (without
  acknowledging it) and examine the next LSA (if any)
  listed in the Link State Update packet.

I don't believe this applies to your example. The two LSAs
are different because they have different Advertising
Routers. They are only functionally equivalent. Hope this
clarifies Problem 1.

Regarding Problem 2, self originated external LSAs are
never installed in the OSPF routing table. RFC 2328 Section
16.4 Step (2) states

 (2) If the LSA was originated by the calculating router
     itself, examine the next LSA.

The reason for this is that a path to 3.3.3.0/24 exists
in the IP routing tables of PSS9 and PSS11 (versus their OSPF 
routing tables) that is external to OSPF, e.g. a static route
or BGP learned path. It is this path that is imported into OSPF
and causes the LSA's origination. Since PSS11's 3.3.3.0/24
external LSA is the more preferred LSA, PSS9's LSA must never
be installed in PSS11's OSPF routing table while this imported
path exist, as the OSPF path could potentially be more
preferred than the imported static route, BGP path, etc... in
the IP routing table. This would happen when OSPF's
administrative metric is preferred over the imported route's
administrative metric. The result could be an endless loop of
self-originations and flushings.

Note based on this discussion it seems clear to me that some
handling of functionally equivalent LSAs is mandatory.

HTH.

Pat

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

---

From: "Chitra Lakshmi Namadevan" <[email-masked]>
Date: Mon, 17 Jul 2006 18:58:49 +0530

Thanks Viswas!!!

-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]]
Sent: Friday, July 14, 2006 5:55 PM
To: Chitra Lakshmi Namadevan
Cc: [email-masked]
Subject: Re: [OSPF] Functionally equivalent as-external lsa

Hi Chitra,

> Problem 1:
Your analysis is correct, the LSA should not be removed if it is in
any of the neighbor lists.
If an Acknowledgement is not got the LSA needs to be retransmitted to
the neighbor.

> Problem 2:
If two routers, both reachable from one another, originate
functionally equivalent AS-external-LSAs (i.e., same destination, cost
and non-zero forwarding address), then the LSA originated by the
router having the highest OSPF Router ID is used. The router having
the lower OSPF Router ID can then flush its LSA.

Also note that any router with lower Router-ID CAN flush it s LSA, it
is an optimization to reduce the size of the OSPF DB.

Thanks,
Vishwas

On 7/14/06, Chitra Lakshmi Namadevan <[email-masked]>
wrote:
>
>
>
>
>
> Hi,
>
>
>
> Functionally equivalent AS-external lsas are originated. Therefore the
lsa with higher advertising router id is installed and the other lsa is
flushed.
> Topology:
> Problem 1:
> ============
> But the database of PSS11 has the AS-external lsa whose advertising
router is 10.81.156.72 along with the lsa advertised by 10.81.156.74.
This is the problem.
>
> PSS9 sends a maxage lsa. When PSS11 receives this maxage lsa it should
flush the external lsa with advertising router 10.81.156.72. But it is
not flushed.
>
> It is due to the following explanation found in RFC2328:
>
> "If there is already a database copy, and if the database copy was
received via flooding and installed less than MinLSArrival seconds ago,
discard the new LSA (without acknowledging it) and examine the next LSA
(if any) listed in the Link State Update packet."
>
> Therefore it discards the maxage lsa and so the lsa is not flushed and
it still remains.
>
> Analysis:
>
> PSS-11 discards the maxage lsa without any ls-ack. PSS-9 should not
flush the lsa and should send again a maxage lsa since it did not
receive a LS-ACK for the maxage lsa.
>
> Kindly let me know if my analysis is correct.
>
> Problem 2:
>
> ==========
>
> Disconnect the cable and make the link up. Then the router with the
lower router id (10.81.156.72 - PSS9) has the as-external lsa advertised
by the higher router id (10.81.156.74 - PSS11). But it should have the
as-external lsa advertised by lower router id i.e. self lsa.
>
> This is happening because the as-external lsa with higher router id is
not flushed. Therefore when PSS 9 originates the self as-external lsa,
it finds that functionally equivalent as-external lsa is still present
so it discards its self lsa.
>
> Kindly let me know what mechanism can be followed to flush the
as-external lsa with higher router id when the neighbor is deleted.
> Regards,
> Chitra

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: "Chitra Lakshmi Namadevan" <[email-masked]>
Date: Mon, 17 Jul 2006 18:59:05 +0530

Thanks Pat!!!

-----Original Message-----
From: Pat Murphy - (650)329-4044 [mailto:[email-masked]]
Sent: Saturday, July 15, 2006 5:02 PM
To: [email-masked]
Cc: Chitra Lakshmi Namadevan
Subject: Re: [OSPF] Functionally equivalent as-external lsa

Chitra,

W.r.t.
          dummy    dummy

          SW(*)    SW(*)
           |       |
 +-----+   |       |   +-----+
 |     |   |       |   |     |
 |     +---+       +---+     |
 |     |               |     |

Regarding the text,

HTH.

Pat