Hi all, I want to share my findings about IBNS 2.0 with interface templates and the idea to use this feature to have the same default interface config on all switchports in the network (except several uplinks for sure).
Main goal is: To allow not only client devices like workstations, printers phones etc. to be connected and authenticated without further admin interaction but also flexconnect access-points and compact switches which require special interface config to work properly.
Existing ideas and documentation:
1. The attached whitepaper is a "IBNS 2.0 Deployment Guide" from 2014. Wow, the feature is already 10 years old and still exists in all Catalyst switches? We should start using it!
2. Cisco officially shows how to use interface templates to change an interface config upon authentication, for example with a flex ap, which requires a trunk port instead of an access port like normal client devices: https://www.youtube.com/watch?v=ivfP1rJrtfU&t=1508s But what am I missing? The default authentication host-mode setting of an interface is "multi-auth". That's fine for normal client devices like workstations, printers, phones and so on, but not for network devices like flex aps or switches, which connect multiple devices to a network and authenticate themselves. So how do I change the host-mode to the suitable setting "multi-host" when an ap or switch is authenticated at a switchport?
3.NEAT is described as the method of choice to authenticate flex aps and switches. (https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_8021x/configuration/15-e/sec-usr-8021x-15-e-book/sec-ieee-neat.pdf) But what am I missing? NEAT changes the switchport mode from access to trunk, but it doesn't change the host-mode accordingly. Thus, we still need to have a different configuration on the interfaces which connect aps and switches.
Conclusion: There is no documentation or configuration example yet how to reach that goal. When I use the existing toolbox to configure network access control with 802.1x and mab with IBNS 2.0 and interface templates, it already works quite well. There are smaller issues for sure, which I list below. But the main issue is the question, if the whole plan is supported by Cisco. The answers are between "no, this will never work" and "good idea! Yes, it should work and should be supported". Thus, an official statement would be great, how a Cisco validated design looks like.
Issues:
- Voice-VLAN doesn't learn mac addresses e.g. from a wireless phone behind a flex ap, after switching a switchport from mode access to mode trunk
- Phones in the voice vlan cannot moved from behind a supplicant switch to the authenticator switch, since CISP keeps the mac address sticky at the downlink port towards the supplicant switch
I create and attach a config example as soon as possible...
