Entre boucle ADSL et FAI il y a quoi?

> Qu'est-ce qu'il y a entre la ligne avec ses modems à chaque bout et les
équipements spécifiques de chaque FAI?

Si je me déconnecte et je me reconnecte avec un identificateur de test pour
accéder à la page test ADSL de FT, quels sont les équipements qui sont
utilisés à la fois pour ce test et par mon FAI habituel? Je suppose que le
DSLAM en fait partie parce que cela ne change pas simplement parce que je
change d'identificateur. Qu'est-ce qu'il y a d'autre?

J'ai pu vérifier que mon problème persiste même que je me déconnecte d'Orange
et je me connecte par l'identificateur de test. Donc tout le matériel
spécifique d'Orange est exclu. Pour diverses raisons, je ne crois pas que la
ligne ou les modems soient en cause. Donc, cela laisse quoi de suspect?

Bonjour,
Pour faire simple, il y a le DSLAM, puis le BAS, puis les LNS des FAI
Voire http://www.rzo.free.fr/docs_jean/adsl.pdf qui est pas mal fait.

--
Les fautes d'orthographes sus-citées sont déposées auprès de leurs
propriétaires respectifs.
Aucune responsabilité n'est engagée sur la lisibilité du message ou les
éventuels dommages qu'ils peuvent engendrer

Salut,

Channels a écrit :

Qu'est-ce qu'il y a entre la ligne avec ses modems à chaque bout et les
équipements spécifiques de chaque FAI?

Pour faire simple, il y a le DSLAM, puis le BAS, puis les LNS des FAI

Ça c'est en option 5 (IP/ADSL), pas chez Orange. Chez Orange, les
sessions PPP sont terminées sur le BAS.

Le Mon, 29 Dec 2008 07:41:21 +0100, Mxsmanic a écrit
dans le message <50sgl4dh3q3sc6hs925d8utbr73qimdidi@4ax.com> :

Qu'est-ce qu'il y a entre la ligne avec ses modems à chaque bout et les
équipements spécifiques de chaque FAI?

Une chaîne variable qui dépend des architectures de collecte, mais
au moins au minimum :

- un DSLAM
- un routeur IP (qu'on appelle NAS, BAS ou BRAS dans ce contexte)

Le DSLAM est un switch (ATM historiquement, mais Ethernet de plus
en plus souvent aussi) et le routeur IP matérialise l'autre extrémité
de la liaison xDSL.

Si je me déconnecte et je me reconnecte avec un identificateur de test pour
accéder à la page test ADSL de FT, quels sont les équipements qui sont
utilisés à la fois pour ce test et par mon FAI habituel? Je suppose que le

Si c'est le test adsl@adsl, sur une ligne FT, c'est le BAS qui joue
le rôle de passerelle IP.

Le passage obligé, c'est le DSLAM. La ligne de téléphone y est physiquement
raccordée aussi bien qu'un PC en LAN doit être raccordé sur son switch
pour parler au reste du réseau.

J'ai pu vérifier que mon problème persiste même que je me déconnecte d'Orange
et je me connecte par l'identificateur de test. Donc tout le matériel
spécifique d'Orange est exclu. Pour diverses raisons, je ne crois pas que la
ligne ou les modems soient en cause. Donc, cela laisse quoi de suspect?

L'identifiant de test permet, dans une certaine mesure, d'aller au-delà
du BAS, notamment pour accéder au serveur de test.

Ce n'est donc pas très "concluant" comme mesures. Si le BAS est saturé
(en tant que routeur IP), ça va ramer vers la page de test.

Par contre, en regardant les valeurs constatées sur le lien ADSL, on
peut être sûr que ce ne soit pas lui qui est en cause, si elles
sont normales.

En particulier quand tout va bien, il y a peu d'erreurs CRC (il y en
aura toujours, tout est une question de proportions après) et la
marge de bruit mesurée est > 10 dB.

Si la ligne est sur un profil "débit max" elle doit aussi toujours
synchroniser à des paliers voisins, il ne doit pas y avoir d'écarts
de plus de 100 à 200 kbit/s ATM.

Un bon test simple consiste à démarrer son modem la nuit, regarder
le débit de sync, puis à le redémarrer à 21 h 00 et voir ce que ça
donne. Si on perd déjà plus de 1000 kbit/s, c'est qu'on est en
environnement perturbé. Il faut refaire le test plusieurs jours
de suite pour en être sûr.

Et également : attendre 15 jours pour faire ce test. En fin d'année
le bruit sur le réseau cuivre baisse sensiblement (ce n'est pas une
blague, c'est constaté sur plusieurs années d'expérience en techos
xDSL).

--
Raphael Bouaziz.

Mxsmanic a écrit :

Qu'est-ce qu'il y a entre la ligne avec ses modems à chaque bout et les
équipements spécifiques de chaque FAI?

Si je me déconnecte et je me reconnecte avec un identificateur de test pour
accéder à la page test ADSL de FT, quels sont les équipements qui sont
utilisés à la fois pour ce test et par mon FAI habituel? Je suppose que le
DSLAM en fait partie parce que cela ne change pas simplement parce que je
change d'identificateur. Qu'est-ce qu'il y a d'autre?

J'ai pu vérifier que mon problème persiste même que je me déconnecte d'Orange
et je me connecte par l'identificateur de test. Donc tout le matériel
spécifique d'Orange est exclu. Pour diverses raisons, je ne crois pas que la
ligne ou les modems soient en cause. Donc, cela laisse quoi de suspect?

Depuis le temps que vous bassinez les gens avec votre problème, vous
n'avez encore pas lancé un outil quelconque de trace route pour
connaitre son origine ????

