On 29 April 2016 at 22:25, Nick Hilliard <nick@foobar.org> wrote:
Baldur Norddahl wrote:
With two uplinks that is highly unlikely to the point of being impossible. There is no topology change upstream that can cause a situation where it is not possible to do a high degree of aggregation of the full default free routing table before loading it in the FIB.
which is why I qualified this in a previous posting:
The more paths you receive from different sources, the more likely it is that this list of 120k "superfluous" prefixes will converge towards zero.
Agreed that small numbers of paths are most unlikely to create the conditions for this problem to occur.
I agree that a larger number of peers makes the situation more complicated. It might warrant more studies. Your thesis is that there might be a problem, but mine is there likely is not. Let me argue why. We can consider networks of various sizes: 1) the dual homed network with full tables 2) the lightly peered ISP with more than two full tables 3) the well peered ISP 4) tier 1 backbone provider Each of those might experience different gain from the proposal and indeed it is likely that the backbone provider would not be interested in the solution no matter what. Even so the proposal could help deliver considerable cheaper hardware solutions to say #1 and #2 class providers. We already agree that the #1 class provider will not see an external event that can explode the number of needed FIB entries after compression. The #2 class provider is not much different. The number of routes he takes in as peering routes as opposed to transit are few. If he runs his network with proper max routes on every BGP session, there is nothing a free peer can do to wreck havok. Any entity with say max routes 50 can only break up a max of 50 of your optimized FIB entries and while that can cascade such a /16 breaks into a series of /17, /18, /19, ..., /24 that will never add up to anything that is a problem. In any case the real problem here will be a rogue peer injecting fake routes into your network. Can the more than two transit providers with full tables become a problem? No not really. These guys are all sending mostly the same routes to you and anything large happening will be reflected on all your transits. There is also the point about the weekly routing report: BGP routing table entries examined: 593320 Prefixes after maximum aggregation (per Origin AS): 217357 Deaggregation factor: 2.73 Unique aggregates announced (without unneeded subnets): 290159 Now can you really say any one entity has the power to magically make all that aggregation disappear just so he can crash your network? I will put that in the "impossible" and "the net already crashed long before that" categories. There is a trend that some network are deaggregating their prefixes. Why not use software to aggregate that right back to what it ought to be before loading the routes into FIB? According to the above stat, that would save at least half the FIB memory and make some routers able to handle full tables for very much longer (possible forever). Regards, Baldur