3

I recently noticed that 3 out of 4 Unifi APs kept reaching 100% CPU usage. When I jumped onto the networks and took a Wireshark capture I noticed 1000s of these packets being sent in just a matter of a few seconds.

11.013029000    fe80::ca5b:76ff:fe64:143a   ff02::1:ff76:6414       ICMPv6  86          Multicast Listener Report

Internet Protocol Version 6, Src: fe80::ca5b:76ff:fe64:143a (fe80::ca5b:76ff:fe64:143a), Dst: ff02::1:ff76:6414 (ff02::1:ff76:6414)
    Payload length: 32
    Next header: IPv6 hop-by-hop option (0)
    Hop limit: 1
    Source: fe80::ca5b:76ff:fe64:143a (fe80::ca5b:76ff:fe64:143a)
    Source SA MAC: c8:5b:76:64:14:3a (c8:5b:76:64:14:3a)
    Destination: ff02::1:ff76:6414 (ff02::1:ff76:6414)
    Source GeoIP: Unknown
    Destination GeoIP: Unknown

Hop-by-Hop Option
    Next header: ICMPv6 (58)
    Length: 0 (8 bytes)
    IPv6 Option (Router Alert)
        Type: Router Alert (5)
        Length: 2
        Router Alert: MLD (0)
    IPv6 Option (PadN)
        Type: PadN (1)
        Length: 0
        PadN: <MISSING>

Internet Control Message Protocol v6
    Type: Multicast Listener Report (131)
    Code: 0
    Checksum: 0x6513 [correct]
    Maximum Response Delay [ms]: 0
    Reserved: 0000
    Multicast Address: ff02::1:ff76:6414 (ff02::1:ff76:6414)

I can't ping or resolve either the source or the destination IPv6. I've tried running:

arp -a | findstr <MAC>

To see if I even have the MACs in my arp cache but I get nothing. I've wandered all around the office connecting to each of the APs specifically running the same commands.

I've read that these messages could be the result of a dying NIC. But I'm not sure how to verify/validate that or where to even start now.

Has anyone ever seen this behaviour before and resolved it? What are these messages, and how do I mitigate them? I'm very fascinated by this but also I'd like my APs to stop crashing! :P

5

You wouldn't be looking for ARP entries with IPv6, since ARP doesn't exist with IPv6. You would be looking for IPv6 ICMP Neighbor Discovery cache. IPv6 MLD messages are used similarly to IPv4's IGMP for Multicast group membership management and also with Neighbor Discovery.

If all these are coming from the same source MAC address then I'd start by tracking down that host.

The Multicast DST address it's sending to is a solicited Node address, but 1000s over a short time period is not normal behavior.

The Source MAC seems to be linked to

C8:5B:76 LcfcHefe LCFC(HeFei) Electronics Technology co., ltd

| improve this answer | |
  • 2
    Thanks for the insightful response. Just finished figuring this out. We logged onto our switch to see what port corresponded to the MAC and traced it back to a physical machine on the network. Oddly, the MAC and IPv6 didn't match when we ran an ipconfig but, unplugging the cable on the switch side still disconnected it. After a reboot the network cleared up and CPU went back down. :) – Tikiyetti May 15 '18 at 17:18
  • I was about to say the same. For linux, the command is ip -6 neigh show Arp will only show v4 data (i.e. ip -4 ...) Switch CAM tables are a better way to trace it, as long as it's a wired system causing it. Chasing down an errant wireless device can be a pain. – Ricky May 15 '18 at 19:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.