Guillaume writes:

Depuis le temps que vous bassinez les gens avec votre problème, vous
n'avez encore pas lancé un outil quelconque de trace route pour
connaitre son origine ????

J'ai passé le weekend à faire des traces, sous Windows et UNIX. Avec MTU par
défaut, environ 50% des paquets de taille importante (plusieurs centaines
d'octets ou plus) se perdent, ou (rarement) sont reçus très tard. Souvent les
conversations TCP se bloquent lorsque la machine locale envoie un ACK qui
indiquent qu'elle n'a pas encore reçu tous les paquets.

Le MTU semble être à 1440 octets par défaut (si je ne mets aucune restriction,
découverte automatique de MTU validée). Si je le mets à 500 octets
explicitement, les conversations se bloquent nettement moins mais la lenteur
est toujours extrème, et des paquets sont parfois perdus ou très en retard
quand même. Il y a souvent plusieurs secondes entre deux paquets, voire
plusieurs minutes.

Mxsmanic a écrit :

Guillaume writes:

Depuis le temps que vous bassinez les gens avec votre problème, vous
n'avez encore pas lancé un outil quelconque de trace route pour
connaitre son origine ????

J'ai passé le weekend à faire des traces, sous Windows et UNIX. Avec MTU par
défaut, environ 50% des paquets de taille importante (plusieurs centaines
d'octets ou plus) se perdent, ou (rarement) sont reçus très tard. Souvent les
conversations TCP se bloquent lorsque la machine locale envoie un ACK qui
indiquent qu'elle n'a pas encore reçu tous les paquets.

Le MTU semble être à 1440 octets par défaut (si je ne mets aucune restriction,
découverte automatique de MTU validée). Si je le mets à 500 octets
explicitement, les conversations se bloquent nettement moins mais la lenteur
est toujours extrème, et des paquets sont parfois perdus ou très en retard
quand même. Il y a souvent plusieurs secondes entre deux paquets, voire
plusieurs minutes.

Et ? Quel routeur ferait perdre ces paquets ?
Essayez 3D trace, c'est simple d'utilisation.

Guillaume writes:

Et ? Quel routeur ferait perdre ces paquets ?

Il y a plusieurs machines entre le modem du côté DSLAM and la machine distante
avec laquelle je communique, donc plusieurs possibilités. Je ne sais pas
laquelle de ces machines en est la cause, car je ne peux que regarder les flux
de données de mon côté.

Essayez 3D trace, c'est simple d'utilisation.

J'y réfléchirai.

Mxsmanic a écrit :

Guillaume writes:

Et ? Quel routeur ferait perdre ces paquets ?

Il y a plusieurs machines entre le modem du côté DSLAM and la machine distante
avec laquelle je communique, donc plusieurs possibilités. Je ne sais pas
laquelle de ces machines en est la cause, car je ne peux que regarder les flux
de données de mon côté.

Essayez 3D trace, c'est simple d'utilisation.

J'y réfléchirai.

Ce serait mieux d'arrêter de réfléchier et de passer à l'action ...
3D trace, en mode liste, donne le nombre et % de paquets perdus en
fonction du routeur.

> Mxsmanic a écrit :

Guillaume writes:

Et ? Quel routeur ferait perdre ces paquets ?

Il y a plusieurs machines entre le modem du côté DSLAM and la machine
distante
avec laquelle je communique, donc plusieurs possibilités. Je ne sais pas
laquelle de ces machines en est la cause, car je ne peux que regarder les
flux
de données de mon côté.

Essayez 3D trace, c'est simple d'utilisation.

J'y réfléchirai.

Ce serait mieux d'arrêter de réfléchier et de passer à l'action ...
3D trace, en mode liste, donne le nombre et % de paquets perdus en fonction
du routeur.

Est ce que le role principale d'un routeur n'est t'il pas de router ?
C'est a dire que si il n'a pas le temps de repondre au ping, il y
repondera avec du retard, voire pas du tout ?

--
Les fautes d'orthographes sus-citées sont déposées auprès de leurs
propriétaires respectifs.
Aucune responsabilité n'est engagée sur la lisibilité du message ou les
éventuels dommages qu'ils peuvent engendrer

Channels <channels@cyber-rezo.net.nospam> a écrit sur son écran le
30/12/2008 20:23:26 +0100 :

Mxsmanic a écrit :

Guillaume writes:

Et ? Quel routeur ferait perdre ces paquets ?

Il y a plusieurs machines entre le modem du côté DSLAM and la machine
distante
avec laquelle je communique, donc plusieurs possibilités. Je ne sais
pas
laquelle de ces machines en est la cause, car je ne peux que regarder
les flux
de données de mon côté.

Essayez 3D trace, c'est simple d'utilisation.

J'y réfléchirai.

Ce serait mieux d'arrêter de réfléchier et de passer à l'action ...
3D trace, en mode liste, donne le nombre et % de paquets perdus en
fonction du routeur.

Est ce que le role principale d'un routeur n'est t'il pas de router ?
C'est a dire que si il n'a pas le temps de repondre au ping, il y
repondera avec du retard, voire pas du tout ?

Le tout est de savoir interpréter le résultat du traceroute, et de juger
de sa pertinence en fonction du résultat ;-)

--
> Pfff, si on peut plus supputer ou ça coince, je vais faire quoi,
> moi, me perdre dans le SI de FT ? :-p
c'est un coup à ce qu'on retrouve ta momie dans 100 ans
-+- Brina in GFD - "Le dégroupage avance en Egypte" -+-