Subject: Selection of router id. And behaviour with IPv4 address removal.

From: "Aniket D." <[email-masked]>
Date: Mon, 23 Jan 2006 11:13:46 -0800

I had a question about the Router id and its relation with IPv4 addresses.
   
  The popular and common choice for Router Id is the highest loopback IPv4 address or the IPv4 address of any other interface. 
   
  Now if we continue to use the same scheme for the Router id for OSPFv3, what happens is:
  A) OSPFv3 process cannot be started until an IPv4 address is configured on the box. 
   
  B) Suppose: An IPv4 address is configured to start the OSPFv3 routing process. Now if we remove all IPv4 addresses from all the interfaces what is it that should happen. With a Cisco router, the OSPFv3 adjacencies persist and the same router id continues to be used despite that address no longer being configured on any interface on that box. 
  - What this leads you to is that - now if you do a save running-config and reload the box, the OSPFv3 adjacencies wont come up, which were already up before reloading the box. 
   
  C) What is the right behaviour? Should OSPFv3 adjacencies go down when all IPv4 addresses are removed? 
   
  D) Should the Router Id be chosen with some other algorithm?
   
  Thanks and regards,
  Aniket.

---------------------------------
Yahoo! Photos
 Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.

---

From: Abhay Roy <[email-masked]>
Date: Mon, 23 Jan 2006 11:32:33 -0800

I guess the same "issue" also arises in OSPFv2. The best 
way to overcome them is to use a manually configured Router 
ID v/s letting the routers choose automagically..

Regards,
-Abhay

---

From: AJAY THAKUR <[email-masked]>
Date: Wed, 25 Jan 2006 17:31:20 +0530

Aniket,
This is related to implementation.  
Starting ospf process without router-Id is not allowed in cisco but
it is not true for other implementations.

But still I do have some more question
on the same topic,

(1) Configure ip address 1.1.1.1
    Now this is ospf router id

(2) Now configure ip address 2.2.2.2
Now still ospf uses 1.1.1.1 as router-Id.

(3) Now uncofigure 1.1.1.1 ip address.

Now if  you reload the box ospf will not identify self-originated lsa
and in this case these lsa will  remain in database for MAX_AGE.

What do you say about this behaviour?
Thanks
ajay

Aniket D. wrote:

> The popular and common choice for Router Id is the highest loopback 
> IPv4 address or the IPv4 address of any other interface.
>  
> B) Suppose: An IPv4 address is configured to start the OSPFv3 routing 
> process. Now if we remove all IPv4 addresses from all the interfaces 
> what is it that should happen. With a Cisco router, the OSPFv3 
> adjacencies persist and the same router id continues to be used 
> despite that address no longer being configured on any interface on 
> that box.
> - What this leads you to is that - now if you do a save running-config 
> and reload the box, the OSPFv3 adjacencies! wont come up, which were 
> already up before reloading the box.
>  
> ------------------------------------------------------------------------
> Yahoo! Photos
> Ring in the New Year with Photo Calendars 
> <http://us.rd.yahoo.com/mail_us/taglines/photos/*http://pa.yahoo.com/*http://us.rd.yahoo.com/mail_us/taglines/photos/evt=38087/*http://pg.photos.yahoo.com/ph//page?.file=calendar_splash.html&.dir=>. 
> Add photos, events, holidays, whatever.

---

From: anup <[email-masked]>
Date: Mon, 30 Jan 2006 11:28:40 +0530

One good solution is to flush the router lsa and the network lsa that were
originated with the old router-id. This ensures that the router with old
router-id is no longer reachable.

Anup

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of AJAY
THAKUR
Sent: Wednesday, January 25, 2006 5:31 PM
To: [email-masked]
Subject: Re: Selection of router id. And behaviour with IPv4 address
removal.

Aniket,

