Dépannage du faible débit TCP Ethernet métropolitain

La mise en place

Nous avons loué quelques lignes louées qui se présentent comme un réseau de couche 2, c'est-à-dire que vous avez un gros tuyau au centre de données et que les sites distants ont des tuyaux plus petits. À l'intérieur du réseau de couche 2, vous pouvez faire ce que vous voulez. Ils utilisent probablement 802.1ad pour donner à chaque client leur réseau distinct à l'intérieur de leur réseau. AFAICS la plupart des sites sont connectés via VDSL simple.

Nous avons décidé de mettre un routeur sur chaque site et de donner à chaque site son propre VLAN. Le pare-feu au niveau du contrôleur de domaine a donc autant de VLAN définis qu'il y a de sites. Chaque site utilise ainsi sa plage d'adresses dans son propre VLAN.

Diagramme du réseau:

Le problème

Maintenant, nous sommes confrontés à des problèmes de débit:

• L'exécution d'un transfert FTP du site au contrôleur de domaine fonctionne correctement à environ 10 Mo / s, ce qui correspond à la vitesse de la ligne.
• L'exécution d'un transfert FTP de DC vers le site ne fonctionne pas correctement à 6 Mo / s ou moins.

Peu importe de quel côté initie le transfert. La seule chose cohérente est qu'une direction ne fonctionne pas bien. Dommage, c'est la direction vers le site car ce serait la bande passante dont nous avons le plus besoin car nous aimerions utiliser des clients Terminal Server.

Environ 10 secondes après le transfert, le débit baisse. Nous voyons les accusés de réception DUP lors du reniflement. Ce qui m'amène peut-être à limiter les tarifs chez le fournisseur ?? (Actuellement, ils n'ont pas la moindre idée, et j'aime m'assurer que nous ne sommes pas en faute avant d'escalader)

REMARQUE Les sites distants sont limités à 10 Mo en quelque sorte. La définition du commutateur vers le port Metro sur 10 Mo n'aide pas non plus. En fait, c'est le pire (30 Ko / s max.). La définition de 100 Mo fonctionne correctement mais commence déjà à produire le problème décrit. Idem pour 1G.

Des captures du problème peuvent être téléchargées ici:

* http://178.63.11.6/dc-to-remote_dc-side.pcapng
* http://178.63.11.6/dc-to-remote_remote-side.pcapng

Diagnostique

Dans l'image, vous voyez le graphique d'E / S Wireshark avec quelques détails d'erreur:

• à gauche: transfert FTP du DC au site
• à droite: transfert FTP du site vers DC

Dans le cas où l'autre côté lance le transfert (c'est-à-dire mettre à partir de dc, au lieu de récupérer à distance), le problème reste inchangé.

Veuillez me faire plaisir avec ce que vous pensez être le problème ici.

MISE À JOUR # 1 (intégrée ci-dessus)

MISE À JOUR # 2 ( MISE À JOUR )

Cela doit être un contrôle de congestion.

Notez que de DC à distant, nous avons des liaisons 10G-> 1G-> 100M-> 10M-> 1G. <- ne fonctionne pas

Dans l'autre sens, nous avons donc l'inverse: 1G-> 10M-> 100M-> 1G-> 10G. <- très bien

Le premier "1G-> 10M" est le 10M "invisible" sur le site distant, où tout, y compris la vitesse du port de liaison montante est réglé sur 1G, même s'il n'y a que 10M derrière (vendu).

Cependant, les 100 Mbps au DC sont de 100 Mbps réels, l'interface est configurée à 100 Mbps sur la couche physique.

J'ai maintenant utilisé iperf:

• Les tests TCP fonctionnent correctement dans une seule direction (client = DC, serveur = distant)

