Depuis que j’ai segmenté mon réseau local avec des VLAN et que l’ipx800v4 se trouve dans un VLAN différent de celui de mon PC, l’IPX800v4 est parfois très long à répondre.
Pas de problème avec l’IPX800v5 (et tous les autres équipements du VLAN) qui se trouve dans la meme situation. Cela semble spécifique au v4.
Idem lorsque j’y accede en VPN, en fait tout ce qui provient d’un subnet différent finalement. Avec ou sans NAT, c’est le même problème.
L’interface web de l’IPX800v4 fonctionne bien pendant quelques requêtes/réponses, puis après quelques-unes, ça lag et ca revient d’un coup. Parfois, il faut refresh manuellement la page.
Le problème a déjà été décrit ici à plusieurs reprises :
Pas de solution de la part du support (j’avais ouvert un ticket).
D’après ce que j’ai compris, il n’y aura pas d’évolution, ni de correction (malheureusement) sur l’ipx800v4. Je trouve cela bien dommage en ces temps où l’on essaye de réparer au lieu de remplacer…
si il ne va pas y avoir d’évolution sur la V4 ce n’est pas parce que GCE souhaite l’abandonner (la preuve ils commercialisent toujours la V2 et la V3) mais parce que la mémoire est pleine, c’est d’ailleurs ce qui a déclenché la réflexion de faire une V5.
De plus la V4 est beaucoup utilisée dans l’industrie, alors…
Quand à la réparation des modules, GCE le fait avec rapidité (en général 1 semaine départ chez vous → retour chez vous) et à un coût très raisonnable.
Merci pour la réponse, mais on est pas dans un cas d’ajout de feature (comme le SSL/TLS).
Ce qui est demandé, c’est un correction d’un problème bas niveau et élémentaire (pas dans le sens simpliste).
J’ai du mal à croire que corriger un problème fondamental de stack IP (problème de HOP ou TTL réseau je suppose) soit empêché par un problème de mémoire.
Je suis persuadé qu’il y a moyen de trouver quelques octets pour les quelques lignes de code supplémentaires. Mais ceci n’est que mon avis…
Et pourtant, croyez moi si on pouvait le faire ce serait déja fait. Il y a des raisons qui font que ce n’est pas possible de faire cette évolution, il est donc inutile de suggérer qu’il s’agirait d’une mauvaise volonté de notre part d’autant qu’il existe des méthodes pour contourner cette limitation.
Il s 'agit de réseau, sans capture wireshark pour analyser ce qui se passe en profondeur, c’est compliqué de vous donner une solution.
Si vous avez un switch manageable, ( ce qui doit etre le cas) vous devriez pouvoir créer une règle de contournement. De mémoire, il me semble que certains clients passent par des Synology ou ont changés de VPN pour contourner ce soucis.
De mon coté je n’ai pas vraiment eu de retour précis technique ou plus de détails que ça. Les ingé du BE m’ont simplement dit à l’époque que c’était pas faisable dans la stack embarqué de la v4. Depuis le ticket à été clôturé et on est passé à la v5.
J’ai bien entendu testé plusieurs contournements (NAT, mangle, etc…).
Le problème se produit dés l’instant où il y routage et donc un HOP entre le client (browser) et le serveur (IPX). Que ce soit entre deux VLAN différents ou simplement deux subnet différents.
Le problème ne provient pas d’un VPN ou autre. Bien sûr quand on monte un tunnel VPN, on fait forcément de la segmentation subnet, sauf à faire du bridge (tap), mais ça, c’est mal (d’ailleurs dans ce cas, plus de problème, mais c’est vraiment pas réaliste)…
Je pense qu’il serait opportun de comprendre / analyser précisément ce qui bloquerait la mise en place de la correction. Je travaille moi-même dans une grande entreprise industrielle et les VLAN / subnet IOT sont une pratique plus que courante. Je suis très surpris que ce problème ne soit pas une priorité chez GCE.
Encore une fois, je doute que cela soit véritablement un problème uniquement technique et encore plus mémoire. On est probablement dans un cas où il y quelques lignes de code C à modifier.
J’avais cru comprendre que le dev de la stack IP était sous-traitée à une entreprise tierce et qu’il était compliqué de faire bouger les choses. Kevin du support m’avait écrit dans mon ticket EL5-93D-U6Q9 :
Le problème pourrait provenir de la stack IP de l’IPX800 V4, cette dernière datant de la sortie de l’IPX.
Je ne pense malheureusement pas qu’une amélioration soit possible à ce niveau car les évolutions sur l’IPX800 V4 sont stoppées depuis la sortie de l’IPX8001 V5 (qui possède une nouvelle stack IP).
D’où ma remarque sur le manque de « motivation » sur la mise en place d’un correctif sur un produit remplacé commercialement (par l’ipx800v5).
Ce serait bien de donner un maximum d’éléments (schéma réseau, des ip, des vlan, référence du switch ou box dans lesquels les vlan sont paramétrés), difficultés à accéder en lan ou en wan ou les deux ? wifi connecté (piratage de la ligne pour charger du contenu)
Depuis quel matériel est fait la connexion (pc, mac, windows, linux etc)
Avec un max d’éléments il est plus probable pour ceux qui auraient ou les connaissances techniques ou le même matériel voire les deux puissent éventuellement aider à trouver une solution…
Voir peut-être si il est possible de définir du routage inter-vlan pour faciliter le flux…
Le
fait plus penser à une saturation momentanée sur le LAN et il faudrait dans ce cas voir qui sature et pourquoi et on revient au point au dessus => max d’infos
Le problème n’est absolument pas lié au matériel. Nous sommes plusieurs sur le forum à avoir le même problème.
J’ai eu plusieurs matériels et typo différents.
Mes matériels testés sont de marques Mikrotik, Juniper, Cisco et plusieurs kernel Linux 6.x (utilisé en core switch).
Tous les tests ont été fait en filaire (hors wifi) et le problème ne se produit qu’avec l’ipx800v4 (pas le v5 ni tous mes - très - nombreux devices dans la même typo réseau).
Pour ce qui est du piratage ou de la surcharge de mon LAN/WAN, cela me paraît invraisemblable dans mon cas…
Bien entendu le routage (inter-VLAN ou subnet) est indispensable pour faire communiquer le client (browser) et le serveur (ipx). J’ai tenté un contournement en utilisant du NAT (postrouting juste pour voir), pas d’amélioration.
Lorsque j’avais ouvert un ticket (voir la ref précedente), j’avais donné toutes les traces demandées pour aboutir à la réponse finale que j’ai postée précédemment…
Si GCE souhaite d’autres traces, je leur fournirais bien volontiers via le ticket. Je pense que poster des tcpdump ici n’a pas d’intérêt.
Je préfère pas, pour etre honnête, je ne lancerais pas mes équipes sur ce sujet. Ce ticket est clos depuis longtemps et le support sur la v4 est stoppé depuis plusieurs années déja. Ce produit à 10 ans avec une stack de la meme époque.
Au mieux je peux vous proposer une remise sur une V5 mais pour la v4 le résultat est trop incertain pour se lancer.
