Security

We have seen issues with keeping our default gateway on an upstream network device and also having an L3 interface on the same subnet on the controller.  I have the default gateway for our guest users on another device that does the routing.  The VLAN is trunked layer 2 to the controller.  In order for the captive portal to work you need a L3 interface on the controller.  It seems that when this is done clients function for some time and then spontaneously lose the ability to pass traffic but are still connected to the SSID and are in the correct role on the controller.  I issue an arp -a when this starts and noticed both L3 interfaces in the arp cache.  I then issue an arp -d to clear the arp cache and things instantly work.  After the arp -d is issued only the default gateway .1 shows in the arp cache and the controller L3 interface .11 is gone.  I am wondering if others are implementing in this fashion or if they are doing L3 at the controller.

Thanks

jmadej, 

Does this issue happen on all the client devices or any specific devices? 

Do you mean that the client is browsing the web and all of a sudden they are unable to load any webpages? 

Are they able to ping the default gateway when this happens? 

When you say that the client is not able to pass traffic, do you see any sessions on the controller? 

"show datapath session table <client-ip>" 

I can not say for sure if it is all clients but I can say it is a large amount.  Yes, when this happens suddenly all web browsing stops as well as the constant ping I have running.  The controller still shows sessions in the session table but the traffic cannot reach the client.  The firewall with the default gateway has an incomplete ARP entry when this happens.  After issuing the arp -d command on the client the firewall gets a complete arp entry and communication is restored.  The arp timeout on the firewall is 30 minutes.  The real question is why the FW cannot arp and get the client IP.  They cannot ping the gateway because it is on a FW that does not respond to ping. 

Please open a support case for this issue as it might be tedious to resolve it over the forums. 

Thanks, 

--

HT 

This was resolved by removing BCMC optimization from the L3 interface.  Enabling bradcast-filter all and broadcast-filter arp on the VAP supposedly has the same result in helping to recuce broadcast traffic.  When these settings are applied to the VAP you must also enable broadcast filter