./iperf -c 192.168.x -i2 -t 60 -r
-------------------------------------------------- ----------
Écoute du serveur sur le port TCP 5001
Taille de la fenêtre TCP: 85,3 Ko (par défaut)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client se connectant à 192.168.x, port TCP 5001
Taille de la fenêtre TCP: 16,0 Koctets (par défaut)
-------------------------------------------------- ----------
[3] port local 10.x 38195 connecté au port 192.168.x 5001
[3] 0,0 à 2,0 s 1,44 Mo 6,03 Mbits / s
[3] 2,0 à 4,0 s 2,23 Mo 9,37 Mbits / s
[3] 4,0 à 6,0 s 2,28 Mo 9,57 Mbits / s
[3] 6,0 - 8,0 sec 1,88 Mo 7,90 Mbits / sec
[3] 8,0-10,0 s 1,00 Mo 4,19 Mo / s
[3] 10,0-12,0 s 1,30 Mo 5,47 Mbits / sec
[3] 12,0-14,0 s 688 Koctets 2,82 Mbits / s
[3] 14,0-16,0 s 840 Ko 3,44 Mbits / s
[3] 16,0-18,0 s 1,03 Mo 4,33 Mbits / s
[3] 18,0-20,0 s 1,01 Mo 4,23 Mbits / s
[3] 20,0-22,0 s 1,03 Mo 4,33 Mbits / s
[3] 22,0-24,0 s 1,18 Mo 4,95 Mbits / s
[3] 24,0-26,0 s 904 Ko 3.70 Mbits / s
[3] 26,0-28,0 s 840 Ko 3,44 Mbits / s
[3] 28,0-30,0 s 936 Ko octets 3,83 Mbits / s
[3] 30,0 à 32,0 s 1,09 Mo 4,59 Mbits / s
[3] 32,0-34,0 s 960 Ko 3,93 Mbits / s
[3] 34,0 à 36,0 sec 752 Koctets 3,08 Mbits / sec
[3] 36,0 à 38,0 s 1,09 Mo 4,59 Mbits / s
[3] 38,0 à 40,0 s 1,09 Mo 4,59 Mbits / s
[3] 40,0 à 42,0 s 840 Ko 3,44 Mbits / s
[3] 42,0 à 44,0 s 1,27 Mo 5,34 Mbits / s
[3] 44,0 à 46,0 s 1,16 Mo 4,85 Mbits / s
[3] 46,0 à 48,0 s 840 Ko octets 3,44 Mbits / s
[3] 48,0 à 50,0 s 960 Ko octets 3,93 Mbits / s
[3] 50,0-52,0 s 1,28 Mo 5,37 Mbits / s
[3] 52,0-54,0 s 1,09 Mo 4,59 Mbits / s
[3] 54,0 à 56,0 s 992 Koctets 4,06 Mbits / s
[3] 56,0-58,0 s 1,00 Mo 4,19 Mo / s
[3] 58,0 à 60,0 s 1,09 Mo 4,59 Mbits / s
[3] 0,0 à 60,2 s 33,9 Mo 4,73 Mbits / s
[5] port local 10.x 5001 connecté au port 192.168.x 10965
[5] 0,0 à 2,0 s 1,85 Mo 7,75 Mbits / sec
[5] 2,0 à 4,0 s 1,90 Mo 7,98 Mbits / s
[5] 4,0 à 6,0 s 1,89 Mo 7,93 Mbits / s
[5] 6,0 - 8,0 s 1,92 Mo 8,07 Mbits / s
[5] 8,0-10,0 s 1,91 Mo 8,02 Mbits / s
[5] 10,0-12,0 s 1,83 Mo 7,69 Mbits / s
[5] 12,0-14,0 s 1,86 Mo 7,78 Mbits / sec
[5] 14,0-16,0 s 1,79 Mo 7,52 Mbit / s
[5] 16,0-18,0 s 1,79 Mo 7,52 Mbit / s
[5] 18,0-20,0 s 1,89 Mo 7,91 Mbits / s
[5] 20,0-22,0 s 1,91 Mo 8,00 Mbits / s
[5] 22,0-24,0 s 1,88 Mo 7,91 Mbits / s
[5] 24,0-26,0 s 1,95 Mo 8,16 Mbits / s
[5] 26,0-28,0 s 1,90 Mo 7,99 Mbits / s
[5] 28,0-30,0 s 1,87 Mo 7,84 Mbits / s
[5] 30,0 à 32,0 s 1,85 Mo 7,77 Mbits / s
[5] 32,0-34,0 s 1,55 Mo 6,49 Mbits / s
[5] 34,0 à 36,0 s 1,92 Mo 8,07 Mbits / s
[5] 36,0 à 38,0 s 1,90 Mo 7,99 Mbits / s
[5] 38,0 à 40,0 s 1,84 Mo 7,73 Mbits / s
[5] 40,0 à 42,0 s 1,66 Mo 6,95 Mbits / s
[5] 42,0 à 44,0 s 1,92 Mo 8,07 Mbits / s
[5] 44,0 à 46,0 s 1,91 Mo 7,99 Mbits / s
[5] 46,0 à 48,0 s 1,90 Mo 7,98 Mbits / s
[5] 48,0 à 50,0 s 1,84 Mo 7,70 Mbits / s
[5] 50,0-52,0 s 1,93 Mo 8,09 Mbits / s
[5] 52,0-54,0 s 1,80 Mo 7,54 Mbits / s
[5] 54,0-56,0 s 1,83 Mo 7,67 Mbits / s
[5] 56,0-58,0 s 1,88 Mo 7,86 Mbits / s
[5] 58,0 à 60,0 s 1,85 Mo 7,78 Mbits / s
[5] 0,0 à 60,3 s 56,0 Mo 7,79 Mbits / s

• Pour aller au fond des choses, voici les tests UDP de deux hôtes dans le même VLAN utilisant encore la connexion Metro, 200 = distant, 201 = DC

Nous voyons la perte de paquets augmenter avec l'augmentation de la bande passante (lorsque nous approchons de 10 Mbps, nous avons 0,93%, commence à être critique ... et expliquerait également pourquoi TCP a des problèmes de performance)

++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u
++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++
-------------------------------------------------- ----------
Écoute du serveur sur le port UDP 5001
Réception de datagrammes de 1470 octets
Taille du tampon UDP: 64,0 Koctets (par défaut)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client se connectant à 192.168.191.200, port UDP 5001
Envoi de datagrammes de 1470 octets
Taille du tampon UDP: 64,0 Koctets (par défaut)
-------------------------------------------------- ----------
[4] port local 192.168.191.201 61759 connecté au port 192.168.191.200 5001
[ID] Bande passante de transfert d'intervalle
[4] 0,0 à 1,0 s 128 Ko 1,05 Mbits / s
[4] 1,0 à 2,0 s 128 Koctets 1,05 Mbits / s
[4] 2,0 à 3,0 s 129 Ko 1,06 Mbits / s
[4] 3,0 à 4,0 s 128 Ko 1,05 Mbits / s
[4] 4,0 à 5,0 s 128 Ko 1,05 Mbits / s
[4] 5,0 à 6,0 s 128 Ko 1,05 Mbits / s
[4] 6,0 - 7,0 s 128 Ko 1,05 Mbits / s
[4] 7,0 - 8,0 s 128 Ko 1,05 Mbits / s
[4] 8,0 - 9,0 sec 128 Ko 1,05 Mbits / sec
[4] 9,0-10,0 s 129 Ko 1,06 Mbits / s
[4] 10,0-11,0 s 128 Ko 1,05 Mbits / s
[4] 11,0-12,0 s 128 Ko 1,05 Mbits / s
[4] 12,0-13,0 s 128 Ko 1,05 Mbits / s
[4] 13,0-14,0 s 128 Ko 1,05 Mbits / s
[4] 14,0-15,0 s 128 Ko 1,05 Mbits / s
[4] 15,0-16,0 s 128 Ko 1,05 Mbits / s
[4] 16,0-17,0 s 128 Ko 1,05 Mbits / s
[4] 17,0-18,0 s 128 Ko 1,05 Mbits / s
[4] 18,0-19,0 ​​s 131 Koctets 1,07 Mbits / s
[4] 19,0-20,0 s 128 Ko 1,05 Mbits / s
[4] 0,0-20,0 s 2,50 Mo 1,05 Mbits / s
[4] Envoyé 1785 datagrammes
[4] Rapport du serveur:
[4] 0,0-20,0 s 2,50 Mo 1,05 Mbits / s 0,257 ms 0/1785 (0%)
[3] port local 192.168.191.201 5001 connecté au port 192.168.191.200 50749
[3] 0,0 à 1,0 s 128 Koctets 1,05 Mbits / s 0,285 ms 0/89 (0%)
[3] 1,0 à 2,0 s 128 Koctets 1,05 Mbits / s 0,313 ms 0/89 (0%)
[3] 2,0 à 3,0 s 128 Ko 1,05 Mbits / s 0,278 ms 0/89 (0%)
[3] 3,0 à 4,0 s 128 Koctets 1,05 Mbits / s 0,241 ms 0/89 (0%)
[3] 4,0 à 5,0 s 128 Ko 1,05 Mbits / s 0,266 ms 0/89 (0%)
[3] 5,0 à 6,0 s 128 Ko 1,05 Mbits / s 0,293 ms 0/89 (0%)
[3] 6,0 - 7,0 sec 128 Koctets 1,05 Mbits / sec 0,314 ms 0/89 (0%)
[3] 7,0 - 8,0 sec 128 Koctets 1,05 Mbits / sec 0,280 ms 0/89 (0%)
[3] 8,0 - 9,0 sec 128 Koctets 1,05 Mbits / sec 0,242 ms 0/89 (0%)
[3] 9,0-10,0 s 129 Koctets 1,06 Mbits / s 0,250 ms 0/90 (0%)
[3] 10,0-11,0 s 128 Koctets 1,05 Mbits / s 0,275 ms 0/89 (0%)
[3] 11,0-12,0 s 128 Koctets 1,05 Mbits / s 0,299 ms 0/89 (0%)
[3] 12,0-13,0 s 128 Koctets 1,05 Mbits / s 0,327 ms 0/89 (0%)
[3] 13,0-14,0 sec 128 Koctets 1,05 Mbits / sec 0,290 ms 0/89 (0%)
[3] 14,0-15,0 sec 128 Koctets 1,05 Mbits / sec 0,251 ms 0/89 (0%)
[3] 15,0-16,0 sec 128 Koctets 1,05 Mbits / sec 0,275 ms 0/89 (0%)
[3] 16,0-17,0 s 128 Koctets 1,05 Mbits / s 0,303 ms 0/89 (0%)
[3] 17,0-18,0 sec 128 Koctets 1,05 Mbits / sec 0,333 ms 0/89 (0%)
[3] 18,0-19,0 ​​s 128 Koctets 1,05 Mbits / s 0,294 ms 0/89 (0%)
[3] 19,0-20,0 s 131 Koctets 1,07 Mbits / s 0,281 ms 0/91 (0%)
[3] 0,0-20,0 s 2,50 Mo 1,05 Mbits / s 0,305 ms 0/1785 (0%)

