Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

gRIBI

gRPC Routing Information Base Interface (gRPC) est un service gRPC qui permet aux applications externes d’ajouter, de modifier et de supprimer des routes par programmation sur un équipement réseau.

Le service gRIBI est une API permettant d'ajouter, de modifier et de supprimer des entrées de routage dans la base d'informations de routage (RIB, également connue sous le nom de table de routage) d'un appareil. Si l'entrée est éligible au transfert, le système d'exploitation ajoute automatiquement l'entrée à la base d'informations de transfert (FIB) de l'appareil, également appelée table de transfert. Les applications clientes gRIBI peuvent utiliser n’importe quel langage pris en charge par Juniper Extension Toolkit (JET). L’application cliente peut s’exécuter sur un système de gestion réseau externe ou en tant qu’application locale sur l’équipement réseau.

Le fichier de définition de prototo du service gRIBI se trouve à https://github.com/openconfig/gribi/blob/master/v1/proto/service/gribi.proto. Les messages gRIBI pris en charge par les équipements Junos se trouvent dans le package IDL de JET.

Le modèle AFT (Abstract Forwarding Table) OpenConfig est un modèle de données YANG qui décrit les entrées de transfert installées sur un équipement réseau. gRIBI utilise une version traduite par Protocol Buffer du modèle OpenConfig AFT pour décrire les entrées RIB qu’il peut modifier. La représentation protobuf du schéma AFT OpenConfig se trouve dans le fichier de définition proto situé à https://github.com/openconfig/gribi/blob/master/v1/proto/gribi_aft/gribi_aft.proto.

Avantages de gRIBI :

  • Envoie des accusés de réception lorsque vous programmez un itinéraire.
  • Prend en charge les recherches hiérarchiques.
  • Prend en charge l’arbitrage lorsque plusieurs clients sont connectés à la session gRIBI.

Utilisez la commande pour afficher les show route extensive données de route pour gRIBI, y compris l’ID client et l’ID de groupe de sauts suivant utilisé par la route.

Remarque :

Nous vous recommandons d’utiliser gRIBI ou l’API de service JET RIB, mais pas les deux simultanément, en particulier pour le même ensemble de routes.

RPC pris en charge

Les équipements Junos prennent en charge les RPC de service gRIBI pour récupérer, ajouter, modifier ou supprimer à distance des routes du RIB d'un équipement. Les RPC fonctionnent en modifiant ou en lisant les tables de transfert abstraites (AFT) sur l’équipement.

Tableau 1 : RPC gribi.proto pris en charge
RPC Définition Introduit dans la version
Modify()

Ajouter, modifier ou supprimer des entrées de l’AFT.

Junos OS version 19.4R1

Junos OS Evolved version 20.3R1
Get()

Récupérez les entrées installées dans l’AFT.

Junos OS Evolved 22.2R1
Flush()

Supprimez toutes les entrées AFT de l'appareil qui correspondent à ce qui est décrit dans le FlushRequest message.

Junos OS Evolved 22.2R1

Configuration des équipements réseau

Junos OS Evolved version 23.4R1 et ultérieures

Avant de commencer :

Pour configurer le périphérique réseau pour gRIBI :

  1. Créez une instance de routage avec transfert basé sur des filtres.
  2. Configurez les deux stratégies : l’une pour gérer la résolution multichemin et l’autre pour gérer l’équilibrage de charge.

    Dans cet exemple, une stratégie appelée mp-resolve gère la résolution de chemins multiples. Si l’itinéraire de résolution comporte plusieurs chemins, l’itinéraire résolu se résout sur tous les chemins. La stratégie pplb indique au moteur de transfert de paquets d’équilibrer le trafic pour chaque paquet.

  3. Définissez le temps d’arrêt des restes pour donner au système suffisamment de temps pour mettre à jour les itinéraires. Après le redémarrage du système, le processus rpd attend l’expiration du temps d’arrêt restant avant de nettoyer les routes. Le processus rpd ne supprime pas les routes mises à jour avant l’expiration du temps d’attente.

    Vous êtes maintenant prêt à utiliser les RPC de service gRIBI.

