Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Préférences de routes statiques et sauts suivants qualifiés

Comprendre les préférences de routes statiques et les sauts suivants qualifiés

Une adresse de destination de route statique peut être associée à plusieurs sauts suivants. Dans ce cas, plusieurs itinéraires sont insérés dans la table de routage et la sélection de l’itinéraire doit avoir lieu. Étant donné que le critère principal de sélection d’itinéraire est la préférence d’itinéraire, vous pouvez contrôler les itinéraires utilisés comme itinéraire principal pour une destination particulière en définissant la préférence d’itinéraire associée à un saut suivant particulier. Les itinéraires dont la préférence est la plus faible sont toujours utilisés pour acheminer le trafic. Lorsque vous ne définissez pas de route préférée, Junos OS choisit de manière aléatoire l’une des adresses de saut suivant à installer dans la table de transfert.

En général, les propriétés par défaut affectées à une route statique s’appliquent à toutes les adresses de saut suivant configurées pour la route statique. Toutefois, si vous souhaitez configurer deux adresses de prochain saut possibles pour un itinéraire particulier et les traiter différemment, vous pouvez définir l’une d’entre elles comme un saut suivant qualifié.

Les sauts suivants qualifiés vous permettent d’associer une ou plusieurs propriétés à une adresse de saut suivant particulière. Vous pouvez définir une préférence globale pour un itinéraire statique particulier, puis spécifier une préférence différente pour le saut suivant qualifié. Par exemple, supposons que deux adresses de saut suivant (10.10.10.10 et 10.10.10.7) soient associées à la route statique 192.168.47.5/32. Une préférence générale est attribuée à l’ensemble de la route statique, puis une préférence différente est attribuée uniquement à l’adresse de saut suivant qualifiée 10.10.10.7. Par exemple:

Dans cet exemple, le saut suivant qualifié 10.10.10.7 se voit attribuer la préférence 6 et le saut suivant 10.10.10.10 se voit attribuer la préférence 5.

Note:

Les preference options et metric de la [edit route route qualified-next-hophiérarchie ] ne s’appliquent qu’aux sauts suivants qualifiés. La préférence de saut suivant et la mesure qualifiées remplacent la préférence de route et la mesure pour ce saut suivant qualifié spécifique, de la même manière que la préférence de route remplace la préférence et la mesure par défaut (pour cet itinéraire spécifique).

Note:

À partir de la version 15.1R4 de Junos OS, le routeur ne prend plus en charge une configuration dans laquelle une route statique pointe vers un saut suivant lié à un abonné. En règle générale, cela peut se produire lorsque RADIUS attribue le saut suivant avec l’attribut Framed-IP-Address. Une alternative à cette mauvaise configuration consiste à demander au serveur RADIUS de fournir un attribut Framed-Route qui correspond à l’itinéraire statique.

Exemple : Configuration des préférences de routage statique et des sauts suivants qualifiés pour contrôler la sélection de routage statique

Cet exemple montre comment contrôler la sélection de route statique.

Exigences

Dans cet exemple, aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise.

Aperçu

Dans cet exemple, la route statique 192.168.47.0/24 a deux sauts suivants possibles. Étant donné qu’une liaison a une bande passante plus élevée, cette liaison est le chemin préféré. Pour appliquer cette préférence, l’instruction qualified-next-hop est incluse dans la configuration sur les deux périphériques. Reportez-vous à la Figure 1.

Figure 1 : contrôle de la sélection Controlling Static Route Selection d’un itinéraire statique

Topologie

Configuration

Procédure

Configuration rapide de la CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.

Appareil B dans le réseau du fournisseur

Appareil D dans le réseau du client

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette procédure, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de l’interface de ligne de commande Junos OS.

Pour contrôler la sélection d’itinéraire statique :

  1. Sur l’appareil B, configurez les interfaces.

  2. Sur l’équipement B, configurez un itinéraire statique vers le réseau client.

  3. Sur l’équipement B, configurez un itinéraire de secours vers le réseau client.

  4. Sur l’appareil D, configurez les interfaces.

  5. Sur l’équipement D, configurez un itinéraire statique par défaut vers des réseaux externes.

  6. Sur l’équipement D, configurez une route statique de sauvegarde par défaut vers des réseaux externes.