++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 5m
++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++
-------------------------------------------------- ----------
Écoute du serveur sur le port UDP 5001
Réception de datagrammes de 1470 octets
Taille du tampon UDP: 64,0 Koctets (par défaut)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client se connectant à 192.168.191.200, port UDP 5001
Envoi de datagrammes de 1470 octets
Taille du tampon UDP: 64,0 Koctets (par défaut)
-------------------------------------------------- ----------
[4] port local 192.168.191.201 61760 connecté au port 192.168.191.200 5001
[ID] Bande passante de transfert d'intervalle
[4] 0,0 à 1,0 s 610 Ko 5,00 Mbits / s
[4] 1,0 à 2,0 s 609 Ko 4,99 Mbits / s
[4] 2,0 à 3,0 s 610 Ko 5,00 Mbits / s
[4] 3,0 à 4,0 s 609 Ko 4,99 Mbits / s
[4] 4,0 à 5,0 s 610 Ko 5,00 Mbits / s
[4] 5,0 à 6,0 s 609 Ko 4,99 Mbits / s
[4] 6,0 - 7,0 s 610 Ko 5,00 Mbits / s
[4] 7,0 - 8,0 s 609 Ko 4,99 Mbits / s
[4] 8,0 - 9,0 s 610 Ko 5,00 Mbits / s
[4] 9,0-10,0 s 619 Koctets 5,07 Mbits / s
[4] 10,0 à 11,0 s 610 Ko 5,00 Mbits / s
[4] 11,0-12,0 s 609 Ko 4,99 Mbits / s
[4] 12,0-13,0 s 609 Ko 4,99 Mbits / s
[4] 13,0-14,0 s 610 Ko 5,00 Mbits / s
[4] 14,0 à 15,0 s 609 Ko 4,99 Mbits / s
[4] 15,0-16,0 s 610 Ko 5,00 Mbits / s
[4] 16,0-17,0 s 609 Ko 4,99 Mbits / s
[4] 17,0-18,0 s 610 Koctets 5,00 Mbits / sec
[4] 18,0 à 19,0 s 619 Koctets 5,07 Mbits / s
[4] 19,0-20,0 s 609 Ko 4,99 Mbits / s
[4] 0,0-20,0 s 11,9 Mo 5,00 Mbits / s
[4] 8504 datagrammes envoyés
[4] Rapport du serveur:
[4] 0,0-20,0 s 11,9 Mo 4,99 Mbits / s 0,000 ms 12/8503 (0,14%)
[4] 0,0-20,0 s 1 datagrammes reçus en panne
[3] port local 192.168.191.201 5001 connecté au port 192.168.191.200 50750
[3] 0,0 à 1,0 s 606 Koctets 4,96 Mbits / s 2,238 ms 1/423 (0,24%)
[3] 1,0 à 2,0 s 610 Koctets 5,00 Mbits / sec 2,739 ms 0/425 (0%)
[3] 2,0 à 3,0 s 609 Ko 4,99 Mbits / s 3,089 ms 1/425 (0,24%)
[3] 3,0 à 4,0 s 609 Koctets 4,99 Mbits / s 3,605 ms 0/424 (0%)
[3] 4,0 à 5,0 s 607 Ko 4,97 Mbits / s 1,954 ms 0/423 (0%)
[3] 5,0 à 6,0 s 612 Koctets 5,01 Mbits / s 2,666 ms 0/426 (0%)
[3] 6,0 - 7,0 sec 607 Koctets 4,97 Mbits / sec 2,602 ms 0/423 (0%)
[3] 7,0 - 8,0 sec 612 Koctets 5,01 Mbits / sec 2,960 ms 0/426 (0%)
[3] 8,0 - 9,0 sec 609 Koctets 4,99 Mbits / sec 2,512 ms 0/424 (0%)
[3] 9,0-10,0 s 619 Koctets 5,07 Mbits / s 2,133 ms 0/431 (0%)
[3] 10,0-11,0 s 609 Koctets 4,99 Mbits / s 3,605 ms 1/425 (0,24%)
[3] 11,0-12,0 s 609 Koctets 4,99 Mbits / s 2,509 ms 0/424 (0%)
[3] 12,0-13,0 s 610 Koctets 5,00 Mbits / s 3,570 ms 0/425 (0%)
[3] 13,0-14,0 s 609 Ko 4,99 Mbits / s 3,077 ms 1/425 (0,24%)
[3] 14,0 à 15,0 s 609 Koctets 4,99 Mbits / s 2,679 ms 0/424 (0%)
[3] 15,0-16,0 s 609 Koctets 4,99 Mbits / s 1,887 ms 0/424 (0%)
[3] 16,0-17,0 s 610 Koctets 5,00 Mbits / sec 2,651 ms 0/425 (0%)
[3] 17,0-18,0 s 609 Koctets 4,99 Mbits / s 3,390 ms 0/424 (0%)
[3] 18,0-19,0 ​​s 617 Koctets 5,06 Mbits / s 2,601 ms 0/430 (0%)
[3] 19,0-20,0 s 612 Koctets 5,01 Mbits / s 3,525 ms 0/426 (0%)
[3] 0,0-20,0 s 11,9 Mo 4,99 Mo / s 3,156 ms 3/8503 (0,035%)
[3] 0,0-20,0 s 1 datagrammes reçus en panne

