Mois : novembre 2009

Configurer un switch Cisco sous MacOS

Antoine 1 commentaire

CISCO LOGOCela fait désormais un an que je suis utilisateur assidu de MacOS. J’ai toujours réussi à faire ce que je faisais sur PC sur MacOS à quelques exceptions près. Ces deux exceptions sont les jeux 3D spécifiques Windows (Flight Simulator entre autre) et l’administration d’un équipement réseau via port série.

Les MacBook Pro ne sont pas dotés d’un port série. J’ai donc du commander un adaptateur USB-Série sur Ebay pour une somme tout à fait correcte dont je ne me souviens plus. On en trouve actuellement pour moins d’une dizaine d’euros. Vous allez cependant devoir vous armer de patience car ils sont le plus souvent expédiés de Chine. Voici à quoi ressemble ce fameux adaptateur.

usbserie

Il fonctionne parfaitement sous Ubuntu. Je n’ai eu aucune difficulté particulière. Une simple recherche Google et l’installation d’un driver a suffit pour le faire fonctionner. Je souhaitais cependant le faire fonctionner sur mon MacBook car il est quand même bien plus pratique de déplacer un portable qu’une tour.

La première action à effectuer est de récupérer le pilote adapté à l’adaptateur que vous avez acheté. Le problème est qu’il n’y a strictement rien marqué dessus. Ayant précédemment fait l’installation sous Ubuntu, j’avais réussi à déterminer qu’il s’agissait d’un PL2303. Ces adaptateurs semblent très répandus. Il y a donc beaucoup de chances que si le votre ressemble au mien, ce soit la même chose. Vous trouverez le pilote du PL2303 sur le site d’Apple. Vous allez devoir redémarrer votre poste pour finaliser l’installation du pilote.

Ensuite, il va falloir se connecter au périphérique que vous avez raccordé à l’autre bout de votre câble série. Sur Windows, vous auriez eu HyperTerminal qui remplit très bien ses fonctions. Sur MacOS, il est visiblement possible de faire fonctionner Minicom. Je n’ai pas du tout réussi… Fink et apt-get n’ont pas réussi à le trouver dans leurs dépôts. Je me suis donc lancé dans l’utilisation de screen. Dans mon cas, mon adaptateur était reconnu sous le nom /dev/cu.PL2303-00002006.

Il va falloir aller configurer les paramètres du port série du système. Dans le fichier /etc/gettytab, vous devriez trouver des lignes commencant par « serial. « . Effacez (ou commentez) toutes celles ne contenant pas 9600. Sauvegardez le fichier et exécuter la commande suivante :

stty -f /dev/cu.serial

Si la première ligne de la réponse est « speed 9600 baud; », votre port série est bien configuré. Vous pouvez ensuite accéder au périphérique en exécutant la commande suivante :

screen /dev/cu.PL2303-00002006

Vous devriez pouvoir accéder à votre périphérique. Une fois que vous aurez fini la configuration, vous pouvez quitter le screen en tapant « Cmd A » puis « Cmd . ».

Je pense que ce tutoriel devrait être utile à quelques personnes car cette configuration n’est pas forcément aisée à faire. Je me suis aidé d’un sujet sur le site d’Apple et d’un tutoriel du site MacOSHints.

Cloisonnement d’un réseau à l’aide de VRF : Introduction

Antoine 1 commentaire

stepfinal2Je vais commencer une nouvelle série d’article plus orientée vers le réseau. Je n’ai eu que relativement peu d’occasions de parler de réseau sur ce blog mais je vais me rattraper quelque peu. Cette série devrait comporter 3 articles voire peut être un peu plus, en fonction de mon humeur. Elle est le résultat d’une journée d’expérimentation effectuée avec un collègue dans le cadre de mon stage. Dans ce billet d’introduction, je vais présenter l’objectif de l’expérimentation, le matériel utilisé et la topologie.

La problématique

