topic Re: ISIS on SDA in Software-Defined Access (SD-Access)

ISIS on SDA

JUANNN — Thu, 27 Aug 2026 00:00:44 GMT

Hello,

Why is IS-IS level-1 not used in SDA, instead of level-1-2? Why on an SDA site we need to mantain a level-2 adjacency and database too, if we can just have everything on the same area? In what production scenario do we benefit from level1-2 on SDA?

Thanks,

Juan

Re: ISIS on SDA

Andrii Oliinyk — Thu, 27 Aug 2026 05:29:50 GMT

Hi,
i'd assume it's bc of default IS-IS configuration developers chosen as single automation option for underlay. But just quick Q: what benefit can u see in using L1-only instead L2-only?

Re: ISIS on SDA

JUANNN — Thu, 27 Aug 2026 05:59:16 GMT

With level-1 only switches only need to maintain 1 database rather than 2. No need to copy level-1 information to level-2 database. Less calculations, less workload, ... and simple setup.

Re: ISIS on SDA

Andrii Oliinyk — Thu, 27 Aug 2026 06:36:55 GMT

the same basically is relevant to L2-only.
"and simple setup." - for CatC automated underlay provisioning (built-in) of for custom Day0-templates to do the same by admin?

Re: ISIS on SDA

JUANNN — Thu, 27 Aug 2026 08:58:19 GMT

Why not level-1 (all in the same area, where the area can be understood as the site itself). Why having multiple areas if I can just have everything on 1, for the sake of simplicity.

Re: ISIS on SDA

Andrii Oliinyk — Thu, 27 Aug 2026 09:14:06 GMT

single L2-only doesnt necessary mean multi-area domain :0)
& at very 1st approach reason for not L1-only: if for some reason admin will decide to partition site into multi-area (just hypothetically) - it will be easier to do with L2-backbone.

Re: ISIS on SDA

M02@rt37 — Thu, 27 Aug 2026 09:47:55 GMT

Hello @JUANNN

In a single area SDA fabric, L1-only would generaly be sufficient because all nodes can learn the complete topology within the same area...

L1/L2 is used mainly because it provide scalability for hierarchical designs ; I mean L1 handle the local area, while L2 can connect that arae to other ISIS areas or an external backbone.

So, in a production SDA environment with multiple fabric domains or an underlay that must integrate with other isis areas, L1/L2 is useful; in a truly flat, single-area deployment, the L2 database/adjacency provide little practical benefit and adds some overhead...

Hope that clear.

Re: ISIS on SDA

Andrii Oliinyk — Thu, 27 Aug 2026 09:50:15 GMT

"in a truly flat, single-area deployment, the L2 database/adjacency provide little practical benefit and adds some overhead" - could u please bring more details about "little practical benefit and adds some overhead"?

Re: ISIS on SDA

Andrii Oliinyk — Thu, 27 Aug 2026 09:53:36 GMT

"In a single area SDA fabric, L1-only would generaly be sufficient because all nodes can learn the complete topology within the same area..." vs "single L2-only doesnt necessary mean multi-area domain"
give me single advantage of using L1-only vs L2-only in single area SDA fabric :0)

Re: ISIS on SDA

swept — Thu, 27 Aug 2026 10:34:14 GMT

I was wondering about this as well when looking at the IS-IS design used with SDA. If all the SDA devices are intended to operate within the same area, I initially thought level-1 would be enough.

What I’m trying to understand is the practical reason for keeping the level-2 adjacency and database. Is there a specific SDA topology or production scenario where level-1-2 provides a real advantage, such as connecting different sites, areas, or providing better path selection?

It would be helpful to see a simple production example showing where level-1-2 makes a difference compared with using only level-1.

Re: ISIS on SDA

Andrii Oliinyk — Thu, 27 Aug 2026 11:05:00 GMT

"practical reason for keeping the level-2 adjacency and database." - the same as keeping L1 concurrently with L2.
"Is there a specific SDA topology or production scenario where level-1-2 provides a real advantage, such as connecting different sites, areas, or providing better path selection?" -u can imagine such a scenario w/ huge IS-IS domain as underlay for fabric site where u would decide (again, just hypothetically) to implement partitioning in L1& L1/L2. CatC wont automate it for u. u'll need to develop both target IS-IS configuration & (likely) Day0-templates. But so far i can only interpret this topic as purely academical interest, coz to decide something like this one need to face scalability issue w/ L1/L2 as default.

Re: ISIS on SDA

Andrii Oliinyk — Thu, 27 Aug 2026 11:30:27 GMT

Just borrowed it from linkedin chat:
https://bst.cisco.com/quickview/bug/CSCvy10542 (thanks to Freerk Terpstra)

Re: ISIS on SDA

Andrii Oliinyk — Thu, 27 Aug 2026 11:36:57 GMT

