On 12/4/13, 12:58 PM, Brian Dickson wrote:
On Wed, Dec 4, 2013 at 3:48 PM, Christopher Morrow <morrowc.lists@gmail.com>wrote:
On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
Except that we have a hard limit of 1M total, which after a few 100K from
where does the 1M come from?
FIB table sizes, usually dictated by TCAM size. Think deployed hardware, lots of it. (Most instances of TCAM share it for IPv4 + IPv6, with each slot on IPv6 taking two slots of TCAM, IIRC. And a few other things also consume TCAM, maybe not as significantly.)
(Newer boxes may handle more on some network's cores, but I don't believe it is ubiquitously the case across the DFZ.)
Table size growth has conveniently not outstripped the growth of available fib sizes in a quite a long time. There doesn't appear to be much reason to believe that won't continue baring us coming up with novel ways to blow up the size of the DFZ. Managing to aggregate in some way that respects your internal topology and addressing plan without blowing up your route count is an exercise for the reader. It's somewhat facile to relate fib size to the bounds of what ternary cam chips you can currently buy since not all routers use cams for longest match lookups.
Brian