Tres mil sucursais soan a un problema de encamiñamento, pero compórtanse como un problema de contabilidade. O total de prefixos calcúlase en dez minutos e raramente é o número que doe. O que doe é o traballo por sesión, a vaga de actualizacións cando falla un compoñente compartido e o tempo que pasa ata que o reenvío volve coincidir coa nova topoloxía.

Así que percorra a aritmética na orde correcta. Conte as relacións, conte os prefixos e as alternativas, despois conte que ocorre nunha hora mala e só despois compare protocolos e plataformas. Na orde inversa, o exercicio convértese nunha discusión sobre límites de rutas que ninguén pode pechar coa información sobre a mesa.

Catro orzamentos, non un

Cada orzamento responde a unha pregunta distinta, e cada un pode ser a restrición limitante nunha plataforma distinta. Escribilos por separado impide que un só número grande de prefixos faga de substituto de todo o deseño.

BudgetWhat you are really counting
SessionsPeers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count
PrefixesAlternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see
ChurnUpdates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event
RecoveryTime to detect, reselect, reinstall and restore the application, measured end to end rather than per box

Os dous últimos son os que se saltan nunha revisión de deseño. Unha rede que en estado estable cabe comodamente na memoria pode comportarse mal cando catrocentas sucursais se reconectan en dous minutos, porque o traballo chega máis rápido do que o plano de control o drena. Anote o tamaño da vaga como un número, xunto con canto tempo pode permanecer degradado o servizo. Iso converte unha preocupación vaga nunha proba que alguén pode executar de verdade.

Tamén hai unha pregunta de plataforma agochada dentro dos catro: se o cifrado, o reenvío e o encamiñamento comparten unha CPU ou teñen camiños separados. Dous dispositivos coa mesma capacidade de rutas poden comportarse moi distinto baixo a vaga, e a folla de datos raramente di cal está a comprar.

Faga a aritmética cos seus propios números

Colla un deseño inventado: 3,000 sucursais, tres prefixos cada unha antes da agregación e dous concentradores por sucursal por redundancia. O par de concentradores debe soster uns 9,000 prefixos de sucursal antes do resumo, e o deseño implica 6,000 sesións de sucursal a concentrador se cada sucursal se empareja cos dous.

Agora engada as partes que non son prefixos. Cada sesión leva estado e mensaxes periódicas mesmo cando nada cambia. Cada concentrador pode manter máis dun camiño por prefixo se se espera que cambie rápido, así que o número de alternativas pode superar o número de seleccionadas. E a vista de cada radio é unha decisión de política aparte: dar a cada sucursal as rutas de todas as demais multiplica o traballo dunha forma que o reconto do lado do concentrador non revela.

Son cifras de planificación para unha conversa de deseño, non unha medición de ningún produto. O resultado útil do exercicio é a forma da curva, non unha afirmación sobre onde cede un encamiñador concreto.

Que lle compra BGP e que lle compra un IGP

BGP separa o que un encamiñador recibiu, o que seleccionou e o que anuncia, e cada unha desas cousas está controlada por política. Iso é xusto o que necesita unha rede de sucursais, porque un radio adoita ter que ver unha ruta por defecto, os servizos centrais e moi pouco máis. Contar só a táboa final agocha as alternativas e os anuncios, que son precisamente as partes que medran ao engadir redundancia.

Un IGP non é automaticamente incorrecto. Cando a topoloxía, a estrutura de áreas e o modelo de adxacencia encaixan co servizo, un protocolo de estado de enlace converxe rápido e necesita menos andaime de política. A trampa é supoñer que pode expresar o mesmo control de exportación por veciño que BGP: unha área OSPF é unha fronteira de inundación, non un filtro que se poida colgar dunha sucursal.

De calquera xeito, decida primeiro o modelo de visibilidade. Rutas por defecto, resumos para servizos centrais ou detalles completos de sucursal son tres produtos distintos, e un resumo que agocha un fallo máis específico é unha decisión de deseño que hai que escribir, non descubrir durante unha interrupción.

Probe a vaga, non o estado estable

Construa a comparación arredor do fallo que realmente espera: un concentrador caído, un evento WAN rexional ou unha ventá de mantemento que deixa media rede de sedes fóra de liña á vez. Mida a recuperación desde a perspectiva da sucursal, incluída a aplicación, porque un plano de control que converxe en segundos significa pouco se a sesión tarda minutos en restablecerse.

show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPF

Rexiste que fai a plataforma no pico da vaga e non en repouso, e repítao coas funcións de seguridade activadas. Unha proba de concepto que só mostra unha táboa tranquila é unha proba de memoria, e a memoria nunca foi o número interesante.

Artigos relacionados