Recently, on our core switch (also our layer 3 router) we regularly see a high cpu load. This cpu load is the cause of packet loss and bad connections. This is happening for almost two weeks now.
Network inspection shows us that there is a flood of IPv6 Neighbor Advertisements originating from what seems the same IPv6 Address but from different Hardware (MAC) addresses. In each second there are up to a 1500 packets per second advertising the same IPv6 address. See below for more details about these packets.
Tracing the MAC addresses to their owner learns that all clients are using Windows 8 with Hyper-V and that they have an External Virtual Network bound to their Wireless/WiFi Network Adapter. Removing this virtual network stops sending those packets. Because multiple hosts are involved it may be necessary to remove this network on all of these hosts.
As is visible in the following packet dump this is an unsolicited neighbor advertisements, resulting in an update in the neighbor table on our IPv6 router. These updates are probably the course of the high cpu load.
Frame: Number = 188594, Captured Frame Length = 86, MediaType = ETHERNET
+ Ethernet: Etype = IPv6,DestinationAddress:[33-33-00-00-00-01],SourceAddress:[00-24-D7-76-C4-68]
- Ipv6: Next Protocol = ICMPv6, Payload Length = 32
+ Versions: IPv6, Internet Protocol, DSCP 0
PayloadLength: 32 (0x20)
NextProtocol: ICMPv6, 58(0x3a)
HopLimit: 255 (0xFF)
- Icmpv6: Neighbor Advertisement, Target = FD00:4953:4E4C:20:6F7:E4FF:FE4A:2267
MessageType: Neighbor Advertisement, 136(0x88)
Code: 0 (0x0)
Checksum: 3593 (0xE09)
- NeighborAdvertisementFlag: 536870912 (0x20000000)
R: (0...............................) Not router
S: (.0..............................) Not solicited
O: (..1.............................) Override
Type: Target Link-Layer Address, 2(0x2)
Length: 1, in unit of 8 octets
Because the target address is the same in all packets but the MAC address changes, it seems that there is something on the hosts that is forwarding/proxying these packets (and only those packets) back to the network it came from, but only after changing the targetlinklayeraddress in the advertisement. This process is described in RFC4389.
One host with this problem on the network will not resolve in a flood. Only when more hosts with this issue are active the flood occurs. It seems that two or more hosts are required to magnify the packets send by the others.
Hyper-V on Windows 8 makes use of a Network Bridge in software to enable the use of wireless network adapters. Is this the cause of all those packets?
Some of the hosts also had Windows Phone 8 SDK installed. The installation of this SDK enables some networks in Hyper-V. Maybe some configuration change is made enabling the proxying of those packets back to the network they came from? After removing the SDK the hosts are still transmitting too much packets.
The first occurrence of this flood was on the day after Microsofts update Tuesday. Is it possible that one of the updates may be the cause of this? There is one mayor update KB2770917 which includes updates to DHCPv6 and NDIS librarys. Again, removing this update does not solves the problem.
Updating our switch/router to a higher level of firmware may lessen the impact, this is something I can try. But it shall not solve the problem, the switch is not the source of the packets.
Hopefully somebody recognizes this issue. All ideas are welcome.