Mailing List Archive

> It seems the problem is number of flaps, etc. Doesn't it make sense to
> simply start dropping the routes that flap the most? Of course this will
> be biased in the /24 space but at least the rationale/solution maps
> identically to a solid reason.
>
> To what extent is this flapping due to basically static information being
> propogated? One solution would be to nail these routes ...
>
> Cheers, peter

I know that Sprint was talking about doing this (damping /24s harder
than /23s harder than ...).

Is it implemented or about to be implemented?

Avi

- - - - - - - - - - - - - - - - -

Avi Freedman wrote:
>
>> It seems the problem is number of flaps, etc. Doesn't it make sense to
>> simply start dropping the routes that flap the most? Of course this will
>> be biased in the /24 space but at least the rationale/solution maps
>> identically to a solid reason.
>>
>> To what extent is this flapping due to basically static information being
>> propogated? One solution would be to nail these routes ...
>>
>> Cheers, peter
>
>I know that Sprint was talking about doing this (damping /24s harder
>than /23s harder than ...).
>
>Is it implemented or about to be implemented?
>
>Avi
>

We implement it into AS1849 (UUNETPIPEX) (UK) in a streamlined form and it
works fine. Doesn't reduce the number of routes in the table though :-(

Haven't been effected by any route flaps just recently though :)


--Tony
- - - - - - - - - - - - - - - - -

Geoff,

I have been recording routing table size at 12 hour intervals since
January. If nothing finger is available, I wouldbe happy to let you
have my data.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net Phone: +1 510 486-8634
- - - - - - - - - - - - - - - - -