Hôtes virtuels pour labo Cisco réel…

Derrière ce titre on ne peut plus flou se cache la solution que j’ai mise en place pour ajouter diverses machines (clients/serveurs/…) à mon labo Cisco personnel.

Alors que mon rack commence à devenir un peu étroit, je cherchais un moyen économe et efficace pour ajouter divers clients/serveurs aux topologies sans devoir d’une part investir dans du matériel en plus, et d’autre part en évitant d’encore accroître l’encombrement de mon labo.

Et si la solution résidait dans le non respect des bonnes pratiques ? Et si pour une fois on faisait abstraction des grands principes qu’on nous fait digérer pour les certifications ?

 

Avant-propos…

Ce qui j’ai mis en place pour mon labo va à l’encontre de plusieurs règles de bases en matière de bonnes pratiques dans un réseau de production… Il s’agit ici d’une solution de bricolage pour répondre à un besoin précis avec peu de moyens à disposition.

 

Matériel à disposition…

Rien de très glorieux en soi:

  • Un switch WS-C2950 24x FastEthernet (servant d’interconnexion entre mon réseau domestique et le labo, en plus des interconnexions entre les routeurs au besoin).
  • Un vieux PC (Core2 Duo 1ere génération, 8Gb RAM, HDD 320Go) doté d’une interface GigabitEthernet supportant les VLANs (chipset Realtek 8111C).

Et avec ça je devrais arriver à enrichir le labo de 3-4 clients/serveurs…

 

Quelques pistes…

Comment transformer un PC en plusieurs machines ? … La virtualisation! Voilà la base de ma réflexion.

Ensuite survient un premier problème… le PC ne dispose que d’une interface physique. Même si elle supporte les VLANs, je n’arriverai à priori pas à connecter physiquement les machines virtuelles où je le souhaite (sur un switch d’accès par exemple…) et surtout si je veux en utiliser plusieurs en même temps…

SAUF si je m’écarte de l’utilisation standard des vlans et des trunks…

  1. Activer le support des trames ethernet taguées dot1q sur le PC
  2. Configurer un trunk entre le switch et le PC (Serveur de virtualisation Hyper-V)
  3. Créer un vlan dédié à chaque machine virtuelle sur le switch. Et associer un switch virtuel côté Hyper-V pour chacun de ces VLANs

Jusque-là je peux amener le trafic des machines virtuelles jusqu’au switch… maintenant il faut encore arriver diviser les trafic des vlans vers des interfaces physiques différentes… Rien de plus simple: à chaque vlan dédié à une machine virtuelle, j’ai associé une et une seule interface physique.

 

Mise en place…

vhosts

Du point de vue fonctionnement, tout trafic provenant d’une machine virtuelle circule dans un vlan dédié, et débouche sur une interface physique (et vice-versa).

De la sorte, je peux connecter la VM du VLAN 100 à n’importe quel équipement simplement en reliant la Fa0/20 du switch à ce même équipement.

L’interface Fa0/24 est un trunk tout ce qu’il y a de plus standard (sans négociation, vu qu’à l’autre bout du fil se trouve un PC incapable de négocier le trunk, il faut donc forcer le mode).

Les Fa0/20-23 sont des ports en mode « access », placé dans leur vlan respectif, ni plus, ni moins.

Oui mais … et si cet équipement était un switch ? Cela ne poserait-il pas un problème ? En théorie oui. Pour éviter tout problème, il faudrait respecter les numéros de VLANs etc…

Pour contourner cette restriction j’ai décidé d’outrepasser une règle d’or en matière de VLANs: « Ne jamais faire passer du trafic d’un vlan à un autre ».

Comment fait-on cela ? C’est aussi simple que de configurer les ports Fa0/20-23 en mode « access » et de les mettre dans le vlan désiré (respectivement, 100, 110, 120 et 130)… et de raccorder cette interface sur n’importe quel port de n’importe quel switch en mode « access ».

Oui mais … si le vlan d’accès n’est pas le même des deux côtés ? Le switch ne va-t-il pas générer des alertes ? … Si bien sûr… pour autant qu’il le voit!. Il suffit donc de le rendre aveugle … en désactivant CDP sur les interfaces Fa0/20-23 (« no cdp enable » en configuration de ces interfaces).

Chose totalement déroutante, je peux même désormais connecter le port Fa0/20 par exemple sur un autre port du même switch … sans que Spanning-Tree ne bloque la liaison… Logique finalement, puisque chaque VLAN est géré par une instance différente de STP.

Résultat…

Un PC largement dépassé qui me permet d’héberger sans souci 6-8 machines virtuelles (Ubuntu Server 12.04 LTS), que je peux maintenant connecter où je le souhaite sur mes équipements du labo.

Cela ne fonctionne bien entendu que si je garde le principe d’avoir une correspondance comme: 1 VM = 1 VLAN = 1 Interface physique du switch

Solution économe, fonctionnant plutôt bien … mais que je ne mettrais jamais en oeuvre dans une infrastructure en production 😉

3 Comments on “Hôtes virtuels pour labo Cisco réel…

  1. « non respect des bonnes pratiques », « abstraction des grands principes », « à l’encontre de plusieurs règles de bases », « solution de bricolage », « outrepasser une règle d’or », « jamais en oeuvre dans une infrastructure en production »… Je crois que vous avez été assez clair pour qu’on fasse gaffe à ce qu’on fait ! 😉

    Mais c’est une solution vraiment économique, même sans virtualisation. Un Linux avec 24 vlans sur son interface réseau, un 2950 relié en Gigabit, et on a un ordinateur avec 24 cartes réseau pour pas cher. Moi, j’aime bien ce critère !

  2. Bonsoir !

    J’avais déjà fait ça mais j’avais de problèmes de STP qui se déclenchait tout seul. Merci pour le « no cdp enable »aue je vais essayé au plus vite ! 😉

    Pour la virtualisation, regardez du coté des conteneurs Linux (OpenVZ, LXC) qui sont beaucoup plus économes en terme de ressources (le noyau étant partagé). Ça limite à des machines Linux, mais c’est bien pratique.

    Merci pour ces bonnes idées, vivement le prochain live ! 😉

    • Le no cdp enable ne permet que d’éviter les messages du genre ‘vlan mismatch’. Côté STP tant qu’il n’y a pas de boucle ça devrait passer. Mais le fait de tricher au niveau des vlans empêche STP de faire son job… Donc gaffe aux erreur de câblage 😉