Cohabitation de deux adressage d'ip sur le même réseau physique.
37 réponses
André Georgel
Bonjour à tous,
J'ai besoin, pour faire des tests, d'intégrer dans mon réseau physique
privé, (192.168.0.xxx en DHCP) deux machines venant d'un autre réseau
d'entreprise dont l'adresage est un adressage de classe C.
les deux machine en classe C fonctionnent entre-elles sans problème, de
même que mes PC perso en DHCP.
Je souhaiterait pouvoir faire du FTP entre une machine de l'adresage
classe C avec un de mes PC.
Comment procéder ?
Je ne souhaite pas reconfigurer les PC d'netreprise ni mes PC perso (le
partage de connexion Internet sous XP impose les adresses en
192.168.0.xxx).
J'ai pensé à un route add mais je ne vois pa comment le faire.
D'avance merci pour vos lumières, qui en ce jour seront, je n'en doute
pas un véritable feu d'artifices !
Andre Georgel
Pour répondre et obtenir l'adresse Email :
http://marreduspam.com/ade0b300
"La perfection n'est pas lorsqu'il n'y a plus rien à ajouter, mais
lorsque qu'il n'y a plus rien à enlever."
"Perfection is not when there is nothing to add, but when there is
nothing to remove."
Et chu presque prêt à vous suivre : une modélisation pourrait donc se représenter comme un empilage de couches, ou comme une vision des interfaces de la machine (rangées dans les couches correspondantes).
Ah bah oui. Le modèle TCP/IP est un modèle théorique. Il n'y a donc pas réellement de couches à part entière, mais des processus système que l'on peut plus ou moins bien séparer en différentes tâches, elles-même agencées en couches (j'ai vraiment l'impression de ne pas être clair :-( )
Comme le dit Eric, il n'y a qu'une pile TCP/IP. Pas une pile par interface ou adresse IP. Cette pile n'est qu'un ensemble de fonctions qui sont appelées les unes par les autres si besoin (par exemple, appelle de la fonction gethostbyname par le resolver, etc.)
Dans le cas de l'IP aliasing, on ne fait qu'ajouter une adresse IP sur une interface. C'est toujours l'interface principale qui est utilisée en priorité. Par contre, la machine répond aux requêtes ARP pour l'adresse IP aliasée, ca se limite à cela.
C'est notamment utile quand on veut faire tourner plusieurs processus avec des droits différents, sur un même port (par exemple le DNS pour une résolution interne et une résolution publique) On créé une nouvelle IP sur l'interface ethernet, et on y associe un processus différent. Ainsi, on peut avoir plusieurs services que le même port, mais qui répondent différemment selon l'IP demandée :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Angelot" <OnSePame@KesceKonSePame.fr> wrote in message
news:cd6bvp$hab$1@news-reader4.wanadoo.fr
Et chu presque prêt à vous suivre : une modélisation pourrait donc se
représenter comme un empilage de couches, ou comme une vision des interfaces
de la machine (rangées dans les couches correspondantes).
Ah bah oui.
Le modèle TCP/IP est un modèle théorique. Il n'y a donc pas réellement
de
couches à part entière, mais des processus système que l'on peut plus
ou moins bien séparer en différentes tâches, elles-même agencées en
couches (j'ai vraiment l'impression de ne pas être clair :-( )
Comme le dit Eric, il n'y a qu'une pile TCP/IP. Pas une pile par
interface ou adresse IP. Cette pile n'est qu'un ensemble de fonctions
qui sont appelées les unes par les autres si besoin (par exemple,
appelle de la fonction gethostbyname par le resolver, etc.)
Dans le cas de l'IP aliasing, on ne fait qu'ajouter une adresse IP
sur une interface. C'est toujours l'interface principale qui est
utilisée en priorité. Par contre, la machine répond aux requêtes ARP
pour l'adresse IP aliasée, ca se limite à cela.
C'est notamment utile quand on veut faire tourner plusieurs processus
avec des droits différents, sur un même port (par exemple le DNS pour
une résolution interne et une résolution publique)
On créé une nouvelle IP sur l'interface ethernet, et on y associe un
processus différent. Ainsi, on peut avoir plusieurs services que le même
port, mais qui répondent différemment selon l'IP demandée :-)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Et chu presque prêt à vous suivre : une modélisation pourrait donc se représenter comme un empilage de couches, ou comme une vision des interfaces de la machine (rangées dans les couches correspondantes).
Ah bah oui. Le modèle TCP/IP est un modèle théorique. Il n'y a donc pas réellement de couches à part entière, mais des processus système que l'on peut plus ou moins bien séparer en différentes tâches, elles-même agencées en couches (j'ai vraiment l'impression de ne pas être clair :-( )
Comme le dit Eric, il n'y a qu'une pile TCP/IP. Pas une pile par interface ou adresse IP. Cette pile n'est qu'un ensemble de fonctions qui sont appelées les unes par les autres si besoin (par exemple, appelle de la fonction gethostbyname par le resolver, etc.)
Dans le cas de l'IP aliasing, on ne fait qu'ajouter une adresse IP sur une interface. C'est toujours l'interface principale qui est utilisée en priorité. Par contre, la machine répond aux requêtes ARP pour l'adresse IP aliasée, ca se limite à cela.
C'est notamment utile quand on veut faire tourner plusieurs processus avec des droits différents, sur un même port (par exemple le DNS pour une résolution interne et une résolution publique) On créé une nouvelle IP sur l'interface ethernet, et on y associe un processus différent. Ainsi, on peut avoir plusieurs services que le même port, mais qui répondent différemment selon l'IP demandée :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Eric Masson
"Angelot" == Angelot writes:
Angelot> une modélisation pourrait donc se représenter comme un Angelot> empilage de couches,
Au niveau protocolaire, seule l'interaction arp/ip n'est pas vraiment représentable de cette manière, les deux étant étroitement imbriqués. Mais pour le reste c'est une simplification acceptable (les implémentations existantes peuvent violer cette archi en couches pour des raisons diverses et variées comme des optimisations, ou autres joyeusetés du genre)
Angelot> ou comme une vision des interfaces de la machine (rangées dans Angelot> les couches correspondantes).
Ben, une interface configurée ajoute une entrée supplémentaire dans la table de routage ip du système. au même titre que l'ajout d'un alias à une interface. La/les encapsulation()s que subira le paquet avant de rejoindre un média physique dépend(ent) uniquement de la table de routage.
En simplifiant :
- si la table de routage donne une route via une interface de périphérique réseau physique, le paquet sera passé au driver de la dite interface pour y subir une encapsulation correspondant au media utilisé et être physiquement placé sur le dit media. - si la table de routage donne une route via une pseudo interface (tunnels divers), le paquet sera passé au driver de la pseudo interface qui effectuera l'encapsulation correspondante et replacera le paquet modifié dans le flux de traitement ip pour une nouvelle itération.
Eric Masson
-- CF : Tu vois l'intérêt d'en faire tourner une sous WinCE ? PAD: L'écran bleu ? SP : Voilà. Une sorte de "Game over" aléatoire, en fait... + SP in Guide du Macounet Pervers : Playstation II c plus fort que toi+
Angelot> une modélisation pourrait donc se représenter comme un
Angelot> empilage de couches,
Au niveau protocolaire, seule l'interaction arp/ip n'est pas vraiment
représentable de cette manière, les deux étant étroitement imbriqués.
Mais pour le reste c'est une simplification acceptable (les
implémentations existantes peuvent violer cette archi en couches pour
des raisons diverses et variées comme des optimisations, ou autres
joyeusetés du genre)
Angelot> ou comme une vision des interfaces de la machine (rangées dans
Angelot> les couches correspondantes).
Ben, une interface configurée ajoute une entrée supplémentaire dans la
table de routage ip du système. au même titre que l'ajout d'un alias à
une interface. La/les encapsulation()s que subira le paquet avant de
rejoindre un média physique dépend(ent) uniquement de la table de
routage.
En simplifiant :
- si la table de routage donne une route via une interface de
périphérique réseau physique, le paquet sera passé au driver de la dite
interface pour y subir une encapsulation correspondant au media utilisé
et être physiquement placé sur le dit media.
- si la table de routage donne une route via une pseudo interface
(tunnels divers), le paquet sera passé au driver de la pseudo interface
qui effectuera l'encapsulation correspondante et replacera le paquet
modifié dans le flux de traitement ip pour une nouvelle itération.
Eric Masson
--
CF : Tu vois l'intérêt d'en faire tourner une sous WinCE ?
PAD: L'écran bleu ?
SP : Voilà. Une sorte de "Game over" aléatoire, en fait...
+ SP in Guide du Macounet Pervers : Playstation II c plus fort que toi+
Angelot> une modélisation pourrait donc se représenter comme un Angelot> empilage de couches,
Au niveau protocolaire, seule l'interaction arp/ip n'est pas vraiment représentable de cette manière, les deux étant étroitement imbriqués. Mais pour le reste c'est une simplification acceptable (les implémentations existantes peuvent violer cette archi en couches pour des raisons diverses et variées comme des optimisations, ou autres joyeusetés du genre)
Angelot> ou comme une vision des interfaces de la machine (rangées dans Angelot> les couches correspondantes).
Ben, une interface configurée ajoute une entrée supplémentaire dans la table de routage ip du système. au même titre que l'ajout d'un alias à une interface. La/les encapsulation()s que subira le paquet avant de rejoindre un média physique dépend(ent) uniquement de la table de routage.
En simplifiant :
- si la table de routage donne une route via une interface de périphérique réseau physique, le paquet sera passé au driver de la dite interface pour y subir une encapsulation correspondant au media utilisé et être physiquement placé sur le dit media. - si la table de routage donne une route via une pseudo interface (tunnels divers), le paquet sera passé au driver de la pseudo interface qui effectuera l'encapsulation correspondante et replacera le paquet modifié dans le flux de traitement ip pour une nouvelle itération.
Eric Masson
-- CF : Tu vois l'intérêt d'en faire tourner une sous WinCE ? PAD: L'écran bleu ? SP : Voilà. Une sorte de "Game over" aléatoire, en fait... + SP in Guide du Macounet Pervers : Playstation II c plus fort que toi+
Eric Masson
"Angelot" == Angelot writes:
Angelot> une modélisation pourrait donc se représenter comme un Angelot> empilage de couches,
Au niveau protocolaire, seule l'interaction arp/ip n'est pas vraiment représentable de cette manière, les deux étant étroitement imbriqués. Mais pour le reste c'est une simplification acceptable (les implémentations existantes peuvent violer cette archi en couches pour des raisons diverses et variées comme des optimisations, ou autres joyeusetés du genre)
Angelot> ou comme une vision des interfaces de la machine (rangées dans Angelot> les couches correspondantes).
Ben, une interface configurée ajoute une entrée supplémentaire dans la table de routage ip du système. au même titre que l'ajout d'un alias à une interface. La/les encapsulation()s que subira le paquet avant de rejoindre un média physique (si nécessaire) dépend(ent) uniquement de la table de routage.
En simplifiant :
- si la table de routage donne une route via une interface de périphérique réseau physique, le paquet sera passé au driver de la dite interface pour y subir une encapsulation correspondant au media utilisé et être physiquement placé sur le dit media. - si la table de routage donne une route via une pseudo interface (tunnels divers), le paquet sera passé au driver de la pseudo interface qui effectuera l'encapsulation correspondante et replacera le paquet modifié dans le flux de traitement ip pour une nouvelle itération.
Eric Masson
-- CF : Tu vois l'intérêt d'en faire tourner une sous WinCE ? PAD: L'écran bleu ? SP : Voilà. Une sorte de "Game over" aléatoire, en fait... + SP in Guide du Macounet Pervers : Playstation II c plus fort que toi+
Angelot> une modélisation pourrait donc se représenter comme un
Angelot> empilage de couches,
Au niveau protocolaire, seule l'interaction arp/ip n'est pas vraiment
représentable de cette manière, les deux étant étroitement imbriqués.
Mais pour le reste c'est une simplification acceptable (les
implémentations existantes peuvent violer cette archi en couches pour
des raisons diverses et variées comme des optimisations, ou autres
joyeusetés du genre)
Angelot> ou comme une vision des interfaces de la machine (rangées dans
Angelot> les couches correspondantes).
Ben, une interface configurée ajoute une entrée supplémentaire dans la
table de routage ip du système. au même titre que l'ajout d'un alias à
une interface. La/les encapsulation()s que subira le paquet avant de
rejoindre un média physique (si nécessaire) dépend(ent) uniquement de la
table de routage.
En simplifiant :
- si la table de routage donne une route via une interface de
périphérique réseau physique, le paquet sera passé au driver de la dite
interface pour y subir une encapsulation correspondant au media utilisé
et être physiquement placé sur le dit media.
- si la table de routage donne une route via une pseudo interface
(tunnels divers), le paquet sera passé au driver de la pseudo interface
qui effectuera l'encapsulation correspondante et replacera le paquet
modifié dans le flux de traitement ip pour une nouvelle itération.
Eric Masson
--
CF : Tu vois l'intérêt d'en faire tourner une sous WinCE ?
PAD: L'écran bleu ?
SP : Voilà. Une sorte de "Game over" aléatoire, en fait...
+ SP in Guide du Macounet Pervers : Playstation II c plus fort que toi+
Angelot> une modélisation pourrait donc se représenter comme un Angelot> empilage de couches,
Au niveau protocolaire, seule l'interaction arp/ip n'est pas vraiment représentable de cette manière, les deux étant étroitement imbriqués. Mais pour le reste c'est une simplification acceptable (les implémentations existantes peuvent violer cette archi en couches pour des raisons diverses et variées comme des optimisations, ou autres joyeusetés du genre)
Angelot> ou comme une vision des interfaces de la machine (rangées dans Angelot> les couches correspondantes).
Ben, une interface configurée ajoute une entrée supplémentaire dans la table de routage ip du système. au même titre que l'ajout d'un alias à une interface. La/les encapsulation()s que subira le paquet avant de rejoindre un média physique (si nécessaire) dépend(ent) uniquement de la table de routage.
En simplifiant :
- si la table de routage donne une route via une interface de périphérique réseau physique, le paquet sera passé au driver de la dite interface pour y subir une encapsulation correspondant au media utilisé et être physiquement placé sur le dit media. - si la table de routage donne une route via une pseudo interface (tunnels divers), le paquet sera passé au driver de la pseudo interface qui effectuera l'encapsulation correspondante et replacera le paquet modifié dans le flux de traitement ip pour une nouvelle itération.
Eric Masson
-- CF : Tu vois l'intérêt d'en faire tourner une sous WinCE ? PAD: L'écran bleu ? SP : Voilà. Une sorte de "Game over" aléatoire, en fait... + SP in Guide du Macounet Pervers : Playstation II c plus fort que toi+
Angelot
Bonjoue T0t0,
Le modèle TCP/IP est un modèle théorique. Il n'y a donc pas réellement de couches à part entière, mais des processus système que l'on peut plus ou moins bien séparer en différentes tâches, elles-même agencées en couches (j'ai vraiment l'impression de ne pas être clair :-( )
C'est clair ! Une couche se concrétise par une suite ordonnée de processus du système d'exploitation dont les actions se réalisent sur un ensemble bien déterminée des données reçues.
Comme le dit Eric, il n'y a qu'une pile TCP/IP. Pas une pile par interface ou adresse IP. Cette pile n'est qu'un ensemble de fonctions qui sont appelées les unes par les autres si besoin (par exemple, appelle de la fonction gethostbyname par le resolver, etc.)
Je diverge : il existe une pile TCP/IP par machine (à un instant donné). La pile TCP/IP de mon PC ne comporte pas SNMP, ni le protocole de transport SCTP, ni...
L'expression "pile TCP/IP" est une forme abrégée de l'écriture "pile des protocoles (de couche) du modèle TCP/IP" et la pile s'applique à une machine définie ou, encore, à une catégorie bien définie de machines. Toutes les machines n'ont pas besoin d'être dotée de tous les protocoles TCP/IP.
Néanmoins, j'ai pris conscience de la distinction entre la représentation de la pile TCP/IP d'une machine, et de la représentation de ses interfaces TCP/IP (la seconde comportant d'ailleurs toutes les indications pour déduire la première). Dans le même ordre d'idée, OSI utilisait la notion de point d'accès aux services (SAP), ce qui n'a pas pas été un terme repris dans le monde TCP/IP.
Dans le cas de l'IP aliasing, on ne fait qu'ajouter une adresse IP sur une interface. C'est toujours l'interface principale qui est utilisée en priorité. Par contre, la machine répond aux requêtes ARP pour l'adresse IP aliasée, ca se limite à cela.
Et probablement aux datagrammes IP à destination des adresses IP alias.
C'est notamment utile quand on veut faire tourner plusieurs processus avec des droits différents, sur un même port (par exemple le DNS pour une résolution interne et une résolution publique) On créé une nouvelle IP sur l'interface ethernet, et on y associe un processus différent. Ainsi, on peut avoir plusieurs services que le même port, mais qui répondent différemment selon l'IP demandée :-)
Merci, je note.
Cordialement, Angelot
Bonjoue T0t0,
Le modèle TCP/IP est un modèle théorique. Il n'y a donc pas réellement
de
couches à part entière, mais des processus système que l'on peut plus
ou moins bien séparer en différentes tâches, elles-même agencées en
couches (j'ai vraiment l'impression de ne pas être clair :-( )
C'est clair ! Une couche se concrétise par une suite ordonnée de processus
du système d'exploitation dont les actions se réalisent sur un ensemble bien
déterminée des données reçues.
Comme le dit Eric, il n'y a qu'une pile TCP/IP. Pas une pile par
interface ou adresse IP. Cette pile n'est qu'un ensemble de fonctions
qui sont appelées les unes par les autres si besoin (par exemple,
appelle de la fonction gethostbyname par le resolver, etc.)
Je diverge : il existe une pile TCP/IP par machine (à un instant donné). La
pile TCP/IP de mon PC ne comporte pas SNMP, ni le protocole de transport
SCTP, ni...
L'expression "pile TCP/IP" est une forme abrégée de l'écriture "pile des
protocoles (de couche) du modèle TCP/IP" et la pile s'applique à une machine
définie ou, encore, à une catégorie bien définie de machines. Toutes les
machines n'ont pas besoin d'être dotée de tous les protocoles TCP/IP.
Néanmoins, j'ai pris conscience de la distinction entre la représentation de
la pile TCP/IP d'une machine, et de la représentation de ses interfaces
TCP/IP (la seconde comportant d'ailleurs toutes les indications pour déduire
la première). Dans le même ordre d'idée, OSI utilisait la notion de point
d'accès aux services (SAP), ce qui n'a pas pas été un terme repris dans le
monde TCP/IP.
Dans le cas de l'IP aliasing, on ne fait qu'ajouter une adresse IP
sur une interface. C'est toujours l'interface principale qui est
utilisée en priorité. Par contre, la machine répond aux requêtes ARP
pour l'adresse IP aliasée, ca se limite à cela.
Et probablement aux datagrammes IP à destination des adresses IP alias.
C'est notamment utile quand on veut faire tourner plusieurs processus
avec des droits différents, sur un même port (par exemple le DNS pour
une résolution interne et une résolution publique)
On créé une nouvelle IP sur l'interface ethernet, et on y associe un
processus différent. Ainsi, on peut avoir plusieurs services que le même
port, mais qui répondent différemment selon l'IP demandée :-)
Le modèle TCP/IP est un modèle théorique. Il n'y a donc pas réellement de couches à part entière, mais des processus système que l'on peut plus ou moins bien séparer en différentes tâches, elles-même agencées en couches (j'ai vraiment l'impression de ne pas être clair :-( )
C'est clair ! Une couche se concrétise par une suite ordonnée de processus du système d'exploitation dont les actions se réalisent sur un ensemble bien déterminée des données reçues.
Comme le dit Eric, il n'y a qu'une pile TCP/IP. Pas une pile par interface ou adresse IP. Cette pile n'est qu'un ensemble de fonctions qui sont appelées les unes par les autres si besoin (par exemple, appelle de la fonction gethostbyname par le resolver, etc.)
Je diverge : il existe une pile TCP/IP par machine (à un instant donné). La pile TCP/IP de mon PC ne comporte pas SNMP, ni le protocole de transport SCTP, ni...
L'expression "pile TCP/IP" est une forme abrégée de l'écriture "pile des protocoles (de couche) du modèle TCP/IP" et la pile s'applique à une machine définie ou, encore, à une catégorie bien définie de machines. Toutes les machines n'ont pas besoin d'être dotée de tous les protocoles TCP/IP.
Néanmoins, j'ai pris conscience de la distinction entre la représentation de la pile TCP/IP d'une machine, et de la représentation de ses interfaces TCP/IP (la seconde comportant d'ailleurs toutes les indications pour déduire la première). Dans le même ordre d'idée, OSI utilisait la notion de point d'accès aux services (SAP), ce qui n'a pas pas été un terme repris dans le monde TCP/IP.
Dans le cas de l'IP aliasing, on ne fait qu'ajouter une adresse IP sur une interface. C'est toujours l'interface principale qui est utilisée en priorité. Par contre, la machine répond aux requêtes ARP pour l'adresse IP aliasée, ca se limite à cela.
Et probablement aux datagrammes IP à destination des adresses IP alias.
C'est notamment utile quand on veut faire tourner plusieurs processus avec des droits différents, sur un même port (par exemple le DNS pour une résolution interne et une résolution publique) On créé une nouvelle IP sur l'interface ethernet, et on y associe un processus différent. Ainsi, on peut avoir plusieurs services que le même port, mais qui répondent différemment selon l'IP demandée :-)
Merci, je note.
Cordialement, Angelot
Eric Masson
"Angelot" == Angelot writes:
Angelot> Je diverge : il existe une pile TCP/IP par machine (à un Angelot> instant donné). La pile TCP/IP de mon PC ne comporte pas SNMP, Angelot> ni le protocole de transport SCTP, ni...
La pile tcp/ip d'un machine se limite à fournir des transports.
SNMP, SCTP sont des applications qui font appel aux services de la dite pile et ne font pas à ce titre partie de la pile en elle-même.
Angelot> Et probablement aux datagrammes IP à destination des adresses Angelot> IP alias.
Ben ça découle du fait qu'elle réponde aux requêtes arp pour l'adresse d'alias, quel serait l'intérêt de répondre aux requêtes arp si c'est pour ne pas traiter le trafic concernant la dite adresse ?
Eric Masson
-- Je poste des messages de demeuré parce que j'ai une réputation de demeuré à défendre. On n'imagine pas combien une telle réputation est difficile à établir. Son entretien est un souci permanent... -+- EB in Guide du Neuneu sur Usenet : Une réputation, deux meurés. -+-
Angelot> Je diverge : il existe une pile TCP/IP par machine (à un
Angelot> instant donné). La pile TCP/IP de mon PC ne comporte pas SNMP,
Angelot> ni le protocole de transport SCTP, ni...
La pile tcp/ip d'un machine se limite à fournir des transports.
SNMP, SCTP sont des applications qui font appel aux services de la dite
pile et ne font pas à ce titre partie de la pile en elle-même.
Angelot> Et probablement aux datagrammes IP à destination des adresses
Angelot> IP alias.
Ben ça découle du fait qu'elle réponde aux requêtes arp pour l'adresse
d'alias, quel serait l'intérêt de répondre aux requêtes arp si c'est
pour ne pas traiter le trafic concernant la dite adresse ?
Eric Masson
--
Je poste des messages de demeuré parce que j'ai une réputation de
demeuré à défendre. On n'imagine pas combien une telle réputation est
difficile à établir. Son entretien est un souci permanent...
-+- EB in Guide du Neuneu sur Usenet : Une réputation, deux meurés. -+-
Angelot> Je diverge : il existe une pile TCP/IP par machine (à un Angelot> instant donné). La pile TCP/IP de mon PC ne comporte pas SNMP, Angelot> ni le protocole de transport SCTP, ni...
La pile tcp/ip d'un machine se limite à fournir des transports.
SNMP, SCTP sont des applications qui font appel aux services de la dite pile et ne font pas à ce titre partie de la pile en elle-même.
Angelot> Et probablement aux datagrammes IP à destination des adresses Angelot> IP alias.
Ben ça découle du fait qu'elle réponde aux requêtes arp pour l'adresse d'alias, quel serait l'intérêt de répondre aux requêtes arp si c'est pour ne pas traiter le trafic concernant la dite adresse ?
Eric Masson
-- Je poste des messages de demeuré parce que j'ai une réputation de demeuré à défendre. On n'imagine pas combien une telle réputation est difficile à établir. Son entretien est un souci permanent... -+- EB in Guide du Neuneu sur Usenet : Une réputation, deux meurés. -+-
Eric Masson
"Eric" == Eric Masson writes:
Eric> Ben ça découle du fait qu'elle réponde aux requêtes arp pour Eric> l'adresse d'alias, quel serait l'intérêt de répondre aux requêtes Eric> arp si c'est pour ne pas traiter le trafic concernant la dite Eric> adresse ?
Il y en aurait bien sûr un et immédiat, mettre le bronx sur le lan (corruption de cache arp), mais je me place bien sûr dans le cadre d'une utilisation orthodoxe du lan.
Eric Masson
-- C'est quoi les dinos ? J'ai compris que c'était des vieux cons, mais à part ça ?? -+- CL in GNU : Je ne voudrais pas passer pour un con... Loupé. -+-
"Eric" == Eric Masson <emss@free.fr> writes:
Eric> Ben ça découle du fait qu'elle réponde aux requêtes arp pour
Eric> l'adresse d'alias, quel serait l'intérêt de répondre aux requêtes
Eric> arp si c'est pour ne pas traiter le trafic concernant la dite
Eric> adresse ?
Il y en aurait bien sûr un et immédiat, mettre le bronx sur le lan
(corruption de cache arp), mais je me place bien sûr dans le cadre d'une
utilisation orthodoxe du lan.
Eric Masson
--
C'est quoi les dinos ?
J'ai compris que c'était des vieux cons, mais à part ça ??
-+- CL in GNU : Je ne voudrais pas passer pour un con... Loupé. -+-
Eric> Ben ça découle du fait qu'elle réponde aux requêtes arp pour Eric> l'adresse d'alias, quel serait l'intérêt de répondre aux requêtes Eric> arp si c'est pour ne pas traiter le trafic concernant la dite Eric> adresse ?
Il y en aurait bien sûr un et immédiat, mettre le bronx sur le lan (corruption de cache arp), mais je me place bien sûr dans le cadre d'une utilisation orthodoxe du lan.
Eric Masson
-- C'est quoi les dinos ? J'ai compris que c'était des vieux cons, mais à part ça ?? -+- CL in GNU : Je ne voudrais pas passer pour un con... Loupé. -+-
T0t0
"Angelot" wrote in message news:cd89if$d81$
C'est clair ! Une couche se concrétise par une suite ordonnée de processus du système d'exploitation dont les actions se réalisent sur un ensemble bien déterminée des données reçues.
Yep !
Je diverge : il existe une pile TCP/IP par machine (à un instant donné). La pile TCP/IP de mon PC ne comporte pas SNMP, ni le protocole de transport SCTP, ni...
Normal, puisque la dite pile TCP/IP se borne aux couches 3 et 4 (on peut y intégrer la couche 2 avec Ethernet ou autre protocoles de liaison, mais ce n'est pas normalisé par TCP/IP) Elles fournissent aux couches applicatives le transport des informations. Mais les couches applicatives n'en font pas partie.
L'expression "pile TCP/IP" est une forme abrégée de l'écriture "pile des protocoles (de couche) du modèle TCP/IP" et la pile s'applique à une machine définie ou, encore, à une catégorie bien définie de machines. Toutes les machines n'ont pas besoin d'être dotée de tous les protocoles TCP/IP.
Normalement si, tu dois avoir IP, ARP, ICMP, ainsi qu'UDP et TCP si tu veux que ca fonctionne. Ensuite, tu peux faire transiter des protocoles applicatifs grâce à ces protocoles de la pile TCP/IP.
Dans le cas de l'IP aliasing, on ne fait qu'ajouter une adresse IP sur une interface. C'est toujours l'interface principale qui est utilisée en priorité. Par contre, la machine répond aux requêtes ARP pour l'adresse IP aliasée, ca se limite à cela. Et probablement aux datagrammes IP à destination des adresses IP alias.
Tout à fait.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Angelot" <OnSePame@KesceKonSePame.fr> wrote in message
news:cd89if$d81$1@news-reader1.wanadoo.fr
C'est clair ! Une couche se concrétise par une suite ordonnée de processus
du système d'exploitation dont les actions se réalisent sur un ensemble bien
déterminée des données reçues.
Yep !
Je diverge : il existe une pile TCP/IP par machine (à un instant donné). La
pile TCP/IP de mon PC ne comporte pas SNMP, ni le protocole de transport
SCTP, ni...
Normal, puisque la dite pile TCP/IP se borne aux couches 3 et 4
(on peut y intégrer la couche 2 avec Ethernet ou autre protocoles de
liaison, mais ce n'est pas normalisé par TCP/IP)
Elles fournissent aux couches applicatives le transport des
informations. Mais les couches applicatives n'en font pas partie.
L'expression "pile TCP/IP" est une forme abrégée de l'écriture "pile des
protocoles (de couche) du modèle TCP/IP" et la pile s'applique à une machine
définie ou, encore, à une catégorie bien définie de machines. Toutes les
machines n'ont pas besoin d'être dotée de tous les protocoles TCP/IP.
Normalement si, tu dois avoir IP, ARP, ICMP, ainsi qu'UDP et TCP si tu
veux que ca fonctionne.
Ensuite, tu peux faire transiter des protocoles applicatifs grâce à
ces protocoles de la pile TCP/IP.
Dans le cas de l'IP aliasing, on ne fait qu'ajouter une adresse IP
sur une interface. C'est toujours l'interface principale qui est
utilisée en priorité. Par contre, la machine répond aux requêtes ARP
pour l'adresse IP aliasée, ca se limite à cela.
Et probablement aux datagrammes IP à destination des adresses IP alias.
Tout à fait.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
C'est clair ! Une couche se concrétise par une suite ordonnée de processus du système d'exploitation dont les actions se réalisent sur un ensemble bien déterminée des données reçues.
Yep !
Je diverge : il existe une pile TCP/IP par machine (à un instant donné). La pile TCP/IP de mon PC ne comporte pas SNMP, ni le protocole de transport SCTP, ni...
Normal, puisque la dite pile TCP/IP se borne aux couches 3 et 4 (on peut y intégrer la couche 2 avec Ethernet ou autre protocoles de liaison, mais ce n'est pas normalisé par TCP/IP) Elles fournissent aux couches applicatives le transport des informations. Mais les couches applicatives n'en font pas partie.
L'expression "pile TCP/IP" est une forme abrégée de l'écriture "pile des protocoles (de couche) du modèle TCP/IP" et la pile s'applique à une machine définie ou, encore, à une catégorie bien définie de machines. Toutes les machines n'ont pas besoin d'être dotée de tous les protocoles TCP/IP.
Normalement si, tu dois avoir IP, ARP, ICMP, ainsi qu'UDP et TCP si tu veux que ca fonctionne. Ensuite, tu peux faire transiter des protocoles applicatifs grâce à ces protocoles de la pile TCP/IP.
Dans le cas de l'IP aliasing, on ne fait qu'ajouter une adresse IP sur une interface. C'est toujours l'interface principale qui est utilisée en priorité. Par contre, la machine répond aux requêtes ARP pour l'adresse IP aliasée, ca se limite à cela. Et probablement aux datagrammes IP à destination des adresses IP alias.
Tout à fait.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Angelot
Bonjour Eric,
SNMP, SCTP sont des applications qui font appel aux services de la dite pile et ne font pas à ce titre partie de la pile en elle-même.
Diantre ! que si. En outre SCTP est un protocole de couche transport, au niveau TCP et UDP. La pile TCP/IP se déploie depuis la couche accès réseau jusqu'à la couche application : et SNMP fait partie de la pile, parbleu !
Je réitère : pile = pile de protocoles de couche
Ben ça découle du fait qu'elle réponde aux requêtes arp pour l'adresse d'alias, quel serait l'intérêt de répondre aux requêtes arp si c'est pour ne pas traiter le trafic concernant la dite adresse ?
Oui, aucun intérêt.
Vous connaissez cette histoire ? Un voyageur dans un train pointe de son doigt la campagne qui défile. Il s'adresse à son voisin : "vous avez vu le mouton noir dans le troupeau ?". Le voisin rétorque : "Ah non ! mon cher, nous avons observé un mouton avec un côté entièrement noir, mais rien ne nous dit que la face opposée était aussi noire".
Cordialement, Angelot
Bonjour Eric,
SNMP, SCTP sont des applications qui font appel aux services de la dite
pile et ne font pas à ce titre partie de la pile en elle-même.
Diantre ! que si. En outre SCTP est un protocole de couche transport, au
niveau TCP et UDP. La pile TCP/IP se déploie depuis la couche accès réseau
jusqu'à la couche application : et SNMP fait partie de la pile, parbleu !
Je réitère : pile = pile de protocoles de couche
Ben ça découle du fait qu'elle réponde aux requêtes arp pour l'adresse
d'alias, quel serait l'intérêt de répondre aux requêtes arp si c'est
pour ne pas traiter le trafic concernant la dite adresse ?
Oui, aucun intérêt.
Vous connaissez cette histoire ?
Un voyageur dans un train pointe de son doigt la campagne qui défile. Il
s'adresse à son voisin : "vous avez vu le mouton noir dans le troupeau ?".
Le voisin rétorque : "Ah non ! mon cher, nous avons observé un mouton avec
un côté entièrement noir, mais rien ne nous dit que la face opposée était
aussi noire".
SNMP, SCTP sont des applications qui font appel aux services de la dite pile et ne font pas à ce titre partie de la pile en elle-même.
Diantre ! que si. En outre SCTP est un protocole de couche transport, au niveau TCP et UDP. La pile TCP/IP se déploie depuis la couche accès réseau jusqu'à la couche application : et SNMP fait partie de la pile, parbleu !
Je réitère : pile = pile de protocoles de couche
Ben ça découle du fait qu'elle réponde aux requêtes arp pour l'adresse d'alias, quel serait l'intérêt de répondre aux requêtes arp si c'est pour ne pas traiter le trafic concernant la dite adresse ?
Oui, aucun intérêt.
Vous connaissez cette histoire ? Un voyageur dans un train pointe de son doigt la campagne qui défile. Il s'adresse à son voisin : "vous avez vu le mouton noir dans le troupeau ?". Le voisin rétorque : "Ah non ! mon cher, nous avons observé un mouton avec un côté entièrement noir, mais rien ne nous dit que la face opposée était aussi noire".
Cordialement, Angelot
Angelot
Bonjour T0t0,
Normal, puisque la dite pile TCP/IP se borne aux couches 3 et 4 (on peut y intégrer la couche 2 avec Ethernet ou autre protocoles de liaison, mais ce n'est pas normalisé par TCP/IP)
C'est assez personnel comme représentation...
Elles fournissent aux couches applicatives le transport des informations. Mais les couches applicatives n'en font pas partie.
Sglurk ! tu confonds probablement application logicielle, couche application TCP/IP, et couche application OSI.
Angelot
Bonjour T0t0,
Normal, puisque la dite pile TCP/IP se borne aux couches 3 et 4
(on peut y intégrer la couche 2 avec Ethernet ou autre protocoles de
liaison, mais ce n'est pas normalisé par TCP/IP)
C'est assez personnel comme représentation...
Elles fournissent aux couches applicatives le transport des
informations. Mais les couches applicatives n'en font pas partie.
Sglurk ! tu confonds probablement application logicielle, couche application
TCP/IP, et couche application OSI.
Normal, puisque la dite pile TCP/IP se borne aux couches 3 et 4 (on peut y intégrer la couche 2 avec Ethernet ou autre protocoles de liaison, mais ce n'est pas normalisé par TCP/IP)
C'est assez personnel comme représentation...
Elles fournissent aux couches applicatives le transport des informations. Mais les couches applicatives n'en font pas partie.
Sglurk ! tu confonds probablement application logicielle, couche application TCP/IP, et couche application OSI.
Angelot
Eric Masson
"Angelot" == Angelot writes:
Angelotf> En outre SCTP est un protocole de couche transport, au niveau Angelotf> TCP et UDP.
My bad, je viens de voir la rfc :/
Angelotf> La pile TCP/IP se déploie depuis la couche accès réseau Angelotf> jusqu'à la couche application : et SNMP fait partie de la Angelotf> pile, parbleu !
Façon de voir les choses, je pose la distinction entre les services fournis par le noyau (ce qu'on appelle communément la pile ip d'un système dans le monde unix) et les applis userland.
Tel que tu définis la pile, toute appli ouvrant une socket de type AF_INET ou AF_INET6 en fait partie.
Eric Masson
-- Personnelement je lis de haut en bas et de droite à gauche et pas l'inverse. ? ac emmoc siavircé'j is tnaihc sap tiares en aC -+-LS in <http://www.le-gnu.net> fbq, le bon sens loin de chez vous -+-
Angelotf> En outre SCTP est un protocole de couche transport, au niveau
Angelotf> TCP et UDP.
My bad, je viens de voir la rfc :/
Angelotf> La pile TCP/IP se déploie depuis la couche accès réseau
Angelotf> jusqu'à la couche application : et SNMP fait partie de la
Angelotf> pile, parbleu !
Façon de voir les choses, je pose la distinction entre les services
fournis par le noyau (ce qu'on appelle communément la pile ip d'un
système dans le monde unix) et les applis userland.
Tel que tu définis la pile, toute appli ouvrant une socket de type
AF_INET ou AF_INET6 en fait partie.
Eric Masson
--
Personnelement je lis de haut en bas et de droite à gauche et pas
l'inverse. ?
ac emmoc siavircé'j is tnaihc sap tiares en aC
-+-LS in <http://www.le-gnu.net> fbq, le bon sens loin de chez vous -+-
Angelotf> En outre SCTP est un protocole de couche transport, au niveau Angelotf> TCP et UDP.
My bad, je viens de voir la rfc :/
Angelotf> La pile TCP/IP se déploie depuis la couche accès réseau Angelotf> jusqu'à la couche application : et SNMP fait partie de la Angelotf> pile, parbleu !
Façon de voir les choses, je pose la distinction entre les services fournis par le noyau (ce qu'on appelle communément la pile ip d'un système dans le monde unix) et les applis userland.
Tel que tu définis la pile, toute appli ouvrant une socket de type AF_INET ou AF_INET6 en fait partie.
Eric Masson
-- Personnelement je lis de haut en bas et de droite à gauche et pas l'inverse. ? ac emmoc siavircé'j is tnaihc sap tiares en aC -+-LS in <http://www.le-gnu.net> fbq, le bon sens loin de chez vous -+-
