Topologie réseau : le modèle hiérarchique en 3 couches

Suite à un commentaire dans mon article précédent, où l’on me demandait ce qu’était un « switch access », voici une présentation des problématiques de design réseau et des solutions généralement utilisées pour y répondre.
 

Un besoin avant tout

 

Imaginez : vous êtes architecte réseau, votre mission actuelle consiste à mettre en place le réseau d’une entreprise. Vous partez de zéro, l’entreprise cliente ayant décidé que sa vitesse d’évolution justifiait un gros budget et une transformation complète de son réseau.

 

Vous vous retrouvez donc devant une page blanche, avec uniquement les besoins (et donc les obligations techniques que ces besoins apportent) du client. Il faut prendre une décision sur le design du réseau.

 

Et là… Un bon architecte se doit de mettre en priorité les performances, le coût, la tolérance de panne, la rapidité (des échanges), pourquoi pas du load-balancing… Bref, son boulot est de créer un réseau le plus efficace et optimal possible !

 

Or, si l’analyse est mal faite, le risque majeur est de se retrouver avec un réseau mal adapté : évolutions non prévues, lenteurs des échanges, pannes fréquentes, services non fonctionnels, supervision difficile à implémenter et assumer… De plus, tout informaticien sait que plus on divise, plus il est aisé de gérer par la suite (attention, trop diviser sera source de complication…) : c’est le principe même du LAN, de l’architecture réseau mais aussi des classes en développement, par exemple.

 

Heureusement pour nous, l’informatique n’ayant pas été inventé en 2011, d’autres personnes y ont déjà songé. Et en l’occurrence, des personnes beaucoup plus compétentes que le premier admin réseau venu. Il n’est plus nécessaire de réinventer la roue : des modèles existent !
 

Le modèle hiérarchique en « trois-couches »

 

Plus généralement nommé par sa version anglaise, « tree-layers hierarchical internetworking design/model », ce modèle a été inventé et diffusé par Cisco.

 

Le principe est simple : créer un design réseau structuré en trois couches (layers), chacune ayant un rôle précis impliquant des différences de matériel, performances et outils.

 

Ces trois couches sont :

- la couche cœur, « Core layer »
- la couche distribution, « Distribution layer ».
- la couche accès, « Access layer ».

 

Schéma du modèle hiérarchique

Schéma réseau de la topologie. La redondance est apportée par les liens multiples, en plus du doublage des routeurs/switchs si besoin.

 
1) Core Layer

C’est la couche supérieure. Son rôle est simple : relier entre eux les différents segments du réseau, par exemple les sites distants, les LANs ou les étages d’une société.

 

Nous trouvons généralement les routeurs à ce niveau. Si l’entreprise est vraiment grande, ce modèle peut s’imbriquer : le design d’implémentation des routeurs correspond à ce modèle, mais le design du niveau 2 (modèle OSI), c’est-à-dire les switchs, reprendra la même hiérarchisation et les même rôles ! On a donc un modèle Core/Distribution/Access à l’intérieur de la partie Access ou Distribution des routeurs.

 

Mais je m’égare…

 

Comme beaucoup de trafic passe par ces routeurs ou switchs Core, les besoins en performance sont conséquents. Et en débit, aussi. Le matériel change donc en fonction du rôle. Par exemple, chez Cisco, le CRS-3 est la référence (322 Tbps, quand même ! Et ce n’est pas donné…).

 

Le Core est aussi appelé Backbone.

 

2) Distribution Layer

Une fois nos routeurs/switchs de la couche Core choisis et mis en place dans notre architecture, le designer s’intéresse à la couche Distribution.

 

Son rôle est simple : filtrer, router, autoriser ou non les paquets… Nous sommes entre la couche Core et la couche Access, c’est-à-dire entre la partie « liaison » et la partie « utilisateurs ». Ici, on commence à diviser le réseau en segment, en ajoutant plusieurs routeurs/switchs de distribution, chacun étant connecté au Core d’un côté, et à la couche Access de l’autre.

 

