Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
EN ESTA PÁGINA
 

gRIBI

La interfaz de base de información de enrutamiento gRPC (gRIBI) es un servicio gRPC que permite a las aplicaciones externas agregar, modificar y eliminar rutas mediante programación en un dispositivo de red.

El servicio gRIBI es una API para agregar, modificar y eliminar entradas de enrutamiento en la base de información de enrutamiento (RIB, también conocida como tabla de enrutamiento) de un dispositivo. Si la entrada es apta para reenvío, el sistema operativo agrega automáticamente la entrada a la base de información de reenvío (FIB, también conocida como tabla de reenvío) del dispositivo. Las aplicaciones cliente de gRIBI pueden usar cualquier idioma admitido por el kit de herramientas de extensión (JET) de Juniper. La aplicación cliente puede ejecutarse en un sistema de administración de red externo o como una aplicación local en el dispositivo de red.

El archivo de definición de proto del servicio gRIBI se encuentra en https://github.com/openconfig/gribi/blob/master/v1/proto/service/gribi.proto. Los mensajes gRIBI compatibles con los dispositivos de Junos se encuentran en el paquete JET IDL.

El modelo de tabla de reenvío abstracta (AFT) de OpenConfig es un modelo de datos de YANG que describe las entradas de reenvío instaladas en un dispositivo de red. gRIBI utiliza una versión traducida de Protocol Buffer del modelo AFT de OpenConfig para describir las entradas RIB que puede modificar. La representación protobuf del esquema AFT de OpenConfig se encuentra en el archivo de definición de prototipo ubicado en https://github.com/openconfig/gribi/blob/master/v1/proto/gribi_aft/gribi_aft.proto.

Beneficios de gRIBI:

  • Envía confirmaciones cuando se programa una ruta.
  • Admite búsquedas jerárquicas.
  • Admite el arbitraje cuando hay varios clientes conectados a la sesión de gRIBI.

Utilice el show route extensive comando para mostrar los datos de ruta para gRIBI, incluido el ID de cliente y el ID del grupo de salto siguiente utilizado por la ruta.

Nota:

Recomendamos usar gRIBI o la API de servicio JET RIB, no ambos simultáneamente, especialmente para el mismo conjunto de rutas.

RPC compatibles

Los dispositivos Junos admiten RPC de servicio gRIBI para recuperar, agregar, modificar o eliminar rutas de forma remota del RIB de un dispositivo. Las RPC funcionan modificando o leyendo las tablas de reenvío abstractas (AFT) en el dispositivo.

Tabla 1: RPC de gribi.proto compatibles
RPC Definición Introducido en la versión
Modify()

Añadir, modificar o eliminar entradas del AFT.

Junos OS versión 19.4R1

Junos OS Evolved versión 20.3R1
Get()

Recupere las entradas instaladas de la AFT.

Junos OS evolucionado 22.2R1
Flush()

Quite todas las entradas AFT del dispositivo que coincidan con lo descrito en el FlushRequest mensaje.

Junos OS evolucionado 22.2R1

Configuración de dispositivos de red

Junos OS Evolved versión 23.4R1 y posteriores

Antes de empezar:

Para configurar el dispositivo de red para gRIBI:

  1. Cree una instancia de enrutamiento con reenvío basado en filtros.
  2. Configure las dos políticas: una para gestionar la resolución de multirrutas y otra para gestionar el equilibrio de carga.

    En este ejemplo, una política llamada mp-resolve handles multirruta resolve. Si la ruta de resolución tiene varias rutas, la ruta resuelta se resuelve en todas las rutas. La política pplb indica al motor de reenvío de paquetes que equilibre la carga del tráfico de cada paquete.

  3. Establezca el tiempo de espera remanente para que el sistema tenga tiempo suficiente para actualizar las rutas. Después de reiniciar el sistema, el proceso rpd espera hasta que expire el tiempo de espera remanente antes de limpiar las rutas. El proceso rpd no elimina ninguna ruta que se actualice antes de que expire el tiempo de espera.

    Ahora está listo para usar los RPC de servicio de gRIBI.

