INTERDATA, Groupe MRV Communications est une Société de près de 50 personnes, spécialisée dans l'intégration et la distribution d'équipements pour réseaux informatiques.
Créée au début des années 1980, lnterdata naît dans une conjoncture où les réseaux informatiques émergent.
La société tire parti de nouvelles données techniques à explorer et acquiert une profonde connaissance du métier. 1988 restera une année stratégique pour Interdata qui choisit alors Wellfleet comme fournisseur et devient son Distributeur exclusif pour l'intégration des premiers routeurs, en FRANCE. Aujourd'hui, Interdata construit de nouveaux partenariats forts avec les plus grands constructeurs et éditeurs notamment dans les pôles sécurité informatique et équipements optiques.
Précurseur des nouvelles technologies et certifiée Expert par la plupart de ses fournisseurs, Interdata apporte à ses clients une forte valeur ajoutée. L'entreprise s'adapte aux besoins du marché et importe ou trouve en FRANCE, des produits innovants pour ses clients.
L'entreprise J3TEL, basée aux ULIS, est filiale à 100% d'Interdata. Dédiée au test, à l'analyse et à la mesure de performances des réseaux, J3TEL joue un rôle essentiel dans le Groupe et fournit un solide appui à INTERDATA dans son activité d'intégrateur.
[...] En effet, le tunnel peut être monté en passant par le routeur R1 et R3 mais également entre R2 et R3. Le choix de la compression par un tunnel ou par un autre se fera selon 3 critères : - le seuil maximal établi pour la perte de paquets (si trop de données sont perdues, un basculement d'un tunnel vers un autre dirigera les données à transmettre) - selon la QOS mise en place (les plus prioritaires passent par le tunnel primaire et le reste vers le secondaire) - un seuil de latence (si la latence du lien dépasse 80ms, les données sont basculées sur le tunnel secondaire) 6.7.4.4.1 Les tests de répartition de charge du client 6.7.4.4.1.1 Objectif Le principal but du client est d'émuler un partage de charge en créant deux tunnels distincts par équipement afin de valider la possibilité des boîtiers à s'adapter aux architectures de haute disponibilité proposée par son fournisseur d'accès Internet. [...]
[...] Concernant les applications types Exchange, http, CIFS, ces protocoles sont retardés par TCP par les délais pris par les RTT. L'accélération CIFS a lieu entre deux WX et les systèmes d'exploitation Windows les plus récents à savoir Win 2000, XP et 2003 (serveurs et clients). Le nom de l'accélération de ce type de protocole est Application Flow Acceleration. Le CIFS fonctionne avec des messages allant du client vers le serveur et toutes les machines peuvent être cliente ou serveur. Ce protocole est très bavard car il envoie beaucoup de requêtes en attente de réponses des clients. [...]
[...] Une option dans le WX permet de propager la défaillance d'une interface d'un équipement sur l'autre (schéma 6.7.4.2.a). Cela permet dans le cas où l'une ou l'autre interface tombe en panne tout l'équipement se comporte comme un fil et le spanning-tree converge pour bloquer un port afin d'éviter la boucle réseau Cependant cette option ne résout pas tout le problème étant donné qu'il en créer un autre. En effet, répertorié comme un bug par Juniper, la propagation d'erreur associée à un port forcé en vitesse (100Mb/s) et en mode (full-duplex) fait planter l'équipement réseau connecté directement à l'équipement. [...]
[...] Concrètement, suivant le schéma 6.7.5.2.b, le sous-réseau 1 sera annoncé par le « virtual endpoint » situé en coupure de réseau du site. Ainsi le trafic d'un site avec WX vers ce sous réseau pourra être maîtrisé par l'utilisation d'une politique de QOS (mise en place de garantie de bande passante, de maximum autorisé par application mais également des algorithmes de gestion de file d'attente). Malgré cela, il n'est pas possible de faire de la compression vers le sous réseau 1 étant donné qu'aucun équipement physique n'est disposé à décompresser et compresser le trafic vers un site distant. [...]
[...] A partir de là, il faut affecter chaque application à une classe. Par exemple, il est intéressant de créer une classe « haute disponibilité » et y mettre toutes les applications critiques (que ce soit au niveau temps de latence et perte de paquets). Ensuite, il faut affecter (si besoin) un minimum et/ou maximum de bande passante pour une classe spécifique. Il est possible d'allouer jusqu'à 80% de la totalité de la bande passante de garantie restant pour « other traffic »). [...]
Lecture en ligne
avec notre liseuse dédiée !Contenu vérifié
par notre comité de lecture