I've run an ISIS network of a few thousands nodes, back when the network included c2k series routers in addition to things like GSR (i.e. a couple decades ago), so very slow control-planes. According to Abe Martey's IS-IS network designs solutions book you can approximate SPF complexity in nonhighly meshed networks as O(LlogN) (links, nodes). When we combined two large ISIS networks, and I was worried about the computational cost on the lower end devices, I used this to approximate what the SPF run time would be after migration, and it was spot on. In some ISIS standard bodies public mailing lists some Chinese networks have spoken about many orders of magnitudes larger flat level2 ISIS topologies. So I wouldn't worry about it, 300 was nothing 20 years ago, and it's nothing today. On Mon, 27 Jul 2026 at 20:48, Tom via NANOG <nanog@lists.nanog.org> wrote:

Hello,

I'm wondering what some practical/real experiences have been with building out a large flat IS-IS network. I've read a lot of threads on conjecture and older docs on what the vendors recommend but haven't found anything yet or real world examples. Two questions,

1) Is anyone running a flat IS-IS L2 network with approx 300 routers? If not, what is the higher end you've seen? 2) On aggregation routers, what is the upper end of IS-IS adj to downstream routers? Would agg routers with approx 100 connections be an issue moving to IS-IS with the addition of keeping track of that many adj?

Thanks. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/XXHOSKUL...

-- ++ytti

Yeah 300 nodes in a single flat L2 area generally shouldn't be a problem. You may need to tweak SPF delay depending on geographic distribution and/or total size of the LSDB , but it should be very doable. Realistically if the LSDB size is a thing you probably shouldn't be running a flat area anyways, but with a little tweaking you can get away with it just fine. On Mon, Jul 27, 2026 at 2:41 PM Mark Tinka via NANOG <nanog@lists.nanog.org> wrote:

On 27/07/2026 19:08, Tom via NANOG wrote:

...

Hello,

I'm wondering what some practical/real experiences have been with building out a large flat IS-IS network. I've read a lot of threads on conjecture and older docs on what the vendors recommend but haven't found anything yet or real world examples. Two questions,

1) Is anyone running a flat IS-IS L2 network with approx 300 routers? If not, what is the higher end you've seen? 2) On aggregation routers, what is the upper end of IS-IS adj to downstream routers? Would agg routers with approx 100 connections be an issue moving to IS-IS with the addition of keeping track of that many adj?

With today's control planes, 300 nodes is not even a corn flake :-).

We did that number back in 2009, on Cisco CRS-1's, ME3600X's and Juniper M320's, T320's and MX480's.

The state-of-the-art has moved on a great deal, since then.

Mark. _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SCR7AOTL...

On Mon, Jul 27, 2026 at 6:14 PM Dan Snyder via NANOG <nanog@lists.nanog.org> wrote:

It really depends on what hardware you are using, how large of a fault domain you want if there is an issue in the L2 area, and how quickly you expect it to converge if there is a failure.

To add a bit to Dan's excellent reply When I'm working on a network design, one of the questions first and foremost in my mind is "what's the blast radius for the common failures that will happen, and where does it make sense to put blast doors in?" Failures come from many sources; bugs in automation tools, humans making typos in inputs to automation tools, hardware failures at L1, L2, L3, fiber cuts, etc. The duration of the outage also comes into play; undersea, transoceanic fiber failures can have months-long repair cycles, whereas a failed optic in a datacenter aggregation router can often be swapped out in minutes. While it can often be tempting to simply keep scaling up a flat network as you grow larger and larger, what you'll generally find is that your fragility increases as you do that. What's more is that the increase in fragility follows a power law that grows faster than the diameter of your flat network, and that there are stepwise jumps in the fragility of your network as you hit certain boundary points. Recognize that restoration times are long for subsea links; that costs for them are much higher, so putting in N+M or 2N pathways subsea almost never pencils out for the finance team paying f or them; that trying to find sufficient diversity that you can do N+M for a small value of M while ensuring that there's no shared fate between any of N and M so that you can survive a subsea cut without having to do higher-order traffic engineering is an exponentially increasing problem. And then stare long and hard at the beautiful diagram of your single flat L2 network that circles the planet, and think to yourself "when 2/3 of my transpacific capacity goes down due to an undersea earthquake and landslide in the strait of taiwan, how am I going to tell a flat L2 network that I don't want *all* my traffic still flowing across the few links that remain?"[0] That is, Mark Tinka and Tom Beecher are spot-on; IS-IS will handle the number of nodes you're talking about plus another order of magnitude without blinking; and with a few knobs, you can even keep your SPF timing reasonable with round-the-planet latencies. But just because it *can* doesn't mean that's a good network design. ^_^; So, I would encourage you to think about the size and scope of your network, not just today but where you envision it being 3 years from now, 5 years from now, 10 years from now, and start thinking "how can I start putting blast doors into my network to limit the impacts of failure, and give me higher-level control points that will let me traffic engineer in ways that go beyond what I can do with a simple flat L2 IS-IS network?" I'll admit--I don't know the first thing about your network. It may be that you have a tightly geographically constrained network, so your edge-to-edge latency is low double digits, you have plentiful access to diverse fiber everywhere you need to go so that you can overengineer your Quantity Of Service to a degree that you can leave everything to IS-IS to route around failures without ever needing to traffic engineer your traffic, and you have trucks ready to roll at a moment's notice to swap out any failed hardware in less time than it takes a sleeping network engineer to wake up, find their glasses, find their phone for 2FA to log into the network tooling to figure out what broke, why they got paged, and how to route around it. If so, that's awesome! In that case, you can rest easy knowing that a flat IS-IS L2 topology will scale up just fine for you, even at 10x your current size. :) But...on the off-chance that's not what your network looks like, I've found that thinking about failure modes and how to limit the impact of them goes a long way towards developing a robust network design, and that the network design you arrive at is likely to not be a simple single flat L2 topology. Thanks for asking the question! :) Matt [0]There's a reason many networks do continental IS-IS networks, and then use BGP plus their favorite flavor of traffic engineering overlay across transoceanic links. BGP provides very, very strong blast doors to limit the blast radius of IGP goofs, as well as an easy way to ensure your IGP won't continue to try passing all of your traffic across a small number of remaining transoceanic links during a major outage.

