Optimal IPv6 router

Joel jaeggli joelja at bogus.com
Mon Feb 6 15:35:39 UTC 2012


On 2/6/12 06:48 , Glen Kent wrote:

> One example that comes to my mind is that a few existing routers
> cant do line rate routing for IPv6 traffic as long as the netmask is
> < 65.

I'm sorry that's  bs. It's trivial to partition a cam in order to do
/128s in a single lookup. that's actually the worst case scenario, a
more efficient packing will result in lower power consumption and memory
use. potentially that results in multiple lookups which in no way
implies you're not going to meet your pps target.

> Also routers have a limited TCAM size for storing routes with masks
> > 64. These routers were primarily designed for IPv4 and also
> support IPv6.

All routers don't use tcams for fib lookups. M T MX devices do not use
cams for fib for example.

limited cam partitioning schemes exist in ip4 as well,
big cams have a cost power wise, and bom wise, parititioning them in a
way that meets the developers view of the distribution of route lengths
can be beneficial and be used to build products suitable for lots of
roles but probably not being a internet core router. standard juniper
ex8200 line cards for example are just peachy for a datacenter but not
so much for a internet core device and the bom feature set and price
reflect that.

> I was wondering what we could optimize on if we only design an IPv6 
> router (assume an extreme case where it does not even support IPv4).

right now if I take a platform that uses a  large CAM like a force 10
e1200i ej line card, I can adjust the cam allocation to do basically
nothing but ipv6, given the default balance between ipv4 and ipv6 doing
so more that doubles the number of ipv6 routes I can expect to hold.

> Glen
>> 
>> Best regards, Daniel
>> 
>> -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP:
>> 0xA85C8AA0
>> 
> 
> 





More information about the NANOG mailing list