IP : Routage à établissement de connexion à la demande (DDR)

Conception de réseaux de stub à grande échelle avec ODR

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Le Routage à établissement de connexion à la demande (DDR) est une amélioration au Protocole CDP (Cisco Discovery Protocol), un protocole utilisé pour découvrir d'autres périphériques de Cisco sur des medias d'émission ou de non-émission. Avec l'aide du CDP, il est possible de trouver le type de périphérique, l'adresse IP, l'exécution de version de Ý de Cisco IOS sur le périphérique voisin de Cisco, les capacités du périphérique voisin, et ainsi de suite. Dans le Logiciel Cisco IOS version 11.2, ODR a été ajouté au CDP pour annoncer le préfixe IP connecté d'un routeur d'extrémité par l'intermédiaire du CDP. Cette caractéristique prend les cinq octets supplémentaires pour chaque réseau ou sous-réseau, quatre octets pour l'adresse IP, et un octet pour annoncer le masque de sous-réseau avec l'IP. ODR peut diffuser les informations de longueur variable du masque de sous-réseau (VLSM).

ODR a été conçu pour les clients au détail d'entreprise qui ne veulent pas utiliser leur bande passante de réseau pour des mises à jour de protocole de routage. Dans un environnement de X.25, par exemple, il est souvent très coûteux pour exécuter un protocole de routage au-dessus de ce lien. Le routage statique est un bon choix, mais il y a trop de temps système pour mettre à jour manuellement les artères statiques. ODR n'est pas CPU-intensif et il est utilisé pour propager des artères IP dynamiquement au-dessus de la couche 2.

ODR n'est pas un protocole de routage et ne devrait pas être traité en tant que tels en le configurant. Les configurations traditionnelles pour différents protocoles de Routage IP ne fonctionneront pas dans ODR, comme ODR utilise le CDP sur la couche 2. Pour configurer ODR, utilisez la commande de router odr sur le routeur concentrateur. La conception, l'implémentation, et l'interaction d'ODR avec d'autres protocoles de Routage IP peuvent être difficiles.

ODR ne fonctionnera pas sur des Routeurs de gamme Cisco 700 ou au-dessus des liens atmosphère excepté l'Émulation LAN (LANE).

Réseaux de stub contre des réseaux de transit

Quand aucune informations ne traverse le réseau, c'est un réseau de stub. Le topologie de réseau hub-and-spoke est un bon exemple d'un réseau de stub. Les grands organismes avec beaucoup de sites connectés à un centre de traitement des données utilisent ce type de topologie.

Des routeurs bas de gamme tels que le Cisco 2500, 1600, et les Routeurs de gamme 1000 sont utilisés du côté de l'étoile. Si les informations traversent des routeurs en étoile pour obtenir à un autre réseau, ce routeur d'extrémité devient un routeur de transit. Cette configuration se produit quand un rai est connecté à un autre routeur sans compter que le routeur concentrateur.

