Re: Clarification in changing the router id dynamically!!

kamatchi soundaram <kamatchi@TDD.SJ.NEC.COM> Tue, 08 July 2003 19:08 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05585 for <ospf-archive@LISTS.IETF.ORG>; Tue, 8 Jul 2003 15:08:56 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A58411@cherry.ease.lsoft.com>; Tue, 8 Jul 2003 15:08:54 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47810179 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Jul 2003 14:43:44 -0400
Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Jul 2003 14:43:43 -0400
Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id h68IhfmX000015 for <OSPF@peach.ease.lsoft.com>; Tue, 8 Jul 2003 11:43:41 -0700 (PDT)
Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (/) with ESMTP id h68IhYrP026987 for <OSPF@peach.ease.lsoft.com>; Tue, 8 Jul 2003 11:43:34 -0700 (PDT)
Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.9/8.12.9) with ESMTP id h68IWQDp005249 for <OSPF@peach.ease.lsoft.com>; Tue, 8 Jul 2003 11:32:26 -0700 (PDT)
Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com (8.12.9/8.12.9) with SMTP id h68IWO8C012220 for <OSPF@peach.ease.lsoft.com>; Tue, 8 Jul 2003 11:32:24 -0700 (PDT)
References: <002c01c3419b$75dd9ca0$1105f183@b90.tdd.sj.nec.com> <3F06291C.1070706@redback.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID: <008601c34581$f61b7c40$1105f183@b90.tdd.sj.nec.com>
Date: Tue, 08 Jul 2003 11:51:37 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: kamatchi soundaram <kamatchi@TDD.SJ.NEC.COM>
Subject: Re: Clarification in changing the router id dynamically!!
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Acee,

----- Original Message -----
From: "Acee Lindem" <acee@redback.com>
To: <OSPF@peach.ease.lsoft.com>
Sent: Friday, July 04, 2003 6:25 PM
Subject: Re: Clarification in changing the router id dynamically!!


> kamatchi soundaram wrote:
> > Hi,
> >
> >   If the router id of the router R1 is changed on the fly (dynamically),
> > what factor triggers the adjacent router R2 connected to R1 via point to
> > point link, to generate the new Router LSA???
> >
> >  From the RFC i could infer that R1 will flush all his self originated
lsas
> > when it's router lsa has been changed.
> >   But i couldn't find, how the R2 triggered to generate the new router
lsa
> > with the changed router id as is neighbor id in its router lsa??
>
> Kamatchi,
>
> Actually, since neighbors are identified by router ID on P2P links (as per
> RFC 2338 section 8.2), R2 shouldn't recognize R1 with the new router ID
and
> should bring down the old adjacency with R1 and form a new one. A more
> interesting question is what would happen on a broadcast or NBMA network
> (where neighbors are identified by source address).
> This case isn't explicitly handled by RFC 2328 and there is some variance
> between implementations. At a minimum, the DR must recognize the change
> in router ID and originate a new network LSA. I found that one popular
> implementation required the router with the router ID change to bring its
> adjacencies down (by sending a hello w/o any neighbor IDs) in order to
> interoperate.

Does it mean that the R1 (router whose Id has got changed), should reset
it's NSM with all its neighbor to down/init state and then send hello
without any neighbor ids??

  Since, R1 need to flush all it's self originated lsas before to bring down
the adjacency and restart again, there needs some ample amount of time to
flood and flush the lsas in the routing domain (atleast with the neighbor).
So, i cannot send the hello packet (without any neighbors) immedietly after
the sending out the max age lsas (to flush the self originated lsas).

 Because if i do that, then there is a chance that before the self
originated lsas are completely flushed out or sent from R1, the NSM may
reverted to down state. Which will basically prevent the complete flushing
of self oringinated lsas . . correct??

 My question is how can be the time between the flushing the lsas and
hello's sent without the neighbor ids determined???

 Since, if there is no significant amount left between the lsa flushing and
new hello without neighbor id, then the entire system will be in bad
condition.

Thanks,
Kamatchi.

>
> Thanks,
> Acee
>
> >
> > Thanks in advance,
> > Kamatchi.
> >
>
>
> --
> Acee
>