Best MAB practice for quiet endpoints with static IPs

[Walker]

We are in a closed mode environment. I am running into an issue where we have specific devices that do not support DHCP. The device will not kick off 802.1x/MAB process because it will not initiate any traffic on the port. The temporary workaround we've put in place is to go in and statically configure the correct vlan on that port and allow traffic both directions. This is generally done because the devices are added to our network management system and will send a ping to that device thus kicking off the 802.1x/MAB process.

Our normal operation is to have ports on a default VLAN, then DVLAN/DACL pushed out after successful authentication. My goal is to try and keep all of our configuration consistent but unfortunately this type of device changes that. I'm wondering what my options are and if it would be best practice.

I've also thought about using low-impact mode specifically for these types of devices, but that still wouldn't keep my configurations consistent and then we need to manage 2 different modes of operation.

What have the ISE experts seen out in the field and how did you manage this problem? 

TIH!

[Aref Alsouqi · Accepted solution]

If those devices won't send any frame to the switch to trigger the MAB process then I think you have no other options to workaround this.

[Arne Bier]

I second what @Aref Alsouqi said. NAC is a great security tool, but it only works if the endpoints are either intelligent (i.e. have supplicants) or are somewhat 'chatty'. Static IPs are almost tolerable, if (and only if) the device sends some gratuitous traffic like for example, an occasional ping (keepalive) or has a CDP/LLDP agent running. Basically, the device needs to send 'something' to give the switch an Ethernet frame to pass onto the RADIUS server.  I have seen devices that use DHCP that don't send a single packet, even if the switch stack on which they were happily connected, is rebooted. You would expect that any half-decent Ethernet client driver would notice a link flap and re-initialise the IP stack. But in this case the device was 'stranded' because the port was closed after the stack booted back up again, but the endpoint still hadn't sent a single frame.  The only workaround was to reboot the endpoint to force its software to initialise. Even the best NAC enabled switch in the world cannot handle that situation - it's a problem of the endpoint.

And in those situations you have to admit defeat and use other mechanisms like sticky MAC (port security) 

[Walker]

I was afraid that was going to be the answer. I believe my problem is that I didn't want to accept it. Thank you so much for the informed reply!