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

RESUMEN La interfaz 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 del dispositivo (FIB, también conocida como tabla de reenvío). Las aplicaciones cliente de gRIBI pueden utilizar cualquier lenguaje compatible con 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 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 Junos se encuentran en el paquete JET IDL.

El modelo de tabla de reenvío abstracto (AFT) de OpenConfig es un modelo de datos 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 OpenConfig AFT 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 proto, 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 comando para mostrar los datos de show route extensive ruta para gRIBI, incluido el ID de cliente y el ID del grupo del próximo salto utilizado por la ruta.

Nota:

Recomendamos usar gRIBI o la API de servicio JET RIB, no ambas 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 de la RIB de un dispositivo. Las RPC funcionan modificando o leyendo las tablas de reenvío abstracto (AFT) en el dispositivo.

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

Agregue, modifique o elimine entradas de la 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 que se describe 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 directivas: una para controlar la resolución de múltiples rutas y otra para controlar el equilibrio de carga.

    En este ejemplo, una política llamada mp-resolve handles multipath 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 dar al sistema 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 gRIBI.

Antes de Junos OS Evolved, versión 23.4R1

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 usar para la resolución predeterminada de protocolos de familia IPv4 y 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 solo comprueba la segunda tabla de enrutamiento si no puede encontrar una entrada para la dirección del próximo salto del protocolo en la primera tabla de enrutamiento.

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

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

    Por ejemplo:

  4. Configure las dos directivas: una para controlar la resolución de múltiples rutas y otra para controlar el equilibrio de carga.

    En este ejemplo, una política llamada mp-resolve handles multipath 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 del siguiente salto al instalar un salto siguiente en el plano de reenvío.
  6. Configure las tablas de enrutamiento que desea usar para la resolución de rutas del protocolo de las familias IPv4 e IPv6 y la directiva 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 dar al sistema 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 gRIBI.

Modificar rutas

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

Modify() es un RPC de streaming 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 de AFT en el orden en que el Modify() RPC las transmite.

Los dispositivos Junos admiten los siguientes tipos de entrada de AFT:

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

Utilice RPC Modify() para realizar las siguientes funciones:

Agradecimientos de ruta

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

Los dispositivos Junos admiten los siguientes valores 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. La 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 en las instancias VRF de ingeniería de tráfico de su red. Para instalar una entrada de AFT en una instancia no predeterminada, especifique la instancia de 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 acuses de recibo del servidor de que el servidor recibió los mensajes asociados NextHopGroup y NextHop . Si el cliente programa la IPv4Entry entrada AFT en el servidor sin confirmar el NextHopGroup mensaje, agrega la ruta al servidor como una ruta oculta.

Programa Grupos Next Hops y Next Hop

Utilice la RPC gRIBI Modify() para programar un grupo de salto siguiente o siguiente en el servidor gRIBI. El RPC solo crea grupos de saltos y saltos siguientes dentro de la instancia predeterminada de VRF.

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

En los dispositivos Junos, la RPC crea una instancia de los siguientes saltos de la inet6.3 tabla como FC01::next_hop_id, donde el ID del siguiente 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 del salto siguiente aparecen en la inet6.3 tabla como FC02::next_hop_id. Por ejemplo, si el ID del grupo del siguiente salto es 100, el servidor instala una ruta llamada FC02::64 en la inet6.3 tabla.

Por ejemplo, para programar un objeto de salto siguiente 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 = significa establecer el campo en ese valor:

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

  3. Establezca el mensaje para usar lo ModifyRequest 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 de la CLI.

Programe los próximos saltos con direcciones MAC

Opcionalmente, puede identificar un salto siguiente con su dirección MAC en lugar de su dirección IP. Esta función es útil en redes donde los dispositivos no pueden usar el Protocolo de resolución de direcciones dinámico (ARP) o el Protocolo de descubrimiento de vecinos (NDP) para buscar la dirección MAC del próximo 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 o NDP dinámico para ningún tráfico que utilice esta interfaz. Si el próximo salto de gRIBI programado se elimina o se purga cuando el cliente se desconecta, el dispositivo vuelve a habilitar automáticamente ARP en la interfaz y la ruta continúa funcionando usando ARP dinámico.

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

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

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

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

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

  5. Establezca el mensaje para usar lo ModifyRequest 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 de 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, use la AFT IPv4 para programar extremos de túnel IP-IP y rutas de direcciones IP virtuales de grupos de sitios.

Para encapsular el tráfico en el nodo de entrada en un túnel de IP en IP, establezca los siguientes campos 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 de 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 del SessionParameters mensaje 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 primarios

En ALL_PRIMARY modo de redundancia:

  • Cualquier cliente puede modificar rutas.

  • Varios clientes pueden agregar la misma entrada de AFT.

  • La API 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 solo 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 del recuento de referencias.

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

Modo primario único

En SINGLE_PRIMARY modo de redundancia:

  • Los clientes gRIBI pueden tener un rol principal (activo) o de respaldo.

  • Solo el cliente principal puede realizar operaciones de AFT.

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

  • 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 elección se conserva incluso si un cliente está en estado inactivo. Si el cliente principal se desconecta, seguirá siendo el cliente principal hasta que establezca el ID de elección de otro dispositivo en 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 elección, envíe el ModifyRequest mensaje con el ID de elección establecido en su nuevo valor. Cada cliente debe tener un ID electoral único. No establezca ningún otro campo del ModifyRequest mensaje cuando actualice el ID de elección.

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

  • ModifyRequest: permite establecer el ID de elección del 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 de 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 el show route extensive comando muestra en SINGLE_PRIMARY modo. El resultado 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 la interrupción del tráfico. Esta ruta alternativa se denomina ruta de reserva. Si el tráfico no estaba encapsulado 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 desencapsulación y 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 túnel nuevo antes de volver a enrutar el tráfico al siguiente salto. Esta función 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 siguientes campos 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 reserva. 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 en network_instance DEFAULT.OPENCONFIGAFTTYPESENCAPSULATION HEADERTYPE_IPV4 Esta ruta predeterminada tiene un siguiente salto con desencapsulación y busca rutas en el VRF predeterminado.

También puede seleccionar un grupo de copia de seguridad del próximo salto para facilitar la configuración de una ruta de reserva. Para ello, establezca el backup_next_hop_group campo en el NextHopGroup mensaje.

Selección de instancias VRF

gRIBI no admite rutas de programación en una instancia de VRF no predeterminada. Para usar una instancia de VRF no predeterminada, configure primero un filtro de firewall mediante la CLI. El filtro de 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 tráfico:

  1. Establezca los siguientes campos en el Afts mensaje:

  2. Establezca los siguientes campos en el AFTOperation mensaje:

  3. Establezca el mensaje para usar lo ModifyRequest 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. Cuando se recupere la conexión con el servidor, 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 sólo responde con las entradas que han sido confirmadas. Después de que el servidor envía todas las entradas al cliente, el servidor cierra la RPC.

Si se configura un cambio correcto del motor de enrutamiento (GRES), el servidor gRIBI y el proceso rpd también recuperan rutas después de que el servidor gRIBI se reinicie. 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 reconciliadas activas en el servidor. Si GRES está configurado y no se configura el enrutamiento sin interrupciones, la API gRIBI también recupera rutas después de un cambio de motor de enrutamiento.

Nota:

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

Rutas de descarga

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

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

Tabla de historial de cambios

La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.

Lanzamiento
Descripción
cambio completado