Visualisez bien : 1 core router > plusieurs distribution routers connectés sur le même core router > encore plus de switchs access, tous connectés sur un distribution layer. C’est exactement comme un arbre généalogique :-)

 

Ici aussi, selon la taille et les moyens de l’entreprise, l’architecte devra choisir entre routeur et switch. Evidemment, plus la société est grande, plus on aura besoin de routeur à ce niveau. Pour une petite entreprise, des switchs suffisent.

 

Ces routeurs de distribution vont s’occuper de router (envoyer sur le bon chemin, pour les néophytes) les paquets, d’y appliquer des ACLs, d’assurer la tolérance de panne, de délimiter les domaines de broadcast, etc

Note : Bien entendu, s’il n’y a que des switchs dans notre couche distribution, ces actions seront effectuées au niveau Core puisque seule la couche Core possède des routeurs.

 

On peut aussi, comme vous le trouverez probablement dans certains articles sur Internet, résumer le rôle de la couche Distribution en disant qu’elle sert à relier les couche Core et Access.


3) Access Layer

C’est la dernière couche de notre modèle. Son rôle est simple mais très important : connecter les périphériques « end-users » au réseau.

 

Mais aussi, assurer la sécurité !

 

Ici, pas de routeur. Seuls des switchs, ou hubs parfois, sont implémentés. C’est normal, me direz-vous, puisque tout le travail des routeurs est déjà effectué au niveau de la Distribution ou du Core. Résultat, on ne s’occupe que de connecter nos end-users au réseau, que ce soit en Wi-fi, Ethernet ou autre. Et si possible, on le fait de manière sécurisée, c’est-à-dire en utilisant switchport sur nos switchs, en désactivant les interfaces non utilisées, etc… (cela pourrait faire l’objet d’un prochain article, tellement il y a à dire !).

 

Du coup, la configuration de ce type de switch pose moins de contrainte. Pas besoin de performances particulières car chaque switch aura – au maximum – un nombre d’utilisateur égale à son nombre de port (moins 1 ou 2 pour le trunk entre Access et Distribution). De plus, les traitements restent basiques et ne demandent que peu de ressources.

4) Mais encore ?…

Il est important de noter que chaque couche apporte ses impératifs et ses besoins, influençant le matériel mis en place ainsi que  les configurations et/ou solutions.

 

C’est d’ailleurs la raison principale de l’existence de ce modèle : plus compliqué, au premier abord, à mettre en place, mais totalement plus efficace, rentable, réfléchi et économe sur le long terme qu’une architecture improvisé au fil du temps.

 

Autres modèles

 

Certes, le modèle hiérarchique en trois couches est une référence que de nombreuses architectures utilisent. Il est généralement adapté aux besoins de l’entreprise.

 

Mais il n’est pas le seul et unique modèle. Il existe de nombreux autres modèle d’architecture, tels que le modèle « en étoile » par exemple ou encore le « Campus LAN ».

 

Cependant, ce n’est pas le sujet de cet article (si je devais parler de tous les designs existants on en aurait pour quelques jours), ni dans mes priorités de rédaction : la plupart de ces modèles sont beaucoup trop théoriques, et – bien qu’ils soient nécessaire à tout architecte réseau – n’ont pas vraiment d’intérêt sur ce blog.

 

Bilan

 

Pour finir, 3 points à retenir :

- Ce modèle hiérarchique est une référence, il est très utilisé. Mais il faut bien entendu l’adapter aux besoins de son entreprise.

- Chaque couche – Core / Distribution / Access – implique des configurations différentes. Notamment la couche Access, qui nécessite de la part de l’administrateur certaines actions (réglage de l’état de chaque port des switchs, mise en place de trunk, sécurité, etc…)

- Tous les liens (lien = liaison entre deux points, englobant le côté physique et logiciel) sont doublés/backupés dans la majorité des cas. (voire mon article précédent par exemple)

 

Et n’oubliez pas que réfléchir et choisir le mieux possible l’architecture de son réseau, c’est-à-dire le design, les plages d’IP pour les différents LANs, le nombre de LAN/VLAN et tous les autres paramètres, est primordial ! Surtout sur le long terme…

