Naive IPv6 (was AT&T UVERSE Native IPv6, a HOWTO)

joel jaeggli joelja at bogus.com
Wed Dec 4 21:26:16 UTC 2013


On 12/4/13, 12:58 PM, Brian Dickson wrote:
> On Wed, Dec 4, 2013 at 3:48 PM, Christopher Morrow
> <morrowc.lists at gmail.com>wrote:
> 
>> On Wed, Dec 4, 2013 at 3:43 PM, Brian Dickson
>> <brian.peter.dickson at 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
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131204/4fd96345/attachment.bin>


More information about the NANOG mailing list