Qué tiene que cuadrar antes de que un MX pueda terminar IPsec
Un commit que acepta la configuración demuestra el analizador, no la ruta. Cinco partes de la tupla de plataforma deciden si el servicio se ejecuta de verdad.
La configuración se confirma sin errores, las interfaces suben y el túnel sigue negándose a establecerse. Nada en el registro dice que la plataforma no pueda hacerlo; simplemente no lo hace. En Junos, IPsec es un servicio que solo puede prestar una combinación concreta de chasis, hardware de servicios o ruta de software, y versión, y una página de funcionalidades describe la capacidad del software, no su equipo. La tupla hay que comprobarla parte por parte, porque el resultado del commit solo demuestra el analizador.
Por dónde va realmente el paquete
El tráfico seleccionado para IPsec tiene que llegar al componente que lo cifra. En las plataformas con módulo de servicios, el flujo seleccionado se dirige a ese módulo y después vuelve a la ruta de reenvío. Si el módulo falta, es insuficiente o no está asociado a la interfaz, la configuración existe y no se procesa ni un solo paquete. Nada en la salida del commit distingue ese caso de uno saludable.
Las implementaciones alojadas en software dejan el trabajo en el motor de enrutamiento o en hardware en línea, con límites de recursos muy distintos. Un túnel visible en la configuración no le dice cuál de esas rutas lo transporta realmente.
Las cinco partes de la tupla
Anote la combinación antes de leer cualquier recomendación, porque una parte puede invalidar a las demás. Un número de pieza que soportaba un servicio hace tres años no dice nada sobre la tarjeta ni la versión de este chasis. Lea las filas siguientes como lista de comprobación y luego rellene los valores que la configuración no puede mostrarle.
| 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 |
Las familias de direcciones y la carga de trabajo son las dos filas que la gente se salta, y ambas son baratas de comprobar y caras de descubrir tarde. Lea la tupla en el equipo y no en una hoja de cálculo, porque una configuración informa de lo que usted pidió, no de lo que está instalado. Dos comandos aportan casi todo: show chassis hardware nombra la tarjeta realmente instalada y show version da la versión exacta. Ninguno de los dos depende de que la configuración sea correcta, y ahí está la clave.
show chassis hardware
show versionLos umbrales de versión son umbrales reales
El detalle de la versión no es una formalidad. La descripción general de IPsec de Juniper sitúa el soporte de AES-GCM para tarjetas multiservicio en Junos 17.3R1, con el modo FIPS a partir de 17.4R1. Por tanto, la misma función tiene dos umbrales según cómo se opere la plataforma, y el modo que usted ejecute decide cuál se aplica. Compruebe el modo antes de comprobar la lista de funciones.
Lea las notas de la versión exacta instalada, no la más reciente documentada. Una capacidad que llegó en una compilación posterior no puede darse por presente en una anterior, y una afirmación escrita para una tarjeta no se traslada a otra. Copie la línea de las notas de la versión en el registro de diseño para que la afirmación lleve su propia fuente, porque una declaración de soporte escrita para una familia de plataformas no es una declaración sobre el modo que usted ejecuta ni sobre la tarjeta que tiene.
La capacidad es una carga de trabajo, no un titular
Una cifra de rendimiento de titular sin sus condiciones de medición es un número de marketing. Los paquetes pequeños cuestan mucho más por bit que los grandes, las asociaciones simultáneas consumen memoria y cualquier otro servicio que comparta la tarjeta reduce lo que queda.
Estime a partir del tráfico que espera: tamaños de paquete típicos y en el peor caso, número de pares y si esa tarjeta también termina NAT u otro servicio. Luego deje margen para el día en que una ruta lleve más carga de la que supuso el diseño. Un plan de capacidad que da por sentado hardware ocioso es un deseo, no un plan. Si la cifra importa para el caso de negocio, mídala una vez en el equipo bajo una carga representativa y guarde esa medición con el diseño.
Escriba el registro antes del diseño
Para cada capacidad que necesite el diseño, guarde la referencia de plataforma, la documentación ajustada a la versión y cualquier restricción no resuelta en un mismo sitio. Cuando falle una fila de la tupla, compare otra pasarela ya aprobada en lugar de rehacer el diseño en torno a una lista de compras obsoleta. El registro debe decir qué sistema exacto hace el trabajo y bajo qué límites.
Solo entonces compruebe el par, porque la compatibilidad de protocolo con el extremo remoto es la siguiente pregunta y nunca sustituye al soporte local. Un par que acepta las propuestas no puede ayudar a un chasis que jamás cifra un paquete.