> Tech > Mettez de la redondance dans vos WAN / LAN

Mettez de la redondance dans vos WAN / LAN

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par John Green - Mis en ligne le 19/05/2004

Grâce à  ces standards et pratiques, les paquets continueront à  circuler

Le serveur est en panne ! Internet est en rideau ! Les administrateurs système et les administrateurs réseau préfèreraient ne jamais entendre ces mots : et, après tout, les mots expriment rarement la réalité...Combien de fois un serveur est-il entièrement détruit ? Combien de fois Internet souffre d'une défaillance globale ? La plupart des pannes du système proviennent d'un seul composant. Votre mission est de le trouver, de le réparer et de remettre le système en service.
Pour des systèmes cruciaux, vous vous efforcez de prévoir l'immobilisation et de la réduire. L'une des méthodes consiste à  analyser le chemin de communication du système, des serveurs aux utilisateurs, et de surveiller les points de défaillance uniques potentiels - c'est-à -dire, les composants individuels qui, quand ils ne fonctionnent plus, peuvent rendre tout le système indisponible. Après avoir identifié les divers points de défaillance potentiels, reste à  décider ce qu'il faut en faire. Compte tenu de l'aspect financier, vous vous livrez à  une analyse de risque - formel ou informel. La réponse comporte souvent une ou plusieurs des stratégies suivantes :

  • Ne rien faire. Soit le risque est faible, soit le coût d'une réparation est trop élevé.
  • Acquérir des pièces détachées à  froid. Les pièces détachées à  froid sont des composants permettant de remplacer rapidement les pièces défectueuses. Cette stratégie présente un coût et un risque modérés et elle convient quand on peut tolérer un certain temps d'interruption.
  • Acquérir des pièces détachées à  chaud. Ce sont des composants redondants qui fonctionnent en permanence, prêts à  relayer les composants en panne du système. Le clustering, l'équilibrage de charge, et les hot sites sont tous des formes de cette redondance, selon la partie d'un système à  réparer.
En tant qu'administrateur réseau, vous devez vous assurer que les paquets continuent à  circuler. Souvent, les connexions réseau redondantes sont votre meilleur allié. Une telle redondance assure la tolérance aux pannes et augmente la capacité de communication. Pour construire des chemins de communication réseau fiables, vous devez savoir comment mettre en oeuvre des connexions LAN et WAN redondantes. Pour plus d'informations sur les standards et protocoles qui permettent les scénarios de redondance suivants, voir l'encadré « Glossaire des standards et protocoles concernant les réseaux redondants ».

Tôt ou tard, vous serez confrontés à 
une défaillance de communication survenant
dans le subnet local d’un serveur.
Le NIC et la passerelle par défaut
du serveur sont tous deux des points
de défaillance potentiels, mais vous
pouvez ajouter de la redondance de diverses
manières.

NIC multiples sur le même subnet.
Que votre système serveur soit
autonome, en cluster, ou à  équilibrage
de charge, le NIC est un point de défaillance
potentiel. A partir de Windows
2000, Microsoft a simplifié l’installation
de multiples NIC configurés
pour le même subnet IP. Pour assurer la
redondance des NIC, vous pouvez
connecter de tels NIC au même hub ou
commutateur ou, mieux encore, à  des
commutateurs différents. La propriété
Interface metric détermine lequel des
NIC actifs (c’est-à -dire, validés) le système
utilisera pour le trafic sortant. Le
système utilise le NIC avec le nombre
le plus petit dans le champ Interface
metric. Allez à  Control Panel, Network
et Dial-up Connections, Local Area
Connection, Properties. Sélectionnez
Internet Protocol (TCP/IP) et cliquez
sur Properties. Sur l’onglet General,
cliquez sur Advanced. Enlevez la coche
de la case Automatic Metric en bas de la
boîte de dialogue résultante et entrez
la valeur que vous voulez attribuer à  ce
NIC.

Passerelles par défaut multiples.
Une défaillance de la passerelle
par défaut sur le subnet stoppe le trafic
vers les subnets distants. Pour pallier
ce genre de défaillance, on peut mettre
en oeuvre des routeurs multiples sur le
subnet. Le VRRP (Virtual Routeur
Redundancy Protocol) et le HSRP (Hot
Standby Router Protocol) assurent une
telle tolérance aux pannes sans demander
de changements de configuration
chez le client. Vous pouvez aussi
mettre en oeuvre des passerelles par
défaut multiples chez chaque client en
définissant plus d’une adresse de passerelle par défaut sur chaque NIC. A
partir de Win2K, Microsoft permet
d’attribuer une valeur à  une passerelle
par défaut de la même manière que
vous en attribuez une à  un NIC.
Dans les précédentes versions de
Windows, on pouvait attribuer une valeur
à  une passerelle par défaut en installant
des passerelles par défaut supplémentaires
directement dans la table
de routage IP. Pour procéder à  de tels
changements de la table de routage,
utilisez la commande Route Add avec
l’option Metric à  une invite de commande
standard. Par exemple, la commande

