A route flap is any routing change that would cause a change in the BGP table. This would include a change in MED. Large numbers of these at any one time is is a serious problem. At 30 updates per second, routing table updates are difficult. At 50 updates per second, HDLC doesn't happen. There is a daily cycle to the patterns.
ASes 174, 1237, 86, 1903, and 2149 are the top five flap sources per hour. Sprint notes that the problem probably originates from lines going up and down. It appears that all the flapping that PSI causes originates inside PSI.
This needs to be fixed. Line changes appear to be the biggest problem. Many of these are single updates. Sean argues that doing BGP with customers is evil, especially if the customer injects alot of updates. Sean argues that the router closes to the problem should generate an unreachable. Peter Ford argues that using static routes at the fringes, especially those that are temporary connections. CIDR is better.
Using a static route to a null interface to a block will generally work well, because when the temporary connection presents itself as a more specific route.
Alternatively, you could point the temporary net at the null interface as well. Proxy aggegation is good, but Sean says it does not work well. Another option would be to install a route with an infinite hold-down to deal with providers that won't fix the problem.
Vince Fuller cautions that using static routes or infinte-hold routes could cause large routing loops. Sean agrees. Peter Lothberg says that the problem really needs to be done at the peripheral edges. Sean says that in one particular case on ICM, Sprint is reengineering a connection that will reduce flaps by about 300-400 per second.
