Auteur Sujet: Performance et NAT sur les Box (Lu 6518 fois)

nimbus3d · « **le:** 31 août 2007 à 12:57:14 »

J'attends de pied ferme la freebox optique, car les tests avec la RGW se sont montré très décevant, alors que le max n'était que de 30 mbps... Faire du NAT à des débits pareils, je sens que les freebox n'ont pas finit de rebooter!!! ;o)
A moins que free ne passe en IPv6 pour les fibrés?
Ch.

jyce · « **Réponse #1 le:** 31 août 2007 à 18:55:13 »

La freebox (contrairement a la RGW) peut se mettre en mode passerelle. Du coup il suffit d'utiliser un "vrai" routeur derrière

feyb64 · « **Réponse #2 le:** 01 septembre 2007 à 00:32:39 »

Citation de: nimbus3d le 31 août 2007 à 12:57:14

J'attends de pied ferme la freebox optique, car les tests avec la RGW se sont montré très décevant, alors que le max n'était que de 30 mbps... Faire du NAT à des débits pareils, je sens que les freebox n'ont pas finit de rebooter!!! ;o)
A moins que free ne passe en IPv6 pour les fibrés?
Ch.

Euh

Quel rapport entre IPV6 et le débit ? j'en vois à priori aucun $:-\$

vivien · « **Réponse #3 le:** 01 septembre 2007 à 09:04:00 »

Citation de: feyb64 le 01 septembre 2007 à 00:32:39

Quel rapport entre IPV6 et le débit ? j'en vois à priori aucun $:-\$

Le NAT est une opération gros consommateur de CPU.

Aujourd'hui les constructeurs sont obligé de mettre des accélérateurs sinon le débit est bien moindre ( inférieur a 20 Mb/s) : Lorsque l'utilisateur lance un téléchargement TCP/UDP, les premiers paquets qui sont responsables de l'établissement de la connexion passent par le CPU (chemin classique :NAT/FIREWALL/policies...), une fois le lien est établie tous les prochains paquets passeront par les accélérateurs (chemin rapide). Les accélérateurs n'analyse que l'entête TCP/IP du paquet et pas son contenue.

Sur la plupart des box il y a 2 ports sur lequel les accélérateurs sont désactivés afin d'ouvrir les ports a la volé : le port 20 pour le FTP et le port 1683 pour MSN. Sans cette ouverture, pas de conversation audio / vidéo sans ouvrir de port et pas de FTP actif. Je suis a votre disposition pour faire un test sur ces 2 ports avec IPERF. (note : cas spécifique de la Neuf Box 4 en FTTH : il semble impossible de faire du FTP actif donc ils est probable que le port 20 soit full speed)

Tout ceci c'est en IPv4 car en IPv6, chaque utilisateur dispose d'une classe d'adresse public donc le nat n'est pas nécessaire.

Vivien.

feyb64 · « **Réponse #4 le:** 01 septembre 2007 à 15:03:00 »

Citation de: vivien le 01 septembre 2007 à 09:04:00

Le NAT est une opération gros consommateur de CPU.

Aujourd'hui les constructeurs sont obligé de mettre des accélérateurs sinon le débit est bien moindre ( inférieur a 20 Mb/s) : Lorsque l'utilisateur lance un téléchargement TCP/UDP, les premiers paquets qui sont responsables de l'établissement de la connexion passent par le CPU (chemin classique :NAT/FIREWALL/policies...), une fois le lien est établie tous les prochains paquets passeront par les accélérateurs (chemin rapide). Les accélérateurs n'analyse que l'entête TCP/IP du paquet et pas son contenue.

Sur la plupart des box il y a 2 ports sur lequel les accélérateurs sont désactivés afin d'ouvrir les ports a la volé : le port 20 pour le FTP et le port 1683 pour MSN. Sans cette ouverture, pas de conversation audio / vidéo sans ouvrir de port et pas de FTP actif. Je suis a votre disposition pour faire un test sur ces 2 ports avec IPERF. (note : cas spécifique de la Neuf Box 4 en FTTH : il semble impossible de faire du FTP actif donc ils est probable que le port 20 soit full speed)

