Background
I am somewhere that blocks Dropbox downloads, so I can't see the captured traffic, but I'll go on the assumption these were 64-byte ethernet multicasts.
Let's do some math to see how much traffic you're permitting...
A 64-byte frame is 672 bits (including 8 bytes for Preamble/SFD, and 12 bytes for IFG)...
8*(8 + 12 + 64) = 672 bits
That means line rate Gigabit Ethernet 64-bytes frames is about 1.488Mpps...
(1000000000 / 672.0) = 1488095.24 pps
What does this mean to you? Well your current storm-control configuration throttles traffic at 5% of line-rate, so you're allowing 74.4kpps of traffic to hit your switch before storm-control kicks in. 74.4kpps * 64-byte frames is 38Mbps, which is right at what your graphs show:
Answer
So, the bottom line is that you're allowing too much traffic to hit the switch CPU, which is why the CPU utilization was high. 74.4kpps is really too much to allow any switch CPU to process.
Assuming these stations shouldn't be sending a lot of multicast or broadast, the simple answer is to throttle your traffic like this...
! Note that broadcast traffic has the ethernet I/G bit set
! which means it is also classified technically as a multicast
! for storm-control purposes. Therefore set your broadcast limit
! a little lower than your multicast limit
storm-control broadcast level 0.4 0.3
storm-control multicast level 0.5 0.3
Now storm-control kicks in when a port sends 6kpps of broadcast (0.4% 1GE line rate) or 7.5kpps of combined multicast / broadcast (0.5% 1GE line rate).
FYI, it is probably worth looking into Control Plane Policing, which protects the switch CPU against several ports ganging up on it. Keep in mind that CPP can be complicated to get right, so it's a good idea to test well before you roll it out in your environment.
There are two types of wireless extenders. First would be an extender that uses some sort of mesh technology. This type of extender is typically only found within an enterprise deployment and will establish a connection to the network in addition to also acting as an AP. Often a mesh device will use two radios, one providing the "back haul" and one to provide client access.
However most devices referred to as wireless extenders fall into the second group and are actually just repeaters. When a wireless repeater receives (or "hears") a frame, it will then transmit a copy of that frame into the air. Naturally it will only hear frames on the channel to which it is configured, and typically will also be configured to only re-transmit frames for a particular SSID or BSSID.
Since RF is a shared resource, this repetition of data can result in a significant loss of performance. To reduce this impact, some repeaters are smart enough to not repeat frames where it hears both the frame and the acknowledgement between the AP and client device, but others are not and will re-transmit all frames. Even if you are using a "smarter" repeater, if the client is too far from the repeater to be heard, all AP traffic will get repeated leading to the same loss of performance.
When a device connects to that SSID, what exactly happens?
When a client device connects, it goes through an association process with the access point. If the client is out of range of the AP, but within range of the repeater, the repeater will re-transmit the client frames as well as the return frames from the AP.
How does the device know that base station and range extender are part of the same network and no third party can impersonate another range extender on the same network?
The device doesn't. When function as a repeater, the repeater itself doesn't really have any "identity" on the network (any management interface on the repeater is a separate matter). It is merely repeating the frames that it hears unchanged.
Even if a third party does place a repeater on in the area, this is not really a problem as the client device is associating (and establishing encryption) with the access point itself and not the repeater.
Then, what happens if the device moves around and signal strengths change? Is there some kind of renegotiation going on?
With most repeaters, there is no roaming or renegotiation. The client device will either see the frame from the original AP, the repeated frame from the repeater, or possibly both.
What does the range extender actually do? Simply rebroadcast whatever it gets from device and base station, or is it more intelligent than that?
See above.
Best Answer
Look at the actual hardware destination of the packet. Just because the IP was not a broadcast doesn't mean the hardware destination can't be. Functions like failover often operate via broadcast traffic (sent to ff:ff:ff:ff:ff:ff) which will be seen by every port on the subnet. If the destination is a mac address that is not your PC, and the switch should have learned it (i.e. that host is active) then the packet should not have been sent to you for the reason you stated. If you have the capture file, open it with a tool like Wireshark and you will be able to drill into a lot of detail.