Asignación segura de bloques de puerto Registro provisional
Registro provisional para una asignación segura de bloques de puerto
Con la asignación de bloques de puertos, generamos un registro syslog por cada conjunto de puertos asignados para un suscriptor. Estos registros se basan en UDP y pueden perderse en la red, particularmente para flujos de larga duración. El registro provisional activa el reenvío de los registros anteriores en un intervalo configurado para los bloques activos que tienen tráfico en al menos uno de los puertos del bloque. En función de la topología de red, puede establecer el intervalo para los registros de asignación de bloques de puerto en función del período del archivo de archivo, de modo que esté presente al menos un registro por bloque de puerto (para un flujo activo) en cada archivo comprimido.
Para configurar el intervalo de registro provisional en el nivel de interfaz de servicios, que se aplica a todos los grupos TDR en esa interfaz ms-, incluya la pba-interim-logging-interval seconds instrucción en el nivel de [edit interfaces ms-fpc/pic/port services-options] jerarquía. Esta pba-interim-logging-interval opción se admite en enrutadores serie MX con MS-DPC y en enrutadores serie M con PIC multiservicios MS-100, MS-400 y MS-500. Esta pba-interim-logging-interval opción se admite en enrutadores serie MX con MS-MPC y MS-MIC a partir de la versión 14.2R2 de Junos OS.
A partir de Junos OS versión 15.1R1, también puede configurar el intervalo de registro provisional a nivel de grupo de TDR. Esta capacidad solo se admite en enrutadores de la serie MX con MS-MPC y MS-MIC. Para configurar el intervalo de registro provisional a nivel de grupo TDR, incluya la interim-logging-interval seconds instrucción en el [edit services nat pool pool-name port secured-port-block-allocation] nivel de jerarquía. Puede especificar un valor de 0 a 86400 segundos para la frecuencia de registro provisional.
Beneficios de Iterim Logging
Le permite identificar los bloques de puerto utilizados actualmente
Elimina la necesidad de buscar y analizar registros archivados para identificar el host interno que está utilizando la dirección IP y el puerto externos
Ver también
Directrices para configurar el registro provisional para la asignación segura de bloques de puerto
Tenga en cuenta las siguientes directrices cuando configure el intervalo de registro provisional para la asignación de bloques de puerto protegidos:
-
El registro provisional solo se habilita cuando se configura la funcionalidad de registro provisional. La
pba-interim-logging-intervalinstrucción que puede configurar en el[edit interfaces ms-fpc/pic/port services-options]nivel de jerarquía de una ms-interface se proporciona para que sea compatible con versiones anteriores. Estapba-interim-logging-intervalopción se admite en enrutadores serie MX con MS-DPC y en enrutadores serie M con PIC multiservicios MS-100, MS-400 y MS-500. Estapba-interim-logging-intervalopción se admite en enrutadores serie MX con MS-MPC y MS-MIC a partir de la versión 14.2R2 de Junos OS.La
interim-logging-intervalinstrucción que está disponible para la configuración en MS-MPC y MS-MIC a partir de la versión 15.1R1 de Junos OS proporciona un registro provisional para un conjunto de TDR específico. -
Si configura la capacidad de registro provisional para que se aplique a todos los grupos de PBA que residen en esa interfaz de servicios en particular y la capacidad de registro provisional para un grupo de PBA específico, el intervalo específico del grupo de TDR tiene prioridad sobre el intervalo específico de la interfaz de servicios. Para los bloques de puertos asignados desde otros conjuntos de PBA para los que no está configurado el intervalo de registro provisional en el nivel de grupo de TDR, se aplica el valor del intervalo de registro configurado en el nivel de interfaz MS-.
-
El valor predeterminado es cero, lo que indica que no se genera ningún mensaje de registro provisional.
-
Los registros provisionales se envían en cualquier momento después del período de tiempo configurado en segundos. La diferencia de tiempo no se fija entre los intervalos de registro de dos registros.
-
Los registros provisionales se generan para los bloques de puertos (activos e inactivos) que contienen al menos un puerto en uso por un flujo que tiene tráfico. No se ejecutan controles de temporizador en los bloques de puerto para generar los registros. Cuando se recibe un paquete en un flujo, la validación se realiza para generar un registro provisional. Si se cumplen las condiciones, se genera un registro provisional para ese bloque de puerto. No se generan registros provisionales para los bloques de puerto eliminados.
-
El registro provisional contiene la marca de hora de la creación del bloque de puerto en formato hexadecimal (cuando se establece la hora local, el valor hexadecimal proporciona la hora en formato UTC).
-
La conversión de la marca de tiempo al formato UTC se puede realizar en el servidor syslog externo según sea necesario.
-
En algunos casos, es posible que la marca de tiempo en valor hexadecimal y la marca de tiempo real en los mensajes ALLOC difieran en un par de segundos. Este comportamiento se produce porque el mecanismo syslog contiene una ligera diferencia cuando lee la hora (como se ve en PORT_BLOCK_ALLOC syslog) y la hora a la que TDR aplicación lee la hora (para actualizar la hora de ALLOC en el contexto suscriptor). El registro provisional del sistema muestra el tiempo de ALLOC recuperado del contexto del suscriptor.
-
Dado que estos registros se generan en el cálculo de la CPU y en la ruta rápida, es posible que se observe un ligero impacto con el rendimiento de la ruta rápida solo cuando se produce una generación del registro.
-
La marca de tiempo de creación de bloques de puerto en hexadecimal se guarda en el mensaje JSERVICES_TDR_PORT_BLOCK_RELEASE, incluso si no hay registro provisional.
-
Si define el intervalo de registro cuando el flujo de tráfico está en curso, esta funcionalidad surte efecto en los flujos nuevos y existentes. No es necesario reiniciar el MIC ni activar o desactivar el conjunto de servicios.
-
Si el tiempo de espera de los flujos o suscriptores está agotado, indica que no se ven paquetes o flujos de tráfico nuevos para estos datos de 5 tuplas o para ese suscriptor en particular. En tal caso, no se generan registros provisionales.
-
Si el intervalo de registro provisional es menor que el tiempo de espera de inactividad del flujo, no se observan registros provisionales cuando se agota el tiempo de espera del flujo y ha transcurrido el intervalo de registro provisional. Si el intervalo de registro provisional es menor que el valor de tiempo de espera del suscriptor, no se observan registros provisionales cuando se agota el tiempo de espera del suscriptor y ha transcurrido el intervalo de registro provisional. Por ejemplo, si el tiempo de espera de inactividad está configurado en 2500 segundos y el registro provisional está configurado como 1800 segundos, cuando se agota el tiempo de espera del flujo, hay un momento en el que han transcurrido 1800 segundos desde que se vio el último paquete en este flujo y no se genera ningún registro provisional en este caso.
-
Los registros provisionales se registran para los grupos que tienen PBA configurado. Si existen agrupaciones sin la configuración de PBA presente en la unidad de procesamiento de red (NPU) de servicio, los registros provisionales no se guardan aunque habilite la funcionalidad de registro provisional.
-
Solo puede configurar un rango de valores para el intervalo en el que se deben generar los registros, como 0, [1800, 86400].
-
Puede habilitar la generación de syslogs mediante la instrucción syslog en los
[edit system]niveles y[edit services service-sets service-set name nat rule rule-name term term-name then]jerarquía que contienen las reglas de TDR con agrupaciones de PBA. Los registros provisionales no se activan si la grabación de syslogs no está habilitada en el sistema. -
Recomendamos que configure el intervalo de registro provisional para que sea mayor que el período de tiempo de espera de inactividad para los flujos establecidos. Además, le recomendamos que configure el intervalo de registro provisional para que sea mayor que el valor de tiempo de espera del suscriptor. Cuando se configura la asignación independiente del punto de conexión (EIM), el intervalo de registro intermedio debe ser mayor que la suma de los valores de tiempo de espera de emparejamiento de agrupación de direcciones (APP) y tiempo de espera de EIM.
-
La transmisión de registros se produce en formato de texto sin formato, similar a otros mensajes de registro que las PIC de servicios no cifran. Se supone que el transporte de troncos y el posicionamiento del recolector de troncos están dentro de un ámbito seguro. Dado que los mensajes no contienen detalles confidenciales, como nombre de usuario o contraseñas, no causan ningún riesgo de seguridad o confiabilidad. El aumento de la generación de mensajes de registro no provoca la posibilidad de una inundación de registros, ya que la frecuencia del registro se puede configurar en función de la topología de la red, los niveles de tráfico y sus necesidades de supervisión.
-
Los registros de PBA en el microkernel comienzan con el prefijo de ASP_*. Estos registros se modificaron para comenzar con el prefijo de JSERVICES_*. A continuación, se muestran ejemplos de registros del sistema para PBA en el microkernel y con los paquetes de proveedor de extensiones de Junos OS instalados y configurados en el dispositivo.
Microkernel: 1970-01-01 00:32:36 {nat64}[FWNAT]:ASP_NAT_PORT_BLOCK_ACTIVE: 2001:db8:0:0:0:0:0:2 -> 10.1.1.1:1050-1091 0x6fJunos OS Extension-Provider (eJunos): 1970-01-01 00:32:36 {nat64}[FWNAT]:JSERVICES_NAT_PORT_BLOCK_ACTIVE: 2001:db8:0:0:0:0:0:2 -> 10.1.1.1:1050-1091 0x6f -
Además, puede especificar el intervalo de registro provisional por grupo TDR en lugar de una configuración global por MS-PIC, en función de si desea que la configuración de syslog se aplique a todos los grupos TDR de un dispositivo o para un grupo TDR determinado. Para TDR, las interfaces miembro deben tener configurado el paquete jservices-nat. El mensaje de registro del sistema JSERVICES_TDR_PORT_BLOCK_ACTIVE se genera cuando se configura el registro provisional para PBA. Los siguientes registros de ejemplo indican los mensajes de registro generados con el intervalo intermedio establecido en 1800 segundos. Puede observar que la marca de tiempo entre registros provisionales consecutivos es de más de 1800 segundos.
1970-01-01 00:01:51 [FWNAT]:JSERVICES_NAT_PORT_BLOCK_ALLOC: 2001:db8:0:0:0:0:0:2 -> 10.1.1.1:1050-1091 1970-01-01 00:32:36 {nat64}[FWNAT]:JSERVICES_NAT_PORT_BLOCK_ACTIVE: 2001:db8:0:0:0:0:0:2 -> 10.1.1.1:1050-1091 0x6f 1970-01-01 01:03:20 {nat64}[FWNAT]:JSERVICES_NAT_PORT_BLOCK_ACTIVE: 2001:db8:0:0:0:0:0:2 -> 10.1.1.1:1050-1091 0x6f 1970-01-01 01:34:04 {nat64}[FWNAT]:JSERVICES_NAT_PORT_BLOCK_ACTIVE: 2001:db8:0:0:0:0:0:2 -> 10.1.1.1:1050-1091 0x6f 1970-01-01 02:04:48 {nat64}[FWNAT]:JSERVICES_NAT_PORT_BLOCK_ACTIVE: 2001:db8:0:0:0:0:0:2 -> 10.1.1.1:1050-1091 0x6f -
A partir de la versión 19.3R1 de Junos OS, cuando se configura un prefijo de softwire distinto del 128, todos los registros de JSERVICES_TDR_PORT_BLOCK ahora muestran el prefijo dirección B4. Se modifican los siguientes JSERVICES_TDR_PORT_BLOCK:
-
JSERVICES_TDR_BLOQUE_DE_PUERTO_ALLOC
-
JSERVICES_TDR_PORT_BLOCK_RELEASE
-
JSERVICES_TDR_BLOQUE_DE_PUERTO_ACTIVO
En versiones anteriores de Junos OS, cuando se configuraba un prefijo de softwire, algunas de las direcciones B4 que se mostraban en el registro JSERVICES_TDR_PORT_BLOCK eran direcciones /128. Por ejemplo, cuando se configuró un prefijo /56, el bloque de puerto syslog mostró las siguientes direcciones B4:
-
JSERVICES_TDR_PORT_BLOCK_ALLOC mostraba la dirección /128 B4 del primer B4 al que se le asignó un puerto desde un bloque de puerto determinado
-
JSERVICES_TDR_PORT_BLOCK_RELEASE mostraba la dirección /128 B4 del último B4 que liberó su puerto de nuevo al bloque de puerto
-
Ver también
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.