Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuración de interfaces RSVP

 

En las siguientes secciones se describe cómo configurar interfaces RSVP:

Configuración de la reducción de Actualizar RSVP

Puede configurar la reducción de la actualización de RSVP en cada interfaz, incluyendo las siguientes instrucciones en la configuración de la interfaz:

  • aggregatey reliable—habilite todas las características de reducción de la actualización RSVP: La agrupación de mensajes RSVP, el identificador de mensajes RSVP, la entrega de mensajes confiable y el Resumen de actualización.

    Para tener una reducción de actualización y una entrega confiable, debe incluir los aggregate Estados reliable de cuenta y.

  • no-aggregate—Deshabilite la agrupación de mensajes RSVP y la actualización conjunta.

  • no-reliable—Deshabilite el ID de mensaje de RSVP, la entrega de mensajes confiable y la actualización conjunta.

Para obtener más información acerca de la reducción de la actualización de RSVP, consulte la RSVP Refresh Reduction.

Si la no-reliable instrucción se configura en el enrutador (se deshabilita la entrega de mensajes de forma confiable), el enrutador acepta mensajes RSVP que incluyan el objeto ID del mensaje, pero ignora el objeto ID del mensaje y sigue realizando un procesamiento estándar de los mensajes. En este caso, no se genera ningún error y RSVP funciona con normalidad.

Sin embargo, no todas las combinaciones entre dos vecinos con distintas capacidades de reducción de actualización funcionan correctamente. Por ejemplo, un enrutador está configurado con aggregate la instrucción no-reliable y la instrucción, reliable o no-aggregate con las instrucciones y. Si un vecino RSVP envía un objeto Summary Actualizar a este enrutador, no se genera ningún error, pero no se puede procesar el objeto Summary Actualizar. En consecuencia, los Estados de RSVP pueden agotar el tiempo de espera de este enrutador si el vecino solo se basa en Actualizar de resumen para actualizar esos Estados de RSVP.

Es recomendable, a menos que haya requisitos específicos, que configure la reducción de la actualización RSVP de manera similar en cada vecino RSVP.

Para habilitar todas las características de reducción de la actualización RSVP en una aggregate interfaz, incluya la siguiente instrucción:

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Para deshabilitar la agrupación de mensajes RSVP y la actualización no-aggregate conjunta, incluya la siguiente instrucción:

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Para habilitar la entrega de mensajes confiables y el ID de mensajes de RSVP reliable en una interfaz, incluya la siguiente instrucción:

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Para deshabilitar el ID del mensaje RSVP, la entrega de mensajes confiable y la no-reliable actualización conjunta de Resumen, incluya la siguiente instrucción:

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Determinación de la capacidad de reducción Actualizar de los vecinos de RSVP

Para determinar la capacidad de reducción de la actualización RSVP de un vecino RSVP, necesita la siguiente información:

  • El bit RR anunciado por el vecino

  • Configuración local de la reducción de la actualización de RSVP

  • Los mensajes RSVP reales recibidos desde el vecino

Para obtener esta información, puede emitir un show rsvp neighbor detail comando. El resultado de ejemplo es el siguiente:

user@host> show rsvp neighbor detail

Para obtener más información sobre show rsvp neighbor detail el comando.

Configuración del intervalo de saludo de RSVP

RSVP supervisa el estado de los vecinos del Protocolo de puerta de enlace interior (IGP) (IS-IS o OSPF) y confía en los protocolos IGP para detectar cuándo se produce un error en un nodo. Si un protocolo de IGP declara un vecino hacia abajo (ya que no se reciben paquetes de saludo), RSVP también deja al otro vecino. Sin embargo, los IGP protocolos y RSVP siguen funcionando de manera independiente cuando se pone un vecino en la proximidad.

Para los enrutadores Juniper Networks, la configuración de un intervalo de saludo más corto o más largo no tiene ningún impacto sobre si se ha desactivado o no una sesión de RSVP. Las sesiones RSVP se mantienen, incluso si ya no se reciben los paquetes de saludo RSVP. Las sesiones RSVP se mantienen hasta que el enrutador deja de recibir IGP paquetes de saludo o la ruta de acceso RSVP y los mensajes RESV agotan el tiempo de espera. Sin embargo, a partir de Junos OS versión 16,1, cuando se agota el tiempo de espera de los mensajes de saludo de RSVP, se desactivan las sesiones RSVP.