Avant Junos OS Evolved version 23.4R1

Avant de commencer :

Pour configurer le périphérique réseau pour gRIBI :

  1. Créez une instance de routage avec transfert basé sur des filtres.
  2. Configurez la ou les tables de routage que vous souhaitez utiliser pour la résolution de route par défaut, du protocole de la famille IPv4 et du protocole de la famille IPv6 dans votre instance de routage.

    Vous pouvez spécifier jusqu’à deux tables de routage pour chaque famille de protocoles. Le schéma de résolution de route vérifie uniquement la deuxième table de routage s'il ne trouve pas d'entrée pour l'adresse next-hop du protocole dans la première table de routage.

    Dans cet exemple, il s’agit de la teVRF.inet.0 table de routage par défaut. S’il n’existe pas de route pour l’adresse du saut suivant dans cette table de routage, le schéma de solution de routage vérifie la inet.3 table.

  3. Spécifiez les stratégies d’importation pour les arbres de résolution des familles IPv4 et IPv6.

    Par exemple :

  4. Configurez les deux stratégies : l’une pour gérer la résolution multichemin et l’autre pour gérer l’équilibrage de charge.

    Dans cet exemple, une stratégie appelée mp-resolve gère la résolution de chemins multiples. Si l’itinéraire de résolution comporte plusieurs chemins, l’itinéraire résolu se résout sur tous les chemins. La stratégie pplb indique au moteur de transfert de paquets d’équilibrer le trafic pour chaque paquet.

  5. Configurez les options de routage pour conserver la hiérarchie du saut suivant lors de l’installation d’un saut suivant dans le plan de transfert.
  6. Configurez la ou les tables de routage que vous souhaitez utiliser pour la résolution de routage des protocoles de la famille IPv4 et IPv6 et la stratégie de résolution de routage au niveau des options de routage. Répétez cette configuration pour chaque table de routage que vous avez configurée au niveau de l’instance de routage.

    Par exemple :

  7. Définissez le temps d’arrêt des restes pour donner au système suffisamment de temps pour mettre à jour les itinéraires. Après le redémarrage du système, le processus rpd attend l’expiration du temps d’arrêt restant avant de nettoyer les routes. Le processus rpd ne supprime pas les routes mises à jour avant l’expiration du temps d’attente.

    Vous êtes maintenant prêt à utiliser les RPC de service gRIBI.

Modifier les routes

Utilisez le RPC pour installer de nouvelles routes et modifier les Modify() routes existantes dans le RIB du serveur gRIBI. Les routes sont ajoutées en tant que routes statiques.

Modify()est un RPC de streaming bidirectionnel. Le client envoie un RPC contenant ModifyRequest des Modify() messages pour modifier une entrée AFT sur le serveur. Pour chaque ModifyRequest, le serveur gRIBI répond au client par un ModifyResponse message.

Le ModifyRequest message comprend un ou plusieurs AFTOperation messages. Chaque AFTOperation message définit une demande d’ajout, de modification ou de suppression d’une seule entrée AFT. Le serveur gRIBI traite les opérations AFT dans l’ordre dans lequel le Modify() RPC les diffuse.

Les équipements Junos prennent en charge les types d’entrées AFT suivants :

  • IPv4Entry: programme d’une route IPv4.
  • NextHopEntry: programme d’un saut suivant.
  • NextHopGroup: programme un groupe de sauts suivant.

Utilisez le Modify() RPC pour exécuter les fonctions suivantes :

Accusés de réception de route

Le serveur envoie un accusé de réception lorsque vous programmez avec succès une route dans le moteur de transfert de paquets à l’aide Modify() du RPC. Si l’API gRIBI ne parvient pas à programmer une route dans le moteur de transfert de paquets dans le délai d’attente donné, le serveur envoie un message d’erreur. Vous pouvez configurer la durée de ce délai d’expiration. L’accusé de réception n’est valable que pour l’itinéraire le plus récent. Si une ancienne route envoie un accusé de réception mais que la nouvelle route n’en envoie pas, le moteur de transfert de paquets l’enregistre comme une erreur.