Résultats

Confirmez votre configuration en exécutant les show interfaces commandes and show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Si vous avez terminé de configurer les périphériques, entrez commit à partir du mode de configuration sur les deux périphériques.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification des tables de routage

But

Assurez-vous que les routes statiques apparaissent dans les tables de routage de l’équipement B et de l’équipement D.

Action
Signification

Les astérisques (*) dans les tables de routage indiquent les itinéraires actifs. Les itinéraires de sauvegarde sont répertoriés ci-dessous.

Envoi d’un ping aux adresses distantes

But

Vérifiez que les routes statiques fonctionnent.

À partir de l’équipement B, envoyez une requête ping à l’une des adresses de l’interface de bouclage sur l’appareil D.

À partir de l’équipement D, envoyez une requête ping à l’une des adresses de l’interface de bouclage sur l’équipement B.

Action

S’assurer que la route de secours devient la route active

But

Si la route principale devient inutilisable, assurez-vous que la route secondaire de secours devient active.

Action
  1. Désactivez la route active en désactivant l’interface ge-1/2/0.0 sur l’appareil B.

  2. Vérifiez la table de routage de l’équipement B.

Signification

La route de secours est devenue la route active.

Conservation des adresses IP à l’aide de routes statiques

Les fournisseurs d’hébergement hébergent plusieurs serveurs pour plusieurs clients et souhaitent préserver l’utilisation de leur espace d’adressage IP. Traditionnellement, lorsqu’un client fournisseur d’hébergement ajoute de nouveaux serveurs, les serveurs se voient attribuer un petit bloc d’adresses IP, tel qu’un bloc /29, et les serveurs du client sont tous situés dans ce bloc d’adresses IP.

Le numéro, illustré

Par exemple, le client A peut avoir besoin de trois serveurs et se voit attribuer le bloc 10.3.3.0/29 (10.3.3.0 à 10.3.3.7). Dans ce scénario, plusieurs adresses IP sont consommées. Il s’agit notamment des adresses IP de réseau et de diffusion (10.3.3.0 et 10.3.3.7), des adresses de la passerelle de routeur à laquelle les serveurs sont connectés et des adresses des serveurs individuels. Pour allouer trois serveurs, huit adresses IP doivent être allouées. La division d’un seul réseau /24 en 32 réseaux /29 donne 96 adresses IP sur les 256, dans la mesure où /24 est consommée par les adresses réseau, de diffusion et de passerelle. Lorsque cet effet est multiplié sur des milliers de fournisseurs d’hébergement, l’espace d’adressage IP est loin d’être utilisé efficacement. La figure 2 illustre le problème.

Figure 2 : utilisation inefficace de l’espace d’adressage Inefficient Use of IP Address Space IP

Dans cette configuration, chaque client se voit attribuer un bloc d’espace d’adressage /29. Pour chaque bloc, les adresses réseau, de diffusion et de passerelle ne sont pas disponibles pour l’adressage IP du serveur, ce qui entraîne une utilisation inefficace de trois adresses IP. De plus, les blocs consomment des adresses IP inutilisées pour une expansion future.

Solution

Ce problème peut être résolu en configurant l’interface sur le routeur avec une adresse du préfixe IPv4 réservé pour l’espace d’adressage partagé (RFC 6598) et en utilisant des routes statiques pointées vers les interfaces. L’IANA a enregistré l’attribution d’un IPv4 /10 pour une utilisation en tant qu’espace d’adressage partagé. La plage d’adresses de l’espace d’adressage partagé est 100.64.0.0/10.

Une adresse IP est allouée à l’interface du routeur à partir de l’espace RFC 6598, de sorte qu’elle ne consomme pas d’espace d’adressage routable publiquement, et la connectivité est gérée avec des routes statiques sur une interface. L’interface du serveur est configurée avec une adresse de routage public, mais pas les interfaces du routeur. Les adresses réseau et de diffusion sont consommées dans l’espace RFC 6598 plutôt que dans l’espace d’adressage routable publiquement.

Cette fonctionnalité est prise en charge sur les commutateurs QFX10000 à partir de Junos OS 17.1R1.

