ISE Wired Dynamic VLAN assignment with DHCP re-new after new VLAN

[MS-JK]

The Setup:

Cisco ISE 3.x, cisco wired switch 3850. I have a port that is configured with default VLAN X and this VLAN X is also setup to get DHCP IP from 3rd party DHCP server. This switch/port is also configured for wired Dot1x. I have a MAB policy on ISE that assigns certain end-devices into specific VLAN.

The Problem:

Device A connects to the port on the swtich. It first is connected to the default VLAN X. During this time, it receives DHCP IP from the server and also undergoes Authentication/Authorization for dot1x. After successful MAB auth/authorization Cisco ISE send to the swtich to change the port VLAN to VLAN Z. This change is successful and the port is now in new vlan. BUT the problem is, the end-device that previously received DHCP for VLAN X has no idea that VLAN changed on the switch port and it never renews the IP of the new VLAN Z. So its basically stuck with wrong IP after the new dynamic VLAN.

Solution:

Is there a way to force DHCP release from the switch/ise somehow after the dynamic VLAN is assigned?

Thank you.

[Damien Miller · Accepted solution]

You've run across a problem that ISE itself can't fix because it's an endpoint problem and not an ISE problem. 

In days gone past there was an applet that you could run with a CWA redirect that would force the endpoint to do a dhcp release/renew, but this only worked for workstations, and support for the app was dropped by all browsers. Headless endpoints were never able to use this workflow. 

The partial solution that works in most cases is to not allow the endpoint to get an IP address at all until you assign a vlan. This typically results in the endpoint continuing to try and get an IP address until ISE has finished. I would call it a partial solution because there are endpoints with poorly designed network stacks that just give up if they can't get an IP quick enough after link up. Healthcare and OT networks are plagued with these sort of poorly written stacks. 

[Aref Alsouqi · Accepted solution]

I agree with @Damien Miller , this issue can't be fixed by ISE since it is not related to ISE itself. I think the solution for this in my opinion would be one of these:

- Move those devices from MAB to dot1x, doesn't necessarily have to be using certs, it could be EAP-PEAP (username/password)

- Set a parking VLAN on the switch ports with no DHCP scope, this will avoid the dummy devices to get an IP until they are moved into the final VLAN.

- Reduce the DHCP lease duration of the initial VLAN to something very minimum. This will trigger the DHCP renew process soon so the dummy devices will then get an IP from within the new VLAN.

[MS-JK]

How about going the 'macro' way? Possibly due a macro on switch that is triggered by ISE authorization profile?

Something to this effect: https://community.cisco.com/t5/network-access-control/solution-for-change-of-vlan-for-wired-guests-using-smart-port/m-p/3432614?attachment-id=147806

I've created the macro on the swtich but somehow it isn't triggering it. Wondering if anyone has used macro's with ISE and what limitation it presented. It would be somewhat pain to have it deployed on 1000s of switches.

[Massimo Baschieri]

As far as I know micros do the job by cycling physical ports, that's surely going to fix the dhcp issue, but if you have more than one host connected, ip phones for example, it does a mess