On 15/09/16 20:57, Chris Evans wrote:
Does anyone know the maximum amount of IPv6 neighbors an ASR9K platform
(don't care which modules) can support?

Disclaimer: I'm not familiar with the ASR9k, but from a general Cisco perspective:

On Cisco kit, a layer3+2 neigbour typically consumes a host route from the FIB, an adjacency from the adjacency table, and a MAC address from the layer2 FDB (if appropriate)

For example an IPv4 host in a subnet will consume one /32 from the routing table, an adjacency for the target of the /32, and on SVI-style interfaces a MAC entry for the destination MAC address (not used on layer3 ports/sub-ints)

An IPv6 neighbour will typically consume a /128 per address, adjacency and optional MAC entry.

Assuming the ASR9k works the same way, you'll want to look at the FIB size, whether the partitioning between sizes of entry (v4, v6) is static, the adjacency table size and optionally the MAC table size. As such this is almost certainly linecard/scale license dependent.

Vendors play annoying tricks with these numbers. You've got to watch out for "can support 64k IPv4 or 32k IPv6 hosts" which is minimally true on a 64k 72-bit TCAM FIB platform, but only if you no actual non-host routes on the box, and it's either/or.

If I understand the info here:


...then you're looking at a comfortable 64k IPv6 neighbours, assuming 2 addresses per neighbour (permanent and privacy) in the default profile. However be very careful about assuming 2 per neighbour - various platforms (iOS is a particular offender) cycles privacy addresses very, very rapidly.

It's a complex question, and I'd look carefully at the current utilisation and your planned growth before deciding. Consult with the vendor - or better yet, put mandatory requirements in an RFP - before paying money!

Slightly OT: It is a matter of considerable irritation to me that the controller platforms are transparent layer-2; if they terminated the traffic at layer3 it would avoid maintaining per-host adjacency state in two places (on the controller and in the upstream layer3 first-hop).

cisco-nsp mailing list  cisco-nsp@puck.nether.net
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to