Lorsque nous nous sommes lancés dans ces expériences, nous avions un objectif bien précis correspondant à la réalité d’une architecture actuellement en production. La problématique était d’isoler au niveau IP plusieurs clients pouvant potentiellement avoir des plages d’IP similaires. Plus concrètement, l’objectif était d’isoler chaque client dans sa « bulle de routage » afin de pouvoir avoir une plus grande liberté dans l’évolution de l’architecture et dans l’intégration de nouveaux clients.

Nous savions déjà qu’il était possible de résoudre le problème d’isolation par le biais des VRF de Cisco. Pour rappel, une VRF est une « bulle de routage » spécifique à un groupe de ports. Typiquement, une VRF correspond à un client spécifique. La véritable difficulté venait du fait que nous souhaitions également qu’il soit possible de communiquer de manière sélective entre les différentes VRF.

Le matériel utilisé

Afin de pouvoir tester la mise en place de cette idée, nous avons ressorti des équipements Cisco qui se trouvaient fortuitement sur notre chemin. Ce jour là, notre chemin a rencontré deux Cisco 7204 VXR ainsi que deux Cisco 2970G. Chaque 7204 VXR était doté d’une carte de supervision avec 2 ports 100Mbit/s ainsi que d’un module 1 interface 100Mbit/s supplémentaire. Nous avons donc mélangé tout ce matériel pour faire deux routeurs différents : le « Routeur 1  » sans module supplémentaire et le « Routeur 2  » avec les deux modules supplémentaires.

Voici une petite photo du montage que nous avons effectué.

matosLe « Routeur 1  » était le routeur du haut et le « Routeur 2  » était le routeur du bas. Au niveau des switchs, nous n’avons utilisé que celui du bas. Les ports 1 et 2 servaient pour le réseau « Interco ». Les ports 13 à 16 étaient le VLAN de Prod. Les ports 17 à 20 étaient le VLAN Client 1. Les ports 21 à 24 étaient les VLAN Client 2. Le câble permettait de relier le PC de test.

Topologie logique

Le schéma suivant représente la topologie logique que nous avons mis en place.

SchemaGlobalSmall

Le « Routeur 1  » est le routeur qui pourrait faire office de routeur de sortie vers Internet. La route par défaut de notre réseau pointera sur lui. Le « Routeur 2  » est le routeur « coeur » qui arbitrera toutes les VRF et les échanges de routes. Les trois switch du bas du schéma sont les différents LAN de nos clients. L’objectif sera de faire communiquer les LAN client avec le routeur 1 et le LAN de Prod.

Au final, cet article avait pour objectif de vous présenter la topologie et la problématique. Le prochain article s’attachera  la configuration des équipements et la mise en place des VRF.

Articles de la série

Barcamp ce Samedi à Troyes

Antoine 3 commentaires

barcamp_icon_finalJe vais faire un petit billet de publicité pour un événement auquel je vais participer ce weekend. Il s’agit d’un barcamp. Pour ceux qui ne connaissent pas le principe du barcamp, il s’agit d’une rencontre entre passionnés de diverses technologies où chacun présente un sujet de son choix.

Un barcamp aura donc lieu à la Halle Sportive de l’Université de technologie de Troyes ce Samedi à partir de 17 heures. Il aura lieu en marge de l’Utt Lan Session qui est une LAN Party organisée par l’Utt Net Group. Il devrait durer jusqu’à 22 heures environ. Une pause pour manger est prévue afin de pouvoir reposer vos neurones.

En ce qui me concerne, j’aurais l’occasion de vous faire une présentation « tour d’horizon » sur les réseaux de stockage. Vous pourrez également participer à de nombreuses autres présentations parmi les suivantes :

  • VBA
  • SOAP
  • OpenID & OAuth
  • OpenPGP
  • LDAP
  • CNIL
  • Trap your process

N’hésitez pas à venir faire un tour et nous rencontrer ce weekend à Troyes. Vous trouverez toutes les infos nécessaires par rapport à cette manifestation sur le site de l’ULS.

Récapitulatif

  • Quoi ? Un barcamp
  • Quand ? Samedi 28 Novembre à partir de 17h jusqu’à 22h
  • Où ? A la Halle Sportive de l’Université de technologie de Troyes
  • Pour qui ? Tout le monde qui souhaite partager avec nous