++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9m
++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++
-------------------------------------------------- ----------
Écoute du serveur sur le port UDP 5001
Réception de datagrammes de 1470 octets
Taille du tampon UDP: 64,0 Koctets (par défaut)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client se connectant à 192.168.191.200, port UDP 5001
Envoi de datagrammes de 1470 octets
Taille du tampon UDP: 64,0 Koctets (par défaut)
-------------------------------------------------- ----------
[4] port local 192.168.191.201 61761 connecté au port 5001 192.168.191.200
[ID] Bande passante de transfert d'intervalle
[4] 0,0 à 1,0 s 1,07 Mo 9,00 Mbits / s
[4] 1,0 à 2,0 s 1,07 Mo 8,98 Mbits / s
[4] 2,0 à 3,0 s 1,07 Mo 9,00 Mbits / s
[4] 3,0 à 4,0 s 1,07 Mo 8,98 Mbits / s
[4] 4,0 à 5,0 s 1,07 Mo 9,00 Mbits / s
[4] 5,0 à 6,0 s 1,07 Mo 8,98 Mbits / s
[4] 6,0 - 7,0 s 1,07 Mo 8,98 Mbits / s
[4] 7,0 - 8,0 s 1,07 Mo 9,00 Mbits / s
[4] 8,0 - 9,0 s 1,07 Mo 8,98 Mbits / s
[4] 9,0-10,0 s 1,09 Mo 9,14 Mbits / s
[4] 10,0-11,0 s 1,07 Mo 9,00 Mbits / s
[4] 11,0-12,0 s 1,07 Mo 8,98 Mbits / s
[4] 12,0-13,0 s 1,07 Mo 8,98 Mbits / s
[4] 13,0-14,0 s 1,07 Mo 9,00 Mbits / s
[4] 14,0-15,0 s 1,07 Mo 8,98 Mbits / s
[4] 15,0-16,0 s 1,07 Mo 9,00 Mbits / s
[4] 16,0-17,0 s 1,07 Mo 8,98 Mbits / s
[4] 17,0-18,0 s 1,07 Mo 8,98 Mbits / s
[4] 18,0-19,0 ​​s 1,09 Mo 9,14 Mbits / s
[4] 19,0-20,0 s 1,07 Mo 9,00 Mbits / s
[4] 0,0-20,0 s 21,5 Mo 9,00 Mbits / s
[4] 15315 datagrammes envoyés
[4] Rapport du serveur:
[4] 0,0-20,0 s 21,3 Mo 8,94 Mbits / s 0,104 ms 96/15314 (0,63%) !!!!!!!!!!!
[4] 0,0-20,0 s 1 datagrammes reçus en panne
[3] port local 192.168.191.201 5001 connecté au port 192.168.191.200 50751
[3] 0,0 à 1,0 s 1,06 Mo 8,89 Mbits / s 2,405 ms 0/756 (0%)
[3] 1,0 - 2,0 s 1,07 Mo 9,00 Mbits / s 2,308 ms 0/765 (0%)
[3] 2,0 à 3,0 s 1,07 Mo 9,00 Mbits / s 2,305 ms 0/765 (0%)
[3] 3,0 à 4,0 s 1,07 Mo 8,97 Mbits / s 2,290 ms 1/764 (0,13%)
[3] 4,0 à 5,0 s 1,07 Mo 8,98 Mbits / s 2,271 ms 1/765 (0,13%)
[3] 5,0 - 6,0 s 1,07 Mo 8,98 Mbits / s 2,313 ms 0/764 (0%)
[3] 6,0 - 7,0 s 1,07 Mo 9,00 Mbits / s 2,191 ms 0/765 (0%)
[3] 7,0 - 8,0 s 1,07 Mo 8,95 Mbits / s 2,314 ms 3/764 (0,39%)
[3] 8,0 - 9,0 s 1,07 Mo 8,98 Mbits / s 2,232 ms 1/765 (0,13%)
[3] 9,0-10,0 s 1,09 Mo 9,13 Mbits / s 2,257 ms 0/776 (0%)
[3] 10,0-11,0 s 1,07 Mo 8,98 Mbits / s 2,365 ms 0/764 (0%)
[3] 11,0-12,0 s 1,07 Mo 8,98 Mbits / s 2,301 ms 1/765 (0,13%)
[3] 12,0-13,0 s 1,07 Mo 8,98 Mbits / s 2,277 ms 0/764 (0%)
[3] 13,0-14,0 s 1,07 Mo 9,00 Mbits / s 2,323 ms 0/765 (0%)
[3] 14,0-15,0 s 1,07 Mo 9,00 Mbits / s 2,176 ms 0/765 (0%)
[3] 15,0-16,0 s 1,07 Mo 8,96 Mbits / s 2,273 ms 2/764 (0,26%)
[3] 16,0-17,0 s 1,07 Mo 8,98 Mbits / s 2,313 ms 0/764 (0%)
[3] 17,0-18,0 s 1,07 Mo 8,98 Mbits / s 2,247 ms 1/765 (0,13%)
[3] 18,0-19,0 ​​s 1,09 Mo 9,9 Mbit / s 2,276 ms 1/776 (0,13%)
[3] 19,0-20,0 s 1,07 Mo 8,97 Mbits / s 2,394 ms 1/764 (0,13%)
[3] 0,0-20,0 s 21,5 Mo 8,99 Mo / s 2,659 ms 11/15314 (0,072%)
[3] 0,0-20,0 s 1 datagrammes reçus en panne

