Mailing List Archive

Hi. I'm using zebra to advert RIPv2 pkts out every 10 secs and I'm afraid
the hardcoded RIP jitter might cause flaps. I'm wondering if it could be
made tunable:

Your patch is backwards (but that's not a big deal in understanding it).

I cannot follow the logic here. The original code seems to generate a
random value from 0 to time (inclusive), and then subtract half of
time.
So the result it between -time/2 and time/2, more or less.
With the patch, it looks like etiher 0, 1 or 2, then - 1, so either
-1, 0 or +1.

Can you explain what's wrong in the 10s case and how the original code
behaves? It clearly seems intended to scale with an interval.

--
Greg Troxel <gdt@ir.bbn.com>

On Tue, 13 Jan 2004, Greg Troxel wrote:

> Hi. I'm using zebra to advert RIPv2 pkts out every 10 secs and I'm afraid
> the hardcoded RIP jitter might cause flaps. I'm wondering if it could be
> made tunable:
>
> Your patch is backwards (but that's not a big deal in understanding it).

sorry. Thx for responding.

>
> I cannot follow the logic here. The original code seems to generate a
> random value from 0 to time (inclusive), and then subtract half of
> time.
> So the result it between -time/2 and time/2, more or less.
> With the patch, it looks like etiher 0, 1 or 2, then - 1, so either
> -1, 0 or +1.

exactly.

>
> Can you explain what's wrong in the 10s case and how the original code
> behaves? It clearly seems intended to scale with an interval.

It may be OK, I'm testing it now under various failure scenarios and
traffic load. It just seems that -time/2 -> time/2 is too wide a gap.
If I configure zebra to advert every 10 secs, I expect it to advert every 10
secs (+/- 1 sec). I'm adverting to a Cisco router which I'm afraid (I may
be wrong) wouldn't have the tolerence.

Cheers,
Anthony

On Tue, 13 Jan 2004 Anthony.Golia@morganstanley.com wrote:

> It may be OK, I'm testing it now under various failure scenarios and
> traffic load. It just seems that -time/2 -> time/2 is too wide a gap.
> If I configure zebra to advert every 10 secs, I expect it to advert every 10
> secs (+/- 1 sec). I'm adverting to a Cisco router which I'm afraid (I may
> be wrong) wouldn't have the tolerence.

Why? The most important timer is the timeout times. It is usualy (and
should be) much larger than update timer.

Best regards,

Krzysztof Olêdzki

It may be OK, I'm testing it now under various failure scenarios and
traffic load. It just seems that -time/2 -> time/2 is too wide a gap.
If I configure zebra to advert every 10 secs, I expect it to advert every 10
secs (+/- 1 sec). I'm adverting to a Cisco router which I'm afraid (I may
be wrong) wouldn't have the tolerence.

It would be good to read the spec here and see if the current behavior
is legal.

On Tue, 13 Jan 2004, Krzysztof Oledzki wrote:

>
>
> On Tue, 13 Jan 2004 Anthony.Golia@morganstanley.com wrote:
>
> > It may be OK, I'm testing it now under various failure scenarios and
> > traffic load. It just seems that -time/2 -> time/2 is too wide a gap.
> > If I configure zebra to advert every 10 secs, I expect it to advert every 10
> > secs (+/- 1 sec). I'm adverting to a Cisco router which I'm afraid (I may
> > be wrong) wouldn't have the tolerence.
>
> Why? The most important timer is the timeout times. It is usualy (and
> should be) much larger than update timer.

that's what i thought. an engineer here is telling me that the cisco
router will ignore the RIP updates if they're out of sync. I'll test and
let you know. That said, it does seem wrong to have zebra send out RIP
adverts every 15 secs (which it could potentially do) if I config it to
send every 10 secs.

>
> Best regards,
>
> Krzysztof Olêdzki
>
>

Cheers,
Anthony

from RFC 1058 (RIPv1) :


implementations are required to take one of two precautions.

- The 30-second updates are triggered by a clock whose rate
is not affected by system load or the time required to
service the previous update timer.

(I'll believe it when I see it) ;-)

- The 30-second timer is offset by addition of a small random
time each time it is set.


IMO time/2 is not small compared to time.


but then from the RIPv2 RFC (which is what I'm using):


- The 30-second timer is offset by a small random time (+/- 0 to 5
seconds) each time it is set. (Implementors may wish to consider
even larger variation in the light of recent research results [10])

from reference 10:

"a small random time must be added to the 30-second routing timer each
time, though the magnitude of the random time is not specified."

the +/- 0 to 5 secs in the RFC is based on a 30 sec timer. The current
code in zebra will give +/- 0 to 5 secs for a 10 sec timer. It should be
less.



On Tue, 13 Jan 2004, Greg Troxel wrote:

> It may be OK, I'm testing it now under various failure scenarios and
> traffic load. It just seems that -time/2 -> time/2 is too wide a gap.
> If I configure zebra to advert every 10 secs, I expect it to advert every 10
> secs (+/- 1 sec). I'm adverting to a Cisco router which I'm afraid (I may
> be wrong) wouldn't have the tolerence.
>
> It would be good to read the spec here and see if the current behavior
> is legal.
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev
>
>

Cheers,
Anthony

Does the spec permit a 10 second timer?
I suppose that's already an option.

Reducing the delta seems reasonable, but I'd like any such patch to
include comments with spec references and describe the intended
behavior. IMHO only the ripv2 spec counts now for jittering guidance.

It may be that jittering by +/- 25%, or +/- one-sixth is good enough.
ripv2 calls for +/- 5, which is 1/6.

We should ensure that the jitter is always at least +/- 1, and
prohibit intervals < 2s (or some larger value if there is MUST NOT in
the rfc).

On Wed, 14 Jan 2004, Greg Troxel wrote:

> Does the spec permit a 10 second timer?

doesnt say yes or no.

> I suppose that's already an option.

yes thank goodness for me ;-)

>
> Reducing the delta seems reasonable, but I'd like any such patch to
> include comments with spec references and describe the intended
> behavior. IMHO only the ripv2 spec counts now for jittering guidance.

agreed.

>
> It may be that jittering by +/- 25%, or +/- one-sixth is good enough.
> ripv2 calls for +/- 5, which is 1/6.
>
> We should ensure that the jitter is always at least +/- 1, and
> prohibit intervals < 2s (or some larger value if there is MUST NOT in
> the rfc).

sounds logical to me. Thank you.

>
>

Cheers,
Anthony