Showing results for 
Search instead for 
Did you mean: 
Community Member


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.


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.

This is documented in Cisco Bug ID :CSCtx95544


  • 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


  • 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


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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers
Quick Links