> Tech > Les configurations de multihoming à  équilibrage de charge

Les configurations de multihoming à  équilibrage de charge

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

Il est possible de créer une configuration de multihoming à  équilibrage de charge en spécifiant les routeurs qui annoncent et reçoivent des informations sur certains itinéraires. Par exemple, sur la Figure 5, la société A possède deux itinéraires.
L'itinéraire 192.1.0.0/16 est le plus court entre l'ISP1 et le Routeur 3,

Les configurations de multihoming à  équilibrage de charge

et 130.1.0.0/16
le plus court entre l’ISP1 et le Routeur 4. L’administrateur réseau de A devra
peut-être configurer le Routeur 3 pour qu’il privilégie la liaison de Lyon pour
le trafic entrant en ajoutant une valeur MED plus basse à  l’itinéraire annoncé
par le Routeur 3 au Routeur 1 de Lyon, et une valeur MED plus élevée à  l’itinéraire
annoncé par le Routeur 3 au Routeur 2 de Montpellier.
L’administrateur peut également donner une valeur MED plus basse à  l’itinéraire
annoncé par le Routeur 4 au Routeur 2 de Montpellier et une valeur MED plus élevée
à  l’itinéraire annoncé par le Routeur 4 au Routeur 1 de Lyon. Ainsi, pour le trafic
entrant, la liaison de Lyon servira de liaison primaire pour 192.1.0.0/16 et de
liaison de secours pour 130.1.0.0/16, et la liaison de Montpellier servira de
liaison primaire pour 130.1.0.0/16 et de liaison de secours pour 192.1.0.0/16.

Si des itinéraires spécifiques annoncés par l’ISP sont acceptés par le routeur
Internet, la charge qu’ils génèrent pour le trafic sortant peut être équilibrée.
Par exemple, sur la Figure 5, la société A a un partenaire de commerce électronique
avec un itinéraire court (l’itinéraire 193.1.0.0/16) vers le POP de Lyon de l’ISP1,
et un autre partenaire avec un itinéraire court (itinéraire 11.0.0.0/8) à  destination
du POP de Montpellier de l’ISP1. L’administrateur de la société A peut associer
une valeur LOCAL-PREF plus élevée à  l’itinéraire 193.1.0.0/16 et une valeur LOCAL-PREF
inférieure à  l’itinéraire 11.0.0.0/8 reçu par le Routeur 3 pour faire de la liaison
de Lyon de l’ISP1 la liaison primaire pour 193.1.0.0/16 et la liaison de secours
pour 11.0.0.0/8.
Pour configurer la liaison de Montpellier comme liaison primaire pour 11.0.0.0/8
et comme liaison de secours pour 193.1.0.0/16, il suffit d’inverser ces paramètres
pour les deux itinéraires reçus par le Routeur 4. L’administrateur de la société
A peut en outre paramétrer la liaison de Lyon comme liaison primaire pour l’itinéraire
par défaut (c’est-à -dire tous les autres itinéraires Internet) et la liaison de
Montpellier comme liaison de secours.

Pour équilibrer les charges et ajouter la tolérance de pannes à  une configuration
de multihoming composée de plusieurs connexions à  plusieurs ISP (comme sur la
Figure 6), on utilise les mêmes méthodes que pour les configurations de multihoming
composées de plusieurs connexions à  un seul ISP. Mais il ne faut pas oublier que
l’attribut MED ne fonctionne que dans les cas où un SA se compose de plusieurs
connexions à  un autre SA (autrement dit MED n’est pas transitif). La méthode MED
ne peut donc pas être utilisée lorsque chacun se compose d’une seule liaison avec
plusieurs ISP. Sur la Figure 6, la société A ne possède qu’une connexion avec
chaque ISP et l’administrateur de la société A ne peut donc pas utiliser l’attribut
MED. En revanche, il peut manipuler l’attribut SA-PATH pour annoncer un itinéraire.

Par exemple, pour définir SA1 comme liaison de secours pour 130.1.0.0/16, il peut
créer une valeur SA-PATH bidon en ajoutant 4 à  la valeur 4 SA-PATH normale. Lorsque
le Routeur 3 annonce 130.1.0.0/16, avec une valeur SA-PATH de 4 4 à  SA1, SA1 annonce
l’itinéraire avec une valeur SA-PATH de 1 4 4 à  SA3. Le Routeur 4 annonce 130.1.0.0/16
avec une valeur SA-PATH normale de 4 à  SA2 et SA2 annonce l’itinéraire avec une
valeur SA-PATH de 2 4 à  SA3.

Ainsi, SA3 choisira la liaison SA2 pour le trafic vers 130.1.0.0/16 puisque cet
itinéraire est plus court.
Lorsque vous vous connectez à  plusieurs ISP, bloquez tous les itinéraires établis
par l’ISP, ainsi que leurs itinéraires appris, sauf ceux que vous spécifiez. Sinon,
les ISP risquent de découvrir un chemin plus court vers une autre destination
à  travers votre SA et votre réseau pourrait devenir un SA de transit pour le trafic
entre les ISP.

Téléchargez gratuitement cette ressource

IBMi et Cloud : Table ronde Digitale

IBMi et Cloud : Table ronde Digitale

Comment faire évoluer son patrimoine IBMi en le rendant Cloud compatible ? Comment capitaliser sur des bases saines pour un avenir serein ? Faites le point et partagez l'expertise Hardis Group et IBM aux côtés de Florence Devambez, DSI d'Albingia.

Tech - Par iTPro - Publié le 24 juin 2010