L’envers de la virtualisation, épisode 2

Antoine 3 commentaires

tech-presentation-2Lors du précédent article, j’ai introduit cette série d’articles par le portrait marketing de la virtualisation. Vous l’aurez sans doute compris que ce portrait se voulait ironique. L’ironie puise cependant ses origines dans la réalité. Les discours marketing sont souvent assez peu loin de ce que j’ai eu l’occasion de décrire.

Une boite noire qui fait tout

La virtualisation se vend actuellement sous forme de solutions « boite noire » qu’on installe sur un serveur standard. Cette configuration incite à faire penser qu’il est possible d’installer cette « boite noire » en mode Windows sans se poser la moindre question. Lorsque vous installez une plateforme de virtualisation, l’hyperviseur de virtualisation est la couche applicative la plus critique de votre infrastructure. Vous comprendrez donc aisément l’importance et la criticité de ce composant applicatif.

L’installation d’un hyperviseur de virtualisation doit être la plus standard possible. Vous allez sans aucun doute être amené à migrer des machines virtuelles d’un serveur à un autre. Il faut donc que la couche la plus basse soit standardisée. De plus, il est nécessaire de limiter au strict nécessaire les fonctions exécutées par la couche de virtualisation afin de limiter les possibilités de bugs.

On l’installe et on l’oublie

Au cours de l’exploitation de votre plateforme, vous serez sans aucun doute amener à rencontrer des problèmes liés à la couche de virtualisation. Penser que la virtualisation est quelque chose de parfaitement transparent est parfaitement faux. Il est nécessaire de maintenir cette plateforme. Des actions de maintenance classique sont l’analyse des performances afin de déterminer si votre plateforme est correctement dimensionnée ainsi que l’analyse des fichiers de logs.

Tous les défauts inhérents à un système d’exploitation peuvent se retrouver au niveau des couches de virtualisation. Il n’y a pas de magie spécifique qui tendrait à rendre parfait une plateforme de virtualisation. Il est nécessaire d’y porter un regard attentif et régulier.

Tout marche tout seul

Cette affirmation peut être vraie. Cependant, la limite de sa véracité se limite à la survenue du premier problème lié à la couche de virtualisation. Les problèmes vont avoir besoin de personnes pour se résoudre. Les problèmes de couche de virtualisation ne sont pas forcément simples. Il est donc nécessaire d’avoir du personnel formés à la virtualisation qui connaissent les spécificités de cet outil ainsi que son fonctionnement.

Au final, la virtualisation est une technique informatique exceptionnelle qui s’implante avec succès dans les infrastructures actuelles. Il est cependant nécessaire de prévoir soigneusement l’installation des couches de virtualisation afin d’assurer une homogénéité et d’éviter de nombreuses surprises en cas de défaillance. Il est également nécessaire de prévoir et prendre le temps d’analyser le fonctionnement quotidien de cette couche de virtualisation afin de s’assurer de sa santé et de prévoir les évolutions. De plus, une couche de virtualisation n’est pas un système d’exploitation comme un autre et nécessite une formation spécifique.

Configuration réseau d’OpenSolaris

Antoine 1 commentaire

solarisJe vous ai déjà fait une présentation succincte de Solaris et introduit la prise en main d’un tel système d’exploitation. Au fur et à mesure que je découvre, de mon coté, OpenSolaris, je rencontre différents problèmes. Un problème assez handicapant que j’ai rencontré est la configuration réseau.

Lorsque j’ai monté ma machine virtuelle OpenSolaris, j’ai fait la configuration réseau à la main rapidement via l’utilitaire ifconfig. Je ne représenterais pas cet utilitaire dans ce billet. Son fonctionnement sous Solaris est fortement similaire à son fonctionnement sous Linux. L’utilitaire route fonctionne de manière similaire pour l’ajout de routes. Il est cependant différent dans la mesure où il ne permet pas l’affichage de la table de routage via la commande route -n. Afin d’afficher la table de routage, il est nécessaire d’exécuter la commande netstat -rn.