Antes de la versión 23.4R1 de Junos OS Evolved

Antes de empezar:

Para configurar el dispositivo de red para gRIBI:

  1. Cree una instancia de enrutamiento con reenvío basado en filtros.
  2. Configure las tablas de enrutamiento que desea utilizar para la resolución de ruta predeterminada, del protocolo de familia IPv4 y del protocolo de familia IPv6 en la instancia de enrutamiento.

    Puede especificar hasta dos tablas de enrutamiento para cada familia de protocolos. El esquema de resolución de rutas sólo comprueba la segunda tabla de enrutamiento si no puede encontrar una entrada para la dirección del protocolo de salto siguiente en la primera tabla de enrutamiento.

    En este ejemplo, es teVRF.inet.0 la tabla de enrutamiento predeterminada. Si no hay ninguna ruta para la dirección de salto siguiente en esa tabla de enrutamiento, el esquema de solución de ruta comprueba la inet.3 tabla.

  3. Especifique políticas de importación para los árboles de resolución genealógicos IPv4 e IPv6.

    Por ejemplo:

  4. Configure las dos políticas: una para gestionar la resolución de multirrutas y otra para gestionar el equilibrio de carga.

    En este ejemplo, una política llamada mp-resolve handles multirruta resolve. Si la ruta de resolución tiene varias rutas, la ruta resuelta se resuelve en todas las rutas. La política pplb indica al motor de reenvío de paquetes que equilibre la carga del tráfico de cada paquete.

  5. Configure las opciones de enrutamiento para conservar la jerarquía de salto siguiente al instalar un salto siguiente en el plano de reenvío.
  6. Configure las tablas de enrutamiento que desea utilizar para la resolución de rutas del protocolo de familia IPv4 e IPv6 y la política para la resolución de rutas en el nivel de opciones de enrutamiento. Repita esta configuración para cada tabla de enrutamiento que haya configurado en el nivel de instancia de enrutamiento.

    Por ejemplo:

  7. Establezca el tiempo de espera remanente para que el sistema tenga tiempo suficiente para actualizar las rutas. Después de reiniciar el sistema, el proceso rpd espera hasta que expire el tiempo de espera remanente antes de limpiar las rutas. El proceso rpd no elimina ninguna ruta que se actualice antes de que expire el tiempo de espera.

    Ahora está listo para usar los RPC de servicio de gRIBI.

Modificar rutas

Utilice RPC Modify() para instalar nuevas rutas y editar rutas existentes en el RIB del servidor gRIBI. Las rutas se agregan como rutas estáticas.

Modify() es un RPC de transmisión bidireccional. El cliente envía una Modify() RPC que contiene ModifyRequest mensajes para modificar una entrada AFT en el servidor. Para cada ModifyRequest, el servidor gRIBI responde al cliente con un ModifyResponse mensaje.

El ModifyRequest mensaje consta de uno o más AFTOperation mensajes. Cada AFTOperation mensaje define una solicitud para agregar, modificar o eliminar una sola entrada de AFT. El servidor gRIBI procesa las operaciones AFT en el orden en que el Modify() RPC las transmite.

Los dispositivos Junos admiten los siguientes tipos de entrada AFT:

  • IPv4Entry: programe una ruta IPv4.
  • NextHopEntry—Programe un próximo salto.
  • NextHopGroup—Programe un grupo de salto siguiente.

Utilice RPC Modify() para realizar las siguientes funciones:

Reconocimientos de ruta

El servidor envía una confirmación cuando programa correctamente una ruta en el motor de reenvío de paquetes mediante la Modify() RPC. Si la API de gRIBI no puede programar una ruta en el motor de reenvío de paquetes dentro del período de tiempo de espera especificado, el servidor envía un mensaje de error. Puede configurar la duración de este tiempo de espera. El reconocimiento solo es válido para la ruta más reciente. Si una ruta anterior envía una confirmación pero la nueva no, el motor de reenvío de paquetes lo registra como un error.

