BGP route flap damping

The problem takes place five or six AS far from me… Where I can’t do
much. I still can’t reach some prefixes announced by large ISPs.

>Last week we received a DoS attack which got down my BGP connections
>my upstream providers (for three or four times I believe). I also
>that event caused some routers to suppress my BGP announcement.

We have been conducting simulation studies to quantify
the impact of BGP peering session attacks and how RFD
could severely amplify the outage periods.
I can share some insights we have developed which
I hope are helpful although they may not directly address
the problem you are experiencing.

Please use this link to our BGP attack simulation work
(at NIST) for additional details:

One point to be noted with certainty is that if your BGP
router loses its BGP session with a peer
and when the session gets restored shortly thereafter,
the peer then resets your RFD penalty to zero.
Hence, even if the attack events happen multiple times,
RFD penalties for prefixes in your AS at your peer are
not incrementing and your peer does not put
your BGP router or prefixes under RFD suppression.
However, your peer’s peers and other ASs upstream
(who are more than one hop away from you)
could place the prefixes in your AS under RFD suppression.
When the DOS attacks that caused the BGP session
to be lost multiple times have subsided, then the RFD penalty
will decay below the RFD reuse threshold within
a few thousands of seconds. The half-time of the exponential decay
is typically 900s and hence it takes a few thousands of seconds
for RFD penalty value to fall back below the RFD reuse threshold.

The BGP speakers that are two or more hops away from your
BGP speaker should restore all prefixes in your AS in their routing
tables within that amount of time (about 2000s to 4000s) after
the attacks have subsided.
From the experimental results in paper we have written
(click on the link noted above for a pdf copy),
it can be seen that even under large scale attacks, the
unreachability between ASs and prefixes lasts for a few
thousands of seconds (after attacks have subsided),
and all AS-prefix routes are restored back to
their stable paths after that amount of time.
If the unreachability in your case has lasted for hours or days after
the attacks have happened, then it is not clear what
may have caused that. It may be something that is due to operational
procedures with some providers that are extraneous to the
normal operating principles of RFD (just a thought).