Les équipements Junos prennent en charge les valeurs suivantes dans le entry champ du message AFTOperation:

Remarque :

Les équipements Junos ne prennent pas en charge cette MAC_ENTRY option.

Utilisez la show route extensive commande pour afficher l’état de l’accusé de réception. L’état de l’accusé de réception est persistant lors des redémarrages du processus rpd.

Programmer une route IPv4

Pour programmer une route IPv4, utilisez l’entrée IPv4Entry AFT. L’AFT fait correspondre les paquets d’entrée en fonction de l’adresse de destination et les mappe aux sauts suivants correspondants. Installez l’entrée AFT sur l’instance VRF par défaut ainsi que sur les instances VRF d’ingénierie de trafic de votre réseau. Pour installer une entrée AFT dans une instance autre que par défaut, spécifiez l’instance VRF dans le network_instance champ du AFTOperation message. Par exemple :

  • Instance VRF d’ingénierie de trafic : g_b4_cos1
  • Définissez le network_instance champ sur : g_b4_cos1

Le client gRIBI ne programme l’entrée IPv4Entry AFT sur le serveur qu’après avoir reçu des accusés de réception du serveur indiquant que le serveur a reçu les messages associés NextHopGroup NextHop . Si le client programme l’entrée IPv4Entry AFT sur le serveur sans accusé de réception du NextHopGroup message, il ajoute la route vers le serveur en tant que route cachée.

Programmez les prochains sauts et les groupes de prochains sauts

Utilisez le RPC gRIBI Modify() pour programmer un saut suivant ou un groupe de sauts suivant sur le serveur gRIBI. Le RPC ne crée que les sauts suivants et les groupes de sauts suivants dans l’instance VRF par défaut.

Lorsqu’il y a des sauts suivants et des groupes de sauts suivants dans le même ModifyRequest message, le client gRIBI les gère en fonction de l’opération AFT. Si l’opération AFT ajoute NextHop et NextHopGroup entre, le client ajoute tous les sauts suivants au serveur avant d’ajouter les groupes de sauts suivants. Si l’opération AFT supprime NextHop et NextHopGroup saisit, le client les traite dans l’ordre inverse : il supprime tous les groupes de sauts suivants avant de supprimer les sauts suivants.

Dans les équipements Junos, le RPC instancie les sauts suivants dans la table sous la inet6.3 forme FC01::next_hop_id, où l’ID de saut suivant est en hexadécimal. Par exemple, si l’ID de saut suivant est 10, le serveur installe une route appelée FC01::A dans la inet6.3 table.

Les groupes de sauts suivants apparaissent dans le tableau sous la inet6.3 forme FC02::next_hop_id. Par exemple, si l’ID du groupe de sauts suivant est 100, le serveur installe une route appelée FC02::64 dans la inet6.3 table.

Par exemple, pour programmer un objet de saut suivant via une interface directement accessible :

  1. En supposant que l’adresse 10.0.1.2 est accessible via l’interface et-0/0/7.0, définissez les champs suivants dans le Afts message, où = signifie définir le champ à cette valeur :

  2. Définissez les champs de AFTOperation message comme suit :

  3. Définissez le ModifyRequest message pour utiliser ce qui AFTOperation est défini ci-dessus.

  4. Appelez le Modify() RPC avec le message ci-dessus ModifyRequest .

  5. Pour confirmer que la route a été programmée avec succès, utilisez la show route programmed commande de la CLI.

Programmez les prochains sauts avec des adresses MAC

Vous pouvez également identifier un saut suivant avec son adresse MAC au lieu de son adresse IP. Cette fonctionnalité est utile dans les réseaux où les périphériques ne peuvent pas utiliser le protocole ARP (Address Resolution Protocol) dynamique ou le protocole NDP (Neighbor Discovery Protocol) pour rechercher l'adresse MAC du saut suivant. Pour utiliser l’adresse MAC, utilisez le mac_address champ au lieu du ip_address champ dans le message AFT.