route -p add 0.0.0.0 mask 0.0.0.0
10.10.0.254 metric 15

ajoute une passerelle par défaut persistante
pour le routeur à  10.10.0.254
avec une valeur de 15. Il faut bien voir
que seul le trafic orienté connexion, tel
que TCP/IP, déclenchera un changement de passerelle par défaut ; le trafic
UDP et ICMP (Internet Control
Message Protocol), tel que Ping, ne le
fera pas. Le fait de définir différentes
passerelles par défaut pour différents
NIC dans un ordinateur « multihomed
» peut causer des problèmes
quand les NIC se connectent à  des réseaux
qui ne peuvent pas communiquer
entre eux. Même quand les passerelles
par défaut sont définies sur des
NIC différents, une seule des passerelles
par défaut d’un ordinateur est active
à  la fois. Pour plus d’informations
sur la configuration des passerelles par
défaut, voir l’article Microsoft « Default
Gateway Configuration for Multihomed
Computers » (http://support.microsoft.
com/?kbid=157025.)
Le protocole IRDP (Internet Router
Discovery Protocol) est encore un
autre moyen de traiter la détection de
passerelles mortes. Les routeurs qui
supportent IRDP utilisent des messages
ICMP pour annoncer leur présence.
Dans Windows NT 4.0, Microsoft
a ajouté le support IRDP, qui est
désactivé par défaut. Vous utilisez les
modifications de registre pour valider
IRDP individuellement pour chaque
NIC, comme décrit dans les
articles Microsoft « Internet
Router Discovery Protocol
(IRDP) Client Support
Added to Windows NT 4.0 »
(http://support.microsoft.
com/?kbid=223756) et
« Router Discovery Protocol
Is Disabled by Default »
(http://support.microsoft.com/?kbid=
269734). Une fois que vous aurez validé
IRDP, la pile de protocoles sera à 
l’écoute des annonces du routeur et
les demandera même, et
les utilisera pour définir
une passerelle par défaut.

Agrégation de liens.
Voilà  plusieurs années, les
fournisseurs de NIC ont
commencé à  proposer des
solutions propriétaires au
problème de la vulnérabilité
du NIC unique. Ces solutions
sont devenues le standard
LACP (Link Aggregation Control
Protocol) IEEE 802.3ad. LACP permet
de multiples connexions commutateur/
commutateur et serveur/commutateur
en parallèle. Vous pouvez utiliser
ce standard – qui porte divers
noms: NIC teaming (équipe de NIC),
port bonding (lien de port) et link aggregation
(agrégation de liens) – pour
configurer des produits de type LACP
pour la tolérance aux pannes, une
bande passante accrue, et l’équilibrage
de charge sur des liens parallèles.
La figure 1 montre le concept de
l’agrégation de liens serveur/commutateur.
Dans cet exemple, quatre ports
NIC sur le serveur se connectent à 
quatre ports d’un commutateur. Le
support de mode statique LACP dans
le driver de NIC et le commutateur
combinent la bande passante des
quatre ports pour obtenir une bande
passante totale égale à  la somme des
vitesses des NIC. Le trafic qui emprunte
les quatre lignes fait l’objet d’un
équilibrage de charge et, quand un lien
est défaillant, l’algorithme d’équilibrage
de charge converge rapidement
pour équilibrer la charge sur les liens
restants. Ce genre de configuration
n’assure pas la tolérance aux pannes
dans le cas d’une défaillance de commutateur.
La figure 2 montre une configuration
serveur/commutateur qui assure
la tolérance aux pannes en cas de défaillance
de commutateur mais ne fournit
pas l’agrégation de liens et l’équilibrage
de charge. Cette configuration
demande que vous validiez le STA
(Spanning Tree Algorithm) dans les
deux commutateurs pour vous assurer
qu’un seul lien est actif à  un moment
donné, empêchant ainsi les paquets de
circuler entre les liens.
La figure 3 montre une configuration
serveur/commutateur qui demande
le support LACP Dynamic
Mode. Comme le serveur a des connexions
avec deux commutateurs, la
configuration offre la tolérance aux
pannes de commutateurs. Le serveur a
de multiples connexions vers chaque
commutateur, et les connexions vers
chaque commutateur sont groupées
(c’est-à -dire mises en équipe). Dans
cette configuration, les connexions en
équipe vers Switch A sont actives, tandis
que les connexions en équipe vers
Switch B restent en mode standby.
LACP fournit l’agrégation de liens,
l’équilibrage de charge, et la tolérance aux pannes, en cas de défaillance des
liens, dans l’équipe active. Dans le cas
d’une défaillance de commutateur,
LACP bascule les communications
sur l’équipe standby connectée au
Switch B.
La figure 4 montre une configurationc
commutateur/commutateur.
Cette configuration supporte un supplément
de bande passante commutateur/
commutateur, d’équilibrage de
charge, et de tolérance aux pannes en
cas de défaillance des liens.

Téléchargez cette ressource

Comment lutter contre le Phishing ?

Comment lutter contre le Phishing ?

Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.

Tech - Par iTPro.fr - Publié le 24 juin 2010