++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++
C: \ iperf-2.0.5-2-win32> iperf -c 192.168.191.200 -i 1 -t 20 -r -u -b 9850k
++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++
-------------------------------------------------- ----------
Écoute du serveur sur le port UDP 5001
Réception de datagrammes de 1470 octets
Taille du tampon UDP: 64,0 Koctets (par défaut)
-------------------------------------------------- ----------
-------------------------------------------------- ----------
Client se connectant à 192.168.191.200, port UDP 5001
Envoi de datagrammes de 1470 octets
Taille du tampon UDP: 64,0 Koctets (par défaut)
-------------------------------------------------- ----------
[4] port local 192.168.191.201 61762 connecté au port 192.168.191.200 5001
[ID] Bande passante de transfert d'intervalle
[4] 0,0 à 1,0 s 1,17 Mo 9,84 Mbits / s
[4] 1,0 à 2,0 s 1,17 Mo 9,84 Mbits / s
[4] 2,0 à 3,0 s 1,17 Mo 9,84 Mbits / s
[4] 3,0 à 4,0 s 1,17 Mo 9,84 Mbits / s
[4] 4,0 à 5,0 s 1,17 Mo 9,84 Mbits / s
[4] 5,0 à 6,0 s 1,17 Mo 9,83 Mbits / s
[4] 6,0 - 7,0 s 1,17 Mo 9,84 Mbits / s
[4] 7,0 - 8,0 s 1,17 Mo 9,84 Mbits / s
[4] 8,0 - 9,0 s 1,17 Mo 9,84 Mbits / s
[4] 9,0-10,0 s 1,19 Mo 10,0 Mbits / s
[4] 10,0 à 11,0 sec 1,17 Mo 9,84 Mbits / sec
[4] 11,0-12,0 s 1,17 Mo 9,84 Mbits / s
[4] 12,0-13,0 s 1,17 Mo 9,83 Mbits / s
[4] 13,0-14,0 s 1,17 Mo 9,85 Mbits / s
[4] 14,0 à 15,0 s 1,17 Mo 9,83 Mbits / s
[4] 15,0-16,0 s 1,17 Mo 9,85 Mbits / s
[4] 16,0-17,0 s 1,17 Mo 9,83 Mbits / s
[4] 17,0-18,0 s 1,17 Mo 9,84 Mbits / s
[4] 18,0-19,0 ​​s 1,19 Mo 10,0 Mbits / s
[4] 19,0-20,0 s 1,17 Mo 9,84 Mbits / s
[4] 0,0-20,0 s 23,5 Mo 9,85 Mbits / s
[4] 16765 datagrammes envoyés
[4] Rapport du serveur:
[4] 0,0-20,0 s 23,3 Mo 9,74 Mbits / s 3,421 ms 156/16764 (0,93%) !!!!!!!!!!
[4] 0,0-20,0 s 1 datagrammes reçus en panne
[3] port local 192.168.191.201 5001 connecté au port 192.168.191.200 50752
[3] 0,0 à 1,0 s 1,16 Mo octets 9,74 Mbits / s 2,131 ms 0/828 (0%)
[3] 1,0 - 2,0 s 1,17 Mo 9,84 Mbits / s 2 140 ms 0/837 (0%)
[3] 2,0 à 3,0 s 1,17 Mo 9,83 Mbits / s 2,099 ms 1/837 (0,12%)
[3] 3,0 à 4,0 s 1,17 Mo 9,84 Mbits / s 2,113 ms 0/837 (0%)
[3] 4,0 à 5,0 s 1,17 Mo 9,84 Mbits / s 2,105 ms 0/837 (0%)
[3] 5,0 à 6,0 s 1,17 Mo 9,83 Mbits / s 2,058 ms 1/837 (0,12%)
[3] 6,0 - 7,0 sec 1,17 Mo 9,92 Mbits / sec 2,165 ms 1/836 (0,12%)
[3] 7,0 - 8,0 s 1,17 Mo 9,84 Mbits / s 2,156 ms 0/837 (0%)
[3] 8,0 - 9,0 s 1,17 Mo 9,82 Mbit / s 2 135 m 2/837 (0,24%)
[3] 9,0-10,0 s 1,19 Mo 9,97 Mbit / s 2,152 ms 2/850 (0,24%)
[3] 10,0 à 11,0 s 1,17 Mo 9,83 Mbits / s 2,153 ms 1/837 (0,12%)
[3] 11,0-12,0 s 1,17 Mo 9,84 Mbits / s 2,127 ms 0/837 (0%)
[3] 12,0-13,0 s 1,17 Mo 9,83 Mbits / s 2,136 ms 1/837 (0,12%)
[3] 13,0-14,0 s 1,17 Mo 9,82 Mbits / s 2,087 ms 2/837 (0,24%)
[3] 14,0-15,0 s 1,17 Mo 9,83 Mbits / s 2,061 ms 1/837 (0,12%)
[3] 15,0-16,0 s 1,17 Mo 9,84 Mbits / s 2,045 ms 0/837 (0%)
[3] 16,0-17,0 s 1,17 Mo 9,82 Mbits / s 2,203 ms 1/836 (0,12%)
[3] 17,0-18,0 s 1,17 Mo 9,94 Mbits / s 2,165 ms 0/837 (0%)
[3] 18,0-19,0 ​​s 1,17 Mo 9,83 Mbits / s 2,154 ms 1/837 (0,12%)
[3] 19,0-20,0 s 1,19 Mo 9,98 Mbits / s 2,209 ms 0/849 (0%)
[3] 0,0-20,0 s 23,5 Mo 9,84 Mbits / s 2,548 ms 13/16764 (0,078%)
[3] 0,0-20,0 s 1 datagrammes reçus en panne