Remarque : Tout le trafic utilisant cette interface utilise l’adresse MAC statique programmée par le service gRIBI, même le trafic sur les routes non programmées par le service gRIBI.

Une fois que vous avez utilisé le service gRIBI pour programmer une adresse MAC en tant que saut suivant sur l’interface, l’équipement n’utilise pas ARP dynamique ou NDP pour le trafic utilisant cette interface. Si le saut suivant gRIBI programmé est supprimé ou purgé lorsque le client se déconnecte, l’équipement réactive automatiquement ARP sur l’interface et la route continue de fonctionner à l’aide de l’ARP dynamique.

Par exemple, pour programmer un objet de saut suivant avec une adresse MAC via une interface directement accessible :

  1. Assurez-vous que l’interface que vous souhaitez programmer avec un saut suivant est une interface numérotée.

  2. Assurez-vous que la famille IPv6 est activée sur l’interface.

  3. En supposant que l’adresse MAC 00:00:5E :00:53:00 est accessible via l’interface et-0/0/7.0, définissez les champs suivants dans le Afts message, où = signifie définir le champ sur cette valeur :

  4. Définissez les champs de AFTOperation message comme suit :

  5. Définissez le ModifyRequest message pour utiliser ce qui AFTOperation est défini ci-dessus.

  6. Appelez le Modify() RPC avec le message ci-dessus ModifyRequest .

  7. Pour confirmer que la route a été programmée avec succès, utilisez la show route programmed commande de la CLI.

Recherches hiérarchiques et tunnelisation IP-in-IP

L’implémentation Junos de gRIBI prend en charge les recherches hiérarchiques. Pour configurer des recherches hiérarchiques, utilisez l’AFT IPv4 pour programmer des points de terminaison tunnel IP-IP et des routes d’adresses IP virtuelles de groupes de sites.

Pour encapsuler le trafic sur le nœud entrant dans un tunnel IP vers IP, définissez les champs suivants dans le NextHop message :

Arbitrage pour plusieurs clients

Le Modify() RPC prend en charge l’arbitrage lorsque plusieurs clients sont connectés au serveur gRIBI. L’arbitrage détermine quel client peut effectuer quelles opérations.

Utilisez le SessionParameters message pour définir le mode de persistance et le mode de redondance client pour les clients gRIBI. Tous les clients doivent envoyer les mêmes valeurs de tous les attributs du SessionParameters message. SessionParameters ne doit être envoyé qu’une seule fois pendant la durée de vie de la session.

SessionParameters doit être le premier message envoyé après une reconnexion. Lorsqu’un client se reconnecte, une nouvelle session démarre. Si d’autres clients sont déjà connectés, faites correspondre les valeurs du SessionParameters message aux valeurs définies par les clients existants. Si tous les clients se reconnectent, vous pouvez définir les valeurs du SessionParameters message sur des valeurs différentes de celles utilisées dans la session précédente.

Les équipements Junos prennent en charge les deux PRESERVE modes et DELETE la persistance. Si le mode de persistance est défini sur PRESERVE, le serveur conserve les entrées AFT ajoutées par le client même après la déconnexion du client. Si le mode de persistance est défini sur DELETE, le serveur supprime les entrées AFT lorsque le client se déconnecte.

Nous vous recommandons de supprimer toutes les routes avant de modifier les paramètres de session. Vous pouvez constater un comportement inattendu si vous modifiez les paramètres de session et basculez le mode de redondance entre ALL_PRIMARY et SINGLE_PRIMARY après l’ajout de routes dans l’autre mode.

Lorsqu’il existe plusieurs clients, vous devez choisir entre deux modes de redondance client :

Mode principal

En ALL_PRIMARY mode redondance :

  • Tout client peut modifier les itinéraires.

  • Plusieurs clients peuvent ajouter la même entrée AFT.

  • L’API gRIBI gère un mappage des clients qui ont ajouté la route.

  • La première opération d’ajout ajoute l’entrée au RIB. Les opérations d’ajout ultérieures pour la même entrée d’un client différent ajoutent le client à la liste des clients référençant l’entrée.

  • Les opérations de suppression suppriment le client de la liste des clients référençant l’entrée. L’entrée n’est supprimée que lorsqu’aucun client ne la référence.