El intervalo de saludo de RSVP también podría verse afectado cuando otro’equipo del proveedor desconectase una sesión RSVP. Por ejemplo, un enrutador vecino que no sea de Juniper Networks podría configurarse para supervisar paquetes de saludo de RSVP.

Para modificar la frecuencia con la que RSVP envía paquetes de saludo hello-interval , incluya la siguiente instrucción:

Para obtener una lista de los niveles de jerarquía en los que puede incluir esta instrucción, consulte la sección Resumen de instrucciones.

Configuración de la autenticación RSVP

Todos los intercambios del protocolo RSVP pueden autenticarse para garantizar que solo los vecinos de confianza participan en la configuración de reservas. De forma predeterminada, la autenticación RSVP está deshabilitada.

La autenticación RSVP utiliza un compendio basado en mensajes hash de código de autenticación de mensajes (HMAC) MD5. Este esquema produce una síntesis del mensaje basada en una clave de autenticación secreta y el contenido del mensaje. (El contenido del mensaje también incluye un número de secuencia.) El algoritmo implícito calculado se transmite con mensajes RSVP. Una vez configurada la autenticación, todos los mensajes RSVP recibidos y transmitidos con todos los vecinos se autentican en esta interfaz.

La autenticación MD5 proporciona protección contra la falsificación y la modificación de mensajes. También puede impedir ataques de reproducción. Sin embargo, no ofrece confidencialidad, ya que todos los mensajes se envían en texto no cifrado.

De forma predeterminada, la autenticación está deshabilitada. Para habilitar la autenticación, configure una clave en cada interfaz incluyendo authentication-key la instrucción:

Puede incluir esta instrucción en los siguientes niveles de jerarquía:

  • [edit protocols rsvp interface interface-name]

  • [edit logical-systems logical-system-name protocols rsvp interface interface-name]

Configuración de la suscripción de ancho de banda para tipos de clase

De forma predeterminada, RSVP permite el uso del 100% del ancho de banda para un tipo de clase para las reservas RSVP. Cuando sobresuscribe un tipo de clase para un LSP de multiclase, se permite que la demanda total de todas las sesiones RSVP pueda superar la capacidad real del tipo de clase.

Para obtener instrucciones detalladas acerca de cómo configurar la suscripción de ancho de banda para los tipos de clase, consulte Configuring the Bandwidth Subscription Percentage for LSPs.

Configuración del umbral de actualización de RSVP en una interfaz

Los protocolos de puerta de enlace interior (IGPs) mantienen la base de datos de ingeniería de tráfico, pero el ancho de banda disponible actualmente en los vínculos de la base de datos de ingeniería de tráfico procede de RSVP. Cuando un ancho’de banda de Link s cambia, RSVP informa a la iGPS, que a su vez puede actualizar la base de datos de ingeniería de tráfico y reenviar la nueva información de ancho de banda a todos los nodos de la red. A continuación, los nodos de red saben la cantidad de ancho de banda disponible en el vínculo de la base de datos de ingeniería de tráfico (local o remota) y CSPF pueden calcular correctamente las rutas.

Sin embargo, IGP actualizaciones pueden consumir demasiados recursos del sistema. Dependiendo del número de nodos de una red, puede que no sea conveniente realizar una IGP actualización para los pequeños cambios de ancho de banda. Al configurar la update-threshold instrucción en el [edit protocols rsvp] nivel de la jerarquía, puede ajustar el umbral en el que un cambio en el ancho de banda reservado activa una IGP actualización.

Puede configurar un valor de from 0.00del 1 al 20 por ciento (el valor predeterminado es 10 por ciento) para cuándo activar una actualización IGP. Si el cambio en el ancho de banda reservado es mayor o igual que el porcentaje del umbral configurado del ancho de banda estático de esa interfaz, se producirá una actualización de IGP. Por ejemplo, si ha configurado la update-threshold afirmación para que sea del 15 por ciento y el enrutador descubre que el ancho de banda reservado de un vínculo ha cambiado en un 10% del ancho de banda del vínculo, RSVP no activa una IGP actualización. Sin embargo, si el ancho de banda reservado en un vínculo cambia en un 20 por ciento del ancho de banda de vínculo, RSVP activa una IGP actualización.

