Essayer de tester une configuration VRRP de laboratoire virtuel pour les problèmes STP


9

Je suis en train de mettre en place un laboratoire avec une configuration VRRP , et j'essaie de rechercher tous les problèmes possibles que nous pourrions rencontrer en production.

Un problème que je connais avec VRRP est qu'il semble que le temps de convergence STP (d'environ 45 secondes, je crois) peut parfois provoquer le flap des nœuds VRRP. Selon mon diagramme, je ne vois aucune boucle (en ignorant les serveurs multi-hébergés en bas), donc je suppose que je peux simplement désactiver STP et l'oublier. Mais j'aimerais voir ce qui se passe avec STP activé, tout de même.

J'utilise Vyatta Core 6.5 pour les routeurs ISPA et ISPB. J'exécute les VM sur la station de travail VMWare.

La raison pour laquelle mon laboratoire inclut des commutateurs entre ISPA et ISPB est que, dans la production, nous les utilisons pour mettre fin aux liaisons montantes fibre vers notre fournisseur. J'ai donc essayé de rendre mon laboratoire aussi proche que possible de la production.

Ma configuration est comme ça:

Diagramme de laboratoire VRRP

Mon problème est que, actuellement, les commutateurs n'existent pas réellement dans mon laboratoire. J'utilise simplement des segments LAN dans la station de travail VMWare pour permettre aux machines virtuelles Vyatta de se parler. Mon problème est que parce que toutes les connexions entre les VM se font à l'intérieur de l'Hyervisor, il semble qu'il n'y ait aucune possibilité de tester des choses comme ça.

Ma question est: quelqu'un peut-il penser à un moyen de connecter ces machines virtuelles de manière à simuler des machines Vyatta physiques connectées via des commutateurs Cisco (ou autres), afin que je puisse tester STP (et tout ce à quoi je peux penser) ?

Ce que j'ai essayé

Utilisation de GNS3 pour interconnecter des machines virtuelles

Une chose que j'ai essayé de faire est de faire communiquer les machines virtuelles via GNS3 à l'aide d'adaptateurs VMNet Host-Only à intégrer à GNS3, puis en utilisant un Cisco 3745 avec un module de commutation FastEthernet ajouté. Il y a quelques problèmes ici:

  • Dans mon laboratoire, j'utilise un seul sous-réseau pour parler entre ISPA et ISPB (10.11.246.0/29).
  • VMWare s'attend à ce qu'un seul adaptateur VMNet utilise un seul sous-réseau, donc je ne peux pas utiliser plusieurs adaptateurs VMNet distincts avec le seul sous-réseau 10.11.246.0/29.
  • Dans tous les cas où deux machines virtuelles utilisent le même adaptateur VMNet, les paquets sont envoyés directement entre eux, et donc sans adaptateurs VMNet séparés, je ne vois pas de moyen forçant les machines virtuelles à communiquer via un routeur GNS3.
  • Ma compréhension est qu'avec VRRP, utiliser un sous-réseau plus petit que ce qui pourrait accueillir tous les nœuds + IP virtuelles serait considéré comme un hack et non recommandé. Ainsi, par exemple, l'utilisation de / 30s et de plusieurs adaptateurs VMNet n'est pas une bonne idée.

Autres notes

  • Je suis ouvert à l'utilisation d'autres plateformes de machines virtuelles telles que la boîte virtuelle.
  • J'ai un Cisco Catalyst 2950 physique sur mon bureau, et la machine hôte dispose de deux NIC physiques disponibles.

1
Je peux voir une boucle afin de ne pas désactiver STP. ISPB-BDR-01, ISPB-BDR-02, les commutateurs Cisco sont une boucle. ISPB-BDR-01, ISPB-BDR-02 et ISPB-BDR-SW01 et ISPB-BDR-SW02 en est un autre. 45 secondes, cela semble long, avez-vous activé la portée rapide (802.1w)? Cela réduirait le temps de convergence. Où est le pont racine STP? Il est recommandé d'avoir la racine STP sur le périphérique VRRP / HSRP actif.
Epaphus

@Epaphus Oh vraiment? Je dois fondamentalement mal comprendre ce qui constitue une boucle. Je n'ai actuellement pas activé la répartition rapide, bien que j'aurais pensé que dans les deux cas, le fait qu'il y ait un temps de convergence signifie que je voudrais tester pour m'assurer que ce temps de convergence est toujours suffisamment bas. En ce qui concerne la racine STP, je n'ai pas encore pensé à la configuration STP, car je suis toujours concentré sur la mise en place du laboratoire afin de tester une telle configuration (et comme vous l'avez peut-être deviné, j'ai une expérience minimale avec STP).
Geekman