Remarque :

Lorsqu’elle FlushRequest est traitée, les entrées sont supprimées sans aucune vérification du nombre de références.

Utilisez la show route extensive commande pour afficher les détails de l’itinéraire. Voici un exemple de ce que la show route extensive commande affiche en ALL_PRIMARY mode. Le résultat a été raccourci pour plus de clarté.

Mode primaire unique

En SINGLE_PRIMARY mode redondance :

  • Les clients gRIBI peuvent avoir un rôle principal (actif) ou de secours.

  • Seul le client principal peut effectuer des opérations AFT.

  • Le client ayant l’ID électoral le plus élevé est le client principal. Tous les autres clients sont des clients de secours.

  • Lorsqu’un client de sauvegarde devient le client principal, les routes ajoutées par le client principal précédent peuvent être modifiées par le nouveau client principal.

Définissez l’ID de choix pour chaque appareil afin de déterminer quel client est le client principal. Vous ne pouvez définir l’ID d’élection qu’en SINGLE_PRIMARY mode de redondance. L’ID d’élection est conservé même si un client est à l’état inactif. Si le client principal se déconnecte, il reste le client principal jusqu’à ce que vous définissiez l’ID d’élection d’un autre appareil sur plus élevé. Une fois l’ID d’élection défini, le nouveau client principal continue de programmer les entrées gRIBI.

Pour mettre à jour l’ID d’élection, envoyez le ModifyRequest message avec l’ID d’élection défini sur sa nouvelle valeur. Chaque client doit avoir un numéro d’identification d’élection unique. Ne définissez aucun autre champ du message lorsque vous mettez à jour l’ID d’élection ModifyRequest .

L’identifiant de l’élection est présent dans les messages suivants :

  • ModifyRequest: définit l’ID d’élection du client. Le client ayant le numéro d’identification électoral le plus élevé devient le client principal.

  • AFTOperation: détermine si le serveur doit traiter l’opération AFT.

  • ModifyResponse: le serveur répond avec l’ID d’élection actuel le plus élevé.

Utilisez la show programmable-rpd clients detail commande pour afficher l’ID de groupe et indiquer si le client a le rôle principal ou de secours.

Utilisez la show route extensive commande pour afficher les détails de l’itinéraire. Voici un exemple de ce que la show route extensive commande affiche en SINGLE_PRIMARY mode. Le résultat a été raccourci pour plus de clarté.

Programmer une route de secours dans une instance VRF

Lorsqu’un saut suivant devient inaccessible via une route statique, le réseau peut réacheminer le trafic vers une autre route pour éviter toute interruption du trafic. Cette route alternative est appelée route de secours. Si le trafic n’a pas été encapsulé dans un tunnel, configurez la route statique de secours comme vous le feriez habituellement avec la CLI. Toutefois, si le trafic a été encapsulé dans un tunnel, vous pouvez utiliser gRIBI pour programmer un tunnel de secours qui inclut la décapsulation et l’encapsulation.

Vous pouvez programmer la route de secours dans le VRF de sorte que le système décapsule le trafic de l’ancien tunnel et le réencapsule dans un nouveau tunnel avant de réacheminer le trafic vers le saut suivant. Cette fonctionnalité prend en charge le transport IPv4 pour les tunnels IP-IP dynamiques avec une charge utile IPv4 ou IPv6.

Pour programmer un tunnel IP de repli avec fonctionnalité de décapsulation et de réencapsulation, définissez les champs suivants dans le NextHop message :

