Subject: [Isis-wg] Hello Intervals

From: "vikram isis" <[email-masked]>
Date: Mon, 11 Sep 2000 23:15:03 GMT

Hi,
A question on hello interval timers. Cisco implements hellos times as 
follows:
1> hello interval : 10
2> hello multiplier: 3
does anybody have some suggestions as to where these values have been 
specified?

Any help is appreciated.

Vikram
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Mon, 11 Sep 2000 19:39:03 -0400 (EDT)

>>	From: "vikram isis" <[email-masked]>
>>      1> hello interval : 10
>>      2> hello multiplier: 3

I think the Cisco numbers are reasonable. The hello timer must
be settable, and perhaps the holding multiplier is as well. So
the "hello interval" of 10 is a default, right?

By the way, the holding multiplier was something I discovered, to my
surprise (and not happiness) that 10589 specified to be a constant,
and 10 times
the hello timer, which is way too much. I think it was specified
as 2+fudge factor, or perhaps 3, in the DECnet Phase 5 routing spec.
At any rate, when I asked on the mailing list about how the multiplier
got to be specified as 10 (and not settable...an architectural constant),
the answer was that everyone was ignoring that, so it wasn't a problem!

There's no magic to the numbers, and there was no careful analysis
done, but 2 or 3 times for the multiplier
seems about right, and 10 times seems definitely
wrong. As for the hello timer, I'd think it would have to be
a parameter, since if you want to notice a router down within a few
seconds, you'll have to send more frequent hellos, and if it were
always, say, 1 second, that might be too much overhead in most cases.

Radia

---

From: Danny McPherson <[email-masked]>
Date: Mon, 11 Sep 2000 18:02:48 -0600

> always, say, 1 second, that might be too much overhead in most cases.

Several service provider networks I'm familiar with actually increase the 
multiplier to 4 or 5 and lower the interval to 1-2s.  The b/w utilization is 
negligible (especially on OC-n connections), and even less when 
implementations stop padding hellos after adjacency establishment.  The 
benefit (i.e. detecting faults nearly an order of magnitude faster) certainly 
is interesting, especially when comparing to typical default values.

Then again, others increase the interval to cut down on chatting (especially 
w/large NBMA clouds -- where they need it most *8^/).

Of course, it goes without saying -- mucking with values without understanding 
the full impact on the network is a bad idea.

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 11 Sep 2000 20:13:41 -0600

> What is the value in increasing the multiplier? I understand why you'd
> want to set the hello interval to be small in order to detect failure
> quickly. The only reason I could imagine for setting the multiplier
> higher is if the link is very flaky and it's likely you'll miss
> several hellos in a row. Are the networks you refer to
> using very fast and very flaky links?
> Or are the routers likely to lose a lot of packets without looking at
> them first, so that most hellos do get lost?

There are a number of reasons, actually.  A couple of the networks I refer to 
are indeed very fast and usually very reliable, though the reasoning equally 
applies to the lower-speed networks as well.

Increasing the multiplier seems to provide a sense of security when decreasing 
the interval, primarily in order to avoid instability or oscillation as a 
result of bursts of errors (on usually very reliable links, perhaps when 
switching to protected SONET paths, though applicable to "non-protected" links 
as well), or dealing with bursty traffic resulting in temporal congestion 
(perhaps as the result of circuit failures or other anomalies in the network). 
 And, of course, to deal with "platform" issues (e.g. lack or system 
bandwidth, processor cycles, plain old flakiness, etc..).

Similarly, such models have been deployed w/BGP and other routing protocols, 
as well as link layer keepalives, etc..

-danny