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,
Comme toutes les infâmes bidouilles qui permettent de faire des trucs pas prévus à l'origine. Autre exemple : le NAT.
Ben, si les isp français nous fournissaient une alternative qui permettent de se passer de l'encapsulation ppp, ce serait quand même plus simple (il semble que Free le permette sur ses accès dégroupés, c'est de l'IPoA sauce rfc1577 ?)
Juste précis. Il y a déjà assez de confusion, inutile d'en rajouter.
Vi :)
-- MC> Le Nono de base est fourni sans l'option second degré. apres la lecture de la reponse de Nono ! a ton post je me demande tout simplement si il existe une version de base du Nono ! avec cerveau :)) -+- F in GNU : Neurone de tous les neuneux, unis toi -+-
Comme toutes les infâmes bidouilles qui permettent de faire des trucs
pas prévus à l'origine. Autre exemple : le NAT.
Ben, si les isp français nous fournissaient une alternative qui
permettent de se passer de l'encapsulation ppp, ce serait quand même
plus simple (il semble que Free le permette sur ses accès dégroupés,
c'est de l'IPoA sauce rfc1577 ?)
Juste précis. Il y a déjà assez de confusion, inutile d'en rajouter.
Vi :)
--
MC> Le Nono de base est fourni sans l'option second degré.
apres la lecture de la reponse de Nono ! a ton post je me demande tout
simplement si il existe une version de base du Nono ! avec cerveau :))
-+- F in GNU : Neurone de tous les neuneux, unis toi -+-
Comme toutes les infâmes bidouilles qui permettent de faire des trucs pas prévus à l'origine. Autre exemple : le NAT.
Ben, si les isp français nous fournissaient une alternative qui permettent de se passer de l'encapsulation ppp, ce serait quand même plus simple (il semble que Free le permette sur ses accès dégroupés, c'est de l'IPoA sauce rfc1577 ?)
Juste précis. Il y a déjà assez de confusion, inutile d'en rajouter.
Vi :)
-- MC> Le Nono de base est fourni sans l'option second degré. apres la lecture de la reponse de Nono ! a ton post je me demande tout simplement si il existe une version de base du Nono ! avec cerveau :)) -+- F in GNU : Neurone de tous les neuneux, unis toi -+-
Pascal Hambourg
TJ a écrit :
On peut aussi le configurer en "half-bridge"
J'ai justement utilisé cette solution chez un ami, par contre un problème persiste, lorsque la connexion tombe (en particulier la coupure de l'opérateur subie toutes les 24h), le modem met toujours _au moins_ 3 minutes à remonter la connexion. Ce n'est à priori pas lié au half-bridge mais il me semble que cela se produit depuis l'upgrade du fw et l'utilisation de ce mode, mais je n'ose plus toucher à la conf du modem ;-)
La connexion de cet ami a-t-elle une adresse IP fixe ou variable ? Dans le cas d'une adresse variable, la nouvelle n'est transmise au client ou au routeur par DHCP que lorsque ce dernier renouvelle le bail. Il n'y a pas dans DHCP de mécanisme à l'initiative du serveur permettant à celui-ci de signaler à un client que son adresse n'est plus valide.
Séquence : - déconnexion PPP à l'initiative du FAI - reconnexion PPP à l'initiative du modem avec une nouvelle adresse - mise à jour de l'adresse qui sera servie par DHCP - à la moitié du délai d'expiration, le client renouvelle le bail - le modem sert la nouvelle adresse
Pendant tout ce temps, bien que le modem soit reconnecté, tant que le client a l'ancienne adresse il ne peut plus communiquer. C'est un des défauts inhérents au half bridge, et ça impose de fixer une durée de bail DHCP très courte. Lorsque le client ou le routeur gère lui-même la session PPP, il récupère immédiatement la nouvelle adresse.
TJ a écrit :
On peut aussi le configurer en "half-bridge"
J'ai justement utilisé cette solution chez un ami, par contre un
problème persiste, lorsque la connexion tombe (en particulier la coupure
de l'opérateur subie toutes les 24h), le modem met toujours _au moins_ 3
minutes à remonter la connexion. Ce n'est à priori pas lié au
half-bridge mais il me semble que cela se produit depuis l'upgrade du fw
et l'utilisation de ce mode, mais je n'ose plus toucher à la conf du
modem ;-)
La connexion de cet ami a-t-elle une adresse IP fixe ou variable ?
Dans le cas d'une adresse variable, la nouvelle n'est transmise au
client ou au routeur par DHCP que lorsque ce dernier renouvelle le bail.
Il n'y a pas dans DHCP de mécanisme à l'initiative du serveur permettant
à celui-ci de signaler à un client que son adresse n'est plus valide.
Séquence :
- déconnexion PPP à l'initiative du FAI
- reconnexion PPP à l'initiative du modem avec une nouvelle adresse
- mise à jour de l'adresse qui sera servie par DHCP
- à la moitié du délai d'expiration, le client renouvelle le bail
- le modem sert la nouvelle adresse
Pendant tout ce temps, bien que le modem soit reconnecté, tant que le
client a l'ancienne adresse il ne peut plus communiquer. C'est un des
défauts inhérents au half bridge, et ça impose de fixer une durée de
bail DHCP très courte. Lorsque le client ou le routeur gère lui-même la
session PPP, il récupère immédiatement la nouvelle adresse.
J'ai justement utilisé cette solution chez un ami, par contre un problème persiste, lorsque la connexion tombe (en particulier la coupure de l'opérateur subie toutes les 24h), le modem met toujours _au moins_ 3 minutes à remonter la connexion. Ce n'est à priori pas lié au half-bridge mais il me semble que cela se produit depuis l'upgrade du fw et l'utilisation de ce mode, mais je n'ose plus toucher à la conf du modem ;-)
La connexion de cet ami a-t-elle une adresse IP fixe ou variable ? Dans le cas d'une adresse variable, la nouvelle n'est transmise au client ou au routeur par DHCP que lorsque ce dernier renouvelle le bail. Il n'y a pas dans DHCP de mécanisme à l'initiative du serveur permettant à celui-ci de signaler à un client que son adresse n'est plus valide.
Séquence : - déconnexion PPP à l'initiative du FAI - reconnexion PPP à l'initiative du modem avec une nouvelle adresse - mise à jour de l'adresse qui sera servie par DHCP - à la moitié du délai d'expiration, le client renouvelle le bail - le modem sert la nouvelle adresse
Pendant tout ce temps, bien que le modem soit reconnecté, tant que le client a l'ancienne adresse il ne peut plus communiquer. C'est un des défauts inhérents au half bridge, et ça impose de fixer une durée de bail DHCP très courte. Lorsque le client ou le routeur gère lui-même la session PPP, il récupère immédiatement la nouvelle adresse.
Eric Masson
Pascal Hambourg writes:
'Lut,
Comme toutes les infâmes bidouilles qui permettent de faire des trucs pas prévus à l'origine. Autre exemple : le NAT.
Ben, si les isp français nous fournissaient une alternative qui permette de se passer de l'encapsulation ppp, ce serait quand même plus simple (il semble que Free le permette sur ses accès dégroupés, c'est de l'IPoA sauce rfc1577 ?)
Juste précis. Il y a déjà assez de confusion, inutile d'en rajouter.
Vi :)
-- MC> Le Nono de base est fourni sans l'option second degré. apres la lecture de la reponse de Nono ! a ton post je me demande tout simplement si il existe une version de base du Nono ! avec cerveau :)) -+- F in GNU : Neurone de tous les neuneux, unis toi -+-
Comme toutes les infâmes bidouilles qui permettent de faire des trucs
pas prévus à l'origine. Autre exemple : le NAT.
Ben, si les isp français nous fournissaient une alternative qui
permette de se passer de l'encapsulation ppp, ce serait quand même
plus simple (il semble que Free le permette sur ses accès dégroupés,
c'est de l'IPoA sauce rfc1577 ?)
Juste précis. Il y a déjà assez de confusion, inutile d'en rajouter.
Vi :)
--
MC> Le Nono de base est fourni sans l'option second degré.
apres la lecture de la reponse de Nono ! a ton post je me demande tout
simplement si il existe une version de base du Nono ! avec cerveau :))
-+- F in GNU : Neurone de tous les neuneux, unis toi -+-
Comme toutes les infâmes bidouilles qui permettent de faire des trucs pas prévus à l'origine. Autre exemple : le NAT.
Ben, si les isp français nous fournissaient une alternative qui permette de se passer de l'encapsulation ppp, ce serait quand même plus simple (il semble que Free le permette sur ses accès dégroupés, c'est de l'IPoA sauce rfc1577 ?)
Juste précis. Il y a déjà assez de confusion, inutile d'en rajouter.
Vi :)
-- MC> Le Nono de base est fourni sans l'option second degré. apres la lecture de la reponse de Nono ! a ton post je me demande tout simplement si il existe une version de base du Nono ! avec cerveau :)) -+- F in GNU : Neurone de tous les neuneux, unis toi -+-
Pascal Hambourg
Eric Masson a écrit :
Pascal Hambourg writes:
Comme toutes les infâmes bidouilles qui permettent de faire des trucs pas prévus à l'origine. Autre exemple : le NAT.
Ben, si les isp français nous fournissaient une alternative qui permettent de se passer de l'encapsulation ppp, ce serait quand même plus simple
A qui le dis-tu... Pareil, s'ils nous fournissaient assez d'adresses IP publiques on n'aurait pas besoin de faire du NAT.
(il semble que Free le permette sur ses accès dégroupés, c'est de l'IPoA sauce rfc1577 ?)
Oui, mais ça ne change pas vraiment le problème : pour moi ça reste du half-bridge dans la mesure où le modem fait la transition entre une encapsulation "routée" sans MAC (PPP ou IPoA) et une encapsulation ethernet, donc avec MAC. L'encapsulation IPoA est plus simple, mais la Freebox doit quand même aussi mettre les mains dans la couche IP et gérer le même bazar pour que ça marche : DHCP, proxy ARP...
La petite différence, c'est que c'est prévu dans le plan d'adressage du réseau de Free, et donc on peut appliquer un masque de sous-réseau côté ethernet (qui n'a pas de sens côté PPP ou IPoA) sans crainte que les adresses réservées de réseau et de broadcast définies par ce masque entrent en conflit avec des adresses existantes.
Comme toutes les infâmes bidouilles qui permettent de faire des trucs
pas prévus à l'origine. Autre exemple : le NAT.
Ben, si les isp français nous fournissaient une alternative qui
permettent de se passer de l'encapsulation ppp, ce serait quand même
plus simple
A qui le dis-tu...
Pareil, s'ils nous fournissaient assez d'adresses IP publiques on
n'aurait pas besoin de faire du NAT.
(il semble que Free le permette sur ses accès dégroupés,
c'est de l'IPoA sauce rfc1577 ?)
Oui, mais ça ne change pas vraiment le problème : pour moi ça reste du
half-bridge dans la mesure où le modem fait la transition entre une
encapsulation "routée" sans MAC (PPP ou IPoA) et une encapsulation
ethernet, donc avec MAC. L'encapsulation IPoA est plus simple, mais la
Freebox doit quand même aussi mettre les mains dans la couche IP et
gérer le même bazar pour que ça marche : DHCP, proxy ARP...
La petite différence, c'est que c'est prévu dans le plan d'adressage du
réseau de Free, et donc on peut appliquer un masque de sous-réseau côté
ethernet (qui n'a pas de sens côté PPP ou IPoA) sans crainte que les
adresses réservées de réseau et de broadcast définies par ce masque
entrent en conflit avec des adresses existantes.
Comme toutes les infâmes bidouilles qui permettent de faire des trucs pas prévus à l'origine. Autre exemple : le NAT.
Ben, si les isp français nous fournissaient une alternative qui permettent de se passer de l'encapsulation ppp, ce serait quand même plus simple
A qui le dis-tu... Pareil, s'ils nous fournissaient assez d'adresses IP publiques on n'aurait pas besoin de faire du NAT.
(il semble que Free le permette sur ses accès dégroupés, c'est de l'IPoA sauce rfc1577 ?)
Oui, mais ça ne change pas vraiment le problème : pour moi ça reste du half-bridge dans la mesure où le modem fait la transition entre une encapsulation "routée" sans MAC (PPP ou IPoA) et une encapsulation ethernet, donc avec MAC. L'encapsulation IPoA est plus simple, mais la Freebox doit quand même aussi mettre les mains dans la couche IP et gérer le même bazar pour que ça marche : DHCP, proxy ARP...
La petite différence, c'est que c'est prévu dans le plan d'adressage du réseau de Free, et donc on peut appliquer un masque de sous-réseau côté ethernet (qui n'a pas de sens côté PPP ou IPoA) sans crainte que les adresses réservées de réseau et de broadcast définies par ce masque entrent en conflit avec des adresses existantes.
TJ
On 2008-11-13, Pascal Hambourg wrote:
La connexion de cet ami a-t-elle une adresse IP fixe ou variable ?
l'IP est fixe, mais la route peut changer. Le problème se pose même si la route ne change pas suite à la coupure.
Séquence : - déconnexion PPP à l'initiative du FAI - reconnexion PPP à l'initiative du modem avec une nouvelle adresse - mise à jour de l'adresse qui sera servie par DHCP - à la moitié du délai d'expiration, le client renouvelle le bail - le modem sert la nouvelle adresse
Pendant tout ce temps, bien que le modem soit reconnecté, tant que le client a l'ancienne adresse il ne peut plus communiquer. C'est un des défauts inhérents au half bridge, et ça impose de fixer une durée de bail DHCP très courte. Lorsque le client ou le routeur gère lui-même la session PPP, il récupère immédiatement la nouvelle adresse.
Merci pour cette précision, ce problème était effectivement rencontré. 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 :
Environ trois minutes au plus court. 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).
Dernier détail, pendant la phase de reconnexion, l'interface web du modem est injoignable (timeout) sur sa patte IP locale.
On 2008-11-13, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
La connexion de cet ami a-t-elle une adresse IP fixe ou variable ?
l'IP est fixe, mais la route peut changer. Le problème se pose même si
la route ne change pas suite à la coupure.
Séquence :
- déconnexion PPP à l'initiative du FAI
- reconnexion PPP à l'initiative du modem avec une nouvelle adresse
- mise à jour de l'adresse qui sera servie par DHCP
- à la moitié du délai d'expiration, le client renouvelle le bail
- le modem sert la nouvelle adresse
Pendant tout ce temps, bien que le modem soit reconnecté, tant que le
client a l'ancienne adresse il ne peut plus communiquer. C'est un des
défauts inhérents au half bridge, et ça impose de fixer une durée de
bail DHCP très courte. Lorsque le client ou le routeur gère lui-même la
session PPP, il récupère immédiatement la nouvelle adresse.
Merci pour cette précision, ce problème était effectivement rencontré.
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 :
Environ trois minutes au plus court. 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).
Dernier détail, pendant la phase de reconnexion, l'interface web du
modem est injoignable (timeout) sur sa patte IP locale.
La connexion de cet ami a-t-elle une adresse IP fixe ou variable ?
l'IP est fixe, mais la route peut changer. Le problème se pose même si la route ne change pas suite à la coupure.
Séquence : - déconnexion PPP à l'initiative du FAI - reconnexion PPP à l'initiative du modem avec une nouvelle adresse - mise à jour de l'adresse qui sera servie par DHCP - à la moitié du délai d'expiration, le client renouvelle le bail - le modem sert la nouvelle adresse
Pendant tout ce temps, bien que le modem soit reconnecté, tant que le client a l'ancienne adresse il ne peut plus communiquer. C'est un des défauts inhérents au half bridge, et ça impose de fixer une durée de bail DHCP très courte. Lorsque le client ou le routeur gère lui-même la session PPP, il récupère immédiatement la nouvelle adresse.
Merci pour cette précision, ce problème était effectivement rencontré. 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 :
Environ trois minutes au plus court. 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).
Dernier détail, pendant la phase de reconnexion, l'interface web du modem est injoignable (timeout) sur sa patte IP locale.
Eric Masson
Pascal Hambourg writes:
A qui le dis-tu... Pareil, s'ils nous fournissaient assez d'adresses IP publiques on n'aurait pas besoin de faire du NAT.
Pour ça, d'ici à deux/trois ans, cela devrait être réglé, quoique j'ai lu ici et là que certains avaient du mal à envisager qu'ipv6 ne fournisse pas de mécanisme de NAT (ce serait un non sens, mais bon...)
Oui, mais ça ne change pas vraiment le problème : pour moi ça reste du half-bridge dans la mesure où le modem fait la transition entre une encapsulation "routée" sans MAC (PPP ou IPoA) et une encapsulation ethernet, donc avec MAC. L'encapsulation IPoA est plus simple, mais la Freebox doit quand même aussi mettre les mains dans la couche IP et gérer le même bazar pour que ça marche : DHCP, proxy ARP...
La petite différence, c'est que c'est prévu dans le plan d'adressage du réseau de Free, et donc on peut appliquer un masque de sous-réseau côté ethernet (qui n'a pas de sens côté PPP ou IPoA) sans crainte que les adresses réservées de réseau et de broadcast définies par ce masque entrent en conflit avec des adresses existantes.
Ok, merci pour les explications.
Qu'est ce que tu trouverais donc satisfaisant en l'état actuel ?
-- l'anarchie, c'est pt'etre pas genial comme mode de gouvernement, mais c'est mieux que pas de gouvernement du tout. -+- Kevin in <http://www.le-gnu.net> -+- Ni Root, ni Maître. -+-
A qui le dis-tu...
Pareil, s'ils nous fournissaient assez d'adresses IP publiques on
n'aurait pas besoin de faire du NAT.
Pour ça, d'ici à deux/trois ans, cela devrait être réglé, quoique j'ai
lu ici et là que certains avaient du mal à envisager qu'ipv6 ne
fournisse pas de mécanisme de NAT (ce serait un non sens, mais bon...)
Oui, mais ça ne change pas vraiment le problème : pour moi ça reste du
half-bridge dans la mesure où le modem fait la transition entre une
encapsulation "routée" sans MAC (PPP ou IPoA) et une encapsulation
ethernet, donc avec MAC. L'encapsulation IPoA est plus simple, mais la
Freebox doit quand même aussi mettre les mains dans la couche IP et
gérer le même bazar pour que ça marche : DHCP, proxy ARP...
La petite différence, c'est que c'est prévu dans le plan d'adressage du
réseau de Free, et donc on peut appliquer un masque de sous-réseau côté
ethernet (qui n'a pas de sens côté PPP ou IPoA) sans crainte que les
adresses réservées de réseau et de broadcast définies par ce masque
entrent en conflit avec des adresses existantes.
Ok, merci pour les explications.
Qu'est ce que tu trouverais donc satisfaisant en l'état actuel ?
--
l'anarchie, c'est pt'etre pas genial comme mode de gouvernement,
mais c'est mieux que pas de gouvernement du tout.
-+- Kevin in <http://www.le-gnu.net> -+- Ni Root, ni Maître. -+-
A qui le dis-tu... Pareil, s'ils nous fournissaient assez d'adresses IP publiques on n'aurait pas besoin de faire du NAT.
Pour ça, d'ici à deux/trois ans, cela devrait être réglé, quoique j'ai lu ici et là que certains avaient du mal à envisager qu'ipv6 ne fournisse pas de mécanisme de NAT (ce serait un non sens, mais bon...)
Oui, mais ça ne change pas vraiment le problème : pour moi ça reste du half-bridge dans la mesure où le modem fait la transition entre une encapsulation "routée" sans MAC (PPP ou IPoA) et une encapsulation ethernet, donc avec MAC. L'encapsulation IPoA est plus simple, mais la Freebox doit quand même aussi mettre les mains dans la couche IP et gérer le même bazar pour que ça marche : DHCP, proxy ARP...
La petite différence, c'est que c'est prévu dans le plan d'adressage du réseau de Free, et donc on peut appliquer un masque de sous-réseau côté ethernet (qui n'a pas de sens côté PPP ou IPoA) sans crainte que les adresses réservées de réseau et de broadcast définies par ce masque entrent en conflit avec des adresses existantes.
Ok, merci pour les explications.
Qu'est ce que tu trouverais donc satisfaisant en l'état actuel ?
-- l'anarchie, c'est pt'etre pas genial comme mode de gouvernement, mais c'est mieux que pas de gouvernement du tout. -+- Kevin in <http://www.le-gnu.net> -+- Ni Root, ni Maître. -+-
Pascal Hambourg
Eric Masson a écrit :
Ben, si les isp français nous fournissaient une alternative qui permette de se passer de l'encapsulation ppp, ce serait quand même plus simple (il semble que Free le permette sur ses accès dégroupés, c'est de l'IPoA sauce rfc1577 ?)
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é.
Eric Masson a écrit :
Ben, si les isp français nous fournissaient une alternative qui
permette de se passer de l'encapsulation ppp, ce serait quand même
plus simple (il semble que Free le permette sur ses accès dégroupés,
c'est de l'IPoA sauce rfc1577 ?)
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é.
Ben, si les isp français nous fournissaient une alternative qui permette de se passer de l'encapsulation ppp, ce serait quand même plus simple (il semble que Free le permette sur ses accès dégroupés, c'est de l'IPoA sauce rfc1577 ?)
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é.
Pascal Hambourg
TJ a écrit :
l'IP est fixe, mais la route peut changer.
Quelle route ?
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 :
Je vois ça. Le FAI, c'est Nerim ? En tout cas on dirait que ça vient de la partie PPP du modem, pas forcément de la partie 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.
TJ a écrit :
l'IP est fixe, mais la route peut changer.
Quelle route ?
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 :
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 :
Je vois ça. Le FAI, c'est Nerim ? En tout cas on dirait que ça vient de la partie PPP du modem, pas forcément de la partie 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.
Pascal Hambourg
Eric Masson a écrit :
Pascal Hambourg writes:
Pareil, s'ils nous fournissaient assez d'adresses IP publiques on n'aurait pas besoin de faire du NAT.
Pour ça, d'ici à deux/trois ans, cela devrait être réglé, quoique j'ai lu ici et là que certains avaient du mal à envisager qu'ipv6 ne fournisse pas de mécanisme de NAT (ce serait un non sens, mais bon...)
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.
Qu'est ce que tu trouverais donc satisfaisant en l'état actuel ?
En ADSL ? Plus j'y réfléchis, plus je crains qu'il n'y ait pas de solution idéale universelle. PPP était un bon compromis en tant que protocole répandu permettant à la fois l'authentification, la configuration IP dynamique et l'aiguillage vers différents FAI partageant un même opérateur de collecte IP/ADSL en option 5, seule solution abordable permettant une couverture nationale pour un petit FAI. Là où ça se gâte, c'est quand le modem et le routeur sont séparés (parce qu'on ne trouve pas de modem-routeur qui fasse ce qu'on veut) par un lien ethernet (le matériel ATM, c'est plus rare et cher). Il faut faire passer le PPP par dessus l'ethernet, et il n'y a rien de vraiment satisfaisant pour ça. La simplicité de PPPoE est séduisante au premier abord, mais il est plombé par des problèmes de MTU bien connus au sujet desquels je ne m'étendrai pas et contre lesquels il n'existe pas de vraie solution universelle. L'encapsulation de PPP dans une surcouche comme PPTP - que j'utilise - basée sur IP, qui lui sait gérer la fragmentation contrairement à ethernet et PPPoE, permet d'éviter cet écueil, mais au prix d'une complexité accrue - et potentiellement d'une moindre stabilité - dans le modem et le routeur qui doivent savoir gérer cette surcouche.
Une solution satisfaisante pour moi devrait permettre l'utilisation d'un simple modem ADSL de son choix, avec interface ethernet, qui ne s'occupe que de la couche liaison (je n'ai pas dit "que de la couche ethernet") et pas du tout de la couche réseau. Si j'ai envie d'utiliser NetBEUI ou IPX (pour changer d'IPv4 et IPv6) ça ne regarde que moi et mon FAI, pas le modem et encore moins l'opérateur.
La solution la plus évidente qui vient à l'esprit, ce serait d'avoir de l'IP (ou autre protocole de couche réseau) sur ethernet de bout en bout entre le routeur et le FAI : modem en bridge avec encapsulation ethernet ponté RFC 1483/2684 sur la partie ADSL, comme pour PPPoE, et ensuite tunnel ethernet avec une encapsulation à définir jusqu'au FAI. Pour l'aiguillage et l'authentification du client, l'opérateur ADSL et le FAI pourraient se baser sur l'identification de la ligne, comme Free en dégroupé.
Pareil, s'ils nous fournissaient assez d'adresses IP publiques on
n'aurait pas besoin de faire du NAT.
Pour ça, d'ici à deux/trois ans, cela devrait être réglé, quoique j'ai
lu ici et là que certains avaient du mal à envisager qu'ipv6 ne
fournisse pas de mécanisme de NAT (ce serait un non sens, mais bon...)
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.
Qu'est ce que tu trouverais donc satisfaisant en l'état actuel ?
En ADSL ?
Plus j'y réfléchis, plus je crains qu'il n'y ait pas de solution idéale
universelle. PPP était un bon compromis en tant que protocole répandu
permettant à la fois l'authentification, la configuration IP dynamique
et l'aiguillage vers différents FAI partageant un même opérateur de
collecte IP/ADSL en option 5, seule solution abordable permettant une
couverture nationale pour un petit FAI. Là où ça se gâte, c'est quand le
modem et le routeur sont séparés (parce qu'on ne trouve pas de
modem-routeur qui fasse ce qu'on veut) par un lien ethernet (le matériel
ATM, c'est plus rare et cher). Il faut faire passer le PPP par dessus
l'ethernet, et il n'y a rien de vraiment satisfaisant pour ça. La
simplicité de PPPoE est séduisante au premier abord, mais il est plombé
par des problèmes de MTU bien connus au sujet desquels je ne m'étendrai
pas et contre lesquels il n'existe pas de vraie solution universelle.
L'encapsulation de PPP dans une surcouche comme PPTP - que j'utilise -
basée sur IP, qui lui sait gérer la fragmentation contrairement à
ethernet et PPPoE, permet d'éviter cet écueil, mais au prix d'une
complexité accrue - et potentiellement d'une moindre stabilité - dans le
modem et le routeur qui doivent savoir gérer cette surcouche.
Une solution satisfaisante pour moi devrait permettre l'utilisation d'un
simple modem ADSL de son choix, avec interface ethernet, qui ne s'occupe
que de la couche liaison (je n'ai pas dit "que de la couche ethernet")
et pas du tout de la couche réseau. Si j'ai envie d'utiliser NetBEUI ou
IPX (pour changer d'IPv4 et IPv6) ça ne regarde que moi et mon FAI, pas
le modem et encore moins l'opérateur.
La solution la plus évidente qui vient à l'esprit, ce serait d'avoir de
l'IP (ou autre protocole de couche réseau) sur ethernet de bout en bout
entre le routeur et le FAI : modem en bridge avec encapsulation ethernet
ponté RFC 1483/2684 sur la partie ADSL, comme pour PPPoE, et ensuite
tunnel ethernet avec une encapsulation à définir jusqu'au FAI. Pour
l'aiguillage et l'authentification du client, l'opérateur ADSL et le FAI
pourraient se baser sur l'identification de la ligne, comme Free en
dégroupé.
Pareil, s'ils nous fournissaient assez d'adresses IP publiques on n'aurait pas besoin de faire du NAT.
Pour ça, d'ici à deux/trois ans, cela devrait être réglé, quoique j'ai lu ici et là que certains avaient du mal à envisager qu'ipv6 ne fournisse pas de mécanisme de NAT (ce serait un non sens, mais bon...)
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.
Qu'est ce que tu trouverais donc satisfaisant en l'état actuel ?
En ADSL ? Plus j'y réfléchis, plus je crains qu'il n'y ait pas de solution idéale universelle. PPP était un bon compromis en tant que protocole répandu permettant à la fois l'authentification, la configuration IP dynamique et l'aiguillage vers différents FAI partageant un même opérateur de collecte IP/ADSL en option 5, seule solution abordable permettant une couverture nationale pour un petit FAI. Là où ça se gâte, c'est quand le modem et le routeur sont séparés (parce qu'on ne trouve pas de modem-routeur qui fasse ce qu'on veut) par un lien ethernet (le matériel ATM, c'est plus rare et cher). Il faut faire passer le PPP par dessus l'ethernet, et il n'y a rien de vraiment satisfaisant pour ça. La simplicité de PPPoE est séduisante au premier abord, mais il est plombé par des problèmes de MTU bien connus au sujet desquels je ne m'étendrai pas et contre lesquels il n'existe pas de vraie solution universelle. L'encapsulation de PPP dans une surcouche comme PPTP - que j'utilise - basée sur IP, qui lui sait gérer la fragmentation contrairement à ethernet et PPPoE, permet d'éviter cet écueil, mais au prix d'une complexité accrue - et potentiellement d'une moindre stabilité - dans le modem et le routeur qui doivent savoir gérer cette surcouche.
Une solution satisfaisante pour moi devrait permettre l'utilisation d'un simple modem ADSL de son choix, avec interface ethernet, qui ne s'occupe que de la couche liaison (je n'ai pas dit "que de la couche ethernet") et pas du tout de la couche réseau. Si j'ai envie d'utiliser NetBEUI ou IPX (pour changer d'IPv4 et IPv6) ça ne regarde que moi et mon FAI, pas le modem et encore moins l'opérateur.
La solution la plus évidente qui vient à l'esprit, ce serait d'avoir de l'IP (ou autre protocole de couche réseau) sur ethernet de bout en bout entre le routeur et le FAI : modem en bridge avec encapsulation ethernet ponté RFC 1483/2684 sur la partie ADSL, comme pour PPPoE, et ensuite tunnel ethernet avec une encapsulation à définir jusqu'au FAI. Pour l'aiguillage et l'authentification du client, l'opérateur ADSL et le FAI pourraient se baser sur l'identification de la ligne, comme Free en dégroupé.
Herm
"Pascal Hambourg" a écrit...
Eric Masson a écrit :
Ben, si les isp français nous fournissaient une alternative qui permette de se passer de l'encapsulation ppp, ce serait quand même plus simple (il semble que Free le permette sur ses accès dégroupés, c'est de l'IPoA sauce rfc1577 ?)
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é.
Bonsoir,
Il ne doit pas y avoir de bien grandes différences entre CIP et IPoA.
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...
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...
-- Herm
"Pascal Hambourg" a écrit...
Eric Masson a écrit :
Ben, si les isp français nous fournissaient une alternative qui
permette de se passer de l'encapsulation ppp, ce serait quand même
plus simple (il semble que Free le permette sur ses accès dégroupés,
c'est de l'IPoA sauce rfc1577 ?)
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é.
Bonsoir,
Il ne doit pas y avoir de bien grandes différences entre CIP et IPoA.
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...
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...
Ben, si les isp français nous fournissaient une alternative qui permette de se passer de l'encapsulation ppp, ce serait quand même plus simple (il semble que Free le permette sur ses accès dégroupés, c'est de l'IPoA sauce rfc1577 ?)
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é.
Bonsoir,
Il ne doit pas y avoir de bien grandes différences entre CIP et IPoA.
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...
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...