Vous pouvez utiliser une route par défaut dans une instance VRF (Virtual Routing and Forwarding) d’ingénierie du trafic comme route de secours. Ajoutez d’abord l’itinéraire par défaut au VRF afin que les futurs itinéraires que vous configurez dans le VRF l’utilisent comme itinéraire de secours. Pour utiliser cette route par défaut, définissez le decapsulate_header champ sur OPENCONFIGAFTTYPESENCAPSULATION HEADERTYPE_IPV4 et définissez network_instance sur DEFAULT. Cette route par défaut a un saut suivant avec la décapsulation et recherche des routes dans le VRF par défaut.

Vous pouvez également sélectionner un groupe de saut suivant de sauvegarde pour faciliter la configuration d’un itinéraire de secours. Pour ce faire, définissez le backup_next_hop_group champ dans le NextHopGroup message.

Sélection de l’instance VRF

gRIBI ne prend pas en charge la programmation de routes dans une instance VRF qui n’est pas par défaut. Pour utiliser une instance VRF qui n’est pas par défaut, configurez d’abord un filtre de pare-feu à l’aide de la CLI. Le filtre du pare-feu doit correspondre au protocole DSCP et IP requis. Appliquez le filtre à l’interface sur laquelle le trafic est attendu.

Par exemple, si le trafic provient de l’interface et-0/0/0 :

Transfert basé sur des stratégies

Utilisez le message pour programmer le PolicyForwardingEntry transfert basé sur la politique sur le serveur gRIBI. Le transfert basé sur des stratégies garantit que le trafic déplacé vers le tunnel de secours reste dans le tunnel, indépendamment de ce que dit la table de routage.

Pour définir les conditions de correspondance et programmer une stratégie de transfert de trafic :

  1. Définissez les champs suivants dans le Afts message :

  2. Définissez les champs suivants dans le AFTOperation message :

  3. Définissez le ModifyRequest message pour utiliser ce qui AFTOperation est défini ci-dessus.

  4. Appelez le Modify() RPC avec le message ci-dessus ModifyRequest .

Obtenir des routes

Lorsque le client perd la connexion au serveur gRIBI, les routes programmées pendant le temps d’arrêt peuvent ne pas être ajoutées au serveur. Une fois la connexion au serveur rétablie, utilisez le Get() RPC pour vérifier que toutes les routes ont été correctement ajoutées à la table de routage du serveur. Le Get() RPC est également utile pour vérifier périodiquement que les routes installées sur un serveur sont correctes et rapprocher les éventuelles différences.

Le Get() RPC récupère le contenu des AFT installés sur le serveur. Lorsque le client envoie une Get() requête RPC, le serveur répond avec l’ensemble des entrées actuellement installées à l’aide GetResponse du flux. Le serveur ne répond qu’avec les entrées qui ont fait l’objet d’un accusé de réception. Une fois que le serveur a envoyé toutes les entrées au client, le serveur ferme le RPC.

Si GRES (graceful moteur de routage switchover) est configuré, le serveur gRIBI et le processus rpd récupèrent également les routes après le redémarrage du serveur gRIBI. Une fois que le client s’est reconnecté au serveur, le client envoie automatiquement une requête RPC gRIBI Get() au serveur. Si GRES est configuré, le client rapproche les routes sur le serveur. Si le client envoie une autre Get() requête RPC, le GetResponse flux inclut les routes réconciliées actives sur le serveur. Si GRES est configuré et que le routage non-stop n’est pas configuré, l’API gRIBI récupère également les routes après un basculement du moteur de routage.

Remarque :

Seules les routes actives sont récupérées lorsque le processus RPD redémarre.

Routes de vidage

Le Flush() RPC supprime toutes les routes programmées gRIBI du serveur qui correspondent à ce qui est décrit dans le FlushRequest message. L’envoi d’un FlushRequest message est un moyen rapide et facile de supprimer les routes programmées gRIBI du serveur.

Lorsque des routes sont présentes dans une instance VRF d’ingénierie de trafic, videz-les de l’instance VRF à l’aide Flush() du RPC avant de supprimer l’instance VRF.

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libération
Descriptif
23.4R1-EVO
Vous n’avez plus besoin de configurer des instructions au niveau de la hiérarchie [edit routing-options, resolution] pour exécuter des RPC de service gRIBI.