Port bounce during CWA process

[bikespace]

Hi all, Is it possible to issue a port bounce during guest flow process? After dynamic VLAN allocation I need to bounce the port so that DHCP renew is performed on the new VLAN. Doesn't seem to port bounce at present, but I'm guessing that the port bounce setting for CoA in profiling is not relevant in this situation? I can't rely on the java app to renew IP address, it's clunky/flakey at best. Cheers.

[nspasov]

It is not possible to issue a port bounce during CWA. And even if it was possible it would not solve your issue. Think about it, if you issue a port bounce after a successful authentication and VLAN change, the session would terminate and it would start all over again. 

I think what you are looking for is located under the guest portal settings: Administration > Web Portal Management > Multi-Portal Configuration > Name_of_guest_portal > Operations > all of the way at the bottom you can find "VLAN DCHP Release" option.

Thank you for rating useful posts!

[bikespace]

Yep, understand the process, I'm just amazed that Cisco hasn't found a solution to it. The VLAN DHCP Release option seems to be a sticking plaster which fixes some Windows devices. Has to install an applet which requires administrator access, and only for Windows? Not a viable solution for guest networks.

In my mind, I'd imagined that Cisco would have designed in a mechanism to allow the port bounce and allow some continuity of session, even if it is ISE that correlates the old and new session.

Without that, unless I'm missing something dynamic vlans is not useable for guest access.

I've moved to a single vlan with DACL's and we'll get around the original reason for a different VLAN/VRF.

Really hope Cisco improve this feature at some point.

[nspasov]

I hear your frustration but IMO VLAN changing is somewhat of a legacy/uncool way to do things :) There are just too many issues with it such as the one you are facing with. Too many devices out there don't support a VLAN change (printers, badge readers, etc) and I honestly don't see Cisco being able to put in a place a solution for all types of devices and scenarios. That is why what you have with DACLs is really the way to go. If more segmentation is needed and/or you want to get really fancy you can always start using TrustSec/SGA/SGT

[bikespace]

From what I've seen so far most devices do support change of VLAN. We already use it in many places for MAB and dot1x, but of course for these there is only EAPOL until the VLAN is dynamically allocated, and the device picks up its new VLAN, picks up DHCP, and all is well.

It just seems that Cisco has not bothered to implement. It's a little annoying that dynamic VLAN's are sold as being a working solution. It clearly doesn't work for CWA. You might get it working in the lab for a subset of clients but in the real world it doesn't work.

I find it hard to believe that there is no method of allocating wired users to a subnet based on CWA login credentials. This becomes even more crucial when their allocated VLAN is dropping them in to a VRF further in to the network.

[Saurav Lodh]

I agree with Neno, the switchport bounce will result into new session, authentication again