Fonction OSPF Demand Circuit
Contenu
Introduction
Des options de circuit de demande ont été introduites pour OSPF (Open Shortest Path First) dans le logiciel Cisco IOS® version 11.2 en réponse à la RFC 1793 
OSPF. Le protocole OSPF envoie des paquets HELLO toutes les 10 secondes et actualise ses LSA toutes les 30 minutes. Ces fonctions maintiennent les relations de voisinage et garantissent que les bases de données d’état des liaisons sont précises et utilisent une bande passante beaucoup moins importante que les fonctions similaires dans les protocoles RIP (Routing Information Protocol) et IGRP (Interior Gateway Routing Protocol). Cependant, même cette quantité de trafic est indésirable sur les circuits à la demande. L'utilisation des options de circuit de demande OSPF supprime les fonctions d'actualisation des paquets Hello et LSA. Le protocole OSPF peut établir une liaison de demande pour former une contiguïté et effectuer la synchronisation initiale de la base de données. La contiguïté reste active même après la défaillance de la couche 2 du circuit de demande.
La version 12.1(2)T de Cisco IOS introduit la fonctionnalité de réduction de l'inondation pour OSPF. Cette fonctionnalité est destinée à minimiser le trafic créé par une actualisation périodique des LSA dans les domaines OSPF avec un grand nombre de LSA. Contrairement à la fonction de circuit de demande OSPF, la réduction de la propagation est généralement configurée sur les lignes louées. La réduction des inondations utilise la même technique que les circuits de demande pour supprimer l’actualisation périodique des LSA. Cette fonctionnalité est soumise pour standardisation au groupe de travail OSPF IETF.
Conditions préalables
Conditions requises
Les lecteurs de ce document devraient avoir connaissance des sujets suivants :
-
OSPF
-
IGRP
-
RIP
Components Used
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
-
Cisco IOS version 12.1(2)T et ultérieure
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
En quoi le circuit OSPF sur demande diffère-t-il d’un circuit normal ?
Il existe deux caractéristiques principales du circuit OSPF sur demande qui le différencient d’un circuit normal.
-
Hellos périodiques supprimés
-
Actualisation LSA périodique supprimée
Hellos périodiques supprimés
Lorsqu’un circuit de demande OSPF est configuré sur une liaison, les HELLO OSPF périodiques sont supprimés. Les HELLO périodiques sont supprimés uniquement sur un type de réseau point à point et point à multipoint. Sur tout autre type de réseau, les HELLO OSPF sont toujours envoyés via l’interface.
Actualisation LSA périodique supprimée
Les actualisations LSA périodiques qui ont lieu toutes les 30 minutes ne se produisent pas avec le circuit de demande OSPF. Lorsqu’une liaison de circuit de demande est établie, un bit d’option unique (le bit DC) est échangé entre les routeurs voisins. Si deux routeurs négocient le bit DC avec succès, ils en prennent note et définissent un bit spécifique dans l’âge LSA appelé bit DoNotAge (DNA). Le bit d'ADN est le bit le plus significatif dans le champ LS Age. En définissant ce bit, la LSA cesse de vieillir et aucune mise à jour périodique n’est envoyée.
Quand une actualisation LSA périodique est-elle envoyée sur un circuit de demande OSPF ?
Il n'existe que deux scénarios dans lesquels l'actualisation LSA périodique se produit lors de l'utilisation de la fonctionnalité de circuit de demande OSPF :
-
Si la topologie du réseau change
-
S’il y a un routeur dans le domaine OSPF qui ne peut pas comprendre les circuits de demande
Tout d’abord, il n’est pas possible d’arrêter l’actualisation de la LSA car le routeur doit envoyer les nouvelles informations de la LSA pour mettre à jour le voisin au sujet de la modification de topologie.
Cependant, il existe un moyen spécial de gérer le deuxième scénario. Le routeur ABR (Area Border Router), qui est le routeur D dans le schéma de réseau ci-dessous, sait que le routeur C est incapable de comprendre les LSA ADN car il voit que le bit DC est clair dans le champ d’option de la LSA provenant du routeur C. Dans ce cas, le routeur ABR, le routeur D, avertit les routeurs capables de circuit de demande de ne pas lancer la LSA avec le bit DNA défini parce qu’il n’est pas comprendre le bit d'ADN.
Ce diagramme de réseau montre un scénario où l'actualisation LSA périodique est envoyée sur un circuit de demande :
LSA d'indication
L’ABR, le routeur D, émet une LSA d’indication dans le backbone indiquant à tous les routeurs du backbone de ne pas émettre de LSA d’ADN. Lorsque le routeur A (un autre ABR) voit cette indication LSA, il génère l’indication LSA dans d’autres zones, à l’exclusion du backbone et de toute zone de stub ou de non-so-stubby (NSSA). Cette indication LSA pour le routeur D est présentée ci-dessous. La LSA d’indication est une LSA récapitulative de type 4 dans laquelle l’ID d’état des liaisons est l’ABR lui-même au lieu du routeur ASBR (Autonomsystem Border Router). En d’autres termes, l’ID d’état des liaisons et le champ du routeur publicitaire sont identiques, comme indiqué ici :
RouterD# show ip ospf database asbr-summary
Adv Router is not-reachable
LS age: 971
Options: (No TOS-capability, No DC)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 141.108.1.129 (AS Boundary Router address)
Advertising Router: 141.108.1.129
LS Seq Number: 80000004
Checksum: 0xA287
Length: 28
Network Mask: /0
TOS: 0 Metric: 16777215
La métrique d'une LSA d'indication est définie à l'infini. L’ID d’état des liaisons et le champ du routeur d’annonce sont toujours l’ID de routeur de l’ABR à l’origine de l’indication LSA. Dans le schéma de réseau ci-dessus, la liaison entre les routeurs A et B est configurée comme circuit de demande, mais comme il existe un routeur dans la zone 1 qui est incapable de comprendre la LSA DNA, il n’y aura aucune LSA DNA provenant de la zone 1. En conséquence, les actualisations LSA périodiques, originaires de la zone 1, sont envoyées sur le circuit de demande.
Il n’y a que deux conditions qui font qu’un ABR OSPF génère une LSA d’indication :
-
Il existe un routeur dans le réseau exécutant IOS 11.2 ou version antérieure.
-
Il existe un routeur non Cisco dans le réseau qui ne prend pas en charge le circuit de demande.
Solution
Configurez la zone 2 en tant que stub ou zone NSSA. Cela empêche l’indication LSA émise par le routeur D d’être envoyée dans la zone 2 par le routeur A, car la zone 2 est une zone stub et l’indication LSA, qui est une LSA récapitulative de type 4, ne peut pas être diffusée dans la zone stub. Maintenant, puisque la zone 2 ne voit aucune LSA d’indication, elle continue à générer les LSA d’ADN dans la zone 2 et la liaison entre les routeurs A et B n’apparaît pas car l’actualisation LSA périodique est supprimée.
Cisco vous recommande de configurer le circuit de demande OSPF dans les zones autres que les zones de backbone et de faire de ces zones NSSA, stub ou totalement stubby (cette dernière option est préférable). Il s'agit de minimiser les informations injectées à partir d'autres zones dans la zone contenant des circuits de demande. Ainsi, vous réduisez la portée des modifications, ce qui peut augmenter le circuit de demande OSPF. Référez-vous à Pourquoi le circuit de demande OSPF continue à activer la liaison pour des scénarios de dépannage impliquant la fonctionnalité de circuit de demande OSPF.
Si vous avez une situation similaire à celle décrite ci-dessus et que le circuit de demande fait également partie du backbone, vous ne pouvez pas utiliser cette solution car la zone de backbone ne peut pas être configurée en tant que stub ou NSSA.
Tâche de configuration
L'exemple de la tâche de configuration de cette section montre la configuration nécessaire pour créer un circuit de demande. Un seul côté est requis pour avoir la commande de circuit de demande sous l'interface car si l'autre côté est capable de comprendre le circuit de demande, il négocie automatiquement cette fonctionnalité dans le paquet Hello. S'il n'est pas capable de comprendre le circuit de demande, il ignore cette option.
RouterA# show run interface Serial0 interface Serial 0 encapsulation frame-relay ip address 141.108.1.1 255.255.255.0 ip ospf network-type point-to-mutipoint ip ospf demand-circuit !
Remarque : Vous pouvez utiliser un circuit de demande sur n'importe quel type de réseau, bien que ce soit uniquement sur les types de réseau point à point ou point à multipoint qui sont supprimés.
En quoi la fonction de réduction des inondations diffère-t-elle de la fonction de circuit de demande ?
La fonctionnalité de réduction de l’inondation OSPF est une légère modification des circuits de demande conçus pour réduire le trafic supplémentaire sur les liaisons résultant d’une actualisation LSA périodique. Il utilise le même mécanisme pour éliminer la nécessité d'actualiser les LSA périodiques. Généralement, les routeurs ne sont pas immédiatement connectés à la liaison et ne peuvent pas identifier si elle est configurée comme circuit de demande ou liaison de réduction de l’inondation. La représentation de base de données des deux types de liaison est identique.
La principale différence entre les circuits de réduction de l'inondation et les circuits de demande est que le premier supprime uniquement les mises à jour LSA périodiques ; il ne supprime pas les paquets hello périodiques. Par conséquent, la fonction de réduction de l’inondation n’empêche pas la détection d’un routeur voisin en panne.
Les liaisons de réduction des inondations ont les mêmes contraintes que les circuits de demande. En particulier, tous les routeurs de la zone doivent prendre en charge la fonctionnalité de circuit de demande afin de réduire la propagation. Les techniques de dépannage des circuits de demande et des liaisons de réduction de l'inondation sont également courantes.
Cet exemple montre une configuration de fonction de réduction de l'inondation OSPF :
interface POS 0/0 ip address 192.168.122.1 255.255.255.0 ip ospf flood-reduction
Comme ci-dessus, l’interface POS 0/0 du routeur est configurée pour la réduction de l’inondation OSPF. Aucune actualisation LSA périodique n’est envoyée sur la liaison, mais des paquets Hello sont envoyés.
Commentaires