Los dispositivos Junos admiten los valores siguientes en el entry campo del mensaje AFTOperation:

Nota:

Los dispositivos Junos no admiten la MAC_ENTRY opción.

Utilice el show route extensive comando para mostrar el estado de confirmación. El estado de confirmación es persistente en los reinicios del proceso rpd.

Programar una ruta IPv4

Para programar una ruta IPv4, utilice la IPv4Entry entrada AFT. El AFT hace coincidir los paquetes de entrada en función de la dirección de destino y los asigna a los siguientes saltos correspondientes. Instale la entrada AFT en la instancia VRF predeterminada, así como las instancias VRF de ingeniería de tráfico en su red. Para instalar una entrada AFT en una instancia no predeterminada, especifique la instancia VRF en el network_instance campo del AFTOperation mensaje. Por ejemplo:

  • Instancia de VRF de ingeniería de tráfico: g_b4_cos1
  • Establezca el network_instance campo en: g_b4_cos1

El cliente gRIBI solo programa la IPv4Entry entrada AFT en el servidor después de recibir confirmaciones del servidor de que el servidor recibió los mensajes asociados NextHopGroup NextHop . Si el cliente programa la IPv4Entry entrada AFT en el servidor sin confirmación del NextHopGroup mensaje, agrega la ruta al servidor como una ruta oculta.

Programa Next Hops y Next Hop Groups

Utilice la RPC de gRIBI Modify() para programar un próximo salto o un grupo de próximos saltos en el servidor de gRIBI. La RPC solo crea los saltos siguientes y los grupos de saltos siguientes dentro de la instancia VRF predeterminada.

Cuando hay grupos de próximos saltos y siguientes saltos en el mismo ModifyRequest mensaje, el cliente gRIBI los maneja de acuerdo con la operación AFT. Si la operación AFT suma NextHop y NextHopGroup entradas, el cliente agrega todos los saltos siguientes al servidor antes de agregar los grupos de saltos siguientes. Si la operación AFT elimina NextHop y NextHopGroup las entradas, el cliente las procesa en el orden inverso: elimina todos los grupos de saltos siguientes antes de eliminar los saltos siguientes.

En dispositivos Junos, la RPC crea una instancia de los siguientes saltos en la inet6.3 tabla como FC01::next_hop_id, donde el ID del próximo salto está en hexadecimal. Por ejemplo, si el ID del siguiente salto es 10, el servidor instala una ruta llamada FC01::A en la inet6.3 tabla.

Los grupos de saltos siguientes aparecen en la inet6.3 tabla como FC02::next_hop_id. Por ejemplo, si el ID del grupo de salto siguiente es 100, el servidor instala una ruta llamada FC02::64 en la inet6.3 tabla.

Por ejemplo, para programar un objeto de siguiente salto a través de una interfaz directamente accesible:

  1. Suponiendo que se puede acceder a la dirección 10.0.1.2 a través de la interfaz et-0/0/7.0, establezca los siguientes campos en el Afts mensaje, donde = means establezca el campo en ese valor:

  2. Establezca los campos de AFTOperation mensaje de la siguiente manera:

  3. Establezca el ModifyRequest mensaje para que utilice el AFTOperation definido anteriormente.

  4. Llame al Modify() RPC con el mensaje anterior ModifyRequest .

  5. Para confirmar que la ruta se programó correctamente, utilice el show route programmed comando en la CLI.

Programar próximos saltos con direcciones MAC

Opcionalmente, puede identificar un próximo salto con su dirección MAC en lugar de su dirección IP. Esta función es útil en redes en las que los dispositivos no pueden usar el protocolo de resolución de direcciones dinámico (ARP) o el protocolo de detección de vecinos (NDP) para buscar la dirección MAC del siguiente salto. Para utilizar la dirección MAC, utilice el mac_address campo en lugar del ip_address campo del mensaje AFT.

