cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2502
Views
6
Helpful
12
Replies

Using IBNS 2.0 and interface templates for a default switchport config

achim2
Level 1
Level 1

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

Chapters: 00:00 Intro and Agenda 00:31 Adoption Barriers: Clients, Network Devices, Solution Complexity 02:16 ISE and Cisco DNAC Integration 03:05 Balancing Tools and Complexity 03:51 DNAC Automation 04:49 Intent-Based Networking and Software-Defines Access (SDA) 06:44 IEEE 802.1X 07:44 MAC ...
12 Replies 12

Arne Bier
VIP
VIP

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
Level 1
Level 1

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

@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

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!

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.

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?

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

Hey @Arne Bier , long time listener, first time caller. Seen a lot of your posts over the years here. I also stumbled onto this thread (and the preceding one that led to here) looking for a similar answer. 
Currently, I believe I have this deployed correctly. It is working using the defaulted Catalyst Center pushed config for OpenAuth. Testing it with a new office spin-up ATM.  Currently the flow works as follows:

1.) We plug in WAP to an access 1X port
2.) WAP authenticates successfully via profiling, and receives a Flex AP template that's local to the switch. (Pushed via Site Network Profile config in CatC) 
3.) Switchport gets converted to trunk port with associated native VLAN for the WAP
4.) WAP gets IP in that native VLAN, starts doing all the typical WLC-controllery stuff. 

So far in this new office we're spinning up, they haven't experienced any issues. They're on a time-lag, so that's a challenge. 

At the moment, the reason that actually brought me to this thread, was that we see two things with this workflow: 

1.) The switchport config still, as you mentioned and the original poster mentioned, *merges*, it does not *replace* existing config. As a result, the existing 1X template configurations still exist. 

This creates a scenario where you are also authenticating the wireless endpoints twice - once for "real" on the WLC and another "fake" entry on the switchport.

2.) That means you see all of the access-sessions on that particular endpoint twice - on the switch port, and recorded in ISE / another NAC as a wired endpoint (even though it's wireless.) 

I came to this thread to see if anyone else experienced this....doesn't seem like they have yet. I'm doing live testing with this now, so feel free to drop me a line if you have any q's or suggestions. 

My head is still firmly in the sand on this topic. Given all the challenges with this concept, it seems that it hasn't caught on in the mainstream. I think the IOS needs an extra command to make the session manager smarter in these situations. e.g. something like host-mode for Flex WAPs - where the session manager only cares about one MAC address. In fact, you could try host-auth. The problem with that, is that you can run into race conditions, where, if the switch reboots, and the first MAC address seen is that of a wireless client (and not the WAP management traffic) then you would kill/reject the session - and hence, kill the WAP. This happened to me on hypervisors attached to NAC interfaces and I thought I could use host-auth (and VMs piggyback on the activated session of the hypervisor traffic).

Whatever you do, it has to work 100% of the time and considering failure scenarios.

PSM
Level 1
Level 1

Hi @Arne Bier we have been using "host-mode multi-host " for a while and find it to be quit ok. Race condition issue only happens when session of WAP is cleared on the switch. In that case client mac address can come first and stuck in authentication. Apart from that, if switch reboots, access points also gets reboot ( Unless access point is having POE injector or external power adapter ). If a shut/no shut is performed on switch port then also AP got a reboot. In case of AP reboot it is always the MAC address of AP which appears 1st on the switch. 

@PSM Yeah in those scenarios, the AP would always get the first frame out because we wouldn't be seeing a broadcast (AP hasn't even come up yet) of any SSIDs for any clients to hit that could beat it in a race condition. 

I think the only issue now is just seeing the duplicated sessions in ISE on the wire, and also on the access-sess.