Version complète: Packet Loss De Neuf à Neuf....
Il y a du packet loss dans l'air du Neuf vers www.neuf.fr .....
Pas plus www.neuf.fr que www.orange.com ne sont pingables... donc host unreachable est normal.
Je ne parlais pas de ping mais de Packet Loss (perte de paquets).
voir colonne "PL%" .
voir colonne "PL%" .
Bonjour,
Je serai tenté de dire :
- soit un problème réseau
- ou plus certainement le fait que ces routeurs sont paramétrés pour ne pas répondre en priorité à tous les pings pour justemenet éviter une saturation et une bonne QoS
Je serai tenté de dire :
- soit un problème réseau
- ou plus certainement le fait que ces routeurs sont paramétrés pour ne pas répondre en priorité à tous les pings pour justemenet éviter une saturation et une bonne QoS
Il s'agit d'un problème réseau car inhabituel.
Un packet loss de 80% sur certains serveurs Neuf bien identifiés est anormal !!!!!!
voir 157.178.96-84.rev.gaoland.net [84.96.178.157]
Un packet loss de 80% sur certains serveurs Neuf bien identifiés est anormal !!!!!!
voir 157.178.96-84.rev.gaoland.net [84.96.178.157]
Des routeurs ou des DSLAM qui ont pris le chaud ou l'orage ? Je ne constate pas de mon côté de perte de paquets vers les destinations indiquées (0% de perte de paquets sur 84.96.178.157)
Il faut targeter un noeud plus loin pour le mettre en évidence:
54.176.96-84.rev.gaoland.net [84.96.176.54]
165.178.96-84.rev.gaoland.net [84.96.178.165]
157.178.96-84.rev.gaoland.net [84.96.178.157]
V4075.par1-co-2.n9uf.net [62.39.148.78]
54.176.96-84.rev.gaoland.net [84.96.176.54]
165.178.96-84.rev.gaoland.net [84.96.178.165]
157.178.96-84.rev.gaoland.net [84.96.178.157]
V4075.par1-co-2.n9uf.net [62.39.148.78]
Problème packet loss: 157.178.96-84.rev.gaoland.net [84.96.178.157]
Qui est responsable de ce matériel défecteux:
Qui est responsable de ce matériel défecteux:
- Information related to '84.96.169.0 - 84.96.185.255'
inetnum: 84.96.169.0 - 84.96.185.255
netname: N9UF-INFRA
mnt-by: LDCOM-MNT
role: LDCOM Legal Contact
address: neuf telecom
CITATION(mickey19 @ Samedi 29 Juillet 2006 À 13:09) 
ou plus certainement le fait que ces routeurs sont paramétrés pour ne pas répondre en priorité à tous les pings pour justemenet éviter une saturation et une bonne QoS
Heureusement d'ailleurs. C'est fait pour eviter les petits malins qui pings des routeurs à tout va....
Sinon, il y aurait de gros deny de services....
Encore une fois, il ne s'agit pas d'un problème de ping qui est même très bon.
Il n'y a pas besoin de beaucoup de paquets pour juste faire un ping !
Les pertes de paquets (packet loss) impactent la qualité en VoIP.
Des pertes de paquets sont rarement dues à un réglage (!!) mais plutôt à un problème sur un équipement.
A qui doit-on demander de regarder ce qui se passe sur celui-ci: 157.178.96-84.rev.gaoland.net [84.96.178.157] ?
S'il s'agit vraiment d'un réglage, c'est l'accasion de le refaire pour ne plus perdre de paquets !!
Une valeur de 80% de perte est totalement anormale.
Il n'y a pas besoin de beaucoup de paquets pour juste faire un ping !
Les pertes de paquets (packet loss) impactent la qualité en VoIP.
Des pertes de paquets sont rarement dues à un réglage (!!) mais plutôt à un problème sur un équipement.
A qui doit-on demander de regarder ce qui se passe sur celui-ci: 157.178.96-84.rev.gaoland.net [84.96.178.157] ?
S'il s'agit vraiment d'un réglage, c'est l'accasion de le refaire pour ne plus perdre de paquets !!
Une valeur de 80% de perte est totalement anormale.
Explique alors pourquoi un ping direct ne fait pas apparaître de problème (0% de pertes de paquets sur une trentaine envoyés) 
Pour moi et comme confirmé par Manuel_9T, c'est voulu pour éviter/se prémunir contre une attaque DoS (par exemple)(d'ailleurs free fait pareil sur son routeur, ainsi qu'à l'interconnexion 9T/free)
Le routage droppe certains paquets selon des critères probablement mûrement étudiés
PS : la voip n'est probablement pas impactée par des paquets droppés lors d'un ping (la voip ne circule pas avec une entête ICMP
)
Pour moi et comme confirmé par Manuel_9T, c'est voulu pour éviter/se prémunir contre une attaque DoS (par exemple)(d'ailleurs free fait pareil sur son routeur, ainsi qu'à l'interconnexion 9T/free)
Le routage droppe certains paquets selon des critères probablement mûrement étudiés
PS : la voip n'est probablement pas impactée par des paquets droppés lors d'un ping (la voip ne circule pas avec une entête ICMP
)
CITATION(mickey19 @ Samedi 29 Juillet 2006 À 21:44)
Explique alors pourquoi un ping direct ne fait pas apparaître de problème (0% de pertes de paquets sur une trentaine envoyés)
Ca semble évident.
C'est lors de l'operation de forward des paquets qui arrivent vers un autre noeud qu'on peut compter les pertes de paquets.
Les mesures que j'ai fournies ci-dessus sont très explicites.
Juste un ping sur l'équipement incriminé positionné en point final ne permet donc pas cette mesure de perte spécifiquement pour l'équipement suspecté, puisque les paquets ne font qu'arriver, sans être traités.
La requête ping est forcément traitée par le routeur, il faut bien qu'il renvoie un paquet vers ta machine pour que tu saches qu'elle est up... donc le routeur n'est probablement pas surchargé vu qu'il répond.
Tout dépend de la façon dont ce qui te sert à calculer le nombre de paquets droppés procède... certainement pas un ping echo tout bête (qui lui renvoie un 0% de droppés) mais un autre type de paquets (où une règle drop existe) : un petit coup d'ethereal pour confirmer ou infirmer
PS : il est cependant envisageable qu'effectivement un problème existe, mais je n'y crois pas trop (ça n'engage que moi )
Tout dépend de la façon dont ce qui te sert à calculer le nombre de paquets droppés procède... certainement pas un ping echo tout bête (qui lui renvoie un 0% de droppés) mais un autre type de paquets (où une règle drop existe) : un petit coup d'ethereal pour confirmer ou infirmer
PS : il est cependant envisageable qu'effectivement un problème existe, mais je n'y crois pas trop (ça n'engage que moi
)
Mais ce n'est pas le microscopique paquet qu'est le ping qui revient vers le point d'émission qui est intéressant pour savoir si des paquets se perdent en route.
Ce qui est important sont les paquets qui transitent du point de départ jusqu'au point final.
C'est à ça que sert cette mesure de perte de paquets.
La mesure de perte est le plus souvent globale du point de départ vers le point final, mais là, je pointe l'équipement qui provoque ces pertes.
Comme le Neuf fait de la VoIP, j'espère que ça n'étonne personne qui connait un peu la VoIP.
Ce qui est important sont les paquets qui transitent du point de départ jusqu'au point final.
C'est à ça que sert cette mesure de perte de paquets.
La mesure de perte est le plus souvent globale du point de départ vers le point final, mais là, je pointe l'équipement qui provoque ces pertes.
Comme le Neuf fait de la VoIP, j'espère que ça n'étonne personne qui connait un peu la VoIP.
Je ne suis pas informaticien : c'est juste une hypothèse (celle d'une règle de filtrage) qui me semble a priori pouvoir expliquer le nombre de paquets perdus (à partir de mes modestes connaissances en réseaux informatiques).
Evidemment je serai heureux que quelqu'un de 9T ou autre vienne nous expliquer exactement la vraie origine de cette constatation (panne ou non) . C'est toujours intéressant d'apprendre
Evidemment je serai heureux que quelqu'un de 9T ou autre vienne nous expliquer exactement la vraie origine de cette constatation (panne ou non) . C'est toujours intéressant d'apprendre
Ca ressemble à un équipement surchargé / sous-dimensionné, ou à une erreur de réglage type MTU sur cet équipement.
Lorsque des paquets son perdus, l'émetteur doit renvoyer ces paquets ce qui joue donc sur le débit et sur la qualité VoIP qui supporte très mal des pertes de paquets dont la conséquence sera de l'écho et/ou du hachurage des conversations.
Enfin, avec l'adresse exacte de la machine incriminée, si un responsable réseau ne peut pas analyser et expliquer, ce serait quand-même inquiétant.
Si ces pertes sont volontaires, c'est du sabotage !
Précision: en cas de perte de paquets, il seront retransmis en protocole TCP, mais pas en UDP (utilisé par la VoIP) !!
Donc perte de paquets = perte de qualité en VoIP.
_________
7.2 - Perte de paquets
Lorsque les buffers des différents élément réseaux IP sont congestionnés, ils « libèrent » automatiquement de la bande passante en se débarrassant d'une certaine proportion des paquets entrant, en fonction de seuils prédéfinis. Cela permet également d'envoyer un signal implicite aux terminaux TCP qui diminuent d'autant leur débit au vu des acquittements négatifs émis par le destinataire qui ne reçoit plus les paquets. Malheureusement, pour les paquets de voix, qui sont véhiculés au dessus d'UDP, aucun mécanisme de contrôle de flux ou de retransmission des paquets perdus n'est offert au niveau du transport.
Si aucun mécanisme performant de récupération des paquets perdus n'est mis en place (cas le plus fréquent dans les équipements actuels), alors la perte de paquet IP se traduit par des ruptures au niveau de la conversation et une impression de hachure de la parole. Cette dégradation est bien sûr accentuée si chaque paquet contient un long temps de parole (plusieurs trames de voix de paquet).
Enfin connaître le pourcentage de perte de paquets sur une liaison n'est pas suffisant pour déterminer la qualité de la voix que l'on peut espérer, mais cela donne une bonne approximation. En effet, un autre facteur essentiel intervient; il s'agit du modèle de répartition de cette perte de paquets, qui peut être soit « régulièrement » répartie, soit répartie de manière corrélée, c'est à dire avec des pics de perte lors des phases de congestion, suivies de phases moins dégradées en terme de QoS.
Lorsque des paquets son perdus, l'émetteur doit renvoyer ces paquets ce qui joue donc sur le débit et sur la qualité VoIP qui supporte très mal des pertes de paquets dont la conséquence sera de l'écho et/ou du hachurage des conversations.
Enfin, avec l'adresse exacte de la machine incriminée, si un responsable réseau ne peut pas analyser et expliquer, ce serait quand-même inquiétant.
Si ces pertes sont volontaires, c'est du sabotage !
Précision: en cas de perte de paquets, il seront retransmis en protocole TCP, mais pas en UDP (utilisé par la VoIP) !!
Donc perte de paquets = perte de qualité en VoIP.
_________
7.2 - Perte de paquets
Lorsque les buffers des différents élément réseaux IP sont congestionnés, ils « libèrent » automatiquement de la bande passante en se débarrassant d'une certaine proportion des paquets entrant, en fonction de seuils prédéfinis. Cela permet également d'envoyer un signal implicite aux terminaux TCP qui diminuent d'autant leur débit au vu des acquittements négatifs émis par le destinataire qui ne reçoit plus les paquets. Malheureusement, pour les paquets de voix, qui sont véhiculés au dessus d'UDP, aucun mécanisme de contrôle de flux ou de retransmission des paquets perdus n'est offert au niveau du transport.
Si aucun mécanisme performant de récupération des paquets perdus n'est mis en place (cas le plus fréquent dans les équipements actuels), alors la perte de paquet IP se traduit par des ruptures au niveau de la conversation et une impression de hachure de la parole. Cette dégradation est bien sûr accentuée si chaque paquet contient un long temps de parole (plusieurs trames de voix de paquet).
Enfin connaître le pourcentage de perte de paquets sur une liaison n'est pas suffisant pour déterminer la qualité de la voix que l'on peut espérer, mais cela donne une bonne approximation. En effet, un autre facteur essentiel intervient; il s'agit du modèle de répartition de cette perte de paquets, qui peut être soit « régulièrement » répartie, soit répartie de manière corrélée, c'est à dire avec des pics de perte lors des phases de congestion, suivies de phases moins dégradées en terme de QoS.
Bonjour Diorser
Lorsque vous citez des textes, merci d'en citer les sources.
C'est une obligation, je vous laisse jusqu'à ce soir pour les mentionner, sinon je supprime
Lorsque vous citez des textes, merci d'en citer les sources.
C'est une obligation, je vous laisse jusqu'à ce soir pour les mentionner, sinon je supprime
Il s'agit d'information hyper classique et connue pour des spécialistes réseau.
Mais vue les questions ou remarques, il est peut-être préférable de donner le lien plus complet:
www.frameip.com/voip/
En espérant que le ping ne sera plus confondu avec perte de paquets !
Mais vue les questions ou remarques, il est peut-être préférable de donner le lien plus complet:
www.frameip.com/voip/
En espérant que le ping ne sera plus confondu avec perte de paquets !
Mais rien ne dit que la perte de paquets mesurée par tes soins corresponde à celle qui serait observée pour des paquets "VoIP"
PS: que celui (ou ceux) qui confond(ent) pertes de paquets et ping se dénonce(nt) ... ah ben personne ne répond... y'a quelqu'un... elqu'un.... qu'un... un......
PS: que celui (ou ceux) qui confond(ent) pertes de paquets et ping se dénonce(nt) ... ah ben personne ne répond... y'a quelqu'un... elqu'un.... qu'un... un......
Ta remarque est surprenante car déjà expliquée plus haut.
En gros, un paquet de bits perdu est totalement indépendant du contenu d'information transportée ! Un bit est juste un O ou un 1.
Le protocole TCP permet l'dentification du paquet perdu et demandera une réémission.
Le protocle UDP ne voit pas les paquets perdus, qui sont perdus à jamais.
Si, plus à titre personnel, tu souhaites mieux comprendre les protocoles TCP ou UDP que ni moi, ni le Neuf n'avons inventés, je te recommande la lecture des liens suivants pour mieux comprendre: TCP , UDP , VoIP (SIP et H323) .
Pour recentrer le sujet sur la question initiale relative à la perte de paquets sur des équipements du Neuf, seul un technicien de ce réseau (Neuf ou LDCOM ?) pourra analyser et expliquer un taux de perte jusqu'à 80% de paquets sur les noeuds identifiés.
En gros, un paquet de bits perdu est totalement indépendant du contenu d'information transportée ! Un bit est juste un O ou un 1.
Le protocole TCP permet l'dentification du paquet perdu et demandera une réémission.
Le protocle UDP ne voit pas les paquets perdus, qui sont perdus à jamais.
Si, plus à titre personnel, tu souhaites mieux comprendre les protocoles TCP ou UDP que ni moi, ni le Neuf n'avons inventés, je te recommande la lecture des liens suivants pour mieux comprendre: TCP , UDP , VoIP (SIP et H323) .
Pour recentrer le sujet sur la question initiale relative à la perte de paquets sur des équipements du Neuf, seul un technicien de ce réseau (Neuf ou LDCOM ?) pourra analyser et expliquer un taux de perte jusqu'à 80% de paquets sur les noeuds identifiés.
Je n'arriverai donc pas à me faire comprendre... ce que je suppose est qu'un paquet perdu peut l'être car l'équipement est surchargé et donc ne peut pas y répondre (pas de ressources physiques), ou bien alors car l'équipement ne veut pas y répondre car il a été programmé ainsi pour certains paquets. Et pour l'instant aucune des explications données ne la met en défaut, à moins que je comprenne mal
PS : en supposant qu'effectivement 80 % de pertes de paquets influeraient quoi qu'il arrive sur la voip, elle serait inexploitable... tu n'aurais que 1/5ème de la conversation, c'est même plus du hachage à ce niveau Mais une explication officielle est toujours la bienvenue
PS : en supposant qu'effectivement 80 % de pertes de paquets influeraient quoi qu'il arrive sur la voip, elle serait inexploitable... tu n'aurais que 1/5ème de la conversation, c'est même plus du hachage à ce niveau
Mais une explication officielle est toujours la bienvenue
CITATION(mickey19 @ Lundi 31 Juillet 2006 À 10:24)
en supposant qu'effectivement 80 % de pertes de paquets influeraient quoi qu'il arrive sur la voip,
Ce n'est pas une hypothèse mais c'est un fait.
Tu n'as pas encore suffisamment lu les liens que je t'ai proposés.
J'ai bien compris que tu n'es pas informaticien.
Sincèrement, je ne pense pas que ce forum Neuf soit le bon endroit pour te former au TCP, à l'UDP ou VoIP.
Tu peux essayer plutôt ici.
Pour ce fil, contentons-nous modestement de trouver la réponse à la question initiale.
CITATION(Diorser @ Lundi 31 Juillet 2006 À 10:37)
Pour ce fil, contentons-nous modestement de trouver la réponse à la question initiale.
http://moncompte.neuf.fr/extranet/servlet/...;action=contact
C'est gratuit
La réponse recherchée n'a rien de spécifique à un compte, mais est générique pour tous les flux transitants par le serveur ou relais 157.178.96-84.rev.gaoland.net [84.96.178.157] .
C'est l'adresse de contact du service client (technique ou commercial) de chez 9T... tu peux tout à fait les contacter par là si tu veux une réponse (rapide) d'un technicien 9T.
CITATION(Diorser @ Lundi 31 Juillet 2006 À 10:42)
La réponse recherchée n'a rien de spécifique à un compte, mais est générique pour tous les flux transitants par le serveur ou relais 157.178.96-84.rev.gaoland.net [84.96.178.157] .
Attention a bien comprendre le traceroute qui a été fait.
Aucun paquet n'est perdu entre la source et la destination. Les pertes de paquets que l'on peut voir sur les routeurs (essentiellement des routeurs de coeur) sont dut a des protections. Les équipements d'opérateurs possèdent tous des protections pour éviter que la CPU des routeurs ne passe sont temps a traiter des requètes secondaires (types TTL exceded).
le fait que des routeurs perdent des paquets n'indique en rien une saturation du routeur mais seulement que le nombre de TTL exceded traité par le routeur a un instant T dépasse le seuil qui a été configuré.
La seule ligne interessante en terme de paquets perdu dans un traceroute est la derniere (celle de la destination finale)
Si cette hypothèse est vérifiée, il reste surprenant que seulement quelques équipements bien identifiés aient ce comportement (je n'avais jamais remarqué ce problème de perte de paquets avant).
Il resterait à clarifier si ce non traitement "volontaire" des TTL est un réglage délibéré, ou plutôt un signe de saturation du CPU du routeur en question, qui ne traiterait les TTLs qu'en seconde priorité.
Ne pas traiter les TTLs doit aussi avoir d'autres conséquences indésirables, car si le traitement TTL ne servait vraiment à rien, il serait supprimé sur tous les équipements pour alléger le traitement CPU.
Il resterait à clarifier si ce non traitement "volontaire" des TTL est un réglage délibéré, ou plutôt un signe de saturation du CPU du routeur en question, qui ne traiterait les TTLs qu'en seconde priorité.
Ne pas traiter les TTLs doit aussi avoir d'autres conséquences indésirables, car si le traitement TTL ne servait vraiment à rien, il serait supprimé sur tous les équipements pour alléger le traitement CPU.
Le TTL exceded sert a signifier a l'utilisateur que le chemin est plus long que ce que peut supporter le paquet. Il peut servir à détecter une boucle de routage. Dans ce cas, celle-ci dur assez longtemps pour que des "non réponse" de certains routeurs n'empêchent pas cette détection.
Il est normal et facilement explicable que seul certains routeurs aient ce comportement : Les limitations sont mise en nombre de paquets traités par secondes. Les TTL exceded sont disparates sur le réseau donc à un instant T seul certain routeurs atteignent le seuil. A T+1 ce sera probablement d’autre. De plus les routeurs qui sont sur un plus grand nombre de chemin doivent logiquement traiter plus de ce type de paquet et donc en ignorer plus souvent.
La non réponse des routeurs est donc quelque chose de courrant sur des équipements réseaux et ne signifie en rien la moindre saturation.
Il est normal et facilement explicable que seul certains routeurs aient ce comportement : Les limitations sont mise en nombre de paquets traités par secondes. Les TTL exceded sont disparates sur le réseau donc à un instant T seul certain routeurs atteignent le seuil. A T+1 ce sera probablement d’autre. De plus les routeurs qui sont sur un plus grand nombre de chemin doivent logiquement traiter plus de ce type de paquet et donc en ignorer plus souvent.
La non réponse des routeurs est donc quelque chose de courrant sur des équipements réseaux et ne signifie en rien la moindre saturation.
Possible...
Mais il est quand-même surprenant que seuls certains équipements du Neuf semblent avoir cette bizarrerie...
"Le TTL exceeded sert a signifier a l'utilisateur que le chemin est plus long que ce que peut supporter le paquet."
Ben oui justement, il y a bien un équipement qui attend une réponse conformément à un protocole, et qui ne l'obtient pas.
Je ne sais pas si supprimer les réponses TTLs est bien standard, ou plutôt une lberté prise par un opérateur réseau....
Mais il est quand-même surprenant que seuls certains équipements du Neuf semblent avoir cette bizarrerie...
"Le TTL exceeded sert a signifier a l'utilisateur que le chemin est plus long que ce que peut supporter le paquet."
Ben oui justement, il y a bien un équipement qui attend une réponse conformément à un protocole, et qui ne l'obtient pas.
Je ne sais pas si supprimer les réponses TTLs est bien standard, ou plutôt une lberté prise par un opérateur réseau....
CITATION(Diorser @ Lundi 31 Juillet 2006 À 10:37)
Ce n'est pas une hypothèse mais c'est un fait.
Tu n'as pas encore suffisamment lu les liens que je t'ai proposés.
J'ai bien compris que tu n'es pas informaticien.
Sincèrement, je ne pense pas que ce forum Neuf soit le bon endroit pour te former au TCP, à l'UDP ou VoIP.
Tu peux essayer plutôt ici.
Pour ce fil, contentons-nous modestement de trouver la réponse à la question initiale.
Tu n'as pas encore suffisamment lu les liens que je t'ai proposés.
J'ai bien compris que tu n'es pas informaticien.
Sincèrement, je ne pense pas que ce forum Neuf soit le bon endroit pour te former au TCP, à l'UDP ou VoIP.
Tu peux essayer plutôt ici.
Pour ce fil, contentons-nous modestement de trouver la réponse à la question initiale.
Tu es peut-être informaticien mais ça n'empêche visiblement pas de raconter n'importe quoi.
Par mesure de protection, les routeurs du réseau neuf traitent un nombre limité de TTL exceeded.
Il ne s'agit pas du tout de paquets perdus.
(cf documentation traceroute, ça sera plus profitable que de copier-coller de la littérature hors-sujet sur la VoIP)
Si il y avait réellement des pertes de paquets, tu aurais du mal à pinger les machine situées en aval de ce routeur. Or, ça n'est pas le cas.
CITATION(plpl @ Lundi 31 Juillet 2006 À 12:45)
Tu es peut-être informaticien mais ça n'empêche visiblement pas de raconter n'importe quoi.
Par mesure de protection, les routeurs du réseau neuf traitent un nombre limité de TTL exceeded.
Il ne s'agit pas du tout de paquets perdus.
(cf documentation traceroute, ça sera plus profitable que de copier-coller de la littérature hors-sujet sur la VoIP)
Si il y avait réellement des pertes de paquets, tu aurais du mal à pinger les machine situées en aval de ce routeur. Or, ça n'est pas le cas.
Par mesure de protection, les routeurs du réseau neuf traitent un nombre limité de TTL exceeded.
Il ne s'agit pas du tout de paquets perdus.
(cf documentation traceroute, ça sera plus profitable que de copier-coller de la littérature hors-sujet sur la VoIP)
Si il y avait réellement des pertes de paquets, tu aurais du mal à pinger les machine situées en aval de ce routeur. Or, ça n'est pas le cas.
pas mieux
CITATION(ungrim @ Lundi 31 Juillet 2006 À 14:22)
Le TTL exceded sert a signifier a l'utilisateur que le chemin est plus long que ce que peut supporter le paquet. Il peut servir à détecter une boucle de routage. Dans ce cas, celle-ci dur assez longtemps pour que des "non réponse" de certains routeurs n'empêchent pas cette détection.
Il est normal et facilement explicable que seul certains routeurs aient ce comportement : Les limitations sont mise en nombre de paquets traités par secondes. Les TTL exceded sont disparates sur le réseau donc à un instant T seul certain routeurs atteignent le seuil. A T+1 ce sera probablement d’autre. De plus les routeurs qui sont sur un plus grand nombre de chemin doivent logiquement traiter plus de ce type de paquet et donc en ignorer plus souvent.
La non réponse des routeurs est donc quelque chose de courrant sur des équipements réseaux et ne signifie en rien la moindre saturation.
Il est normal et facilement explicable que seul certains routeurs aient ce comportement : Les limitations sont mise en nombre de paquets traités par secondes. Les TTL exceded sont disparates sur le réseau donc à un instant T seul certain routeurs atteignent le seuil. A T+1 ce sera probablement d’autre. De plus les routeurs qui sont sur un plus grand nombre de chemin doivent logiquement traiter plus de ce type de paquet et donc en ignorer plus souvent.
La non réponse des routeurs est donc quelque chose de courrant sur des équipements réseaux et ne signifie en rien la moindre saturation.
Merci pour cette réponse éclairée, je pense avoir saisi le principe
Il n'y a donc pas de craintes à avoir, c'est bien une protection comme cela l'avait été supposé.
@plpl
Tu n'as visiblement pas tout lu le fil pour en comprendre la chronologie.
Le sujet VoIP n'était pas "hors sujet" car il permettait d'expliquer à mikey la différence de l'importance de perdre des paquets en protocole TCP, ou UDP utilisé pour la VoIP.
Si tu as les réponses aux questions soulevées, inutile de le faire avec agressivité d'autant plus inutile que tu ne sembles pas encore lu la réponse de ungrim.
Quand on pose une question sur un forum, c'est justement qu'on a pas la réponse et qu'on cherche à comprendre.
Keep cool.
Tu n'as visiblement pas tout lu le fil pour en comprendre la chronologie.
Le sujet VoIP n'était pas "hors sujet" car il permettait d'expliquer à mikey la différence de l'importance de perdre des paquets en protocole TCP, ou UDP utilisé pour la VoIP.
Si tu as les réponses aux questions soulevées, inutile de le faire avec agressivité d'autant plus inutile que tu ne sembles pas encore lu la réponse de ungrim.
Quand on pose une question sur un forum, c'est justement qu'on a pas la réponse et qu'on cherche à comprendre.
Keep cool.
Quand on pose une question sur un forum, il faut aussi savoir écouter les réponses de ses interlocuteurs pour leur répondre convenablement (et non à côté de la plaque) pour essayer de trouver une réponse constructive...
A bon entendeur
PS : il n'est pas interdit de remercier les gens qui ont répondu à ta question (plutôt que de les "agresser") <_<
A bon entendeur
PS : il n'est pas interdit de remercier les gens qui ont répondu à ta question (plutôt que de les "agresser") <_<
Alors.... Spécialement pour notre pro du routage IP, voici la commande responsable de ce phénomène sur les routeurs du coeur de réseau : mls rate-limit all ttl-failure 20 1
Comme celui-ci connait les routeurs Cisco par coeur, il comprendra sans mal le fonctionnement, et le résultat de cette commande sur un routeur....
Pour les autres, je me ferait un plaisir de détailler à la demande...
Comme celui-ci connait les routeurs Cisco par coeur, il comprendra sans mal le fonctionnement, et le résultat de cette commande sur un routeur....
Pour les autres, je me ferait un plaisir de détailler à la demande...
Merci à ton pro du réseau du neuf pour l'info !
S'il s'agit d'équipements cisco, il doit s'agir de ce problème: TTL=1 and Cisco CPU Usage
S'il s'agit d'équipements cisco, il doit s'agir de ce problème: TTL=1 and Cisco CPU Usage
Ah !!!.. Quand même....
Et donc ceci a pour effet que lorsque le routeur jette un paquet pour cause de TTL=1, il n'envoie pas systématiquement le paquet ICMP (N°11, TTL-exceeded), ce qui a pour effet de faire croire que le routeur a un problème lors d'un traceroute => ceci n'a aucune incidence sur le trafic IP utile....
Et donc ceci a pour effet que lorsque le routeur jette un paquet pour cause de TTL=1, il n'envoie pas systématiquement le paquet ICMP (N°11, TTL-exceeded), ce qui a pour effet de faire croire que le routeur a un problème lors d'un traceroute => ceci n'a aucune incidence sur le trafic IP utile....
Sounds clear now.... bien que troublant quand on ne connait pas ce problème spécifique Cisco.Sinon, j'avais un téléphone en réserve en cas de coup dur en UDP.
CITATION(Diorser @ Jeudi 03 Août 2006 À 15:47)
... quand on ne connait pas ce problème spécifique Cisco.
Euh.... Rien de spécifique à Cisco... Juste un moyen de protection d'un système en réseau....
CITATION(Diorser @ Jeudi 03 Août 2006 À 15:47)
Sounds clear now.... bien que troublant quand on ne connait pas ce problème spécifique Cisco.
Mais bon sang de bois ça n'est pas un problème.
Tout le monde se tue à essayer de t'expliquer que c'est fait exprès et que c'est configuré ainsi exprès.
Ca fonctionne très bien au contraire
Ceci est une version "bas débit" de Justneuf. Pour voir la version complète avec plus d'information, la mise en page et les images, veuillez cliquer ici.