Bonjour,
A quelle endroit est donc contrôlé le checksum d'en-tête d'un datagramme
IP
?
A chaque traversée de routeur ou à la destination finale.
Plus précisément :
- Avant de recalculer le checksum avec le TTL décrémenté, le routeur
intermédiaire contrôle-t-il le checksum entrant ?
- Que fait-il s'il trouve une erreur : la datagramme va-t-il à la poubelle
?
le checksum est remis en cohérence avec l'en-tête du datagramme entrant
(avec incrémentation d'un compteur d'erreurs) ?
Amis routiers ou mélomanes de l'IP, merci pour vos avis sur la question.
Bonjour,
A quelle endroit est donc contrôlé le checksum d'en-tête d'un datagramme
IP
?
A chaque traversée de routeur ou à la destination finale.
Plus précisément :
- Avant de recalculer le checksum avec le TTL décrémenté, le routeur
intermédiaire contrôle-t-il le checksum entrant ?
- Que fait-il s'il trouve une erreur : la datagramme va-t-il à la poubelle
?
le checksum est remis en cohérence avec l'en-tête du datagramme entrant
(avec incrémentation d'un compteur d'erreurs) ?
Amis routiers ou mélomanes de l'IP, merci pour vos avis sur la question.
Bonjour,
A quelle endroit est donc contrôlé le checksum d'en-tête d'un datagramme
IP
?
A chaque traversée de routeur ou à la destination finale.
Plus précisément :
- Avant de recalculer le checksum avec le TTL décrémenté, le routeur
intermédiaire contrôle-t-il le checksum entrant ?
- Que fait-il s'il trouve une erreur : la datagramme va-t-il à la poubelle
?
le checksum est remis en cohérence avec l'en-tête du datagramme entrant
(avec incrémentation d'un compteur d'erreurs) ?
Amis routiers ou mélomanes de l'IP, merci pour vos avis sur la question.
http://frameip.dyndns.org/index.php?argument1=enteteip&argument2V532&argum
ent36535#3.10_-_Checksum
le checksum est remis en cohérence avec l'en-tête du datagramme entrant
(avec incrémentation d'un compteur d'erreurs) ?
Si il entre avec un bad checksum c'est que le paquet n'est plus valide. Ca
serait donc une erreur de recalculer le checsum et de router la trame. Car
dans ce cas, le routeur rendrait un paquet faussé avec un checksum calculé
sur l'erreur.
http://frameip.dyndns.org/index.php?argument1=enteteip&argument2V532&argum
ent36535#3.10_-_Checksum
le checksum est remis en cohérence avec l'en-tête du datagramme entrant
(avec incrémentation d'un compteur d'erreurs) ?
Si il entre avec un bad checksum c'est que le paquet n'est plus valide. Ca
serait donc une erreur de recalculer le checsum et de router la trame. Car
dans ce cas, le routeur rendrait un paquet faussé avec un checksum calculé
sur l'erreur.
http://frameip.dyndns.org/index.php?argument1=enteteip&argument2V532&argum
ent36535#3.10_-_Checksum
le checksum est remis en cohérence avec l'en-tête du datagramme entrant
(avec incrémentation d'un compteur d'erreurs) ?
Si il entre avec un bad checksum c'est que le paquet n'est plus valide. Ca
serait donc une erreur de recalculer le checsum et de router la trame. Car
dans ce cas, le routeur rendrait un paquet faussé avec un checksum calculé
sur l'erreur.
Merci Sébastien pour ces commentaires,
http://frameip.dyndns.org/index.php?argument1=enteteip&argument2V532&argum
Le lien n'est pas accessible en ce moment, c'est peut-être temporaire. Je
n'arrive plus non plus à accéder sur la page d'accueil.
Oui ! c'est très sentimental, il va falloir vérifier dans les RFC si cela
est bien explicité.
Quelques mots sur ce sujet :
(1) Si le contrôle d'erreur est incorrect, le paquet n'est PAS valide.
Cette
assertion est juste, par définition même du contrôle d'erreur qui détecte
si
la trame est valide ou non ! La question est de savoir quelle attitude par
défaut va prendre le routeur, sachant que tout est configurable.
(2) Si le contrôle d'erreur est incorrect, la paquet n'est PLUS valide.
Cette assertion se discute (sentimentalement). Si l'erreur est dans le
champ
TOS ou dans celui des options, le routeur n'a aucune raison de jeter. Mais
par définition, le routeur ne sait pas où se trouve la cause (au moins 1
bit
parmi les 480 maxi).
(3) "ça serait donc une erreur de recalculer le checsum et de router la
trame" Eh bien ! en SDH,
lorsqu'une trame est trouvée erronée (par B2 par
exemple), le contrôle d'erreur est remis en cohérence avec la trame
entrante, un compteur local est incrémenté, le nombre d'erreurs détectés
est
signalé à la source (par M1).
Mais, à la différence de TCP/IP, on est en mode connecté.
(4) IP est transmis (au moins en longue distance) sur SDH.
Le datagramme IP
peut être vérolé dans le réseau SDH, et SDH continue la transmission.
Je vois assez mal le fait que le routeur en sortie de SDH puisse jeter la
trame
minutieusement transmise sur la fibre optique !
Merci Sébastien pour ces commentaires,
http://frameip.dyndns.org/index.php?argument1=enteteip&argument2V532&argum
Le lien n'est pas accessible en ce moment, c'est peut-être temporaire. Je
n'arrive plus non plus à accéder sur la page d'accueil.
Oui ! c'est très sentimental, il va falloir vérifier dans les RFC si cela
est bien explicité.
Quelques mots sur ce sujet :
(1) Si le contrôle d'erreur est incorrect, le paquet n'est PAS valide.
Cette
assertion est juste, par définition même du contrôle d'erreur qui détecte
si
la trame est valide ou non ! La question est de savoir quelle attitude par
défaut va prendre le routeur, sachant que tout est configurable.
(2) Si le contrôle d'erreur est incorrect, la paquet n'est PLUS valide.
Cette assertion se discute (sentimentalement). Si l'erreur est dans le
champ
TOS ou dans celui des options, le routeur n'a aucune raison de jeter. Mais
par définition, le routeur ne sait pas où se trouve la cause (au moins 1
bit
parmi les 480 maxi).
(3) "ça serait donc une erreur de recalculer le checsum et de router la
trame" Eh bien ! en SDH,
lorsqu'une trame est trouvée erronée (par B2 par
exemple), le contrôle d'erreur est remis en cohérence avec la trame
entrante, un compteur local est incrémenté, le nombre d'erreurs détectés
est
signalé à la source (par M1).
Mais, à la différence de TCP/IP, on est en mode connecté.
(4) IP est transmis (au moins en longue distance) sur SDH.
Le datagramme IP
peut être vérolé dans le réseau SDH, et SDH continue la transmission.
Je vois assez mal le fait que le routeur en sortie de SDH puisse jeter la
trame
minutieusement transmise sur la fibre optique !
Merci Sébastien pour ces commentaires,
http://frameip.dyndns.org/index.php?argument1=enteteip&argument2V532&argum
Le lien n'est pas accessible en ce moment, c'est peut-être temporaire. Je
n'arrive plus non plus à accéder sur la page d'accueil.
Oui ! c'est très sentimental, il va falloir vérifier dans les RFC si cela
est bien explicité.
Quelques mots sur ce sujet :
(1) Si le contrôle d'erreur est incorrect, le paquet n'est PAS valide.
Cette
assertion est juste, par définition même du contrôle d'erreur qui détecte
si
la trame est valide ou non ! La question est de savoir quelle attitude par
défaut va prendre le routeur, sachant que tout est configurable.
(2) Si le contrôle d'erreur est incorrect, la paquet n'est PLUS valide.
Cette assertion se discute (sentimentalement). Si l'erreur est dans le
champ
TOS ou dans celui des options, le routeur n'a aucune raison de jeter. Mais
par définition, le routeur ne sait pas où se trouve la cause (au moins 1
bit
parmi les 480 maxi).
(3) "ça serait donc une erreur de recalculer le checsum et de router la
trame" Eh bien ! en SDH,
lorsqu'une trame est trouvée erronée (par B2 par
exemple), le contrôle d'erreur est remis en cohérence avec la trame
entrante, un compteur local est incrémenté, le nombre d'erreurs détectés
est
signalé à la source (par M1).
Mais, à la différence de TCP/IP, on est en mode connecté.
(4) IP est transmis (au moins en longue distance) sur SDH.
Le datagramme IP
peut être vérolé dans le réseau SDH, et SDH continue la transmission.
Je vois assez mal le fait que le routeur en sortie de SDH puisse jeter la
trame
minutieusement transmise sur la fibre optique !
Regarder si c'est explicitement écrit dans les Rfc !! Intéressant, c'est
une
bonne remarque, je vais m'y pencher.
Tu dis : "Si le contrôle d'erreur est incorrect", tu veux dire que si un
routeur reçoit une trame correcte mais qu'il se trompe dans le calcul ? Si
c'est ce que tu voulais dire, je n'y avais jamais pensée. Il jettera alors
trame, enfin comment deviner ce que fera un périphérique en panne ou
bugger
Ils n'ont pas la même fonction et lors de la réception d'une trame IP,
elle
a été déjà validé en en couche 2.
Mais, à la différence de TCP/IP, on est en mode connecté.
(4) IP est transmis (au moins en longue distance) sur SDH.
Le datagramme IP
peut être vérolé dans le réseau SDH, et SDH continue la transmission.
Exacte, et c'est le cas de tous les protocole couche 2. Si le switch
ethernet déforme le contenu, il l'a transmettra tout de même.
Si, par exemple, tu peux avoir un FH SDH qui vérole les trame du à une
intempérie. Si les perturbations sont très fortes, alors le faisceau verra
une coupure, mais si la perturbation est faible alors, SDH ne verra rien.
Donc heureusement que le routeur d'extrémité valide le contenu.
Regarder si c'est explicitement écrit dans les Rfc !! Intéressant, c'est
une
bonne remarque, je vais m'y pencher.
Tu dis : "Si le contrôle d'erreur est incorrect", tu veux dire que si un
routeur reçoit une trame correcte mais qu'il se trompe dans le calcul ? Si
c'est ce que tu voulais dire, je n'y avais jamais pensée. Il jettera alors
trame, enfin comment deviner ce que fera un périphérique en panne ou
bugger
Ils n'ont pas la même fonction et lors de la réception d'une trame IP,
elle
a été déjà validé en en couche 2.
Mais, à la différence de TCP/IP, on est en mode connecté.
(4) IP est transmis (au moins en longue distance) sur SDH.
Le datagramme IP
peut être vérolé dans le réseau SDH, et SDH continue la transmission.
Exacte, et c'est le cas de tous les protocole couche 2. Si le switch
ethernet déforme le contenu, il l'a transmettra tout de même.
Si, par exemple, tu peux avoir un FH SDH qui vérole les trame du à une
intempérie. Si les perturbations sont très fortes, alors le faisceau verra
une coupure, mais si la perturbation est faible alors, SDH ne verra rien.
Donc heureusement que le routeur d'extrémité valide le contenu.
Regarder si c'est explicitement écrit dans les Rfc !! Intéressant, c'est
une
bonne remarque, je vais m'y pencher.
Tu dis : "Si le contrôle d'erreur est incorrect", tu veux dire que si un
routeur reçoit une trame correcte mais qu'il se trompe dans le calcul ? Si
c'est ce que tu voulais dire, je n'y avais jamais pensée. Il jettera alors
trame, enfin comment deviner ce que fera un périphérique en panne ou
bugger
Ils n'ont pas la même fonction et lors de la réception d'une trame IP,
elle
a été déjà validé en en couche 2.
Mais, à la différence de TCP/IP, on est en mode connecté.
(4) IP est transmis (au moins en longue distance) sur SDH.
Le datagramme IP
peut être vérolé dans le réseau SDH, et SDH continue la transmission.
Exacte, et c'est le cas de tous les protocole couche 2. Si le switch
ethernet déforme le contenu, il l'a transmettra tout de même.
Si, par exemple, tu peux avoir un FH SDH qui vérole les trame du à une
intempérie. Si les perturbations sont très fortes, alors le faisceau verra
une coupure, mais si la perturbation est faible alors, SDH ne verra rien.
Donc heureusement que le routeur d'extrémité valide le contenu.
Ils n'ont pas la même fonction et lors de la réception d'une trame IP,
elle a été déjà validé en en couche 2.
Le terme validé ne convient pas. Elle peut avoir été seulement
comptabilisée
(détectée) au niveau 2 et se retrouver tel quelle au niveau 3 (si l'erreur
est située dans la charge utile de la trame niveau 2).
SDH est en mode connecté au niveau 1 et 2, tandis qu'IP est en mode non
connecté (s/entendu de niveau 3).
Le flux Ethernet est asynchrone. Si par exemple un routeur trouve une
trame
Ethernet avec une longueur de données supérieure à 1500 octets, il la
jette
au niveau 2. La vie de la trame s'arrête, c'est non connecté au niveau 2.
Euh ! toutes les erreurs SDH sont vues et comptabilisées : dans les
en-têtes
et/ou les charges utiles.
On rajoute en hertzien des codes détecteurs / correcteurs d'erreur qui
fonctionnent très bien en fading de grande amplitude, jusqu'au seuil de
sensibilité du récepteur.
En plus, en cas de fading, le contrôle automatique
de puissance se met en route pour accroître la puissance d'émission. Au
pire, si la liaison se casse, il existe toujours une liaison de protection
qui passe par exemple 100 Km plus loin.
Ne pas dire SDH ne voit rien, les pertes d'exploitation ne sont pas du
même
ordre de grandeur que celle d'un internaute le dimanche à Berduche les
Fossés.
Ils n'ont pas la même fonction et lors de la réception d'une trame IP,
elle a été déjà validé en en couche 2.
Le terme validé ne convient pas. Elle peut avoir été seulement
comptabilisée
(détectée) au niveau 2 et se retrouver tel quelle au niveau 3 (si l'erreur
est située dans la charge utile de la trame niveau 2).
SDH est en mode connecté au niveau 1 et 2, tandis qu'IP est en mode non
connecté (s/entendu de niveau 3).
Le flux Ethernet est asynchrone. Si par exemple un routeur trouve une
trame
Ethernet avec une longueur de données supérieure à 1500 octets, il la
jette
au niveau 2. La vie de la trame s'arrête, c'est non connecté au niveau 2.
Euh ! toutes les erreurs SDH sont vues et comptabilisées : dans les
en-têtes
et/ou les charges utiles.
On rajoute en hertzien des codes détecteurs / correcteurs d'erreur qui
fonctionnent très bien en fading de grande amplitude, jusqu'au seuil de
sensibilité du récepteur.
En plus, en cas de fading, le contrôle automatique
de puissance se met en route pour accroître la puissance d'émission. Au
pire, si la liaison se casse, il existe toujours une liaison de protection
qui passe par exemple 100 Km plus loin.
Ne pas dire SDH ne voit rien, les pertes d'exploitation ne sont pas du
même
ordre de grandeur que celle d'un internaute le dimanche à Berduche les
Fossés.
Ils n'ont pas la même fonction et lors de la réception d'une trame IP,
elle a été déjà validé en en couche 2.
Le terme validé ne convient pas. Elle peut avoir été seulement
comptabilisée
(détectée) au niveau 2 et se retrouver tel quelle au niveau 3 (si l'erreur
est située dans la charge utile de la trame niveau 2).
SDH est en mode connecté au niveau 1 et 2, tandis qu'IP est en mode non
connecté (s/entendu de niveau 3).
Le flux Ethernet est asynchrone. Si par exemple un routeur trouve une
trame
Ethernet avec une longueur de données supérieure à 1500 octets, il la
jette
au niveau 2. La vie de la trame s'arrête, c'est non connecté au niveau 2.
Euh ! toutes les erreurs SDH sont vues et comptabilisées : dans les
en-têtes
et/ou les charges utiles.
On rajoute en hertzien des codes détecteurs / correcteurs d'erreur qui
fonctionnent très bien en fading de grande amplitude, jusqu'au seuil de
sensibilité du récepteur.
En plus, en cas de fading, le contrôle automatique
de puissance se met en route pour accroître la puissance d'émission. Au
pire, si la liaison se casse, il existe toujours une liaison de protection
qui passe par exemple 100 Km plus loin.
Ne pas dire SDH ne voit rien, les pertes d'exploitation ne sont pas du
même
ordre de grandeur que celle d'un internaute le dimanche à Berduche les
Fossés.
Oui, cela va sortir du Post et des frontière du group, mais j'ai du mal à
placer SDH en couche 1. Peux tu m'en parler deux minutes pour me
convaincre
?
Tu veux dire qu'en SDH, il y a un con^trôle de type checksum ou CRC ? Ce
qui
parrait logique, sinon on ne recevrait pas les informations sur le taux
d'erreur.
C'est de base ou il faut le rajouter manuelement (rajouter = configurer).
En plus, en cas de fading, le contrôle automatique
de puissance se met en route pour accroître la puissance d'émission. Au
pire, si la liaison se casse, il existe toujours une liaison de
protection
qui passe par exemple 100 Km plus loin.
Que se passe t il si l'on a déjà configurer les db au max des le départ ?
Oui, cela va sortir du Post et des frontière du group, mais j'ai du mal à
placer SDH en couche 1. Peux tu m'en parler deux minutes pour me
convaincre
?
Tu veux dire qu'en SDH, il y a un con^trôle de type checksum ou CRC ? Ce
qui
parrait logique, sinon on ne recevrait pas les informations sur le taux
d'erreur.
C'est de base ou il faut le rajouter manuelement (rajouter = configurer).
En plus, en cas de fading, le contrôle automatique
de puissance se met en route pour accroître la puissance d'émission. Au
pire, si la liaison se casse, il existe toujours une liaison de
protection
qui passe par exemple 100 Km plus loin.
Que se passe t il si l'on a déjà configurer les db au max des le départ ?
Oui, cela va sortir du Post et des frontière du group, mais j'ai du mal à
placer SDH en couche 1. Peux tu m'en parler deux minutes pour me
convaincre
?
Tu veux dire qu'en SDH, il y a un con^trôle de type checksum ou CRC ? Ce
qui
parrait logique, sinon on ne recevrait pas les informations sur le taux
d'erreur.
C'est de base ou il faut le rajouter manuelement (rajouter = configurer).
En plus, en cas de fading, le contrôle automatique
de puissance se met en route pour accroître la puissance d'émission. Au
pire, si la liaison se casse, il existe toujours une liaison de
protection
qui passe par exemple 100 Km plus loin.
Que se passe t il si l'on a déjà configurer les db au max des le départ ?
Pour revenir à ma question de départ.
Une réponse se trouve dans RFC 1122 - the datagram is silently discard
(donc
pas d'envoi d'ICMP dont on ne saurait d'ailleurs pas où envoyer si
l'adresse
source est pleine de boutons).
Pour revenir à ma question de départ.
Une réponse se trouve dans RFC 1122 - the datagram is silently discard
(donc
pas d'envoi d'ICMP dont on ne saurait d'ailleurs pas où envoyer si
l'adresse
source est pleine de boutons).
Pour revenir à ma question de départ.
Une réponse se trouve dans RFC 1122 - the datagram is silently discard
(donc
pas d'envoi d'ICMP dont on ne saurait d'ailleurs pas où envoyer si
l'adresse
source est pleine de boutons).