Routeurs et redondance : VRRP

Cet article a pour objectif de :

-         vous présenter le (ou les) protocole(s) utilisés pour permettre la redondance sur des routeurs CISCO.

-         vous expliquer la théorie, nécessaire à une bonne compréhension de la pratique (et de l’article…)

-         vous donner un exemple concret de configuration !

 

 

Tout d’abord, présentons le contexte.

 

De nos jours, les réseaux informatiques sont de plus en plus grands, compliqués, modernes… mais surtout, ils deviennent de plus en plus « logiques ». C’est-à-dire virtuels. Fini le temps où un réseau était un LAN, physiquement délimité par un routeur. Désormais, les VLANs sont omniprésents, tout comme les interfaces virtuelles, les IPs virtuelles, etc…

Comme détaillé à l’instant, les réseaux informatiques sont logiques. Certes. Mais ils sont aussi plus grands. C’est-à-dire qu’il y a plus de périphériques, plus d’utilisateurs, plus de distance (avec les VLANs, nos LANs ne sont plus géographiquement limités) et souvent plus de débit…

Or, tout LAN a une gateway (passerelle, ou « passerelle par défaut »). Exceptionnellement, ou dans les petites entreprises, la gateway peut être un serveur (Windows Server 2008 R2 par exemple) ou un TMG Forefront. Mais plus généralement, et systématiquement dans les grandes entreprises, une gateway est un routeur.

 

D’où : si la gateway est un routeur, et que le nombre de périphérique augmente de plus en plus, comment assurer un service constant de cette gateway ? Comment être certain que le routeur de sortie ne va pas couper les liens, interdisant toute communication entre le (ou les) LANs et ce qu’il y a derrière (autres LANs, Internet, liaison WAN…) à un moment ou à un autre ?

 

Plus simplement : comment assurer une tolérance de panne efficace et sûre au niveau de toutes nos gateway, afin d’obtenir une disponibilité (DICP) maximale ?

 

La solution est la redondance : si notre routeur tombe, un autre prend sa place. Très simple, non ?

Très, peut être pas, mais simple, oui !

Car effectivement, CISCO (et d’autres) y ont pensé ! Depuis longtemps, les environnements CISCO utilisent un protocole nommé HSRP (Hot Standby Router Protocol) pour gérer tout cela.

 

Je pourrais vous présenter HSRP, mais l’apparition (assez récente) de VRRP change la donne. HSRP est propriétaire CISCO, alors que VRRP est l’adaptation de HSRP à des fins de normalisation : protocole disponible pour tous.

 

VRRPv3 (dernière version), pour Virtual Router Redundancy Protocol, est défini dans la RFC 5798.

 

Comme je ne suis pas le seul à présenter VRRP sur l’Internet, je vous rassure tout de suite : je ne vais pas paraphraser Wikipédia ou l’article d’un autre. Une explication simple et basique, même pas tellement technique, et un bon exemple.

Voilà les ingrédients de la vulgarisation (et donc de la compréhension) !

 

 

1] Comment ça marche ?

 

Vous avez donc deux routeurs (identiques, si possible). Pour l’article, nos deux routeurs seront des routeurs CISCO (2921 par exemple).

Ces deux routeurs sont reliés à un switch, que ce switch soit un switch Access ou pas n’ayant pas vraiment d’importance.

Nous avons donc : Internet/WAN/Autres LANs -> 2 routeurs -> 1 switch -> [d’autres switchs, mais c’est facultatif] -> les périphériques clients.

 

VRRP1

Schéma du réseau sans VRRP

 

Habituellement, chaque périphérique du LAN doit être configuré (soit par DHCP soit de façon statique et manuelle) avec une adresse IP, un masque de sous-réseau (définissant son appartenance au (V)LAN) et une adresse de passerelle.

Et bien dans notre cas, c’est identique ! Sauf que… quelle adresse de passerelle choisir ? Celle du routeur 1 (R1) ou du deuxième (R2) ?

La réponse ? Aucune des deux ;-)

 

Et oui ! N’oublions pas que la présence de R2 n’est justifiée que par le besoin de redondance, et donc de VRRP.

Pour l’instant, nous n’avons pas mis en place VRRP, ni même expliqué son fonctionnement.

Voici l’architecture logique cible, une fois VRRP configuré sur nos deux routeurs :

 

VRRP2

Schéma du réseau avec VRRP

 

Que voyons-nous ?

Toujours notre réseau simplifié, avec nos deux routeurs R1 et R2, notre switch SW1 et enfin nos périphériques utilisateurs (serveurs, imprimantes, PCs…). Mais le cadre bleu, nouveau, représente VRRP.

 

En fait, avec VRRP activé, voilà ce qu’il se passe :

1)      Nos deux routeurs ont chacun une priorité ainsi que divers paramètres sur lesquels nous reviendrons dans la suite de l’article.

2)      Le routeur possédant la plus haute priorité est élu Maitre.

3)      L’autre passe en statut « standby ».

4)      L’adresse IP virtuelle (en bleu sur le schéma, 10.10.0.1) est alors utilisée uniquement par le routeur Maitre.

5)      Si les priorités changent (par exemple, lorsqu’un lien tombe, un service réduit la priorité du routeur), une élection a lieu à nouveau afin de désigner le routeur Maitre.

 

Ainsi, si PC1 ping l’adresse IP 10.10.0.1, il ne saura pas quel routeur répond. Cette adresse sera joignable, comme si elle correspondait à une interface physique d’un vrai routeur. En fait, cette IP est virtuelle, et n’est donc qu’un « point » dans le réseau. Point relié aux deux routeurs. C’est ensuite VRRP qui définit quelle interface (et donc quel routeur) doit répondre aux requêtes.

 

Ok. Si cela est (vraiment) compris, le plus dur est fait. Je vous encourage à relire les 2 ou 3 derniers paragraphes et à bien regarder le schéma.

 

Comprenez bien que si R1 est élu maitre, alors PC1 et PC2 passeront par le lien WAN (l’éclair jaune sur le schéma) de R1 (celui de gauche donc) pour accéder à Internet, et non celui de R2.

Le routeur R2 ne sera d’ailleurs pas sollicité, si ce n’est par quelques protocoles de routage ou autres, et bien sur par VRRP. Mais ni PC1, ni PC2 ne passeront par R2 pour communiquer avec Internet ou avec un LAN distant : VRRP ne fait pas de load-balancing (répartition de charge), mais uniquement de la redondance (tolérance de pannes).

 

 

2] Configuration et exemples :

 

Maintenant, attaquons la configuration. Et qui dit configuration, dit exemple !

 

R1> enable

R1# conf t

R1(config)# interface FastEthernet 0/0                                      ! Mode configuration d’interface

R1(config-if)# ip address 10.10.0.2 255.255.252.0                ! Adresse IP de F0/0 sur R1

R1(config-if)# no shutdown                                                                  ! Activation de l’interface

R1(config-if)# interface Serial0/0/0                                               ! Mode configuration d’interface

R1(config-if)# ip address 172.16.1.2 255.255.255.252         ! Adresse IP de S0/0/0 sur R1

R1(config-if)# no shutdown                                                                  ! Activation de l’interface

R2(config)# interface FastEthernet 0/0

R2(config-if)# ip address 10.10.0.3 255.255.252.0

R2(config-if)# no shutdown

R2(config-if)# interface Serial0/0/0

R2(config-if)# ip address 172.16.1.6 255.255.255.252

R2(config-if)# no shutdown

 

Ici, rien à voir avec VRRP, nous nous sommes contentés d’attribuer les IPs du schéma sur nos interfaces, avec le masque correspondant (/22 = 255.255.252.0 ; soit 1024 adresses donnant 1022 hosts).

Par convention et mesure de sécurité, il est préférable de configurer les différentes interfaces AVANT de configurer VRRP. Dites vous bien que généralement, il n’y a pas uniquement deux routeurs…

 

Une fois cela fait, attaquons nous au cœur du sujet : VRRP.

 

R1(config)# interface FastEthernet 0/0                  ! Mode configuration d’interface

R1(config-if)# vrrp 10 priority 160                                ! Réglage de la priorité de R1

R1(config-if)# vrrp 10 timers advertise 3                 ! Réglage du timer “advertise”

R1(config-if)# vrrp 10 timers learn                               ! Réglage du timer “learn”

R1(config-if)# vrrp 10 ip 10.10.0.1                                   ! Réglage de l’IP virtuelle du group

R1(config-if)# vrrp 10 preempt                                        ! Activation du preempt

R1(config-if)# vrrp 10 enable                                             ! Facultatif

 

Et c’est tout pour le routeur R1.

 

Détaillons :

- Ligne 1 (L1) : Nous entrons en mode configuration d’interface.

- L2 : Nous attribuons une priorité à l’interface, c’est-à-dire au routeur. De plus, nous créons par la même occasion le groupe « 10 » (appelé VRID pour Virtual Routeur ID)

- L3/L4 : Réglage des délais d’avertissement (envoie de paquet aux autres routeurs du groupe VRRP pour vérifier l’état du VRID) et de « learn » (fréquence d’apprentissage des infos VRRP)

- L5 : Attribution de l’adresse IP virtuelle du VRID, c’est-à-dire l’IP représentant le groupe qui sera utilisée par R1 ou R2 selon le cas.

- L6 : Cette option autorise un routeur à devenir maitre si sa priorité est supérieure à celle du maitre actuel, même si ce maitre fonctionne correctement. Sans cette option, il y aura réélection si et seulement si le routeur maitre tombe.

- L7 : On active le VRID/routeur virtuel (facultatif).

 

 

Rebelotte sur R2 :

 

R2(config)# interface FastEthernet 0/0

R2(config-if)# vrrp 10 priority 100                          ! Priorité inférieure par choix !!

R2(config-if)# vrrp 10 timers advertise 3

R2(config-if)# vrrp 10 timers learn

R2(config-if)# vrrp 10 ip 10.10.0.1                             ! Même IP que sur R1 ! Logique.

R2(config-if)# vrrp 10 preempt

R2(config-if)# vrrp 10 enable

 

Seule la priorité a changé.

 

Explications :

Nos deux routeurs sont configurés pour appartenir à un seul et même VRID, c’est-à-dire un « groupe VRRP ». En fait, c’est un routeur virtuel (ou logique si vous préférez), un « faux routeur qui n’existe pas physiquement mais seulement virtuellement ». Le fait de créer ce VRID équivaut presque à la création d’un troisième routeur (R3) dans notre schéma : le routeur « bleu ». Ces deux routeurs, R1 et R2 donc, ont des IPs différentes sur leurs interfaces. Le VRID, lui, possède une IP virtuelle : 10.10.0.1.

 

La priorité de R1 étant supérieure à R2 (160 > 100), c’est R1 qui sera élu maitre. C’est donc R1 qui va posséder l’adresse virtuelle 10.10.0.1, et répondre aux différentes requêtes adressées à cette adresse : telnet, ssh, ping…

 

Si, par le plus grand des hasards, R1 s’éteint ou n’est plus joignable (F0/0 down notamment), il y a réélection dans le groupe. R2 est ici le seul autre routeur, il va donc être élu maitre. S’il y avait eu 3 routeurs dans le VRID, et donc 2 routeurs restants, celui avec la plus haute priorité serait devenu maitre. Et, si les 2 restants avaient eu la même priorité, celui avec l’adresse IP la plus élevée serait passé maitre.

 

Une fois R2 devenu maitre, c’est lui qui va répondre à l’adresse virtuelle (10.10.0.1). Le temps de transition est faible – et paramétrable ; généralement configuré pour un délai de 120 secondes, soit 2 minutes, afin d’éviter un changement de routeur à chaque petite coupure de connexion (plus fréquente qu’on ne le pense, mais sans réel danger pour les données).

 

