Problem
You are having six 5508's running 7.0.116 code.
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.
Solution
You are hitting his proble due to the following bugs causing H-REAP packet leak on the WLC Network:
Bug-1
- 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.
This is documented in Cisco Bug ID :CSCtx95544
Bug-2
- 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.
This is documented in Cisco Bug ID :CSCtz35153
Bug-3
- Multicast packet from client is sent to WLC when the client associates
Symptom:After client deauth from session timeout, a multicast packet from client is getting sent to the WLC when the client associates
Workaround:ACL or dummy interface on the WLC tied to that WLAN preventing multicast traffic
This is documented in Cisco Bug ID :CSCtz35198
The workaround is to turn on IGMP snooping
Summary
To resolve this issue of webauth packet leak, IGMP snooping needs to be enabled on the WLC and applied the ACL's on the management interface.