La vraie question demeure:

Nous ne sursouscrivons pas le lien DC car il est à 100 Mbps et ne peut pas envoyer plus de 100 Mbps. Cependant, les sites distants sont à 10 Mbps.

• Les tampons du côté distant débordent-ils et abandonnent-ils les paquets?
• Le gestionnaire de trafic du fournisseur fait-il quelque chose pour le trafic? (Le trafic provenant d'un autre nœud serait-il influencé par la configuration du trafic des FAI ou uniquement par le trafic entrant dans le nœud (de l'extérieur)) ...... Vous voyez ce que je veux dire?

Pourquoi TCP ne peut-il pas gérer cela tout seul?

Mise à jour # 3 J'ai maintenant utilisé le scénario suivant:

Laptop ------- ... LAN ... --- DC switch --- Metro-Eth --- Laptop (directly connected)
NIC@10Mbps                       100Mbps                  NIC@10Mbps

Voici la perte de paquets dans le sens DC-> distant: (test UDP iperf 9 Mbps)

[  3] local 192.168.191.200 port 5001 connected with 192.168.191.201 port 55236
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec   912 KBytes  7.47 Mbits/sec   2.713 ms    0/  635 (0%)
[  3]  1.0- 2.0 sec  1001 KBytes  8.20 Mbits/sec   2.168 ms    0/  697 (0%)
[  3]  2.0- 3.0 sec  1001 KBytes  8.20 Mbits/sec   2.478 ms    0/  697 (0%)
[  3]  3.0- 4.0 sec   999 KBytes  8.18 Mbits/sec   0.933 ms    0/  696 (0%)
[  3]  4.0- 5.0 sec  1001 KBytes  8.20 Mbits/sec   2.620 ms    0/  697 (0%)
[  3]  5.0- 6.0 sec  1001 KBytes  8.20 Mbits/sec   2.721 ms    0/  697 (0%)
[  3]  6.0- 7.0 sec  1001 KBytes  8.20 Mbits/sec   2.089 ms    0/  697 (0%)
[  3]  7.0- 8.0 sec   999 KBytes  8.18 Mbits/sec   2.641 ms    0/  696 (0%)
[  3]  8.0- 9.0 sec  1002 KBytes  8.21 Mbits/sec   0.896 ms    0/  698 (0%)
[  3]  9.0-10.0 sec  1015 KBytes  8.31 Mbits/sec   2.557 ms    0/  707 (0%)
[  3] 10.0-11.0 sec   999 KBytes  8.18 Mbits/sec   2.822 ms    1/  697 (0.14%)
[  3] 11.0-12.0 sec   999 KBytes  8.18 Mbits/sec   1.551 ms    1/  697 (0.14%)
[  3] 12.0-13.0 sec   998 KBytes  8.17 Mbits/sec   2.504 ms    2/  697 (0.29%)
[  3] 13.0-14.0 sec   995 KBytes  8.15 Mbits/sec   2.038 ms    3/  696 (0.43%)
[  3] 14.0-15.0 sec   991 KBytes  8.11 Mbits/sec   2.539 ms    7/  697 (1%)
[  3] 15.0-16.0 sec   992 KBytes  8.13 Mbits/sec   2.759 ms    6/  697 (0.86%)
[  3] 16.0-17.0 sec   998 KBytes  8.17 Mbits/sec   2.229 ms    2/  697 (0.29%)
[  3] 17.0-18.0 sec   993 KBytes  8.14 Mbits/sec   2.723 ms    4/  696 (0.57%)
[  3] 18.0-19.0 sec   998 KBytes  8.17 Mbits/sec   2.038 ms    2/  697 (0.29%)
[  3] 19.0-20.0 sec  1012 KBytes  8.29 Mbits/sec   2.575 ms    3/  708 (0.42%)
[  3]  0.0-20.0 sec  19.5 MBytes  8.15 Mbits/sec   2.775 ms   31/13917 (0.22%)
[  3]  0.0-20.0 sec  1 datagrams received out-of-order

L'autre direction est très bien. Cependant , lors de l'exécution d'un test TCP, la direction distante-> DC ne fonctionne pas beaucoup mieux que la direction DC-> distante (environ 5 Mbps) .......

Je ne suis pas sûr que nous ayons atteint le fond de cela.

Référencement de notre chat Stack Exchange ...

Histoire courte, vous devez contrôler les discordances de vitesse sur les deux côtés de vos métro liaisons Ethernet ... Je redessine votre diagramme pour des raisons de clarté ... ^{Note 1}

• Le DC (montré en vert) passe très rapidement de 10GE à 100M ... c'est une transition de vitesse 100 fois, et vous devez généralement implémenter une certaine forme de qos (comme la mise en forme) pour atténuer une transition aussi importante. Voir le bas de cette réponse pour la preuve que le DC a besoin de mise en forme (par site) ...
• Le côté distant passe de 1GE à 10M très rapidement CIR ... encore une fois, c'est une transition de vitesse 100 fois. La mise en forme ou d'autres solutions de contournement du qos sont généralement nécessaires.
• Il semble également y avoir un décalage de vitesse entre le DC UNI (100M) et le UNI distant (10M); cela demande en soi une solution de gestion de la bande passante par site.

Pour info, si votre fournisseur implémente des services conformes à MEF , ils ne sont pas en train de façonner, ils sont en train de contrôler . Le trafic TCP a tendance à mieux fonctionner avec la mise en forme .

Le besoin de votre propre QoS

Vous semblez remettre en question le besoin de qualité de service , je vais donc citer le livre blanc MEF "Comprendre le débit Ethernet de l'opérateur" , page 9 ... à titre d'examen, le client de la figure 2 du livre blanc MEF a une meilleure situation que vous. .. ils ont acheté un CIR 50Mbps, mais leur UNI est livré sur un 1GE ... votre site distant a un CIR 10Mbps sur un UNI 1GE.

