ipconfig /all

e.christian

25/02/2004 à 12:28

Bonjour, Etienne.
Je te remercis, pour l'information, je ne connais pas, OE6, mais je crois
que cela viens de maider tout de mème.
Je tente l'envoi de cette réponce, et je verrais bien le résultat.
Encors merci.
Bonne journée, et à bientôt peut ètre.
chris..

"EtienneD" a écrit dans le message de news:
403c5f9f$0$22397$

Si tu utilises par exemple OE6, il suffit dans les propriétés du compte
news, d'indiquer un email bricolé antispam de ton choix et c'est celui-ci
qui sera placé dans tes messages.
Il ne faut absolument pas tarder sinon, gare aux spams (si le mal n'est
pas

déjà fait).

EtienneD

Annie D.

25/02/2004 à 13:13

"e.christian" wrote:

Je tente l'envoi de cette réponse, et je verrais bien le résultat.

Raté (c).

Vous avez laissé l'adresse valide dans le From:, donc ça ne gêne pas les
spammeurs. Par contre vous avez mis une adresse invalide (et incorrecte
dans sa forme, ce qui est mal) dans le champ Reply-To:, ce qui empêche
les lecteurs de vous répondre en privé. Moralité, cela ne gêne que les
honnêtes gens.

De toute façon, ne vous faites pas d'illusion, l'adresse est grillée
depuis le premier article que vous avez publié.

Allez, lisez plutôt ça :

http://www.usenet-fr.net/fur/minis-faqs/adresses-antispam.html

e.christian

25/02/2004 à 13:46

Merci, Annie D.
j'ai consulté la page. Si je suis importuné à l'avenir, je devrais changer
d'adresse mail.
je pence que m'aintenant j'ai solutionné, avec du retard.
Je le verrais à l'avenir, (le champ Reply-to:, est maintenant correctement
renseigné).

"Annie D." a écrit dans le message de news:

"e.christian" wrote:

Je tente l'envoi de cette réponse, et je verrais bien le résultat.

Raté (c).

Vous avez laissé l'adresse valide dans le From:, donc ça ne gêne pas les
spammeurs. Par contre vous avez mis une adresse invalide (et incorrecte
dans sa forme, ce qui est mal) dans le champ Reply-To:, ce qui empêche
les lecteurs de vous répondre en privé. Moralité, cela ne gêne que les
honnêtes gens.

De toute façon, ne vous faites pas d'illusion, l'adresse est grillée
depuis le premier article que vous avez publié.

Allez, lisez plutôt ça :

http://www.usenet-fr.net/fur/minis-faqs/adresses-antispam.html

Angelot

26/02/2004 à 20:05

Bonsoir Annie,

Euh, je vois pas trop le rapport entre l'interface de bouclage (c'est
bien de 'lo' que vous parlez ?) et le fait de jeter les paquets
inroutables.

Probablement le même terme : lo = loopback. Le datagramme à envoyer passe du
tampon émission couche 3 au tampon réception couche 3.

L'adresse 192.168.9.255 est une adresse spéciale (ex-RFC 1700 remplacée
par

www.iana.org), elle apparaîtra dans la table au même titre que toute
autre

adresse spéciale, quel que soit le réseau extérieur.

Spéciale en quoi ?

Paragraphe des adresses spéciales dans RFC 1700 par exemple :

(d) {<Network-number>, -1}

Directed broadcast to specified network. Can only be used
as a destination address.

ipconfig
PPP carte {ACEAA7FF-E69A-4A40-807B-5BB56BB1294C} :

Suffixe DNS spéc. à la connexion. :
Adresse IP. . . . . . . . . . . . : 192.168.9.65
Masque de sous-réseau . . . . . . : 255.255.255.255
Passerelle par défaut . . . . . . :

Quel est le masque que vous avez réellement saisi ? à 24 bits ?

Et alors comment expliquez-vous que je ne retrouve rien de tel dans la
table de routage (même la table "locale" qui n'est normalement pas
affichée) de la machine "pair" de cette liaison point à point ?

Comprend pas cette phrase. On est bien d'accord que la table de routage
(d'un host ou gateway) permet de trouver une route pour toute adresse de
destination ?

détail qui peut avoir son importance, cette machine tourne sous
GNU/Linux, et j'aurais une certaine tendance à créditer cet OS d'un plus
grand respect des standards IP qu'un Windows.

La table de routage GNU/Linux est-elle affichable ?

Cordialement,
Angelot

Annie D.

26/02/2004 à 21:48

Angelot wrote:

Euh, je vois pas trop le rapport entre l'interface de bouclage (c'est
bien de 'lo' que vous parlez ?) et le fait de jeter les paquets
inroutables.

