Resumo
- A pergunta original descreveu um domínio IS-IS L2 plano com aproximadamente 300 roteadores e equipamentos de agregação com cerca de 100 adjacências para a borda.
- Saku Ytti relatou ter operado alguns milhares de nós em control planes antigos; Mark Tinka afirmou que sua rede já trabalhava com aproximadamente 300 nós em 2009.
- Tom Beecher avaliou que a escala deveria funcionar, condicionada à distribuição geográfica, ao tamanho da LSDB e ao ajuste de atraso SPF. Dan Snyder acrescentou hardware, tamanho do domínio de falha e meta de convergência.
- Matthew Petach transformou a discussão em decisão arquitetural: capacidade do protocolo não define quanto da rede um erro de automação, falha física ou rompimento de fibra deve alcançar.
- Documentos da IETF mostram que áreas IS-IS contêm flooding e cálculo SPF, mas a hierarquia também troca parte da visibilidade e da escolha ótima de caminhos por escala.
- A validação deve usar cenários de falha e demanda degradada, e não apenas confirmar que todos os roteadores conseguem armazenar a topologia.
O autor da pergunta buscava experiências de produção. O desenho tinha perto de 300 roteadores em um único domínio IS-IS Level 2 e, em alguns pontos de agregação, aproximadamente 100 adjacências com roteadores abaixo deles.
Os primeiros relatos reduziram rapidamente o peso desse número. Saku Ytti disse que já operou alguns milhares de nós IS-IS em uma época de control planes muito mais lentos. Mark Tinka citou uma rede de aproximadamente 300 nós em 2009, com plataformas Cisco CRS-1 e ME3600X e equipamentos Juniper M320, T320 e MX480. Tom Beecher também considerou o volume normalmente administrável.
Não são testes do ambiente proposto. O thread não informa topologia, gerações de hardware, quantidade de links, tamanho previsto da LSDB, latência entre extremos ou objetivo de convergência. Assim, ele não produz um teto universal. Produz uma conclusão operacional mais segura: 300, isoladamente, não é critério suficiente para aprovar ou rejeitar o desenho.
O gargalo pode não estar no control plane
Beecher vinculou a viabilidade à geografia e ao tamanho total da base de estado de enlace. Uma rede espalhada pode exigir ajuste nos atrasos SPF. Uma LSDB grande aumenta o trabalho. Sua ressalva mais importante foi que, se a base já preocupa, talvez seja hora de revisar a decisão de permanecer em uma área plana.
Dan Snyder organizou o problema em três perguntas: qual hardware executa o protocolo, qual domínio de falha é aceitável e em quanto tempo a rede precisa convergir. Um processador rápido pode reduzir cálculo sem diminuir o alcance de uma configuração errada. Uma convergência curta pode entregar todo o tráfego a caminhos que não têm capacidade para recebê-lo.
A resposta de Matthew Petach, publicada no fim da janela e indexada pouco depois, trouxe o novo sinal. Ele recomenda começar pelos erros mais prováveis: defeitos em automação, entradas humanas incorretas, falhas nas camadas física e de rede e cortes de fibra. Para cada classe, a equipe deve definir o raio de impacto e onde precisa de uma barreira lógica.
Petach concorda que IS-IS comporta 300 nós e uma ordem de grandeza adicional em condições adequadas. O alerta é que “comportar” descreve estado e cálculo; não descreve a quantidade de clientes, regiões ou enlaces que reagem ao mesmo evento.
O tempo de reparo muda a topologia econômica
Uma óptica queimada dentro de um data center com equipe e uma fibra de longa distância interrompida podem gerar recomputação semelhante, mas impõem tempos econômicos diferentes. A primeira pode ser trocada rapidamente. A segunda pode deixar a rede em modo degradado por tempo suficiente para exigir reserva de capacidade, priorização e comunicação com clientes.
Petach usa enlaces transoceânicos para mostrar o mecanismo. Caminhos extras custam caro, rotas vendidas como diversas podem compartilhar destino físico, e um evento regional pode retirar várias capacidades ao mesmo tempo. O IGP encontra os enlaces restantes, mas o caminho mais curto pode concentrar neles mais demanda do que conseguem transportar.
Não há um incidente concreto ou medições de cabo no thread. Portanto, o exemplo não sustenta afirmações sobre uma infraestrutura específica. Ele sustenta um teste: aplicar a matriz de demanda a cada topologia degradada e verificar saturação, serviço protegido e o ponto de intervenção de engenharia de tráfego.
Áreas contêm estado, não eliminam escolhas
A RFC 5302 descreve um domínio IS-IS dividido em áreas Level 1 conectadas por uma topologia Level 2. Manter LSPs dentro de uma área limita o tamanho da base de estado e a complexidade do cálculo de menor caminho.
O mesmo documento registra o preço. Sumarização e abstração removem detalhes e podem gerar rotas menos ótimas. Distribuir informações mais específicas melhora a precisão, mas aumenta memória, transmissão e processamento em todo o domínio. A hierarquia não oferece resiliência gratuita; ela reorganiza o compromisso entre escala, informação e escolha de caminho.
A RFC 9377 trata processamento e flooding como limites inevitáveis de um único domínio IS-IS e aponta múltiplos domínios L1 com backbone L2 como a abordagem normal de expansão. A RFC 8405 exige parâmetros de back-off SPF coerentes dentro da mesma área ou nível e observa que os valores apropriados podem mudar durante a vida da rede.
Nenhuma dessas normas escolhe 300 como linha vermelha. O conjunto relevante inclui nós, links, crescimento da LSDB, frequência de atualizações, velocidade de flooding, comportamento SPF e capacidade sobrevivente.
Quatro testes colocam o desenho em produção
O primeiro mede folga de controle. A equipe deve incluir a plataforma mais lenta ainda implantada e registrar CPU, memória, formação de adjacências, propagação de LSP e SPF completo e incremental durante mudanças realistas.
O segundo mede contenção. Erro de automação, política de rota incorreta, perda de equipamento, perda de site e falha simultânea de links de longa distância com destino compartilhado precisam de cenários separados. Cada um deve ter escopo máximo, serviço afetado e responsável.
O terceiro mede capacidade degradada. Tabelas convergentes não bastam se os enlaces restantes saturam. O plano precisa indicar onde entram engenharia de tráfego, admissão ou prioridade de serviço e qual telemetria dispara a intervenção.
O quarto mede operação futura. Petach propôs horizontes de três, cinco e dez anos. A expansão inclui mais roteadores, mas também novas regiões, gerações diferentes de equipamentos, domínios de manutenção maiores e o número de profissionais capazes de entender a topologia durante um incidente.
A próxima entrega deveria ser um orçamento de falha
Uma rede geograficamente compacta, com caminhos realmente diversos e bastante capacidade ociosa, pode continuar plana de forma racional. Uma rede distribuída, dependente de poucos enlaces longos ou sujeita a reparos demorados pode precisar de limites bem antes de o protocolo mostrar dificuldade.
O debate da NANOG separa duas aprovações. A primeira diz que IS-IS e os equipamentos suportam o estado de 300 nós. A segunda diz que a organização aceita o raio de falha e consegue controlar o tráfego durante uma degradação.
Para o projeto analisado, a próxima evidência não deve ser outro caso com milhares de roteadores. Deve ser um orçamento de falha: eventos cobertos, alcance e duração máximos, capacidade restante e ponto de comando disponível quando o menor caminho deixa de ser a melhor decisão.
Fontes
- Pergunta original na NANOG sobre um domínio IS-IS plano de 300 roteadores
- Experiência histórica de escala relatada por Saku Ytti
- Exemplo de implantação de 2009 apresentado por Mark Tinka
- Tom Beecher sobre LSDB, geografia e atraso SPF
- Dan Snyder sobre hardware, domínio de falha e convergência
- Matthew Petach sobre raio de impacto e limites de desenho
- RFC 5302 sobre IS-IS em dois níveis e o compromisso entre escala e otimização
- RFC 8405 sobre back-off de SPF
- RFC 9377 sobre escala de domínios de flooding IS-IS

