Dimensionar uma grande VPN em estrela: conte antes de escolher o BGP
Os prefixos são o número fácil. As sessões, a rajada de atualizações e a recuperação após a falha de um concentrador decidem se o desenho aguenta alguns milhares de filiais.
Três mil filiais soam como um problema de encaminhamento, mas comportam-se como um problema de contabilidade. O total de prefixos fica pronto em dez minutos, e raramente é o número que dói. O que dói é o trabalho por sessão, a rajada de atualizações quando um componente partilhado falha, e o tempo até o encaminhamento voltar a coincidir com a nova topologia.
Percorra então a aritmética na ordem correta. Conte as relações, conte os prefixos e as alternativas, depois conte o que acontece numa hora má, e só depois compare protocolos e plataformas. Na ordem inversa, o exercício torna-se uma discussão sobre limites de rotas que ninguém consegue fechar com a informação em cima da mesa.
Quatro orçamentos, não um
Cada orçamento responde a uma pergunta diferente, e cada um pode ser a restrição limitante numa plataforma diferente. Escrevê-los em separado impede que um único número grande de prefixos substitua todo o desenho.
| Budget | What you are really counting |
|---|---|
| Sessions | Peers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count |
| Prefixes | Alternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see |
| Churn | Updates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event |
| Recovery | Time to detect, reselect, reinstall and restore the application, measured end to end rather than per box |
Os dois últimos são os que se saltam numa revisão de desenho. Uma rede que cabe confortavelmente na memória em regime estável pode comportar-se mal quando quatrocentas filiais se reconectam em dois minutos, porque o trabalho chega mais depressa do que o plano de controlo o consegue escoar. Anote o tamanho da rajada como número, juntamente com quanto tempo o serviço pode permanecer degradado. Isso transforma uma preocupação vaga num teste que alguém pode realmente executar.
Há também uma pergunta de plataforma escondida nos quatro: se a cifra, a comutação e o encaminhamento partilham uma CPU ou têm caminhos separados. Dois equipamentos com igual capacidade de rotas podem comportar-se de forma muito diferente sob a rajada, e a folha de dados raramente diz qual está a comprar.
Faça a aritmética com os seus próprios números
Tome um desenho inventado: 3,000 filiais, três prefixos cada antes da agregação, e dois concentradores por filial para redundância. O par de concentradores tem de suster cerca de 9,000 prefixos de filial antes do resumo, e o desenho implica 6,000 sessões de filial para concentrador se cada filial se ligar a ambos.
Agora acrescente as partes que não são prefixos. Cada sessão transporta estado e mensagens periódicas mesmo quando nada muda. Cada concentrador pode manter mais de um caminho por prefixo se se esperar uma mudança rápida, pelo que o número de alternativas pode exceder o das selecionadas. E a vista de cada spoke é uma decisão de política separada: dar a cada filial as rotas de todas as outras multiplica o trabalho de uma forma que a contagem do lado do concentrador não revela.
São números de planeamento para uma conversa de desenho, não a medição de qualquer produto. O resultado útil do exercício é a forma da curva, não uma afirmação sobre onde um router concreto cede.
O que o BGP lhe dá, e o que um IGP lhe dá
O BGP separa o que um router recebeu, o que selecionou e o que anuncia, e cada uma dessas coisas é controlada por política. É exatamente do que uma rede de filiais precisa, porque um spoke deve normalmente ver uma rota predefinida, os serviços centrais e muito pouco mais. Contar só a tabela final esconde as alternativas e os anúncios, que são precisamente as partes que crescem quando acrescenta redundância.
Um IGP não é automaticamente errado. Quando a topologia, a estrutura de áreas e o modelo de adjacência se ajustam ao serviço, um protocolo de estado de ligação converge depressa e precisa de menos andaime de política. A armadilha é supor que consegue exprimir o mesmo controlo de exportação por vizinho que o BGP: uma área OSPF é uma fronteira de inundação, não um filtro que se pendura numa filial.
De qualquer forma, decida primeiro o modelo de visibilidade. Rotas predefinidas, resumos para serviços centrais ou detalhes completos das filiais são três produtos diferentes, e um resumo que esconde uma falha mais específica é uma decisão de desenho que tem de ser escrita, não descoberta durante uma interrupção.
Teste a rajada, não o regime estável
Construa a comparação em torno da falha que realmente espera: um concentrador em baixo, um evento WAN regional ou uma janela de manutenção que coloca metade dos locais offline de uma vez. Meça a recuperação do ponto de vista da filial, incluindo a aplicação, porque um plano de controlo que converge em segundos vale pouco se a sessão leva minutos a restabelecer-se.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFRegiste o que a plataforma faz no pico da rajada e não em repouso, e repita com as funções de segurança ativas. Uma prova de conceito que só mostra uma tabela calma é um teste de memória, e a memória nunca foi o número interessante.