Internet Edge Router replacement - IPv6 route table size considerations

Thu Mar 10 13:14:12 UTC 2011

On Wed, Mar 9, 2011 at 9:11 PM, Chris Woodfield <rekoil at semihuman.com> wrote:
> I think this is the point where I get a shovel, a bullwhip and head over to the horse graveyard that is CAM optimization...

The classic problem with any sort of FIB optimization is that you
can't optimize every figure on the spec sheet at once, at least not
without telling lies to your customers!  You can have more compact
structures which require more memory accesses and clock cycles to
perform look-ups, or you can have bigger structures which improve
look-up speed at the expense of memory footprint.  Since the market is
pretty much used to everything being advertised as "wire speed" now,
in order to continue doing look-ups at wire speed with an
ever-increasing number of routes in the FIB and with entries having
longer bit masks, you need more silicon -- more parallel look-up
capability, faster (or parallel) memory, or "optimizations" which may
not maintain wire speed for all use cases (cache, interleaving, etc.)

As the guy making purchasing decisions, I really care about one thing:
correct information on the spec sheet.  You may have noticed that some
recent spec sheets from Cisco include little asterisks about the
number of routes which will fit on the FIB are based on "prefix length
distribution," which means, in effect, that such "optimizations" are
in effect and the box should perform at a guaranteed forwarding speed
by sacrificing a guaranteed number of possible routes in FIB.

Relating to IPv6 forwarding in particular, this produces an
interesting problem when deploying the network: the IPv6 NDP table
exhaustion issue.  Some folks think it's a red herring; I obviously
strongly disagree and point to Cisco's knob, which Cisco will gladly
tell you only allows you to control the failure mode of your box (not
prevent subnets/interfaces from breaking), as evidence.  (I am not
aware of any other vendors who have even added knobs for this.)

If you configure a /64, you are much more likely to have guaranteed
forwarding speed to that destination, and guaranteed number of routes
in FIB.  What you don't have is a guarantee that ARP/NDP will work
correctly on the access router.  If you choose to configure a /120,
you may lose one or both of the first guarantees.  The
currently-available compromise is to configure a /120 on the access
device and summarize to a /64 (or shorter) towards your
aggregation/core.  I see nothing wrong with this, since I allocate a
/64 even if I only configure a /120 within it, and this is one of the
driving reasons behind that decision (the other being a possible
future solution to NDP table exhaustion, if one becomes practical.)

The number of people thinking about the "big picture" of IPv6
forwarding is shockingly small, and the lack of public discussion
about these issues continues to concern me.  I fear we are headed down
a road where the first large IPv6 DDoS attacks will be a major wake-up
call for operators and vendors.  I don't intend to be one of the guys
hurriedly redesigning my access layer as a result, but I'm pretty sure
that many networks will be in exactly that situation.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts