TiChou a écrit :
>
> Dans l'hébergement Web on utilise beaucoup le multihoming.

Pourrais-tu préciser ? Je comprends bien l'utilité pour un hébergeur
d'avoir plusieurs liens internet, mais quelle est l'utilité qu'un
serveur ait des adresses IP multiples ?

[Copie dans fr.comp.reseaux.ip, avec proposition de continuer là-bas.
Répondre dans un seul forum de préférence.]

Pascal@plouf wrote:

> TiChou a écrit :
>>
>> Dans l'hébergement Web on utilise beaucoup le multihoming.
>
> Pourrais-tu préciser ? Je comprends bien l'utilité pour un hébergeur
> d'avoir plusieurs liens internet, mais quelle est l'utilité qu'un
> serveur ait des adresses IP multiples ?

Mise à part pour le référencement google, je ne vois pas trop

amicalement,

--
Christophe Casalegno | Groupe Digital Network | UIN : 153305055
http://www.digital-network.net | http://www.securite-reseaux.com
TISTC | OFREMHI | IIHEC | IICRAI | CIRET-AVT | KESAC | TIIX
Technical director | Security Intrusion techniques & infowar specialist.

Pascal@plouf a écrit :
> TiChou a écrit :
>
>>
>> Dans l'hébergement Web on utilise beaucoup le multihoming.
>
>
> Pourrais-tu préciser ? Je comprends bien l'utilité pour un hébergeur
> d'avoir plusieurs liens internet, mais quelle est l'utilité qu'un
> serveur ait des adresses IP multiples ?
>

Un interet est d'avoir de la redondance (au sens haute disponibilité) au
niveau des operateurs sans aller jusqu'à gérer un numero d'AS et du BGP.

En l'occurence avec deux IPs sur la meme machine, correspondant à deux
operateurs distincts, on peut déjà avoir un petit failover en utilisant
juste du round robin DNS.

--
J1

J1 wrote:

> Un interet est d'avoir de la redondance (au sens haute disponibilité) au
> niveau des operateurs sans aller jusqu'à gérer un numero d'AS et du BGP.
>
> En l'occurence avec deux IPs sur la meme machine, correspondant à deux
> operateurs distincts, on peut déjà avoir un petit failover en utilisant
> juste du round robin DNS.

En effet, cependant dans le cas d'un balancing dns, il y a un temps de
propagation à prévoir si l'on est pas sur le meme réseau (on ne peut pas se
contenter d'aliaser l'ip ou alors il faut prévoir un bouncer).

En termes de coûts, je pense qu'il est plus intéressant de prendre du réseau
multiop et de demander par exemple une double alimentation IP.

amicalement,

--
Christophe Casalegno | Groupe Digital Network | UIN : 153305055
http://www.digital-network.net | http://www.securite-reseaux.com
TISTC | OFREMHI | IIHEC | IICRAI | CIRET-AVT | KESAC | TIIX
Technical director | Security Intrusion techniques & infowar specialist.

Christophe Casalegno a écrit :
>>En l'occurence avec deux IPs sur la meme machine, correspondant à deux
>>operateurs distincts, on peut déjà avoir un petit failover en utilisant
>>juste du round robin DNS.
>
>
> En effet, cependant dans le cas d'un balancing dns, il y a un temps de
> propagation à prévoir si l'on est pas sur le meme réseau (on ne peut pas se
> contenter d'aliaser l'ip ou alors il faut prévoir un bouncer).
>
> En termes de coûts, je pense qu'il est plus intéressant de prendre du réseau
> multiop et de demander par exemple une double alimentation IP.
>

Soit, tout dépend alors des tarifs négociés.
On peut aussi envisager un site demandant une haute disponibilité et
proposant également des téléchargements pour lesquels la disponibilité
ne serait pas le facteur le plus pondérant.

On pourra alors avoir une IP pour le site en lui même, avec de la bande
passante multiop, et une autre IP pour le telechargement de binaires,
avec de la bande passante à pas cher, avec un cout au Mbit beaucoup
moins elevé. Le tout sur un seul serveur.

Je pense que les possibilités offertes par les aliases IP sont vraiment
nombreuses.

--
J1

"Pascal@plouf" wrote in message <dfp7d8$15ls$1@biggoron.nerim.net>:
> Pourrais-tu préciser ? Je comprends bien l'utilité pour un hébergeur
> d'avoir plusieurs liens internet, mais quelle est l'utilité qu'un
> serveur ait des adresses IP multiples ?

Pour servir plusieurs sites web avec le même matériel, ça peut être utile.
Le name-based virtual hosting marche pas mal, mais les extensions pour TLS
sont encore mal supportées, il me semble.

> [Copie dans fr.comp.reseaux.ip, avec proposition de continuer là-bas.
> Répondre dans un seul forum de préférence.]

Je ne le lis pas régulièrement. Je donne ma réponse comme ça...

Nicolas George a écrit :
> "Pascal@plouf" wrote in message <dfp7d8$15ls$1@biggoron.nerim.net>:
>
>>Pourrais-tu préciser ? Je comprends bien l'utilité pour un hébergeur
>>d'avoir plusieurs liens internet, mais quelle est l'utilité qu'un
>>serveur ait des adresses IP multiples ?
>
> Pour servir plusieurs sites web avec le même matériel, ça peut être utile.

Certes, mais ça n'est plus lié au multihoming.

> Le name-based virtual hosting marche pas mal,

Oui, sauf pour les navigateurs antédiluviens qui ne sont pas compatibles
HTTP/1.1.

> mais les extensions pour TLS sont encore mal supportées, il me semble.

Je m'y connais pas grand chose mais d'après ce que j'ai compris il faut
une correspondance entre le certificat et l'adresse IP, donc
effectivement une adresse IP par site est nécessaire.

Pascal@plouf a écrit(wrote):
> TiChou a écrit :
>>
>> Dans l'hébergement Web on utilise beaucoup le multihoming.
>
> Pourrais-tu préciser ? Je comprends bien l'utilité pour un hébergeur
> d'avoir plusieurs liens internet, mais quelle est l'utilité qu'un
> serveur ait des adresses IP multiples ?
>

Une raison simple est de pouvoir gérer plusieurs sites en SSL(HTTPS) sur
la même machine. En effet, le SSL impose que la connexion soit
entièrement chiffrée et authentifiée. De ce fait le serveur doit pouvoir
savoir quel est le certificat à présenter sans avoir accès aux entêtes
HTTP aui seront transmises plus tard dans la transaction et qui peuvent
contenir le nom du site (ce qui aurait permis de savoir quel est le bon
certificat). On associe une IP à un nom de domaine unique et on crée un
certificat pour ce nom de domaine. Une connexion HTTPS sur un serveur
qui héberge plusieurs sites se déroule alors comme suit (en simplifiée).

1) Établissement d'une connexion TCP et le serveur sur une adresse (IP1)
qui a été obtenu en résolvant le nom qualifié du site (par exemple
www.site1.com) sur le port qui va bien (en général 443).
2) Établissement d'un canal chiffré au dessus de la connexion TCP.
3) Le serveur s'identifie auprès du client, il envoit un certificat
ayant pour objet www.site1.com et une preuve qu'il le possède.
4) Éventuellement le client s'authentifie de la même manière.
5) le dialogue HTTP classique commence (demande d'une page du site
www.site1.com)
6) D'autre étape HTTP ou de réauthentification SSL peuvent avoir lieu.
7) Fin de session SSL
8) Fin de session TCP

Durant l'étape 3 le seul moyen dont dispose le serveur pour trouver le
bon certificat à envoyer est l'IP sur laquelle le client est connecté
qui est associée à un nom et donc à un certificat.


Bon, bien sûr, un jour les navigateurs et les serveurs sauront gérés la
RFC 2817 et le monde sera plus beau... puisqu'on tout vers avec une IP
et un port)

> [Copie dans fr.comp.reseaux.ip, avec proposition de continuer là-bas.
> Répondre dans un seul forum de préférence.]


--
Julien

J1 a écrit :
>>>
>>> Dans l'hébergement Web on utilise beaucoup le multihoming.
>>
>> Pourrais-tu préciser ? Je comprends bien l'utilité pour un hébergeur
>> d'avoir plusieurs liens internet, mais quelle est l'utilité qu'un
>> serveur ait des adresses IP multiples ?
>
> Un interet est d'avoir de la redondance (au sens haute disponibilité) au
> niveau des operateurs sans aller jusqu'à gérer un numero d'AS et du BGP.

D'accord mais si les deux IP appartiennent à deux opérateurs différents,
elles ont peu de chance d'appartenir au même sous-réseau IP. Or la
remarque de Tichou était en réponse à mon affirmation (peut-être un peu
hâtive) selon laquelle le plus souvent les alias IP appartiennent à des
sous-réseaux différents.

Arrêtez-moi si je dis une connerie, mais il me semble qu'en matière de
réseau multihomé il y a deux cas :
- le réseau a son propre AS et routage BGP et les mêmes adresses sont
routées par tous les liens, donc pas besoin d'alias IP.
- le réseau n'est pas autonome et des adresses différentes sont routées
sur chaque lien ; dans ce cas une machine a un alias IP par lien, et ces
adresses ne sont pas dans le même sous-réseau.

> En l'occurence avec deux IPs sur la meme machine, correspondant à deux
> operateurs distincts, on peut déjà avoir un petit failover en utilisant
> juste du round robin DNS.

Autant je conçois le round robin DNS pour faire de l'équilibrage de
charge, autant j'ai un doute sur son utilisation pour faire de la
redondance. Tous les programmes clients essaient-ils vraiment toutes les
adresses IP en cas d'échec ? Le client telnet de Windows ne le fait pas.
Et quand ils le font, n'est-ce pas après un délai interminable ? C'est
le cas de Firefox sous Windows. Et comme le resolver dudit Windows
ressert les adresses toujours dans le même ordre une fois les données
dans le cache DNS, le résultat est loin d'être génial quand c'est
l'adresse en première position qui est HS.

Pascal@plouf a écrit :
> D'accord mais si les deux IP appartiennent à deux opérateurs différents,
> elles ont peu de chance d'appartenir au même sous-réseau IP. Or la
> remarque de Tichou était en réponse à mon affirmation (peut-être un peu
> hâtive) selon laquelle le plus souvent les alias IP appartiennent à des
> sous-réseaux différents.
>
> Arrêtez-moi si je dis une connerie, mais il me semble qu'en matière de
> réseau multihomé il y a deux cas :
> - le réseau a son propre AS et routage BGP et les mêmes adresses sont
> routées par tous les liens, donc pas besoin d'alias IP.
> - le réseau n'est pas autonome et des adresses différentes sont routées
> sur chaque lien ; dans ce cas une machine a un alias IP par lien, et ces
> adresses ne sont pas dans le même sous-réseau.


Tout à fait d'accord. Je n'avais pas lu le début du thread sur fcolc,
mea culpa.


>> En l'occurence avec deux IPs sur la meme machine, correspondant à deux
>> operateurs distincts, on peut déjà avoir un petit failover en utilisant
>> juste du round robin DNS.

^^^^^

> Autant je conçois le round robin DNS pour faire de l'équilibrage de
> charge, autant j'ai un doute sur son utilisation pour faire de la
> redondance. Tous les programmes clients essaient-ils vraiment toutes les
> adresses IP en cas d'échec ? Le client telnet de Windows ne le fait pas.
> Et quand ils le font, n'est-ce pas après un délai interminable ? C'est
> le cas de Firefox sous Windows. Et comme le resolver dudit Windows
> ressert les adresses toujours dans le même ordre une fois les données
> dans le cache DNS, le résultat est loin d'être génial quand c'est
> l'adresse en première position qui est HS.


Effectivement, tests à l'appui le résultat est loin d'être optimal, et
même franchement médiocre :-(
Ceci dit c'est surtout la faute du resolver :
client windows = failover operationel à 0% si une adresse est HS
client linux : failover operationel à ((1 - 1/n)*100) %

Alors rectification : on peut avoir la traitresse illusion d'un failover
en utilisant du round robin DNS.

--
J1

Julien Salgado a écrit :
>>Arrêtez-moi si je dis une connerie, mais il me semble qu'en matière de
>>réseau multihomé il y a deux cas :
>>- le réseau a son propre AS et routage BGP et les mêmes adresses sont
>>routées par tous les liens, donc pas besoin d'alias IP.
>
> Oui.

+1


>>- le réseau n'est pas autonome et des adresses différentes sont routées
>>sur chaque lien ; dans ce cas une machine a un alias IP par lien, et ces
>>adresses ne sont pas dans le même sous-réseau.
>
> Et c'est vite un bazar en terme de routage, on se retrouve avec du
> routage asymmétrique, du source routing...


Je n'ai encore jamais mis en production ce genre de solution, mais une
fois le source routing mis en place, où sont le bazar et le routage
asymétrique?


> en faic'est un mauvais choix
> de ne pas créer un aire spécifique pour les serveurs et de repousser le
> multihoming opérateur sur une zone de routage pur (et on se retrouve
> dans le cas 1 )


Un exemple illustrant les problèmes dus au "mauvais choix" serait le
bienvenu pour eclairer ma lanterne :-)


--
J1, intrigué

Julien Salgado wrote:

> Une raison simple est de pouvoir gérer plusieurs sites en SSL(HTTPS) sur

On est dans ce cas là dans le cas d'un seul fournisseur. Cela ne nécessite
pas des ips appartenant à des fournisseurs différents.

amicalement,

--
Christophe Casalegno | Groupe Digital Network | UIN : 153305055
http://www.digital-network.net | http://www.securite-reseaux.com
TISTC | OFREMHI | IIHEC | IICRAI | CIRET-AVT | KESAC | TIIX
Technical director | Security Intrusion techniques & infowar specialist.

Dans le message <news:slrndi1b5f.d5r.Julien.Salgado@chez.moi>,
*Julien Salgado* tapota sur f.c.r.ip :

>>> Dans l'hébergement Web on utilise beaucoup le multihoming.
>>
>> Pourrais-tu préciser ? Je comprends bien l'utilité pour un hébergeur
>> d'avoir plusieurs liens internet, mais quelle est l'utilité qu'un
>> serveur ait des adresses IP multiples ?

> Une raison simple est de pouvoir gérer plusieurs sites en SSL(HTTPS) sur
> la même machine.

Le SSL est bien évidement le cas le plus fréquent et l'explication qui a été
donné ici démontre bien les besoins en multihoming pour ce cas précis.

Sinon, un ami qui travaille dans l'hébergement, me faisait remarquer qu'il y
a des clients qui ont des exigences particulières, comme par exemple de
pouvoir accéder à leur site sans nom de domaine associé. Il me disait que
c'est plus spécifique mais que ça existe.
Un autre exemple moins spécifique, c'est les clients qui désirent faire
tourner différents services sur des adresses IP bien distinctes. En effet,
il n'est pas rare d'avoir des serveurs dédiés qui hébergent sur la même
machine serveur Web, serveur DNS et serveur mail.
Un dernier exemple plus atypique ou anecdotique, c'est les (vieux) serveurs
ne faisant que du HTTP/1.0 où le virtual hosting ne peut se faire qu'avec du
multihoming. D'une manière générale tous les services ne pouvant faire du
virtual hosting que par le multihoming.

--
TiChou

J1 a écrit :
>
> Tout à fait d'accord. Je n'avais pas lu le début du thread sur fcolc,
> mea culpa.

C'est ma faute aussi, j'ai importé la discussion ici sans reprendre tous
les éléments.

>> Autant je conçois le round robin DNS pour faire de l'équilibrage de
>> charge, autant j'ai un doute sur son utilisation pour faire de la
>> redondance. Tous les programmes clients essaient-ils vraiment toutes
>> les adresses IP en cas d'échec ? Le client telnet de Windows ne le
>> fait pas. Et quand ils le font, n'est-ce pas après un délai
>> interminable ? C'est le cas de Firefox sous Windows. Et comme le
>> resolver dudit Windows ressert les adresses toujours dans le même
>> ordre une fois les données dans le cache DNS, le résultat est loin
>> d'être génial quand c'est l'adresse en première position qui est HS.
>
> Effectivement, tests à l'appui le résultat est loin d'être optimal, et
> même franchement médiocre :-(
> Ceci dit c'est surtout la faute du resolver :

Pas uniquement, le client a aussi sa part de responsabilité. Par exemple
le client Telnet de Linux essaie rapidement toutes les adresses (à
condition qu'un ICMP destination unreachable soit retourné), donc la
position de l'adresse HS dans la réponse du resolver n'a pas trop
d'importance. En comparaison, Firefox sous Windows met beaucoup plus de
temps à basculer sur l'adresse suivante. En fait c'est peut-être plus dû
à la pile TCP/IP qu'à l'application.

> client windows = failover operationel à 0% si une adresse est HS
> client linux : failover operationel à ((1 - 1/n)*100) %

A quoi correspond exactement ce pourcentage ?

TiChou a écrit :
>
> Le SSL est bien évidement le cas le plus fréquent et l'explication qui a
> été donné ici démontre bien les besoins en multihoming pour ce cas précis.

J'allais te demander quel est le rapport entre SSL et multihoming et je
viens de me rendre compte que le terme "multihoming" a deux
significations bien différentes :
- plusieurs adresses IP (synonyme d'alias)
- plusieurs liens

Visiblement tu emploies la première alors que je ne pensais qu'à la
seconde. Misère...

Pascal@plouf a écrit(wrote):
> Julien Salgado a écrit :
>> Pascal@plouf a écrit(wrote):
>>
>>>- le réseau n'est pas autonome et des adresses différentes sont routées
>>>sur chaque lien ; dans ce cas une machine a un alias IP par lien, et ces
>>>adresses ne sont pas dans le même sous-réseau.
>>
>> Et c'est vite un bazar en terme de routage, on se retrouve avec du
>> routage asymmétrique, du source routing... en faic'est un mauvais choix
>> de ne pas créer un aire spécifique pour les serveurs et de repousser le
>> multihoming opérateur sur une zone de routage pur (et on se retrouve
>> dans le cas 1 )
>
> Plusieurs questions me viennent à l'esprit en réponse à ton commentaire.
>
> 1) Pourquoi du routage asymétrique dans ce cas de figure puisque le flux
> correspondant à une adresse locale passe forcément par le même lien dans
> les deux sens ?

Par routage j'entend bien chemin de routage, que cela passe par le même
support physique est une autre chose...
Si je considère un serveur connecté à un switch, lui même connecté à
deux routeurs connectés à un autre routeur d'un opérateur distinct.
Si je positionne une route par défaut elle doit aller vers un des
routeurs, correspondant à l'un des opérateurs. Maintenant si on fait un
simple ping de puis le routeur situé chez l'autre opérateur, alors le
paquet de routeur va passer par l'autre operateur pour finalement
arriver chez l'opérateur original. Bien sûr je peux mettre un route sur
le serveur... en fait sur tous les serveurs...

> Le routage asymétrique n'est-il pas au contraire plus fréquent dans un
> réseau autonome, dans la mesure où les paquets d'un même flux peuvent
> indifféremment sortir par un lien et entrer par un autre ?

J'ai jammais fait de statistique... mais je ne suis pas contre le
routage assymétrique, mais contre le fait de l'utiliser là où il apporte
des difficulités d'administration et de gestion d'indicident/debug.
Dans le cas de l'exemple, on se retrouve à faire plein de configuration
si on a plusieurs serveurs.

>
> 2) Comme d'autres personnes tu emploies l'expression "source routing"
> pour désigner une politique de routage basée sur l'adresse source.
> N'est-ce pas un abus de langage ?

Oui. Je suis pris en flagrant délit

> Il me semblait que "source routing" désignait une option du protocole
> IP qui permet à l'émetteur de spécifier dans l'en-tête d'un datagramme
> IP la liste des routeurs à emprunter pour arriver à destination
> (routage défini par la source).
>
> 3) Qu'entends-tu par "créer un aire spécifique pour les serveurs" et
> "repousser le multihoming opérateur sur une zone de routage pur" ?

Pour reprendre l'exemple précédant, je rajouterai un routeur au dessus
du (des) serveur(s) qui gérerait (éventuellement les routes vers
l'extérieur. On aurait deux «zones», une zone d'hégergement où
seraient les serveurs (la politique de routage serait purement interne
ou dirigée vers le nouveau routeur pour la sortie) et un zone de sortie
vers qui pourrait recevoir plusieurs opérateurs (toute l'administration
du routage extérieur serait faite seulement dans cette zone sans impact
sur l'autre zone).

Bon, bien sûr ce n'est qu'un exemple dans un cas quand même particulier.



--
Julien

Pascal@plouf a écrit :
>> Ceci dit c'est surtout la faute du resolver :
>
> Pas uniquement, le client a aussi sa part de responsabilité. Par exemple
> le client Telnet de Linux essaie rapidement toutes les adresses (à
> condition qu'un ICMP destination unreachable soit retourné), donc la
> position de l'adresse HS dans la réponse du resolver n'a pas trop
> d'importance.


Du moins tant que l'on reçoit les messages d'erreur ICMP et que les
paquets ne sont pas simplement droppés/perdus.


> En comparaison, Firefox sous Windows met beaucoup plus de
> temps à basculer sur l'adresse suivante. En fait c'est peut-être plus dû
> à la pile TCP/IP qu'à l'application.
>
>> client windows = failover operationel à 0% si une adresse est HS


C'est faux ça. C'est à priori le même pctage que ci dessous.
Sur mon poste windows, IE, Firefox et mozilla accèdent tous à
la même IP et ne basculent jamais sur l'IP suivante.
Sans doute parceque j'ai fait mes tests avec une ip non attribuée pour
laquelle les réponses "Destination Host Unreachable" n'arrivent pas
jusqu'à mon poste.

Il faudrait quelques recherches supplémentaires pour ne pas avoir des
résultats trop empiriques.


>> client linux : failover operationel à ((1 - 1/n)*100) %
>
> A quoi correspond exactement ce pourcentage ?


Si le resolver répond "en round robin" (c'est le cas sur mon poste sous
linux), la probabilité de tomber sur une ip down est de

(le nombre d'ips down)/(le nombre d'ips du round robin)


En pratique pour faire baisser ce pourcentage, il faut augmenter le
nombre d'ips du round robin et baisser le nombre d'ips down : avoir un
nombre important d'operateurs IPs est réélement très couteux.

Le round robin DNS ne semble vraiment pas être une solution
satisfaisante pour de la haute disponibilité, surtout en comparaison
avec du BGP.

--
J1