Subject: Re: What will happen in this kind of topology with 100 nbrs and 2 000 ASEs ??

From: "Yu, Mu Zhi (Alex)" <[email-masked]>
Date: Mon, 25 Oct 2004 14:53:33 +0800

Which kind of router in cisco or juniper could support the mechanisms
described in draft-ietf-ospf-scalability-08.txt? especially the "exponential
backoff algorithm" and "water mark" mechanisms.

#Alex

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of Mollin,
Arvind - LiqwidKrystal
Sent: 2004年10月25日 MuZhiPM 02:45
To: [email-masked]
Subject: Re: What will happen in this kind of topology with 100 nbrs and
2000 ASEs ??

Thanks for one n all.
Well this case is something related to congestion as Vishwas have
pointed out. Suppose R1 sends a update, ( that is each neighbor will
send an update 100 updates altogether) then R2 would send back 99*100
updates to R1, thus R1 is busy in processing them and doesn't send
hello's or doesn't process hellos, also sometimes the buffer overflows.
These are the reason why ospf flaps. So in this kind of topology the
processing will hog the CPU.
  Well, I have read that some implementations can handle upto 750
neighbors. !! provided congestions are avoided.

--Arvind

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Dave
Katz
Sent: Monday, October 25, 2004 11:52 AM
To: [email-masked]
Subject: Re: What will happen in this kind of topology with 100 nbrs and
2000 ASEs ??

This kind of behavior is related to the quality of the implementation.
Some implementations can handle 100 neighbors with aplomb.  There's no
reason this shouldn't be stable, particularly with the large default
timer values.

But my rants on this subject are well known...

On Oct 24, 2004, at 11:40 PM, Vishwas Manral wrote:

> Hi Arvind,
>
> Instead of increasing the "Router Dead Interval", you could instead
use
> techniques as given in
> http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-08.txt
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Mailing List [mailto:[email-masked]] On Behalf Of
> Nitin
> Kakkar
> Sent: Monday, October 25, 2004 10:33 AM
> To: [email-masked]
> Subject: Re: What will happen in this kind of topology with 100 nbrs
> and
> 2000 ASEs ??
>
> Most probable reason seems to be that Hello's doesn't come on time and
> adjacencies are dropped. Some time later hellos come and adjacencies
> are
> reestablished. May be you can increase your adjacency dead timer and
> try
> again.
> HTH
> Nitin
>   -----Original Message-----
> From: Mailing List [mailto:[email-masked]]On Behalf Of
> Mollin,
> Arvind - LiqwidKrystal
> Sent: 2004Ae10OA25EO 10:12
> To: [email-masked]
> Subject: What will happen in this kind of topology with 100 nbrs and
> 2000
> ASEs ??
>
>
>
> Hi,
>
>   I have two routers connected back to back through a gig link. I have
> configured 100 VLANs in that single gig link, now each vlan act as
> virtual
> interface. I have configured 100 neighbors on each router using these
> 100
> virtual interfaces. All the neighbors are in backbone. See the figure
> below,
>
>
>
> ( 100 nbrs )R1 -------------100 vlans ------------------ R2 ( 100 nbrs
> )
>
>
>
> After sometime I could see all nbrs flapping often. What could be the
> reason
> for this ??
>
> Is this topology right?, Has anybody tested with this kind of setup ??
>
>
>
> Thanks
>
> Arvind
>
>

---

From: Dave Katz <[email-masked]>
Date: Mon, 25 Oct 2004 01:16:41 -0600

> backoff algorithm" and "water mark" mechanisms.

I can't comment on the cisco implementation (haven't looked at the code
in most of a decade;  I assume it has improved in that time.)  The
Juniper implementation has a number of mechanisms that it uses to
improve scalability, some of which resemble some of the schemes in the
draft and some of which don't.  The details are proprietary.

> Sent: 2004 $BG/ (B10 $B7n (B25 $BF| (B MuZhiPM 02:45

---

From: Dave Katz <[email-masked]>
Date: Mon, 25 Oct 2004 01:19:42 -0600

> processing will hog the CPU.

There's no reason that a router should be so busy as to not send or
process hellos if it is properly implemented, excepting the case that
the arrival rate of Hellos is so high that there is insufficient
resources to process them.

Otherwise, the worst that should happen is that convergence will slow
due to the processing load.

> neighbors. !! provided congestions are avoided.

Yup.