On pourrait presque imager cela en prenant l’exemple du NAT : une fois le routeur maitre élu, son interface (F0/0) est liée au VRID, et donc l’IP de F0/0 est reliée à celle du VRID. Ainsi, 10.10.0.2 est directement liée à 10.10.0.1.

 

Résultat : si vous appelez 10.10.0.1, c’est en fait 10.10.0.2 et donc F0/0 de R1, qui vous répond ;-)

 

Fortiche VRRP hein ? Et ce protocole étant une norme, il est surtout multi-tout : OS, plateforme, fabricant… Bien sur, encore faut-il qu’un module/paquet existe pour l’exploiter.

 

 

3] Bonus : surveiller une interface

 

Là où VRRP prend encore plus d’importance et d’intérêt, c’est qu’il est capable de surveiller l’état d’une interface (ou de plusieurs) et d’agir en fonction.

 

Utilisation typique : on force R1 comme maitre (en lui donnant une priorité supérieure à celle de R2) et on utilise donc la table de routage ainsi que la liaison WAN de ce routeur. Si l’interface reliée au LAN tombe, il y a réélection. Mais que se passe-t-il si la liaison WAN tombe ? Rien… Comme VRRP est configuré sur l’interface LAN F0/0 de R1, l’état de S0/0/0 ne l’intéresse pas : VRRP ne sait même pas si cette interface est up ou down !

 

Ne serait ce pas encore plus efficace si VRRP forçait une réélection du routeur maitre dès qu’une des deux liaisons de R1 tombe ? Histoire d’utiliser la liaison WAN de R2 pour sortir du réseau, au lieu d’être bloqué !

Certes. Il est heureusement possible de faire cela !

 

R1(config)# track 1 interface serial 0/0/0 line-protocol

R1(config)# interface F0/0

R1(config-if)# vrrp 10 track 1 decrement 100

 

Sur la première ligne, nous définissons quelle interface “surveiller” (to track en anglais). On attribut un identifiant (1 ici) à cette surveillance, on y désigne l’interface puis le type de surveillance (line-protocol = état du lien ; ip-routing = routage activé ou pas + état du lien).

 

Puis après être entré en mode configuration d’interface (la bonne, celle appartenant au VRID), nous attribuons au VRID 10 la bonne surveillance (via l’identifiant précédemment désigné, « 1 »), suivi du plus important : l’action à prendre en cas de problème. Ici, nous allons enlever 100 à la priorité de R1. Résultat : 160 – 100 = 60 ; 60 < 100 ; d’où : R2 devient maitre.

 

Ainsi, en ne rajoutant que 2 lignes dans notre fichier de configuration de R1 (nous n’avons pas touché à R2 !), nous évitons bien des soucis. Désormais, si la liaison WAN de R1 tombe, le LAN pourra toujours communiquer avec l’extérieur grace à la liaison WAN de R2. Et la transition passera inaperçue !

 

Et bien entendu, vous pouvez appliquer la même chose de l’autre côté, par mesure de sécurité.

 

 

4] Pour aller plus loin !

 

Cet article s’achève. Vous êtes désormais capable de mettre en place VRRP sur un routeur CISCO. Et surtout, vous devriez avoir compris le principe de ce protocole, très important et très utilisé (en fait, HSRP – l’ancêtre propriétaire CISCO – est majoritairement utilisé dans les environnements cisco, mais les services IT sont en train de migrer ; et VRRP est très très proche de HSRP).

 

Pour approfondir, en plus des articles de bloggeurs divers et variés, vous retrouverez toutes les infos nécessaires sur le site (la Bible, devrais je dire) de CISCO, notamment :

-         VRRP sur Cisco.com

-         Configuring VRRP sur Cisco.com

-         VRRP (Fr) sur Wikipédia

-         VRRP (En) sur Wikipédia

 

N’hésitez pas à poser vos questions dans les commentaires, s’il y en a !

Et partagez l’article s’il vous a plu !