Route Flaps at NAP's
pst at juniper.net
Wed Sep 17 17:54:16 UTC 1997
From: bmanning at ISI.EDU (Bill Manning)
Subject: Re: Route Flaps at NAP's
How is one to tell the "actual transitions" if not by counting updates?
Let me turn that back on you, Bill, how is counting updates relevant
to the question being asked: "What magnitude of routing instability
is there at a particular place and time?"
Flap is mis-used as short-hand for a transition, but in fact you want
to measure transitions, of which flaps are the most common.
What's a transition:
1) a prefix was advertised, now it's withdrawn
2) a prefix wasn't advertised, now it is
3) an attribute of the prefix has changed
(next hop, as path, community, etc.)
(1) and (2) combined are the most common events, we call them flaps.
All 3 events actually contribute to routing infrastructure stability,
as all 3 typically cause messages to propogate through the network.
In order to answer: "What's the routing stability at (put in your
favorite pint in the network)?" you actually want to count (read
this twice) the number of transitions that each prefix advertised
from a neighbor has made during your sample period.
Say I need to withdraw 10 prefixes I am advertising to you. I can
send you 1 update message with 10 prefixes in it, or I can send
you 10 updates with one prefix in it. No difference in routing
stability, the change should be measured the same way either way.
Say I send you an update withdrawing 10 prefixes, but the withdrawal
is a no-op because you don't have them installed, possibly due to
a previous withdrawal. The update is a no-op and does not affect
routing stability, nor does it cause a message that needs to be
propagated past the receiving router.
I hope this makes it clearer why I think counting the messages
themselves is not particularly relevant.
It should be easy to instrument the more useful number in your RS
code: Increment a counter every time a rt_entry's info is actually
Heck, the Merit guys shouldn't even need to change their cute little
Java app's (which by the way don't work under Netscape 4.0.2b8 under
FreeBSD...so much for Java uber alles), just report the right number:
"the sum of the transitions of all prefixes from a neighbor
since the start of the sample period"
More information about the NANOG