Is IBNS 2.0 a requirement for various functionality of ISE/DNAC/SDA?

[Nadav]

Hi everyone,

At present I'm not using IBNS 2.0 for authentication control on access ports, the legacy model serves us just fine. No need for more granular authenction policies or critical VLANs. 

With that said, maybe there is certain functionality with ISE/DNAC/SDA which requires IBNS 2.0 in place to function. Something that without IBNS 2.0 you can't implement successfully.

Any chance you're familiar with such use cases? I haven't found something like that in the documentation.

Edit 14/02/2020:  I feel as though the answers in this discussion deal more with that IBNS 2.0 is newer and newer is better, rather than any limitations with the specific applications I mentioned. I haven't seen a single use case dicussed here where it would limit basic 802.1x functionality or stand as a prerequisite for migration to SDA/DNAC.

I'll take that as an implicit "it's fine as long as it suits your use cases".  Thanks to everyone for their thoughts :)

[Damien Miller]

When I was first introduced to the SDA beta back in 2017, it had IBNS 1.0 config, and I remember it being in there at least until 2018.  It's been a while since I really dug in deep to it, but I believe that as of 1.2+ the configuration switched to IBNS 2.0.  

If you deploy SDA, you get what DNAC pushes.  There is a benefit to this too because Cisco does a lot of automated testing of network device code and solutions.  Pushing common configs cuts down the number of bugs that should make it to the field.  

So migrating/adopting SDA will bring IBNS 2.0 these days.  

[Nadav]

Well if something is managed by SDA, the actual underlying configuration is less of a worry as long as it works as expected. Any ideas if ISE or DNAC require any IBNS 2.x for functionality?

[Marvin Rhoads]

All of the basic 802.1x and MAB functions will work fine with IBNS 1.0.

Recently I have seen the TAC tell customers that certain IOS bugs with IBNS 1.0 functionality will not be addressed because the development effort is all in IBNS 2.0. So if you're leveraging features such as device classifier (for profiling) and/or working on newer platforms such as Catalyst 9k, I'd strongly recommend considering IBNS 2.0. It's a bit of a hurdle to learn at first but in the long term it will serve you better.

[Mike.Cifelli]

I agree with @Marvin Rhoads & @Damien Miller .  Having a good understanding will be beneficial if you do decide to migrate to SDA.  When referring to edge nodes (access infrastructure), DNAC will configure the devices via the out-of-the-box templates that you use to assign to your fabric.  Some items are changeable via DNAC admin gui.  However, something to note from my experience with SDA over the last 1.5-2 years is that while it is nice to have the templates I have found our team making several changes consistently via the template editor.  Note that these "things" will vary per environment based on requirements.  We were fortunate enough to run new fiber in our campus so that we could build out SDA while keeping it completely separate from the legacy network.  Not sure of your end goal, but there are a handful of technologies that are utilized as components in the SDA solution such as LISP, BGP, Trustsec, whatever underlay routing protocol you use (we use ISIS), vxlan, and others.  I would recommend engaging your reps, and gaining a solid understanding of SDA in general.  HTH!