La problématique de ce type de configuration est que la configuration n’est pas conservée après un redémarrage du système d’exploitation. Nous allons donc nous intéresser plus spécifiquement à la configuration pérenne des interfaces réseau en IP statique. La configuration se fera via le module physical:default.

Tout d’abord, vous allez devoir déclarer le nom d’hôte de votre machine. Vous remplacerez xnf0 par le nom de votre interface réseau.

echo « hostname »> /etc/hostname.xnf0

Ensuite, on sauvegarde le fichier hosts d’origine et on y insère les noms d’hôte de votre machine.

echo « 127.0.0.1 localhost »> /etc/inet/hosts

echo « 10.0.0.3 antoinebenkemoun.fr »>> /etc/inet/hosts

Nous allons ensuite spécifier le masque de sous-réseau lié à cette interface.

echo « 10.0.0.0 255.0.0.0 »>> /etc/inet/netmasks

Il nous reste plus qu’à préciser la route par défaut.

echo « 10.0.0.1 »> /etc/defaultrouter

La configuration de l’interface est désormais terminée. Il ne nous reste plus qu’à vérifier que les bon services sont activés. Nous devons activer le service physical:default et désactiver physical:nwam. Ce deuxième service est un doublon du premier, il ne faut donc en activer qu’un seul.

svcadm disable svc:/network/physical:nwam

svcadm enable svc:/network/physical:default

Afin de faire prendre en compte les modifications d’interface réseau, il est nécessaire de redémarrer le service physical:default.

svcadm restart svc:/network/physical:default

Le tour est joué ! Je pense que ce billet devrait être utile à certaines personnes démarrant sous Solaris et venant du monde de Linux. Dans tous les cas, il me sera utile pour future référence.

L’envers de la virtualisation, épisode 1

Antoine 2 commentaires

tech-presentation-2J’ai eu l’occasion d’évoquer les nombreux mérites de la virtualisation dans ce blog. La virtualisation est un des « buzzword » très à la mode actuellement. On en parle en long, en large, en travers et en profondeur (rien que ca …). Je n’évoquerais pas le « cloud computing » dans cet article car j’aurais l’occasion d’évoquer le sujet ultérieurement.

A en croire les louanges faites de la virtualisation, il serait quasiment possible de croire qu’il s’agit du paradis de l’informatique, la solution pour toutes les dominer. Dans un premier épisode, je dresserais le tableau qui est dressé par les commerciaux de produits de virtualisation. Dans un second épisode, je m’attacherais à coller plus à la réalité. Cet article se veut ironique au cas où vous auriez un doute.

En route vers le paradis

La virtualisation présente de nombreux avantages et permet de donner un nouveau souffle aux architectures informatiques. Ceci se fait essentiellement à travers la mutualisation des équipements physiques. Cette mutualisation des équipements permet donc des réductions de coûts. Vous allez juste devoir rajouter une petite « boite noire » qui se maintient automatiquement et qui permet de donner une flexibilité incroyable à votre infrastructure.

Vous allez pouvoir remplacer votre baie de serveurs physiques ayant chacun leur utilité par un petit nombre de serveurs plus puissants dotés d’une plateforme de virtualisation. Cette affirmation est exceptionnellement alléchante mais ne présente que le point de départ et le point d’arrivée. Le chemin entre les deux n’est pas sans embuche et ne s’emprunte pas aveuglément.

Vous allez pouvoir économiser de l’argent au niveau du stockage car plus les disques sont volumineux plus le prix au gigaoctet est faible. Vous allez peut être même pouvoir gagner en redondance car vous aurez plusieurs serveurs. Vous allez économiser au niveau du réseau car vous aurez besoin de moins de ports réseau.

Les nouvelles machines que vous allez acheter vont être des monstres de puissance et donc théoriquement vous aurez plus de puissance et de rapidité. De plus, vous avez lu de nombreux articles sur la virtualisation qui vous ont démontré que les performances d’un OS virtualisé sont pratiquement identiques à celles d’un OS natif. Que de bonheur !

Au final, voici un bon nombre de clichés que nous rencontrons tous les jours autour de la virtualisation. Je vous donne rendez-vous pour le second épisode qui s’attachera à donner du réalisme à toutes ces promesses.