Probablement le même terme : lo = loopback.

Bien, on parle donc de la même chose.

Le datagramme à envoyer passe du
tampon émission couche 3 au tampon réception couche 3.

Ça doit être quelque chose comme ça, je ne me suis pas penchée sur les
détails. Donc je répète ma question, quel rapport entre cette interface
et le fait de jeter des paquets ? Pour mémoire, je rappelle vos propos :

Tout ordinateur avec une seule interface est un routeur minimal, puisqu'il a
le choix de transmettre le datagramme sur cette interface de sortie ou bien
de le jeter par une adresse de bouclage logiciel.

L'adresse 192.168.9.255 est une adresse spéciale

Spéciale en quoi ?

Paragraphe des adresses spéciales dans RFC 1700 par exemple :

(d) {<Network-number>, -1}

Directed broadcast to specified network. Can only be used
as a destination address.

Ceci n'est valable qu'avec des liaisons de couche 2 pour lesquelles la
notion de broadcast a un sens, comme ethernet. Dans une liaison PPP qui
par définition ne relie que deux points, un à chaque bout, cette notion
n'a pas de sens. Ce qu'on envoie à un bout est reçu à l'autre bout et
c'est tout.

ipconfig
PPP carte {ACEAA7FF-E69A-4A40-807B-5BB56BB1294C} :

Suffixe DNS spéc. à la connexion. :
Adresse IP. . . . . . . . . . . . : 192.168.9.65
Masque de sous-réseau . . . . . . : 255.255.255.255
Passerelle par défaut . . . . . . :

Quel est le masque que vous avez réellement saisi ? à 24 bits ?

Je n'ai rien saisi du tout ! C'est une liaison PPP. L'adresse est
attribuée par le serveur PPTP.

Et alors comment expliquez-vous que je ne retrouve rien de tel dans la
table de routage (même la table "locale" qui n'est normalement pas
affichée) de la machine "pair" de cette liaison point à point ?

Comprend pas cette phrase. On est bien d'accord que la table de routage
(d'un host ou gateway) permet de trouver une route pour toute adresse de
destination ?

Non, la table de routage peut être incomplète. C'est le cas d'un réseau
isolé par exemple. Chaque station ne connaît que son sous-réseau, sans
passerelle par défaut. Elle ne saura pas router les adresses
n'appartenant pas à ce réseau, c'est parfaitement normal. Mais tout ceci
n'a aucun rapport avec le sujet.

La table de routage GNU/Linux est-elle affichable ?

Bien sûr.
Table de routage "standard" (routes extérieures) : commandes 'route' ou
'netstat -r' ou 'ip route show table main'

Table de routage locale (contenant les broadcasts et l'interface de
boucle locale) : commande 'ip route show table local'

Angelot wrote:

Euh, je vois pas trop le rapport entre l'interface de bouclage (c'est
bien de 'lo' que vous parlez ?) et le fait de jeter les paquets
inroutables.

Probablement le même terme : lo = loopback.

Bien, on parle donc de la même chose.

Le datagramme à envoyer passe du
tampon émission couche 3 au tampon réception couche 3.

Ça doit être quelque chose comme ça, je ne me suis pas penchée sur les
détails. Donc je répète ma question, quel rapport entre cette interface
et le fait de jeter des paquets ? Pour mémoire, je rappelle vos propos :

Tout ordinateur avec une seule interface est un routeur minimal, puisqu'il a
le choix de transmettre le datagramme sur cette interface de sortie ou bien
de le jeter par une adresse de bouclage logiciel.

L'adresse 192.168.9.255 est une adresse spéciale

Spéciale en quoi ?

Paragraphe des adresses spéciales dans RFC 1700 par exemple :

(d) {<Network-number>, -1}

Directed broadcast to specified network. Can only be used
as a destination address.

Ceci n'est valable qu'avec des liaisons de couche 2 pour lesquelles la
notion de broadcast a un sens, comme ethernet. Dans une liaison PPP qui
par définition ne relie que deux points, un à chaque bout, cette notion
n'a pas de sens. Ce qu'on envoie à un bout est reçu à l'autre bout et
c'est tout.