Un souci commun est combien grand d'une mise à jour ODR un rai peut envoyer. Normalement, des rais sont connectés seulement à un hub. Si des rais sont connectés à d'autres Routeurs, ils ne sont plus des stubs et deviennent un transit network. Les cases bas de gamme ont habituellement un ou deux interfaces de RÉSEAU LOCAL. Par exemple, le Cisco 2500 peut prendre en charge deux interfaces de RÉSEAU LOCAL. Dans des situations normales, un paquet 10-byte est envoyé (au cas où il y aurait deux réseaux locaux du côté de l'étoile) comme partie de CDP. Le CDP est activé par défaut, tellement là n'est aucune question de temps système supplémentaire. Il n'y aura jamais une situation où il y a une grande mise à jour ODR. La taille des mises à jour ODR ne sera pas un problème dans un environnement de réseau hub-and-spoke vrai.

Réseau hub-and-spoke et ODR

Un réseau hub-and-spoke est un réseau ordinaire où un hub (routeur haut de gamme) sert beaucoup de rais (routeurs bas de gamme). Dans des cas particuliers, là peut être plus d'un hub, pour des raisons de redondance ou prendre en charge les rais supplémentaires par l'intermédiaire d'un hub distinct. Dans cette situation, enable ODR sur les deux Concentrateurs. Il est également nécessaire d'avoir un protocole de routage pour permuter les informations de routage ODR entre les deux Concentrateurs.

Figure 1 : Topologie de réseau hub-and-spoke

odrhs.jpg

Rais avec un seul point de sortie

Dans la figure 1 ci-dessus, les rais sont connectés à un pivot de sorte qu'ils puissent se fonder sur la passerelle par défaut au lieu de recevoir toutes les informations de routage pour le pivot avec un point de sortie. Il n'est pas nécessaire de passer toutes les informations aux rais, puisqu'un rai ne devra pas prendre une décision intelligente de routage. Un rai enverra toujours le trafic au hub, ainsi les rais ont besoin seulement d'un default route étant dirigé vers un hub.

Il doit y a une manière pour que l'information de sous-réseau du rai soit envoyée au hub. Avant le Cisco IOS 11.2, la seule manière de réaliser ceci était d'activer un protocole de routage au rai. Utilisant ODR, cependant, des protocoles de routage n'ont pas besoin d'être activés du côté de l'étoile. Avec ODR, seulement le Cisco IOS 11.2 et une route statique par défaut étant dirigée vers un hub sont nécessaires sur le rai.

Rais avec des plusieurs points de sortie

Un rai peut avoir de plusieurs connexions au hub pour des buts de Redondance ou de sauvegarde au cas où la liaison principale échouerait. Un hub distinct est souvent exigé pour cette Redondance. Dans cette situation, les rais ont des plusieurs points de sortie. ODR fonctionne bien également dans ce réseau.

Les rais doivent être point par point, autrement la route statique par défaut flottante ne fonctionnera pas. Dans une configuration multipoint, il n'y a aucune manière de détecter une panne du prochain saut, juste comme dans des supports de diffusion.

Équilibrage de charge ou sauvegarde avec un hub simple

Pour réaliser l'Équilibrage de charge, définissez deux routes statiques par défaut sur des rais avec la même distance et le rai fera l'Équilibrage de charge entre ces deux chemins. S'il y a deux chemins à la destination, ODR maintiendra les deux artères dans la table de routage et fera l'Équilibrage de charge sur le hub.

Pour des sauvegardes, définissez deux routes statiques par défaut avec une distance d'une meilleure que l'autre. Le rai utilisera la liaison principale et, quand la liaison principale descend, la Route statique flottante fonctionnera. Dans le routeur concentrateur, utilisez la commande de distance pour chaque adresse du voisin de CDP et rendez une distance meilleure que l'autre. Avec cette configuration, les artères ODR apprises par un lien seront préférées au-dessus de l'autre. Cette configuration est utile dans un environnement où il y a les liaisons principales rapides et ralentit des liaisons de sauvegarde (de faible bande passante) et où l'Équilibrage de charge n'est pas désiré.

Remarque: Aujourd'hui, il n'y a aucune autre méthode du côté de l'étoile pour préférer un lien au-dessus de l'autre dans une situation simple de hub, excepté comme décrit ci-dessus. Si vous utilisez IOS 12.0.5T ou plus tard, le hub envoie automatiquement le default route par l'intermédiaire des deux liens et le rai ne peut pas distinguer les deux chemins et installera chacun des deux dans sa table de routage. La seule manière de préférer un default route au-dessus de l'autre est d'utiliser une route statique par défaut sur le rai qui a un chemin avec une distance inférieure d'admin pour laquelle vous voulez préférer. Ceci ignore automatiquement les default route qui sont livré sur les rais par l'intermédiaire d'ODR. Actuellement, l'idée de fournir le rai une molette, où elle peut préférer un lien au-dessus de l'autre, est à l'étude.

Figure 2 : Rais avec des plusieurs points de sortie et un hub simple

/image/gif/paws/13710/odr3.jpg

Équilibrage de charge ou sauvegarde avec des plusieurs concentrateurs

Ces configurations peuvent également être utilisées pour l'Équilibrage de charge ou les sauvegardes quand il y a des plusieurs concentrateurs. Tous les Concentrateurs doivent être entièrement engrenés de sorte que si un des liens des rais échoue, la destination puisse encore être accédée par un deuxième hub. Voyez l'ODR contre. L'autre section de protocoles de routage de ce document pour une explication plus détaillée. De même, dans le cas des plusieurs concentrateurs, si IOS est 12.0.5T ou plus tard dans utilisé, les Concentrateurs envoient les default route ODR aux rais et les rais installent chacun des deux dans la table de routage. Une future amélioration permettra a parlé pour préférer un hub au-dessus de l'autre. Actuellement, ceci peut être fait par une route statique par défaut définie sur le routeur et l'utilisation du rai de la distance d'admin dans la commande statique d'artère de préférer un hub au-dessus de l'autre. Ceci n'affecte pas des situations d'Équilibrage de charge.

Figure 3 : Rais avec des plusieurs points de sortie et des plusieurs concentrateurs

/image/gif/paws/13710/odr4.jpg

ODR contre. D'autres protocoles de routage

Le plus grand avantage d'ODR par rapport au Routage IP est que le routeur concentrateur apprendra des préfixes IP sans activer des protocoles de routage relatif à la couche 3. Les mises à jour ODR font partie de CDP sur la couche 2.

ODR contre l'EIGRP

Dans un environnement de réseau hub-and-spoke vrai, il est inutile de passer toutes les informations de routage à tous les rais. les rais de Lent-lien gaspillent la bande passante dans des mises à jour de routage et des relations voisines de mise à jour. En activant le Protocole EIGPR (Enhanced Interior Gateway Routing Protocol) sur les rais, conduisant des mises à jour sont envoyés aux rais. Dans de grands réseaux, ces mises à jour deviennent bande passante énorme et de rebut CPU, et peuvent exiger plus de mémoire sur des routeurs en étoile.

Une meilleure approche avec l'EIGRP est d'appliquer des filtres au hub. Les informations de routage sont commandées de sorte que les Concentrateurs envoient seulement un default route dynamiquement aux rais. Ces filtres aident à réduire la taille de la table de routage du côté de l'étoile, mais si le hub perd un voisin, il enverra des requêtes à tous les autres voisins. Ces requêtes sont inutiles parce que le hub n'obtiendra jamais une réponse d'un voisin.

La meilleure approche est d'éliminer le temps système des requêtes EIGRP et de la maintenance voisine utilisant ODR. En ajustant les temporisateurs ODR, le temps de convergence peut être augmenté.

Aujourd'hui, nous avons une nouvelle caractéristique dans l'EIGRP qui mesure l'EIGRP bien mieux dans une situation de hub and spoke. Référez-vous à la Stub Routing d'Enhanced IGRP pour plus d'informations sur la caractéristique d'eigrp stub.

ODR contre l'OSPF

Le Protocole OSPF (Open Shortest Path First) offre plusieurs options pour des environnement de réseau hub-and-spoke, et l'option de NO--résumé de stub a le moins temps système.

Vous pouvez rencontrer des problèmes en exécutant l'OSPF sur les réseau hub-and-spoke de grande puissance. Les exemples dans cette section utilisent le Relais de trames parce que c'est le topologie de réseau hub-and-spoke le plus commun.

Réseaux de stub de Point à point OSPF

Dans cet exemple, l'OSPF est activé sur 100 rais reliés par une configuration point par point. D'abord, il y a beaucoup d'adresses IP gaspillées, même si nous sous-réseau avec un masque de réseau de /30. En second lieu, si nous incluons ces 100 rais dans une zone et un rai est agité, le premier (SPF) algorithme de plus court chemin fonctionnera et peut devenir CPU-intensif. Cela situation vaut particulièrement pour des routeurs en étoile si le lien s'agite constamment. Des instabilités plus voisines peuvent poser des problèmes en ce qui concerne des routeurs en étoile.

Dans l'OSPF, la zone est stub et pas l'interface. S'il y a 100 Routeurs dans un réseau de stub, plus de mémoire est nécessaire sur les rais pour tenir la grande base de données. Ce problème peut être résolu en divisant une grande zone d'extrémité en petites zones. Cependant, une instabilité dans une zone d'extrémité déclenchera toujours la SPF pour fonctionner sur les rais, ainsi ce temps système ne peut pas être traité en faisant une petite zone d'extrémité sans le résumé et aucun externals.

Une autre option est d'inclure chaque lien dans une zone. Avec cette option, le routeur concentrateur devra exécuter un algorithme SPF distinct pour chaque zone et créer un récapitulation d'annonce d'état des liaisons (LSA) (LSA) pour des artères dans la zone. Cette option peut blesser la représentation du routeur concentrateur.

L'évolution à une meilleure plate-forme n'est pas une solution permanente ; cependant, ODR fournit une solution. Des artères apprises par l'intermédiaire d'ODR peuvent être redistribuées dans l'OSPF pour informer d'autres routeurs concentrateur au sujet de ces artères.

Réseaux de stub point-à-multipoint OSPF

Dans les réseaux point-à-multipoint, l'espace d'adresse IP est enregistré en mettant chaque rai sur le même sous-réseau. En outre, la taille du hub de LSA du routeur qui est généré sera divisée en deux puisqu'elle génèrera seulement un lien de stub pour tous les liens point par point. Un réseau point-à-multipoint forcera le sous-réseau entier à inclure dans une zone. En cas d'instabilité de lien, le rai exécutera la SPF, qui peut être CPU-intensive.

Bonjour la tempête

Les paquets HELLO OSPF sont petits, mais s'il y a trop de voisins, leur taille peut devenir grande. Puisque les hellos sont multidiffusé, le routeur traite les paquets. Le hub OSPF envoie et reçoit bonjour des paquets consistés en 20 octets d'en-tête IP, 24 octets d'en-tête OSPF, 20 octets de paramètres Hello, et 4 octets pour chaque voisin vu. Un paquet HELLO OSPF d'un hub dans un réseau point-à-multipoint avec 100 voisins peut devenir de 464 octets de long et sera inondé à tous les rais toutes les 30 secondes.

Tableau 1 : Paquet HELLO OSPF pour 100 voisins

20 en-têtes IP d'octets
24 en-têtes OSPF d'octets
20 paramètres Hello d'octets
4 octets chaque ID de routeur voisin (DÉBARRASSÉ)
….
….
….
….
….

Le temps système est résolu dans ODR parce qu'aucune informations supplémentaires n'est envoyée du hub aux rais. Les rais envoient le préfixe IP de 5 octets par sous-réseau au routeur concentrateur. Vu la taille bonjour du paquet, comparez les 5 octets dans ODR (le rai envoyant les informations d'un sous-réseau connecté) aux 68 octets d'OSPF (la plus petite longueur de paquet de bonjour comprenant une en-tête IP envoyée du a parlé au hub) plus 68 octets (le plus petit paquet de bonjour envoyé du hub au rai) pendant un intervalle 30-second. En outre, les hellos OSPF se produisent sur la couche 3 tandis que les mises à jour ODR se produisent sur la couche 2. Avec ODR, loin moins d'informations sont envoyées, ainsi la bande passante de lien peut être utilisée pour d'importantes données.

ODR contre RIPv2

La version 2 (RIPv2) de Protocole d'Information de Routage est également un bon choix pour des environnement de réseau hub-and-spoke. Pour concevoir RIPv2, envoyez le default route du hub aux rais. Les rais annoncent alors leur interface connectée par l'intermédiaire du RIP. RIPv2 peut être utilisé quand il y a des adresses secondaires sur les rais qui doivent être annoncés ou si plusieurs Routeurs de constructeur sont utilisés ou si la situation n'est pas vraiment un hub and spoke.

RIPv2 au-dessus de circuit de demande

La version 2 a quelques modifications, mais elle ne change pas le protocole rigoureusement. Cette section discute quelques améliorations POUR DÉCHIRER pour des circuits de demande.

Les interréseaux d'aujourd'hui se déplacent en direction des réseaux commutés ou des sauvegardes des sites primaires pour fournir des connexions à un grand nombre de sites distants. De tels types de connexions peuvent passer à l'un ou l'autre très peu ou pas de trafic de données pendant le fonctionnement normal.

Le comportement de RIP périodique pose des problèmes sur ces circuits. Le RIP a des problèmes avec la faible bande passante, les interfaces point par point. Des mises à jour sont envoyées toutes les 30 secondes avec les grandes tables de routage qui utilisent la bande passante élevée. Dans cette situation, il est le meilleur d'utiliser le Protocole RIP déclenché.

Protocole RIP déclenché

Le Protocole RIP déclenché est conçu pour les Routeurs qui permutent toutes les informations de routage avec leur voisin. Si les changements du routage interviennent, seulement les modifications sont propagées au voisin. Le routeur récepteur applique les modifications immédiatement.

Des mises à jour de Protocole RIP déclenché sont envoyées seulement quand :

  • Une demande d'une mise à jour de routage est reçue.

  • Les nouvelles informations sont reçues.

  • La destination a changé du circuit vers le bas pour faire le tour.

  • Le routeur est d'abord activé.

Être suit un exemple de configuration pour le Protocole RIP déclenché :

Spoke# configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
Spoke(config)# int s0.1 
Spoke(config-if)# ip rip triggered 
Spoke(config)# int s0.2 
Spoke(config-if)# ip rip triggered 
       
interface serial 0 
encapsulation frame-relay 
       
interface serial 0.1 point            /* Primary PVC */ 
ip address 10.x.x.x 255.255.255.0 
ip rip triggered 
frame-relay interface-dlci XX 
       
interface serial 0.2 point       /* Secondary PVC */ 
ip address 10.y.y.y 255.255.255.0 
ip rip triggered 
frame-relay interface-dlci XX 

router rip 
  network 10.0.0.0 
       

Spoke# show ip protocol 
Routing Protocol is "rip" 
  Sending updates every 30 seconds, next due in 23 seconds 
  Invalid after 180 seconds, hold down 180, flushed after 240 
  Outgoing update filter list for all interfaces is not set 
  Incoming update filter list for all interfaces is not set 
  Redistributing: rip 
  Default version control: send version 1, receive any version 
    Interface        Send  Recv    Triggered RIP    Key-chain 
    Ethernet0           1        1 2 
    Serial0.1             1        1 2               Yes 
    Serial0.2             1        1 2               Yes 
  Routing for Networks: 
    10.0.0.0 
  Routing Information Sources: 
    Gateway         Distance      Last Update 
  Distance: (default is 120) 

La commande d'ip rip triggered doit être configurée sur l'interface de connexion du routeur concentrateur aux rais.

En comparant RIPv2 à ODR, ODR est un meilleur choix parce que RIPv2 travaille à la couche 3 et ODR se produit sur la couche 2. Quand le hub envoie les mises à jour RIPv2 à plus de 1000 rais, il doit répliquer le paquet sur la couche 3 pour chaque rai. ODR envoie à rien du hub excepté la mise à jour habituelle de CDP chaque minute sur la couche 2, qui n'est pas CPU intensive du tout. L'envoi de l'information de sous-réseau connectée dans la couche 2 du rai est loin moins de CPU intensive qu'envoyant RIPv2 sur la couche 3.

Conception de réseau à grande échelle avec ODR

ODR fonctionne mieux dans un réseau à grande échelle que n'importe quel autre protocole de routage. Le plus grand avantage d'ODR est que des protocoles de routage ne doivent pas être activés sur les liaisons série connectées. Actuellement, il n'y a aucun protocole de routage capable envoyer les informations de routage sans les activer sur l'interface connectée.

ODR avec l'exécution EIGRP sur des Concentrateurs

En exécutant l'EIGRP, établissez un rapport passif d'interface au réseau hub-and-spoke de sorte qu'il n'envoie pas les paquets HELLO EIGRP inutiles sur le lien. Si possible, il vaut mieux de ne pas mettre des déclarations de réseau pour des réseaux entre le hub and spoke parce que, si le lien descend, l'EIGRP n'enverra pas des requêtes inutiles aux principaux voisins. Choisissez toujours un réseau factice entre le hub and spoke ainsi ces liens ne seront pas inclus dans le domaine EIGRP parce que vous ne mettrez pas des déclarations de réseau dans les configurations.

Redondance et récapitulation

Dans une situation simple de hub, aucun paramétrage supplémentaire n'est exigé. Récapitulez la particularité, des sous-réseaux connectés des rais et coulez-les dans le noyau. Les temps système des requêtes, cependant, seront toujours là. Si des artères spécifiques sont perdues d'un des rais, envoyez les requêtes à tous les Routeurs de voisins au centre.

Dans le cas des plusieurs concentrateurs, il est très important que les deux Concentrateurs soient connectés et que l'EIGRP s'exécute entre les Concentrateurs. Si possible, ce lien devrait être un seul réseau principal de sorte qu'il ne gêne pas d'autres liens allant aux rais. Cette configuration est nécessaire parce que l'EIGRP ne peut pas être activé sur une interface spécifique, ainsi même si nous faisons le passif d'interface, il sera encore annoncé par l'intermédiaire de l'EIGRP. Si l'interface est récapitulée, des requêtes seront encore envoyées si un rai est perdu. Tant que le lien entre les deux Concentrateurs n'est pas en même réseau principal que les rais, la configuration devrait fonctionner correctement.

Figure 4 : Redondance et récapitulation : Le noyau reçoit des récapitulatifs de routage

/image/gif/paws/13710/odr7.jpg

Un avantage d'EIGRP est qu'il peut récapituler au niveau d'interface, ainsi le récapitulatif de routage des sous-réseaux en étoile sera envoyé dans le noyau et il enverra plus d'artère spécifique à l'autre hub. Si le lien entre un hub and spoke descend, il est possible d'atteindre la destination par l'intermédiaire du deuxième hub.

ODR avec l'exécution OSPF sur des Concentrateurs

Dans ce scénario, l'OSPF ne doit pas être activé sur le lien connectant les rais. Dans un scénario normal, si l'OSPF est activé sur le lien, et un lien spécifique s'agite constamment, il peut poser plusieurs problèmes, y compris l'exécution SPF, régénération de LSA du routeur, régénération de LSA récapitulatif, et ainsi de suite. En exécutant ODR, n'incluez pas la liaison série connectée dans le domaine OSPF. La question principale est de recevoir les informations de segment de RÉSEAU LOCAL des rais. Ces informations peuvent être obtenues par ODR. Si un lien s'agite constamment, il ne gênera pas le protocole de routage dans le routeur concentrateur.

Redondance et récapitulation

Tous les liens spécifiques peuvent être récapitulés avant la fuite dans le noyau pour éviter le calcul d'artère si une des interfaces connectées d'un rai descend. Il ne peut pas être détecté si les principales informations de routeur sont récapitulées.

Figure 5 : Redondance et récapitulation : Le principal routeur reçoit des récapitulatifs de routage

/image/gif/paws/13710/odr6.jpg

Dans cet exemple, il est très important que les Concentrateurs soient connectés entre eux pour des raisons de redondance. Cette connexion récapitulera également les sous-réseaux rai-connectés avant la fuite dans le noyau OSPF.

NSSA avec la future amélioration

Il y aura par la suite une caractéristique de Fonction OSPF Not-So-Stubby Areas (NSSA) qui permettra non seulement la récapitulation dans le noyau, mais également les informations plus spécifiques à travers le hub par le lien NSSA. L'avantage d'exécuter NSSA est que les récapitulatifs de routage peuvent être envoyés dans le noyau. Puis, le noyau peut envoyer le trafic à l'un ou l'autre de hub pour atteindre la destination du rai. Si le lien entre un hub et un rai descend, il y aura un LSA plus spécifique du type 7 dans des les deux Concentrateurs pour accéder la destination par l'autre hub.

Être suit un exemple de configuration utilisant NSSA :

N2507: Hub 1 

router odr 
  timers basic 8 24 0 1 
! 
router ospf 1 
  redistribute odr subnets 
  network 1.0.0.0 0.255.255.255 area 1 
  area 1 nssa 
       

N2504: Hub 2 

router odr
  timers basic 8 24 0 1 
! 
router ospf 1 
  redistribute odr subnets 
  network 1.0.0.0 0.255.255.255 area 1 
  area 1 nssa 

N2507# show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
       U - per-user static route, o - ODR 
       
Gateway of last resort is not set 
       
C    1.0.0.0/8 is directly connected, Serial0 
C    2.0.0.0/8 is directly connected, Serial1 
     3.0.0.0/24 is subnetted, 1 subnets 
C       3.3.3.0 is directly connected, Ethernet0 
o    150.0.0.0/16 [160/1] via 3.3.3.2, 00:00:23, Ethernet0 
o    200.1.1.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0 
o    200.1.2.0/24 [160/1] via 3.3.3.2, 00:00:23, Ethernet0

N2504# show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
       U - per-user static route, o - ODR 
       
Gateway of last resort is not set 
       
C    1.0.0.0/8 is directly connected, Serial0 
C    2.0.0.0/8 is directly connected, Serial1 
     3.0.0.0/24 is subnetted, 1 subnets 
C       3.3.4.0 is directly connected, TokenRing0 
C    5.0.0.0/8 is directly connected, Loopback0 
C    6.0.0.0/8 is directly connected, Loopback1 
O N2 150.0.0.0/16 [110/20] via 1.0.0.1, 00:12:06, Serial0 
O N2 200.1.1.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0 
O N2 200.1.2.0/24 [110/20] via 1.0.0.1, 00:12:06, Serial0 

Amélioration de récapitulation et de futur avec NSSA

Assignez un bloc contigu de sous-réseaux aux rais de sorte que ces sous-réseaux puissent être récapitulés correctement dans le noyau OSPF, suivant les indications de l'exemple suivant. Si les sous-réseaux ne sont pas récapitulés et un sous-réseau connecté descend, alors le noyau de totalité le détecterait et recalculerait les artères. En envoyant la route récapitulative pour un bloc contigu, si le sous-réseau en étoile s'agite, le noyau ne le détectera pas.

N2504# configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
N2504(config)# router ospf 1 
N2504(config-router)# summary-address 200.1.0.0 255.255.0.0 
       

N2504# show ip ospf database external 
       
       OSPF Router with ID (6.0.0.1) (Process ID 1) 
       
       
                Type-5 AS External Link States 
       
  LS age: 1111 
  Options: (No TOS-capability, DC) 
  LS Type: AS External Link 
  Link State ID: 200.1.0.0 (External Network Number ) 
  Advertising Router: 6.0.0.1 
  LS Seq Number: 80000001 
  Checksum: 0x2143 
  Length: 36 
  Network Mask: /16 
        Metric Type: 2 (Larger than any link state path) 
        TOS: 127 
        Metric: 16777215 
        Forward Address: 0.0.0.0 
        External Route Tag: 0

Problème de distance

Dans cet exemple, les informations plus spécifiques sont reçues des deux Concentrateurs. Puisque la distance OSPF est 110 et la distance ODR est 160, les informations gêneront ODR quand elles sont reçues de l'autre sous-réseau à peu près identique de hub. L'autre hub sera toujours préféré pour obtenir à la destination de rai, qui entraînera le routage suboptimal. Pour remédier à de la situation, diminuez la distance ODR à moins de 110 avec la commande de distance, de sorte que l'artère ODR toujours soit préférée au-dessus de l'artère OSPF. Si l'artère ODR échoue, l'artère externe OSPF sera installée dans la table de routage de la base de données.

N2504(config)# router odr 
N2504(config-router)# distance 100 
N2504(config-router)# end 

N2504# show ip route 
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default 
       U - per-user static route, o - ODR 
       
Gateway of last resort is not set 
       
C    1.0.0.0/8 is directly connected, Serial0 
C    2.0.0.0/8 is directly connected, Serial1 
     3.0.0.0/24 is subnetted, 1 subnets 
C       3.3.4.0 is directly connected, TokenRing0 
C    5.0.0.0/8 is directly connected, Loopback0 
C    6.0.0.0/8 is directly connected, Loopback1 
o    150.0.0.0/16 [100/1] via 3.3.4.1, 00:00:39, TokenRing0 
o    200.1.1.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0 
o    200.1.2.0/24 [100/1] via 3.3.4.1, 00:00:39, TokenRing0 
O    200.1.0.0/16 is a summary, 00:04:38, Null0 

Les artères de N2 sont toujours dans la base de données et deviendront en activité si le lien de concentrateur principal au rai descend.

N2504# show ip ospf database nssa 
       
       OSPF Router with ID (6.0.0.1) (Process ID 1) 
       
       
                Type-7 AS External Link States (Area 1) 
       

  LS age: 7 
  Options: (No TOS-capability, Type 7/5 translation, DC) 
  LS Type: AS External Link 
  Link State ID: 150.0.0.0 (External Network Number ) 
  Advertising Router: 6.0.0.1 
  LS Seq Number: 80000002 
  Checksum: 0x965E 
  Length: 36 
  Network Mask: /16 
        Metric Type: 2 (Larger than any link state path) 
        TOS: 0 
        Metric: 20 
        Forward Address: 1.0.0.2 
        External Route Tag: 0 

Avec l'amélioration à NSSA, le LSA plus spécifique du type 7 sera dans la base de données NSSA. Au lieu d'un récapitulatif de routage, la sortie de la base de données NSSA apparaîtra comme affiché ci-dessous :

LS age: 868 
Options: (No TOS-capability, Type 7/5 translation, DC) 
LS Type: AS External Link 
Link State ID: 200.1.1.0 (External Network Number) 
Advertising Router: 3.3.3.1 
LS Seq Number: 80000001 
Checksum: 0xDFE0 
Length: 36 
Network Mask: /24 
        Metric Type: 2 (Larger than any link state path) 
        TOS: 0 
        Metric: 20 
        Forward Address: 1.0.0.1 
        External Route Tag: 0 
       
LS age: 9 
Options: (No TOS-capability, Type 7/5 translation, DC) 
LS Type: AS External Link 
Link State ID: 200.1.2.0 (External Network Number) 
Advertising Router: 3.3.3.1 
LS Seq Number: 80000002 
Checksum: 0xFDC3 
Length: 36 
Network Mask: /24 
        Metric Type: 2 (Larger than any link state path) 
        TOS: 0 
        Metric: 20 
        Forward Address: 1.0.0.2 
        External Route Tag: 0 

Circuit de demande

Le circuit de demande est une caractéristique du Cisco IOS 11.2 qui peut également être utilisée dans les réseau hub-and-spoke. Cette caractéristique est en général utile dans des scénarios d'Accès direct secouru et dans le X.25 ou les environnements de circuit virtuel commutés par Relais de trames (SVC). Être suit un exemple de configuration d'un circuit de demande :

router ospf 1 
network 1.1.1.0 0.0.0.255 area 1 
area 1 stub no-summary 

interface Serial0                   /* Link to the hub router  */ 
  ip address 1.1.1.1 255.255.255.0 
  ip ospf demand-circuit 
  clockrate 56000 

Spoke#show ip o int s0 
Serial0 is up, line protocol is up 
  Internet Address 1.1.1.1/24, Area 1 
  Process ID 1, Router ID 141.108.4.2, Network Type POINT_TO_POINT, Cost: 64 
  Configured as demand circuit. 
  Run as demand circuit. 
  DoNotAge LSA not allowed (Number of DCbitless LSA is 1). 
  Transmit Delay is 1 sec, State POINT_TO_POINT, 
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 
    Hello due in 00:00:06 
  Neighbor Count is 1, Adjacent neighbor count is 1 
    Adjacent with neighbor 130.2.4.2 
  Suppress hello for 0 neighbor(s) 

Utilisant la fonctionnalité de circuit à la demande dans un réseau hub-and-spoke évoquera le circuit et formera la nouvelle contiguïté s'il y a n'importe quel changement de la topologie. Par exemple, s'il y a un sous-réseau dans un rai qui s'agite, le circuit de demande évoquera la contiguïté et inondera ces informations. Dans un environnement de zone tronquée, ces informations seront inondées dans toute la zone d'extrémité. ODR résout ce problème en ne coulant pas ces informations aux autres rais. Référez-vous au pour en savoir plus de caractéristique d'OSPF Demand Circuit.

ODR avec les réseaux point par point

L'état en cours du Cisco IOS 12.0 sur des limites de l'Interface Descriptor Block (la BID) est comme suit :

Routeur Limite
1000 300
2600 300
3600 800
4x00 300
5200 300
5300 700
5800 3000
7200 3000
RSP 1000

Avant IOS 12.0, le nombre maximal de rayons qu'un hub pourrait le prendre en charge était 300 dus aux limites BID. Si un réseau exigeait plus de 300 rais, alors la configuration point par point n'était pas un bon choix. En outre, un paquet CDP séparé a été généré pour chaque lien. La complexité horaire pour envoyer des mises à jour de CDP sur les liens point par point est N2. La table ci-dessus nous donne la BID des limites pour différentes Plateformes. Le nombre maximal de rayons pris en charge sur chaque plate-forme varie, mais le temps système de créer un paquet CDP séparé pour chaque lien est toujours une question. Par conséquent, dans une grande situation de hub and spoke, configurer une interface point-à-multipoint est une meilleure solution qu'une interface point par point.

ODR avec les réseaux point-à-multipoint

Dans un réseau point-à-multipoint où un hub prend en charge de plusieurs rais, il y a trois problèmes cruciaux :

  • Le hub peut facilement prendre en charge plus de 300 rais. Par exemple, un réseau 10.10.0.0/22 pourrait prendre en charge 1024-2 rais avec une interface multipoint.

  • Dans un environnement multipoint, un paquet de CDP est généré pour tous les voisins et est répliqué sur la couche 2. La complexité horaire de la mise à jour de CDP est réduite au N.

  • Dans une configuration point-à-multipoint, vous pouvez assigner seulement un sous-réseau à tous les rais.

ODR et plusieurs constructeurs

Une fausse idée commune est qu'ODR ne fonctionnera pas si de plusieurs constructeurs sont utilisés. ODR fonctionnera tant que le réseau est un réseau hub-and-spoke vrai. Par exemple, s'il y a 100 rais et deux des rais sont des Routeurs d'un différent constructeur, puis il est possible d'activer un protocole de routage relatif à ces liens se connectant aux différents Routeurs et d'exécuter toujours ODR sur les autres 98 rais de Cisco.

Figure 6 : ODR avec de plusieurs constructeurs

odr10.jpg

Le routeur concentrateur connecté aux 98 Routeurs de Cisco recevra des mises à jour de sous-réseau par ODR et recevra des mises à jour de protocole de routage des autres deux Routeurs différents. Les liens se connectant aux différents Routeurs doivent être sur le Point à point distinct ou les sous-réseaux point-à-multipoint.

Questions de croissance future

Si une organisation exécute ODR sur 100 rais, ils par la suite peuvent vouloir changer leur topologie d'un réseau hub-and-spoke. Par exemple, ils peuvent décider d'améliorer un ont parlé à une plus grande plate-forme, faisant qui a parlé un hub pour 20 autres nouveaux rais.

Figure 7 : Croissance future

/image/gif/paws/13710/odr9.jpg

Il est possible d'exécuter un protocole de routage relatif au nouveau hub et de garder toujours la conception ODR car il est. Si le nouveau hub prend en charge des rais 20 ou plus nouveaux, ODR peut fonctionner sur le nouveau hub. Le nouveau hub peut se renseigner sur ces nouveaux sous-réseaux en étoile par ODR et redistribuer ces informations au hub d'origine par un autre protocole de routage.

Cette situation est semblable quand ODR commence par deux Concentrateurs. Il n'y a aucun temps système de changer des protocoles. Fondamentalement, ODR peut fonctionner tant que le routeur est une stub.

Représentation

Plusieurs plusieurs configurations peuvent être ajustées pour une convergence plus rapide et une meilleure représentation en exécutant ODR.

Réglage de temporisateurs pour une convergence plus rapide

Dans un grand environnement ODR, ajustez les temporisateurs ODR pour une convergence plus rapide et augmentez les temporisateurs de la mise à jour de CDP du hub au a parlé pour réduire la performance du CPU du hub.

Routeur concentrateur

Le temporisateur de mise à jour de CDP devrait se transférer sur 60 secondes pour diminuer le niveau de trafic du hub aux rais. Le holdtime devrait être grimpé jusqu'au maximum (255 secondes). Puisque le routeur concentrateur doit mettre à jour trop de tables de contiguïté CDP et au cas où quelques voisins descendraient, ne supprimez pas les entrées de CDP de la mémoire pendant 255 secondes (le temps de gel maximal donné). Cette configuration donnera la flexibilité au routeur concentrateur parce que si le voisin se réactive dans un délai de quatre minutes, la contiguïté CDP ne devra pas être recréée. La vieille entrée de table peut être utilisée et le temporisateur de holddown peut être mis à jour.

Être suit un exemple d'un modèle de configuration IP pour un routeur central :

cdp holdtime 255 
       
      router odr 
        timers basic 8 24 0 1  /* odr timer's are update, invalid, hold down, flush 
       
        router eigrp 1 
        network 10.0.0.0 
        redistribute odr 
        default-metric 1 1 1 1 1

Il y a trois circuits virtuels permanents (PVCs) de chaque site distant (entrepôt, région, et dépôt). Deux du PVCs vont à deux Routeurs centraux distincts. Le troisième PVC va à un routeur de PayPoint. On l'exige que le PVC à l'artère de PayPoint soit utilisé pour le trafic destiné pour le réseau de PayPoint. De l'autre les fonctions primaires et de sauvegarde service de deux PVCs pour tout l'autre trafiquent. Basé sur ces conditions requises, voyez le modèle de configuration ci-dessous pour chaque routeur distant.

Il est très important d'ajuster les temporisateurs ODR tels que non valide, le holddown, et l'annulation pour une convergence plus rapide. Quoique le CDP n'envoie pas un préfixe IP une fois le router odr est configuré, le temporisateur de mise à jour ODR devrait apparier le temporisateur de mise à jour de CDP voisin parce que le temporisateur de convergence peut seulement être placé s'il y a un temporisateur de mise à jour. Ce temporisateur est différent que le cdp timer et peut seulement être utilisé pour une convergence plus rapide.

Routeur en étoile

Puisque les rais envoient des mises à jour ODR en paquets de CDP, le temporisateur pour des mises à jour de CDP devrait être maintenu très petit pour une convergence plus rapide. Dans un véritable environnement de rai, il n'y a aucune restriction pour le temps de gel pour le voisin de CDP, puisqu'il y a juste quelques entrées pour a parlé pour maintenir dans sa table de CDP. Le temps de gel maximal de 255 secondes est recommandé de sorte que si le PVC de hub descend et revient dans un délai de quatre minutes, aucune nouvelle contiguïté CDP ne soit nécessaire parce que la vieille entrée de table peut être utilisée.

Être suit un exemple d'un modèle de configuration IP pour un site distant :

cdp timer 8 
cdp holdtime 255 
       
interface serial 0 
encapsulation frame-relay 
cdp enable 
            
interface serial 0.1 point                      /* Primary PVC */ 
ip address 10.x.x.x 255.255.255.0 
frame-relay interface-dlci XX 
      
interface serial 0.2 point                      /* Secondary PVC */ 
ip address 10.y.y.y 255.255.255.0 
frame-relay interface-dlci XX 
      
       
interface bri 0 
interface BRI0 
description Backup ISDN for frame-relay 
ip address 10.c.d.e 255.255.255.0 
encapsulation PPP 
dialer idle-timeout 240 
dialer wait-for-carrier-time 60 
dialer map IP 10.x.x.x name ROUTER2 broadcast xxxxxxxxx 
ppp authentication chap 
dialer-group 1 
isdn spid1 xxxxxxx 
isdn spid2 xxxxxxx 
      
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 
dialer-list 1 LIST 101 
       
       
/* following are the static routes that need to be configured on the remote routers 
       
ip route 0.0.0.0 0.0.0.0 10.x.x.x 
ip route 0.0.0.0 0.0.0.0 10.y.y.y 
ip route 0.0.0.0 0.0.0.0 bri 0 100 
ip classless 

Les routes statiques par défaut ne sont pas exigées si vous utilisez IOS 12.0.5T ou plus tard puisque le routeur concentrateur envoie le default route automatiquement vers tous les rais.

Filtre et récapitulation des artères ODR

Des artères ODR peuvent être filtrées avant qu'elles soient coulées dans le noyau. Utilisez la commande de distribute-list in. Tous les sous-réseaux connectés des rais devraient être récapitulés en coulant dans le noyau. Si la récapitulation n'est pas possible, alors des artères inutiles peuvent être filtrées au routeur concentrateur. Dans des réseaux de plusieurs concentrateurs, les rais peuvent annoncer l'interface connectée qui est le lien à un autre hub.

Dans cette situation, la commande de distribute-list doit être appliquée de sorte que le hub ne mette pas ces artères dans la table de routage. Quand ODR est redistribué dans le hub, ces informations ne sont pas coulées dans le noyau.

Réglage de temporisateur d'opérateur de téléphonie

Il est important d'ajuster le temporisateur d'opérateur de téléphonie pour augmenter le temps de convergence pour les rais. Si le PVC du côté concentrateur descend, les rais devraient pouvoir le détecter rapidement pour commuter au deuxième hub.

Performance du CPU

Le processus ODR ne prend pas le sort d'utilisation du processeur. ODR a été testé pour approximativement 1000 voisins avec l'utilisation du processeur de trois à quatre pour cent. Le paramètre du temporisateur agressif de l'ODR sur le hub aide avec une convergence plus rapide. Si les valeurs par défaut sont utilisées, l'utilisation du processeur demeure à zéro à un pour cent.

Même avec ODR agressif et cdp timer, la sortie ci-dessous prouve qu'il n'y avait pas une utilisation du CPU élevé. Cet essai a été réalisé avec un processeur de 150 MHZ sur un Cisco 7206.

Hub# show proc cpu 
CPU utilization for five seconds: 4%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
   . 
   . 
  18    11588036  15783316   734   0.73%  1.74%  1.95%   0 CDP Protocol 
   . 
   . 
  48    3864      5736        673  0.00%  0.00%  0.00%   0 ODR Router 
     

Hub# show proc cpu 
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
    . 
    . 
   18    11588484  15783850    734   2.21%  1.83%  1.96%   0 CDP Protocol 
    . 
    . 
   48        3864     5736     673   0.00%  0.00%  0.00%   0 ODR Router 

Hub# show proc cpu 
CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
  . 
  . 
 18    11588676  15784090    734   1.31%  1.79%  1.95%   0 CDP Protocol 
  . 
  . 
 48        3864      5736    673   0.00%  0.00%  0.00%   0 ODR Router 
       

Hub# show proc cpu 
CPU utilization for five seconds: 1%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
  . 
  . 
 18    11588824  15784283    734   0.65%  1.76%  1.94%   0 CDP Protocol 
  . 
  . 
 48        3864      5737    673   0.00%  0.00%  0.00%   0 ODR Router 

Hub# show proc cpu 
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
  . 
  . 
 18    11589004  15784473    734   1.96%  1.85%  1.95%   0 CDP Protocol 
  . 
  . 
 48        3864      5737    673   0.00%  0.00%  0.00%   0 ODR Router 
       

Hub# show proc cpu 
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3% 
PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
  . 
  . 
 18    11589188  15784661    734   1.63%  1.83%  1.94%   0 CDP Protocol 
  . 
  . 
 48        3864      5737    673   0.00%  0.00%  0.00%   0 ODR Router

Améliorations

La version d'ODR avant le Cisco IOS 12.0.5T a eu quelques limites. Être suit la liste d'améliorations dans le Cisco IOS 12.0.5T et plus élevé :

  • Avant CSCdy48736, les sous-réseaux secondaires obtiennent annoncé comme /32 dans une mise à jour de CDP. Ceci est réparé dans 12.2.13T et plus tard.

  • Les Concentrateurs de CDP propagent maintenant des default route aux rais, tellement là ne sont aucun besoin d'ajouter des routes statiques par défaut dans les rais. Le temps de convergence augmente de manière significative. Quand le prochain saut descend, le rai le détecte rapidement par l'intermédiaire d'ODR et converge. Cette caractéristique est ajoutée dans 12.0.5T par la bogue CSCdk91586.

  • Si le lien entre le hub and spoke est ip unnumbered, le default route envoyé par le hub ne peut être vu aux rais. Cette bogue, CSCdx66917, est réparée dans IOS 12.2.14, 12.2.14T, et plus tard.

  • Pour augmenter/diminuez la distance ODR sur les rais ainsi ils peuvent préférer un hub au-dessus de l'autre, une suggestion a été faits qui est dépistée par l'intermédiaire de CSCdr35460. Le code a été déjà testé et sera disponible bientôt pour des clients.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 13710