> D) Should the Router Id be chosen with some other algorithm?
<http://us.rd.yahoo.com/mail_us/taglines/photos/*http://pa.yahoo.com/*http:/
/us.rd.yahoo.com/mail_us/taglines/photos/evt=38087/*http://pg.photos.yahoo.c
om/ph//page?.file=calendar_splash.html&.dir=>.

---

From: Dave Katz <[email-masked]>
Date: Sun, 29 Jan 2006 22:14:31 -0800

> router-id is no longer reachable.

This is unnecessary, since the old router ID will be unreachable  
anyhow (nobody will be adjacent to it, so the LSAs will never be  
considered in the SPF.)

There's no harm in letting them rot for an hour, it's just memory.

---

From: AJAY THAKUR <[email-masked]>
Date: Mon, 30 Jan 2006 11:40:31 +0530

Anup,
In all implementation we do follow this ..
we flush all the self-originated LSA whenever router-Id is
changed.
But my concern was that, "what if router does not get chance
to flush the self-originated lsas (in case of reload) and  after reload
router-Id is no more same". This is still valid..

thanks
ajay

---

From: anup <[email-masked]>
Date: Mon, 30 Jan 2006 11:54:02 +0530

The lsas originated by the router remain in the LSDB of other routers for an
hour. During this time, the router with old router-id is virtually intact
(still reachable) from other routers' perspective. So, it is necessary to
flush all the lsas with old router-id. But, it is sufficient if only router
and network lsas are flushed. 

In case of ospfv3, additional lsas might have to be flushed.

Correct me if I'm wrong.

Anup

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Dave Katz
Sent: Monday, January 30, 2006 11:45 AM
To: [email-masked]
Subject: Re: Selection of router id. And behaviour with IPv4 address
removal.

---

From: Dave Katz <[email-masked]>
Date: Sun, 29 Jan 2006 22:32:13 -0800

> and network lsas are flushed.

No, they are not reachable.  No other router will have the offending  
router ID in their router LSAs, so SPF will ignore them.  There is no  
reason, other than tidiness, to try to flush them.  Topologically the  
offending LSAs are partitioned from the rest of the network.

---

From: Divakar Dhar <[email-masked]>
Date: Mon, 30 Jan 2006 12:35:27 +0530

> offending LSAs are partitioned from the rest of the network.

exactly...there is nothing wrong in keeping the LSA's for MAX_AGE.  It 
is just a question of memory and no other router would be seeing us as 
fully adjacent router, so there is no issue with the sanity of routing 
tables.
The router-id is taken from loopback interface addresses (even in cisco) 
even if some non-loopback interface IP address is more than the loopback 
interface address.  It is  because, it is expected that the loopback 
interface addresses wont change much often.
-Divakar

---

From: Erblichs <[email-masked]>
Date: Sun, 29 Jan 2006 23:30:45 -0800

Dave, et al,

	Dave, aren't you simplfing the issue? Here are
	just a few quick items.

	Will the SPF or incremental SPF still run upon
	flushing them, even though the results will
	not change? I think so.

	Second, worse case (Murphy's Law) scenario. What
	happens if all routers within the area/AS reboot
`	without MAXAGING their LSAs? We could theoreticly
	use 2x the amount of memory for out LSDB?

	Could this trigger some type of LSDB overload
	protection?

	If we had just originated new LSAs, should we
	wait until we can transmit the LSA with MAXAGE?

	their is a significant amount of work to flush.

	What is the cost of flushing vs not flushing? Additionally
	to the above, "dead LSAs in our LSDB", will also be
	aged (assume non DNA) and checksummed periodicly and still
	need to be aged out. Then why waste the memory?

	So the bottom line, IMO, if we broke the suggested 30 min
	re-originate interval and do it every 50 mins, and 48 mins
	have passed, I would elect to allow "independent flushing"
	to occur in 12 mins.

	And if we are close to a group determined LSDB Overload,
	and 55 mins is due to the LSA being aged out, I would elect
	to do "demand MAXAGE flushing". Yes, DNA LSAs also fit here.
	
	Anywhere in between is dependent on whether we are in
	a stub area and memory is IMPORTANT or..

	In between, I tend to lean towards "demand MAXAGE flushing"
	to remove unnecessary periodic work.

	Just a few things to consider. Sorry about the MPLS
	concepts, I just had to use them. :)

	Mitchell Erblich
	----------------------

---

From: Dave Katz <[email-masked]>
Date: Mon, 30 Jan 2006 02:39:39 -0800

My point was only that flushing the LSAs is not necessary for  
correctness, as the protocol must be robust against this sort of  
thing.  Whether or not it is a good idea, or easy, or hard, is an  
issue for the implementer.  There are certainly some cases where it  
is not possible or at least not reasonable (the router ID changing  
during a reboot, which can happen for secondary reasons.)

> 	have passed, I would elect to allow "independent flushing"

I "broke" this in 1997;  the 30 minute refresh interval is stupid.  I  
did turn up really egregious bugs in a couple of other  
implementations this way, so whether I was also stupid is open for  
debate.

> 	to remove unnecessary periodic work.

We're free to implement this as we wish, as it is not and cannot be  
subject to standardization.  There is also a cost to complexity  
(bloat and bugs) and being squeaky clean about these things need to  
be weighed against the obvious and more subtle costs of doing so.

Let's put it this way--if your implementation can withstand the  
occasional (and seemingly inevitable, based on history)  
misconfiguration when full routing gets dumped into OSPF, the  
negligible loads of aging extra LSAs will not make you break a sweat.

---

From: Erblichs <[email-masked]>
Date: Mon, 30 Jan 2006 11:35:49 -0800

Group,

	A much more common case is just a router leaving
	the area. In the BMA environment, after the dead
	router interval has passed. Their is no MUST
	requirement that a router clean up its LSAs
	before leaving.

	Does anyone think that a Network LSA would then
	be re-originated showing that the old router is
	no longer reachable?

	Mitchell Erblich
	-------------------