The transition from legacy services such as T1, T3, Frame Relay and ATM
to Carrier Ethernet has created some unintended consequences. Not all customers have 
conforming equipment facing the network which properly limits/shapes the traffic outbound
to the network, with deleterious results.  For instance, on the 1 GigE interface of
Figure 2, if the customer’s equipment accidentally transmits long bursts of data at 
150 Mbits instead of the SLA’s Committed Information Rate of 50 Mbits, 67% of the data 
may be lost and network breakdown will likely result.

Répondre à d'autres questions TCP lors d'une modification ...

Nous ne sursouscrivons pas le lien DC car il est à 100 Mbps et ne peut pas envoyer plus de 100 Mbps ...

Je ne suis pas d'accord, vous pouvez envoyer des microrafales à 10 GE car votre DC a des liaisons 10 GE, mais le métro UNI est à 100 Mbps. Une question ouverte est la quantité de mémoire tampon dont vous disposez sur votre commutateur LAN Enterasys (commutateur A) lorsque vous effectuez la transition de 10GE à 100M.

Pourquoi TCP ne peut-il pas gérer cela tout seul?

TCP gère les choses en ralentissant lorsqu'il voit une perte de paquets ... il ralentit vraiment (et peut interrompre la connexion) pour une perte de paquets sérieuse. Ainsi, TCP fait ce qu'il devrait ... en tant qu'ingénieur réseau, votre objectif est de construire un réseau avec des conditions qui rendent TCP heureux.

Autres questions TCP du chat

Marki a déclaré : Je ne comprends pas ce qui est abandonné, où, par qui, pourquoi et pourquoi TCP ne gère pas simplement le fait qu'il y a (réel) 100 Mo à une extrémité et seulement 10 Mbps à l'autre.

Concernant le besoin de mise en mémoire tampon de TCP et les conséquences de l'absence de mémoire tampon :

Fait numéro 1: TCP a besoin d'un tampon pour les transitions de vitesse car il est conçu comme un système de contrôle de rétroaction .

Par analogie avec la conduite: en bons conducteurs, nous laissons toujours quelques secondes d'espace entre nous et la voiture devant nous; à certains égards, cet espace entre les voitures est à peu près analogue à un tampon réseau. Si la personne devant nous clique sur les freins lorsqu'un animal court devant eux, l'espace entre nos voitures (espérons-le) nous empêche de heurter leur voiture. Nous laissons de l'espace car il faut du temps à nos yeux pour voir les feux stop, notre pied pour réagir et les freins pour dissiper suffisamment de chaleur; nos yeux nous donnent un système de contrôle de rétroaction visuelle.

De même, lorsqu'une session FTP est dynamitée à 10 GE, les rafales de trafic peuvent atteindre jusqu'à 4 Mo (dans votre cas) en raison de la taille de la fenêtre à l'échelle TCP avant que le socket ne s'arrête et attende un TCP ACK. Pendant ce temps, si le flux de trafic 10GE atteint soudainement un "Fast Ethernet", TCP doit ralentir progressivement. Des tampons profonds dans l'équipement réseau permettent à TCP de supprimer beaucoup moins de paquets lorsqu'il effectue des transitions de vitesse; cependant, si vous n'avez pas de tampons, vous pouvez supprimer peut-être 99% de cette fenêtre TCP de 4 Mo lorsqu'elle est limitée de 10GE à 100M. Considérez cette perte sévère de 99% comme un crash de socket TCP; TCP réagit de manière prévisible à une perte de paquets relativement progressive. TCP réagit de façon beaucoup moins prévisible à la perte de paquets grave et continue ^{Note 3} .

À la question de savoir pourquoi vous ne devriez pas utiliser un CIR Ethernet Metro asymétrique avec 100M au DC et 10M sur la télécommande, posez-vous une question rhétorique "qui met en mémoire tampon ce trafic de 100 Mbps lorsqu'il atteint le NID Ethernet 10 Mbps bon marché que votre métro -Ethernet Provider vous a donné? "... (indice: personne ne met en mémoire tampon).

Si personne ne met en mémoire tampon les transitions de vitesse importantes (voir note 2), ces points sont des endroits potentiels pour interrompre le trafic par intermittence.

Qu'est-ce qui est abandonné par qui :

Lorsque le trafic TCP quitte le centre de données, il peut être supprimé à trois endroits:

• À D1: parce que les commutateurs LAN ont rarement une mémoire tampon suffisamment profonde pour une transition de vitesse de 100: 1
• À J2: si le NID a déjà négocié la liaison UNI à une vitesse supérieure au CIR ; ce n'est pas le cas en ce moment, donc je ne m'attends pas à des baisses là-bas.
• À J3: pour toutes les raisons que je viens de décrire à propos des CIR Ethernet Ethernet asymétriques .

Lorsque le trafic TCP va au centre de données ...

• À J4: parce que vous avez une UNI 1GE et un CIR 10M ; c'est le cas pathologique de D2 que j'ai évoqué plus haut.

Comment atténuer les décalages de vitesse:

Un exemple de solution EVPL :

• Dans une topologie commutée comme celle-ci, un EVPL avec des EVC point à point du DC vers chaque télécommande est probablement votre meilleure option (voir le schéma ci-dessus). Cela appliquerait un CIR individuel à chaque EVC. Remarque: tous les autres conseils QoS dans cette réponse s'appliquent ... c'est-à-dire éviter les transitions à grande vitesse ^{Note 2} sans tester si votre équipement gérera suffisamment bien.
• Alternativement, vous pourriez envisager d'acheter des services de métro qui ont des tarifs symétriques entre le DC et la télécommande; bien que je concède que ce ne soit peut-être pas l'orientation la plus pratique.
• Pour info, la solution classique à ce problème pour les services routés est d' acheter des routeurs qui prennent en charge la mise en forme aux vitesses requises, puis de façonner votre trafic de métro en fonction du CIR approprié (par site distant). Pour info, le côté distant pourrait s'en tirer avec un routeur assez petit, car ce n'est qu'une entrée 1GE et un CIR 10Mbps ... Il y a quelques mois, lorsque nous avons parlé de la conception de ce service, j'ai recommandé le routage si vous étiez à l'aise avec les technologies ...