Tout ceci c'est en IPv4 car en IPv6, chaque utilisateur dispose d'une classe d'adresse public donc le nat n'est pas nécessaire.

Vivien.

Certe pour la plage 'ip' publique en ipv6, mais reste que les règles de firewall/policies sont certainement les plus consommatrices (tests de validité, ...) et changer juste l'ip dans les paquets pour la translation d'adresses (nat) est bien moins consommateur qu'eux ...
Pour palier ce problème 'général', il suffit de mettre une cpu plus puissante dans le routeur car c'est l'augmentation du débit sur la ligne qui fait que ces opérations nat/règles de firewall/... sont à la traîne, pas le fait de leur existance en soit.

Passer en ipv6 ne changera pas grand chose à mon avis sur les routeurs actuels car il faudra toujours ces règles de sécurité/firewall dans le routeur (je vois mal laisser la seule protection aux pc finaux, surtout pour le user lambda qui n'y connais rien. en tout cas c'est pas rendre service à la communauté internet mais plutôt aux spammers/pirates/... )

jyce · « **Réponse #5 le:** 01 septembre 2007 à 15:35:06 »

L'encapsulation PPP aussi (dans le cas de citéfibre) bouffe pas mal de ressources.
D'ailleurs, j'ai pas compris l'interet de faire du PPP sur du FTTH.

vivien · « **Réponse #6 le:** 01 septembre 2007 à 15:50:37 »

Citation de: jyce le 01 septembre 2007 à 15:35:06

L'encapsulation PPP aussi (dans le cas de citéfibre) bouffe pas mal de ressources.
D'ailleurs, j'ai pas compris l'interet de faire du PPP sur du FTTH.

Se compliquer la vie... ce n'est pas un bon argument ?

Ce n'est même nécessaire pas pour différencier le flux des différents opérateurs palois sur le PBC car le DHCP peut attribuer une adresse par port Atrica et donc une passerelle spécifique. Atrica permet de ne laisser passer que cette ip (pas d'usurpation d'ip possible) Donc on pouvais trés bien différencier PauOnline et MédiaFibre par leur passerelles respectives.

Je suis toujours dans l'incompréhension du choix de PPP qui entraîne aussi une fragmentation des paquets IP et donc une baisse du débit pour les machines non optimisées.

De plus ces octets pris par PPP diminue le débit. C'est pour cette raison que citéFibre provisionne 31 Mb/s pour que les abonnés aient réellement 30 Mb/s.

feyb64 · « **Réponse #7 le:** 01 septembre 2007 à 17:07:42 »

Ca s'appelle "Pourquoi faire simple quand on peut faire compliqué "

Surtout qu'en plus il y a déjà les vlan par flux qui en soit rendent les réseaux virtuellement indépendants.

