> As I understand the problem, your interpretaion is correct. Only the > worst case de-aggregation of /16 into 256 /24s would cause every > even/odd /24 to find a new next-hop. Most cases would be somewhere > between x0 (same next-hop) through x8 (your example) and up to x256 > (worst case).
Yes it is definately more of a concern with different next-hops for prefixes within some aggregated space. My gut feeling is that cam implementation is going to be an issue, as I think ordering of aggregated prefixes in the cam and how to handle non-matching prefixes in an aggregate is a problem for existing implementations. > Maybe someone could look at historic instability (from BGPmon?) the past > couple of years and model how FIB aggregation would behave? I've just finished the code for parsing mrt indextablev2 dumps. I have to come up with some algorithm to choose the most affected ASs based on prefixes and neighbor ASs. Any ideas appreciated!! Once that is done and I have a few ASs to concentrate on, I was planning to pump in real bgp update information (have to 'guesstimate' how it will be seen by those ASs) from routeviews. This should give a pretty good real-world answer to the question of aggregation in tcam, for the worst case scenarios at the moment. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
