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."
Au niveau protocolaire, seule l'interaction arp/ip n'est pas vraiment représentable de cette manière, les deux étant étroitement imbriqués.
On parle de datagramme ARP et de datagramme IP : le terme datagramme se réfère à la couche internet. Et l'usage veut que l'on appelle aussi couche IP la couche internet : suffit de bien comprendre ce que l'on manipule.
De la même façon, on confond souvent l'architecture ATM avec le protocole de la couche ATM : ceci est plus grave.
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)
Je ne crois pas, mais c'est une autre passionnante histoire qu'il faudrait revoir. La recommandation I.320 donne quelques indications sur l'imbrication des modèles. L'aspect brouhaha est assez organisé (et non markovien).
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.
Merci pour ces détails, je note les aspects développements.
Cordialement, Angelot
Au niveau protocolaire, seule l'interaction arp/ip n'est pas vraiment
représentable de cette manière, les deux étant étroitement imbriqués.
On parle de datagramme ARP et de datagramme IP : le terme datagramme se
réfère à la couche internet.
Et l'usage veut que l'on appelle aussi couche IP la couche internet : suffit
de bien comprendre ce que l'on manipule.
De la même façon, on confond souvent l'architecture ATM avec le protocole de
la couche ATM : ceci est plus grave.
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)
Je ne crois pas, mais c'est une autre passionnante histoire qu'il faudrait
revoir. La recommandation I.320 donne quelques indications sur l'imbrication
des modèles. L'aspect brouhaha est assez organisé (et non markovien).
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.
Merci pour ces détails, je note les aspects développements.
Au niveau protocolaire, seule l'interaction arp/ip n'est pas vraiment représentable de cette manière, les deux étant étroitement imbriqués.
On parle de datagramme ARP et de datagramme IP : le terme datagramme se réfère à la couche internet. Et l'usage veut que l'on appelle aussi couche IP la couche internet : suffit de bien comprendre ce que l'on manipule.
De la même façon, on confond souvent l'architecture ATM avec le protocole de la couche ATM : ceci est plus grave.
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)
Je ne crois pas, mais c'est une autre passionnante histoire qu'il faudrait revoir. La recommandation I.320 donne quelques indications sur l'imbrication des modèles. L'aspect brouhaha est assez organisé (et non markovien).
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.
Merci pour ces détails, je note les aspects développements.
Cordialement, Angelot
PYT
Bonjour. Je me permets d'intervenir, juste pour remercier Angelot de ces interventions: sa modélisation et son approche sont assez proches des miennes. Ses interventions et les réponses pas toujours claires du premier coup (il reformule bien pour faire avancer) mais patientes, nous permettent de progresser.
Merci.
Bonjour.
Je me permets d'intervenir, juste pour remercier Angelot de ces
interventions: sa modélisation et son approche sont assez proches des
miennes. Ses interventions et les réponses pas toujours claires du premier
coup (il reformule bien pour faire avancer) mais patientes, nous permettent
de progresser.
Bonjour. Je me permets d'intervenir, juste pour remercier Angelot de ces interventions: sa modélisation et son approche sont assez proches des miennes. Ses interventions et les réponses pas toujours claires du premier coup (il reformule bien pour faire avancer) mais patientes, nous permettent de progresser.
Merci.
T0t0
"Angelot" wrote in message news:cd8jkm$d7t$
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...
C'est peut-être une interprétation du "TCP/IP illustré" de R.Stevens.
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.
Peut-être. Pour moi application logicielle est décorellée de l'idée de réseau. Couche applicative TCP/IP n'a pas de sens puisque l'application est décorellée de TCP/IP. Couche application OSI représente le niveau 7 du modèle OSI. Soit une application qui s'appuie sur des protocoles pour dialoguer sur le réseau.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Angelot" <OnSePame@KesceKonSePame.fr> wrote in message
news:cd8jkm$d7t$1@news-reader5.wanadoo.fr
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...
C'est peut-être une interprétation du "TCP/IP illustré" de R.Stevens.
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.
Peut-être.
Pour moi application logicielle est décorellée de l'idée de réseau.
Couche applicative TCP/IP n'a pas de sens puisque l'application est
décorellée de TCP/IP.
Couche application OSI représente le niveau 7 du modèle OSI. Soit
une application qui s'appuie sur des protocoles pour dialoguer sur le
réseau.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
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...
C'est peut-être une interprétation du "TCP/IP illustré" de R.Stevens.
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.
Peut-être. Pour moi application logicielle est décorellée de l'idée de réseau. Couche applicative TCP/IP n'a pas de sens puisque l'application est décorellée de TCP/IP. Couche application OSI représente le niveau 7 du modèle OSI. Soit une application qui s'appuie sur des protocoles pour dialoguer sur le réseau.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Angelot
Bonsoir T0t0,
C'est peut-être une interprétation du "TCP/IP illustré" de R.Stevens.
Observe par exemple RFC1122 (§1.1.3 Internet Protocol Suite).
Pour moi application logicielle est décorellée de l'idée de réseau.
Oui
Couche applicative TCP/IP n'a pas de sens puisque l'application est décorellée de TCP/IP.
Non, au-dessus d'une couche applicative existe une application qui lui indique les octets à transmettre (IE pour HTTP par exemple).
Cordialement, Angelot
Bonsoir T0t0,
C'est peut-être une interprétation du "TCP/IP illustré" de R.Stevens.
Observe par exemple RFC1122 (§1.1.3 Internet Protocol Suite).
Pour moi application logicielle est décorellée de l'idée de réseau.
Oui
Couche applicative TCP/IP n'a pas de sens puisque l'application est
décorellée de TCP/IP.
Non, au-dessus d'une couche applicative existe une application qui lui
indique les octets à transmettre (IE pour HTTP par exemple).
C'est peut-être une interprétation du "TCP/IP illustré" de R.Stevens.
Observe par exemple RFC1122 (§1.1.3 Internet Protocol Suite).
Pour moi application logicielle est décorellée de l'idée de réseau.
Oui
Couche applicative TCP/IP n'a pas de sens puisque l'application est décorellée de TCP/IP.
Non, au-dessus d'une couche applicative existe une application qui lui indique les octets à transmettre (IE pour HTTP par exemple).
Cordialement, Angelot
Angelot
Bonsoir PYT,
Je me permets d'intervenir, juste pour remercier Angelot de ces interventions: sa modélisation et son approche sont assez proches des miennes. Ses interventions et les réponses pas toujours claires du premier coup (il reformule bien pour faire avancer) mais patientes, nous permettent
de progresser.
Merci, vous m'obligez ainsi à tourner 7 fois mon doigt au-dessus du clavier avant d'écrire. Vérifiez quand même un peu la route, afin que je ne vous emmène pas au fossé. Sans vous tous, je ne suis plus rien.
Cordialement, Angelot
Bonsoir PYT,
Je me permets d'intervenir, juste pour remercier Angelot de ces
interventions: sa modélisation et son approche sont assez proches des
miennes. Ses interventions et les réponses pas toujours claires du premier
coup (il reformule bien pour faire avancer) mais patientes, nous
permettent
de progresser.
Merci, vous m'obligez ainsi à tourner 7 fois mon doigt au-dessus du clavier
avant d'écrire. Vérifiez quand même un peu la route, afin que je ne vous
emmène pas au fossé. Sans vous tous, je ne suis plus rien.
Je me permets d'intervenir, juste pour remercier Angelot de ces interventions: sa modélisation et son approche sont assez proches des miennes. Ses interventions et les réponses pas toujours claires du premier coup (il reformule bien pour faire avancer) mais patientes, nous permettent
de progresser.
Merci, vous m'obligez ainsi à tourner 7 fois mon doigt au-dessus du clavier avant d'écrire. Vérifiez quand même un peu la route, afin que je ne vous emmène pas au fossé. Sans vous tous, je ne suis plus rien.
Cordialement, Angelot
PYT
"Angelot" a écrit dans le message news: cd9i02
Merci, vous m'obligez ainsi à tourner 7 fois mon doigt au-dessus du clavier
avant d'écrire.
Je me suis mal exprimé: vous interventions sont claires pour moi, car elles correspondent assez bien à ma représentation du sujet. Les réponses (dans ce fil, T0t0, Eric Masson) sont sans doute pertinante, mais un peu décalées par rapport à mon "modèle" du sujet. Grace à vos relances, on converge. Je voulais donc vous remercier pour votre effort de rigueur, et les remercie pour leur patience. Il me semble que la somme des deux est une bonne pédagogie.
"Angelot" <OnSePame@KesceKonSePame.fr> a écrit dans le message news: cd9i02
Merci, vous m'obligez ainsi à tourner 7 fois mon doigt au-dessus du
clavier
avant d'écrire.
Je me suis mal exprimé: vous interventions sont claires pour moi, car elles
correspondent assez bien à ma représentation du sujet.
Les réponses (dans ce fil, T0t0, Eric Masson) sont sans doute pertinante,
mais un peu décalées par rapport à mon "modèle" du sujet. Grace à vos
relances, on converge.
Je voulais donc vous remercier pour votre effort de rigueur, et les remercie
pour leur patience. Il me semble que la somme des deux est une bonne
pédagogie.
Merci, vous m'obligez ainsi à tourner 7 fois mon doigt au-dessus du clavier
avant d'écrire.
Je me suis mal exprimé: vous interventions sont claires pour moi, car elles correspondent assez bien à ma représentation du sujet. Les réponses (dans ce fil, T0t0, Eric Masson) sont sans doute pertinante, mais un peu décalées par rapport à mon "modèle" du sujet. Grace à vos relances, on converge. Je voulais donc vous remercier pour votre effort de rigueur, et les remercie pour leur patience. Il me semble que la somme des deux est une bonne pédagogie.
Angelot
Bonsoir PYT,
Je me suis mal exprimé: vous interventions sont claires pour moi, car elles
correspondent assez bien à ma représentation du sujet. Les réponses (dans ce fil, T0t0, Eric Masson) sont sans doute pertinante, mais un peu décalées par rapport à mon "modèle" du sujet. Grace à vos relances, on converge. Je voulais donc vous remercier pour votre effort de rigueur, et les remercie
pour leur patience. Il me semble que la somme des deux est une bonne pédagogie.
Vous vous étiez bien exprimé et je vous avais bien compris.
Pris dans la passion d'une discussion nous devons nous rappeler que d'autres personnes nous lisent, nous observent, nous analysent, dans le silence de leur pensée. Et le fait même de le savoir, d'en prendre conscience à la faveur de votre touchante déclaration, m'oblige à être encore plus attentif à la clarté de l'expression, à étayer au mieux les arguments, à enrichir les développements, à reconnaître les fautes de mon esprit. Je ne suis pas seul sur le chemin, d'autres me suivent ou m'ont déjà précédé.
Cordialement, Angelot
Bonsoir PYT,
Je me suis mal exprimé: vous interventions sont claires pour moi, car
elles
correspondent assez bien à ma représentation du sujet.
Les réponses (dans ce fil, T0t0, Eric Masson) sont sans doute pertinante,
mais un peu décalées par rapport à mon "modèle" du sujet. Grace à vos
relances, on converge.
Je voulais donc vous remercier pour votre effort de rigueur, et les
remercie
pour leur patience. Il me semble que la somme des deux est une bonne
pédagogie.
Vous vous étiez bien exprimé et je vous avais bien compris.
Pris dans la passion d'une discussion nous devons nous rappeler que d'autres
personnes nous lisent, nous observent, nous analysent, dans le silence de
leur pensée. Et le fait même de le savoir, d'en prendre conscience à la
faveur de votre touchante déclaration, m'oblige à être encore plus attentif
à la clarté de l'expression, à étayer au mieux les arguments, à enrichir les
développements, à reconnaître les fautes de mon esprit. Je ne suis pas seul
sur le chemin, d'autres me suivent ou m'ont déjà précédé.
Je me suis mal exprimé: vous interventions sont claires pour moi, car elles
correspondent assez bien à ma représentation du sujet. Les réponses (dans ce fil, T0t0, Eric Masson) sont sans doute pertinante, mais un peu décalées par rapport à mon "modèle" du sujet. Grace à vos relances, on converge. Je voulais donc vous remercier pour votre effort de rigueur, et les remercie
pour leur patience. Il me semble que la somme des deux est une bonne pédagogie.
Vous vous étiez bien exprimé et je vous avais bien compris.
Pris dans la passion d'une discussion nous devons nous rappeler que d'autres personnes nous lisent, nous observent, nous analysent, dans le silence de leur pensée. Et le fait même de le savoir, d'en prendre conscience à la faveur de votre touchante déclaration, m'oblige à être encore plus attentif à la clarté de l'expression, à étayer au mieux les arguments, à enrichir les développements, à reconnaître les fautes de mon esprit. Je ne suis pas seul sur le chemin, d'autres me suivent ou m'ont déjà précédé.
