Subject: OSPFv2 db-exchange

From: John Pecola <[email-masked]>
Date: Fri, 28 Jan 2005 21:18:41 -0800

In this setup (OSPFv2), following sequence of events
take place - 

  R1--------Pt-to-Pt-------R2

1. Adjacency between R1 and R2 goes down
2. R1 postpones re-origination of its router lsa
because it did so less than minLSInterval before
3. R1 and R2 go into exchange state
4. R1 sends the copy of exisiting router-lsa in its db
description packet
5. R2 already has this copy and therefore does not
request for it (Sec13.1 rfc 2328)
6. After minLSInterval, R1 re-originates its router
lsa
7. R2 assumes it to be the same as its existing copy
(sec 13.2) and does not run its SPF.

This might cause an inconsistent routing table on R2.
What am I missing in the above sequence?

Thanks
John

__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250

---

From: Manish Gupta <[email-masked]>
Date: Sat, 29 Jan 2005 15:33:27 +0530

Hi Joan,

SPF needs to be run whenever router received a new LSA via flooding OR
it's newly self-originated LSA installed in database.
in your case due to MinLsaInterval you have not received router LSA from R1.
but when adjacency goes down, R2 will generate a new instance of Router LSA
in which Point-to-point link (link type 1, and Link Id as R1 router ID)
should not be there by which R2 will know that
R1 is nor reachable and it can calculate the correct routes.
and when the adjacency become FULL R2 will again generate the router LSA
with point-to-point link (link type 1, and Link Id as R1 router ID) by which
it can caculate the correct routes.

Regards
Manish Gupta

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of John
Pecola
Sent: Saturday, 29 January 2005 10:49 AM
To: [email-masked]
Subject: OSPFv2 db-exchange

Thanks
John

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: Acee Lindem <[email-masked]>
Date: Sat, 29 Jan 2005 08:30:05 -0500

Hi John,

>(sec 13.2) and does not run its SPF.
When R1 reoriginates its LSA it should a new sequence number (and most
probably the checksum will change). Hence, R2 should interprete it as a more
recent LSA and run its SPF.

Thanks,
Acee

---

From: Manish Gupta <[email-masked]>
Date: Sat, 29 Jan 2005 22:18:40 +0530

Hi Acee,
    i agree with you that when R1 reoriginates its LSA it should a new
sequence number (and most
probably the checksum will change)

but why R2 should run the SPF if only sequence number or check sum is
changed.

say for example R1 and R2 are connected via point to point link.
after every LSRefreshTime R1 and R2 will generate a new instance of LSAs.
but there is no change in the network topology so why should we run the SPF.

according to RFC 2328 section 13.2 :-

 When comparing an LSA to	its previous instance,
	the following are all considered to be differences in contents:

	    o	The LSA's Options field	has changed.

	    o	One of the LSA instances has LS	age set	to MaxAge, and
		the other does not.

	    o	The length field in the	LSA header has changed.

	    o	The body of the	LSA (i.e., anything outside the	20-byte
		LSA header) has	changed. Note that this	excludes changes
		in LS Sequence Number and LS Checksum.

am i missing something ?

Regards
Manish Gupta

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of Acee
Lindem
Sent: Saturday, 29 January 2005 7:00 PM
To: [email-masked]
Subject: Re: OSPFv2 db-exchange

Hi John,

Thanks,
Acee

---

From: John Pecola <[email-masked]>
Date: Sat, 29 Jan 2005 12:06:59 -0800

Manish,

R2 may also go through similar sequence that R1 went
through. When the adjacency went down, R2 was unable
to re-originate its router LSA because of
minLSInterval. When it eventually does, adjacency is
already back up, and so R2 should see its router lsa
unchanged (Sec 13.2) and not re-install it (and not
run its routing table calculation). Is this assumption
correct?

Thanks
John

--- Manish Gupta <[email-masked]> wrote:

> From: Mailing List
> [mailto:[email-masked]]On Behalf Of John
> Pecola

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Ramanan N <[email-masked]>
Date: Sat, 29 Jan 2005 18:32:44 -0500

Please see inlined !

> This might cause an inconsistent routing table on R2.

John, I didnt get this.
When R1 has reoriginated the router LSA with a higher seq num,
the contents would not have changed from that of the prev one.
So, R2 would have installed the R1's new lsa in R2's database,

