Archive for the ‘Lab. time’ Category
Date du lab programmée et INE Mock Lab I
Bonjour à tous,
Comme promis, je vous donne des nouvelles de ma préparation pour le lab.
Je m’améliore sur mes points faibles comme le MPLS et le Multicast en travaillant sur les Workbook Vol I même si je sens qu’il me reste un petit peu de boulot.
Ce qui me pose le plus problème également est l’interprétation des tâches et leur vrai sens. Normalement, l’énoncé vous oriente avec ses contraintes sur une seule et unique solution valide en restant assez ambigu, vous forçant à connaitre ce qu’on attend de vous avant même de penser à la réalisation de la tâche en elle-même.
Plus largement, mon objectif est d’adopter une stratégie solide pour les deux parties du lab et de s’y tenir. Ne pas aller trop vite. Bien tenir compte de toutes les contraintes et dépendances des tâches.
J’ai programmé ma date de lab également. Mon premier essai aura lieu le 29 juillet à Bruxelles.
NAT on a stick sans VLAN
Bonjour à tous,
Cela fait un moment que je n’avais pas écrit sur cet espace, ma préparation pour le lab s’intensifie de jours en jours. Je sens que je deviens de plus en plus confiant sur les technologies et la juste interprétation des tâches. Je posterais des détails dans la foulée après cet article.
Mais pour l’instant, parlons d’un mode d’implémentation qui m’a, à première vue choqué mais qui se révèle au final très logique, vous allez le voir.
« Faites du NAT on a stick sans VLAN! »
Lorsque vous pensez à la translation d’adresse, vous pensez à la translation statique et dynamique surchargée(PAT avec overload) entre zones inside et outside. Vous pouvez l’appliquer sur des ports physiques ou des sous-interfaces de VLAN sur un routeur. Jusque là rien de bien exceptionnel.
L’énoncé nous demande de faire du NAT on a stick sans utiliser de sous-interfaces et donc de VLAN. Vous avez bien lu. Il faut que le routeur soit capable de faire de la translation d’adresse sur un même port physique! Regardons la topologie pour avoir plus de détail sur ce qui nous attend.
BGP Backdoor
Bonjour à tous,
Un petit article court aujourd’hui pour parler d’une fonctionalité assez utile, BGP Backdoor.
Introduction
L’idée est de faire préférer un chemin plus optimal pour le transit des données au lieu de la classique distance administrative pour installer la route dans la table de routage du routeur.
Pour mettre en image tout cela, prenons cette topologie.
Topologie
DMVPN : les tunnels à la demande!
Introduction
Bonjour à tous,
Après avoir changé de travail depuis maintenant 15 jours et rejoint la société Econocom, les missions qui me sont affectées me permettent de monter en compétence et de pratiquer sur une technologie Cisco que je ne connaissais que de nom, DMVPN!
A l’époque où j’avais préparé la CCNA Security, je me souviens en avoir entendu parler mais rien de bien concret. Le scope à l’époque restait tout de même très concentré sur les VPNs IPsec site-à-site ou accès distant.
Je vous propose de commencer par un peu de théorie avant d’aborder la question de l’implémentation en elle-même.
DMVPN c’est quoi?
Dynamic Multipoint VPN. Rien que l’acronyme est accrocheur!
Il s’agit d’un mécanisme qui vous permet d’établir les tunnels IPsec+GRE directement entre les routeurs qui veulent dialoguer ensemble avec une simplicité et une scalabilité déconcertante et surtout de façon totalement dynamique!
Il utilise un mécanisme Hub & Spoke où un routeur est défini comme jouant le rôle d’hub. Le reste des routeurs opèrent en mode spoke.
On peut facilement imaginer comment un spoke peut contacter un autre spoke directement sans passer obligatoirement par un hub et comment par ce biais, rediriger tout le data plane de la session. L’utilisation de la bande passante peut-être donc optimisée et conservée pour ne pas saturer les liens du hub par exemple.
Par exemple, une fois le routeur hub configuré, vous pourrez implémenter une configuration quasi-générique sur les spokes sans changer la configuration du hub!
Un composant est crucial dans le mécanisme, NHRP ou Next-Hop Resolution Protocol.
Vous verrez pourquoi quand je parlerais plus en détail de la procédure d’établissement des tunnels.
Lectures achevées, place à la pratique maintenant!
Introduction
Ayant terminé intégralement mon étagère de livre Cisco Press récemment, je me suis, depuis quelques jours, lancé directement dans la préparation du tant redouté Lab!
Avant de parler de tout cela, un petit feedback des livres que j’ai pu lire!
Feedback des livres lus
Avant de parler du Lab, quelques petits feedbacks sur les livres s’imposent :
L’un des premiers livres que j’ai lu dans le cadre de ma préparation théorique.
Très très bonne lecture qui vous emmène dans le fonctionnement complexe des protocoles de routages IGP.
Temps de lecture : ~ 2 semaines
Note: 5/5
Ce livre fut également l’une de mes premières lectures dans ma préparation.
D’aussi bonne qualité que le premier, ce livre complète le spectre de compétences en abordant les EGP et les différents services(Multicast,NetFlow, RMON, NTP). Même si certains topics ne sont pas « officiellement » au programme, les auteurs nous les décrivent avec la même pédagogie.
Temps de lecture : ~ 2 semaines
Note: 4/5
CCIE Official Certification Guide:
Ce livre est dans la continuité des autres livres que Wendell Odom et explique plus dans la globalité les différentes technologies auxquelles nous aurons à faire lors de l’éxamen écrit.
Le livre « suffit » pour la partie écrite mais en aucun cas pour la partie lab.
Temps de lecture : ~ 3 semaines
Note : 4,5/5
Cet ouvrage est celui qui m’a permis de démystifier entièrement MPLS, sujet qui m’étais totalement étranger.
Il est écrit par Luc de Ghein dans une prose qui favorise l’apprentissage et la bonne compréhension des différents concepts.
Beaucoup de concepts vus dans ce livre ne sont absolument pas nécéssaires(je pense notamment au Trafic Engineering avec MPLS) et sauf si vous voulez aller plus loin sur le sujet, je vous invite à lire les premiers chapitres ainsi que le chapitre sur les MPLS VPN qui eux font partie du programme CCIE.
Temps de lecture : ~ 1 semaine et demi
Note: 4,5/5
Ce petit ouvrage délivré sous la forme d’un eBook et revoit tout les concepts rapidement.
C’est un bon ouvrage de révision juste avant de passer le written mais n’en attendez pas plus!
Temps de lecture : ~ 1 semaine
Note : 2,5/5
Mise en place d’un VPN MPLS
Introduction
Dans le cadre de ma préparation pour l’examen écrit, j’ai presque fini de lire « MPLS Fundamentals » de Luc de Ghein.
Ce livre m’a beaucoup aidé à démystifier MPLS et ses différents mécanismes et d’un en particulier dont nous allons parler aujourd’hui: les VPN MPLS.
Je vais concentrer le sujet de ce billet sur l’implémentation de la technologie qui reste, une fois qu’on a assimilé les concepts inhérents, très logique à faire et à suivre.
Comme d’habitude, on commence par une topologie diabolique(ou pas…) faite maison:
Plusieurs précisions s’avèrent nécéssaires pour la bonne compréhension de ce schéma.
Protocoles de transition IPv6 : 6to4
Introduction
Comme vous le savez, nous sommes « à court » d’IPv4 publiques depuis le début de l’année.
Autant dire que cet évènement va, je l’espère, accélérer la transition inéluctable vers une architecture plus portée vers l’IPv6.
Maintenant vous pouvez vous poser la question légitimement, comment passer « en douceur » à l’IPv6 sans forcément bannir IPv4 de votre réseau interne et externe et remettre en question votre architecture entière.
C’est là où les protocoles de transition rentrent en jeu et notamment celui que nous allons voir dans ce post : 6to4.
6to4
Le postulat de ces protocoles de transition reste assez simple. Il s’agit de permettre à du traffic de type IPv6 de passer à travers un réseau IPv4 classique. Cela est rendu possible grâce au routeur qui encapsule notre paquet IPv6 dans la zone de données du paquet IPv4(c’est-à-dire le payload) et ainsi l’envoyer à travers un réseau IPv4 dans perdre aucune information IPv6.
Remarquez que l’on pourra aisément distinguer ce type de paquet grâce au Type 41 dans le header de notre paquet IPv4.
6to4 va vous permettre d’établir des tunnels de type point-to-multipoint de façon totalement dynamique.
La force de cette technologie est de pouvoir par exemple, ajouter 100 routeurs dans votre topologie sans pour autant remettre en cause la configuration de vos routeurs existants puisque tout s’établit de façon dynamique!
Ce protocole utilise la range 2002::/16 pour pouvoir fonctionner.
L’inconvénient principal néanmoins de 6to4 est qu’il ne prend pas en charge les IGP, ce qui n’est pas nécéssairement un problème si vous restez dans un environnement 6to4.
Passage d’un rack CCNP à CCIE
On ne parle pas de CCIE sans parler obligatoirement d’expériences pratiques.
Depuis le commencement de mon parcours CCNP Routing & Switching et jusqu’à son obtention il y a quelques semaines maintenant, je me suis fabriqué un « rack maison » qui m’a permis en complément de la théorie de pratiquer sur du matériel Cisco dont j’ai l’habitude de me servir quand je réalise des déploiements.
Le dilemme posé au départ pour la préparation pratique de cette certification m’offrait deux options distintes: me construire un rack Cisco entier ou me faire une architecture virtuelle à l’aide de simulateurs. J’ai choisi la première option après mûre réfléxion avec ses avantages et ses inconvéniants :
- + Charge CPU quasi nulle
- + Expériences sans limites
- + Moins de bug
- – Coût
- – Fléxibilité
Même si l’investissement que j’ai réalisé a été important(de l’ordre de 4000€ pour le matériel ici), la pratique sur du vrai matériel ne peut pas être égalée par un quelquonque simulateur. Néanmoins, on enlève de la fléxibilité à l’expérience puisque je ne peut pas réaliser mes labs quand je suis par exemple en déplacement surtout quand ceux-ci incluent du câblage à réaliser.