Solution simple : on attribue 1 N° vlan par FAI et par application (sur le pbc 3 flux : data, voip, tvip soit 3 vlan à attribuer par fai), point.
Les switchs finaux 'abonnés' sont alors configurés à l'abonnement pour que le port x sur lequel l'abonné est branché ne 'route' que les 3 vlan de son fai, donc même si il y a un malin qui tente de changer ces vlans de son côté (mise en place d'un pc en lieu et place du routeur abonné) il ne pourra pas aller plus loin que le port du switch juste en amont sur le réseau.
Point de 'ppp', juste quelques octets de tags vlan à rajouter, qui peuvent être hors de la frame ethernet classique de 1500 octets avec des matos acceptant les 'long frames', donc pas de 'perte' non plus en terme de mtu.

Autre solution : réseau de type mpls, le taguing 'mpls' (super vlan) n'empêche pas de refaire du vlan classique en dessous. Donc le FAI se voit juste attribué un unique tag mpls, il choisi ou non de créer des vlans classiques pour différencier ses flux comme il l'entend.

vivien · « **Réponse #8 le:** 01 septembre 2007 à 17:17:39 »

Citation de: feyb64 le 01 septembre 2007 à 17:07:42

Solution simple : on attribue 1 N° vlan par FAI et par application (sur le pbc 3 flux : data, voip, tvip soit 3 vlan à attribuer par fai), point.
Les switchs finaux 'abonnés' sont alors configurés à l'abonnement pour que le port x sur lequel l'abonné est branché ne 'route' que les 3 vlan de son fai, donc même si il y a un malin qui tente de changer ces vlans de son côté (mise en place d'un pc en lieu et place du routeur abonné) il ne pourra pas aller plus loin que le port du switch juste en amont sur le réseau.

Pas possible avec la version Atrica déployé. (je ne connais pas la dernière, je crois que cette limite est levée) Il faut un vlan par service ET par client au niveau du réseau Atrica et par utilisateurs. Cela impose 6 vlan par utilisateurs triple play (data + Vidéo a la demande + VoIP) L'ensemble étant sécurisé cela fait 3 +3. Les 2 vlan multicast sont commun a tous les clients. Comme on est limité a 2000 Vlan, il faut dupliquer les équipements de terminaison tous les 333 clients.

feyb64 · « **Réponse #9 le:** 01 septembre 2007 à 17:44:27 »

Citation de: vivien le 01 septembre 2007 à 17:17:39

Pas possible avec la version Atrica déployé. (je ne connais pas la dernière, je crois que cette limite est levée) Il faut un vlan par service ET par client au niveau du réseau Atrica et par utilisateurs. Cela impose 6 vlan par utilisateurs triple play (data + Vidéo a la demande + VoIP) L'ensemble étant sécurisé cela fait 3 +3. Les 2 vlan multicast sont commun a tous les clients. Comme on est limité a 2000 Vlan, il faut dupliquer les équipements de terminaison tous les 333 clients.

Ormis le pb de 'version', avec 2000 vlan possibles celà en fait des FAI ...
Je ne comprend pas ton histoire de "6 vlan par utilisateur" ? pourquoi donc ? En plus ce n'est pas vrai sur le PBC, on est tous sur les mêmes vlan ...
Et je ne vois pas l'intérêt du 'sécurisé' ... il n'y a pas de raisons qu'un n° de vlan ne passe pas et l'autre oui à part une erreur de config ... et en plus nous rgw sont 'fixées' sur trois seuls numéros, elles vont pas chercher autre chose ...

vivien · « **Réponse #10 le:** 01 septembre 2007 à 18:01:00 »

Citation de: feyb64 le 01 septembre 2007 à 17:44:27

Ormis le pb de 'version', avec 2000 vlan possibles celà en fait des FAI ...
Je ne comprend pas ton histoire de "6 vlan par utilisateur" ? pourquoi donc ? En plus ce n'est pas vrai sur le PBC, on est tous sur les mêmes vlan ...
Et je ne vois pas l'intérêt du 'sécurisé' ... il n'y a pas de raisons qu'un n° de vlan ne passe pas et l'autre oui à part une erreur de config ... et en plus nous rgw sont 'fixées' sur trois seuls numéros, elles vont pas chercher autre chose ...

Au niveau des RGW elles voient 3 vlan mais au niveau du réseau il faut un vlan data qui passe dans un sens un autre dans l'autre sens afin que si la boucle de switch se coupe les connexions soient reroutées. Je parle au niveau réseau pas au niveau des RGW où il n'y a que 3 VLAN, toujours les même N°.

Chaque abonné a son propre N° de VLAN data sur le réseau qui lui donne par exemple un certain débit max (les offres de Pauonline ne sont pas toutes au même débit, désolé pour l'exemple je n'ai que ca en tête)

La problématique de sécurité c'est pour le DHCP, d'empécher qu'un abonné puisse prendre l'IP d'un autre puisqu'en mode DHCP (pour rappel utilisé pour la vidéo à la demande et pour la VoIP) on se croit sur un réseau local avec un masque par exemple 255.255.255.0 Il ne faut donc pas que si l'abonné force lui même son IP que le flux puissse sortir.