• Si vous n'avez pas d'argent supplémentaire à dépenser et que vous ne pouvez pas réorganiser votre service de métro-Ethernet, vous pouvez masser les asymétries de vitesse plus progressivement. Je n'ai jamais fait cela, mais en principe, vous pouvez essayer de faire des transitions de vitesse de 10 à 1, au lieu de 100 à 1 (ce que vous avez actuellement à la fois sur le DC et à distance):

  • Au lieu d'acheter un routeur pour façonner la télécommande à 10 Mo, vous pouvez essayer de forcer la télécommande UNI à négocier automatiquement à 100 Mo au lieu de 1 GE; GigabitEthernet nécessite toutes les broches d'un câble Cat5e , vous pouvez donc le forcer efficacement à 100M avec une prise mod RJ45 qui connecte simplement les broches 1, 2, 3 et 6.
  • Au lieu d'acheter un routeur pour façonner le DC à 100M, utilisez votre Enterasys pour contrôler le lien 10GE vers 1GE lors de l'envoi de trafic vers le lien 100M

Analyser vos iperfrésultats ...

Il y a deux points clés à retenir iperf(toutes les informations basées sur la iperfversion 2):

• iperfmesure la bande passante de la charge utile TCP ou UDP ; en d'autres termes, il ignore la surcharge des en-têtes TCP, UDP, IP et Ethernet. Puisque vous avez un service Ethernet, n'oubliez pas de modifier les iperfrésultats en conséquence
• Le iperfclient envoie des données au serveur pendant les tests.

En tant que tel, la sortie suivante montre que la machine DC (en iperf -cmode) se connecte au iperfserveur sur le site distant (192.168.x) et pousse les données du DC (100M UNI) vers le site distant (10M UNI) ...

./iperf -c 192.168.x -i2 -t 60 -r
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.x, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 10.x port 38195 connected with 192.168.x port 5001
[  3]  0.0- 2.0 sec  1.44 MBytes  6.03 Mbits/sec
[  3]  2.0- 4.0 sec  2.23 MBytes  9.37 Mbits/sec
[  3]  4.0- 6.0 sec  2.28 MBytes  9.57 Mbits/sec
[  3]  6.0- 8.0 sec  1.88 MBytes  7.90 Mbits/sec
[  3]  8.0-10.0 sec  1.00 MBytes  4.19 Mbits/sec
[  3] 10.0-12.0 sec  1.30 MBytes  5.47 Mbits/sec
[  3] 12.0-14.0 sec    688 KBytes  2.82 Mbits/sec

La sortie ci-dessus montre clairement les problèmes dans le sens DC vers la distance; nous devrions nous attendre à voir 9 Mbps ou plus lorsque les choses fonctionnent bien (c'est-à-dire que vous attendez au moins 90% de la capacité - 10 Mbps sur le site distant). Maintenant, regardons le trafic dans la direction opposée (quand iperfpousse les données du site distant vers le DC) ...

[  5] local 10.x port 5001 connected with 192.168.x port 10965
[  5]  0.0- 2.0 sec  1.85 MBytes  7.75 Mbits/sec
[  5]  2.0- 4.0 sec  1.90 MBytes  7.98 Mbits/sec
[  5]  4.0- 6.0 sec  1.89 MBytes  7.93 Mbits/sec
[  5]  6.0- 8.0 sec  1.92 MBytes  8.07 Mbits/sec
[  5]  8.0-10.0 sec  1.91 MBytes  8.02 Mbits/sec
[  5] 10.0-12.0 sec  1.83 MBytes  7.69 Mbits/sec
[  5] 12.0-14.0 sec  1.86 MBytes  7.78 Mbits/sec

Vous pouvez envoyer environ 80% de la capacité de votre CIR distant, mais c'est encore moins que ce que j'attends.

Illustration de l'inadéquation de la vitesse CC (10 Gbit / s -> 100 Mbit / s)

Marki a dit : N'oubliez pas, le problème ne se manifeste que lorsque le débit est de 100 Mo-> 10 Mo, et non l'inverse.

Le problème se manifeste dans les deux sens, mais les iperfsymptômes semblent s'aggraver dans le sens DC -> à distance. Voir mon analyse de la iperfsortie ci-dessus.

Pour rendre cela concret, regardons votre pcap FTP lorsque vous transférez un fichier de votre serveur FTP DC (130.1.6.4) vers le site distant (192.168.191.2). Le transfert du côté Ethernet 100M du métro est limité à plusieurs points pendant le transfert. Vous pouvez le voir si vous regardez le dc-to-remote_remote-side.pcapngpcap et filtrezexpert.message contains "segment not captured"

^{Remarque 1} Je choisis des valeurs CBS de 25 Ko par MetroEthernet CIR 1 Mbps; c'est un ratio couramment utilisé par les fournisseurs ...
^Note YMMV ² Ma règle personnelle: "grande" est une transition de vitesse qui est nettement plus grande qu'une transition de vitesse 10: 1
^{Note 3}Je ne peux pas donner de chiffres précis pour ce qui est et ce n'est pas trop de perte de paquets pour TCP. Si la perte est suffisamment grave pour que vos applications en souffrent, c'est trop. Ma règle personnelle: lorsque je traite avec un réseau d'entreprise câblé entièrement sous mon contrôle, toute perte de paquets (involontaire) est trop importante. Cela dit, certains modèles de commutateurs réduisent la mise en mémoire tampon; ces commutateurs peuvent parfois perdre des paquets ... c'est une question de jugement de savoir si vous devez vivre avec le problème ou acheter de meilleurs commutateurs. FYI: Ce n'est pas toujours évident, mais TCP augmente périodiquement le taux de transmission d'un socket pour s'assurer qu'il obtient autant de débit que possible; de nombreuses implémentations TCP savent qu'elles vont trop vite lorsqu'elles voient des pertes de paquets.

Alors que discuter de ce problème était très intéressant, le FAI a entre-temps commencé à échanger les modems DSL sur les différents sites par une autre marque. Certains problèmes de fragmentation des paquets, disent-ils. Et bon, 9,5 Mbps dans les deux sens sans aucun problème ni réglages spéciaux.