Problème avec Routeur CISCO 871 et Modem Linksys AM200 : Net défaillant !
25 réponses
kergad1
Bonjour,
Voila je suis entrain de réinstaller mon réseaux et je dispose d'un routeur Cisco 871 (dépourvu de modem ADSL mais permettant les connexion PPPoA), d'un modem LINKSYS A200 et d'un sitch mangeable.
Mon soucis est que pour utiliser le modem, on est obligé de lui adresser une IP, soit 192.168.1.1, pour accéder au net.
Quand je le branche en live ou sur mon swith tous est nikel, mais dès que j'essaie de l'utiliser avec mon routeur, plus moyen d'accéder aux net depuis mes postes clients.
Donc voici comment je procède :
Réseaux local en 192.168.x.x
NET > MODEM > ROUTEUR > SWITCH > CLIENT le tout en ethernet.
IP public | 1.1 > 1.2 | 0.254 > 0.10
Je connecte le modem sur le port WAN du routeur et le switch sur un port LAN.
Bref après avoir suivit la config du Wizzard, j'arrive à pinguer le modem depuis mes clients mais impossible d'avoir le net ...
Nota : je considère mon modem comme un réseaux, la connexion en PPPo ne fonctionne pas.
Les route m'ont l'air correct :
ip route 192.168.0.0 255.255.255 192.168.1.1
Le DNS indiquer sur mes clients et l'adresse du routeur, 192.168.1.1 (j'ai testé les DNS de Wanadoo, mais rien n'y fait)
Enfin si quelqu'un a déjà fait une installation de ce type, je suis preneur,
Cependant je base mon diagnostic sur les logs de connexions fournis par le FAI, par exemple pour une autre connexion (mais dégroupée, celle de l'ami ne l'est pas) qui utilise le même FAI, les même équipements et même configuration :
Oui tout à fait, je pensais avoir précisé mais j'ai oublié !
En tout cas on dirait que ça vient de la partie PPP du modem, pas forcément de la partie half-bridge.
C'est ce qu'il me semble aussi, un jour où j'aurais le temps et l'occasion je testerai tous réglages et configurations possibles pour voir si c'est évitable.
AM200 en half-bridge, keep-alive coché, RFC 2364 PPPoA, bail DHCP à 24h (même en cas de changement de route cela se passe bien, mystère).
Si par route tu entends la passerelle par défaut, c'est juste la magie du proxy ARP.
Je comprends mieux, c'est toujours difficile à comprendre quand la magie intervient ;-)
On 2008-11-13, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
TJ a écrit :
l'IP est fixe, mais la route peut changer.
Quelle route ?
La passerelle par défaut.
Cependant je base mon diagnostic sur les logs de connexions fournis par
le FAI, par exemple pour une autre connexion (mais dégroupée, celle de
l'ami ne l'est pas) qui utilise le même FAI, les même équipements et
même configuration :
Oui tout à fait, je pensais avoir précisé mais j'ai oublié !
En tout cas on dirait que ça vient de la partie PPP du modem, pas
forcément de la partie half-bridge.
C'est ce qu'il me semble aussi, un jour où j'aurais le temps et
l'occasion je testerai tous réglages et configurations possibles pour
voir si c'est évitable.
AM200 en half-bridge, keep-alive
coché, RFC 2364 PPPoA, bail DHCP à 24h (même en cas de changement de
route cela se passe bien, mystère).
Si par route tu entends la passerelle par défaut, c'est juste la magie
du proxy ARP.
Je comprends mieux, c'est toujours difficile à comprendre quand la
magie intervient ;-)
Cependant je base mon diagnostic sur les logs de connexions fournis par le FAI, par exemple pour une autre connexion (mais dégroupée, celle de l'ami ne l'est pas) qui utilise le même FAI, les même équipements et même configuration :
Oui tout à fait, je pensais avoir précisé mais j'ai oublié !
En tout cas on dirait que ça vient de la partie PPP du modem, pas forcément de la partie half-bridge.
C'est ce qu'il me semble aussi, un jour où j'aurais le temps et l'occasion je testerai tous réglages et configurations possibles pour voir si c'est évitable.
AM200 en half-bridge, keep-alive coché, RFC 2364 PPPoA, bail DHCP à 24h (même en cas de changement de route cela se passe bien, mystère).
Si par route tu entends la passerelle par défaut, c'est juste la magie du proxy ARP.
Je comprends mieux, c'est toujours difficile à comprendre quand la magie intervient ;-)
Pascal Hambourg
TJ a écrit :
AM200 en half-bridge, keep-alive coché, RFC 2364 PPPoA, bail DHCP à 24h (même en cas de changement de route cela se passe bien, mystère).
Si par route tu entends la passerelle par défaut, c'est juste la magie du proxy ARP.
Je comprends mieux, c'est toujours difficile à comprendre quand la magie intervient ;-)
Juste pour satisfaire ma curiosité, serait-il possible de fournir un exemple du masque de sous-réseau et de la passerelle attribués par le DHCP du modem en mode half-bridge ?
TJ a écrit :
AM200 en half-bridge, keep-alive
coché, RFC 2364 PPPoA, bail DHCP à 24h (même en cas de changement de
route cela se passe bien, mystère).
Si par route tu entends la passerelle par défaut, c'est juste la magie
du proxy ARP.
Je comprends mieux, c'est toujours difficile à comprendre quand la
magie intervient ;-)
Juste pour satisfaire ma curiosité, serait-il possible de fournir un
exemple du masque de sous-réseau et de la passerelle attribués par le
DHCP du modem en mode half-bridge ?
AM200 en half-bridge, keep-alive coché, RFC 2364 PPPoA, bail DHCP à 24h (même en cas de changement de route cela se passe bien, mystère).
Si par route tu entends la passerelle par défaut, c'est juste la magie du proxy ARP.
Je comprends mieux, c'est toujours difficile à comprendre quand la magie intervient ;-)
Juste pour satisfaire ma curiosité, serait-il possible de fournir un exemple du masque de sous-réseau et de la passerelle attribués par le DHCP du modem en mode half-bridge ?
Pascal Hambourg
Herm a écrit :
"Pascal Hambourg" a écrit...
Je n'avais pas percuté à la première lecture, mais il me semble que Free dégroupé n'utilise pas RFC 1577 (Classical IP) mais RFC 1483/2684 en mode routé.
Il ne doit pas y avoir de bien grandes différences entre CIP et IPoA.
CIP ne couvre pas seulement l'encapsulation de paquets IP dans ATM, qui est celle décrite dans RFC 1483/2684, mais aussi la topologie du LIS (Logical IP Subnetwork) et surtout le fonctionnement et l'encapsulation du protocole de résolution d'adresse ATMARP, adaptation d'ARP au réseau ATM pour que ce dernier apparaisse comme un réseau local. Toutes autres choses qui à ma connaissance sont absentes de l'IPoA de Free.
Je reprends l'exemple du speed touch pro d'Alcatel, capable de faire du CIP, et dont la seule modif faite (à ma connaissance) dans le firmware bidouillé pour Free dégroupé, c'est de changer l'encapsulation LLC/SNAP de CIP par le VCMUX que Free utilise...
L'en-tête LLC/SNAP en CIP sert à contenir l'ethertype IP ou ARP selon le type de paquet transmis. Dans l'IPoA de Free il n'y a pas d'ARP mais seulement de l'IP, donc pas besoin d'en-tête LLC/SNAP.
Par contre il doit y avoir une autre modification dans le firmware pour pallier l'absence d'ATMARP : en CIP, le Speed Touch s'attend à atteindre chaque adresse du sous-réseau sur un circuit virtuel différent, alors que chez Free elles sont toutes sur le même circuit virtuel.
Il y a peut-être d'autres différences, par exemple, concernant l'auto-configuration IP. Dans la configuration du speed touch home, on entre à la main l'IP wan, l'IP passerelle, et les IP DNS, comme s'il ne savait pas faire du "DHCP" sur un tel lien IPoA...
Dans mon manuel du Speed Touch Home/Pro, il n'est pas indiqué d'autre méthode de configuration IP en CIP que statique.
Herm a écrit :
"Pascal Hambourg" a écrit...
Je n'avais pas percuté à la première lecture, mais il me semble que
Free dégroupé n'utilise pas RFC 1577 (Classical IP) mais RFC 1483/2684
en mode routé.
Il ne doit pas y avoir de bien grandes différences entre CIP et IPoA.
CIP ne couvre pas seulement l'encapsulation de paquets IP dans ATM, qui
est celle décrite dans RFC 1483/2684, mais aussi la topologie du LIS
(Logical IP Subnetwork) et surtout le fonctionnement et l'encapsulation
du protocole de résolution d'adresse ATMARP, adaptation d'ARP au réseau
ATM pour que ce dernier apparaisse comme un réseau local. Toutes autres
choses qui à ma connaissance sont absentes de l'IPoA de Free.
Je reprends l'exemple du speed touch pro d'Alcatel, capable de faire du
CIP, et dont la seule modif faite (à ma connaissance) dans le firmware
bidouillé pour Free dégroupé, c'est de changer l'encapsulation LLC/SNAP
de CIP par le VCMUX que Free utilise...
L'en-tête LLC/SNAP en CIP sert à contenir l'ethertype IP ou ARP selon le
type de paquet transmis. Dans l'IPoA de Free il n'y a pas d'ARP mais
seulement de l'IP, donc pas besoin d'en-tête LLC/SNAP.
Par contre il doit y avoir une autre modification dans le firmware pour
pallier l'absence d'ATMARP : en CIP, le Speed Touch s'attend à atteindre
chaque adresse du sous-réseau sur un circuit virtuel différent, alors
que chez Free elles sont toutes sur le même circuit virtuel.
Il y a peut-être d'autres différences, par exemple, concernant
l'auto-configuration IP. Dans la configuration du speed touch home, on
entre à la main l'IP wan, l'IP passerelle, et les IP DNS, comme s'il ne
savait pas faire du "DHCP" sur un tel lien IPoA...
Dans mon manuel du Speed Touch Home/Pro, il n'est pas indiqué d'autre
méthode de configuration IP en CIP que statique.
Je n'avais pas percuté à la première lecture, mais il me semble que Free dégroupé n'utilise pas RFC 1577 (Classical IP) mais RFC 1483/2684 en mode routé.
Il ne doit pas y avoir de bien grandes différences entre CIP et IPoA.
CIP ne couvre pas seulement l'encapsulation de paquets IP dans ATM, qui est celle décrite dans RFC 1483/2684, mais aussi la topologie du LIS (Logical IP Subnetwork) et surtout le fonctionnement et l'encapsulation du protocole de résolution d'adresse ATMARP, adaptation d'ARP au réseau ATM pour que ce dernier apparaisse comme un réseau local. Toutes autres choses qui à ma connaissance sont absentes de l'IPoA de Free.
Je reprends l'exemple du speed touch pro d'Alcatel, capable de faire du CIP, et dont la seule modif faite (à ma connaissance) dans le firmware bidouillé pour Free dégroupé, c'est de changer l'encapsulation LLC/SNAP de CIP par le VCMUX que Free utilise...
L'en-tête LLC/SNAP en CIP sert à contenir l'ethertype IP ou ARP selon le type de paquet transmis. Dans l'IPoA de Free il n'y a pas d'ARP mais seulement de l'IP, donc pas besoin d'en-tête LLC/SNAP.
Par contre il doit y avoir une autre modification dans le firmware pour pallier l'absence d'ATMARP : en CIP, le Speed Touch s'attend à atteindre chaque adresse du sous-réseau sur un circuit virtuel différent, alors que chez Free elles sont toutes sur le même circuit virtuel.
Il y a peut-être d'autres différences, par exemple, concernant l'auto-configuration IP. Dans la configuration du speed touch home, on entre à la main l'IP wan, l'IP passerelle, et les IP DNS, comme s'il ne savait pas faire du "DHCP" sur un tel lien IPoA...
Dans mon manuel du Speed Touch Home/Pro, il n'est pas indiqué d'autre méthode de configuration IP en CIP que statique.
Eric Masson
Pascal Hambourg writes:
'Lut,
Tu crois que le déploiement de l'internet IPv6 aura suffisamment avancé d'ici là pour qu'on puisse raisonnablement commencer à abandonner IPv4 ? Je suis beaucoup moins optimiste, depuis le temps que j'attends assis sur mon gros /48 qui ne me sert pas à grand chose.
Je suis de nature optimiste ;)
En ADSL ?
<snip réponse>
La dernière option envisagée me semble pas mal du tout, effectivement. Mais bon, de là à ce qu'un FAI y songe...
Merci pour tes réponses.
-- Je possède un T28S, et j'en suis content. Problème : mon chien aime aussi ce téléphone, particulièrement son mode d'emploi. Il l'a bouffé, et je me retrouve avec des notices anglaise, hollandaise et espagnole -+- JLP in <www.le-gnu.net> : Utiliser une alimentation équillibrée -+-
Tu crois que le déploiement de l'internet IPv6 aura suffisamment avancé
d'ici là pour qu'on puisse raisonnablement commencer à abandonner IPv4 ?
Je suis beaucoup moins optimiste, depuis le temps que j'attends assis
sur mon gros /48 qui ne me sert pas à grand chose.
Je suis de nature optimiste ;)
En ADSL ?
<snip réponse>
La dernière option envisagée me semble pas mal du tout, effectivement.
Mais bon, de là à ce qu'un FAI y songe...
Merci pour tes réponses.
--
Je possède un T28S, et j'en suis content. Problème : mon chien aime
aussi ce téléphone, particulièrement son mode d'emploi. Il l'a bouffé,
et je me retrouve avec des notices anglaise, hollandaise et espagnole
-+- JLP in <www.le-gnu.net> : Utiliser une alimentation équillibrée -+-
Tu crois que le déploiement de l'internet IPv6 aura suffisamment avancé d'ici là pour qu'on puisse raisonnablement commencer à abandonner IPv4 ? Je suis beaucoup moins optimiste, depuis le temps que j'attends assis sur mon gros /48 qui ne me sert pas à grand chose.
Je suis de nature optimiste ;)
En ADSL ?
<snip réponse>
La dernière option envisagée me semble pas mal du tout, effectivement. Mais bon, de là à ce qu'un FAI y songe...
Merci pour tes réponses.
-- Je possède un T28S, et j'en suis content. Problème : mon chien aime aussi ce téléphone, particulièrement son mode d'emploi. Il l'a bouffé, et je me retrouve avec des notices anglaise, hollandaise et espagnole -+- JLP in <www.le-gnu.net> : Utiliser une alimentation équillibrée -+-
Pascal Hambourg
Eric Masson a écrit :
Pascal Hambourg writes:
Tu crois que le déploiement de l'internet IPv6 aura suffisamment avancé d'ici là pour qu'on puisse raisonnablement commencer à abandonner IPv4 ? Je suis beaucoup moins optimiste, depuis le temps que j'attends assis sur mon gros /48 qui ne me sert pas à grand chose.
Je suis de nature optimiste ;)
Je voudrais être aussi optimiste, et j'espère que c'est toi qui as raison. Mais j'ai du mal. Là où j'ai moins de doutes en revanche, c'est sur l'épuisement du stock d'adresses IPv4 disponibles à cette échéance. A ne pas confondre avec la pénurie d'adresses IPv4, qui existe depuis longtemps déjà AMA ; s'il n'y avait pas de pénurie, les FAI pourraient refiler au minimum un /29 IPv4 à leurs abonnés haut débit (5 machines par foyer, c'est raisonnable) comme ils refilent au minimum un /64 IPv6.
La dernière option envisagée me semble pas mal du tout, effectivement. Mais bon, de là à ce qu'un FAI y songe...
Pas seulement les FAI mais aussi les opérateurs de collecte pour les FAI qui n'ont pas leur propres DSLAM. Et ça imposerait pour eux de tels changements d'architecture que c'est complètement irréaliste.
Tu crois que le déploiement de l'internet IPv6 aura suffisamment avancé
d'ici là pour qu'on puisse raisonnablement commencer à abandonner IPv4 ?
Je suis beaucoup moins optimiste, depuis le temps que j'attends assis
sur mon gros /48 qui ne me sert pas à grand chose.
Je suis de nature optimiste ;)
Je voudrais être aussi optimiste, et j'espère que c'est toi qui as
raison. Mais j'ai du mal. Là où j'ai moins de doutes en revanche, c'est
sur l'épuisement du stock d'adresses IPv4 disponibles à cette échéance.
A ne pas confondre avec la pénurie d'adresses IPv4, qui existe depuis
longtemps déjà AMA ; s'il n'y avait pas de pénurie, les FAI pourraient
refiler au minimum un /29 IPv4 à leurs abonnés haut débit (5 machines
par foyer, c'est raisonnable) comme ils refilent au minimum un /64 IPv6.
La dernière option envisagée me semble pas mal du tout, effectivement.
Mais bon, de là à ce qu'un FAI y songe...
Pas seulement les FAI mais aussi les opérateurs de collecte pour les FAI
qui n'ont pas leur propres DSLAM. Et ça imposerait pour eux de tels
changements d'architecture que c'est complètement irréaliste.
Tu crois que le déploiement de l'internet IPv6 aura suffisamment avancé d'ici là pour qu'on puisse raisonnablement commencer à abandonner IPv4 ? Je suis beaucoup moins optimiste, depuis le temps que j'attends assis sur mon gros /48 qui ne me sert pas à grand chose.
Je suis de nature optimiste ;)
Je voudrais être aussi optimiste, et j'espère que c'est toi qui as raison. Mais j'ai du mal. Là où j'ai moins de doutes en revanche, c'est sur l'épuisement du stock d'adresses IPv4 disponibles à cette échéance. A ne pas confondre avec la pénurie d'adresses IPv4, qui existe depuis longtemps déjà AMA ; s'il n'y avait pas de pénurie, les FAI pourraient refiler au minimum un /29 IPv4 à leurs abonnés haut débit (5 machines par foyer, c'est raisonnable) comme ils refilent au minimum un /64 IPv6.
La dernière option envisagée me semble pas mal du tout, effectivement. Mais bon, de là à ce qu'un FAI y songe...
Pas seulement les FAI mais aussi les opérateurs de collecte pour les FAI qui n'ont pas leur propres DSLAM. Et ça imposerait pour eux de tels changements d'architecture que c'est complètement irréaliste.