ipconfig
PPP carte {ACEAA7FF-E69A-4A40-807B-5BB56BB1294C} :

Suffixe DNS spéc. à la connexion. :
Adresse IP. . . . . . . . . . . . : 192.168.9.65
Masque de sous-réseau . . . . . . : 255.255.255.255
Passerelle par défaut . . . . . . :

Quel est le masque que vous avez réellement saisi ? à 24 bits ?

Je n'ai rien saisi du tout ! C'est une liaison PPP. L'adresse est
attribuée par le serveur PPTP.

Et alors comment expliquez-vous que je ne retrouve rien de tel dans la
table de routage (même la table "locale" qui n'est normalement pas
affichée) de la machine "pair" de cette liaison point à point ?

Comprend pas cette phrase. On est bien d'accord que la table de routage
(d'un host ou gateway) permet de trouver une route pour toute adresse de
destination ?

Non, la table de routage peut être incomplète. C'est le cas d'un réseau
isolé par exemple. Chaque station ne connaît que son sous-réseau, sans
passerelle par défaut. Elle ne saura pas router les adresses
n'appartenant pas à ce réseau, c'est parfaitement normal. Mais tout ceci
n'a aucun rapport avec le sujet.

La table de routage GNU/Linux est-elle affichable ?

Bien sûr.
Table de routage "standard" (routes extérieures) : commandes 'route' ou
'netstat -r' ou 'ip route show table main'

Table de routage locale (contenant les broadcasts et l'interface de
boucle locale) : commande 'ip route show table local'

Vous avez filtré cet utilisateur ! Consultez son message

Angelot wrote:

Euh, je vois pas trop le rapport entre l'interface de bouclage (c'est
bien de 'lo' que vous parlez ?) et le fait de jeter les paquets
inroutables.

Probablement le même terme : lo = loopback.

Bien, on parle donc de la même chose.

Le datagramme à envoyer passe du
tampon émission couche 3 au tampon réception couche 3.

Ça doit être quelque chose comme ça, je ne me suis pas penchée sur les
détails. Donc je répète ma question, quel rapport entre cette interface
et le fait de jeter des paquets ? Pour mémoire, je rappelle vos propos :

Tout ordinateur avec une seule interface est un routeur minimal, puisqu'il a
le choix de transmettre le datagramme sur cette interface de sortie ou bien
de le jeter par une adresse de bouclage logiciel.

L'adresse 192.168.9.255 est une adresse spéciale

Spéciale en quoi ?

Paragraphe des adresses spéciales dans RFC 1700 par exemple :

(d) {<Network-number>, -1}

Directed broadcast to specified network. Can only be used
as a destination address.

Ceci n'est valable qu'avec des liaisons de couche 2 pour lesquelles la
notion de broadcast a un sens, comme ethernet. Dans une liaison PPP qui
par définition ne relie que deux points, un à chaque bout, cette notion
n'a pas de sens. Ce qu'on envoie à un bout est reçu à l'autre bout et
c'est tout.

ipconfig
PPP carte {ACEAA7FF-E69A-4A40-807B-5BB56BB1294C} :

Suffixe DNS spéc. à la connexion. :
Adresse IP. . . . . . . . . . . . : 192.168.9.65
Masque de sous-réseau . . . . . . : 255.255.255.255
Passerelle par défaut . . . . . . :

Quel est le masque que vous avez réellement saisi ? à 24 bits ?

Je n'ai rien saisi du tout ! C'est une liaison PPP. L'adresse est
attribuée par le serveur PPTP.

Et alors comment expliquez-vous que je ne retrouve rien de tel dans la
table de routage (même la table "locale" qui n'est normalement pas
affichée) de la machine "pair" de cette liaison point à point ?