This is absolutely the norm. People framing it as some engineering challenge that needs consideration are unnecessarily creating complexity and concern where there is none. Tier1s run global flat level2 at this scale, and have since forever. Outage information cannot propagate faster than light, no matter how you. bake it. The justification should be the opposite, you should have a strong reason not to run flat IGP, if you don't have it, run flat. You will struggle to justify any of what is proposed here, regarding SPF time, regarding convergence time, that these can be improved by adding complexity. SPF and convergence don't even matter in any modern design, because when you converge, you converge for all single failures too, that is, on link-down, you immediately forward around the problem, instead of waiting for SPF, since waiting for SPF takes a long time in any scale, even intraDC. On Tue, 28 Jul 2026 at 06:48, Matthew Petach via NANOG <nanog@lists.nanog.org> wrote:

On Mon, Jul 27, 2026 at 6:14 PM Dan Snyder via NANOG <nanog@lists.nanog.org> wrote:

...

It really depends on what hardware you are using, how large of a fault domain you want if there is an issue in the L2 area, and how quickly you expect it to converge if there is a failure.

To add a bit to Dan's excellent reply

When I'm working on a network design, one of the questions first and foremost in my mind is "what's the blast radius for the common failures that will happen, and where does it make sense to put blast doors in?" Failures come from many sources; bugs in automation tools, humans making typos in inputs to automation tools, hardware failures at L1, L2, L3, fiber cuts, etc. The duration of the outage also comes into play; undersea, transoceanic fiber failures can have months-long repair cycles, whereas a failed optic in a datacenter aggregation router can often be swapped out in minutes.

While it can often be tempting to simply keep scaling up a flat network as you grow larger and larger, what you'll generally find is that your fragility increases as you do that. What's more is that the increase in fragility follows a power law that grows faster than the diameter of your flat network, and that there are stepwise jumps in the fragility of your network as you hit certain boundary points.

Recognize that restoration times are long for subsea links; that costs for them are much higher, so putting in N+M or 2N pathways subsea almost never pencils out for the finance team paying f or them; that trying to find sufficient diversity that you can do N+M for a small value of M while ensuring that there's no shared fate between any of N and M so that you can survive a subsea cut without having to do higher-order traffic engineering is an exponentially increasing problem. And then stare long and hard at the beautiful diagram of your single flat L2 network that circles the planet, and think to yourself "when 2/3 of my transpacific capacity goes down due to an undersea earthquake and landslide in the strait of taiwan, how am I going to tell a flat L2 network that I don't want *all* my traffic still flowing across the few links that remain?"[0]

That is, Mark Tinka and Tom Beecher are spot-on; IS-IS will handle the number of nodes you're talking about plus another order of magnitude without blinking; and with a few knobs, you can even keep your SPF timing reasonable with round-the-planet latencies. But just because it *can* doesn't mean that's a good network design. ^_^;

