Using IBNS 2.0 and interface templates for a default switchport config

[achim2]

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...

[MHM Cisco World]

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-x-series-switches/207193-Configure-IBNS-2-0-for-Single-Host-and-M.html

Check this 

MHM

[Arne Bier]

Hi @achim2 

Well summarised. I look forward to your worked examples.

I believe one of the caveats of NEAT was also that once NEAT had changed the interface config, and then someone issues a "wr mem" on the device, then the config is permanent. Or something along those lines. But interface templates are dynamic, which is what we want.

Interesting about the voice VLAN issue you mentioned - that's quite subtle.

I wonder if Cisco are putting any future effort into this.

[Philipp Staiger]

Hi @achim2,
did you get any further with this? I tould be really great to have some documentation on this.
Thanks

[Arne Bier]

@achim2 - I will second that. My use case is Meraki/Cisco Flex WAP on trunk interfaces that I would like to have on a secured switch interface, using such a dynamic template switch. But there cannot be any weird caveats - e.g. things that should not cause an impact:

• Someone issues a write mem while the template is active (downloaded from ISE and interface operating as trunk)
• Switch reboots
• RADIUS server unavailable and WAP/switch reboots - what happens? Auth Fail VLAN doesn't apply - we need Auth Fail Template
• Interface is in trunk template mode and someone clears the session interface - what happens
• Interface is in trunk template mode and someone does a shut/ no shut - what happens
• Interface is in trunk template mode and someone inadvertently configures additional lines of code in the interface (e.g. a description etc.)
• etc. (I can't think of anything else right now)

This concept must be bullet proof before I would consider using it

[achim2]

Hi @Arne Bier,

here are some thoughts regarding your concerns:

• write mem doesn't affect dynamic interface templates, since they are only applied to the session, not written to the running-config
• Switch reboot is no problem. After the reboot, the authentication and dynamic interface config via templates happens again
• Radius server unavailable while ap reboots is an issue, if not solved by the critical template. But the critical template cannot help all types of clients...
• If someone clears the session, the ap authenticates again and the template is pushed accordingly. That's no issue
• Shut/no shut on an interface is no issue. If the ap authentications after having booted, it authenticates again, if another client has been plugged in in the meantime, it authenticates as well
• Additional lines of config are allowed, but they will have an impact, e. g. a switchport access vlan to wake up passive clients. Description is fine, but can be overwritten by the interface template - only during the session uptime for sure

I have posted my lab configs above in response to Philipps post. I look forward to hear about your findings!

[achim2]

Hi @Philipp Staiger, sorry for the delay. I planned to not only post the configs, but also describe the whole process with authentication results. But this is a little bit too time consuming. That's why I send the configs first and look forward to read your results. ISE only sends the interface template name e. g. ap-flex upon the ap authentication, which is available from the common tasks list in the authorization profile.

[Arne Bier]

Wow - this is most excellent. So you go as far as protecting the switches themselves, by configuring them as supplicants?  If so, do you trust the setup enough to not break your switch connectivity?  Why do this, if the interfaces are all behind lock and key?

[achim2]

You are right: We don't use the supplicant config generally for all switches, but only for those who don't have physically secured uplinks, e.g. compact switches placed in an office as port extension. The goal is here, to not have unsecured trunk ports in the network. Compared with the old NEAT config, using templates doesn't require manual config on the downlink ports leading to a supplicant switch. The supplicant switch is like a flexconnect ap just an endpoint in the network which can be plugged in everywhere, and will be authorized and able to work without admin interaction. That's the idea...