Que ten que cadrar antes de que un MX poida terminar IPsec
Un commit que acepta a configuración demostra o analizador, non a ruta. Cinco partes da tupla de plataforma deciden se o servizo se executa de verdade.
A configuración confírmase sen erros, as interfaces soben e o túnel segue negándose a establecerse. Nada no rexistro di que a plataforma non poida facelo; simplemente non o fai. En Junos, IPsec é un servizo que só pode prestar unha combinación concreta de chasis, hardware de servizos ou ruta de software, e versión, e unha páxina de funcionalidades describe a capacidade do software, non o seu equipo. A tupla hai que comprobala parte por parte, porque o resultado do commit só demostra o analizador.
Por onde vai realmente o paquete
O tráfico seleccionado para IPsec ten que chegar ao compoñente que o cifra. Nas plataformas con módulo de servizos, o fluxo seleccionado diríxese a ese módulo e despois volve á ruta de reenvío. Se o módulo falta, é insuficiente ou non está asociado á interface, a configuración existe e non se procesa nin un só paquete. Nada na saída do commit distingue ese caso dun saudable.
As implementacións aloxadas en software deixan o traballo no motor de encamiñamento ou en hardware en liña, con límites de recursos moi distintos. Un túnel visible na configuración non lle di cal desas rutas o transporta realmente.
As cinco partes da tupla
Anote a combinación antes de ler calquera recomendación, porque unha parte pode invalidar as demais. Un número de peza que soportaba un servizo hai tres anos non di nada sobre a tarxeta nin a versión deste chasis. Lea as filas seguintes como lista de comprobación e logo encha os valores que a configuración non pode amosarlle.
| Part | What to record | Where it fails quietly |
|---|---|---|
| Chassis and service hardware | Model plus the installed PIC, MPC or MIC | Card absent or not bound to the interface |
| Implementation | Services card, inline or software path | Configuration accepted, no processing |
| Release | Exact Junos version | The feature arrives in a later build |
| Address families and mode | Outer and inner family, tunnel mode, peer authentication | Half the traffic silently unprotected |
| Entitlement and capacity | Licence state and the workload profile | Ceiling reached only under load |
As familias de enderezos e a carga de traballo son as dúas filas que a xente salta, e ambas son baratas de comprobar e caras de descubrir tarde. Lea a tupla no equipo e non nunha folla de cálculo, porque unha configuración informa do que vostede pediu, non do que está instalado. Dous comandos achegan case todo: show chassis hardware nomea a tarxeta realmente instalada e show version dá a versión exacta. Ningún dos dous depende de que a configuración sexa correcta, e aí está a clave.
show chassis hardware
show versionOs limiares de versión son limiares reais
O detalle da versión non é unha formalidade. A descrición xeral de IPsec de Juniper sitúa o soporte de AES-GCM para tarxetas multiservizo en Junos 17.3R1, co modo FIPS a partir de 17.4R1. Por tanto, a mesma función ten dous limiares segundo como se opere a plataforma, e o modo que vostede execute decide cal se aplica. Comprobe o modo antes de comprobar a lista de funcións.
Lea as notas da versión exacta instalada, non a máis recente documentada. Unha capacidade que chegou nunha compilación posterior non se pode dar por presente nunha anterior, e unha afirmación escrita para unha tarxeta non se traslada a outra. Copie a liña das notas da versión no rexistro de deseño para que a afirmación leve a súa propia fonte, porque unha declaración de soporte escrita para unha familia de plataformas non é unha declaración sobre o modo que vostede executa nin sobre a tarxeta que ten.
A capacidade é unha carga de traballo, non un titular
Unha cifra de rendemento de titular sen as súas condicións de medición é un número de mercadotecnia. Os paquetes pequenos custan moito máis por bit que os grandes, as asociacións simultáneas consomen memoria e calquera outro servizo que comparta a tarxeta reduce o que queda.
Estime a partir do tráfico que espera: tamaños de paquete típicos e no peor caso, número de pares e se esa tarxeta tamén termina NAT ou outro servizo. Logo deixe marxe para o día en que unha ruta leve máis carga da que supuxo o deseño. Un plan de capacidade que dá por sentado hardware ocioso é un desexo, non un plan. Se a cifra importa para o caso de negocio, mídaa unha vez no equipo baixo unha carga representativa e garde esa medición co deseño.
Escriba o rexistro antes do deseño
Para cada capacidade que necesite o deseño, garde a referencia de plataforma, a documentación axustada á versión e calquera restrición non resolta nun mesmo sitio. Cando falle unha fila da tupla, compare outra pasarela xa aprobada en lugar de refacer o deseño arredor dunha lista da compra obsoleta. O rexistro debe dicir que sistema exacto fai o traballo e baixo que límites.
Só entón comprobe o par, porque a compatibilidade de protocolo co extremo remoto é a seguinte pregunta e nunca substitúe o soporte local. Un par que acepta as propostas non pode axudar a un chasis que xamais cifra un paquete.