También puede configurar el umbral como un valor absoluto mediante la threshold-value opción de la update-threshold instrucción.

Si el valor umbral se configura en más del 20% del ancho de banda del enlace, el valor de umbral se limita al 20% del ancho de banda.

Por ejemplo, si el ancho de banda de una interfaz es 1Gbps threshold-value y el está configurado en más de threshold-value 200Mbps, el se limita en 200Mbps. El servicio umbral: porcentaje se muestra como 20,000% y threshold-value como 200Mbps.

Nota

Las dos opciones, umbral: porcentaje y threshold-value, se excluyen mutuamente. Solo puede configurar una opción en un momento dado para generar una IGP actualización para reservas de ancho de banda inferiores. Como resultado, cuando se configura una opción, se calcula la otra opción y se muestra en la CLI.

Por ejemplo, en un vínculo de 1Gbps, si el umbral: porcentaje está configurada en 5% threshold-value , el se calcula y se muestra como 50Mbps. De forma similar, threshold-value si el está configurado para 50m, entonces el umbral: porcentaje se calcula y se muestra como 5%.

Para ajustar el umbral en el que un cambio en el ancho de banda reservado activa una IGP actualización, incluya la instrucción update-threshold . Debido al umbral de actualización, es posible que la ruta de acceso más corta primero restringida (CSPF) calcule una ruta usando información obsoleta de ancho de banda de la base de datos de ingeniería de tráfico en un vínculo. Si RSVP intenta establecer un LSP a través de esa ruta de acceso, es posible que no haya suficiente ancho de banda en ese vínculo. Cuando esto ocurre, RSVP activa una actualización de la base de datos de ingeniería de tráfico IGP, inundando la información de ancho de banda actualizada en la red. A continuación, CSPF puede volver a calcular el path utilizando la información actualizada del ancho de banda e intentar encontrar una ruta diferente, evitando el vínculo congestionado. Tenga en cuenta que esta funcionalidad es la predeterminada y no necesita ninguna configuración adicional.

Puede configurar la rsvp-error-hold-time instrucción en el [edit protocols mpls] nivel de jerarquía o en [edit logical-systems logical-system-name protocols mpls] el nivel de jerarquía para mejorar la precisión de la base de datos de ingeniería de tráfico (incluida la precisión de las estimaciones de ancho de banda para LSP) con la información proporcionada por el Message. Consulte Improving Traffic Engineering Database Accuracy with RSVP PathErr Messagesdel apartado del apartado de RSVP.

Configuración de RSVP para interfaces no numeradas

El Junos OS es compatible con la ingeniería de tráfico RSVP a través de interfaces no numeradas. La información de ingeniería de tráfico de vínculos no numerados se incluye en el IGP Traffic Transformation Extensions for OSPF y está tal y como se describe en RFC 4203, Extensiones de OSPF para la admisión de conmutación de etiquetas de varios protocolos generalizadas (GMPLS)y RFC 4205, Extensiones Sistema intermedio a sistema intermedio (IS IS) compatibles con la conmutación de etiquetas de varios protocolos generalizada (GMPLS). Los vínculos no numerados también pueden especificarse en el MPLS señalización de ingeniería de tráfico como se describe en RFC 3477, Señalización de vínculos no numerados en protocolo de reserva de recursos-ingeniería de tráfico (RSVP-TE). Esta característica le permite evitar tener que configurar direcciones IP para cada interfaz que participa en la red señalizada con RSVP.

Para configurar RSVP para interfaces no numeradas, debe configurar el enrutador con un identificador de enrutador utilizando router-id la [edit routing-options] instrucción especificada en el nivel de la jerarquía. El identificador de enrutador debe estar disponible para enrutamiento (normalmente, puede utilizar la dirección de bucle de retroceso). Los mensajes de control de RSVP para los vínculos sin numerar se envían mediante la dirección de ID de enrutador (en lugar de una dirección seleccionada al azar).

Para configurar la protección de vínculos y la reenrutación rápida en un enrutador con interfaces no numeradas habilitadas, debe configurar al menos dos direcciones. Recomendamos que configure una interfaz secundaria en el bucle invertido, además de configurar el ID del enrutador.

Release History Table
Publicación
Descripción
Sin embargo, a partir de Junos OS versión 16,1, cuando se agota el tiempo de espera de los mensajes de saludo de RSVP, se desactivan las sesiones RSVP.