La figure 3 illustre l’utilisation efficace de l’espace d’adressage IP.

Figure 3 : configuration à l’aide de l’espace d’adressage Configuration Using the Shared Address Space partagé

Dans cette configuration, chaque client se voit attribuer des adresses IP individuelles par serveur. Il existe une route statique qui peut être configurée en tant que route hôte. Une adresse IP est allouée à l’interface du routeur à partir de l’espace RFC 6598, de sorte qu’elle ne consomme pas d’espace d’adressage routable publiquement, et la connectivité est gérée avec des routes statiques vers une interface.

Configuration

La configuration ressemble à ceci pour le client A sur le routeur de passerelle :

Avec cette configuration, aucune adresse IP routable publiquement n’est gaspillée. Il convient de noter que lorsqu’un paquet est transféré dans cette configuration du routeur au serveur du serveur du client A 203.0.113.10, la route est transférée à l’interface ge-1/0/1.0 dont l’adresse IP est 100.64.0.1.

Les serveurs du client A sont configurés comme suit :

Cet exemple montre une seule route d’hôte par serveur, qui correspond à un mappage 1:1. Si cela est maintenu, cela pourrait équivaloir à un grand nombre de routes hôtes statiques. Pour des raisons de mise à l’échelle, nous devons prendre en charge les routes non-hôtes dans cet environnement. Par exemple, si un client C dans cette configuration comporte huit serveurs, il serait beaucoup plus efficace d’allouer une route /29 sur le routeur qui indique l’interface sur laquelle les huit serveurs sont connectés. Si le client C se voyait attribuer des adresses IP serveur de 203.0.114.8 à 203.0.114.15 et que celles-ci étaient connectées via l’interface ge-1/0/2.0, cela ressemblerait à ceci :

Comprendre le contrôle de route statique dans les tables de routage et de transfert

Vous pouvez contrôler l’importation de routes statiques dans les tables de routage et de transfert de plusieurs façons. Les méthodes principales incluent l’affectation d’un ou plusieurs des attributs suivants à l’itinéraire :

  • retain : conserve l’itinéraire dans la table de transfert après l’arrêt du processus de routage ou le redémarrage de l’équipement.

  • no-readvertise : empêche la réannonce de la route vers d’autres protocoles de routage.

  • passive : rejette le trafic destiné à l’itinéraire.

Cette rubrique comprend les sections suivantes :

Rétention de route

Par défaut, les routes statiques ne sont pas conservées dans la table de transfert lorsque le processus de routage s’arrête. Lorsque le processus de routage redémarre, toutes les routes configurées en tant que routes statiques doivent être ajoutées à nouveau à la table de transfert. Pour éviter cette latence, les routes peuvent être marquées comme étant conservées, de sorte qu’elles soient conservées dans la table de transfert même après l’arrêt du processus de routage. La rétention garantit que les routes se trouvent toujours dans la table de transfert, même immédiatement après le redémarrage du système.

Prévention de la nouvelle publicité

Par défaut, les routes statiques peuvent être réannoncées par d’autres protocoles de routage. Dans une zone de stub où vous ne souhaitez peut-être en aucun cas réannoncer ces routes statiques, vous pouvez marquer les routes statiques comme no-readvertise.

Rejet forcé du trafic de route passive

En règle générale, seules les routes actives sont incluses dans les tables de routage et de transfert. Si l'adresse de saut suivant d'une route statique est inaccessible, la route est marquée passive et n'est pas incluse dans les tables de routage ou de transfert. Pour forcer l’inclusion d’une route dans les tables de routage, quelle que soit l’accessibilité du prochain saut, vous pouvez marquer la route comme passive. Si un itinéraire est marqué comme passif et que son adresse de saut suivant est inaccessible, l’itinéraire est inclus dans la table de routage et tout le trafic destiné à l’itinéraire est rejeté.

Exemple : Empêcher la réannonce d’une route statique

Cet exemple montre comment empêcher une route statique d’être réannoncée dans OSPF, empêchant ainsi la route d’apparaître dans les tables de routage et de transfert.

Exigences

Dans cet exemple, aucune configuration spéciale au-delà de l’initialisation de l’appareil n’est requise.

Aperçu

