Merci pour avoir non seulement fait la manip mais analysé les résultats.
> Essai fait fair sur un réseau 172.30.18.0/23, avec une machine W98.
>Quand je ping 172.30.19.255 (à partir de la console DOS), le programme
>envoie 4 demandes, et affiche 4 réponses:
>Envoi d'une requête 'ping' sur 172.30.19.255 avec 32 octets de données
:
>
>Réponse de 172.30.19.255 : octets=32 temps<10 ms TTL=64
>Réponse de 172.30.19.255 : octets=32 temps<10 ms TTL=64
>Réponse de 172.30.19.255 : octets=32 temps<10 ms TTL=64
>Réponse de 172.30.19.255 : octets=32 temps<10 ms TTL=64
Donc, si je comprends bien 4 requêtes ping sont émises, 31 machines font
écho, et pas plus de 4 réponses sont affichées, c'est cela ?
>En fait, un petit coup d'Ethereal me montre que mon ping est bien >diff
usé en brodcast Ethernet, que des machines font des ARP pour >obtenir mo
n adresse MAC, et finalement répondent.
Sacrebleu ! si ce ping est porté par une trame Ethernet diffusée en broa
dcast (Ethernet), y'a pas besoin d'ARP ! Je lis mal ?
Cordialement,
Angelot
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Article poste via Voila News - http://www.news.voila.fr
Le : Thu Sep 18 22:43:52 2003 depuis l'IP : avelizy-115-1-16-171.w81-249.abo.wanadoo.fr [VIP 234496906613]
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
PYT
Bonjour
"Angelot" a écrit dans le message news: bkd5ea$7uh$
Donc, si je comprends bien 4 requêtes ping sont émises, 31 machines font écho, et pas plus de 4 réponses sont affichées, c'est cela ?
Oui. Ca c'est du au programme ping.exe, qui n'attend et n'affiche qu'une réponse par requete envoyée. "djodj" a écrit dans le message news: bkcsg1$c5r$
je demande le service d'echo (ping donc) des que je recoit une reponse mon service est rendu et donc je passe au service suivant.. toutes les trames arrivant par la suite et correspondant a la demande de service précédante sont alors jetées a la poubelle car la demande de service est close
Sacrebleu ! si ce ping est porté par une trame Ethernet diffusée en broa dcast (Ethernet), y'a pas besoin d'ARP ! Je lis mal ?
Je me suis sans doute mal expliqué: ma machine emet bien la requete icmp en diffusion ethernet. Par contre, les machines pinguées répondent au demandeur, donc en unicast. Elles ont besoin de mon adresse MAC pour me répondre, et l'obtiennent par arp.
Pierre-Yves
Bonjour
"Angelot" <anonyme@avelizy-115-1-16-171.w81-249.abo.wanadoo.fr> a écrit dans
le message news: bkd5ea$7uh$1@news.x-echo.com...
Donc, si je comprends bien 4 requêtes ping sont émises, 31 machines font
écho, et pas plus de 4 réponses sont affichées, c'est cela ?
Oui. Ca c'est du au programme ping.exe, qui n'attend et n'affiche qu'une
réponse par requete envoyée.
"djodj" <joel.voye@infonie.fr> a écrit dans le message news:
bkcsg1$c5r$1@news.tiscali.fr...
je demande le service d'echo (ping donc) des que je recoit une reponse mon
service est rendu et donc je passe au service suivant.. toutes les trames
arrivant par la suite et correspondant a la demande de service précédante
sont alors jetées a la poubelle car la demande de service est close
Sacrebleu ! si ce ping est porté par une trame Ethernet diffusée en broa
dcast (Ethernet), y'a pas besoin d'ARP ! Je lis mal ?
Je me suis sans doute mal expliqué: ma machine emet bien la requete icmp en
diffusion ethernet. Par contre, les machines pinguées répondent au
demandeur, donc en unicast. Elles ont besoin de mon adresse MAC pour me
répondre, et l'obtiennent par arp.
"Angelot" a écrit dans le message news: bkd5ea$7uh$
Donc, si je comprends bien 4 requêtes ping sont émises, 31 machines font écho, et pas plus de 4 réponses sont affichées, c'est cela ?
Oui. Ca c'est du au programme ping.exe, qui n'attend et n'affiche qu'une réponse par requete envoyée. "djodj" a écrit dans le message news: bkcsg1$c5r$
je demande le service d'echo (ping donc) des que je recoit une reponse mon service est rendu et donc je passe au service suivant.. toutes les trames arrivant par la suite et correspondant a la demande de service précédante sont alors jetées a la poubelle car la demande de service est close
Sacrebleu ! si ce ping est porté par une trame Ethernet diffusée en broa dcast (Ethernet), y'a pas besoin d'ARP ! Je lis mal ?
Je me suis sans doute mal expliqué: ma machine emet bien la requete icmp en diffusion ethernet. Par contre, les machines pinguées répondent au demandeur, donc en unicast. Elles ont besoin de mon adresse MAC pour me répondre, et l'obtiennent par arp.
Pierre-Yves
Amm
"PYT" a écrit dans le message news: bke9br$403$
Bon, avec Pyt (on est ensemble), on a un peu compliqué la mainip. J'ai eu l'idée de faire un ping broadcast sur un réseau distant. Voici la description de la manip
Ma machine est un W98 en 172.30.134.60 avec un masque 255.255.255.192 sur le réseau 172.30.134.0 /26
Je ping en 172.30.17.255 car normalement il y a un réseau172.30.16.0/23 (ping avec l'option -n 1 pour n'en émettre qu'un seul)
L'appli ping me donne rapidement (7ms) une réponse de 172.30.17.255 (ça c'est la con... de ping)
Evidemment, brillement, on a lancer Ethereal sur la machine pingueuse
Euh... ça ne veut plus s'arrêter.... une heure après, j'en reçois encore
Bon description du réseau (l'est pas raccordé à l'Internet :)
Sur le lan source 172.30.134.0 /26 il y a un seul routeur PF1_RT (en 172.30.134.1) PF1_RT (172.30.135.198) est relié à un routeur ARC_RT (en 172.30.135.197) par un Wan 172.30.135.196 /30 Entre autre, ce routeur ARC_RT est relié en 172.30.87.238 à un routeur CRI_RT_N (en 172.30.87.237) par un Wan 172.30.87.236 /30 en 172.30.87.254 à un routeur CRI_RT_S (en 172.30.87.253) par un Wan 172.30.87.252 /30
CRI_RT_N et CRI_RT_S sont, entre autre, raccordés sur le réseau cible du ping 172.30.16.0 /23 CRI_RT_N en 172.30.16.2 et CRI_RT_S en 172.30.16.3
Il y a un /protocol machin-bidule/ entre CRI_RT_N et CRI_RT_S pour que ces 2 routeurs apparaissent comme un routeur virtuel unique (redondant) depuis le réseau cible 172.30.16.0 /23
Quand on examine les trames ethernet revenant sur la machine pingueuse, on observe :
* un (et un seul) Echo (Ping) Reply de 172.30.87.237 qui est un des port de CRI_RT_N * une multitude de ICMP [Destination unreachable] revenant de 172.30.135.197 qui est un des ports de ARC_RT.
Il y en a eu 142 en 4278 secondes... et ça continue :...-((( Ca fait curieusement pile 2 à la minute !
Le réseau est beaucoup maillé plus loin et on utilise OSPF sur les 6 routeurs du backbone (CRI_RT_N CRI_RT_S ARC_RT et 3 autres) Les autres routeurs, une cinquantaine sont en table fixe car ils ne servent qu'à coupler des LAN vers des routeurs genre ARC_RT. Evidemment tous les sites sont éparpillés géographiquement et les supports télécom du backbone sont des conduits 2 Mbits (SDH) sur des fibres optiques privés.
- Bon, comment je vais arrêter le phénomène ? - Que se passe-t-il ? -- Amm
"PYT" <pyt@fr.invalid> a écrit dans le message news:
bke9br$403$1@freyda.setra.i2...
Bon, avec Pyt (on est ensemble), on a un peu compliqué la mainip. J'ai eu
l'idée de faire un ping broadcast sur un réseau distant. Voici la
description de la manip
Ma machine est un W98 en 172.30.134.60 avec un masque 255.255.255.192 sur le
réseau 172.30.134.0 /26
Je ping en 172.30.17.255 car normalement il y a un réseau172.30.16.0/23
(ping avec l'option -n 1 pour n'en émettre qu'un seul)
L'appli ping me donne rapidement (7ms) une réponse de 172.30.17.255 (ça
c'est la con... de ping)
Evidemment, brillement, on a lancer Ethereal sur la machine pingueuse
Euh... ça ne veut plus s'arrêter.... une heure après, j'en reçois encore
Bon description du réseau (l'est pas raccordé à l'Internet :)
Sur le lan source 172.30.134.0 /26 il y a un seul routeur PF1_RT (en
172.30.134.1)
PF1_RT (172.30.135.198) est relié à un routeur ARC_RT (en 172.30.135.197)
par un Wan 172.30.135.196 /30
Entre autre, ce routeur ARC_RT est relié
en 172.30.87.238 à un routeur CRI_RT_N (en 172.30.87.237) par un Wan
172.30.87.236 /30
en 172.30.87.254 à un routeur CRI_RT_S (en 172.30.87.253) par un Wan
172.30.87.252 /30
CRI_RT_N et CRI_RT_S sont, entre autre, raccordés sur le réseau cible du
ping 172.30.16.0 /23
CRI_RT_N en 172.30.16.2 et CRI_RT_S en 172.30.16.3
Il y a un /protocol machin-bidule/ entre CRI_RT_N et CRI_RT_S pour que ces 2
routeurs apparaissent comme un routeur virtuel unique (redondant) depuis le
réseau cible 172.30.16.0 /23
Quand on examine les trames ethernet revenant sur la machine pingueuse, on
observe :
* un (et un seul) Echo (Ping) Reply de 172.30.87.237 qui est un des port de
CRI_RT_N
* une multitude de ICMP [Destination unreachable] revenant de 172.30.135.197
qui est un des ports de ARC_RT.
Il y en a eu 142 en 4278 secondes... et ça continue :...-((( Ca fait
curieusement pile 2 à la minute !
Le réseau est beaucoup maillé plus loin et on utilise OSPF sur les 6
routeurs du backbone (CRI_RT_N CRI_RT_S ARC_RT et 3 autres) Les autres
routeurs, une cinquantaine sont en table fixe car ils ne servent qu'à
coupler des LAN vers des routeurs genre ARC_RT. Evidemment tous les sites
sont éparpillés géographiquement et les supports télécom du backbone sont
des conduits 2 Mbits (SDH) sur des fibres optiques privés.
- Bon, comment je vais arrêter le phénomène ?
- Que se passe-t-il ?
--
Amm
Bon, avec Pyt (on est ensemble), on a un peu compliqué la mainip. J'ai eu l'idée de faire un ping broadcast sur un réseau distant. Voici la description de la manip
Ma machine est un W98 en 172.30.134.60 avec un masque 255.255.255.192 sur le réseau 172.30.134.0 /26
Je ping en 172.30.17.255 car normalement il y a un réseau172.30.16.0/23 (ping avec l'option -n 1 pour n'en émettre qu'un seul)
L'appli ping me donne rapidement (7ms) une réponse de 172.30.17.255 (ça c'est la con... de ping)
Evidemment, brillement, on a lancer Ethereal sur la machine pingueuse
Euh... ça ne veut plus s'arrêter.... une heure après, j'en reçois encore
Bon description du réseau (l'est pas raccordé à l'Internet :)
Sur le lan source 172.30.134.0 /26 il y a un seul routeur PF1_RT (en 172.30.134.1) PF1_RT (172.30.135.198) est relié à un routeur ARC_RT (en 172.30.135.197) par un Wan 172.30.135.196 /30 Entre autre, ce routeur ARC_RT est relié en 172.30.87.238 à un routeur CRI_RT_N (en 172.30.87.237) par un Wan 172.30.87.236 /30 en 172.30.87.254 à un routeur CRI_RT_S (en 172.30.87.253) par un Wan 172.30.87.252 /30
CRI_RT_N et CRI_RT_S sont, entre autre, raccordés sur le réseau cible du ping 172.30.16.0 /23 CRI_RT_N en 172.30.16.2 et CRI_RT_S en 172.30.16.3
Il y a un /protocol machin-bidule/ entre CRI_RT_N et CRI_RT_S pour que ces 2 routeurs apparaissent comme un routeur virtuel unique (redondant) depuis le réseau cible 172.30.16.0 /23
Quand on examine les trames ethernet revenant sur la machine pingueuse, on observe :
* un (et un seul) Echo (Ping) Reply de 172.30.87.237 qui est un des port de CRI_RT_N * une multitude de ICMP [Destination unreachable] revenant de 172.30.135.197 qui est un des ports de ARC_RT.
Il y en a eu 142 en 4278 secondes... et ça continue :...-((( Ca fait curieusement pile 2 à la minute !
Le réseau est beaucoup maillé plus loin et on utilise OSPF sur les 6 routeurs du backbone (CRI_RT_N CRI_RT_S ARC_RT et 3 autres) Les autres routeurs, une cinquantaine sont en table fixe car ils ne servent qu'à coupler des LAN vers des routeurs genre ARC_RT. Evidemment tous les sites sont éparpillés géographiquement et les supports télécom du backbone sont des conduits 2 Mbits (SDH) sur des fibres optiques privés.
- Bon, comment je vais arrêter le phénomène ? - Que se passe-t-il ? -- Amm