@Epaphus Oh je pense que je vois maintenant. En effet, même s'il n'y a qu'une seule connexion physique entre chaque combinaison de commutateurs <-> routeur, ils font tous partie du même domaine de diffusion, donc cela constitue toujours une boucle. Droite?
Geekman

Pourquoi cette inquiétude? Vous êtes bloqué uniquement avec 802.1D? Vous ne pouvez pas exécuter RSTP?
laf

Sauf si vous allez travailler très dur et activer le pontage dans vos routeurs (ou si votre diagramme n'est pas correct), il n'y a pas de boucle car 2 commutateurs ne sont pas interconnectés.
fredpbaker

Réponses:


1

Ma question est: quelqu'un peut-il penser à un moyen de connecter ces machines virtuelles de manière à simuler des machines Vyatta physiques connectées via des commutateurs Cisco (ou autre), afin que je puisse tester STP (et tout ce à quoi je peux penser) ?

Vous pouvez utiliser l'hyperviseur ESXi pour exécuter les machines virtuelles gratuitement et ajouter le commutateur virtuel Cisco NEXUS 1000. Téléchargement du commutateur Nexus


0

Je ne comprends pas votre inquiétude concernant VRRP.

En regardant la topologie, aucun des commutateurs n'est attaché les uns aux autres. À moins que vous ne fassiez quelque chose de fou, comme activer le pontage sur les serveurs, ne voyez pas comment vous créez une boucle.

Plus intéressant, si ISP-BDR-01 est attaché au LAN 2 et ISP-BDR-01 est attaché au LAN 1, ils ne se voient pas au niveau 2, les routeurs Cisco n'autorisent pas le même sous-réseau sur plusieurs interfaces, donc je suggère votre la topologie telle que documentée ne fonctionne pas. L'ajout d'un lien entre les commutateurs corrige désormais le fait que la connexion des commutateurs ne crée pas non plus de boucle.

La plupart des routeurs prennent en charge les ajustements dans les minuteries afin que vous puissiez si vous souhaitez définir un basculement VRRP plus important que la convergence STP, mais étant donné la topologie simple, vous vous inquiétez de la mauvaise chose


Ma compréhension est que la boucle est causée parce que, par exemple, vous pouvez passer du routeur ISPB-BDR-01 à ISPB-BDR-02 via ISPB-BDR-SW01 ou SW02, donc c'est deux chemins possibles dans le même domaine de diffusion, donc il y a la boucle. Je ne suis pas à 100% là-dessus, mais cela a du sens. En référence à votre deuxième paragraphe, je suppose que vous parlez d'ISP_B_-BDR-01/02. Où mon digram montre-t-il qu'ils se trouvent sur des réseaux locaux distincts? Les deux routeurs partagent le même LAN sur les cartes réseau publiques (il indique LAN1 à gauche et à droite), et un autre (LAN2) sur le côté privé.
Geekman

Je suppose que mon problème n'est pas tant de savoir comment résoudre ce problème potentiel, car j'ai vu qu'il y a un paramètre de préemption-retard dans Vyatta qui, je suppose, résoudrait tous les problèmes potentiels. Mais le problème est plus - comment puis-je tester cela avec un minimum de matériel physique? Particulièrement STP, mais il y a probablement beaucoup d'autres choses auxquelles je n'ai pas pensé.
Geekman

dans la liste de cisco land, vous NE POUVEZ PAS configurer le même sous-réseau sur 2 interfaces dans le même routeur. donc oui le sous-réseau A peut aller de ISPB-BDR-01 à ISPB-BDR-02 via ISPB-BDR-SW01 mais un sous-réseau différent irait via SW01 également pour avoir une boucle L2 que les routeurs doivent transmettre à L2 et ils ne le font pas c'est le cas ISPB-BDR-01 ne transmettra JAMAIS un ARP de SW01 à SW02
fredpbaker

0

ok, vous devez avoir stp, est-ce que certains des utilisateurs ont un ordinateur portable? longs câbles Ethernet? adaptateurs à deux ports? hehe, règles d'utilisation! qu'en est-il de la batterie de serveurs? pas de potentiel de boucle là hein?

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.