Cet exemple montre comment configurer une stratégie de routage qui relance les routes statiques dans OSPF, à l’exception d’une route statique qui n’est pas réannoncée car elle est balisée avec l’instruction no-readvertise .

Topologie

La figure 4 illustre l’exemple de réseau.

Figure 4 : Itinéraires clients connectés à un fournisseur de services Customer Routes Connected to a Service Provider

Configuration

Procédure

Configuration rapide de la CLI

Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande au niveau de la [edit] hiérarchie.

Appareil A

Dispositif B

Dispositif C

Procédure étape par étape

L’exemple suivant vous oblige à naviguer à différents niveaux dans la hiérarchie de configuration. Pour obtenir des instructions sur cette procédure, reportez-vous à la section Utilisation de l’éditeur CLI en mode configuration dans le Guide de l’utilisateur de l’interface de ligne de commande Junos OS.

Pour configurer l’appareil A :

  1. Configurez l’interface avec l’appareil B.

  2. Configurez OSPF pour former une relation d’homologue OSPF avec l’équipement B.

Procédure étape par étape

Pour configurer l’équipement B :

  1. Configurez les interfaces vers l’appareil A et l’appareil C.

  2. Configurez une ou plusieurs routes statiques ainsi que le numéro du système autonome (AS).

  3. Configurez la stratégie de routage.

    Cette stratégie exporte les routes statiques de la table de routage vers OSPF.

  4. Incluez l’instruction no-readvertise pour empêcher l’exportation de la route 192.168.0.0/24 vers OSPF.

  5. Configurez les protocoles de routage.

    La configuration BGP forme une relation d’homologue BGP externe (EBGP) avec l’appareil C.

    La configuration OSPF forme une relation d’homologue OSPF avec l’équipement A et applique la stratégie de routage statique d’envoi .

Procédure étape par étape

Pour configurer l’équipement C :

  1. Créez l’interface sur l’appareil B et configurez l’interface de bouclage.

  2. Configurez la session d’appairage EBGP avec l’équipement B.

  3. Configurez le numéro AS.

Résultats

Confirmez votre configuration en exécutant les show interfacescommandes , show policy-options, show protocolset show routing-options . Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Appareil A

Dispositif B

Dispositif C

Si vous avez terminé de configurer les périphériques, entrez commit à partir du mode de configuration.

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de la table de routage

But

Assurez-vous que l’instruction no-readvertise fonctionne.

Action
  1. Sur l’équipement A, exécutez la show route protocol ospf commande pour vous assurer que l’itinéraire 192.168.0.0/24 n’apparaît pas dans la table de routage de l’équipement A.

  2. Sur l’appareil B, désactivez l’instruction no-readvertise .

  3. Sur l’équipement A, réexécutez la show route protocol ospf commande pour vous assurer que l’itinéraire 192.168.0.0/24 apparaît dans la table de routage de l’équipement A.

Signification

L’instruction no-readvertise fonctionne comme prévu.

Vérification de la configuration de la route statique

But

Vérifiez que les routes statiques se trouvent dans la table de routage et qu’elles sont actives.

Action

Dans l’interface de ligne de commande, entrez la show route terse commande.

Sortie de l’échantillon

nom_commande

Signification

La sortie affiche la liste des routes qui se trouvent actuellement dans la table de routage inet.0 . Vérifiez les informations suivantes :

  • Chaque route statique configurée est présente. Les routes sont répertoriées par ordre croissant par adresse IP. Les routes statiques sont identifiées par un S dans la colonne de protocole (P) de la sortie.

  • Chaque route statique est active. Les routes actives affichent l’adresse IP du prochain saut dans la colonne Saut suivant . Si l'adresse de saut suivant d'un itinéraire est inaccessible, l'adresse de saut suivant est identifiée comme Rejeter. Ces routes ne sont pas des routes actives, mais elles apparaissent dans la table de routage car l’attribut passif est défini.

  • La préférence pour chaque route statique est correcte. La préférence pour un itinéraire particulier est répertoriée dans la colonne Prf de la sortie.

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érer
Description
17.1R1
Cette fonctionnalité est prise en charge sur les commutateurs QFX10000 à partir de Junos OS 17.1R1.