[193443] in North American Network Operators' Group
Re: Questions on IPv6 deployment
daemon@ATHENA.MIT.EDU (William Herrin)
Tue Jan 17 18:53:35 2017
X-Original-To: nanog@nanog.org
X-Really-To: <nanog@nanog.org>
In-Reply-To: <FA13671D-D2B4-4EE3-B16C-608DC56D997A@steffann.nl>
From: William Herrin <bill@herrin.us>
Date: Tue, 17 Jan 2017 18:53:04 -0500
To: Sander Steffann <sander@steffann.nl>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On Tue, Jan 17, 2017 at 6:06 PM, Sander Steffann <sander@steffann.nl> wrote=
:
> One thing that comes to mind is that it seems that some routers only have=
limited space in their routing tables for prefixes longer than a /64. If y=
ou would configure a /127 on the link but push the /64 to the routing table=
then you might both avoid ND Cache exhaustion and avoid the limitations on=
longer-than-/64 prefixes.
Hi Sander,
IIRC, the problem was that some routers could only fit the first 64
bits in the TCAM so routes longer than /64 fell out of the fast path.
That was about half a decade ago. No idea if anything modern still
suffers from this.
That would impact every route in Matthew's proposed solution: the
loopbacks from the infrastructure /64 and the /127's from otherwise
unpopulated /64's. Because programmatically those /64's don't have one
prefix, they have two: the /127 for the link and the implicit null
route for everything else. The router has to honor the implicit null
route so it can't aggregate the /127 to /64 and keep it in the fast
path.
Regards,
Bill Herrin
--=20
William Herrin ................ herrin@dirtside.com bill@herrin.us
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
