Over-utilisation of v6 neighbour slots

[Matej Gregr]

Hi Phil,

>  1. Has anyone else run into this sort of thing (neighbour table
> exhaustion) and what kind of approach did you take to solving or
> ameliorating it? DHCPv6?

We run to the same problem as well. Not on wireless network, but on
large Ethernet campus. The problem is, that we are stacking several
switches to one virtual. The benefits are great, but the problem is that
the cache size is not combination of the physical switches size, but is
the size of one physical switch. This is understandable, but you will
face the same problem as on the wireless network - cache exhaustion.

Decreasing the exhaustion time was the first solution, but than we have
to move several VLANs to another switch, to load balance the caches.

>  2. Does anyone know if Apple (and other vendors) understand the
> negative consequences of their aggressive rotation of IPv6 privacy
> addresses, and are going to address it?

Probably not, because Windows behaviour is the same. Not so aggresive,
but this is because of personal computers are used in different way than
mobile phones.

>  3. Does anyone know if any equipment vendors have more intelligent
> strategies for handling this kind of situation - LRU expiry of v6
> neighbours at >90% util rather than self-destructing FIB overflow, for
> example ;o)

The HP/H3C we are using will deny creation of a new record which is also
quite bad. Everythink works for already connected clients but new
clients fail. It's "great" for throubleshooting.

> [We're aware the sup720 is old, but it seems like this could be an issue
> even for more recent devices at sufficient scale]

Absolutely, we tested switches of several vendors and the problem is the
same. The cache size for IPv6 is always smaller than IPv4 cache size and
this is a problem, because even in the perfect use case, you need twice
as big IPv6 cache as IPv4 - link local + global addresses.

Regards,
  Matej


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2909 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20131022/1a61bb1d/attachment-0001.bin