Oui tout à fait, ça fragmente à mort. J'ai essayé de modifier le MTU sur les interfaces LAN aux extrémités du tunnel en les diminuant, puis en les augmentant on ne sait jamais, en jouant sur le TCP MSS, mais la fragmentation a continué.
D'après ce que je lis, c'est bien au niveau de l'interface pseudowire qu'il faut faire quelque chose pour le MTU. Je vois par contre que sur les derniers versions du firmware c1900, l'option ip pmtu n'y est plus.. Je vais downgrader le firmware pour tester avec cette option .. Merci encore pour les retours Le mar. 11 juin 2019 à 23:17, David Ponzone <david.ponz...@gmail.com> a écrit : > Pas sûr, ça peut venir de la fragmentation/reassembly. > Il y a apparement des problèmes de MTU propres à L2TPv3: > > http://www.mplsvpn.info/2009/05/mtu-problem-in-l2tpv3.html > > Ca vaut le coup de vérifier. > > Le 11 juin 2019 à 22:16, Fabien H <frnog.fab...@gmail.com> a écrit : > > Alors sur le CPE par lesquels les paquets iperf du LAN rentrent, le CPU est > à 35%/34% assez constant. > > Par contre j'avais mal regardé mais sur le CPE par lesquels les paquets > sortent, le CPU est à 99%/33% !! > > Donc le problème vient clairement de là je pense.. > > Le mar. 11 juin 2019 à 16:07, David Ponzone <david.ponz...@gmail.com> a > écrit : > > Sur un show proc c, tu as quoi comme valeur X/Y ? > -> > > https://community.cisco.com/t5/switching/high-cpu-load-but-nothing-in-show-proce-cpu-why/td-p/1467781 > > CEF activé ? > Des features gourmands activés (PBR, ACL, tout en même temps ?) > > > Le 11 juin 2019 à 15:59, Fabien H <frnog.fab...@gmail.com> a écrit : > > La débit commence à diminuer à partir d'une taille de paquet < 1100 octets > à 80 Mb/s environ, donc si je calcule bien environ 9100 pps ... > > > > Le mar. 11 juin 2019 à 15:31, David Ponzone <david.ponz...@gmail.com> a > écrit : > > Essaie de réduire la taille des paquets UDP pour voir si c’est > effectivement le routeur qui ne suit pas en PPS. > > Le 11 juin 2019 à 15:29, Fabien H <frnog.fab...@gmail.com> a écrit : > > Voici les résultats : > > En test UDP, j'arrive à 85 Mb/s avec les paramètres suivants (taille > > paquet > > = 1400) : > > iperf3 -c <IP> -u -b 100M -t 10 -l 1400 > > En test TCP, j'arrive à 65 Mb/s avec les paramètres suivants (taille > > paquet > > = 1450, TCP MSS = 1410) : > > iperf3 -c <IP> -t 10 -l 1450 -M 1410 > > Le test TCP correspond à peu près au débit relevé lors du transfert SMB > > (60 > > Mb/s) > > J'ai peur que ça vienne d'une limitation routeur (pourtant le CPU est à > > 50% > > environ pendant le test)... > > > > Le mar. 11 juin 2019 à 12:53, Arnaud BRAND <arnaud.brand--fr...@tib.cc> > > a > > écrit : > > Comme dit par plusieurs : > - iperf UDP pour savoir combien ton tuyau/tunnel débite > - iperf TCP pour voir si tes tailles de fenêtres windows sont limitantes > par rapport au RTT (cf bandwidth-delay product) > - autres protos (FTP, SMB, ...) pour valider ce que le client verra (et > qui peut mener à du tuning de taille de fenêtre dans son > registre/netsh/gpo windows) > > Comme dit par d'autres: Mikrotik avec de l'EoIP fera très bien le job. > Pour du 100M et +, je mets en général des CCR1009 par sécurité > (plusieurs tunnels, plusieurs queues et un peu de classification), mais > en lab j'ai monté les hEX à 700/800M de mémoire. > Attention, débit sans chiffrement, donc à réserver à du backbone privé. > Pour 50 balles pièces, je réfléchis pas trop longtemps. > > Pense à passer les tests avec des paquets UDP à 1400 pour éviter la frag > par le tunnel et à activer le clamp MSS sur le tunnel EoIP avec la bonne > valeur pour que les connecs TCP s'adaptent bien au MTU réel. > > Bonne journée, > AB > > > Le 2019-06-11 11:05, CHENICLET, DAVID a écrit : > > Bonjour, > > +1 > > Pour le test de débit il vaut mieux le faire avec FTP. > La vitesse du transfert varie en fonction de la version du protocole > CIFS (liée à la version de l'OS Windows). > J'ai déjà eu le cas de transfert bridés avec le partage Windows... > > > Cordialement, > David C > > -----Message d'origine----- > De : frnog-requ...@frnog.org <frnog-requ...@frnog.org> De la part de > David Ponzone > Envoyé : mardi 11 juin 2019 10:18 > À : Fabien H > Cc : frnog-t...@frnog.org > Objet : Re: [FRnOG] [TECH] Tunnel L2 sur liens fibre L3 > > Hmm y a un temps où quand un Cisco tapait le 50% de CPU, c’était pas > bon du tout et il était temps de l’upgrader. > Je ne sais pas si Cisco a changé sa manière de calculer le CPU…. > > Après tu as essayé de faire un test de perf avec iperf ? > Parce que j’ai rarement vu un transfert SMB utilisé comme étalon de > performance. > D’autres sur la liste seront certainement aptes à nous dire si SMB est > capable de débits wirespeed même si le RTT augmente. > > Le 11 juin 2019 à 09:54, Fabien H <frnog.fab...@gmail.com> a écrit : > > Bonjour, > > un client a un besoin pour faire un tunnel L2 d'au moins 100Mb/s entre > 2 sites équipés en fibre 200M (MPLS). > > Nous avons essayé de mettre en place un Xconnect l2tpv3 entre les 2 > routeurs client (des CISCO 1921). Nous livrons de part et d'autre le > tunnel > L2 sur l'interface Gigabit Ethernet 0/1 du routeur client. > > Ca marche bien, mais le débit plafonne à environ 60 Mb/s en transfert > de fichier Windows ( Le CPU du routeur n'est qu'à 50% ... ). Nous > avons essayé de tuner le mtu et le adjust tcp mss, les buffer de > fragmention/defrag des interfaces LAN du xconnect, mais sans succès.. > > Nous souhaiterions au moins atteindre 100 Mb/s en L2 > > Avez-vous des pistes pour arriver à ce résultat ? > > - Est-ce que le xconnect MPLS plutôt que l2tpv3 serait plus efficace > au niveau bande passante ? > - Le stacked Vlan semble intéressant mais j'ai du mal à voir si c'est > pour faire du tunnel L2.. > - Nos switch core (Cisco) ne gèrent pas le Vlan rewrite > - Nos routeurs de coeur sont des ASR 1002-X > > Merci, > Cordialement, > > Fabien > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > This message contains information that may be privileged or > confidential and is the property of the Capgemini Group. It is > intended only for the person to whom it is addressed. If you are not > the intended recipient, you are not authorized to read, print, retain, > copy, disseminate, distribute, or use this message or any part > thereof. If you receive this message in error, please notify the > sender immediately and delete all copies of this message. > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