So, I would encourage you to think about the size and scope of your network, not just today but where you envision it being 3 years from now, 5 years from now, 10 years from now, and start thinking "how can I start putting blast doors into my network to limit the impacts of failure, and give me higher-level control points that will let me traffic engineer in ways that go beyond what I can do with a simple flat L2 IS-IS network?"

I'll admit--I don't know the first thing about your network. It may be that you have a tightly geographically constrained network, so your edge-to-edge latency is low double digits, you have plentiful access to diverse fiber everywhere you need to go so that you can overengineer your Quantity Of Service to a degree that you can leave everything to IS-IS to route around failures without ever needing to traffic engineer your traffic, and you have trucks ready to roll at a moment's notice to swap out any failed hardware in less time than it takes a sleeping network engineer to wake up, find their glasses, find their phone for 2FA to log into the network tooling to figure out what broke, why they got paged, and how to route around it. If so, that's awesome! In that case, you can rest easy knowing that a flat IS-IS L2 topology will scale up just fine for you, even at 10x your current size. :)

But...on the off-chance that's not what your network looks like, I've found that thinking about failure modes and how to limit the impact of them goes a long way towards developing a robust network design, and that the network design you arrive at is likely to not be a simple single flat L2 topology.

Thanks for asking the question! :)

Matt

[0]There's a reason many networks do continental IS-IS networks, and then use BGP plus their favorite flavor of traffic engineering overlay across transoceanic links. BGP provides very, very strong blast doors to limit the blast radius of IGP goofs, as well as an easy way to ensure your IGP won't continue to try passing all of your traffic across a small number of remaining transoceanic links during a major outage. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2ESUIWF3...

-- ++ytti

I'd like to contribute what to monitor. But since I literally never had any problems with this, thousands of units decades ago, I never had to learn what will break and how to keep it in check. ISIS standard bodies lists offer some clues of what might break, but they're at 100ks of units.

On Thu, 30 Jul 2026 at 09:46, Matthew Petach <mpetach@netflight.com> wrote:

The point I was trying to make is that just because a routing protocol supports doing that doesn't mean it's a good idea operationally. There are other issues that come into network design that often suggest a single flat IGP might not give you enough knobs to allow you to control traffic flows and impact radius from unusual externalities.

It was a long-winded and meandering way of saying "just because you CAN, doesn't necessarily mean you SHOULD." ^_^;

I'll see your long-winded and meandering and raise you this: Of course I agree with the general principle here, but in this case, just because you can, you should. Because NOT doing flat IGP is far more complex, and adding complexity requires justification. And as we know, all of these devices are extremely fragile and very low quality software, we run into customer-affecting bugs all the time and it's entirely impossible to have any strong confidence that what you're delivering works well. So you really need to pick your battles, which problems most. benefit from careful thought, which problems do not need it. I'm fairly confident (happy to be proven wrong, if provided access) that in any network configuration I review, I'll find catastrophic mistakes in production configuration, in control-plane protection, in QoS, and highly suboptimal configurations in regards to convergence and redundancy. And these will not be complex or esoteric, but fairly common, simple mistakes. No one seems to have time to even get basics rights, doing deep dive on issue that is known to be very barren ground for issues is not justifiable. -- ++ytti

On Sun, 2 Aug 2026 at 12:31, Mark Tinka <mark@tinka.africa> wrote:

An obvious case against multi-level IS-IS is that to create end-to-end MPLS LSP's, you need each node to have every other node in its LFIB.

I think 'end-to-end' here can be defined in many ways. But I would consider seamless MPLS as end-to-end, and of course in this case you have no global IGP, you have metros having their own level2, and core having its own level2, none of them communicate. I've done that as well, and that's generally the approach if you cannot justify global L2, there is no real case for L1, L1L2, L2 design. -- ++ytti

Mark Tinka via NANOG писал(а) 2026-08-02 07:43:

On 02/08/2026 13:21, Saku Ytti wrote:

...

I think 'end-to-end' here can be defined in many ways. But I would consider seamless MPLS as end-to-end, and of course in this case you have no global IGP, you have metros having their own level2, and core having its own level2, none of them communicate. I've done that as well, and that's generally the approach if you cannot justify global L2, there is no real case for L1, L1L2, L2 design.

Yes, large networks with Metro-E rings can either have a flat L2 domain that communicates between the core and metro, or can have BGP-LU separating them (as you say, the Seamless MPLS definition).

I suppose in either case, a single L2 domain remains as the only scope, whether separated by BGP-LU or not.

I have ran both topologies without issue, but admittedly, different scales.

Mark.

With SR-ISIS you don't need BGP-LU, although still need L2 to L1 leaking. But when loopbacks from L2 become available in L1, ISIS advertises them with [binding] labels, so Seamless MPLS comes much easier. Kind regards, Andrey