Je viens de quitter le bas débit pour passer à l'adsl.
J'ai un modem routeur 192.168.0.1 et trois ordi 192.168.0.2 (linux)
192.168.0.3 et 192.168.0.4 et une imprimante 192.168.0.11.
Je n'arrive pas à comprendre la logique de la table de routage de mon ordi
(celui sous linux)
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use
Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0
128.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
où 4 lignes aboutissent à eth0, y a t'il un site où tout serait expliqué
Le Sun, 02 Oct 2005 09:34:34 +0200, Dominique Grosset ecrivait:
Bonjour
Je viens de quitter le bas débit pour passer à l'adsl. J'ai un modem routeur 192.168.0.1 et trois ordi 192.168.0.2 (linux) 192.168.0.3 et 192.168.0.4 et une imprimante 192.168.0.11. Je n'arrive pas à comprendre la logique de la table de routage de mon ordi (celui sous linux) Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0 128.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
où 4 lignes aboutissent à eth0, y a t'il un site où tout serait expliqué
Bonjour,
que toutes les ligne aboutissent à eth0 est a priori normal, eth0 étant une interface pointant sur une carte réseau. Apparamment tout le flux à destination de ton réseau passe par cette carte réseau (sauf le loopback, bien sûr) et donc est retranscrit sur la table de routage comme utilisant eth0.
Pour un site intéressant, essaie google, tu y trouveras tous les conseils souhaités.
Merci De rien
Le Sun, 02 Oct 2005 09:34:34 +0200, Dominique Grosset ecrivait:
Bonjour
Je viens de quitter le bas débit pour passer à l'adsl.
J'ai un modem routeur 192.168.0.1 et trois ordi 192.168.0.2 (linux)
192.168.0.3 et 192.168.0.4 et une imprimante 192.168.0.11.
Je n'arrive pas à comprendre la logique de la table de routage de mon ordi
(celui sous linux)
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use
Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0
128.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
où 4 lignes aboutissent à eth0, y a t'il un site où tout serait expliqué
Bonjour,
que toutes les ligne aboutissent à eth0 est a priori normal, eth0 étant une
interface pointant sur une carte réseau. Apparamment tout le flux à destination
de ton réseau passe par cette carte réseau (sauf le loopback, bien sûr) et
donc est retranscrit sur la table de routage comme utilisant eth0.
Pour un site intéressant, essaie google, tu y trouveras tous les conseils
souhaités.
Le Sun, 02 Oct 2005 09:34:34 +0200, Dominique Grosset ecrivait:
Bonjour
Je viens de quitter le bas débit pour passer à l'adsl. J'ai un modem routeur 192.168.0.1 et trois ordi 192.168.0.2 (linux) 192.168.0.3 et 192.168.0.4 et une imprimante 192.168.0.11. Je n'arrive pas à comprendre la logique de la table de routage de mon ordi (celui sous linux) Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0 128.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
où 4 lignes aboutissent à eth0, y a t'il un site où tout serait expliqué
Bonjour,
que toutes les ligne aboutissent à eth0 est a priori normal, eth0 étant une interface pointant sur une carte réseau. Apparamment tout le flux à destination de ton réseau passe par cette carte réseau (sauf le loopback, bien sûr) et donc est retranscrit sur la table de routage comme utilisant eth0.
Pour un site intéressant, essaie google, tu y trouveras tous les conseils souhaités.
Merci De rien
lhabert
Dominique Grosset :
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
La première et la troisième colonne indiquent que cette règle sert à router les adresses en 192.168.0.*, la deuxième colonne indique que ces adresses sont accessibles directement sans passer par un routeur, et la dernière colonne indique qu'il faut envoyer les paquets sur eth0.
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
Cette ligne indique que pour accéder à n'importe quelle adresse, tu peux passer par le routeur 192.168.0.1 en envoyant sur eth0
128.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0 0.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0
Ces deux lignes sont des cas particuliers de la précédente. Je ne comprends vraiment pas l'intéret de les avoir. C'est le DHCP qui les crée?
Dominique Grosset :
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
La première et la troisième colonne indiquent que cette règle sert à router
les adresses en 192.168.0.*, la deuxième colonne indique que ces adresses
sont accessibles directement sans passer par un routeur, et la dernière
colonne indique qu'il faut envoyer les paquets sur eth0.
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
Cette ligne indique que pour accéder à n'importe quelle adresse, tu peux
passer par le routeur 192.168.0.1 en envoyant sur eth0
128.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0
Ces deux lignes sont des cas particuliers de la précédente. Je ne comprends
vraiment pas l'intéret de les avoir. C'est le DHCP qui les crée?
La première et la troisième colonne indiquent que cette règle sert à router les adresses en 192.168.0.*, la deuxième colonne indique que ces adresses sont accessibles directement sans passer par un routeur, et la dernière colonne indique qu'il faut envoyer les paquets sur eth0.
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
Cette ligne indique que pour accéder à n'importe quelle adresse, tu peux passer par le routeur 192.168.0.1 en envoyant sur eth0
128.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0 0.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0
Ces deux lignes sont des cas particuliers de la précédente. Je ne comprends vraiment pas l'intéret de les avoir. C'est le DHCP qui les crée?
Shal
Bonjour
Je viens de quitter le bas débit pour passer à l'adsl. J'ai un modem routeur 192.168.0.1 et trois ordi 192.168.0.2 (linux) 192.168.0.3 et 192.168.0.4 et une imprimante 192.168.0.11. Je n'arrive pas à comprendre la logique de la table de routage de mon ordi (celui sous linux) Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 Cette ligne tout ce qui va vers 192.168.0.xxx vas directement a la carte
eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo Ca c'est le traffic local (le serveur X par exemple)
0.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0 La route par defaut, quand linux ne sait pas comment envoyer un paquet
il le passe a la machine 192.168.0.2 qui est sur l'interface eth0. Par contre le mask est bizarre
128.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0 Mouais, je sais pas ce que ce reseau fait ici
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 La deux deuxieme route par defaut (deja normalement il n'y en a que une)
qui me semble plus correcte.
Supprime les deux ligne avec 128.0.0.0 qui sont une erreur venue cje ne sais d'où. Pour cela route del -net 128.0.0.0 gw 192.168.0.1 route del defualt gw 192.168.0.1 netmask 128.0.0.0
Et ca devrait être bon. Le problème c'est que au prochain reboot tout sera a refaire : To be continued ;-)
Bonjour
Je viens de quitter le bas débit pour passer à l'adsl.
J'ai un modem routeur 192.168.0.1 et trois ordi 192.168.0.2 (linux)
192.168.0.3 et 192.168.0.4 et une imprimante 192.168.0.11.
Je n'arrive pas à comprendre la logique de la table de routage de mon ordi
(celui sous linux)
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use
Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Cette ligne tout ce qui va vers 192.168.0.xxx vas directement a la carte
eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
Ca c'est le traffic local (le serveur X par exemple)
0.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0
La route par defaut, quand linux ne sait pas comment envoyer un paquet
il le passe a la machine 192.168.0.2 qui est sur l'interface eth0. Par
contre le mask est bizarre
128.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0
Mouais, je sais pas ce que ce reseau fait ici
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
La deux deuxieme route par defaut (deja normalement il n'y en a que une)
qui me semble plus correcte.
Supprime les deux ligne avec 128.0.0.0 qui sont une erreur venue cje ne
sais d'où.
Pour cela
route del -net 128.0.0.0 gw 192.168.0.1
route del defualt gw 192.168.0.1 netmask 128.0.0.0
Et ca devrait être bon.
Le problème c'est que au prochain reboot tout sera a refaire : To be
continued ;-)
Je viens de quitter le bas débit pour passer à l'adsl. J'ai un modem routeur 192.168.0.1 et trois ordi 192.168.0.2 (linux) 192.168.0.3 et 192.168.0.4 et une imprimante 192.168.0.11. Je n'arrive pas à comprendre la logique de la table de routage de mon ordi (celui sous linux) Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 Cette ligne tout ce qui va vers 192.168.0.xxx vas directement a la carte
eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo Ca c'est le traffic local (le serveur X par exemple)
0.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0 La route par defaut, quand linux ne sait pas comment envoyer un paquet
il le passe a la machine 192.168.0.2 qui est sur l'interface eth0. Par contre le mask est bizarre
128.0.0.0 192.168.0.1 128.0.0.0 UG 0 0 0 eth0 Mouais, je sais pas ce que ce reseau fait ici
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 La deux deuxieme route par defaut (deja normalement il n'y en a que une)
qui me semble plus correcte.
Supprime les deux ligne avec 128.0.0.0 qui sont une erreur venue cje ne sais d'où. Pour cela route del -net 128.0.0.0 gw 192.168.0.1 route del defualt gw 192.168.0.1 netmask 128.0.0.0
Et ca devrait être bon. Le problème c'est que au prochain reboot tout sera a refaire : To be continued ;-)
lhabert
Shal :
Le problème c'est que au prochain reboot tout sera a refaire
Voire même au prochain refresh du DHCP, qui peut arriver très vite, suivant la conf du serveur. Franchement, ça doit marcher en l'état, donc pourquoi s'embêter à le corriger? D'ailleurs, ce n'est pas foncièrement faux, c'est juste un peu redondant.
Shal :
Le problème c'est que au prochain reboot tout sera a refaire
Voire même au prochain refresh du DHCP, qui peut arriver très vite, suivant
la conf du serveur. Franchement, ça doit marcher en l'état, donc pourquoi
s'embêter à le corriger? D'ailleurs, ce n'est pas foncièrement faux, c'est
juste un peu redondant.
Le problème c'est que au prochain reboot tout sera a refaire
Voire même au prochain refresh du DHCP, qui peut arriver très vite, suivant la conf du serveur. Franchement, ça doit marcher en l'état, donc pourquoi s'embêter à le corriger? D'ailleurs, ce n'est pas foncièrement faux, c'est juste un peu redondant.
TiChou
Dans le message <news:dhob1c$2e69$, *Luc Habert* tapota sur f.c.o.l.configuration :
Shal :
Le problème c'est que au prochain reboot tout sera a refaire
Voire même au prochain refresh du DHCP, qui peut arriver très vite, suivant la conf du serveur.
À mon avis ça ne peut pas venir d'une configuration par DHCP. En effet, je ne connais pas de client DHCP sous Linux capable d'ajouter des routes supplémentaires autre que les routes par défaut.
Franchement, ça doit marcher en l'état,
Oui.
donc pourquoi s'embêter à le corriger?
Drôle de concept de l'informatique.
D'ailleurs, ce n'est pas foncièrement faux, c'est juste un peu redondant.
Ça n'est pas «juste un peu» redondant, c'est redondant.
-- TiChou
Dans le message <news:dhob1c$2e69$2@nef.ens.fr>,
*Luc Habert* tapota sur f.c.o.l.configuration :
Shal :
Le problème c'est que au prochain reboot tout sera a refaire
Voire même au prochain refresh du DHCP, qui peut arriver très vite,
suivant la conf du serveur.
À mon avis ça ne peut pas venir d'une configuration par DHCP. En effet, je
ne connais pas de client DHCP sous Linux capable d'ajouter des routes
supplémentaires autre que les routes par défaut.
Franchement, ça doit marcher en l'état,
Oui.
donc pourquoi s'embêter à le corriger?
Drôle de concept de l'informatique.
D'ailleurs, ce n'est pas foncièrement faux, c'est juste un peu
redondant.
Ça n'est pas «juste un peu» redondant, c'est redondant.
Dans le message <news:dhob1c$2e69$, *Luc Habert* tapota sur f.c.o.l.configuration :
Shal :
Le problème c'est que au prochain reboot tout sera a refaire
Voire même au prochain refresh du DHCP, qui peut arriver très vite, suivant la conf du serveur.
À mon avis ça ne peut pas venir d'une configuration par DHCP. En effet, je ne connais pas de client DHCP sous Linux capable d'ajouter des routes supplémentaires autre que les routes par défaut.
Franchement, ça doit marcher en l'état,
Oui.
donc pourquoi s'embêter à le corriger?
Drôle de concept de l'informatique.
D'ailleurs, ce n'est pas foncièrement faux, c'est juste un peu redondant.
Ça n'est pas «juste un peu» redondant, c'est redondant.
-- TiChou
TiChou
Dans le message <news:433fa5d4$0$4340$, *Shal* tapota sur f.c.o.l.configuration :
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo Ca c'est le traffic local (le serveur X par exemple)
Cette route a été ajoutée par les scripts de configuration réseau de la distribution et elle est en fait totalement inutile car elle est déjà présente dans la table de routage locale, créée automatiquement lors de l'activation de l'interface lo.
-- TiChou
Dans le message <news:433fa5d4$0$4340$626a14ce@news.free.fr>,
*Shal* tapota sur f.c.o.l.configuration :
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0
lo
Ca c'est le traffic local (le serveur X par exemple)
Cette route a été ajoutée par les scripts de configuration réseau de la
distribution et elle est en fait totalement inutile car elle est déjà
présente dans la table de routage locale, créée automatiquement lors de
l'activation de l'interface lo.
Dans le message <news:433fa5d4$0$4340$, *Shal* tapota sur f.c.o.l.configuration :
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo Ca c'est le traffic local (le serveur X par exemple)
Cette route a été ajoutée par les scripts de configuration réseau de la distribution et elle est en fait totalement inutile car elle est déjà présente dans la table de routage locale, créée automatiquement lors de l'activation de l'interface lo.
-- TiChou
TiChou
(Supersedes )
Dans le message <news:dhob1c$2e69$, *Luc Habert* tapota sur f.c.o.l.configuration :
Shal :
Le problème c'est que au prochain reboot tout sera a refaire
Voire même au prochain refresh du DHCP, qui peut arriver très vite, suivant la conf du serveur.
À mon avis ça ne peut pas venir d'une configuration par DHCP. En effet, je ne connais pas de client DHCP sous Linux capable d'ajouter des routes supplémentaires autres que les routes par défaut.
Franchement, ça doit marcher en l'état,
Oui.
donc pourquoi s'embêter à le corriger?
Drôle de concept de l'informatique.
D'ailleurs, ce n'est pas foncièrement faux, c'est juste un peu redondant.
Ça n'est pas «juste un peu» redondant, c'est redondant donc inutile, donc sujet à d'éventuels conflits par la suite, donc à supprimer.
Dans le message <news:dhob1c$2e69$2@nef.ens.fr>,
*Luc Habert* tapota sur f.c.o.l.configuration :
Shal :
Le problème c'est que au prochain reboot tout sera a refaire
Voire même au prochain refresh du DHCP, qui peut arriver très vite,
suivant la conf du serveur.
À mon avis ça ne peut pas venir d'une configuration par DHCP. En effet, je
ne connais pas de client DHCP sous Linux capable d'ajouter des routes
supplémentaires autres que les routes par défaut.
Franchement, ça doit marcher en l'état,
Oui.
donc pourquoi s'embêter à le corriger?
Drôle de concept de l'informatique.
D'ailleurs, ce n'est pas foncièrement faux, c'est juste un peu
redondant.
Ça n'est pas «juste un peu» redondant, c'est redondant donc inutile, donc
sujet à d'éventuels conflits par la suite, donc à supprimer.
Dans le message <news:dhob1c$2e69$, *Luc Habert* tapota sur f.c.o.l.configuration :
Shal :
Le problème c'est que au prochain reboot tout sera a refaire
Voire même au prochain refresh du DHCP, qui peut arriver très vite, suivant la conf du serveur.
À mon avis ça ne peut pas venir d'une configuration par DHCP. En effet, je ne connais pas de client DHCP sous Linux capable d'ajouter des routes supplémentaires autres que les routes par défaut.
Franchement, ça doit marcher en l'état,
Oui.
donc pourquoi s'embêter à le corriger?
Drôle de concept de l'informatique.
D'ailleurs, ce n'est pas foncièrement faux, c'est juste un peu redondant.
Ça n'est pas «juste un peu» redondant, c'est redondant donc inutile, donc sujet à d'éventuels conflits par la suite, donc à supprimer.
-- TiChou
Pascal
Salut,
À mon avis ça ne peut pas venir d'une configuration par DHCP. En effet, je ne connais pas de client DHCP sous Linux capable d'ajouter des routes supplémentaires autres que les routes par défaut.
Tu veux dire qu'aucun client DHCP pour Linux ne tient compte de l'option "static route" ?
Au passage, saurais-tu - ou quelqu'un d'autre - comment l'adresse de destination de cette option devrait être interprétée, étant donné l'absence de masque de sous-réseau explicite : comme une adresse individuelle ou une adresse de réseau en lui associant le masque de la classe correspondante ?
Salut,
À mon avis ça ne peut pas venir d'une configuration par DHCP. En effet, je
ne connais pas de client DHCP sous Linux capable d'ajouter des routes
supplémentaires autres que les routes par défaut.
Tu veux dire qu'aucun client DHCP pour Linux ne tient compte de l'option
"static route" ?
Au passage, saurais-tu - ou quelqu'un d'autre - comment l'adresse de
destination de cette option devrait être interprétée, étant donné
l'absence de masque de sous-réseau explicite : comme une adresse
individuelle ou une adresse de réseau en lui associant le masque de la
classe correspondante ?
À mon avis ça ne peut pas venir d'une configuration par DHCP. En effet, je ne connais pas de client DHCP sous Linux capable d'ajouter des routes supplémentaires autres que les routes par défaut.
Tu veux dire qu'aucun client DHCP pour Linux ne tient compte de l'option "static route" ?
Au passage, saurais-tu - ou quelqu'un d'autre - comment l'adresse de destination de cette option devrait être interprétée, étant donné l'absence de masque de sous-réseau explicite : comme une adresse individuelle ou une adresse de réseau en lui associant le masque de la classe correspondante ?
Nicolas George
"" wrote in message <dholi9$hbp$:
Au passage, saurais-tu - ou quelqu'un d'autre - comment l'adresse de destination de cette option devrait être interprétée, étant donné l'absence de masque de sous-réseau explicite : comme une adresse individuelle ou une adresse de réseau en lui associant le masque de la classe correspondante ?
La réponse à ta question est dans la RFC 3442 : l'option de route statique numéro 33 est obsolète pour précisément cette raison, remplacée par une option numéro 121 qui précise le masque.
"Pascal@plouf" wrote in message <dholi9$hbp$1@biggoron.nerim.net>:
Au passage, saurais-tu - ou quelqu'un d'autre - comment l'adresse de
destination de cette option devrait être interprétée, étant donné
l'absence de masque de sous-réseau explicite : comme une adresse
individuelle ou une adresse de réseau en lui associant le masque de la
classe correspondante ?
La réponse à ta question est dans la RFC 3442 : l'option de route statique
numéro 33 est obsolète pour précisément cette raison, remplacée par une
option numéro 121 qui précise le masque.
Au passage, saurais-tu - ou quelqu'un d'autre - comment l'adresse de destination de cette option devrait être interprétée, étant donné l'absence de masque de sous-réseau explicite : comme une adresse individuelle ou une adresse de réseau en lui associant le masque de la classe correspondante ?
La réponse à ta question est dans la RFC 3442 : l'option de route statique numéro 33 est obsolète pour précisément cette raison, remplacée par une option numéro 121 qui précise le masque.
Pascal
Au passage, saurais-tu - ou quelqu'un d'autre - comment l'adresse de destination de cette option devrait être interprétée, étant donné l'absence de masque de sous-réseau explicite : comme une adresse individuelle ou une adresse de réseau en lui associant le masque de la classe correspondante ?
La réponse à ta question est dans la RFC 3442 : l'option de route statique numéro 33 est obsolète pour précisément cette raison, remplacée par une option numéro 121 qui précise le masque.
Merci. C'était donc une adresse de réseau "classful", ce que ne précisait pas la RFC 2132.
Au passage, saurais-tu - ou quelqu'un d'autre - comment l'adresse de
destination de cette option devrait être interprétée, étant donné
l'absence de masque de sous-réseau explicite : comme une adresse
individuelle ou une adresse de réseau en lui associant le masque de la
classe correspondante ?
La réponse à ta question est dans la RFC 3442 : l'option de route statique
numéro 33 est obsolète pour précisément cette raison, remplacée par une
option numéro 121 qui précise le masque.
Merci. C'était donc une adresse de réseau "classful", ce que ne
précisait pas la RFC 2132.
Au passage, saurais-tu - ou quelqu'un d'autre - comment l'adresse de destination de cette option devrait être interprétée, étant donné l'absence de masque de sous-réseau explicite : comme une adresse individuelle ou une adresse de réseau en lui associant le masque de la classe correspondante ?
La réponse à ta question est dans la RFC 3442 : l'option de route statique numéro 33 est obsolète pour précisément cette raison, remplacée par une option numéro 121 qui précise le masque.
Merci. C'était donc une adresse de réseau "classful", ce que ne précisait pas la RFC 2132.
