J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en
changeant les adresses hardware source et destination par des octets
aléatoires. J'ai bien mis mon IP en source, celle du routeur en
destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse,
destinée à ma carte réseau (la bonne adresse, pas l'aléatoire).
J'observe le même comportement avec TCP, sans doute tous les protocoles
de la couche transport.
Pourquoi mon routeur, voyant arriver un paquet d'une adresse MAC
inconnue, n'envoie-t-il pas une requête ARP pour savoir à qui elle
appartient, ou pour prévenir les autres machines?
De plus, le routeur a su à qui renvoyer la réponse, il s'est donc basé
sur l'IP et non sur l'adresse MAC. Cette priorité est-elle définie
quelque part ?
"Nicolas Favre-Felix" wrote in message news:cftrl7$e0i$
Bonjour,
J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en changeant les adresses hardware source et destination par des octets aléatoires. J'ai bien mis mon IP en source, celle du routeur en destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse, destinée à ma carte réseau (la bonne adresse, pas l'aléatoire). J'observe le même comportement avec TCP, sans doute tous les protocoles de la couche transport.
Pourquoi mon routeur, voyant arriver un paquet d'une adresse MAC inconnue, n'envoie-t-il pas une requête ARP pour savoir à qui elle appartient, ou pour prévenir les autres machines? De plus, le routeur a su à qui renvoyer la réponse, il s'est donc basé sur l'IP et non sur l'adresse MAC. Cette priorité est-elle définie quelque part ?
Merci.
re-essaie en vidant les caches ARP.
"Nicolas Favre-Felix" <n.favrefelix@__free.fr> wrote in message
news:cftrl7$e0i$1@news.tiscali.fr...
Bonjour,
J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en
changeant les adresses hardware source et destination par des octets
aléatoires. J'ai bien mis mon IP en source, celle du routeur en
destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse,
destinée à ma carte réseau (la bonne adresse, pas l'aléatoire).
J'observe le même comportement avec TCP, sans doute tous les protocoles
de la couche transport.
Pourquoi mon routeur, voyant arriver un paquet d'une adresse MAC
inconnue, n'envoie-t-il pas une requête ARP pour savoir à qui elle
appartient, ou pour prévenir les autres machines?
De plus, le routeur a su à qui renvoyer la réponse, il s'est donc basé
sur l'IP et non sur l'adresse MAC. Cette priorité est-elle définie
quelque part ?
"Nicolas Favre-Felix" wrote in message news:cftrl7$e0i$
Bonjour,
J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en changeant les adresses hardware source et destination par des octets aléatoires. J'ai bien mis mon IP en source, celle du routeur en destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse, destinée à ma carte réseau (la bonne adresse, pas l'aléatoire). J'observe le même comportement avec TCP, sans doute tous les protocoles de la couche transport.
Pourquoi mon routeur, voyant arriver un paquet d'une adresse MAC inconnue, n'envoie-t-il pas une requête ARP pour savoir à qui elle appartient, ou pour prévenir les autres machines? De plus, le routeur a su à qui renvoyer la réponse, il s'est donc basé sur l'IP et non sur l'adresse MAC. Cette priorité est-elle définie quelque part ?
Merci.
Jacques Caron
Salut,
On Tue, 17 Aug 2004 23:00:30 +0200, Nicolas Favre-Felix wrote:
J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en changeant les adresses hardware source et destination par des octets aléatoires. J'ai bien mis mon IP en source, celle du routeur en destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse, destinée à ma carte réseau (la bonne adresse, pas l'aléatoire).
Avec l'adresse MAC du routeur en destination, pas une aléatoire, je suppose.
J'observe le même comportement avec TCP, sans doute tous les protocoles de la couche transport.
Pourquoi mon routeur, voyant arriver un paquet d'une adresse MAC inconnue, n'envoie-t-il pas une requête ARP pour savoir à qui elle appartient, ou pour prévenir les autres machines?
ARP ne sert pas à déterminer à qui appartient une adresse MAC, mais à qui appartient une adresse IP. Le routeur n'a aucune raison de se poser la moindre question sur cette adresse MAC. Par contre, certains équipements "apprennent" automatiquement dans ce cas que l'adresse MAC associée à telle IP a changé et notent la nouvelle.
De plus, le routeur a su à qui renvoyer la réponse, il s'est donc basé sur l'IP et non sur l'adresse MAC. Cette priorité est-elle définie quelque part ?
C'est une question simple d'empilement de couches réseau. C'est un paquet ICMP, dont un paquet IP. La réponse se fait donc au niveau IP, en répondant à l'adresse IP source d'origine, et en regardant dans sa table ARP quelle est l'adresse MAC associée, et renvoie à celle là. Rien de plus normal, donc.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Tue, 17 Aug 2004 23:00:30 +0200, Nicolas Favre-Felix
<n.favrefelix@__free.fr> wrote:
J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en
changeant les adresses hardware source et destination par des octets
aléatoires. J'ai bien mis mon IP en source, celle du routeur en
destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse,
destinée à ma carte réseau (la bonne adresse, pas l'aléatoire).
Avec l'adresse MAC du routeur en destination, pas une aléatoire, je
suppose.
J'observe le même comportement avec TCP, sans doute tous les protocoles
de la couche transport.
Pourquoi mon routeur, voyant arriver un paquet d'une adresse MAC
inconnue, n'envoie-t-il pas une requête ARP pour savoir à qui elle
appartient, ou pour prévenir les autres machines?
ARP ne sert pas à déterminer à qui appartient une adresse MAC, mais à qui
appartient une adresse IP. Le routeur n'a aucune raison de se poser la
moindre question sur cette adresse MAC. Par contre, certains équipements
"apprennent" automatiquement dans ce cas que l'adresse MAC associée à
telle IP a changé et notent la nouvelle.
De plus, le routeur a su à qui renvoyer la réponse, il s'est donc basé
sur l'IP et non sur l'adresse MAC. Cette priorité est-elle définie
quelque part ?
C'est une question simple d'empilement de couches réseau. C'est un paquet
ICMP, dont un paquet IP. La réponse se fait donc au niveau IP, en
répondant à l'adresse IP source d'origine, et en regardant dans sa table
ARP quelle est l'adresse MAC associée, et renvoie à celle là. Rien de plus
normal, donc.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Tue, 17 Aug 2004 23:00:30 +0200, Nicolas Favre-Felix wrote:
J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en changeant les adresses hardware source et destination par des octets aléatoires. J'ai bien mis mon IP en source, celle du routeur en destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse, destinée à ma carte réseau (la bonne adresse, pas l'aléatoire).
Avec l'adresse MAC du routeur en destination, pas une aléatoire, je suppose.
J'observe le même comportement avec TCP, sans doute tous les protocoles de la couche transport.
Pourquoi mon routeur, voyant arriver un paquet d'une adresse MAC inconnue, n'envoie-t-il pas une requête ARP pour savoir à qui elle appartient, ou pour prévenir les autres machines?
ARP ne sert pas à déterminer à qui appartient une adresse MAC, mais à qui appartient une adresse IP. Le routeur n'a aucune raison de se poser la moindre question sur cette adresse MAC. Par contre, certains équipements "apprennent" automatiquement dans ce cas que l'adresse MAC associée à telle IP a changé et notent la nouvelle.
De plus, le routeur a su à qui renvoyer la réponse, il s'est donc basé sur l'IP et non sur l'adresse MAC. Cette priorité est-elle définie quelque part ?
C'est une question simple d'empilement de couches réseau. C'est un paquet ICMP, dont un paquet IP. La réponse se fait donc au niveau IP, en répondant à l'adresse IP source d'origine, et en regardant dans sa table ARP quelle est l'adresse MAC associée, et renvoie à celle là. Rien de plus normal, donc.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
_SebF - www.frameip.com
"Nicolas Favre-Felix" a écrit dans le message de news: cftrl7$e0i$
Bonjour,
Salut,
J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en changeant les adresses hardware source et destination par des octets aléatoires. J'ai bien mis mon IP en source, celle du routeur en destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse, destinée à ma carte réseau
Es-tu sur que tu as modifier l'adresse Mac de destination ? Et pas plutôt uniquement la source.
(la bonne adresse, pas l'aléatoire).
Bonne remarque
J'observe le même comportement avec TCP, sans doute tous les protocoles de la couche transport.
Je ne vois pas le rapport avec Tcp.
Pourquoi mon routeur, voyant arriver un paquet d'une adresse MAC inconnue, n'envoie-t-il pas une requête ARP pour savoir à qui elle appartient,
Il n'envoit pas de requête; car il devrait, par defaut, répondre à l'adresse Mac source du paquet que tu as aenvoyé. Il en profitera même pour mettre à jour son cache.
ou pour prévenir les autres machines?
Prévenir les autres ....
De plus, le routeur a su à qui renvoyer la réponse,
Je rejoins en regardant la possibilitée que le routeur avait la correspondance Mac(good)-IP dans son cache. Peux tu refaire ton test en t'assurant que les caches soient vide ?
Cordialement,
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
"Nicolas Favre-Felix" <n.favrefelix@__free.fr> a écrit dans le message de
news: cftrl7$e0i$1@news.tiscali.fr...
Bonjour,
Salut,
J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en
changeant les adresses hardware source et destination par des octets
aléatoires. J'ai bien mis mon IP en source, celle du routeur en
destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse,
destinée à ma carte réseau
Es-tu sur que tu as modifier l'adresse Mac de destination ? Et pas plutôt
uniquement la source.
(la bonne adresse, pas l'aléatoire).
Bonne remarque
J'observe le même comportement avec TCP, sans doute tous les protocoles
de la couche transport.
Je ne vois pas le rapport avec Tcp.
Pourquoi mon routeur, voyant arriver un paquet d'une adresse MAC
inconnue, n'envoie-t-il pas une requête ARP pour savoir à qui elle
appartient,
Il n'envoit pas de requête; car il devrait, par defaut, répondre à l'adresse
Mac source du paquet que tu as aenvoyé. Il en profitera même pour mettre à
jour son cache.
ou pour prévenir les autres machines?
Prévenir les autres ....
De plus, le routeur a su à qui renvoyer la réponse,
Je rejoins H@wk en regardant la possibilitée que le routeur avait la
correspondance Mac(good)-IP dans son cache. Peux tu refaire ton test en
t'assurant que les caches soient vide ?
Cordialement,
--
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
"Nicolas Favre-Felix" a écrit dans le message de news: cftrl7$e0i$
Bonjour,
Salut,
J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en changeant les adresses hardware source et destination par des octets aléatoires. J'ai bien mis mon IP en source, celle du routeur en destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse, destinée à ma carte réseau
Es-tu sur que tu as modifier l'adresse Mac de destination ? Et pas plutôt uniquement la source.
(la bonne adresse, pas l'aléatoire).
Bonne remarque
J'observe le même comportement avec TCP, sans doute tous les protocoles de la couche transport.
Je ne vois pas le rapport avec Tcp.
Pourquoi mon routeur, voyant arriver un paquet d'une adresse MAC inconnue, n'envoie-t-il pas une requête ARP pour savoir à qui elle appartient,
Il n'envoit pas de requête; car il devrait, par defaut, répondre à l'adresse Mac source du paquet que tu as aenvoyé. Il en profitera même pour mettre à jour son cache.
ou pour prévenir les autres machines?
Prévenir les autres ....
De plus, le routeur a su à qui renvoyer la réponse,
Je rejoins en regardant la possibilitée que le routeur avait la correspondance Mac(good)-IP dans son cache. Peux tu refaire ton test en t'assurant que les caches soient vide ?
Cordialement,
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Nicolas Favre-Félix
_SebF - www.frameip.com wrote:
J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en changeant les adresses hardware source et destination par des octets aléatoires. J'ai bien mis mon IP en source, celle du routeur en destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse, destinée à ma carte réseau
Es-tu sur que tu as modifier l'adresse Mac de destination ? Et pas plutôt uniquement la source.
Oui, les deux. Par contre, ici (au boulot), la passerelle (un switch si je me souviens bien) ne répond que si son adresse MAC est spécifiée en destination. L'adresse source semble être ignorée. Ce soir, chez moi, je sniffe tout ça et j'uploade un log ethereal.
Il n'envoit pas de requête; car il devrait, par defaut, répondre à l'adresse Mac source du paquet que tu as aenvoyé. Il en profitera même pour mettre à jour son cache.
Jacques Caron wrote:
C'est une question simple d'empilement de couches réseau. C'est un paquet ICMP, dont un paquet IP. La réponse se fait donc au niveau IP, en répondant à l'adresse IP source d'origine, et en regardant dans sa table ARP quelle est l'adresse MAC associée, et renvoie à celle là. Rien de plus normal, donc.
Je rejoins en regardant la possibilitée que le routeur avait la correspondance Mac(good)-IP dans son cache.
Je pense aussi que c'est cela, mais quelle est la norme qui définit cet ordre : D'abord l'ip (trouver la MAC dans le cache ou par ARP), et si cela échoue, envoyer à l'adresse MAC source.
Peux tu refaire ton test en t'assurant que les caches soient vide ?
Je vais regarder la doc, rien ne le permet par l'interface d'administration. (Netgear RP614)
Cordialement,
Cordialement, Nicolas.
_SebF - www.frameip.com wrote:
J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en
changeant les adresses hardware source et destination par des octets
aléatoires. J'ai bien mis mon IP en source, celle du routeur en
destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse,
destinée à ma carte réseau
Es-tu sur que tu as modifier l'adresse Mac de destination ? Et pas plutôt
uniquement la source.
Oui, les deux. Par contre, ici (au boulot), la passerelle (un switch si
je me souviens bien) ne répond que si son adresse MAC est spécifiée en
destination. L'adresse source semble être ignorée. Ce soir, chez moi, je
sniffe tout ça et j'uploade un log ethereal.
Il n'envoit pas de requête; car il devrait, par defaut, répondre à l'adresse
Mac source du paquet que tu as aenvoyé. Il en profitera même pour mettre à
jour son cache.
Jacques Caron wrote:
C'est une question simple d'empilement de couches réseau. C'est un
paquet ICMP, dont un paquet IP. La réponse se fait donc au niveau IP,
en répondant à l'adresse IP source d'origine, et en regardant dans sa
table ARP quelle est l'adresse MAC associée, et renvoie à celle là.
Rien de plus normal, donc.
Je rejoins H@wk en regardant la possibilitée que le routeur avait la
correspondance Mac(good)-IP dans son cache.
Je pense aussi que c'est cela, mais quelle est la norme qui définit cet
ordre : D'abord l'ip (trouver la MAC dans le cache ou par ARP), et si
cela échoue, envoyer à l'adresse MAC source.
Peux tu refaire ton test en
t'assurant que les caches soient vide ?
Je vais regarder la doc, rien ne le permet par l'interface
d'administration. (Netgear RP614)
J'ai fait quelques tests d'envois de paquets IP sur mon LAN Ethernet, en changeant les adresses hardware source et destination par des octets aléatoires. J'ai bien mis mon IP en source, celle du routeur en destination, et après l'envoi d'un ICMP echo, j'ai bien reçu la réponse, destinée à ma carte réseau
Es-tu sur que tu as modifier l'adresse Mac de destination ? Et pas plutôt uniquement la source.
Oui, les deux. Par contre, ici (au boulot), la passerelle (un switch si je me souviens bien) ne répond que si son adresse MAC est spécifiée en destination. L'adresse source semble être ignorée. Ce soir, chez moi, je sniffe tout ça et j'uploade un log ethereal.
Il n'envoit pas de requête; car il devrait, par defaut, répondre à l'adresse Mac source du paquet que tu as aenvoyé. Il en profitera même pour mettre à jour son cache.
Jacques Caron wrote:
C'est une question simple d'empilement de couches réseau. C'est un paquet ICMP, dont un paquet IP. La réponse se fait donc au niveau IP, en répondant à l'adresse IP source d'origine, et en regardant dans sa table ARP quelle est l'adresse MAC associée, et renvoie à celle là. Rien de plus normal, donc.
Je rejoins en regardant la possibilitée que le routeur avait la correspondance Mac(good)-IP dans son cache.
Je pense aussi que c'est cela, mais quelle est la norme qui définit cet ordre : D'abord l'ip (trouver la MAC dans le cache ou par ARP), et si cela échoue, envoyer à l'adresse MAC source.
Peux tu refaire ton test en t'assurant que les caches soient vide ?
Je vais regarder la doc, rien ne le permet par l'interface d'administration. (Netgear RP614)
Cordialement,
Cordialement, Nicolas.
Jacques Caron
Salut,
On Wed, 18 Aug 2004 10:22:10 +0200, Nicolas Favre-Félix wrote:
Je pense aussi que c'est cela, mais quelle est la norme qui définit cet ordre : D'abord l'ip (trouver la MAC dans le cache ou par ARP), et si cela échoue, envoyer à l'adresse MAC source.
Non non. Quand IP traite le paquet ICMP, il ne voit pas du tout les adresses MAC utilisées. Il répond donc à l'IP source, et ensuite il essaie de trouver l'adresse MAC qui va avec, à travers le cache ARP ou une requête ARP.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Wed, 18 Aug 2004 10:22:10 +0200, Nicolas Favre-Félix
<n.favrefelix@__free.fr> wrote:
Je pense aussi que c'est cela, mais quelle est la norme qui définit cet
ordre : D'abord l'ip (trouver la MAC dans le cache ou par ARP), et si
cela échoue, envoyer à l'adresse MAC source.
Non non. Quand IP traite le paquet ICMP, il ne voit pas du tout les
adresses MAC utilisées. Il répond donc à l'IP source, et ensuite il essaie
de trouver l'adresse MAC qui va avec, à travers le cache ARP ou une
requête ARP.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Wed, 18 Aug 2004 10:22:10 +0200, Nicolas Favre-Félix wrote:
Je pense aussi que c'est cela, mais quelle est la norme qui définit cet ordre : D'abord l'ip (trouver la MAC dans le cache ou par ARP), et si cela échoue, envoyer à l'adresse MAC source.
Non non. Quand IP traite le paquet ICMP, il ne voit pas du tout les adresses MAC utilisées. Il répond donc à l'IP source, et ensuite il essaie de trouver l'adresse MAC qui va avec, à travers le cache ARP ou une requête ARP.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Vincent Bernat
OoO En cette nuit nuageuse du mercredi 18 août 2004, vers 01:18, "_SebF - www.frameip.com" disait:
Il n'envoit pas de requête; car il devrait, par defaut, répondre à l'adresse Mac source du paquet que tu as aenvoyé. Il en profitera même pour mettre à jour son cache.
Il n'y a pas d'apprentissage à ce niveau. L'apprentissage se fait uniquement sur les réponses à des requêtes ARP que l'on envoie. Cela évite dans une certaine mesure de corrompre trop facilement le cache ARP. -- Quelqu'un connait il la vitesse en mètres par seconde du chameau d'Egypte ? -+- JM in: Guide du Cabaliste Usenet - Bien configurer son chameau -+-
OoO En cette nuit nuageuse du mercredi 18 août 2004, vers 01:18,
"_SebF - www.frameip.com" <onsespam@encore.et.encore.com> disait:
Il n'envoit pas de requête; car il devrait, par defaut, répondre à l'adresse
Mac source du paquet que tu as aenvoyé. Il en profitera même pour mettre à
jour son cache.
Il n'y a pas d'apprentissage à ce niveau. L'apprentissage se fait
uniquement sur les réponses à des requêtes ARP que l'on envoie. Cela
évite dans une certaine mesure de corrompre trop facilement le cache
ARP.
--
Quelqu'un connait il la vitesse en mètres par seconde du
chameau d'Egypte ?
-+- JM in: Guide du Cabaliste Usenet - Bien configurer son chameau -+-
OoO En cette nuit nuageuse du mercredi 18 août 2004, vers 01:18, "_SebF - www.frameip.com" disait:
Il n'envoit pas de requête; car il devrait, par defaut, répondre à l'adresse Mac source du paquet que tu as aenvoyé. Il en profitera même pour mettre à jour son cache.
Il n'y a pas d'apprentissage à ce niveau. L'apprentissage se fait uniquement sur les réponses à des requêtes ARP que l'on envoie. Cela évite dans une certaine mesure de corrompre trop facilement le cache ARP. -- Quelqu'un connait il la vitesse en mètres par seconde du chameau d'Egypte ? -+- JM in: Guide du Cabaliste Usenet - Bien configurer son chameau -+-
_SebF - www.frameip.com
"Vincent Bernat" a écrit dans le message de news:
OoO En cette nuit nuageuse du mercredi 18 août 2004, vers 01:18,
Il n'y a pas d'apprentissage à ce niveau. L'apprentissage se fait uniquement sur les réponses à des requêtes ARP que l'on envoie. Cela évite dans une certaine mesure de corrompre trop facilement le cache ARP.
Je te prends un exemple, Un Xp Ms et un 7206 Cisco sur le même Lan avec des caches Arp vide. La station ping le routeur.
Ethereal montre uniquement (en dehors du flux Icmp) deux trames Arp correspondant aux Request Reply. Deux trames représentant un seul échange. Le routeur de destination à donc répondu, malgré son cache vide, à l'adresse Mac source sans émettre d'Arp Request. En plus, les caches des deux Hosts ont été alimentés.
Je me suis dis que cela était peux être propre à Cisco. J'ai donc renouvelé le test avec deux Win et le résultat est le même.
Cordialement,
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
"Vincent Bernat" <vincent.bernat@raysa.org> a écrit dans le message de news:
m3smakx0ua.fsf@neo.loria...
OoO En cette nuit nuageuse du mercredi 18 août 2004, vers 01:18,
Il n'y a pas d'apprentissage à ce niveau. L'apprentissage se fait
uniquement sur les réponses à des requêtes ARP que l'on envoie. Cela
évite dans une certaine mesure de corrompre trop facilement le cache
ARP.
Je te prends un exemple, Un Xp Ms et un 7206 Cisco sur le même Lan avec des
caches Arp vide. La station ping le routeur.
Ethereal montre uniquement (en dehors du flux Icmp) deux trames Arp
correspondant aux Request Reply. Deux trames représentant un seul échange.
Le routeur de destination à donc répondu, malgré son cache vide, à l'adresse
Mac source sans émettre d'Arp Request. En plus, les caches des deux Hosts
ont été alimentés.
Je me suis dis que cela était peux être propre à Cisco. J'ai donc renouvelé
le test avec deux Win et le résultat est le même.
Cordialement,
--
_SebF
http://www.frameip.com
Un site pour les spécialistes IP
OoO En cette nuit nuageuse du mercredi 18 août 2004, vers 01:18,
Il n'y a pas d'apprentissage à ce niveau. L'apprentissage se fait uniquement sur les réponses à des requêtes ARP que l'on envoie. Cela évite dans une certaine mesure de corrompre trop facilement le cache ARP.
Je te prends un exemple, Un Xp Ms et un 7206 Cisco sur le même Lan avec des caches Arp vide. La station ping le routeur.
Ethereal montre uniquement (en dehors du flux Icmp) deux trames Arp correspondant aux Request Reply. Deux trames représentant un seul échange. Le routeur de destination à donc répondu, malgré son cache vide, à l'adresse Mac source sans émettre d'Arp Request. En plus, les caches des deux Hosts ont été alimentés.
Je me suis dis que cela était peux être propre à Cisco. J'ai donc renouvelé le test avec deux Win et le résultat est le même.
Cordialement,
--
_SebF
http://www.frameip.com Un site pour les spécialistes IP
Vincent Bernat
OoO Pendant le temps de midi du mercredi 18 août 2004, vers 12:37, "_SebF - www.frameip.com" disait:
Il n'y a pas d'apprentissage à ce niveau. L'apprentissage se fait uniquement sur les réponses à des requêtes ARP que l'on envoie. Cela évite dans une certaine mesure de corrompre trop facilement le cache ARP.
Je te prends un exemple, Un Xp Ms et un 7206 Cisco sur le même Lan avec des caches Arp vide. La station ping le routeur.
Ethereal montre uniquement (en dehors du flux Icmp) deux trames Arp correspondant aux Request Reply. Deux trames représentant un seul échange. Le routeur de destination à donc répondu, malgré son cache vide, à l'adresse Mac source sans émettre d'Arp Request. En plus, les caches des deux Hosts ont été alimentés.
Ma réponse est en effet incomplète. L'apprentissage se fait aussi sur les requêtes ARP qui arrivent. L'important dans une bonne implémentation est que les adresses MAC en question apparaissent dans un paquet broadcasté (pour éviter qu'une corruption de cache passe inaperçue). -- J'ai dû m'inscrire par erreur. Je vous prie de retirer mon nom de ce groupe. Merci. -+- DF in Guide du Neunu d'Usenet : Je viens ou je me retire ? -+-
OoO Pendant le temps de midi du mercredi 18 août 2004, vers 12:37,
"_SebF - www.frameip.com" <onsespam@encore.et.encore.com> disait:
Il n'y a pas d'apprentissage à ce niveau. L'apprentissage se fait
uniquement sur les réponses à des requêtes ARP que l'on envoie. Cela
évite dans une certaine mesure de corrompre trop facilement le cache
ARP.
Je te prends un exemple, Un Xp Ms et un 7206 Cisco sur le même Lan avec des
caches Arp vide. La station ping le routeur.
Ethereal montre uniquement (en dehors du flux Icmp) deux trames Arp
correspondant aux Request Reply. Deux trames représentant un seul échange.
Le routeur de destination à donc répondu, malgré son cache vide, à l'adresse
Mac source sans émettre d'Arp Request. En plus, les caches des deux Hosts
ont été alimentés.
Ma réponse est en effet incomplète. L'apprentissage se fait aussi sur
les requêtes ARP qui arrivent. L'important dans une bonne
implémentation est que les adresses MAC en question apparaissent dans
un paquet broadcasté (pour éviter qu'une corruption de cache passe
inaperçue).
--
J'ai dû m'inscrire par erreur.
Je vous prie de retirer mon nom de ce groupe. Merci.
-+- DF in Guide du Neunu d'Usenet : Je viens ou je me retire ? -+-
OoO Pendant le temps de midi du mercredi 18 août 2004, vers 12:37, "_SebF - www.frameip.com" disait:
Il n'y a pas d'apprentissage à ce niveau. L'apprentissage se fait uniquement sur les réponses à des requêtes ARP que l'on envoie. Cela évite dans une certaine mesure de corrompre trop facilement le cache ARP.
Je te prends un exemple, Un Xp Ms et un 7206 Cisco sur le même Lan avec des caches Arp vide. La station ping le routeur.
Ethereal montre uniquement (en dehors du flux Icmp) deux trames Arp correspondant aux Request Reply. Deux trames représentant un seul échange. Le routeur de destination à donc répondu, malgré son cache vide, à l'adresse Mac source sans émettre d'Arp Request. En plus, les caches des deux Hosts ont été alimentés.
Ma réponse est en effet incomplète. L'apprentissage se fait aussi sur les requêtes ARP qui arrivent. L'important dans une bonne implémentation est que les adresses MAC en question apparaissent dans un paquet broadcasté (pour éviter qu'une corruption de cache passe inaperçue). -- J'ai dû m'inscrire par erreur. Je vous prie de retirer mon nom de ce groupe. Merci. -+- DF in Guide du Neunu d'Usenet : Je viens ou je me retire ? -+-
Cedric Blancher
Le Wed, 18 Aug 2004 12:37:30 +0200, _SebF - www.frameip.com a écrit :
Ethereal montre uniquement (en dehors du flux Icmp) deux trames Arp correspondant aux Request Reply. Deux trames représentant un seul échange. Le routeur de destination à donc répondu, malgré son cache vide, à l'adresse Mac source sans émettre d'Arp Request. En plus, les caches des deux Hosts ont été alimentés.
Parce que le routeur s'est servi de la requête ARP du XP pour remplir son cache dans la mesure où celle-ci contient toutes les informations nécessaires pour le faire. Le comportement du cache ARP est opportuniste, dans le sens où toute information est utilisée.
Dans le cas présent, si une machine (XP) nous (Cisco) envoie une requête ARP, c'est qu'elle s'apprête à nous envoyer un paquet IP auquel nous devrons probablement répondre. Pour faire l'économie d'une requête ARP, nous prenons les informations mis en source dans le payload de sa requête pour alimenter notre cache. CQFD.
Tu peux aller voir http://www.arp-sk.org/, je pense que la description du fonctionnement du cache ARP qui y est faite est assez complète.
-- BOFH excuse #367:
Webmasters kidnapped by evil cult.
Le Wed, 18 Aug 2004 12:37:30 +0200, _SebF - www.frameip.com a écrit :
Ethereal montre uniquement (en dehors du flux Icmp) deux trames Arp
correspondant aux Request Reply. Deux trames représentant un seul échange.
Le routeur de destination à donc répondu, malgré son cache vide, à l'adresse
Mac source sans émettre d'Arp Request. En plus, les caches des deux Hosts
ont été alimentés.
Parce que le routeur s'est servi de la requête ARP du XP pour remplir son
cache dans la mesure où celle-ci contient toutes les informations
nécessaires pour le faire. Le comportement du cache ARP est opportuniste,
dans le sens où toute information est utilisée.
Dans le cas présent, si une machine (XP) nous (Cisco) envoie une requête
ARP, c'est qu'elle s'apprête à nous envoyer un paquet IP auquel nous
devrons probablement répondre. Pour faire l'économie d'une requête ARP,
nous prenons les informations mis en source dans le payload de sa requête
pour alimenter notre cache. CQFD.
Tu peux aller voir http://www.arp-sk.org/, je pense que la description du
fonctionnement du cache ARP qui y est faite est assez complète.
Le Wed, 18 Aug 2004 12:37:30 +0200, _SebF - www.frameip.com a écrit :
Ethereal montre uniquement (en dehors du flux Icmp) deux trames Arp correspondant aux Request Reply. Deux trames représentant un seul échange. Le routeur de destination à donc répondu, malgré son cache vide, à l'adresse Mac source sans émettre d'Arp Request. En plus, les caches des deux Hosts ont été alimentés.
Parce que le routeur s'est servi de la requête ARP du XP pour remplir son cache dans la mesure où celle-ci contient toutes les informations nécessaires pour le faire. Le comportement du cache ARP est opportuniste, dans le sens où toute information est utilisée.
Dans le cas présent, si une machine (XP) nous (Cisco) envoie une requête ARP, c'est qu'elle s'apprête à nous envoyer un paquet IP auquel nous devrons probablement répondre. Pour faire l'économie d'une requête ARP, nous prenons les informations mis en source dans le payload de sa requête pour alimenter notre cache. CQFD.
Tu peux aller voir http://www.arp-sk.org/, je pense que la description du fonctionnement du cache ARP qui y est faite est assez complète.
-- BOFH excuse #367:
Webmasters kidnapped by evil cult.
Tibo
"Nicolas Favre-Félix" wrote in message news:41231181$0$26980> > Peux tu refaire ton test en
t'assurant que les caches soient vide ?
Je vais regarder la doc, rien ne le permet par l'interface d'administration. (Netgear RP614)
Eteins le et rallume le (au moment du boot, debrouille toi pour que le PC et la passerelle ne communiquent pas, en debranchant le PC du hub.)
"Nicolas Favre-Félix" <n.favrefelix@__free.fr> wrote in message
news:41231181$0$26980> > Peux tu refaire ton test en
t'assurant que les caches soient vide ?
Je vais regarder la doc, rien ne le permet par l'interface
d'administration. (Netgear RP614)
Eteins le et rallume le (au moment du boot, debrouille toi pour que le PC et
la passerelle ne communiquent pas, en debranchant le PC du hub.)