Nota: Todo el tráfico que utiliza esta interfaz utiliza la dirección MAC estática programada por el servicio gRIBI, incluso el tráfico en rutas no programadas por el servicio gRIBI.

Después de utilizar el servicio gRIBI para programar una dirección MAC como el siguiente salto en la interfaz, el dispositivo no utiliza ARP ni NDP dinámicos para ningún tráfico que utilice esta interfaz. Si el próximo salto programado de gRIBI se elimina o purga cuando el cliente se desconecta, el dispositivo vuelve a habilitar ARP automáticamente en la interfaz y la ruta continúa funcionando mediante ARP dinámico.

Por ejemplo, para programar un objeto de próximo salto con una dirección MAC a través de una interfaz directamente accesible:

  1. Asegúrese de que la interfaz que desea programar con un salto siguiente sea una interfaz numerada.

  2. Asegúrese de que la familia IPv6 esté habilitada en la interfaz.

  3. Suponiendo que la dirección MAC 00:00:5E:00:53:00 es accesible a través de la interfaz et-0/0/7.0, establezca los siguientes campos en el Afts mensaje, donde = means establezca el campo en ese valor:

  4. Establezca los campos de AFTOperation mensaje de la siguiente manera:

  5. Establezca el ModifyRequest mensaje para que utilice el AFTOperation definido anteriormente.

  6. Llame al Modify() RPC con el mensaje anterior ModifyRequest .

  7. Para confirmar que la ruta se programó correctamente, utilice el show route programmed comando en la CLI.

Búsquedas jerárquicas y tunelización de IP en IP

La implementación de Junos de gRIBI admite búsquedas jerárquicas. Para configurar búsquedas jerárquicas, utilice la AFT IPv4 para programar puntos de conexión de túnel IP-IP y rutas de direcciones IP virtuales de grupo de sitios.

Para encapsular el tráfico en el nodo de entrada en un túnel IP a IP, establezca los campos siguientes en el NextHop mensaje:

Arbitraje para múltiples clientes

El Modify() RPC admite el arbitraje cuando hay varios clientes conectados al servidor gRIBI. El arbitraje determina qué cliente puede realizar qué operaciones.

Utilice el SessionParameters mensaje para establecer el modo de persistencia y el modo de redundancia de cliente para los clientes gRIBI. Todos los clientes deben enviar los mismos valores de todos los atributos del SessionParameters mensaje. SessionParameters debe enviarse solo una vez durante la duración de la sesión.

SessionParameters debe ser el primer mensaje enviado después de una reconexión. Cuando un cliente se vuelve a conectar, se inicia una nueva sesión. Si otros clientes ya están conectados, haga coincidir los valores del SessionParameters mensaje con los valores establecidos por los clientes existentes. Si todos los clientes se vuelven a conectar, puede establecer los valores de los SessionParameters mensajes en valores diferentes a los utilizados en la sesión anterior.

Los dispositivos Junos admiten ambos PRESERVE modos de DELETE persistencia. Si el modo de persistencia se establece en PRESERVE, el servidor conserva las entradas AFT agregadas por el cliente incluso después de que el cliente se desconecte. Si el modo de persistencia se establece en DELETE, el servidor elimina las entradas AFT cuando el cliente se desconecta.

Recomendamos eliminar todas las rutas antes de cambiar los parámetros de sesión. Es posible que observe un comportamiento inesperado si cambia los parámetros de sesión y cambia el modo de redundancia entre ALL_PRIMARY y SINGLE_PRIMARY después de agregar rutas en el otro modo.

Cuando hay varios clientes, debe elegir entre dos modos de redundancia de cliente:

Todos los modos principales