Since the contents have not changed, SPF is not run immediately.
when the SPF is run later, there should not be any inconsistency
in the routing table. 

> What am I missing in the above sequence?

Or did I too miss ?

---

From: Erblichs <[email-masked]>
Date: Sat, 29 Jan 2005 18:20:45 -0800

John Pecola,

	The below sequcence really doesn't make sense,
	because R1 & R2 cannot go into exhange state
	while they are no longer neighbors., so I must
	assume that they became 2-way before echange.

    AA - Assuming that R1 & R2 have other neighbors/adjs,
	when the adjcency went down between the two of
	them, they each would re-orginate their router
	LSAs no longer declaring the link to the other
	router (R1 or R2) link up TO THEIR other nbr routers.

     BB - If R1 and R2 didn't have other nbrs, then they
	could keep the original past nbr's LSA in their
	database because it can't be used without the adj
	to the nbr via the SPF calc.

	When the link comes back up, they will maybe
	form a 2-way nbr state, and move into
	exchange state.

	At this point, I think you assume it's BB. They
	should each request and recieve the older LSA
	version. They each should increment the sequence
	of their respective router LSA and send it in
	a LS Update pkt.

	I believe if my memory serves me, one of Moy's
	OSPF book's he has the restart seq with
	router's echanging the
	old LSAs, and then Updating with a newer LSA
	via an increment of its instance.
	This violates your #5.

	Some implimentations may scan for no longer
	valid LSAs and remove them. This would
	easily be the case if 1 hour had passed 
	between your (#1 and #3) since
	the LSA was updated. This would then result
	in the new LSAs being sent after Requests.

	FYI: Some implimentations will wait for some
	period of time iff a link's history has a quality
	of UNstableness, before exchange begins.

	The MinLSInterval really applies when the LSA
	changes in a significant manner and in theory 
	reduces the freq of the repeated flooding of a 
	particular LSA.

	However, with respect to router's specified in router
	and network LSAs, they in theory require full adj
	before being specified in the LSAs. This requires
	these nbr to be updated with a additional LSA.

	Mitchell Erblich

---

From: Acee Lindem <[email-masked]>
Date: Mon, 31 Jan 2005 08:08:25 -0500

>probably the checksum will change)
Hi Manish,
I guess there are different interpretations for the original post. My 
assumption was that
the original LSA had changes and was delayed due to MinLSInterval.

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Mon, 31 Jan 2005 08:19:49 -0500

Hi John,

Now I think I understand your scenario - see inline.

John Pecola wrote:

>unchanged (Sec 13.2) and not re-install it
>
In any case, it should re-install it in the database since it is more 
recent.

> (and not
It need not re-run the routing calculation if the LSA is unchanged. 
However, it will
definitely re-run it's routing calculation when it goes to FULL state 
with R1.

---

From: Manish Gupta <[email-masked]>
Date: Fri, 28 Jan 2005 22:41:29 +0530

Hi Acee,

please see inline

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of Acee
Lindem
Sent: Monday, 31 January 2005 6:50 PM
To: [email-masked]
Subject: Re: OSPFv2 db-exchange

Hi John,

John Pecola wrote:

>already back up,

<MANISH> does it mean that adjacency with R1 is become FULL when R2
re-originate router LSA after MinLSInterval ?
         (i am asumming it's FULL)

and so R2 should see its router lsa
>unchanged (Sec 13.2) and not re-install it

<MANISH> R2 must install the LSA since it is more recent (sequence number
will increament).
         but it need not to run the SPF.

>run its routing table calculation). Is this assumption

<MANISH> i think this is o.k

<MANISH> i think the state is already FULL and there is no need to run the
SPF in this situation.
         even if you run the SPF the routing table will be same only.

Regards
Manish Gupta

---

From: Acee Lindem <[email-masked]>
Date: Mon, 31 Jan 2005 13:24:45 -0500

>         (i am asumming it's FULL)
Both sides can't become full until they have left LOADING state and 
consequently received
all more recent LSAs from each other (including their own originations 
due to the
adjacency flapping). Hence, I don't think this is a possible situation.

>>>you are notified that you are strictly prohibited
>>>      
>>>
>>>from using,
>>    
>>