Cet article est un complément aux vidéos publiées récemment (visibles ici). Dans ces vidéos, quelques outils sont cités pour émuler un terminal VT100 afin d’accéder à l’interface console de l’équipement. Si vous souhaitez apprendre les technologies Cisco, il faudra tôt ou tard utiliser un logiciel de ce type.
Le but de cet article est précisément de vous aider à choisir un de ces outils. Pour cela, nous allons d’abord présenter les fonctions attendues sur un tel logiciel. Vous verrez dans cet article que l’émulation de terminal est une fonction de base certes, mais ce n’est pas la seule à laquelle nous pouvons prétendre pour un logiciel digne de notre intérêt !
Émulation de VT100
Un logiciel d’émulation de terminal doit évidemment permettre d’émuler le comportement d’une VT (Virtual Terminal). Cette fonction de base consiste à permettre la communication entre l’ordinateur et l’équipement réseau en exploitant le lien série (port COM) de l’ordinateur. Sur les équipements Cisco, le port série n’a pas l’aspect physique d’un port COM mais d’un connecteur RJ-45. Pour autant, il ne faut pas se méprendre, ce connecteur ne peut pas être utilisé pour être raccordé à un réseau ! La prise RJ-45 du « port console » est juste une façon de proposer un connecteur mécanique habituel mais les fils sont utilisés pour l’échange de caractères en série. Pas d’Ethernet ou d’IP sur ce port: c’est impossible.
De nos jours, cela semble plus qu’obsolète et pourtant, on utilise encore ce protocole tout simple (le protocole série RS-232) pour échanger des caractères sur une liaison série. Les caractères saisis sur le clavier de l’ordinateur sont transmis sur la liaison vers l’équipement via son port console et les caractères reçus sur le port COM de l’ordinateur sont affichés dans l’interface du logiciel d’émulation. Le fonctionnement de base est là: l’échange de caractères entre l’ordinateur et l’équipement réseau.
Client Telnet et SSH
Ensuite, lorsque l’équipement est configuré (on parle de la configuration initiale d’un équipement), il lui est généralement attribué une adresse IP pour lui permettre d’être administré « à distance ». Pourquoi parle-t-on d’administration à distance ? Tout simplement par opposition à l’administration via le port console (qui est un port série, donc) où l’échange – par un protocole « série » – limite fortement la longueur des fils de cuivre. Seul un cable de quelques mètres peut être utilisé entre l’ordinateur et l’équipement réseau. Alors que, lorsqu’on utilise la technologie IP pour l’échange de caractères, il n’y a plus de limite physique (à partir du moment où la connectivité IP est possible entre l’ordinateur et l’équipement). L’administration (configuration, supervision, diagnostic, etc.) peut alors se faire à distance…
Cependant, à distance ou pas, l’accès à l’interface de commande en ligne consiste à échanger des caractères. La seule différence, c’est qu’à distance on n’utilise plus les interfaces séries mais la pile de communication TCP/IP (sur un port autre que le port console, donc). Ce sont toujours des caractères qui sont échangés mais en utilisant les protocoles TCP/IP: c’est le rôle du protocole Telnet. Ainsi, il est intéressant que le logiciel qui servait initialement pour émuler une VT en exploitant le lien série du PC puisse, après la phase de configuration initiale, jouer le rôle de client Telnet ou, préférablement, de client SSH (c’est fonctionnellement la même chose, mais avec de la sécurité en plus !).
Ainsi, le logiciel d’émulation de terminal devra idéalement permettre l’accès au CLI à distance en supportant les protocoles Telnet et SSH.
Gestion multi-sessions
Maintenant que notre outil permet d’accéder à distance au CLI, il est aisé de se connecter à plusieurs équipements réseaux sans rien changer sur l’ordinateur: il suffit de se connecter sur une autre adresse IP distante (associée à un autre équipement). C’est le cas en entreprise mais c’est également le cas lorsque l’on travaille sur des plate-forme de tests: nous devons nous connecter à plusieurs routeurs et commutateurs pour les configurer, les surveiller ou bien pour diagnostiquer un problème ! Dans ce cas, il est optimal que l’outil d’accès au CLI nous permettent de gérer plusieurs connexions simultanées avec, par exemple, des onglets différents (exactement comme sur un navigateur web!).
Et puis, puisque l’on a plusieurs sessions, il peut être très pertinent d’avoir un logiciel qui nous autorise, à la demande, d’envoyer les commandes, non plus sur un seul onglet, mais sur tout ou partie des onglets. Par exemple, lorsque je souhaite activer une nouvelle fonctionnalité sur le réseau, cela nécessite de rentrer les mêmes commandes sur tous les équipements: quel confort de pouvoir taper la commande une seule fois et d’indiquer qu’elle doit être envoyée sur les différentes sessions ouvertes ! Voilà pourquoi, dans la fonctionnalités « multi-sessions », il ne s’agit pas seulement de permettre d’établir plusieurs connexions en même temps !
Script et Auto-Login
Là encore, c’est une fonctionnalité additionnelle non obligatoire mais appréciable. Un script préalablement défini dans le logiciel peut faciliter l’accès aux équipements en renseignant automatiquement les champs attendus pour l’authentification. L’utilisateur n’a même plus besoin de rentrer ses identifiants login/mot de passe (lesquels peuvent être différents pour chaque équipement) ! Cela peut sembler abusif une telle possibilité ; mais pourtant, mettez-vous à la place d’un administrateur qui doit gérer plusieurs dizaines d’équipements: dans ce cas, l’avantage saute immédiatement aux yeux !
Transfert de fichier par lien série (ZMODEM, etc.)
Enfin, il arrive (de rares fois heureusement) que l’accès au système d’exploitation de l’équipement soit impossible. Un peu comme lorsque votre PC n’arrive pas à charger Windows: on n’a accès qu’au BIOS ! 😥
Dans ce cas, pas de pile IP disponible pour mettre à jour le logiciel IOS : seule une version très simplifiée de l’IOS peut être utilisée pour communiquer avec l’équipement. Mais la résolution ne se fait pas en quelques commandes, il faut parfois formater la mémoire et recharger le logiciel d’exploitation. Pour cela, la solution consiste à utiliser le lien série (port console) pour échanger – octet par octet – le logiciel d’exploitation ! Ces protocoles (par exemple, ZMODEM) doivent donc être supportés par notre outils d’accès au CLI… (OUF, on pourra s’en sortir 😉 )
Voilà donc une liste non exhaustive des fonctionnalités que j’utilise dans mon logiciel d’accès au CLI. Un article (prochainement mis en ligne) listera les principales solutions logicielles disponibles sur le marché et analysera chaque offre au regard des fonctions listées ici!
Bien sûr, cette liste constitue une sélection personnelle de ce qu’il me semble prioritaire. Alors, n’hésitez pas à partager avec nous ce que vous utilisez (ou pas) et les fonctions importantes que vous aimez retrouver. Dites-nous TOUT, dans les commentaires ci-dessous!
Laisser un commentaire