En ALL_PRIMARY modo de redundancia:

  • Cualquier cliente puede modificar rutas.

  • Varios clientes pueden agregar la misma entrada AFT.

  • La API de gRIBI mantiene una asignación de qué clientes han agregado la ruta.

  • La primera operación de adición agrega la entrada a la RIB. Las operaciones de adición posteriores para la misma entrada de un cliente diferente agregan el cliente a la lista de clientes que hacen referencia a la entrada.

  • Las operaciones de eliminación quitan el cliente de la lista de clientes que hacen referencia a la entrada. La entrada sólo se elimina cuando no hay clientes que hagan referencia a la entrada.

Nota:

Cuando FlushRequest se procesa, las entradas se eliminan sin ninguna comprobación de recuento de referencias.

Utilice el show route extensive comando para ver los detalles de la ruta. Este es un ejemplo de lo que muestra el comando en ALL_PRIMARY el show route extensive modo. La salida se ha acortado para mayor claridad.

Modo principal único

En SINGLE_PRIMARY modo de redundancia:

  • Los clientes de gRIBI pueden tener una función principal (activa) o de respaldo.

  • Solo el cliente principal puede realizar operaciones AFT.

  • El cliente con el ID de elección más alto es el cliente principal. Todos los demás clientes son clientes de respaldo.

  • Cuando un cliente de copia de seguridad se convierte en el cliente principal, el nuevo cliente principal puede modificar las rutas agregadas por el cliente principal anterior.

Establezca el ID de elección para cada dispositivo a fin de determinar qué cliente es el cliente principal. Solo puede establecer el ID de elección en SINGLE_PRIMARY modo de redundancia. El ID de la elección se conserva incluso si un cliente está en el estado inactivo. Si el cliente principal se desconecta, seguirá siendo el cliente principal hasta que establezca que el ID de elección de otro dispositivo sea mayor. Después de establecer el ID de elección, el nuevo cliente principal continúa programando las entradas de gRIBI.

Para actualizar el ID de la elección, envíe el ModifyRequest mensaje con el ID de la elección establecido en su nuevo valor. Cada cliente debe tener un ID de elección único. No establezca ningún otro campo del ModifyRequest mensaje cuando actualice el ID de la elección.

El ID de la elección está presente en los siguientes mensajes:

  • ModifyRequest: establezca el ID de elección para el cliente. El cliente con el ID de elección más alto se convierte en el cliente principal.

  • AFTOperation: determina si el servidor debe procesar la operación AFT.

  • ModifyResponse: el servidor responde con el ID de elección más alto actual.

Use el show programmable-rpd clients detail comando para ver el ID de grupo y si el cliente tiene el rol principal o de respaldo.

Utilice el show route extensive comando para ver los detalles de la ruta. Este es un ejemplo de lo que muestra el comando en SINGLE_PRIMARY el show route extensive modo. La salida se ha acortado para mayor claridad.

Programar una ruta de reserva en una instancia de VRF

Cuando un siguiente salto se vuelve inalcanzable a través de una ruta estática, la red puede redirigir el tráfico a través de una ruta alternativa para evitar interrupciones en el tráfico. Esta ruta alternativa se denomina ruta de reserva. Si el tráfico no se encapsuló en un túnel, configure la ruta estática de reserva como lo haría normalmente con la CLI. Sin embargo, si el tráfico se encapsuló en un túnel, puede usar gRIBI para programar un túnel de reserva que incluya la desencapsulación y la encapsulación.

Puede programar la ruta de reserva en el VRF para que el sistema desencapsule el tráfico del túnel antiguo y lo vuelva a encapsular en un nuevo túnel antes de volver a enrutar el tráfico al siguiente salto. Esta característica admite el transporte IPv4 para túneles IP-IP dinámicos con una carga IPv4 o IPv6.

Para programar un túnel IP en IP de reserva con capacidad de desencapsulación y reencapsulación, establezca los campos siguientes en el NextHop mensaje:

Puede utilizar una ruta predeterminada en una instancia de enrutamiento y reenvío virtual (VRF) de ingeniería de tráfico como ruta de respaldo. Agregue primero la ruta predeterminada al VRF para que las rutas futuras que configure en el VRF la usen como ruta de reserva. Para utilizar esta ruta predeterminada, establezca el campo en y establézcalo decapsulate_header network_instance en DEFAULT.OPENCONFIGAFTTYPESENCAPSULATION HEADERTYPE_IPV4 Esta ruta predeterminada tiene un salto siguiente con desencapsulación y busca rutas en el VRF predeterminado.

También puede seleccionar un grupo de salto siguiente de respaldo para facilitar la configuración de una ruta de reserva. Para ello, configure el backup_next_hop_group campo en el NextHopGroup mensaje.

Selección de instancias VRF

gRIBI no admite la programación de rutas en una instancia VRF no predeterminada. Para usar una instancia de VRF no predeterminada, configure primero un filtro de firewall mediante la CLI. El filtro del firewall debe coincidir con el protocolo DSCP e IP requerido. Aplique el filtro a la interfaz en la que se espera el tráfico.

Por ejemplo, si el tráfico está en la interfaz et-0/0/0:

Reenvío basado en políticas

Utilice el mensaje para programar el PolicyForwardingEntry reenvío basado en políticas en el servidor gRIBI. El reenvío basado en políticas garantiza que el tráfico movido al túnel de respaldo permanezca en el túnel independientemente de lo que diga la tabla de enrutamiento.

Para establecer las condiciones de coincidencia y programar una política para reenviar el tráfico:

  1. Establezca los campos siguientes en el Afts mensaje:

  2. Establezca los campos siguientes en el AFTOperation mensaje:

  3. Establezca el ModifyRequest mensaje para que utilice el AFTOperation definido anteriormente.

  4. Llame al Modify() RPC con el mensaje anterior ModifyRequest .

Obtener rutas

Cuando el cliente pierde la conexión con el servidor gRIBI, es posible que las rutas programadas durante el tiempo de inactividad no se agreguen al servidor. Después de que la conexión al servidor vuelva a funcionar, utilice la Get() RPC para comprobar que todas las rutas se agregaron correctamente a la tabla de enrutamiento del servidor. El Get() RPC también es útil para comprobar periódicamente que las rutas instaladas en un servidor son correctas y conciliar cualquier diferencia.

La Get() RPC recupera el contenido de las AFT instaladas en el servidor. Cuando el cliente envía una Get() solicitud RPC, el servidor responde con el conjunto de entradas instaladas actualmente mediante la GetResponse secuencia. El servidor solo responde con las entradas que se han confirmado. Después de que el servidor envía todas las entradas al cliente, el servidor cierra la RPC.

Si se configura un cambio normal del motor de enrutamiento (GRES), el servidor gRIBI y el proceso rpd también recuperan rutas después de que se reinicie el servidor gRIBI. Después de que el cliente se vuelve a conectar al servidor, el cliente envía automáticamente una solicitud RPC gRIBI Get() al servidor. Si GRES está configurado, el cliente concilia las rutas en el servidor. Si el cliente envía otra Get() solicitud RPC, la GetResponse secuencia incluye las rutas conciliadas activas en el servidor. Si GRES está configurado y el enrutamiento sin paradas no está configurado, la API de gRIBI también recupera rutas después de un cambio de motor de enrutamiento.

Nota:

Solo las rutas activas se recuperan cuando se reinicia el proceso rpd.

Rutas de descarga

La Flush() RPC elimina todas las rutas programadas gRIBI del servidor que coincidan con lo descrito en el FlushRequest mensaje. Enviar un FlushRequest mensaje es una forma rápida y fácil de eliminar las rutas programadas de gRIBI del servidor.

Cuando haya rutas presentes en una instancia de VRF de ingeniería de tráfico, vacíe las rutas de la instancia de VRF mediante la Flush() RPC antes de eliminar la instancia de VRF.

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.

Lanzamiento
Descripción
23.4R1-EVO
Ya no es necesario configurar instrucciones en el nivel de jerarquía [edit routing-options resolution] para ejecutar RPC de servicio gRIBI.