You have 2200 1142 model AP's all running in H-REAP mode.
You have about 22000 wifi clients.
The WLC's are configured with a single management interface IP address
and the AP's are all in remote locations connected over a WAN.
You are finding that the WLC's are initiating packets with the source mac-address of each
client because the 6500 core switch that all your WLC's are connected to have a mac address
table of about 18000 mac entries. 16000 of those are client mac address.
This will be a major problem when you migrate to nexus switches that onlysupport 16000 macaddresses.
You need to find out why this is happening and need to stop the WLC's from making the
6500's learn 15000 mac address. You see no reason why the WLC needs to do this.
You are hitting his proble due to the following bugs causing H-REAP packet leak on the WLC Network:
Timing delay on HREAP locally switched WLAN's between WLC moving HREAP locally switched client into RUN state and the AP learning about the client status moving into RUN statecauses client packets to egress wlc. Hence the switch updates its mac address table with client entries from locally switched WLAN's.
Workaround: Create a dummy interface and tie the WLAN to that interface with a dummy VLAN that does not exist on the switch.
Setup an interace ACL on the management interface to block any traffic egressing the WLC. This is a deny allACL for bi-directional from any ip address. Once this is in place we should not see any
client packets egress the WLC after they have been placed into the RUN state by the WLC.
After the ACL in place any egress traffic for HREAP clients on your network should only be for clients stuck in the webauth_reqdstate.We will need a client from any of your remote networks connecting to your HREAP local switching SSID. Technically if we do not accept the webauth credentials for this client we should see the WLC place this client in the webauth_reqd state for 5 mins. This should give us enough time to analyze a packet leak for clients in this state.