Hi M02@rt37
i already asked above this specific Q about "L2 database/adjacency provide little practical benefit and adds some overhead" in single IS-IS domain (read fabic site underlay). Can u maybe bring more details on both "little practical benefit and adds some overhead" especially keeping in mind that in SDA we rely on automation from CatC (either LAN-A or Day0 templates)?

Re: ISIS on SDA

M02@rt37 — Thu, 27 Aug 2026 13:23:59 GMT

Hello @Andrii Oliinyk

The overhead is mostly protocol/state overhead rather than configuration overhead. CatC/Day-0 templates can make configuring L2 trivial, yes, but they do not eliminate what ISIS does at runtime: L2 adjacencies must be maintained, L2 LSPs are flooded through the fabric, every L2 router maintains the corresponding LSDB, and topology changes can trigger SPF processing...

For a "normal" SDA fabric this cost is usually small, so I would not argue that L2 is a performance problem. The stronger argument is unnecesary state: if L1 already gives every node the complete topology/reachability required inside one area, L2 add another level of topology state without a corresponding SDA service benefit.

Where L1/L2 can make sense in production is when you deliberately introduce an ISIS hierarchy. For example, an SDA underlay that must interact with a larger ISIS infrastructure, or where you want a boundary between the fabric and another routing domain/area. Inside a genuinely self-contained SDA site, however, there is little architectural reason to maintain L2 purely for the sake of L2. The fact that Catalyst Center automates it makes the configuration argument weaker, not stronger: automation hides the complexity from the engineer, but the switches still pay the runtime cost of maintaining the L2 database and adjacencies...

No ?

Re: ISIS on SDA

Andrii Oliinyk — Thu, 27 Aug 2026 13:44:01 GMT

"L2 adjacencies must be maintained, L2 LSPs are flooded through the fabric, every L2 router maintains the corresponding LSDB, and topology changes can trigger SPF processing" - prove me wrong but if u replace L2 w/ L1 nothing will change.
"normal" SDA deploys either L1/L2 or L2 (post DNA Center version 2.3.2.3). If either already gives every node the complete topology/reachability required inside one area, removal L2 or L1 from L1/L2, or replacement L2 w/ L1 add unnecessary burden "without a corresponding SDA service benefit."
"Inside a genuinely self-contained SDA site, however, there is little architectural reason to maintain L2 purely for the sake of L2. " - replace L2 w/ L1 & nothing will change.
Finally, "cost of maintaining the L2 database and adjacencies" - i still do not see any calculable facts of why "cost of maintaining the L1 database and adjacencies" is less than it is w/ L2 only.
Give me at least one that is not as well applicable to L1 or this dispute will lose it's sense.

Re: ISIS on SDA

julian.bendix — Fri, 28 Aug 2026 10:25:16 GMT

Hey!

Check this out - https://bst.cisco.com/quickview/bug/CSCvy10542

Taken from a recently deployed lab:

sda01#show run | i is-type is-type level-2-only sda01#

BR Jules

Re: ISIS on SDA

JUANNN — Sat, 29 Aug 2026 02:47:22 GMT

I guess in scenario where there is an IS-ISI hierarchy like M02@rt37 said, level-2 only ensures that all nodes get for example the /32 route required for certain services, like the WLC. With level-1, again supposing there is an actual backbone, some nodes may receive just the default route created from the attached bit of an area border router (level1-2)...

Re: ISIS on SDA

Andrii Oliinyk — Sat, 29 Aug 2026 11:26:15 GMT

imagine chain of routers R1-R2-R3 in area X. R1&R3 run L1, & R2 runs L1/L2. imagine there are /32 addressed loopbacks running isis process as well & let them be L1-only. will R1&R3 have /32 routes of each other in their ribs by default? yes they will.
with regard to default route, each L1-router will have it as soon as L1/L2-router in area generates LSP w/ ATT-bit set.

Re: ISIS on SDA

muhammadawaisaz17 — Sat, 29 Aug 2026 11:53:49 GMT

I agree with your point. In a self-contained SDA fabric, keeping L2 only because it is automated does not necessarily provide much additional value. If L1 already provides the required topology and reachability, using a simpler hierarchy can reduce unnecessary routing state while still meeting the design requirements. L1/L2 makes more sense when the fabric needs to connect with a larger ISIS domain or another routing area.

Re: ISIS on SDA

M02@rt37 — Sat, 29 Aug 2026 16:40:31 GMT

Hello @Andrii Oliinyk

Yes, I agree, in a single-area, self-contained SDA fabric, there is no strong technical argument that L1-only is inherently cheaper than L2-only—both maintain one adjacency level, one LSDB, flood LSPs, and run spf for essentialy the same topology.

The real, non-equivalent advantage of L2 is when the SDA underlay must participate in a larger IS-IS hierarchy or connect multiple areas, because L2 provides the backbone/inter-area routing function; L1 does not.

If that requirement does not exist, then maintaining L1/L2 rather than simply L1-only or L2-only is mainly an architectural/automation choice, not an SDA service necessity. No ?