Voila mon problème,
 
J'ai des soucis de continuité de service avec le FAI Colt, le problème c'est que le tech me dit "Quand je fait des ping ça fonctionne donc pas de problème" mais moi je m'en fous des ping ce qui m'interesse c'est de tenir une connexion VPN ou RDP plus de 5 minutes d'affilé sans interuption de service.
 
Donc ma question est : Comment, entre 2 site données (le siège en région parisienne et le Datacenter sur paris), puis-je tester et surtout graphé une continuité de service et/ou de flux afin de prouver à colt que la ligne déconne.
 
Merci d'avance pour vos réponses.

Tu peux superviser la ligne en snmp.

Effectivement je n'y avait pas pensé, il faut que je voi avec la personne du datacenter si on peut rajouter la ligne colt sur le nagios.
 
A la base je pose cette quetion car je suis en charge du problème et que les autres ont pas trop le temps de s'en occuper. Tout est possible à condition que je le fasse moi-même ^^

Tu peux voir aussi un test en continu avec iperf pour voir en même temps quel débit tu as, mais il va te manger une partie de la bande passante
 
Avantage : si ton serveur le supporte, tu le mets dans le cron avec les options qui vont bien.

Merci.
 
Le problème n'est pas trop la bande passante, c'est une linge 4 mega synchrone (SDSL). Nan le soucis est une rupture de service dans les flux RDP et VNP et je ne sais pas si le problème est materiel (routeur, lien, ou autre) ou logiciel (Routage, firewall).
 
Le routeur Colt est un Cisco 2900 mais je n'ai pas la main dessus il est la propriété de colt. J'ai juste la main sur notre routeur/firewall et de son coté tout est OK.

Tu devrait vérifier le MTU.

Je ferais cela, mais pourrais-tu approfondir ta pensé et me dire à quoi tu pense ?? Quelle est la taille de la MTU normale ?? Sous quelle taille le VPN et/ou RDP pourrais ne pas fonctionner ??
 
Je vais creuser cette voie de mon coté aussi.
 
Merci

J'ai eu pas mal de soucis avec des clients vpn où j'ai du baisser le MTU des postes clients.
LEs users avaient des déco de temps en temps. Et des gros lags.

 
bonjour
 
nous avons eu le même soucis dans notre société . Nous n'arrivions pas à faire du RDP sur un de nos sites relié par un VPN (réseau Equant) , nous avons été obligé de faire passer le MTU de 1518 à 151 et c'est passé niquel (opération réalisé avec TCPoptimizer)

Tu voulais dire 1510 c'est çà ?

non non c'est bien 151 ...

151 ça paraît vraiment ridicule comme taille de mtu.  
tu peux faire des tests de ping en modifiant la taille de paquet (ping -l), mais ton MTU ne devrait pas descendre en dessous de 1300, sauf cas extrêmes.  
 
avec une telle valeur de MTU, la fragmentation devient quasi systématique, et surcharge ton équipement réseau.  
 
pour la continuité de service, c'est très compliqué de vérifier des pertes de paquets.  
il faut des traces réseaux à chaque extrémité et pouvoir les corréler.
pour le snmp, vu que l'interrogation se fait toutes les 5 minutes, difficile de reproduire le phénomène.  
 
Avec des pings sur une grande période tu dois pouvoir y arriver.

 
Non seulement c'est ridicule, c'est scandaleux.  Ces problèmes sont généralement liés à des équipements qui ne supportent pas la rfc1191, càd des équipements qui bloquent les ICMP Type 3 Code 4 (bloqués au travers d'access-lists ou bien au niveau des firewalls).  Ces problèmes sont assez fréquents sur les grosses architectures à base de tunnels GRE et/ou IPSec (qui permettent de tirer des VPN).
 
A noter que la majorité des PC à notre époque émettent des paquets IP avec le DF bit égal à 1, ce qui signifie que les routeurs n'effectuent quasiment plus d'IP fragmentation; d'ailleurs, c'est pour ça qu'on a créé la rfc1191, on considérait que ce n'est pas le job des routeurs de fragmenter parce que c'est très intensif et qu'il faut allouer bcp de buffer.  D'autre part, lorsqu'un paquet IP est fragmenté, le routeur qui réassemble ne connait la taille du paquet original que lorsqu'il a reçu le dernier fragment, ce qui est un autre challenge de faire le réassemblage sur un noeud qui route.  
 
A noter que sur Cisco, il est possible de faire un "reset" du DF bit en utilisant un route-map.  Ce "quick-and-dirty fix" est quelques fois utilisé dans les grosses entreprises et appliqué à tout le trafic entrant.
 
La méthode générale à ce genre de problème (communément appelé PMTUD Black Hole), consiste à envoyer des ICMP à une destination avec le DF bit à 1 et en augmentant progressivement le payload du champ data des ICMP afin de déterminer la plus petite valeur de MTU le long du chemin (attention au calcul du MTU physique : MTU physique = ICMP Payload + 28 octets).
 
-sb

 
Non seulement c'est ridicule, c'est scandaleux.  X25 fait beaucoup mieux :-)
 
Ces problèmes sont généralement causés par des équipements qui ne supportent pas la rfc1191, càd des équipements qui bloquent les ICMP Type 3 Code 4 (bloqués au travers d'access-lists ou bien au niveau de firewall).  Ces problèmes sont assez fréquents sur les grosses architectures à base de tunnels GRE et/ou IPSec (qui permettent de tirer des VPN).
 
A noter que la majorité des PC à notre époque émettent des paquets IP avec le DF bit égal à 1, ce qui signifie que les routeurs n'effectuent quasiment plus d'IP fragmentation; d'ailleurs, c'est pour ça qu'on a créé la rfc1191, on considérait que ce n'est pas le job des routeurs de fragmenter parce que c'est très intensif et qu'il faut allouer bcp de buffer.  D'autre part, lorsqu'un paquet IP est fragmenté, le routeur qui réassemble ne connait la taille du paquet original que lorsqu'il a reçu le dernier fragment, ce qui est un autre challenge de faire le réassemblage sur un noeud qui route.  
 
A noter que sur Cisco, il est possible de faire un "reset" du DF bit en utilisant un route-map.  Ce "quick-and-dirty fix" est quelques fois utilisé dans les grosses entreprises et appliqué à tout le trafic entrant.  Malheureusement, ça signifie que tout le traffic inspecté par le route-map est "process-switché" et ça va vous bouffer plein de cycles CPU.
 
La méthode générale à ce genre de problème (communément appelé PMTUD Black Hole), consiste à envoyer des ICMP à une destination avec le DF bit à 1 et en augmentant progressivement le payload du champ data des ICMP afin de déterminer la plus petite valeur de MTU le long du chemin (attention au calcul du MTU physique : MTU physique = ICMP Payload + 28 octets).  Lorsque l'équipement (routeur, firewall) qui présente la MTU la plus faible est localisée, il faut s'interroger sur le pourquoi.  Encore une fois, basé sur mon expérience, c'est à 90% lié au blocage des ICMP Type 3 Code 4.  Si la raison n'est pas identifiée (ou si le méchant opérateur ne coopère pas), il faut fixer la MTU sur l'équipement qui route le trafic vers l'opérateur sans bloquer quoi que ce soit (càd pas d'access-list qui blque les ICMP), ou bien régler la MTU des stacks IP des stations (dans la base de registres).
 
-sb

Désolé pour le message en double, je voulais faire un aperçu, j'ai dû merder et poster 2 fois :-(
 
-sb

tu sait que tu peux effacer un des 2 post en double aussi