Comprend pas cette phrase. On est bien d'accord que la table de routage
(d'un host ou gateway) permet de trouver une route pour toute adresse de
destination ?

Non, la table de routage peut être incomplète. C'est le cas d'un réseau
isolé par exemple. Chaque station ne connaît que son sous-réseau, sans
passerelle par défaut. Elle ne saura pas router les adresses
n'appartenant pas à ce réseau, c'est parfaitement normal. Mais tout ceci
n'a aucun rapport avec le sujet.

La table de routage GNU/Linux est-elle affichable ?

Bien sûr.
Table de routage "standard" (routes extérieures) : commandes 'route' ou
'netstat -r' ou 'ip route show table main'

Table de routage locale (contenant les broadcasts et l'interface de
boucle locale) : commande 'ip route show table local'

Angelot

28/02/2004 à 17:56

Bonjour Annie,

Le datagramme à envoyer passe du
tampon émission couche 3 au tampon réception couche 3.

Ça doit être quelque chose comme ça, je ne me suis pas penchée sur les
détails. Donc je répète ma question, quel rapport entre cette interface
et le fait de jeter des paquets ? Pour mémoire, je rappelle vos propos :

Tout ordinateur avec une seule interface est un routeur minimal,
puisqu'il a

le choix de transmettre le datagramme sur cette interface de sortie ou
bien

de le jeter par une adresse de bouclage logiciel.

Je précise. Lorsque qu'un datagramme est formé de quelconque manière dans la
couche Réseau, la table de routage lui est "appliqué" pour trouver une route
de destination. Si, compte tenu de son adresse de destination, le datagramme
ne doit pas être transmis à la couche Accès Réseau, l'interface de sortie de
ce datagramme est l'adresse de loopback (bouclage logiciel). Dans ce cas, le
datagramme passe directement du tampon d'émission de la couche Réseau au
tampon de réception de la couche Réseau, sans atteindre l'Accès Réseau.

Les cas que j'ai observés, il en existe probablement d'autres : datagrammes
avec @destination = @source, avec @destination = 127.x.x.x et, parfois, avec
@destination = @multicast (dans le bloc 224.0.0.0/4).

Ceci n'est valable qu'avec des liaisons de couche 2 pour lesquelles la
notion de broadcast a un sens, comme ethernet. Dans une liaison PPP qui
par définition ne relie que deux points, un à chaque bout, cette notion
n'a pas de sens. Ce qu'on envoie à un bout est reçu à l'autre bout et
c'est tout.

L'application de la table de routage est indépendante de l'Accès Réseau qui
peut être simple LLC/SNAP/802.3, PPP/AAL5, RFC1356/X.25 , ou plus complexe
LLC/SNAP/MAC/RFC2684/AAL5/ATM/STM-1/WDM pour résumer.

Non, la table de routage peut être incomplète. C'est le cas d'un réseau
isolé par exemple. Chaque station ne connaît que son sous-réseau, sans
passerelle par défaut. Elle ne saura pas router les adresses
n'appartenant pas à ce réseau, c'est parfaitement normal. Mais tout ceci
n'a aucun rapport avec le sujet.

Le rôle de la route par défaut (avec application du masque 0.0.0.0.0, quand
toutes les autres routes ont échouées) est de diriger les datagrammes sur
une interface en liaison directe avec une machine qui peut les traiter. Le
cas trivial est celui de mon PC qui n'a aucune passerelle de déclarer, la
route par défaut conduit tous les datagrammes au POP par le RTC !

Cordialement,
Angelot

Bonjour Annie,

Le datagramme à envoyer passe du
tampon émission couche 3 au tampon réception couche 3.

Ça doit être quelque chose comme ça, je ne me suis pas penchée sur les
détails. Donc je répète ma question, quel rapport entre cette interface
et le fait de jeter des paquets ? Pour mémoire, je rappelle vos propos :

Tout ordinateur avec une seule interface est un routeur minimal,
puisqu'il a

le choix de transmettre le datagramme sur cette interface de sortie ou
bien

de le jeter par une adresse de bouclage logiciel.

Je précise. Lorsque qu'un datagramme est formé de quelconque manière dans la
couche Réseau, la table de routage lui est "appliqué" pour trouver une route
de destination. Si, compte tenu de son adresse de destination, le datagramme
ne doit pas être transmis à la couche Accès Réseau, l'interface de sortie de
ce datagramme est l'adresse de loopback (bouclage logiciel). Dans ce cas, le
datagramme passe directement du tampon d'émission de la couche Réseau au
tampon de réception de la couche Réseau, sans atteindre l'Accès Réseau.

Les cas que j'ai observés, il en existe probablement d'autres : datagrammes
avec @destination = @source, avec @destination = 127.x.x.x et, parfois, avec
@destination = @multicast (dans le bloc 224.0.0.0/4).

Ceci n'est valable qu'avec des liaisons de couche 2 pour lesquelles la
notion de broadcast a un sens, comme ethernet. Dans une liaison PPP qui
par définition ne relie que deux points, un à chaque bout, cette notion
n'a pas de sens. Ce qu'on envoie à un bout est reçu à l'autre bout et
c'est tout.

L'application de la table de routage est indépendante de l'Accès Réseau qui
peut être simple LLC/SNAP/802.3, PPP/AAL5, RFC1356/X.25 , ou plus complexe
LLC/SNAP/MAC/RFC2684/AAL5/ATM/STM-1/WDM pour résumer.

Non, la table de routage peut être incomplète. C'est le cas d'un réseau
isolé par exemple. Chaque station ne connaît que son sous-réseau, sans
passerelle par défaut. Elle ne saura pas router les adresses
n'appartenant pas à ce réseau, c'est parfaitement normal. Mais tout ceci
n'a aucun rapport avec le sujet.

Le rôle de la route par défaut (avec application du masque 0.0.0.0.0, quand
toutes les autres routes ont échouées) est de diriger les datagrammes sur
une interface en liaison directe avec une machine qui peut les traiter. Le
cas trivial est celui de mon PC qui n'a aucune passerelle de déclarer, la
route par défaut conduit tous les datagrammes au POP par le RTC !

Cordialement,
Angelot

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour Annie,

Le datagramme à envoyer passe du
tampon émission couche 3 au tampon réception couche 3.

Ça doit être quelque chose comme ça, je ne me suis pas penchée sur les
détails. Donc je répète ma question, quel rapport entre cette interface
et le fait de jeter des paquets ? Pour mémoire, je rappelle vos propos :

Tout ordinateur avec une seule interface est un routeur minimal,
puisqu'il a

le choix de transmettre le datagramme sur cette interface de sortie ou
bien

de le jeter par une adresse de bouclage logiciel.

Je précise. Lorsque qu'un datagramme est formé de quelconque manière dans la
couche Réseau, la table de routage lui est "appliqué" pour trouver une route
de destination. Si, compte tenu de son adresse de destination, le datagramme
ne doit pas être transmis à la couche Accès Réseau, l'interface de sortie de
ce datagramme est l'adresse de loopback (bouclage logiciel). Dans ce cas, le
datagramme passe directement du tampon d'émission de la couche Réseau au
tampon de réception de la couche Réseau, sans atteindre l'Accès Réseau.

Les cas que j'ai observés, il en existe probablement d'autres : datagrammes
avec @destination = @source, avec @destination = 127.x.x.x et, parfois, avec
@destination = @multicast (dans le bloc 224.0.0.0/4).

Ceci n'est valable qu'avec des liaisons de couche 2 pour lesquelles la
notion de broadcast a un sens, comme ethernet. Dans une liaison PPP qui
par définition ne relie que deux points, un à chaque bout, cette notion
n'a pas de sens. Ce qu'on envoie à un bout est reçu à l'autre bout et
c'est tout.

L'application de la table de routage est indépendante de l'Accès Réseau qui
peut être simple LLC/SNAP/802.3, PPP/AAL5, RFC1356/X.25 , ou plus complexe
LLC/SNAP/MAC/RFC2684/AAL5/ATM/STM-1/WDM pour résumer.

Non, la table de routage peut être incomplète. C'est le cas d'un réseau
isolé par exemple. Chaque station ne connaît que son sous-réseau, sans
passerelle par défaut. Elle ne saura pas router les adresses
n'appartenant pas à ce réseau, c'est parfaitement normal. Mais tout ceci
n'a aucun rapport avec le sujet.

Le rôle de la route par défaut (avec application du masque 0.0.0.0.0, quand
toutes les autres routes ont échouées) est de diriger les datagrammes sur
une interface en liaison directe avec une machine qui peut les traiter. Le
cas trivial est celui de mon PC qui n'a aucune passerelle de déclarer, la
route par défaut conduit tous les datagrammes au POP par le RTC !

Cordialement,
Angelot

www.frameip.com

28/02/2004 à 18:12

"Angelot" a écrit dans le message de news:
c1qh9b$of1$

Je précise. Lorsque qu'un datagramme est formé de quelconque manière dans
la

couche Réseau, la table de routage lui est "appliqué" pour trouver une
route

de destination. Si, compte tenu de son adresse de destination, le
datagramme

ne doit pas être transmis à la couche Accès Réseau, l'interface de sortie
de

ce datagramme est l'adresse de loopback (bouclage logiciel). Dans ce cas,
le

datagramme passe directement du tampon d'émission de la couche Réseau au
tampon de réception de la couche Réseau, sans atteindre l'Accès Réseau.

Je ne comprend pas, qu'entends tu par "l'Accès Réseau" ?

Le cas trivial est celui de mon PC qui n'a aucune passerelle de déclarer
, la route par défaut conduit tous les datagrammes au POP par le
RTC !

Tu dis quelle n'a pas de passerelle par defaut, mais quelle est la
différence entre paramètrer graphiquement une passerelle par defaut et
ajouter une route 0.0.0.0 dans la table ?
Si les trame sont dirigé sur le RTC, c'est bien que tu as une route 0.0.0.0
qui est monté en même temps que ton PPP. Mais tu as raison, les deux ne sont
lié que par un côté applicatif.

--

SebF
Pour ceux qui aiment IP

www.frameip.com ( Nom de domaine temporairement bloqué, merci d'utiliser
l'url http://frameip.dyndns.org pendant le mois de Février 2004)

Angelot

28/02/2004 à 19:43

Bonjour Sèb (il est partout !)

Je ne comprend pas, qu'entends tu par "l'Accès Réseau" ?

Je me réfère au modèle 4 couches de la DoD (Accès Réseau / Internet ou
Réseau / Transport / Application). Personnellement, je rejette le modèle OSI
pour TCP/IP et, lorsqu'un ouvrage commence par décrire TCP/IP en plaquant le
modèle OSI, je referme l'ouvrage, car cela présage mal de la suite. C'est
strictement personnel ! et je n'invite personne à faire comme moi : une
application TCP/IP n'est pas une application OSI, ni une application
logicielle, ni l'application d'un enduit sur un mur...

Tu dis quelle n'a pas de passerelle par defaut, mais quelle est la
différence entre paramètrer graphiquement une passerelle par defaut et
ajouter une route 0.0.0.0 dans la table ?

Ces routes ne sont pas pas ajoutées, elles sont de fait dans les tables
comme chacun peut l'expérimenter.

Voici la route par défaut de mon PC (pas déclaration de passerelle par
défaut) :

Adresse réseau 0.0.0.0
Masque réseau 0.0.0.0
Adr. passerelle 85.78.94.208
Adr. interface 85.78.94.208

La machine est en même temps routeur sur le réseau dans lequel elle est
seule !

Voici la route par défaut d'un PC sur LAN, avec attribution DHCP par ex.
d'une passerelle par défaut

Adresse réseau 0.0.0.0
Masque réseau 0.0.0.0
Adr. passerelle 192.168.6.254
Adr. interface 192.168.6.26

Tout datagramme qui prend cette route fera son ARP request, si besoin est,
vers la passerelle par défaut.

Si les trame sont dirigé sur le RTC, c'est bien que tu as une route
0.0.0.0

qui est monté en même temps que ton PPP.

La table de routage ne dépend pas de PPP, de toute façon de résoudre l'Accès
Réseau (sauf cas explicite).

Cordialement,
Angelot

www.frameip.com

28/02/2004 à 20:08

"Angelot" a écrit dans le message de news:
c1qngu$a71$

Je me réfère au modèle 4 couches de la DoD (Accès Réseau / Internet ou
Réseau / Transport / Application). Personnellement, je rejette le modèle
OSI

pour TCP/IP et, lorsqu'un ouvrage commence par décrire TCP/IP en plaquant
le

modèle OSI, je referme l'ouvrage, car cela présage mal de la suite. C'est
strictement personnel ! et je n'invite personne à faire comme moi : une
application TCP/IP n'est pas une application OSI, ni une application
logicielle, ni l'application d'un enduit sur un mur...

Merci, je comprends désormais ce que tu voulais dire sur les trames qui ne
passe pas en couche 2.

Désolé, moi un site qui commence par exposer le modèle basé sur 4 couche, je
ne le ferme pas, mais c'est vrai que je pars avec un a priori. lol

Cela n'engage que moi, moi je trouve le modèle 4 couche trop générale et
résout toutes les discutions délicates en globalisant les couches. Pourquoi
pas une couche! J'exagère un peu, c'est juste pour exprimer mon avis.

Ces routes ne sont pas pas ajoutées, elles sont de fait dans les tables
comme chacun peut l'expérimenter.

Elle ne le sont pas de base. Avant que la connexion PPP soit monté, la route
n'existe pas.

Voici la route par défaut de mon PC (pas déclaration de passerelle par
défaut) :

Adresse réseau 0.0.0.0
Masque réseau 0.0.0.0
Adr. passerelle 85.78.94.208

Bien choisit. lol

Adr. interface 85.78.94.208

La machine est en même temps routeur sur le réseau dans lequel elle est
seule !

Of course

Voici la route par défaut d'un PC sur LAN, avec attribution DHCP par ex.
d'une passerelle par défaut

Adresse réseau 0.0.0.0
Masque réseau 0.0.0.0
Adr. passerelle 192.168.6.254
Adr. interface 192.168.6.26

Tout datagramme qui prend cette route fera son ARP request, si besoin est,
vers la passerelle par défaut.

On est d'accord, mais la discussion porté sur le fait que la route 0.0.0.0
d'une connexion PPP est identique à une """"route passerelle"""".

Si les trame sont dirigé sur le RTC, c'est bien que tu as une route
0.0.0.0

qui est monté en même temps que ton PPP.

La table de routage ne dépend pas de PPP, de toute façon de résoudre
l'Accès

Réseau (sauf cas explicite).

Tu as effacé la fin de ma phrase que je reporte :
SebF Wrote : "Mais tu as raison, les deux ne sont lié que par un côté
applicatif."

Ce qui signifie qu'une route IP couche 3 n'a bien sur pas de rapport avec la
couche 2, mais quelles sont liées par l'applicatif qui les enchainent.

--

SebF

http://www.frameip.com
Pour ceux qui aiment IP

"Angelot" <OnSePame@KestceKonSePame.fr> a écrit dans le message de news:
c1qngu$a71$1@news-reader3.wanadoo.fr...

Je me réfère au modèle 4 couches de la DoD (Accès Réseau / Internet ou
Réseau / Transport / Application). Personnellement, je rejette le modèle
OSI

pour TCP/IP et, lorsqu'un ouvrage commence par décrire TCP/IP en plaquant
le

modèle OSI, je referme l'ouvrage, car cela présage mal de la suite. C'est
strictement personnel ! et je n'invite personne à faire comme moi : une
application TCP/IP n'est pas une application OSI, ni une application
logicielle, ni l'application d'un enduit sur un mur...

Merci, je comprends désormais ce que tu voulais dire sur les trames qui ne
passe pas en couche 2.

Désolé, moi un site qui commence par exposer le modèle basé sur 4 couche, je
ne le ferme pas, mais c'est vrai que je pars avec un a priori. lol

Cela n'engage que moi, moi je trouve le modèle 4 couche trop générale et
résout toutes les discutions délicates en globalisant les couches. Pourquoi
pas une couche! J'exagère un peu, c'est juste pour exprimer mon avis.

Ces routes ne sont pas pas ajoutées, elles sont de fait dans les tables
comme chacun peut l'expérimenter.

Elle ne le sont pas de base. Avant que la connexion PPP soit monté, la route
n'existe pas.

Voici la route par défaut de mon PC (pas déclaration de passerelle par
défaut) :

Adresse réseau 0.0.0.0
Masque réseau 0.0.0.0
Adr. passerelle 85.78.94.208

Bien choisit. lol

Adr. interface 85.78.94.208

La machine est en même temps routeur sur le réseau dans lequel elle est
seule !

Of course

Voici la route par défaut d'un PC sur LAN, avec attribution DHCP par ex.
d'une passerelle par défaut

Adresse réseau 0.0.0.0
Masque réseau 0.0.0.0
Adr. passerelle 192.168.6.254
Adr. interface 192.168.6.26

Tout datagramme qui prend cette route fera son ARP request, si besoin est,
vers la passerelle par défaut.

On est d'accord, mais la discussion porté sur le fait que la route 0.0.0.0
d'une connexion PPP est identique à une """"route passerelle"""".

Si les trame sont dirigé sur le RTC, c'est bien que tu as une route
0.0.0.0

qui est monté en même temps que ton PPP.

La table de routage ne dépend pas de PPP, de toute façon de résoudre
l'Accès

Réseau (sauf cas explicite).

Tu as effacé la fin de ma phrase que je reporte :
SebF Wrote : "Mais tu as raison, les deux ne sont lié que par un côté
applicatif."

Ce qui signifie qu'une route IP couche 3 n'a bien sur pas de rapport avec la
couche 2, mais quelles sont liées par l'applicatif qui les enchainent.

--

SebF

http://www.frameip.com
Pour ceux qui aiment IP

Vous avez filtré cet utilisateur ! Consultez son message

"Angelot" a écrit dans le message de news:
c1qngu$a71$

Je me réfère au modèle 4 couches de la DoD (Accès Réseau / Internet ou
Réseau / Transport / Application). Personnellement, je rejette le modèle
OSI

pour TCP/IP et, lorsqu'un ouvrage commence par décrire TCP/IP en plaquant
le

modèle OSI, je referme l'ouvrage, car cela présage mal de la suite. C'est
strictement personnel ! et je n'invite personne à faire comme moi : une
application TCP/IP n'est pas une application OSI, ni une application
logicielle, ni l'application d'un enduit sur un mur...

Merci, je comprends désormais ce que tu voulais dire sur les trames qui ne
passe pas en couche 2.

Désolé, moi un site qui commence par exposer le modèle basé sur 4 couche, je
ne le ferme pas, mais c'est vrai que je pars avec un a priori. lol

Cela n'engage que moi, moi je trouve le modèle 4 couche trop générale et
résout toutes les discutions délicates en globalisant les couches. Pourquoi
pas une couche! J'exagère un peu, c'est juste pour exprimer mon avis.

Ces routes ne sont pas pas ajoutées, elles sont de fait dans les tables
comme chacun peut l'expérimenter.

Elle ne le sont pas de base. Avant que la connexion PPP soit monté, la route
n'existe pas.

Voici la route par défaut de mon PC (pas déclaration de passerelle par
défaut) :

Adresse réseau 0.0.0.0
Masque réseau 0.0.0.0
Adr. passerelle 85.78.94.208

Bien choisit. lol

Adr. interface 85.78.94.208

La machine est en même temps routeur sur le réseau dans lequel elle est
seule !

Of course

Voici la route par défaut d'un PC sur LAN, avec attribution DHCP par ex.
d'une passerelle par défaut

Adresse réseau 0.0.0.0
Masque réseau 0.0.0.0
Adr. passerelle 192.168.6.254
Adr. interface 192.168.6.26

Tout datagramme qui prend cette route fera son ARP request, si besoin est,
vers la passerelle par défaut.

On est d'accord, mais la discussion porté sur le fait que la route 0.0.0.0
d'une connexion PPP est identique à une """"route passerelle"""".

Si les trame sont dirigé sur le RTC, c'est bien que tu as une route
0.0.0.0

qui est monté en même temps que ton PPP.

La table de routage ne dépend pas de PPP, de toute façon de résoudre
l'Accès

Réseau (sauf cas explicite).

Tu as effacé la fin de ma phrase que je reporte :
SebF Wrote : "Mais tu as raison, les deux ne sont lié que par un côté
applicatif."

Ce qui signifie qu'une route IP couche 3 n'a bien sur pas de rapport avec la
couche 2, mais quelles sont liées par l'applicatif qui les enchainent.

--

SebF

http://www.frameip.com
Pour ceux qui aiment IP

Angelot

28/02/2004 à 20:56

Bonsoir Sèb,

Ces routes ne sont pas pas ajoutées, elles sont de fait dans les tables
comme chacun peut l'expérimenter.

Elle ne le sont pas de base. Avant que la connexion PPP soit monté, la
route

n'existe pas.

On peut dire que le modèle TCP/IP est tronqué. Du point de vue système
d'exploitation les pilotes de couches basses ne sont pas encore en
communication avec le noyau de l'OS qui comporte les files d'attentes IP.

On est d'accord, mais la discussion porté sur le fait que la route 0.0.0.0
d'une connexion PPP est identique à une """"route passerelle"""".

Pige pas !

Ce qui signifie qu'une route IP couche 3 n'a bien sur pas de rapport avec
la

couche 2, mais quelles sont liées par l'applicatif qui les enchainent.

Un routeur fonctionne sans applicatif !
Un modèle de télécommunication (OSI, TCP/IP, IPX/SPX, Appletalk, NetBios...)
n'est que la représentation synthétique des fonctionnalités HW et SW d'un
OS. Ce serait plutôt comme cela qu'il faut raisonner.

Codialement,
Angelot

ipconfig /all

10 réponses

Veuillez sélectionner un problème