Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Quels problèmes posés par un NAT sur plusieurs liens Internet ?

2 réponses
Avatar
Olivier
Bonjour,

Je travaille sur des système sous Debian Bullseye devant implémenter
la fonction routage vers Internet et NAT pour 100 Í  200 utilisateurs
d'un réseau WiFi.
Pour améliorer les performances et la continuité de service, ces
routeurs seront connectés Í  deux liens FTTH en mode actif-actif.

J'observe que dans sa configuration par défaut, la fonction Equal Cost
Multi Path de Linux s'appuie sur un 5-uplet IP Srce/Dest, Port
Srce/Dest, type de protocole IP pour choisir le lien en sortie.
Choisir avec ce 5-uplet fait, si j'ai bien compris, que le noyau peut,
pour une application comme SIP, faire sortir le flux de signalisation
par le lien n°1, et le flux media par le lien n°2 puisque ces 2 flux
utilisent des ports différents.

On peut considérer que la capacité d'une "application Internet" Í  bien
fonctionner dans un environnement o͹ un utilisateur est simultanément
actif via plusieurs IP publiques distinctes est du ressort de celui
qui met en ligne ces applications. En d'autres termes, Í  charge pour
l'exploitant du service SIP de notre exemple de se débrouiller.

Néanmoins, je serai très intéressé de connaÍ®tre les "utilisations
classiques d'Internet pouvant être mises Í  mal par le passage d'une Í 
plusieurs IP publiques" et de comprendre la raison pour laquelle ces
applications dys-fonctionnent quand on introduit l'ECMP ou quelque
chose d'équivalent.

Connaissez-vous une norme, une étude, un lien qui liste ces
applications perturbées par la répartition de charge ?

Avec mon moteur de recherche, des choses comme "ECMP breaks" ne donne
rien de bien pertinent.

Slts

2 réponses

Avatar
Olivier
À chaud, je pense qu'un algo répartissant le trafic en n'utilisant que
l'IP Source (ie l'IP privée) devrait mieux me convenir: un
utilisateur,
pendant la même session, est toujours vu avec la même IP publique, ce
qui colle assez bien Í  l'utilisation d'Internet avec un CPE classique.
Si l'IP publique change d'une session Í  l'autre, c'est pas grave.
Alternativement, on peut remplacer un routage dynamique par un routage
déterministe qui force pour chaque utilisateur un chemin donné mais ma
question demeure:
quelles sont les applications "fragiles" ou sensibles au load balancing ?
Le lun. 21 mars 2022 Í  10:51, Pierre Malard a écrit :
Salut,
Peut-être un simple problème de route ambiguë !
Le 21 mars 2022 Í  09:47, Olivier a écrit :
Bonjour,
Je travaille sur des système sous Debian Bullseye devant implémenter
la fonction routage vers Internet et NAT pour 100 Í  200 utilisateurs
d'un réseau WiFi.
Pour améliorer les performances et la continuité de service, ces
routeurs seront connectés Í  deux liens FTTH en mode actif-actif.
J'observe que dans sa configuration par défaut, la fonction Equal Cost
Multi Path de Linux s'appuie sur un 5-uplet IP Srce/Dest, Port
Srce/Dest, type de protocole IP pour choisir le lien en sortie.
Choisir avec ce 5-uplet fait, si j'ai bien compris, que le noyau peut,
pour une application comme SIP, faire sortir le flux de signalisation
par le lien n°1, et le flux media par le lien n°2 puisque ces 2 flux
utilisent des ports différents.
On peut considérer que la capacité d'une "application Internet" Í  bien
fonctionner dans un environnement o͹ un utilisateur est simultanément
actif via plusieurs IP publiques distinctes est du ressort de celui
qui met en ligne ces applications. En d'autres termes, Í  charge pour
l'exploitant du service SIP de notre exemple de se débrouiller.
Néanmoins, je serai très intéressé de connaÍ®tre les "utilisations
classiques d'Internet pouvant être mises Í  mal par le passage d'une Í 
plusieurs IP publiques" et de comprendre la raison pour laquelle ces
applications dys-fonctionnent quand on introduit l'ECMP ou quelque
chose d'équivalent.
Connaissez-vous une norme, une étude, un lien qui liste ces
applications perturbées par la répartition de charge ?
Avec mon moteur de recherche, des choses comme "ECMP breaks" ne donne
rien de bien pertinent.
Slts
--
Pierre Malard
| _,,,---,,_
/,`.-'`' -. ;-;;,_
|,4- ) )-,_. , ( `'-'
'---''(_/--' `-'_) πr
perl -e '$_=q#: 3| 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. , ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'_): 24Ï€r::#;y#:#n#;s#(D)(d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
Avatar
NoSpam
Bonjour
ne pas se casser la tête avec NAT/Multi Nat/... et passer en ipv6.
Asterisk y fonctionne très bien.
Le 21/03/2022 Í  09:47, Olivier a écrit :
Bonjour,
Je travaille sur des système sous Debian Bullseye devant implémenter
la fonction routage vers Internet et NAT pour 100 Í  200 utilisateurs
d'un réseau WiFi.
Pour améliorer les performances et la continuité de service, ces
routeurs seront connectés Í  deux liens FTTH en mode actif-actif.
J'observe que dans sa configuration par défaut, la fonction Equal Cost
Multi Path de Linux s'appuie sur un 5-uplet IP Srce/Dest, Port
Srce/Dest, type de protocole IP pour choisir le lien en sortie.
Choisir avec ce 5-uplet fait, si j'ai bien compris, que le noyau peut,
pour une application comme SIP, faire sortir le flux de signalisation
par le lien n°1, et le flux media par le lien n°2 puisque ces 2 flux
utilisent des ports différents.
On peut considérer que la capacité d'une "application Internet" Í  bien
fonctionner dans un environnement o͹ un utilisateur est simultanément
actif via plusieurs IP publiques distinctes est du ressort de celui
qui met en ligne ces applications. En d'autres termes, Í  charge pour
l'exploitant du service SIP de notre exemple de se débrouiller.
Néanmoins, je serai très intéressé de connaÍ®tre les "utilisations
classiques d'Internet pouvant être mises Í  mal par le passage d'une Í 
plusieurs IP publiques" et de comprendre la raison pour laquelle ces
applications dys-fonctionnent quand on introduit l'ECMP ou quelque
chose d'équivalent.
Connaissez-vous une norme, une étude, un lien qui liste ces
applications perturbées par la répartition de charge ?
Avec mon moteur de recherche, des choses comme "ECMP breaks" ne donne
rien de bien pertinent.

--
Daniel